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

خطة الاختبار هي أساس اختبار كل برنامج. إنه النشاط الأكثر أهمية الذي يضمن توافر جميع قوائم الأنشطة المخططة بالتسلسل المناسب.

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

أنواع خطة الاختبار

هناك ثلاثة أنواع من خطة الاختبار

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

خطة الاختبار الرئيسية

خطة الاختبار الرئيسية هي نوع من خطة الاختبار التي تحتوي على مستويات متعددة من الاختبار. يتضمن استراتيجية اختبار كاملة.

خطة اختبار المرحلة

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

خطط اختبار محددة

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

كيفية كتابة خطة الاختبار

يعد وضع خطة اختبار المهمة الأكثر أهمية في عملية إدارة الاختبار. وفقًا لمعيار IEEE 829، اتبع الخطوات السبع التالية لإعداد خطة الاختبار.

• أولا، تحليل هيكل المنتج والهندسة المعمارية.
• الآن قم بتصميم استراتيجية الاختبار.
• تحديد كافة أهداف الاختبار.
• تحديد منطقة الاختبار.
• تحديد جميع الموارد القابلة للاستخدام.
• جدولة جميع الأنشطة بطريقة مناسبة.
• تحديد جميع مخرجات الاختبار.

مكونات خطة الاختبار أو سماتها

تتكون خطة الاختبار من أجزاء مختلفة تساعدنا في استخلاص نشاط الاختبار بأكمله.

أهداف: وهو يتألف من معلومات حول الوحدات والميزات وبيانات الاختبار وما إلى ذلك، والتي تشير إلى هدف التطبيق يعني سلوك التطبيق والهدف وما إلى ذلك.

نِطَاق: أنه يحتوي على المعلومات التي تحتاج إلى اختبارها مع كل تطبيق. يمكن تقسيم النطاق أيضًا إلى قسمين:

• في نطاق
• خارج النطاق

في نطاق: هذه هي الوحدات التي تحتاج إلى اختبار صارم (بالتفصيل).

خارج النطاق: هذه هي الوحدات التي لا تحتاج إلى اختبارها بدقة.

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

الآن كيف نقرر الميزات التي لا يجب اختبارها؟

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

ما هو أوري

• كما نرى فوق ذلك يساعد لن يتم اختبار الميزات، حيث يتم كتابتها وتطويرها بواسطة الكاتب الفني ومراجعتها من قبل كاتب محترف آخر.
• لنفترض أن لدينا تطبيقًا واحدًا يحتوي على ف، س، ر، و س الميزات التي تحتاج إلى تطوير بناءً على المتطلبات. ولكن هنا، تم بالفعل تصميم ميزة S واستخدامها من قبل بعض الشركات الأخرى. لذلك سيقوم فريق التطوير بشراء S من تلك الشركة ودمجه مع ميزات إضافية مثل P وQ وR.

الآن، لن نقوم بإجراء اختبار وظيفي على ميزة S لأنه تم استخدامها بالفعل في الوقت الفعلي. لكننا سنجري اختبار التكامل واختبار النظام بين ميزات P وQ وR وS لأن الميزات الجديدة قد لا تعمل بشكل صحيح مع ميزة S كما نرى في الصورة أدناه:

• لنفترض في الإصدار الأول للمنتج، العناصر التي تم تطويرها، مثل P، Q، R، S، T، U، V، W…..X، Y، Z . الآن سيقوم العميل بتوفير متطلبات الميزات الجديدة التي تعمل على تحسين المنتج في الإصدار الثاني والميزات الجديدة هي A1 وB2 وC3 وD4 وE5.

بعد ذلك، سوف نكتب النطاق أثناء خطة الاختبار كما يلي

نِطَاق

الميزات التي سيتم اختبارها

A1، B2، C3، D4، E5 (ميزات جديدة)

ف، س، ص، ق، ت

الميزات لا يمكن اختبارها

ث…..X، Y، Z

لذلك، سوف نقوم بفحص الميزات الجديدة أولاً ثم الاستمرار في الميزات القديمة لأن ذلك قد يتأثر بعد إضافة الميزات الجديدة، مما يعني أنها ستؤثر أيضًا على مناطق التأثير، لذلك سنقوم بجولة واحدة من اختبار الانحدار لـ P، Q ، ر…، ميزات تي.

منهجية الاختبار:

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

على سبيل المثال، للتطبيق المستقل مثل أدوبي فوتوشوب ، سنقوم بإجراء الأنواع التالية من الاختبارات:

اختبار الدخان ← الاختبار الوظيفي ← اختبار التكامل ← اختبار النظام ← اختبار مخصص ← اختبار التوافق ← اختبار الانحدار ← اختبار العولمة ← اختبار إمكانية الوصول ← اختبار سهولة الاستخدام ← اختبار الموثوقية ← اختبار الاسترداد ← اختبار التثبيت أو إلغاء التثبيت

