21/07/2020

Chương 1. Tổng quan về
kiểm thử phần mềm
1.1. Khái niệm phát triển phần mềm
1.1.1. Khái niệm phần mềm
1.1.2. Vòng đời phát triển phần mềm
1.1.3. Các mơ hình phát triển phần mềm

1.2. Khái niệm kiểm thử phần mềm
1.2.1. Khái niệm kiểm thử
1.2.2. Đảm bảo chất lượng
1.2.3. Kiểm soát chất lượng sản phẩm

Bộ môn Công nghệ thông tin
Trường Đại học Thương mại

1.3. Các nguyên tắc kiểm thử
1.4. Vai trò kiểm thử phần mềm
4

1.1.1. Khái niệm phần mềm

Tài liệu tham khảo
10th

Ian Sommerville, Software Engineering,
Edition, 2016.
Glenford J. Myers, Tom Badgett, Todd M.
Thomas, Corey Sandler, The Art of Software
Testing, 2011.

Ron Patton, Software Testing, Second Edition,
Sam Publishing, 2009.
 /> /> />
Khái niệm phần mềm
Một phần mềm gồm 3 thành phần:




Chương trình máy tính: mã nguồn, mã máy
Cấu trúc dữ liệu: cấu trúc làm việc (bộ nhớ trong) và cấu trúc
lưu trữ (bộ nhớ ngoài)
Các tài liệu liên quan: tài liệu hướng dẫn sử dụng (dành cho
người dùng), tài liệu phát triển (dành cho người phát triển
hệ thống), tài liệu tham khảo kỹ thuật (dành cho người bảo
trì)

Phần mềm được coi là tất cả các kỹ thuật

ứng dụng để thực hiện những dịch vụ chức
năng cho mục đích nào đó bằng phần cứng,
làm cho sử dụng phần cứng máy tính đạt
hiệu quả cao.

2

5

1.1.1. Khái niệm phần mềm


Nội dung
Chương 1. Tổng quan về kiểm thử
phần mềm
Chương 2. Quy trình kiểm thử phần
mềm
Chương 3. Các công cụ kiểm thử phần
mềm
Chương 4. Thiết kế ca kiểm thử
3

6

1


21/07/2020

Nhóm kỹ thuật, phương pháp luận
Các khái niệm và trình tự cụ thể hóa
một hệ thống

1.1.2. Vịng đời phát triển PM

Các phương pháp tiếp cận giải quyết
vấn đề

Là khoảng thời gian tính từ khi phần
mềm được đề xuất cho đến khi bỏ đi:
cụ thể là từ khi được đặt hàng, phát

triển, sử dụng đến khi bị loại bỏ.

Các trình tự thiết kế và phát triển
được chuẩn hóa
Các phương pháp đặc tả yêu cầu, thiết
kế hệ thống, thiết kế chương trình,
kiểm thử, tồn bộ quy trình quản lý
phát triển phần mềm.
7

Vịng đời phần mềm được phân chia
thành các pha chính như xác định yêu
cầu, triển khai, kiểm thử, bảo trì (vận
hành)... Phạm vi, thứ tự các pha khác
nhau tùy theo từng mơ hình, dự án cụ
thể
10

Nhóm chương trình

1.1.2. Vịng đời phát triển PM

 Là phần giao diện với phần cứng, tạo thành từ các nhóm

lệnh chỉ thị cho máy tính biết trình tự thao tác xử lý dữ
liệu
 Phần mềm cơ bản: với chức năng cung cấp môi trường
thao tác dễ dàng cho người sử dụng nhằm tăng hiệu năng
xử lý của phần cứng (ví dụ như OS là chương trình hệ
thống)

 Phần mềm ứng dụng: dùng để xử lý nghiệp vụ thích hợp
nào đó (quản lý, kế tốn, . . .), phần mềm đóng gói, phần
mềm của người dùng, . . .

Tùy mơ hình áp dụng mà việc phân
chia các pha, các bước có thể có sự
khác nhau: từ 3 đến 20 pha.
Xác định yêu cầu

Triển khai

Kiểm thử

(VËn hµnh) Bảo trì

Vịng đời phần mềm

11

8

1.1.2. Vịng đời phát triển PM

Nhóm các tư liệu
Những tư liệu hữu ích, có giá trị cao và
rất cần thiết để phát triển, vận hành và
bảo trì phần mềm
Để xây dựng phần mềm với độ tin cậy
cao cần tạo ra các tư liệu chất lượng
cao: đặc tả yêu cầu, mô tả thiết kế từng

loại, điều kiện kiểm thử, thủ tục vận
hành, hướng dẫn thao tác, …
9

 Các giai đoạn phát triển phần mềm
1.

Phân tích tính khả thi và đặc tả yêu cầu

2. Phân tích
3. Thiết kế
4. Mã hóa
5. Kiểm thử
6. Cài đặt
7. Bảo trì

12

2


21/07/2020

Phân tích tính khả thi
3. Đặc tả yêu cầu: Pha này sẽ tư liệu hố những thơng tin thu thập được.
Có hai loại u cầu cần được xác định:

Phân tích tính khả thi
Xác định vấn đề cần giải quyết
Xem xét các giải pháp và kỹ thuật khác nhau


(đánh giá ưu nhược điểm của từng giải
pháp)
Đánh giá về thời gian, giá thành, nguồn tài
nguyên cần thiết
Sản phẩm: tài liệu phân tích

* Yêu cầu của người sử dụng: là những yêu cầu bằng ngôn ngữ tự nhiên bổ
sung thêm cho các biểu đồ của các dịch vụ mà hệ thống cung cấp và các
ràng buộc vận hành của nó. Kiểu yêu cầu này được viết bởi người sử
dụng.
* Yêu cầu hệ thống: là những tài liệu có cấu trúc mơ tả chi tiết về các chức
năng, dịch vụ và các ràng buộc vận hành của hệ thống. Yêu cầu hệ thống
sẽ định nghĩa những gì cần phải xây dựng, cho nên nó có thể trở thành
bản hợp đồng giữa khách hàng và nhà thầu.

4. Đánh giá yêu cầu: pha này sẽ kiểm tra lại các yêu cầu xem chúng có
đúng thực tế hay khơng, có thống nhất khơng, có đầy đủ khơng. Nếu
phát hiện ra lỗi thì ta phải chỉnh sửa các lỗi này.

13

16

Đặc tả yêu cầu

Đặc tả yêu cầu
 Phân tích và đặc tả yêu cầu

Xác định nhu cầu của khách hàng/người sử


dụng


Xác định bài tốn, chứ khơng phải là giải pháp

Khó khăn



Khách hàng khơng biết rõ cái họ cần
Khách hàng khơng trình bày rõ cái họ muốn thay đổi

Sản phẩm: tài liệu đặc tả yêu cầu

14

17

Đặc tả yêu cầu

Thiết kế phần mềm

 Đặc tả yêu cầu (hay còn gọi là kỹ thuật xác định yêu cầu) là quy

 Thiết kế phần mềm là quá trình thiết kế cấu trúc phần mềm dựa trên

trình tìm hiểu và định nghĩa những dịch vụ nào được yêu cầu
và các ràng buộc trong quá trình vận hành và xây dựng hệ
thống.

 Quy trình xác định yêu cầu bao gồm bốn pha chính:
1. Nghiên cứu khả thi: Nghiên cứu khả thi giúp xác định
những yêu cầu của người sử dụng có thoả mãn những cơng
nghệ hiện tại hay khơng. Về góc độ kinh doanh, nghiên cứu
khả thi nhằm xác định hệ thống đưa ra có mang lại lợi
nhuận không. Việc nghiên cứu khả thi nên được thực hiện
một cách nhanh chóng và khơng q tốn kém. Kết quả của
việc nghiên cứu khả thi sẽ xác định có nên tiếp tục xây dựng
hệ thống nữa hay khơng.
2. Phân tích và rút ra các u cầu: đây là quy trình đưa ra các
u cầu hệ thống thơng qua một số phương pháp như: quan
sát hệ thống hiện tại, phỏng vấn và thảo luận với người sử
dụng, phân tích nhiệm vụ, phân tích tài liệu hoặc hệ thống
cũ … Trong pha này, chúng ta có thể phải xây dựng một hoặc
nhiều mơ hình hệ thống và các mẫu thử.

15

những tài liệu đặc tả. Hoạt động thiết kế bao gồm những cơng việc
chính sau:
 Thiết kế kiến trúc: Các hệ thống con cấu thành lên hệ thống cần xây dựng

và mối quan hệ giữa chúng được xác định và tư liệu hoá.

 Đặc tả trừu tượng: với mỗi hệ thống con, phải có một bản đặc tả về các

dịch vụ của nó và những ràng buộc khi nó vận hành.

 Thiết kế giao diện: với mỗi hệ thống con, các giao diện của nó với những


hệ thống con khác phải được thiết kế và tư liệu hoá.

 Thiết kế thành phần: các dịch vụ cung cấp cho các thành phần khác và các

giao diện tương tác với chúng phải được thiết kế.

 Thiết kế cấu trúc dữ liệu: cấu trúc dữ liệu được sử dụng để cài đặt hệ

thống phải được thiết kế một cách chi tiết và cụ thể.

 Thiết kế thuật toán: Các thuật toán được sử dụng để cung cấp các dịch vụ

phải được thiết kế chi tiết và chính xác.

18

3


21/07/2020

Phân tích

Mã hóa và gỡ rối
Mã hóa và gỡ rối
Mã hóa: cài đặt các thiết kế bằng ngơn ngữ

lập trình khơng đơn thuần chỉ là lập trình







Viết tài liệu
Chuẩn lập trình
Lập trình theo cấp
Cơng cụ
Quản lý phiên bản

