‫‪The short-term benefits:‬‬

‫•‬ ‫‪include improving the performance,‬‬

‫•‬ ‫‪interoperability and matching of the software products produced.‬‬

‫‪In the longer term:‬‬

‫•‬ ‫‪reduces the future costs,‬‬

‫•‬ ‫‪and builds customer confidence.‬‬

‫الفوائد على المدى القصير‪:‬‬

‫تحسين األداء‪.‬‬ ‫•‬

‫تعزيز التوافق بين المنتجات البرمجية‪.‬‬ ‫•‬

‫ضمان التوافق مع متطلبات المنتج‪.‬‬ ‫•‬

‫أما على المدى الطويل‪ ،‬فيؤدي اختبار البرمجيات إلى ‪:‬‬

‫تقليل التكاليف المستقبلية المتعلقة بالصيانة واإلصالحات‪.‬‬ ‫•‬

‫بناء ثقة العمالء بالمنتجات البرمجية‪.‬‬ ‫•‬

‫‪Poor quality lead to increase:‬‬

‫‪→ Software Failures‬‬

‫‪→ development cost‬‬

‫➔ ‪Delay in releasing software‬‬

‫لو السوفت وير مش جودته كويسة‪ ،‬ده بيأدي لمشاكل كتير زي زيادة األعطال‪ ،‬ارتفاع تكاليف التطوير‪ ،‬وتأخير إطالق السوفت‬
‫وير‪ .‬علشان كده الزم نهتم بشوية صفات رئيسية‪:‬‬

‫‪ .1‬الوظيفية ‪ (Functionality):‬يعني السوفت وير يقدر يعمل كل اللي مطلوب منه زي ما هو متوقع‪.‬‬

‫‪ .2‬الموثوقية ‪ (Reliability):‬إن السوفت وير يشتغل من غير مشاكل أو أعطال لفترة طويلة‪.‬‬

‫‪ .3‬سهولة االستخدام ‪ (Usability):‬السوفت وير يكون سهل للمستخدمين يفهموه ويشتغلوا عليه بسهولة‪.‬‬

‫‪ .4‬الكفاءة ‪ (Efficiency):‬إنه يستخدم الموارد بشكل كويس‪ ،‬يعني يشتغل بسرعة وما ياخدش مساحة أو طاقة كتير‪.‬‬

‫‪ .5‬قابلية الصيانة ‪ (Maintainability):‬إنه يكون سهل لو حبينا نعدله أو نعمل صيانة وتحديثات‪.‬‬

‫‪ .6‬قابلية النقل ‪ (Portability):‬إنه يشتغل على أجهزة وبيئات مختلفة من غير ما يحتاج تعديالت كبيرة‪.‬‬

‫**‪ Software Testing‬وإدارة المخاطر**‪:‬‬

