0% found this document useful (0 votes)

4 views

01 Testing-Intro

gioi thieu kiem thu

Uploaded by

haunam3112

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

4 views

01 Testing-Intro

gioi thieu kiem thu

Uploaded by

haunam3112

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 38

KIỂM THỬ VÀ ĐẢM BẢO

CHẤT LƯỢNG PHẦN MỀM

Giới thiệu
Nội dung

• Một số khái niệm cơ bản

• Tại sao cần kiểm thử phần mềm?
• Mục tiêu của kiểm thử
• Kiểm chứng và kiểm định phần mềm
• Kiểm thử hộp trắng, kiểm thử hộp đen
Phần mềm xuất hiện ở mọi nơi
Tại sao cần kiểm thử
phần mềm?
Phần mềm

• Ngành công nghiệp phần mềm đã phát triển mạnh mẽ

trong vài thập kỷ qua.
• Phần mềm ngày càng:
- Lớn hơn
- Cạnh tranh hơn
- Có nhiều người dùng hơn

• Phần mềm là một phần quan trọng của:

- airplanes, spaceships, air traffic control systems…
- watches, ovens, cars, DVD players, mobile phones, remote
controls…
Câu chuyện về phần mềm thất bại

• NASA’s Mars lander: 9/1999, tàu không gian đã bị đâm

vào sao hoả bởi vì lỗi đơn vị tính của 2 mô-dun được làm
bởi 2 nhóm phát triển khác nhau.

• Therac-25 radiation machine: Không kiểm tra kỹ tính an

toàn của phần phần mềm đã làm cho 3 người thiệt mạng.

• Chip Pentium of Intel: đưa ra kết quả sai cho một số

phép chia
Câu chuyện về phần mềm thất bại

• Airbus A220: Sau khi cập nhật phần mềm à động cơ

rung quá mức cho phép à ít nhất có 3 chuyến bay phải hạ
cánh khẩn cấp
• Jeep: đã phải thu hồi 1.5 triệu ô tô bởi vì một số phần
mềm trong những chiếc ô tô này có thể bị hacked từ bên
ngoài
• Một ngân hàng ở Banglades bị mất 81 triệu đô, do lỗ hổng
trong phần mềm và hacker có thể truy cập vào hệ thống
và lấy trộm tiền
The total cost of poor software quality in the US

Thống kê năm 2020, báo cáo xuất bản ngày 1/1/2021 bởi Consortium for
Information & Software Quality (CISQ)
Tại sao cần kiểm thử phần mềm?

• Phần mềm ngày càng được ứng dụng vào nhiều lĩnh vực.
• Con người ngày càng phụ thuộc chặt chẽ vào các sản
phẩm phần mềm.
• Ngành công nghiệp phần mềm đang đối mặt với hai thách
thức:
- Sản xuất phần mềm với giá thành thấp
- Phần mềm cần dễ dùng, an toàn và tin cậy
Tại sao cần kiểm thử phần mềm?

• Lỗi nên được tìm ra trước khi phát hành sản phẩm/ bàn
giao sản phẩm cho khách hàng
• Kiểm thử là một cách để đo độ tin cậy của phần mềm

à Kiểm thử có phương pháp là một hoạt động không

thể thiếu
Tại sao phần mềm lại có rất nhiều lỗi/bugs?
Software faults, errors,
and failures
Software faults, errors & failures

• Software fault: A static defect in software (incorrect lines

of code, often referred to as bug)
• Software error: An incorrect interal state that is the
manifestation of some fault(s) (unobserved)
• Software failure: External, incorrect behavior with respect
to the requirements or other description of the expected
behavior (observed)
Ví dụ
Fault: Should start
searching at 0, not 1

!"#$%&'())%&'%+) +",-./0 1%+) 2'3'//4

