TỔNG LIÊN ĐOÀN LAO ĐỘNG VIỆT NAM

TRƯỜNG ĐẠI HỌC TÔN ĐỨC THẮNG

KHOA CÔNG NGHỆ THÔNG TIN

THÂN TRONG HUỲNH NHÂN- 51800590

NGHIÊN CỨU VỀ KIỂM THỬ

PHẦN MỀM VÀ THIẾT KẾ TEST
CASES TRONG KIỂM THỬ PHẦN
MỀM

DỰ ÁN CÔNG NGHỆ THÔNG TIN 1

KHOA HỌC MÁY TÍNH

THÀNH PHỐ HỒ CHÍ MINH, NĂM 2023

 TỔNG LIÊN ĐOÀN LAO ĐỘNG VIỆT NAM
TRƯỜNG ĐẠI HỌC TÔN ĐỨC THẮNG
KHOA CÔNG NGHỆ THÔNG TIN

THÂN TRONG HUỲNH NHÂN- 51800590

NGHIÊN CỨU VỀ KIỂM THỬ PHẦN

MỀM VÀ THIẾT KẾ TEST CASES
TRONG KIỂM THỬ PHẦN MỀM

DỰ ÁN CÔNG NGHỆ THÔNG TIN 1

KHOA HỌC MÁY TÍNH

Cán bộ hướng dẫn: Trịnh Thị Mỹ Uyên
Giảng viên giám sát: Dung Cẩm Quang

THÀNH PHỐ HỒ CHÍ MINH, NĂM 2023

 i

LỜI CẢM ƠN

Chúng em xin chân thành cảm ơn ……………………………………

…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………

TP. Hồ Chí Minh, ngày ... tháng … năm 20..

Tác giả
(Ký tên và ghi rõ họ tên)

Thân Trọng Huỳnh Nhân

 ii

CÔNG TRÌNH ĐƯỢC HOÀN THÀNH

TẠI TRƯỜNG ĐẠI HỌC TÔN ĐỨC THẮNG

Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi và được sự
hướng dẫn khoa học của thầy Dung Cẩm Quang. Các nội dung nghiên cứu, kết
quả trong đề tài này là trung thực và chưa công bố dưới bất kỳ hình thức nào
trước đây. Những số liệu trong các bảng biểu phục vụ cho việc phân tích, nhận
xét, đánh giá được chính tác giả thu thập từ các nguồn khác nhau có ghi rõ
trong phần tài liệu tham khảo.

Ngoài ra, trong Dự án còn sử dụng một số nhận xét, đánh giá cũng như
số liệu của các tác giả khác, cơ quan tổ chức khác đều có trích dẫn và chú thích
nguồn gốc.

Nếu phát hiện có bất kỳ sự gian lận nào tôi xin hoàn toàn chịu trách
nhiệm về nội dung Dự án của mình. Trường Đại học Tôn Đức Thắng không
liên quan đến những vi phạm tác quyền, bản quyền do tôi gây ra trong quá trình
thực hiện (nếu có).

TP. Hồ Chí Minh, ngày … tháng … năm

20..
Tác giả
(Ký tên và ghi rõ họ tên)

Thân Trọng Huỳnh Nhân

 iii

TÊN ĐỀ TÀI

TÓM TẮT

(Time New Romans – 13)...........................................................................................

...............................................................................................................................................
...............................................................................................................................................
 iv

TITLE

ABSTRACT

(Time New Romans – 13)...........................................................................................

...............................................................................................................................................
...............................................................................................................................................
 v

MỤC LỤC
DANH MỤC HÌNH VẼ..............................................................................................viii

DANH MỤC BẢNG BIỂU............................................................................................

DANH MỤC CÁC CHỮ VIẾT TẮT..........................................................................

CHƯƠNG 1. MỞ ĐẦU VÀ TỔNG QUAN ĐỀ TÀI...................................................

1.1 Lý do chọn đề tài........................................................................................................

1.2 Mục tiêu thực hiện đề tài............................................................................................

CHƯƠNG 2. GIỚI THIỆU VỀ KIỂM THỬ PHẦN MỀM.......................................

2.1 Khái niệm kiểm thử phần mềm..................................................................................

2.1.1 Mục tiêu chính của kiểm thử phần mềm...............................................................

2.1.2 Phạm vi kiểm thử phần mềm.................................................................................

2.1.3 Các hoạt động của kiểm thử phần mềm...............................................................

2.2 Các phương pháp kiểm thử........................................................................................

2.2.1 Kiểm thử tĩnh – Static Testing..............................................................................

2.2.2 Kiểm thử động - Dynamic Testing........................................................................

2.3 Các kỹ thuật kiểm thử phần mềm..............................................................................

2.3.1 Kiểm thử hộp trắng(White-box testing)................................................................

2.3.2 Kiểm thử hộpđen(Black-box testing)....................................................................

2.3.3 Kiểm thử hộp xám(Grey-box testing)................................................................

2.4 Các cấp độ (chu trình) kiểm thử phần mềm.............................................................

2.4.1 Kiểm tra đơn vị (Unit Test).................................................................................

2.4.2 Kiểm thử tích hợp các đơn vị (Integration Testing)...........................................

2.4.3 Kiểm tra hệ thống (System testing).....................................................................

 vi

2.4.4 Kiểm tra chấp nhận (Acceptance testing)..........................................................

CHƯƠNG 3. THIẾT KẾ VÀ KHỞI TẠO TESTCASE...........................................

3.1 Khái niệm.................................................................................................................

3.2 Vai trò của thiết kế testcase......................................................................................

3.3 Quy trình thiết kế test case.......................................................................................

3.3.1 Kiểm thử hộp trắng.............................................................................................

3.3.2 Bao phủ quyết định – Decision Coverage..........................................................

3.3.3 Bao phũ điều kiện – Condition Coverage...........................................................

3.3.4 Kiểm thử hộp đen................................................................................................

CHƯƠNG 4. TẦM QUAN TRỌNG CỦA KIỂM THỬ PHẦN MỀM...................

4.1 Tầm quan trọng........................................................................................................

4.2 Một số công cụ.........................................................................................................

CHƯƠNG 5. CƠ BẢN VỀ PHẦN MỀM VÀ LỖI PHẦN MỀM............................

5.1 Phần mềm và các khái niệm liên quan.....................................................................

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

5.1.2 Vòng đời của phần mềm.....................................................................................

5.2 Chất lượng phần mềm và đảm bảo chất lượng phần mềm.......................................

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

5.2.2 Những tiêu chí đánh giá chất lượng phần mềm.................................................

5.2.3 Khái niệm đảm bảo chất lượng phần mềm.........................................................

5.2.4 Quy trình đảm bảo chất lượng phần mềm..........................................................

5.3 Lỗi phần mềm và quy trình xử lý lỗi phần mềm......................................................

5.3.1 Khái niệm lỗi phần mềm.....................................................................................

 vii

5.3.2 Các loại lỗi phần mềm........................................................................................

5.3.3 Qui trình sửa chữa lỗi phần mềm.......................................................................

CHƯƠNG 6. KẾT LUẬN............................................................................................

6.1 Kết luận....................................................................................................................

6.2 Hướng phát triển......................................................................................................

TÀI LIỆU THAM KHẢO...........................................................................................

 viii

DANH MỤC HÌNH VẼ

Hình 2.1: Quy trình kiểm thử phần mềm....................................................................4

Hình 2.2: Các kỹ thuật kiểm thử phần mềm..............................................................7

Hình 2.3: Kiểm thử hộp trắng.....................................................................................8

Hình 2.4: Mô tả kiểm thử hộp đen............................................................................10

Hình 2.5: Các loại kiểm thử hộp đen........................................................................11

Hình 2.6: Các loại chính của kiểm thử chức năng....................................................13

Hình 2.7: Các loại chính của kiểm thử phi chức năng_a..........................................14

Hình 2.8: Các loại chính của kiểm thử phi chức năng_b..........................................15

Hình 2.9: Các cấp độ kiểm thử phần mềm_a............................................................17

Hình 2.10: Các cấp độ kiểm thử phần mềm_b..........................................................18

Hình 2.11: Kiểm tra đơn vị.......................................................................................19

Hình 2.12: Kiểm tra tích hợp....................................................................................20

Hình 2.13: Phương pháp tiếp cận Big Bang.............................................................21

Hình 2.14: Minh họa cách tiếp cận từ trên xuống.....................................................22

Hình 2.15: Minh họa cách tiếp cận từ dưới lên.........................................................23

Hình 2.16: Mô hình...................................................................................................24

Hình 2.17: Kiểm tra hệ thống...................................................................................25

Hình 2.18: Kiểm tra chấp nhận.................................................................................26

Hình 3.1: Ví dụ về phân vùng tương đương.............................................................32

Hình 3.2: Giá trị biên................................................................................................33

Hình 3.3: Các ký hiệu được sử dụng trong đồ thị Nguyên nhân-Kết quả.................34

Hình 4.1: Các ký hiệu được sử dụng trong đồ thị Nguyên nhân-Kết quả.................36
 ix

Hình 4.2: Selenium IDE............................................................................................37

Hình 4.3: Robot Framework.....................................................................................37

Hình 5.1: Vòng đời...................................................................................................39

Hình 5.2: Mô hình thác nước không liên lạc............................................................40

Hình 5.3: Mô hình vòng lặp......................................................................................40

Hình 5.4: Mô hình vòng xoắn...................................................................................41

Hình 5.5Mô hình Agile.............................................................................................41

Hình 5.6: Mô hình chữ V (Rapid Application Development)..................................42

Hình 5.7: Vòng đời các trạng thái của một lỗi phần mềm trong dự án.....................47

Hình 5.8: Qui trình xử lý của một lỗi phần mềm trong dự án..................................48
 x

DANH MỤC BẢNG BIỂU

Bảng 4.1: Thống kê kiểu thực thể trong tập VLSP 2016.................................................
 xi

DANH MỤC CÁC CHỮ VIẾT TẮT

BERT Bidirectional Encoder Representations from

