Môn học Kiểm chứng phần mềm

1. MônhọcKiểmchứngphầnmềm Th.SNguyễnThịKiêmÁi

2. Giớithiệu Cáckhíacạnh test trên web Mứcđộ KTPM Cácthànhphầnvàchuẩn UI Kỹthuậtvàchiếnlược KTPM Côngcụkiểmthử Xâydựng test plan Rènluyện Quảnlýtiếntrìnhkiểmthử Báocáo Nội dung Web testing Kiếnthứctổngquan

3. Giớithiệu Cáckhíacạnh test trên web Mứcđộ KTPM Cácthànhphầnvàchuẩn UI Kỹthuậtvàchiếnlược KTPM Côngcụkiểmthử Xâydựng test plan Rènluyện Quảnlýtiếntrìnhkiểmthử Báocáo Nội dung Web testing Kiếnthứctổngquan

4. Đặt vấn đề • Tạisaocầnquảnlýchấtlượng? • Thỏamãnyêucầuđượcđặtratừphíakháchhàng/ ngườidùng • Hạnchếtốiđanhữnglỗicóthểxảyra • Tạouytínchocôngty • ....

5. Software Testing: Software testing is the process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component.

6. Mụctiêu testing trêncácquanđiểm • Stakeholders : programmers, test engineers, project managers và customers. • Các stakeholder nhìnnhậnquytrình test từnhiềuquanđiểmkhácnhau: • It does work: khithựcthimộtđơnvịchươngtrình, các programmers muốnbiếtnócóhoạtđộng hay khôngtrongtrườnghợpbìnhthường. Đốivớitoànhệthốngcũngcùng ý tưởng, khitoànhệthốngđượctíchhợp developers muốn test hệthốngcóthựchiệncácchứcnăngcơbản hay không. muốnchỉrarằnghệthốnghoạtđộng. • It does not work: khicác programmers (độingũpháttriển) hàilòngkhimộtđơnvị (hệthống) hoạtđộng ở mứcđộnhấtđịnh, thêmcác test đượctiếnhànhvớimụctiêutìmra faults muốnlàmchohệthống fail. • Giảmrủiro failure : hầuhếtcáchệthốngphầnmềmphứctạpđềucó fault làmchohệthống fail theothờigian. Kháiniệm “failing from time to time” làmphátsinhkháiniệm failure rate. Khi fault đượctìmravà fix thì failure rate giảmxuốngmụctiêucủaviệcthựchiện test làgiảmrủiro fail xuốngmứccóthểchấpnhậnđược. • Giảm chi phí testing: chi phíthiếtkế, bảotrìvàthựchiện test case, chi phíphântíchkếtquảthựchiệnmỗi test case, chi phí document test case, chi phíhệthốngthựcthithựcsựvà document nó. • Nhưvậy, càngít test case cànggiảm chi phíliênquan. Mụctiêucaonhấtcủathựchiện test làtạorasảnphẩmrủirothấp (low – risk software) vớiít test case nhất effectiveness of test cases, Test engineers phảilựachọn test case ítnhấtmàhiệuquảnhất.

7. Cácvấnđềtrungtâmtrong testing • Chúng ta nhậnrarằngxoayquanhvấnđềthửnghiệm(testing) làpháthiệnratấtcảcáclỗi. Đâylànhiệmvụkhócóthểthựchiện. Vìvậy, điều tiếp theo tốt nhất là chọn input domain phùhợpvàphủtốtđể thử nghiệm chương trình. • Đề cập đến Hình 1.5, LấyD là miềnđầu vào của một chương trình P.Giảsửchúng ta chọnmộttậphợp con D1 của D, D1 ⊂ D, để test chươngtrình P. Phần test trongD1 chỉ là một phần P1, có nghĩa là, P1 ⊂ P, hành vi thực hiện của P, trong đó trường hợp lỗi với các phần khác, P 2, sẽ không bị phát hiện. • Bằng cách chọn một tập hợp con của lĩnh vực đầu vào D 1, các kỹ sư kiểm tra cố gắng để suy ra các thuộc tính của toàn bộ chương trình P bằng cách quan sát hành vi của một phần P 1 của toàn bộ hành vi của P dựa trên đầu vào D 1. • Vì vậy, lựa chọn các tập hợp con của miềnđầu vào phải được thực hiện một cách có hệ thống và cẩn thận để khấu trừ là chính xác và đầy đủ nhất có thể.Ví dụ, các ý tưởng được xem xét khi lựa chọn các trường hợp thử nghiệm.