Test 1
5''66'788.&)(9':8'*// %('+"$$');/0<'="$$>0%+)./7?&.!)%0+ [ 2, 7, 0 ]
66'.$(.'/.)"/+');.'+",#./'08'0&&"//.+&.('08'@'%+'*// Expected: 1
%+) &0"+)'A'@B Actual: 1
80/'1%+) % A'CB'% D'*//E$.+F);B'%GG4
5 Error: i is 1, not 0, on Test 2
%8'1*// 2'% 3'AA'@4 the first iteration [ 0, 2, 7 ]
5 Failure: none Expected: 1
&0"+)GGB Actual: 0
H
H Error: i is 1, not 0
/.)"/+'&0"+)B Error propagates to the variable count
H Failure: count is 0 at the return statement
Bài tập
Bài tập

Quan sát chương trình ở slide trước và trả lời các câu hỏi
sau:
1. Xác định lỗi (fault) và sửa
2. Chỉ ra 1 test case mà không thực thi fault
3. Chỉ ra 1 test case thực thi không fault nhưng không gây
ra error
4. Chỉ ra 1 test case thực thi fault, gây ra error, nhưng
không gây ra failure
RIP Model

Có 3 điều kiện cần thoả mãn để 1 error có thể quan sát

được (failure)
• Reachability: Vị trí chứa fault trong chương trình cần
được thực thi (reach)
• Infection: Sau khi thực vị trí đó, trạng thái của chương
trình trở nên không đúng
• Propagation: Trạng thái không đúng đó gây ra hành vi
không mong muốn của chương trình
Chúng ta cần “đối mặt” với
lỗi trong chương trình như
thế nào?
Kiểm thử và gỡ lỗi

• Kiểm thử (testing): Đánh giá phần mềm thông qua

thực thi và quan sát các hành vi của nó
• Gỡ lỗi (Debugging): Quá trình tìm lỗi (fault)

• Kiểm thử là một công việc khó

• Gỡ lỗi cũng là một công việc khó
Tại sao kiểm thử lại khó?
The Zune Killer

Đây là 1 đoạn code trong trình chơi nhạc Zune của Microsoft.
Đoạn code này có lỗi không? Nếu có, lỗi ở đâu? Tại sao?
Verification and validation

• Mục tiêu: Đảm bảo phần mềm đáp ứng được nhu
cầu/yêu cầu của khách hàng/người dùng

Verification Validation
Kiểm tra xem phần mềm có Kiểm tra xem phần mềm có
hoạt động đúng không? đáp ứng đúng mong đợi của
(Are we building a product khách hàng không?
right?) (Are we building a right
product?)
Verification and validation

• Verification: Quá trình kiểm tra xem các sản phẩm của
một giai đoạn (phases) trong quy trình phát triển phần
mềm có đáp ứng các yêu cầu đã được thiết lập trong giai
đoạn trước đó hay không.

• Validation: Quá trình đánh giá phần mềm khi kết thúc quy
trình phát triển phần mềm, để đảm bảo phần mềm đáp
ứng đúng mong muốn của khách hàng.
Vấn đề của kiểm thử

• Các hành vi được kiểm thử chỉ là một tập con của tất cả
các hành vi có thể của chương trình
• Các hành vi của chương trình là không liên tục
(discontinuous)
à Thường không thể ngoại suy kết quả của các test
cases chưa được thực thi
• Bản chất của kiểm thử là không đầy đủ (Testing is
incomplete)
Kiểm thử phần mềm
Kiểm thử chương trình

• Là hoạt động chủ chốt nhằm đánh giá chất lượng

• Có thể chỉ ra lỗi, không thể khẳng định không còn lỗi
• Một ca kiểm thử thành công là ca kiểm thử phát hiện ra lỗi
Mục tiêu của kiểm thử

• Chỉ ra rằng phần mềm hoạt động (it does work)

• Chỉ ra rằng phần mềm không hoạt động (it does not work)
• Giảm rủi ro của phần mềm thất bại (reduce the risk of
failure)
• Giảm chi phí kiểm thử (reduce the cost of testing)
Phân tích tĩnh và phân tích động