Transformers

GEC Grammatical Error Correction

MLM Masked Language Model

NLP Natural Language Processing

NSP Next Sentence Prediction

 1

CHƯƠNG 1. MỞ ĐẦU VÀ TỔNG QUAN ĐỀ TÀI

1.1 Lý do chọn đề tài

Hiện nay, sự tiến bộ của công nghệ thông tin đang diễn ra như một cơn bão,
mở ra cánh cửa cho sự gia tăng đồng thời về quy mô và độ phức tạp của hệ thống
mạng và phần mềm. Phần mềm ngày càng trở nên phức tạp hơn với nhiều tính năng
được tích hợp để tối ưu hóa kết nối và đối mặt với nhiều thách thức phần mềm hơn.
Tuy nhiên, điều này cũng mang theo một loạt vấn đề, đặc biệt là các lỗi phần mềm,
có thể dẫn đến hậu quả nghiêm trọng đối với kinh tế và xã hội.

Những lỗi này có thể xuất phát từ việc phần mềm bị xâm nhập do không đủ
kiểm soát trước khi phát hành, gây nguy hiểm cho người dùng bằng cách chấm dứt
dịch vụ hoặc thậm chí là phá hủy thông tin cá nhân như số tài khoản ngân hàng, số
điện thoại, tin nhắn, và nhiều hơn nữa. Điều này làm nổi lên sự cần thiết của việc
kiểm tra, vì mỗi người trong chúng ta đều có khả năng phạm sai lầm. Một số lỗi có
thể không gây hại, nhưng những sai lầm khác có thể đánh đổi mức giá hoặc thậm
chí đe dọa tính mạng.

Kiểm thử phần mềm trở thành một bước quan trọng trong quá trình phát triển
sản phẩm, giúp cải thiện tính nhất quán và hiệu suất. Ưu điểm chính của thử nghiệm
là phát hiện và khắc phục lỗi một cách hiệu quả. Ngoài ra, thử nghiệm còn giúp so
sánh kết quả thực tế và kết quả mong đợi, từ đó nâng cao chất lượng sản phẩm.

Nếu phần mềm được sản xuất mà không trải qua quá trình kiểm thử, nó có
thể trở nên vô dụng hoặc thậm chí gây nguy hiểm. Lập kế hoạch test case là một
phần quan trọng của quy trình kiểm thử, giúp xác định bước cần thiết để kiểm thử
hệ thống, bao gồm các bước thực hiện trong hệ thống, giá trị dữ liệu đầu vào và kết
 2

quả kiểm thử dự kiến. Các trường hợp thử nghiệm giúp nhà phát triển và người thử
nghiệm xác định lỗi có thể xuất hiện trong quá trình phát triển hoặc bị bỏ sót trong
quá trình thử nghiệm.

Lợi ích của một test case hiệu quả bao gồm đảm bảo phạm vi kiểm tra tốt,
giảm hỗ trợ và bảo trì, tái sử dụng hộp kiểm tra, đảm bảo phần mềm đáp ứng yêu
cầu người dùng, nâng cao chất lượng và trải nghiệm người dùng, hài lòng khách
hàng, và tăng lợi nhuận. Điều này đặt ra thách thức lớn trong ngành công nghiệp
công nghệ ở Việt Nam, nơi nguồn nhân lực kiểm thử có hạn, đồng thời tạo nên sự
quan trọng của việc thiết kế test case trong kiểm thử phần mềm. Mục tiêu thực hiện đề
tài

Tìm hiểu các lý thuyết chung về phương pháp thử nghiệm và ứng dụng: khái
niệm cơ bản, quy trình thử nghiệm, phương pháp thử nghiệm, kỹ thuật và ứng dụng.
Bạn sẽ hiểu rõ hơn và sâu hơn về các vấn đề liên quan đến công nghệ phần mềm, lỗi
phần mềm và kiểm thử phần mềm.

Sử dụng kiến thức về kiểm thử phần mềm để viết kiểm thử cho một ứng
dụng cụ thể.
 3

CHƯƠNG 2. GIỚI THIỆU VỀ KIỂM THỬ PHẦN MỀM

2.1 Khái niệm kiểm thử phần mềm

Kiểm thử phần mềm đại diện cho một quy trình nhằm xác minh rằng phần
mềm thực tế đáp ứng đúng các yêu cầu được kỳ vọng và đảm bảo rằng nó không
chứa lỗi. Quá trình này có thể bao gồm việc thực hiện thủ công các thử nghiệm trên
các thành phần phần mềm hoặc hệ thống, cũng như sử dụng các công cụ tự động để
đánh giá một hoặc nhiều thuộc tính quan trọng (ISTQB-
CTFL_Syllabus_2018_v3.1.1.Pdf, n.d.). Mục tiêu chính của kiểm thử phần mềm là
xác định và báo cáo về các lỗi, lỗ hổng hoặc yêu cầu còn thiếu so với yêu cầu thực
tế.

Có nhiều định nghĩa về kiểm thử phần mềm, phản ánh quan điểm của những
người hoặc tổ chức khác nhau. Dưới đây là một số định nghĩa đáng chú ý:
- "Thử nghiệm là quá trình tạo ra niềm tin rằng một chương trình hoặc hệ
thống sẽ thực hiện những gì nó được bảo." (Hetzel 1973)
- "Kiểm thử là bất kỳ hoạt động nào đánh giá chức năng hoặc khả năng của
một chương trình hoặc hệ thống và xác định xem nó có đáp ứng các yêu cầu của nó
hay không." (Hetzel 1983)
- "Thử nghiệm là chạy một chương trình hoặc hệ thống để tìm lỗi." (Myers
1979)
- "Quá trình phân tích phần mềm để xác định sự khác biệt giữa các điều kiện
hiện có và yêu cầu (nghĩa là lỗi/thiếu sót/lỗi) và để đánh giá chức năng của phần
mềm sản phẩm." (Theo tiêu chuẩn ANSI/IEEE 1059)

2.1.1 Mục tiêu chính của kiểm thử phần mềm

Hãy tìm kiếm mọi lỗi (hoặc sự cố) có thể trong khoảng thời gian cụ thể. Đảm
bảo rằng phần mềm đáp ứng tất cả các thông số kỹ thuật cần thiết. Tối ưu hóa chất
lượng kiểm thử phần mềm bằng cách hạn chế nỗ lực và chi phí. Xây dựng các bài
 4

kiểm tra chất lượng cao, triển khai chúng một cách hiệu quả và ghi chép mọi lỗi một
cách chính xác, đồng thời tạo ra các báo cáo lỗi mang tính hữu ích. Phạm vi kiểm thử
phần mềm

Hình 2.1: Quy trình kiểm thử phần mềm

2.1.2 Các hoạt động của kiểm thử phần mềm

2.1.2.1 Thiết kế kế hoạch thử nghiệm

Xác định kế hoạch kiểm thử phần mềm bằng cách xác định:

● Quá trình kiểm tra và lịch trình kiểm tra hoạt động của nó.

● Yêu cầu và hạng mục kiểm tra.

● Chiến lược kiểm thử và các công cụ hỗ trợ..

2.1.2.2 Thiết kế Testcase và mô tả các thông số kỹ thuật

● Thiết kế phần mềm dựa trên các phương pháp tạo thử nghiệm được xác

định rõ ràng..

● Xác định các bài kiểm tra để đạt được phạm vi kiểm tra được nhắm mục

tiêu..

2.1.2.3 Thiết lập thông số thử nghiệm

 5

● Triển khai các công cụ và môi trường kiểm thử.

● Xác định bộ thử nghiệm..

2.1.2.4 Sử dụng và thực thi các bài kiểm thử

● Thực hiện các ca kiểm thử thủ công hoặc tự động. Báo cáo lỗi chương

trình bằng cách sử dụng một giải pháp có hệ thống.

2.1.2.5 Kiểm tra Quản lý và Đo lường

● Quản lý các hoạt động kiểm thử phần mềm, quản lý lịch kiểm thử, đo

lường mức độ phức tạp và chi phí kiểm thử

2.1.2.6 Kiểm thử tự động

● Định nghĩa và phát triển các công cụ kiểm thử phần mềm..

● Triển khai và sử dụng các công cụ kiểm thử phần mềm.

● Viết kịch bản và kiểm thử phần mềm..

2.1.2.7 Quản lý cấu hình thử nghiệm

● Quản lý và duy trì các phiên bản khác nhau của bộ thử nghiệm, môi

trường và công cụ thử nghiệm cũng như tài liệu cho các bản phát hành
sản phẩm khác nhau..

2.2 Các phương pháp kiểm thử

2.2.1 Kiểm thử tĩnh – Static Testing

Kiểm thử tĩnh là một dạng kiểm thử phần mềm mà không yêu cầu việc thực
thi mã nguồn. Quá trình này bao gồm kiểm tra và đánh giá tài liệu yêu cầu, tài liệu
thiết kế, và mã nguồn, cả tự động và thủ công, để phát hiện và xác định lỗi. Mục
 6

tiêu chính của kiểm thử tĩnh là nâng cao chất lượng của ứng dụng phần mềm bằng
cách phát hiện lỗi ở giai đoạn đầu của quá trình phát triển, mà được biết đến như
thử nghiệm xác minh. Quá trình này có thể được thực hiện trên nhiều loại tài liệu
làm việc, bao gồm thông số kỹ thuật, tài liệu thiết kế, mã nguồn, kế hoạch và trường
hợp kiểm thử.

Kiểm thử tĩnh cũng có thể được tự động hóa, thực hiện xác minh đầy đủ
thông qua việc phân tích cú pháp chương trình bằng trình thông dịch hoặc trình biên
dịch kiểm tra cú pháp. Các kỹ thuật kiểm thử tĩnh bao gồm một loạt các phương
pháp và công cụ, đảm bảo rằng mã nguồn và tài liệu đáp ứng các tiêu chuẩn và yêu
cầu xác định, giúp tối ưu hóa quá trình kiểm thử và nâng cao chất lượng của sản
phẩm phần mềm.

