أتمتة الاختبار

الموسوعة الحرة
جزء من سلسلة عن
تطوير البرمجيات
الأنشطة الأساسية
النماذج والأنماط
المنهجيات والأطر
دعم التخصصات
الممارسات
أدوات
المعايير وهيئات المعرفة
القواميس
الخطوط العريضة
  • ف
  • ت
  • هـ

في اختبار البرمجيات ، أتمتة الاختبار هي استخدام برنامج منفصل عن البرنامج الذي يتم اختباره للتحكم في تنفيذ الاختبارات ومقارنة النتائج الفعلية بالنتائج المتوقعة. [1] يمكن لأتمتة الاختبار أتمتة بعض المهام المتكررة ولكن الضرورية في عملية اختبار رسمية موجودة بالفعل، أو إجراء اختبارات إضافية يصعب القيام بها يدويًا. أتمتة الاختبار أمر بالغ الأهمية للتسليم المستمر والاختبار المستمر . [2]

النهج العام

هناك العديد من الطرق لأتمتة الاختبار، ولكن فيما يلي الطرق العامة المستخدمة على نطاق واسع:

طرق أخرى

الاختبار المبني على النموذج

إحدى الطرق لتوليد حالات الاختبار تلقائيًا هي الاختبار القائم على النموذج من خلال استخدام نموذج للنظام لتوليد حالات الاختبار، ولكن البحث مستمر في مجموعة متنوعة من المنهجيات البديلة للقيام بذلك. [ بحاجة لمصدر ] في بعض الحالات، يتيح النهج القائم على النموذج للمستخدمين غير الفنيين إنشاء حالات اختبار أعمال آلية باللغة الإنجليزية البسيطة بحيث لا تكون هناك حاجة إلى أي نوع من البرمجة من أجل تكوينها لأنظمة تشغيل ومتصفحات وأجهزة ذكية متعددة. [3]

اختبار الانحدار

قد تكون بعض مهام اختبار البرامج (مثل اختبار الانحدار الشامل للواجهة منخفضة المستوى ) شاقة وتستغرق وقتًا طويلاً إذا تم إجراؤها يدويًا. بالإضافة إلى ذلك، قد لا يكون النهج اليدوي فعالًا دائمًا في العثور على فئات معينة من العيوب. توفر أتمتة الاختبار إمكانية إجراء هذه الأنواع من الاختبارات بشكل فعال.

بمجرد تطوير الاختبارات الآلية، يمكن تشغيلها بسرعة وبشكل متكرر عدة مرات. يمكن أن تكون هذه طريقة فعّالة من حيث التكلفة لاختبار الانحدار لمنتجات البرامج التي تتمتع بعمر صيانة طويل. حتى التصحيحات البسيطة خلال عمر التطبيق يمكن أن تتسبب في تعطل الميزات الموجودة والتي كانت تعمل في وقت سابق.

اختبار واجهة برمجة التطبيقات

يستخدم اختبار واجهة برمجة التطبيقات أيضًا على نطاق واسع من قبل مختبري البرامج لأنه يتيح لهم التحقق من المتطلبات بشكل مستقل عن تنفيذ واجهة المستخدم الرسومية الخاصة بهم، وعادةً لاختبارها في وقت مبكر من التطوير، والتأكد من أن الاختبار نفسه يلتزم بمبادئ الكود النظيف، وخاصة مبدأ المسؤولية الفردية . يتضمن اختبار واجهات برمجة التطبيقات بشكل مباشر كجزء من اختبار التكامل ، لتحديد ما إذا كانت تلبي التوقعات الخاصة بالوظائف والموثوقية والأداء والأمان. [4] نظرًا لأن واجهات برمجة التطبيقات تفتقر إلى واجهة مستخدم رسومية ، يتم إجراء اختبار واجهة برمجة التطبيقات في طبقة الرسائل . [5] يُعتبر اختبار واجهة برمجة التطبيقات أمرًا بالغ الأهمية عندما تعمل واجهة برمجة التطبيقات كواجهة أساسية لمنطق التطبيق . [6]

