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

Bài giảng Kiểm thử phần mềm - Chương 4: Các quá trình kiểm thử cung cấp cho người học các kiến thức: Chiến lược kiểm thử, sự thích ứng của chiến lược kiểm thử, tổ chức kiểm thử, phân công trách nhiệm kiểm thử,... Mời các bạn cùng tham khảo nội dung chi tiết.

Trang 1

Kiểm thử phần mềm

TS Nguyễn Thanh Hùng

Bộ Môn Công Nghệ Phần Mềm Email: hungnt@soict.hust.edu.vn Website: http://soict.hust.edu.vn/~hungnt

Các quá trình kiểm thử

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

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

CuuDuongThanCong.com https://fb.com/tailieudientucntt

Trang 2

 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ử

Chiến lược kiểm thử

Trang 3

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

Trang 4

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ử

Sự đáp ứng của chiến lược kiểm thử

Trang 5

 Câu hỏi: Ai làm? Làm cái gì? Khi nào? Và mối quan hệ

5

Trang 6

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

Trách nhiệm kiểm thử phần mềm

Trang 7

Phân công trách nhiệm kiểm thử

 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

Trang 8

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

Trang 9

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ô

Trang 10

Kiểm thử đơn vị

 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ý

Trang 11

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

Kiểm thử đơn vị

Trang 12

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

Trang 13

Đặc trưng dữ liệu qua giao diện

 Các đặc trưng qua giao diện là:

 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

Trang 14

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?

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 ghikhô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ý?

Trang 15

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, …

Kiểm thử cấu trúc dữ liệu cục bộ

Trang 17

 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

Kiểm thử các điều kiện logic

Trang 18

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

Trang 19

Kiểm thử sai tiềm ẩn

 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

Trang 20

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

Thủ tục kiểm thử đơn vị

Trang 21

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

Trang 22

Trang 23

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

Trang 25

 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ử

Trang 26

 Xác nhận kết quả đúng của kiểm thử bằng

Trang 27

} public void test_case2() { assertEquals(search.binarySearch( sortedArray2

,8),-1);

,6),2);

,4),1);

,10),4);

} // test case for showing the JUnit failure public void test_case6() {

assertEquals(search.binarySearch( sortedArray3

,7),4);

} }

86

JUnit Example for binarySearch

Trang 28

,8),-1);

,6),2);

,4),1);

,10),4);

} // test case for showing the JUnit failure public void test_case6() {

assertEquals(search.binarySearch( sortedArray3

,7),4);

} }

86

JUnit Example for binarySearch

Trang 29

Kiểm thử tích hợp

Trang 30

Khái niệm

 Kiểm thử tích hợp (integration testing) nhằm

nhận được một bộ phận chức năng hay một hệ con hoạt động tốt

 Là một kỹ thuật có tính hệ thống để xây dựng cấu trúc chương trình

 Từ các module đã kiểm thử đơn vị, xây dựng cấu trúc chương trình đảm bảo tuân theo thiết kế

 Có hai cách tích hợp:

• Tích hợp dần: từ trên xuống, dưới lên, kẹpKiểm thử tích hợp

Trang 31

Các sai gặp khi tích hợp

Các sai có thể gặp khi tích hợp:

 Dữ liệu bị mất khi đi qua một giao diện

 Hiệu ứng bất lợi một module vô tình gây ra

đối với các module khác

 Sự kết hợp chức năng phụ có thể không

sinh ra chức năng chính mong muốn

 Sự phóng đại các sai sót riêng rẽ có thể bị

Trang 32

 Kết hợp tất cả các module đã kiểm thử đơn vị thành chương trình

 Tiến hành kiểm thử toàn bộ chương trình

 Kết quả: một mớ hỗn độn

Với một tập các sai, chỉnh sửa chúng là khó khăn

vì cô lập các nguyên nhân là phức tạp: sai này được sửa, có thể xuất hiện nhiều sai khác, cứ thế triền miên

