Bài giảng Kiểm thử phần mềm - Bài 1: Tổng quan kiểm thử phần mềm - Nguyễn Thị Thanh Trúc

cầu 
 – Không đồng bộ về các phiên bản của tài liệu 
 yêu cầu người dùng và tài liệu đặc tả 
 – Bản đặc tả có thêm những yêu cầu không 
 xuất phát từ người dùng 
 25 
26 
• Khoảng cách giữa bản đặc tả và sản phẩm: 
 – Hiểusai yêu cầu đặc tả do trong bản đặc tả có những 
 chỗ diễnđạt chưa rõ ràng cụ thể. 
 – Có các yêu cầu được đưa thêm vào trong quá trình 
 phát triển nhưng không được thêm vào bản đặc tả. 
 – Có sự thay đổi yêu cầu trong quá trình phát triển 
 nhưng không được cập nhật vào bản đặc tả
 – Các tính năng mới được thêm vào bởi mục đích riêng 
 của người phát triển 
 – Cácyêu cầu có trong bản đặc tả nhưng bị bỏ qua do 
 quá khó để thực hiện 
 27 
1.2 Tiếp 
• Khoảng cách giữa yêu cầu người dùng và 
 sản phẩm: 
 – Khoảng cách này xuất hiện do sản phẩm làm 
 ra không thỏa mãn yêu cầu người dùng 
 – Độ lệch này phụ thuộc vào hai cạnh còn lại 
 của tam giác chất lượng 
 – Đây là độ lệch gây tốn kém nhất để sửa chữa
 28 
 1.3 Khái niệm kiểm thử 
• Theo Glenford Myers: 
 – Kiểm thử là quá trình vận hành chương trình để 
 tìm ra lỗi 
• Theo IEEE: Kiểm thử là 
 – (1) Là quá trình vận hành hệ thống hoặc thành 
 phần dưới những điều kiện xác định, quan sát 
 hoặc ghi nhận kết quả và đưa rađánh giá về hệ 
 thống hoặc thành phần đó.
 – (2) Là quá trình phân tích phần mềm để tìm ra sự 
 khác biệt giữa điều kiện thực tế và điều kiện yêu 
 cầu và dựa vào điểm khác biệt đó để đánh giá 
 tính năng phần mềm 29 
1.4 Mục tiêu của kiểm thử 
• Tìm ra được càng nhiều lỗi càng tốt trong 
 điều kiệnvề thời gian đãđịnh và nguồn lực 
 sẵn có 
• Chứng minh rằng sản phẩm phần mềm phù 
 hợp với các đặctả của nó. 
• Xácthực chất lượng kiểm thử phần mềm đã 
 dùng chi phí và nỗ lực tối thiểu 
• Thiếtkế tài liệu kiểm thử một cách có hệ
 thống vàthực hiện nó sao cho có hiệu quả, 
 tiết kiệm được thờigian công sức. 
 30 
1.5 Tầm quan trọng của kiểm thử 
 31 
1.5 Tầm quan trọng của kiểm thử 
 32 
Qui trình phát triển phần mềm RUP 
 33 
1.5 Tầm quan trọng của kiểm thử 
 34 
Cost of bugs 
 $14,000 
 85% % Defects 
 Introduced in 
 this phase 
 % Defects 
 found in 
 in this phase 
 $1000 
 $ Cost to 
 Percentage of Bugs of Percentage $130 $250 repair defect 
 $25 in this phase 
 Coding Unit Funct Field Post 
 Test Test Test Release 
 Source: Applied Software Measurement, 
 Capers Jones, 1996 
36 
Lỗi tăng lên khi nào? 
 37 
1.5 Tầm quan trọng của kiểm thử 
• Những người phát triển phần mềm cho rằng: 
 – Kiểmthử chỉ để chứng minh chương trình không 
 có lỗi 
 – Mụcđích của kiểm thử là chỉ ra rằng chương 
 trình đã thực hiện đúng các chức năngđã đưa ra. 
 – Kiểm thử là quytrì nh thực hiện để chứng tỏ 
 chương trình đã làm được các chức năng cần có. 