8. Hoạtđộngkiểmthử - Testing Activities • Để kiểm tra một chương trình, một kỹ sư kiểm tra phải thực hiện một chuỗi các hoạt động thử nghiệm.Hầu hết các hoạt động này đã được thể hiện trong hình 1.6 và được giải thích sau đây. Những giải thích này tập trung vào một trường hợp thử nghiệm duy nhất. •  Identify an objective to be tested: Hoạt động đầu tiên là xác định một mục tiêu để được kiểm tra.Mục tiêu xác định mục đích, hoặc thiết kế một hoặc nhiều trường hợp thử nghiệm để đảm bảo rằng chương trình hỗ trợ mục tiêu. Một mục đích rõ ràng phải được liên kết với tất cả các trường hợp thử nghiệm.

9. Cácnhântốchấtlượngcủaphầnmềm MôhìnhMCCall

10. Độđochấtlượngphầnmềm • McCall đãđưaracácđộđochấtlượngphầnmềmnhưsau: • Kiểmtoánđược: Cóthểkiểmtradễdàngviệctuânthủcácchuẩn. • Độchínhxác • Tínhđầyđủ: Mứcđộđápứngđầyđủcácyêucầuđãđượcđặtra. • Tínhsúctích: Độgọncủachươngtrình. • Tínhnhấtquán: Tínhnhấtquántrongtoànbộchươngtrình. • Phổbiếndữliệu: Việcdùngcáccấutrúcvàkiểudữliệuchuẩntrongchươngtrình. • Dung sai: Nhữngảnhhưởngkhichươngtrìnhbịlỗicóthểchấpnhậnđược. • Hiệuquảthựchiện: Hiệunăngkhichạychươngtrình. • Tínhmởrộngđược: Mứcđộmàtheođócácthiếtkếkiếntrúc, dữliệu hay chứcnăngcóthểmởrộngđược. • Tínhtổngquát • Độclậpphầncứng: Mứctáchbiệtcủaphầnmềmđốivớiphầncứng. • Tínhmôđun: Tínhđộclậpcủacácthànhphần. • Tínhvậnhành: Tínhdễvậnhànhcủachươngtrình. • Tính an toàn: khảnăngkiểmsoát hay bảovệchươngtrìnhvàdữliệu. • Tínhsưuliệu: Khảnăngđápứngđầyđủcácthông tin trongquátrìnhpháttriểnphầnmềm. • Tínhđơngiản: Mứcđộngườidùngcóthểhiểuđượcchươngtrìnhmộtcáchdễdàng. • Tínhđộclậphệthốngphầnmềm: Mứcđộmàtheođóchươngtrìnhđượcđộclậpvớicáctínhnăngvàcácràngbuộcvớicácmôitrườngkhác. • Tínhhuấnluyện: Mứcđộmàchươngtrìnhtrợgiúpngườidùngthựchiệncácthaotác.

11. Mộtsốkháiniệmtrong KTPM • Phânbiệt QC & QA

12. Mộtsốkháiniệmtrong KTPM(tt) • Vídụ: Xácđịnhcôngviệc QC? QA? • Kiểm tra để bảo đảm các giải thuật khi viết code phải được chúthích rõ ràng • Kiểmtra module “đăngkýhọcphần” trongdựánhoạtđộngđúngnhưyêucầukhông?

13. Mộtsốkháiniệmtrong KTPM(tt) • Phânbiệtkiểmthử black box & white box • Black box: kiểmthửhộpđen • Đặc tính của hộp đen là chỉ nhìn thấy bên ngoài, ko thể nhìn thấy được cấu tạo bên trong của hộp. Do đó, BlackBox là loại test mà ta không cần biết cấu trúc bên trong mà chỉ cần quan tâm đến Input và Output, nó dùng trong functional test, thường là QC làm. • White box: kiểmthửhộptrắng • đặc tính của hộp trắng có thể thấy được bên trong của hộp. Do đó, WhiteBox là loại test mà ta cần phải biết cấu trúc bên trong, nó dùng trong unit test, thường do developer làm.

14. Mộtsốkháiniệmtrong KTPM(tt)

15. Mộtsốkháiniệmtrong KTPM(tt) • Manual Testing và Automation Testing.