اختبار واجهة المستخدم الرسومية (GUI)

توفر العديد من أدوات أتمتة الاختبار ميزات التسجيل والتشغيل التي تسمح للمستخدمين بتسجيل تصرفات المستخدم بشكل تفاعلي وإعادة تشغيلها أي عدد من المرات، ومقارنة النتائج الفعلية بتلك المتوقعة. تتمثل ميزة هذا النهج في أنه يتطلب القليل من تطوير البرامج أو لا يتطلب أي تطوير على الإطلاق. يمكن تطبيق هذا النهج على أي تطبيق يحتوي على واجهة مستخدم رسومية . ومع ذلك، فإن الاعتماد على هذه الميزات يفرض مشاكل كبيرة في الموثوقية والقدرة على الصيانة. قد تتطلب إعادة تسمية زر أو نقله إلى جزء آخر من النافذة إعادة تسجيل الاختبار. غالبًا ما يضيف التسجيل والتشغيل أيضًا أنشطة غير ذات صلة أو يسجل بعض الأنشطة بشكل غير صحيح. [ بحاجة لمصدر ]

هناك اختلاف في هذا النوع من الأدوات وهو مخصص لاختبار مواقع الويب. هنا، "الواجهة" هي صفحة الويب. ومع ذلك، يستخدم هذا الإطار تقنيات مختلفة تمامًا لأنه يقوم بعرض HTML والاستماع إلى أحداث DOM بدلاً من أحداث نظام التشغيل. تُستخدم عادةً متصفحات بدون واجهة أو حلول تعتمد على Selenium Web Driver لهذا الغرض. [7] [8] [9]

هناك شكل آخر من أشكال أداة أتمتة الاختبار هذه وهو اختبار التطبيقات المحمولة. وهذا مفيد للغاية نظرًا لعدد الأحجام والدقة وأنظمة التشغيل المختلفة المستخدمة على الهواتف المحمولة. بالنسبة لهذا الشكل، يتم استخدام إطار عمل لإنشاء مثيلات للإجراءات على الجهاز المحمول وجمع نتائج الإجراءات.

هناك اختلاف آخر وهو أتمتة الاختبار بدون نص برمجي لا يستخدم التسجيل والتشغيل، ولكن بدلاً من ذلك يبني نموذجًا [ يحتاج إلى توضيح ] للتطبيق ثم يتيح للمختبر إنشاء حالات اختبار عن طريق إدراج معلمات الاختبار والشروط ببساطة، الأمر الذي لا يتطلب مهارات البرمجة النصية.

المنهجيات

التطوير الموجه بالاختبار

أتمتة الاختبار، باستخدام اختبار الوحدة في الغالب، هي سمة أساسية للبرمجة المتطرفة وتطوير البرمجيات الرشيقة ، حيث تُعرف باسم التطوير القائم على الاختبار (TDD) أو تطوير الاختبار أولاً. يمكن كتابة اختبارات الوحدة لتحديد الوظيفة قبل كتابة الكود. ومع ذلك، تتطور اختبارات الوحدة هذه وتمتد مع تقدم الترميز، واكتشاف المشكلات وخضوع الكود لإعادة الهيكلة. [10] فقط عندما تمر جميع الاختبارات لجميع الميزات المطلوبة، يُعتبر الكود مكتملًا. يزعم المؤيدون أنه ينتج برنامجًا أكثر موثوقية وأقل تكلفة من الكود الذي يتم اختباره من خلال الاستكشاف اليدوي. [ بحاجة لمصدر ] يُعتبر أكثر موثوقية لأن تغطية الكود أفضل، ولأنه يتم تشغيله باستمرار أثناء التطوير بدلاً من تشغيله مرة واحدة في نهاية دورة تطوير الشلال . يكتشف المطور العيوب فور إجراء تغيير، عندما يكون إصلاحه أقل تكلفة. أخيرًا، يكون إعادة هيكلة الكود أكثر أمانًا عند استخدام اختبار الوحدة؛ إن تحويل الكود إلى نموذج أبسط مع تكرار أقل للكود ، ولكن السلوك المكافئ، يكون أقل احتمالية بكثير لإدخال عيوب جديدة عندما يتم تغطية الكود المعاد صياغته بواسطة اختبارات الوحدة.

