Bài giảng Kiểm thử - Chương 6: Kiểm thử phần mềm

PHẦN 4: KIỂM THỬ

CHƯƠNG 6:

KIỂM THỬ PHẦN MỀM

Mục tiêu

Nội dung

l ỗ i

ì m

ể

h đ

ì n

h ư ơ n

ệ

h i

T h ự c

Nâng cao độ tin cậy của phần mềm

Khám phá các lỗi tiềm ẩn

Mục tiêu

Tạo các kiểm thửvới khả năng cao tìm kiếm ra các lỗi tiềm ẩn

Phần mềm, Mô hình phần mềm, danh sách các yêu cầu

Kết quả tiếp nhận

Phần mềm đã được khẳng định về chất lượng.

Kết quả chuyển giao

NỘI DUNG:

1. Giới thiệu 2. Các kỹ thuật kiểm thử 3. Các chiến lược kiểm thử 4. Gỡ lỗi

t h ử

k i ể m

1 . G i ớ i t h i ệ C á c k ỹ t h u ậ t

2 .

Nội dung

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

4. Gỡlỗi

1. Giới thiệu

1.1 Mở đầu 1.2 Nguyên tắc 1.3 Khái niệm các kiểm thử (test cases)

1.1 Mở đầu

(cid:131)

Lỗi có thể xảy ra trong tất cả các giai đoạn: Xác định, phát triển, khai thác. Ngăn chặn sai sót từ đầu là việc làm đáng quan tâm. (cid:57) Không để lỗi sai lọt vào chương trình (đơn thể, chương trình

con)

(cid:131)

(cid:57) Không để lỗi sai lọt vào hệ thống chương trình. (cid:57) Không để lỗi sai lọt vào giai đoạn khai thác Kiểm thử là quá trình tìm lỗi; là đánh giá cuối cùng về giai đoạn phát triển PM trước khi khai thác. Kiểm thử là một họat động rất khó được chấp nhận, đặc biệt là không phải là thành phần trong nhóm xây dựng phần mềm

1.2 Nguyên tắc:

(cid:131) (cid:131) (cid:131)

(cid:131)

(cid:131) (cid:131)

Kiểm thử nên hướng về yêu cầu khách hàng. Nên lập kế hoạch trước một thời gian dài. Áp dụng nguyên lý Pareto: 80% lỗi có nguyên nhân từ 20% lỗi của các modun nhỏ hơn. Quá trình kiểm thử tiến hành từ các thành phần nhỏ đến các thành phần lớn hơn. Kiểm thử theo kiểu vét cạn là không khả thi. Nên có thành phần thứ 3 độc lập với người dùng và bộ phận phát triển PM

1.3 Khái niệm các kiểm thử (test cases):

Thao tác kiểm thử

(cid:131) Dữ liệu Input. (cid:131) (cid:131) Dữ liệu output của chương trình

(cid:131) Các kiểm thử cho White-Box: Dựa vào cấu trúc

điều khiển của CT.

(cid:131) Các kiểm thử cho Black-Box: Dựa vào yêu cầu

chức năng phần mềm.

2. Các kỹ thuật kiểm thử

2.1 Kiểm thử hộp trắng 2.2 Kiểm thử hộp đen

2.1 Kiểm thử hộp trắng (White -box testing) Mục tiêu:

Sử dụng các cấu trúc điều khiển để tạo ra các kiểm thử với mục tiêu :

(cid:145) Bảo đảm mọi đường thực hiện độc lập trong một modun được

thực hiện ít nhất 1 lần.

(cid:145) Tất cả các điều kiện logic đều được thực hiện. (cid:145) Tất cả vòng lặp đều được thực hiện tại biên. (cid:145) Kiểm tra tất cả cấu trúc dữ liệu nhằm đảm bảo tính hợp lệ.

ả

ơ b g )

g c s ti n

n e

i ệ u

ờ ư ử đ 2 . 1 . 1 K i ể m t h a t h T s i s P ( B t h ử l u ồ n g d ữ l i n g ) 2 . 1 . 2 K i ể m

( D a t a F l o w T e s t

2.1.4 Kiểm thử điều kiện (Condition Testing)

Kiểm thử Hộp trắng 2.1.3 Kiểm thử vòng lặp (Loop Testing)

2.1.1 Kiểm thử đường độc lập cơ bản

Các cách tính khác của độ phức tạp chu trình

a. Đồ thị dòng chảy b. Các đường độc lập cơ bản c. d. Các bước thực hiện để tạo kiểm thử

a. Đồ thị dòng chảy (cid:145) Đồ thị dòng chảy xây dựng từ lưu đồ thuật giải hay mã CT (cid:145) Mỗi nút hình tròn biểu diễn một hay nhiều câu lệnh.

(Mỗi điều kiện là phân nhánh hoặc hợp nhánh phải đưa thành node)

(cid:145) Cạnh có hướng mô tả đường thực hiện.

Rẽ nhánh

Lựa chọn

Tuần tự

while

do ...while

Ví dụ:

2 3

3 4 6

4 6 7 8 5

7 8 5

10 9

Đồ thị dòng chảy Lưu đồ

Ví dụ:

while (x == 0)

{

if (y ==0)

z = 0;

4 3

else

if (k == 0)

6 5

z = 1;

else

x = 1;

}

Đồ thị dòng chảy

(DT1)

Ghi chú: (cid:145) Phải phân rã tất cả các điều kiện phức thành các điều kiện

đơn.

(cid:145) Mỗi node mô tả một điều kiện đơn gọi là node vị ngữ

(Predicate)

Phân tích

if (a)

Lưu đồ

{

0 a

if(b)

1 !(a&&b) ≡ !a || !b 0 x b

else

if (a&&b)

}

else

Sơ đồ dòng chảy

while (a || b)

Phân rã

Sơ đồ dòng chảy

Lưu đồ

b. Các đường độc lập cơ bản

(cid:145)Đường độc lập cơ bản là các đường từ node bắt đầu đến node kết thúc sao cho đường đang xét ít nhất đi qua 1 cạnh chưa được duyệt qua bởi các đường liệt kê trước đó.

(cid:145)Độ phức tạp chu trình được định nghĩa là

tổng số các đường độc lập cơ bản.

(cid:145)Gọi V(G) là độ phức tạp chu trình, V(G) có

thể tính được bằng công thức sau đây:

V(G) = P +1; với P là số node vị ngữ

Ví dụ: xem đồ thị dòng chảy:

Liệt kê: (cid:145) Đường 1: 1->9 (cid:145) Đường 2: 1->2->3->8->1... (cid:145) Đường 3: 1->2->4->5->7->8->1... (cid:145) Đường 4: 1->2->4->6->7->8->1...

4 3

Tổng số đường:

6 5

V(G) = P+1 = 3 + 1 = 4 Các node phân nhánh: 2, 4, 1

c. Các cách tính khác của độ phức tạp chu trình

Node

Cạnh

Vùng

(cid:145) Các cạnh của đồ thị dòng chảy sẽ tạo ra biên của nhiều vùng (Region) của đồ thị.Vùng ở ngoài đồ thị cũng được xem là một vùng.

6 4

7 8 5

(cid:145) Độ phức tạp chu trình còn có thể tính theo các cách khác sau đây: (cid:153) V(G)= E – N + 2; ( trong đó: E số cạnh, N số node ) (cid:153) V(G) = Số vùng trong lưu đồ.

Ví dụ: xem đồ thị dòng chảy:

v 1

Tổng số đường: Cách 1:

6 4

V(G) = P+1 = 3 + 1 = 4 Các node phân nhánh: 6, 3, 1 Cách 2:

εΛ

V(G)= E – N + 2 = 13 – 11+2 = 4

Cách 3:

v 2

7 8 5

V(G) = Số vùng trong lưu đồ

= 4

d. Các bước thực hiện để tạo kiểm thử

(cid:145) Thiết lập một kiểm thử cho mỗi đường độc lập cơ bản. (cid:145) Dựa vào thuật giải để tìm ra một dữ liệu input, sau đó tính dữ liệu output xem có đáp ứng mong đợi của thuật giải

Ví dụ: Xét đồ thị dòng chảy sau

a=c

a=b

7 2

c>0

b=c

1 8

a2 = b2 + c2

10 3 9

Các node phân nhánh: 1, 2, 4, 6, 8, 9.

- Tổng số đường: V(G) = P + 1 = 6 + 1= 7

- Liệt kê các đường độc lập cơ bản: (cid:145) Đường 1: 1->3->12 (cid:145) Đường 2: 1->2->3->12 (cid:145) Đường 3: 1->2->4->5->12 (cid:145) Đường 4: 1->2->4->6->7->12 (cid:145) Đường 5: 1->2->4->6->8->7->12 (cid:145) Đường 6: 1->2->4->6->8->9->10->12 (cid:145) Đường 7: 1->2->4->6->8->9->11->12

Thiết lập các kiểm thử

(cid:145) Kiểm thử cho đường 1: 1->3->12

– Input: a = 4, b = 2, c= 0 – Output: Lỗi

(cid:145) Kiểm thử cho đường 2: 1->2->3->12

– Input: a = 17, b = 5, c= 4 – Output: Lỗi

(cid:145) Kiểm thử cho đường 3: 1->2->4->5->12

– Input: a = 6, b = 6, c= 6

(cid:145) Output: Đều (Tg) (cid:145) . . .

2.1.2 Kiểm thử điều kiện (cid:131) Phương pháp tạo các kiểm thử dựa vào các điều kiện logic của

chương trình.

(cid:131) Một điều kiện đơn giản là một điều kiện Boolean (true/falsse)

hay điều kiện quan hệ (<, >, <=, >=).

(cid:131) Một điều kiện phức tạp bao gồm các điều kiện đơn giản nối

kết bằng các toán tử quan hệ (&&, ||, !,. . .)

Các chiến lược kiểm thử điều kiện bao gồm:

(cid:131) Kiểm nhánh: Phân rã các điều kiện tổng hợp thành các điều kiện đơn giản và thực hiện kiểm thử trên các nhánh đơn giản này ít nhất 1 lần.

(cid:131) Kiểm lĩnh vực: Các kiểm thử dựa vào điều kiện quan hệ

và tóan tử quan hệ.

(cid:131) Kiểm nhánh và quan hệ: Thực hiện trên các điều kiện tổng hợp. Tất cả các tổ hợp có thể có từ các điều kiện đơn giản đều được kiểm thử

2.1.3 Kiểm thử luồng dữ liệu

Phương pháp tạo các kiểm thử dựa vào vị trí khai báo và qua trình sử dụng biến trong chương trình, gọi là chuỗi khai báo sử dụng của biến. Mỗi chuỗi cần được duyệt qua và kiểm thử ít nhất 1 lần. Phương pháp này không đảm bảo mọi nhánh thực hiện chương trình nhưng thích hợp để kiểm tra độ chính xác của dữ liệu khi thực hiện.

2.1.4 Kiểm thử vòng lặp Xét các loại vòng lặp: (cid:131) Đơn giản (cid:131) lồng nhau

a. Vòng lặp đơn giản: với n là số lần lặp tối đa.

(cid:131)

Thực hiện các bước: Bỏ qua không thực hiện Thực hiện vòng lặp 1 lần Thực hiện vòng lặp 2 lần Thực hiện vòng lặp m lần (m < n) Thực hiện vòng lặp tại biên lặp trên, qua n-1, n, n+1 lần thực hiện.

b. Vòng lặp lồng nhau:

(cid:131)

Độ phức tạp của các vòng lặp lông nhau có thể rất lớn, có thể không kiểm thử hiệu quả được. Hướng giải quyết sẽ là: Bắt đầu từ vòng lặp bên trong nhất, tất cả các vòng lặp ngoài đặt biến điều khiển ở mức thấp nhất. Thực hiện kiểm thử vòng lặp đơn giản cho vòng lặp trong nhất này. Thực hiện tiếp tục dần ra ngoài cho đến hết vòng lặp.

2.2 Kiểm thử hộp đen (black- box testing)

Kiểm thử hộp đen tập trung vào các chức năng hệ thống (không quan tâm đến cáu trúc bên trong), tạo ra các kiểm thử với mục tiêu :

(cid:145) Kiểm định độ hợp lý của các chức năng. (cid:145) Phân lớp đầu vào để kiểm thử (cid:145) Phân biên cho dữ liệu được truy xuất để kiểm thử (cid:145) Kiểm định lưu lượng và mật độ dữ liệu hệ thống.

Các lỗi thường được phát hiện: (cid:145) Chức năng sai hay thiếu. (cid:145) Lỗi giao diện (cid:145) Lỗi trong cấu trúc dữ liệuhay truy xuất dữ liệu ngoài (cid:145) Lỗi khởi tạo (cid:145) . . .

t ư ơ n g đ ư ơ n g i o n i n g )

