![43
v1.1013109225
VÍ DỤ 2
double average(double value[], double min, double max,
int& tcnt, int& vcnt) {
double sum = 0;
int i = 1;
tcnt = vcnt = 0;
while (value[i] <> -999 && tcnt <100) {
tcnt++;
if (min<=value[i] && value[i] <= max)
sum += value[i];
vcnt ++;
}
i++;
}
if (vcnt > 0) return sum/vcnt;
return -999;
}
9
10
11
12
4 6
7
8
2
1
5
1
2
3
4
5
6
7
8
9
10
11 12](https://image.slidesharecdn.com/se301bai2v1-220822075519-a127dece/85/Test-Types-Test-Levels-pdf-43-320.jpg)
Test Types & Test Levels.pdf
- 1. 1 v1.1013109225 BÀI 2 KIỂM THỬ PHẦN MỀM Giảng viên: ThS. Trần Mạnh Thắng
- 2. 2 v1.1013109225 TÌNH HUỐNG DẪN NHẬP Kiểm thử phần mềm là gì? và có những phương pháp, chiến lược, kỹ thuật và cấp độ kiểm thử nào? Nó được áp dụng như thế nào trong quá trình sản xuất phần mềm của công ty STT? • Như trong bài một thì chúng ta đã có những khái niệm về công nghệ phần mềm, các pha trong tiến trình xây dựng cũng như các mô hình sản xuất các phần mềm… để công ty STT có thể sử dụng trong quá trình sản xuất các sản phẩm phần mềm tuỳ theo quy mô và đặc điểm của từng sản phẩm; • Tuy nhiên, phần mềm do công ty STT sản xuất ra liệu có đạt yêu cầu về chất lượng và có đáp ứng được đúng theo yêu cầu của khách hàng cũng như việc phát sinh ra lỗi khi khách hàng đưa vào sử dụng các sản phẩm do công ty này sản xuất. Chính vì lý do này mà phải tiến hành kiểm thử phần mềm.
- 3. 3 v1.1013109225 MỤC TIÊU Trình bày được khái niệm kiểm thử phần mềm; Mô tả các kỹ thuật thiết kế kiểm thử phần mềm; Trình bày các phương pháp kiểm thử phần mềm; Trình bày các chiến lược kiểm thử phần mềm; Trình bày được các cấp độ kiểm thử phần mềm; Xây dựng một ứng dụng có sử dụng một trong các phương pháp, kỹ thuật, chiến lược kiểm thử.
- 4. 4 v1.1013109225 NỘI DUNG Khái niệm kiểm thử phần mềm 1 Các phương pháp kiểm thử 2 Các kỹ thuật thiết kế kiểm thử 3 Các chiến lược kiểm thử 4 Các cấp độ của việc kiểm thử phần mềm 5
- 5. 5 v1.1013109225 1. KHÁI NIỆM KIỂM THỬ PHẦN MỀM 1.1. Khái niệm 1.2. Vòng đời kiểm thử phần mềm 1.3. Phân loại kiểm thử
- 6. 6 v1.1013109225 1.1. CÁC ĐỊNH NGHĨA • Kiểm thử (testing) là quá trình thực thi một chương trình với mục đích là tìm ra lỗi (Glen Myers); • Việc kiểm thử là nói đến các lỗi, sai sót, hỏng hóc hoặc các hậu quả. Một phép kiểm thử là cách chạy phần mềm theo các trường hợp kiểm thử với mục tiêu tìm ra sai sót và giải thích sự hoạt động chính xác (Paul Jorgensen); • Kiểm thử thành công là phát hiện ra lỗi; kiểm thử không phát hiện ra lỗi là kiểm thử dở (Sue A.Conger- The New SE); • Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía cạnh nào đó của hệ thống hay thành phần đó. (Theo Bảng chú giải thuật ngữ chuẩn IEEE của Thuật ngữ kỹ nghệ phần mềm- IEEE Standard Glossary of Software Engineering Terminology); • Có thể định nghĩa một cách dễ hiểu như sau: Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tính thực hiện theo cái mà chúng đã được thiết kế để làm, và không thực hiện bất cứ thứ gì không mong muốn. Đây là một pha quan trọng trong quá trình phát triển hệ thống, giúp cho người xây dựng hệ thống và khách hàng thấy được hệ thống mới đã đáp ứng yêu cầu đặt ra hay chưa?
- 7. 7 v1.1013109225 Lưu ý khi tiến hành kiểm thử: • Chất lượng phần mềm do khâu thiết kế quyết định là chủ yếu, chứ không phải khâu kiểm thử; • Tính dễ kiểm thử phụ thuộc vào cấu trúc chương trình; • Người kiểm thử và người phát triển nên khác nhau; • 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ử mà phát hiện ra lỗi; • Khi thiết kế trường hợp thử, không chỉ dữ liệu kiểm thử nhập vào, mà phải thiết kế trước cả dữ liệu kết quả sẽ có; • 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. 1.1. CÁC ĐỊNH NGHĨA (tiếp theo)
- 8. 8 v1.1013109225 Tương ứng giữa vòng đời dự án và kiểm thử 1.2. VÒNG ĐỜI CỦA KIỂM THỬ - TESTING LIFE CYCLE Đối tượng và phạm vi Đặc tả chức năng/ Thiết kế lô gíc Thiết kế Vật lý Cấu trúc chương trình và đặc tả môđun Mã hoá môđun chương trình Kiểm thử chấp nhận Kiểm thử hệ thống Kiểm tích hợp Kiểm đơn vị Kiểm hồi quy
- 9. 9 v1.1013109225 1.2. VÒNG ĐỜI CỦA KIỂM THỬ - TESTING LIFE CYCLE (tiếp theo) Mô tả yêu cầu Thiết kế Lập trình Kiểm nghiệm Phân loại lỗi Cô lập lỗi Giải pháp sửa lỗi Sửa lỗi Lỗi Lỗi Lỗi Sai sót Sai sót Sai sót Hậu quả
- 10. 10 v1.1013109225 1.3. PHÂN LOẠI KIỂM THỬ • Theo mức độ chi tiết của các bộ phận hợp thành phần mềm: Kiểm thử đơn vị (Unit); Kiểm thử hệ thống (System); Kiểm thử tích hợp (Integration). • Theo phương pháp kiểm thử: Kiểm thử hộp đen: Kiểm thử chức năng; Kiểm thử hộp trắng: Kiểm thử cấu trúc.
- 11. 11 v1.1013109225 1.3.1. MÔ HÌNH CHỮ V Các mức kiểm thử Phân tích yêu cầu Đặc tả phần mềm Thiết kế kiến trúc Thiết kế chi tiết Lập trình Test chấp nhận Test hệ thống Test tích hợp Test đơn vị Rà soát mã
- 12. 12 v1.1013109225 1.3.1. MÔ HÌNH CHỮ V • Mô hình chữ V biểu diễn sự tương quan giữa các công đoạn xây dựng phần mềm và loại kiểm thử phần mềm. Bên trái chữ V là quá trình phát triển phần mềm và bên phải là kiểm thử. Tại mỗi một mức trong tiến trình phát triển thì có một pha kiểm thử tương ứng; • Các mức kiểm thử có thể được lập kế hoạch và thiết kế song song. Sau đó chúng ta thực hiện kiểm thử từ đáy tháp chữ V nên tương ứng với từng mức phát triển. Kế hoạch kiểm thử hệ thống cần phải sớm hơn khi trước khi pha kiểm thử bắt đầu: Kế hoạch kiểm thử hệ thống là phải khớp với các yêu cầu phần mềm; Các trường hợp kiểm thử cần phải hoàn thành khi các thiết kế chi tiết đã xong; Kiểm thử hệ thống bắt đầu từ ngay trước khi lập trình.
- 13. 13 v1.1013109225 1.3.2. TIẾN TRÌNH KIỂM THỬ Kiểm thử đơn vị Kiểm thử tích hợp Kiểm thử hệ thống Kiểm thử chấp nhận Mỗi module Nhiều module, hệ con Phần cứng, phần mềm, yêu cầu hệ thống Yêu cầu người dùng, hệ thống
- 14. 14 v1.1013109225 2. CÁC PHƯƠNG PHÁP KIỂM THỬ 2.1. Kiểm thử tĩnh (Static testing) 2.2. Kiểm thử động (Dynamic testing)
- 15. 15 v1.1013109225 2.1. KIỂM THỬ TĨNH – KIỂM THỬ TRÊN BÀN • Khái niệm: Là phương pháp kiểm thử phần mềm đòi hỏi xem xét lại thông qua việc sử dụng giấy, bút để kiểm tra lần từng chi tiết mà không cần chạy chương trình. • Các phương pháp kiểm thử tĩnh: Thanh tra (Inspection); Đi xuyên suốt (Walkthrough) hay duyệt.
- 16. 16 v1.1013109225 • Khái niệm: Là phương pháp kiểm tra ngang hàng sản phẩm phần mềm thực hiện bởi những người nghiên cứu riêng lẻ để tìm ra những lỗi có thể bằng một tiến trình chuẩn cho trước. • Một cuộc thanh tra bao gồm: Đặc tả phần mềm; Kế hoạch thanh tra; Sản phẩm phần mềm; Điều phối viên; Thanh tra viên; Tác giả phần mềm. 2.1.1. KIỂM THỬ TĨNH BẰNG PHƯƠNG PHÁP THANH TRA • Tiến trình thanh tra Lên kế hoạch; Gặp gỡ trước; Chuẩn bị; Gặp gỡ thanh tra; Gia công lại; Bám sát.
- 17. 17 v1.1013109225 • Khái niệm: Là một phương pháp kiểm tra ngang hàng với một người thiết kế hướng nhóm phát triển đến các hoạt động chú ý của quá trình sản xuất phần mềm, tham gia đặt câu hỏi và chú thích cho các lỗi có thể có. • Khác biệt với thanh tra: Cấu trúc mở; Khả năng gợi ý định hướng thay đổi phần mềm. 2.1.2. KIỂM THỬ TĨNH BẰNG PHƯƠNG PHÁP DUYỆT • Tiến trình duyệt: Đánh giá đầu vào; Chuẩn bị quản lí; Lập kế hoạch; Gặp gỡ trước; Chuẩn bị riêng; Duyệt; Gia công/ bám sát; Kết thúc, đánh giá.
- 18. 18 v1.1013109225 • Khái niệm: Phương pháp kiểm thử phần mềm thông qua việc dùng máy chạy chương trình để điều tra trạng thái tác động của chương trình. • Các phương pháp kiểm thử động: Kiểm thử khuyết tật; Kiểm thử thống kê. 2.2. KIỂM THỬ ĐỘNG – KIỂM THỬ TRÊN MÁY • Đặc điểm của kiểm thử động: Các ca kiểm thử xác định bằng sự thực thi của đối tượng kiểm thử hay chạy các chương trình; Kiểm tra cách thức hoạt động động của mã lệnh, tức là kiểm tra sự phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian; Phần mềm phải thực sự được biên dịch và chạy; Làm việc với phần mềm, nhập các giá trị đầu vào và kiểm tra xem liệu đầu ra có như mong muốn hay không.
- 19. 19 v1.1013109225 Tiến trình kiểm thử động: 1. Thiết kế trường hợp thử theo thử tĩnh; 2. Trường hợp thử phải có cả kết quả kì vọng sẽ thu được; 3. Dịch chương trình nguồn và tạo modul tải để thử; 4. Xác định miền vào ra của tệp nếu cần thiết; 5. Nhập dữ liệu đã thiết kế cho truờng hợp thử; 6. Điều chỉnh môi trường thực hiện modul tải; 7. Thực hiện modul tải và ghi nhận kết quả; 8. Xác nhận kết quả với kết quả kỳ vọng; 9. Lặp lại thao tác từ 5-8. 2.2. KIỂM THỬ ĐỘNG – KIỂM THỬ TRÊN MÁY (tiếp theo)
- 20. 20 v1.1013109225 • Khái niệm: Phương pháp thử để tìm ra khuyết tật của phần mềm chủ yếu là lỗi lập trình; Tiến hành dựa trên phân tích đặc tả chức năng; Phân tích mã nguồn. • Các loại thử nghiệm khuyết tật: Thử nghiệm chức năng; Thử nghiệm cấu trúc. 2.2.1. KIỂM THỬ ĐỘNG BẰNG THỬ NGHIỆM KHUYẾT TẬT
- 21. 21 v1.1013109225 Khái niệm: • Phương pháp thử bằng cách đánh giá tính dùng được của sản phẩm sử dụng dữ liệu thực dựa trên thống kê của số người truy cập hoặc số thao tác; • Phương pháp này có bộ cơ sở dữ liệu thống kê rất lớn. 2.2.2. KIỂM THỬ ĐỘNG BẰNG THỬ NGHIỆM THỐNG KÊ
- 22. 22 v1.1013109225 3. CÁC KỸ THUẬT THIẾT KẾ KIỂM THỬ 3.1. Kiểm thử hộp trắng 3.2. Kiểm thử hộp đen
- 23. 23 v1.1013109225 3.1. KIỂM THỬ HỘP TRẮNG (WHITE BOX TESTING) Khái niệm: • Kiểm thử hộp trắng là kiểm thử dựa vào cấu trúc/mã lệnh chương trình (trong trường hợp này yêu cầu người kiểm thử phải biết ngôn ngữ lập trình); • Đây là kỹ thuật thiết kế trường hợp thử dựa trên đặc tả bên trong của chương trình. Results Input White Box Data Testing Strategy Kiểm thử hộp trắng để kiểm thử cái gì? Các lệnh trong chương trình Các điều kiện logic Các chu trình lặp lại Cấu trúc dữ liệu Các luồng điều khiển
- 24. 24 v1.1013109225 3.1.1. YÊU CẦU VÀ CÁC KỸ THUẬT VỚI KIỂM THỬ HỘP TRẮNG • Yêu cầu đối với kiểm thử hộp trắng: Những con đường độc lập trong modul được thực hiện ít nhất một lần; Những điều kiện logic được thực hiện với cả hai giá trị “True” và “False”; Các chu trình đều phải thực hiện trong nội dung vòng lặp và khi đặt trong hoạt động của hệ thống; Thực thi mọi cấu trúc dữ liệu để đảm bảo hiêu lực thi hàng của nó; Thực thi các luồng điều khiển theo một tiến trình từ đầu cho đến khi kết thúc; Thực hiện tất cả các vòng lặp ở biên của nó và cả với biên vận hành của nó; Áp dụng giai đoạn đầu của vòng kiểm thử. • Các kỹ thuật sử dụng với kiểm thử hộp trắng: Các câu lệnh (Statement); Đường dẫn (Path); Các điều kiện (Condition); Vòng lặp (Loop); Ngã rẽ (Branch).
- 25. 25 v1.1013109225 3.1.2. KIỂM THỬ HỘP TRẮNG VỚI CÁC CÂU LỆNH • Khái niệm: Là việc thiết kế các trường hợp kiểm thử một chương trình, một phần chương trình, một hệ thống hay một phần của hệ thống dựa vào cấu trúc/mã lệnh chương trình xem nó có đáp ứng tốt tất cả các giá trị đầu vào theo yêu cầu của chương trình; • Các câu lệnh của chương trình phải được thực hiện ít nhất một lần.
- 26. 26 v1.1013109225 3.1.3. KIỂM THỬ HỘP TRẮNG THEO ĐƯỜNG DẪN • Khái niệm: Là phương pháp kiểm tra bao trùm mọi đường dẫn của chương trình và cần kết hợp với lược đồ tiến trình. • Đặc điểm: Phụ thuộc nhiều vào các biểu thức điều kiện; Với những trường hợp có số lượng đường dẫn quá lớn thì không nên sử dụng phương pháp này để kiểm tra tính đúng đắn của chương trình.
- 27. 27 v1.1013109225 VÍ DỤ If (A>B) { S1; S2; } else S3; S4; while(A>B) { S1; S2; } S3; A>B A>B A>B A>B S3; S1;S2; S4; True False
- 28. 28 v1.1013109225 3.1.4. KIỂM THỬ HỘP TRẮNG THEO ĐIỀU KIỆN • Khái niệm: Là phương pháp kiểm tra các biểu thức điều kiện trên hai giá trị true và false; • Đặc điểm: Cần xem xét kết hợp các điều kiện với nhau; • Ví dụ: if (x>0 && y>0) x = 1; else x = 2; Các bộ kiểm tra { (x>0, y>0), (x<=0, y>0) } sẽ kiểm tra toàn bộ các điều kiện; Tuy nhiên: Không thỏa mãn với mọi giá trị input, cần kết hợp cả x và y để thực hiện bước kiểm tra.
- 29. 29 v1.1013109225 3.1.5. KIỂM THỬ HỘP TRẮNG THEO VÒNG LẶP • Khái niệm: Là phương pháp tập trung vào tính hợp lệ của các cấu trúc vòng lặp. • Có các loại kiểm tra vòng lặp: Vòng lặp đơn giản; Vòng lặp lồng nhau; Vòng lặp nối tiếp nhau; Vòng lặp không cấu trúc. Vòng lặp đơn giản Vòng lặp lồng nhau Vòng lặp nối tiếp nhau Vòng lặp không cấu trúc
- 30. 30 v1.1013109225 3.2. KIẾM THỬ HỘP ĐEN – BLACK BOX TESTING Khái niệm: • Là hình thức kiểm thử mà kiểm thử viên không cần biết đến cách thức hoạt động, mã nguồn, xử lý dữ liệu bên trong một thành phần/hệ thống. Công việc cần làm là nhập dữ liệu đầu vào và kiểm tra kết quả trả về có đúng như mong muốn hay không; • Còn được gọi là kiểm thử chức năng; • Là phương pháp tập trung về mặt yêu cầu chức năng của sản phẩm; • Có thể tạo ra một bộ các điều kiện đầu vào để kiểm thử tất cả. Black Box Results Input Kiểm thử hộp đen
- 31. 31 v1.1013109225 3.2.1. MÔ HÌNH KIỂM THỬ HỘP ĐEN Mô hình kiểm thử hộp đen Danh sách chức năng Dữ liệu đầu vào Đầu ra liên quan
- 32. 32 v1.1013109225 3.2.2. ĐẶC ĐIỂM VÀ MỤC ĐÍCH CỦA KIỂM THỬ HỘP ĐEN • Đặc điểm của kiểm thử hộp đen: Bổ xung cho phương pháp kiểm thử hộp trắng để phát hiện ra tất cả các lỗi khác nhau mà kiểm thử hộp trắng không phát hiện ra được; Không cần quan tâm đến thiết kế, mã nguồn mà chỉ quan tâm đến chức năng đã đề ra của chương trình; Chỉ dựa vào bản mô tả chức năng của chương trình; Hướng vào các đặc tả bên ngoài; Chủ yếu là kiểm tra giao diện; Áp dụng vào giai đoạn sau của vòng kiểm thử. • Mục đích của kiểm thử hộp đen: Tìm các loại sai liên quan đến: Chức năng: Đủ, đúng đắn; Giao diện vào, ra: Đủ, phù hợp đúng và tiện lợi; Cấu trúc truy cập dữ liệu: Thông suốt, đúng đắn; Thực thi trôi chảy, kịp thời, chịu lỗi phục hồi; Khởi đầu, kết thúc mỗi quá trình thông suốt.
- 33. 33 v1.1013109225 3.2.3. CÁC KỸ THUẬT THƯỜNG DÙNG CHO KIỂM THỬ HỘP ĐEN • Phân chia tương đương - Equivalence Partition Testing; • Phân tích giá trị biên - Boundary Value Analysis Testing; • Đồ thị Cause-Effect - Cause-effect Graphing Testing; • Kiểm tra hành vi – Behavioural Testing; • Ước lượng lỗi - Error Guessing Testing; • Kiểm thử mọi cặp – All-pairs Testing; • Kiểm thử fuzz – Fuzz Testing; • Kiểm thử dựa trên mô hình – Model Based Testing; • Ma trận dấu vết – Traceability Matrix Testing; • Kiểm thử thăm dò – Exploratory Testing; • Kiểm thử dựa trên đặc tả – Specification-base Testing.
- 34. 34 v1.1013109225 KIỂM THỬ HỘP ĐEN THEO PHÂN CHIA TƯƠNG ĐƯƠNG (EQUIVALENCE PARTITION) • Là loại kiểm thử chia miền dữ liệu vào của chương trình thành các lớp dữ liệu đầu vào đại diện để lập ra các ca kiểm thử theo mỗi lớp đó. Phân hoạch tương đương cố gắng xác định các ca kiểm thử mà không bao phủ các lớp lỗi, do đó giảm tổng số các kiểm thử sẽ được phát triển. • Thực hiện: Chia dữ liệu vào thành các đoạn có cùng hành vi; Mỗi đoạn lấy đại diện một số dữ liệu; Kiểm thử chỉ thực hiện trên đại diện đó; Nếu giá trị đại diện bị lỗi thì các thành phần còn lại cũng lỗi. • Ưu điểm: Test theo mức trừu tượng nên giảm số lượng test; • Nhược điểm: Không thể tiến hành kiểm thử mọi trường hợp nên có thể sót lỗi.
- 35. 35 v1.1013109225 VÍ DỤ • Công ty STT viết chương trình trong đó có một hàm tính giá trị tuyệt đối của một số nguyên. Hãy kiểm thử xem hàm này có thực hiện đúng hay không bằng phương pháp kiểm thử hộp đen theo phân chia tương đương. • Thực hiện: Chia các dữ liệu đầu vào thành hai lớp: Cách chia 1: Lớp hợp lệ là lớp có loại dữ liệu số nguyên đại diện đầu vào và ra yêu cầu là (2/2); Lớp không hợp lệ là lớp có loại dữ liệu số không nguyên: đại diện đầu vào và ra yêu cầu là (2,5/2,5). Cách chia 2: Lớp hợp lệ là lớp có loại dữ liệu số dương: Đại diện đầu vào và ra yêu cầu là (2/2); Lớp không hợp lệ là lớp có loại dữ liệu số âm: Đại diện đầu vào và ra yêu cầu là (-5/-5).
- 36. 36 v1.1013109225 KIỂM THỬ HỘP ĐEN THEO PHÂN TÍCH GIÁ TRỊ BIÊN - BVA (BOUNDARY VALUE TESTING) • BVA là kỹ thuật kiểm thử bổ sung thêm cho phân hoạch tương đương, nó dựa trên giá trị biên của vùng dữ liệu hợp lệ; • Thay vì chọn bất cứ phần tử nào của lớp tương đương, BVA chọn các ca kiểm thử sát với lớp tương đương; • Thay vì tập trung vào điều kiện vào, BVA còn đưa ra các ca kiểm thử từ miền ra; • BVA cho rằng số lớn các sai xuất hiện ở biên nhiều hơn là vùng dữ liệu trung tâm. Không những chú ý đến dữ liệu trong và sát biên mà còn chú ý đến dữ liệu ngoài và sát biên; • Thực hiện: Phân đoạn tương tương tập các giá trị dữ liệu vào thành các lớp; Chọn các giá trị ở biên của mỗi lớp; Chọn các giá trị trên và dưới của biên.
- 37. 37 v1.1013109225 VÍ DỤ • Một trường dữ liệu có định dạng dữ liệu số nguyên là 3. Tức là chỉ chấp nhận các giá trị nguyên, lớn hơn hoặc bằng 0, và nhỏ hơn hoặc bằng 999 (0<= x <=999); • Các giá trị biên là 0 và 999; • Kiểm thử theo giá trị biên nhằm đảm bảo hệ thống chỉ chấp nhận các giá trị x lớn hơn hoặc bằng 0 và nhỏ hơn hoặc bằng 999 mà không chấp nhận các giá trị nhỏ hơn 0 hoặc lớn hơn 999.
- 38. 38 v1.1013109225 3.1.2. KIỂM THỬ HỘP TRẮNG VỚI CÁC CÂU LỆNH (tiếp theo) Các bước kiểm thử hộp trắng với các câu lệnh: • Dùng tài liệu thiết kế hay mã nguồn để vẽ thuật toán của chương trình hay hàm; • Xác định đồ thị V(G); • Từ đồ thị V(G) xác định tập đường độc lập tuyến tính lẫn nhau; • Xây dựng trường hợp kiểm thử dựa trên tập đường độc lập tuyến tính ở trên.
- 39. 39 v1.1013109225 ĐƯỜNG ĐỘC LẬP TUYẾN TÍNH • Để đảm bảo các câu lệnh đều được kiểm thử ít nhất một lần, ta cần tìm tất cả các đường điều khiển độc lập trong chương trình, tức là mỗi đường khác với các đường khác ít nhất một lệnh; • Số các của một chương trình là giới hạn trên của số các kiểm thử cần phải tiến hành. Nó được gọi là độ phức tạp chu trình của chương trình; • Một tập cơ bản con đường độc lập là tập: Mọi cạnh của đồ thị dòng đều có mặt trong một con đường của tập này; Mỗi con đường của tập đó đều chứa ít nhất một cung không có mặt trong mọi con đường khác của nó; Số lượng các con đường của tập này cho ta số đo độ phức tạp chu trình của một chương trình.
- 40. 40 v1.1013109225 ĐÁNH GIÁ ĐỘ PHỨC TẠP CỦA ĐỒ THỊ DÒNG Đánh giá độ phức tạp của đồ thị dòng: Độ phức tạp chu trình V(G) đối với 1 đồ thị dòng G được định nghĩa là: V(G) = Số miền phẳng; V(G) = E - N + 2; V(G) = P + 1. Trong đó: E là số cạnh; N là số nút của đồ thị dòng; P là số nút vị từ. V(G) cung cấp số các đường đi độc lập trong một chương trình và nó được coi là cận trên của số lượng kiểm thử phải tiến hành để đảm bảo mỗi lệnh đều được thực hiện ít nhất một lần.
- 41. 41 v1.1013109225 CÁC ĐƯỜNG CƠ BẢN CỦA ĐỒ THỊ DÒNG • Đồ thị dòng (đồ thị chương trình) gần giống dòng điều khiển. • Nó là một đồ thị cấu trúc gồm: Mỗi nút (hình tròn) biểu thị một số (hoặc có thể là 0) câu lệnh thủ tục; Mỗi cạnh nối hai nút biểu diễn dòng điều khiển; Chia mặt phẳng thành nhiều miền; Một nút là vị từ nếu nó biểu thị sự phân nhánh hoặc hội nhập của cung. • Đồ thị dòng dùng để biểu diễn thiết kế thủ tục. if case while Tuần tự until
- 42. 42 v1.1013109225 VÍ DỤ 1 1 float foo(int a, int b, int c, int d) { 2 float e; 3 if (a==0) 4 return 0; 5 int x = 0; 6 if ((a==b) || ((c==d) && bug(a))) 7 x = 1; 8 e = 1/x; 9 return e; 10 } s1 c1 s2 c2 s3 s4 s5
- 43. 43 v1.1013109225 VÍ DỤ 2 double average(double value[], double min, double max, int& tcnt, int& vcnt) { double sum = 0; int i = 1; tcnt = vcnt = 0; while (value[i] <> -999 && tcnt <100) { tcnt++; if (min<=value[i] && value[i] <= max) sum += value[i]; vcnt ++; } i++; } if (vcnt > 0) return sum/vcnt; return -999; } 9 10 11 12 4 6 7 8 2 1 5 1 2 3 4 5 6 7 8 9 10 11 12
- 44. 44 v1.1013109225 VÍ DỤ 2 (tiếp theo) Đồ thị bên có 5 nút quyết định nhị phân nên có độ phức tạp C = 5 +1 = 6. 6 đường thi hành tuyến tính độc lập là : • 1 2 10 11 • 1 2 3 10 11 • 1 2 10 12 • 1 2 3 4 5 8 9 • 1 2 3 4 5 6 8 9 • 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 10 11 12
- 45. 45 v1.1013109225 VÍ DỤ 2 (tiếp theo) • Test case cho đường 1 2 10 11: value(k) <>-999, với 1< k < i; value(i) = -999 với 2 ≤ i ≤ 100; Kết quả kỳ vọng: (1) average = Giá trị trung bình của k giá trị hợp lệ. (2) tcnt = k. (3) vcnt = k; Chú ý: không thể kiểm thử đường 1 này riêng biệt mà phải khiểm thử chung với đường 4 hay 5 hay 6. • Test case cho đường 1 2 3 10 11: value(k) <>-999, với k < i , i >100; Kết quả kỳ vọng: (1) average = Giá trị trung bình của 100 giá trị hợp lệ. (2) tcnt = 100. (3) vcnt = 100. • Test case cho đường 1 2 10 12: value(1) = -999; Kết quả kỳ vọng: (1) average = -999. (2) tcnt = 0. (3) vcnt = 0;
- 46. 46 v1.1013109225 VÍ DỤ 2 (tiếp theo) • Test case cho đường 1 2 3 4 5 8 9: value(i) <> -999 i <= 100; và value(k) < min với k < I; Kết quả kỳ vọng: (1) average = Giá trị trung bình của n giá trị hợp lệ. (2) tcnt = 100. (3) vcnt = n (số lượng giá trị hợp lệ). • Test case cho đường 1 2 3 4 5 6 8 9: value(i) <>-999 với i <= 100 và value(k) > max với k <= i Kết quả kỳ vọng: (1) average = Giá trị trung bình của n giá trị hợp lệ. (2) tcnt = 100. (3) vcnt = n (số lượng giá trị hợp lệ). • Test case cho đường 1 2 3 4 5 6 7 8 9: value(i) <>-999 và min <= value(i) <= max với i <= 100 Kết quả kỳ vọng: (1) average = Giá trị trung bình của 100 giá trị hợp lệ. (2) tcnt = 100. (3) vcnt = 100.
- 47. 47 v1.1013109225 KIỂM THỬ HỘP ĐEN THEO ĐỒ THỊ CAUSE-EFFECT (CAUSE-EFFECT GRAPHING) • Là kỹ thuật kiểm thử phân tích việc kết hợp các điều kiện vào, tạo một đồ thị kết nối nguyên nhân – kết quả (cause-effect). Trong đó, nguyên nhân (cause) là đầu vào và kết quả (effect) là đầu ra. • Các bước tiến hành: Lập danh sách các nguyên nhân (điều kiện vào) và kết quả (hành động) cho từng môđun và gán giá trị định danh cho chúng; Phát triển đồ thị nhân quả; Chuyển đồ thị đó thành bảng quyết định; Sử dụng các quy luật của bảng quyết định để xây dựng các ca kiểm thử.
- 48. 48 v1.1013109225 KIỂM THỬ HỘP ĐEN THEO ĐỒ THỊ CAUSE-EFFECT (CAUSE-EFFECT GRAPHING) a b a b c a b a b c a b a b a b a b Các ký hiệu trong đồ thị nhân quả
- 49. 49 v1.1013109225 KIỂM THỬ HỘP ĐEN THEO ĐỒ THỊ CAUSE-EFFECT (CAUSE-EFFECT GRAPHING) yêu cầu Yêu cầu 7 bao hàm Bao hàm 6 Nếu đúng, thì sai, hoặc nếu sai, thì đúng. Loại trừ 5 Nếu sai, thì đúng. NOT (phủ định) 4 Nếu đúng hoặc đúng, thì đúng. OR (hoặc) 3 Nếu đúng và đúng, thì đúng. AND (và) 2 Nếu đúng thì đúng. Tương đương 1 Giải thích Ý nghĩa Ký hiệu STT
- 50. 50 v1.1013109225 VÍ DỤ KIỂM THỬ HỘP ĐEN THEO ĐỒ THỊ CAUSE-EFFECT Có modun chương trình tính thuế thu nhập, có mô tả sau: • Người vô gia cư nộp 4% thuế thu nhập; • Người có nhà ở nộp thuế như sau: Tổng thu nhập <= 5.000.000 đồng thì nộp thuế 4%; Tổng thu nhập > 5.000.000 đồng thì nộp thuế 6%. Nộp 4% thuế Nộp 6% thuế Người có nhà ở: Tổng thu nhập <= 5.000.000 đồng Tổng thu nhập > 5.000.000 đồng Kết quả Nguyên nhân Bảng quan hệ nguyên nhân và kết quả
- 51. 51 v1.1013109225 VÍ DỤ KIỂM THỬ HỘP ĐEN THEO ĐỒ THỊ CAUSE-EFFECT Đồ thị nguyên nhân và kết quả Nộp thuế 6% Nộp thuế 4% Có tổng thu nhập > 5.000.000 Có tổng thu nhập <= 5.000.000 Người có nhà ở X -- Y N Y 1 -- X N Y Y 2 -- -- X X Kết quả -- -- Y -- -- N Nguyên nhân 4 3 Trường hợp kiểm thử Nguyên nhân và kết quả
- 52. 52 v1.1013109225 4. CÁC CHIẾN LƯỢC KIỂM THỬ 4.1. Kiểm thử trên xuống (Top-down Test) 4.2. Kiểm thử từ dưới lên (Bottom-up Test) 4.3. Kiểm thử cột trụ (Big bang Test) 4.5. Kiểm thử kẹp (Sandwich Test)
- 53. 53 v1.1013109225 4.1. KIỂM THỬ TỪ TRÊN XUỐNG DƯỚI – TOP-DOWN TEST • Môđun điều khiển chính được dùng như trình điều khiển kiểm thử chính, gắn dần các mô đun từ trên xuống theo trật tự dòng điều khiển. Bắt đầu từ mô đun điều khiển chính, sau đó gắn từng mô đun phụ trợ vào mô đun điều khiển thượng cấp. Có thể theo hai cách: Theo chiều sâu trước; Theo chiều rông trước. • Kiểm thử được tiến hành khi từng môđun được tích hợp vào hệ thống. Các nút thử xong thì thử tiếp nút khác; • Cần có các cuống kéo theo những khó khăn dành cho cuống, có ngay chức năng điều khiển hệ thống.
- 54. 54 v1.1013109225 TIẾN TRÌNH KIỂM THỬ TỪ TRÊN XUỐNG Tiến trình này gồm 6 bước như sau: • Mô đun điều khiển chính được dung như bộ lái kiểm thử (Test Driver) và tất cả các mô đun phụ trợ trực tiếp được thay thế bởi các cuống (Stub); • Thay thế dần từng cuống bằng các mô đun thực thi tương ứng; • Sau khi tích hợp mô đun đó, tiến hành kiểm thử tương ứng; • Khi hoàn thành kiểm thử này thì thay thế một cuống khác bằng mô đun thực (nghĩa là quay lại bước 2); • Có thể kiểm thử lại (toàn bộ hoặc 1 phần các kiểm thử trước - kiểm thử hồi quy) để đảm bảo không có sai mới nào sinh ra; • Tiếp tục lặp lại bước hai cho đến khi toàn bộ chương trình cấu trúc được xây dựng. Sơ đồ ví dụ kiểm thử từ trên xuống Hệ cần kiểm thử Kết hợp theo chiều rộng Kết hợp theo chiều sâu
- 55. 55 v1.1013109225 4.2. KIỂM THỬ TỪ DƯỚI LÊN (BOTTOM-UP TEST) • Bắt đầu xây dựng kiểm thử từ các mô đun nguyên tố; • Việc xử lý nếu có đòi hỏi các mô đun phụ trợ thì các mô đun chính đã sẵn sàng (cuống đã bị loại); • Luôn chưa có chương trình chỉnh thể, thiết kế các ca kiểm thử dễ không cần cuống; • Thực hiện theo 4 bước: Các mô đun mức thấp được tích hợp thành các cụm thực hiện một chức năng phụ trợ nhất định; Một bộ lái được viết để phối hợp đầu vào và đầu ra của các ca kiểm thử; Kiểm thử cụm đó; Tháo bỏ các Driver và các cụm tổ hợp ngược lên trong cầu trúc chương trình.
- 56. 56 v1.1013109225 VÍ DỤ Vòng 1 Vòng 2 Vòng 3
- 57. 57 v1.1013109225 4.3. KIỂM THỬ CỘT TRỤ (BIG BANG TEST) • Tích hợp không tăng dần; • Tất các các môđun đều được tổ hợp trước; • Toàn bộ chương trình được kiểm thử tổng thể; • Khó khăn: Khó cô lập lỗi, khi chữa xong lỗi này có thể lỗi mới lại phát sinh.
- 58. 58 v1.1013109225 4.4. KIỂM THỬ KẸP (SANDWICH TEST) Phương pháp kiểm thử hỗn hợp (Sandwich) có thể là phương pháp phù hợp nhất: • Tích hợp trên xuống cho các mức trên cấu trúc chương trình; • Tích hợp dưới lên cho các mức phụ thuộc.
- 59. 59 v1.1013109225 5. CÁC CẤP ĐỘ KIỂM THỬ 5.1. Kiểm thử đơn vị 5.2. Kiểm thử tích hợp 5.3. Kiểm thử hệ thống 5.4. Kiểm thử chấp nhận sản phẩm 5.5. Một số cấp độ kiểm thử khác
- 60. 60 v1.1013109225 5.1. KIỂM THỬ ĐƠN VỊ (UNIT TESTING) • Unit Testing là việc kiểm thử ở mức độ thấp nhất là các phương thức (Method), hàm (Function), lớp (Class) trong mã nguồn. Nhằm đảm bảo các thành phần trên hoạt động đúng như yêu cầu; • Việc kiểm tra ở mức độ này thường do chính các lập trình viên (Developer) thực hiện trong quá trình mã hóa (Coding, Implement); • Một mô hình thường được ứng dụng với Unit Testing là Phát triển theo định hướng kiểm thử (Test-Driven Development): Các Unit Test viết trước dựa theo yêu cầu kết quả trả về ban đầu là sai (False); Mã nguồn sẽ được viết sau và được kiểm tra tự động bằng các Unit Test; Việc phát triển được hoàn thành khi các Unit Test trả về kết quả đúng (True). • Trong ISTQB (phiên bản 2007), khái niệm Unit Testing được hiểu là Component Testing. Lý do là các công việc trên được thực hiện bởi lập trình viên. Các tài liệu trên phân loại dưới quan điểm của một kiểm thử viên.
- 61. 61 v1.1013109225 ĐẶC ĐIỂM CỦA KIỂM THỬ ĐƠN VỊ (UNIT TEST) • Người tiến hành kiểm thử thông thường là người lập trình mô đun đó hoặc lập trình viên cùng nhóm; • Kiểm thử riêng biệt từng đơn vị phần mềm; • Số lượng nhiều nhưng đơn giản; • Xuyên suốt thời gian lập trình và cả chu kỳ phần mềm; • Kiểm thử Unit là mức thấp nhất trong tiến trình kiểm thử, thường là áp dụng phương pháp kiểm thử hộp trắng; • Thường là được thực hiện bới nhà phát triển trước khi các môđun được tích hợp với các mô đun khác; • Kết quả của kiểm thử Unit thường tìm ra khoảng 20% lỗi trong tất cả cá lỗi của dự án.
- 62. 62 v1.1013109225 PHƯƠNG PHÁP GÌ ĐƯỢC ÁP DỤNG CHO KIỂM THỬ ĐƠN VỊ • Nó kiểm thử các phần sau: Thử nghiệm giao diện; Khám nghiện cấu trúc dữ liệu cục bộ; Thử nghiệm với các điều kiện biên; Các đường độc lập; Các đường xử lý sai. • Kiểm thử đơn vị sử dụng các kỹ thuật: Kiểm thử đường cơ sở; Kiểm thử vòng lặp; Kiểm thử biên.
- 63. 63 v1.1013109225 5.2. KIỂM THỬ TÍCH HỢP • Kiểm thử Tích hợp (Intergration Testing): Là một kỹ thuật có tính hệ thống để xây dựng cấu trúc chương trình ngay khi đang tiến hành kiểm thử để phát hiện sai liên kết với giao diện. • Phải kiểm thử tích hợp vì: Dữ liệu có thể bị mất khi đi qua một giao diện; Một mođun có thehẻ có một hiệu ứng bất lợi vô tình lên các môđun khác; Các chức năng phụ khi kết hợp lại có thể không sinh ra chức năng chính mong muốn; Các điều không chính xác riêng rẽ có thể bị phóng đại đến mức không chấp nhận được; Các cấu trúc dữ liệu toàn cục có thể để lộ ra các vấn đề… • Phương pháp được áp dụng cho kiểm thử tích hợp Phương pháp “big-bang”; Phương pháp trên xuống; Phương pháp dưới lên.
- 64. 64 v1.1013109225 5.3. KIỂM THỬ HỆ THỐNG Kiểm thử hệ thống (System Testing): • Là mức độ kiểm thử toàn bộ các chức năng của hệ thống phần mềm. Bao gồm tất cả các thành phần tương tác với nhau, và hoạt động trong môi trường giống như môi trường thực tế như hệ điều hành, cơ sở dữ liệu, kết nối mạng, khả năng tương thích với các phần mềm khác, … • Kiểm thử hệ thống cũng chú ý đến vấn đề bảo mật, thân thiện, khả năng đáp ứng, tốc độ thực hiện của hệ thống phần mềm.
- 65. 65 v1.1013109225 5.4. KIỂM THỬ CHẤP NHẬN SẢN PHẨM Kiểm thử chấp nhận (Acceptance Testing, User Acceptance Testing): • Mức độ này được thực hiện bởi phía người dùng với một nhóm độc lập với nhóm phát triển. Mục đích của giai đoạn này là kiểm tra, đánh giá phần mềm có đáp ứng được các yêu cầu của người dùng đã đề ra hay không? Có thể triển khai cho công việc thực tế của người dùng hay không; • Việc được người dùng chấp nhận sẽ đánh dấu cho sự kết thúc của giai đoạn phát triển, mở ra giai đoạn triển khai, bảo trì và nâng cấp phần mềm. • Các loại kiểm thử chấp nhận sản phẩm: Kiểm thử Alpha (Alpha Testing): Do người dùng thực hiện; Trong môi trường được quản lý. Kiểm thử Beta (Beta Testing): Do người dùng thực hiện; Trong môi trường thực.
- 66. 66 v1.1013109225 5.5. MỘT SỐ CẤP ĐỘ KIỂM THỬ KHÁC • Kiểm thử hộp xám (Gray-box Testing): Là hình thức “lai” giữa kiểm thử hộp đen và kiểm thử hộp trắng; • Kiểm thử bằng tay (Manual Testing): Là kỹ thuật kiểm thử mà các công đoạn được làm hoàn toàn bằng sức người; • Kiểm thử tự động (Automation Testing): Là kỹ thuật kiểm thử với các công đoạn được tự động hóa bởi máy tính thông qua các “đoạn mã kiểm thử” (Test Script)…
- 67. 67 v1.1013109225 TÓM LƯỢC CUỐI BÀI • Đã trình bày các khái niệm về kiểm thử, vòng đời của kiểm thử và mối tương quan giữa quá trình xấy dựng phần mềm và các giai đoạn kiểm thử phần mềm; • Đã trình bày được các phương pháp kiểm thử và một số ví dụ tương ứng; • Đã trình bày được các kỹ thuật kiểm thử và một số vì dụ tương ứng; • Đã trình bày được các mức độ kiểm thử và một số ví dụ tương ứng