Bài giảng Kiểm thử phần mềm: Chương 4 - TS. Nguyễn Thanh Hùng

Trường Đại Học Bách Khoa Hà Nội

Viện Công Nghệ Thông Tin &Truyền Thông

Kiểm thử phần mềm
Các quá trình kiểm thử
TS. Nguyễn Thanh Hùng
Bộ Môn Công Nghệ Phần Mềm
Email:
Website: />
CuuDuongThanCong.com

/>

Chiến lược kiểm thử
 Bắt đầu từ module level cho đến lúc tích hợp
thành hệ thống trọn vẹn
 Các kỹ thuật kiểm thử khác nhau thích hợp tạo
các thời điểm khác nhau
 Kiểm thử được kiểm soát bởi các developers và
các nhóm kiểm thử độc lập
 Kiểm thử và gỡ lỗi là các hoạt động khác nhau,
nhưng gỡ lỗi phải được thích ứng trong chiến
lược kiểm thử

CuuDuongThanCong.com

/>

Sự thích ứng của chiến lược kiểm thử
Chiến lược cần thích ứng với từng mức

kiểm thử:
 Kiểm thử mức thấp: xác minh từng đoạn mã
nguồn có tương ứng và thực thi đúng đắn
không?
 Kiểm thử mức cao: xác minh và thẩm định
các chức năng hệ thống chủ yếu có đúng đặc
tả và đáp ứng yêu cầu của khách hàng
không?

3
CuuDuongThanCong.com

/>

Sự đáp ứng của chiến lược kiểm thử
Mỗi chiến lược đáp ứng được yêu cầu
người quan tâm:
 Có các hướng dẫn cho người thực hiện tiến
hành kiểm thử
 Có các cột mốc cho các nhà quản lý kiểm
soát hoạt động đảm bảo chất lượng
 Có thước đo để có thể nhận ra các vấn đề
càng sớm càng tốt và khách hàng nhận biết
được quá trình kiểm thử

4
CuuDuongThanCong.com

/>

Tổ chức kiểm thử
Kiểm thử phần mềm là một phần của
hoạt động “Xác minh và thẩm định”
 Xác minh là một tập các hoạt động để đảm
bảo rằng: phần mềm thực hiện đúng chức
năng đã được đặc tả
 Thẩm định là một tập hợp các hoạt động để
đảm bảo rằng: phần mềm đã đáp ứng đúng
các yêu cầu của khách hàng
 Câu hỏi: Ai làm? Làm cái gì? Khi nào? Và mối
quan hệ
5
CuuDuongThanCong.com

/>

Trách nhiệm kiểm thử phần mềm
Các kỹ sư phần mềm làm ra phần mềm.
Một cách tự nhiên họ cần tiến hành các
kiểm thử ban đầu. Về nguyên tắc, người
làm sản phẩm, kiểm tra sản phẩm là
không hợp lý.
Có một số hiểu lầm:
 Người phát triển không tham gia kiểm thử
 Cho phép người lạ kiểm thử một cách tàn
nhẫn
 Người kiểm thử chỉ quan tâm khi kiểm thử bắt
đầu
6
CuuDuongThanCong.com

/>

Phân công trách nhiệm kiểm thử
Từ thực tiễn dẫn đến sự phân công:
 Người phát triển chỉ trách nhiệm kiểm thử
đơn vị do mình phát triển để đảm bảo thực
hiện đúng thiết kế (một yêu cầu của xác minh)
 Người phát triển có thể tham gia kiểm thử tích
hợp
 Nhóm kiểm thử độc lập bắt đầu làm việc khi
các khoản mục cấu trúc phần mềm đã đầy đủ

7
CuuDuongThanCong.com

/>

Vai trò của người kiểm thử
 Nhóm kiểm thử độc lập giúp gỡ bỏ những thành