الاختبار المستمر

الاختبار المستمر هو عملية تنفيذ اختبارات آلية كجزء من خط أنابيب تسليم البرامج للحصول على ملاحظات فورية حول المخاطر التجارية المرتبطة ببرنامج مرشح للإصدار. [11] [12] بالنسبة للاختبار المستمر، يمتد نطاق الاختبار من التحقق من صحة المتطلبات من الأسفل إلى الأعلى أو قصص المستخدم إلى تقييم متطلبات النظام المرتبطة بأهداف العمل الشاملة. [13]

اعتبارات

العوامل التي يجب مراعاتها عند اتخاذ قرار تنفيذ أتمتة الاختبار

ما الذي يجب أتمتته، ومتى يجب أتمتته، أو حتى ما إذا كان المرء يحتاج حقًا إلى الأتمتة هي قرارات حاسمة يجب على فريق الاختبار (أو التطوير) اتخاذها. [14] وجدت مراجعة أدبية متعددة المصادر لـ 52 ممارسًا و 26 مصدرًا أكاديميًا أن خمسة عوامل رئيسية يجب مراعاتها في قرار أتمتة الاختبار هي: 1) النظام قيد الاختبار (SUT)، 2) أنواع وأعداد الاختبارات، 3) أداة الاختبار، 4) الموضوعات البشرية والتنظيمية، و 5) العوامل المتقاطعة. كانت العوامل الفردية الأكثر شيوعًا التي تم تحديدها في الدراسة هي: الحاجة إلى اختبار الانحدار، والعوامل الاقتصادية، ونضج SUT. [15]

تأثير الهضبة

في حين أن شركات تطوير البرمجيات تقدر إعادة استخدام الاختبارات الآلية، إلا أن هذه الخاصية يمكن اعتبارها أيضًا عيبًا. فهي تؤدي إلى ما يسمى "مفارقة المبيدات الحشرية" ، حيث تتوقف البرامج النصية التي يتم تنفيذها بشكل متكرر عن اكتشاف الأخطاء التي تتجاوز أطر عملها. في مثل هذه الحالات، قد يكون الاختبار اليدوي استثمارًا أفضل. يؤدي هذا الغموض مرة أخرى إلى استنتاج مفاده أن القرار بشأن أتمتة الاختبار يجب أن يتم اتخاذه بشكل فردي، مع مراعاة متطلبات المشروع وخصائصه.

ماذا يجب اختباره

يمكن أن تساعد أدوات الاختبار في أتمتة المهام مثل تثبيت المنتج وإنشاء بيانات الاختبار والتفاعل مع واجهة المستخدم الرسومية واكتشاف المشكلات (ضع في اعتبارك تحليل أو استطلاع الوكلاء المجهزين بأوراكل الاختبار ) وتسجيل العيوب وما إلى ذلك، دون أتمتة الاختبارات بالضرورة بطريقة شاملة.

يجب علينا الاستمرار في تلبية المتطلبات الشائعة عند التفكير في أتمتة الاختبار:

الأدوار

أدوات أتمتة الاختبار

يمكن أن تكون أدوات أتمتة الاختبار باهظة الثمن وعادة ما يتم استخدامها مع الاختبار اليدوي. يمكن جعل أتمتة الاختبار فعالة من حيث التكلفة على المدى الطويل، وخاصة عند استخدامها بشكل متكرر في اختبار الانحدار . المرشح الجيد لأتمتة الاختبار هو حالة اختبار للتدفق المشترك للتطبيق، حيث يلزم تنفيذها (اختبار الانحدار) في كل مرة يتم فيها إجراء تحسين في التطبيق. تقلل أتمتة الاختبار من الجهد المرتبط بالاختبار اليدوي. هناك حاجة إلى جهد يدوي لتطوير وصيانة الفحوصات الآلية، بالإضافة إلى مراجعة نتائج الاختبار.

