TestRail - الإعدادات الفردية للمشروع

مقدمة

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

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

تبرير الخطة (ما سيتم تنفيذه)

  1. المتطلبات العامة

    1. يجب أن تكون الحالة قادرة على اجتياز أي شخص على الإطلاق

    2. يجب أن تظل الحالات ذات صلة لأطول فترة ممكنة

    3. يجب أن تغطي الحالات وظائف تطبيقات الهاتف المحمول بعناية قدر الإمكان إلى الحد الذي لا يتعارض فيه مع النقطتين الأوليين.

  2. الفصل في TestCase و TestSenario

  3. تشكيل سريع من TestRun بأنواعه المختلفة

    1. التدخين

    2. تراجع

    3. اختبار التأثير ، إلخ.

  4. تحسين دعم الحالة

    1. رفض لقطات الشاشة "الميتة" المشفرة والانتقال إلى "البيانات المنقولة"

المتطلبات الأساسية

سوف تحتاج إلى وصول المسؤول لتعديل الحقول

اختيار نوع المشروع

هناك ثلاثة أنواع من المشاريع للاختيار من بينها:

TestRail - الإعدادات الفردية للمشروع

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

إضافة الحقول لعرض قائمة حالات الاختبار

دعنا نضيف حقلاً لعرض حالات الاختبار ذات الأولوية:

TestRail - الإعدادات الفردية للمشروع

يمكنك أيضًا إضافة حقول أخرى.

تحديد الحقول والعلامات لحالة الاختبار

فتح قائمة الإعدادات:

TestRail - الإعدادات الفردية للمشروع

نحتاج هذه المجالات:

حقل "الملخص" (عنوان حالة الاختبار)

TestRail - الإعدادات الفردية للمشروع

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

سيناريو الاختبار:

مثال: TestScenario - حالة الاستخدام الرئيسية لتطبيق الهاتف المحمول

حالة اختبار:

مثال: الشاشة الرئيسية - قسم التخويل - إدخال تسجيل الدخول

في المجموع ، نرى في ملخص الحالة فهمًا كلاسيكيًا: "ماذا وأين ومتى". نحن أيضًا نفصل بصريًا نصوص الاختبار عالية المستوى وحالات الاختبار ذات المستوى المنخفض في الشكل الأنسب للأتمتة.

علامة "StartScreen" (الشاشة التي يبدأ منها TestScenario ، كما يمكن للعديد من حالات الاختبار أن تلمس الشاشات المجاورة)

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

قم بإنشاء حقل جديد:

TestRail - الإعدادات الفردية للمشروع

املأ مكونات الحقل الجديد:

TestRail - الإعدادات الفردية للمشروع

في هذه الحالة ، نقوم بإنشاء حقل تحديد من قائمة القيم. أدخل قيم هذا الحقل:

TestRail - الإعدادات الفردية للمشروع

لاحظ أن قيم المعرف لا تبدأ من واحد وليست متتالية. لماذا يتم هذا؟ الحقيقة هي أنه إذا سجلنا حالات الاختبار بالمعرف الذي تم إدخاله ،

TestRail - الإعدادات الفردية للمشروع

وبعد ذلك نحتاج إلى إنشاء شاشة ثالثة بين الشاشتين الحاليتين ،

TestRail - الإعدادات الفردية للمشروع

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

ضع علامة على "شاشة" (اسم الشاشة التي تؤثر على TestCase)

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

مثال: الشاشة الرئيسية ، MapScreen ، PayScreen ، إلخ.

TestRail - الإعدادات الفردية للمشروع

حقل MovableData (رابط إلى قاعدة بيانات الوكيل ببيانات اختبار قابلة للتغيير)

بعد ذلك ، سنحاول حل مشكلة الحفاظ على أهمية البيانات في حالات الاختبار:

  1. روابط إلى التخطيطات الفعلية (هذا أفضل بكثير من التقاط لقطات شاشة ميتة)

  2. الخطوات النموذجية لشاشة حالة الاختبار

  3. استعلامات SQL

  4. روابط للبيانات الخارجية والبيانات الأخرى

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

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