Gỡ rối: phát hiện các lỗi trong quá trình lập

trình
Sản phẩm: chương trình

22

19

Thiết kế phần mềm

Kiểm thử

Các công việc trong thiết kế phần mềm

Kiểm thử - Đánh giá phần mềm hay
còn gọi là thẩm tra và đánh giá (V&V Verification and validation) được sử
dụng để chỉ ra rằng hệ thống đã thực
hiện theo đúng các đặc tả và thoả mãn
mọi yêu cầu của khách hàng.

Kiểm thử bao gồm các công đoạn:
kiểm tra, xem xét lại, và kiểm thử hệ
thống. Kiểm thử hệ thống tức là cho hệ
thống thực hiện trên những trường
hợp có dữ liệu thật được lấy từ tài liệu23
đặc tả hệ thống. Quy trình kiểm thử

20

Thiết kế phần mềm

Bảo trì hệ thống

Các phương pháp thiết kế



Bảo trì hệ thống:

Hướng chức năng
Hướng đối tượng

Bảo đảm chương trình vận hành tốt
Cài đặt các thay đổi
Cài đặt các yêu cầu mới
Xử lý các lỗi khi vận hành
Sản phẩm: chương trình

21


24

4


21/07/2020

1.1.3. Các mơ hình phát triển PM

Bảo trì hệ thống
Cải tiến phần mềm
Khi các yêu cầu hệ thống thay đổi theo sự

thay đổi của các yêu cầu nghiệp vụ thì phần
mềm phải cải tiến và thay đổi để hỗ trợ
khách hàng. Thơng thường chi phí để bảo trì
và cải tiến thường đắt hơn nhiều so với chi
phí xây dựng phần mềm.

Hiện nay có rất nhiều mơ hình phát
triển phần mềm, và thường được phân
thành 2 loại: mơ hình tuyến tính và mơ
hình lặp.
Mơ hình tuyến tính: các bước được thực

hiện tuần tự, khơng lặp lại.



Mơ hình thác nước

Mơ hình V…

Mơ hình lặp: các bước có thể thực hiện song

song, có thể lặp lại một số bước.



25

1.1.2. Vòng đời phát triển phần mềm



Mơ hình tiến hóa
Mơ hình xoắn ốc
Mơ hình hợp nhất…

28

a. Mơ hình Thác nước
Mơ hình thác nước (Water Fall Model)

29

26

1.1.2. Vòng đời phát triển phần mềm
 Kiểm thử cần thực hiện trong suốt
vịng đời của phần mềm

Kiểm thử khơng tồn tại độc lập.
Các hoạt động của kiểm thử luôn gắn liền với

các hoạt động phát triển phần mềm.
Các mô hình phát triển phần mềm khác nhau
cần các cách tiếp cận test khác nhau.

27

a. Mơ hình Thác nước
Các pha của mơ hình thác nước bao
gồm:
Phân tích và xác định các yêu cầu
Thiết kế hệ thống và phần mềm
Cài đặt và kiểm thử đơn vị
Tích hợp và kiểm thử hệ thống
Vận hành và bảo trì.

30

5


21/07/2020

b. Mơ hình V

a. Mơ hình Thác nước

Bảo trì


Là mơ hình cổ điển
Phân tích u
cầu

Phương pháp áp dụng 1 lần
Điều khiển hiệu quả

Kiểm thử chấp
nhận

Thiết kế hệ
thống

Phạm vi giới hạn của vịng lặp
Vịng đời dài
Khơng thích hợp với các hệ thống
khơng rõ ràng

Kiểm thử hệ
thống
Kiểm thử đơn vị và
tích hợp

Thiết kế
chương trình

Lập trình
34


31

b. Mơ hình V

Ứng dụng
Trong mơ hình thác nước, năm pha trên phải
được thực hiện một cách tuần tự; kết thúc pha
trước, rồi mới được thực hiện pha tiếp theo. Do
đó, nhược điểm chính của mơ hình thác nước là
rất khó khăn trong việc thay đổi các pha đã được
thực hiện. Giả sử, pha phân tích và xác định yêu
cầu đã hoàn tất và chuyển sang pha kế tiếp, nhưng
lúc này lại có sự thay đổi yêu cầu của người sử
dụng; thì chỉ cịn cách là phải thực hiện lại từ đầu.
Mơ hình này chỉ thích hợp khi các yêu cầu đã
được tìm hiểu rõ ràng và những thay đổi sẽ được
giới hạn một cách rõ ràng trong suốt q trình
thiết kế. Tuy nhiên, trong thực tế có rất ít những
hệ thống nghiệp vụ có các u cầu ổn định.

Trong mơ hình V:
Các tiến trình kiểm thử được thêm vào
Kết nối kiểm thử với phân tích và thiết kế
Thích hợp với những trường hợp bài tốn

khơng nhất qn

32

35


b. Mơ hình V

Nhận xét
Ưu điểm:

Tồn bộ qui trình được chia thành hai nhóm giai
đoạn tươngứng nhau: phát triển và kiểm thử.Mỗi
giai đoạn phát triển sẽ tiến hành song song với một
giai kiểm thử tương ứng => các lỗi được phát hiện
sớm ngay từ đầu

Chỉ phù hợp với các dự án nhỏ hoặc
Yêu cầu xác định

Nhược điểm:

Tinh thần chủ đạo của V-model là các hoạt động kiểm
thử phải được tiến hành song song (theo khả năng có
thể) ngay từ đầu chu trình cùng với các hoạt động phát
triển. Ví dụ, các hoạt động cho việc lập kế hoạch kiểm
thử toàn hệ thống có thể được thực hiện song song với
các hoạt động phân tích và thiết kế hệ thống.

Khơng phù hợp với dự án lớn
Thời gian thực hiện lâu

33

36


6


21/07/2020

b. Mơ hình V

c. Mơ hình bản mẫu

 Giai đoạn phát triển:
 Xác định yêu cầu và đặc tả (Requirement & Specification): Xác định
yêu cầu cần thiết mà hệ thống địi hỏi, đưa ra bản đặc tả.
 Phân tích hệ thống (System Analysis): Phân tích các yêu cầu mà hệ
thống cần có và đưa ra giải pháp tích hợp các yêu cầu đó vào hệ thống.
 Thiết kế chi tiết (Detailed Design): Chi tiết hóa các bước thực hiện xây
dựng hệ thống (Về cả giao diện và nội dung).
 Phát triển (Development ): Thực hiện việc viết code
 Giai đoạn kiểm thử:
 Kiểm tra từng thành phần và tích hợp (Unit & Intergration Test): Kiểm
tra các module của hệ thống tương ứng với pha thiết kế chi tiết.
 Kiểm thử toàn hệ thống (System Test): kiểm thử hoạt động của hệ thống
(về chức năng, giao diện).
 Nghiệm thu (Accepted Test): Kiểm tra lần cuối cùng và nghiệm thu sản
phẩm đưa vào sử dụng.
37

b. Mơ hình V

Mục đích

Xem xét u cầu người sử dụng ở giai đoạn

ban đầu
Giảm bớt rủi ro và không chắc chắn
Kiểm chứng thiết kế và thực thi

Nên thường xuyên trả lời các câu hỏi
chuyên biệt; mục đích phải được xác
định.
40

Lợi ích của bản mẫu

 Với V model thì cơng việc test được tham gia ngay từ đầu, từ

lúc lấy yêu cầu là có thể "test" bằng cách review tài liệu yêu
cầu, rồi cho tới review đặc ta chi tiết, các bản thiết kế,... review
code rồi cuối cùng là test ở mức thấp nhất - từng module, chức
năng, màn hình,... đến test tích hợp rồi kiểm thử hệ thống.
 So với mơ hình khác thì ở mơ hình này, công việc test đi sát
hơn và ngay từ đầu khi bắt đầu phát triển. Chắc chắn chất
lượng dự án sẽ tốt hơn. Nhưng tại sao người ta vẫn tiếp tục đưa
ra mơ hình phát triển khác? Vì ở mơ hình chữ V này người ta
vẫn phát triển cùng lúc cả hệ thống (nhiều yêu cầu, chức năng
cùng lúc) mà rủi ro (risk) về thay đổi yêu cầu là rất lớn. Nên
mơ hình này vẫn có thể gặp rắc rối khi khách hàng thường
xuyên thay đổi yêu cầu.

Học bằng cách làm việc
Tăng cường giao tiếp

Tăng sự tham gia của người dùng vào
dự án
Làm rõ các yêu cầu chỉ biết một phần

41

38

c. Mơ hình bản mẫu

Tuần tự làm bản mẫu
Tập hợp yêu cầu

Nghe Khách
trình bày

Thiết kế nhanh

Tạo / sửa
bản mẫu

Xây dựng bản mẫu
Đánh giá của khách hàng
Làm mịn

Khách kiểm tra
bản mẫu

Quay lại thiết kế nhanh để điều chỉnh
Xây dựng sản phẩm


Mô hình bản mẫu (Prototyping model)

39

42

7


21/07/2020

Đánh giá

d. Mơ hình xoắn ốc

Ưu điểm: phù hợp với
Hệ thống rủi ro cao

Lập kế hoạch

Yêu cầu không chắc chắn

Phân tích rủi ro

Giao tiếp

Giao diện chưa rõ ràng

khách hàng


Khái niệm

Chiến lược cài đặt chưa rõ ràng

Thiết kế

Làm mới
Nâng cấp

Khách hàng

Hạn chế:
Khách hàng có thể cho rằng nguyên mẫu là

hệ thống thực

Mong đợi không thực tế về tiến triển của dự án

Chi phí tăng thêm

Xác định mục đích,
lựa chọn và ràng
buộc

