Tìm hiểu các kỹ thuật kiểm thử phần mềm

Kiểm thử phần mềm là quá trình chạy thử một ứng dụng để phát hiện lồi và xem nó có thỏa mãn các yêu cầu đã đặt ra trong quá trình phát triển phầnmềm, những người phát triển phần mềm và c

Nguyền Ngọc Hải - 1 - 4/10/2013

TRƯỜNG ĐẠI HỌC HÙNG VƯƠNG

KHOA TOÁN - CÔNG NGHỆ

ĐÈ TÀI TÌM HIỂU CÁC KỸ THUẬT KIẺM THỦ PHẦN MÈM

Giáo viên hướng dẫn:

Lương Mạnh Bá Sinh Viên Thực Hiện:

1 Nguyễn Ngọc Hải (Trưởng Nhóm)

2. Nguyễn Xuân Chiến

Phú Thợ 2011

Mục lục

Phần I: Giới Thiệu về Kiếm Thử Phần Mầm 3

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

1.2 Mục tiêu của kiếm thử 4

1.3 Những khó khăn của kiếm thử 4

1.4 Các phuxmg pháp kiểm thủ’ 4

1.5 Các kỹ thuật thiết kế trường họp kiểm thử 4

1.6 Phưong pháp thử các mô đun 4

PHÀN II GIỚI THIỆU CHI TIÉT VÈ KIỂM THỬ 5

2.1 Nguyên tắc CO’ bản kiểm thử phần mềm 5

2.2 Các phưong pháp kiếm thủ’ 5

2.3 Các kỹ thuật thiết kế trưòng họp kiểm thử 7

2.3.1 Kiêm thủ’ hộp đen - Black box testing 7

*Phân Đoạn Tương Đương 7

*Phân tích giá trị biên - Boundary Value Analysis 9

* Kỹ Thuật Cause-Effect Graphing 10

* Đoán lỗi 15

2.3.2

Kiểm thử hộp trắng - White box testing

15 * Kiểm thử đường diễn tiến của chuơng trình 16 *Kiểm Định cấu Trúc Điều Kiền

16 * Độ phức tạp lặp (Cyclomatic Complexity) 21 2.3.3 Kiểm thử hộp xám - Gray box testing 22 2.4

Phương pháp thử các mô đun

22 2.4.1 Kiểm thử mô đun 22

2.4.2 Kiểm thủ’ tích hợp - Intergration Test 22 * Kiêm tra top-down 23

* Kiêm tra hottom-up 24

* Kiểm thử hệ thống - System Test 25

phát triển phần mềm đế đảm bảo rằng phần mềm thoả mãn các yêu cầu thiết

kế và các yêu cầu đó đáp ứng các nhu cầu của người dùng Các kỹ thuật kiếmthử phần mềm đã, đang được nghiên cứu, và việc kiếm thử phần mềm đã trởthành qui trình bắt buộc trong các dự án phát triến phần mềm trên thế giới.Kiểm thử phần mềm là khâu mấu chốt đế đảm bảo chất lượng phần mềm,

là đánh giá cuối cùng về đặc tả thiết kế và mã hóa

Kiểm thử phần mềm là quá trình chạy thử một ứng dụng để phát hiện lồi

và xem nó có thỏa mãn các yêu cầu đã đặt ra trong quá trình phát triển phầnmềm, những người phát triển phần mềm và các kỹ sư kiểm thử cùng làm việc đếphát hiện lỗi và đảm bảo chất lượng sản phẩm Một sản phẩm phần mềm đượcphân phổi phải có đầy đủ các chức năng yêu cầu và tương thích với phần cứngcủa khách hàng

• Chi phí của kiếm thử chiếm

• 40% tổng công sức phát triển

• >=30% tổng thời gian phát triển

Sơ đô kiêm thử

Nguyền Ngọc Hải -4- 4/10/2013

1.2 Mục tiêu của kiếm thử

