Bài giảng môn học Công nghệ phần mềm

Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
KIỂM NGHIỆM TỪNG MODULE (t.t)
Module
……….
~~~~~~
~~~~~~
~~~~~~
interface
local data structures
boundary conditions
independent paths
error handling paths
test-
cases
driver
stub stub

Mỗi module mã nguồn không phải là một chương trình hoàn chỉnh 
và đôi khi phải gọi các module chưa được kiểm nghiệm khác 
 có 
thể phải thiết lập driver và/hoặc stub: phí tổn khá lớn (70%)

 Driver là một chương trình chính có nhiệm vụ nhận dữ liệu kiểm 
nghiệm, chuyển dữ liệu đó xuống cho module để kiểm tra và in ra 
các kết quả kiểm tra tương ứng.

 Stub thay thế các module được gọi bởi module đang kiểm tra.
- Trang 265 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
KIỂM NGHIỆM TỪNG MODULE (t.t)
KIỂM NGHIỆM TÍCH HỢP

 Từng module mã nguồn đã hoạt động đúng. Liệu khi kết hợp 
chúng lại thành một nhóm lớn chúng có hoạt động đúng không ?

 Phải tiến hành kiểm nghiệm tích hợp để phát hiện lỗi liên quan 
đến giao tiếp giữa các module.

 Tránh tích hợp kiểu big-bang: tất cả các module được kết hợp lại, 
và toàn bộ chương trình sẽ được kiểm nghiệm một lúc

 Nên tích hợp tăng dần: từ trên xuống hoặc từ dưới lên
- Trang 266 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
TÍCH HỢP TỪ TRÊN XUỐNG

Module chính được dùng như là driver, và stub được thay thế bởi 
các module con trực tiếp của của module chính này.

 Tuỳ thuộc vào cách tích hợp theo chiều sâu (depth-first) hoặc 
chiều ngang(breath-first), mỗi stub con được thay thế một lần bởi 
module tương ứng đã kiểm nghiệm.

 Tiến hành kiểm nghiệm khi có sự thay thế mới

 Tiến hành kiểm nghiệm hồi quy để phát hiện các lỗi khác trong 
từng module
- Trang 267 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
M1
M3 M4
M7
M2
M5 M6
M8 Tích hợp kiểu từ trên xuống theo hình thức depth-first
- Trang 268 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
TÍCH HỢP TỪ TRÊN XUỐNG (t.t)
- Trang 269 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
TÍCH HỢP TỪ DƯỚI LÊN

 Các module mức thấp nhất được kết hợp thành các nhóm thể hiện 
một chức năng con đặc biệt của phần mềm.

Một driver được tạo ra để thao tác các test-case

 Nhóm module được kiểm nghiệm.

 Driver được bỏ đi và các nhóm module được kết hợp dần lên phía 
trên trong sơ đồ phân cấp của chương trình.
Mo
Ma Mb
D2D1 D3
cl
us
te
r 1
cluster 2
c
l
u
s
t
e
r
3
- Trang 270 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
TÍCH HỢP TỪ DƯỚI LÊN (t.t)
KIỂM NGHIỆM 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 I/O 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 nghiệm theo đơn vị

 Kiểm nghiệm hồi quy có thể được tiến hành thủ công bằng cách 
thực hiện lại các test-case đã tạo ra. Hoặc có thể dùng một công cụ 
capture-playback để thực hiện tự động
- Trang 271 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
KIỂM NGHIỆM TÍNH NĂNG

 Kiểm nghiệm tính năng hiểu theo cách đơn giản nhất là: 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

 Áp dụng kỹ thuật black-box

 Kiểm nghiệm tính năng bao gồm

 Xem xét lại cấu hình phần mềm

 Kiểm nghiệm alpha

 Kiểm nghiệm beta
- Trang 272 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm

 Kiểm nghiệm alpha

 Đượ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 nghiệm beta

 Phần mềm được kiểm tra bên ngoài phạm vi của đơn vụ sản xuất.

 Khách hành trực tiếp sử dụng và ghi nhận lỗi để báo lại cho nhà phát 
triển sửa chữa.
- Trang 273 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
KIỂM NGHIỆM TÍNH NĂNG (t.t)
KIỂM NGHIỆM HƯỚNG ĐỐI TƯỢNG

 Về cơ bản chiến thuật kiểm nghiệm hướng đối tượng cũng theo 
thứ tự giống như kiểm nghiệm cổ điển: 
kiểm nghiệm đơn vị - kiểm nghiệm tích hợp - kiểm nghiệm chức 
năng -kiểm nghiệm toàn bộ hệ thống
- Trang 274 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
KIỂM NGHIỆM ĐƠN VỊ HƯỚNG ĐT

 Không thể tách rời từng tác vụ của đối tượng/lớp để kiểm 