ولنفترض أن علينا اختبار https://www.jeevansathi.com/ التطبيق، لذلك سنقوم بإجراء الأنواع التالية من الاختبارات:

يقترب

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

يمكننا فهم تدفق التطبيق بمساعدة الجوانب التالية:

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

من خلال كتابة السيناريوهات عالية المستوى

على سبيل المثال لنفترض أننا نختبر بريد جوجل طلب:

• تسجيل الدخول إلى Gmail - يرسل بريدًا إلكترونيًا ويتحقق مما إذا كان موجودًا في صفحة العناصر المرسلة
• تسجيل الدخول إلى …….
• ……
• …..

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

عن طريق كتابة الرسم البياني التدفق

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

نقوم بإنشاء الرسوم البيانية الانسيابية لتحقيق الفوائد التالية مثل:

• التغطية سهلة
• الدمج سهل

ويمكن تقسيم المنهج إلى قسمين وهما كما يلي:

• النهج من أعلى إلى أسفل
• النهج من الأسفل إلى الأعلى

افتراض

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

مخاطرة

هذه هي التحديات التي يتعين علينا مواجهتها لاختبار التطبيق في الإصدار الحالي، وإذا فشلت الافتراضات، فإن المخاطر ستكون متضمنة.

على سبيل المثال، تأثير التطبيق، يتم تأجيل تاريخ الإصدار.

خطة التخفيف أو خطة الطوارئ

إنها خطة احتياطية تم إعدادها للتغلب على المخاطر أو المشكلات.

دعونا نرى مثالاً واحدًا للافتراض والمخاطر وخطة الطوارئ معًا لأنها مرتبطة ببعضها البعض.

في أي منتج، افتراض ما سنفعله هو أن جميع مهندسي الاختبار الثلاثة سيكونون هناك حتى الانتهاء من المنتج ويتم تعيين وحدات مختلفة لكل منهم مثل P وQ وR. في هذا السيناريو بالذات، مخاطرة يمكن أن يكون ذلك إذا ترك مهندس الاختبار المشروع في منتصفه.

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

دائمًا ما تكون الافتراضات والمخاطر وخطة التخفيف أو الطوارئ دقيقة بالنسبة للمنتج نفسه. أنواع المخاطر المختلفة هي كما يلي:

فرز القائمة حسب جافا

• منظور العملاء
• نهج الموارد
• الرأي الفني

دور ومسؤولية

فهو يحدد المهمة الكاملة التي يجب أن يؤديها فريق الاختبار بأكمله. عندما يأتي مشروع كبير، ثم مدير الاختبار هو الشخص الذي يكتب خطة الاختبار. إذا كان هناك 3-4 مشاريع صغيرة، فسيقوم مدير الاختبار بتعيين كل مشروع لكل قائد اختبار. وبعد ذلك، يكتب قائد الاختبار خطة الاختبار للمشروع، والتي يتم تعيينها له.

دعونا نرى مثالاً حيث سنفهم أدوار ومسؤولية مدير الاختبار، ورئيس الاختبار، ومهندسي الاختبار.

الدور: مدير الاختبار

الاسم: ريان

مسؤولية:

• إعداد (كتابة ومراجعة) خطة الاختبار
• عقد الاجتماع مع فريق التطوير
• عقد الاجتماع مع فريق الاختبار
• إجراء الاجتماع مع العميل
• عقد اجتماع الوقوف شهريا
• قم بتسجيل الخروج من مذكرة الإصدار
• التعامل مع التصعيد والقضايا

الدور: اختبار الرصاص

الاسم: هارفي

مسؤولية:

• إعداد (كتابة ومراجعة) خطة الاختبار
• عقد اجتماع الوقوف اليومي
• مراجعة حالة الاختبار والموافقة عليها
• إعداد RTM والتقارير
• تعيين الوحدات
• الجدول الزمني للتعامل

الدور: مهندس اختبار 1، مهندس اختبار 2 ومهندس اختبار 3

الاسم: لويس، جيسيكا، دونا

تعيين الوحدات: M1 وM2 وM3

مسؤولية:

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

جدول

يتم استخدامه لشرح توقيت العمل، وما الذي يجب القيام به أم أن هذه السمة تغطي متى يجب أن يبدأ كل نشاط اختبار وينتهي بالضبط؟ ويتم أيضًا ذكر البيانات الدقيقة لكل نشاط اختبار في تاريخ معين.

ولذلك كما نرى في الصورة أدناه أنه بالنسبة للنشاط المحدد، سيكون هناك تاريخ بدء وتاريخ انتهاء؛ لكل اختبار لبناء معين، سيكون هناك تاريخ محدد.