‫‪ -‬كل ما الشركة تحط ‪ Resources‬أكتر في ‪ ،Testing‬بتقل احتمالية حدوث ‪ ،Failures‬بس في نفس الوقت تكلفة الـ‪Testing‬‬
‫بتزيد‪.‬‬
‫‪ -‬من ضمن الحاجات المهمة في ‪ Risk Management‬هي إن الشركة تقارن بين تكلفة الـ‪ Failure‬المتوقعة وتكلفة الـ‪.Testing‬‬
‫وبيتم حساب التكلفة المتوقعة كالتالي‪:‬‬
‫)‪Expected Cost = (Risk of Failure) × (Cost of Failure‬‬
‫الكالم ده بيساعد الشركات إنها تاخد قرار صح بخصوص الموارد اللي هيحتاجوها في الـ‪ ،Testing‬عشان يحققوا ‪ Balance‬بين‬
‫تقليل الـ‪ Risks‬والتكاليف الكلية‪ ،‬ويوصلوا للجودة اللي محتاجينها في الـ‪.Software‬‬

‫في أي ‪ ،Business‬بيبقى فيه تكاليف على المدى القصير والبعيد مرتبطة بحدوث ‪Failure.‬‬

‫التكاليف على المدى القصير غالبا ً بتكون مرتبطة بإصالح المشكلة‪ ،‬لكن كمان ممكن تشمل خسارة ‪Revenue‬لو تأخر‬ ‫•‬
‫‪Product Release.‬‬

‫التكاليف على المدى البعيد بتكون غالبا ً بسبب فقدان ‪ ،Reputation‬وكمان تأثيرها على ‪Sales‬المرتبطة‪.‬‬ ‫•‬

‫بمعني‬

‫لما يحصل **‪( **Failure‬يعني مشكلة في المنتج أو الخدمة)‪ ،‬ده بيعمل تكاليف للشركة على نوعين‪:‬‬

‫‪** .1‬المدى القصير**‪ :‬التكاليف دي بتكون عشان يصلحوا المشكلة اللي حصلت‪ ،‬ولو المنتج اتأخر عن ميعاده بسبب المشكلة دي‪،‬‬
‫ممكن الشركة تخسر فلوس (أو **‪ )**Revenue‬ألنها مبيعتش المنتج في الميعاد اللي الناس مستنياه فيه‪.‬‬

‫‪** .2‬المدى البعيد**‪ :‬هنا التكاليف بتيجي من حاجة زي فقدان السمعة (**‪ .)**Reputation‬لو المنتج فيه مشاكل كتير‪ ،‬الناس‬
‫مش هتثق في الشركة تاني‪ ،‬وده هيأثر على مبيعاتها (**‪ )**Sales‬ألن الناس هتبدأ تدور على بدائل تانية‪.‬‬

‫عندنا ‪ 3‬انواع من االخطاء ‪:‬‬

‫‪ :**Mistakes** .1‬دي أخطاء بيعملها **‪ .**Software Developers‬بتكون موجودة في دماغهم وبتسبب عيوب أو‬
‫**‪ **Faults‬في **‪developer >– .**Source Code‬‬

‫‪ :**Faults** .2‬دي العيوب اللي بتبقى موجودة في **‪ ،**Source Code‬وبتكون نتيجة لـواحد أو أكتر من **‪.**Mistakes‬‬
‫و**‪ **Faults‬ممكن تؤدي لحدوث **‪ **Failures‬أثناء تشغيل البرنامج‪.‬‬

‫‪→ tester‬‬

‫‪ :**Failures** .3‬دي األعراض اللي بتظهر بسبب **‪ ،**Fault‬وبتكون عبارة عن سلوك غلط أو مخالف للمواصفات في‬
‫**‪ .**Software‬ولما **‪ **Software‬يكتشف **‪ ،**Failure‬غالبا ً بيظهر في شكل **‪.**Error Code‬‬
 → customer

software faults ‫عندنا حاجات بتساعدنا علي تصنيف ال‬

Analysing , designing , coding software -1

‫لما بنيجي نحلل او نصمم البرامج‬
Developing software -2
software ‫لما بنيجي نعمل تطوير لل‬
Evaluation process or improvement -3
software ‫لما يكون في تقييم اوتحسيين لل‬

Types of fault :

Algorithmic .1

Syntax .2

Computation and Precision .3

Documentation .4

Stress or Overload .5

Capacity and Boundary .6

7. Timing or Co-ordination

Throughput or Performance .8

Recovery .5

Standards and Procedure .10

 Ch2

Static Verification (or Static Analysis) involves reviewing the code without executing it to find
faults.

It can be
A mathematical approach (symbolic execution).
A formal approach (symbolic verification).
Main Problems:
Time-consuming.
Only suitable for certain cases.

Summary in English:

There are tools available to assist in static program analysis.

offering advantages over execution-based testing. ,Manual inspections can be very valuable
Design and code reviews are used to improve software quality by identifying faults earlier in
.development
Pair-programming in Agile software development promotes real-time collaboration.
Checklists in formal code reviews help ensure all critical elements are reviewed and validated.
Summary in English:

Detect faults in the specification/program and ensure adherence to standards. :Objective

:INPUT
The specification/code under review.
A set of objectives or guidelines (checklist) to review.
A copy of relevant standards.
:OUTPUT
A report with a checklist of faults to be fixed.
A set of test cases for dynamic testing at a later stage.

Code Reviews/Inspections : ‫شرح‬

‫ وده ألن العملية دي بتتطلب مراجعة‬،Walk-through ‫ أو التفتيش على الكود بيعتبر أكثر شموالً من الـ‬Code Reviews ‫الـ‬
. ‫أعمق للكود أو المواصفات‬
‫الـ ‪ Inspection‬بتكون عملية رسمية ودقيقة أكتر‪ ،‬وبتعتمد على فريق مكون من أربع أشخاص على األقل‪ .‬كل شخص في الفريق ليه‬
‫دور مهم في المراجعة‪.‬‬

‫المشاركين الرئيسيين‪:‬‬

‫‪ .1‬المصمم )‪:(Designer‬‬
‫‪ .a‬هو الشخص اللي كتب الكود أو اللي صمم البرنامج‪.‬‬
‫‪ .b‬مهمته إنه يشرح الكود لبقية الفريق ويفسر أي قرارات تم اتخاذها أثناء الكتابة‪.‬‬
‫‪ .2‬المختبر )‪:(Tester‬‬
‫‪ .a‬هو الشخص اللي دوره يضمن إن الكود ده متوافق مع معايير الجودة وبيعمل االختبارات الالزمة لضمان جودته‪.‬‬
‫‪ .b‬بيبقى مسؤول عن التأكد إن الكود هينفذ الوظائف المطلوبة منه بدون ما يظهر أخطاء‪.‬‬

‫الـ ‪ Code Inspection‬عادةً بتكون أكثر رسمية وبتكون فيها قائمة فحص )‪ (checklist‬محددة علشان تضمن أن كل الجوانب‬
‫المهمة في الكود تم مالحظتها ‪.‬‬

‫‪Summary in English:‬‬

‫‪Inspection is a more comprehensive process than a walk-through.‬‬

‫‪It involves a team of four people.‬‬
‫‪:The key participants are‬‬
‫‪The person who created the software. :Designer‬‬
‫‪The person responsible for ensuring the quality of the software :Tester‬‬

‫شرح مراحل ‪Code Reviews/Inspections :‬‬

‫الـ ‪) Inspection‬تفتيش الكود( بيتكون من خمس مراحل رسمية‪ ،‬كل مرحلة ليها هدف معين علشان نقدر نعمل فحص دقيق للكود أو‬
‫المواصفات ‪.‬‬

‫المرحلة ‪( Overview :1‬نظرة عامة)‬

‫في المرحلة دي‪ ،‬الشخص المسؤول عن كتابة الكود أو التصميم‪ ،‬اللي هو المصمم )‪ ،(Designer‬بيجهز وثيقة نظرة عامة‬ ‫•‬
‫عن المنتج‪.‬‬
‫الوثيقة دي بتحتوي على تفاصيل مهمة عن المواصفات أو التصميم أو الكود أو الخطة‪ ،‬وهي بتكون األساس اللي هنعتمد عليه‬ ‫•‬
‫في الفحص‪.‬‬
‫الهدف هنا هو تقديم صورة عامة للمنتج عشان الفريق يقدر يبدأ يراجع الكود أو المواصفات بنا ًء على فكرة واضحة عن‬ ‫•‬
‫المنتج‪.‬‬

‫المرحلة ‪( Preparation :2‬التحضير)‬

‫في المرحلة دي‪ ،‬المختبر )‪ (Tester‬بيبدأ يقرأ الوثيقة بعناية ويفهمها بالتفصيل‪.‬‬ ‫•‬
‫الزم يكون عنده قائمة فحص )‪ (checklist‬تحتوي على أنواع األخطاء الشائعة في التفتيشات دي‪ ،‬ويكون األخطاء دي‬ ‫•‬
‫مرتبة حسب التكرار‪.‬‬
‫الفكرة هنا هي إن المختبر يركز على األخطاء األكثر شيوعا ً ويحاول يكتشفها أثناء المراجعة‪.‬‬ ‫•‬
 ‫المرحلة ‪( Inspection :3‬التفتيش الفعلي)‬

‫في المرحلة دي بيحصل اجتماع بين الفريق‪ ،‬وفيه بيتم عمل ‪ Walk-through‬للوثيقة أو الكود المراجع‪.‬‬ ‫•‬
‫الهدف من االجتماع ده هو التأكد من إن كل بند في قائمة الفحص )‪ (checklist‬تم تغطيته بشكل كامل‪.‬‬ ‫•‬
‫كل شخص في الفريق بيدقق في النقاط المحددة في القائمة عشان يتأكد من إنها مطبقة بشكل صحيح‪.‬‬ ‫•‬

‫المرحلة ‪( Rework :4‬إعادة العمل)‬

‫بعد االجتماع‪ ،‬لو تم اكتشاف أخطاء أو قضايا خالل الـ ‪ ،Walk-through‬الزم يتم حلها‪.‬‬ ‫•‬
‫في المرحلة دي‪ ،‬الفريق يبدأ في إصالح كل األخطاء اللي تم تحديدها‪ ،‬وده يشمل إعادة كتابة أجزاء من الكود أو تعديل‬ ‫•‬
‫المواصفات حسب الحاجة‪.‬‬

‫المرحلة ‪( Follow-up :5‬المتابعة)‬

‫في المرحلة األخيرة‪ ،‬قائد الفريق اللي بيقود التفتيش الزم يتأكد من إن كل القضايا تم حلها‪.‬‬ ‫•‬
‫الزم يتأكد من إنه مفيش حاجة مفتوحة أو ناقصة‪.‬‬ ‫•‬
‫وأيضاً‪ ،‬بيجب عليه إعداد تقرير نهائي يعرض فيه كل األخطاء اللي تم اكتشافها وكيف تم حلها‪ ،‬وأي تفاصيل تانية مهمة عن‬ ‫•‬
‫العملية‪.‬‬

‫‪Summary in English:‬‬

‫‪The Designer prepares an overview document detailing the product :Overview - Stage 1‬‬
‫‪or plan. ,code ,design ,specifications‬‬
‫‪The Tester must thoroughly understand the document and have a :Preparation - Stage 2‬‬
‫‪checklist of common fault types ranked by frequency to guide their focus during the review.‬‬
‫‪A meeting is held to walk through the document and ensure every item in :Inspection - Stage 3‬‬
‫‪the checklist is covered.‬‬
‫‪all identified faults and issues are resolved. ,After the meeting :Rework - Stage 4‬‬
‫‪The leader ensures all issues have been addressed and prepares a final :Follow-up - Stage 5‬‬
‫‪report.‬‬

‫‪Formal Methods and Testing :‬‬

‫الطرق الرسمية )‪ (Formal Methods‬بتعتمد على أدوات رياضية لتحليل الكود والتصاميم عشان نقدر نثبت صحة الكود أو التصميم‬
‫بشكل دقيق‪ .‬الهدف منها هو التأكد إن الكود أو التصميم بيحقق الخصائص المطلوبة وبيشتغل بالشكل الصحيح بدون أخطاء‪.‬‬

‫أمثلة على الطرق الرسمية‪:‬‬

‫‪ :#Microsoft’s Spec‬ده مثال على أداة رياضية من ‪ #Spec .Microsoft‬هي لغة برمجة تعتبر امتداد للغة ‪،#C‬‬ ‫•‬

‫الطرق دي بتعتبر دقيقة جداً ألنها مش بتعتمد على التجارب أو االختبارات التقليدية‪ ،‬ولكن على إثباتات رياضية‪ ،‬عشان نثبت إن الكود‬
‫بيشتغل بشكل صحيح في كل الحاالت الممكنة‪.‬‬
 ‫‪Summary in English:‬‬

‫‪Formal Methods use mathematical tools to prove the correctness of designs and‬‬ ‫•‬
‫‪source code.‬‬
‫‪Microsoft’s Spec# is a tool that extends C# :Example‬‬ ‫•‬

‫شرح ‪Model Checking and Program Verification :‬‬

‫من منظور االختبار‪ ،‬في نوعين أساسيين من الطرق الرسمية اللي بنستخدمها لتحليل الكود‪:‬‬

‫‪( Model Checking .1‬التحقق من النموذج)‪:‬‬

‫‪ Model checking‬بيستخدم علشان يتأكد من صحة التصميم المجرد‪.‬‬ ‫•‬

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

‫‪( Program Verification .2‬التحقق من البرنامج)‪:‬‬

‫‪ Program verification‬بيتم بشكل ثابت عشان نتأكد إن البرنامج بيحقق المواصفات اللي تم تحديدها‪.‬‬ ‫•‬
‫فيه مستويين من التحقق‪:‬‬ ‫•‬
‫‪ o‬المستوى العالي (‪ :)High level‬ده بيتم علشان نتحقق من إن الطرق في البرنامج متناسقة مع بعض وإنها‬
‫تتفاعل بشكل صحيح علشان تحقق مواصفات الفئة (‪class specification).‬‬
‫‪ o‬المستوى المنخفض (‪ :)Low level‬ده بيتم علشان نتحقق من إن الكود الخاص بكل طريقة (‪)method‬‬
‫بيحقق المواصفات الخاصة بها‪.‬‬

‫الفرق بين النموذج والتحقق من البرنامج‪:‬‬

‫‪ Model checking‬بيكون على تصميم مجرد‪ ،‬بينما ‪ Program verification‬بيكون على البرنامج نفسه لضمان‬ ‫•‬
‫تحقيقه للمواصفات‪.‬‬

‫‪Summary in English:‬‬

‫‪ensuring it ,Model Checking is used to verify the correctness of an abstract design .1‬‬
‫‪meets requirements.‬‬
‫‪:Program Verification checks that a program meets its specification .2‬‬
‫‪Ensures methods are consistent and interact correctly to meet class :High level .a‬‬
‫‪specifications.‬‬
‫‪Ensures the code for each method satisfies its specification. :Low level .b‬‬
 ‫شرح ‪ Advantages & Disadvantages‬للمراجعة الثابتة )‪Static Verification) :‬‬