Phần mềm quản lý:

Quá trình thử nghiệm diễn ra trong giai đoạn sớm của Quy trình Phát triển
Độc lập Phần mềm (SLDC) và áp dụng cho một phần cụ thể của sản phẩm như
SRS, mã nguồn, hoặc thiết kế sản phẩm. Nó liên quan đến việc kiểm tra thủ công
các thành phần khác nhau của sản phẩm ở các giai đoạn trước đó. Đây là một dạng
đánh giá phổ biến, trong đó tạo ra một danh sách kiểm tra để đảm bảo rằng công
việc được ghi lại đáp ứng chất lượng mong muốn. Cấu trúc thử nghiệm này ít chính
thức và ít yêu cầu hơn, là quy trình dễ thực hiện và quản lý hơn so với quy trình
kiểm thử đăng ký.

Tổng quan về kỹ thuật cho thử nghiệm tĩnh này là một quá trình dễ dàng hơn
quá trình đăng ký, và nó không yêu cầu quy trình xác định cụ thể. Đây là một
phương pháp đánh giá cấp cao hơn kỹ thuật quản lý hoặc kỹ thuật quản lý vì nó còn
liên quan đến việc quản lý. Công nghệ này đánh giá và đánh giá sản phẩm để đảm
bảo rằng nó tuân thủ các tiêu chuẩn, hướng dẫn và thông số kỹ thuật trong quá trình
phát triển. Mặc dù không có quy trình xác định rõ ràng và phần lớn công việc được
 7

thực hiện bởi người điều hành, nhưng nó vẫn giúp bảo đảm chất lượng của sản
phẩm và tuân thủ các yêu cầu.Kiểm thử động - Dynamic Testing

Kiểm thử động hoạt động với phần mềm bằng cách cung cấp các giá trị đầu
vào và kiểm tra xem đầu ra có như mong đợi hay không bằng cách chạy một trường
hợp kiểm thử cụ thể, có thể chạy thủ công hoặc thông qua tự động hóa. Kiểm tra
động có thể được thực hiện khi mã được thực thi trong môi trường thực. Đó là một
quy trình xác nhận thực hiện kiểm tra chức năng [kiểm tra sự chấp nhận của đơn vị,
tích hợp, hệ thống và người dùng] và kiểm tra phi chức năng [kiểm tra hiệu suất,
khả năng sử dụng, khả năng tương tác] như khả năng phục hồi và an toàn]. Các
phương pháp kiểm tra động bao gồm:

Kiểm tra đơn vị: Nhà phát triển thực hiện kiểm tra đơn vị mỗi khi ứng dụng
được hoàn thành và bàn giao cho kỹ sư kiểm tra phần mềm. Nhà phát triển bắt đầu
thử nghiệm từng mô-đun hoặc ứng dụng một cách độc lập hoặc từng cái một. Và
quá trình này được gọi là kiểm tra thành phần. Kiểm thử tích hợp: Xác minh việc
thực hiện mối quan hệ giữa các thành phần khác nhau bởi các kỹ sư kiểm thử phần
mềm. Kiểm tra hệ thống: Kiểm tra được thực hiện trên toàn bộ hệ thống. Thông qua
thử nghiệm này, hệ thống được thiết kế để sử dụng tất cả các chức năng và đảm bảo
hoạt động và hiệu suất chính xác. Kiểm thử chấp nhận: Kiểm thử được thực hiện từ
quan điểm của người dùng cuối. Với thử nghiệm này, ứng dụng đã được đưa đến
người dùng.

2.3 Các kỹ thuật kiểm thử phần mềm

Có 3 kỹ thuật kiểm thử phần mềm chính đó là:

 Kiểm thử hộp trắng (White-box testing)

 Kiểm thử hộp đen (Black-box testing)

 Kiểm thử hộp xám (Grey-box testing)

 8

Hình 2.2: Các kỹ thuật kiểm thử phần mềm

2.3.1 Kiểm thử hộp trắng(White-box testing)

2.3.1.1 Định nghĩa

Hình 2.3: Kiểm thử hộp trắng

 9

Kiểm thử hộp trắng, hay còn được biết đến là kiểm thử hộp thủy tinh,
là một loại kiểm thử tập trung vào việc kiểm tra và đánh giá cấu trúc nội bộ, mã
hóa, và hạ tầng của phần mềm. Thường được gọi là kiểm thử hộp bên trong, kiểm
thử hộp mở, và kiểm thử hộp, quá trình này đặt trọng tâm vào việc kiểm tra các đầu
vào đã được xác định trước đối với đầu ra mong muốn. Kiểm thử hộp trắng thường
dựa trên hoạt động nội bộ của ứng dụng và chú trọng vào việc kiểm tra cấu trúc bên
trong.

Loại kiểm thử này đòi hỏi kỹ năng lập trình để thiết kế các trường hợp kiểm
thử. Mục tiêu chính của kiểm thử hộp trắng là tập trung vào việc đánh giá đầu vào
và đầu ra của phần mềm để cải thiện tính bảo mật. Trong quá trình kiểm thử hộp
trắng, lập trình viên kiểm tra từng dòng mã chương trình để đảm bảo tính đúng đắn
và an toàn của mã nguồn.

Các nhà phát triển thường thực hiện kiểm thử hộp trắng trước khi chuyển ứng dụng
hoặc phần mềm đó sang quá trình kiểm thử hộp đen. Sau khi hoàn tất kiểm thử hộp
trắng, họ gửi sản phẩm để thực hiện kiểm thử hộp đen. Trong giai đoạn này, nhà
kiểm thử kiểm tra và đánh giá ứng dụng, xác định lỗi và tạo báo cáo chi tiết để chia
sẻ với nhà phát triển và các bên liên quan.

2.3.1.2 Đặc điểm của kiểm thử hộp trắng(White-box testing)

Kiểm thử hộp trắng tập trung vào việc kiểm tra cấu trúc dữ liệu nội bộ của
một đơn vị phần mềm đang được thử nghiệm, dựa trên một thuật toán nhất định.
Mục tiêu của quá trình này là xác định xem đơn vị phần mềm đó có đáng để triển
khai hay không. Người thực hiện kiểm thử hộp trắng cần sở hữu kỹ năng và kiến
thức chuyên sâu để hiểu rõ chi tiết của mã nguồn đang được kiểm tra.

Công việc cập nhật các bài kiểm tra tích hợp hoặc kiểm tra hệ thống thường
đòi hỏi nhiều thời gian và nỗ lực, do đó, kỹ thuật kiểm thử hộp trắng thường được
 10

ưu tiên sử dụng để thử nghiệm ở mức đơn vị. Trong ngữ cảnh lập trình hướng đối
tượng, các bài kiểm tra đơn vị tập trung vào việc kiểm tra mọi tác vụ của một lớp
chức năng cụ thể.

Kiểm thử hộp trắng có hai chức năng chính:

● Kiểm tra các bài kiểm tra đang thực hiện.

● Kiểm tra luồng dữ liệu.

2.3.1.3 Đặc điểm của kiểm thử hộp trắng(White-box testing)

- Ưu điểm
 Kiểm thử hộp trắng tối ưu hóa mã để có thể phát hiện các lỗi ẩn.
 Kiểm thử hộp trắng có thể dễ dàng tự động hóa.
 Thử nghiệm này toàn diện hơn các phương pháp thử nghiệm khác vì
nó bao gồm tất cả các đường dẫn mã.
 Nó có thể hoạt động trong giai đoạn phát triển phần mềm mà không
cần giao diện người dùng đồ họa.
- Nhược điểm
 Kiểm thử hộp trắng mất quá nhiều thời gian khi xử lý các ứng dụng
phần mềm lớn.
 Kiểm thử hộp trắng tốn kém và khó khăn.
 Điều này có thể dẫn đến lỗi sản xuất vì nó chưa được các nhà phát
triển tinh chỉnh. Tổ hợp lệnh có thể gây ra lỗi.
 Kiểm thử hộp trắng đòi hỏi các lập trình viên chuyên nghiệp có kiến
thức chi tiết và hiểu ngôn ngữ lập trình cũng như cách thực hiện.

2.3.2 Kiểm thử hộp đen (Black-box testing)

2.3.2.1 Định nghĩa

 11

Kiểm thử hộp đen là một phương pháp kiểm thử phần mềm được thiết kế để
đảm bảo tính hoạt động của phần mềm mà không cần quan tâm đến cấu trúc nội bộ
hay mã nguồn của nó. Nguồn thông tin chính để thực hiện kiểm thử hộp đen là định
nghĩa về yêu cầu từ phía khách hàng. Trong quy trình này, người kiểm thử lựa chọn
một chức năng cụ thể và cung cấp giá trị đầu vào để kiểm thử chức năng đó, sau đó
xác minh xem chức năng đã tạo ra đầu ra như kỳ vọng hay không. Nếu chức năng
hoạt động chính xác, thử nghiệm sẽ được coi là thành công; ngược lại, nếu có sai
sót, thì kết quả sẽ được xem là không đạt.

Nhóm thử nghiệm sau đó báo cáo kết quả cho nhóm phát triển, và quá trình
kiểm thử tiếp tục với các chức năng khác. Trong trường hợp xảy ra vấn đề nghiêm
trọng, sự cố đó sẽ được báo cáo lại cho nhóm phát triển để khắc phục sau khi đã
kiểm tra tất cả các chức năng cần thiết.

Hình 2.4: Mô tả kiểm thử hộp đen

Các cách kiểm tra hộp đen:

● Phân vùng tương đương.

 12

● Phân tích giá trị giới hạn.

● Tất cả các thử nghiệm ghép đôi.

● Kiểm định mờ - kiểm định mờ.

● Thử nghiệm dựa trên mô hình.

● Ma trận truy xuất nguồn gốc.

● Nghiên cứu thử nghiệm.

● Thông số kỹ thuật - Thử nghiệm cơ bản.

 13

2.3.2.2 Các phân loại kiểm thử hộp đen

Hình 2.5: Các loại kiểm thử hộp đen

