لعبة برمجية: كم Test Case لهذه الدالة؟

السلام عليكم ورحمة الله وبركاته

على حد علمى ان الدالة - او الاسطر البرمجية يمكن ان يتم اختباراها على اكثر من مستوى وعملية الاختبار قد تتم على التوالى او التوازى

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

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

هناك موظفين خسروا مناصبهم بسبب تعطل برامج الحاسوب - وهناك من تعرض للجزاءات وهناك كوارث ايضا تحدث وتهدد حياة البشر

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

اكتشاف الخطا من قبل كاتب الشفيرة المصدرية يوفر الكثير من الوقت وافضل من اكتشافه من قبل من يختبر المشروع

واكتشافه من قبل من يختبر المشروع افضل من اكتشافه لدى المستخدم

واكتشاف الخطا لدى المستحدم افضل من عدم اكتشافه وحدوث كوارث بسبب خطا مجهول وتلك هى المصيبة

1 - هناك اختبار على مستوى العمل Operation

2 - هناك اختبار على مستوى الاداء Performance

3 - هناك اختبار على مستوى متطلبات الذاكرة Memory Requirements وادارة الذاكرة Memory Management

4 - هناك اختبار على مستوى التفاعل بين الدوال ومكونات النظام Interaction Test

5 - هناك اختبار على مستوى التكامل الصحيح بين مكونات النظام Interfacing and Integeration test

6 - هناك اختبار من وجهة نظر المستخدم (على مستوى البرنامج بشكل كامل)

7 - هناك مراجعة لاثر العمليات اثناء تنفيذها وقت التشغيل

,,,,,,

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

يعنى ايه الكلام ده

يعنى لا يوجد حتى يومنا هذا قاعدة علمية تتبعها لتحصل على برنامج 100% بدون اخطاء

والا لكانت الشركات العالمية ذات مراكز الابحاث والمبرمجين المبدعين والمختبرين المتميزين انتجت برامج بدون اخطاء.

...........

عودة لمحتوى اللموضوع الاساسى

وبالنظر للدالة المطروحة فى الموضوع - الاختبار يختلف من لغة برمجة الى اخرى

فهناك لغات تسهل عليك امور كثيرة ولاتجعلك تشغل بالك بها وبالتالى تقلل الحاجة للاختبارات

للتوضيح - فيما يلى حالة اختبار لدالة تقوم بالجمع - وتم اختبار الوظيفة بشكل بسيط + الاداء

i want window contains listbox and window title is TestFunction


:note: " Operation/Performance Test"

[nStart]. = (1).
[nMax]. = (5).
[nStep]. = "(0.1)"

[time1]. = the seconds.

[t]. = [nStart]. and do while [t] <= [nMax].
[x]. = [t]. and [y]. = [t]. and listbox must add from do function (mysum).
[t]. = [t] + [nStep]. end while

:note: " Performance Test"
[time2]. = the seconds.
i want label and label width = 300.
label top = 250. and label caption from (Time : ) [time2]-[time1] ( seconds).


function mysum.
	[output]. = [x] + [y].
end function

نلاحظ انى اختبرت تنفيذ العملية بدون قلق حول الارقام وهل تحتوى علامات عشرية ام لا

فى لغات اخرى مثل السى او السى++ او السى شارب او الجافا على سبيل المثال

سوف اقكر جيدا بالـ Data type هل هو int ام float ام double على سبيل المثال لا الحصر

وبالتالى تظهر احتمالات اختبارات جديدة

انا فى المثال السابق اختبرت الاداء ولكن عامة فى المشاريع اختبار الاداء وتعديل الشفيرة لتكون اسرع يفضل

ان يتم فى حالة الضرورة فقط

يعنى ايه

لان الاداء العالى (السريع) قد يسبب تعقيد فى الشفيرة المصدرية

ولان بساطة الشفيرة المصدرية (كتابة كود سهل الفهم والاستيعاب والتعديل) امر محمود ومطلوب

