تطوير اختبارات من طراز
في Microsoft Visual Studio Ultimate ، يمكنك استخدام نماذج البناء و المتطلبات لتنظيم الاختبارات من أجل النظام الخاص بك و المكونات الخاصة به. هذا يساعد على ضمان اختبار المتطلبات ذات الأهمية للمستخدمين و المساهمين الآخرين , و يساعدك على تحديث الاختبارات بسرعة عند تغيير المتطلبات. إذا كنت تستخدم Microsoft Test Manager ، يمكنك أيضًا المحافظة على الارتباطات بين النماذج و الاختبارات.
اختبار النظام و النظام الفرعي
اختبار النظام, والذي يعرف أيضاً باسم اختبار القبول ، يعني اختبار ما إذا كانت احتياجات المستخدمين قد تحققت. مثل هذه الاختبارات تهتم بالسلوك المرئي خارجياً للنظام بدلاً من التصميم الداخلي.
اختبارات النظام تكون هامة جداً عند توسيع أو إعادة تصميم نظام . تساعدك هذه على تجنب ظهور الأخطاء عند تغيير التعليمات البرمجية.
عندما تخطط لأي تغيير أو إلحاق إلى نظام, يكون من المفيد البدء بمجموعة من اختبارات النظام التي تعمل على النظام الموجود. ثم يمكنك توسيع أو ضبط الاختبارات لاختبار المتطلبات الجديدة, إجراء التغييرات في التعليمات البرمجية, ثم إعادة تشغيل المجموعة الكاملة من الاختبارات.
عند تطوير نظام جديد يمكنك البدء بإنشاء الاختبارات بمجرد أن يبدأ التطوير. عن طريق تعريف الاختبارات قبل تطوير أي ميزة, يمكنك التقاط مناقشات المتطلبات بطريقة معينة جداً.
اختبار النظام الفرعي يطبّق نفس المبادئ على المكونات الرئيسية لنظام. يتم اختبار كل مكوّن بشكل منفصل عن المكونات الأخرى. اختبارات النظام الفرعي تركّز على السلوك المرئي في واجهات المستخدم للمكوّن أو API.
للحصول على مزيد من المعلومات حول كيفية تشغيل الاختبارات, انظر اختبار التطبيق.
اشتقاق اختبارات النظام من طراز متطلبات
يمكنك إنشاء و صيانة علاقة بين اختبارات النظام و طراز متطلبات. إلى تأسيس هذه العلاقة، تقوم بكتابة الاختبارات التي تتوافق مع إلى عناصر الطراز المتطلبات الأساسية. Visual Studio Ultimateيساعد في المحافظة على علاقة تلك بواسطة السماح لك بإنشاء الارتباطات بين الاختبارات و أجزاء من طراز. للحصول على مزيد من المعلومات حول طرازات المتطلبات, راجع بناء متطلبات المستخدم.
كتابة اختبارات لكل حالة استخدام
إذا كنت تستخدم Microsoft Test Manager ، يمكنك إنشاء مجموعة من الاختبارات لكل حالة استخدام قمت بتعريفها في طراز المتطلبات الخاص بك. على سبيل المثال، إذا كان لديك حالة استخدام "طلب وجبة", تتضمن "إنشاء طلب" و "إضافة عنصر إلى الطلب" ، يمكنك إنشاء اختبارات لكل من حالات الاستخدام الإجمالية و الأكثر تفصيلاً. لمزيد من المعلومات حول حالات الاستخدام, راجعمخطط حالات استخدام UML إرشادات.
هذه الإرشادات قد تكون مفيدة:
كل حالة استخدام يجب أن يكون لديها اختبارات عدّة, للمسارات الرئيسية و الردود الاستثنائية.
عند وصف حالة استخدام في طراز متطلبات, من المهم أكثر تعريف الشروط اللاحقة الخاصة به, أي الهدف الذي يتم إنجازه, عن الوصف بالتفصيل للإجراءات التي يتبعها المستخدم لتحقيق الهدف. على سبيل المثال, الشرط اللاحق لـ"طلب وجبة" يمكن أن يكون تحضير "المطعم" لوجبة لـ"العميل" أن "العميل" قد دفع. الشرط اللاحق هو المعيار الذي يجب أن تتحقق منه الاختبارات الخاصة بك.
اختبارات منفصلة أساسية على عبارات منفصلة للشرط اللاحق. على سبيل المثال، قم بإنشاء اختبارات منفصلة لإعلام المطعم بالطلب, ومن أجل أخذ الدفع من العميل. هذا الفصل له هذه الميزات:
التغييرات في الأوجه المختلفة من المتطلبات تحدث بشكل متكرر بشكل مستقل. بتقسيم الاختبارات إلى أوجه مختلفة بهذه الطريقة, يمكنك تسهيل تحديث الاختبارات عند تغيير المتطلبات.
إذا كان خطة التطوير تقوم بتنفيذ جانب واحد من حالة الاستخدام قبل آخر، يمكنك تمكين الاختبارات بشكل منفصل أثناء تقدم العمل في التطوير.
عندما تقوم بتصميم الاختبارات, افصل اختيار بيانات الاختبار عن التعليمات البرمجية أو البرنامج النصي الذي يحدد ما إذا كان قد تم تحقيق الشرط اللاحق. على سبيل المثال، اختبار لدالة حسابية بسيطة قد يكون: إدخال 4; تحقق من الإخراج هو 2. بدلاً من ذلك، تقوم بتصميم برنامج نصي كـ: اختر الإدخال; اضرب الإخراج في نفسه, ثم تحقق من أن الناتج هو الإدخال الأصلي. يتيح لك هذا النمط تغيير إدخالات الاختبار بدون تغيير النص الأساسي للاختبار.
ربط الاختبارات بحالات الاستخدام
إذا كنت تستخدم Test Manager لتصميم و تشغيل الاختبارات لديك ، يمكنك تنظيم الاختبارات ضمن متطلبات أو حالة استخدام أو عناصر عمل قصة مستخدم. يمكنك ربط عناصر العمل هذه بحالات الاستخدام في الطراز الخاص بك. يتيح لك ذلك سرعة تتبع تغييرات المتطلبات إلى الاختبارات, ويساعدك هذا في تعقب التقدم لكل حالة استخدام.
لربط اختبارات بحالة استخدام
في Test Manager, قم بإنشاء أحد المتطلبات ثم بإسناد مجموعة اختبار له. للتعرف على كيفية فعل ذلك، راجع إنشاء خطة اختبار باستخدام متطلبات أو قصص المستخدم.
المتطلب الذي تقوم بإنشائه هو عنصر عمل في Team Foundation Server. قد يكون قصة مستخدم, أو متطلبات, أو عنصر عمل حالة استخدام، استناداً إلى قالب العملية الذي يستخدمه مشروعك مع Team Foundation. لمزيد من المعلومات، راجع تخطيط المشاريع وتعقبها.
اربط عنصر عمل المتطلبات بواحد أو أكثر من حالات الاستخدام في الطراز الخاص بك.
في رسم تخطيطي لحالة استخدام ، انقر بزر الماوس الأيمن فوق حالة استخدام ثم انقر فوق ربط بعنصر عمل. لمزيد من المعلومات، راجع كيفية القيام بما يلي: ربط عناصر العمل بالطراز.
أضف إلى مجموعة الاختبار, حالات الاختبار التي تتحقق من حالات الاستخدام.
عادةً، كل قصة مستخدم أو عنصر عمل متطلبات سوف يرتبط بعدة حالات استخدام في الطراز الخاص بك, و كل حالة استخدام سترتبط بعدة قصص مستخدمين أو متطلبات. وهذا لأن كل قصة مستخدم أو متطلبات تغطي مجموعة من المهام التي تطوّر عدة حالات استخدام. على سبيل المثال، في تكرار مبكر للمشروع الخاص بك, قد تقوم بتطوير قصة المستخدم الأساسية التي فيها يختار العميل عناصر من كتالوج و يتم تسليمها له. في تكرار لاحق, القصة قد تكون أن المستخدم يدفع عند إكمال الطلب، و المورِّد يتلقى المال بعد إرسال السلع. كل قصة تضيف عبارة للشرط اللاحق لحالة الاستخدام "طلب سلع".
يمكنك إنشاء ارتباطات منفصلة من المتطلبات إلى عبارات الشرط اللاحق عن طريق كتابة هذه العبارات في تعليقات منفصلة على الرسم التخطيطي لحالة الاستخدام. يمكنك ربط كل تعليق بعنصر عمل للمتطلبات, و ربط التعليق بحالة الاستخدام على الرسم التخطيطي.
الاختبارات الأساسية على أنواع المتطلبات
الأنواع - أي الفئات ،و الواجهات, و التعدادات- من طراز المتطلبات تصف المفاهيم و العلاقات بما يتعلق بكيفية تفكير و اتصال المستخدمين حول الأعمال الخاصة بهم. هذا يستثني الأنواع المهتمة فقط بالتصميم الداخلي للنظام.
صمم اختباراتك حسب أنواع المتطلبات هذه. تساعدك هذه الممارسة على التأكد من أن عند مناقشة تغيير المتطلبات، فمن السهل ربط التغييرات بالتغييرات الضرورية في الاختبارات. هذا يجعل من الممكن مناقشة الاختبارات ونتائجها المقصودة مباشرة مع المستخدمين و المساهمين. هذا يعني أن احتياجات المستخدمين يجب أن تظل خارج عملية التطوير, و يتجنب التصميم الغير المقصود للاختبارات حول أخطاء محتملة في التصميم.
بالنسبة للاختبارات اليدوية, هذه الممارسة تتضمن التقيّد بالكلمات الخاصة بطراز المتطلبات في البرامج النصية للاختبار. بالنسبة للاختبارات التلقائية, هذه الممارسة تتضمن استخدام مخططات الفئة للمتطلبات كأساس للتعليمات البرمجية الخاصة بالاختبار الخاص بك, و إنشاء أساليب استرجاع قيمة و تحديث لربط طراز المتطلبات بالتعليمات البرمجية.
على سبيل المثال، طراز المتطلبات قد يتضمّن الأنواع "قائمة", و "عنصر قائمة", و "طلب", و اقترانات بينها. يمثل هذا الطراز المعلومات التي يتم تخزينها و التعامل معها عن طريق نظام طلب الوجبات، ولكن لا يمثل التعقيدات الخاصة بالتنفيذ. في النظام العامل ، قد يكون هناك عدة ملاحظات مختلفة لكل نوع في قواعد البيانات و في واجهات المستخدم و في API. في نظام موزَّع ، قد يكون هناك العديد من كل الاختلافات لمثيل مخزّن في أجزاء مختلفة من النظام في نفس الوقت.
لاختبار حالة استخدام مثل "إضافة عنصر إلى طلب" ، أسلوب الاختبار قد يتضمّن تعليمات برمجية مشابهة لهذا:
Order order = … ; // set up an order
// Store prior state:
int countBefore = order.MenuItems.Count;
// Perform use case:
MenuItem chosenItem = …; // choose an item
AddItemToOrder (chosenItem, order);
// Verify part of postcondition:
int countAfter = order.MenuItems.Count;
Assert (countAfter == countBefore = 1);
لاحظ أن أسلوب الاختبار هذا يستخدم الفئات الخاصة بطراز المتطلبات. يتم تحقيق من الاقترانات والسمات كخصائص .NET.
لجعل هذا يعمل, يجب تعريف خصائص الفئات كدالات للقراءة فقط أو دوال استرجاع قيمة, تقوم بالوصول إلى النظام لاسترداد معلومات حول الحالة الحالية. الأساليب التي تحاكي حالة استخدام مثل AddItemToOrder يجب أن تحرّك النظام خلال الـ API الخاص به أو من خلال طبقة أسفل واجهة المستخدم الخاصة به. مُنشئات كائنات الاختبار مثل Order و MenuItem يجب أيضا أن تحرّك النظام لإنشاء العناصر المكافئة داخل النظام.
العديد من دوال استرجاع القيمة و المحدّثات ستكون متوفرة بالفعل عبر الـ API العادي الخاص بالتطبيق. ولكن بعض الدالات الإضافيةقد تحتاج لكتابتها لتمكين الاختبارات. في بعض الأحيان تُعرَف دوال استرجاع القيمة و المحدّثات الإضافية باسم 'آلات الاختبار'. لأنها تعتمد على التصميم الداخلي للنظام, تكون مسؤولية مطوري النظام أن يوفروها, في حين أن المختبرين يقومون بكتابة التعليمات البرمجية الخاصة بالاختبارات من خلال مصطلحات طراز المتطلبات.
عند كتابة الاختبارات التلقائية, يمكنك استخدام "الاختبارات العامة" لالتفاف دوال استرجاع القيمة و المحدّثات. لمزيد من المعلومات، راجع إنشاء تلقائي اختبارات للوظائف استخدام اختبارات عام.
الاختبارات لقواعد العمل
بعض المتطلبات غير متعلقة بشكل مباشر بأي حالة استخدام واحدة. على سبيل المثال، العمل DinnerNow يسمح للعملاء بالاختيار من العديد من "القوائم", ولكن يتطلب أن في كل "طلب", كافة "العناصر" المختارة تكون من قائمة واحدة. يمكن التعبير عن قاعدة العمل هذه كثابت للاقترانات بين "الطلبات" و "القوائم" و "العناصر" في طراز فئة المتطلبات.
القاعدة الثابتة من هذا النوع لا تحكم فقط كافة حالات الاستخدام التي تم تعريفها حالياً ولكن أيضاً أي حالات استخدام أخرى سيتم تعريفها لاحقاً. لذلك، يكون مفيداً كتابتها بشكل منفصل عن أي حالة استخدام, و أن يتم اختبارها بشكل منفصل عن حالات الاستخدام.
يمكنك كتابة قاعدة عمل ثابتة كتعليق في رسم تخطيطي لفئة. لمزيد من المعلومات، راجع مخططات فئات UML: إرشادات.
يمكنك ربط الاختبارات بقاعدة عمل بواسطة ربط التعليق بمتطلب أو عنصر عمل قصة مستخدم، و الذي يمكنك ربطه بمجموعة اختبار في Test Manager. لمزيد من المعلومات، راجع إرفاق حالات اختبار بعناصر طراز.
الأداء و المتطلبات الأخرى لجودة الخدمة يمكن ذكرهم في التعليقات على حالة استخدام, أو نشاط, أو رسومات تخطيطية تسلسلية. يمكنك ربط هذه أيضاً بعناصر عمل متطلبات و مجموعات الاختبار الخاصة بها.
الرسومات التخطيطية للأنشطة و التسلسلات الخاصة بالاختبارات
إذا كانت المتطلبات أو طرازات الهندسة الخاصة بك تتضمن رسومات تخطيطية للأنشطة أو التسلسلات ، يمكنك كتابة الاختبارات التي تتبع المخططات مباشرة.
من المفيد في بعض الأحيان تصميم الاختبارات التي بشكل حيوي تختار مسارات مختلفة خلال الفروع و الحلقات في الرسم التخطيطي.
حاول أن تتحقق من حالة النظام بعد كل رسالة أو إجراء. قد يتطلب ذلك آلات إضافية.
اشتقاق اختبارات نظام فرعي من الطرازات
في تصميم عالي المستوى لنظام كبير, يمكنك تعريف مكونات أو أنظمة فرعية. هذه تمثّل الأجزاء التي يمكن تصميمها بشكل منفصل, أو الموجودة على أجهزة كمبيوتر مختلفة, أو الوحدات النمطية القابلة لإعادة الاستخدام التي يمكن أن إعادة تجميعها بعدة طرق. لمزيد من المعلومات، راجع مخططات مكونات UML: إرشادات.
يمكنك تطبيق على كل مكون رئيسي نفس المبادئ أثناء استخدامك للنظام الكامل. في مشروع كبير، يمكن لكلّ مكوّن أن يمتلك طراز المتطلبات الخاص به. في المشاريع الصغيرة, يمكن إنشاء طراز هندسي أو تصميم عالي المستوى لإظهار المكونات الرئيسية و التفاعلات الخاصة بها. لمزيد من المعلومات، راجع بناء نمذجة لبنية نظام البرامج..
في كلتا الحالتين، يمكنك إنشاء علاقة بين عناصر الطراز و اختبارات النظام الفرعي بنفس الطريقة كما تفعل بين طراز المتطلبات و اختبارات النظام.
عزل المكونات مع الواجهات المتوفرة و المطلوبة
يكون هذا مفيداً لتعريف كافة التبعيات التي لدى مكون على أجزاء أخرى من النظام أو خدمات الخارجية, و لتمثيل هذه كـ"واجهات مطلوبة". عادة هذه الممارسة تؤدي لبعض إعادة التصميم التي تترك المكون غير مزدوج بشكل أكبر و قابل للفصل بسهولة عن باقي التصميم.
ميزة من إلغاء الازدواجية هي أن المكون يمكن تنفيذه للاختبار بواسطة استبداله بالكائنات الوهمية للخدمات التي يستخدمها عادةً. هذه مكونات يتم إعدادها لأغراض الاختبار. المكوّن الوهمي يوفر الواجهة يتطلبها المكون الخاص بك, و يجيب على الاستعلامات ببيانات محاكاة. المكونات الوهمية تشكّل جزءًا من مفعّل اختبار كامل يمكنك توصيله بكافة الواجهات للمكون.
الفائدة من الاختبار الوهمي هي تطوير المكون الخاص بك عندما تكون المكونات الأخرى التي ستستخدمها لا تزال قيد التطوير.
المحافظة على العلاقات بين الاختبارات والطراز
في مشروع نموذجي يقوم بإجراء تكرار كل بضعة أسابيع, يتم عمل مراجعة المتطلبات بالقرب من بداية كل تكرار. الاجتماع يتناول الميزات التي يفترض تسليمها في التكرار التالي. يمكن استخدام طراز المتطلبات للمساعدة في مناقشة المفاهيم و السيناريوهات و تسلسلات الإجراءات التي سوف يتم تطويرها. المساهمين في العمل يقومون بتعيين أولويات, و المطورون يجرون تقديرات, و المختبرون يتأكدون من أن السلوك المتوقع لكل ميزة يتم التقاطه بشكل صحيح.
كتابة الاختبارات هي الطريقة الأكثر فعالية لتعريف متطلبات ، وهي أيضاً طريقة فعالة للتأكد من أن شخص ما لديه فهم واضح لما هو مطلوب. ومع ذلك، بينما كتابة الاختبارات تأخذ وقتا طويلا جداً بحيث لا يمكن القيام بها أثناء ورشة عمل المواصفات ، إنشاء طرازات يمكن إجراؤه بسرعة كبيرة.
من وجهة نظر الاختبار, طراز المتطلبات يمكن مشاهدته كاختصار لنسخة الاختبارات. ولذلك، فإنه من المهم الحفاظ على العلاقة بين الاختبارات والطراز خلال المشروع.
إرفاق حالات اختبار بعناصر طراز
إذا كان المشروع الخاص بك يستخدم Test Manager, يمكنك ربط الاختبارات بالعناصر الموجودة في الطراز الخاص بك. وهذا يتيح إمكانية البحث بسرعة عن الاختبارات التي تتأثر بتغيير في المتطلبات, و يساعدك على تعقب المدى الذي وصل إليه تحقيق المتطلبات.
يمكنك ربط الاختبارات بكافة أنواع العناصر. وفيما يلي بعض الأمثلة:
اربط حالة استخدام بالاختبارات التي تعمل عليها.
اكتب عبارات الشرط اللاحق لحالة استخدام, أو الهدف ، في تعليقات مرتبطة بحالة الاستخدام, ثم اربط الاختبارات بكل تعليق.
اكتب قواعد ثابتة في التعليقات على الرسومات التخطيطية للفئة أو الرسومات التخطيطية للأنشطة, وقم بربطها بالاختبارات.
اربط الاختبارات برسم تخطيطي للأنشطة, أو بأنشطة فردية.
اربط مجموعة اختبار بالمكون أو النظام الفرعي التي تختبره.
لربط الاختبارات بعنصر الطراز أو علاقة
في Test Manager, قم بإنشاء أحد المتطلبات ثم بإسناد مجموعة اختبار له. للتعرف على كيفية فعل ذلك، راجع إنشاء خطة اختبار باستخدام متطلبات أو قصص المستخدم.
المتطلب الذي تقوم بإنشائه هو عنصر عمل في Team Foundation Server. قد يكون قصة مستخدم, أو متطلبات, أو عنصر عمل حالة استخدام، استناداً إلى قالب العملية الذي يستخدمه مشروعك مع Team Foundation. لمزيد من المعلومات، راجع تخطيط المشاريع وتعقبها.
اربط عنصر عمل المتطلبات بواحد أو أكثر من العناصر الموجودة في الطراز الخاص بك.
في رسم تخطيطي للطراز, انقر يمينا فوق عنصر أو تعليق أو علاقة ثم انقر فوق ارتباط إلى عنصر عمل. لمزيد من المعلومات، راجع كيفية القيام بما يلي: ربط عناصر العمل بالطراز.
أضف إلى مجموعة الاختبار, حالات الاختبار التي تتحقق من المتطلبات المحددة في عنصر الطراز.