❖ Kiểm thử chức năng (Functional Testing)

Kiểm thử chức năng là một dạng kiểm thử phần mềm được áp dụng để xác
minh tính hoạt động của các chức năng trong một ứng dụng và đảm bảo rằng chúng
hoạt động đúng theo yêu cầu. Trong quá trình này, mỗi chức năng của ứng dụng
được thử nghiệm bằng cách cung cấp giá trị đầu vào, đánh giá kết quả đầu ra và so
sánh với giá trị mong đợi.

Kiểm thử chức năng thường có đặc điểm của kiểm thử hộp đen, nơi mục tiêu
chính là đảm bảo rằng ứng dụng hoặc hệ thống thực hiện chính xác theo các yêu cầu
đã được đặt ra. Phương pháp này tập trung vào các thông số kỹ thuật của ứng dụng
hơn là đối với mã nguồn thực tế. Người kiểm thử tập trung vào phần mềm mà
không chú ý đến các thành phần hệ thống.
 14

Mục tiêu của kiểm thử chức năng là kiểm tra các chức năng chính của ứng
dụng, bao gồm các luồng chính, chức năng sử dụng, và giao diện màn hình. Ví dụ,
trong quá trình kiểm thử chức năng, người kiểm thử có thể thử nghiệm tính năng
hiển thị thông báo lỗi để đảm bảo rằng người dùng có thể dễ dàng điều hướng trong
ứng dụng...

Cách “step by step” để chuyên viên kiểm thử tiến hành công việc kiểm thử
chức năng:

● Người kiểm tra thực hiện việc xác minh định nghĩa bài đăng của phần

mềm.

● Sau khi phân tích, người kiểm tra đặc tả tạo một kế hoạch.

● Sau khi thiết kế các bài kiểm tra, người kiểm tra thiết kế trường hợp kiểm

tra.

● Sau khi lập kế hoạch kiểm tra, người kiểm tra trường hợp tạo một tài liệu

ma trận có thể theo dõi.

● Người kiểm tra thiết kế các bài kiểm tra.

● Phân tích mức độ phù hợp để kiểm tra khu vực thử nghiệm được ứng

dụng bao phủ.

● Quản lý vấn đề nên làm gì để quản lý giải quyết vấn đề

Mục đích chính của kiểm thử chức năng (functional testing) là kiểm tra chức
năng của một thành phần. Kiểm thử chức năng được chia thành nhiều phần:

● Unit Testing

● Smoke Testing.
 15

● Sanity Testing.

● Interface Testing

● Integration Testing

● System Testing

● Regression Testing

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

Hình 2.6: Các loại chính của kiểm thử chức năng

❖ Kiểm thử Phi chức năng (Non-Functional Testing)

Kiểm thử phi chức năng là một loại kiểm thử phần mềm tập trung vào việc
kiểm tra các tham số không liên quan trực tiếp đến chức năng cụ thể của ứng dụng.
Các tham số này bao gồm độ tin cậy của phần mềm, kiểm thử tải, hiệu suất, và các
yếu tố liên quan đến trách nhiệm pháp lý. Mục tiêu chính của kiểm thử phi chức
năng là đánh giá các khía cạnh không chức năng của hệ thống.

Kiểm thử phi chức năng đặt ra các thách thức liên quan đến tốc độ đọc của
hệ thống, dựa trên các yếu tố phi chức năng. Các tham số này không được kiểm tra
 16

trước khi thực hiện kiểm thử chức năng. Điều này làm cho kiểm thử phi chức năng
trở nên quan trọng như kiểm thử chức năng trong việc đảm bảo sự hài lòng của
khách hàng.

Kiểm thử chức năng và phi chức năng đều là quan trọng trong quá trình phát
triển phần mềm mới. Trong khi kiểm thử chức năng xác minh độ chính xác của các
chức năng nội bộ, kiểm thử phi chức năng xác minh khả năng hoạt động trong môi
trường bên ngoài. Nó giúp xác định cách phần mềm được triển khai, cấu hình, và
thực thi.

Thử nghiệm phi chức năng sử dụng các chỉ số và thước đo để thu thập thông
tin chi tiết về hành vi của sản phẩm và các công nghệ sử dụng. Điều này giúp giảm
rủi ro sản xuất và chi phí lập trình liên quan.

Các loại của kiểm thử phi chức năng:

● Performance Testing

● Load Testing

● Resilience Testing

● Document Testing

● Stress Testing

● Security Testing

● Portability Testing

● Reliability Testing
 17

● Efficiency Testing

● Compatibility Testing,…

Hình 2.7: Các loại chính của kiểm thử phi chức năng_a
 18

Hình 2.8: Các loại chính của kiểm thử phi chức năng_b
2.3.2.3 Ưu, nhược điểm của kiểm thử hộp đen

- Ưu điểm
 Người kiểm tra không cần kiến thức kỹ thuật, kỹ năng lập trình hoặc
kỹ năng máy tính.
 19

 Người kiểm tra không cần phải tìm hiểu chi tiết về việc triển khai hệ
thống.
 Việc kiểm thử có thể được thực hiện bởi những người kiểm thử thuê
ngoài hoặc thuê ngoài.
 Các thử nghiệm ít phức tạp hơn vì chúng chỉ mô hình hóa hành vi của
một người dùng thông thường.
- Nhược điểm
 Khó tự động hóa.
 Yêu cầu mức độ ưu tiên, thường không thể giám sát tất cả người
dùng.
 Tính toán phạm vi kiểm tra là khó khăn.
 Nếu thử nghiệm không thành công, có thể khó tìm ra nguyên nhân cốt
lõi của vấn đề.
 Thử nghiệm có thể được thực hiện ở quy mô nhỏ hoặc trong môi
trường phi sản xuất.

2.3.3 Kiểm thử hộp xám(Grey-box testing)

Kiểm thử hộp xám là một phương pháp kiểm thử phần mềm kết hợp cả hai
yếu tố của kiểm thử hộp đen và hộp trắng. Phương pháp này cho phép kiểm thử
viên có quyền truy cập vào mã nguồn nội bộ của phần mềm để thiết kế các trường
hợp kiểm thử. Dựa vào cấp độ chức năng, kiểm thử hộp xám thực hiện kiểm thử
giống như kiểm thử hộp đen.

Trong quá trình kiểm thử hộp xám, kiểm thử viên thường xác định các lỗi cụ
thể trong ngữ cảnh của hệ thống mạng. Khi phát hiện lỗi, họ có thể can thiệp và sửa
đổi mã nguồn để khắc phục vấn đề, sau đó thực hiện kiểm thử lại trong thời gian
thực. Phương pháp này tập trung vào nhiều lớp của phần mềm phức tạp để mở rộng
phạm vi kiểm thử.
 20

Kiểm thử hộp xám thường được áp dụng trong các quy trình thử nghiệm tích
hợp và thử nghiệm thâm nhập. Bằng cách kết hợp hai phương pháp kiểm thử này,
đảm bảo rằng quá trình thử nghiệm:

- Sử dụng kiến thức về kiến trúc ứng dụng để xác định các lỗ hổng và lỗi.
- Đánh giá ứng dụng một cách khách quan và xác định các vấn đề về
UI/UX như một người dùng thực.
- Bao gồm tất cả các khía cạnh của chức năng ứng dụng.

2.4 Các cấp độ (chu trình) kiểm thử phần mềm

Kiểm thử phần mềm sử dụng nhiều phương pháp khác nhau tại các cấp độ
khác nhau. Trong lĩnh vực này, chúng ta thường chia thành bốn cấp độ kiểm thử:
kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống, và kiểm thử chấp nhận.

Hình 2.9: Các cấp độ kiểm thử phần mềm_a

 21

Hình 2.10: Các cấp độ kiểm thử phần mềm_b

2.4.1 Kiểm tra đơn vị (Unit Test)

Thử nghiệm đơn vị là giai đoạn kiểm thử phần mềm đầu tiên, nhằm kiểm tra
liệu các mô-đun phần mềm có đáp ứng các yêu cầu cụ thể hay không. Giai đoạn đầu
của thử nghiệm này liên quan đến việc phân tích từng đơn vị hoặc thành phần riêng
lẻ trong phần mềm. Nó cũng là cấp độ đầu tiên của kiểm thử chức năng.

Mục tiêu chính của việc thực hiện kiểm thử đơn vị là xác thực các thành
phần phần mềm với hiệu suất được đặt ra. Những lỗi phát sinh có thể được phát
 22

hiện và sửa chữa sớm trong quá trình phát triển phần mềm, giúp tiết kiệm thời gian
và nguồn lực cho việc khắc phục lỗi cũng như tăng độ tin cậy của mã nguồn.
Thường do các nhà phát triển thực hiện, quá trình này nên diễn ra trong giai đoạn
viết mã và ưu tiên được triển khai càng sớm càng tốt trong chu kỳ phát triển phần
mềm. Đối với người kiểm thử, việc này đòi hỏi sự hiểu biết sâu rộng về thiết kế và
mã nguồn chương trình.

Hình 2.11: Kiểm tra đơn vị

2.4.2 Kiểm thử tích hợp các đơn vị (Integration Testing)

Một cấp độ khác của kiểm thử phần mềm được gọi là kiểm thử tích hợp, diễn
ra sau giai đoạn kiểm thử đơn vị. Thường được sử dụng để kiểm tra luồng dữ liệu từ
một mô-đun hoặc thành phần sang các mô-đun khác.

Trong quá trình thử nghiệm tích hợp, người thử nghiệm kiểm tra các đơn vị
hoặc thành phần phần mềm hoặc mô-đun riêng lẻ trong một nhóm. Mục tiêu chính
của kiểm thử tích hợp là phát hiện lỗi trong sự tương tác của các thành phần hoặc
đơn vị tích hợp. Vì mỗi thành phần hoặc mô-đun hoạt động độc lập, việc kiểm tra
 23

luồng dữ liệu giữa các mô-đun phụ thuộc là cực kỳ quan trọng và được thực hiện
trong quá trình kiểm thử tích hợp.