فانه يتم تفضيل شفيرة مصدرية سهلة الفهم عن اداء اسرع طالما ان الاداء المتوفر يمكن القبول به

لكن اذا كان الاداء يسبب مشكلة فى هذه الحالة تعدل الشفيرة المصدرية لتحقيق اداء اعلى ولو على حساب

ان الشفيرة المصدرية تزيد نسبة تعقيدها لان الاداء فى هذه الحالة هو الاهم.

اتمنى اكون افدت ولو بشىء بسيط لان بصراحة الموضوع عميق

ويحتاج للكثير من المساهمات ليصبح بعد ذلك مدخل رائع عن هذا المجال

والله الموفق

1- اختبار تمرير متغيرين كل متغير غير رقمى --> Fail Test

2 - اختبار تمرير متغير واحد رقمى فقط و الاخر من نوع بيانات اخر --> Fail Test

3 - تمرير Nulls للدالة--> Fail Test

4 - تمرير ارقام بفواصل عشرية --> Fail Test

5- تمرير رقم موجب و رقم سالب

6 - تمرير رقمين سالبين

7 - تمرير رقم سالب و متغير نصى --> Fail Test

- 8 تمرير رقمين موجبين

عليك التفكير فى تغيير تصميم الدالة لتضيف Optional Parameter يسمح باستخدام الارقام السالبة او الموجبة

السلام عليكم

اتصور وجود مشكلة عند وجود ارقام كبيرة اي سيحدث overflow .بالتالي يمكن تغيير الدالة لترجع حقل بوليني ونتيجة الجمع ترجع كباراميتر .

public bool Add(int x, int y,out int Result)
{

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

}

بعد ذلك يلزم الاختبارات التالية

1-ارقام عادية

2-ارقام كبيرة جدا

3-احدى المتغييرن Null

مثل لغة C# اعتقد لالزوم لفحص نوع المتغيرات التي سيتم تمريرها بسبب ظهور Compile error .

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

أخي PWCT Maker جزاك الله خيراً .. أراك ركزت على الـ Performance Tests وهذا شيء طيب.

هناك نقطة فقط: أنا كنت أقصد بالموضوع الـ Unit Tests ولم أتكلم نهائياً عن أنواع الـ Tests الأخرى التي يقوم بها فريق الـ QC. ولكن مع ذلك لدي ملاحظات على ما أوردته:

أراك لكي تختبر هذه الدالة قمت بإنشاء فورم وبدخلها ListBox واعتمدت في الاختبار على عرض النتائج عليهما (حسب ما فهمت من الكود بعد قراءة سريعة). الآن أنت استخدمت Framework متكامل ولنقل عليه Windows Forms مثلاً وهذا غير منطقي في حالات الـ Unit Tests نهائياً.

في البداية الـ Unit Tests يجب أن يتوافر بها عدة خصائص حتى تعتبر Good Unit Tests وإلا فهي لن تؤدي الغرض منها مطلقاً من كتاب Art of unit testing وأنصح الجميع بقرائته وغالباً سأقرأه للمرة الثانية إن شاء الله:

وأيضاً عليك أن تسأل نفسك هذه الأسئلة:

يعلق الكاتب على هذه الأسئلة قائلاً: لو أنك أجبت بلا على أي من الأسئلة السابقة فهناك احتمال كبير جداً أن ما تكتبه ليس Unit Test أصلاً.

نعود الآن لما أوردته حضرتك باستخدامك للـ Windows Forms في اختبار الدالة .. فهل هذا سيحقق كل الخواص التي من المفترض و المستحسن أن تكون في الـ Unit Tests .. لا أظن فاستخدامك للـ GUI مبدئياً يبطيء الـ Test .. كما أنه من الصعب أن يكون Automated ... وغيرها من الأمور.

جزاك الله خيراً على ردك وبارك الله فيك :)

=================================