إلى ورقة Google يمكن استخدام استعلامات SQL. مثال:

=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")

إلى Excel يمكنك إعداد وحدات ماكرو مناسبة للبحث الفوري. (ترشيح) مثال رابط.

في الواقع ، الفكرة ليست جديدة وهي موصوفة في الكتاب الأول للمختبِر "Testing dot com". (المؤلف Savin Roman) لقد قمنا فقط بدمج الأساليب التي اقترحها Roman Savin في TestRail. للقيام بذلك ، قم بإنشاء حقل به ارتباط إلى الملف الذي تم إنشاؤه:

TestRail - الإعدادات الفردية للمشروع

املأ القيمة الافتراضية للارتباط بحيث يوجد ارتباط بالفعل في كل حالة اختبار جديدة:

TestRail - الإعدادات الفردية للمشروع

إذا تغير موقع الملف الخارجي (نحن نوفر أي قوة قاهرة) ، فيمكنك بسهولة تغيير حقل واحد أو أكثر في جميع حالات الاختبار مرة واحدة:

TestRail - الإعدادات الفردية للمشروعTestRail - الإعدادات الفردية للمشروع

"الأوصاف" الميدانية (وصف أو فكرة عن حالة الاختبار ، تعليمات نموذجية)

ما قد تحتاجه: في حقل النص هذا ، سنضع وصفًا موجزًا ​​لحالة الاختبار والتعليمات النموذجية.

على سبيل المثال: يتم تمييز جميع بيانات الاختبار (التخطيطات الفعلية واستخدام الأدوات والبيانات الأخرى) من حالة الاختبار هذه بروابط {...} وتقع في MovableData. رابط إلى MovableData في الحقل المقابل في الأعلى.

TestRail - الإعدادات الفردية للمشروع

علامة "المكون" (مكون تطبيق الجوال)

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

أمثلة على المكونات: GooglePay ، الطلب ، المستخدمون ، الخريطة ، التفويض ، إلخ.

TestRail - الإعدادات الفردية للمشروع

علامة "TAG" (علامات أخرى للتصفية)

وضع علامات على حالة الاختبار بالملصقات من أجل التصفية العشوائية. 

مفيد جدًا لـ: 

  1. تجميع سريع لـ TestRun لمختلف المهام النموذجية: الدخان ، الانحدار ، إلخ.

  2. ما إذا كانت الاختبارات ستكون مؤتمتة أم مؤتمتة بالفعل

  3. أي علامات أخرى

مثال: دخان ، آلي ، WhiteLabel ، ForDelete ، إلخ.

TestRail - الإعدادات الفردية للمشروعTestRail - الإعدادات الفردية للمشروع

ضبط ترتيب عرض الحقول في حالة الاختبار

لقد أنشأنا الكثير من الحقول الجديدة ، حان الوقت لترتيبها بترتيب مناسب:

TestRail - الإعدادات الفردية للمشروع

إنشاء TestRun

سننشئ الآن اختبارًا جديدًا للحالات ذات الصلة لاختبار الدخان في ثلاث نقرات:

TestRail - الإعدادات الفردية للمشروع

نصائح أخرى

  1. إذا كان هناك العديد من المشاريع في TestRail ، فلا تنس إنشاء حقول جديدة فقط لمشروعك ، وإلا فسيتفاجأ الزملاء من الفرق المجاورة بظهور حقول جديدة غير عادية. الإغماء المحلي ممكن.

TestRail - الإعدادات الفردية للمشروع

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

TestRail - الإعدادات الفردية للمشروع

3. يمكن تقاسم الحسابات. على سبيل المثال: مسؤول واحد ، عدة مستخدمين.

اختتام

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

المراجع:

موقع ويب بائع TestRail

الكتاب: "Testing .COM" (المؤلف Roman Savin)

شكرا جزيلا لكم على اهتمامكم!

المصدر: www.habr.com

إضافة تعليق