• Những ý kiến trên về kiểm thử đãđầy đủ? 
 – Kiểm thử còn để tìm ra lỗi và sửa chữa các lỗi đó
 nhằm tăng độ tin cậycho phần mềm. 
 38 
 1.5 Tầm quan trọng của kiểm thử 
• Tại sao cần thực hiện kiểm thử? 
 – Để xem xét chất lượng sản phẩm 
 – Để phát hiện ra lỗi 
• Ví dụ: Khách hàng có thể rút tiền ở máy ATM với số tiền tối
 đa là 250$/1 giao dịch 
 – Người kiểm thử 1: 
 – Thử 3 lần với 3 yêu cầu:50 $, 150$, 250$ thấy máy đều 
 nhả ra số tiền chính xác, kếtluận chức năng rút tiền hoạt 
 động đúng yêu cầu của khách hàng là yêucầu rútra bao 
 nhiêu đều trả về đúng bây nhiêu tiền. 
 – Người kiểm thử2 : 
 – Yêu cầu số tiền là 300$, máy vẫn nhả ra đúng 300$ mà ko 
 đưa ra thông báo số tiền rút bị quá hạn, như vậy là có lỗi 
 mà người kiểm thử1 ko tìm ra được. 39 
Vai trò kiểm thử 
• Vai trò kiểm thử trong suốt quy trình sống 
 của phần mềm 
 – Kiểm thử không tồn tại độc lập. 
 – Các hoạt động của kiểm thử luôn gắn liền với 
 các hoạt động phát triển phần mềm. 
 – Các mô hình phát triển phần mềm khác nhau 
 cần các cách tiếp cận kiểm thử khác nhau. 
1.6 Các nguyên tắc trong kiểm thử 
• Trong kiểm thử có 7 nguyên tắc cơ bản: 
1. Kiểm thử chỉ ra sự hiện diện của lỗi trong phần 
mềm 
2. Kiểm thử tất cả các trường hợp là điều không thể
3. Nên thực hiện kiểm thử càng sớm càng tốt 
4. Sự phân cụm của các lỗi 
5. Nghịch lý thuốc trừ sâu 
6. Kiểm thử theo các ngữ cảnh độc lập 
7. Sự sai lầm về việc không có lỗi 
 41 
1.7 Phân loại kiểm thử 
• Phân loại kiểm thử dựa trên các yếu tố:
 – Mục đích kiểm thử 
 – Chiến lược kiểm thử 
 – Phương pháp kiểm thử 
 – Kỹ thuật kiểm thử 
 42 
1.7.1 Dựa vào mục đích kiểm thử 
 • Kiểm thử đơn vị, module 
 • Kiểm thử cấu hình 
 • Kiểm thử sơ lược (smoke testing) 
 • Kiểm thử chức năng 
 • Kiểm thử tích hợp 
 • Kiểm thử hồi quy 
 • Kiểm thử hệ thống 
 • Kiểm thử tải dữ liệu (load testing) 
 • Kiểm thử tải trọng (stress testing) 
 • Kiểm thử hiệu suất (performance testing) 
 • Kiểm thử chấp nhận (UAT) 
 • Kiểm thử bảo mật (security testing) 43 
1.7.2 Dựa vào chiến lược kiểm thử 
• Kiểm thử thủ công: 
 – Thực hiện kiểm thử mọi thứ bằng tay, từ viết 
 test case đến thực hiện test. 
• Kiểm thử tự động: 
 – Thực hiện một cách tự động các bước trong 
 kịch bản kiểm thử bằng cách dùng một công 
 cụ trợ giúp 
 – Kiểm thử tự động nhằm tiết kiệm thời gian 
 kiểm thử 
 44 
 1.7.3 Dựa vào pp tiến hành kiểm thử 
• Kiểm thử tĩnh: 
 – Mộthì nh thức của kiểm thử mà phần mềm không được 
 sử dụng thựcsự. 
 – Thường không kiểm thử chi tiết mà chủ yếu kiểm tra
 tính đúng đắn của code, thuật toán hoặc tài liệu 
 – Các hoạt động: Đi xuyên suốt (walk through), thanh tra 
 (inspection) 