على سبيل المثال

• كتابة حالات الاختبار
• عملية التنفيذ

تتبع الخلل

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

فيما يلي جوانب مختلفة لتتبع الخلل:

تقنيات لتتبع الخلل
…..
……
……
……أدوات تتبع الأخطاء
يمكننا التعليق على اسم الأداة التي سنستخدمها لتتبع الأخطاء. بعض أدوات تتبع الأخطاء الأكثر استخدامًا هي Jira، وBugzilla، وMantis، وTrac، وما إلى ذلك.<خطورة
يمكن أن تكون الخطورة على النحو التالي:
مانع أو showstopper
…..
….. (اشرح ذلك بمثال في خطة الاختبار)
على سبيل المثال سيكون هناك خلل في الوحدة؛ لا يمكننا المضي قدمًا لاختبار الوحدات الأخرى لأنه إذا تم حظر الخطأ، فيمكننا المتابعة للتحقق من الوحدات الأخرى.
شديد الأهمية
……
….. (اشرح ذلك بمثال في خطة الاختبار)
في هذه الحالة، سوف تؤثر العيوب على العمل.
رئيسي
….
…. (اشرح ذلك بمثال في خطة الاختبار)
صغير
…..
….. (اشرح ذلك بمثال في خطة الاختبار)
هذه العيوب هي تلك التي تؤثر على شكل ومظهر التطبيق.أولوية
عالية-P1
…..
متوسطة-P2
…..
منخفض P3
…..
…..
ص4

لذلك، بناءً على أولوية الأخطاء مثل العالية والمتوسطة والمنخفضة، سنقوم بتصنيفها إلى P1 وP2 وP3 وP4.

بيئات الاختبار

هذه هي البيئات التي سنختبر فيها التطبيق، وهنا لدينا نوعان من البيئات، وهما برمجة و المعدات إعدادات.

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

و ال تكوين الأجهزة يعني المعلومات حول أحجام مختلفة من ذاكرة الوصول العشوائي (RAM) وذاكرة القراءة فقط (ROM) والمعالجات .

على سبيل المثال

• ال برمجة يتضمن ما يلي:

الخادم

قائمة الصفيف مرتبة في Java

ملحوظة: الخوادم المذكورة أعلاه هي الخوادم التي يستخدمها فريق الاختبار لاختبار التطبيق.

عميل

ملاحظة: توفر التفاصيل المذكورة أعلاه أنظمة التشغيل والمتصفحات المختلفة التي سيقوم فريق الاختبار باختبار التطبيق فيها.

• ال المعدات يتضمن ما يلي:

الخادم : صن ستار كات 1500

يمكن لفريق الاختبار استخدام هذا الخادم المحدد لاختبار تطبيقاتهم.

عميل:

لديها التكوين التالي، وهو على النحو التالي:

ملحوظة: سيوفر تكوين أنظمة مهندسي الاختبار الذين يمثلون فريق الاختبار.

عملية تثبيت البرنامج
……
…..
…..

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

معايير الدخول والخروج

وهو شرط ضروري يجب استيفاؤه قبل البدء في عملية الاختبار وإيقافها.

معايير الدخول

تحتوي معايير الدخول على الشروط التالية:

• يجب الانتهاء من اختبار الصندوق الأبيض.
• فهم وتحليل المتطلبات وإعداد وثائق الاختبار أو عندما تكون وثائق الاختبار جاهزة.
• يجب أن تكون بيانات الاختبار جاهزة.
• بناء أو يجب أن يتم إعداد التطبيق
• يجب تعيين الوحدات أو الميزات لمهندسي الاختبار المختلفين.
• يجب أن يكون المورد اللازم جاهزًا.

معايير الخروج

تتضمن معايير الخروج الشروط التالية:

• عندما يتم تنفيذ جميع حالات الاختبار.
• يجب أن تكون معظم حالات الاختبار اجتاز .
• يعتمد على خطورة الأخطاء مما يعني أنه لا يجب أن يكون هناك أي مانع أو خطأ كبير، في حين توجد بعض الأخطاء الصغيرة.

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

هنا على أساس خطورة يعني وجود الخطأ أن فريق الاختبار كان سيقرر المضي قدمًا في المراحل التالية.

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

وفي هذا سنقرر ما يلي:

• ما هي الميزة التي يجب أن تكون آلية وليست آلية؟
• ما هي أداة التشغيل الآلي للاختبار التي سنستخدمها في إطار التشغيل الآلي؟

نقوم بأتمتة حالة الاختبار فقط بعد الإصدار الأول.

وهنا يطرح السؤال أنه على أي أساس نحن سوف تحديد الميزات التي يجب اختبارها؟

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