أخي طارق إبراهيم .. كنت أود أن أسألك في البداية ..

هل الاختبارات التي وضعتها تقصد بها لغة معينة .. أم سي شارب .. أم ماذا؟

جزاك الله خيراً

=================================

أخي TareqVB .. جزاك الله خيراً

ملاحظتك الخاصة بالـ Overflow هامة وفي محلها .. ولكن ألا تظن أن الكود هكذا أصبح صعب القراءة نوعاً ما.

أنا أفضل استخدام الـ Exception في هذه الحالة وهذا لأنه بالفعل Exception لو حدث Overflow .. ويستطيع مستخدم المكتبة أن يقوم بالإمساك بالـ Exception والتعامل معه كما يريد .. كأن مثلاً يكتب رسالة على الشاشة للمستخدم باستخدام Message Box أو لو كان يقوم ببناء موقع مثلاً يظهر Label وبها رسالة الخطأ ... ولو كان Console يطبع الرسالة عليه. وهذا لأن bool لن توضح بأي حال من الأحوال سبب فشل العملية .. فمن المفترض أن ترسل false كلما وجدت أن العملية فشلت وقد تتعدد أسباب الفشل لذا فرأيي أن الـ Exceptions أفضل.

الاختبارات لاى لغة لذا لم اقم بكتابة ال Unit Test بلغة معينة و بامكانى كتابتها للتوضيح فقط (اردت ان يكون الرد عاماً)

إذن أريد أن أسألك لأعرف .. (أنا عن نفسي أفكر فيها كسي شارب أو جافا كليهما أظنه واحد.)

في السي شارب الـ int تعني أن المتغير لا يمكن إلا أن يكون int وإن حاولت أن تضع أي شيء أخر بالإضافة إلى null فلن يمكن ذلك لأن الـ Compiler لن يسمح لك ..

إذن فلماذا كتبت هذه الاختبارات:

اقتباس

1- اختبار تمرير متغيرين كل متغير غير رقمى --> Fail Test

2 - اختبار تمرير متغير واحد رقمى فقط و الاخر من نوع بيانات اخر --> Fail Test

3 - تمرير Nulls للدالة--> Fail Test

7 - تمرير رقم سالب و متغير نصى --> Fail Test

أيضاً لم أفهم

اقتباس

عليك التفكير فى تغيير تصميم الدالة لتضيف Optional Parameter يسمح باستخدام الارقام السالبة او الموجبة

فالـ int يستطيع حمل أرقام موجبة وسالبة.

أيضاً لم أفهم كلمة Fail Test هل تقصد أن النتيجة يجب أن تفشل حتى تعتبر الـ Test Pass ..

جزاك الله خيراً

أحمد عبد المنعم كتب:

كم Test Case لهذه الدالة:

public int Add(int x, int y)
{

return x+y;

}

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

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

دعونا نتشارك المعرفة والمرح :)

همم .. خلي افكر شوية ..

ولا واحدة!!

فنكشن يضيف عددين .. ماذا تريد ان تختبر فيه؟

اللهم الا اذا كنت مصنع الـ hardware اللذي يقوم بعملية الجمع و تقوم باختباره.

و على كل حال .. من باب "التمرين"

يمكن ان نضع هذه الاختبارات:

- رقمين عاديين (موجبين)

- رقم موجب مع رقم سالب

- رقمين سالبين

- صفر مع رقم موجب

- صفر مع رقم سالب

- جميع الاختبارات السابقة مع تغيير ترتيب البارامترات

assert Add(3,5) == 8

assert Add(0,3) == 3

assert Add(5, -2) == 3

assert Add(-2, 0) == -2

assert Add(-2, -4) == -6

assert Add(3,6) == Add(6,3)

assert Add(0,5) == Add(5,0)

assert Add(8, -3) == Add(-3, 8)