Kiểm thử tích hợp chỉ bắt đầu sau khi kiểm thử chức năng của từng mô-đun
ứng dụng đã được hoàn tất thành công. Tóm lại, mục tiêu của kiểm thử tích hợp là
đánh giá tính chính xác của giao tiếp giữa tất cả các mô-đun.

Hình 2.12: Kiểm tra tích hợp

Có 4 phương pháp để áp dụng Intergration Testing:

Phương pháp tiếp cận Big Bang có nghĩa là tất cả các mô-đun được kiểm thử
bằng cách tích hợp chúng đồng thời. Phương pháp này thuận tiện cho các hệ thống
phần mềm nhỏ, nhưng khi áp dụng vào các hệ thống phần mềm lớn, có thể khó phát
hiện lỗi. Bởi vì thử nghiệm này có thể được thực hiện sau khi tất cả các mô-đun đã
hoàn tất, nhóm thử nghiệm sẽ có ít thời gian hơn để hoàn thành quy trình này. Điều
 24

này có thể dẫn đến việc bỏ qua các liên kết nội bộ và tăng rủi ro cho các mô-đun
quan trọng.

Hình 2.13: Phương pháp tiếp cận Big Bang

Phương pháp tiếp cận tăng dần (Incremental): Các mô-đun được thêm vào
một cách tăng dần, theo thứ tự hoặc khi cần thiết, và chúng cần phải có liên kết
logic. Thông thường, hai hoặc nhiều mô-đun được thêm vào và kiểm tra để đảm bảo
hoạt động đúng đắn. Quá trình này lặp lại cho đến khi tất cả các mô-đun được xác
minh thành công.

Phương pháp tiếp cận từ trên xuống (Top-Down): Chiến lược kiểm thử từ
trên xuống liên quan đến việc kiểm tra các mô-đun cấp cao hơn trước với các mô-
đun cấp thấp hơn, đến khi tất cả các mô-đun đều đã được kiểm tra thành công. Các
lỗi thiết kế chủ yếu có thể được xác định và sửa chữa nhanh chóng khi các mô-đun
 25

quan trọng đã được kiểm tra trước. Trong phương pháp này, chúng ta thêm vào từng
giai đoạn hoặc từng cái một và kiểm soát luồng dữ liệu theo cùng một thứ tự..

Hình 2.14: Minh họa cách tiếp cận từ trên xuống

Phương pháp từ dưới lên (Bottom-up): Chiến lược kiểm thử từ dưới lên tập
trung vào việc kiểm tra các mô-đun cấp thấp hơn trước với các mô-đun cấp cao hơn,
cho đến khi tất cả các mô-đun đều đã được kiểm tra thành công. Các mô-đun quan
trọng ở cấp cao nhất thường được kiểm tra cuối cùng, điều này có thể dẫn đến việc
phát hiện lỗi. Hoặc có thể nói rằng chúng ta thêm các mô-đun từ phía dưới lên và
kiểm tra luồng dữ liệu theo cùng một thứ tự.
 26

Hình 2.15: Minh họa cách tiếp cận từ dưới lên

Phương pháp thử nghiệm hỗn hợp (Hybrid): Kỹ thuật thử nghiệm này kết
hợp cả hai chiến lược kiểm tra từ trên xuống và từ dưới lên. Trong quá trình này,
các mô-đun cấp cao hơn được kiểm tra với các mô-đun cấp thấp hơn, và đồng thời,
các mô-đun cấp thấp hơn được kiểm tra cùng với các mô-đun cấp cao hơn. Rủi ro
xuất hiện lỗi giảm đi vì mỗi kết nối mô-đun đều được kiểm tra..
 27

Hình 2.16: Mô hình

2.4.3 Kiểm tra hệ thống (System testing)

Cấp độ thứ ba của kiểm thử phần mềm là kiểm thử hệ thống, trong đó chúng
ta kiểm tra cả yêu cầu chức năng và phi chức năng của phần mềm. Đây là các thử
nghiệm cuối cùng, trong đó môi trường thử nghiệm chạy đồng thời với môi trường
sản xuất.

Ở cấp độ thứ ba của kiểm thử phần mềm, chúng tôi thực hiện kiểm thử ứng
dụng như một hệ thống toàn diện. Quá trình thử nghiệm hệ thống này bao gồm việc
kiểm tra toàn bộ luồng của ứng dụng hoặc phần mềm từ đầu đến cuối, đồng thời
đóng vai trò như người dùng cuối. Chúng tôi kiểm tra tất cả các mô-đun cần thiết
của ứng dụng, đảm bảo rằng các chức năng cuối cùng hoặc chức năng cuối cùng
hoạt động một cách bình thường và kiểm tra cả sản phẩm như một hệ thống hoàn
chỉnh..
 28

Hình 2.17: Kiểm tra hệ thống

2.4.4 Kiểm tra chấp nhận (Acceptance testing)

Cấp độ cuối cùng và thứ tư của kiểm thử phần mềm là kiểm thử chấp nhận,
mục tiêu là đánh giá xem đặc tả hoặc các yêu cầu đã được đáp ứng hay không dựa
trên trải nghiệm sử dụng thực tế. Sau khi phần mềm đã trải qua ba cấp độ kiểm thử
trước đó (kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống), kiểm thử chấp
nhận đóng vai trò là cột mốc cuối cùng.
 29

Kiểm thử chấp nhận nhằm xác nhận rằng phần mềm làm đúng công dụng và
đáp ứng đúng các yêu cầu đặc tả. Trong quá trình này, các lỗi nhỏ mà người dùng
cuối có thể phát hiện khi sử dụng hệ thống trong môi trường thực tế cũng được
kiểm tra và sửa chữa. Tóm lại, kiểm thử chấp nhận là bước củng cố của tất cả các
quy trình kiểm thử đã được thực hiện trước đó, chúng tôi đảm bảo rằng phần mềm
đáp ứng mọi kỳ vọng của người sử dụng cuối..

Hình 2.18: Kiểm tra chấp nhận

 30

CHƯƠNG 3. THIẾT KẾ VÀ KHỞI TẠO TESTCASE

3.1 Khái niệm

Một trường hợp thử nghiệm là một tài liệu chứa các dữ liệu thử nghiệm, điều
kiện ban đầu, kết quả mong đợi và điều kiện sau được phát triển cho một kịch bản
thử nghiệm cụ thể, nhằm đảm bảo tuân thủ một yêu cầu cụ thể. Trường hợp thử
nghiệm đóng vai trò là điểm xuất phát để thực hiện thử nghiệm, và sau khi áp dụng
một tập hợp các giá trị đầu vào, ứng dụng sẽ nhận được kết quả cuối cùng và thoát
khỏi hệ thống tại điểm cuối, hay còn gọi là điều kiện thực hiện sau điều kiện.

Các trường hợp thử nghiệm thường được soạn thảo bởi đội ngũ QA hoặc các
thành viên nhóm thử nghiệm. Chúng có thể được sử dụng như một hướng dẫn từng
bước để thực hiện thử nghiệm trên hệ thống. Quá trình thử nghiệm bắt đầu sau khi
nhóm phát triển hoàn thành một tính năng hoặc bộ tính năng của hệ thống. Một tập
hợp hoặc chuỗi các trường hợp thử nghiệm thường được gọi là bộ thử nghiệm.

3.2 Vai trò của thiết kế testcase

Các trường hợp kiểm thử đặt ra các hoạt động cụ thể để kiểm tra hệ thống,
bao gồm các bước thực hiện trong hệ thống, giá trị dữ liệu đầu vào cần được áp
dụng vào hệ thống và kết quả kiểm thử dự kiến. Các trường hợp thử nghiệm giúp
nhà phát triển và người thử nghiệm xác định lỗi có thể xuất hiện trong quá trình
phát triển hoặc bị bỏ sót trong quá trình kiểm thử cụ thể. Những lợi ích của một
trường hợp thử nghiệm hiệu quả bao gồm:

● Đảm bảo phạm vi kiểm tra tốt.

● Giảm hỗ trợ và bảo trì phần mềm.

● hộp kiểm tra tái sử dụng.

 31

● Đảm bảo phần mềm đáp ứng yêu cầu của người dùng cuối. Nâng cao

chất lượng phần mềm và trải nghiệm người dùng.

● Sản phẩm chất lượng dẫn đến khách hàng hài lòng hơn.

● Khách hàng hài lòng hơn làm tăng lợi nhuận của công ty.

Mục đích của thiết kế test case là:

● Tìm nhiều lỗi nhất

● Chi phí và thời gian tối thiểu

3.3 Quy trình thiết kế test case

Th Xây dựng trường hợp kiểm thử để thử nghiệm phần mềm là quá trình tạo
ra các phương pháp kiểm thử nhằm phát hiện lỗi, sai sót và khiếm khuyết trong
phần mềm, đóng góp vào việc xây dựng một sản phẩm phần mềm đáng tin cậy.
Thiết kế trường hợp thử nghiệm đóng một vai trò quan trọng trong việc cải thiện
chất lượng phần mềm vì những lý do sau:

❖ Tạo các bài kiểm tra tốt nhất có thể bắt được càng nhiều lỗi và lỗi lập

trình càng tốt.

❖ Tạo các bài kiểm tra với chi phí thấp nhất và thời gian và công sức tối

thiểu.

Khi khách hàng trình bày nhu cầu kinh doanh, nhóm phát triển bắt đầu quá
trình phát triển và dự kiến sẽ mất 3,5 tháng để hoàn thành sản phẩm. Trong thời
gian đó, nhóm kiểm thử bắt đầu viết các trường hợp kiểm thử. Khi trường hợp kiểm
thử hoàn thành, chúng được chuyển đến quản trị kiểm thử để xem xét. Khi nhóm
phát triển đã hoàn thành sản phẩm, sản phẩm được chuyển giao cho nhóm kiểm thử.
 32