• Kiểm thử động: 
 – Mộthì nh thức kiểm thử phần mềm chạy mãlập trình 
 thực tếtrong cáctì nh huống, diễn ra khi bản thân 
 chương trình đó đang được sử dụng 
 – Kiểm thử động có thể bắt đầu trước khi chương trình đã 
 hoàn tất. 
 45 
1.7.4 Dựa vào kỹ thuật kiểm thử 
• Kiểm thử hộp trắng 
 – Kiểm thử theo góc nhìn thực hiện 
 – Cần có kiến thức về chi tiết thiết kế và thực hiện bên
 trong 
 – Kiểm thử dựa vào phủ các lệnh, các nhánh, phủ các
 điều kiện con 
• Kiểm thử hộp đen 
 – Kiểm thử theo góc nhìn sử dụng 
 – Kiểm thử dựa trên các yêu cầu và đặc tả sử dụng thành 
 phần phần mềm 
 – Không đòi hỏi kiến thức về chi tiết thiết kế và thực hiện
 ở bên trong chương trình 
 46 
 1.8 Một số khái niệm liên quan 
• Xác minh (Verification) 
 – Xác minh là quy trình xác định xem sản phẩm của một 
 công đoạn trong quy trình phát triển phần mềm có thỏa 
 mãn các yêu cầu đặt ratrong công đoạn trước hay 
 không?(Ta có đang xây dựng đúng sản phẩm mà được 
 đăc tả không?) 
 – Xác minh quan tâm tới việc ngăn chặn lỗi giữa các công 
 đoạn 
 – Xác minh thường là hoạt động kỹ thuật vànó có sử 
 dụng cáckiến thứcvề các yêu cầu, các đặc tả rời rạc
 của phần mềm 
 – Các hoạt động của xác minh bao gồm: Kiểm thử
 (Testing) vàRà soátloại (Review) 
 47 
1.8 Một số khái niệm liên quan 
• Thẩm định (Validation) 
 – Làtiến trình nhằm chỉ ra toàn bộ hệ thống đã 
 phát triển xong phù hợp với tài liệu mô tả yêu 
 cầu. Thẩm định là quá trình kiểm chứng 
 chúng ta xây dựng phầm mềm có đúng theo 
 yêu cầu khách hàng không? 
 – Thẩm định chỉ quan tâm đến sản phẩm cuối 
 cùng không còn lỗi 
 48 
1.8 Một số khái niệm liên quan 
 49 
 1.8 Một số khái niệm liên quan 
• Xác định và thẩm định (vertification & Validation) 
 A we producing A we producing 
 the product right? the right product? 
 50 
 Testing Approach 
 Mobile testing 
 Beta testing Alpha testing 
 Test 
 Regression testing 
Database testing Level 
 Test Test 
 Re-testing Stress testing 
 Method Type 
 SQL testing GUI testing 
 Smoke testing Sanity testing 
 Web testing 
 Installation testing Load testing 
  testing 
 51 
1.8 Một số khái niệm liên quan 
• Dữ liệu kiểm thử (test data): Dữ liệu cần 
 cung cấpđể phầnmềm có thể thực thi để 
 kiểm thử 
• Kịch bản kiểm thử (test scenario): Các 
 bước thực hiện khi kiểm thử 
• Kỹsư kiểm thử (tester): người thực hiện 
 kiểm thử 
 52 
 1.8 Một số khái niệm liên quan 
• Ca kiểm thử (test case): chứa các thông tin cần thiết 
 để kiểm thử thành phần phần mềm theo 1 mục tiêu 
 xác định. 
• Test case gồm bộ3 thông tin { tập dữ liệu đầu vào, 
 thứ tự thực hiện, tập kết quả kỳ vọng} 
 – Tập dữ liệu đầu vào (input): gồm các giá trị dữ liệu 
 cần thiếtđể thànhphần phần mềm dùng và xửlý 
 – Tập kết quả kỳ vọng (output): kết quả mong muốn 
 sau khi thành phần phần mềm xử lý dữ liệu nhập 
 – Thứ tự thực hiện: 
 53 
