Kiểm thử phần mềm

Đại cương về kiểm thử phần mềm

Các mức độ kiểm thử
 Kiểm thử phần mềm
Đại cương về kiểm thử phần mềm
Các mức độ kiểm thử
Đại cương về kiểm thử phần mềm
Xác minh (verification) và thẩm định (validation):
Xác minh là quá trình xem xét phần mềm được thực hiện có đúng
đặc tả hay không, có đúng thiết kế không, và phát hiện lỗi chương
trình.

Thẩm định là dãy các hoạt động để đảm bảo cho phần mềm được
xây dựng theo nhu cầu người dùng, hoạt động hiệu quả và nhằm
phát hiện lỗi phân tích, lỗi thiết kế.
Đại cương về kiểm thử phần mềm
Xác minh (verification) và thẩm định (validation):
Thẩm định/xác minh tĩnh (kiểm tra - software inspection),
lúc này chúng ta không thực hiện chương trình mà chỉ xét
duyệt yêu cầu, thiết kế, mã nguồn. Quá trình này được tiến
hành ở mọi công đoạn phát triển. Tuy nhiên phương pháp
này khó đánh giá tính hiệu quả của sản phẩm.
Đại cương về kiểm thử phần mềm
Xác minh (verification) và thẩm định (validation):
Thẩm định/xác minh động (kiểm thử – software testing),
lúc này chúng ta cần thực hiện chương trình. Việc kiểm
thử cần có mã nguồn, nhằm phát hiện lỗi lập trình và đánh
giá tính hiệu quả phần mềm. Đây là cách duy nhất để kiểm
tra các yêu cầu phi chức năng.
Đại cương về kiểm thử phần mềm
Xác minh (verification) và thẩm định (validation):
Thẩm định/xác minh tĩnh (kiểm tra - software inspection),
lúc này chúng ta không thực hiện chương trình mà chỉ xét
duyệt yêu cầu, thiết kế, mã nguồn. Quá trình này được tiến
hành ở mọi công đoạn phát triển. Tuy nhiên phương pháp
này khó đánh giá tính hiệu quả của sản phẩm.
Đại cương về kiểm thử phần mềm
Kiểm thử phần mềm là gì?
Theo IEEE: Kiểm thử là tiến trình vận hành hệ thống hoặc thành phần
của hệ thống dưới những điều kiện xác định, quan sát hoặc ghi nhận
kết quả và đưa ra các đánh giá về hệ thống hoặc thành phần đó.

Theo Myers[the art of software testing]: Kiểm thử là tiến trình vận hành
chương trình với mục đích tìm thấy lỗi.

=> kiểm thử là tổ chức, vận hành phần mềm một cách có kế hoạch và
phương pháp để tìm ra lỗi.
Đại cương về kiểm thử phần mềm
Khái niệm cơ bản:
Sai sót (error): là một sự nhầm lẫn hay một sự thiếu sót của người phát triển
trong quá trình phát triển phần mềm.

Lỗi (fault, defect): Lỗi xuất hiện trong chương trình là kết quả của một sai sót.

Hỏng hóc (failure): là kết quả của một hoặc một số lỗi. Chúng làm cho chương
trình không hoạt động được hoặc nếu hoạt động được thì cho ra kết quả không
như mong đợi.
Đại cương về kiểm thử phần mềm
Khái niệm cơ bản:
Dữ liệu thử (test data): là các dữ liệu đầu vào cung cấp cho chương trình trong khi thực thi.
Kịch bản kiểm thử (test scenario): là các bước thực hiện khi tiến hành kiểm thử.
Phán xét kiểm thử (test oracle): là hoạt động nhằm đánh giá kết quả kiểm thử. Hoạt động
này có thể tiến hành tự động bằng chương trình máy tính hoặc tiến hành thủ công bởi con
người.
Kiểm thử viên (tester): là người tiến hành hoạt động kiểm thử.
Ca kiểm thử (test case): Một ca kiểm thử bao gồm:
•Tập dữ liệu thử.
•Điều kiện thực thi.
•Kết quả mong đợi.
Đại cương về kiểm thử phần mềm
Đại cương về kiểm thử phần mềm
Mục tiêu của kiểm thử:
Xác định được mức độ phần mềm đáp ứng được các yêu cầu (độ tin cậy) và tìm
ra lỗi (nếu có) với chi phí thấp nhất.