2 . 2 . 1 P h â n c h i a ( E q u i v a l e n c e P a r

. . .

Kiểm thử Hộp đen 2.2.2 Phân tích giá trị biên (Boundary Value Analyis)

2.2.1. Phân chia tương đương (cid:131) Phân các điều kiện đầu vào thành các lớp tương đương. (cid:131) Chỉ cần kiểm thử trên mỗi lớp tương đương

2.2.2. Phân tích giá trị biên (cid:131) Các lỗi xảy ra thường nằm tại các biên của các khoảng dữ liệu

đầu vào.

(cid:131) Dữ liệu đầu vào là khoảng số thì kiểm thử thực hiện tại các giá

trị gần biên dưới, biên trên

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

(cid:145) Mở đầu (cid:145) Kiểm thử đơn vị (cid:145) Kiểm thử tích hợp (cid:145) Kiểm thử chức năng (cid:145) Kiểm thử hệ thống

3.1 Mở đầu (cid:131) Quá trình phát triển PM đi từ trên xuống, trong khi đó chiến

lược kiểm thử PM đi từ dưới lên. Bắt đầu từ các modun tạo mã đến quá trình tích hợp theo thiết kế, xác minh và khẳng định tính hợp lệ của PM với các yêu cầu đặt ra.

(cid:131) Xác minh (Verification) là quá trình khẳng định chương trình

xây dựng đúng theo thiết kế.

(cid:131) Hợp lệ (Validation) là quá trình khẳng định PM xây dựng thỏa

mãn mọi yêu cầu đặt ra.

Phân tích toàn bộ hệ thống

Kiểm thử toàn bộ hệ thống

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

Kiểm thử hợp lệ

Thiết kế phần mềm

Kiểm thử tích hợp

Mã hóa

Kiểm thử đơn vị

Quan hệ giữa các giai đọan phát triển và kiểm thử PM

ố

n x

ừ tr ê

Kiể m th ử đơ n vị

h h ợ p

t í

K i ể m t h ử

Từ dưới lên

Kiể

m thử

hệthống

Các mức kiểm thử Kiểm thử hợp lệ

3.2 Kiểm thử đơn vị: ( Unit testing)

-Giao diện

-cấu trúc dữ liệu địa phương

Điều kiện biên

(cid:131) Tiến hành cho mỗi đơn vị nhỏ nhất của PM, đó là các modun mã nguồn đã được dịch thành công

(cid:131) Thường dùng phương pháp

-Đường thực hiện,

White-Box

-...

(cid:131) Có thể tiến hành cùng lúc

nhiều modun.

(cid:131) Kiểm thử theo trình tự: giao diện, cấu trúc dữ liệu địa phương, điều kiện biên, đường thực hiện, ...

Modun -------------- -------------- -------------- -------------- -------------- --------------

Các kiểm thử

(cid:131) Mỗi modun mã nguồn không phải là chương trình hoàn chỉnh và đôi khi phải gọi các modun chưa được kiểm nghiệm khác. Do đó phải xây dựng các driver hoặc stub. (cid:131) Driver (chương trình điều khiển) là chương trình chính có nhiệm vụ nhận dữ liệu kiểm thử, chuyến dữ liệu đó xuống cho modun để kiểm tra và in ra kết quả kiểm tra tương ứng.

(cid:131) Stub thay thế các modun được gọi là modun đang kiểm

tra

3.3 Kiểm thử tích hợp (Integration testing) (cid:131) Kiểm thử trong quá trình tích hợp là cần thiết vì:

(cid:57) Dữ liệu có thể mất qua giao diện. (cid:57) Modun này có thể làm sai lạc các modun khác (cid:57) . . .

(cid:131) Kiểm thử tích hợp là kỹ thuật thực hiện một cách có hệ thống lắp ghép cấu trúc chương trình, đồng thời thực hiện các kiểm thử phát hiện lỗi giao diện. (cid:131) Có 2 hướng tích hợp chính:

(cid:57) Từ trên xuống (cid:57) Từ dưới lên.

3.3.1 Tích hợp từ trên xuống (Top-Down Integration) (cid:131) Là một cách làm tăng tiến để xây dựng kiến trúc chương trình. (cid:131) Các modun được tích hợp xuống theo cấu trúc điều khiển. (cid:131) Có thể đi theo chiều sâu (defth first) hay chiều rộng (breadth

first).

(cid:131) Đi theo chiều sâu: nhánh

(cid:57) Tại mỗi nhánh, các modun con lần lượt ghép nối, những nhánh chưa được ghép nối hay modun thấp hơn sẽ được thay bằng các modun giả lập. Sau khi thực hiện xong tại 1 nhánh, các modun giả lập dần được thay đổi ở mức thấp và ở các nhánh khác

(cid:131) Đi theo chiều rộng:

(cid:57) Tích hợp theo từng mức. Tất các các modun tại một mức sẽ dần được

tích hợp. Các modun ơ mức thấp thay bằng modun giả lập.

Quá trình tích hợp bao gồm các bước: 1. Modun chính được dùng làm điều khiển kiểm thử, các modun

giả lập nối trực tiếp vào modun này

2. Tùy vào cách tích hợp, từng modun giả lập sẽ được thay bằng

modun thật.

3. Kiểm thử được thực hiện với từng modun thay thế 4. Khi kết thúc một kiểm thử, một modun khác lại được thay thế

bằng modun thật.

5. Kiểm thử lại có thể được thực hiện nhằm bảo đảm quá trình tích hợp modun mới không làm ảnh hưởng kết quả kiểm thử cũ.

Tích hợp từ trên xuống (theo chiều sâu)

M3 M2 M4

M5 M6 M7

M8 M9

3.3.2 Tích hợp từ dưới lên (Bottom-Up Integration)

Bắt đầu từ các modun ở mức thấp nhất, sau đó các modun được tích hợp dần lên. Quá trình tích hợp gồm các bước:

(cid:131) Các modun thấp được tích hợp thành các cụm (cluster) thực

hiện một phần chức năng cụ thể của PM.

(cid:131) Một driver được viết để kết hợp các kiểm thử đầu vào và đầu

(cid:131) Toàn bộ cụm được kiểm tra (cid:131) Các driver bị loại bỏ, các cụm được kết hợp tiếp lên để hình

thành cấu trúc chương trình. Quá trình kiểm thử này dễ dàng thực hiện hơn, nhưng lại tốn nhiều sức để viết các driver

Tích hợp từ dưới lên

Ma Mb

1 r e t s u C

D1 D2 D3

Cluster 2

3.3.3 Kiểm thử lại (Regression Testing) (cid:131) Khi một modun mới được thêm vào, phần mềm sẽ thay đổi.Những luồng dữ liệu mới, những điều khiển mới. . .được thêm vào có thể thay đổi những gì thực hiện trước đó.

(cid:131) Kiểm thử lại là hoạt động nhằm đảm bảo những thay đổi do

trong quá trình tích hợp .

(cid:131) Kiểm thử lại chỉ lấy một phần của bộ kiểm thử trước đó để thực hiện, chẳng hạn một số mẫu chức năng hệ thống, các kiểm thử trên các chức năng có thể bị thay đổi,...

3.3 Kiểm thử hợp lệ (chức năng) (cid:131) Kiểm thử các chức năng phần mềm có phù hợp với các yêu cầu chức năng trong hồ sơ phân tích yêu cầu.

(cid:131) Áp dụng phương pháp Black-Box. (cid:131) Kiểm thử hợp lệ bao gồm:

(cid:57)Xem xét lại cấu hình phần mềm (cid:57)Kiểm thử Alpha (cid:57)Kiểm thử Beta

1. Xem xét cấu hình phần mềm

(cid:145) Nhằm đảm bảo các chức năng phần mềm được phát triển một cách đúng đắn và phù hợp với các đặc tả phân tích, thiết kế phần mềm

Phần mềm tích hợp

Các yêu cầu

Tư liệu người sử dụng

Phần mềm hợp lệ

Kiểm thử hợp lệ

h ợ p

h p

Phát hành Phần mềm

u h ì n

C ấ

Tư liệu người sử dụng

Tư liệu thiết kê

Phê chuẩn quản lý

Các tư liệu kiểm thử

Xét duyệt cấu hình

2. Kiểm thử Alpha

(cid:145) Kiểm thử Alpha được khách hàng tiến hành tại cơ quan của nhà phát triển phần mềm. Phần mềm được khách hàng sử dụng qua sự sắp đặt tự nhiên của nhà phát triển, lỗi phần mềm và các vấn đề sử dụng sẽ được ghi lại.

(cid:145) Kiểm thử Alpha được tiến hành trong một môi trường có

kiểm soát

3. Kiểm thử Beta

(cid:145) Tiến hành ngoài nơi sản xuất phần mềm. Khách hàng sẽ thực hiện tại một hay nhiều cơ quan của khách hàng và nhà phát triển không có mặt.

(cid:145) Do đó, kiểm thử beta là việc thực hiện phần mềm trong

môi trường mà nhà phát triển không kiểm sóat được.

(cid:145) Khách hàng sẽ ghi lại tất cả các lỗi của phần mềm, các vấn đề sử dụng và chuyển lại cho nhà phát triển giải quyết.

3.4 Kiểm thử hệ thống (System testing)

(cid:131) Phần mềm là một yếu tố của một hệ thống dựa trên máy tính, chảng hạn phần cứng, cơ sở dữ liệu, tài liệu, . . .Cuối cùng phần mềm sẽ được tổ hợp với các yếu tố hệ thống khác để tạo hệ thống dựa trên máy tính, nên sẽ phải tiến hành các kiểm thử trên hệ thống.

(cid:131) Ta thường dùng các kiểu kiểm thử hệ thống sau: (cid:57) Kiểm tra tính phục hồi dữ liệu (Recovery Testing). (cid:57) Kiểm tra tính bảo mật (Security Testing). (cid:57) Kiểm tra hiệu suất (Performance Testing).

4. Gỡ lỗi

(cid:145) Gỡ lỗi không phải là kiểm thử, nhưng bao giờ cũng xuất

hiện như là một hệ quả của kiểm thử.

(cid:145) Tiến trình gỡ lỗi bắt đầu với thực hiện một trường hợp kiểm thử, thực hiện các kỹ thuật kiểm thử, các chiên lược kiểm thử, cho ra kết quả kiểm thử.

(cid:145) Tiến trình gỡ lỗi bao giờ cũng có một trong 2 kết quả

logic:

(cid:145) Nguyên nhân tìm ra: Sửa chữa và loại bỏ lỗi. (cid:145) Nguyên nhân không tìm ra: Người thực hiện đặt giả thiết các nguyên nhân, thiết kế trường hợp kiểm thử, tiến hành thực hiện kiểm thử, tiến hành lặp lại các bước gỡ lỗi, . . .

Thực hiện trường hợp kiểm thử Trường hợp kiểm thử

Kiểm thử phụ

Sửa chữa Nguyên nhân hoài nghi

Kết quả

Gỡ lỗi Xác định nguyên nhân