+ أفضل ، ولكن نسخة غلاف أقل مضحك عاجلاً أم آجلاً ، يأتي الجميع إلى AT. الموقف عندما يحدث هذا متأخراً أمر مفهوم ، ومتى يكون مبكرًا؟ وكيف نفهم ما هو ممكن بالفعل؟تستند المقالة إلى تجربة فريق واحد: سأخبرك عن متطلباتنا المسبقة وأسباب إدخال الاختبار التلقائي ، وما هي المعايير التي حددناها للاستعداد للتكنولوجيا المساعدة والأدوات التي نستخدمها في النهاية. المفسد: في النهاية ، بعض الحالات الناجحة وليست مع Xamarin.UITest.مقدمة عن المنتج. , , , , , . offline.
-.
ماذا تقول النظرية
النظر في نهج الأتمتة باستخدام هرم الاختبار كمثال. بصفتي مستويات الهرم ، سأقوم بإجراء أنواع الاختبارات التي نستخدمها. وهي اختبارات الوحدة واختبارات التكامل واختبارات نهاية إلى نهاية (E2E).
اختبارات الوحدة (اختبارات الوحدة) تتحقق من عمل أجزاء صغيرة فردية من النظام (الوظيفة ، الطريقة). إنها صغيرة ، تمر بسرعة ، لا تتطلب تكاليف تطوير وصيانة كبيرة.تختبر اختبارات التكامل تشغيل التطبيق مع المكونات الخارجية. على سبيل المثال ، مع قاعدة بيانات أو خدمات مختلفة. يستغرقون وقتًا أطول في كتابة الاختبارات ودعمها وفي الجري. لمثل هذه الاختبارات ، غالبًا ما تحتاج إلى تكوين ودعم نوع من البيئة. في هذه الحالة ، غالبًا ما يصبحون أكثر هشاشة ، لأنه تميل البيئة إلى الانهيار.اختبارات نهاية إلى نهاية التحقق من تشغيل النظام ككل ، ومحاكاة تصرفات المستخدم النهائي. غالبًا ما يصلون إلى النظام من خلال واجهة المستخدم: يضغطون على الأزرار كمستخدم ، ويملئون الحقول ، وما إلى ذلك. ولكن يمكن أيضًا استخدامها في أنظمة بدون واجهة. هذه الاختبارات أغلى بكثير من تلك المذكورة أعلاه ، لأنه تتطلب المزيد من الوقت لتطوير ودعم الاختبارات نفسها والبيئة بأكملها. بالإضافة إلى ذلك ، فهي هشة للغاية ، لأنها تتأثر بالتغييرات في أي جزء من النظام ، وقد يؤثر السلوك غير المتوقع للمحاكي أو المتصفح على نتيجة اختبار معين. كما أن مدة إجراء هذه الاختبارات أعلى بكثير من البقية: لتنفيذ أي إجراء فردي للمستخدم ، تحتاج إلى إجراء العديد من الاختبارات الإضافية. على سبيل المثال ، قم بتسجيل الدخول أو انتقل إلى عنصر القائمة المطلوب.وفقًا لمبدأ الهرم ، كلما كان الاختبار أسهل وأسرع وأرخص ، كلما كان يجب أن تكون بنسبة مئوية من إجمالي عدد الاختبارات. أولئك. لا يجب أن يتحقق الاختبار من خلال تعيين قيم مختلفة لحقل واحد (إلا إذا كنت بحاجة إلى التحقق من تشغيل واجهة المستخدم في هذه الحالات).لجميع هذه الأنواع من الاختبارات المعينة دور. في مرحلة ما من دورة حياة التطبيق ، تنشأ الحاجة إلى اختبار آلي أو آخر. يمكن لمنتجك القيام به بسهولة من خلال اختبارات الوحدة فقط ، ويمكن أن ينمو بسرعة إلى الحاجة إلى الاختبار الشامل. الشيء الرئيسي عند تخطيط الأتمتة هو فهم ما سيستفيد منه منتجك بالضبط حاليًا ، والذي من المحتمل أن تضيع الوقت.عند تنفيذ الأتمتة ، لا تنسى الاختبار اليدوي ، حتى مع وجود كمية كبيرة من الأتمتة ، سيكون هناك دائمًا أشياء يجب فحصها يدويًا. كحد أدنى ، وظائف جديدة ليس من المنطقي كتابة الاختبارات على الفور.لكن جميع الأتمتة ، في رأيي ، يجب أن تهدف في المقام الأول إلى تقليل حجم الاختبار اليدوي. وعند التخطيط للاختبار اليدوي ، يجدر النظر في الحالات المؤتمتة بالفعل.كيف يتم تنظيم اختبارات السيارات معنا؟
كل منتج على حدة لديه اختبارات وحدة ، تعمل على كل العلاقات العامة. هم مسؤولية المطورين.
تتحقق اختبارات التكامل من تفاعل خدمة الويب مع EDMS.تحاكي تشغيل تطبيق العميل. يتحولون إلى طرق خدمة الويب للحصول على وتعديل بيانات EDS.تشغيل بعد كل بناء من إصدار جديد من جانب الخادم.
تحاكي الاختبارات الشاملة أداء المستخدم النهائي. يضغطون على الأزرار في واجهة تطبيق الهاتف المحمول ، ويعمل التطبيق مع EDMS من خلال خدمة الويب.يقوم المختبرون الآن بإجراء اختبارات التكامل والاختبار الشامل.لماذا نحتاج إلى تطبيقات AT للجوال من طرف إلى طرف؟
قبل الشروع في الأتمتة ، يجدر النظر في المشكلة التي تريد حلها عن طريق تقديمها. ما لم يكن لديك أهداف محددة ، فلن تتمكن من توضيح للمشرف أو مالك المنتج سبب قضاء الوقت في الاختبارات الذاتية. سيكون من الصعب تقييم فوائد تنفيذها.لقد اختبرنا منذ فترة طويلة تطبيقات الهاتف المحمول يدويًا. على الرغم من أن هذا كان تطبيقًا بوظائف قليلة ، إلا أننا نجحنا في التعامل معه. كل شيء تم تطويره كان ± في منطقة واحدة ، ويمكن تنظيم الاختبار اليدوي بطريقة لاختبار جميع ميزات التطبيق بسرعة وسهولة.ولكن بعد مرور بعض الوقت ، بدأ التطبيق في النمو بميزات جديدة ، كانت مستقلة تمامًا وتتطلب المزيد من الاهتمام. كانت هناك مشكلة في الأخطاء في الوظيفة القديمة ، والتي لم نجدها إلا في المراحل الأخيرة من المشروع.لذلك ، كانت الأهداف الأولية لتقديم اختبارات واجهة المستخدم لتطبيقات الهاتف المحمول بالنسبة لنا:- تغطية حالات التطبيق الرئيسية ؛
- تقليل عدد الأخطاء في الانحدار قبل إطلاقه.
تحقيق الهدف الأول يجب أن يؤدي تلقائيا إلى تحقيق الهدف الثاني كما يجب أن تعثر الاختبارات المنتظمة للوظائف الأساسية طوال المشروع على أخطاء في المراحل المبكرة.بعد مرور بعض الوقت ، تمت إضافة هدف آخر - تقليل عدد اختبارات الانحدار اليدوي.ومتى حان الوقت لإدخال الأتمتة في الاختبار؟
قبل الشروع في أتمتة الاختبار ، يجب عليك تقييم جاهزية تطبيقك للأتمتة. وكذلك استعدادك لهذه العملية.وظائف مستقرة
لكي تتمتع AT بفرصة لتكون مفيدة ، يجب أن يكون للتطبيق وظائف ثابتة. ومن قيمتها تغطية الاختبارات الذاتية. خلاف ذلك ، سوف تقضي الكثير من الوقت والجهد في تحديث وتحديث الاختبارات نتيجة لتغييرات التطبيق.خطط التنمية
يجب تنفيذ الأتمتة فقط إذا كان لتطبيقك خطط تطوير مستقبلية للسنوات القادمة. لماذا الاختبارات التلقائية لتطبيق لا يتغير؟مصادر
يجب أن يكون لديك موارد لتطوير الاختبارات ، والأهم من ذلك ، لدعمهم الإضافي. أولئك. عند التخطيط لتنفيذ الأتمتة ، من المهم أن نفهم أن الموارد لن تكون مطلوبة فقط لكتابة الاختبارات. الاختبارات ستسقط بالتأكيد لسبب ما. يجب تحليل نتائج الجري واتخاذ الإجراءات اللازمة. بما فيها تغيير شيء ما في الاختبارات. حسنًا ، بالإضافة إلى الدعم ، لا تنسى الحاجة إلى تطويرها.كيف تقرر؟
عند التفكير في اختبارات واجهة المستخدم لتطبيقات الهاتف المحمول ، توصلنا على الفور إلى أرفف كبيرة مزودة بأجهزة أو مزارع يتم استئجار الأجهزة عليها. كانت هناك الكثير من المشكلات في الاختبارات بسبب الحاجة إلى التحقق من الأحجام ودقة الشاشة المختلفة. نعم ، ولم يكن هناك الكثير من الخبرة في التنمية. كان الأمر مخيفًا وأجبر على إبعاد الخطط.جاءت الأهداف التي تم وضعها في وقت سابق لإنقاذها ، وكان الهدف الرئيسي اختبارًا وظيفيًا. لذلك ، بدأنا صغير.نتيجة لذلك ، اختباراتنا:- تشغيل مرة واحدة في اليوم (هذا يكفي للعثور على مصدر المشكلة إذا حدث شيء ما) ؛
- تعمل محليًا على خوادمنا ؛
- على جهازين (iOS و Android) ؛
- بالنسبة إلى Android ، يوجد الآن حوالي 50 اختبارًا ، ويستغرق الجري حوالي ساعة (مع التجميع) ؛
- لنظام التشغيل iOS - حوالي 40 اختبارًا ، يستغرق الجري حوالي 30 دقيقة ؛
- تتم كتابة الاختبارات باستخدام Xamarin.UITest ؛
- يتم إطلاقها تلقائيًا من خلال البنيات في TFS ، في نفس المكان في TFS نراقب نتائج الجري.
قليلا عن Xamarin.UITest
هذا هو إطار للاختبار التلقائي لواجهة المستخدم للمشاريع على Xamarin.iOS و Xamarin.Android (يتم أيضًا الإعلان عن دعم Objective-C / Swift و Java). الاختبارات مكتوبة في C # باستخدام NUnit. يمكن دمج مشاريع المحتوى بسهولة.يعتمد مبدأ تشغيل الإطار على مكونين: البحث عن عنصر (استعلامات) وتنفيذ أي إجراءات معه (إجراءات) ، على سبيل المثال ، الضغط أو تنفيذ انتقاد.هنا ، على سبيل المثال ، اختبار يتحقق من عرض الخطأ عند إدخال تسجيل دخول غير صالح:public void ShowErrIncorrectLoginOrPassword_IfLoginIsWrong()
{
var wrongLogin = TestsSettings.UserLogin + "1";
app.EnterLoginAndPassword(wrongLogin, TestsSettings.UserPassword);
app.WaitForElement(Resources.Identifiers.ErrorMessage, "Login is incorrect, alert message wasn't shown.", TestsSettings.Delay);
Assert.AreEqual(CoreResources.ErrIncorrectLoginOrPassword, ErrorMessage);
}
private string ErrorMessage =>
app.Query(x => x.Marked(Resources.Identifiers.ErrorMessage)).First().Text;
طريقة إدخال بيانات الاعتماد المستخدمة فيه:public static void EnterLoginAndPassword(this AndroidApp app, string login, string password)
{
app.WaitForElement(Resources.Identifiers.LoginEdit, TestsSettings.Delay);
app.EnterText(Resources.Identifiers.LoginEdit, login);
app.EnterText(Resources.Identifiers.PasswordEdit, password);
app.Tap(Resources.Identifiers.LoginButton);
}
في هذا المثال ، يتم استخدام طرق الإطار القياسية - في انتظار عنصر ، وإدخال نص ، والنقر على عنصر.عند تطوير الاختبارات وتصحيحها ، من الملائم استخدام الأداة المساعدة المضمنة في وحدة التحكم REPL (read-Eval-print-loop) ، والتي تتيح لك عرض شجرة العناصر الموجودة الآن على الشاشة ، بالإضافة إلى تنفيذ طرق الإطار القياسية.لتكون غير متوقعة بالنسبة لنا
لم تؤدي معالجة عناصر الواجهة أحيانًا إلى ما كنا نتوقعه.على سبيل المثال ، عندما يتم فتح نافذة جديدة في تطبيق مع جزء في نفس النشاط ، يرى المستخدم هذه النافذة الجديدة فقط على الشاشة. ولكن في هذه الحالة سيكون هناك تلك العناصر في شجرة العناصر المرئية التي لا يراها المستخدم الآن بعينيه. سيكون البحث عن عنصر "غير مرئي" ناجحًا ، ويمكنك تنفيذ إجراء معه. هذه مجرد نقرة سيتم تنفيذها في النافذة التي يراها المستخدم. أولئك. في الواقع ، ستكون إيجابية كاذبة.قد تحتوي الشجرة على العديد من العناصر المتطابقة ؛ بشكل افتراضي ، سيتم تنفيذ الإجراء مع العنصر المناسب الأول للشجرة. وإذا وصلت في أحد الاختبارات إلى عنصر عبر ملصق ، ثم كان لديك عنصر بنفس التسمية في مكان ما ، فسيبدأ الاختبار في السقوط (أو ربما ليس إذا كان العنصر الذي تحتاجه هو الأول).كانت لدينا حالة واحدة عندما سقط اختبار مكتوب ومُصحح في أول إطلاق قتالي. لأن الاختبارات أجريت على جهاز بحجم شاشة مختلف. والعنصر الذي تم النقر عليه على هذا الجهاز ظهر تحت عنصر واجهة آخر.
كان مجلد البريد الصادر تحت زر إنشاء مهمة ، والنقر على المجلد في هذه الحالة أدى إلى النقر على الزر. هذه حالة مألوفة للمستخدم ، فسيقوم ببساطة بتمرير الشاشة. لكن في شجرة العناصر ، هذا التراكب غير مرئي.تسبب مثل هذه المشاكل إزعاجًا بسيطًا وتجعلك تفكر في بعض الاختبارات بعناية أكبر. وأحيانًا نلائم البيانات في قاعدة البيانات حتى لا يتداخل أي شيء مع الاختبار. بعد كل شيء ، الهدف في هذا المثال هو فتح مجلد ، وعدم التحقق من أن لا شيء يمنع فتحه.مفاجأة وخيبة أمل أخرى كانت عدم القدرة على تشغيل وتصحيح اختبارات iOS من Visual Studio لنظام التشغيل Windows. لم يتم تنفيذ هذه الميزة حتى الآن. يجب أن أعمل في الاستوديو لنظام MacOS.بعض نتائج الكابتن
تنفيذ الأتمتة إذا كان ذلك منطقيًا.اجعل اختباراتك بحد أدنى من التكوينات ، واجعلها تعمل يدويًا ومرة واحدة فقط في الشهر ، ولكن إذا كانت تحل مشاكلك وتساعدك - فلماذا لا؟حسنًا ، لا تنس مبدأ الهرم.