Các nguyên tắc được xem như mục tiêu kiếm thử là:

• Kiếm thử là một quá trình thực thi chương trình với mục đích tìm lỗi

• Một trường hợp kiểm thử tốt là trường hợp kiểm thử mà có khả

năng cao việc tìm thấy các lỗi chưa từng được phát hiện

• Một kiểm thử thành công là kiểm thử mà phát hiện lồi chưa từng

được phát hiện

1.3 Những khó khăn của kiếm thử

• Nâng cao chất lượng phần mềm nhưng không vượt quá chất lưọưg

thiết kế chỉ phát hiện các lỗi tiềm tàng và sửa chúng

• Phát hiện lỗi bị hạn chế do thủ công là chính

• Dễ bị ảnh hưởng tâm lý khi kiếm thủ

• Khó đảm bảo tính đầy đủ của kiểm thử

1.4 Các phưoưg pháp kiếm thử

Người ta phân biệt 2 phương pháp kiểm thử: Kiểm thử trên bàn hay kiểmthử tĩnh và Kiếm thử trên máy hay kiếm thử động Kiểm thử tĩnh thường đượctiến hành trước nhằm tạo ra kịch bản cho kiếm thử động

1.5 Các kỹ thuật thiết kế trường họp kiếm thủ’

Kiếm thử hộp đen - Black box testing

Kiểm thử hộp trắng - White box testing

Kiểm thử hộp xám - Gray box testing

-PHẦN II GIỚI THIỆU CHI TIẾT VÊ KIỂM THỦ

Có thể sử dụng một số kỹ thuật trong quá trình kiểm thử nhằm

tăng

hiệu quả của họat động này Mc Gregor mô tả các kỹ thuật kiêm thử

nhu những công cụ được thiết kế đế đảm bảo rằng tất cả các khía cạnh

của sản phẩm đều đuợc khảo sát Mặt khác, các kỹ thuật kiểm thử là

những công cụ để dễ dàng đạt được hiệu quả kiểm thử

2.1 Nguyên tắc cơ bản kiếm thử phần mềm.

Trong lúc kiểm thử, công nghệ phần mềm phát sinh một chuỗi các trườnghọp kiếm thử được sử dụng đế “tách tùng phần” phần mềm Kiếm thử là

một bước trong qui trình phần mềm mà có thế được xem xét bởi đội ngũ

phát triển bằng cách phá vỡ thay vì xây dựng Các kỹ sư phần mềm

chính là những người xây dựng và việc kiểm thử yêu cầu họ vượt qua cáckhái niệm cho trước về độ chính xác và giải quyết mâu thuẫn khi các lỗi

-6- 4/10/2013Nguyền Ngọc

Khác biệt với thanh tra:

Điều kiện bên ngoài Các lóp tương đương hợp

lệ Các lóp tương đươngkhông hợp lệ

4/10/2013

(6) Điều chỉnh môi trường thực hiện môđun tải (tạo thủ tục đưa các tệp truy

-cập tệp vào chương trình)(7) Thực hiện môđun 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 (5)-(8)

2.3 Các kỹ thuật thiết kế trưòng họp kiếm thử 2.3.1 Kiểm thử hộp đen - Black box testing

Kiểm thử hộp đen (Black Box testing) là kỹ thuật thiết kế trường hợp thử

dựa trên đặc tả bề ngoài của chương trình Người kiếm thử chỉ quan tâm đếnnhiệm vụ mà mô đun phải đảm nhận, đầu vào cho mô đun và kết quả xử lý - đầura

Kiếm thử hộp đen lại chia nhỏ ra nhiều kỹ thuật:

- Phân đoạn tương đương

- Phân tích giá trị biên

- Đoán lỗi

và một sổ kỹ thuật khácHình 1: Black Box testing

*Phân Đoạn Tương Đương