مهندس اختبار

في الاختبار الآلي، يجب أن يتمتع مهندس الاختبار أو الشخص المسؤول عن ضمان جودة البرمجيات بالقدرة على ترميز البرمجيات، حيث تتم كتابة حالات الاختبار في شكل كود مصدري ينتج عند تشغيله مخرجات وفقًا للتأكيدات التي تشكل جزءًا منه. تسمح بعض أدوات أتمتة الاختبار بتأليف الاختبار باستخدام الكلمات الرئيسية بدلاً من الترميز، وهو ما لا يتطلب البرمجة.

الاختبار على مستويات مختلفة

إحدى الاستراتيجيات لتحديد عدد الاختبارات التي سيتم أتمتتها هي هرم أتمتة الاختبار. تقترح هذه الاستراتيجية كتابة ثلاثة أنواع من الاختبارات بمستويات مختلفة من الدقة. وكلما ارتفع المستوى، قل عدد الاختبارات التي سيتم كتابتها. [16]

مستويات الوحدة والخدمة وواجهة المستخدم

هرم أتمتة الاختبار الذي اقترحه مايك كوهن [16]
  • باعتبارها أساسًا متينًا، توفر اختبارات الوحدات قوة ومتانة لمنتجات البرمجيات. إن اختبار أجزاء فردية من الكود يجعل من السهل كتابة الاختبارات وتشغيلها. يكتب المطورون اختبارات الوحدات كجزء من كل قصة ويدمجونها مع CI. [17]
  • تشير طبقة الخدمة إلى اختبار خدمات التطبيق بشكل منفصل عن واجهة المستخدم الخاصة به، وهذه الخدمات هي أي شيء يفعله التطبيق استجابة لبعض المدخلات أو مجموعة من المدخلات.
  • على المستوى الأعلى، لدينا اختبار واجهة المستخدم الذي يحتوي على عدد أقل من الاختبارات بسبب السمات المختلفة التي تجعل تشغيله أكثر تعقيدًا، على سبيل المثال هشاشة الاختبارات، حيث يمكن أن يؤدي التغيير الصغير في واجهة المستخدم إلى تعطيل الكثير من الاختبارات وإضافة جهد الصيانة. [16] [18]

الوحدة والتكامل والمستويات الشاملة

رسم تخطيطي مثلثي يصور "هرم الاختبار" الخاص بشركة Google. يبدأ من أصغر قسم "E2E" في الأعلى، ثم "Integration" في المنتصف، ثم القسم الأكبر "Unit" في الأسفل.
هرم اختبار جوجل [19]

يتضمن أحد مفاهيم هرم الاختبار اختبارات الوحدة والتكامل والاختبارات الشاملة. ووفقًا لمدونة اختبار Google ، يجب أن تشكل اختبارات الوحدة غالبية استراتيجية الاختبار الخاصة بك، مع عدد أقل من اختبارات التكامل وكمية صغيرة فقط من الاختبارات الشاملة. [19]

  • اختبارات الوحدة: هي اختبارات تختبر مكونات أو وحدات فردية من التعليمات البرمجية بشكل منعزل. وهي اختبارات سريعة وموثوقة وتعزل الأعطال في وحدات صغيرة من التعليمات البرمجية.
  • اختبارات التكامل: تتحقق هذه الاختبارات من كيفية عمل وحدات مختلفة من التعليمات البرمجية معًا. ورغم أن الوحدات الفردية قد تعمل بشكل صحيح بمفردها، فإن اختبارات التكامل تضمن عملها معًا بشكل متماسك.
  • الاختبارات الشاملة: تختبر هذه الاختبارات النظام ككل، وتحاكي سيناريوهات الاستخدام في العالم الحقيقي. وهي الاختبارات الأبطأ والأكثر تعقيدًا.

النهج الإطاري في الأتمتة