Đánh giá lựa chọn;
xác định và giải
quyết rủi ro

Phân tích

rủi ro
Phân tích
rủi ro
Phân tích
rủi ro

Người phát triển có sự chọn lựa không tốt
Phù hợp cho nguyên mẫu, nhưng không phù hợp cho hệ
thống thực

Lập kế hoạch
u cầu

Ngun mẫu khơng giống hồn tồn hệ

Lập kế hoạch
phát triển

thống cuối cùng


46

d. Mơ hình xoắn ốc
(Boehm 1987)

Đánh giá




Xuất xưởng

Mơ hình xoắn ốc (spiral)

43



Xây dựng &

đánh giá

Bảo trì

Bản mẫu

Kế hoạch kiểm
thử và tích hợp

Khách hàng sẽ có các phản ứng khác nhau

Kế hoạch cho giai đoạn tiếp

44

Chức năng

Yêu cầu phần
mềm


Kiểm thử yêu
cầu

Thiết kế
hệ
thống

Thiết kế
chi tiết

Lập
trình

Kiểm thử
thiết kế
Kiểm thử
chấp nhận

Bản mẫu
Bản mẫu

Tích hợp và
kiểm thử

Kiểm
thử
đơn vị

Phát triển và kiểm
chứng sản phẩm

mức tiếp theo

47

Ứng dụng

d. Mơ hình xoắn ốc

Mơ hình bản mẫu thường được sử dụng
khi:

 Trong mơ hình xoắn ốc, quy trình phát triển phần mềm

Khi mới rõ mục đích chung chung của phần

mềm, chưa rõ chi tiết đầu vào hay xử lý ra sao
hoặc chưa rõ yêu cầu đầu ra
Dùng như “Hệ sơ khai” để thu thập yêu cầu
người dùng qua các thiết kế nhanh
Các giải thuật, kỹ thuật dùng làm bản mẫu có
thể chưa nhanh, chưa tốt, miễn là có mẫu để
thảo luận gợi yêu cầu của người dùng
45

được biểu diễn như một vòng xoắn ốc. Các pha trong quy
trình phát triển xoắn ốc bao gồm:
 Thiết lập mục tiêu: xác định mục tiêu cho từng pha của dự án.
 Đánh giá và giảm thiểu rủi ro: rủi ro được đánh giá và thực hiện các

hành động để giảm thiểu rủi ro.


 Phát triển và đánh giá: sau khi đánh giá rủi ro, một mô hình xây

dựng hệ thống sẽ được lựa chọn từ những mơ hình chung.

 Lập kế hoạch: đánh giá dự án và pha tiếp theo của mơ hình xoắn ốc

sẽ được lập kế hoạch.

48

8


21/07/2020

d. Mơ hình xoắn ốc

Đánh giá

Nhấn mạnh việc đánh giá các rủi ro

Ưu điểm

Phần mềm được xây dựng theo nhiều
chu kỳ. Mỗi chu kỳ tương ứng với một
sản phẩm của 1 giai đọan phát triển
Xác định các mục tiêu, giải pháp, ràng buộc
Đánh giá các giải pháp, xác định các nguy cơ


và tìm cách giải quyết chúng
Phát triển và kiểm thử sản phẩm của chu kỳ
này
Lập kế hoạch cho chu kỳ tiếp theo
49

Hạn chế rủi ro sớm
Nhận được phản hồi ( feedbacks) từ khách

hàng sớm

Dễ kiểm soát các mạo hiểm ở từng mức tiến hóa

Hạn chế
Khó thuyết phục khách hàng là phương pháp tiến hóa

xoắn ốc có thể kiểm sốt được
Chưa được dùng rộng rãi như các mơ hình tuyến tính

hoặc chế thử.
52

d. Mơ hình xoắn ốc (tiếp)

Ứng dụng
Mơ hình xoắn ốc phù hợp với

 Giao tiếp khách hàng: giữa người phát triển và khách

Các hệ phần mềm quy mô lớn, các dự án lớn,


hàng để tìm hiểu yêu cầu, ý kiến
 Lập kế hoạch: Xác lập tài nguyên, thời hạn và những
thơng tin khác
 Phân tích rủi ro: Xem xét mạo hiểm kỹ thuật và mạo
hiểm quản lý
 Thiết kế: Xây dựng một hay một số biểu diễn của
ứng dụng

phức tạp

Hệ thống cần phát triển nhiều phiên bản
Các hệ thống có u cầu chưa xác định rõ ràng

50

d. Mơ hình xoắn ốc (tiếp)

53

e. Mơ hình hợp nhất
 Mơ hình hợp nhất sử dụng Các kỹ thuật thế hệ 4

Xây dựng và xuất xưởng: xây dựng, kiểm thử,
cài đặt và cung cấp hỗ trợ người dùng (tư liệu,
huấn luyện, . . .)
Đánh giá của khách hàng: Nhận các phản hồi
của người sử dụng về biểu diễn phần mềm trong
giai đoạn kỹ nghệ và cài đặt


51

(Fourth generation techniques): Tập hợp các cơng cụ
cho phép xác định đặc tính phần mềm ở mức cao, sau
đó tự động sinh mã nguồn dựa theo đặc tả đó.
 Các cơng cụ 4GT điển hình: ngơn ngữ phi thủ tục cho
truy vấn CSDL, tạo báo cáo, xử lý dữ liệu, tương tác
màn hình, tạo mã nguồn, khả năng đồ họa bậc cao, khả
năng bảng tính, khả năng giao diện Web.
 Từ thu thập yêu cầu cho đến sản phẩm: đối thoại giữa
khách và người phát triển là quan trọng.
 Không nên bỏ qua khâu thiết kế: 4GT chỉ áp dụng để
triển khai thiết kế qua ngôn ngữ lập trình thế hệ 4
(4GL- Fourth-generation programming language).
54

9


21/07/2020

e. Mơ hình hợp nhất

e. Mơ hình hợp nhất
Tiến trình hợp nhất có thể được nhìn
dưới hai góc nhìn khác nhau

Góc nhìn kỹ thuật

Góc nhìn quản lý: quan tâm đến lĩnh vực


kinh tế, chiến thuật, con người.


Tiến trình gồm 4 giai đoạn.

Góc nhìn kỹ thuật: quan tâm đến cơng nghệ,

kiểm tra chất lượng, phương pháp.


Tiến trình gồm nhiều bước lặp.

55

58

e. Mơ hình hợp nhất

e. Mơ hình hợp nhất
Góc nhìn quản lý

Kết hợp hai góc nhìn

56

e. Mơ hình hợp nhất

59


e. Mơ hình hợp nhất

Góc nhìn kỹ thuật: các bước lặp

Mơ hình hợp nhất và UML

Mỗi bước lặp gồm các hoạt động







Đặc tả
Phân tích
Thiết kế
Mã hóa
Kiểm thử
Cài đặt

Mỗi bước lặp là một tiến trình thác đổ

57

60

10



21/07/2020

e. Mơ hình hợp nhất

f. Mơ hình Agile: quy trình Scrum

Ưu điểm: giảm thời gian phát triển và
tăng năng suất lao động.
Nhược điểm: 4GT khó dùng hơn ngơn
ngữ lập trình, mã khó tối ưu và khó
bảo trì cho hệ thống lớn  cần kỹ
năng của kỹ sư phần mềm
Trong tương lai: kết hợp 4GT với mơ
hình hướng thành phần.

Scrum là một quy trình phát triển phần mềm theo
mơ hình linh hoạt (agile). Vì thế, nó tn thủ các
ngun tắc của Agile
Scrum rất linh hoạt như các phương pháp Agile
khác. Nhờ đó nó mang lại tính thích nghi rất cao.
Dựa trên các thơng tin minh bạch hóa từ các q
trình thanh tra và làm việc, Scrum có thể phản hồi
lại các thay đổi một cách tích cực, nhờ đó mang
lại thành cơng cho dự án.

61

f. Mơ hình Agile: quy trình Scrum
 Agile là một phương pháp phát triển phần mềm linh hoạt để


làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt
càng sớm càng tốt.
 Đặc trưng Agile:
 ◦Tính lặp (Iterative): Dự án sẽ được thực hiện trong các phân

đoạn lặp đi lặp lại. Các phân đoạn (được gọi là Iteration hoặc
Sprint) này thường có khung thời gian ngắn (từ 1 – 4 tuần). Trong
mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các cơng
việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế, triển
khai, kiểm thử (với các mức độ khác nhau) để cho ra các phần
nhỏ của sản phẩm.
 ◦Các phân đoạn (Sprint) lặp đi lặp lại trong Agile: Các phương

pháp Agile thường phân rã mục tiêu thành các phần nhỏ với quá
trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, và khơng thực
hiện việc lập kế hoạch dài hạn.

62

f. Mơ hình Agile: quy trình Scrum
 Đặc trưng Agile:
 ◦Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary): Cuối các

phân đoạn (Sprint), nhóm phát triển thường cho ra các phần nhỏ của sản
phẩm cuối cùng. Các phần nhỏ này thường là đầy đủ, có khả năng chạy
tốt, được kiểm thử cẩn thận và có thể sử dụng ngay (gọi là potentially
shippable product increment of functionality). Theo thời gian, phân đoạn
(sprint) này tiếp nối phân đoạn (sprint) kia, các phần chạy được này sẽ
được tích lũy, lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng
được thỏa mãn.

 ◦Tính thích ứng (hay thích nghi – adaptive): Do các Sprint chỉ kéo dài
trong một khoảng thời gian ngắn, và việc lập kế hoạch cũng được điều
chỉnh liên tục, nên các thay đổi trong quá trình phát triển (yêu cầu thay
đổi, thay đổi công nghệ, thay đổi định hướng về mục tiêu v.v.) đều có
thể được đáp ứng theo cách thích hợp. Theo đó, các quy trình Agile
thường thích ứng rất tốt với các thay đổi.
63