Đây là kỹ thuật chia vùng thông tin nhập vào của chương trình thành các lớpthông tin/dữ liệu Lớp tương đương biểu diễn thành một tập các giá trị hợp lệ và

thành một lóp tương đương họp lệ và hai lớp tương đương không hợp

lệ Chẳng hạn, nếu đầu vào x=5, thì lớp hợp lệ là x= 5, các lớp khônghợp lệ là X <5 và X >5

Neu điều kiện đầu vào xác định một phần tử của tập hợp, thì phânhoạch thành một lóp tương đương họp lệ và một lóp tương đương khônghọp lệ

Neu điều kiện đầu vào là Boolean, thì phân hoạch thành một lớptương đương họp lệ và một lóp tương đương không họp lệ tương ứng với

Một mẫu cho việc liệt kê các lóp tưong đưong

Ngoài ra, một nguyên tắc thứ năm được bố sung là sử dụng khả năngphán đoán, kinh nghiệm và trục giác của người kiểm thử

Các trường họp kiếm thửBước thứ hai trong phương pháp phân đoạn tương đương là thiết kếcác trường họp kiếm thử dựa trên sự ước lượng của các lóp tương đươngcho miền đầu vào Tiến trình này được thực hiện như sau:

1. Gán một giá trị duy nhất cho mỗi lóp tương đương

Đen khi tất cả các lớp tương đương hợp lệ được phủ bởi các trườnghợp kiếm thử thì viết một trường hợp kiếm thử mới phủ nhiều nhất cóthể các lóp tương đương họp lệ chưa được phủ

Đen khi tất cả các lớp tương đương không họp lệ được phủ bởi cáctrường hợp kiểm thử thì hãy viết các trường hợp kiểm thử mới sao chomỗi trường hợp kiểm thử mới chỉ phủ duy nhất một lớp tương đươngkhông họp lệ chưa được phủ

Nguyền Ngọc Hải -9- 4/10/2013

*Phân tích giá trị biên - Boundary Value Analysis

Kinh nghiệm cho thấy các ca kiểm thử mà khảo sát tỷ mỷ các điều kiện biên có

tỷ lệ phần trăm cao hon các ca kiểm thử khác Các điều kiện biên là những điềukiện mà các tình huống ngay tại, trên và duới các cạnh của các lớp tuong đưongđầu vào và các lớp tương đương đầu ra Phân tích các giá trị biên là phươngpháp thiết kế ca kiếm thử bô sung thêm cho phân lóp tương đương, nhưng khácvới phân lóp tương đương ở 2 khía cạnh:

1. Phân tích giá trị biên không lựa chọn phần tử bất kỳ nào trong 1 lóptương đương là điển hình, mà nó yêu cầu là 1 hay nhiều phần tử đượclựa chọn như vậy mà mỗi cạnh của lớp tương đương đó chính là đổitượng kiểm tra

2. Ngoài việc chỉ tập trung chú ý vào các trạng thái đầu vào (không gianđầu vào), các ca kiểm thử cũng nhận được bằng việc xem xét khônggian kết quả (các lóp tương đương đầu ra)

Phân tích giá trị biên yêu cầu óc sáng tạo và lượng chuyên môn hóa nhất định và

nó là một quá trình mang tính kinh nghiệm rất cao Tuy nhiên, có một số quy tắcchung như sau:

1. Neu 1 trạng thái đầu vào định rõ giới hạn của các giá trị, hãy viết các cakiếm thử cho các giá trị cuối của giới hạn, và các ca kiếm thử đầu vàokhông hợp lệ cho các trường hợp vừa ra ngoài phạm vi

2. Neu 1 trạng thái đầu vào định rõ số lượng giá trị, hãy viết các ca kiểmthử cho con số lớn nhất và nhở nhất của các giá trị và một giá trị trên,một giá trị dưới những giá trị này

3. Sử dụng quy tắc 1 cho mỗi trạng thái đầu vào Ví dụ, nếu 1 chương trình