‫المزايا‪:‬‬

‫التحقق الثابت بيوفر فائدة كبيرة ألنه يثبت صحة البرنامج لجميع قيم المدخالت المحتملة‪ ،‬مش بس المدخالت اللي تم‬ ‫•‬
‫اختيارها لالختبار‪.‬‬
‫ً‬
‫‪ o‬يعني‪ ،‬البرنامج لو اتحقق ثابتا‪ ،‬هيكون صحيح في جميع الحاالت الممكنة‪ ،‬سواء كانت حاالت اختبارات معينة أو‬
‫حاالت غير متوقعة ‪.‬‬

‫العيوب‪:‬‬

‫‪ .1‬بعض الحاالت بتحتاج مساعدة إلتمام اإلثباتات ‪:‬‬

‫‪ .a‬في بعض األحيان‪ ،‬األدوات مش قادرة تثبت صحة البرنامج بشكل كامل‪ ،‬وبتحتاج مساعدة بشرية أو تدخل إضافي‬
‫إلكمال اإلثباتات‪.‬‬
‫‪ .2‬مش كل اإلنشاءات البرمجية مدعومة من األدوات‪:‬‬
‫‪ .a‬معظم األدوات الحالية مفيش دعم كامل لكل أنواع اإلنشاءات البرمجية‪ .‬في بعض األحيان‪ ،‬قد تكون األدوات غير‬
‫قادرة على التحقق من كل مكون في البرنامج‪.‬‬
‫‪ .3‬األدوات بتأخر عن مواكبة اللغات الجديدة‪:‬‬
‫‪ .a‬األدوات المتاحة حاليا ً غالبا ً ما تكون أبطأ من تطور لغات البرمجة الحديثة‪ ،‬يعني قد تأخذ وقت طويل لتطوير‬
‫األدوات لتدعم اللغات الجديدة أو المزايا الحديثة‪.‬‬

‫‪Summary in English:‬‬

‫‪not just ,Static verification proves correctness for all possible input values :Advantages‬‬
‫‪selected test cases.‬‬
‫‪:Disadvantages‬‬
‫‪Some cases require assistance to complete proofs.‬‬
‫‪Not all program constructs are supported by most tools.‬‬
‫‪Tools tend to lag behind programming languages.‬‬

‫‪ Tools and Languages‬و ‪Use in Software Development :‬‬

‫األدوات واللغات ‪:‬‬

‫‪Why3 language and toolset:‬‬ ‫‪.1‬‬

‫‪ Why3 .a‬هي لغة وأداة بيدعموها علشان التحقق الثابت للكود‪.‬‬
‫‪ .b‬بتدعم كل من ‪ Java‬و ‪ ،++C‬يعني ممكن تستخدمها علشان تتحقق من صحة البرامج المكتوبة باللغتين دول‪.‬‬
‫‪Verifast:‬‬ ‫‪.2‬‬
‫‪ Verifast .a‬هو أداة وبيستخدم للتحقق الثابت للبرامج المكتوبة بـ ‪C.‬‬
‫‪AutoProof:‬‬ ‫‪.3‬‬
‫‪ AutoProof .a‬هو أداة للتحقق من صحة البرامج المكتوبة بـ ‪ ،Eiffel‬وهي لغة موجهة للكائنات‪.‬‬
‫‪SPARK:‬‬ ‫‪.4‬‬
‫‪ SPARK .a‬هي أداة للتحقق من صحة البرامج المكتوبة بـ ‪ ،ADA‬وهي لغة بتستخدم في البرمجة في األنظمة‬
‫الحرجة‪.‬‬
 ‫‪JML language and toolset: .5‬‬
‫‪ JML .a‬هي لغة وأداة بيدعموها ‪ ،Java‬بتساعد في التحقق الثابت للبرامج المكتوبة بالـ ‪Java.‬‬

‫استخدامها في تطوير البرمجيات‪:‬‬

‫واحد من العمليات المحتملة هو استخدام أداة التحقق من البرنامج بدالً من أغلب اختبارات الوحدة )‪.(Unit Tests‬‬ ‫•‬
‫‪ o‬الفكرة هنا إنك ممكن تعتمد على التحقق الثابت عشان تتأكد من صحة البرنامج في بداية مراحل التطوير بدالً من‬
‫االعتماد على اختبارات الوحدة التقليدية اللي بتختبر حاالت معينة من المدخالت‪.‬‬
‫‪ o‬ده ممكن يقلل من وقت االختبار ويزيد من موثوقية البرنامج ألنه بيغطي جميع الحاالت الممكنة‪.‬‬

‫‪Summary in English:‬‬

‫‪Tools and Languages:‬‬

‫‪.++Why3 supports Java and C‬‬

‫‪Verifast supports C.‬‬
‫‪AutoProof supports Eiffel.‬‬
‫‪SPARK supports ADA.‬‬
‫‪JML supports Java.‬‬

‫‪One possible process is using a program verifier in place of :Use in Software Development‬‬
‫‪most unit tests for ensuring correctness in early stages of development.‬‬

‫يعني إيه ‪Dynamic Verification‬؟‬

‫‪ Dynamic Verification‬أو اللي بنسميه اختبار البرمجيات )‪ (Software Testing‬بيهدف لتأكيد إن البرنامج‬ ‫•‬
‫بيشتغل بشكل صحيح‪.‬‬
‫ده بيتم عن طريق تنفيذ البرنامج فعليا ومالحظة النتائج عشان نتأكد إنها متوافقة مع اللي متوقعينه‪.‬‬ ‫•‬

‫إزاي بيتم؟‬

‫بيتم االعتماد على بيانات االختبار )‪Test Data):‬‬ ‫•‬

