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

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

لماذا عد المال

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

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

المنطق هنا بسيط: الأعمال - للعملاء الذين يطلبون منا تطوير البرمجيات لشركاتهم - في الواقع ، لا يحتاجون إلى برامج على الإطلاق. يحتاج العمل إلى المال ، والفوائد التي يحققها هذا البرنامج.

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

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

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

الاختبار الذي هو أكثر ربحية

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

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

اختبارات التكامل - اختبار 2x-3x أو أكثر من الوحدات معًا. يمكن أن يكون هناك مئات أو الآلاف من هذه الاختبارات على المشروع ، وهذا يتوقف على مبرمج. السرعة - ثانية أو دقائق لكامل مجموعة الاختبار. التكلفة أعلى من اختبارات الوحدة.

اختبارات القبول تحاكي إجراءات المستخدم باستخدام برنامج. إنها تتطلب إعداد بيئة تشغيلية ؛ وبالتالي فهي معقدة ومكلفة. الكمية لكل مشروع - عادةً يتم إجراء اختبار واحد لقصة العمل. تتراوح سرعة العمل عادة من عشرات الدقائق إلى عدة ساعات لمجموعة كاملة من الاختبارات.

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

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

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

بالنسبة للأنواع المختلفة للاختبار التلقائي ، هناك ثلاثة جوانب مهمة أخرى يجب مراعاتها.

بادئ ذي بدء ، هي الموثوقية - ما مدى سهولة كسر الاختبار (هذا هو أفضل مؤشر لاختبارات الوحدات).

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

وأخيرا - التغطية (تغطية الاختبار). تتمتع اختبارات الوحدة بتغطية جيدة وتستخدم طوال المشروع. تستخدم اختبارات التكامل عادةً في أجزاء معينة من المشروع ، أي أنها لا تغطي البرنامج بالكامل. تعد تغطية اختبارات القبول أسوأ - ويرجع ذلك إلى تعقيد الكتابة وإدارتها ، وغالبًا ما تغطي الحالات التجارية الرئيسية ، وهذا يمثل 20-40٪ من إجمالي حجم المشروع.

استنتاج

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

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