Bài giảng Bài 2: Kiểm thử phần mềm – ThS. Trần Mạnh Thắng

BÀI 2 KIỂM THỬ PHẦN MỀM

Giảng viên: ThS. Trần Mạnh Thắng

1

v1.1013109225

TÌNH HUỐNG DẪN NHẬP

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



2

v1.1013109225

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?

MỤC TIÊU

Trình bày được khái niệm kiểm thử phần mềm;

Trình bày các phương pháp 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 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;

3

v1.1013109225

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

NỘI DUNG

1 Khái niệm kiểm thử phần mềm

2 Các phương pháp kiểm thử

3 Các kỹ thuật thiết kế kiểm thử

4 Các chiến lược kiểm thử

4

v1.1013109225

5 Các cấp độ của việc kiểm thử phần mềm

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

5

v1.1013109225

1.3. Phân loại kiểm thử

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);

6

v1.1013109225

• 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?

1.1. CÁC ĐỊNH NGHĨA (tiếp theo)

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 đó

7

v1.1013109225

để tránh ảnh hưởng lan truyền sóng.

1.2. VÒNG ĐỜI CỦA KIỂM THỬ - TESTING LIFE CYCLE

Đối tượng và phạm vi

Kiểm thử chấp nhận

Kiểm thử hệ thống

Đặc tả chức năng/ Thiết kế lô gíc

Thiết kế Vật lý

Kiểm tích hợp

Kiểm hồi quy

Kiểm đơn vị

Cấu trúc chương trình và đặc tả môđun

Mã hoá môđun chương trình

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 (tiếp theo)

Lỗi

Sửa lỗi

Mô tả yêu cầu

Giải pháp sửa lỗi

Lỗi

Sai sót

Thiết kế

Cô lập lỗi

Lỗi

Sai sót

Lập trình

Phân loại lỗi

Hậu quả

Sai sót

Kiểm nghiệm

9

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;

10

v1.1013109225

 Kiểm thử hộp trắng: Kiểm thử cấu trúc.

1.3.1. MÔ HÌNH CHỮ V

Test chấp nhận

Phân tích yêu cầu

Đặc tả phần mềm

Test hệ thống

Thiết kế kiến trúc

Test tích hợp

Test đơn vị

Thiết kế chi tiết

Lập trình

Rà soát mã

Các mức kiểm thử

11

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;

12

v1.1013109225

 Kiểm thử hệ thống bắt đầu từ ngay trước khi lập trình.

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

13

v1.1013109225

2. CÁC PHƯƠNG PHÁP KIỂM THỬ

2.1. Kiểm thử tĩnh (Static testing)

14

v1.1013109225

2.2. Kiểm thử động (Dynamic testing)

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);

15

v1.1013109225

 Đi xuyên suốt (Walkthrough) hay duyệt.

2.1.1. KIỂM THỬ TĨNH BẰNG PHƯƠNG PHÁP THANH TRA

• 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:

 Sản phẩm phần mềm;  Đặc tả phần mềm;  Kế hoạch thanh tra;

 Điều phối viên;  Thanh tra viên;  Tác giả phần mềm.

• 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;

16

v1.1013109225

 Bám sát.

2.1.2. KIỂM THỬ TĨNH BẰNG PHƯƠNG PHÁP DUYỆT

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

• 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;

17

v1.1013109225

 Kết thúc, đánh giá.

2.2. KIỂM THỬ ĐỘNG – KIỂM THỬ TRÊN MÁY

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

• Đặ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

18

v1.1013109225

đầu ra có như mong muốn hay không.

2.2. KIỂM THỬ ĐỘNG – KIỂM THỬ TRÊN MÁY (tiếp theo)

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;

19

v1.1013109225

9. Lặp lại thao tác từ 5-8.

2.2.1. KIỂM THỬ ĐỘNG BẰNG THỬ NGHIỆM KHUYẾT TẬT

• 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;

20

v1.1013109225

 Thử nghiệm cấu trúc.

2.2.2. KIỂM THỬ ĐỘNG BẰNG THỬ NGHIỆM THỐNG KÊ

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;

21

v1.1013109225

• Phương pháp này có bộ cơ sở dữ liệu thống kê rất lớn.

3. CÁC KỸ THUẬT THIẾT KẾ KIỂM THỬ

3.1. Kiểm thử hộp trắng

22

v1.1013109225

3.2. Kiểm thử hộp đen

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

Input

Results



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);

 

White Box Data Testing Strategy

• Đâ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.

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

23

v1.1013109225

Các luồng điều khiển

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);

24

v1.1013109225

 Ngã rẽ (Branch).

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;

25

v1.1013109225

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

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

26

v1.1013109225

phương pháp này để kiểm tra tính đúng đắn của chương trình.

VÍ DỤ

A>B

False True If (A>B) { S1; S2;

S1;S2; S3;

} else

S3;

S4; S4;

A>B

while(A>B) {

S1; S2;

A>B

} S3;

27

v1.1013109225

A>B

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;

28

v1.1013109225

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.

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 đơ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

29

v1.1013109225

 Vòng lặp không cấu trúc.

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;

Input

Results

Black Box

• Có thể tạo ra một bộ các điều kiện đầu vào để kiểm thử tất cả.

Kiểm thử hộp đen

30

v1.1013109225

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

31

v1.1013109225

Mô hình kiểm thử hộp đen

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;

32