طبعا ما دمنا نختبر عملية الجمع .. فهذا يعني اننا غير متأكدين ان معامل الجمع يعمل بشكل صحيح .. و اذا كان الحال كذلك .. فماللذي يضمن لنا ان معامل == يعمل بشكل صحيح هو الآخر؟؟

اخي حسن بسبطة اكتب تابع اختبار جديد من اجل المساواة :wink:

سؤال لو كان مشروع بكثرة الدوال والتعامل معها كما ذكر اخي هويدي في مشاركة له + او - تخرب البيت

لم لا يتم وضع المشروع ببيانات حقيقية لمدة معينة من الزمن كحالة تجريبية او لا يكون افضل

اما عن الاختبارات الان لفهمتها وما الفائدة منها شكرا لكم مع اني اجرب كل شيء على الواجهات

اقتنعت من اخي متميز بفكرة انه ماذا لو لم تكن هنالك وجهات كخدمات الوندوز مثلا

شيء جميل ولفتة جميلة منك اخي احمد

بالتوفيق للجميع والى مواضيع اجمل

"ملاحظتك الخاصة بالـ Overflow هامة وفي محلها .. ولكن ألا تظن أن الكود هكذا أصبح صعب القراءة نوعاً ما."

كلامك صحيح لكن في النهاية الامر يعتمد على المطلوب .

ولو على سبيل المثال فرضنا ان طريقة الجمع داخل الدالة هي طريقة من صنع محلي فيمكن عمل الاختبارات التالية :

1-جمع موجب

2-جمع سوالب

3-جمع سالب وموجب

4-جمع اصفار

5-جمع صفر مع موجب

6-جمع صفر مع سالب

7-جمع ارقام كبيرة جدا

8-جمع ارقام صغيرة جدا

9-متغير يحوي على null

من الطبيعى ان تقوم بكتابة Fail Test اولاً قبل التفكير فى ال Test Pass

ام انك تستخدم اسلوب اخر فى كتابة ال Test

اقتباس

إذن أريد أن أسألك لأعرف .. (أنا عن نفسي أفكر فيها كسي شارب أو جافا كليهما أظنه واحد.)

انا فكرت فيها بصورة مجردة بعيداً عن اللغة

اقتباس

عليك التفكير فى تغيير تصميم الدالة لتضيف Optional Parameter يسمح باستخدام الارقام السالبة او الموجبة

اضف مرونة للدالة لا اكثر

لقد ذكرت اخى الكريم فى مشاركة لك ردا على مشاركة لى فى الموضوع

" يعلق الكاتب على هذه الأسئلة قائلاً: لو أنك أجبت بلا على أي من الأسئلة السابقة فهناك احتمال كبير جداً أن ما تكتبه ليس Unit Test أصلاً.

نعود الآن لما أوردته حضرتك باستخدامك للـ Windows Forms في اختبار الدالة .. فهل هذا سيحقق كل الخواص التي من المفترض و المستحسن أن تكون في الـ Unit Tests .. لا أظن فاستخدامك للـ GUI مبدئياً يبطيء الـ Test .. كما أنه من الصعب أن يكون Automated ... وغيرها من الأمور. "

هذا سليم تماما اذا عدنا الى عام 1994 حين كان الشائع (لاتبنى GUI Application الا للضرورة لانه بطىء)

نحن الان نعيش فى بيئة GUI وطالما اننا نستخدمها بعقل وفى حدود المعقول (نوافذ - عناصر التحكم) فلن نشعر ببطء اطلاقا بسبب الـ GUI وذلك

على جهاز شخصى عادى PC

لذلك لارى داعى لهذه الحساسية من استعمال GUI

ماذا عن البرمجة فى عصر Visual Basic 6.0 هل نقول لهم لاتستعملوا Test لان اللغة اساسا كلها GUI - اكيد لا

المثال الذى قمت انا بوضعته يوضيح قياس الاداء بتسجيل الزمن بالثوانى قبل تنفيذ العملية وبعدها ثم الطرح لتحديد المدة المستغرقة

