1 / 79

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

Môn học Kiểm chứng phần mềm. Th.S Nguyễn Thị Kiêm Ái. Giới thiệu. Các khía cạnh test trên web. Mức độ KTPM. Các thành phần và chuẩn UI. Kỹ thuật và chiến lược KTPM. Công cụ kiểm thử. Xây dựng test plan. Rèn luyện. Quản lý tiến trình kiểm thử. Báo cáo. Nội dung. Web testing.

maylin
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. 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.

  6. 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.

  7. 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.

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

  9. Độđ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.

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

  11. 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?

  12. 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.

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

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

  15. Test Case làgì? • 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

  16. 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

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

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

  19. 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)

  20. 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.

  21. 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

  22. 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..

  23. 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

  24. 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

  25. 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.

  26. 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

  27. 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.

  28. 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.

  29. 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

  30. 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ý.

  31. 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.

  32. 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ệ.

  33. 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.

  34. 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.

  35. 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)

  36. 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)

  37. 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.

  38. 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

  39. 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

  40. 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êucủ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,...

  41. 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 • …

  42. 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ự

  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. Hoạtđộng QC trong QT PTPM

  45. Cácgiaiđoạnkiểmthử • Lậpkếhoạchkiểmthửtestplan • Xâydựngcáctrườnghợpkiểmthử testcase • Thựcthi excute • Đánhgiá, báocáolỗi bug report

  46. http://hcmus.byethost32.com/client/index.php

More Related