tính toán sự khấu trừ FICA hàng tháng và nếu mức tối thiểu là 0.00$, vàtối đa là 1,165.25$, hãy viết các ca kiểm thử mà khấu trù' 0.00$ và1,165.25, khấu trù' âm và khấu trù' lớn hơn 1,165.25$ Chú ý là việc xem

- 10- 4/10/2013Nguyền Ngọc Hải

của giới hạn đầu ra (ví dụ, xét chương trình con tính SIN) Ngoài ra,không phải lúc nào cũng có thể tạo ra 1 kết quả bên ngoài giới hạn đầu

ra, nhưng tuy nhiên rất đáng để xem xét tiềm ẩn đó

4. Sử dụng nguyên tắc 2 cho mỗi trạng thái đầu ra

5. Neu đầu vào hay đầu ra của 1 chương trình là tập được sắp thứ tự’ ( vídụ,l file tuần tự hay 1 danh sách định tuyến hay 1 bảng) tập trung chú ývào các phần tử đầu tiên và cuối cùng của tập họp

6. Sử dụng sự khéo léo của bạn đế tìm các điều kiện biên

khoảng giá trị

tương đưong

Kỹ Thuật Cause-Effect Graphing

Ta thấy rằng 2 kỹ thuật trên dữ liệu đầu vào đã được phân loại đế phân tích Tuynhiên kỹ thuật sắp trình bày dưới đây cho phép xác định ra các trường họp kiểmthử hiếu quả nhất ngay cả trong lúc dữ liệu đầu vào là khó phân loài thành cáclớp như trong 2 kỹ thuật trên

Kỹ thuật này gồm có 4 bước như sau :

1. Đặc tả được chia thành các phần có thể thực hiện được Điều này là cầnthiết bởi vì đồ thị nguyên nhân - kết quả trở nên khó sử dụng khi được

sử dụng trên những đặc tả lớn

2. Nguyên nhân và kết quả trong các đặc tả được nhận biết Một nguyênnhân là một trạng thái đầu vào nhất định hay một lớp tương đương củacác trạng thái đầu vào Một kết quả là một trạng thái đầu ra hay 1 sự

-11- 4/10/2013Nguyền Ngọc Hải

biến đổi hệ thống (kết quả còn lại mà 1 đầu vào có trạng thái của 1chương trình hay hệ thống) Bạn nhận biết nguyên nhân và kết quả bằng

việc đọc từng từ của đặc tả và gạch chân các từ hoặc cụm từ mô tảnguyên nhân và kết quả Khi được nhận biết, mỗi nguyên nhân và kếtquả được gán cho 1 số duy nhất

3. Xây dựng đồ thị nguyên nhân - kết quả bằng cách phát triển và biến đổinội dung ngữ nghĩa của đặc tả thành đồ thị Boolean nối giữa nguyênnhân và kết quả

4. Đồ thị được được diễn giải với các ràng buộc mô tả những sự kết hợpcủa nguyên nhân và/hoặc kết quả là không thể vì các ràng buộc ngữnghĩa và môi trường

5. Bằng việc dò theo các điều kiện trạng thái trong đồ thị một cách cấnthận, bạn chuyển đổi đồ thị thành một bảng quyết định mục vào giớihạn Mỗi cột trong bảng mô tả một ca kiểm thử

6. Các cột trong bảng quyết định được chuyển thành các ca kiếm thử

Ký hiệu cơ bản cho đồ thị được chỉ ra trong hình 1 Tưởng tượng mồi nút có giátrị là 0 hoặc 1; 0 mô tả trạng thái vắng mặt và 1 mô tả trạng thái có mặt Hàm

đồng nhất nói là nếu a là 1 thì ồ là 1; ngược lại, b là 0 Hàm not là nói nếu a là

1 thì b là 0; ngược lại thì b là 1 Hàm or khẳng định rằng nếu a hoặc b hoặc c là

