1. پيش گفتار راوي
حسين فاني
طراح
fani@behsazan.net
sites.google.com/site/hosseinfani
مخاطب
Stakeholders ذينفعان سيستم نرم افزاري
مشتري
...
داستان
آزمون نرم افزار و آزمونگر آن
مديريت آزمون
1
2. مراجع
2
Software Engineering, A Practitioner’s
Approach, 5th Ed, Roger S. Pressman
Foundation of Software Testing, ISTQB
Certification, Dorothy Graham et. al. …
Acknowledgment تشکر
خانم مرجان فردوس ي پور، گروه شرکتهاي همکاران سيستم
6. فلسفه آزمون 6
چرا آزمون
انسان ها:
همه چيز را نمي دانند.
داراي دانش محدود هستند.
)Human is Err(. دچار اشتباه مي شوند
نياز به آزمون دارد )Manmade( هر چيز انسان ساز
چطور؟ God made در مورد
نرم افزارها
تحت فشار
محدوديت زماني
”افراد باهوش مشكلات را حل مي كنند حال آنكه افراد عاقل از پيش آمدن آن ها جلوگيري مي كنند.“
Einstein
8. فلسفه آزمون 8
تعريف آزمون
2002 : فرآيند همزمان با مهندس ي نرم افزار براي ارزيابي و بهبود کيفيت نرم افزار
Testware ) •آزمون افزار )مستندات و ابزارآلات آزمون
•هيچ اسمي از يافت خطا برده نمي شود!
1983 : فعاليتي به منظور ارزيابي صفتي از برنامه
1979 : اجراي برنامه به منظور يافت خطا
•آزمون در انتهاي چرخه توليد نرم افزار
•هدف اصلي: يافت خطا
Assessment •ارزيابي
Quality Measures •مقياس کيفيت نرم افزار
9. آزمون نرم افزار چيست؟
Shall Is
فلسفه آزمون 9
آزمون به
فرآيند
برنامه ريزي
آماده سازي
ارزيابي محصولات نرم افزاري
با هدف
تعيين ميزان تطابق سيستم با مشخصات و نيازمندي هاي موجود
اثبات تناسب سيستم با مورد استفاده مربوطه
يافتن خطاهاي موجود در سيستم
گفته مي شود
the process of comparing "what is" with "what ought to be."
10. • Functional
قابل ارجاع به يک نيازمندي مشتري • Non-Functional
• اتمام مدل نيازمندي مهيا شدن بسيار زودتر از شروع آزمون
از کوچک به بزرگ
3• نفر سوم rd Party
• Exhaustive
همه حالات برنامه را نمي توان آزمون کرد Test
80 درصد خطاهاي کشف نشده تنها در 20 درصد •
قسمتهاي نرم افزاري هستند
Pareto 80/20
اصول
Principles
فلسفه آزمون 10
11. آزمون پذيري
Testability
11
• هر چي بهتر کار کنه بهتر ميشه تستش کرد
• خطاي بازدارنده
• همزماني آزمون و توليد
Operability
Controllability
• تجزيه کار آزمون و نتايج و حذف وابستگي ها
• بررس ي وابستگي ها
Decomposability
• تغييرات کم
• تغييرات کنترل شده
Stability
• هر چه مي بيني همون رو تست ميکني
• دسترس ي به اتفاقات داخلي )حالتهاي قبل، گامهاي طي شده تا اينجا،
جدول، کد(
Observability
• Structural (CBS, Layered,
..)
• Functional
Simplicity
هر چي بيشتر بدوني، با هوشتر تست ميکني • Understandability
فلسفه آزمون
12. 12
Polar 3دسامبر 1999 ، مريخ نورد
ناپديد شد.
دليل خرابي، خطا در مقدار دهي به يك بيت
حافظه بوده است كه باعث شده تا مريخ
نورد در ارتفاع 1800 پايي سطح مريخ
موتورش خاموش شود.
خطاي مربوطه باعث سقوط مريخ پيماي
شد! Polar
خطاي مربوطه توسط تيم تست ناسا كشف
نشده بود.
ناسا متحمل 110 ميليون دلار زيان مالي
شد!
فلسفه آزمون
شيرشاه Disney اولين بازي شركت
براي كودكان )The Lion King(
روز كريسمس منتشر شد.
26 دسامبر، دپارتمان پشتيباني شركت
به جهنم تبديل شد!
برنامه تنها روي يك ويرايش سيستم عامل
تست شده بود.
بازي مربوطه روي بسياري از سيستم
هاي عامل اجرا نمي شد
14. Test Apply اجراي آزمون
Test Case مورد آزمون
Test Scenario سناريوي آزمون
Test Case State Transition چرخه مورد آزمون
و چرخه آن Bug خطا
14
15. اجراي آزمون 15
Test Case مورد آزمون
راهنماي اجراي آزمون )مثال(
آزمونگر بدون مورد آزمون، حق آزمون ندارد! چرا؟
چطور آزمون خود را به نيازمندي مشتري ارجاع دهد؟
چطور اثبات درستي و کيفيت نيازمندي را اثبات کند؟
چطور اثبات کند که در حال آزمون است؟
سناريوي آزمون )مثال(
مورد آزموني که در بردارنده جريان کار در چندين مورد کاربرد مختلف
پس چرا برخي آزمونگران بدون مورد آزمون، آزمون مي کنند؟
16. 16
اجراي آزمون
نام شماره سطح زير سيستم و نسخه نرم افزار سناريو )بله/خير( تاريخچه مورد آزمونهاي مرتبط
طراح آزمونگر وضعيت دليل وزن الصاقات خطاهاي مرتبط
Test Description شرح کلي آزمون Test Steps گامهاي آزمون
- هدف مورد آزمون و شرح
- شرح نکات ابهام آميز
نکته: هيچ گام و نتيجه اي در اين قسمت نوشته نمي شود.
- گام هاي آزمون دقيق و کامل
- بدون ابهام براي تستر
نکته: پاسخهاي سيستمي در اين قسمت بيان نمي شوند.
Pre Condition پيش شرط Expected Results نتيجه مورد انتظار
- پيش شرط هاي غير بديهي
- داده آزمون )اختياري (
پيش شرط هاي بديهي مانند
- تعيين سال مالي
- داشتن دسترس ي لازم
نتايج مورد انتظار با توجه به
- گامها
- پيش شرط
نکتهه: فعاليتهااي کااربر در ايان قسامت بياان نمهي شاوند. باه عباارتي ديگار
عماال در گااام هاااي آزمااون مشاااخا مااي شااود و عکااس العماال در نتيجاااه
مورد انتظار.
18. خطا
Error . عمل انجام شده توسط افراد كه باعث ايجاد نتيجه اشتباه مي شود Error
مي شوند. Fault ها معمولا منجر به بروز يک يا چندين
نگاه داخلي نقص ي در سيستم كه باعث مي شود سيستم نتواند كاركرد :Fault
مورد انتظارش را انجام دهد.
نگاه خارجي انحراف سيستم از ارائه سرويس مورد انتظارش را :Failure
مي گويند Failure
18
ممكن است باعث شود
اجراي آزمون
20. اجراي آزمون 20
گزارش خطا
هر چه پر بارتر، يافت منشا خطا و رفع آن سريعتر
گزارش خطاي موثر
قابليت باز توليد
شرح صريح و گام به گام تا برخورد به خطا
داراي صفات
شماره خطا، مورد آزمون متناظر، گزارشگر، زير سيستم و نسخه، سخت
افزار و سيستم عامل و ...
)Enhancement ،Trivial ،Minor ،Major ،Critical ،Blocker(Severity شدت
فرق آن با شدت؟( (Priority اولويت
22. 22
Test Apply اجراي آزمون
Test Case مورد آزمون
Test Scenario سناريوي آزمون
Test Case State Transition چرخه مورد آزمون
و چرخه آن Bug خطا
23. 23
طراحي مورد آزمون
Test(Case) Design
طراحي مورد آزمون
استراتژي )سطح( آزمون
- تکنيک در برابر استراتژي
Unit - واحد
Integration - يکپارچگي
System - سيستم
Validation (Acceptance) - صحت
24. طراحي مورد آزمون 24
طراحي مورد آزمون
منبع )مرجع( توليد
Use Case مورد کاربرد
درخواست
نيازمندي
قواعد کسب و کار
مورد کاربرد
Main Flow گردش اصلي
Alternate Flow گردشهاي جايگزين
26. 26
طراحي موردآزمون
نام شماره سطح زير سيستم و نسخه نرم افزار سناريو )بله/خير( تاريخچه مورد آزمونهاي مرتبط
طراح آزمونگر وضعيت دليل وزن الصاقات خطاهاي مرتبط
Test Description شرح کلي آزمون Test Steps گامهاي آزمون
- هدف مورد آزمون و شرح
- شرح نکات ابهام آميز
نکته: هيچ گام و نتيجه اي در اين قسمت نوشته نمي شود.
- گام هاي آزمون دقيق و کامل
- بدون ابهام براي تستر
نکته: پاسخهاي سيستمي در اين قسمت بيان نمي شوند.
Pre Condition پيش شرط Expected Results نتيجه مورد انتظار
- پيش شرط هاي غير بديهي
- داده آزمون )اختياري (
پيش شرط هاي بديهي مانند
- تعيين سال مالي
- داشتن دسترس ي لازم
نتايج مورد انتظار با توجه به
- گامها
- پيش شرط
نکتهه: فعاليتهااي کااربر در ايان قسامت بياان نمهي شاوند. باه عباارتي ديگار
عماال در گااام هاااي آزمااون مشاااخا مااي شااود و عکااس العماال در نتيجاااه
مورد انتظار.
27. طراحي مورد آزمون 27
طراحي مورد آزمون )ادامه(
داشتن الگو و استاندارد مشخا
جملات سوم شخا و قابل فهم براي کودک!
Reuse قابل استفاده مجدد بودن
Robustness وCorrectness نگرش مثبت و منفي
خلاصه و مفيد بودن
Test Data داده آزمون
اولويت بندي موارد آزمون
لينک کردن درخواست، نيازمندي يا مورد آزمون ديگر به مورد آزمون
)Pesticide Paradox( به روزنگهداشتن، حذف
28. طراحي مورد آزمون 28
استراتژي )سطح()انواع( آزمون
به چه کس ي چه کيفيتي رو اثبات ميکنيد؟
استراتژي در برابر تکنيک آزمون
29. طراحي مورد آزمون 29
Unit Test آزمون واحد
اولين و جزئي ترين سطح آزمون
آزمون جزء: کوچکترين واحد قابل آزمون
آزمونگر
توسعه دهنده
طراح
مشتري
Module ماژول ،Component آزمون مولفه
30. طراحي مورد آزمون 30
Integration Test آزمون يکپارچگي
واسط بين اجزاء و روابطآن ها
Top-Down
Bottom-Up
Regression
Impact Analysis
Smoke
قطعه سخت افزاري براي اولين بار روشن مي شود، اگر آتش نگيرد يعني احتمالا كار مي كند!
آزمونگر
توسعه دهنده
طراح
تحليلگر
مشتري
31. طراحي مورد آزمون 31
Validation Test ؟ آزمون
Validation Vs. Verification
درست کار مي کند
کار درستي مي کند
شرط پذيرش، اعتبار، قبولي: سند نيازمندي
در دو زير سطح
مشتري در محل توليد :Alpha
مشتري در محل استفاده :Beta
آزمونگر
3rd Party
مشتري
Acceptance
32. طراحي مورد آزمون 32
System Test آزمون سيستم
Recovery
Data
Check Point
MTTR
Security
Stress
Abnormal Resource Demand (Quantity, Frequency, Volume)
Performance
Sanity
Stable Enough to TEST
Load
Usability
Reliability
Four 9
33. 33
طراحي مورد آزمون
Test(Plan) Design
طراحي مورد آزمون
طراحي مورد آزمون
استراتژي )سطح( آزمون
تکنيک در برابر استراتژي
Unit واحد
Integration يکپارچگي
System سيستم
Validation (Acceptance) صحت
35. 35
Test Technique تکنيک آزمون
White/Black Box جعبه سياه و سفيد
Static/Dynamic ايستا و پويا
36. تکنيک آزمون 36
دسته بندي تکنيک ها
Observability ميزان مشاهده
تنها ورودي و خروجي مشاهده پذيرند :Black Box جعبه سياه
اجزاي اجراي داخلي :White Clear Box ) جعبه سفيد )جعبه شيشه اي
نيز مشاهده پذيرند
قابليت اجرا
ايستا: بدون اجراي برنامه
پويا: با اجراي برنامه
37. 37
Techniques
Dynamic
Structure-based
Code
Coverage
Experience-based
Error Guessing
Exploratory
Specification-based
Equivalence
Partitioning
تکنيک آزمون
Boundary Value
Analysis
Decision Tables
State
Transition
Comparison
Static
Review Static
Analysis
Control Flow
Data Flow
38. 38
Test Technique تکنيک آزمون
White/Black Box جعبه سياه و سفيد
Static/Dynamic ايستا و پويا
39. 39
Test Plan برنامه ريزي )فرآيند( آزمون
جايگاه در فرآيند توليد نرم افزار
استاندارد برگزاري آزمون
شروع آزمون
پايان آزمون )شرط توقف/بازشروع(
جمع آوري اطلاعات
بررسي کيفيت برگزاري و کيفيت نرم افزار )معيارها(
40. برنامه ريزي )فرآيند( آزمون 40
جايگاه در فرآيند توليد نرم افزار
نگرش
در گذشته )طبق تعريف گذشته(: آزمون بعد از توليد
امروزه: آزمون به موازات توليد
کشف خطا هر چه سريعتر، خرابي کمتر
43. 43
فرآيند آزمون
کنترل )نظارت(
برنامه ريزي آزمون
تحليل و انتخاب
استراتژي آزمون
طراحي موارد آزمون
و اجراي آنها
برنامه ريزي )فرآيند( آزمون
گزارش و تحليل
نتايج
بررس ي کيفيت
فرآيند و کيفيت
نرم افزار
44. برنامه ريزي )فرآيند( آزمون 44
استاندارد طرح آزمون نرم افزار
طرح آزمون
سندي كه دامنه ، روش ، برنامه اجرايي و ضوابط آزمون را از پيش مشخا مي سازد.
استاندارد
فايل استاندارد
شرايط آغاز، توقف، شروع مجدد و پايان
آنچه آزمون نخواهد شد!
شرايط انتشار محصول
ساختار سازماني آزمون
45. برنامه ريزي )فرآيند( آزمون 45
کيفيت فرآيند و کيفيت نرم افزار )معيارها(
گزارشات مديريتي
پوشش دهي
وضعيت موارد آزمون
وضعيت خطاها
عملكرد افراد
ميانگين سن خطا
گزارشهاي عملياتي
موارد آزمون مردودي كه خطا ندارند
موارد آزمون مردودي كه تمام خطاهايشان بسته شده است
موارد آزمون مردودي كه خطاي باز دارند
خطاهايي كه به هيچ مورد آزموني متصل نيستند
خطاهايي كه به موارد آزمون غيرفعال متصل هستند
47. 47
ممكن است فكر
كنيد اينجا هستيد
ممكن است اينجا
باشيد!
تعداد
خطاي كم
كيفيت تست
تعداد
خطاي كم
كيفيتنرم افزار
48. 48
Test Plan برنامه ريزي )فرآيند( آزمون
جايگاه در فرآيند توليد نرم افزار
استاندارد برگزاري آزمون
شروع آزمون
پايان آزمون )شرط توقف/بازشروع(
جمع آوري اطلاعات
بررسي کيفيت برگزاري و کيفيت نرم افزار )معيارها(
خطاي بدي! خورد. چيزي نيست، خطاي ريزيه!
اولويت: زمان!
محسبه حقوق اشتباه: شدت Critical ولي اولويت متوسط: چون الان تازه 3 ماه است و محاسبه حقوق 30 ماه صورت ميگيره!
سال 2038 در سيستمهاي يونيکس:
It is possible a similar problem could occur in 2038 (the year 2038 problem), as many Unix systems calculate the time in seconds since 1 January 1970, and store this number as a 32-bit signed integer, for which the maximum possible value is 231 − 1 (2,147,483,647) seconds.
حالا شما مثال بزنيد از اولويت بالا ولي شدت پايين:
Blocker: No further testing work can be done.
Critical: Application crash, Loss of data.
Major: Major loss of function.
Minor: minor loss of function.
Trivial: Some UI enhancements.
Enhancement: Request for new feature or some enhancement in existing one
Some Bonus tips to write a good bug report:
1) Report the problem immediately: If you found any bug while testing, do not wait to write detail bug report later. Instead write the bug report immediately. This will ensure a good and reproducible bug report. If you decide to write the bug report later on then chances are high to miss the important steps in your report.
2) Reproduce the bug three times before writing bug report:Your bug should be reproducible. Make sure your steps are robust enough to reproduce the bug without any ambiguity. If your bug is not reproducible every time you can still file a bug mentioning the periodic nature of the bug.
3) Test the same bug occurrence on other similar module:Sometimes developer use same code for different similar modules. So chances are high that bug in one module can occur in other similar modules as well. Even you can try to find more severe version of the bug you found.
4) Write a good bug summary:Bug summary will help developers to quickly analyze the bug nature. Poor quality report will unnecessarily increase the development and testing time. Communicate well through your bug report summary. Keep in mind bug summary is used as a reference to search the bug in bug inventory.
5) Read bug report before hitting Submit button:Read all sentences, wording, steps used in bug report. See if any sentence is creating ambiguity that can lead to misinterpretation. Misleading words or sentences should be avoided in order to have a clear bug report.
6) Do not use Abusive language:It’s nice that you did a good work and found a bug but do not use this credit for criticizing developer or to attack any individual.
Resolved: دلايل آن
Fixed
Rejection
Duplicate
Non-Reproducable
Later
نمي ارزه (صلاح نيست انجامش بديم)
Change control board
آيا هر خطايي تاييد ميشه؟
آيا هر خطاي تاييد شده اي رفع ميشه؟ ممکنه انقدر تاثير بذاره که خطا را به عنوان بخشي از نرم افزار بپذيريم!!
ولي تستر فارق از اينکه خطا رفع ميشه يا نه بايد کار خوش رو انجام بده
30 دقيقه
در سناريوي آزمون گردشها در چندين مورد کاربرد جريان دارد!
ارائه چندين مثال از مورد آزمون
نمايش عکس از TFS براي ايجاد يک مورد آزمون و نمايش فيلدهاي آن
ارائه چندين مثال از مورد آزمون
جملات امري: نام مشتري را وارد مي کنيم. نام مشتري وارد شود
Reuse: مورد تست بايد به گونه اي طراحي شود که بتواند در سناريوهاي ديگر نيز استفاده شود
-Correctness : سيستم منطق و رفتار صحيح داشته باشد
Robustness-: سيستم در برابر رفتار و ورودي اشتباه، رفتار درست نشان دهد. (گربه روي کيیبور راه بره)
خلاصه و مفيد: 100 تا مورد تست کوچيک بهتر است از 10 تا بلند
اولويت بندي: ما مجبور شويم بعضي از موارد تست را به دليل کم اهميت بودن تست نکنيم و اين سوال پيش آيد که چه مقدار تست «كافي» است؟
معني استراتژي تست: بهتره از نمون هاي جزئي به دسته بندي کلي رسيد
ميخوآي چه صفتي از کيفيت رو بسنجي
ميخواي چه خطاهايي رو کشف کني
استراتژي: حمله از دور: تکنيک تيرو کمان
استراتژي: حمله از نزديک: شمشير
کنترل: فعاليت Umbrella Activity
برنامه ريزي:
چه استراتژي هايي، چه مواقعي، با چه هزينه اي، شرايط توقف، شرايط انتشار، شرايط تغيير از يک سطح آزمون به سطح ديگر
انتخاب استراتژي:
چه تکنيکي هايي و از هر يک چه تعداد مورد آزمون
گزارش:
چه کساني، چه تعداد مورد آزمون، چند تا خطا، چند تا رفع خطا، چند تا خطاي بازدارنده، مهم، ...، از کي تا کي، ...
تصميم سازي و تصميم گيري:
فرآيند آزمون خوب بوده ولي کيفيت نرمافزار بسيار پايين هست و بايد يه بار ديگه نسخه بخوره!
موارد آزمون غير فعال: مواردي که در اين فرآيند تست آزمون نخواهند شد!