18. Test Case • Test case là trườnghợpkiểmtra, đượcthiếtkếnhằmxácnhậnmộtđốitượngcóthỏamãnyêucầuđặtra hay không • Gồmcácthànhphầncơbản: • Tập các giá trị nhập • Các điều kiện tiên quyết, cácbước thực thi • Các kết quả mong đợi

19. Thếnàolàtestcasetốt? • 1. Chính xác:Test case được thiết kế ra có thể test được mọi thứ như đã thiết kế.2. Ngắn gọn:Các bước mô tả thực hiện test gọn gàng, không dư thừa, chỉ mô tả chính xác những step cần phải thực hiện.3. Có thể tái sử dụng:Viết test case sao cho có thể dùng lại hoặc tái sử dụng nó vào các dự án khác (có thể chỉ một phần)4. Có thể quản lý thay đổi:Có thể quản lý các lần thay đổi test case dựa vào spec (thêm sheet revision, không xóa dòng cũ mà gạch ngang)5. Có thể sử dụng để test: Có thể thực hiện theo các bước ghi trong test case để thực hiện test sản phẩm, phù hợp với người thực hiện test và môi trường test mà khách hàng mong muốn.6. Độc lập với người viết: Người đọc test case và test có thể không phải là người thiết kế ra test case, vì vậy đảm bảo sao cho tester khác cũng có thể đọc, hiểu test case và thực hiện test được.7. Tự làm sạch: Qua các lần thay đổi, cập nhật, test case sẽ được tinh chỉnh lại cho phù hợp hơn, tốt hơn.

20. Test Case (tt) • Vídụ: • Textbox chophépnhậpsốdương • Chươngtrìnhchophépngườidùngnhập 3 cạnhcủa tam giác, tínhchu vi tam giác. • Viếttestcasechomànhình “Login”

21. Giớithiệu Cáckhíacạnh test trên web Mứcđộ KTPM Cácthànhphầnvàchuẩn UI Kỹthuậtvàchiếnlược KTPM Côngcụkiểmthử Xâydựng test plan Rènluyện Quảnlýtiếntrìnhkiểmthử Báocáo Nội dung Web testing Kiếnthứctổngquan

22. Mứcđộkiểmthửcơbản

23. Mốitươngquangiữapháttriểnvàkiểmtraphầnmềm

24. Unit Test – Kiểmtramứcđơnvị • Unit làphầnnhỏnhấtcủamãnguồn (source code) cóthểđượcbiêndịch, liênkếtvà load (compiled, linked, loaded) • Cáchàm (Function), thủtục (Procedure), lớp (Class), hoặccácphươngthức (Method) đềucóthểđượcxemlà Unit. • Unit testing đượcthựchiệnbởiLậptrìnhviên (Developers) • Sửdụngphươngpháp test hộptrắng (White box testing)

25. Intergration Test- Kiểmtratíchhợp • Software Integration làquátrìnhhợpnhấtcác unit đơnlẻvàothànhmộthệthống (hoặcmộttiểuhệthống). • Integration testing là test cácliênkếtgiữacác unit thànhphần, pháthiệnlỗigiaotiếpxảyragiữacác Unit. • Integration testing đòihỏicác module phảiđược unit test trước.

26. System Test- Kiểmtrahệthống • Mụcđích: kiểmtrathiếtkếvàtoànbộhệthống(saukhitíchhợp) cóthỏamãnyêucầuđặtra hay không, bảođảmhệthốngđủkhảnănglàmviệctrongmôitrườngthực. • System Test bắtđầukhitấtcảcácbộphậncủaphầnmềmđãđượctíchhợpthànhcông • Trongnhiềutrườnghợp, việckiểmtrađòihỏimộtsốthiếtbịphụtrợ, phầnmềmhoặcphầncứngđặcthù, đặcbiệtlàcácứngdụngthờigianthực, hệthốngphânbố, hoặchệthốngnhúng

27. System Test- Kiểmtrahệthống(tt) • Điểmkhácnhau then chốtgiữa Integration Test và System Test ? • Đòihỏinhiềucôngsức, thờigianvàtínhchínhxác, kháchquan, System Test thườngđượcthựchiệnbởimộtnhómkiểmtraviênhoàntoànđộclậpvớinhómpháttriểndựán. • Test dựatrênyêucầuhệthống, test chứcnăng, hiệunăng, bảomật, cấuhình..