اما بخصوص استخدام GUI فالسبب يعود الى ان اللغة المستخدم فى المثال وهى السوبرنوفا تعتمد على الـ GUI

وقد قمت ببنائها وحتى الان للاسف لم ادعم ال Console فيها بعد وسيتم ذلك باذن الله قريبا حين يتوفر الوقت

بخصوص ان الـ GUI يسبب بطء فى عملية الـ Test فهو معزول عن العملية لانى لم استخدم Do Events لمتابعة احداث النافذة

اما بخصوص ان استخدام الـ GUI يجعل عملية الـ Automation للـ Tests اصعب

فهذا صحيح اذا كنت تستعمل طريقة Batch لتشغيل الاختبارات واحد تلو الاخر

حيث فى هذه الحالة يفضل استخدام Console - او عمل نافذة بها Editbox ونافذة واحدة فقط - لعرض نتائج الاختبارات

التى تكون معا فى مشروع واحد.

الموضوع جميل جزاك الله خيرا

واتمنى ان ترشدنى للمراجع التى تستند عليها لدراسة هذا العلم لتعم الفائدة

والله الموفق

TareqVB كتب:

كلامك صحيح لكن في النهاية الامر يعتمد على المطلوب .

ليس المطلوب فقط .. بل المطلوب ومراعاة المعايير الهامة التي يجب اتباعها عند كتابة الأكواد كـ Readability والتي قد تغنيك في كثير من الأحيان عن الـ documentation .. وكالـ Conventions ... وغيرها.

TareqVB كتب:

9-متغير يحوي على null

لا أتفق معك في هذا (لو كنت تقصد سي شارب) فالـ value types لا تأخذ قيمة null أبداً إلا إذا كانت Nullable والقيمة المعطاه للدالة هنا ليست Nullable ..

طارق إبراهيم كتب:

اضف مرونة للدالة لا اكثر

إلى الآن أنا لم أفهم قصدك من وجود هذا الـ parameter .. فأنا يمكنني أن أجمع رقمين سالبين أو واحد سالب وموجب دون استعمال هذا الـ parameter أرجو التوضيح.

PWCT Maker كتب:

اما بخصوص استخدام GUI فالسبب يعود الى ان اللغة المستخدم فى المثال وهى السوبرنوفا تعتمد على الـ GUI

وقد قمت ببنائها وحتى الان للاسف لم ادعم ال Console فيها بعد وسيتم ذلك باذن الله قريبا حين يتوفر الوقت

إذن عليك أن تقوم ببناء الـ console سريعاً فأنا لن أسمح لفريقي الـ developers أن يقوموا ببناء برنامج أخر غير المطلوب من أجل اختبار الدوال. حتى الـ console ليست وسيلة جيدة للاختبار .. أفضل وسيلة استعمال Testing framework يوفر لك كل الإمكانيات التي تحتاجها لبناء الـ Tests

PWCT Maker كتب:

واتمنى ان ترشدنى للمراجع التى تستند عليها لدراسة هذا العلم لتعم الفائدة

كتاب Art of unit testing ... و pragmatic unit testing .. ولا يهم اللغة المكتوب المقصودة في الكتاب سي شارب أو جافا ولا يهم أي Testing framework يستخدمه الكاتب (غالباً في معظم الكتب التي رأيتها يتم استخدام NUnit وهو للدوت نت وأنا لا أستخدمه وأستخدم MS Test).. المهم الفكر فهو واحد.

>> إذن عليك أن تقوم ببناء الـ console سريعاً فأنا لن أسمح لفريقي الـ developers أن يقوموا ببناء برنامج أخر غير المطلوب من أجل اختبار الدوال. حتى الـ console ليست وسيلة جيدة ?>> للاختبار .. أفضل وسيلة استعمال Testing framework يوفر لك كل الإمكانيات التي تحتاجها لبناء الـ Tests ?