v1.1013109225

 Khởi đầu, kết thúc mỗi quá trình thông suốt.

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;

33

v1.1013109225

• Kiểm thử dựa trên đặc tả – Specification-base Testing.

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;

34

v1.1013109225

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

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);



35

v1.1013109225

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

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;

36

v1.1013109225

 Chọn các giá trị trên và dưới của biên.

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

37

v1.1013109225

hoặc lớn hơn 999.

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;

38

v1.1013109225

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

ĐƯỜ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

39

v1.1013109225

chương trình.

ĐÁ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ừ.

40

v1.1013109225

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.

CÁC ĐƯỜNG CƠ BẢN CỦA ĐỒ THỊ DÒNG

Tuần tự

if

while

until

case

• Đồ 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.

41

v1.1013109225

• Đồ thị dòng dùng để biểu diễn thiết kế thủ tục.

VÍ DỤ 1

s1

1 float foo(int a, int b, int c, int d)

{

c1 float e; 2

if (a==0) 3 s2

return 0; 4

s3 int x = 0; 5

if ((a==b) || ((c==d) && bug(a))) 6

c2 x = 1; 7

e = 1/x; 8 s4

return e; 9 s5

42

v1.1013109225

10 }

VÍ DỤ 2

double average(double value[], double min, double max, int& tcnt, int& vcnt) {

double sum = 0; 1

1

int i = 1;

2 tcnt = vcnt = 0;

2

while (value[i] <> -999 && tcnt <100) {

3

4 6 tcnt++; 5

10

if (min<=value[i] && value[i] <= max)

4

12

11

sum += value[i]; 7

5

vcnt ++;

}

6

8

i++;

11

7

9 }

8

if (vcnt > 0) return sum/vcnt;

9

10 return -999;

43

v1.1013109225

} 12

VÍ DỤ 2 (tiếp theo)

1

2

3

10

4

12

11

5

Đồ 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

6

7

8

9

44

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;

45

v1.1013109225

 Kết quả kỳ vọng: (1) average = -999. (2) tcnt = 0. (3) vcnt = 0;

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ị

46

v1.1013109225

hợp lệ. (2) tcnt = 100. (3) vcnt = 100.

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;

47

v1.1013109225

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

KIỂM THỬ HỘP ĐEN THEO ĐỒ THỊ CAUSE-EFFECT (CAUSE-EFFECT GRAPHING)

a

b

c

a

b

b

c

a

a

b

a

b

a

b

a

b

a

b

48

v1.1013109225

Các ký hiệu trong đồ thị nhân quả

KIỂM THỬ HỘP ĐEN THEO ĐỒ THỊ CAUSE-EFFECT (CAUSE-EFFECT GRAPHING)

STT

Ký hiệu

Ý nghĩa

Giải thích

Tương đương

Nếu đúng thì đúng.

1

2

AND (và)

Nếu đúng và đúng, thì đúng.

3

OR (hoặc)

Nếu đúng hoặc đúng, thì đúng.

4

NOT (phủ định)

Nếu sai, thì đúng.

Nếu đúng, thì

sai, hoặc nếu sai,

5

Loại trừ

thì đúng.

6

Bao hàm

bao hàm

7

Yêu cầu

yêu cầu

49

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

Bảng quan hệ nguyên nhân và kết quả

Nguyên nhân

Kết quả

Người có nhà ở:

Nộp 4% thuế

Tổng thu nhập <= 5.000.000 đồng

Nộp 6% thuế

Tổng thu nhập > 5.000.000 đồng

50

v1.1013109225

VÍ DỤ KIỂM THỬ HỘP ĐEN THEO ĐỒ THỊ CAUSE-EFFECT

Đồ thị nguyên nhân và kết quả

Trường hợp kiểm thử

1

2

3

4

Người có nhà ở

Y

Y

N

--

Có tổng thu nhập <= 5.000.000

N

Y

--

Y

Có tổng thu nhập > 5.000.000

Y

N

--

--

Nguyên nhân và kết quả N g u y ê n n h â n

Nộp thuế 4%

--

X

X

X

K ế t q u ả

Nộp thuế 6%

X

--

--

--

51

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)

52

v1.1013109225

4.5. Kiểm thử kẹp (Sandwich Test)

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

53

v1.1013109225

khiển hệ thống.

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.

Kết hợp theo chiều rộng

Kết hợp theo chiều sâu

Hệ cần kiểm thử

54

Sơ đồ ví dụ kiểm thử từ trên xuống

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 đó;

55

v1.1013109225

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

VÍ DỤ

Vòng 1

Vòng 2

Vòng 3

56

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ể;

57

v1.1013109225

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

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;

58

v1.1013109225

• Tích hợp dưới lên cho các mức phụ thuộc.

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

59

v1.1013109225

5.5. Một số cấp độ kiểm thử khác

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

60

v1.1013109225

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

ĐẶ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

61

v1.1013109225

của dự án.

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;

62

v1.1013109225

 Kiểm thử biên.

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;

63

v1.1013109225

 Phương pháp dưới lên.

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,

64

v1.1013109225

tốc độ thực hiện của hệ thống phần mềm.

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;

65

v1.1013109225

 Trong môi trường thực.

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

66

v1.1013109225

tự động hóa bởi máy tính thông qua các “đoạn mã kiểm thử” (Test Script)…

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;

67

v1.1013109225

• Đã trình bày được các mức độ kiểm thử và một số ví dụ tương ứng