‫‪) Input values o‬قيم المدخالت(‪ :‬القيم اللي بندخلها للبرنامج أثناء االختبار‪.‬‬
‫‪) Expected Output values o‬قيم اإلخراج المتوقعة(‪ :‬النتائج اللي المفروض البرنامج يطلعها بنا ًء على‬
‫المدخالت‪.‬‬
‫البيانات دي بتتحدد بنا ًء على مجموعة حاالت االختبار )‪ ،(Test Cases‬واللي بتتضمن سيناريوهات مختلفة عشان نغطي‬ ‫•‬
‫جميع الحاالت المحتملة‪.‬‬

‫‪Summary in English:‬‬

‫‪Dynamic Verification (Software Testing) confirms the program’s correct operation by executing‬‬
‫‪it.‬‬
‫‪Test data (input and expected output values) is derived from a set of test cases.‬‬
 ‫الفرق بين ‪ Black-Box‬و ‪White-Box Testing:‬‬

‫‪Black-Box Testing: .1‬‬

‫‪ .a‬هنا االختبار بيتم بدون معرفة الكود الداخلي للبرنامج‪.‬‬
‫‪ .b‬بنختبر المخرجات اللي البرنامج بيطلعها بنا ًء على المدخالت‪ ،‬من غير ما نعرف تفاصيل تنفيذ البرنامج‪.‬‬
‫‪White-Box Testing: .2‬‬
‫‪ .a‬في النوع ده‪ ،‬بنكون عندنا معرفة تفصيلية بالكود الداخلي‪.‬‬
‫‪ .b‬الهدف هو اختبار منطق الكود‪ ،‬وبنتأكد إن كل جزء من الكود شغال بشكل صحيح‪.‬‬

‫االستخدام في مراحل التطوير المختلفة‪:‬‬

‫‪Unit Testing:‬‬ ‫•‬

‫‪ o‬لما الكود لسه بيتكتب‪ ،‬بنستخدم ‪ White-Box‬الختبار التفاصيل الداخلية‪.‬‬
‫‪ o‬بنقدر كمان نستخدم ‪ Black-Box‬لو بنختبر الوحدات بشكل منفصل بنا ًء على المدخالت والمخرجات ‪.‬‬
‫‪Integration Testing:‬‬ ‫•‬
‫‪ o‬لما نبدأ نضيف كود جديد للسيستم بشكل تدريجي‪ ،‬نختبر إن األجزاء الجديدة شغالة بشكل متكامل مع األجزاء‬
‫القديمة‪.‬‬
‫‪ o‬ممكن نستخدم النوعين )‪ Black-Box‬و ‪ (White-Box‬عشان نضمن التكامل‪.‬‬
‫‪System Testing:‬‬ ‫•‬
‫‪ o‬مع كل إصدار نهائي للسيستم‪ ،‬نعمل اختبار شامل للتأكد إن النظام كله شغال زي ما متوقع‪.‬‬
‫‪ o‬هنا بنركز أكتر على ‪ Black-Box Testing‬عشان نختبر الوظائف النهائية للمستخدم‪.‬‬

‫‪Summary in English:‬‬

‫‪Tests without knowledge of the internal code; focuses on input and output. :Black-Box Testing‬‬

‫‪Tests with detailed knowledge of the internal code; focuses on code logic. :White-Box Testing‬‬

‫‪Applied to:‬‬

‫‪During code development. :Unit Testing‬‬

‫‪As new code is added to the system. :Integration Testing‬‬
‫‪For each release of the final system. :System Testing‬‬

‫الفرق بين ‪ Black-Box Testing‬و ‪White-Box Testing :‬‬

‫‪( Black-Box Testing‬اختبار الصندوق األسود)‪:‬‬

‫يُعرف كـ ‪ Specification-Based‬أو ‪:Functional Testing‬‬ ‫•‬

‫‪ o‬بنعتمد على المواصفات )‪ (Specifications‬من غير أي معرفة بـ الكود الداخلي‪.‬‬
‫‪ o‬الهدف هو اختبار الوظائف والتأكد إن البرنامج بينفذ المطلوب بنا ًء على الوصف‪.‬‬
‫إزاي بنختبر؟‬ ‫•‬
 ‫بنقارن المخرجات بـ المواصفات عشان نكتشف األخطاء اللي بتحصل لما التنفيذ مش متطابق مع الوصف‪.‬‬ ‫‪o‬‬
‫بنختار مجموعة فرعية من المدخالت الممكنة الختبارها‪ ،‬ومش بنركز على التفاصيل الداخلية للبرنامج‪.‬‬ ‫‪o‬‬

‫‪( White-Box Testing‬اختبار الصندوق األبيض)‪:‬‬

‫يُعرف كـ ‪ Implementation-Based‬أو ‪Structural Testing:‬‬ ‫•‬

‫‪ o‬بيعتمد على تنفيذ الكود )‪ (Implementation‬عشان نصمم االختبارات ‪.‬‬
‫‪ o‬الهدف هو تحليل هيكل الكود واكتشاف األخطاء في منطق البرنامج أو تركيبه‪.‬‬
‫إزاي بنختبر؟‬ ‫•‬
‫‪ o‬بنفهم إزاي البرنامج بيشتغل ونصمم االختبارات عشان نشغل مكونات معينة داخل الكود‪.‬‬
‫‪ o‬بيتم تقييم االختبار بنا ًء على تغطية الكود )‪Coverage Criteria).‬‬

‫الفرق بين ‪ Black-Box Testing‬و ‪White-Box Testing :‬‬

‫‪Black-Box Testing:‬‬

