Kiểm thử cặp đôi thông minh

 Kiểm thử cặp đôi thông minh (pairwise testing) là một trường hợp đặc biệt của phương pháp kiểm thử tổ hợp. Trong phương pháp kiểm thử cặp đôi thông minh, ta chỉ yêu cầu mọi cặp giá trị (xi, xj) (1<=i <> j <= n) xuất hiện trong một ca kiểm thử nào đó. Một ca kiểm thử thường có nhiều cặp giá trị với mỗi biến đầu vào. Do đó, kỹ thuật này sẽ giúp ta giảm thiểu đáng kể số lượng ca kiểm thử so với phương pháp kiểm thử tổ hợp.

Xét ví dụ sau. Giả sử ta có hàm y = f(x1, x2, x3) và x1 thuộc {a; b}, x2 thuộc {c; d}, x3 thuộc {e; g}. Đối với phương pháp kiểm thử tổ hợp, số lượng ca kiểm thử cần thiết để phủ được hết các trường hợp là 2^3 = 8.  Tuy nhiên, phương pháp kiểm thử cặp đôi thông minh yêu cầu ít hơn như vậy. Cụ thể, ta có thể chỉ cần 4 ca kiểm thử để phủ được các trường hợp yêu cầu: {(a, c, e); (a, d, g); (b, c, e); (b, d, g)}.

Các nghiên cứu về kiểm thử hướng đến việc sinh tự động các ca kiểm thử theo phương pháp kiểm thử cặp đôi thông minh. Một trong những phương pháp sinh ca kiểm thử tự động là phương pháp IPO [1]. Phương pháp được chia thành hai bước. Sau bước khởi tạo tập các ca kiểm thử để mỗi ca kiểm thử chứa một cặp hai giá trị cho hai tham số đầu tiên. Bước đầu tiên là mở rộng các ca kiểm thử theo chiều ngang – Horizontal Grow. Tại bước này, với mỗi tham số đầu vào còn thiếu, các ca kiểm thử được thêm các giá trị tương ứng. Bước thứ hai là mở rộng theo chiều dọc – Vertical Grow. Nhiệm vụ của bước này là tạo ra các ca kiểm thử khác cho những giá trị chưa được xuất hiện. Như vậy, mỗi tham số từ sau hai tham số đầu tiên, chiến lược áp dụng mở rộng theo chiều ngang và chiều dọc để sinh được các ca kiểm thử cần tìm.

Phương pháp kiểm thử cặp đôi thông minh để so sánh về khả năng phủ các trường hợp so với phương pháp tổ hợp thì không thể bằng. Tuy nhiên, triết lý ở đây là ta hy vọng với việc mỗi cặp biến đầu vào đều được kiểm thử ít nhất là một lần, ta có thể tìm được lỗi của chương trình. Phương pháp này đánh đổi việc bao phủ toàn bộ các trường hợp với chi phí để tiến hành việc kiểm thử.

Phương pháp kiểm thử cặp đôi thông minh có thể được ứng dụng ở nhiều trường hợp ngoài việc kiểm thử đơn vị. Ta có thể kết hợp các điều kiện kiểm thử tích hợp, kiểm thử hệ thống, kiểm thử chấp nhận. Ta cũng có thể kết hợp các yếu tố khác nhau của môi trường kiểm thử với nhau để giảm thiểu số lượng môi trường kiểm thử cần phải thiết lập và công sức cần thiết để kiểm thử phần mềm.

 

[1] Kuo-Chung Tai and Yu Lei (2002). “A test generation strategy for pairwise testing”. In: IEEE transactions on software Engineering 28.1, pp. 109–111

Kiểm thử bằng bảng quyết định

Giới thiệu