28. Acceptance Test - Kiểmtrachấpnhận • Thựchiệnsausaugiaiđoạn System Test • Kháchhànghoặcủyquyềnchomộtnhómthứbathựchiện • Mụcđíchlàđểchứng minh PM thỏamãntấtcảyêucầucủakháchhàngvàkháchhàngchấpnhậnsảnphẩmtrướckhinghiệmthu

29. Installation Test- Kiểmtracàiđặt • Test cácbướcthựchiệncàiđặtdựatrênTàiliệuhướngdẫncàiđặt, chứng minh Tàiliệuhướngdẫncàiđặtđã qui chuẩnđểchuyểngiaokháchhàng. • Installation test đượcthựchiệnbởiNhóm test

30. Regression Test - Kiểmtrahồiquy • Regression Test khôngphảilàmộtmứckiểmtra, nhưcácmứckhácđãnói ở trên. • Đơnthuầnkiểmtralại PM saukhicómộtsựthayđổixảyra, đểbảođảmphiênbản PM mớithựchiệntốtcácchứcnăngnhưphiênbảncũvàsựthayđổikhônggâyralỗimớitrênnhữngchứcnăngvốnđãlàmviệctốt. • Regression test cóthểthựchiệntạimọimứckiểmtra.

31. Giớithiệu Cáckhíacạnh test trên web Mứcđộ KTPM Cácthànhphầnvàchuẩn UI Kỹthuậtvàchiếnlược KTPM Côngcụkiểmthử Xâydựng test plan Rènluyện Quảnlýtiếntrìnhkiểmthử Báocáo Nội dung Web testing Kiếnthứctổngquan

32. Cácphươngphápkỹthuật test • Equivalence class partitioning – Phânlớptươngđương • Phâncác test cases theonhómcácTEST CASEcùngloại, gọilà class hay lớpcácTEST CASE. • Trongmỗi class chọn test chỉmộtvài test case. • Nêntest nhiều class thaycho test nhiều test cases trongcùngmột class.

33. Cácphươngphápkỹthuậttest(tt) • Control flow testing – Luồngđiềukhiển • PhânloạicácTEST CASEtheosơđồmôhìnhluồngxửlý (Đólàsơđồmôhìnhhoáhành vi củahệthống, chứkhôngphảilàsơđồmôtảcáccâulệnhtrong code). • Mỗirẽnhánhtrongluồngxửkýlà 1 TEST CASE. • Đâylà 1 kỹthuật test cănbản, ápdụnghiệuquảđượcchohầuhếtcáchệthống, ápdụngđượcchomọigiaiđoạn test.

34. Cácphươngphápkỹthuậttest(tt) • Data flow testing – Luồngdữliệu • Ápdụngcholoạihệthốngđòihỏivàxửlýnhiềudữliệu (data-intensive) • PhânloạicácTEST CASEtheosơđồmôhìnhluồngdữliệu

35. Cácphươngphápkỹthuậttest(tt) • Transaction testing – Giaodịch • Ápdụngchocáchệthốngxửlýgiaodịch (cácgiaodịchtrongngânhàng, đặtvémáy bay, đặtphòngkháchsạn…) • PhânloạiTEST CASEtheoloạicácgiaodịch, chútrọngviệcxácđịnhđiểmkhởiđầu, điểmkếtthúc, vàhàngđợicácđiểmgiaodịchcầnxửlý.

36. Cácphươngphápkỹthuậttest(tt) • Syntax testing – Cúpháp • Ápdụng test cáccâulệnh, cáctrườngtoántửcóđịnhdạngxácđịnh. • Phântích, nắmrõcáccúphápđểthiếtkếcácTEST CASE, sửdụngkỹthuậtphânlớptươngđương, vàtheoloạiđúnghoặcsaicúpháp.

37. Cácphươngphápkỹthuậttest(tt) • State machine testing – Trạngthái • Ápdụngcholoạihệthốngcóđặctrưngchuyểnđổitrạngthái, các “menu driven application” – Chươngtrìnhđiềukhiểnbằngtrìnhđơn, cáchệthốngthiếtkếbằngphươngpháphướngđốitượng. • CácTEST CASEđượcphânloạitừviệclậpcácbiểuđồchuyểnđổitrạngtháicủahệthống, theoloạichuyểnđổitrạngtháihợplệvàkhônghợplệ.