‫بيعتمد فقط على المواصفات )‪ (Specifications‬لتصميم االختبارات‪.‬‬ ‫‪.1‬‬

‫االختبارات دي ممكن تتعاد وتُستخدم تاني لو الكود اتعدل عشان يصلح خطأ أو يضيف وظيفة جديدة‪.‬‬ ‫‪.2‬‬
‫تصميم االختبارات هنا مش محتاج الكود يكون مكتوب‪ ،‬لكن بيعتمد على وجود المواصفات فقط‪.‬‬ ‫‪.3‬‬
‫مش بيضمن إن كل مكونات الكود اتنفذت؛ وبالتالي ممكن يحصل أخطاء من نوع "‪) "errors of commission‬أي‬ ‫‪.4‬‬
‫أخطاء تنفيذية(‪.‬‬
‫صعب قياس كفاءة االختبارات أو معرفة إذا كانت غطت كل جوانب المواصفات وال أل‪.‬‬ ‫‪.5‬‬

‫‪White-Box Testing:‬‬

‫بيعتمد على الكود والمواصفات معا لتصميم االختبارات‪.‬‬ ‫‪.1‬‬

‫أي تغيير في الكود بيبطل صالحية االختبارات الحالية؛ ألنها مصممة بنا ًء على الكود الموجود‪.‬‬ ‫‪.2‬‬
‫الزم الكود يكون مكتوب قبل ما نبدأ تصميم االختبارات‪.‬‬ ‫‪.3‬‬
‫بيضمن إن كل المكونات المختارة من الكود تم تنفيذها‪ ،‬لكنه مش بيضمن تغطية كل المواصفات؛ وبالتالي ممكن يحصل‬ ‫‪.4‬‬
‫أخطاء من نوع "‪) "errors of omission‬أي أخطاء إغفال(‪.‬‬
‫سهل قياس كفاءة االختبارات وتحديد نسبة الكود اللي تم تغطيته باستخدام أدوات آلية‪.‬‬ ‫‪.5‬‬

‫‪Summary in English:‬‬

‫‪Black-Box Testing:‬‬ ‫•‬

‫‪Relies only on specifications. o‬‬
‫‪Tests can be reused after code updates. o‬‬
‫‪Does not ensure all code components are exercised (commission errors). o‬‬
‫‪Measuring effectiveness is difficult. o‬‬
‫‪White-Box Testing:‬‬ ‫•‬
‫‪Relies on both specifications and code. o‬‬
 ‫‪Tests are invalidated by code changes.‬‬ ‫‪o‬‬
‫‪Ensures selected components are exercised but may miss some specifications‬‬ ‫‪o‬‬
‫‪(omission errors).‬‬
‫‪Measuring effectiveness is easier.‬‬ ‫‪o‬‬

‫أنواع األخطاء في االختبار ))‪Errors in Testing‬‬

‫‪( Errors of Omission .1‬أخطاء اإلغفال)‪:‬‬

‫معناها‪ :‬إن المطور ماعملش حاجة كان المفروض تتعمل‪ ،‬زي إنه ينسى يضيف وظيفة معينة أو يسيب جزء من المواصفات‬ ‫•‬
‫مش منفذ‪.‬‬
‫المثال‪ :‬في مشروع‪ ،‬لو كان مطلوب إن البرنامج يضيف خاصية تسجيل دخول ومافيش أي كود ليها‪ ،‬ده بيعتبر خطأ إغفال‪.‬‬ ‫•‬
‫العالقة بـ ‪:White-box Testing‬‬ ‫•‬
‫‪ o‬ألن االختبار ده بيركز على الكود المكتوب‪ ،‬ممكن ما يالحظش إن فيه حاجات ناقصة أو غير مكتملة في‬
‫المواصفات ‪.‬‬

‫‪( Errors of Commission .2‬أخطاء التنفيذ)‪:‬‬

‫معناها‪ :‬المطور عمل حاجة غلط أو أضاف حاجة زيادة عن المطلوب‪.‬‬ ‫•‬
‫المثال‪ :‬لو البرنامج بيضيف خاصية مش موجودة في المواصفات‪ ،‬أو لو الوظيفة المكتوبة بتخرج نتيجة مش صحيحة‪.‬‬ ‫•‬
‫العالقة بـ ‪:Black-box Testing‬‬ ‫•‬
‫ً‬
‫‪ o‬النوع ده بيركز على التحقق من الوظائف مقارنة بالمواصفات‪ ،‬وبالتالي ممكن ما يكتشفش المشاكل اللي جوا الكود‬
‫أو وجود حاجات زيادة عن اللزوم‪.‬‬

‫الفرق بين ‪ White-box Testing‬و ‪ Black-box Testing‬من حيث األخطاء‪:‬‬

‫‪:White-box Testing .1‬‬

 .‫ بيركز على الهيكل الداخلي للبرنامج والكود نفسه‬.a
. ‫ ألن تركيزه بيكون على اللي مكتوب مش اللي ناقص‬،(Omission) ‫ أخطاء اإلغفال‬:‫ مش بيكتشف‬.b
:Black-box Testing .2
.‫ بيركز على التحقق من الوظائف زي ما هو مذكور في المواصفات‬.a
.‫ ألنه مش بيدخل في تفاصيل الكود أو بنيته‬،(Commission) ‫ أخطاء التنفيذ‬:‫ مش بيكتشف‬.b

:‫ملخص مهم باإلنجليزي‬

Errors of Omission: .1
Occur when required functionality is missing. .a
not ,Common in White-box Testing because it focuses on the written code .b
what’s missing.
Errors of Commission: .2
Occur when there is extra or incorrect functionality. .a
Common in Black-box Testing because it focuses on functionality without .b
delving into the internal code structure.

Key Weaknesses:

Does not detect omission errors (missing functionality). :White-box Testing •

Does not detect commission errors (extra or incorrect functionality). :Black-box Testing •
 ‫‪Slide 25,26,27,28,29 in ch2‬‬

‫الجزء ده بيتكلم عن ‪ Test Approaches‬أو طرق االختبار اللي بنستخدمها لقياس جودة البرمجيات‪ ،‬وبيوضح ‪ 3‬طرق أساسية في‬
‫االختبار‪:‬‬

‫‪ .1‬االختبار باالعتماد على المواصفات (‪Black-Box Testing(:‬‬

‫الفكرة األساسية هنا إنك تختبر البرنامج بنا ًء على المواصفات )التعليمات أو المتطلبات( اللي مكتوبة من غير ما تشوف أو‬ ‫•‬
‫تدخل في تفاصيل الكود اللي مكتوب‪.‬‬
‫يعني باختصار‪ ،‬بنعمل اختبارات على أساس "المواصفات" بتاعة البرنامج بس‪ ،‬مش بنشوف الكود اللي بيشتغل من وراه ‪.‬‬ ‫•‬
‫الهدف هنا هو التأكد من أن كل قيمة في المدخالت )‪ (inputs‬بتترجم بشكل صحيح وتدي نتائج صحيحة في المخرجات‬ ‫•‬
‫)‪outputs).‬‬
‫فيه شوية طرق لعمل االختبارات دي زي‪:‬‬ ‫•‬
‫‪ o‬االختبار ضد المواصفات‪ :‬يعني بنشوف إذا كانت النتائج بتتوافق مع اللي مكتوب في المواصفات‪.‬‬
‫‪ o‬استخدام معايير تغطية اختبار بناء على المواصفات‪ :‬بتتأكد إن كل حاجة مكتوبة في المواصفات معمولة بشكل‬
‫صحيح‪.‬‬
‫‪ o‬تطوير حاالت اختبار مشتقة من المواصفات‪ :‬يعني بنعمل اختبارات على أساس ما هو مكتوب في الوثائق‪.‬‬
‫العيب هنا‪:‬‬ ‫•‬
 ‫من الصعب قياس درجة التغطية الختبارات ‪ Black-Box‬تلقائيًا‪ .‬يعني صعب نعرف إذا كنا غطينا كل حاجة في‬ ‫‪o‬‬
‫المواصفات وال أل‪.‬‬
‫بنعتمد على جودة عمل الشخص اللي بيعمل االختبار بشكل كبير عشان نقدر نحقق نتائج دقيقة‪ .‬لو االختبار مش‬ ‫‪o‬‬
‫مضبوط‪ ،‬النتيجة هتكون مش دقيقة‪.‬‬

‫‪ .2‬االختبار باالعتماد على التنفيذ (‪White-Box Testing(:‬‬

‫ده نوع آخر من االختبارات اللي بيركز على فحص الكود نفسه‪ ،‬بمعنى إنك تختبر البرمجيات بنا ًء على التنفيذ الفعلي للكود‪.‬‬ ‫•‬
‫هنا بنشوف هل الكود بيشتغل صح وال أل‪ ،‬وده بيضمن إن كل جزء من الكود اتنفذ بشكل صحيح‪.‬‬ ‫•‬

‫‪ .3‬إدخال األخطاء (‪ )Fault Insertion‬أو اختبار الطفرات (‪Mutation Testing(:‬‬

‫ده نوع من االختبارات بيستخدم عشان يكتشف األخطاء في النظام‪.‬‬ ‫•‬

‫بنقوم بإدخال تغييرات )أو "طفرات"( عشوائية في الكود اللي بيشتغل وبنشوف إذا كان البرنامج قادر على اكتشاف األخطاء‬ ‫•‬
‫دي وال أل‪.‬‬

‫ملخص النقاط المهمة باإلنجليزي‪:‬‬

‫‪Test Approaches aim to measure software quality. .1‬‬

‫‪:Black-Box Testing .a‬‬
‫‪Tests based on specifications without looking at the code. .i‬‬
‫‪Ensures that input values map to correct output values. .ii‬‬
‫‪relies on tester’s quality. ,Difficult to measure coverage automatically .iii‬‬
‫‪White-Box Testing: .2‬‬
‫‪Focuses on testing the implementation (code itself). .a‬‬
‫‪Fault Insertion (Mutation Testing): .3‬‬
‫‪Introduces errors to measure testing quality and detect faults. .a‬‬

‫‪.‬‬
 ‫عملية تصميم االختبار )‪ (Test Design Process‬هي الخطوات اللي بنمشي عليها عشان نختبر السوفت وير بشكل فعال‪ .‬الهدف‬
‫األساسي هو إننا نحدد البيانات اللي هنستخدمها في االختبار )‪ (Test Data‬ونحدد المدخالت )‪ (Inputs‬والمخرجات المتوقعة‬
‫)‪Expected Outputs).‬‬

‫المراحل األساسية في تصميم االختبار‪:‬‬

‫‪ .1‬تحليل البرنامج اللي هنختبره )‪SUT): - Analysing the Software Under Test‬‬
‫‪ .a‬الزم األول نعمل تحليل للبرنامج اللي هنختبره‪ ،‬سواء كان عن طريق تحليل الكود المصدر )‪ (Source Code‬أو‬
‫المواصفات )‪Specifications).‬‬
‫‪ .b‬التحليل ده بيطلع نتائج بنستخدمها في تحديد حاالت االختبار‪.‬‬
‫‪ .2‬توليد حاالت االختبار ) ‪Generating Test Cases):‬‬
‫‪ .a‬حاالت االختبار هي الحاجات اللي المفروض "نتأكد منها" أثناء االختبار‪.‬‬
‫‪ .b‬توليد الحاالت بيشمل تحديد الحاالت دي ووصف االختبارات اللي تغطيها‪.‬‬

‫أمثلة على حاالت االختبار‪:‬‬

‫‪ .c‬قيمة معينة أو نطاق معين للقيم اللي بياخدها بارامتر‪.‬‬

‫‪ .d‬عالقة معينة بين بارامترين‪.‬‬
‫‪ .e‬سطر كود معين يتم تنفيذه‪.‬‬
‫‪ .f‬مسار معين في الكود يتم اتخاذه‪.‬‬

‫مالحظات‪:‬‬

‫‪ .g‬ممكن اختبار واحد يغطي أكتر من حالة اختبار‪.‬‬

‫ عشان نغطي أكتر عدد من الحاالت بنفس‬،‫( قدر اإلمكان‬Generic) ‫ القيم المستخدمة في وصف الحالة تكون عامة‬.h
.‫االختبار‬

:‫أنواع حاالت االختبار‬

Normal Cases). ) ‫ حاالت عادية‬.i