Kỹ sư kiểm thử không bao giờ xác minh yêu cầu khi kiểm thử tài liệu sản
phẩm, vì quá trình kiểm thử diễn ra liên tục và không phụ thuộc vào tâm trạng hay
chất lượng của người kiểm thử. Một phương pháp kiểm thử không hiệu quả là kiểm
thử ngẫu nhiên tất cả các đầu vào, và quá trình này thường sử dụng lựa chọn ngẫu
nhiên. Tuy nhiên, một tập hợp con của các giá trị đầu vào có thể.

Đối với việc chọn dữ liệu thử nghiệm một cách thông minh, có một số cách
tiếp cận. Số lượng lỗi tối đa có thể xảy ra, và việc chọn một tập hợp các trường hợp
thử nghiệm ngẫu nhiên không chắc là tối ưu hoặc gần tối ưu. Dưới đây là một số
cách để lựa chọn dữ liệu thử nghiệm một cách hiệu quả.

3.3.1 Kiểm thử hộp trắng

3.3.1.1 Bao phủ câu lệnh – Statement Coverage

Bao phủ câu lệnh là một trong những phương pháp kiểm thử phần mềm phổ
biến, thường được sử dụng trong kiểm thử hộp trắng. Thuật ngữ "overlay" xuất hiện
trong việc thiết kế trường hợp kiểm thử hộp trắng. Phương pháp này đòi hỏi thực
hiện mọi dòng mã nguồn ít nhất một lần. Nó được áp dụng để đếm tổng số lệnh
được thực thi trong mã nguồn và so sánh với tổng số lệnh có sẵn trong mã nguồn.
Trong quá trình kiểm thử hộp trắng, phạm vi bao phủ được xác định bởi các báo cáo
dựa trên cấu trúc của mã nguồn.

Trong đó, "số lượng câu lệnh được thực thi khi chạy test case" là số lượng
câu lệnh trong mã nguồn mà hướng dẫn kiểm thử đã thực hiện khi chạy một trường
hợp kiểm thử cụ thể. "Số lượng toàn bộ câu lệnh" là tổng số câu lệnh trong thành
phần hoặc hệ thống được xác định.
 33

Mã nguồn bao gồm nhiều thành phần như toán tử, phương thức, mảng, vòng
lặp, câu lệnh, trình xử lý ngoại lệ, và nhiều thành phần khác. Tùy thuộc vào đầu vào
được cung cấp cho chương trình, một số hướng dẫn mã có thể được thực thi trong
khi một số khác có thể không được thực hiện. Mục tiêu của kỹ thuật nhúng câu lệnh
là bao gồm tất cả các câu lệnh có thể xuất hiện và tất cả các đường dẫn thực thi
trong mã nguồn.

Ví dụ: Ta có đoạn code như sau và khi nhập vào kịch bản là a = 5, b=4;
print (int a, int b) {
int sum = a+b;
if (sum>0)
print ("This is a positive result")
else
print ("This is negative result")
}
Chúng ta có thể thấy giá trị của tổng sẽ là 9 lớn hơn 0 và theo điều kiện kết
quả sẽ là "This is a positive result “. Có 5 câu lệnh được thực thi của kịch bản này.
Để tính toán mức độ phù hợp của câu lệnh của tình huống đầu tiên, hãy lấy tổng số
câu lệnh là 7 và số câu lệnh được sử dụng là 5. Thế nên độ bao phũ sẽ bằng.

Độ bao phủ câu lệnh = = 71%

3.3.2 Bao phủ quyết định – Decision Coverage

Kỹ thuật bao phủ quyết định là một phương pháp kiểm thử hộp trắng được
thiết kế để cung cấp bao phủ cho các giá trị Boolean trong mã nguồn. Phương thức
này chú trọng vào các câu lệnh điều khiển như câu lệnh do while, câu lệnh if và câu
lệnh switch, nơi mà có hai hoặc nhiều kết quả có thể xuất hiện.
 34

Nếu câu lệnh đó có thể có hai hoặc nhiều kết quả (đúng hoặc sai), nó được
coi là một điểm quyết định. Vùng quyết định là tập hợp của tất cả các kết quả có thể
xảy ra từ các điều kiện boolean trong mã, và nó thường được mô tả bằng biểu đồ
kiểm soát hoặc lưu đồ.

Một điểm quyết định thường có hai giá trị quyết định, một là đúng và một là
sai. Tổng kết quả của một điểm quyết định là hai. Khoảng quyết định tỷ lệ phần
trăm được xác định bằng cách chia số kết quả thu được cho tổng số kết quả và nhân
với 100, đo lường mức độ bao phủ quyết định của bài kiểm thử.

Hình 3.2 Công thức tính độ bao phủ quyết định

3.3.3 Bao phũ điều kiện – Condition Coverage

Phạm vi nhánh là một phương pháp kiểm thử hộp trắng được sử dụng để bao
phủ tất cả các nhánh của sơ đồ luồng điều khiển trong mã nguồn. Mục tiêu là đảm
bảo rằng mọi chi nhánh tại mọi điểm quyết định đều được thực thi ít nhất một lần,
bao gồm cả kết quả đúng và sai đối với mỗi điều kiện của điểm quyết định.

Phạm vi nhánh có mục tiêu là bao phủ mọi nhánh từ mọi điểm quyết định
trong mã nguồn. Các kỹ thuật bao gồm cả kỹ thuật bảo vệ độ phân giải và bảo vệ
nhánh, với sự chú ý đặc biệt đến việc đảm bảo rằng mỗi nhánh đều đã được thực thi.

Có nhiều số liệu khác nhau có thể được sử dụng để đo lường mức độ phủ
nhánh và quyết định, nhưng một số số liệu đơn giản bao gồm tỷ lệ phần trăm của
chương trình và đường dẫn thực thi trong quá trình chạy. Sơ đồ luồng điều khiển
 35

thường được sử dụng để đếm số lượng nhánh và đường dẫn đã được thực thi, cung
cấp thông tin về mức độ bao phủ của kiểm thử.

3.3.4 Kiểm thử hộp đen

3.3.4.1 Phân lớp tương đương – Equivalence Partitioning

Phân vùng tương đương là một kỹ thuật kiểm thử phần mềm trong đó dữ liệu
đầu vào được chia thành các phân vùng có điều kiện tương đương, trong đó mỗi
phân vùng chứa các giá trị đầu vào có cùng các điều kiện tương đương. Nguyên tắc
cơ bản của phương pháp này là nếu một điều kiện là đúng cho một phần trong một
phân vùng, thì tất cả các điều kiện khác trong cùng phân vùng đó cũng phải là đúng,
và nếu một điều kiện là sai, thì tất cả các điều kiện khác trong cùng phân vùng phải
là sai.

Phân vùng tương đương giúp giảm số lượng trường hợp thử nghiệm cần
kiểm tra, bằng cách giảm bớt những trường hợp thử nghiệm không cần thiết. Các
phân vùng tương đương có thể được xác định từ yêu cầu phần mềm và các thông số
kỹ thuật. Phương pháp này giúp giảm thời gian thử nghiệm và có thể được áp dụng
ở mọi cấp độ trong quá trình kiểm thử.
 36

Hình 3.19: Ví dụ về phân vùng tương đương

3.3.4.2 Phân tích giá trị biên – Boundary Value Analysis

Phân tích giá trị biên là một kỹ thuật thiết kế kiểm thử hộp đen phổ biến,
thường được sử dụng để kiểm thử các giá trị gần giới hạn của đầu vào. Điều này là
do giá trị đầu vào gần giới hạn thường mang theo rủi ro lớn về lỗi. Trong quá trình
thực hiện kiểm thử phân tích giá trị biên, người kiểm thử tập trung vào việc đảm
bảo rằng phần mềm đưa ra kết quả chính xác khi xử lý các giá trị biên.

Giá trị giới hạn là giá trị tối thiểu hoặc tối đa mà một biến có thể có. Ví dụ,
nếu có một biến "tuổi" trong một hàm và giá trị tối thiểu là 18 và giá trị tối đa là 30,
thì 18 và 30 được coi là các giá trị giới hạn.

Phương pháp này tập trung vào tạo ra các trường hợp thử nghiệm với các giá
trị biên, vì những giá trị này thường có khả năng gây ra nhiều lỗi nhất. Điều này
 37

giúp tăng cường chất lượng của quá trình kiểm thử bằng cách chú ý đặc biệt đến các
điểm mà có thể gây lỗi.

Hình 3.20: Giá trị biên

3.3.4.3 Đồ thị nguyên nhân kết quả -- Cause and Effect Graph

Sơ đồ nhân quả là một phần quan trọng của kỹ thuật kiểm thử hộp đen, nó
tập trung vào việc hiểu rõ mối quan hệ giữa kết quả mong đợi và các yếu tố ảnh
hưởng đến kết quả đó. Kỹ thuật này thường được sử dụng để xây dựng các trường
hợp thử nghiệm động, đặc biệt là khi mã chương trình phụ thuộc vào đầu vào của
người dùng.

Ví dụ cụ thể có thể là khi sử dụng tài khoản email: nếu bạn nhập một địa chỉ
email hợp lệ, hệ thống sẽ chấp nhận, ngược lại, nếu bạn nhập địa chỉ email không
hợp lệ, hệ thống sẽ hiển thị thông báo lỗi.

Sơ đồ nhân quả đặt điều kiện đầu vào làm nguyên nhân và kết quả của điều
kiện đầu vào này làm hiệu ứng. Bằng cách này, nó giúp xác định trường hợp kiểm
thử nhỏ nhất có thể bao phủ toàn bộ khu vực kiểm thử phần mềm. Sự ứng dụng của
sơ đồ nhân quả giúp giảm thiểu số lượng trường hợp thử nghiệm cần thiết, đồng
thời tối ưu hóa chất lượng kiểm thử và giảm thiểu thời gian và chi phí thực hiện thử
nghiệm.
 38

Hình 3.21: Các ký hiệu được sử dụng trong đồ thị Nguyên nhân-Kết quả
3.3.4.4 Đoán lỗi – Error Guessing