1, thì d là 1; ngược lại d là 0 Hàm and khẳng định nếu cả a và b là 1 thì c là 1; ngược lại c là 0 Hai hàm or và and được phép có số lượng đầu vào bất kỳ.

Ràng buộc E (Exclude - loại trù') khắng định rằng tối đa, chỉ có hoặc a hoặc b có thế là 1 (a và b không thế đồng thời là 1) Ràng buộc I (Include - bao hàm) khẳng định ít nhất một trong a, b hoặc c phải luôn luôn là 1 (a, b hoặc c không

thế đồng thời là 0) Ràng buộc o (Only - chỉ một) khắng định một và chỉ một

hoặc a hoặc b phải là 1 Ràng buộc R (Request - yêu cầu) khắng định rằng khi a

là 1, thì b phải là 1 (ví dụ, không thể có trường hợp a là 1, còn b là 0) Ràng buộc M (Mask - mặt nạ) khắng định là nếu kết quả a là 1, kết quả b sẽ bắt buộc

phải là 0

Hình 2 Các ký hiệu ràng buộc

Bước tiếp theo là tạo bảng quyết định mục vào giới hạn - ỉimited-entry decision table Tương tự với các bảng quyết định, thì nguyên nhân chính là các điều kiện

và kết quả chính là các hành động Quy trình được sử dụng là như sau:

1. Chọn một kết quả đế là trạng thái có mặt (1)

2. Lần ngược trở lại đồ thị, tìm tất cả những sự kết hợp của các nguyênnhân (đối tượng cho các rằng buộc) mà sẽ thiết lập kết quả này thành 1

3. Tạo một cột trong bảng quyết định cho mỗi sự kết hợp nguyên nhân

4. Với mồi sự kết hợp, hãy quy định trạng thái của tất cả các kết quả khác

và đặt chúng vào mỗi cột

Trong khi biểu diễn bước 2, cần quan tâm các vấn đề sau:

1. Khi lần ngược trở lại qua một nút or mà đầu ra của nó là 1, không bao giờ thiết lập nhiều hơn 1 đầu vào cho nút or là 1 một cách đồng thời Điều này được gọi là path sensitizing - làm nhạy đường đi Mục tiêu

của nó là để ngăn chặn dò lỗi thất bại vì một nguyên nhân che đi mộtnguyên nhân khác

Nguyền Ngọc Hải

nếu bạn đang khảo sát trạng thái mà 1 đầu ra là 0 và một hay nhiều đầu

ra khác là 1, thì không nhất thiết phải liệt kê tất cả các điều kiện màdưới điều kiện đó các đầu vào khác có thế là 1

3. Khi lần ngược trở lại qua một nút and mà đầu ra của nó là là 0, chỉ cần liệt kê 1 điều kiện trong đó tất cả đầu vào bằng 0 (Neu nút and ở chính

giữa của đồ thị như vậy thì tất cả các đầu vào của nó xuất phát từ cácnút trung gian khác, có thế có quá nhiều trạng thái mà trong trạng thái

đó tất cả các đầu vào của nó bằng 0.)

Hình 3 Những xem xét được sử dụng khi dò theo đồ thị

Những sự xem xét này có thể xuất hiện thất thường, nhưng chúng có một mục

đích rất quan trọng: đế giảm bớt các kết quả được kết hợp của đồ thị Chúng liệt

kê các trường hợp mà hướng về các ca kiếm thử ít có lợi Neu các ca kiếm thử ít

có lợi không được liệt kê, một đồ thị nguyên nhân - kết quả lớn sẽ tạo ra một sốlượng ca kiểm thử cực kỳ lớn Neu số lượng các ca kiểm thử trên thực tế là quálớn, bạn sẽ chọn ra 1 tập con nào đó, nhưng không đảm bảo là các ca kiểm thử ít