Error Cases).) ‫ حاالت خطأ‬.j
‫ لكن ماينفعش ندمج أكتر من حالة خطأ في اختبار‬،‫ ممكن ندمج أكتر من حالة عادية في اختبار واحد‬:‫ مالحظة‬.k
.‫واحد‬
Generating Test Data):) ‫ توليد بيانات االختبار‬.3
.‫ دي البيانات اللي هنستخدمها كمدخالت أثناء تنفيذ االختبار‬.a
Implementing the Tests):) ‫ تنفيذ االختبارات‬.4
.‫ في المرحلة دي بننفذ االختبارات اللي جهزناها ونشوف النتائج‬.a

:‫مالحظات إضافية‬

:(Unique Identifier) ‫معرف فريد‬ ّ ‫كل حالة اختبار الزم يكون ليها‬ •
"EP-001" ‫ ممكن نستخدم معرف زي‬،(Equivalence Partitioning) ‫ لو بنستخدم تقنية تقسيم التماثل‬:‫ مثال‬o
.‫للحالة األولى‬

:‫ملخص النقاط المهمة باإلنجليزي‬

Test Design Process includes four main stages: .1

Analyzing the Software Under Test (SUT). .a
Generating test cases. .b
Generating test data. .c
Implementing the tests. .d
Key aspects of each stage: .2
Determines test cases by examining the source code or specification. :Analysis .a
:Test Cases .b
or relationships. ,code paths ,Cover specific items like parameter values .i
Divided into normal cases and error cases. .ii
Use generic values for flexibility. .iii
Require unique identifiers (e.g., EP-001 for Equivalence Partitioning). .iv
Inputs for testing. :Test Data .c
Execution of prepared tests. :Implementation .d
Goals: .3
Reduce the number of tests while maximizing coverage. .a
Ensure error cases result in corresponding error outputs. .b

Generating Test Data(:( ‫توليد بيانات االختبار‬

Test Cases).) ‫البيانات المستخدمة في االختبار بتكون معتمدة على الحاالت اللي االختبار بيغطيها‬ •
:(Normal Cases) ‫ للحاالت العادية‬o
 ‫▪ االختبار الواحد المفروض يغطي أكبر عدد ممكن من الحاالت ‪.‬‬
‫‪ o‬للحاالت الخطأ )‪:(Error Cases‬‬
‫▪ االختبار الزم يغطي حالة واحدة فقط بالضبط‪.‬‬
‫الهدف األساسي هو التأكد إن كل حاالت االختبار مغطاة بالكامل ‪.‬‬ ‫•‬
‫اختيار البيانات بطريقة تقلل عدد االختبارات المطلوبة يعتبر مهارة مهمة‪.‬‬ ‫•‬

‫مواصفات االختبار الزم تشمل‪:‬‬

‫تعريف الـ ‪) SUT‬اسم البرنامج ورقم النسخة(‪.‬‬ ‫‪.1‬‬

‫معرف فريد لكل اختبار )زي ‪ T001‬لالختبار األول(‪.‬‬ ‫ّ‬ ‫‪.2‬‬
‫قائمة بحاالت االختبار اللي كل اختبار بيغطيها‪.‬‬ ‫‪.3‬‬
‫بيانات االختبار )‪:(Test Data‬‬ ‫‪.4‬‬
‫‪ .a‬مدخالت )‪ :(Input Values‬قيم واضحة ومحددة‪.‬‬
‫‪ .b‬المخرجات المتوقعة )‪ :(Expected Output‬مستمدة من المواصفات وليس من الكود‪.‬‬

‫تنفيذ االختبارات (‪Implementing Tests(:‬‬

‫االختبارات ممكن تتنفذ كـ كود )‪ (Automated Tests‬أو كـ إجراءات يدوية )‪.(Manual Tests‬‬ ‫•‬
‫‪ :Unit Tests o‬داي ًما أوتوماتيكية‪.‬‬
‫‪ :Integration Tests o‬غالبًا أوتوماتيكية‪.‬‬
‫‪ :System Tests o‬أوتوماتيكية على قد ما نقدر‪.‬‬

‫خطوات تنفيذ االختبار األوتوماتيكي‪:‬‬

‫‪ .1‬كتابة كود لتشغيل ‪ SUT‬باستخدام المدخالت المحددة ‪.‬‬

‫‪ .2‬مقارنة الناتج الفعلي )‪ (Actual Output‬بالناتج المتوقع )‪Expected Output).‬‬

‫تحليل مواصفات البرنامج (‪Analysis of Software Specifications(:‬‬

‫العناصر اللي الزم تتحلل أثناء االختبار‪:‬‬

‫‪) Parameters .1‬البارامترات(‪:‬‬

‫‪ .a‬البارامترات الصريحة )‪ :(Explicit‬اللي بنمررها أثناء استدعاء الميثود‪.‬‬
‫‪ .b‬البارامترات الضمنية )‪ :(Implicit‬زي المتغيرات العامة )‪Global Variables).‬‬
‫‪ .c‬الزم نختبر النوعين‪.‬‬
‫‪) Parameter Ranges .2‬نطاقات القيم(‪:‬‬
‫‪ .a‬النطاق الطبيعي )‪ :(Natural Ranges‬بنا ًء على نوع البارامتر )‪Type).‬‬
‫‪ .b‬النطاقات المبنية على المواصفات )‪ (Specification-based ranges‬أو "تقسيم التماثل ) ‪Equivalence‬‬
‫‪".(Partitions‬‬

‫نطاقات البارامترات (‪Parameter Ranges(:‬‬

‫النطاق الطبيعي )‪Natural Ranges):‬‬ ‫•‬

‫‪ o‬القيم الطبيعية لنوع معين )مثال‪:(int :‬‬
‫▪ ‪Integer.MIN_VALUE..Integer.MAX_VALUE‬‬
 .‫ بتكون أكتر تعقيدًا‬Classes ‫ والـ‬Arrays ‫ زي الـ‬:(Compound Types) ‫ األنواع المركبة‬o
Equivalence Partitions):) ‫نطاقات مبنية على المواصفات‬ •
.‫( هو تقسيم النطاق لقيم متساوية في طريقة معالجتها‬EP) ‫ تقسيم التماثل‬o
boolean isNegative(int x) :‫ مثال‬o

.‫ لو غير كده‬false‫ و‬،‫ سالبة‬x ‫ لو‬true ‫ترجع‬ ▪

:‫ هنا‬EPs ‫الـ‬ ▪
true. ‫ ترجع‬:1-..Integer.MIN_VALUE •
false. ‫ ترجع‬:Integer.MAX_VALUE..0 •

Equivalence Partitions: ‫إرشادات الختيار الـ‬

Partition. ‫ كل قيمة ألي بارامتر الزم تكون ضمن‬.1

Partitions. ‫ مفيش قيم بين الـ‬.2
.‫ النطاق الطبيعي للبارامتر بيحدد الحدود العليا والدنيا لو المواصفات مش مذكورة‬.3

:‫ملخص النقاط المهمة باإلنجليزي‬

Test Data Generation: .1

Cover as many cases as possible in one test. :Normal Cases .a
Each test must cover exactly one case. :Error Cases .b
:Test specification includes the following .c
SUT identification (name and version). .i
Test identifier (e.g., T001). .ii
List of test cases covered. .iii
Test data (Input values and Expected output). .iv
Test Implementation: .2
Tests can be automated (code) or manual (procedures). .a
Unit tests are always automated; integration and system tests are mostly .b
automated.
:Automated tests involve .c
Writing code to invoke SUT with inputs. .i
expected output. .Comparing actual vs .ii
Software Specification Analysis: .3
Analyze parameters (explicit and implicit). .a
:Identify parameter ranges .b
Natural ranges (based on type). .i
Equivalence partitions (based on specification). .ii
Ensure every parameter value belongs to one partition. .c
Ch3

Selecting Equivalence Partitions:

