في دوراتي التدريبية لتدريب المختبرين المبتدئين، أقترح عليهم كتابة اختبارات إيجابية وسلبية لـ:

1. وظيفة حساب الجذر في الآلة الحاسبة.
2. العمل مع سلة التسوق (إضافة / حذف / تحرير) في المتجر الإلكتروني.

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

لذلك قررت أن أكتب مقالا توضيحيا.

اختبار إيجابي

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

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

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

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

دعونا نلقي نظرة على مثال:

حالة الاختبار الرئيسية هي التحقق من حساب جذر الرقم الصحيح بالفعل.

يمكنك تقسيمها إلى الفصول التاليةالتكافؤ:

• بعد حساب الجذر، يبقى عدد صحيح (جذر 4 = 2)
• بعد حساب الجذر يبقى عدد كسري (جذر 3)

حسنًا، ماذا لو لم يكن لدينا رقم كسري فقط بعد الحسابات الجذرية، ولكن أيضا ل ؟ هل يمكننا أخذ جذر 2.2؟ اختبار إيجابي؟ إيجابي!

يمكنك أيضًا تقسيم الأرقام إلى أرقام صغيرة، حتى 100، على سبيل المثال. ثم خذ الفاصل الزمني من 100 إلى الحجم int وسيكون الثالث أكبر، بقدر ما يناسب الآلة الحاسبة لدينا. 3 فئات تكافؤ، نتحقق من قيمة واحدة من الفترة.

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

من الشيء الرئيسي، ربما، كل شيء.

أوه، هذا هو المكان الذي يوجد فيه مجال للخيال!

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

هل تعتقد أنه سيعمل إذا كان يعمل بشكل منفصل؟ Nooooo يا شباب، أنتم المختبرين! لا تأخذ البرامج على محمل الجد أبدًا! هل توصلت إلى سيناريو؟ تحقق من ذلك!

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

هل السيناريو نفسه إيجابي؟ نعم! على الرغم من وجود ملاحظات الانحراف بالفعل، يجب أن أعترف

اختبار سلبي

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

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

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

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

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

ولكن كيف يتم إنشاء مثل هذه الاختبارات؟ دعونا نلقي نظرة على الأمثلة:

1. وظيفة لحساب الجذر في الآلة الحاسبة.

أول ما يتبادر إلى ذهنك هو ماذا يحدث إذا قمت بحساب جذر الرقم السالب؟

ولكن ماذا يمكنك التفكير هنا؟

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

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

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

2. العمل مع عربة التسوق في متجر عبر الإنترنت.

هنا، مرة أخرى، يمكنك العثور على حقل أرقام واللعب به، كما فعلنا للتو مع الآلة الحاسبة. حقل "كمية السلعة" مناسب جدًا هنا! ولكن، من ناحية أخرى، هل هي مملة، مثل هذه التطبيقات المختلفة ونفس الاختبارات؟

تذكر كلمتين فقط - علامات تبويب مختلفة !

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

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

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

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

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

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

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

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

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

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

لذا يا شباب، اذهبوا لذلك! افتح علامات تبويب مختلفة وتابع البحث عن معلومات حول كيف يتصرف برنامجك بالضبط تحت التأثيرات المتناقضة عليه؟

ملحوظة: هذا مقتطف من كتابي للمختبرين المبتدئين، وقد كتب لمساعدة الطلاب في مدرستي للمختبرين

تعال وقم بزيارتنا!

ツ

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

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

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

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

اختبار إيجابي وسلبي

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

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

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

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

ولذلك، في رأينا،

لا يلزم فصل الاختبارات السلبية والإيجابية وتباعدها في الوقت المناسب.

لأنه هل يمكننا القول أن النظام يعمل كما ينبغي إذا اختبرنا استجابته للمدخلات الصحيحة فقط؟

اختبار إيجابي سلبي

عند الاختبار، ما مدى أهمية الحدس والغرائز وغرائز الصيد - سمها كما تريد. وهنا يجلس مهندسنا، ويتحقق من استمارة التسجيل، على سبيل المثال.

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

وماذا؟يجب أن يقول لنفسه: لا. الآن لا بد لي من إجراء اختبار إيجابي ولا شيء غير ذلك. لدي موعد سلبي للأسبوع المقبل، وبعد ذلك سوف يحين وقت %adynadyn/>. ربما"؟

نعتقد أن هذا النهج تجاه الاختبار السلبي غير فعال، وإليكم السبب:

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

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

