بيت › التثبيت والتكوين › اختبار منتجات البرمجيات. كيفية اختبار وظيفة وظيفة تستخدم وظائف أخرى داخلها؟ تغيير الاختبارات ذات الصلة

اختبار منتجات البرمجيات. كيفية اختبار وظيفة وظيفة تستخدم وظائف أخرى داخلها؟ تغيير الاختبارات ذات الصلة

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

كيف يمكنك التأكد من أن حالات الأعطال أو التجميد أو الفشل في تنفيذ الإجراءات اللازمة للبرنامج الذي قمت بتطويره أصبحت نادرة جدًا؟

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

وهذا العلاج يسمى اختبارات منتج برمجي .

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

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

متى ومن؟

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

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

الاختبار الوظيفي
اختبار غير وظيفي

الاختبار الوظيفي

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

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

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

عادة، يتم إجراء الاختبار الوظيفي على مستويين:

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

اختبار غير وظيفي

يقوم الاختبار غير الوظيفي بتقييم صفات منتج البرنامج، مثل بيئة العمل أو الأداء.

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

كما يوحي الاسم، يتحقق الاختبار غير الوظيفي من أن منتج البرنامج يلبي المتطلبات غير الوظيفية الاختصاصاتمن أجل إنشائها. وكما هو الحال في الاختبار الوظيفي، يتم تطوير برنامج ومنهجية اختبار للاختبارات غير الوظيفية.

اختبار البرامج المضمنة والامتثال لها في عصر Agile

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

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

اختبار أداء

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

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

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

وثائق للاختبار

كما ذكر أعلاه، يتم إجراء الاختبار وفقًا للبرنامج ومنهجية الاختبار، التي تم تطويرها وفقًا لـ GOST 34.603-92.

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

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

أثناء الاختبار، يتم وضع بروتوكول اختبار يحتوي على معلومات حول إكمال جميع مراحل وخطوات الاختبار والتعليقات الواردة أثناء الاختبار.

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

الاختبارات الاستكشافية

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

اختبار الإجهاد

اختبار الحمل هو عملية تحليل أداء النظام قيد الاختبار تحت الحمل. الغرض من اختبار الحمل هو تحديد قدرة التطبيق على تحمل الأحمال الخارجية. عادة، يتم إجراء الاختبارات على عدة مراحل.

1. إنشاء نصوص الاختبار

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

2. تطوير تكوين الاختبار

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

3. إجراء اختبار تجريبي

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

أتمتة الاختبار

السمة الرئيسية للاختبار الآلي هي القدرة على إجراء اختبارات الانحدار بسرعة. تتمثل المزايا الرئيسية للأتمتة (وفقًا لتقرير من Worksoft) في زيادة كفاءة الموظفين والكشف المبكر عن العيوب والمزيد جودة عاليةالعمليات التجارية. ويقابل هذه المزايا عيب كبير: التكلفة العالية - نظرًا لارتفاع تكلفة تنفيذ ودعم أتمتة الاختبار، لا تزال حوالي 50% من الشركات تستخدم الاختبار اليدوي بشكل أساسي.

اختبار قابلية الاستخدام

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

اختبار التكوين

يمنح اختبار التكوين الثقة في أن التطبيق سيعمل على منصات مختلفة، وبالتالي لأقصى عدد ممكن من المستخدمين. بالنسبة لتطبيقات الويب، عادةً ما يتم اختيار الاختبار عبر المتصفحات. لتطبيقات Windows - اختبار على مختلف أنظمة التشغيلوأحجام البت (x86، x64). أحد المكونات المهمة لاختبار التكوين هو البنية التحتية للاختبار: لإجراء الاختبارات، تحتاج إلى صيانة أسطول من أجهزة الاختبار باستمرار. عددهم يتراوح من 5 إلى عدة عشرات.

اختبار التكامل

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

اختبار الإجهاد

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

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

عندما أقوم باختبار get-dataهل يجب أن أتحقق من توفر البيانات للمفاتيح؟ هل من المنطقي أن تفشل هذه الوظيفة في اختبارات الوحدة إذا فشل أحد المصدر-أ والمصدر-ب والمصدر-ج؟ إذا كانت وظيفة هذه الوظيفة هي ضم البيانات، وهي كذلك، فيجب أن يكون ذلك كافيًا، أليس كذلك؟

2 إجابات

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

عظيم. ثم يجب عليك التحقق من ذلك. بالنسبة لمعرف معين، هل تقوم بإرجاع البيانات الصحيحة؟

تستخدم هذه الوظيفة الآن 3 وظائف source-a وsource-b وsource-c لإنتاج ثلاثة أنواع مختلفة من الخرائط.

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

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

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

في اختبار الوحدة، يجب عليك اختبار وظيفة فئة واحدة فقط، إذا كانت طرق source-a وsource-b وsource-c تستدعي فئات أخرى، فيجب عليك الاستهزاء بها (يجب اختبارها في فصولها).

في اختبار التكامل، أنت تختبر سلوك فئات متعددة تتفاعل فيما بينها، وهذا يعني أن وظيفة الحصول على البيانات الخاصة بك يجب أن تتحقق من صحة البيانات التي يتم استردادها (source-a وsource-b وsource-c صحيحة و تم توصيل البيانات بشكل صحيح).

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

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

