6 1 testingviet testing PTIT

!"#$%&'()*%+, (/00*&%12'((
34(567(8926 (:;<2(
=5>5?@>5?!A(
1;"2B-CDEF-G'B*GH1(
I(
Software Testing
J(
Ví dụ về lỗi phần mềm
Vụ thất bại tên lửa Patriot:
xảy ra tại Dharan, Saudi Arabia, vào 25 tháng 2, 1991
làm 28 người chết
nguyên nhân: vì lỗi rounding error (làm tròn)
American
army
Iraqi
American Army
barracks
0.5km
missile

K(
Ví dụ về lỗi phần mềm (tiếp)
Vụ phát nổ Ariane 5:
xảy ra tại tại Kourou, French Guiana , vào ngày 4 tháng sáu 1996
thiệt hại 500 triệu $
nguyên nhân: vì lỗi tràn số (Overflow error)
(vì biểu diễn số phẩy động (floating point) 64-bit
bởi số phẩy tĩnh (fixed point) 16-bit)

The rocket exploded just
40 seconds after its lift-

off

Đặc tả và lỗi phần mềm
Đặc tả
“if you can’t say it, you can’t do it”
•  Ta cần biết sản phẩm như thế nào
trước khi ta có thể nói nó có lỗi.
•  Đặc tả định nghĩa sản phẩm và:
•  Yêu cầu chức năng mô tả các tính năng của sản
phẩm. Ví dụ, calculator:
•  Save, +, -, *, /, …
•  Yêu cầu phi chức năng là các ràng buộc về sản phẩm.
Ví dụ ,
•  thân thiện với người dùng, hiệu năng, …
12/31/13
Đặc tả và lỗi phần mềm
Lỗi phần mềm
•  Phần mềm KHÔNG làm nhiệm vụ được đưa ra ở đặc
tả (ví dụ, thiếu phép trừ)
•  Phần mềm làm công việc mà đặc tả KHÔNG cho
phép
•  Phần mềm làm công việc mà đặc tả không đề cập tới
(ví dụ, tính căn bậc hai của số nguyên)
•  Phần mềm không làm công việc mà đặc tả không đề
cập tới nhưng nên làm (ví dụ, kiểm tra divided by 0)
•  Phần mềm khó hiểu, khó dùng, chậm …

12/31/13
Chi phí sửa lỗi
Chi phí sửa lỗi tăng theo cấp số nhân (10x) theo thời gian

Ví dụ, một lỗi phát hiện trong pha đặc tả tốn $1 để sửa.
… nếu phát hiện trong pha thiết kế, tốn $10
… nếu phát hiện trong pha cài đặt, tốn $100
… nếu phát hiện sau khi phát hành, tốn $1000

12/31/13
Kiểm thử - Testing
12/31/13
Kiểm thử phần mềm - KTPM
•  KTPM 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 (IEEE
Standard Glossary of Software Engineering
Terminology).
•  KTPM là quá trình thực thi một chương trình với mục
đích tìm lỗi. ( “The Art of Software Testing”).
•  Một cách dễ hiểu: KTPM là quá trình thực thi một hệ
thống phần mềm để xác định xem phần mềm có
đúng với đặc tả không và môi trường hoạt động có
đúng yêu cầu không.



12/31/13
Software testing objectives
•  Các mục tiêu trực tiếp
•  Xác định và phát hiện nhiều lỗi nhất có thể trong phần mềm
được kiểm thử
•  Sau khi sửa chữa các lỗi đã xác định và kiểm tra lại, làm
cho phần mềm đã được kiểm thử đến một mức độ chấp

nhận được về chất lượng.
•  Thực hiện các yêu cầu kiểm thử cần thiết một cách hiệu
quả và có hiệu quả, trong phạm vi ngân sách và thời gian
cho phép.
•  Các mục tiêu gián tiếp
•  Biên dịch một bản ghi về các lỗi phần mềm để sử dụng
trong công tác phòng chống lỗi (bằng các hành động khắc
phục và ngăn ngừa).
Ca kiểm thử (test case)
Ca kiểm thử: dữ liệu để kiểm tra hoạt động của
chương trình
Ca kiểm thử tốt: được thiết kế để phát hiện một
lỗi của chương trình
Kiểm thử thành công: phát hiện ra lỗi
Mục đích:
− Chứng minh được sự tồn tại của lỗi
− Không chứng minh được sự không có lỗi

12/31/13
Nôi dung của test case
Tên module/chức năng muốn kiểm thử dữ liệu
vào
− dữ liệu thông thường: số, xâu kí tự, file,
− môi trường thử nghiệm: phần cứng, OS,
− thứ tự thao tác (khi kiểm thử giao diện)
Kết quả mong muốn
− thông thường: số, xâu kí tự, file,
− màn hình, thời gian phản hồi
Kết quả thực tế

13
Khó khăn của kiểm thử
“Testing shows the presence, not the absence of bugs.” —Edsger
W. Dijkstra
•  A key tradeoff of testing:
–  Kiểm thử càng nhiều trường hợp tiềm năng càng tốt nhưng
phải trong phạm vi tài chính cho phép
•  Mục tiêu là tìm bugs càng rẻ & nhanh càng tốt.
–  Tư tưởng: thiết kế “right” test case mà phát hiện ra fault và
chạy nó
•  Trên thực tế, ta phải thực hiện nhiều “unsuccessful” test
cases mà không phát hiện ra bugs nào.
Các mức kiểm thử - Beizer’s Testing Levels

12/31/13
Các mức kiểm thử
Mức 0: testing và debuging là giống nhau
Mức 1: Mục tiêu của kiểm thử là để chỉ ra phần
mềm hoạt động
Mức 2: Mục tiêu của kiểm thử là để chỉ ra phần
mềm không hoạt động
Mức 3: Mục tiêu của kiểm thử là để giảm các rủi
ro khi sử dụng phần mềm
Mức 4: Nhằm trợ giúp các chuyên gia CNTT phát
triển các phần mềm có chất lượng cao hơn.

12/31/13
Mức 0
•  Testing và debuging là một
•  thường được thực hiện bởi các sinh viên trong

các môn học lập trình. Sinh viên viết chương
trình, chạy với vài đầu vào, và debug lỗi nếu
có.
•  không phân biệt giữa hành vi không đúng và
lỗi bên trong chương trình.
•  chỉ giúp ích đôi chút trong việc phát triển phần
mềm chính xác
12/31/13
Mức 1
•  Nhằm để chứng minh tính đúng đắn.
•  Một cách phát triển tự nhiên từ mức 0
•  Ta không thể chứng minh tính đúng đắn của phần
mềm.
•  Giả sử ta chạy một tập test và không phát hiện ra lỗi nào. Vậy, phần
mềm chạy tốt hay tập test kém?
•  Việc kiểm thử không có giới hạn dừng cố định, cũng
như không có một kỹ thuật test hình thức (formal)
nào.
•  Nếu người quản lý hỏi: còn phải thực thi bao nhiêu test nữa? Ta không
có cách nào trả lời chính xác câu hỏi này.
12/31/13
Mức 2
•  Nhằm để chỉ ra lỗi.
•  Tìm lỗi là một mục tiêu mang tính tiêu cực.
•  Tester có thể vui vẻ khi tìm ra lỗi, nhưng developers thì
không muốn vậy - họ muốn phần mềm chạy (mức 1 là suy
nghĩ tự nhiên của developers).
•  Đặt tester & developers vào quan hệ đối đầu.
•  Điều này có thể ảnh hưởng xấu tới cả nhóm.
•  Nếu không tìm thấy lỗi nào thì sao?

•  Phần mềm chạy tốt? hoặc việc kiểm thử còn yếu?
12/31/13
Mức 3
•  Dựa trên nhận định: “Kiểm thử có thể chỉ ra lỗi
khi nó xuất hiện, nhưng không thể chứng tỏ
phần mềm không có lỗi”.
•  Nghĩa là, ta phải chấp nhận mỗi khi sử dụng phần mềm, ta
có nguy cơ gặp lỗi.
•  Toàn đội phát triển phần mềm có chung mục
tiêu - giảm nguy cơ gặp lỗi khi sử dụng phần
mềm.
•  Cả tester và developer làm việc cùng nhau để
giảm nguy cơ gặp lỗi.
12/31/13
Mức 4
Khi tester và developers có chung mục tiêu (mức
3), tổ chức có thể chuyển sang mức 4. Kiểm
thử nhằm mục tiêu tăng chất lượng.
Có nhiều cách để tăng chất lượng, trong đó tạo ra test có thể
dẫn tới lỗi chỉ là một.
Kỹ sư kiểm thử có thể trở thành trưởng nhóm kỹ
thuật của dự án. Họ có nhiệm vụ đánh giá, cải
thiện chất lượng phần mềm, và sự thẩm định
của họ sẽ trợ giúp cho developers.

12/31/13
Mức 4
•  Ví dụ như ta có 1 chương trình spell checker.
•  để tìm những từ sai chính tả (đánh vần sai),
•  để tăng khả năng viết chính tả: mỗi khi spell checker tìm ra

một từ sai chính tả, ta có cơ hội để học cách viết đúng.
•  Do vậy, spell checker là “chuyên gia” về chất lượng viết
chính tả.
•  Tương tự, mức 4 hướng tới mục tiêu kiểm thử
để tăng khả năng của developers trong việc
phát triển các phần mềm chất lượng cao.
•  Testers có thể đào tạo developers.
12/31/13
12/31/13
Các kỹ thuật kiểm thử
1. Kiểm thử hộp đen – black box testing
2. Kiểm thử hộp trắng – white box testing

12/31/13
1. Kiểm thử hộp đen
•  Black-box testing là phương pháp kiểm thử mà không
cần biết cài đặt của chương trình.
•  Cần có một bản chương trình chạy được và đặc tả
•  Một số kỹ thuật thiết kế test:
a.  phân lớp tương đương (Equivalence Class Partitioning).
b.  phân tích các giá trị biên (Boundary value analysis).
c.  dùng các bảng quyết định (Decision Tables)
d.  kiểm thử theo cặp (Pairwise)
e.  dùng bảng chuyển trạng thái (State Transition)
f.  …
•  Quan trọng trong công nghiệp
a. Phân lớp tương đương – Equivalence
Patitioning
•  chia miền đầu vào thành các lớp dữ liệu, từ đó
suy dẫn ra các ca kiểm thử.

•  Lớp tương đương biểu thị cho tập các trạng thái hợp lệ hay
không hợp lệ đối với điều kiện vào.
•  Thiết kế Test-case theo 2 bước:
•  Xác định các lớp tương đương.
•  Xác định các ca kiểm thử.

12/31/13