الآن، كيف نقرر ما هي الميزات التي لن يتم اختبارها؟

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

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

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

تقدير الجهود

في هذا، سنقوم بتخطيط الجهد الذي يجب أن يطبقه كل عضو في الفريق.

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

هذه هي المستندات التي هي مخرجات فريق الاختبار والتي قمنا بتسليمها للعميل مع المنتج. ويشمل ما يلي:

خطة اختبار حالات تجريبية مخطوطات الاختبار RTM (مصفوفة تتبع المتطلبات) تقرير العيب تقرير تنفيذ الاختبار الرسوم البيانية والمقاييس ملاحظات الإصدار

الرسوم البيانية والمقاييس

رسم بياني

وفي هذا سنتحدث عن أنواع الرسوم البيانية سوف نرسل، وسوف نقدم أيضا عينة من كل رسم بياني.

كما نرى، لدينا خمسة رسوم بيانية مختلفة توضح الجوانب المختلفة لعملية الاختبار.

الرسم البياني 1: سنوضح في هذا عدد العيوب التي تم تحديدها وعدد العيوب التي تم إصلاحها في كل وحدة.

الرسم البياني 2: يوضح الشكل الأول عدد العيوب الحرجة والكبيرة والثانوية التي تم تحديدها لكل وحدة وعدد العيوب التي تم إصلاحها للوحدات الخاصة بها.

الرسم البياني 3: في هذا الرسم البياني بالذات، نحن نمثل بناء الرسم البياني الحكيم مما يعني أنه في كل بناء، ما هو عدد العيوب التي تم تحديدها وإصلاحها لكل وحدة. بناءً على الوحدة، حددنا الأخطاء. سوف نضيف ر لتوضيح عدد العيوب في P و Q ونضيفها أيضاً س لإظهار العيوب في P وQ وR.

كيفية تحويل str إلى int

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

الرسم البياني5: ال مدير الاختبار وقد صمم هذا النوع من الرسم البياني. يهدف هذا الرسم البياني إلى فهم الفجوة في تقييم الأخطاء والأخطاء الفعلية التي حدثت، ويساعد هذا الرسم البياني أيضًا على تحسين تقييم الأخطاء في المستقبل.

المقاييس

كما هو مذكور أعلاه، قمنا بإنشاء الرسم البياني لتوزيع الأخطاء، والذي يظهر في الشكل 1، وبمساعدة البيانات المذكورة أعلاه، سنقوم بتصميم المقاييس أيضًا.

على سبيل المثال

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

أصدر مذكرة: إنها وثيقة يتم إعدادها أثناء إصدار المنتج وتوقيعها من قبل مدير الاختبار.

في الصورة أدناه، يمكننا أن نرى أنه تم تطوير المنتج النهائي ونشره للعميل، واسم الإصدار الأخير هو بيتا .

ال أصدر مذكرة يتكون مما يلي:

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

على سبيل المثال

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

نموذج

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

• نموذج حالة الاختبار
• نموذج مراجعة حالة الاختبار
• قالب RTM
• نموذج تقرير الأخطاء
• تقرير تنفيذ الاختبار

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

صفحة 1

صفحة3-صفحة18

الصفحة-20

في الصفحة 1، نقوم في المقام الأول بملء الملف فقط الإصدارات والمؤلف والتعليقات والمراجعة بواسطة الحقول، وبعد موافقة المدير عليها سنذكر التفاصيل في تمت الموافقة عليه وتاريخ الموافقة مجالات.

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

ملحوظة:

من يكتب خطة الاختبار؟

• اختبار الرصاص→60%
• مدير الاختبار→20%
• مهندس اختبار→20%

لذلك، كما يمكننا أن نرى مما سبق أنه في 60% من المنتج، تتم كتابة خطة الاختبار بواسطة قائد الاختبار.

من يقوم بمراجعة خطة الاختبار؟

• اختبار الرصاص
• مدير الاختبار
• مهندس اختبارات
• عميل
• فريق التطوير

يقوم مهندس الاختبار بمراجعة خطة الاختبار لمنظور الوحدة الخاصة به ويقوم مدير الاختبار بمراجعة خطة الاختبار بناءً على رأي العميل.

من يوافق على خطة الاختبار؟

• عميل
• مدير الاختبار

من يكتب حالة الاختبار؟

• اختبار الرصاص
• مهندس اختبارات

من يراجع حالة الاختبار؟

الأبجدية كأرقام

• مهندس اختبارات
• اختبار الرصاص
• عميل
• فريق التطوير

من يوافق على حالات الاختبار؟

• مدير الاختبار
• اختبار الرصاص
• عميل

إرشادات خطة الاختبار

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

أهمية خطة الاختبار

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