Có bao giờ bạn tự hỏi đâu là phương pháp kiểm thử chức năng hiệu quả nhất không? Có phải là phương pháp kiểm thử giá trị biên hay kiểm thử phân lớp tương đương? Câu trả lời là phương pháp kiểm thử bằng bảng quyết định [1]. Lý do của việc này là trong hai phương pháp kiểm thử giá trị biên và kiểm thử phân lớp tương đương, các giá trị của tham số đầu vào của hàm là không liên quan đến nhau. Việc này rất khó xảy ra trong thực tế. Phương pháp kiểm thử bằng bảng quyết định là phương pháp giúp kiểm thử viên có thể mô tả được điều kiện xảy ra, hành vi tương ứng của hàm trong những trường hợp đó. Việc này có thể giúp ta mô tả sự liên quan đến nhau của những tham số đầu vào của hàm.

Cấu trúc của bảng quyết định

Một bảng quyết định bao gồm bốn thành phần như sau:

+ Các biểu thức điều kiện C1, C2, C3, v.v.

+ Giá trị của các điều kiện này: T, F, - (không xác định).

+ Hành vi tương ứng của hàm: A1, A2, A3, v.v.

+ Giá trị của hành vi: x: có xảy ra, rỗng: không xảy ra.

Hình sau đây nêu ví dụ về một bảng quyết định với bốn đầu vào được mô tả phía trên.

		Quy tắc
		1	2	3	4	5	6
Điều kiện	C1	T	T	T	T	F	F
	C2	T	T	F	F	F	F
	C3	T	F	T	F	T	F
Hành vi	A1	x		x	x
	A2		x			x
	A3	x					x

 Xét về bản chất, thứ tự của các điều kiện C1, C2, C3, các hành động A1, A2, A3, và các quy tắc 1, 2, v.v. là không quan trọng. Ta có thể thay đổi để phù hợp ngữ cảnh của mình. Tuy nhiên, do mỗi giá trị điều kiện có thể là T, F, hoặc -, ta có thể tăng các cột để phủ hết tổ hợp của các giá trị này.

Thực tế áp dụng

Trong thực tế, để áp dụng phương pháp kiểm thử bằng bảng quyết định, ta cần nắm được quy tắc và bản chất của nó là điều kiện ràng buộc giữa các đầu vào và hành vi tương ứng của hàm hay của phần mềm. Từ đó, ta thấy rằng, phương pháp này có thể được áp dụng không chỉ với hàm mà còn có thể được áp dụng cho việc kiểm thử giao diện với nhiều đầu vào là các điều khiển người dùng. Ngoài ra, ta có thể áp dụng nó cho việc kiểm thử những hành vi của hệ thống phần mềm nói chung với một tập những tham số, sự kiện, thao tác của người dùng hoặc của các hệ thống khác.

Ví dụ

Xét hàm kiểm tra một tam giác có phải tam giác cân hay không

void IsoscelesTriangle(int a, int b, int c) {     if( a<b+c && b<a+c && c<a+b ){         if(a==b || a==c || b==c)             cout<<"Tam giac can";                else             cout<<"Tam giac khong can";         }     else         cout<<"Khong phai mot tam giac"; }

  

		Quy tắc
		1	2	3	4
Điều kiện	a<b+c && b<a+c && c<a+b	T	T	F	F
	a==b || a==c || b==c	T	F	T	F
Hành vi	Tam giac can	x
	Tam giac khong can		x
	Khong phai mot tam giac			x	x

 

Tài liệu tham khảo

[1] Phạm Ngọc Hùng, Trương Anh Hoàng, Đặng Văn Hưng, Giáo trình kiểm thử phần mềm, NXB ĐHQG HN, 2014

Kiểm thử lớp tương đương

 Kiểm thử lớp tương đương còn được biết đến với tên gọi kiểm thử phân vùng tương đương. Ý tưởng chính của phương pháp này là phân chia miền giá trị đầu vào của mỗi tham số của hàm thành những lớp giá trị mà mỗi giá trị trong đó có tác động tương đương nhau đến hàm cần  kiểm thử. Với cách làm như vậy, ta hy vọng rằng những giá trị của biến đầu vào trong một lớp tương đương có thể gây ra những lỗi giống nhau đối với hàm. Do đó, thay vì cần kiểm thử nhiều giá trị cho mỗi vùng tương đương, ta chỉ cần kiểm thử hàm với một giá trị trong vùng đó thôi.

Vấn đề của ta bây giờ là làm sao tìm được các lớp tương đương của tham số đầu vào để có thể sinh được những ca kiểm thử tương ứng. Có hai phương pháp để làm việc này:

• Ta có thể dựa vào việc phân tích mã nguồn, hoặc
• Dựa vào yêu cầu đầu vào của hàm.

Xét ví dụ sau về hàm kiểm tra một năm có phải là năm nhuận hay không:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

int leapYear(int year) { if (year % 4 == 0) { if (year % 100 == 0) { if (year % 400 == 0) return 1; else return 0; } else return 1; } else return 0; }

 Trong ví dụ trên, nếu dựa trên việc phân tích mã nguồn, ta thấy rằng, tham số đầu vào có thể chia làm các lớp sau của giá trị tham số [year]:

+ Lớp chia hết cho 4 nhưng không chia hết cho 100: kết quả của hàm là năm nhuận

+ Lớp chia hết cho 4 và chia hết cho 100, nhưng không chia hết cho 400: kết quả của hàm là năm KHÔNG nhuận

+ Lớp chia hết cho 4 và chia hết cho 100 và chia hết cho 400: kết quả của hàm là năm nhuận

+ Lớp không chia hết cho 4: kết quả của hàm là năm KHÔNG nhuận

Nếu dựa vào yêu cầu đầu vào của hàm, ta cần dựa vào thực tế khi nào một năm được gọi là năm nhuận. Trong tình huống này, ta cũng có những lớp tương đương tương tự như đã phân tích từ mã nguồn ở trên.

Phân loại kiểm thử lớp tương đương

Xét một hàm có hai đầu vào là A và B, trong đó A có các lớp tương đương A1 và A2, B có các lớp tương đương B1, B2, và B3. Giả sử các giá trị a1 và a2 tương ứng thuộc A1 và A2. Các giá trị b1, b2, và b3 tương ứng thuộc B1, B2, và B3. Ta có một số phân loại kiểm thử lớp tương đương sau:

• Kiểm thử lớp tương đương yếu

Trong kiểm thử lớp tương đương yếu, ta chỉ yêu cầu giá trị mỗi miền tương đương của các tham số đầu vào xuất hiện trong một ca kiểm thử nào đó là đủ. Trong ví dụ trên, ta chỉ cần 3 ca kiểm thử là đã có thể thỏa mãn yêu cầu này. Ba ca kiểm thử này là: (a1, b1), (a2, b2), (a1, b3). Ta cũng có thể sử dụng ba ca kiểm thử sau để thỏa mãn yêu cầu này: (a1, b1), (a2, b2), (a2, b3).

• Kiểm thử lớp tương đương mạnh

Trong kiểm thử lớp tương đương mạnh, ta cần tổ hợp các giá trị của những lớp tương đương của các biến đầu vào để có thể đáp ứng được yêu cầu của loại kiểm thử này. Trong ví dụ trên, ta cần tổng số 2x3 = 6 ca kiểm thử để thỏa mãn yêu cầu kiểm thử lớp tương đương mạnh. Sáu ca kiểm thử này như sau: (a1, b1), (a1, b2), (a1, b3), (a2, b1), (a2, b2), (a2,  b3).

• Kiểm thử lớp tương đương đơn giản

Trong kiểm thử lớp tương đương đơn giản, ta chỉ chia miền giá trị của tham số đầu vào của hàm thành hai lớp tương đương là lớp giá trị hợp lệ và lớp giá trị không hợp lệ. Trong ví dụ với hàm [leapYear] đã đề cập ở trên, miền giá trị hợp lệ là những năm lớn hơn 0 (year > 0). Trong khi đó, miền giá trị không hợp lệ là những năm nhỏ hơn hoặc bằng 0 (year <= 0). Sau khi có lớp tương đương cho mỗi tham số đầu vào, ta có thể áp dụng các phương pháp kiểm thử lớp tương đương mạnh và yếu đã trình bày ở trên.