إطار عمل أتمتة الاختبار هو نظام متكامل يحدد قواعد أتمتة منتج معين. يدمج هذا النظام مكتبات الوظائف ومصادر بيانات الاختبار وتفاصيل الكائنات والوحدات النمطية القابلة لإعادة الاستخدام. تعمل هذه المكونات ككتل بناء صغيرة تحتاج إلى التجميع لتمثيل عملية تجارية. يوفر الإطار أساس أتمتة الاختبار ويبسط جهود الأتمتة.

الميزة الرئيسية لإطار الافتراضات والمفاهيم والأدوات التي توفر الدعم لاختبار البرامج الآلي هي التكلفة المنخفضة للصيانة . إذا كان هناك تغيير في أي حالة اختبار ، فلن يلزم تحديث سوى ملف حالة الاختبار وسيظل نص برنامج التشغيل ونص بدء التشغيل كما هو. من الناحية المثالية، ليست هناك حاجة لتحديث النصوص في حالة حدوث تغييرات في التطبيق.

يساعد اختيار الإطار/تقنية البرمجة النصية الصحيحة في الحفاظ على انخفاض التكاليف. وترجع التكاليف المرتبطة ببرمجة النصوص الاختبارية إلى جهود التطوير والصيانة. ويؤثر أسلوب البرمجة النصية المستخدم أثناء أتمتة الاختبار على التكاليف.

يتم استخدام العديد من تقنيات الإطار/البرمجة النصية بشكل عام:

  1. خطي (كود إجرائي، ربما تم إنشاؤه بواسطة أدوات مثل تلك التي تستخدم التسجيل والتشغيل)
  2. مُهيكل (يستخدم هياكل التحكم - عادةً "if-else"، "switch"، "for"، "while" الشروط/العبارات)
  3. يعتمد على البيانات (يتم الاحتفاظ بالبيانات خارج الاختبارات في قاعدة بيانات أو جدول بيانات أو آلية أخرى)
  4. تعتمد على الكلمات الرئيسية
  5. هجين (يتم استخدام اثنين أو أكثر من الأنماط المذكورة أعلاه)
  6. إطار عمل الأتمتة الرشيقة

إطار الاختبار مسؤول عن: [20]

  1. تحديد التنسيق الذي سيتم من خلاله التعبير عن التوقعات
  2. إنشاء آلية للربط بالتطبيق قيد الاختبار أو تشغيله
  3. تنفيذ الاختبارات
  4. نتائج التقارير

أطر اختبار الوحدة

يعد استخدام أطر عمل اختبار الوحدات مثل أطر عمل xUnit (على سبيل المثال، JUnit و NUnit ) من الاتجاهات المتزايدة في تطوير البرمجيات، والتي تسمح بتنفيذ اختبارات الوحدات لتحديد ما إذا كانت أقسام مختلفة من الكود تعمل كما هو متوقع في ظل ظروف مختلفة. تصف حالات الاختبار الاختبارات التي يجب تشغيلها على البرنامج للتحقق من تشغيل البرنامج كما هو متوقع.

واجهة أتمتة الاختبار

تُعد واجهات أتمتة الاختبار منصات توفر مساحة عمل واحدة لدمج أدوات وإطارات اختبار متعددة لاختبار النظام/التكامل للتطبيق قيد الاختبار. والهدف من واجهة أتمتة الاختبار هو تبسيط عملية تعيين الاختبارات لمعايير العمل دون أن يعترض الترميز طريق العملية. ومن المتوقع أن تعمل واجهة أتمتة الاختبار على تحسين كفاءة ومرونة صيانة نصوص الاختبار. [21]

نموذج واجهة أتمتة الاختبار

تتكون واجهة أتمتة الاختبار من الوحدات الأساسية التالية:

  • محرك الواجهة
  • بيئة الواجهة
  • مستودع الكائنات

محرك الواجهة

تم بناء محركات الواجهة على بيئة الواجهة. يتكون محرك الواجهة من محلل ومشغل اختبار. يكون المحلل موجودًا لتحليل ملفات الكائنات القادمة من مستودع الكائنات إلى لغة البرمجة النصية الخاصة بالاختبار. ينفذ مشغل الاختبار نصوص الاختبار باستخدام تسخير الاختبار . [21]

مستودع الكائنات

مستودعات الكائنات عبارة عن مجموعة من بيانات كائنات واجهة المستخدم/التطبيق المسجلة بواسطة أداة الاختبار أثناء استكشاف التطبيق قيد الاختبار. [21]

تحديد الحدود بين إطار العمل الآلي وأداة الاختبار

تم تصميم الأدوات خصيصًا لاستهداف بيئة اختبار معينة، مثل أدوات أتمتة Windows والويب، وما إلى ذلك. تعمل الأدوات كعامل محرك لعملية الأتمتة. ومع ذلك، فإن إطار عمل الأتمتة ليس أداة لأداء مهمة محددة، بل هو البنية الأساسية التي توفر الحل حيث يمكن لأدوات مختلفة القيام بوظيفتها بطريقة موحدة. وهذا يوفر منصة مشتركة لمهندس الأتمتة.

هناك أنواع مختلفة من الأطر. يتم تصنيفها على أساس مكون الأتمتة الذي تستفيد منه. وهي:

  1. الاختبار المبني على البيانات
  2. الاختبار القائم على الوحدات النمطية
  3. الاختبار القائم على الكلمات الرئيسية
  4. الاختبار الهجين
  5. الاختبار المبني على النموذج
  6. الاختبار الموجه بالكود
  7. التنمية القائمة على السلوك

الاختبار المبني على البيانات

الاختبار القائم على البيانات (DDT)، والمعروف أيضًا باسم الاختبار القائم على الجدول أو الاختبار المعلمي، هو منهجية اختبار برمجية تُستخدم في اختبار برامج الكمبيوتر لوصف الاختبار الذي يتم إجراؤه باستخدام جدول الشروط مباشرةً كمدخلات اختبار ومخرجات قابلة للتحقق بالإضافة إلى العملية حيث لا يتم ترميز إعدادات بيئة الاختبار والتحكم فيها بشكل ثابت. [22] [23] في أبسط أشكاله، يوفر المختبر المدخلات من صف في الجدول ويتوقع المخرجات التي تحدث في نفس الصف. يحتوي الجدول عادةً على قيم تتوافق مع مساحات الإدخال الحدودية أو التقسيمية. في منهجية التحكم، يتم "قراءة" تكوين الاختبار من قاعدة بيانات.

الاختبار القائم على الوحدات النمطية

الاختبار القائم على الوحدات النمطية هو مصطلح يستخدم في اختبار البرمجيات . يتطلب إطار عمل وحدات نص الاختبار إنشاء نصوص صغيرة مستقلة تمثل وحدات وأقسام ووظائف التطبيق قيد الاختبار. ثم تُستخدم هذه النصوص الصغيرة بطريقة هرمية لإنشاء اختبارات أكبر، وتحقيق حالة اختبار معينة. [24]

الاختبار القائم على الكلمات الرئيسية

الاختبار القائم على الكلمات الرئيسية ، والمعروف أيضًا باسم الاختبار القائم على الكلمات العملية (لا ينبغي الخلط بينه وبين الاختبار القائم على الفعل)، هو منهجية اختبار برمجية مناسبة للاختبار اليدوي والآلي . تفصل هذه الطريقة توثيق حالات الاختبار  - بما في ذلك البيانات والوظائف المستخدمة - عن وصف طريقة تنفيذ حالات الاختبار. ونتيجة لذلك، فإنها تفصل عملية إنشاء الاختبار إلى مرحلتين متميزتين: مرحلة التصميم والتطوير ومرحلة التنفيذ. تغطي المرحلة الفرعية للتصميم تحليل المتطلبات وتقييمها وتحليل البيانات وتعريفها وتعدادها.

الاختبار الهجين