64

f. Mơ hình Agile: quy trình Scrum
 Các cơng cụ (artifacts) Scrum
 Product backlog: Đây là danh sách ưu tiên các tính năng

(feature) hoặc đầu ra khác của dự án, có thể hiểu như là
danh sách yêu cầu (requirement) của dự án. Product Owner
chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục
(Product Backlog Item) trong Product Backlog dựa trên các
giá trị do Product Owner định nghĩa
 Sprint backlog: Đây là bản kế hoạch cho một Sprint; là kết
quả của buổi họp lập kế hoạch (Sprint Planning). Với sự kết
hợp của Product Owner, nhóm sẽ phân tích các u cầu theo
độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục
trong Product Backlog dưới dạng danh sách công việc
(TODO list).
65

f. Mơ hình Agile: quy trình Scrum
Product Owner tạo ra Product Backlog chứa các yêu
cầu của dự án với các hạng mục được sắp theo thứ tự

ưu tiên. Đội sản xuất sẽ thực hiện việc hiện thực hóa
dần các yêu cầu của Product Owner với sự lặp đi lặp
lại các giai đoạn từ 1 đến 4 tuần làm việc (gọi là
Sprint) với đầu vào là các hạng mục trong Product
Backlog, đầu ra là các gói phần mềm hồn chỉnh có
thể chuyển giao được (Potentially Shippable Product
Increment)
Đội sản xuất cùng họp với Product Owner để lập kế
hoạch cho từng Sprint. Kết quả của buổi lập kế hoạch
(theo cách làm của Scrum) là Sprint Backlog chứa các
công việc cần làm trong suốt một Sprint.
66

11


21/07/2020

f. Mơ hình Agile: quy trình Scrum
Các Sprint sẽ được lặp đi lặp lại cho tới
khi nào các hạng mục trong Product
Backlog đều được hồn tất

f. Mơ hình Agile: quy trình Scrum
 Scrum định nghĩa quy tắc cho bốn sự kiện chủ chốt (các cuộc họp)

nhằm tạo môi trường và quy cách hoạt động và cộng tác cho các thành
viên trong dự án. Các lễ nghi này diễn ra trước khi Sprint bắt đầu
(Sprint Planning), trong khi Sprint diễn ra (Daily Scrum) và sau khi
Sprint kết thúc (Sprint Review và Sprint Retrospective):

 1.Sprint Planning (Họp Kế hoạch Sprint): Nhóm phát triển họp với
Product Owner để lên kế hoạch làm việc cho một Sprint. Công việc lập
kế hoạch bao gồm việc chọn lựa các yêu cầu cần phải phát triển, phân
tích và nhận biết các công việc phải làm kèm theo các ước lượng thời
gian cần thiết để hoàn tất các tác vụ. Scrum sử dụng cách thức lập kế
hoạch từng phần và tăng dần theo thời gian, theo đó, việc lập kế hoạch
không diễn ra duy nhất một lần trong vòng đời của dự án mà được lặp
đi lặp lại, có sự thích nghi với các tình hình thực tiễn trong tiến trình đi
đến sản phẩm.

67

f. Mơ hình Agile: quy trình Scrum
 Trong suốt q trình phát triển, nhóm sẽ phải cập nhật Sprint

Backlog và thực hiện công việc họp hằng ngày (Daily Scrum)
để chia sẻ tiến độ công việc cũng như các vướng mắc trong quá
trình làm việc cùng nhau. Nhóm được trao quyền để tự quản lí
và tổ chức lấy cơng việc của mình để hồn thành cơng việc
trong Sprint.
 Khi kết thúc Sprint, nhóm tạo ra các gói phần mềm có chức
năng hồn chỉnh, sẵn sàng chuyển giao (shippable) cho khác
hàng. Buổi họp Sơ kết Sprint (Sprint Review) ở cuối Sprint sẽ
giúp khách hàng thấy được nhóm đã có thể chuyển giao những
gì, cịn những gì phải làm hoặc cịn gì phải thay đổi hay cải
tiến. Sau khi kết thúc việc đánh giá Sprint, Scrum Master và
nhóm cùng tổ chức họp Cải tiến Sprint (Sprint Retrospective)
để tìm kiếm các cải tiến trước khi Sprint tiếp theo bắt đầu, điều
này sẽ giúp nhóm liên tục học hỏi và trưởng thành qua từng
68

Sprint.

f. Mơ hình Agile: quy trình Scrum
Quy trình Scrum được vận hành thế
nào?

70

f. Mơ hình Agile: quy trình Scrum
 2. Daily Scrum (Họp Scrum hằng ngày):Scrum Master tổ chức cho

Đội sản xuất họp hằng ngày trong khoảng 15 phút để Nhóm Phát
triển chia sẻ tiến độ cơng việc. Trong cuộc họp này, từng người trong nhóm phát
triển lần lượt trình bày để trả lời 3 câu hỏi sau:
 Hơm qua đã làm gì?
 Hơm nay sẽ làm gì?
 Có khó khăn trở ngại gì khơng?

 3. Sprint Review (Họp Sơ kết Sprint): Cuối Sprint, nhóm phát

triển cùng với Product Owner sẽ rà sốt lại các cơng việc đã hoàn tất
(DONE) trong Sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi
cần thiết cho sản phẩm.
 4. Sprint Retrospective (Họp Cải tiến Sprint): Dưới sự trợ giúp
của Scrum Master, nhóm phát triển sẽ rà sốt lại tồn diện Sprint vừa
kết thúc và tìm cách cải tiến quy trình làm việc cũng như bản thân
sản phẩm.
71

f. Mơ hình Agile: quy trình Scrum

 Trong Scrum, đội ngũ tham gia phát triển phần mềm được

phân chia ra ba vai trò với trách nhiệm rõ ràng để đảm bảo
tối ưu hóa các cơng việc đặc thù. Ba vai trị này bao
gồm: Product Owner (chủ sản phẩm), Scrum Master
và Development Team (Đội sản xuất hay Nhóm Phát
triển).
 Product Owner: Là người chịu trách nhiệm về sự thành công

của dự án, người định nghĩa các yêu cầu và đánh giá cuối cùng
đầu ra của các nhà phát triển phần mềm.
 Scrum Master: họ phải đảm bảo các sprint được hoàn thành
đúng mục đích, bảo vệ đội làm việc và loại bỏ các trở ngại.
 Development Team: thường từ 5-9 người, tùy theo quy mơ dự
án nó có thể có rất nhiều đội, nhiều người tham gia.
69

72

12


21/07/2020

Kiểm thử trong mơ hình Agile
 Ko thực hiện đưa toàn bộ yêu cầu/ nghiệp vụ của hệ thống vào

code và testing cùng 1 lúc ( như quy trình truyền thống) mà sẽ
chia các Yêu cầu ra làm theo từng giai đoạn. Mỗi 1 giai đoạn chỉ
làm 1 số lượng yêu cầu nhất định

 Chia thành nhiều giai đoạn nhỏ để thực hiện hay còn gọi là
Sprint
 Mỗi 1 sprint thường kéo dài từ 1 tuần đến 4 tuần ( ko dài hơn 1
tháng)
 Đầu sprint sẽ lên kế hoạch làm những yêu cầu nào. Sau đó, sẽ
thực hiện code và test. Cuối sprint là 1 sản phẩm hoàn thiện cả
code lẫn test có thể demo và chạy được.
 Hồn thành sprint 1, tiếp tục làm sprint 2, sprint... cho đến khi
hồn thành hết các u cầu.

 Lựa chọn mơ hình
Phụ thuộc vào bài tốn, vào mơi
trường cụ thể
u cầu rõ ràng: =>

Mơ hình thác nước

 u cầu chưa rõ ràng, độ phức tạp cao

 Yêu cầu có khả năng thay đổi
 Khơng chắc chắn về tính hiệu quả, tính khả thi
=> Làm bản mẫu, mơ hình xoắn ốc, Agile
76

73

Kiểm thử trong mơ hình Agile
 Trong mỗi 1 sprint thì sẽ có họp hàng ngày – daily meeting. Cả team

sẽ đứng họp thành 1 vòng tròn, thường chỉ họp ngắn từ 15 – 20 phút.

Mỗi thành viên sẽ báo cáo: hơm qua tơi đã làm gì? Hơm nay tơi sẽ
làm gì? Có gặp khó khăn gì ko?
 Trong mỗi 1 sprint thì các thành viên của dự án phải tạo task cho
code và test,1 task code xong là phải có task test liền ngay đó. Do
thời gian làm ngắn ngày nên hiệu quả làm việc phải cao, đúng tiến
độ để đảm bảo cuối sprint là hoàn thành được cả test. ( ý này nếu bị
hỏi mới kể)
 Ưu điểm của quy trình này là phù hợp với những yêu cầu/ nghiệp vụ
hay thay đổi, hoặc hệ thống nghiên cứu do làm theo từng giai đoạn
ngắn ngày, có thể nhìn thấy những rủi ro hay những điểm chưa phù
hợp để thay đổi ( ý này nếu bị hỏi mới kể)
 Điều hành đội dự án sẽ là ơng scrum master, cịn có product owner là
người đánh giá phần mềm làm đã theo đúng nghiệp vụ/ yêu cầu chưa
( ý này nếu bị hỏi mới kể)
74

Kết luận

Có thể tổ hợp các mơ hình để đem lại hiệu quả

77

 Lặp tiến trình:

Đối với Hệ thống phức tạp, cần chia dự

Mỗi phần của tiến trình được lặp theo 2
cách tiếp cận