Ước tính lỗi là một kỹ thuật kiểm thử hộp đen không sử dụng phương pháp
cụ thể để phát hiện lỗi, mà thay vào đó dựa vào sự hiểu biết và kinh nghiệm của
người kiểm thử. Trong phương pháp này, người kiểm thử đoán các vấn đề có thể
xuất hiện trong phần mềm dựa trên kinh nghiệm của họ, không tuân theo cấu trúc cụ
thể để tìm lỗi.

Mỗi kỹ sư kiểm thử chọn giá trị hoặc đầu vào dựa trên sự hiểu biết hoặc giả
định của họ về yêu cầu, và không áp dụng bất kỳ quy tắc cụ thể nào để xác định lỗi
giả định kỹ thuật. Thực hiện kỹ thuật ước tính lỗi phụ thuộc vào khả năng và kiến
thức cá nhân về sản phẩm của người kiểm thử, với giả định rằng kỹ sư kiểm thử có
thể nắm bắt nhiều lỗi có thể xuất hiện.

Mục đích chính của kỹ thuật ước tính lỗi là xử lý tất cả các lỗi có thể xảy ra
mà không thể phát hiện được trong thử nghiệm không chính thức. Các trường hợp
thử nghiệm được chọn để đảm bảo rằng không có vấn đề nào bị bỏ qua và không có
 39

trường hợp thử nghiệm dư thừa. Công nghệ này giúp bổ sung các tính năng chưa
được cải thiện trong thử nghiệm chính thức.

CHƯƠNG 4. TẦM QUAN TRỌNG CỦA KIỂM THỬ PHẦN

MỀM
4.1 Tầm quan trọng

Kiểm thử phần mềm đóng vai trò quan trọng trong quá trình phát triển để
đảm bảo rằng phần mềm đáp ứng được các yêu cầu chất lượng và hiệu suất. Nó
giúp xác định và sửa lỗi, đồng thời đảm bảo rằng ứng dụng hoạt động một cách
đáng tin cậy. Bằng cách này, kiểm thử phần mềm đóng góp vào việc xây dựng và
duy trì niềm tin của khách hàng đối với sản phẩm.

Quá trình kiểm thử phần mềm không chỉ giúp cải thiện chất lượng của phần
mềm mà còn giúp tiết kiệm chi phí và thời gian trong quá trình phát triển. Nó giúp
phát hiện lỗi ở giai đoạn sớm, nơi chúng có thể được sửa chữa một cách hiệu quả
hơn. Hơn nữa, kiểm thử đảm bảo rằng phần mềm là an toàn và bảo mật, đặc biệt là
trong bối cảnh ngày càng nhiều mối đe dọa an ninh mạng.

Tóm lại, kiểm thử phần mềm không chỉ là một phần của quá trình phát triển,
mà còn là một yếu tố quyết định đối với thành công của sản phẩm phần mềm trên
thị trường.
 40

Hình 4.22: Các ký hiệu được sử dụng trong đồ thị Nguyên nhân-Kết quả
4.2 Một số công cụ
 41

Hình 4.23: Selenium IDE

Hình 4.24: Robot Framework

42
 43

CHƯƠNG 5. CƠ BẢN VỀ PHẦN MỀM VÀ LỖI PHẦN MỀM

5.1 Phần mềm và các khái niệm liên quan

5.1.1 Khái niệm phần mềm

Phần mềm (Software) là một tập hợp các dữ liệu hoặc câu lệnh máy tính
được liên kết chặt chẽ với nhau, nhằm đưa ra hướng dẫn cho máy tính thực hiện các
chức năng cụ thể.

Phần mềm thực hiện nhiệm vụ của mình bằng cách trực tiếp gửi các chỉ thị
đến phần cứng (Hardware) hoặc cung cấp dữ liệu để phục vụ cho các chương trình
hoặc phần mềm khác.

Tùy vào mục đích hay đặc trưng mà chúng ta có thể chia phần mềm thành
nhiều loại khác nhau, điển hình như:
 Phần mềm hệ thống.
 Phần mềm ứng dụng
 Phần mềm lập trình
 Phần mềm mã nguồn mở
 Phần mềm mã nguồn đóng
 Phần mềm tiện ích
 Phần mềm độc hại….(Thomas, 2020)
 44

5.1.2 Vòng đời của phần mềm

Hình 5.25: Vòng đời

Quy trình phát triển phần mềm (SDLC), hay còn được gọi là vòng đời phát
triển ứng dụng, là một thuật ngữ được sử dụng trong lĩnh vực kỹ thuật hệ thống, hệ
thống thông tin và kỹ thuật phần mềm để miêu tả quy trình lập kế hoạch, xây dựng,
kiểm thử và triển khai hệ thống thông tin. SDLC đóng vai trò quan trọng trong quá
trình phát triển các dự án Công nghệ thông tin, mô tả các giai đoạn khác nhau của
dự án từ khi bắt đầu đến khi hoàn thành. Có nhiều mô hình hoặc phương pháp
SDLC khác nhau, bao gồm Waterfall, Spiral, Agile, Tạo mẫu nhanh, Tăng dần,
Đồng bộ, Ổn định và nhiều hơn nữa.….. (“Software Engineering: Software
Development Lifecycle (SDLC) - Weekly Sharing - ZenTao,” n.d.)
 45

Hình 5.26: Mô hình thác nước không liên lạc

Hình 5.27: Mô hình vòng lặp

 46

Hình 5.28: Mô hình vòng xoắn

Hình 5.29Mô hình Agile

 47

Hình 5.30: Mô hình chữ V (Rapid Application Development)

Vòng đời phát triển phần mềm (SDLC) bao gồm một loạt các giai đoạn quan
trọng để đảm bảo quá trình phát triển và triển khai phần mềm diễn ra một cách có tổ
chức và hiệu quả. Dưới đây là mô tả chi tiết về từng giai đoạn:

1. Phân Tích Yêu Cầu:

- Trong giai đoạn này, đội ngũ phân tích yêu cầu chú trọng vào việc hiểu rõ
và xác định yêu cầu của khách hàng.
- Đối mặt với sự không rõ ràng và mâu thuẫn từ phía khách hàng, các kỹ sư
giàu kinh nghiệm hợp tác để xây dựng và điều chỉnh cơ sở yêu cầu ban đầu.

2. Thiết Kế:
- Giai đoạn này tập trung vào xây dựng kiến trúc hệ thống để đảm bảo phần
mềm đáp ứng đầy đủ yêu cầu và có khả năng mở rộng trong tương lai.
 48

- Bao gồm cả thiết kế kiến trúc tổng thể và thiết kế chi tiết của từng phần
của hệ thống.

3. Thực Hiện (Lập Trình):

- Lập trình viên chuyển đổi thiết kế thành mã nguồn có thể chạy được, tận
dụng lợi thế của một thiết kế chi tiết và đầy đủ.

4. Kiểm Thử:
- Giai đoạn này liên quan đến việc kiểm thử phần mềm để đảm bảo tính
đúng đắn và độ tin cậy.
- Sử dụng nhiều phương pháp kiểm thử, kết hợp cả kiểm thử chức năng,
hiệu suất và bảo mật.

5. Triển Khai:
- Sau khi kiểm thử hoàn tất, sản phẩm được triển khai để sử dụng.
- Quá trình triển khai được thực hiện một cách an toàn và hiệu quả.

6. Bảo Trì:
- Giai đoạn này bao gồm việc duy trì và cập nhật phần mềm để giải quyết
vấn đề hoặc đáp ứng yêu cầu mới.
- Có thể yêu cầu nhiều thời gian hơn so với quá trình phát triển ban đầu.
(“SDLC - Software Development Life Cycle - Javatpoint,” n.d.)

5.2 Chất lượng phần mềm và đảm bảo chất lượng phần mềm

5.2.1 Khái niệm phần mềm

Chất lượng phần mềm là mức độ mà một hệ thống hoặc quy trình đáp ứng
các yêu cầu chức năng. Đây là yếu tố được cả nhà sản xuất và người dùng quan tâm.
Vì nó có ảnh hưởng trực tiếp đến quá trình trải nghiệm sản phẩm. (“Chất Lượng
Phần Mềm Là Gì?,” 2021)
 49

5.2.2 Những tiêu chí đánh giá chất lượng phần mềm

5.2.2.1 Tính chính xác

Trong bất kỳ phần mềm nào, độ chính xác luôn là một trong những tiêu chí
đánh giá quan trọng. Độ chính xác được xác định dựa trên đầu ra mà phần mềm
cung cấp, và hiện tại, các phần mềm thường không đạt được độ chính xác tuyệt đối,
mà thay vào đó đảm bảo độ chính xác tương đối cao hoặc rất cao.

5.2.2.2 Tính hiệu quả

Hiệu quả là lượng tài nguyên, nguồn lực, khả năng đáp ứng của phần mềm
khi người dùng đưa ra yêu cầu. Tiêu chí này được tính toán dựa trên một số yếu tố
như: hiệu quả công việc, cam kết, khối lượng kết quả, v.v.

5.2.2.3 Tính bảo mật, an toàn

Quyền riêng tư và bảo mật bao gồm khả năng bảo mật dữ liệu người dùng,
ngăn chặn các cuộc tấn công từ bên ngoài, kiểm soát hoạt động của hệ thống, v.v.
Từ đó, mức độ rủi ro và rò rỉ thông tin sẽ được giảm thiểu đến mức thấp nhất.

5.2.2.4 Sự hài lòng của người sử dụng

Bên cạnh các tiêu chí chủ quan trên, sự hài lòng của người tiêu dùng là một
trong những yếu tố quan trọng để đánh giá chất lượng của phần mềm. Suy cho
cùng, người dùng mới là người trải nghiệm và tương tác trực tiếp với sản phẩm. Vì
vậy, họ sẽ đưa ra đánh giá khách quan và chính xác nhất. (“Learn Software Testing
Tutorial - Javatpoint,” n.d.)

5.2.3 Khái niệm đảm bảo chất lượng phần mềm