1.8 Một số khái niệm liên quan 
• Ca kiểm thử (test case): chứa các thông tin cần thiết 
 để kiểmthử thành phần phần mềm theo 1 mục tiêu xác 
 định. 
• Test case gồm bộ 3 thông tin { tập dữ liệu đầu vào, thứ 
 tự thực hiện, tập kết quả kỳ vọng} 
 – Tậpdữ liệu đầu vào (input): gồm các giá trị dữ liệu 
 cần thiết để thành phần phần mềm dùng và xửlý 
 – Tậpkết quả kỳ vọng (output): kết quả mong muốn 
 sau khi thành phần phần mềm xử lý dữ liệu nhập 
 – Thứ tự thực hiện: các bước để hoàn thành ca kiểm 
 thử từ lúc nhập dữ liệu đầu vào tới lúc nhận được 
 kết quả đãqua xử lý của phần mềm 
 54 
 1.8 Một số khái niệm liên quan 
• Thiếtkế các ca kiểm thử dựa trên thứ tự thực hiện các ca kiểm thử:
• Kiểm thử nối tầng 
 – Mộtca kiểm thử này có thể được xây dựng dựa trên một ca kiểm thử
 khác. 
 – Ưu điểm của phong cách này là mỗi ca kiểm thử sẽ trở nên nhỏ hơnvà
 đơn giản hơn. 
 – Nhược điểm là nếu một ca kiểm thử sai, sẽ dẫn tới ca kiểm thử xây
 dựng dựa trên ca kiểmthử đó sẽ sai theo 
• Kiểm thử độc lập 
 – Mỗica kiểm thử được xây dựng độc lập, không dựa vào các ca kiểm thử
 khác,và khôngđò i hỏi các ca kiểm thử khác phải thực hiện thành công. 
 – Ưu điểm của phong cách này là một ca kiểm thử có thể thực hiện bấtcứ
 lúc nào,ko phụthuộc vào thứ tự thực hiện các ca kiểm thử. 
 – Nhược điểm chính là mỗi ca kiểm thử sẽ trở nên cồng kềnh và phức tạp
 hơn, vàcũng làmcho quátrì nh thiết kế, thực hiện và bảotrì trở nên khó 
 khăn hơn. 55 
1.9 Đối tượng thực hiện kiểm thử 
• Sơ đồ tổ chức của đội kiểm thử 
 56 
Các worker và qui trình 
 57 
58 
59 
1.9 Đối tượng thực hiện kiểm thử 
 60 
61 
1.10 Các điểm cần lưu ýkhi kiểm thử 
 1. Chấtlượng phần mềm không phải do khâu kiểm thử 
 màdo khâu thiết kế quyết định 
 2. Tính dễ kiểm thử phụ thuộc vào cấu trúc chương 
 tr.nh 
 3. Người kiểm thử nên làm việc độc lập với người phát 
 triểnphần mềm 
 4. Dữ liệu thử cho kết quả bình thường thìkhông có ý 
 nghĩa nhiều, cần có những dữ liệu kiểm thử để phát 
 hiện ra lỗi 
 5.Khi phát sinh thêm trường hợp thử thìnên thử lại 
 những trường hợp thử trước đó để tránh ảnh hưởng 
 lan truyền sóng. 
 62 
1.11 Các hạn chế của kiểm thử 
• Không thể chắc chắn đặc tả phần mềm đúng hoàn 
 toàn 
• Không thể chắc chắn hệ thống hay tool kiểm thử là 
 đúng 
• Không có tool kiểm thử nào thích hợp cho mọi 
 phần mềm 
• Kỹ sư kiểm thử không chắc chắn họ hiểu đầy đủ về
 sản phẩm 
• Không có tài nguyên để thực hiện tất cả các kiểm 
 thử 
• Không thể tìm ra được tất cả các lỗi 
 63 
CHUYỆN VUI: VÒNG ĐỜI CHẤT LƯỢNG 
• 1. Lập trình viên đưa ra đoạn mã mà anh ta tin rằng không hề có lỗi. 
• 2. Kiểm tra chất lượng sản phẩm, phát hiện 20 lỗi. 
• 3. Lập trình viên sửa 10 lỗi và gửi e-mail tới phòng Thử nghiệm sản phẩm về 10 
 "vấn đề" còn lại mà anh ta nhất định cho rằng không phải là lỗi. 