án thành các hệ thống con



 Tổ hợp các mơ hình:

Một số lưu ý

Trong thực tế, người ta thường kết
hợp nhiều mơ hình cho một dự án



Một số lưu ý

Áp dụng mơ hình xoắn ốc hay mơ hình hợp nhất cho
tồn bộ dự án.
Mỗi hệ thống con có thể áp dụng một mơ hình khác nhau
 Áp dụng mơ hình ngun mẫu cho các hệ thống con phức
tạp
 Áp dụng mơ hình thác nước cho các hệ thống con khác

• Phát triển gia tăng
• Phát triển xoắn ốc

75

78

13



21/07/2020

1.2. Khái niệm kiểm thử phần mềm
Một số lưu ý

Kiểm thử phần mềm là quá trình khảo sát

một hệ thống hay các thành phần dưới
những điều kiện xác định; quan sát, ghi
lại kết quả, và đánh giá một khía cạnh nào
đó của hệ thống hay thành phần đó. (Theo
IEEE Standard Glossary of Software
Engineering Terminology).
Kiểm thử là giai đoạn quan trọng đảm bảo
chất lượng phần mềm.

 Chuẩn hóa tiến trình:
Tăng năng lực của tổ chức phát triển phần
mềm

• ISO 9000-03 (International Standards Organization )
• CMM (Software Engineering Institute)

79

82

1.2.1. Khái niệm kiểm thử
Một số lưu ý


Kiểm thử là tiến trình xem xét, kiểm

 Giảm chi phí phát triển:
Sử dụng các phương pháp, cơng cụ tiên tiến

• tái sử dụng: thư viện thương mại,...
• tự sinh mã: cơng cụ tạo giao diện,...
• hướng đối tượng: kế thừa, bảo trì
• ngơn ngữ bậc cao: năng lực biểu diễn cao

80

tra lại đặc tả, phân tích, thiết kế và
mã hoá nhằm phát hiện lỗi phần
mềm, xác minh phần mềm có đúng
đặc tả, thiết kế; có đáp ứng nhu cầu
người dùng, có hoạt động hiệu quả
khơng .
Kiểm thử thành công khi phát hiện
ra lỗi; kiểm thử không phát hiện ra
lỗi là kiểm thử dở (Theo Sue
A.Conger- The New SE)

83

1.2.1. Khái niệm kiểm thử
Một số lưu ý

 Software Testing là một quá trình thực thi một chương


trình với mục đích tìm lỗi.

 Thực hiện các pha phát triển:
 Pha xác định yêu cầu và thiết kế có vai trò quyết định

đến chất lượng phần mềm, chiếm phần lớn cơng sức so
với mã hóa, kiểm thử.
 Khi chuyển tiếp giữa các pha phát triển phải thẩm định
để đảm bảo lỗi không ảnh hưởng đến pha sau.
 Tài liệu tạo ra ở mỗi pha không chỉ dùng cho pha kế
tiếp mà còn dùng để đảm bảo chất lượng của phần
mềm và dùng trong khâu bảo trì.
 Cần chuẩn hóa mẫu biểu, cách thức ghi chép, tạo tài
liệu nhằm đảm bảo chất lượng phần mềm.
81

 Quality Testing = Verification + Validation (Xác minh

và Thẩm định)
 Là hoạt động kiểm tra xem phần mềm có chạy chính xác

hay khơng (Verification) và có thoả mãn yêu cầu của
khách hàng hay không (Validation) nhằm hướng tới mục
tiêu chất lượng của phần mềm.

84

14



21/07/2020

1.2.1. Khái niệm kiểm thử

1.2.2. Đảm bảo chất lượng

 Kiểm thử là một quá trình đánh giá một hệ thống hay là

 QA: Giám sát, quản lý và đảm bảo chất lượng

các thành phần của nó với mục đích là xác định xem nó có
thỏa mãn những yêu cầu được đưa ra hay không. Hiểu một
cách đơn giản, kiểm thử - test là chạy một chương trình để
xác nhận bất kì lỗ hổng, lỗi sai hay những yêu cầu bị bỏ
quên, những yêu cầu không đúng so với yêu cầu thực tế đề
ra.
 Theo tiêu chuẩn ANSI/IEEE 1059, kiểm thử như một q
trình của việc phân tích các thành phần của phần mềm để
dị tìm sự khác biệt giữa phần mềm thực tế đang tồn tại và
những điều kiện được yêu cầu – requirement.(đó là thiếu
sót – defect, sai sót - error, lỗi - bug). Từ đó đánh giá được
chất lượng của sản phẩm phần mềm.

 QA ( Quality Assurance ), là những cơng việc đảm bảo chất

 QA có nhiệm vụ giám sát để bảo đảm các tiêu chuẩn và quy trình sản

85

88


1.2.1. Khái niệm kiểm thử

lượng của việc xây dựng hệ thống, quy trình sản xuất của cơng
ty theo một chuẩn mực. Giám sát chặt chẽ và đo lường việc
thực hiện các chuẩn chất lượng trong các giai đoạn từ nghiên
cứu thị trường, thiết kế… cho đến sản xuất và bán hàng, chăm
sóc khách hàng.
xuất PM được định nghĩa và tuân thủ nghiêm túc, hướng đến mục
tiêu các sản phẩm (SP) trung gian cũng như SP sau cùng của dự án
thỏa mãn các tiêu chuẩn và yêu cầu đã định trước đó. Cơng việc của
QA liên quan đến quy trình (process).

1.2.2. Đảm bảo chất lượng
 Thơng thường, trong một dự án PM, khách hàng chỉ
trả tiền cho lưc lượng sản xuất trực tiếp như developer
và tester, do đó đầu tư vào lực lượng QA là một đầu tư
mang tính nội bộ và nền tảng, giúp cơng ty cải tiến và
kiểm sốt các quy trình đảm bảo chất lượng
Một khi quy trình sản xuất được tuân thủ nghiêm túc,
lỗi xuất hiện ở các khâu sản xuất sẽ được nhận diện và
ngăn chặn sớm, SP sau cùng (ở chặng kiểm định) sẽ ít
lỗi và khả năng thành cơng của dự án được bảo đảm
hơn, do đó tổng chi phí sẽ thấp hơn.
86

1.2.1. Khái niệm kiểm thử
2 mục đích chính của hoạt động
kiểm thử:
Kiểm tra xem phần mềm làm ra có đúng


đặc tả (u cầu, phân tích, thiết kế) hay
khơng.
Kiểm tra xem phần mềm có đáp ứng yêu
cầu người dùng hay khơng.

Đây chính là 2 hoạt động cốt yếu để
đảm bảo chất lượng phần mềm, diễn
ra trong suốt quá trình phát triển
phần mềm.
87

89

1.2.2. Đảm bảo chất lượng
 Quy trình bao gồm các biểu mẫu, các bước và hướng dẫn cụ thể giúp

thành viên dự án thực hiện một công việc nào đó một cách nhất qn
và có kiểm sốt. Có rất nhiều quy trình khác nhau được thiết kế tùy
theo nhu cầu của một dự án như Quy trình phát triển yêu cầu SP
(Requirement); Quy trình thiết kế SP (Design); Quy trình triển khai
và viết code (Coding); Quy trình kiểm định SP (Testing); Quy trình
cài đặt và hỗ trợ (Delivery); Quy trình bảo trì SP (Maintenance); Quy
trình quản trị dự án (Project management); Quy trình quản lý cấu
hình (Coonfiguration management); Quy trình đảm bảo chất lượng
(Quality Assurance).

90

15



21/07/2020

1.2.2. Đảm bảo chất lượng

1.2.3. Kiểm soát chất lượng phần mềm

 QA là người tham gia phát triển quy trình hoạt động ở cấp

 QC (Quality Control) là những công việc liên quan
đến kiểm soát, kiểm tra, đánh giá chất lượng của sản
phẩm. QC là một trong những khâu trong quy trình
sản xuất rất quan trọng, được tiến hành xen kẽ trong
những công đoạn sản xuất, tạo ra những sản phẩm có
chất lượng theo yêu cầu. QC thường hoạt động trong
những nhà máy sản xuất theo quy trình, những quy
trình công nghệ hiện đại, trong các lĩnh vực về kĩ
thuật, lập trình, may mặc. QC kiểm tra chất lượng của
sản phẩm, đảm bảo chất lượng của sản phẩm trường
khi đưa ra thị trường sử dụng.

công ty và ở cấp dự án, đánh giá các tài liệu. Ngồi ra, họ
cịn phải giám sát và kiểm tra (audit) các hoạt động được
thực hiện trong dự án xem chúng có tuân thủ các quy trình
(process) đã được định ra; xác định các điểm khơng tương
thích với quy trình (process noncompliance – gọi tắt là
NC) và báo cáo cho những người liên quan và các cấp
quản lý đồng thời giám sát để bảo đảm chúng được giải
quyết đến khi hoàn tất.

 Nhân sự QA cũng có thể phản hồi về những bất cập của
quy trình và đề xuất cải tiến quy trình.
 QA cũng hay gọi là PQA ( Process Quanlity Assurance –
Cán bộ quản lý chất lượng quy trình).
91

Quy trình đảm bảo chất lượng
1.

2.

3.
4.
5.

Đề xuất, đưa ra quy trình phát triển (development process)
sản phẩm phù hợp với yêu cầu cụ thể của từng dự án. Các quy
trình này có thể được phát triển dựa trên V-model hay Agile
(đa số là Scrum hoặc Lean Development) hay thơng qua việc
áp dụng những quy trình quản lý sẵn có như ISO hay CMMI.
Đưa ra những tài liệu, biểu mẫu, hướng dẫn để đảm bảo chất
lượng của sản phẩm cho tất cả các bộ phận trong nhóm phát
triển sản phẩm.
Kiểm tra, audit việc thực thi quy trình của các bộ phận trong
nhóm làm sản phẩm có đúng quy trình QA đã đề ra khơng.
Nhắc nhở đội ngũ phát triển sản phẩm việc tuân thủ theo quy
trình làm việc đã đưa ra.
Điều chỉnh, thay đổi quy trình phù hợp với từng sản phẩm mà
các team đang thực hiện.
92