‫ في البرنامج لمجموعات‬input ‫( دي عبارة عن تقسيم القيم اللي ممكن تدخل كـ‬Equivalence Partition (EP .1
.‫ بحيث كل مجموعة بتتعامل بنفس الطريقة‬،(partitions)
:Equivalence Partitions ‫ القواعد اللي الزم نراعيها لما بنحدد الـ‬.2
 ‫‪ .a‬كل قيمة ألي ‪ parameter‬الزم تكون ضمن ‪ Partition‬معين ‪.‬‬
‫‪ .b‬مفيش قيم بين الـ ‪ .Partitions‬يعني‪ ،‬يا إما القيمة تنتمي للـ ‪ ،Partition‬يا إما أل‪.‬‬
‫‪ .c‬الحدود العليا والسفلى للـ ‪ Partitions‬بتكون بنا ًء على ‪ natural range‬الخاص بالـ ‪ parameter‬إال لو الـ‬
‫‪ specification‬حددت حاجة مختلفة‪.‬‬

‫‪Boundary Values:‬‬

‫كل ‪ Equivalence Partition‬ليها قيم حدودية )‪ (Boundary Values‬زي‪:‬‬ ‫‪.1‬‬

‫‪ .a‬الحد العلوي )‪Upper Boundary).‬‬
‫‪ .b‬الحد السفلي )‪Lower Boundary).‬‬
‫األخطاء كتير بتحصل عند التعامل مع الحدود )‪ ،(limits‬عشان كده بنستخدم الـ ‪ Boundary Values‬كطريقة أكتر دقة‪.‬‬ ‫‪.2‬‬
‫مثال‪ :‬الميثود ‪:(boolean isNegative(int x‬‬ ‫‪.3‬‬
‫‪ .a‬القيم الحدودية للـ ‪ x‬هتكون‪:‬‬
‫‪Integer.MIN_VALUE. .i‬‬
‫‪.1- .ii‬‬
‫‪0 .iii‬‬
‫‪.1‬‬
‫‪Integer.MAX_VALUE. .iv‬‬
‫قواعد الختيار الـ ‪:Boundary Values‬‬ ‫‪.4‬‬
‫‪ .a‬كل ‪ parameter‬الزم يكون ليه حدود عليا وسفلى لكل ‪Partition.‬‬
‫‪ .b‬لو نوع البيانات ‪) contiguous‬متصل(‪ ،‬القيمة اللي بعد الحد األعلى للـ ‪ Partition‬بتكون الحد األدنى للـ‬
‫‪ Partition‬اللي بعده ‪.‬‬
‫‪ Natural range .c‬بيوفر الحدود القصوى والدنيا للقيم‪.‬‬
‫القيم الحدودية الزم متتداخلش مع بعض‪ ،‬ومفيش فجوة )‪ (gap‬بين الـ ‪Partitions.‬‬ ‫‪.5‬‬
‫مثال مختصر )‪:(Convenient shorthand‬‬ ‫‪.6‬‬
‫‪1[[0..Integer.MAX_VALUE[.-..Integer.MIN_VALUE[ :x .a‬‬
‫‪true[[false[.[ :return value .b‬‬

‫‪Combinations of Values:‬‬

‫‪ .1‬التحليل دا بيستخدم تقنيات زي ‪ Cause-Effect Graphs‬و‪ Decision Tables‬عشان نحصر كل تركيبات القيم‬
‫الممكنة اللي بتدخل للبرنامج )‪ (Input Causes‬وتأثيرها على المخرجات )‪Output Effects).‬‬
‫‪ .2‬بنعمل جدول للحقيقة )‪ (Truth Table‬عشان نحدد أقل عدد من التركيبات اللي يغطي كل السلوكيات المختلفة للبرنامج‪.‬‬
‫‪ .3‬عدد التركيبات الممكنة = ‪ ،2N2^N‬حيث ‪ NN‬هو عدد ‪independent causes.‬‬

‫‪( Causes and Effects‬مثال)‪:‬‬

‫لو عندك ميثود زي ‪:(boolean isNegative(int x‬‬ ‫•‬

‫‪ Cause o‬واحد فقط‪) x<0 :‬ممكن تكون ‪ true‬أو ‪false).‬‬
‫‪ Effect o‬واحد فقط‪ :‬القيمة المرجعة )‪) (return value‬ممكن تكون ‪ true‬أو ‪false).‬‬

‫مالحظات‪:‬‬

‫‪ .1‬لو عندك تعبيرات حصرية )‪ ،(Mutually Exclusive‬زي ‪ x<0‬و‪:x>=0‬‬

 .‫ ممكن تختصر بواحد منهم فقط‬،‫ مش محتاج تستخدم االتنين‬.a
‫ التعبير البسيط‬.‫ مش محتاجين‬variable==false‫ و‬variable==true ‫ التعبيرين‬،Boolean ‫ لو عندك متغير‬.2
false). ‫ أو‬true) ‫ ألنه بياخد قيمتين‬،‫ كفاية‬variable

:‫النقاط المهمة باإلنجليزي‬

Equivalence Partitions (EP): .1

Divide parameter values into groups where values in each group are processed .a
equivalently.
No gaps between partitions. .b
Natural range provides upper and lower bounds unless specified otherwise. .c
Boundary Values (BV): .2
Each EP has upper and lower boundary values. .a
Helps detect errors in limit handling. .b
and there are no gaps between partitions. ,Boundary values do not overlap .c
Combinations of Values: .3
Use techniques like Cause-Effect Graphs and Decision Tables. .a
Create truth tables to identify minimum test combinations. .b
where NN is the number of independent causes. ,Total combinations = 2N2^N .c
Causes and Effects: .4
Identify independent causes and their effects. .a
Mutually exclusive expressions can be simplified to one form. .b

:)‫ (جداول الحقيقة‬Truth Tables

Rules).) ‫( من خالل قواعد‬Effects) ‫( والتأثيرات‬Causes) ‫جدول الحقيقة هو طريقة بنستخدمها لتوضيح العالقة بين األسباب‬

‫؟‬Truth Table ‫إزاي بنستخدم‬

.‫( في الجدول بتمثل مجموعة معينة من األسباب اللي بتؤدي لمجموعة محددة من التأثيرات‬Rule) ‫ كل قاعدة‬.1
input causes).) ‫ الجدول بيوضح الحاالت المختلفة اللي ممكن تحصل بنا ًء على القيم المدخلة‬.2

Truth Table: ‫خطوات إنشاء‬

:(‫ )عرض األسباب‬Listing Causes .1

Row).) ‫ بنكتب كل سبب في صف مستقل‬.a
:(‫ )تحديد األعمدة للقواعد‬Identifying Columns for Rules .2
.‫ بنخصص عمود لكل تركيبة مختلفة من األسباب اللي بتؤدي لتأثير معين‬.a
:(‫ )القواعد كحاالت اختبار‬Rules as Test Cases .3
Test Case).) ‫( بيمثل حالة اختبار مختلفة‬Rule) ‫ كل عمود‬.a
 ‫مثال عملي‪:‬‬

‫لو عندنا ميثود بتتحقق من حالة معينة بنا ًء على ‪ 3‬أسباب ‪CC: ،BB ،AA‬‬