الاختبار الهجين هو ما تتطور إليه أغلب الأطر بمرور الوقت والمشاريع المتعددة. وتستوعب أطر التشغيل الآلي الأكثر نجاحًا بشكل عام كلًا من القواعد النحوية والإملائية، بالإضافة إلى إدخال المعلومات. وهذا يسمح بمراجعة المعلومات المقدمة مقابل المعلومات الموجودة والمؤكدة. وهذا يساعد على منع نشر معلومات خاطئة أو مضللة. ومع ذلك، فإنه يسمح للآخرين بنشر معلومات جديدة وذات صلة بالمشاركات الموجودة، وبالتالي يزيد من فائدة وأهمية الموقع. ومع ذلك، لا يوجد نظام مثالي، وقد لا يعمل وفقًا لهذا المعيار في جميع الموضوعات طوال الوقت ولكنه سيتحسن مع زيادة الإدخال وزيادة الاستخدام.

الاختبار المبني على النموذج

إعداد الاختبار العام القائم على النموذج
الاختبار القائم على النموذج هو تطبيق للتصميم القائم على النموذج لتصميم وتنفيذ القطع الأثرية بشكل اختياري لإجراء اختبار البرمجيات أو اختبار النظام . يمكن استخدام النماذج لتمثيل السلوك المطلوب للنظام قيد الاختبار (SUT)، أو لتمثيل استراتيجيات الاختبار وبيئة الاختبار. توضح الصورة الموجودة على اليمين النهج السابق.

التنمية القائمة على السلوك

يتضمن التطوير الموجه بالسلوك (BDD) تسمية اختبارات البرمجيات باستخدام لغة المجال لوصف سلوك الكود .

انظر أيضا