1.2.3. Kiểm soát chất lượng phần mềm
 QC = Quality Control
QC chính là Tester. Nhiều cơng ty gọi là QC chứ
khơng phải là tester.
Quality Control: Điều khiển chất lượng
 Tập hợp các hoạt động được tạo ra nhằm đánh

giá chất lượng sản phẩm, bảo đảm sản phẩm
đúng đặc tả yêu cầu
 Trực tiếp kiểm tra chất lượng của sản phẩm
 Có nhiệm vụ khảo sát, chạy thử và báo cáo lỗi
93

94

Quy trình Kiểm sốt chất lượng
1.

2.
3.
4.
5.

Tìm hiểu hệ thống, phân tích tài liệu mô tả về
hệ thống và thiết kế test case, thực hiện việc
test phần mềm trước khi giao cho khách hàng
hay đưa ra thị trường.
Lên kế hoạch kiểm thử phần mềm
Viết Script cho automation test

Sử dụng các test tool để tạo và thực hiện các
test case/script chi tiết.
Phối hợp với nhóm lập trình trong việc fix bug
và báo cáo chi tiết cho Project Manager hoặc
các bên liên quan tuỳ từng dự án, sản phẩm.
95

1.2.3. Kiểm soát chất lượng phần mềm
QA: là người người đặt ra các quy định cho dự
án như: đề xuất đưa ra quy trình phát triển dự
án, giám sát, quản lý và ban hành chất lượng.
Mục đích để đảm bảo rằng quy trình phát triển
hoặc bảo trì chắc chắn sẽ đáp ứng được các mục
tiêu hệ thống đã đề ra.
QC: Là người thi thành các quy định, nguyên tắc
để đảm bảo sản phẩm cuối cùng thực hiện đúng
các quy định, nguyên tắc mà QA đặt ra. Cũng là
người kiểm thử, tìm các trường hợp cịn thiếu
sót hay lỗi so với yêu cầu được đặt ra bởi khách
96
hàng.

16


21/07/2020

QA

QC


QA bao gồm các hoạt động đảm bảo và thực
hiện quy trình, trình tự và tiêu chuẩn trong nội
dung kiểm thử phần mềm đã phát triển và những
yêu cầu đặt ra

QC/Tester bao gồm các hoạt động để đảm bảo
việc kiểm tra một phần mềm đã đáp ứng yêu cầu
trong tài liệu yêu cầu (đảm bảo việc phát hiện
lỗi/bug trong phần mềm)

Tập trung vào quy trình và tuần tự hơn là quản
lý việc test thực tế trên hệ thống

Tập trung vào việc test thự tế trên phần mềm
nhằm phát hiện lỗi trong quá trình phát triển
hệ thống

Đảm bảo chất lượng là quy trình định hướng

Kiểm sốt chất lượng là định hướng sản phẩm

Mục tiêu của đảm bảo chất lượng phần mềm là
phòng tránh lỗi trong ứng dụng phần mềm giúp
cải thiện quá trình phát triển và kiểm thử

Mục tiêu của kiểm soát chất lượng phần mềm là
xác định, phát hiện các lỗi trong khi phát triển
ứng dụng phần mềm


Không liên quan đến việc thực thi chương
chình, code

Liên quan đến việc thực thi chương trình, code

Xác định điểm yếu trong các quy trình phát triển Xác định các lỗi cần sửa
để cải thiện
Đây là tập hợp con của vòng đời phát triển phần Testing là tập hợp con của Quality Control
mềm (SDLC)
(Quản lý chất lượng)
Được thực hiện trước khi kiểm soát chất lượng

Được thực hiện chỉ sau khi hoạt động Đảm bảo
Chất lượng được hoàn thành
97

1.3. Các nguyên tắc kiểm thử
(4) Dữ liệu thử cho kết quả bình thường

thì khơng có ý nghĩa nhiều, cần có những
dữ liệu kiểm thử phát hiện ra lỗi phần
mềm.
(5) Khi thiết kế trường hợp thử, không chỉ
dữ liệu kiểm thử nhập vào, mà phải thiết kế
trước cả dữ liệu kết quả sẽ có.
(6) Khi phát sinh thêm trường hợp thử thì
nên thử lại những trường hợp thử trước đó
để tránh ảnh hưởng lan truyền sóng khi
kiểm thử.
100


1.4. Vai trò kiểm thử phần mềm
 Kiểm thử phần mềm (software testing) là hoạt động nhằm tìm

kiếm, phát hiện các lỗi của phần mềm
 Kiểm thử phần mềm đảm bảo sản phẩm phần mềm đáp ứng

98

chính xác, đầy đủ và đúng theo yêu cầu của khách hàng, yêu
cầu của sản phẩm đề đã đặt ra.
 Kiểm thử phần mềm tạo điều kiện cho bạn tận dụng tối đa tư
duy đánh giá và sáng tạo để bạn có thể phát hiện ra những điểm
mà người khác chưa nhìn thấy.
 Software testing cũng có thể xem như là q trình thẩm định và
thẩm tra (validating and verifying) phần mềm/chương trình/ứng
dụng/sản phẩm để:
 Đáp ứng được các yêu cầu công việc và kỹ thuật đã được
quy định trong thiết kế và trong lúc phát triển
 Làm việc như mong đợi

101

1.3. Các nguyên tắc kiểm thử
(1) Chất lượng phần mềm do khâu thiết
kế quyết định là chủ yếu, chứ không
phải khâu kiểm thử.
(2) Tính dễ kiểm thử phụ thuộc vào cấu
trúc chương trình.
(3) Người kiểm thử và người xây

dựng phần mềm nên khác nhau.
99

BÀI TẬP CHƯƠNG 1
1.
2.

3.
4.
5.

6.

Khái niệm phần mềm, vòng đời phát triển phần mềm.
Trình bày các mơ hình phát triển phần mềm. Theo anh
chị mơ hình phát triển nào hiện đang được triển khai
phổ biến các công ty phát triển phần mềm.
Khái niệm kiểm thử phần mềm, đảm bảo chất lượng
phần mềm.
So sánh hoạt động kiểm thử phần mềm và kiểm sốt
chất lượng phần mềm.
Phân tích các ngun tắc kiểm thử phần mềm. Theo
anh chị, những nguyên tắc nào đảm bảo chất lượng
phần mềm.
Phân tích vai trị kiểm thử phần mềm trong quá trình
phát triển phần mềm.
102

17



21/07/2020

CHƯƠNG 2. QUY TRÌNH KIỂM
THỬ PHẦN MỀM

2.1. Các giai đoạn kiểm thử phần mềm

2.1. Các giai đoạn kiểm thử phần mềm
2.2. Nội dung kiểm thử

Bắt đầu

2.2.1. Kiểm thử đơn vị
2.2.2. Kiểm thử tích hợp
2.2.3. Kiểm thử hệ thống
2.2.4. Kiểm thử chấp nhận



Mẫu test
Các thủ tục Test

Lập kế hoạch Test



Thiết kế Test
Cài đặt và chuẩn bị
Test


Test hệ thống

2.3.1. Kiểm thử chức năng
2.3.2. Kiểm thử phi chức năng

Xem xét và Đánh giá
kết quả test

Tổng hợp, báo cáo

2.4. Công việc của người kiểm thử



Test tích hợp



Lỗi
Biên bản test

2.3. Các hình thức kiểm thử

Kế hoạch test

Mã nguồn Test
Dữ liệu test
Môi trường




Báo cáo kết quả
test, đề xuất giải
pháp



Hồ sơ báo cáo tổng
hợp test

Kết thúc

103

2.1. Các giai đoạn kiểm thử phần mềm

106

2.1. Các giai đoạn kiểm thử phần mềm

Các giai đoạn kiểm thử phần mềm

Initiation

Bắt đầu

Definition

Lập kế hoạch Test


Xác định yêu cầu

Solution

Thiết kế kiến trúc
Thiết kế Test

Construction

Cài đặt và chuẩn bị
Test

Lập trình

Construction

Thử nghiệm

Test tích hợp
Test hệ thống

Xem xét và Đánh giá
kết quả test

(khởi động)

Definition (Xác định yêu cầu)

Solution (Thiết kế kiến trúc)


Construction (Xây dựng)
Coding (lập trình)

Testing (thử nghiệm)

Tổng hợp, báo cáo
Transition

Kết thúc

(Triển khai)

Termination

(Kết thúc)

104

2.1. Các giai đoạn kiểm thử phần mềm

Lập kế hoạch Test

Cài đặt và chuẩn bị
Test

Test tích hợp

Test
Test hệ thống


Xem xét và Đánh
giá kết quả test

Các u cầu test

• Phương thức thực hiện
Cáchồn
rủi rothành
liên quan
đến test
• Tiêu
việc test,
đánh
2. Đánh giá rủi ro và lập mức
ưu chuẩn
giá chất
lượng
sản
phẩm
• Dựa
trên
cáccầu
sảntest
phẩm
tiên cho các u cầu
Các
u
đượcphân
xác tích

định
•• Số
kỹ
năng
Cácngười,
tố
cần
chú cái
ý gì?
•yếu
Xácmức
định:
test
độ ưu
tiên
• Mơi• trường
test:
phần
cứng…
Xác định:
giới
hạnmềm,
cơng việc,
thời
cụPhương
test lực
thức thực hiện
3. Xác lập chiến lược test • Cơng
gian,
nguồn