‫األسباب )‪:(Causes‬‬ ‫•‬

‫‪ :AA o‬الحالة األولى‪.‬‬
‫‪ :BB o‬الحالة التانية‪.‬‬
‫‪ :CC o‬الحالة التالتة‪.‬‬
‫التأثيرات )‪:(Effects‬‬ ‫•‬
‫‪ o‬الناتج النهائي لما يحصل تفاعل بين األسباب‪.‬‬

‫‪ “Don’t Care” Conditions‬بتشير إلى الحاالت اللي قيمة السبب (‪ )Cause‬فيها مش بتأثر على النتيجة (‪ .)Effect‬يعني‬
‫بغض النظر إذا كان السبب "‪ "True‬أو "‪ ،"False‬النتيجة هتكون هي هي‪.‬‬

‫فكرة الـ “‪ :Don’t Care” Conditions‬لما يكون السبب ملوش تأثير على النتيجة‪ ،‬بنسميها "حالة ال تهمنا"‪.‬‬ ‫•‬
‫‪ o‬الهدف منها هو تقليل عدد القواعد (‪ )Rules‬اللي الزم نختبرها‪.‬‬
‫‪ o‬ده بيقلل التعقيد في كتابة الـ ‪ Truth Table‬واالختبارات‪.‬‬

‫المزايا‪:‬‬

‫‪ .1‬الحاالت دي بتساعد إننا نركز على الحاالت اللي ليها تأثير فعلي على النتائج‪.‬‬
‫‪ .2‬بتقلل عدد القواعد اللي بتتعامل معاها في ‪ Truth Table‬لما يكون نفس النتيجة بتتكرر بغض النظر عن قيمة السبب‪.‬‬

‫في أسوأ السيناريوهات‪ :‬لو مفيش وال حالة "‪ ،"Don’t Care‬وكل األسباب مؤثرة‪ ،‬عدد القواعد هيزيد بشكل أُسي‪:‬‬

‫لو عندك ‪ N‬أسباب‪ ،‬يبقى هيتكون عندك ‪ 2N2^N‬قواعد‪.‬‬ ‫•‬

‫التمثيل في ‪Truth Table:‬‬

‫الحاالت دي بنمثلها باستخدام الرمز “*” في الـ ‪.Truth Table‬‬ ‫•‬

‫‪ o‬الرمز ده بيقول إن القيمة ممكن تكون "‪ "True‬أو "‪ "False‬بدون ما تأثر على النتيجة‪.‬‬

‫مثال عملي لتوضيح‪:‬‬

‫لو عندنا دالة بتعمل حاجة بنا ًء على شرطين‪:‬‬

‫الشرط األول ممكن يكون "‪ "True‬أو "‪False".‬‬ ‫•‬

‫الشرط التاني ملوش تأثير على النتيجة‪.‬‬ ‫•‬

‫في الـ ‪ ،Truth Table‬بنحط “*” مكان الشرط التاني‪.‬‬

 ‫النقاط المهمة باإلنجليزي‪:‬‬

‫‪Don’t care" conditions occur when a cause's value does not impact the " :Definition‬‬ ‫‪.1‬‬
‫‪effect.‬‬
‫‪Reduces the number of rules in a truth table by focusing only on relevant :Purpose‬‬ ‫‪.2‬‬
‫‪causes.‬‬
‫‪Helps minimize complexity when multiple causes lead to the same effect. :Reduction‬‬ ‫‪.3‬‬
‫‪N causes generate 2N2^N rules. ,Without "Don’t care" conditions :Worst Case‬‬ ‫‪.4‬‬
‫‪Represented by “*” in a truth table for irrelevant causes. :Representation‬‬ ‫‪.5‬‬

‫‪ Candidate Truth Tables‬هي عملية تطوير تدريجي لـ ‪ Truth Tables‬لضمان إنها بتكون منظمة وسهلة الفهم‪ ،‬ومش بتحتوي‬
‫على قواعد )‪ (Rules‬مستحيلة أو غير ضرورية‪ .‬الهدف منها هو تحسين الجدول بالتدريج للوصول ألبسط شكل ممكن ‪.‬‬

‫خطوات إنشاء ‪Candidate Truth Tables:‬‬

‫‪ .1‬الجدول األولي )‪Initial Table):‬‬

‫‪ .a‬الجدول األول بيشمل كل التوليفات الممكنة للقيم )‪ (True/False‬بطريقة منظمة‪.‬‬
‫‪ .b‬بنبدأ بكل القيم "‪ "True‬وبننتهي بكل القيم "‪False".‬‬
‫‪ .2‬إزالة القواعد المستحيلة )‪Impossible Rules):‬‬
‫‪ .a‬الخطوة التانية هي إننا نمسح أي قواعد مستحيلة أو غير منطقية من الجدول‪.‬‬
‫‪ .b‬القواعد المستحيلة بتكون الحاالت اللي األسباب فيها متناقضة أو غير قابلة للتنفيذ‪.‬‬
‫‪ .3‬إضافة حاالت "‪Don’t Care":‬‬
‫‪ .a‬بعد إزالة القواعد المستحيلة‪ ،‬بنبدأ نحدد الحاالت اللي األسباب فيها ملوش تأثير )‪ ،(Don’t Care‬وبنستخدم الرمز‬
‫“*” لتمثيلها‪.‬‬
‫‪ .b‬ده بيقلل عدد القواعد وبيخلي الجدول أبسط‪.‬‬

‫مالحظات‪:‬‬

‫لما بنحذف القواعد المستحيلة‪ ،‬بنستخدم الرمز “‪ ”-‬في عمود التأثيرات )‪ (Effects‬عشان نوضح إن القاعدة دي غير ممكنة‪.‬‬ ‫•‬
‫بنستخدم حروف بدل أرقام للتمييز بين القواعد المؤقتة )‪ (Candidate Rules‬والقواعد النهائية )‪ ،(Final Rules‬وده‬ ‫•‬
‫لتجنب أي التباس‪.‬‬

‫مثال عملي‪:‬‬

‫لو عندك دالة فيها سببين )‪Causes):‬‬

‫‪ .1‬أول جدول هيشمل كل التوليفات الممكنة للسببين )‪ 4‬قواعد في الحالة دي‪،False/True ،True/False ،True/True :‬‬
‫‪False/False).‬‬
‫‪ .2‬بعد كده‪ ،‬هنحذف أي قاعدة غير ممكنة )مثالً‪ ،‬لو في شرط منطقي مستحيل(‪.‬‬
‫‪ .3‬في النهاية‪ ،‬بنحدد األسباب اللي ملوش تأثير على النتيجة‪ ،‬وبنستخدم “*” لتبسيط الجدول‪.‬‬
 ‫النقاط المهمة باإلنجليزي‪:‬‬

‫‪starting with ,Includes all possible combinations of causes systematically :Initial Table‬‬ ‫‪.1‬‬
‫‪all true and ending with all false.‬‬
‫‪”-“ marked with ,Eliminates any logically impossible rules :Remove Impossible Rules‬‬ ‫‪.2‬‬
‫‪in the effects column.‬‬
‫‪Simplifies the table by identifying and marking irrelevant :”Introduce “Don’t Care‬‬ ‫‪.3‬‬
‫‪causes with “*”.‬‬
‫‪Use letters for candidate rules instead of numbers to avoid :Candidate Rules‬‬ ‫‪.4‬‬
‫‪confusion with final rules.‬‬

‫‪ Partial Truth Tables‬هي طريقة لتقليل حجم الـ ‪ Truth Tables‬عن طريق التركيز على جزء معين من األسباب )‪(Causes‬‬
‫بدل ما نشتغل على الجدول كله مرة واحدة‪ .‬ده معناه إن الجدول هيحتوي بس على مجموعة فرعية من األسباب‪ ،‬والباقي بيتم تحديد قيمته‬
‫كقيمة ثابتة ) ‪Constant Value).‬‬

‫الفكرة األساسية‪:‬‬

‫بدل ما نعمل جدول كبير يحتوي على كل التوليفات الممكنة لكل األسباب‪ ،‬بنختار بس مجموعة من األسباب اللي محتاجين‬ ‫•‬
‫ندرس تأثيرها‪.‬‬
‫األسباب اللي مش محتاجينها في الجدول ده بنحدد قيمتها كقيمة ثابتة )زي ‪ True‬أو ‪False).‬‬ ‫•‬

‫المزايا‪:‬‬

‫‪ .1‬تقليل حجم الجدول‪:‬‬

‫‪ .a‬باستخدام الجداول الجزئية‪ ،‬حجم الجدول بيقل بشكل كبير وبيبقى أسهل في التحليل‪.‬‬
‫‪ .2‬التركيز على األسباب المهمة‪:‬‬
‫‪ .a‬بنركز على األسباب اللي ليها تأثير مباشر على التأثيرات )‪ (Effects‬بدل ما نضيع وقتنا على األسباب غير‬
‫المهمة‪.‬‬

‫مثال عملي‪:‬‬

‫لو عندنا دالة فيها ‪ 4‬أسباب )‪Causes):‬‬

‫بدالً من إنشاء جدول بـ ‪ 16 = 4^162=24‬قاعدة‪ ،‬ممكن نركز على سببين فقط ونجعل السببَين اآلخرين ثابتين‪.‬‬ ‫•‬
‫على سبيل المثال‪:‬‬ ‫•‬
‫‪ o‬السبب ‪C1=TrueC1 = True‬‬
‫‪ o‬السبب ‪C2=FalseC2 = False‬‬

‫وبالتالي‪ ،‬الجدول هيشمل التوليفات الممكنة لـ ‪ C3C3‬و‪ C4C4‬فقط‪.‬‬

 :‫النقاط المهمة باإلنجليزي‬

with the rest set to ,Partial truth tables only include a subset of the causes :Definition .1
constant values.
Reduce table size and simplify analysis by focusing on key causes. :Purpose .2
:Advantages .3
Saves time and effort. .a
Makes it easier to analyze the impact of specific causes. .b
you can ,instead of creating 24=162^4 = 16 rules ,If a function has 4 causes :Example .4
focus on 2 causes and keep the other 2 constant.