• Chất lượng phần mềm được cải tiến thông qua chu trình:
Kiểm thử – tìm lỗi – sửa lỗi

• Quy trình này gồm 2 công việc chính:

+ Phân tích tĩnh
- Khảo sát đặc tả, các tài liệu thiết kế, mã nguồn
- Cũng có thể dùng các phương pháp hình thức
+ Phân tích động
- Thực thi chương trình để phát hiện thất bại
Ca kiểm thử

• Một cặp <test input, expected output>

• Ví dụ: hàm add(int a, int b), thực hiện cộng hai tham số
đầu vào và trả về tổng của chúng
T1 = <(0, 1), 1>
T2 = <(1, 2), 3>
• Test report

ID Test input Expected System output Test

output result
T1
T2
T3
Các hoạt động kiểm thử

Xác định Điều kiện kiểm thử (“Cái gì”): Một phần tử hoặc sự
kiện cần kiểm tra

Thiết kế Làm thế nào để có thể kiểm tra được: thực hiện

Xây dựng Xây dựng ca kiểm thử

Chạy Chạy hệ thống

So sánh So sánh kết quả của hệ thống và kết quả mong đợi

Kết quả kiểm thử

Kiểm thử trong mô hình chữ V
Kiểm thử hồi quy - regression testing

• Khi hệ thống có một chỉnh sửa (sửa lỗi, thêm/bớt chức

năng,…) toàn bộ bộ kiểm thử cần phải chạy lại
- Đảm bảo các tính năng đang hoạt động tốt không bị ảnh hưởng
bởi chỉnh sửa
• Không phải là một mức kiểm thử riêng biệt, mà là một phần
của kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ
thống
Khi nào nên dừng kiểm thử?

• Hết thời gian, hết ngân sách

• Đạt mức độ bao phủ mong muốn
• Đạt tần suất hỏng hóc mong muốn
Bài toán kiểm thử qua biểu đồ ven
Các hành vi của chương trình

S P
Sai lầm về nhiệm
Sai lầm về bỏ vụ: Hành vi được
quên: Hành vi lập trình mà không
được đặc tả nhưng được đặc tả
không được lập
trình

Đặc tả
(Mong đợi) Chương trình
(Thực tế)

Phần đúng đắn

Kiểm thử hộp đen

• Kiểm thử hàm, kiểm thử chức năng

• Chương trình được coi như một hộp đen, chỉ quan tâm
đến đầu vào và đầu ra của chương trình
• Test input được lựa chọn từ đặc tả của chương trình và
các tính chất của miền đầu vào và đầu ra
• Testers chỉ quan tâm đến các chắc năng và tính năng
được mô tả trong đặc tả
Kiểm thử hộp trắng

• Kiểm thử cấu trúc, kiểm thử logic

• Kiểm tra mã nguồn dựa trên luồng dữ liệu và luồng điều
khiển
Công cụ kiểm thử

• Kiểm thử là một công việc tốn kém (cần nhiều lao động)
nhất của quá trình phát triển phần mềm
- Test cases thường được tạo ra một cách thủ công
- Kết quả kiểm thử được phân tích thủ công

• Có nhiều công cụ hỗ trợ: static code analyzer, test data

generator, network analyzer…

Note: Không kiểm thử thì chi phí phát triển phần mềm
còn đắt đỏ, tốn kém hơn nữa
Nhiều công cụ hỗ trợ các loại kiểm thử

• Kiểm thử đơn vị: Achoo, Junit, Pex/Moles, PyUnit

• Tự động kiểm thử: TestComplete
• Kiểm thử hiệu năng và tải: Jmeter
• Kiểm thử giao diện đồ hoạ: Abbot, Guitar
• Kiểm thử tổ hợp: AETG, FireEye
• Kiểm thử dựa trên mô hình: Spec Explorer
• Phân tích bao phủ: Corbertura
• Quản lý lỗi (defects): Bugzilla