Quá trình kiểm thử phần mềm là tốt khi:

+ Có khả năng tìm ra lỗi cao.

+ Không dư thừa.

+ Biết chọn lọc: chỉ kiểm thử những phần nào có khả năng tìm ra lỗi đặc trưng.

+ Không quá phức tạp cũng không quá đơn giản.

Đại cương về kiểm thử phần mềm
Yêu cầu đối với kiểm thử:
+ Tính lặp lại
- Kiểm thử phải lặp lại được (kiểm tra xem lỗi đã được sửa hay chưa)
- Dữ liệu/trạng thái phải mô tả được
+ Tính hệ thống
- Đảm bảo kiểm tra hết các trường hợp
+ Được lập tài liệu
- Kiểm soát tiến trình/kết quả
Đại cương về kiểm thử phần mềm
Các mức độ kiểm thử
Đại cương về kiểm thử phần mềm
Các mức độ kiểm thử
Đại cương về kiểm thử phần mềm
Các mức độ kiểm thử
Trong môi trường của phía phát triển:
•Kiểm thử đơn vị.
•Kiểm thử tích hợp.
•Kiểm thử hệ thống phần mềm
•Kiểm thử chấp nhận
Trong môi trường của phía khách hàng
•Kiểm thử alpha
•Kiểm thử beta
•Kiểm thử hệ thống thông tin
Các giai đoạn kiểm thử
Các giai đoạn kiểm thử
Phía khách hàng:
Kiểm thử alpha: là việc kiểm thử chấp nhận được tiến hành ở môi trường
khách hàng. Quá trình này được tiến hành ngay tại nơi sản xuất phần mềm.
Nhà phát triển phần mềm sẽ quan sát người sử dụng sản phẩm và ghi nhận lại
những lỗi phát sinh để sửa chữa.