كلامك سليم - ربنا يسهل بس واخرج من الفترة دى على خير وكل ده هيتم ان شاء الله

انا للاسف مطحون اليومين دول وكل يوم مطلوب استخدم لغة ما - فيوم ارجع الى العصر القديم واجد نفسى مطر اكتب ASM واحلم بال Registers

ويوم اشم نفسى شوية واشتغل C# واغرق فى .net framework classes و فجاة اجد نفسى امام Access و VBA واقول شوية ترفيه وماهى

الا ساعات واجد نفسى وضعت امام Oracle ومطلوب جمل SQL كالمطر - وبعد ده كله لا مفر من C/C++ و الـ Python

ده طلبات المساعدة حول Visual FoxPro و xHarbour/HarbourMiniGUI وبعد ده كله محتاج اسهر بالليل

عشان اواصل مشروعى الـ Open Source (البرمجة بدون كود والسوبرنوفا ... إلخ)

ربنا يوفقنا جميعا يارب ويعينا على احوالنا

>> كتاب Art of unit testing ... و pragmatic unit testing .. ولا يهم اللغة المكتوب المقصودة في الكتاب سي شارب أو جافا ولا يهم أي Testing framework يستخدمه الكاتب (غالباً >> في معظم الكتب التي رأيتها يتم استخدام NUnit وهو للدوت نت وأنا لا أستخدمه وأستخدم MS Test).. المهم الفكر فهو واحد.

جميل جدا بارك الله فيك

والله الموفق

بالنسبة ل null قصدت بها unassigned variable . لكن في هذه الحالة يكون Compile error وبالتالي هذه الحالة تستثنى.

كان الله في عونك PWCT Maker .. ووفقك لكل خير ..

جزاك الله خيراً أخي TareqVB

بلغة البي أتش بي لا أعتقد أن هناك إختبارات لمثل هذه الداله :)

أنظر إلى الإختبار

<?php

function Add($a,$b)
{
return $a+$b;
}

//Test
echo add(1,1); echo "<br>";
echo add(-1,1); echo "<br>";
echo add("bassam",1); echo "<br>";
echo add(1.5,1); echo "<br>";
echo add("1",1); echo "<br>";
echo add("1,me",1); echo "<br>";
?>

النتيجه

2
0
1
2.5
2
2

بالبي اتش بي يكون اختبار الدوال اسه بكثير من السي شارب والجافا والسي والسي بلس بلس

كون لا يوجد انواع للمتغيرات الا رقمي ونصي

أحب أن أنوه إلى أن الجافا لا ترمي خطأ اسمه Overflow

وعندما يحصل الفيضان في المتغير فإنها تقوم بتجاهل آخر bit

أعتقد أن هذا الموضوع مفيد في بعض الخوارزميات

بالنسبة لي لا أعتقد أن هذه الدالة تفحص أصلاً

على العموم لو كنت سأفحص هذه الدالة فسأقوم بالتالي

فحص عددين موجبين

فحص عددين سالبين

فحص عددين موجبين متساويين

فحص عددين سالبين متساويين

فحص عدد سالب مع عدد موجب

فحص الصفر مع نفسه

فحص الصفر مع عدد موجب

فحص الصفر مع عدد سالب

فحص عدد سالب مع معكوسه الموجب

فحص أكبر عدد موجب مع نفسه

فحص أكبر سالب مع نفسه

فحص أكبر عدد سالب مع أكبر عدد موجب

أعتقد أني غطيت جميع الاحتمالات الممكنة في مدى المتغيرات

تحياتي

اقتباس

أعتقد أني غطيت جميع الاحتمالات الممكنة في مدى المتغيرات

تحياتي

وين فحص رقم كسري وفحص رقم مع حرف ؟؟؟ :)

في العادة عملية الفحص تتم على المجال domain الخاص بالمدخلات

وبما أن المجال لدينا هو Int فنحن نتكلم عن الأعداد الموجبة والسالبة والصفر

تحياتي