• Dữ liệu test
Tiêu chuẩn đánh giá

Thiết kế Test

Chuẩn bị

CÁC HOẠT ĐỘNG - Lập kế hoạch test
1. Xác định yêu cầu cho test

Bắt đầu

Lập kế hoạch

107

Các yếu tố cần chú ý
• Xác định nguồn lực

Phân tích kết quả

Tổng hợp, báo cáo

105

TN Test

TN Test

Các nguồn lực

4. Xác định nguồn lực và mơi
• Lịch trình test
trường
• Các mốc chính
Lịch trình test
5. Lập lịch trình test

TN Test

6. Tổng hợp thông tin, lập KH test Kế hoạch test

TN Test

7. Xem xét và thông qua KH test

Kết thúc

TN Test,
CBT

Kế hoạch test được phê duyệt

TN Test
QTDA

108

18



21/07/2020

CÁC HOẠT ĐỘNG - thiết kế test

CÁC HOẠT ĐỘNG - test hệ thống

•Dựa trên các sản phẩm của:
• Phân tích
• bước lập KH test
1. Lập danh sách các loại test, đảm
Danh• sách
loại các
test test case
TN Test,
Xác định
bảo cho việc xác lập tính đúng đắn &
CBT
• Mơ tả test case: vào, ra, điều kiện
thỏa mãn yêu cầu của sản phẩm

1. Nhận bàn giao với đội lập trình

2. Xây dựng tình huống test (test
case)

Thiết kế test, các mẫu mã sử
dụng, yêu cầu về dữ liệu test

3. Cài đặt


3. Xây dựng và tổ chức thủ tục test
(test procedure)
4. Xem xét tình huống test và thủ tục
test, đánh giá tỷ lệ yêu cầu của khách
hàng (hoặc tình huống sử dụng) sẽ
được test dựa trên thiết kế test đã lập

Các thủ tục test
TN Test,
CBT
• Dựa vào: các test case
•
Xác
định
các
test
procedure
Biên bản xem xét
QTDA, Cán
• Xác lập mối quan hệ và thứ tự
bộgiữa
lập trình
• Các test procedure với nhau
• Các test procedure - Test cases

5. Thơng qua thiết kế Test

Thiết kế test được thông qua

TN Test,

CBT

QTDA

CÁC HOẠT ĐỘNG - Cài đặt và chuẩn bị test

Test script
1.Lập các test script để thực hiện các
tình huống test/thủ tục test (nếu cần)

• Các
lệnh dùng để tự động hố TN
các Test/
thủ
Test
scipts
tục test
CBT

2. Chuẩn bị dữ liệu test

Dữ liệu test

CBT

3. Chuẩn bị môi trường

Môi trường sẵn sàng cho
việc thực hiện test


CBT

4. Kiểm tra các cơng cụ test

Biên bản kiểm tra cơng cụ
test

CBT

•

Lập trình, sử dụng cơng cụ test tự động

5. Xem xét môi trường, điều kiện và dữ Môi trường và dữ liệu test
được kiểm tra
liệu test

TN Test/
CBT

CÁC HOẠT ĐỘNG - test tích hợp

2. Chỉnh sửa thiết kế test

4. Thực hiện test và ghi nhận lỗi

Các sản phẩm cần test được tiếp

nhận
• Kiểm

tra và cập nhật:
Test
Thiết• kế
test,case
test script, dữ liệu test
được•cập
nhật
Test
procedure
Chương
trìnhscript
được cài đặt
• Test
Test
Biên•bản
testdata

CBT
TN Test
CBT
CBT

Danh sách lỗi phát hiện

5. Xử lý lỗi

Biên bản test

Danh sách lỗi phát hiện
• Khi hệ thống

thoả mãn các
Kếtra
quả test được xem xét
6. Xem xét các kết quả test và
việc
tiêu
chuẩn đặt

thực hiện khắc phục lỗi

7. Kết quả test được xem xét

Xác nhân sản phẩm đủ tiêu chuẩn
phát hành

TN Test, CBT
TN Test,QTDA,
CBT, CBCL
(nếu cần)
QTDA, CBCL,
TN Test

CÁC HOẠT ĐỘNG - xem xét và đánh giá kết quả
test

1. Phân tích lỗi và đưa ra đề xuất

Báo cáo kết quả test

TN Test


Đề xuất

2. Đánh giá tỷ lệ test, đánh giá mức Báo cáo kết quả test
độ đạt được các tiêu chí để hoàn
thành test
3. Xem xét báo cáo kết quả test

Báo cáo kết quả test được xem
xét

• Phân tích lỗi dựa:
• mức độ lặp lại
• Dựa trên tỷ lệ
YCnghiêm
được test/tổng
• độ
trọng
số YC cần test• Thời gian sửa lỗi…

TN Test

QTDA,
CBCL

CÁC HOẠT ĐỘNG - tổng hợp, báo cáo

• Tài liệu
• Gói phần mềm
•…

Các sản phẩm cần test được tiếp

CBT

Hệ thống để test sẵn sàng

CBT

3. Thực hiện test và ghi nhận lỗi

Biên bản test

CBT

4. Xử lý lỗi

Danh sách lỗi phát hiện

1. Nhận bàn giao với đội lập trình
2. Cài đặt

• Dựa trên thiết kế test
nhận
• Ghi nhận lỗi vào DMS

• Phối hợp với đội lập trình
• Test lại -> Ghi nhận lỗi mới
5. Xem xét các kết quả test và việc Biên bản test
thực hiện khắc phục lỗi


TN Test,
CBT

1. Tập hợp các dữ liệu, kết
quả test

Dữ liệu, kết quả test

2. Lập báo cáo tổng hợp test Báo cáo tổng hợp test
3. Tổ chức lưu trữ tài liệu, hồ Hồ sơ, files
sơ

CBT
TN Test
CBT

TN Test,
QTDA,
CBT, CBCL
(nếu cần)

19


21/07/2020

HOẠT ĐỘNG – xác định test
case

CÁC HOẠT ĐỘNG

Vấn đề của thiết kế test

Phân hoạch tương đương - Equivalence partitioning

Xác định các test case

Ví dụ:

Phân hoạch tương đương
Đường đi trong mơ đun

Hàm tính trị tuyệt đối
- miền dữ liệu = 0
- miền dữ liệu < 0

Mô tả các test case

Input

Expected
Output

100

100

-20

20


0

0

115

CÁC HOẠT ĐỘNG – mô tả test case
 Tên mô đun/chức năng muốn kiểm thử
 Dữ liệu vào

HOẠT ĐỘNG – xác định test case
Phân hoạch tương đương - Equivalence partitioning
Mở rộng test case:

- dữ liệu thơng thường: số, xâu kí tự, file,...
- môi trường thử nghiệm: phần cứng, OS,...
- thứ tự thao tác (khi kiểm thử giao diện)

Tạo test case cho các trường hợp đặc biệt
- biên của số trong máy tính
(vd. 32767, -32768)
- số không (0)
- số âm, số thập phân
- dữ liệu sai kiểu
- dữ liệu ngẫu nhiên

 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ế

116

119

HOẠT ĐỘNG – xác định test case

HOẠT ĐỘNG – xác định test
case

Phân hoạch tương đương - Equivalence partitioning
 Không thể kiểm thử mọi trường hợp
 Chia dữ liệu thành các miền có cùng hành vi
 Tạo một test case cho từng miền
 Tạo test case cho biên của các miền

Đường đi trong mơ đun
 Phân tích mơ đun để xác định đường đi
 Đườ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 mô đun
 Thiết kế các test case để kiểm thử mọi đường đi

- nhiều lỗi xuất hiện với giá trị biên

117

20



21/07/2020

HOẠT ĐỘNG – xác định test
case
Đường đi trong mô đun – Xác định đường đi


Đánh số các khối lệnh

- có ít nhất một cặp khối lệnh (một cạnh của đồ thị)
chưa xuất hiện trong các đường đi đã có

 Bộ các đường đi độc lập là một tập hợp thỏa mã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

- 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

HOẠT ĐỘNG – xác định test
case
Đường đi trong mô đun – Xác định đường đi
Start 0
1

Ví dụ:


HOẠT ĐỘNG – xác định test
case
Đường đi trong mơ đun – Đường đi độc lập
1

Ví dụ:

2

9

2

4

3

11

4
5

6
7

8
9

10


HOẠT ĐỘNG – xác định test
case
Đường đi trong mô đun – Xác định đường đi
1

Ví dụ:

 Khơng thể chọn mọi đường đi
- chọn các đường đi độc lập

gọn flow chart (đồ thị)

End

Đường đi trong mô đun – Đường đi độc lập

 Đường đi độc lập

- đá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
 Rút

HOẠT ĐỘNG – xác định test
case

5

3

6

7

1-9
1-2-3-8-1-9
1-2-4-6-7-8-1-9
1-2-4-5-7-8-1-9

8

HOẠT ĐỘNG – xác định test
case
Đường đi trong mơ đun – Đường đi độc lập
 Có thể tồn tại nhiều bộ đường đi độc lập

2

9
4
5

3
6

7

đường đi:
1-2-3-8-1-9
1-2-4-6-7-8-1-9

 Đường đi tối thiểu cần kiểm tra

= độ phức tạp thuật toán

8

21


21/07/2020

HOẠT ĐỘNG – xác định test
case
Đường đi trong mô đun – Độ phức tạp thuật toán

2.2. Nội dung kiểm thử
Tiến hành ở mọi giai đoạn phát triển
phần mềm:
 Đặc tả

Độ phức tạp V(G) của flow chart G:

- xét duyệt đặc tả yêu cầu

 Phân tích