kiến cố hữu: “người xây dựng không thể kiểm thử
sản phẩm tốt”
 Gỡ bỏ mâu thuẫn giữa những người tham gia
 Đánh giá công sức phát triển bỏ ra tìm lỗi
 Nhóm kiểm thử độc lập tạo ra báo cáo đầy đủ
cho tổ chức đảm bảo chất lượng phần mềm
 Người phát triển
 Không đẩy chương trình cho người kiểm thử rồi
bỏ đi
 Cùng làm việc với người kiểm thử xuyên suốt

một dự án (bảo đảm việc kiểm thử được tiến
hành triệt để)
8
CuuDuongThanCong.com

/>

Tiến trình thực hiện kiểm thử
Tiến trình thực hiện kiểm thử tương ứng
với tiến trình phát triển (theo từng mô
hình)
Tiến trình kiểm thử thông thường (mô
hình chữ V)

9
CuuDuongThanCong.com

/>

Kiểm thử đơn vị
Nội dung kiểm thử:
 Giao diện
 Cấu trúc dữ liệu sử dụng cục bộ
 Đường điều khiển
 Điều kiện logic
 Phép toán xử lý

10
CuuDuongThanCong.com

/>

Kiểm thử đơn vị
Câu hỏi
 Định lượng/dạng gì (biến, module qua giao
diện)
 Yếu tố nào cần (vào/ra dữ liệu)?
 Sai xử lý, logic (phép toán, biểu thức)?
 Sai điều khiển (vòng lặp, giá trị biên)?
 Sai tiềm ẩn (ghi chép, mô tả)?

11
CuuDuongThanCong.com

/>

Kiểm thử dữ liệu qua giao diện
 Kiểm thử dòng dữ liệu
qua một giao diện của
module liên quan đến
định lượng và định
dạng của các biến và
các module sử dụng
trên giao diện.
 Đặc trưng cụ thể:
 Số lượng?
 Định dạng?

12
CuuDuongThanCong.com

/>

Đặc trưng dữ liệu qua giao diện
 Các đặc trưng qua giao diện là:
 Số tham số = số đối số?
 Tính chất của tham số = tính chất của
đối số?
 Đơn vị của tham số = đơn vị của đối
số?
 Số đối được truyền gọi module = số các
tham số đầu vào của module?
 Thuộc tính các đối được truyền gọi
module = thuộc tính của tham số?
 Đơn vị của đối được truyền để gọi
module = đơn vị các tham số module
13
CuuDuongThanCong.com

/>

Kiểm thử liên quan đến vào ra
Khi thực hiện I/O cần tiến hành thêm:
 Tính chất của file có đúng đắn hay không?
 Các câu lệnh OPEN/CLOSE có đúng đắn
không?
 Đặc tả hình thức có đúng với các câu lệnh I/O
 Cỡ của buffer có đúng với cỡ của bản ghi
không?
 Các file có mở trước khi sử dụng không?

 Các điều kiện end-of-file có được xử lý?
 Các sai lầm I/O có được xử lý?
 Có văn bản nào trong thông tin ra?
CuuDuongThanCong.com

/>

Kiểm thử cấu trúc dữ liệu cục bộ
Cấu trúc dữ liệu cục bộ cho module có thể sai.
Vì thế thiết kế các kiểm thử cần làm lộ ra các
loại lỗi sau:
 Giá trị ngầm định hoặc giá trị khởi tạo sai
 Tên các biến không đúng
 Kiểu dữ liệu không nhất quán
 Ngoại lệ về địa chỉ, overflow, …

CuuDuongThanCong.com

/>

Kiểm thử về các xử lý

Các sai về trình tự, độ chính xác là:
 Thứ tự ưu tiên các phép tính số học
 Sự nhất quán của các phép toán
trộn
 Khởi tạo/kết thúc không đúng đắn
 Sự chính xác của kết quả

CuuDuongThanCong.com

/>

