📕 👨🏼‍🎤 📿 بدلاً من 100 تطبيق تم إطلاقه - اختبار آلي واحد ، أو كيفية إنقاذ مهندس ضمان الجودة لمدة 20 عامًا ♌️ 🧑🏾‍🤝‍🧑🏽 🎩

مرحبا بالجميع ، اسمي يفغيني ديميدينكو. في السنوات القليلة الماضية ، كنت أقوم بتطوير نظام اختبار لعبة آلي في Pixonic. أردت اليوم أن أشارك خبرتنا في تطوير ودعم واستخدام مثل هذا النظام في مشروع War Robots.

بادئ ذي بدء ، سنكتشف ما نقوم به تلقائيًا مع هذا النظام.

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

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

من بين المنصات ، نستخدم Android و iOS - فقط 12 جهازًا في المنتزه. يشارك اثنان من المبرمجين في تطوير ودعم النظام ، ومهندس ضمان الجودة هو كتابة الاختبارات وتحليلها.

أما بالنسبة لمجموعة البرامج ، فإننا نستخدم NUnit في قاعدة البيانات الخاصة بنا ، ولكن ليس لاختبارات الوحدة ، ولكن لاختبارات التكامل والنظام. من أجل اللعب الأساسي وبناء اختبارات التحقق ، نستخدم الحل المدمج من Unity - Unity Test Tools. لكتابة وتحليل التقارير بعد هذه الاختبارات ، يتم استخدام تقرير اختبار Allure Test من Yandex ، بالإضافة إلى TeamCity - كنظام للتكامل المستمر لبناء التطبيق ونشر الخادم وتشغيل الاختبارات. نستخدم مستودع Nexus وقاعدة بيانات PostgreSQL لتخزين القطع الأثرية.

كيف تقوم بإنشاء الاختبارات وتحليلها وتشغيلها

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

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

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

إذن ماذا حدث لتلك الـ 3٪ من الاختبارات التي فشلت؟

نفتح اختبارًا محددًا ونرى رسالة تفيد بحدوث خطأ أثناء مطابقة لقطات الشاشة.

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

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

هذا يبدوا جيدا. لماذا كل هذا ضروري؟

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

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

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

ما الأدوات التي نستخدمها

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

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

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

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

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

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

بعد الابتكارات والمراجعات المقبلة ، بدأت بنية النظام بأكمله تبدو على النحو التالي.

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

نظرًا لأن الاختبارات والتطبيق نفسه يعملان على أجهزة مختلفة فعليًا - على هاتف محمول و Mac mini - فقد احتجنا إلى تنفيذ الاتصال بين إطار عملنا ، War Robots API و Unity API. لقد أضفنا خادم UDP صغير إلى التطبيق ، والذي يتلقى أوامر من إطار العمل ويتواصل مع واجهة برمجة تطبيقات التطبيق و Unity من خلال المعالجات.

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

نصائح لاختيار الأجهزة

بشكل منفصل ، أريد الانتباه إلى اختيار الأجهزة للاختبار.

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

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

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

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

بعد الانتهاء من الاختبارات ، نقوم بإنشاء تقرير جاذبية ، والذي يتضمن جميع القطع الأثرية التي تم إنشاؤها أثناء الاختبار.

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

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

نجمع أيضًا قائمة بالعمليات ، وطاقة البطارية ، ودرجة الحرارة ، وعمومًا كل ما يمكننا الوصول إليه.

ما هي لقطات الشاشة ومقاطع الفيديو الجيدة

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

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

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

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

ماذا يمكن لنظامنا أن يفعل؟

منذ بعض الوقت ، من قسم اختبار ضمان الجودة ، تلقينا طلبًا لتطوير أداة لجمع المقاييس أثناء اختبارات التشغيل اليدوية.

لما هذا؟

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

عمل النظام الذي طورناه على النحو التالي. أطلق مهندس ضمان الجودة لعبة War Robots على الجهاز ، وشغّل سجل جلسة playbench - التناظرية الخاصة بنطاق اللعبة - لعب playtest ، ثم نقر على "إنهاء جلسة playbench" ، وتم حفظ التقرير الذي تم إنشاؤه في المستودع ، وبعد ذلك يمكن للمهندس الذي يحتوي على البيانات الخاصة بهذا الاختبار أن يصل إلى عمله الآلات وانظر التقرير: ما هي عمليات السحب على FPS ، ما استهلاك الذاكرة ، ما كان يحدث على الجهاز.

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

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

وميزات مفيدة أخرى

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

واحدة من أكثر الحالات المثيرة للاهتمام التي ظهرت معنا مؤخرًا هي المعايير أثناء المعارك مع الروبوتات.

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

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

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

بدلا من الاستنتاج

في النهاية ، أود أن ألفت الانتباه إلى المشاكل التي لدينا والتي نعلم عنها والتي نود حلها في المقام الأول.

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

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

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

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

بدلاً من 100 تطبيق تم إطلاقه - اختبار آلي واحد ، أو كيفية إنقاذ مهندس ضمان الجودة لمدة 20 عامًا