Lý do để ta có phân loại kiểm thử lớp tương đương đơn giản này là đa phần yêu cầu đầu vào của phần mềm không chỉ rõ miền giá trị hợp lệ của các tham số đầu vào. Chỉ khi bắt tay vào kiểm thử hoặc lập trình, ta mới có thể phát hiện những trường hợp cụ thể mà chương trình cần xử lý. Nguyên nhân thứ hai là ta cần có những xử lý kiểu hợp lệ để thông báo tới người dùng. Từ đó, chương trình cần có những xử lý để có sự tương tác tốt với người dùng và tránh các lỗi có thể xảy ra. 

Chú ý:

Trong thực tế, việc kiểm thử lớp tương đương không chỉ được áp dụng cho việc kiểm thử với các giá trị tham số đầu vào của hàm. Việc này còn được áp dụng với việc kiểm thử cho các giá trị đầu ra của hàm.

(https://www.facebook.com/thayvietkiemthu/posts/119310270701200)

Kiểm thử giá trị biên

Kiểm thử giá trị biên là một phương pháp kiểm thử hộp đen dựa vào đặc tả của hàm. Phương pháp này xuất phát từ một thực tế rằng lỗi của phần mềm thường xảy ra vào biên của miền xác định của các biến đầu vào của hàm. Điều này là do các lập trình viên thường quên hoặc nhầm lẫn trong các dấu <, >, với <=, và >= khi viết các điều kiện.

Để việc trình bày phương pháp trở nên đơn giản và dễ hiểu, tôi trình bày thông qua một ví dụ sau.

Xét một hàm trong C# như sau:

public void DoSomething(int x, int y);

Trong đó, từ nghiệp vụ của hệ thống, ta có được thông tin giá trị của x, y như sau: 1<x<7 và 5<y<13.

•  Kiểm thử giá trị biên thông thường

Với phương pháp kiểm thử biên thông thường, ta chỉ cần xét năm giá trị với mỗi biến đầu vào bao gồm: min, min+, norm, max-, max. Trong ví dụ này, với x, ta cần xét 1, 2, norm = (7+1)/2 = 4, 6, 7. Với y, ta cần xét 5, 6, norm = (13+5)/2 = 9, 12, 13.

Khi đã xác định được những giá trị của mỗi biến đầu vào, việc kết hợp chúng lại với nhau cũng cần làm sao cho hiệu quả. Ở đây, ta kết hợp mỗi giá trị của x với norm của y và ngược lại. Sau khi loại bỏ ca kiểm thử trùng nhau, ta chỉ còn 9 ca kiểm thử sau: (4,5), (4,6), (4,9), (4,12), (4,13), (1,9), (2,9), (6,9), (7,9).

 

• Kiểm thử giá trị biên mạnh

Trong nhiều trường hợp, ta có thể sử dụng phương pháp kiểm thử giá trị biên mạnh. Trong phương pháp này, ta thêm vào giá trị min- và max+ cho mỗi miền giá trị của biến đầu vào. Như vậy, với mỗi biến đầu vào, ta có 7 giá trị: min-, min, min+, norm, max-, max, max+. Trong ví dụ ta đang xét, tổ hợp lại ta có thêm 4 ca kiểm thử sau: (0,9), (8,9), (4, 4), (4, 14). Tổng số, ta có 13 ca kiểm thử.

 

• Kiểm thử giá trị biên tổ hợp

Trong phương pháp này, thay vì ta kết hợp giá trị norm của biến đầu vào này với các giá trị của biến đầu vào khác, ta tính tổ hợp của chúng với nhau. Phương pháp này tạo ra những ca kiểm thử có khả năng tìm lỗi tốt hơn. Tuy nhiên, chúng tạo ra số lượng lớn ca kiểm thử. Số lượng ca kiểm thử được tạo ra cho một hàm có n tham số lên tới 7^n ca.

 

• Kiểm thử giá trị biên đặc biệt

Trong một số tình huống, việc hiểu rõ nghiệp vụ của hệ thống rất hữu ích để tạo ra những ca kiểm thử có khả năng bắt lỗi cao. Ví dụ điển hình cho tình huống này là việc kiểm thử các giá trị ngày 29 tháng 2 cho những năm nhuận và không nhuận. Ta có thể kiểm tra cả các giá trị ngày 28 và 30 tháng 2 cho cả năm nhuận và năm không nhuận.

 

• Kiểm thử giá trị biên từ mã nguồn

Mặc dù kiểm thử giá trị biên xuất phát từ yêu cầu của phần mềm, nếu ta không có yêu cầu của phần mềm mà chỉ có mã nguồn của nó, vậy ta có thể áp dụng chiến lược kiểm thử giá trị biên không? Tôi xin dành phần thảo luận lại cho độc giả với tình huống ví dụ và một vài câu hỏi mở phía sau. Giả sử hàm kiểm tra một tam giác hợp lệ với độ dài các cạnh a, b, c đều nằm trong khoảng từ 1 đến 10 (1 <= a, b, c <= 10).

int isTriangle(int a, int b, int c)

{

            if((a < b+c) && (b < a+c) && (c< a+b))

{

                        return 1;

            }

            else return 0;

}

Câu hỏi 1: Liệu trong tình huống này, ta có bao nhiêu ca kiểm thử biên?

Câu hỏi 2: Ta có nên cân nhắc tính biên (b+c) đối với a, (a+c) đối với b, và (a+b) đối với c?

(https://www.facebook.com/thayvietkiemthu/posts/117051350927092)

Sự cần thiết nâng cao kiến thức kiểm thử

Tất cả mọi nghề nghiệp đều cần có sự đầu tư nâng cao kiến thức. Theo tôi, sự nâng cao kiến thức có thể được thực hiện từ nhiều khía cạnh: từ kiến thức ta được trang bị trong trường học và ý thức học hỏi trong nghề nghiệp của bản thân ta đến việc đầu tư nâng cao kiến thức và kỹ năng nghề nghiệp trong quá trình đi làm. Trong suốt thời gian hơn 12 năm làm vị trí quản lý dự án, tôi đã tham gia phỏng vấn rất nhiều ứng viên vào các vị trí kiểm thử của đội tôi phụ trách. Có một điều ngạc nhiên là ngoại trừ những ứng viên có chứng chỉ ISTQB (International software testing qualification board – một loại chứng chỉ kiểm thử chuyên nghiệp cho phần mềm) hoặc đã từng đọc, học qua những kiến thức kiểm thử trong đó, có rất nhiều ứng viên không hiểu hoặc không biết một số kỹ thuật kiểm thử rất cơ bản như kiểm thử giá trị biên, kiểm thử phân vùng tương đương, kiểm thử theo bảng quyết định, hay kỹ thuật cao cấp hơn là kỹ thuật phân cặp thông minh (pairwise testing). Những ứng viên này bao gồm cả những em đã được đào tạo bài bản chương trình đại học về công nghệ thông tin (CNTT) hoặc có qua những khóa học kiểm thử viên (tester) ở những trung tâm chuyên nghiệp. Thậm chí, những ứng viên đã có vài năm kinh nghiệm kiểm thử trong những công ty chuyên về phần mềm.

Theo quan sát của tôi, có nhiều lý do cho vấn đề này.

• Thứ nhất, về phía chương trình học: không phải chương trình đào tạo CNTT nào cũng có môn học về kiểm thử phần mềm và cũng không phải ngành đào tạo nào trong CNTT cũng có môn học này. Tôi nghĩ rằng, ít nhất thì những chương trình đào tạo chuyên về phần mềm nên có môn học này để trang bị cho các em những kỹ năng, kiến thức, và hiểu biết nhất định về công việc kiểm thử phần mềm.
• Thứ hai, về bản thân các ứng viên: các em vẫn còn khá thụ động trong việc tiếp thu kiến thức hoặc không được các thầy cô truyền đạt những kinh nghiệm hay kiến thức cần thiết về nghề nghiệp trong tương lai. Việc này thể hiện ở chỗ ngay cả những em đã học qua các chương trình đào tạo kiểm thử viên (tester) chuyên nghiệp, các em vẫn không nắm được những phương pháp kiểm thử kể trên. Ta cần nói thật với nhau rằng, khi các em đã xác định theo đuổi một định hướng nghề nghiệp, ta cần phải ăn với nó, ngủ với nó, và sống với nó. Khi đó, không có lý do gì để ta không nghe nói, không biết về những phương pháp kiểm thử này trong thời đại thông tin tràn ngập không gian mạng như ngày nay. Người ta có một câu nói rất hay rằng, “kiến thức ở trên mây, ta chỉ cần mười đầu ngón tay để lấy xuống”.
• Thứ ba, về ý thức nâng cao kỹ năng trong quá trình đi làm. Khi chúng ta đã được nhận vào làm về kiểm thử trong một đội nhóm, đó mới chỉ là khởi đầu của mọi chuyện. Có nhiều bạn trong đội của tôi, đã kiểm thử những sản phẩm của nhóm vài năm mà bạn vẫn không thành thạo việc thiết lập cấu hình cần thiết cho sản phẩm. Có nhiều ứng viên tôi phỏng vấn, bạn đã có vài năm làm kiểm thử nhưng vẫn không biết hay nghe nói đến những phương pháp kiểm thử tôi đã đề cập. Vậy đây là ý thức nâng cao năng lực bản thân. Trong thời đại ngày nay, chúng ta không tiến nghĩa là chúng ta đang lùi. Không có lý do gì bạn yêu cầu công ty tăng lương khi kiến thức và công việc bạn làm năm nay không khác gì với năm ngoái, tại thời điểm bạn vào công ty.

Trong ngành CNTT ở các nước phát triển, những chuyên gia cao cấp là những người đảm bảo chất lượng phần mềm. Họ nghiên cứu những phương pháp để có thể góp phần nâng cao và đảm bảo chất lượng phần mềm. Đảm bảo ở đây là muốn nói đến sự chính xác ở mức hình thức những thuộc tính nhất định trong thiết kế hoặc cài đặt của  phần mềm. Ở nước ta, do sự hạn chế của trình độ nguồn nhân lực, hạn chế của môi trường phát triển, các kiến thức và kỹ năng kiểm thử vẫn chỉ được phát triển ở một mức độ nhất định, chưa thể chuyên sâu. Sự phát triển của lĩnh vực kiểm thử của ta nói chung và của mỗi người nói riêng rất cần có ý thức nâng cao kiến thức trong công việc của mỗi chúng ta. Ta cần nâng cao kiến thức và kỹ năng cho những bạn trẻ, những người làm kiểm thử chuyên nghiệp từ việc đào tạo kiểm thử và ý thức về chất lượng phần mềm thông qua các chương trình đào tạo. Việc này cũng có thể được thực hiện thông qua sự chủ động tìm kiếm và tiếp thu kiến thức về kiểm thử của mỗi kiểm thử viên. Cuối cùng, mỗi kiểm thử viên có thể đạt được những kiến thức này thông qua việc tự nâng cao năng lực và ý thức về công việc của mình.

Bài này đã phân tích một số khía cạnh về sự cần thiết nâng cao kiến thức kiểm thử để mỗi chúng ta có thể ngày càng tiến bộ trong nghề của mình. Trong những bài sau, tôi sẽ giới thiệu một số phương pháp và kiến thức từ cơ bản đến nâng cao về kiểm thử. Mục đích của việc này là cung cấp kiến thức cho những ai quan tâm, đang tìm kiếm, và thiếu nguồn tài liệu chính thống về kiểm thử. Việc này hướng đến nâng tầm vị trí các công việc của ta có thể làm được trong chuỗi giá trị của ngành công nghiệp phần mềm.

(https://www.facebook.com/thayvietkiemthu/posts/114959587802935)

Một số độ phủ phổ biến trong kiểm thử phần mềm

Kiểm thử phần mềm là một trong hai phương pháp đảm bảo chất lượng phổ biến cho phần mềm: phương pháp kiểm chứng phần mềm và kiểm thử phần mềm. Bên trong kiểm thử phần mềm, ta có nhiều cách tiếp cận để kiểm thử phần mềm như kiểm thử hộp đen, kiểm thử hộp trắng và kiểm thử hộp xám. Trong khi kiểm thử hộp đen tập trung vào phân tích yêu cầu của phần mềm để sinh được các ca kiểm thử, kiểm thử hộp trắng dựa vào mã nguồn của đơn vị được kiểm thử để sinh dữ liệu kiểm thử cho đơn vị đó. Trong khi đó, kiểm thử hộp xám là sự kết hợp của hai loại kiểm thử hộp đen và hộp trắng. Từ bản chất của hai loại hình kiểm thử hộp đen và hộp trắng như vậy, kiểm thử hộp đen được sử dụng để tìm lỗi của phần mềm so với yêu cầu của nó. Trong khi đó, tuy kiểm thử hộp trắng được sử dụng để tìm lỗi của phần mềm, ta tập trung vào việc phân tích mã nguồn, sinh các ca kiểm thử nhằm phủ được mã nguồn theo các tiêu chuẩn phủ khác nhau. Với việc cố gắng  phủ được các loại độ phủ khác nhau, ta tin rằng những dữ liệu kiểm thử của ta sẽ kiểm thử được toàn bộ các trường hợp được cài đặt trong mã nguồn. Từ đó, ta hy vọng là tìm được lỗi của phần mềm tiềm ẩn trong các cài đặt của nó. 

Bài này giới thiệu một số loại độ phủ phổ biến được sử dụng trong kiểm thử hộp trắng và theo luồng điều khiển (control flow graph – CFG) trong lĩnh vực kiểm thử phần mềm. Mỗi loại độ phủ được định nghĩa dựa trên các thành phần khác nhau của đồ thị như câu lệnh, các nhánh thực hiện chương trình, các điều kiện quyết định nhánh, các điều kiện con, hoặc sự kết hợp của chúng, v.v.  Mục tiêu của các phương pháp sinh dữ liệu kiểm thử là sinh tập dữ liệu kiểm thử sao cho đạt được mức độ phủ tối đa trong khi số lượng ca kiểm thử cần thiết là tối thiểu. Sau đây là một số loại độ đo phổ biến thường được sử dụng [LeeCopeland2004]:

Độ phủ cấp 1 (C1) (độ phủ câu lệnh): Mỗi câu lệnh của hàm được thực hiện tối thiểu một lần sau khi chạy các ca kiểm thử. Ví dụ, với hàm getAverage sau đây, ta chỉ cần 1 ca kiểm thử (arr[0] = 5, n = 1) để phủ được toàn bộ câu lệnh của nó. Người ta nói rằng, việc không kiểm thử chương trình để đạt được độ phủ 100% các câu lệnh là một việc làm không chuyên nghiệp, thiếu trách nhiệm trong nghề nghiệp của ta.

float getAverage(int arr[], int n) {     float avg = 0;     int temp = 0;       if (n > 0)     {         for (int i = 0; i < n; i++)         {             temp += arr[i];         }         avg = temp / n;     }     return avg; }

 

Độ phủ cấp 2 (C2) (Độ phủ nhánh): Độ phủ này còn được biết đến với tên độ phủ quyết định (decision coverage). Cả hai nhánh đúng và sai ở các đỉnh điều kiện trong đồ thị luồng điều khiển của đơn vị cần kiểm thử được thực hiện ít nhất một lần. Ví dụ, với hàm getAverage ở trên, ta cần hai ca kiểm thử sau để phủ được hết các nhánh của hàm: (arr = null, n = 0), (arr[0] = 5, n = 1).

Độ phủ cấp 3 (C3) (Độ phủ điều kiện con, Modified condition/decision coverage - MC/DC): Với những hàm có chứa câu điều kiện phức tạp với nhiều điều kiện con, việc đảm bảo toàn bộ các điều kiện con được kiểm tra là một tiêu chí quan trọng. Việc này để đảm bảo các điều kiện được viết trong hàm là có chủ đích và kiểm soát được. Ví dụ, với điều kiện (a == 2) && (b > 3), ta nói rằng điều kiện này có hai điều kiện con là (a == 2) và (b > 3). Như ta đã biết, mỗi điều kiện con sẽ có hai nhánh đúng và sai. Như vậy, với điều kiện này, ta có bốn nhánh. Để phủ được theo độ phủ cấp 3, ta cần bốn ca kiểm thử sau: (a = 2, b = 4), (a = 3, b = 4), (a = 2, b = 3), (a = 3, b = 3).

Đôi khi, ta cũng có xét một độ phủ với mức độ yêu cầu thấp hơn là độ phủ điều kiện (condition coverage) (mỗi điều kiện được tính toán ít nhất một lần). Ví dụ, với điều kiện (a == 2) && (b > 3), ta chỉ cần hai ca kiểm thử để đạt độ phủ này (a = 2, b = 4) (ca kiểm thử này b > 3 không được tính toán), và (a = 3, b = 4) (vì a = 3 nên b > 3 được tính toán).

Độ phủ cấp 4 (C4) (Độ phủ đa điều kiện): Trong trường hợp này, ta cần dựa vào hiểu biết của ta với bản thân ngôn ngữ lập trình và trình biên dịch để đảm bảo rằng toàn bộ điều kiện con của lệnh điều kiện được tính toán và các ca kiểm thử được sinh ra phải phủ được cả hai nhánh TRUE và FALSE của toàn bộ các lệnh điều kiện con. Ở một mức độ nào đó, độ phủ này giống với độ  phủ C3 được trình bày ở trên. Khi đạt được độ phủ này, ta chắc chắn đã đạt được độ phủ C3.

Độ phủ cấp 5 (C5) (Độ phủ vòng lặp): Trong trường hợp hàm cần kiểm thử có chứa lệnh vòng lặp mà vòng lặp này làm cho số lượng đường thi hành của hàm trở nên vô hạn. Ta có thể giảm số lượng ca kiểm thử này về một số trường hợp sau.

Trường hợp 1: vòng lặp không được thực hiện lần nào.

Trường hợp 2: vòng lặp được thực hiện một lần.

Trường hợp 3: vòng lặp được thực hiện n lần với n là một số nhỏ đại diện cho một giá trị lặp thường gặp.

Trường hợp 4: thực thi vòng lặp một số m lần với m là số lớn nhất có thể. Thêm vào đó, ta có thể thử với số lần lặp là m – 1 và m + 1 để có thể kiểm tra được nhiều trường hợp thực thi hơn.

Độ phủ cấp 6 (C6) (Độ phủ đường thi hành): Với những hàm không chứa vòng lặp, thường thì số lượng đường thi hành không quá lớn. Vì vậy, ta có thể sinh các ca kiểm thử để có thể phủ được toàn bộ đường thi hành tương ứng của hàm. Với các hàm có chứa vòng lặp, số lượng đường thi hành có thể rất lớn phụ thuộc vào vòng lặp của hàm. Vì vậy, ta có thể áp dụng độ phủ C5 đã được trình bày ở trên để sinh ca kiểm thử.

 

[LeeCopeland2004] Copeland Lee, A practitioner’s guide to software test design, Artech House, Inc., Norwood, MA, USA, 2003

(https://www.facebook.com/thayvietkiemthu/posts/112786171353610)