استمرار سلسلة الملخصات مع HL2018.
ساعدني رجال Badoo (Vladimir
Yants vyants و Nikolay Krapivny) في التحقق من هذا الملخص ، والذي أشكرك فيه كثيرًا. آمل أن يكون لهذا تأثير إيجابي على جودة رسالة التقرير.
ملامح عملية التطوير:
لا تنتهي مسؤولية المطور بإصدار الواجهة الخلفية. وهو مسؤول قبل التنفيذ على المنصات.
يوجد اختبار يدوي ، ولكن العميل لم يكن جاهزًا في وقت الإصدار ويتم تحريره بتأخير (غير متوقع). لا نعرف غالبًا متى سيبدأ العملاء في تنفيذه. في بعض الأحيان (في كثير من الأحيان) تبدأ الميزات في العمل بعد وقت طويل. لذلك ، فإن الاختبار بيديك أمر صعب وليس كل شيء ممكنًا. لذلك ، هناك حاجة autotests.
الاختبارات
اختبارات الوحدة
كتب في phpunit.
اختبر وحدة صغيرة. لا يذهبون إلى قاعدة البيانات أو إلى الخدمات (لا يجب أن يتفاعلوا مع أي شيء).
الإرث لا يزال لديه ويعقد عملية الاختبار.
لقد قاموا بتطوير مكتبة softMocks - جميع الروابط تشمل / تتطلب وتستبدلها بأخرى تم تغييرها.
يمكنك إنهاء أي طرق: ثابتة ، خاصة ، نهائية.
المكتبة متاحة في المصدر المفتوح.
المشكلة: الأقمشة الناعمة تسترخي وتسمح لك بكتابة كود لم يتم اختباره (وتغطيته بالاختبارات).
قبلت القواعد:
- يجب أن يكون من السهل اختبار الرمز الجديد phpunit
- SoftMocks - الحالة القصوى (الرمز القديم / طويل / مكلف / معقد)
نحن ننظر إلى مراجعة الكود لهذه القواعد.
اختبار الجودة
اختبار الطفرة
- خذ الرمز
- خذ تغطية الكود
- نقوم بتحليل الشفرة وتطبيق الطفرات (تغيير + => - ؛ صحيح => خطأ ، وما إلى ذلك)
- لكل تحور ، نقوم بإجراء مجموعة (مجموعة) من الاختبارات.
- إذا فشلت الاختبارات ، ثم تقريبا. إذا لم يكن كذلك ، فهي ليست فعالة بما فيه الكفاية. نحن نفهم ، نغير / نضيف الاختبارات.
هناك حلول جاهزة (Humbug ، Infection) ، لكنها غير مناسبة (غير متوافقة مع softmocks ، هناك صعوبات في تغطية الكود). لذلك ، كتبوا بأنفسهم.
اختبار الطفرة غير متاح حتى الآن للاختبار اليدوي. متاح للتشغيل يدويًا ، من وحدة التحكم. الآن نقوم بتنفيذها في خط أنابيب CI ، وبناء العملية. ستكون النتيجة على هبر.
اختبارات التكامل
اختبار تشغيل عدة مكونات بالاقتران ؛ نتحقق من العمل مع القاعدة و / أو الخدمات.
النهج القياسي لاختبار قاعدة البيانات (DBUnit):
- رفع قاعدة بيانات الاختبار
- املأه
- قم بإجراء الاختبار
- نقوم بتنظيف قاعدة البيانات
المشاكل:
- من الضروري دعم قواعد البيانات ومجموعة البيانات (مدى صلة محتويات قاعدة البيانات)
- يستغرق إعداد قاعدة البيانات بعض الوقت
- تجعل عمليات الإطلاق المتوازية الاختبارات غير مستقرة وتتسبب في جمود
الحل: مكتبة DBMocks (الحل الخاص)
مبدأ العمل:
- تم اعتراض طرق تشغيل DB باستخدام SoftMocks في اختبار الإعداد
- من طلب parsim db + table
- ينشئ Tmpfs جداول مؤقتة بنفس المخطط
- جميع الاستعلامات تذهب فقط إلى الجداول المؤقتة
- في TearDown ، يتم حذفها.
المكتبة صغيرة ولكنها لم تفتح بعد في المصدر المفتوح.
النتائج:
- لا يمكن أن تتلف الاختبارات البيانات في الجداول الأصلية
- يتم عزل الاختبارات عن بعضها البعض (يمكن إجراؤها بالتوازي)
- اختبار توافق الاستعلام مع نسخة MySQL
اختبارات API
- تقليد جلسة العميل
- قادرة على إرسال طلبات الخلفية
- تستجيب الواجهة الخلفية تقريبًا مثل العملاء الحقيقيين
عادة ، تتطلب هذه الاختبارات مستخدمًا مصرحًا له. يجب إنشاؤها قبل الاختبار وحذفها بعد. هذا يقدم مخاطر إضافية (التكرار ، مهام الخلفية).
الحل: لقد صنعنا مجموعة من مستخدمي الاختبار. تعلمت كيفية تنظيفها.
مستخدمو الاختبار في نفس بيئة المستخدمين الحقيقيين ، لأن devel! = Prod. من الضروري عزل مستخدمي الاختبار والعيش.
للعزل ، تمت إضافة علامة is_test_user للمستخدم. كما يتم استبعاد هؤلاء المستخدمين من التحليلات ونتائج اختبار أ / ب.
يمكن جعله أرخص من خلال إرسال مستخدمي الاختبار "إلى القارة القطبية الجنوبية" ، حيث لن يراها أحد (باستثناء البطاريق).
QA API
أداة لإعداد البيئة في اختبارات واجهة برمجة التطبيقات ، في الواقع باب خلفي في الخلفية لتغيير إعدادات المستخدم / البيئة بسرعة.
- طرق API موثقة بشكل جيد
- إدارة البيانات بسرعة وسهولة.
- يكتب المطورون الواجهة الخلفية
- لا يمكن تطبيقه إلا لاختبار المستخدمين.
يسمح للمستخدم بتغيير البيانات الثابتة (على سبيل المثال ، تاريخ التسجيل).
الحماية المطلوبة:
- على مستوى الشبكة (متوفر فقط من شبكة المكتب)
- يتم تمرير سر مع كل طلب ، يتم التحقق من صحته
- تعمل الطرق فقط مع مستخدمي الاختبار.
هناك برنامج BugsBounty على HackerOne. يدفعون مقابل نقاط الضعف الموجودة. تم العثور على واحد غير قادر على QA API باستخدامه.
يسخر من بعيد
Moki للواجهة الخلفية البعيدة.
اعمل على قاعدة صور وهمية. يطلب الاختبار من الواجهة الخلفية التهيئة لجلسة وهمية. عند استلام الطلب ، تتحقق الخلفية من قائمة mox للجلسة وتطبقها باستخدام SoftMocks.
مثال اختباري:
اختبارات API مريحة للغاية. من المغري كتابتها بدلاً من الوحدة. لكن اختبارات API أبطأ بكثير.
اعتمد مجموعة من القواعد:
- الغرض من اختبارات API هو اختبار البروتوكول والتكامل
- تدفق مجمع الاختيار صالح
- لا يمكن اختبار التغيرات الصغيرة.
- عند مراجعة الكود ، نقوم باختبار الاختبارات أيضًا.
اختبارات واجهة المستخدم
لا يكتب الأمر backend.
يتم تغطية الميزة بواسطة اختبارات واجهة المستخدم عندما تستقر.
يستخدمه السيلينيوم للويب. كالاباش المحمول.
تشغيل اختبار
100000 اختبار وحدة. 6000 اندماج ، 14000 اختبار api.
في تيار واحد ، الوقت هو 40 دقيقة / 90 دقيقة / 10 ساعات.
Made TestCloud - سحابة لإجراء الاختبارات.
توزيع الاختبار بين الخيوط:
- يمكنك بالتساوي (بشكل سيئ ، جميع الاختبارات مختلفة ، وتبين أنها غير متساوية في أجزاء الوقت)
- قم بإجراء سلاسل رسائل متعددة واختبارات phpunit للتغذية واحدًا تلو الآخر (زيادة التهيئة. طويل!)
الحل:
- جمع الإحصائيات في وقت التشغيل.
- تخطيط الاختبارات بحيث لا تعمل القطعة أكثر من 30 ثانية
مشكلة اختبارات واجهة برمجة التطبيقات (API) هي وقت طويل ، الكثير من الموارد ولا تسمح للآخرين بالتنفيذ.
لحل هذه المشكلة ، قسمنا السحابة إلى قسمين:
- يدير اختبارات سريعة فقط.
- يدير كلا النوعين من الاختبارات.
والنتيجة هي تسريع الوقت من أجل:
- الوحدة - 1 دقيقة
- التكامل - 5 دقائق
- API - 15 دقيقة.
تشغيل تغطية التعليمات البرمجية
ما الاختبارات لأداء؟ سيظهر تغطية الرمز.
- نحصل على فرق فرع
- قم بإنشاء قائمة بالملفات المعدلة
- احصل على قائمة الاختبارات لهذه الملفات.
- نقوم بتشغيل الجناح فقط من هذه الاختبارات.
يتم تشكيل التغطية مرة واحدة في اليوم ، ليلا ، للفرع الرئيسي. تتم إضافة النتائج (فرق) إلى قاعدة البيانات.
الإيجابيات:
- نجري اختبارات أقل: حمل أقل للأجهزة وملاحظات اختبار أسرع
- يمكنك تشغيل اختبارات التصحيحات. يتيح لك هذا طرح الإصلاح العاجل بسرعة. في البقع ، السرعة هي الأهم.
السلبيات:
- الإصدار الخلفي 2 مرات في اليوم. بعد الغداء ، تكون التغطية أقل أهمية (ولكن عند طرح إيقاع ، نحن دائمًا نقود مجموعة كاملة).
- اختبارات Api تولد تغطية واسعة النطاق. بالنسبة لهم ، هذا النهج لا يوفر الكثير من المدخرات.
إذا كان المطور بحاجة إلى رؤية تغطية الشفرة على الفور ، أي أداة يمكن تشغيلها في وحدة التحكم والحصول على الفور على أحدث مقياس لغطاء ملف / مكون معين.
يعتبر الأمر صعبًا: يتم أخذ البيانات على سيد الغلاف ، ويتم إضافة جميع الاختبارات المعدلة ، وتبين مجموعة صغيرة تم النظر في التغطية عليها بالفعل.
الملخص
- تحتاج إلى جميع مستويات الاختبار
- الكمية! = الجودة. قم بمراجعة الكود واختبار الطفرة
- عزل مستخدمي الاختبار من الحقيقيين.
- تعمل الواجهات الخلفية في الواجهة الخلفية على تبسيط اختبارات الكتابة وتسريعها
- جمع إحصائيات عن الاختبارات.
المراجع