Kiểm thử các điều kiện logic
 Các sai kiểu, toán tử, ngữ nghĩa:
 So sánh các kiểu dữ liệu khác nhau
 Ưu tiên hoặc toán tử logic không đúng đắn
 Dự đoán một biểu thức so sánh, trong khi sai số làm cho
đẳng thức không chắc có thực
 Các giá trị so sánh không đúng đắn

CuuDuongThanCong.com

/>

Kiểm thử dòng điều khiển/biên
Các sai biến lặp, số vòng lặp
 Vòng lặp không kết thúc hoặc kết
thúc không chính xác
 Sự lặp phân kỳ khó thoát được
 Các biến lặp bị cải biên không chính
xác
Sai ở các biên
 Kiểm thử biên là nhiệm vụ cuối cùng
của bước kiểm thử đơn vị. Phần
mềm thường thất bại tại các biên của
chúng
18
CuuDuongThanCong.com

/>

Kiểm thử sai tiềm ẩn
Các sai tiềm ẩn cần được đánh giá là:
 Mô tả sai (khó hiểu)
 Dữ liệu ghi không tương ứng với sai đã gặp
 Điều kiện sai có trước khi xử lý sai
 Xử lý điều kiện ngoại lệ là không đúng đắn
 Mô tả sai không cung cấp đủ thông tin để trợ
giúp định vị nguyên nhân sai

19
CuuDuongThanCong.com

/>

Thủ tục kiểm thử đơn vị
Sau khi mã nguồn được phát triển, rà soát
và kiểm tra tính đúng đắn cú pháp (thanh
tra), thiết kế ca kiểm thử đơn vị bắt đầu
Kiểm thử đơn vị là phần phụ thêm của mã
hoá
Kết quả rà soát thiết kế cung cấp các chỉ
dẫn để thiết lập các ca kiểm thử nhằm bộc
lộ sai trong mỗi loại đã nêu
Mỗi ca kiểm thử phải gắn với một tập các
kết quả mong đợi.
20
CuuDuongThanCong.com

/>

Kỹ thuật kiểm thử đơn vị
Module không phải là chương trình cô lập,
nên cần phát triển các phần mềm bộ lái
và/hoặc cuống cho kiểm thử đơn vị
Bộ lái (driver) là một hàm “main” điều
khiển việc đưa dữ liệu vào và nhận kết
quả ra của module
Cuống (stub) dùng để thay cho các
module là thứ cấp của nó

21
CuuDuongThanCong.com

/>

Kỹ thuật kiểm thử đơn vị

22
CuuDuongThanCong.com

/>

Kỹ thuật kiểm thử đơn vị
Một cuống (stub) hoặc “dummy program”
dùng các giao diện của module thứ cấp:
làm được các thao tác tối thiểu, kiểm
chứng đầu vào và giá trị trả về.
Bô lái và cuống cần chi phí hành chính.

Chúng cần viết ra nhưng không được phân
phối kèm với sản phẩm cuối cùng
Chi phí hành chính thấp nếu đơn giản,
nhưng không may đa số là cao, khi đó
người ta hoãn kiểm thử đầy đủ cho tới
bước kiểm thử tích hợp
23
CuuDuongThanCong.com

/>

JUnit
JUnit:
 Framework mã nguồn mở Unit Test cho Java
()
• Cung cấp các test drivers cho kiểm thử đơn vị
• Cung cấp kiểm thử tử động
• Cung cấp kiểm tra kết quả tự động

 Các bước sử dụng Junit
• Viết trường hợp kiểm thử
• Chạy kiểm thử
• Kiểm tra kết quả

24
CuuDuongThanCong.com

/>

JUnit

Viết một trường hợp kiểm thử
 Tạo một trường hợp kiểm thử là subclass của
Junit TestCase
 Override phương thức setUp() để khởi tạo
các đối tượng kiểm thử
 Override hàm tearDown() để giải phóng các
đối tượng cần kiểm thử
Chạy kiểm thử
 Định nghĩa hàm test để kiểm tra các đối
tượng
25
CuuDuongThanCong.com

/>