38. Cácphươngphápkỹthuậttest(tt) • Loop testing – Vònglặp • Ápdụngtrongwhitebox testing: quantâmđếnvònglặptrong code. • Ápdụngtrongblackbox testing: quantâmđếnvònglặptronghành vi củahệthống. • PhânloạicácTEST CASEtheosốgiátrịđặcbiệtlầnrẽnhánhcácvònglặp.

39. Cácphươngphápkỹthuậttest(tt) • Domain testing – vùng • Ápdụngcholoạihệthốngxửlýnhiềuvùnggiátrịcủabiến. • PhânloạicácTEST CASEtheovùnggiátrịcủabiến, đặcbiệtchútrọngcácTEST CASEquanhbiênranhgiới, nơihệthốngcónhữngxửlýkhácnhau so vớicácgiátrịbiếnkhác.

40. Chiếnlược test • Danhsáchcácưutiên test - “where to focus testing” • Nhữngvùngquantrọngnhấtcủaphầnmềm • Nhữngvùngphầnmềm hay đượcdùngnhất • Nhữngvùngcóđặctrưngriêng, khácbiệthẳnvớicácvùngkháccủaphầnmềm • Nhữngvùngphầnmềmdễbịảnhhưởngnhấtcủacácthayđổivừacó (khi regression test)

41. Chiếnlược test (tt) • Nhữnglỗidễxảyranhất • Nhữnglỗi (ngườidùng) dễnhìnthấynhất • Nhữngloạilỗikhó fix nhất • Nhữngloạilỗimà tester biếtrõnhất • Nhữngloạilốimà tester biếtlờmờnhất • Positive test trước, negative test sau (test cáctrườnghợphợplệtrước, cáctrườnghợpkhônghợplệsau)

42. Chiếnlược test (tt) • Ưutiênsắpxếp test theo quality dimension • Số1: thườnglà Function testing, vàphảibaoquátđượcbussines cycle củahệthống. • Số2: Usability testing, chú ý test GUI, đảmbảođúng syntax, theo standards và user friendly.

43. Giớithiệu Cáckhíacạnh test trên web Mứcđộ KTPM Cácthànhphầnvàchuẩn UI Kỹthuậtvàchiếnlược KTPM Côngcụkiểmthử Xâydựng test plan Rènluyện Quảnlýtiếntrìnhkiểmthử Báocáo Nội dung Web testing Kiếnthứctổngquan

44. Testplan • Tàiliệumôtảkếhoạchcủahoạtđộng test dựkiến, baogồm: • Mụctiêu, phạm vi, phươngpháptiếpcận, nhânlực, tàinguyên, lịchbiểu. • Nhiệmvụ test, môitrường test • Kỹthuậtthiếtkế test, tiêuchuẩn test • Lý do lựachọnvàrủirocóthểxảyra

45. Testplan (tt) • Cáchạngmụccótrongtestplan • Tiêu đề • Version củaphầnmềm • Quá trình hiệu chỉnh tài liệu như tác giả, ngày cập nhật, duyệt • Mụclục • Mục đích/ mụctiêu của tài liệu • Giớithiệutổngquanvềsảnphẩm • Tàiliệuliênquannhư spec, tài liệu thiết kế, các kế hoạch test khác,...

46. Testplan (tt) • Phạm vi và giới hạn test • Các vấn đề ưu tiên và tập trung test • Phâncôngnguồnnhânlực • Môitrường test • Côngcụ test • Qui trình test • Phươngpháp test • …

47. Testplan (tt) • Làmthếnàođểxâydựngtestplantốt? • Dựatrênđặctảyêucầu, thiếtkếsảnphẩm • Ápdụngcáckỹthuật test • Kếhoạch test phảitiếnhànhsớm • Phânchianhânlựcvànguồntàinguyênhợplý • Dựatrênkinhnghiệmcácdựántươngtự • Cácmẫutestplanthamkhảo

48. Giớithiệu Cáckhíacạnh test trên web Mứcđộ KTPM Cácthànhphầnvàchuẩn UI Kỹthuậtvàchiếnlược KTPM Côngcụkiểmthử Xâydựng test plan Rènluyện Quảnlýtiếntrìnhkiểmthử Báocáo Nội dung Web testing Kiếnthứctổngquan

49. Hoạtđộng QC trong QT PTPM