nghiệm

 Tác vụ được đóng bao trong lớp

 Các lớp con có thể override một tác vụ nào đó

 Kiểm nghiệm đơn vị hướng đối tượng tập trung vào các lớp 

kiểm nghiệm hành vi của lớp 
- Trang 275 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
KIỂM NGHIỆM TÍCH HỢP HƯỚNG ĐT

 Khái niệm sơ đồ phân cấp không còn nhiều ý nghĩa trong
chương trình hướng đối tượng 
 kiểm nghiệm tích hợp theo cách 
khác

 Hai hình thức kiểm nghiệm tích hợp hướng đối tượng

 Kiểm nghiệm trên cơ sở thread: tích hợp các lớp tạo thành một thread 
để phục vụ cho một input nào đó của chương trình

 Kiểm nghiệm trên cơ sở sử dụng: các lớp client sẽ được tích hợp để sử 
dụng dịch vụ nào đó cung cấp bởi các lớp server
- Trang 276 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
KIỂM NGHIỆM THEO KỊCH BẢN

 Dựa vào các use-case để soạn ra các kịch bản

 Ví dụ: một kịch bản cho hệ thống đăng ký môn học qua WEB
1. Login với username = “e59306547”, password = “6547”
2. Chọn chức năng đăng ký môn học
3. Chọn 5 nhóm môn học của 5 môn: CNPM, AI, XLTHS, PTTK, XLSS 
trong đó có 2 nhóm trùng thời khoá biểu
4. Nhấn nút Submit 
Chương trình phải báo lỗi và liệt kê 2 nhóm bị trùng thời khoá biểu 
- Trang 277 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
NGHỆ THUẬT GỠ RỐI

 Gỡ rối là một quá trình nhằm loại bỏ các lỗi được phát hiện 
trong quá trình kiểm tra.

 Gỡ rối được thực hiện như là một kết quả của việc kiểm tra: lỗi 
phát hiện được 
 tìm kiếm nguyên nhân 
 sửa lỗi

 Có 3 hình thức gỡ rối: brute force, loại trừ nguyên nhân và theo 
vết. Nên dùng kết hợp cả 3 hình thức này.
- Trang 278 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
NGHỆ THUẬT GỠ RỐI (t.t)

 Gỡ rối là công việc khó khăn và dễ gây 
tâm lý chán nản bởi nguyên nhân gây ra lỗi 
nhiều khi lại mơ hồ: do time-out, do độ chính 
xác, do chủ quan lập trình...

 Khả năng gỡ rối gần như là bẩm sinh của 
mỗi người
- Trang 279 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
BRUTE FORCE

 Là phương pháp phổ biến nhất nhưng lại ít hiệu quả nhất cho việc 
phát hiện nguyên nhân gây lỗi phần mềm. 

 Triết lý của phương pháp này là: “Hãy để máy tính tìm ra lỗi”.

 Có 3 cách thực hiện:

 Lấy dữ liệu trong bộ nhớ để xem xét.

 Dùng run-time trace để tìm lỗi.

 Dùng lệnh WRITE để xuất dữ liệu cần kiểm tra ra màn hình.

 Áp dụng phương pháp này khi tất cả các phương pháp khác đều 
thất bại. 
- Trang 280 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
LOẠI TRỪ NGUYÊN NHÂN

 Phương pháp này dựa trên nguyên tắc phân chia nhị phân.

 Cách thực hiện:

 Khi một lỗi được phát hiện, cố gắng đưa ra một danh sách các nguyên 
nhân có thể gây ra lỗi.

 Danh sách này được nghiệm lại để loại bỏ dần các nguyên nhân không 
đúng cho đến khi tìm thấy một nguyên nhân khả nghi nhất.

 Khi đó dữ liệu kiểm nghiệm sẽ được tinh chế lại để tiếp tục tìm lỗi.
- Trang 281 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
THEO VẾT

 Là một phương pháp gỡ lỗi khá phổ biến có thể dùng thành 
công trong các chương trình nhỏ nhưng khó áp dụng cho đối với 
các chương trình rất lớn.

 Cách thực hiện: bắt đầu tại dòng mã nguồn có triệu chứng lỗi 
thực hiện lần ngược trở lại từng dòng mã nguồn cho đến khi tìm 
thấy dòng gây ra lỗi.
- Trang 282 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm - Chương 10: Chiến thuật kiểm nghiệm phần 
mềm
KẾT THÚC MÔN HỌC
- Trang 283 -
Khoa Công Nghệ Thông Tin - Môn Công Nghệ Phần Mềm
Thi cuối kỳ ?
Phân tích - Thiết kế -
Hiện thực/triển khai -
Kiểm nghiệm -UML

 Tất cả nội dung
i cuối kỳ 
Phân tích - Thiết kế -
Hiện thực/triển khai -
iể nghiệ - L
Tất cả nội dung
Chúc mừng bạn đã hoàn tất môn học 
Công Nghệ Phần Mềm !