قراءة مقالات حول موضوع اختبار الويب ، موضوعان تلوح في الأفق بشكل مشروط: 1) الاختبار اليدوي ينفد ، الاختبارات التلقائية (يشار إليها فيما يلي باسم autotests هي Selenium UI و REST اختبارات) هي كل شيء لدينا ؛ 2) الاختبار التلقائي ليس حلا سحريا ؛ الاختبار اليدوي أمر لا غنى عنه. في الوقت نفسه ، من المقالات هناك اتجاه نحو زيادة في متطلبات جودة البرمجيات وسرعة تطوير المنتج. Wrike هو الحال فقط عندما تكون هذه المتطلبات حرجة.
عمر المنتج بالفعل 12 عامًا ، لكنه لا يزال ينمو بشكل نشط. عمليات النشر تحدث مرة واحدة في اليوم ، وأحيانًا مرتين. لذلك ، من المهم للغاية بالنسبة لنا أن يتم الانحدار بشكل حصري في الاختبارات الذاتية. ومع ذلك ، يوجد في Wrike (في الشركة) أكثر من 30 فريق سكروم ، وموظفو فريق الأتمتة ليسوا مطاطيين. في مثل هذه الظروف ، فإن توقع التشغيل الآلي للسيناريوهات اليدوية في أحسن الأحوال ، واحد أو اثنين من سباقات السرعة ليس خيارًا. تقول تجربة شركتنا أن المختبر اليدوي يمكنه كتابة الاختبارات الذاتية بشكل مستقل ، مع مراعاة بعض الفروق الدقيقة. في المقال سوف أخبرهم ولماذا ، في رأيي ، هذه القدرة لا تساعد فقط على مواكبة الاتجاهات ، ولكن ستكون أيضًا مفيدة للاختبار نفسه.
العملية القياسية
ما هي العملية التي اعتادت عليها فرق كثيرة؟ إنها تختلف من حالة إلى أخرى ، ولكن الميزات الشائعة هي نفسها تقريبا. هناك أقسام للاختبار التلقائي واليدوي. يمكن توزيع أدوات اختبار يدوية بين أوامر scrum. في هذه الحالة ، لا ترتبط الأتمتة ، كقاعدة عامة ، بفريق معين.
عند العمل باستخدام وظائف جديدة ، يقوم المختبر بإنشاء نصوص اختبار ، يقوم بعضها بتحديدها بطريقة محددة مسبقًا للأتمتة. بالإضافة إلى ذلك ، إذا كانت هناك حالات تم فيها إجراء التعديلات بالفعل ، فستتم الإشارة إليها أيضًا لتحديث الرمز. ثم يتم نقل الاختبارات ملحوظ إلى قسم الأتمتة. يتولى فريق من مهندسي الأتمتة مهمة إصلاح الاختبارات التلقائية الحالية والكتابة في واحدة من السباقات التالية. بالإضافة إلى سيناريوهات اختبار البرمجة ، تتضمن مهام الأتمتة تشغيل الاختبارات التلقائية وتحليل النتائج بالإضافة إلى دعم وتطوير مشروع الاختبار. اتضح أن قسم الأتمتة يعمل كمنفذ خارجي ، وأن المختبرين اليدويين هم نوع من العملاء.
بالإضافة إلى ذلك ، يقضي العميل وقتًا في تجميع المواصفات التفصيلية والدقيقة ، ويناقش بشكل دوري طرق التنفيذ واختيار الاختبارات اللازمة. هناك أيضا مخاطر أنه خلال غياب autotests قد يتم تخطي الأخطاء. لا تنس أن هناك طبقة من المشاكل الفنية التي لا يمكن حلها إلا في الاختبارات التلقائية ، والتي من شأنها توفير الكثير من الوقت. سيتعين التحقق من هذه المهام بأيدي في الجزء الذي لا يزال التنفيذ التلقائي فيه مفقودًا.
إن المقاول ، الذي لم يكن غارقًا جدًا في الوظيفة التي شارك فيها الفريق ، سيستغرق بعض الوقت ليغمر سطحيًا في المهمة وفي إدراك TOR. في الوقت نفسه ، من المحتمل ألا يترجم الاختبار بدقة إلى الشفرة ، والذي بسببه لن يتحقق مما نود. وفقا لذلك ، يتم تقليل كفاءة قاعدة الاختبار.
يتمتع فريق الأتمتة ، كونه المساهم الوحيد في مشروع الاختبار ، بالسيطرة الكاملة على قاعدة الشفرة الخاصة به ، مما يسمح بتطويره بسهولة في أي اتجاه. ومع ذلك ، فإن الوقت اللازم لذلك يصبح غير كاف بسبب زيادة الحمل من الفرق الأخرى. يمكن حل المشكلة عن طريق توسيع عدد الموظفين ، ولكن بعد ذلك سوف تتجاوز تكلفة التشغيل الآلي فعاليتها. حتى إذا قمت بإزالة جزء من الحمل ، وإعطاء المختبرين اليدويين الفرصة لإجراء الاختبارات وتحليل الاختبارات الساقطة ، فلن يحقق ذلك النتيجة الصحيحة. نظرًا لعدم امتلاكهم لأدوات اختبارات تصحيح الأخطاء ، فقد لا يفهمون أن الاختبار تعطل بسبب تغيير في xpath وما إلى ذلك.
وفقًا لذلك ، في المخرجات ، نتوصل إلى أن الاختبارات التلقائية مع هذا المخطط لا تواكب نمو المنتج ، مما يؤدي إلى تغطية ضعيفة للرمز. بسبب التفسير غير الدقيق للمعارف التقليدية ، قد تتخطى الاختبارات الأخطاء. عند انتهاء صلاحيتها لفترة طويلة ، لا يتم إصلاح الحالات المتساقطة على الفور ، ومن الصعب على المختبرين اليدويين أن يخبروا على الفور أي جزء من النظام مغطى جيدًا بالأتمتة. تصبح الاختبارات التلقائية نوعًا من العلبة السوداء ، والتي يختبرها المختبرون. وبالتالي ، يتزايد عدد عمليات الفحص اليدوي غير الضرورية ، وتمتد شروط المهام ، وتنخفض الجودة على المدى الطويل.
يمكنك التعامل مع أوجه القصور هذه ، ولكن كلما كان المنتج والشركة أكبر ، كلما كان الألم أكثر للمشاركين في العملية ، والأهم من ذلك ، أنه من الصعب اتباع اتجاه زيادة السرعة وتحسين الجودة. يصبح المختبر نفسه رهينة للروتين ولا يبقى عمليًا في تطور الوقت.
طريقة الضرب
لذا ، كيف يعمل على مثال الفريق الذي أعمل فيه. هناك فرق الاختبار التلقائي واليدوي. البيانات الأولية لا تزال متشابهة ، ولكن بعد ذلك تبدأ الاختلافات. يتم توزيع اختبار اليدوي بين فرق سكروم. كل فريق سكروم لديه autotester الخاصة به. في بعض الأحيان ، يمكن تخصيصها ليس لفريق واحد ولكن لفريقين ، إذا سمح الحمل بذلك.
عند العمل مع وظائف جديدة ، يكتب المختبر قوائم التحقق ، والتي يقوم بعدها بإجراء اختبارات يدوية. الحد الأدنى المطلوب من الاختبارات من قائمة المراجعة هذه تلقائي. يكتب المختبر نفسه هذه الاختبارات التلقائية في الوقت الذي تكون فيه الميزة قيد التطوير أو الاختبار. علاوة على ذلك ، يتم إعطاء رمز مكتوب للمراجع للمراجعة. مع استثناءات نادرة ، لا يمكن إصدار مهمة بدون اختبارات تلقائية.
بالطبع ، ليس هناك حاجة في Wrike لكتابة الاختبارات الذاتية بواسطة المختبرين اليدويين. يبقى هذا حسب تقدير الفريق. يمكنك إعطاء كل شيء إلى الأتمتة. يمكنك قصر نفسك على إصلاح اختبارات مقطوعة و / أو كتابة اختبارات جديدة عن طريق القياس ، وتفويض مهام أكثر تعقيدًا (إنشاء اختبارات جديدة أو توسيع مقابض النهاية الخلفية القديمة أو كائن الصفحة أو خطوات الاختبار والفئات) إلى أداة أتمتة مخصصة. كل هذا يتوقف عليك ، لكن من الغباء أن تفوت تلك المزايا التي تقدمها الكتابة المستقلة للاختبارات التلقائية.
يعتمد الانحدار بأكمله على الاختبارات التلقائية ، وتشمل مسؤوليات الاختبار اليدوي تشغيل وتحليل حالات فشل الاختبار التلقائي. لكل فرع يعمل عليه الفريق ، يجرون اختبارات تلقائية كضامن أولي ونهائي للجودة. لذلك ، من الأسهل بالنسبة لأولئك الذين يكتبون الاختبارات الذاتية أن يفهموا سبب تعطل الاختبار الذي يجري على فرعهم. في بعض الأحيان تكون أدوات مثل إعادة التشغيل والتقرير في
Allure كافية حقًا ، حيث يمكنك فهم سبب تعطل الاختبار من لقطة الشاشة والخطوات. ومع ذلك ، غالبًا ما يكون أفضل مساعد هو القدرة على إجراء الاختبارات محليًا ، والتلاعب بالخطوات أو تشغيلها في وضع التصحيح ، انظر xpath المتوقعة والحقيقية. بدون خبرة في العمل في مشروع اختبار ، سيستغرق ذلك الكثير من الوقت ، أو سيكون من الضروري صرف أداة التشغيل الآلي المخصصة.
بالإضافة إلى ذلك ، فإن الكتابة المستقلة للاختبارات التلقائية تجعل من الممكن تشغيلها حتى قبل إصدار الميزة. يعرف المختبر دائمًا درجة تغطية الجزء الخاص به من النظام ، والمهام الفنية لا تتم إلا في الاختبارات التلقائية ، مما يوفر وقت الفريق وموارده بشكل كبير. الاختبارات نفسها ذات صلة دائمًا ، حيث يتم ضبط الأعطال قبل الإصدار. يتم تصحيح الاختبارات المكسورة على الفور في نفس الفرع حيث تتم كتابة اختبارات جديدة.
يتم اختبار أداة الاختبار اليدوي إلى أقصى حد في مهمة الفريق ، وبالتالي ، يتم تحديد الحد الأدنى الضروري للاختبارات التلقائية ، والذي يغطي معظم الحالات. تتم مراجعة العينة عدة مرات أثناء الاختبار ، كما هو الحال أثناء الفحص اليدوي ، تتم دراسة الوظيفة بمزيد من التفصيل مع كافة الفروق الدقيقة. تبعا لذلك ، فإن كفاءة مثل هذه الاختبارات في تزايد. تتيح لك عمليات الاختبار التلقائي للكتابة فهم بنية التطبيق والمكونات المستخدمة وتفاعل الواجهة الأمامية مع الواجهة الخلفية بشكل أفضل. في النهاية ، تساعد هذه المعرفة على اتباع نهج أكثر وعياً وفعالية لاختبار المنتجات. على سبيل المثال ، إذا قام بعض الأوامر بإجراء تغييرات على المكون العام ، فمن الأرجح أن تعرف مقدمًا ما إذا كان نطاقك سيتأثر أم لا ، حيث أنك عندما تتعامل مع xpath ستفهم المكونات التي يتم استخدامها في الجزء الخاص بك من التطبيق.
يمكن القول أن كتابة الاختبارات الذاتية تستغرق وقتًا. نعم ، سيتم إصدار المهام بعد يوم إلى ثلاثة أيام من المعتاد ، ولكن على المدى الطويل ، تؤتي ثمارها. علاوة على ذلك ، هناك طرق الأمثلية. على سبيل المثال ، أثناء تطوير إحدى الميزات ، يمكنك إعداد قوائم التحقق اللازمة وإجراء فراغات للاختبارات ، وبالتالي توفير الوقت. إذا كان لديك إطار عمل جاهز ، فمن الممكن إضافة أو إصلاح xpaths الموجودة ، إذا لزم الأمر ، قم بإنشاء كائن صفحة جديد أو ضبط الخطوات. بعد ذلك ، في مرحلة كتابة الاختبارات التلقائية ، بعد الاختبارات اليدوية ، تحتاج فقط إلى إضافة كتل التعليمات البرمجية بالترتيب الصحيح.
بفضل الإطار الذي طوره فريق الأتمتة ، تمثل كتابة الاختبارات التلقائية للجزء الأكبر رمز تجميع من كتل - مثل Lego. تتيح لك هذه البساطة أن تتكيف بسرعة مع المختبرين اليدويين وتبدأ في كتابة الاختبارات الذاتية عن طريق القياس مع الاختبارات الحالية. من تجربتي الخاصة ، سأقول إن الأمر استغرق حوالي أسبوعين من اللحظة التي ذهبت فيها إلى العمل في Wrike حتى أول اختبارات تلقائية كتبت ، مع مهام أخرى.
تتم مراقبة جودة الاختبارات الآلية المكتوبة من خلال مراجعة الكود. لا يوجد فرع اختبار واحد يدخل في الإصدار دون مراجعة. هذه لحظة تدريب جيدة ، حيث يقوم المختبر باستخلاص معلومات مفيدة من التعليقات على الكود الخاص به ويعزز تجربة الحلول الجيدة: على سبيل المثال ، يدير مكتبة Java القياسية بشكل أكثر كفاءة أو يعرّف xpath بشكل أكثر دقة. في المرة القادمة ، سيكون من الواضح أفضل طريقة للعمل مع موقف معين.
بطبيعة الحال ، فإن تطوير مشروع اختبار وإطار عمل وتدريب المختبرين اليدويين يستهلكون موارد الأتمتة ، لا سيما في المرحلة الأولية ، لكن يبدو لي أن هذه الجهود تؤتي ثمارها بالكامل. لدينا العديد من التحسينات في بيئة الاختبار الآلي التي تجعل عملنا أسهل. يتمتع المنتج نفسه بتغطية جيدة ، بحيث يمكنك الاعتماد على الانحدار. هذا يساعد على تسريع عملية طرح الميزات على بيئة المستخدم ويحمي إلى حد كبير أعصاب المختبرين.
وفقًا لتجربة فريقنا ، تعد هذه واحدة من أفضل العمليات للعمل مع منتج كبير سريع التطور في شركة كبيرة. علاوة على ذلك ، فإنه يتماشى مع الاتجاهات الحالية في تحسين جودة البرمجيات وسرعة تسليمها للمستخدمين. يتخلص المختبر من الناحية العملية من الروتين ويتطور في عدة اتجاهات وينظر إلى التطبيق من عدة زوايا.
باختصار عن الشيء الرئيسي
للراحة ، سأسلط الضوء على مزايا الاختبار اليدوي في مكان واحد ، بحيث يكون من السهل إدراك أهميته بشكل فردي أو كليًا:
- يتم تكوين صورة أكثر اكتمالا حول مستوى وجودة التشغيل الآلي للنطاقات الخاصة بك ؛
- تتوفر الاختبارات التلقائية قبل إصدار الميزة ، مما يجعل من الممكن التحقق من جودتها بسرعة في أي وقت ؛
- تزداد كفاءة الاختبارات الذاتية ، كما تزداد كفاءة الاختبار بشكل عام ؛
- يجري تشكيل نهج أكثر استنارة وفعالية للاختبار ؛
- التخلص من الانحدار اليدوي الرتيب واختبارات التقييم الطويلة ؛
- نمو الشخصية وتنمية الكفاءات.
لتلخيص
بالطبع ، لا يوجد رصاصة فضية. ما هو مناسب لشركة واحدة قد يرفض بشدة من قبل شركة أخرى. في حالة Wrike ، ينمو المنتج سريعًا للغاية ولا يوجد وقت للانحدارات اليدوية الطويلة والاختبارات التقييمية. لدينا هذا الدور الذي تؤديه الاختبارات التلقائية ، والتي تغطي تقريبا كل مكون من مكونات المنتج الضخم. يساعد ذلك في الحفاظ على الجودة وتحسين الموارد وتوفير وظائف جديدة للمستخدمين بشكل أسرع.
الأخبار السيئة هي أنه لا يمكن الاستغناء عن الأخطاء ، ولكن في حالتنا ، غالباً ما تكون هذه بعض الحالات الشديدة. والخبر السار هو أن الأخطاء أثناء إصلاحات تمت متضخمة أيضًا مع الاختبارات التلقائية.
لسبب ما ، أصبح من الشائع جدًا في المجتمع أن فكرة كتابة الاختبارات التلقائية من قِبل المختبرين اليدويين مرفوضة. هناك حجة الأكثر شعبية من جانب المختبرين: "إنهم لا يدفعون مقابل ذلك" و "لدينا بالفعل ما يكفي من العمل". بالنسبة لي شخصيًا ، تنقلب كلتا الوسيطتين عندما أدرك أنه يمكنني تشغيل الاختبارات الذاتية في وقت تطوير الميزة وفهمها في وقت قصير كيف تعمل بشكل صحيح. الأمر يستحق الكثير. مهمتنا هي تحسين جودة المنتج والحفاظ عليها ، بحيث يتم استخدام كل فرصة لتيسيره. منذ اللحظة التي بدأت في كتابة الاختبارات التلقائية ، أصبح الروتين في عملي أقل وعيًا.
ملحوظة: تعكس هذه المقالة فقط تجربة فريقنا وقد لا تتوافق مع معتقداتك. لذلك ، سأكون سعيدًا بمعرفة الأساليب التي توجهك في عملك. سأكون سعيدًا أيضًا بالنقد الصحي وفرصة مناقشة المقال في التعليقات.