وهذا العلاج يسمى اختبار منتج البرنامج.

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

متى ومن؟

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

الاختبار الوظيفي
اختبار غير وظيفي

الاختبار الوظيفي

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

عادة، يتم إجراء الاختبار الوظيفي على مستويين:

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

اختبار غير وظيفي

يقوم الاختبار غير الوظيفي بتقييم صفات منتج البرنامج، مثل بيئة العمل أو الأداء.

كما يوحي الاسم، يتحقق الاختبار غير الوظيفي من امتثال منتج البرنامج للمتطلبات غير الوظيفية من المواصفات الفنية لإنشائه. وكما هو الحال في الاختبار الوظيفي، يتم تطوير برنامج ومنهجية اختبار للاختبارات غير الوظيفية.

اختبار البرامج المضمنة والامتثال لها في عصر Agile

اختبار أداء

وثائق للاختبار

كما ذكر أعلاه، يتم إجراء الاختبار وفقًا للبرنامج ومنهجية الاختبار، التي تم تطويرها وفقًا لـ GOST 34.603-92.

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

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

الاختبارات الاستكشافية

اختبار الإجهاد

1. إنشاء نصوص الاختبار

2. تطوير تكوين الاختبار

3. إجراء اختبار تجريبي

أتمتة الاختبار

السمة الرئيسية للاختبار الآلي هي القدرة على إجراء اختبارات الانحدار بسرعة. تتمثل المزايا الرئيسية للأتمتة (وفقًا لتقرير صادر عن Worksoft) في زيادة كفاءة الموظفين والكشف المبكر عن العيوب وتحسين جودة العمليات التجارية. ويقابل هذه المزايا عيب كبير: التكلفة العالية - نظرًا لارتفاع تكلفة تنفيذ ودعم أتمتة الاختبار، لا تزال حوالي 50% من الشركات تستخدم الاختبار اليدوي بشكل أساسي.

اختبار قابلية الاستخدام

اختبار التكوين

يمنح اختبار التكوين الثقة في أن التطبيق سيعمل على منصات مختلفة، وبالتالي لأقصى عدد ممكن من المستخدمين. بالنسبة لتطبيقات الويب، عادةً ما يتم اختيار الاختبار عبر المتصفحات. لتطبيقات Windows - اختبار على أنظمة تشغيل مختلفة ومعدلات بت (x86، x64). أحد المكونات المهمة لاختبار التكوين هو البنية التحتية للاختبار: لإجراء الاختبارات، تحتاج إلى صيانة أسطول من أجهزة الاختبار باستمرار. عددهم يتراوح من 5 إلى عدة عشرات.

اختبار التكامل

اختبار الإجهاد

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

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

الاختبار الوظيفي: أين يتم توجيه الجهود الرئيسية؟

لاختبار الوحدة والنظام؛

لتحديد المربع "الأبيض" أو "الأسود"؛

للاختبار اليدوي والأتمتة؛

لاختبار وظائف جديدة أو؛

للاختبارات "السلبية" أو "الإيجابية".

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

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

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

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

يتضمن الاختبار الوظيفي اختيار الاختبار المناسب. وفي الوقت نفسه، من المعتاد التمييز بين الطرق التالية لإنشاء مجموعات لها:

تحليل القيمة الحدودية؛

قسم مكافئ

افتراض الخطأ؛

تحليل الروابط بين الأسباب والنتائج.

يمكنك النظر في كل واحد منهم على حدة.

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

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

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

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

دعونا نلقي نظرة على عملية الاختبار بناءً على توصيات معيار ISO/IEC 12207، ونقدم أنواع الأخطاء التي تم اكتشافها في كل عملية دورة حياة.

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

الأخطاء النموذجية في هذه العملية هي:

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

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

مع تعريف واجهة المستخدم مع البيئة؛
مع وصف الوظائف (عدم كفاية أهداف وغايات المكونات التي يتم اكتشافها عند فحص مجموعة من المكونات)؛
مع تعريف عملية معالجة المعلومات والتفاعل بين العمليات (نتيجة التحديد غير الصحيح للعلاقات بين المكونات والعمليات)؛
مع مواصفات غير صحيحة للبيانات وبنيتها عند وصف المكونات الفردية والبرنامج ككل؛
مع وصف غير صحيح لخوارزميات الوحدة؛
مع تحديد ظروف حدوثها الأخطاء المحتملةفي برنامج؛
بما يخالف المعايير والتقنيات المعتمدة للمشروع.

مرحلة الترميزفي هذه المرحلة تظهر الأخطاء التي تكون نتيجة عيوب التصميم وأخطاء المبرمجين والمديرين أثناء تطوير وتصحيح النظام. أسباب الأخطاء هي:

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

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

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

عادةً ما يتم تقسيم كافة الأخطاء التي تحدث في البرامج إلى الفئات التالية [7.12]:

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

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

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

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

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

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

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

يعد تحليل أنواع الأخطاء في البرامج شرطًا أساسيًا لإنشاء خطط الاختبار وطرق الاختبار للتأكد من صحة البرامج.

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

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

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

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

فيما يلي التصنيف التالي لأنواع الفشل:

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

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

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

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

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

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

شعبية في الفئة: