KIỂM THỬ PHẦN MỀM NGHIÊN CỨU VÀ ĐÁNH GIÁ CÁC PHƯƠNG PHÁP LUẬN KIỂM THỬ

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI
KHOA CÔNG NGHỆ THÔNG TIN
---------------------------------------

BÁO CÁO BÀI TẬP LỚN THUỘC HỌC PHẦN: KIỂM THỬ
PHẦN MỀM
NGHIÊN CỨU VÀ ĐÁNH GIÁ CÁC PHƯƠNG PHÁP LUẬN KIỂM
THỬ

GVHD:

Ths. Hồng Quang Huy

Nhóm:

7

Thành viên:
Lớp: 20212IT6013002

Khóa: 14

Hà nội, 2022

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ở

lê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 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 cơng việc đó.
Ngày nay, 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.
Với sự hướng dẫn của thầy Hoàng Quang Huy nhóm chúng em thực hiện
đề tài “Nghiên cứu và đánh giá các phương pháp luận kiểm thử” và thực hiện
trên một sản phẩm website đã được xây dựng nhưng chưa hồn thiện, cũng
như gặp rất nhiều thiếu sót trong quá trình phát triển sản phẩm. 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, rất mong được sự giúp đỡ và chỉ dạy của thầy và các bạn.
Chúng em xin chân thành cảm ơn!

MỤC LỤC
LỜI NÓI ĐẦU

1

CHƯƠNG I. CƠ SỞ LÝ THUYẾT

3

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

4

1.1.1. Khái niệm

4

1.1.2. Các kỹ thuật kiểm thử hộp trắng

5

1


1.2. Kiểm thử chấp nhận

12

1.2.1 Khái niệm

12

1.2.2 Các loại kiểm thử chấp nhận

12

CHƯƠNG II. KẾT QUẢ THỰC NGHIỆM

19

2.1. Website kiểm thử

19

2.2. Yêu cầu đặc tả của website

19

2.2.1. Yêu cầu chức năng

19

2.2.2. Yêu cầu hiệu năng

20

2.3. Công cụ kiểm thử Jmeter

20

2.4. Tiến hành kiểm thử trên website

23

2.5. Tiến hành kiểm thử trên công cụ Jmeter

25

CHƯƠNG III. BÀI HỌC KINH NGHIỆM

29

3.1. Bài học kinh nghiệm

29

3.2. Đánh giá kết quả

29

KẾT LUẬN

30

TÀI LIỆU THAM KHẢO

31

2


DANH MỤC HÌNH ẢNH
Hình 1. Control Flow Graph

6

Hình 2. Tạo các khối lệnh

7

Hình 3. Xử lý riêng biệt

7

Hình 4. Khối lệnh If …else

8

Hình 5. Khối lệnh If khơng có else

8

Hình 6. Khối lệnh chia nhiều nhánh

9

Hình 7. Khối lệnh có nhiều cạnh vào, nhiều cạnh ra

9

Hình 8. Mã giả

11

Hình 9. Mã giả sau khi kiểm thử

12

Hình
10.
Hình
11.

Hình
12.
Hình
13.
Hình
14.
Hình
15.
Hình
16.
Hình
17.

Mơ hình chữ V

14

Quy trình kiểm thử chấp nhận người dùng

15

Cài đặt Jmeter

22

Tạo 1 thread group

25

Các thành phần của Thread Group

26

Tạo HTTP Request

26

View Results Tree

27

Graph Results

28

3


CHƯƠNG I. CƠ SỞ LÝ THUYẾT
1.1 Kiểm thử hộp trắng
1.1.1. Khái niệm
Kiểm thử hộp trắng nhằm kiểm tra mã nguồn phần mềm:
Cơ bản là xác minh các lỗ hổng thiếu sót, khiếm khuyết trong các mã
nguồn.
Kiểm tra các đường dẫn (Path) bị hỏng hoặc không đầy đủ trong mã
nguồn.
Kiểm tra dòng chảy của cấu trúc đề cập đến trong tài liệu đặc tả.
Kiểm tra xem có các dead code (mã chết) trong mã nguồn hay không
Kiểm tra các kết quả đầu ra có như mong đợi?
Kiểm tra các vịng lặp, các điều kiện trong các mã nguồn có thực hiện

đúng khơng?
Xác minh từng dịng hoặc phần của các mục trong mã nguồn & bao
phủ các phân nhánh xử lý.
Giải thích Dead code:
Dead code (mã chết) là một phần trong mã nguồn của một chương trình
được thực thi nhưng có kết quả là không bao giờ được sử dụng trong bất kỳ
tính tốn khác.
Trong khi kết quả của một sự tính tốn chết có thể khơng bao giờ được
sử dụng, nó có thể làm tăng lỗi hoặc ảnh hưởng đến tốc độ tồn cục, do đó
cần loại bỏ các mã như vậy nhằm thay đổi hiệu năng của chương trình.
Ví dụ: Dead code
4


int calculate (int X, int Y)
{ int Z = X/Y;
return X*Y;
}
Lệnh là Z = X/Y; không bao giờ được dùng và cịn có khả năng gây lỗi
khi Y = 0.
1.1.2. Các kỹ thuật kiểm thử hộp trắng
Có 03 kỹ thuật kiểm thử White box sau:
● Statement Coverage (phủ lệnh)
● Branch Coverage (phủ nhánh)
● Path Coverage (phủ đường đi)
Một hình thức truyền thống của kiểm thử White-box thường trải qua là:
● Bước 1: Tạo 1 đồ thị mô tả luồng điều khiển từ mã nguồn, được gọi là
đồ thị luồng điều khiển (CFG _ Control Flow Graph). Đồ thị được tạo
từ mã nguồn thường tạo bằng tay.
● Bước 2: Thiết kế các Test case để bao phủ toàn bộ các phần tử của đồ

thị (tùy theo kỹ thuật)
o Phần tử: các nút, cạnh, đường đi (nodes, edges, paths)
o Đồ thị được định nghĩa hình thức tốn học như sau:
o G = (N, E)
o Node: các nút tương ứng với lệnh, điều kiện Edge: các cạnh nối
các nút.

5


Ví dụ về Control Flow Graph (CFG)

Hình 1. Control Flow Graph

Các phần tử của CFG
Có 03 loại nút:
● Nút lệnh: mô tả nút vào, ra, tuần tự.
● Nút điều kiện: nút mô tả điều kiện cho 1 nhánh.
● Nút hỗ trợ: nút kết nối như IF, … Cạnh: biểu diễn các luồng điều
khiển.
Rất dễ khi tạo đồ thị, nó tương tự như vẽ lưu đồ chương trình (Flow
Program).
Tạo các khối lệnh (Block statement)
Để đơn giản hóa các mã nguồn lớn có nhiều lệnh, người ta thường tạo
CFG bằng các khối lệnh thay vì cho từng lệnh.

6


Khối lệnh là tập hợp các lệnh liên tiếp tuần tự, khơng có phân nhánh

(trừ ở cuối), khơng chứa vịng lặp.
Ví dụ:

Hình 2. Tạo các khối lệnh

Ví dụ: có 2 xử lý riêng biệt

Hình 3. Xử lý riêng biệt

Ví dụ: Khối lệnh If …else
7


Hình 4. Khối lệnh If …else

Ví dụ: Khối lệnh If khơng có else

Hình 5. Khối lệnh If khơng có else

Ví dụ: Khối lệnh chia nhiều nhánh như switch(), Select case,..
8


Hình 6. Khối lệnh chia nhiều nhánh
Ví dụ: Khối lệnh có nhiều cạnh vào, nhiều cạnh ra.

Hình 7. Khối lệnh có nhiều cạnh vào, nhiều cạnh ra

9

Statement Coverage (Phủ lệnh)
Lệnh là các dòng mã hoặc hướng dẫn cho máy tính hiểu và hành động
phù hợp. Một lệnh sẽ trở thành một lệnh thực thi khi nó được biên soạn và
chuyển đổi thành mã đối tượng và thực hiện các hành động khi chương trình
ở chế độ chạy.
Do đó ‘Phủ lệnh’, cho thấy đó là phương pháp chứng thực rằng mỗi
dịng mã được thực hiện ít nhất một lần.
Branch Coverage (phủ nhánh)
Branch trong NNLT là lệnh 'IF', lệnh có các nhánh: đúng và sai, hoặc
các lệnh chuyển hướng điều khiển trong mã nguồn như switch(), goto, …
Trong phạm vi phủ nhánh (Branch Coverage _ còn gọi là phủ quyết
định), chúng ta chứng thực rằng mỗi nhánh được thực hiện ít nhất một lần.
Trong trường hợp của một lệnh IF, sẽ có hai điều kiện kiểm thử:
● Một để xác nhận nhánh đúng và
● Cái khác để xác nhận nhánh sai.
Do đó về lý thuyết, Phủ nhánh là một phương pháp kiểm thử mà khi
thực hiện đảm bảo rằng từng nhánh của lệnh (có chứa quyết định) sẽ được thi
hành.
Path Coverage (phủ đường đi)
Phủ đường đi là kiểm tra tất cả các đường đi của chương trình. Đây là
một kỹ thuật toàn diện, đảm bảo rằng tất cả các đường đi của chương trình
được đi qua ít nhất một lần. Phủ đường đi thậm chí cịn mạnh mẽ hơn phủ
nhánh. Kỹ thuật này rất hữu ích để kiểm thử các chương trình phức tạp.
Hãy lấy một ví dụ đơn giản để hiểu tất cả các kỹ thuật kiểm thử hộp
trắng.
10


Xem xét đoạn mã giả sau (pseudo code):

Hình 8. Mã giả

Đối với Statement Coverage: ta chỉ có một trường hợp kiểm thử để
kiểm tra tất cả các dòng m
Xét Test Case_01 với (A = 40 và B = 70), ta thấy tất cả các dòng mã sẽ
được thực thi
Nếu ta xét trường hợp kiểm thử Test Case_02 với (A = 33 và B = 45)
sẽ ra sao?
Bởi vì Statement Coverage sẽ chỉ bao trùm bên phía True tức là chỉ có
một trường hợp kiểm thử vậy sẽ khơng đủ để kiểm tra nó. Là một Tester,
chúng ta cần phải xem xét cả trường hợp False.
Đối với Branch Coverage: ta có thể phủ hết các nhánh, và sẽ đánh giá
cả điều kiện "FALSE".

11


Vì vậy, bây giờ mã giả trở thành:

Hình 9. Mã giả sau khi kiểm thử

1.2. Kiểm thử chấp nhận
1.2.1 Khái niệm
Kiểm thử chấp nhận là một quá trình mà sẽ kiểm tra xem các yêu cầu
đặc tả kỹ thuật và tài liệu hợp đồng có được đáp ứng hay khơng.
Tức là các thử nghiệm chính thức liên quan đến yêu cầu của người
dùng và quy trình nghiệp vụ được tiến hành để xác định xem một hệ thống có
thỏa mãn các tiêu chí chấp nhận hay khơng và cho phép người dùng, khách
hàng hoặc tổ chức được ủy quyền khác xác định có chấp nhận hệ thống đó

hay khơng.
1.2.2 Các loại kiểm thử chấp nhận
Kiểm thử chấp nhận bao gồm các loại phổ biến sau:
● Kiểm thử chấp nhận người dùng (UAT)
● Kiểm thử người dùng cuối (End-user testing)
● Kiểm thử chấp nhận vận hành (Operational Acceptance Testing –
OAT)
12


Kiểm thử chấp nhận người dùng (UAT)
Kiểm thử chấp nhận người dùng là một loại kiểm thử chấp nhận. Nó là
một quá trình mà xác nhận rằng một giải pháp hoặc phần mềm đã tạo ra có
đáp ứng được cho việc sử dụng của người dùng cuối hay không.
Kiểm thử chấp nhận người dùng là quá trình diễn ra vào giai đoạn cuối
của chu trình kiểm thử, sau khi các giai đoạn kiểm thử chức năng (Functional
Testing), kiểm thử tích hợp (Integration Testing) và kiểm thử hệ thống
(System Testing) kết thúc. Và ngay sau khi qua được giai đoạn UAT thì sản
phẩm sẽ sẵn sàng để đưa vào sử dụng thực tế (production).
Lý do cần áp dụng kiểm thử chấp nhận người dùng
Mặc dù khi qua được 3 bước kiểm thử chức năng, kiểm thử tích hợp và
kiểm thử hệ thống, kiểm thử chấp nhận sẽ có thể trở nên dư thừa. Tuy nhiên
lý do chúng ta không nên bỏ qua bước kiểm thử này là bởi vì:
Các lập trình viên dựa vào các đặc tả yêu cầu để phát triển phần mềm.
tuy nhiên đây lại phần mềm được dựng theo “cách hiểu” của cá nhân họ về
các yêu cầu mà có thể khơng phải là những thứ mà người dùng thực sự cần.
Các yêu cầu thay đổi ngay trong q trình triển khai dự án khơng được
truyền đạt hiệu quả cho các lập trình viên.
Kiểm thử chấp nhận người dùng và mơ hình chữ V
Mơ hình chữ V (V-Model) là mơ hình mà trong các giai đoạn kiểm thử

sẽ đi cùng với một giai đoạn phát triển phần mềm, hoặc có thể nói hai q
trình phát triển và kiểm thử hoạt động song song.
Trong mơ hình này, kiểm thử chấp nhận người dùng sẽ tương ứng với
giai đoạn phân tích yêu cầu.

13


Hình 10. Mơ hình chữ V

Kiểm thử chấp nhận người dùng cần thỏa mãn các điều kiện sau để có
thể tiến hành:
● Yêu cầu nghiệp vụ phải có sẵn
● Mã nguồn chương trình cần phải được phát triển đầy đủ
● Các q trình kiểm thử chức năng, kiểm thử tích hợp và kiểm thử hệ
thống phải được hồn thành
● Khơng có các lỗi dừng chương trình đột ngột, hay các lỗi nghiêm trọng
trong q trình kiểm thử tích hợp hệ thống trước đó
● Chỉ có các lỗi về thẩm mỹ mới có thể được bỏ qua trước khi q trình
kiểm thử chấp nhận diễn ra
● Hoàn thành kiểm thử hồi quy mà khơng có lỗi lớn xảy ra
● Tất cả các lỗi phải được báo cáo và sửa trước khi kiểm thử chấp nhận
bắt đầu
14


● Hoàn thành ma trận truy xuất nguồn gốc cho tất cả các bộ kiểm thử
● Môi trường cho kiểm thử chấp nhận phải sẵn sàng để sử dụng.
● Có thông báo sẵn sàng cho kiểm thử chấp nhận từ nhóm kiểm thử hệ
thống.

Quy trình kiểm thử chấp nhận người dùng
Kiểm thử chấp nhận được diễn ra tại máy khách, và được thực hiện bởi
người dùng dự định sẽ sử dụng hệ thống hoặc phần mềm. Quy trình kiểm thử
chấp nhận sẽ bao gồm các bước như sau:

Hình 11. Quy trình kiểm thử chấp nhận người dùng

15


Bước 1: Phân tích các yêu cầu nghiệp vụ
Một trong những việc làm quan trọng nhất của quá trình kiểm thử chấp
nhận là xác định và xây dựng các kịch bản thử nghiệm. Các kịch bản này
được lấy từ các tài liệu sau:
● Bản tuyên ngôn của dự án (Project Charter)
● Các trường hợp sử dụng theo nghiệp vụ (Business Use Cases)
● Các sơ đồ quy trình hoạt động của chương trình (Process Flow
Diagram)
● Tài liệu yêu cầu nghiệp vụ (Business Requirements Document –
BRD)
● Các đặc tả yêu cầu hệ thống (System Requirements Specification
– SRS)
Bước 2: Tạo kế hoạch
Kế hoạch kiểm thử cho kiểm thử chấp nhận sẽ được sử dụng để xác
minh và đảm bảo ứng dụng/chương trình đáp ứng được các yêu cầu nghiệp vụ
của nó. Nó sẽ ghi lại các tiêu chí nhập vào và xuất ra cho kiểm thử chấp nhận,
kịch bản kiểm thử, cách tiếp cận các trường hợp kiểm thử và thời gian kiểm
thử.
Bước 3: Xác định các kịch bản và trường hợp kiểm thử (Test Scenarios and
Test Cases)

Ở bước này sẽ xác định các kịch bản kiểm thử liên quan đến quy trình
nghiệp vụ cấp cao và tạo các trường hợp kiểm thử (test cases) với các bước
kiểm thử rõ ràng. Các trường hợp kiểm thử phải đầy đủ bao gồm hầu hết các
kịch bản của kiểm thử chấp nhận. Các trường hợp sử dụng theo nghiệp vụ là
đầu vào để tạo ra các trường hợp kiểm thử.

16


Bước 4: Chuẩn bị dữ liệu cho việc kiểm thử
Các dữ liệu dùng cho kiểm thử chấp nhận nên là các dữ liệu thực tế mà
người dùng sẽ sử dụng. Chúng ta nên xáo trộn dữ liệu, chẳng hạn như ghép
cặp ngẫu nhiên các bộ dữ liệu với nhau để giúp tăng tính bảo mật và riêng tư.
Bên cạnh đó, người kiểm thử cũng sẽ cần phải làm quen với các luồng
cơ sở dữ liệu.
Bước 5: Tiến hành kiểm thử và ghi lại các kết quả
Bước này sẽ tiến hành kiểm thử theo các tài liệu, quy trình và dữ liệu
sẵn có. Các lỗi xảy ra sẽ được ghi lại và tiến hành kiểm tra lại sau khi đã được
sửa.
Có thể áp dụng các công cụ quản lý kiểm thử cho bước này, chẳng hạn
như JIRA, Klaros, qTest ….
Bước 6: Xác nhận việc đã đáp ứng các mục tiêu nghiệp vụ
Các chuyên viên phân tích nghiệp vụ (Business Analysist – BA) hoặc
người kiểm thử chấp nhận cần thông báo qua mail về việc kết thúc quá trình.
Đến lúc này, sản phẩm đã sẵn sàng để đưa vào sử dụng trong thực tế
(production).
Các tài liệu bàn giao của quá trình kiểm thử chấp nhận bao gồm các kế
hoạch kiểm thử, kịch bản kiểm thử, trường hợp kiểm thử (test cases), kết quả
kiểm thử và nhật ký ghi lại lỗi.
Để đảm bảo sẵn sàng cho sử dụng thực tế (production), kiểm thử chấp

nhận cần đảm bảo các điều sau:
● Khơng có các lỗi nghiêm trọng cịn đang mở
● Quy trình nghiệp vụ hoạt động ổn định

17


● Người tiến hành kiểm thử chấp nhận đã đăng xuất khỏi tất cả các
tài khoản và các bên liên quan.
Một số vấn đề liên quan đến kiểm thử chấp nhận
Để tăng tỉ lệ thành công của kiểm thử chấp nhận (UAT), ta có thể xem
xét các vấn đề sau:
● Chuẩn bị sớm các kế hoạch kiểm thử chấp nhận trong vòng đời
của dự án
● Chuẩn bị các checklists đầy đủ trước khi tiến hành kiểm thử chấp
nhận
● Thực hiện Pre-UAT trong giai đoạn kiểm thử hệ thống
● Đặt kỳ vọng và xác định rõ phạm vi của kiểm thử chấp nhận
● Chỉ kiểm thử với vai trò người dùng cuối và khơng lặp lại q
trình kiểm thử hệ thống
● Kiểm thử với dữ liệu sẽ dùng trong thực tế, khơng sử dụng dữ
liệu giả
● Có tư duy của một người dùng bất kỳ khi tiến hành kiểm thử
● Cần có q trình phản hồi trước khi kết thúc kiểm thử chấp nhận
và chuyển sang giai đoạn sử dụng thực tế.

18


CHƯƠNG II. KẾT QUẢ THỰC NGHIỆM

2.1. Website kiểm thử
Website bán đồng hồ
2.2. Yêu cầu đặc tả của website
2.2.1. Yêu cầu chức năng
Đăng nhập
Mô tả: khách hàng đăng nhập vào hệ thống với tài khoản của mình. Có
chức năng tự động đăng nhập cho những lần sau.
Đăng ký
Mô tả: Khách hàng tạo tài khoản mới, tự động đăng nhập sau khi đăng
ký.
Sửa thông tin khách hàng
Mô tả: Khách hàng sửa thông tin cá nhân như email, số điện thoại, họ
tên, mật khẩu…Hệ thống cập nhật lại thông tin khách hàng
Chi tiết sản phẩm
Mô tả: Khách hàng xem các thông tin chi tiết của sản phẩm như: tên,
hình ảnh, giá, mơ tả, đánh giá…
Thêm giỏ hàng
Mô tả: Khách hàng thêm các sản phẩm vào giỏ hàng. Hệ thống cập nhật
giỏ hàng.
Thêm vào danh mục u thích
Mơ tả: Khách hàng thêm các sản phẩm vào danh mục yêu thích. Hệ
thống cập nhật danh mục yêu thích.
19