Chiến lược “Big-Bang” và hậu quả

Trang 33

 Là một cách tiện lợi để xây dựng và kiểm soát cấu trúc

 Theo chiều “sâu trước”

 Theo chiều “rộng trước”

 Hỗn hợp (theo cả hai cách trên)

33

Chiến lược tích hợp từ trên xuống

Trang 34

Tiến trình tích hợp trên xuống

Tích hợp từ trên xuống thực hiện theo 5

Trang 35

Tiến hình tích hợp trên xuống

Trang 36

Sơ đồ - tích hợp từ trên xuống

Trang 39

Chiến lược tích hợp từ dưới lên

Trang 41

Sơ đồ tích hợp dưới lên

Trang 43

-CuuDuongThanCong.com https://fb.com/tailieudientucntt

Trang 44

Kiểm thử tích hợp hỗn hợp

Các module quyết định (logic modules)

được tích hợp và kiểm thử top-down để

phát hiện sớm các lỗi về thiết kế

Các module chức năng (operational

modules) được tích hợp và kiểm thử

bottom-up để kiểm tra các modules có thể tái sử dụng và giảm các stubs

Tận dụng được lợi thế của cả top-down và bottom-up

Trang 45

Kiểm thử hồi quy

Mỗi lần 1 module mới được tích hợp, hoặc

1 bug được sửa, phần mềm bị thay đổi

Thay đổi có thể tạo ra lỗi trong các chức năng đã hoạt động trước đó

Kiểm thử hồi quy là việc chạy lại một số

kiểm thử để đảm bảo thay đổi không tạo

ra hiệu ứng phụ

45

Trang 46

Trang 47

lượng kiểm thử có thể tăng nhanh

 Chỉ nên được thiết kế để bao gồm các

test-cases cho một số lỗi trong mỗi chương trình

 Không khả thi và hiệu quả nếu mỗi lần có

thay đổi lại chạy lại kiểm thử cho tất cả các

chức năng

47

Trang 49

Kiểm thử hệ thống

Trang 50

chức năng hoạt động tốt trong môi trường định trước.

test)

Trang 51

 Kiểm thử hồi phục

 Kiểm thử khả năng chịu đựng

đồng thời

số, khối lượng…)

lý không đúng cách

51

Trang 52

 Kiểm thử độ an toàn

để phá vỡ)

 Kiểm thử hiệu suất

gian thực và nhúng)

hỏi cả phần cứng và phần mềm

Trang 53

Kiểm thử Alpha và Beta

 Khi hệ thống được sử dụng bởi nhiều khách hàng

 Được sử dụng để phát hiện các lỗi mà chỉ có người dùng cuối dường như có thể tìm thấy

 Thực hiện từ phía nhà phát triển

 Thực hiện bởi khách hàng

 Nhà phát triển theo dõi các lỗi và vấn đề

 Thực hiện trong một môi trường kiểm soát

53

Trang 54

Kiểm thử Alpha và Beta

 Thực hiện tại phía một hay nhiều người dùng

 Thực hiện bởi người dùng cuối

 Không có mặt người phát triển

 Trong môi trường không kiểm soát

 Lỗi có thể là thật hoặc tưởng tượng

 Khách hàng báo cáo lỗi

Trang 55

Kiểm thử chấp nhận

Thực hiện sau kiểm thử hệ thống nếu

phần mềm được phát triển cho khách

hàng cụ thể

Thường được thực hiện bởi khách hàng

hoặc người dùng cuối

Được thực hiện dựa trên yêu cầu:

 Hướng dẫn sử dụng được dùng để hỗ trợ

 Kiểm thử hệ thống có thể được sử dụng

55

Trang 56

Kiểm thử chấp nhận

Phần mềm phải chạy dưới điều kiện thực với điều kiện hoạt động phần cứng/phần mềm

yêu cầu của họ

Định dạng
Số trang	56
Dung lượng	3,42 MB