I.

Giới thiệu đề tài

“Lỗi phần mềm là chuyện hiển nhiên của cuộc sống. Chúng ta dù cố gắng
đến mức nào thì thực tế là ngay cả những lập trình viên xuất sắc nhất cũng không
có thể lúc nào cũng viết được những đoạn mã không có lỗi. Tính trung bình, ngay
cả một lập trình viên loại tốt thì cũng có từ1 đến 3 lỗi trên 100 dòng lệnh. Người ta
ước lượng rằng việc kiểm tra đểtìm ra các lỗi này chiếm phân nửa khối lượng công
việc phải làm đểcó được một phần mềm hoạt động được”. (Software Testing
Techniques, Second Edition, by Boris Beizer, VanNostrand Reinhold, 1990, ISBN
1850328803).

Thật vậy, ngày nay càng ngày các chương trình (các phần mềm) càng trở lên
phức tạp và đồ sộ. Việc tạo ra một sản phẩm có thể bán được trên thịtrường đòi hỏi
sự nổ lực của hàng chục, hàng trăm thậm chí hàng ngàn nhân viên. Sốlượng dòng
mã lên đến hàng triệu. Và đểtạo ra một sản phẩm thì không phải chỉdo một tổchức
đứng ra làm từ đầu đến cuối, mà đòi hỏi sự liên kết, tích hợp của rất nhiều sản
phẩm, thư viện lập trình, … của nhiều tổchức khác nhau… Từ đó đòi hỏi việc kiểm
nghiệm phần mềm càng ngày càng trởnên rất quan trọng và rất phức tạp.

Chúng em chọn đề tài Tìm hiểu các kĩ thuật kiểm thử phần mềm. Một số
công cụ hỗ trợ kiểm thử : JUnit, NUnit đề làm bài tập lớn môn Đảm bảo chất
lượng phần mềm. Tuy chúng em đã cố gắng nhưng vẫn còn nhiều sai sót, mong
thầy giáo thông cảm, đưa ra nhận xét để chúng em hiểu một cách hoàn thiện hơn.

II. Tổng quan về kiểm thử

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

Theo IEEE thì tổng quan về kiểm thử phần mềm là như sau:
Kiểm thử là một hoạt động thực hiện để đánh giá chất lượng sản phẩm, để cải thiện
nó, bằng cách định ra các nhược điểm và vấn đề của nó. Kiểm thử bao gồm các xác
minh về sự đáp ứng của phần mềm trước một tập các test case, được lựa chọn phù
hợp từ các modul thực thi phổ biến của phần mềm, so sánh với các đáp ứng đáng
mong đợi.

b. Mục tiêu của kiểm thử

Là mấu chốt của đảm bảo chất lượng phần mềm

Là tiến trình (và là nghệ thuật) nhằm phát hiện lỗi bằng việc xem xét lại đặc tả,
thiết kế và mã nguồn.

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ở .
c. Các phương pháp kiểm thử
Có hai phương pháp kiểm thử: Kiểm thử tĩnh và kiểm thử trên máy.
Kiểm thử tĩnh: bằng cách kiểm tra trên bàn, giấy bút kiểm tra logic,
Kiểm thử xuyên suốt, hoặc Thanh tra.
Kiểm thử trên máy: Dùng máy chạy chương trình để điều tra trạng
thái từng động tác của chương trình. Có 9 bước kiểm thử bằng máy:

1. Thiết kế trường hợp thử theo thử trên bàn

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 module tải để thực hiện
4. Khi trường hợp thử có xử lý tệp vào-ra, phải làm trước
trên bàn việc xác định miền của các tệp

5. Nhập dữ liệu đã thiết kế cho trường hợp kiểm thử

 6. Điều chỉnh môi trường thực hiện module 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 module 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)
d. Phương pháp kiểm thử module.
i. Kiểm thử từ dưới lên ( Buttom up Test)

o Mô đun ở mức thấp nhất sẽ được kiểm thử đầu tiên

o Mỗi một driver được viết để theo dõi các đầu vào và đầu ra
o Kiểm thử từng khối
o Driver sẽ bị xoá đi và các cụm sẽ được kết hợp lại, sau đó
di chuyển nên trên trong cấu trúc chương trình

Thuận tiện

o Không cần đến gốc

o Rất dễ điều chỉnh số lượng người cần thiết
o Lỗi quyết định sớm được tìm thấy

Sự bất tiện

o Các driver kiểm thử là cần thiết

o Rất nhiều môđun phải được tích hợp trước khi làm việc
o Lỗi giao diện khám phá muộn

Chú thích
 o Phải kiểm tra nhiều các đoạn mã hơn là so với Top-Down,
Bottom-up là một cách mang tính trực giác nhiều hơn
ii. Kiểm thử từ trên xuống(Topdown Test)
o Hàm Main là nút gốc còn tất cả cá môđun ở bên dươic là
các gốc con(bới vì sau khi kiểm thử xong nút gốc này thì
tất cả cá nút gốc con sẽ được kiểm thử).
o Stubs are replaced with actual modules one at a time,
depending on the integration approach selected
(depth/breadth first).
o Nút gốc sẽ được thay thế bằng các môđun cụ thể, phụ
thuộc vào hướng kiểm thử tích hợp được lựa chọn.
o Cứ tiếp tục quá trình như vậy cho đến khi nào kết thúc
chương trình thì thôi.
o Thuật tiện
o Không cầm có driver kiểm thử.
o Lỗi giao diện được phát hiện sớm.
Bất tiện
o Cần gốc (stubs).
o Làm chậm tiến trình kiểm thử.
o Lỗi ở trong các môđun ở mức thấp khó tìm ra.
Chú thích
o Chương trình làm việc đầu tiên nâng lên tinh thần.
o Rất khó để có thế duy trì thuần top-down trong thực tế.

iii. Kiểm thử cột trụ (Big Bang Test)

 Big Bang là một kiểm thử tích hợp không tăng tiến. Tất cả các
mô đun đều được phối hợp ngay từ đầu. Phần mềm được kiểm thử
toàn bộ - kết quả ban đầu thường là lộn xộn. Để đúng được là rất khó
vì một dãy các lỗi gặp phải. Khi một lỗi được sửa thì lại bắt gặp một
lỗi khác chỉ cho tới khi nào vòng lặp dừng thì thôi. Cho nên phương
pháp này không được đề nghị

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

Là một phương pháp kiểm thử kết hợp cả top-down và bottom-up

 Tất cả các môđun và giao diện đều phải kiểm thử bằng phương pháp
Top-Down
 Cả driver và stub đều được sử dụng khi cần thiết
 Tất cả các môđun đều được xây dựng và kiểm thử unit bắt đầu từ
mức thấp nhất, sử dụng chiến thuật Bottom-Up
Tiêu chí để hoàn thành:

Một tester phải biết khi nào kiểm thử là đủ. Kiểm thử có thể dừng khi:

 Nó không phát sinh lỗi

 Nó đã bao phủ gần như hoàn toàn
 Nó phát hiện ra một số lượng lỗi
 Kế hoạch kiểm thử kết thúc