1.

Số miền của đồ thị G
2. V(G) = E - N + 2
E: số cạnh
N: số đỉnh

3. V(G) = P + 1
P: số các nút điều kiện

- xét duyệt đặc tả phân tích

 Thiết kế
- xét duyệt đặc tả thiết kế
 Mã hóa
- kiểm thử mơ đun chương trình
130

HOẠT ĐỘNG – xác định test
case

2.2. Nội dung kiểm thử


Đường đi trong mô đun – Độ phức tạp thuật tốn
1

Ví dụ:

Số cạnh E = 11
Số đỉnh N = 9
Số điều kiện = 3
Số miền = 4

2

9

4
5

3

6
7

Độ phức tạp: 4



Trong môi trường của đội phát triển dự á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 khách hàng
– Kiểm thử alpha
– Kiểm thử beta
– Kiểm thử hệ thống thông tin

8
131

HOẠT ĐỘNG – xác định test
case
Độ phức tạp lớn thì xác suất xuất hiện lỗi cao

•


khơng nên tạo các mơ đun có độ phức tạp > 10
• phân rã mô đun
(tạo các mô đun thứ cấp để giảm độ phức tạp)

2.2. Nội dung kiểm thử
Khảo sát phần mềm

Kiểm thử chấp nhận

Đặc tả chức năng/
Phân tích

Kiểm thử hệ thống

Thiết kế

Kiểm tích hợp

Lập trình/
và đặc tả mơđun

Kiểm thử
hồi quy

Kiểm đơn vị

Mã hố mơđun CT

Nội dung kiểm thử phía phát triển dự án


132

22


21/07/2020

4.1.2. Nội dung kiểm thử
Tên kiểm thử
Kiểm thử đơn vị
(Unit test/Module
test)

Kiểm thử tích hợp
(Integration test)

Nội dung kiểm thử

2.2. Nội dung kiểm thử

Người thực hiện

Yêu cầu đối với kiểm thử:

Kiểm tra 1 module Đội dự án test
(hàm, thủ tục, đoạn (tester)
code, component…)
dựa vào tài liệu thiết
kế chi tiết


 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)

Kiểm tra sự tương Đội dự án test
tác giữa các module (tester)
dựa vào tài liệu thiết
kế tổng thể

- 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 sốt tiến trình/kết quả

Nội dung kiểm thử phía đội phát triển dự án
136

4.1.2. Nội dung kiểm thử
Tên kiểm thử
Kiểm thử hệ thống
(System test)

Kiểm thử chấp nhận
(Acceptance test)

Nội dung kiểm thử

2.2.1. Kiểm thử đơn vị


Người thực hiện

Kiểm tra toàn bộ hệ Đội dự án test (tester)
thống dựa vào tài liệu
đặc tả yêu cầu phần
mềm: kiểm tra sự hoạt
động tổng thể hệ thống,
kiểm tra tính đúng đắn
của giao diện, tính đúng
đắn với đặc tả, và tính
dùng được. Chủ yếu sử
dụng kiểm thử chức
năng.
Dựa vào yêu cầu Thành viên đội dự án
nghiệp vụ của khách và Khách hàng
hàng.

1. UnitTesting : test ở mức cơ bản, test
từng module nhỏ trong hệ thống do lập
trình
viên thực hiện. Là kiểu white box testing
Mục đích: để xác nhận rằng mỗi thành
phần của phần mềm thực hiện đúng với
thiết kế

Nội dung kiểm thử phía đội phát triển dự án

137


4.1.2. Nội dung kiểm thử

2.2.1. Kiểm thử đơn vị

Nội dung kiểm thử phía khách hàng:
 Kiểm thử alpha: kiểm thử được tiến hành bởi một nhóm

nhỏ người sử dụng dưới sự hướng dẫn của người phát
triển, sử dụng các dữ liệu thực, thẩm định tính dùng
được của hệ thống.
 Kiểm thử bê ta: là mở rộng của kiểm thử alpha, được tiến

hành với một số lớn người sử dụng khơng có sự hướng
dẫn của người phát triển, kiểm tra tính ổn định, điểm tốt
và khơng tốt của hệ thống.

 kiểm thử đơn vị có các nội dung sau :
 kiểm thử giao diện
 khám nghiệm cấu trúc dữ liệu cục bộ.
 kiểm thử với các điều kiện biên.
 Các đường Độc lập.
 Các đường xử lý sai.

 Kiểm thử hệ thống: mở rộng phạm vi kiểm thử, xem xét

phần mềm như một thành phần trong HTTT phức tạp.
Kiểm tra các yếu tố: khả năng phục hồi sau lỗi, độ an
toàn, hiệu năng và giới hạn của phần mềm.
135


138

23


21/07/2020

2.2.2. Kiểm thử tích hợp
Là kiểm thử tích hợp 1 nhóm các module

riêng lẻ với nhau. Một dự án phần mềm bao
gồm nhiều module phần mềm, được code
bởi nhiều người khác nhau. Tích hợp thử
nghiệm tập trung vào kiểm tra truyền dữ liệu
giữa các module (tích hợp các hàm lại với
nhau, tích hợp các màn hình lại với nhau
theo từng module hay dựa theo chức năng)
Mục đích: mục đích để tìm ra lỗi trong q
trình tích hợp các thành phần, module lại với
139
nhau.

2.2.2. Kiểm thử tích hợp


Kiểm thử tích hợp (integration testing) nhằm nhận
được một phần hay toàn bộ hệ thống như mong
đợi. Khi tích hợp các thành phần có thể gặp các
sai:
Dữ liệu bị mất khi đi qua một giao diện.

Hiệu ứng bất lợi 1 mơđun vơ tình gây ra đối các môđun
khác.
 Sự kết hợp các 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ị đến mức
không chấp nhận được.
 Vấn đề của cấu trúc dữ liệu tồn cục có thể để lộ ra.



140

2.2.2. Kiểm thử tích hợp
Kiểm thử tích hợp là một lỹ thuật có tính hệ thống
để xây dựng cấu trúc chương trình (ngay khi
đang tiến hành kiểm thử để phát hiện sai liên kết
với giao diện).
 Mục đích là tận dụng các môđun đã kiểm thử
đơn vị và xây dựng cấu trúc chương trình sao cho
nó đảm bảo tn theo thiết kế.
 Có hai hướng tích hợp chương trình





Tích hợp dần
Tích hợp đồng thời 1 lúc: “big bang”

2.2.2. Kiểm thử tích hợp

 Mục đích
- kiểm tra giao diện giữa các unit
- kiểm tra tính đúng đắn so với đặc tả
- kiểm tra tính hiệu quả
 Thường sử dụng kiểm thử chức năng

1. Kiểm thử top – down
2. Kiểm thử bottom – up
3. Kiểm thử quay lui (regression)
142

2.2.2. KIỂM THỬ TÍCH HỢP –
Top-down testing
 Các mô đun mức trên được kiểm thử
trước
 Các mô đun thuộc cấp được thay bằng
bằng các mô đun tạm thời (stub
function)
 có cùng tên với mơ đun thật
 có cùng giao diện
 trả lại kết quả với một hoặc một vài
bộ dữ liệu chuẩn

2.2.2. KIỂM THỬ TÍCH HỢP –
Top-down testing
Ví dụ về stub fuction:
Kiểm thử mơ đun calender() có gọi đến mơ đun tính ngày
trong tuần calc_day()chưa được phát triển.

calender()


đã phát triển, cần kiểm thử

calc_day()

chưa phát triển

141

24


21/07/2020

2.2.2. KIỂM THỬ TÍCH HỢP –
Top-down testing

2.2.2. KIỂM THỬ TÍCH HỢP –
Top-down testing

Ví dụ về stub fuction:

Ưu điểm:

Mơ đun tính ngày trong tuần calc_day():
- input: ngày, tháng, năm
- output: trả xâu kí tự là thứ của ngày đã cho

 Phát hiện sớm các lỗi thiết kế (lỗi cấu trúc)
 Có sớm phiên bản thực hiện được

Nhược điểm:
 Nhiều mô đun cấp thấp rất khó mơ phỏng

String calc_day(Date d)
{
return "Sunday";
}

- thao tác

với cấu trúc dữ liệu phức tạp
- trả lại kết quả phức tạp (con trỏ, ảnh, ...)

2.2.2. KIỂM THỬ TÍCH HỢP –
Top-down testing

2.2.2. KIỂM THỬ TÍCH HỢP –
Bottom-up testing

Ví dụ về stub fuction:

 Các mô đun cấp thấp được kiểm thử trước

Để tăng độ thích nghi, có thể thay thế dữ liệu cố định
bằng cách nhập kết quả trực tiếp từ bàn phím.

 Mơ đun mức trên được thay thế bằng mơ
đun điều khiển (test driver), có chức năng
gọi mơ đun cần thử nghiệm
 truyền dữ liệu

 hiển thị kết quả

String calc_day(Date d)
{
String s;
cout << ”Enter day_of_week of ”<< d;
cin >> s;
return s;
}



 Thay thế dần các driver

2.2.2. KIỂM THỬ TÍCH HỢP –
Top-down testing
A

B

F

2.2.2. KIỂM THỬ TÍCH HỢP –
Bottom-up testing
Ví dụ Test driver Thử nghiệm calc_day()

Top module được kiểm thử trước
với các stubs

void calc_day_test_drive()

{
Date d;
String s;
while (1) {
cout << ”Enter date: ”);
cin >> d;
s = calc_day(d);
cout << s << endl;
}
}

G

Các stubs được thay thế từng cái một
C

D

E

Mỗi khi một module mới được tích hợp
một số ca kiểm thử được thực hiện lại
(kiểm thử quay lui)

147

25