Theo Daniel Galin: “Đảm bảo chất lượng phần mềm là một tập hợp các hành
động cần thiết được lập kế hoạch một cách có hệ thống để cung cấp đủ tin cậy rằng
quá trình phát triển phần mềm là phù hợp để thiết lập các yêu cầu kỹ thuật chức
năng cũng như các yêu cầu quản lý hoạt động và lập kế hoạch trong giới hạn ngân
sách. (“Tổng Quan về Đảm Bảo Chất Lượng Phần Mềm,” 2015)
 50

Đảm bảo chất lượng giúp tạo ra các sản phẩm và dịch vụ đáp ứng nhu cầu,
mong đợi và yêu cầu của khách hàng. Nó cung cấp các dịch vụ sản phẩm chất lượng
cao tạo niềm tin và sự trung thành của khách hàng.
Các tiêu chuẩn và quy trình được xác định bởi một chương trình đảm bảo
chất lượng giúp ngăn ngừa các lỗi, khiếm khuyết của sản phẩm trước khi chúng xảy
ra.

5.2.4 Quy trình đảm bảo chất lượng phần mềm

Phương pháp đảm bảo chất lượng có một chu kỳ xác định được gọi là chu
trình PDCA hoặc chu trình Deming. Các giai đoạn của chu trình này là:
 Lập kế hoạch (Planning) - Tổ chức phải lập kế hoạch và thiết lập các mục
tiêu của quá trình và xác định các quá trình cần thiết để cung cấp một sản
phẩm cuối cùng có chất lượng cao.
 Thực hiện - Phát triển và kiểm tra các quy trình cũng như “thực hiện” các
thay đổi trong quy trình
 Kiểm tra - Giám sát các quy trình, sửa đổi các quy trình và kiểm tra xem
chúng có đáp ứng các mục tiêu xác định trước hay không
 Hành động - Các kiểm soát viên đảm bảo chất lượng phải thực hiện các
hành động cần thiết để cải tiến các quy trình..

5.3 Lỗi phần mềm và quy trình xử lý lỗi phần mềm

5.3.1 Khái niệm lỗi phần mềm

Lỗi phần mềm là một khiếm khuyết, lỗ hổng bảo mật trong một chương trình
hoặc hệ thống máy tính khiến nó tạo ra kết quả không chính xác hoặc không mong
muốn hoặc hoạt động theo cách không được dự kiến.

5.3.2 Các loại lỗi phần mềm

Các thuật ngữ được sử dụng để gọi tên lỗi phần mềm gồm có: Defect (nhược
điểm), Fault (khuyết điểm), Failure (sự thất bại), Anomaly (sự bất thường),
 51

Variance (biến dị), Incident (rắc rối), Problem, Error, Bug, Inconsistency (mâu
thuẫn).
Tuy nhiên, các thuật ngữ thường gặp và sử dụng nhất là: Bug, Defect, Error
và Failure.
 BUG: Là lỗi trong một module hoặc hệ thống mà nó không thực hiện đúng
chức năng như yêu cầu
 DEFECT: Lỗi trong quá trình phát triển (coding) hoặc lỗi logic làm cho
chương trình hoạt động sai yêu cầu đề ra.
 ERROR: Là hành động của con người dẫn đến kết quả sai.
 FAILURE: chính là sự khác biệt giữa kết quả thực tế trên màn hình và kết
quả mong đợi của một function, hệ thống hoặc service nào đó. (“7 Loại Lỗi
Phần Mềm Mà Mọi Nhân Viên Kiểm Thử Nên Biết,” 2018)

5.3.3 Qui trình sửa chữa lỗi phần mềm

Vòng đời của một bug là con đường mà một bug đi qua trong suốt cuộc đời
của nó. Vòng đời của bug bao gồm các trạng thái sau:
 Mới: khi người kiểm tra ghi lại lỗi lần đầu tiên
 Đã chỉ định: khi một lỗi được raise và giao cho một lập trình viên cụ
thể
 Mở: khi người lập trình sửa lỗi
 Đã sửa lỗi: khi lập trình viên sửa xong lỗi
 Kiểm tra lại: Người kiểm tra kiểm tra xem lỗi đã được sửa chưa và có
lỗi mới hay không.
 Mở lại: Nếu lỗi không được giải quyết, người kiểm tra sẽ gửi lại lỗi
cho nhà phát triển. Lỗi phải trải qua cùng một vòng đời một lần nữa.
Có hai tình huống xảy ra lỗi nên mở lại.
o Nếu nhà phát triển sửa lỗi, người kiểm tra thử lại và lỗi vẫn tồn
tại sau khi kiểm tra lại, người kiểm tra mở lại lỗi và giao nó
cho nhà phát triển.
 52

o Lỗi có thể đã được sửa và đóng lại. Trong trường hợp này,
người kiểm tra nên mở lại lỗi đã đóng và gán nó cho nhà phát
triển.
 Bị hoãn: Lỗi sẽ được sửa trong phiên bản tiếp theo. Các lý do có thể là
do lỗi có mức độ ưu tiên thấp, thời gian phát hành ngắn hoặc lỗi
không ảnh hưởng đáng kể đến phần mềm.
 Bị từ chối: Các nhà phát triển sẽ chuyển sang status này nếu họ chứng
minh được đây không phải là lỗi. Điều này xảy ra khi tester hiểu nhầm
một tính năng và raise nó là một lỗi. Trong trường hợp này, lỗi sẽ bị
loại bỏ sau khi một trưởng nhóm khác xem xét.
 Trùng lặp: Lỗi này đã xuất hiện và được raise trước đó.
 Kết thúc: khi người kiểm tra xác nhận rằng lỗi đã được sửa hoàn toàn
 Không có lỗi / cải tiến: Có một số thay đổi trong ứng dụng, nhưng
không có lỗi
 53

Hình 5.31: Vòng đời các trạng thái của một lỗi phần mềm trong dự án
 54

Hình 5.32: Qui trình xử lý của một lỗi phần mềm trong dự án
Qui trình xử lý lỗi có thể bao gồm 6 bước chính:
 Bước 0: Bắt đầu: Phát hiện phần mềm có lỗi
 Bước 1: Đưa lỗi lên hệ thống quản lý lỗi
 Bước 2: Gán lỗi cho nhân viên phát triển
 Bước 3:Xử lý lỗi
 55

 Bước 4: Kiểm thử lại

 Bước 5: Đóng lỗi

5.3.3.1 Xử lý lỗi

Các developer xem xét các lỗi được chỉ định cho họ.
 Nếu lỗi trở thành đúng và lỗi được mô tả rõ ràng và đầy đủ, nhà phát
triển nên sửa lỗi và đưa lỗi về trạng thái đã giải quyết.
 Các trường hợp khác: Nếu đó không phải là lỗi hệ thống, nhà phát
triển yêu cầu người kiểm tra cung cấp thêm thông tin. Ngoài ra, nếu
đó là một lỗi nhưng lỗi có thể được chấp nhận, nhóm phát triển sẽ
chuyển lỗi sang trạng thái ĐÃ XÁC NHẬN và cho biết lý do di
chuyển. Chuyển sang trạng thái ĐÃ XÁC NHẬN trong phần NOTE.

5.3.3.2 Kiểm thử lại

Theo sự phân công của Trưởng nhóm kiểm tra, người kiểm tra sẽ kiểm tra lại
các tính năng không thành công ở trạng thái RESOLVED
 Khi lỗi được giải quyết, hãy đặt lại lỗi về trạng thái CLOSED.
 Nếu lỗi chưa được sửa hoặc chỉ được sửa một phần, hãy đưa lỗi về
trạng thái ASSIGNED, cho biết phần chức năng chưa được sửa và cho
phép nhà phát triển thực hiện các bản sửa lỗi bổ sung.
 Nếu lỗi được phát hiện được chấp nhận, hãy đặt lại lỗi về trạng thái
CHẤP NHẬN. Đồng thời, việc cập nhật kịch bản kiểm tra dẫn đến lỗi
trong trường hợp này (vì nó vẫn là một lỗi).
 56

CHƯƠNG 6. KẾT LUẬN

6.1 Kết luận

6.2 Hướng phát triển

 57

TÀI LIỆU THAM KHẢO

Tiếng Việt
7 loại lỗi phần mềm mà mọi nhân viên kiểm thử nên biết. (2018, January 24).
Retrieved January 8, 2024, from https://viblo.asia/p/7-loai-loi-phan-mem-ma-moi-
nhan-vien-kiem-thu-nen-biet-bJzKmkvXl9N
Chất lượng phần mềm là gì? 4 tiêu chí đánh giá chất lượng phần mềm.
(2021, February 4). Retrieved January 8, 2024, from Blog | Got It Vietnam website:
https://vn.got-it.ai/blog/chat-luong-phan-mem-la-gi
Tổng quan về đảm bảo chất lượng phần mềm. (2015, March 31). Retrieved
January 8, 2024, from https://viblo.asia/p/tong-quan-ve-dam-bao-chat-luong-phan-
mem-al5XRBbLRqPe
Tiếng Anh
ISTQB-CTFL_Syllabus_2018_v3.1.1.pdf. (n.d.). Retrieved from https://istqb-
main-web-prod.s3.amazonaws.com/media/documents/ISTQB-
CTFL_Syllabus_2018_v3.1.1.pdf
Learn Software Testing Tutorial—Javatpoint. (n.d.). Retrieved January 8,
2024, from https://www.javatpoint.com/software-testing-tutorial
SDLC - Software Development Life Cycle—Javatpoint. (n.d.). Retrieved
January 8, 2024, from https://www.javatpoint.com/software-engineering-software-
development-life-cycle
Software Engineering: Software Development Lifecycle (SDLC)—Weekly
Sharing—ZenTao. (n.d.). Retrieved January 8, 2024, from
https://www.zentao.pm/blog/SDLC-software-engineering-software-development-
lifecycle-811.html
Thomas, M. (2020, November 10). A Complete Guide to Different Types of
Software. Retrieved January 8, 2024, from Coderus website:
https://www.coderus.com/software-101-a-complete-guide-to-the-different-types-of-
software/
58