U3F1ZWV6ZTQ2NzUxODY0ODA1MTI3X0ZyZWUyOTQ5NTExODk5MzE1NA==

تعرف على الstatic testing وعلى الtechniques الخاصة به (الreview process –الstatic analysis)





تعرف على الstatic testing وعلى الtechniques الخاصة به (الreview process –الstatic analysis)



ان شاء الله اليوم سوف نتحدث عن الstatic testing وعن التيكنيكس الخاصة به (الreview process – الstatic analysis) ,عرفنا من قبل ان هناك نوعان من التيستينج بيمربهم أى مشروع واحنا شغالين عليه وهما الdynamic testing وال static testing, وعرفنا أيضا ان كل نوع بيندرج تحته أنواع أخرى وكل نوع له الtechniques الخاصة به, وتحدثنا من قبل عن أنواع الdynamic testing وعن الtechniques الخاصة بكل نوع , فقد تحدثنا عن الblack box testing وعن الtechniques الخاصة به فى موضوعين الموضوع الأول بيتحدث عن أول تقنيتين من الblack box testing techniques وهم(الequivalence partitioning- الboundary value analysis)  , والموضوع الثانى بيتحدث عن باقى الtechniques الخاصة بالblack box testing techniques وهم(الdecision table-الstate transition-الuse case) .

وتحدثنا أيضا فى موضوع اخرعن الwhite box testing وعن الtechniques الخاصة به وهم(الstatement testing-
الdecision testing) وعن الexperience based testing وعن الtechniques الخاصة به وهم (الerror guessing-الexploratory testing) , وبكده نكون انتهينا من أنواع التيستينج المندرجة تحت نوع الدينميك تيستينج ومن التيكنيكس الخاصة بها.


الstatic testing  


ان شاء الله اليوم سوف نبدأ فى الحديث عن الstatic testing وعن الtechniques الخاصة به (الreview process- الstatic analysis) , من المهم فى البداية ان نعلم ان الstatic testing techniques والdynamic testing techniques بيستخدموا لإكتشاف الأخطاء وضمان جودة السوفتوير , لكن الstatic testing بيتم قبل ما نعمل execute أو تشغيل  للبرنامج بينما الdynamic testing بيتم واحنا بنعمل execute للبرنامج , ولازم يكون عندنا علم أيضا بإيه اللى بنختبره أصلا أوبنركز عليه واحنا بنعمل تيستينج زى الأهداف أو المعايير الرئيسية , وزى اننا نشوف هل الinterface متناسق ولا لأ, واننا نشوف هل الكود فيه مشاكل ولا لأ.

الstatic testing بينقسم الى مرحلتين,المرحلة الأولى وهى الreview والمرحلة دى بنحدد فيها الأخطاء والعقبات من غير ما أعمل run للكود وذلك بيتم بشكل manual , المرحلة الثانية وهى الstatic analysis والتى تتيح لنا ضمان جودة البرنامج ومعرفة الأخطاء بشكل أتوماتيك.


أما بالنسبة للسمات اللى لازم المراجعة تتضمنها فهى المتطلبات الخاصة بالrequirement , والمتطلبات الخاصة بالdesign , الcode والtest plans ,الtest specification والtest cases والtest scripts والuser guides او web pages .

وده فيديو بيشرح الstatic testing.


الreview process


ان شاء الله هنتكلم فى الreview process عن الأنشطة او العمليات اللى بنعملها لكى تتم عملية الreview بشكل فورمال , وهنتكلم عن المسئولين عن عملية الreview وعن دور كل مسئول , وهنتكلم عن أنواع الreviewers وعن عوامل نجاح الreview.

الأنشطة أو العمليات اللى بنعملها لكى تتم عملية الreview بشكل فورمال


1-الplanning: من خلالها بنحدد الentry criteria واللى من خلالها بنحدد امتى نبدأتيستينج زى مثلا بداية level معين أوعند توافر بيئة معينة أو اجهزة معينة أولما تكون الداتا اللى هتتم بيها عملية التيستينج متاحة , ومن خلال عملية الplanning أيضا بنحد الحاجات اللى هنراجعها ومين اللى هيعمل الreview وايه هى مسئوليتهم  , وايه هى الأجزاء اللى هيتعمل عليها review , وكمان بنحدد الexit criteria واللى من خلالها بنعرف امتى هنوقف تيستينج زى مثلا فى نهاية level معين أوعند حدوث تغيرات معينة اوعلى حسب الميزانية المتوفرة.

2-الkick off meeting: من خلالها بنوزع الdocuments على الreviewers وبنوضح فيها الأهداف المطلوب تحقيقها وبنشرح لهم بالتفصيل.

3-الindividual preparation: من خلالها بيبدأ اللى هيشاركوا  فى الreview يأخذوا الdocuments ويقرأوها ويفهموها كويس ويعملوا document للكومنتات والأسئلة اللى هيسألوها فى الreview meeting.

4- الreview meeting: واللى من خلاله بنعمل اجتماع للreviewers وبنجمع منهم كل الكومنتات والأسئلة اللى حضروها ومنها بنحدد الdefects, وايه الطرق اللى ممكن نستخدمها علشان نحل هذة الdefects.

5- الrework: واللى من خلاله بنبدأ نرجع الdocuments للauthor علشان يعدل فيها ويصلح الdefects.