مراجع

  1. ^ كولاوا، آدم؛ هويزينجا، دوروتا (2007). منع العيوب الآلي: أفضل الممارسات في إدارة البرمجيات . مطبعة جمعية وايلي-معهد مهندسي الكهرباء والإلكترونيات للكمبيوتر. ص. 74. رقم ISBN 978-0-470-04212-0.
  2. ^ O'Connor, Rory V.; Akkaya, Mariye Umay; Kemaneci, Kerem; Yilmaz, Murat; Poth, Alexander; Messnarz, Richard (2015-10-15). Systems, Software and Services Process Improvement: 22nd European Conference, EuroSPI 2015, أنقرة، تركيا، 30 سبتمبر - 2 أكتوبر 2015. Proceedings. Springer. ISBN 978-3-319-24647-5.
  3. ^ وقائع المؤتمر الدولي الخامس لاختبار البرمجيات والتحقق من صحتها (ICST). مركز كفاءة البرمجيات هاجنبرج. "تصميم الاختبار: الدروس المستفادة والتداعيات العملية . doi :10.1109/IEEESTD.2008.4578383. ISBN 978-0-7381-5746-7.
  4. ^ اختبار واجهات برمجة التطبيقات يحمي التطبيقات والسمعة، بقلم إيمي رايخرت، SearchSoftwareQuality مارس 2015
  5. ^ كل شيء عن اختبار واجهة برمجة التطبيقات: مقابلة مع جوناثان كوبر، بقلم كاميرون فيليب إدموندز، ستيكيمايندز، 19 أغسطس 2014
  6. ^ إنتاج برامج أفضل باستخدام استراتيجية الاختبار الطبقي، بقلم شون كينفيك، جارتنر ، 7 يناير 2014
  7. ^ الاختبار بدون رأس باستخدام المتصفحات؛ https://docs.travis-ci.com/user/gui-and-headless-browsers/
  8. ^ الاختبار بدون رأس باستخدام PhantomJS؛http://phantomjs.org/headless-testing.html
  9. ^ اختبار واجهة المستخدم الآلي؛ https://www.devbridge.com/articles/automated-user-interface-testing/
  10. ^ Vodde, Bas; Koskela, Lasse (2007). "تعلم التطوير الموجه بالاختبار من خلال عد الخطوط". IEEE Software . 24 (3): 74–79. doi :10.1109/ms.2007.80. S2CID  30671391.
  11. ^ جزء من خط الأنابيب: لماذا يعد الاختبار المستمر ضروريًا، بقلم آدم أورباخ، TechWell Insights أغسطس 2015
  12. ^ العلاقة بين المخاطر والاختبار المستمر: مقابلة مع واين أريولا، بقلم كاميرون فيليب إدموندز، ستيكيمايندز، ديسمبر 2015
  13. ^ DevOps: هل تقوم بإرسال الأخطاء إلى العملاء بشكل أسرع، بقلم واين أريولا وسينثيا دنلوب، PNSQC أكتوبر 2015
  14. ^ Brian Marick. "متى يجب أتمتة الاختبار؟". StickyMinds.com . تم الاسترجاع في 2009-08-20 .
  15. ^ جاروسي، وحيد؛ مانتيلا، ميكا ف. (2016-08-01). "متى وماذا يجب أتمتته في اختبار البرمجيات؟ مراجعة أدبية متعددة المصادر". تكنولوجيا المعلومات والبرمجيات . 76 : 92-117. doi :10.1016/j.infsof.2016.04.015.
  16. ^ abc Mike Cohn (2010). النجاح مع Agile . راينا شروباك. ISBN 978-0-321-57936-2.
  17. ^ "Full Stack Testing by Gayathri Mohan". www.thoughtworks.com . تم الاسترجاع في 2022-09-13 .
  18. ^ هرم الاختبار العملي، بقلم هام فوكي
  19. ^ "قل لا لمزيد من الاختبارات الشاملة". مدونة اختبار Google . تم الاسترجاع في 11 فبراير 2023 .
  20. ^ "لقاء سيلينيوم 20/4/2010 إليزابيث هندريكسون حول إطار عمل الروبوت 1of2". يوتيوب . 28 أبريل 2010. تم الاسترجاع في 2010-09-26 .
  21. ^ abc "Conquest: Interface for Test Automation Design" (PDF) . مؤرشف من الأصل (PDF) في 2012-04-26 . تم الاسترجاع في 2011-12-11 .
  22. ^ "golang/go TableDrivenTests". GitHub .
  23. ^ "دليل مستخدم JUnit 5". junit.org .
  24. ^ DESAI, SANDEEP; SRIVASTAVA, ABHISHEK (2016-01-30). SOFTWARE TESTING : A Practical Approach (باللغة العربية). PHI Learning Pvt. Ltd. ISBN 978-81-203-5226-1.

المراجع العامة

  • Elfriede Dustin؛ et al. (1999). Automated Software Testing . Addison Wesley. ISBN 978-0-201-43287-9.
  • Elfriede Dustin؛ et al. (2009). تنفيذ اختبار البرمجيات الآلي . Addison Wesley. ISBN 978-0-321-58051-1.
  • مارك فوستر ودوروثي جراهام (1999). أتمتة اختبار البرمجيات . دار نشر ACM/أديسون ويسلي. رقم ISBN 978-0-201-33140-0.
  • رومان سافينكوف: كيف تصبح مُختبر برامج. رومان سافينكوف للاستشارات، 2008، ISBN 978-0-615-23372-7 
  • هونغ تشو؛ وآخرون (2008). AST '08: وقائع ورشة العمل الدولية الثالثة حول أتمتة اختبار البرمجيات. ACM Press. doi :10.1145/1370042. ISBN 978-1-60558-030-2.
  • موسلي، دانيال جيه؛ بوسي، بروس (2002). أتمتة اختبار البرمجيات بالقدر الكافي . برنتيس هول بروفيشنال. رقم ISBN 978-0130084682.
  • هايز، ليندا جي، "دليل الاختبار الآلي"، معهد اختبار البرمجيات، الطبعة الثانية، مارس 2004
  • كانر، سيم، "هندسة أتمتة الاختبار المؤرشفة في 2021-01-26 على موقع واي باك مشين "، أغسطس 2000


Retrieved from "https://en.wikipedia.org/w/index.php?title=Test_automation&oldid=1246651799"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate