HỌC VIỆN KỸ THUẬT MẬT MÃ

KHOA CÔNG NGHỆ THÔNG TIN

ĐỒ ÁN MÔN HỌC

KIỂM THỬ PHẦN MỀM

NHÚNG
Đề tài:

KIỂM THỬ THỦ CÔNG CHỨC NĂNG CHO

WEBSITE

LINHKIENCHATLUONG.VN

Sinh viên thực hiện: HOÀNG TRỌNG TUYÊN CT030258

BÙI ĐÌNH HÙNG CT0302225
 TRẦN MINH QUẢNG CT030245
CAO NGỌC HIỀN CT030219
Nhóm 7
Giảng viên hướng dẫn: THÁI THỊ THANH VÂN

Hà Nội, 11-2021
 LỜI NÓI ĐẦU

Trong thời buổi công nghệ thông tin có mặt khắp các lĩnh vực, các tổ chức cá
nhân, doanh nghiệp ngày càng phát triển mạnh mẽ. Nhu cầu sử dụng các phần mềm
để thực hiện các công việc được nhanh chóng, chính xác và hiệu quả ngày càng
tăng. Việc đảm bảo chất lượng phần mềm ngày càng trở nên quan trọng. Bên cạnh
các phần mềm truyền thống, người ta còn sử dụng các phần mềm chạy trên nền
web. Chính vì điều đó website ngày càng được sử dụng rộng rãi. Ngoài ra, để đáp
ứng nhu cầu chia sẻ thông tin, cũng như truyền tải thông tin một cách nhanh chóng
và tiếp cận với nhiều người nhất thì website chính là phương tiện có khả năng làm
tốt nhất việc đó.
Các website được phát triển một cách cực kỳ mạnh mẽ và nhanh chóng. Tuy
nhiên, đi cùng với sự phát triển vượt bậc và tiện lợi như thế thì cũng có không ít các
trở ngại dẫn đến việc website không được hoạt động một cách hiệu quả nhất. Do đó,
cần thiết phải kiểm thử và đảm bảo chất lượng của website.
Nhóm em xin gửi lời cảm ơn chân thành đến giảng viên hướng dẫn cô Thái Thị
Thanh Vân – Giảng viên bộ môn Kiểm thử phần mềm Nhúng, nhóm em thực hiện
đề tài “Kiểm thử thủ công chức năng cho website linhkienthongminh.vn” và thực
hiện trên website có sẵn nhưng vẫn còn thiếu sót trong việc phát triển. Do hạn chế
về mặt kiến thức cho nên không thể tránh khỏi sai sót trong quá trình làm báo cáo,
nhóm em rất mong được sự góp ý từ cô và các bạn.

Nhóm em xin chân thành cảm ơn!

 MỤC LỤC

DANH MỤC CÁC HÌNH........................................................................................3

TÓM TẮT NỘI DUNG...........................................................................................4
Chương 1: Tổng quan về kiểm thử phần mềm...................................................4
Chương 2: Thiết kế test-case.............................................................................4
Chương 3: Áp dụng...........................................................................................4
CHƯƠNG 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM..............................5
1.1. TỔNG QUAN......................................................................................................5
1.1.1. Kiểm thử phần mềm.................................................................................5
1.1.2. Các phương pháp kiểm thử......................................................................5
1.1.2.1. Kiểm thử tĩnh....................................................................................5
1.1.2.2. Kiểm thử động..................................................................................5
1.2. KIỂM THỬ THỦ CÔNG.......................................................................................6
1.2.1. Khái niệm................................................................................................6
1.2.2. Mục tiêu của kiểm thử thủ công...............................................................6
1.2.3. Các loại kiểm thử thủ công......................................................................6
1.2.3.1. Kiểm thử hộp đen.............................................................................6
1.2.3.2. Kiểm thử hộp trắng...........................................................................7
1.2.3.3. Kiểm thử đơn vị - Unit Test..............................................................8
1.2.3.4. Kiểm thử tích hợp - Intergration Test.............................................10
1.2.3.5. Kiểm thử hệ thống - System Test....................................................14
1.2.3.6. Kiểm thử chấp nhận hệ thống - Acceptance Test............................14
CHƯƠNG 2: THIẾT KẾ TEST-CASE.............................................................17
2.1. KHÁI NIỆM......................................................................................................17
2.2. VAI TRÒ THIẾT KẾ TEST-CASE........................................................................17
2.3. QUY TRÌNH THIẾT KẾ TEST-CASE....................................................................17
2.3.1. Kiểm thử hộp trắng................................................................................18
2.3.1.1. Kiểm thử luồng điều khiển..............................................................18
2.3.1.2. Kiểm thử bao phủ...........................................................................20
2.3.2. Kiểm thử hộp đen..................................................................................21
2.3.2.1. Phân vùng tương đương..................................................................21
2.3.2.2. Phân tích giá trị biên.......................................................................21
2.3.2.3. Kỹ thuật bảng quyết định................................................................21
2.3.2.4. đồ thị nguyên nhân- kết quả............................................................22
2.3.2.5. Kỹ thuật đồ thị chuyển đổi trạng thái..............................................22
CHƯƠNG 3: ÁP DỤNG.....................................................................................23
3.1. XÂY DỰNG KẾ HOẠCH KIỂM THỬ...................................................................23
3.1.1. Mục đích và phạm vi kiểm thử...............................................................23
3.1.1.1. Mục đích của kiểm thử...................................................................23
3.1.1.2. Phạm vi của kiểm thử.....................................................................23
3.1.2. Định hướng cho kế hoạch......................................................................23
3.1.3. Các chức năng cần kiểm thử.................................................................24
3.1.4. Định nghĩa vai trò từng các nhân trong nhóm.......................................24
3.1.5. Các môi trường kiểm thử.......................................................................25
3.2. THIẾT KẾ TEST CASE.......................................................................................26
3.3. ĐIỀU KIỆN DỪNG VIỆC KIỂM THỬ...................................................................26
3.4. ĐÁNH GIÁ KẾT QUẢ KIỂM THỬ.......................................................................26
TÀI LIỆU THAM KHẢO.....................................................................................28
 DANH MỤC CÁC HÌNH

Hình 1: Mô hình kiểm thử tích hợp Big Bang.........................................................11

Hình 2: Mô hình tích hợp kiểm thử Top Down.......................................................12
Hình 3: Mô hình tích hợp kiểm thử Bottom Up.......................................................13
 TÓM TẮT NỘI DUNG

Bản báo cáo được chia thành chương với nội dung như sau:

Chương 1: Tổng quan về kiểm thử phần mềm

Chương này là cái nhìn tổng quan về kiểm thử phần mềm: các khái niệm cơ bản
về kiểm thử phần mềm, các quy tắc trong kiểm thử, và các phương pháp kiểm thử
phần mềm tiêu biểu.

Chương 2: Thiết kế test-case

Trong chương này, em đi tìm hiểu các phương pháp thiết kế test – case có hiệu
quả. Từ đó rút ra nhận xét về ưu nhược điểm của từng phương pháp.

Chương 3: Áp dụng
Từ những kiến thức đã tìm hiểu trong 2 chương trước, nhóm em áp dụng xây
dựng các Test-Case cho website bán đồ linh kiện
 CHƯƠNG 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM

1.1. Tổng quan

1.1.1. Kiểm thử phần mềm

- Là một tiến trình hay một tập hợp các tiến trình được thiết kế ra để:
 Đảm bảo phần mềm thực hiện đúng theo những thứ mà chúng đã được thiết kế.
 Trong quá trình sử dụng phần mềm không phát sinh bất cứ thứ gì không mong
muốn.
- Đây là một pha quan trọng trong quá trình phát triển hệ thống phần mềm:
 Giúp cho khách hàng thấy được sản phẩm đặt ra đã đáp ứng được yêu cầu hay
chưa.
 Giảm thời gian và chi phí phát sinh do bảo trì (fix lỗi) cho người viết phần mềm.

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

1.1.2.1. Kiểm thử tĩnh

- Khái niệm:
Là phương pháp kiểm thử phần mềm thủ công. Phương pháp này thường được
những người phân tích thiết kế phần mềm (IT-BA) thực hiện.
- Cách thực hiện:
Dùng giấy, bút và trí "tưởng tượng" để kiểm tra logic, kiểm tra từng chi tiết luồng
nghiệp vụ theo yêu cầu đề bài mà không cần chạy chương trình.
- Mục đích:
Cách làm này có thể sẽ giúp BA phát hiện ra những thiếu xót trong đề bài để bổ
sung tài liệu trước khi chuyển sang cho DEV.
Đôi khi static testing sẽ bị nhầm lẫn với việc BA đưa tài liệu cho các bên liên quan
(khách hàng/đại diện khách hàng/product owner) để review trước khi chuyển giao tài
liệu sang pharse mới (DEV).

1.1.2.2. Kiểm thử động

- Khái niệm:
 Phương pháp thử phần mềm thông qua việc chạy chương trình để theo dõi trạng
thái, kết quả của từng bước / toàn bộ các bước trong quá trình thực thi phần mềm.

5
  Cách thực hiện dựa trên các ca kiểm thử (test case) xác định bằng sự hoạt động
của đối tượng kiểm thử hay toàn bộ chương trình.
 Kiểm tra cách thức hoạt động động của mã lệnh, bao gồm luôn cả kiểm tra sự
phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian.

- Mục đích:
 Trong kiểm thử động, tester quan tâm đến dữ liệu đầu vào và output đầu ra.
 Với mỗi tập dữ liệu đầu vào sẽ phát sinh ra một tập dữ liệu output
 Nếu chương trình nhận đầu vào để “chạy” sau đó đưa ra dữ liệu output giống như
yêu cầu. Có thể nói đó là phần mềm đã hoạt động thành công.

1.2. Kiểm thử thủ công

1.2.1. Khái niệm

Kiểm thử thủ công: là tester làm mọi công việc hoàn toàn bằng tay, từ viết test case
đến thực hiện test, mọi thao tác như nhập điều kiện đầu vào, thực hiện một số sự kiện
khác như click nút và quan sát kết quả thực tế, sau đó so sánh kết quả thực tế với kết quả
mong muốn trong test case, điền kết quả test. Hiện nay, phần lớn các tổ chức, các công ty
phần mềm, hoặc các nhóm làm phần mềm đều thực hiện kiểm thử thủ công là chủ yếu.

1.2.2. Mục tiêu của kiểm thử thủ công

- Khái niệm chính của Manual Testing là đảm bảo rằng ứng dụng không có lỗi và nó
đang hoạt động tuân theo các yêu cầu chức năng được chỉ định.
- Bộ thử nghiệm hoặc trường hợp, được thiết kế trong giai đoạn thử nghiệm và phải có
phạm vi kiểm tra 100%.
- Nó cũng đảm bảo rằng các lỗi đã báo cáo đã được khắc phục bởi các nhà phát triển và
việc kiểm tra lại đã được thực hiện bởi những người kiểm tra đối với các lỗi đã sửa.
- Về cơ bản, loại kiểm thử này kiểm tra chất lượng của hệ thống và cung cấp sản phẩm
không có lỗi cho khách hàng và người dùng cuối cùng.

1.2.3. Các loại kiểm thử thủ công

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

- Khái niệm:
Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen,
hướng dữ liệu, hay hướng vào/ra. Kiểm thử hộp đen xem chương trình như là
một “hộp đen”. Mục đích của bạn là hoàn toàn không quan tâm về cách cư xử
6
 và cấu trúc bên trong của chương trình. Thay vào đó, tập trung vào tìm các
trường hợp mà chương trình không thực hiện theo các đặc tả của nó.
- Ưu điểm:
 Các tester được thực hiện từ quan điểm của người dùng và sẽ giúp đỡ trong việc
sáng tỏ sự chênh lệch về thông số kỹ thuật.
 Các tester theo phương pháp black box không có “mối ràng buộc” nào với code,
và nhận thức của một tester rất đơn giản: một source code có nhiều lỗi. Sử dụng
nguyên tắc, "Hỏi và bạn sẽ nhận" các tester black box tìm được nhiều bug ở nơi
mà các DEV không tìm thấy.
 Tester có thể không phải IT chuyên nghiệp, không cần phải biết ngôn ngữ lập
trình hoặc làm thế nào các phần mềm đã được thực hiện.
 Các tester có thể được thực hiện bởi một cơ quan độc lập từ các developer, cho
phép một cái nhìn khách quan và tránh sự phát triển thiên vị.
 Hệ thống thật sự với toàn bộ yêu cầu của nó được kiểm thử chính xác.
 Thiết kế kịch bản kiểm thử khá nhanh, ngay khi mà các yêu cầu chức năng được
xác định.
- Nhược điểm:
 Dữ liệu đầu vào yêu cầu một khối lượng mẫu (sample) khá lớn
 Nhiều dự án không có thông số rõ ràng thì việc thiết kế test case rất khó và do đó
khó viết kịch bản kiểm thử do cần xác định tất cả các yếu tố đầu vào, và thiếu cả
thời gian cho việc tập hợp này.
 Khả năng để bản thân kỹ sư lạc lối trong khi kiểm thử là khá cao.
 Chỉ có một số nhỏ các đầu vào có thể được kiểm tra và nhiều đường dẫn chương
trình sẽ được để lại chưa được kiểm tra.
 Kiểm thử black box được xem như "là bước đi trong mê cung tối đen mà không
mang đèn pin” bởi vì tester không biết phần mềm đang test đã được xây dựng như
thế nào. Có nhiều trường hợp khi một tester viết rất nhiều trường hợp test để kiểm
tra một số thứ có thể chỉ được test bằng một trường hợp test và/hoặc một vài phần
cuối cùng không được test hết.

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

- Khái niệm:
 Kiểm thử Hộp Trắng (còn gọi là Clear Box Testing, Open Box Testing, Glass Box
Testing, Transparent Box Testing, Code-Based Testing hoặc Structural Testing) là
một phương pháp kiểm thử phần mềm trong đó tester biết về cấu trúc nội bộ /

7
 thiết kế. Người kiểm tra chọn đầu vào để thực hiện các đường dẫn thông qua mã
và xác định đầu ra thích hợp. Kiến thức lập trình và kiến thức thực hiện là rất cần
thiết trong kiểm thử hộp trắng.
 Kiểm thử hộp trắng bao gồm phân tích dòng dữ liệu, điều khiển dòng, dòng thông
tin, mã thực hành, ngoại lệ và những lỗi trình bày trong hệ thống để kiểm tra
những hành động của phần mềm không được định hướng trước.
- Ưu điểm:
 Test có thể bắt đầu ở giai đoạn sớm hơn, không cần phải chờ đợi cho GUI để có
thể test
 Test kỹ càng hơn, có thể bao phủ hầu hết các đường dẫn
 Thích hợp trong việc tìm kiếm lỗi và các vấn đề trong mã lệnh
 Cho phép tìm kiếm các lỗi ẩn bên trong
 Các lập trình viên có thể tự kiểm tra
 Giúp tối ưu việc mã hoá
 Do yêu cầu kiến thức cấu trúc bên trong của phần mềm, nên việc kiểm soát lỗi tối
đa nhất.
- Nhược điểm:
 Vì các bài kiểm tra rất phức tạp, đòi hỏi phải có các nguồn lực có tay nghề cao,
với kiến thức sâu rộng về lập trình và thực hiện.
 Maintenance test script có thể là một gánh nặng nếu thể hiện thay đổi quá thường
xuyên.
 Vì phương pháp thử nghiệm này liên quan chặt chẽ với ứng dụng đang được test,
nên các công cụ để phục vụ cho mọi loại triển khai / nền tảng có thể không sẵn có.

1.2.3.3. Kiểm thử đơn vị - Unit Test

- Khái niệm:
 Là một loại kiểm thử phần mềm trong đó các đơn vị hay thành phần riêng lẻ của
phần mềm được kiểm thử.
 Kiểm thử đơn vị được thực hiện trong quá trình phát triển (coding) ứng dụng. Mục
tiêu của kiểm thử đơn vị là cô lập một phần code và xác minh tính chính xác của
đơn vị đó. Trong lập trình thủ tục, một đơn vị có thể là một chức năng hoặc thủ tục
riêng lẻ. Kiểm thử đơn vị thường được thực hiện bởi developer.
- Ưu điểm:

8
  Các developer muốn tìm hiểu chức năng nào được cung cấp bởi một đơn vị và
cách sử dụng chức năng này có thể xem xét các test cases kiểm thử đơn vị để có
được sự hiểu biết cơ bản về unit API.
 Kiểm thử đơn vị cho phép lập trình viên cấu trúc lại code vào một ngày sau đó và
đảm bảo mô-đun vẫn hoạt động chính xác (ví dụ: Kiểm thử hồi quy). Quy trình là
viết các trường hợp kiểm thử cho tất cả các hàm và phương thức để mỗi khi thay
đổi gây ra lỗi, nó có thể được xác định và sửa chữa nhanh chóng.
 Do tính chất mô-đun của kiểm thử đơn vị, chúng ta có thể kiểm thử các phần của
dự án mà không cần chờ người khác hoàn thành.
- Nhược điểm:
 Kiểm thử đơn vị không thể phát hiện được mọi lỗi trong một chương trình. Không
thể đánh giá tất cả các luồng thực hiện ngay cả trong các chương trình tầm thường
nhất
 Kiểm thử đơn vị theo bản chất là tập trung vào một đơn vị code. Do đó, kiểm thử
đơn vị không thể bắt lỗi tích hợp hoặc lỗi hệ thống lớn.
- Các kỹ thuật kiểm thử đơn vị:
 Statement Coverage:
o Statement Coverage đảm bảo rằng tất cả các dòng lệnh trong mã nguồn đã
được kiểm tra ít nhất một lần. Nó cung cấp các chi tiết của cả hai khối mã
được thực thi và thất bại trong tổng số các khối mã.
o Ưu điểm:
 Nó có thể được áp dụng trực tiếp vào mã đối tượng và không yêu
cầu xử lý mã nguồn.
 Nó xác minh những gì mã nguồn viết được dự kiến sẽ thực thi và
không thực thi
o Nhược điểm:
 Nó chỉ bao gồm các điều kiện “true” của mã nguồn.
 Statement Coverage hoàn toàn không quan tâm với các toán tử logic
(|| và &&).
 Decision Coverage:
o Các nhà phát triển không thể viết mã trong một chế độ liên tục, tại bất kỳ
điểm nào họ cần phân nhánh mã để đáp ứng các yêu cầu chức năng. Sự
phân nhánh trong mã thực sự là một bước nhảy từ điểm quyết định này
sang điểm khác. Decision coverage kiểm tra mọi đường dẫn có thể hoặc chi
nhánh trong mã được kiểm thử.

9
 o Decision coverage có thể được tính bằng cách tìm số đường dẫn tối thiểu để
đảm bảo rằng tất cả các cạnh đã được che phủ. Trong ví dụ đã cho, không
có đường dẫn duy nhất đảm bảo vùng phủ sóng của tất cả các cạnh cùng
một lúc.
o Ưu điểm:
 Nó bao gồm cả các điều kiện đúng và sai không có khả năng được
gọi trong statement coverage.
 Nó đảm bảo tất cả các nhánh được kiểm thử.
o Nhược điểm:
 Nó bỏ qua các nhánh trong các biểu thức Boolean xảy ra do các toán
tử ngắn mạch.
 Condition Coverage:
o Condition Coverage sẽ kiểm tra phạm vi điều kiện nếu cả hai kết quả (có
nghĩa là “true” hay “fail”) của mọi điều kiện đã được thực hiện. Kết quả
của điểm quyết định chỉ liên quan để kiểm tra các điều kiện. Nó đòi hỏi hai
trường hợp thử nghiệm cho mỗi điều kiện cho hai kết quả.

1.2.3.4. Kiểm thử tích hợp - Intergration Test

- Khái niệm:
 Kiểm thử tích hợp (Integration testing) hay còn gọi là tích hợp và kiểm
thử (integration and testing, viết tắt: I&T) là một giai đoạn trong kiểm thử phần
mềm. Mỗi môđun phần mềm riêng biệt được kết hợp lại và kiểm thử theo nhóm.
 Kiểm thử tích hợp xảy ra sau kiểm thử đơn vị (Unit Test) và trước kiểm thử xác
nhận. Kiểm thử tích hợp nhận các môđun đầu vào đã được kiểm thử đơn vị, nhóm
chúng vào các tập hợp lớn hơn, áp dụng các ca kiểm thử đã được định nghĩa
trong kế hoạch kiểm thử tích hợp vào tập hợp đó, và cung cấp đầu ra cho hệ thống
tích hợp.
- Vai trò kiểm thử tích hợp:
 Mỗi module được thiết kế bởi một developer độc lập, có kiến thức và logic lập
trình có thể khác với các developer khác. Kiểm thử tích hợp trở nên cần thiết để
xác minh các module trong phần mềm hoạt động thống nhất.
 Tại thời điểm phát triển các module, có thể có những thay đổi yêu cầu từ khách
hàng. Các yêu cầu mới này có thể không được unit testing, do đó kiểm thử tích
hợp hệ thống trở nên cần thiết.

10
  Các giao diện của các module trong phần mềm với cơ sở dữ liệu có thể không
tương thích.
 Khi tích hợp các module vào hệ thống có thể không tương thích với cấu hình
chung của hệ thống.
 Xử lý các ngoại lệ không đầy đủ có thể gây ra lỗi.
- Các phương pháp kiểm thử tích hợp:
 Kiểm thử tích hợp Big Bang:

11
Tất cả các thành phần được tích hợp cùng một lúc, sau đó tiến hành kiểm thử.

Hình 1: Mô hình kiểm thử tích hợp Big Bang

o Ưu điểm:
 Thuận tiện cho các hệ thống nhỏ.
 Mọi thứ đã kết thúc trước khi kiểm thử tích hợp bắt đầu.

12
 o Nhược điểm:
 Khó khăn trong việc phát hiện bug.
 Với số lượng giao diện cần được kiểm thử theo phương pháp này,
một số giao diện liên kết cần kiểm thử có thể dễ dàng bị bỏ qua.
 Vì kiểm thử Tích hợp chỉ có thể bắt đầu sau khi tất cả các module
được thiết kế, nên nhóm kiểm thử sẽ có ít thời gian thực hiện hơn
trong giai đoạn kiểm thử.
 Vì tất cả các module được kiểm thử đồng thời, các module quan
trọng có rủi ro cao không bị cô lập và được ưu tiên kiểm thử. Các
module có liên quan đến giao diện người dùng cũng không bị cô lập
và được ưu tiên kiểm thử.
 Kiểm thử tích hợp Top-Down:
Việc kiểm tra diễn ra từ trên xuống dưới, theo dòng điều khiển hoặc cấu trúc
kiến trúc.

Hình 2: Mô hình tích hợp kiểm thử Top Down

o Ưu điểm:
 Sản phẩm được kiểm thử rất phù hợp vì kiểm thử tích hợp về cơ bản
được thực hiện trong một môi trường gần giống với thực tế.

13
  Cơ bản có thể được thực hiện với thời gian ít hơn bởi vì đơn giản
hơn.
 Thu gọn phạm vi bug dễ dàng hơn.
 Modules quan trọng đang được thử nghiệm trên mức ưu tiên, lỗi
trong thiết kế lớn có thể được tìm thấy và cố định đầu tiên.
o Nhược điểm:
 Chức năng cơ bản được kiểm tra vào cuối chu kỳ.
 Cần nhiều Stub.
 Module ở mức độ thấp hơn sẽ được kiểm tra không đầy đủ.
 Kiểm thử tích hợp Bottom-Up:
Mỗi module ở mức thấp hơn được thử nghiệm với các module cao hơn cho đến
khi tất cả các module đều được kiểm tra. Nó được sử dụng cho Driver testing.

Hình 3: Mô hình tích hợp kiểm thử Bottom Up

o Ưu điểm:
 Thu gọn phạm vi bug dễ dàng hơn.
 Không mất thời gian chờ tất cả các module được tích hợp.
o Nhược điểm:
 Module quan trọng của hệ thống có thể dễ bị lỗi.

14
  Không giữ được nguyên mẫu đầu tiên của hệ thống.

1.2.3.5. Kiểm thử hệ thống - System Test

- Khái niệm:
 Kiểm thử hệ thống hay còn gọi là System Test, là kiểm tra lại toàn bộ hệ thống sau
khi tích hợp. Nó cho phép kiểm tra sự tuân thủ của hệ thống theo yêu cầu. Loại
kiểm thử này kiểm tra sự tương tác tổng thể của các thành phần. Nó liên quan đến
tải, hiệu suất, độ tin cậy và kiểm tra bảo mật.
 System Test sẽ được thực hiện sau integration testing. Đây là một bước giữ vai trò
quan trọng trong việc cho ra đời một sản phẩm chất lượng cao.
- Vai trò kiểm thử hệ thống:
 Đảm bảo sản phẩm đáp ứng các tiêu chuẩn chất lượng.
 Xác minh hệ thống phần mềm đáp ứng các yêu cầu chức năng, kỹ thuật và kinh
doanh theo yêu cầu của khách hàng.
 Thực hiện kiểm tra từ đầu đến cuối của sản phẩm phần mềm giúp ngăn ngừa lỗi hệ
thống và sự cố trong quá trình thực hiện với môi trường thật.
 Được thực hiện trong một môi trường tương tự như môi trường production, cho
phép các nhà phát triển cũng như các bên liên quan có được ý tưởng về phản ứng
của người dùng đối với sản phẩm.
 Đóng một vai trò quan trọng trong việc cung cấp một sản phẩm chất lượng cho
người dùng cuối.
 Chính trong giai đoạn này của vòng đời kiểm thử phần mềm (STLC), các Yêu cầu
nghiệp vụ và Kiến trúc ứng dụng được kiểm tra.
 Đảm bảo rằng đầu vào được cung cấp đầu ra / kết quả như mong đợi.

1.2.3.6. Kiểm thử chấp nhận hệ thống - Acceptance Test

- Khái niệm:
Acceptance Testing (Kiểm thử chấp nhận) là một kiểm thử nhằm xác định hệ thống
phần mềm có đạt yêu cầu kỹ thuật hay không. Bằng việc kiểm tra các hành vi của hệ
thống qua dữ liệu thực tế, kiểm thử chấp nhận sẽ xác định có hay không việc hệ thống
đáp ứng được các tiêu chí lẫn yêu cầu của khách hàng.
- Vai trò của kiểm thử chấp nhận:
 Nhờ Acceptance Testing mà bạn có thể xác định được giải pháp, phần mềm tạo ra
đã đi đúng hướng mà khách hàng đề xuất hay không. Ngoài ra, kiểm thử chấp
nhận còn mang lại rất nhiều lợi ích khác như:

15
 o Acceptance Testing giúp tìm hiểu và xác định các yêu cầu của người dùng
bằng cách kiểm chứng trực tiếp.
o Thông qua Acceptance Testing sẽ tìm được những vấn đề ở Unit hoặc
Integration Test đã để lọt.
o Acceptance Testing giúp bạn có cái nhìn tổng quan nhất về kết quả hệ
thống đạt được.
o Acceptance Testing được sử dụng để xác định và xác minh nhu cầu của
khách hàng.
 Các loại Acceptance Testing:
o Alpha & Beta Testing:
Alpha & Beta Testing thường diễn ra trong môi trường phát triển và
được thực hiện bởi nhân lực nội bộ. Số ít người dùng tiềm năng có thể tiến
hành Alpha Testing với điều kiện nó diễn ra trong môi trường phát triển.
Nhờ những thu thập được từ Alpha & Beta Testing sẽ giúp bạn xác định
được một số vấn đề và cải thiện chúng tốt hơn.
o Contract Acceptance Testing:
Contract Acceptance Testing (Kiểm tra chấp nhận hợp đồng) được thực
hiện nhằm kiểm tra các tiêu chí và thông số kỹ thuật đã xác định trong hợp
đồng. Những tiêu chí và thông số kỹ thuật có liên quan sẽ được nhóm dự án
xác định và chấp nhận khi nhóm đồng ý với hợp đồng.
o Regulation Acceptance Testing:
Regulation Acceptance Testing (Kiểm tra chấp nhận quy định) được thực
hiện nhằm kiểm tra xem phần mềm có tuân thủ các quy định hay không.
Trong quá trình kiểm tra cần đặc biệt lưu ý tới các quy định của chính phủ
và pháp lý.
o Operational acceptance Testing:
Operational Acceptance Testing (Thử nghiệm sẵn sàng hoạt động) giúp
đảm bảo các quy trình thực hiện công việc cho phép phần mềm hoặc hệ
thống được sử dụng. Trong Operational Acceptance Testing bao gồm: các
quy trình công việc cho kế hoạch dự phòng – quy trình đào tạo người dùng
– quy trình bảo trì và quy trình bảo mật.
o Black Box Testing:

16
 Black Box Testing (Kiểm thử hộp đen) là một phần của kiểm tra chấp
nhận người dùng. Phương pháp kiểm thử này giúp phân tích các chức năng
mà không cho phép người kiểm tra thấy được cấu trúc code bên trong. Để
làm tốt Black Box Testing, bạn cần biết về các yêu cầu mà phần mềm phải
đáp ứng.

CHƯƠNG 2: THIẾT KẾ TEST-CASE

2.1. Khái niệm

- Ca kiểm thử (test case) là một tình huống kiểm thử tương ứng với một mạch hoạt
động của chương trình. Nó bao gồm một tập các giá trị đầu vào và một danh sách các
kết quả đầu ra mong muốn và thực tế. 32 Mục tiêu thiết kế ca kiểm thử nhằm:
 Tìm ra nhiều lỗi nhất
 Với chi phí và thời gian ít nhất
17
- Trong các thập kỷ 80-90 của thế kỷ XX, người ta đã nghiên cứu nhiều loại phương
pháp thiết kế ca kiểm thử. Trong các phương pháp này, phương pháp thiết kế ca kiểm
thử. Trong các phương pháp này, phương pháp thiết kế được chọn theo cơ chế:
 Bảo đảm tính đầy đủ (không sót phần nào)
 Cung cấp khả năng phát hiện lỗi nhiều nhất.
 Việc thiết kế 1 ca kiểm thử được đặt ra với lý do sau là chủ yếu:
 Số con đường logic/ mạch thực hiện trong chương trình là rất lớn
 Nhiều trạng thái dữ liệu khác nhau: số đại lượng, giá trị, sự thay đổi trong tiến
trình, sự kết hợp giữa chúng.
- Câu hỏi đặt ra là khi nào thì kiểm thử xong? Làm thế nào để biết rằng kiểm thử đã đủ?
Về nguyên tắc:
 Không bao giờ kiểm thử được tất cả
 Vận hành chương trình là đang kiểm thử
 Kiểm thử tiếp tục khi chương trình còn hoạt động. Kỹ sư phần mềm cần các tiêu
chuẩn nghiêm ngặt để xác định có cần phải tiếp tục kiểm thử không.

2.2. Vai trò thiết kế test-case

- Tạo ra các ca kiểm thử tốt nhất có khả năng phát hiện ra lỗi, sai sót của phần mềm
một cách nhiều nhất.
- Tạo ra các ca kiểm thử có chi phí rẻ nhất, đồng thời tốn ít thời gian và công sức nhất.

2.3. Quy trình thiết kế test-case

Một trong những lý do quan trọng nhất trong kiểm thử chương trình là thiết kế và tạo
ra các ca kiểm thử - các Test case có hiệu quả. Với những ràng buộc về thời gian và chi
phí đã cho, thì vấn đề then chốt của kiểm thử trở thành:
Tập con nào của tất cả ca kiểm thử có thể có khả năng tìm ra nhiều lỗi nhất?
Thông thường, phương pháp kém hiệu quả nhất là kiểm tra tất cả đầu vào ngẫu nhiên –
quá trình kiểm thử một chương trình bằng việc chọn ngẫu nhiên một tập con các giá trị
đầu vào có thể. Về mặt khả năng tìm ra nhiều lỗi nhất, tập hợp các ca kiểm thử được chọn
ngẫu nhiên có rất ít cơ hội là tập hợp tối ưu hay gần tối ưu. Sau đây là một số phương
pháp để chọn ra một tập dữ liệu kiểm thử một cách thông minh
Để kiểm thử hộp đen và kiểm thử hộp trắng một cách thấu đáo là không thể. Do đó, một
chiến lược kiểm thử hợp lý là chiến lược có thể kết hợp sức mạnh của cả hai phương
pháp trên: Phát triển 1 cuộc kiểm thử nghiêm ngặt vừa bằng việc sử dụng các phương
18
pháp thiết kế ca kiểm thử hướng hộp đen nào đó và sau đó bổ sung thêm những ca kiểm
thử này bằng việc khảo sát tính logic của chương trình, sử dụng phương pháp hộp trắng.
Những chiến lược kết hợp đó bao gồm:
Hộp đen Hộp trắng
1. Phân vùng tương đương 1. Kiểm thử luồng điều khiển
2. Phân tích giá trị biên 2. Kiểm thử bao phủ
3. Kỹ thuật bảng quyết định
4. Đồ thị nguyên nhân – kết quả
5. Kỹ thuật đồ thị chuyển đổi
trạng thái
Mỗi phương pháp có những ưu điểm cũng như khuyết điểm riêng, do đó để có được
tập các ca kiểm thử tối ưu, chúng ta cần kết hợp hầu hết các phương pháp. Quy trình thiết
kế các ca kiểm thử sẽ bắt đầu bằng việc phát triển các ca kiểm thử sử dụng phương pháp
hộp đen và sau đó phát triển bổ sung các ca kiểm thử cần thiết với phương pháp hộp
trắng.

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

2.3.1.1. Kiểm thử luồng điều khiển

- Là kiểm thử dựa trên các câu lệnh trong chương trình thông qua
đồ thị luồng điều khiển.
- Đồ thị luồng điều khiển:
 Là một đồ thị có hướng biểu diễn của một chương trình, trong đó:
Mỗi nút (đỉnh): biểu diễn một lệnh tuần tự hoặc khối lệnh tuần tự
 Các cung: tương ứng với các quyết định luồng điều khiển đi ra từ một
nút cấu trúc lựa chọn hay lệnh rẽ nhánh. Một cung cần phải kết thúc tại một đỉnh,
cho dù đỉnh đó không biểu diễn cho một lệnh nào.
 Một đỉnh vào và một đỉnh ra được thêm vào đồ thị để biểu diễn cho
điểm vào và ra tương ứng của chương trình

- Lộ trình/ đường đi trong đồ thị luồng điều khiển

19
  Là đường đi xuất phát từ đỉnh vào, đi qua các đỉnh và các cung khác, kết thúc tại
đỉnh ra.
 Đơn giản hóa biểu thức đường đi như sau: G1= n 0 (1 2 3 + 1 2 4 + 1 5) ne
- Số lượng lộ trình trong đồ thị luồng điều khiển
 Công thức tính: V(G) = E-N+2. Trong đó E là số cung, N là số nút
 V(G) = P+1, trong đó P là số miền khép kín tạo ra do các nút và đường trên cùng
mặt phẳng
- Các bước thiết kế test case bằng đồ thị luồng điều khiển
 Xây dựng đồ thị luồng điều khiển của chương trình
 Tính số lượng đường cơ sở
 Xác định tập các đường cơ sở
 Thiết kế các Test Case cho các đường cơ sở
Chú ý: việc quan trọng nhất là xác định các điểm nút.
 Gộp các nút mà luồng điều khiển “chắc chắn” sẽ đi qua.
 Chia nhỏ biểu thức điều kiện
- Kiểm thử đối với vòng lặp đơn giản
Nên chọn các test case sau để kiểm thử lệnh lặp n lần:
 Chạy 0 lần
 Chạy 1 lần
 Chạy k lần, 2<k<n-1
 Chạy n-1 lần
 Chạy n lần
- Kiểm thử đối với vòng lặp lồng nhau
Kiểm thử tuần tự từng vòng lặp từ trong ra ngoài theo gợi ý sau:
 Kiểm thử vòng lặp trong cùng: cho các vòng chạy với giá trị min, kiểm thử vòng
lặp trong cùng bằng 5 test case đã nói trên

20
  Kiểm thử vòng lặp còn lại: cho các vòng ngoài chạy với giá trị min, các vòng bên
trong nó chạy với giá trị điển hình đã giới thiệu

2.3.1.2. Kiểm thử bao phủ

- Là kỹ thuật thiết kế các ca kiểm thử đảm bảo bao phủ hết tất cả các câu lệnh, các biểu
thức điều kiện trong các module cần test.
- Các tiêu chí đánh giá độ bao phủ:
- Method Coverage (phương thức)
o Tỷ lệ phần trăm các phương thức trong chương trình được gọi thực hiện bởi
các testcase
o Các test case cần phải đạt 100% method coverage
- Statement Coverage (câu lệnh)
o Tỷ lệ phần trăm các câu lệnh trong chương trình được gọi thực hiện bởi các
testcase
- Decision/Branch Coverage
o Tỷ lệ phần trăm các biểu thức điều kiện trong chương trình được ước lượng giá
trị trả về (true, false) khi thực hiện các testcase
o Một biểu thức điều kiện phải được kiểm tra trong cả hai trường hợp giá trị của
biểu thức True hay False
o Đối với các hệ thống lớn, thường chỉ đạt 75%- 80% độ bao phủ
- Condition CoverageK
o Tỷ lệ phần trăm các biểu thức điều kiện đơn trong biểu thức điều kiện phức của
chương trình được ước lượng giá trị trả về (true, false) khi thực thi các test
case.

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

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

- Chia các điều kiện đầu vào thành những lớp dữ liệu tương đương nhau
- “Tương đương”: cùng kiểu dữ liệu, cùng thuộc tính, …
- Mục đích: Giảm số lượng Test Case mà vẫn đảm bảo các case bao phủ các yêu cầu.
- Các bước thực hiện:
 Xác định các lớp tương đương
 Xác định các ca kiểm thử
- Nhược điểm:
 Có những bài toán không áp dụng được kỹ thuật phân vùng tương đương

21
  Có thể bị thiếu lỗi ở biên

2.3.2.2. Phân tích giá trị biên

- Là kỹ thuật kiểm thử sử dụng các điều kiện biên để thiết kế các test case.
- Phù hợp với lớp bài toán có các input độc lập với nhau và mỗi đối số đều có một miền
giá trị hữu hạn.
- Lựa chọn theo quy tắc sau: giả sử biến x có miền giá trị [min, max]
 Min: Giá trị biên nhỏ nhất
 Min +: Trên giá trị biên nhỏ nhất
 Nom: Giá trị trung bình trong min, max
 Max-: Dưới giá trị biên lớn nhất
 Max: Giá trị biên lớn nhất
→Số test case: 4*n +1
- Nhược điểm:
 Chỉ sử dụng được với lớp bài toán có các tình huống hoặc đầu vào cụ thể, tức là
các đối số đầu vào độc lập nhau và mỗi đối số đều có một miền giá trị hữu hạn
 Khi kết hợp nhiều yếu tố đầu vào và thực hiện các hành động khác nhau →không
hiệu quả
→Sử dụng kỹ thuật bảng quyết định

2.3.2.3. Kỹ thuật bảng quyết định

- Là kỹ thuật được sử dụng để kiểm thử hoạt động của hệ thống khi kết hợp các đầu vào
khác nhau.
- Còn gọi là bảng nguyên nhân –kết quả (Cause –Effect Table).
- Có thể cho kết quả tốt nếu kết hợp với kỹ thuật phân vùng tương đương.
- Các bước tạo bảng:
 Liệt kê tất cả các Conditions và các Actions
 Tính số lượng kết hợp có thể (Rules)
 Lập bảng quyết định
 Giảm thiểu các case kết hợp và kiểm tra các phép hợp có bao phủ hết mọi
trường hợp hay không.
 Xây dựng test case, mỗi cột tương ứng với một test case.

22
2.3.2.4. đồ thị nguyên nhân- kết quả
- Là kỹ thuật minh họa mối quan hệ giữa một kết quả và tất cả các yếu tố ảnh hưởng
đến kết quả đó
- Thường được sử dụng trong các trường hợp:
 Xác minh vấn đề hiện tại
 Mô tả lại các kết nối hệ thống với các yếu tố ảnh hưởng
 Xác định nguyên nhân có thể xảy ra
- Các bước thực hiện:
 Xác định và mô tả các điều kiện đầu vào (cause) và kết quả (effect)
 Xây dựng sơ đồ nguyên nhân – kết quả
 Chuyển sang bảng quyết định
 Xây dựng các Test Case

2.3.2.5. Kỹ thuật đồ thị chuyển đổi trạng thái

- Là kỹ thuật kiểm thử phần mềm trong đó thay đổi điều kiện đầu vào gây ra thay đổi
trạng thái trong ứng dụng được kiểm thử (Application under Test -AUT).
- Tester phân tích cách xử lý của một ứng dụng được kiểm thử để đưa ra cấc điều kiện
đầu vào khác nhau trong một trình tự thông qua các giá trị kiểm thử đầu vào hợp lệ,
sau đó xác định cách xử lý của hệ thống.
- Kỹ thuật này rất hữu ích khi cần kiểm thử các cách chuyển đổi khác nhau trong hệ
thống
- Các thành phần trong sơ đồ chuyển đổi trạng thái:
 Đỉnh: Chứa các sự kiện
 Cung: Chỉ hướng xử lý tiếp theo của hệ thống

CHƯƠNG 3: ÁP DỤNG

3.1. Xây dựng kế hoạch kiểm thử

3.1.1. Mục đích và phạm vi kiểm thử

3.1.1.1. Mục đích của kiểm thử

- Xác định thông tin cơ bản về dự án và các thành phần chức năng được kiểm thử và
không được kiểm thử
- Liệt kê những chiến lược kiểm thử nên được sử dụng

23
 - Liệt kê những yêu cầu cho việc kiểm thử

3.1.1.2. Phạm vi của kiểm thử

- Áp dụng cho việc kiểm thử chức năng của website linhkienchatluong.vn
- Các chức năng kiểm tra:
 Chức năng liên hệ
 Chức năng giỏ hàng
 Chức năng đăng ký

3.1.2. Định hướng cho kế hoạch

- Phân tích trang web đang được kiểm thử là trang web hán hàng, chuyên bán những
mặt hàng linh kiện:
 Đối tượng sử dụng: Sinh viên theo lập trình nhúng, thợ sửa chữa linh kiện, nhà
bán lẻ, ….
 Trang web phục vụ nhu cầu mua bán của người bán và khách hàng thông qua
internet.
- Mục tiêu tìm được các lỗi trong các chức năng của website:
 Tìm các bug phát sinh do dev tạo ra khi code
 Ngăn ngừa lỗi
 Đảm bảo kết quả cuối cùng đáp ứng các yêu cầu của người sử dụng
 Đạt được sự tín nhiệm của người dùng bằng cách cho khách hàng một sản
phẩm chất lượng
- Các phương tiện trong việc kiểm thử: Máy tính có kết nối internet và trình duyệt
web
- Loại kiểm thử: Thủ công.
 Kiểm thử hộp đen
 Kiểm thử hộp trắng

3.1.3. Các chức năng cần kiểm thử

- Những chức năng được kiểm thử:
 Kiểm tra chức năng liên hệ:
o Tính hợp lệ dữ liệu đầu vào
o Các giá trị được phép cho trường dữ liệu
o Các nút, hình dạng trên trang thuận tiện cho người dùng

24
 o V.v….
 Kiểm tra chức năng giỏ hàng:
o Tính hợp lệ khi nhập số điện thoại
o Kiểm tra ngữ pháp, chính tả
o Nội dung phải đầy đủ thông tin, dễ hiểu, có liên kết hợp lý
 Kiểm tra chức năng đăng ký:
o Tính hợp lệ cho dữ liệu đầu vào
o Giao diện dễ sử dụng, có hướng dẫn khi người dùng nhập sai thông tin
o Các nút, link liên kết cần được thiết kế dễ sử dụng, tương thích với
nhiều thiết bị và nhiều màn hình khác nhau
- Những yêu cầu phi chức năng:
 Trang web chạy ổn định trên nhiều trình duyệt khác nhau Cốc Cốc, Google
Chrome, Microsoft Edge.
 Trang web chạy được trên nhiều nền tảng Windows, Phone, Tabbet
 Không treo trang, các trang không chứa các link chết, link hỏng, …
 Màn hình hiển thị không bị vỡ bố cục, tương thích với nhiều loại màn hình
khác nhau.
- Những chức năng không được kiểm thử:
 Chức năng tìm kiếm.
 Chức năng trang chủ
 Chức năng đăng nhập
 v.v….

3.1.4. Định nghĩa vai trò từng các nhân trong nhóm

Thành viên Vai trò

Hoàng Trọng Tuyên - Test Manager/ Test Designer/ Tester:
+ Lập kế hoạch kiểm thử
+Quản lý tiến độ quá trình kiểm thử
+Đọc các tài liệu tham khảo để cung cấp thông tin
cho nhóm
+Thiết kế Test Case, bổ sung và thực thi Test
Case

25
Bùi Đình Hùng - Test Designer/ Tester
+ Thiết kế và viết các Test Case cho chức năng
Liên Hệ
+Thiết kế và viết các Test Case cho chức năng Giỏ
Hàng
+Thực thi và viết Test Case bổ sung cho chức
năng Đăng Ký
Cao Ngọc Hiền - Test Designer/ Tester
+ Thiết kế và viết các Test Case cho chức năng
Đăng Ký
+ Thực thi và viết Test Case bổ sung cho 2 chức
năng còn lại
Trần Minh Quảng - Test Designer/ Tester
+Thiết kế và viết các Test Case cho chức năng
Đăng Ký
+Thực thi và viết Test Case bổ sung cho 2 chức
năng còn lại

3.1.5. Các môi trường kiểm thử

- Máy tính cá nhân có kết nối mạng Internet để có thể truy cập vào trang web
linhkienchatluong.vn bằng trình duyệt.
- Các chức năng của trang web linhkienchatluong được kiểm tra trên các trình duyệt
Cốc Cốc, Google Chrome hoặc Microsoft edge.
- Hệ điều hành được sử dụng là Microsoft Windows 11 Professional.
- Công cụ quản lý Test Case: Microsoft Office Excel.

3.2. Thiết kế test case

(Phần này nhóm em để các ca kiểm thử trong file excel)

3.3. Điều kiện dừng việc kiểm thử

- Thực thi được 100% Test Case đã được đặt ra.
- Tất cả các lỗi tìm thấy đều được ghi nhận lý do rõ ràng để có thể giúp cho dev
khắc phục.
- Thời hạn kiểm thử đã kết thúc

26
3.4. Đánh giá kết quả kiểm thử
Mức độ nghiêm trọng Đặc tả lỗi
Cao - Không có định dạng chuẩn số điện thoại (có thể nhập
số tùy ý và tùy kích thước)
- Mật khẩu không giới hạn số ký tự
- Emal không định dạng chuẩn
- Không xác thực số điện thoại
Vừa - Không nhập nội dung, tiêu đề mà trang web vẫn hiển
thị thành công
- Các trường hợp nhập nội dung cần thiết không có
dấu (*)
Thấp - Giao diện trang web còn khá đơn sơ, không được căn
giữa, hiệu ứng
- Không có chức năng chuyển ngôn ngữ sang Tiếng
Anh
- Zoom màn hình sẽ bị mất nội dung

Nhận xét chung:

- Tổng số 149 Test Case đã kiểm thử, trong đó có 40 Test Case FAIL
 Đánh giá kết quả kiểm thử: (số Test Case PASS/ Tổng số Test
Case) * 100% = 73,15%,
- Website được vận hành thường xuyên, không bị ngắt quãng
- Website có tốc độ tải trang nhanh
- Bố cục chia trang (giỏ hàng, đăng ký, trang sản phẩm, …) được trình bày hợp lý,
giúp khách hàng dễ dàng tìm được sản phẩm mình cần mua
- Thông tin sản phẩm được ghi rõ ràng, đúng chi tiết
- Giao diện trong trang liên hệ không được bắt mắt, khó thu hút người dùng
- Các trường hợp nhập thông tin thì dev chưa xét những giá trị đầu vào, người dùng
có thể nhập tùy ý, các trường số điện thoại, địa chỉ email không có tính xác thực
 Bảo mật kém
 Rất khó để lấy lại mật khẩu

27
 TÀI LIỆU THAM KHẢO

1. The Art of Software Testing, Glenford J. Myers, Second Edition, John Wiley and
Sons, Inc.

2. Software Engineering - A Practitioner’s Approach, Roger S.Pressman, Sixth

Edition, Ph.D, McGraw-Hill, Inc.

3. Slide bài giảng môn học

4. http://en.wikipedia.org/wiki/Software_testing

5. https://codelearn.io/sharing/toan-tap-kiem-thu-phan-mem?
fbclid=IwAR2zPU5fZH7-7d4jYqjj9yPweps2u-0rSe4GQitOdwU4tjskZO19dv4Z0-
Y

28
6. https://freetuts.net/kiem-thu-thu-cong-1495.html?
fbclid=IwAR3BlORC0xy3WB8qRqeVpBl7ytzJpexs0oHdmH-
D0xgAPB_eQ_q2baAZUHQ

7. https://freetuts.net/quy-trinh-quan-ly-kiem-thu-1622.html?fbclid=IwAR1sbGjA-
AwGaLJ2nQhg-l-BQM48NkqVfhH3Ghg02m3EYldUx1omv_8d7-w

8. https://freetuts.net/cach-tao-test-plan-1642.html?
fbclid=IwAR0i_EKbFwWvhfZpEpUwiY2-
pS2c0p0tYjZGo6kD6YDyQl7ezVwzC2tluO8

9. https://freetuts.net/cach-viet-test-cases-1556.html?
fbclid=IwAR0kIGejfpPZKpkZrkNGLOsnihVR7O62MTIbT5ninTCz5oE4o78VhQ
FMkZc

29