إذن ما هي الاستنتاجات التي يمكننا استخلاصها؟

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

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

مصطلحات ضمان الجودة

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

اختبار إيجابي

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

اختبار سلبي

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

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

يعد هذا اختبارًا للتحقق من جدوى المتطلبات الوظيفية لحل مشكلة المستخدم.

يشمل الاختبار الوظيفي ما يلي:

• الملاءمة الوظيفية
• دقة
• إمكانية التشغيل البيني
• الامتثال للمعايير واللوائح
• حماية

اختبار الأداء

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

يشمل اختبار الأداء ما يلي:

• اختبار الحمل
• اختبار الإجهاد
• اختبار الثبات (اختبار الثبات/التحمل/النقع)

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

يحدد اختبار قابلية الاستخدام هذا مدى قدرة المستخدم على الوصول بسهولة إلى ميزات النظام المتوفرة من خلال واجهة المستخدم.

اختبار واجهة المستخدم

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

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

عملية تقييم مدى تعرض البرمجيات للهجمات المختلفة.

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

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

اختبار التوافق

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

وقد تشمل البيئة العناصر التالية:

• منصة الأجهزة.
• أجهزة الشبكة؛
• الأجهزة الطرفية (الطابعات، ومحركات الأقراص المضغوطة/أقراص الفيديو الرقمية، وكاميرات الويب، وما إلى ذلك)؛
• نظام التشغيل (يونيكس، ويندوز، ماك، ...)
• قواعد البيانات (Oracle، MS SQL، MySQL، ...)
• برامج النظام (خادم الويب، جدار الحماية، مكافحة الفيروسات، ...)
• المتصفحات ( إنترنت إكسبلورر، فايرفوكس، أوبرا، كروم، سفاري)

اختبار الصندوق الأسود

طريقة لاختبار السلوك الوظيفي لكائن (برنامج، نظام) من وجهة نظر العالم الخارجي، والتي لا تستخدم المعرفة حول البنية الداخلية للكائن الذي يتم اختباره.

اختبار الصندوق الأبيض

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

اختبار الصندوق الرمادي

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

الاختبار اليدوي

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

الاختبار الآلي

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

اختبار الوحدة (اختبار المكون/الوحدة)

عملية تسمح لك بالتحقق من صحة الوحدات الفردية كود المصدرالبرامج.

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

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

اختبار النظام (اختبار النظام/الاختبار الشامل)

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

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

مقالات ذات صلة:

حل المشكلات أدوبي فلاشعلى يوتيوب مثال- يقرأ

1. قام بيدفال بإعادة تدوين هذه من
2. أبدى alexruzhyk الإعجاب بهذا
3. قام anko-777 بإعادة تدوين هذه من
4. أحب هذا
5. maryarti معجب بهذا
6. أبدى dfdor44f الإعجاب بهذا
7. قام eridi بإعادة تدوين هذه من
8. أبدى seonoptik الإعجاب بهذا

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

06.10.2018 16947 +67

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

تمت مراجعة المقالة مع الأخذ بعين الاعتبار الانتقادات والتوصيات الواردة في المنتدى.

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

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

ليس كل شيء بهذه البساطة كما بدا لي.

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

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

وبعد فترة طويلة فقط حددت بنفسي تسلسلًا واضحًا للإجراءات التي يجب تنفيذها لاختبار البرنامج:

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

لذلك، دعونا ننظر إلى كل شيء بالترتيب.

المواصفات والمتطلبات، SRS.

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

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

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

بعد أن فهمت كل "حكمة" متطلبات التطبيق وميزات تنفيذ المطور لهذه المتطلبات، يمكنك البدء في اختبار النتيجة النهائية.

عملية الاختبار

ويمكن وصف هذه العملية في الخطوات التالية:

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

تصف الفقرتان الأولى والثانية عملية تسمى الاختبار "الإيجابي". الاختبار "الإيجابي" هو اختبار على البيانات أو السيناريوهات التي تتوافق مع السلوك العادي (القياسي، المتوقع) للنظام قيد الاختبار.

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

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

يقدم قاموس المعلومات تعريفًا واضحًا إلى حد ما لمصطلح "اختبار الدخان":

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

أولويات الاختبار

لماذا يعتبر الاختبار "الإيجابي" أكثر أهمية من الاختبار "السلبي"؟

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

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

ولهذا السبب فإن الاختبار "الإيجابي" أكثر أهمية بكثير من الاختبار "السلبي".

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

سيرة ذاتية

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