• 4. Phòng thử nghiệm sản phẩm e-mail lại rằng 5 trong số 10 đoạn sửa lỗi không 
 hoạt động và đính kèm danh sách 15 lỗi mới. 
• 5. Phòng tiếp thị gởi thông báo rằng họ đã hoàn tất khâu quảng bá cho sản phẩm. 
 Giám đốc gọi điện xuống hỏi về tiến độ công việc và củng cố tinh thần "chiến sỹ". 
 Phòng phát hành cử nhân viên đến nhận đĩa nguồn phần mềm. Phòng tiếp thị 
 thông báo trên truyền hình và báo chí về việc hoãn lại ngày phát hành sản phẩm 
 vài tuần... 
• 6. Ơn trời! Cuối cùng sản phẩm cũng được phát hành. 
• 7. Trong vòng một tuần, người sử dụng phát hiện ra 137 lỗi mới. 
• 8. Lập trình viên phụ trách phát triển sản phẩm đã xin nghỉ phép. 
• 9. Một nhóm "cứu nạn" gồm nhiều lập trình viên kỳ cựu được thành lập khẩn cấp. 
 Sau một tuần làm việc cật lực, họ đã "thanh toán" hết 137 lỗi, nhưng lại được thông 
 báo về 456 lỗi mới. 
• 10. Mọi người tổng kết được 783 lỗi trong chương trình. 
• 13. Giám đốc ngồi tại bàn giấy xem xét các báo cáo và quyết định thuê một lập 
 trình viên mới toanh để xây dựng lại phần mềm từ đống đổ nát ban đầu. 
• 1NEW. Lập trình viên mới đưa ra đoạn mã mà anh ta tin rằng không hề có lỗi. 
Yêu cầu với Lớp. 
• Hình thành nhóm 
• Giới thiệu thành viên nhóm 
 – Tự giới thiệu thông tin cá nhân 
 – Đề xuất phương tiện truyền thông & họp nhóm 
• Đăng ký nhóm 
• Đăng ký đề tài dự án thực hiện của Nhóm trong 
 suốt khóa học 
• Gửi danh sách tất cả các nhóm cho lớp trưởng 
 65 
Đề tài tiểu luận + báo cáo 
Mỗi nhóm sinh viên từ 2-3 người chọn1 : 
• Đề tài1 : Hệ thống quản lý bug: Bugzilla 
• Đề tài2 : Kiểm thử trên thiết bị di động (mobile testing) 
• Đề tài3 : Công cụ kiểm thử tự động: Selenium 
• Đề tài4 : Công cụ hỗ trợ kiểm thử tự động: Robotium. 
• Đề tài5 : Công cụ hỗ trợ kiểm thử tự động: AutoIT 
• Đề tài6 : Công cụ hỗ trợ kiểm thử Mantis Bug 
 Tracker 
• Đề tài7 : Công cụ hỗ trợ kiểm thử Sahi 
• Đề tài 8 : Công cụ hỗ trợ kiểm thử Soap UI
• Đề tài9 : Công cụ hỗ trợ kiểm thử Behavior Testing 
 66 
Test Tools 
 Test tools: 
 – Defect tracking tool 
 – Test Effort tracking tool 
 – Test schedule 
 – Test automation tools 
 –Rational Robot (Functional & Performance 
 test) 
 –OpenSTA (Open source), Witir (Open 
 source) 
 67 
Bài tập trên lớp 
• BT1: Viết 5 test requirements cho phần mềm 
 Mini-bank và4 testcases tương ứng cho mỗi 
 test requirement. (Tuần 6) 
• BT2: Thực thi kiểm thử sử dụng bộ testcase 
 ởbài tập1 và báo cáo kết quả. testcaseNếu 
 failed, tiến hành report bug. (Tuần 9) 
• BT3: Thực hành áp dụng các kỹ thuật hỗ trợ
 thiết kế testcase (white box) để thiết kế test 
 case cho một đoạn chương trình cụ thể (java 
 hoặcC/C ++) (Tuần 12) 
 68