Kiểm thử beta: là sự mở rộng của kiểm thử Alpha, thường được tiến hành với
một lượng lớn người sử dụng. Phần mềm được kiểm tra bên ngoài phạm vi của
đơn vị sản xuất. Người sử dụng tiến hành kiểm thử không có sự hướng dẫn của
người phát triển và thông báo lại kết quả cho người phát triển.
Kiểm thử hệ thống
Kiểm thử hệ thống là một sự mở rộng phạm vi kiểm thử, nhìn
nhận phần mềm như một yếu tố trong một hệ thống phức tạp.
Các loại kiểm thử hệ thống
1. Kiểm thử chức năng (mức hệ thống)
2. Kiểm thử phục hồi (chịu lỗi)
3. Kiểm thử an ninh (sức chịu được tấn công)
4. Kiểm thử thi hành (thông suốt, kịp thời)
5. Kiểm thử chịu tải (quy mô, giá trị nhạy cảm)
Các hoạt động kiểm thử
Các phương pháp kiểm thử
Kiểm thử chức năng (functional testing): là
phương pháp kiểm thử dựa trên đặc tả
chức năng, nhằm phát hiện các sai sót về
chức năng mà không quan tâm nhiều đến
cách cài đặt (phương pháp kiểm thử hộp
đen – bkack box testing).
Các phương pháp kiểm thử
Kiểm thử cấu trúc (structured testing) là phương pháp
có nghiên cứu đến mã nguồn nhằm phân tích thứ tự
thực hiện các lệnh thực thi trong phần mềm (phương
pháp kiểm thử hộp trắng – white box testing).
Kiểm thử hộp đen là phương pháp kiểm tra các chức
năng cụ thể của phần mềm, không quan tâm cấu trúc
bên trong. Mức kiểm thử là module, hệ con.
Các phương pháp kiểm thử
Kiểm thử cấu trúc (structured testing) là phương
pháp có nghiên cứu đến mã nguồn nhằm phân
tích thứ tự thực hiện các lệnh thực thi trong phần
mềm (phương pháp kiểm thử hộp trắng – white
box testing).
Kiểm thử hộp trắng là phương pháp kiểm tra cấu
trúc điều khiển bên trong chương trình. Mức kiểm
thử là đơn vị.
Các chiến lược kiểm thử
Quá trình kiểm thử bao gồm các công việc:
+ Lập kế hoạch kiểm thử.
+ Sinh test-case.
+ Thực hiện kiểm thử, thu thập kết quả và đánh
giá.
+ Tích hợp các module.
Các chiến lược kiểm thử
Quá trình kiểm thử bao gồm các công việc:
+ Lập kế hoạch kiểm thử.
+ Sinh test-case.
+ Thực hiện kiểm thử, thu thập kết quả và đánh
giá.
+ Tích hợp các module.
Mô hình chữ V
Kiểm thử từng module
Kiểm thử trên từng đơn vị nhỏ nhất của phần
mềm, đó là module mã nguồn, sau khi đã thiết
kế, mã hoá và biên dịch thành công.
Dùng kiểm thử hộp trắng.
Có thể liên quan đến module khác -> tốn chi
phí.
Kiểm thử tích hợp
Kiểm thử tích hợp để phát hiện lỗi liên
quan đến giao tiếp giữa các module.
Tích hợp tăng dần theo hướng từ trên
xuống hoặc từ dưới lên.
Kiểm thử tích hợp từ trên xuống
Kiểm thử tích hợp từ dưới lên
Kiểm thử hồi quy
Việc kết hợp các module lại với nhau có thể
ảnh hưởng đến vòng lặp điều khiển, cấu
trúc dữ liệu hay dữ liệu vào/ra chia sẻ trong
một số module. Điều đó làm lộ ra một số lỗi
không thể phát hiện được khi tiến hành
kiểm thử theo đơn vị.
Việc kiểm thử lặp lại các module ta gọi là
kiểm thử hồi quy.
Kiểm thử tính năng
Kiểm thử các chức năng của phần mềm
đáp ứng được nhu cầu của khách hàng vốn
đã được xác định trong văn bản đặc tả yêu
cầu của phần mềm hay không.
Thường áp dụng kỹ thuật kiểm thử hộp đen
cho bước kiểm thử này.
Kỹ thuật kiểm thử
Thiết lập test case.
Phân hoạch tương đương.
Đường đi trong module.
….
Thiết lập test case
Một ca kiểm thử (test-case) bao gồm:
+ 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, hệ điều hành để
thực thi hệ thống, ...
- Thứ tự thao tác (khi kiểm thử giao diện).
Thiết lập test case
Một ca kiểm thử (test-case) bao gồm:
+ Thao tác kiểm thử.
+ 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ế.
Thiết lập test case
Test-case cho kiểm thử hộp đen: chủ yếu dựa
vào các yêu cầu cụ thể của chức năng phần
mềm.
Test-case cho kiểm thử hộp trắng: chủ yếu dựa
vào cấu trúc điều khiển của phần mềm do đó
vấn đề đặt ra: số lượng test-case cần thiết là quá
lớn.
Phân hoạch tương đương
Ví dụ: Với hàm tính trị tuyệt đối, chúng ta có thể
phân hoạch các miền tương đương để kiểm thử
là:
- Miền dữ liệu là các số bằng 0
- Miền dữ liệu là các số bé hơn 0
- Miền dữ liệu là các số lớn hơn 0
Đường đi trong module
Đường đi là thứ tự thực hiện các lệnh từ điểm
bắt đầu đến điểm kết thúc của module.
Cách xác định đường đi như sau:
+ Đánh số các khối lệnh
- Đánh số các khối lệnh, câu lệnh điều kiện
- Đánh số các hợp điểm của luồng lệnh
Đường đi trong module
+ Rút gọn
- Các khối tuần tự được tích hợp thành một khối.
- Tích hợp khối tuần tự vào câu lệnh điều kiện kế
tiếp.
Đường đi trong module
Đường đi độc lập
Do không thể chọn mọi đường đi để kiểm thử, vì vậy
cần chọn các đường đi độc lập. Ở đây đường đi độc
lập được hiểu là đường đi có ít nhất một cặp khối lệnh
(một cạnh của đồ thị) và chưa xuất hiện trong các
đường đi đã có.
Đường đi độc lập là một tập hợp thỏa mãn:
- Mọi khối lệnh đều được thực hiện ít nhất một lần
- Mọi điều kiện đều được kiểm thử với hai trường hợp
true và false.
Đường đi độc lập
Xây dựng đồ thị dòng chảy
Mỗi node của đồ thị hình tròn biểu diễn một
hoặc một vài tác vụ. Cạnh có hướng miêu
tả đường thực thi. Đồ thị dòng chảy được
xây dựng từ lưu đồ thuật giải.
Xây dựng đồ thị dòng chảy
Xây dựng đồ thị dòng chảy
Liệt kê các đường đi độc lập cơ bản
Từ node bắt đầu đến node kết thúc, các đường thực
thi cơ bản được liệt kê theo một thứ tự nào đó để đảm
bảo rằng: đường đang liệt kê ít nhất đi qua một cạnh
chưa được duyệt qua bởi các đường đã liệt kê trước
đó.
Tổng số đường thực thi cơ bản độc lập nhau được tính
bằng: V = P + 1; trong đó P là số node phân nhánh
(predicate).
Liệt kê các đường đi độc lập cơ bản
Thiết lập một test-case cho mỗi đường thực thi
cơ bản. Dựa vào thuật giải để tìm ra một dữ liệu
input, sau đó tính ra dữ liệu output hay các đáp
ứng mong đợi của thuật giải.
Chú ý: có thể không tạo ra được test-case cho
một đường thực thi nào đó.
Thiết lập các test case
Kiểm thử gây áp lực
Đối với một số hệ thống quan trọng, người ta
còn tiến hành thử nghiệm gây áp lực (stress
testing). Đây là loại (bước) thử nghiệm được tiến
hành khi đã có phiên bản làm việc, nhằm tìm
hiểu hoạt động của hệ thống trong các trường
hợp tải trọng lớn (dữ liệu lớn, số người sử dụng
lớn, tài nguyên hạn chế...).
Kiểm thử gây áp lực
Mục đích của thử nghiệm áp lực là:
- Tìm hiểu giới hạn chịu tải của hệ thống
- Tìm hiểu về đặc trưng của hệ thống khi đạt và vượt
giới hạn chịu tải (khi bị sụp đổ)
Ngoài ra thử nghiệm áp lực còn nhằm xác định các
trạng thái đặc biệt như tổ hợp một số điều kiện dẫn
đến sự sụp đổ của hệ thống; tính an toàn của dữ liệu,
của dịch vụ khi hệ thống sụp đổ.
Trắc nghiệm
Kiểm thử Black-box cố gắng tìm ra những lỗi
a.Chức năng không đầy đủ hay không đúng
b.Những lỗi giao diện
c.Những lỗi thực thi
d.Tất cả mục trên
Trắc nghiệm
Kiểm thử lặp là một kỹ thuật kiểm thử cấu trúc điều
khiển mà những tiêu chuẩn dùng để thiết kế test-case
a.Dựa vào kiểm thử đường cơ bản
b.Thử thách điều kiện logic trong module phần mềm
c.Chọn những đường dẫn kiểm tra dựa vào những vị
trí và dùng những biến
d.Tập trung vào việc kiểm thử việc giá trị những cấu
trúc lặp
Trắc nghiệm
Kiểm thử điều kiện là một kỹ thuật kiểm thử cấu trúc điều
khiển mà những tiêu chuẩn dùng để thiết kế test-case
a.Dựa vào kiểm thử đường cơ bản
b.Thử thách điều kiện logic trong module phần mềm
c.Chọn những đường dẫn kiểm tra dựa vào những vị trí và
dùng những biến
d.Tập trung vào việc kiểm thử việc giá trị những cấu trúc
lặp