6- الfollow up:فى المرحلة دى بنتابع هل الdefects اتصلحت ولا لسه وهل حققنا الهدف من الreview وهل وصلنا للexit criteria ولا لسه.

من هم المسئولين عن عملية الreview وماهو دور كل مسئول


1-الmanager:وهو اللى بيقرر بداية تنفيذ عملية ال review, وبيحدد الوقت المطلوب لعملية الreview علشان يقدر لها الوقت المناسب لعملية الschedule , بعد عملية الreview بيشوف هل أهدافها اتحققت ولا لأ.

2-الmoderator: هو اللى بينظم وبيدير الreview meeting وبيقود عملية الreview  على الdocuments وكمان بيتابع التنفيذ بعد الreview meeting وتقريب وجهات النظر بين أعضاء الreview meeting لكى ينجح الreview.

3-الauthor: ده الشخص اللى كتب الdocuments اللى هيتعمل review عليها.

4- الreviewers: ودول اللى بيعملوا review للdocuments وبيقدروا يحددوا الdefects ودول يشترط أنهم يكون عندهم خبرة فى الحاجات اللى هيتعمل عليها review.

5- الrecorder او الscrip: وده اللى بيسجل كل اللى تم فى الreview meeting وكمان بيسجل الbugs.


أنواع  الreviews


1- الinformal: بيكون ودى ومش لازم نعمل document للخارج منه والهدف منه طريقة مش هتكلفنى كثير علشان أخذ رأى حد مش متخصص.

2-walkthrough : الauthor هو اللى بيقود عملية الreview وممكن يكون هناك  scripبس مش هو الauthor وممكن لا يكون هناك scrip , والهدف من هذا النوع من الreview هو ان فريق العمل بيسأل الauthor عن كل حاجة علشان يحصل  learningوgaining أو بمعنى أخر علشان فريق العمل يفهم طبيعة المشروع وبالتالى يقدر يقدم اقتراحات أو تحسينات تخص المشروع.

3-technical review: بيحصل فيه مراجعة أيضا للdocuments ولكن اللى بيقوموا بعملية المراجعة بيكون عندهم   high technical backgroundأوبمعنى اخر بيكون عندهم خلفية عالية عن المجال الذى يقوم عليه المشروع وممكن يشارك فى هذا النوع من الreview  الmanagers, والمسئول عن الreview ده مش الauthor لازم يكون هناك moderator , والهدف من هذا النوع من الreview اننا بنتناقش وبنأخذ قرارات وبنشوف الdefects وبنحل كل الtechnical problems وبنتأكد من التوافق بين الspecification اللى طالبها العميل والstandards.

4-inspection: بيكون مشابه للtechnical review فى ان الmoderator هو المسئول عن  إدارة عملية المراجعة, وحضور leader بيكون اختيارى, والناس اللى بتعمل المراجعة بيكونوا أكثر تخصصا, والهدف من هذا النوع من الreview هو ايجاد الأخطاء ,وبيكون هذا النوع  أكثر formal.

عوامل نجاح الreview:


1- أن يكون عندك أهداف واضحة ومسبقة لعملية الreview.
2-الاختيار الأمثل للفريق طبقا لأهداف الreview وطبقا لأهداف السوفتوير وأحيانا بيتم التدريب المسبق لأعضاء الreview.
3-كلما كان الreviewers خبرتهم أعلى كلما كان تحضيرهم لعملية الreview أسرع.
4-الdefects لازم نتناقش فيها بطريقة إيجابية ولازم يكون هناك ثقة بين أعضاء الفريق.
5-استخدام الcheck list لو مناسبة لزيادة الفاعلية فى التعرف على الdefects.
6-كلما كان التنظيم سليم  كلما كان الreview سليم والخطة ناجحة.

وده فيديو بيشرح الreview process.


الstatic analysis


فى الstatic analysis بنراجع على الsource code قبل مانعمل له execution وفيه بيتم اكتشاف الdefects بدون مانعمل run للبرنامج , وبستخدم فيه  tools وبيخرج لنا report فى شكل HTML أو XML report .

أهمية الstatic analysis:


1-بيساعدنا فى اكتشاف الأخطاء الخاصة بالتبعيات والتناقضات زى مثلا  لو احنا بنربط صفحتين ملهمش علاقة ببعض فهيكون بينهم لينك مش هيشتغل.
2-انه بيساعدنا فى تحسين الكود والdesign والperformance.
3-بيساعدنا فى تلافى الأخطاء لأننا بنكتشف الdefects بدرى قبل مانعمل execution.

ومن الأخطاء الأخرى اللى بنكتشفها فى مرحلة الstatic analysis:


1-الundefined variable.
2-هل الcalling مابين الmodules والcomponent ماشى صح.
3-بيخلينا نكتشف الdead code.
4-بيساعدنا فى اكتشاف الأخطاء الخاصة بالlogic زى الinfinite loop.
5- بنتأكد ان الكود بتاعنا secure ولا لأ.

واللى بيقوم بهذة العملية هم الdevelopers للتأكد من جودة الكود قبل وخلال التنفيذ وبيشاركهم فى ذلك الdesigners للتأكد من سهولة الuser interface.

وده فيديو بيشرح الstatic analysis.




تعديل المشاركة Reactions:
author-img

المهندسة / فاطمة الزهراء نصر

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