Một kỹ thuật thiết kế trường hợp kiếm thử khác là error guessing - đoán lỗi.

Tester được đưa cho 1 chương trình đặc biệt, họ phỏng đoán, cả bằng trực giác

và kinh nghiệm, các loại lồi có thể và sau đó viết các ca kiểm thử để đưa ra cáclỗi đó

Thật khó đế đưa ra một quy trình cho kỹ thuật đoán lỗi vì nó là một quy trình cótính trực giác cao và không thể dự đoán trước Ý tưởng cơ bản là liệt kê mộtdanh sách các lỗi có thể hay các trường hợp dễ xảy ra lỗi và sau đó viết các cakiếm thử dựa trên danh sách đó Một ý tưởng khác đế xác định các ca kiếm thử

có liên đới với các giả định mà lập trình viên có thể đã thực hiện khi đọc đặc tả(tức là, những thứ bị bỏ sót khỏi đặc tả, hoặc là do tình cờ, hoặc là vì người viết

có cảm giác những đặc tả đó là rõ ràng) Nói cách khác, bạn liệt kê nhữngtrường họp đặc biệt đó mà có thế đã bị bỏ sót khi chương trình được thiết kế

2.3.2 Kiếm thử hộp trắng - White box testing

• Kiếm thử hộp trắng là kiểm tra cấu trúc và logic phần mềm theo mụctiêu(Trong trường hợp này yêu cầu người kiểm thử phải biết ngôn ngữ WHITE BOX TESTS

c E>

Nguyền Ngọc Hải - 1 6 - 4/10/2013

* Kiếm thử đường diễn tiến của chương trình

Khái niêm: Là việc thiết kế các trường hợp kiếm thử trên tòng câu lệnh trongchương trình được sẽ được thực hiện ít nhất 1 lần không quan tâm đến ảnhhưởng lên các đường quyết định

Mỗi nút của đồ thị đượcbiếu diễn một lệnh haymột dãy lệnh liên tiếp củachương trình

Các bước tiến hành:Dùng tài liệu thiết kế hay

mã nguồn đế vẽ thuật toáncủa chương trình hay hàm

Xác định đồ thị V(G)

Từ đồ thị 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 xác định ở trên

*Kiểm Định cấu Trúc Điều Kiển

a Kiểm thử các biểu thức điều kiện

Kiếm thử biếu thức điều kiện là phương pháp kiểm thử trên những điều kiệnlogic của hàm hay module Một điều kiện đơn giản là một biến boolean hoặc làmột biếu thức quan hệ:

• X hay Not X một điều kiện logic đơn giản

Các loại lỗi của điều kiện bao gồm

Lỗi trong các thao tác luận lý (lỗi tồn tại một biểu thức không đúng, thiếu hoặcthừa các thao tác luận lý

• Lỗi do giá trị của biến luận lý

• Lỗi do dấu ngoặc

• Lỗi do phép toán quan hệ

• Lỗi trong biểu thức toán học

Mục đích của kiếm thử cấu trúc điều kiến là phát hiện không chỉ lỗi trong điềukiện mà còn những lỗi khác trong chuơng trình Neu một tập kiếm thử cho mộtchuơng trình p là hiệu quả cho việc phát hiện lỗi trong điều kiện của p,thì bộkiếm thử đò cũng có thể phát hiện các lỗi khác trong p

E1 <phép toán quan hệ> E2

Ba trường hợp kiểm thử được yêu cầu đế kiểm tra là giá trị E1 lớn hơn, nhỏ hơn

và bằng giá trị của E2 Neu <phép toán quan hệ> là không đúng và E1, E2 làđúng thì 3 loại kiếm thử trên có đảm bảo có thế xác định được lỗi trong phéptoán quan hệ Đe phát hiện lỗi trong E1 và E2 thì các trường họp kiểm thử E1 lớn

hơn, nhỏ hơn E2 có thế phát hiện ra được lỗi