NGHIÊN CỨU VÀ ỨNG DỤNG CÔNG CỤ JMETER TRONG KIỂM THỬ HIỆU NĂNG WEBSITE

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
HỌC PHẦN KIỂM THỬ PHẦN MỀM

NGHIÊN CỨU VÀ ỨNG DỤNG CÔNG CỤ JMETER
TRONG KIỂM THỬ HIỆU NĂNG WEBSITE

GVHD: Hồng Quang Huy
Nhóm: 6
Sinh viên: Nguyễn Bá Tùng - 2020603041
Hồ Việt Hùng - 2020604142
Vũ Hồng Sơn - 2020601027
Nguyễn Văn Lĩnh - 2020603364
Lớp: 20222IT6084003

Khóa: 15

Hà Nội – Năm 2023


MỤC LỤC
MỞ ĐẦU ...............................................................................................................................1
1.

Lý do lựa chọn đề tài ........................................................................................... 1

2.

Mục tiêu ............................................................................................................... 1

3.

Mục đích .............................................................................................................. 1

4.

Ý nghĩa lý luận thực tiễn ..................................................................................... 1

CHƯƠNG 1: TỐNG QUAN VỀ KIỂM THỬ PHẦN MỀM.......................................2
1.1. Khái niệm ........................................................................................................... 2
1.1.1. Khái niệm kiểm thử phần mềm .................................................................... 2
1.1.2. Vai trị ........................................................................................................... 2
1.1.3. Mục đích ....................................................................................................... 2
1.2. Các loại kiểm thử ............................................................................................... 2
1.2.1. Kiểm thử chức năng (Functional testing) ..................................................... 3
1.2.2. Kiểm thử phi chức năng (Non-functional testing) ........................................ 4
1.2.3. Kiểm thử cấu trúc/kiến trúc phần mềm (Structural testing) ......................... 4
1.2.4. Kiểm thử liên quan đến các thay đổi ............................................................ 5
1.3. Quy trình kiểm thử ............................................................................................ 5
1.3.1. Requirement Analysis (Phân tích yêu cầu) ................................................... 6
1.3.2. Test planning (Lập kế hoạch kiểm thử) ........................................................ 6
1.3.3. Test case development (Phát triển kịch bản kiểm thử) ................................. 7
1.3.4. Environment setup (Thiết lập môi trường kiểm thử) .................................... 7
1.3.5. Test execution (Thực hiện kiểm thử) ............................................................ 8
1.3.6. Test cycle closure (Kết thúc chu kỳ kiểm thử) ............................................. 8
1.4. Các kỹ thuật cơ bản của kiểm thử phần mềm ................................................ 9
1.4.1. Kiểm thử Kiểm thử hộp đen (Black Box Testing – BBT) ............................ 9

1.4.2. Kiểm thử hộp trắng (White Box Testing – WBT)....................................... 12
1.5. Kiểm thử hiệu năng ......................................................................................... 13
1.5.1. Khái niệm .................................................................................................... 13
1.5.2. Tầm quan trọng của kiểm thử hiệu năng .................................................... 14
1.5.3. Các loại kiểm thử hiệu năng ....................................................................... 14
1.5.4. Những vấn đề chung về hiệu năng của một hệ thống ................................. 15
1.5.5. Quy trình kiểm thử hiệu năng ..................................................................... 16
1.5.6. Một số công cụ kiểm thử hiệu năng............................................................ 17
CHƯƠNG 2: TÌM HIỂU CƠNG CỤ KIỂM THỬ APACHE JMETER ............... 19
3.1. Giới thiệu công cụ ............................................................................................ 19
3.2. Đặc điểm của JMeter ....................................................................................... 19
3.3. Các thức hoạt động của JMeter ..................................................................... 22
3.4. Giới thiệu về một số thành phần trong JMeter ............................................. 22
3.4.1. HTTP Request sampler .............................................................................. 25
3.4.2. Listeners ..................................................................................................... 26
3.4.3. HTTP(S) Test Script Recorder .................................................................... 29
3.5. Cách cài đặt và tạo kịch bản kiểm thử hiệu năng với Jmeter ...................... 30
3.5.1. Cách cài đặt Jmeter...................................................................................... 30
3.5.2 Cách tạo kịch bản kiểm thử hiệu năng với Jmeter ....................................... 32
CHƯƠNG 3: KIỂM THỬ HIỆU NĂNG WEBSITE BẰNG CÔNG CỤ KIỂM
THỬ JMETER APACHE ........................................................................................................ 38
3.1 Giới thiệu về Website Natours .......................................................................... 38
3.1.1 Giới thiệu chung về Website ........................................................................ 38
3.1.2. Một số chức năng chính của Natours .......................................................... 39
3.2. Kiểm thử Website Natours............................................................................... 41


3.2.1 Lập kế hoạch kiểm thử (cả nhóm) ................................................................ 41
3.2.2. Thiết lập các tham số ban đầu ..................................................................... 43

3.2.3. Nguyễn Bá Tùng – Kiểm thử chức năng đăng nhập ................................... 45
3.2.4. Hồ Việt Hùng – Kiểm thử chức năng đăng kí tài khoản ............................. 49
3.2.5. Nguyễn Văn Lĩnh – Kiểm thử chức năng truy cập tour .............................. 53
3.2.6. Vũ Hồng Sơn – Kiểm thử chức năng thanh toán ........................................ 59
3.2.7. Báo cáo kiểm thử hiệu năng Website Natours ............................................ 63
3.2.8. Phân tích kết quả kiểm thử hiệu năng Website Natours ............................. 65
KẾT LUẬN VÀ KIẾN NGHỊ ........................................................................................ 66
TÀI LIỆU THAM KHẢO............................................................................................... 68


DANH MỤC BẢNG BIỂU

Bảng 3. 1 Test case chức năng đăng nhập ............................................................... 45
Bảng 3. 2 Test case chức năng đăng kí tài khoản ................................................... 49
Bảng 3. 3 Test case chức năng truy cập tour............................................................ 53
Bảng 3. 4 Test case chức năng thanh tốn ............................................................... 59

DANH MỤC HÌNH ẢNH
Hình 1. 1 Giai đoạn phân tích u cầu ................................................................................. 6
Hình 1. 2 Kiểm thử hộp đen.................................................................................................. 9
Hình 1. 3 Quy trình kiểm thử hiệu năng cơ bản ................................................................. 16
Hình 2. 1 Ưu điểm của Apache Jmeter………………………………………………………….20
Hình 2. 2 Nhược điểm của Apache JMeter ........................................................................ 21
Hình 2. 3 Quy trình làm việc hồn chỉnh của JMeter ........................................................ 22
Hình 2. 4 Một số phần tử phổ biến trong Jmeter ............................................................... 23
Hình 2. 5 Giao diện của Thread Group ............................................................................. 23
Hình 2. 6 Các thành phần của HTTP Request ................................................................... 25
Hình 2. 7 Kết quả phản hồi dưới dạng Results Tree .......................................................... 27
Hình 2. 8 Giao diện Sumary report .................................................................................... 27
Hình 2. 9 Kết quả hiển thị trên Graph Results ................................................................... 28

Hình 2. 10 Giao diện HTTP(S) Test Script Recorder......................................................... 29
Hình 2. 11 Tải Apache Jmeter ............................................................................................ 31
Hình 2. 12 Giải nén file zip vừa tải về ................................................................................ 31
Hình 2. 13 Chạy Jmeter ...................................................................................................... 32
Hình 2. 14 Thêm Thread Group ......................................................................................... 32
Hình 2. 15 Cài đặt Thread Properties ................................................................................ 33
Hình 2. 16 Thêm phần tử HTTP request default ............................................................... 33
Hình 2. 17 Cấu hình cho phần tử HTTP request default ................................................... 34
Hình 2. 18 Thêm phần tử HTTP request ........................................................................... 34


Hình 2. 19 Nhập Path trong HTTP request ....................................................................... 35
Hình 2. 20 Thêm Graph result ............................................................................................ 35
Hình 2. 21 Chạy Jmeter ...................................................................................................... 36
Hình 2. 22 Kết quả test ....................................................................................................... 36
Hình 2. 23 Phân tích kết quả test ....................................................................................... 37
Hình 3. 1 Trang chủ của Website Natours……………………………...……………………...39
Hình 3. 2 Chức năng Đăng kí thành viên ........................................................................... 39
Hình 3. 3 Chức năng đăng nhập ........................................................................................ 40
Hình 3. 4 Chi tiết một tour.................................................................................................. 40
Hình 3. 5 Chức năng thanh tốn bằng thẻ ......................................................................... 41
Hình 3. 6 Thêm mới một Thread Group cho Test Plan ...................................................... 43
Hình 3. 7 Cấu hình Browsers ............................................................................................. 43
Hình 3. 8 Add certificates ................................................................................................... 44
Hình 3. 9 HTTP(S) Test Script Recorder............................................................................ 44
Hình 3. 10 Kết quả của quá trình lấy mẫu kiểm thử trên Website Natours ....................... 45
Hình 3. 11 Đặt địa chỉ http default truy cập vào đăng nhập .............................................. 45
Hình 3. 12 Đặt Path truy cập vào chức năng đăng nhập ................................................... 46
Hình 3. 13 Đặt Path truy cập vào trang đăng nhập ........................................................... 46
Hình 3. 14 Thiết lập Thread Properties test case 1 cho LOGIN ........................................ 46

Hình 3. 15 Kết quả chạy test case 1 LOGIN hiển thị trên Summary Report...................... 47
Hình 3. 16 Kết quả test case 1 LOGIN hiển thị trên Graph Results .................................. 47
Hình 3. 17 Kết quả test case 1 LOGIN hiển trị trên View Results Tree ............................. 47
Hình 3. 18 Thiết lập Thread Properties test case 2 cho LOGIN ........................................ 48
Hình 3. 19 Kết quả test case 2 LOGIN hiển trị trên View Results Tree ............................. 48
Hình 3. 20 Kết quả test case 2 LOGIN hiển thị trên Summary Report .............................. 48
Hình 3. 21 Kết quả test case 2 LOGIN hiển thị trên Graph Results .................................. 48
Hình 3. 22 Đặt địa chỉ http default truy cập vào đăng kí ................................................... 49
Hình 3. 23 Đặt Path truy cập vào chức năng đăng kí tài khoản ........................................ 50
Hình 3. 24 Đặt Path truy cập vào trang đăng kí tài khoản ................................................ 50
Hình 3. 25 Thiết lập Thread Properties cho test case 1 REGISTER.................................. 50


Hình 3. 26 Kết quả test case 1 REGISTER hiển thị trên Graph Results ............................ 51
Hình 3. 27 Kết quả test case 1 REGISTER hiển trị trên View Results Tree ...................... 51
Hình 3. 28 Thiết lập Thread Properties test case 2 REGISTER ........................................ 52
Hình 3. 29 Kết quả test case 2 REGISTER hiển trị trên View Results Tree ...................... 52
Hình 3. 30 Kết quả test case 2 REGISTER hiển thị trên Summary Report ........................ 53
Hình 3. 31 Kết quả test case 2 REGISTER hiển thị trên Graph Results ............................ 53
Hình 3. 32 Đặt địa chỉ http default truy cập vào tour ........................................................ 54
Hình 3. 33 Đặt Path truy cập vào tour the sea explorer .................................................... 54
Hình 3. 34 Đặt Path truy cập vào tour the forest hiker...................................................... 55
Hình 3. 35 Đặt Path truy cập vào tour the snow adventurer ............................................. 55
Hình 3. 36 Thiết lập Thread Properties test case 1 TOUR ................................................ 56
Hình 3. 37 Kết quả test case 1 TOUR hiển thị trên Summary Report ................................ 56
Hình 3. 38 Kết quả test case 1 TOUR hiển thị trên Graph Results .................................... 56
Hình 3. 39 Kết quả test case 1 TOUR hiển trị trên View Results Tree .............................. 57
Hình 3. 40 Thiết lập Thread Properties test case 2 TOUR ................................................ 57
Hình 3. 41 Kết quả test case 2 TOUR hiển trị trên View Results Tree .............................. 58
Hình 3. 42 Kết quả test case 2 TOUR hiển thị trên Summary Report ................................ 58

Hình 3. 43 Kết quảtest case 2 TOUR hiển thị trên Graph Results ..................................... 58
Hình 3. 44 Đặt địa chỉ http truy cập vào trang thanh tốn ................................................ 59
Hình 3. 45 Đặt địa hỉ http default truy cập vào chức năng thanh tốn ............................. 60
Hình 3. 46 Thiết lập Thread Properties cho test case 1 PAYMENT .................................. 60
Hình 3. 47 Kết quả test case 1 PAYMENT hiển thị trên Summary Report ........................ 61
Hình 3. 48 Kết quả test case 1 PAYMENT hiển thị trên Graph Results ............................ 61
Hình 3. 49 Kết quả test case 1 PAYMENT hiển trị trên View Results Tree ....................... 61
Hình 3. 50 Thiết lập Thread Properties cho test case 2 PAYMENT .................................. 62
Hình 3. 51 Kết quả test case 2 PAYMENT hiển trị trên View Results Tree ....................... 62
Hình 3. 52 Kết quả test case 2 hiển thị trên Summary Report ........................................... 63
Hình 3. 53 Kết quả test case 2 hiển thị trên Graph Results ............................................... 63


1
MỞ ĐẦU
1. Lý do lựa chọn đề tài
Trong thời đại công nghệ hiện nay, kiểm thử phần mềm là một bước quan trọng trong
quá trình phát triển phần mềm. Một trong những phương pháp phổ biến được sử dụng trong
kiểm thử phần mềm là kiểm thử hiệu năng website. Để thực hiện kiểm thử hiệu năng này,
các chuyên gia thường sử dụng các cơng cụ hỗ trợ, trong đó Jmeter là một công cụ được sử
dụng rộng rãi và được đánh giá cao bởi cộng đồng chuyên gia kiểm thử phần mềm.
Với mong muốn tìm hiểu, nghiên cứu và ứng dụng công cụ Jmeter để thực hiện kiểm
thử hiệu năng website, chúng tơi đã lựa chọn đề tài "Tìm hiểu công cụ kiểm thử phần mềm
Jmeter và ứng dụng kiểm thử hiệu năng website" nhằm đưa ra các kết quả nghiên cứu và
đánh giá về q trình sử dụng cơng cụ Jmeter để kiểm thử hiệu năng website.
2. Mục tiêu
-

Tìm hiểu được về kỹ thuật kiểm thử hiệu năng website

-

Cách sử dụng công cụ Apache Jmeter

-

Ứng dụng được công cụ vào việc kiểm thử hiệu năng website của nhóm

3. Mục đích
Báo cáo này sẽ cung cấp kiến thức về cơng cụ kiểm thử phần mềm Jmeter và kỹ thuật
kiểm thử hiệu năng website. Ngồi ra, báo cáo cũng trình bày chi tiết q trình nghiên cứu
và ứng dụng của cơng cụ Jmeter để thực hiện kiểm thử hiệu năng website. Mục đích của báo
cáo là giúp mọi người hiểu rõ hơn về công cụ Jmeter và kỹ thuật kiểm thử hiệu năng website,
đồng thời hỗ trợ kiểm thử phần mềm trong quá trình thực hiện kiểm thử hiệu năng website.
4. Ý nghĩa lý luận thực tiễn
Phần nghiên cứu lý thuyết sẽ cung cấp một cách nhìn tổng quát về quá trình kiểm thử
phần mềm và kiểm thử hiệu năng.
Đề tài đã ứng dụng những kiến thức đã học trong công nghệ phần mềm, kiểm thử
phần mềm góp phần nghiên cứu hiệu năng của các ứng dụng web ở môi trường có những
hoạt động với số lượng người dùng lớn.


2
CHƯƠNG 1: TỐNG QUAN VỀ KIỂM THỬ PHẦN MỀM
1.1. Khái niệm
1.1.1. Khái niệm kiểm thử phần mềm
Kiểm thử phần mềm là một cuộc kiểm tra được tiến hành để cung cấp cho các bên
liên quan thông tin về chất lượng của sản phẩm hoặc dịch vụ được kiểm thử.
1.1.2. Vai trị
Kiểm thử có thể cung cấp cho doanh nghiệp một quan điểm, một cách nhìn độc lập

về phần mềm để từ đó cho phép đánh giá và thấu hiểu được những rủi ro trong quá trình
triển khai phần mềm.
Trong kỹ thuật kiểm thử trong chỉ giới hạn ở việc thực hiện một chương trình hoặc
ứng dụng với mục đích đi tìm các lỗi phần mềm mà cịn là một q trình phê chuẩn và xác
minh một chương trình máy tính, ứng dụng, sản phẩm.
1.1.3. Mục đích
- Đáp ứng được mọi yêu cầu hướng dẫn khi thiết kế và phát triển phần mềm.
- Thực hiện công việc đúng như kỳ vọng.
- Có thể triển khai được với những đặc tính tương tự.
- Đáp ứng được mọi nhu cầu của các bên liên quan.
- Phát hiện ra các lỗi phần mềm để từ đó khắc phục và sửa chữa. Việc kiểm thử không
thể khẳng định được rằng các chức năng của sản phẩm đúng trong mọi điều kiện, mà chỉ
có thể khẳng định rằng nó khơng hoạt động đúng trong những điều kiện cụ thể.
1.2. Các loại kiểm thử
Trong kiểm thử Test Type được chia thành 4 loại:
- Testing of function (Functional testing): Kiểm thử chức năng
- Testing of software product characteristics (Non – Functional testing) : Kiểm thử
các đặc tính của sản phẩm phần mềm
- Testing of software structure/architecture (Structural testing): Kiểm thử cấu trúc/
kiến trúc phần mềm


3
- Testing related to changes (Confirmation and regression testing): Kiểm thử liên quan
đến các thay đổi
1.2.1. Kiểm thử chức năng (Functional testing)
Kiểm tra chức năng là kiểm tra xem hệ thống có hoạt động theo đúng các yêu cầu
nghiệp vụ không ? Kiểm thử chức năng được thực hiện ở tất cả các mức kiểm thử.
Kiểm thử chức năng có thể thực hiện theo 2 quan điểm: requirements – based và
business – process – based.

- Requirements – based: sử dụng các đặc tả yêu cầu của hệ thống làm cơ sở để design
test. Sử dụng bảng nội dung của đặc tả yêu cầu như một danh sách các mục kiểm thử và
không kiểm thử, xét độ ưu tiên của yêu cầu dựa trên các tiêu chí rủi ro và sử dụng độ ưu
tiên để kiểm thử. Điều này sẽ đảm bảo những phần quan trọng nhất sẽ được kiểm thử.
- Business – process – based: sử dụng các kiến thức về quy trình nghiệp vụ. Quy trình
nghiệp vụ mơ tả các kịch bản liên quan đến nghiệp vụ hằng ngày của hệ thống.
Kiểm thử chức năng bao gồm 5 bước:
- Xác định các chức năng mà phần mềm mong muốn sẽ thực hiện.
- Tạo các dữ liệu đầu vào dựa trên các tài liệu đặc tả kỹ thuật của các chức năng.
- Xác định các kết quả đầu ra dựa trên các tài liệu đặc tả kỹ thuật của các chức năng.
- Thực hiện các trường hợp kiểm thử.
- So sánh kết quả thực tế và kết quả mong muốn.
Các loại kiểm thử chức năng bao gồm:
- Unit testing: Kiểm thử đơn vị
- Smoke testing: Kiểm thử khói
- Sanity testing: Kiểm thử tình trạng
- Interface testing : Kiểm thử giao diện
- Integration testing : Kiểm thử tích hợp
- System testing : Kiểm thử hệ thống
- Regression Testing : Kiểm thử hồi quy
- Acceptance testing : Kiểm thử chấp nhận


4
1.2.2. Kiểm thử phi chức năng (Non-functional testing)
Kiểm thử phi chức năng là các đặc tính chất lượng của hệ thống sẽ được kiểm tra.
Chúng ta sẽ quan tâm đến việc mọi thứ hoạt động tốt không? Hay nhanh như thế nào? Bao
nhiêu người có thể đăng nhập cùng một lúc? Kiểm thử phi chức năng được thực hiện ở tất
cả các cấp độ kiểm thử.
Kiểm thử phi chức năng bao gồm:

-

Performance testing : Kiểm thử hiệu năng

-

Load testing : Kiểm thử khả năng chịu tải

-

Stress testing : Kiểm thử áp lực

-

Usability testing : Kiểm thử tính khả dụng

-

Maintainability testing : Kiểm thử bảo trì

-

Reliability testing : Kiểm thử độ tin cậy

-

Portability testing : Kiểm thử tính tương thích

Các đặc điểm và các đặc điểm phụ tương ứng:
- Chức năng (Functionality) gồm 5 đặc điểm phụ : sự phù hợp, chính xác, bảo mật,

khả năng tương tác và tuân thủ.
- Độ tin cậy (Reliability) gồm 4 đặc điểm phụ : độ bền, khả năng chịu lỗi, khả năng
phục hồi và tuân thủ.
- Khả năng sử dụng (Usability) gồm 5 đặc điểm phụ : dễ hiểu, khả năng học hỏi, khả
năng hoạt động, sự thu hút và tính tuân thủ.
- Tính hiệu quả (Efficiency) gồm 3 đặc điểm phụ : thời gian (hiệu suất), sử dụng tài
nguyên và tuân thủ.
- Khả năng bảo trì (Maintainability) gồm 5 đặc điểm phụ: khả năng phân tích, khả
năng thay đổi, tính ổn định, khả năng kiểm tra và tuân thủ.
- Tính tương thích (Portability) gồm 5 đặc điểm phụ : khả năng thích ứng, khả năng
cài đặt, cùng tồn tại, khả năng thay thế và tuân thủ.
1.2.3. Kiểm thử cấu trúc/kiến trúc phần mềm (Structural testing)


5
Kiểm thử cấu trúc thường được gọi là “hộp trắng” hoặc “hộp thủy tinh” vì chúng
quan tâm đến những gì đang xảy ra bên trong hộp.
Kiểm thử cấu trúc thường được sử dụng như một cách đo lường của kiểm thử thông
qua độ bao phủ của một tập hợp các yếu tố cấu trúc hoặc các mục bao phủ. Nó có thể xảy
ra ở bất kỳ mức độ kiểm thử nào chủ yếu ở kiểm thử thành phần, tích hợp.
Các kỹ thuật được sử dụng để kiểm tra cấu trúc là kỹ thuật kiểm thử hộp trắng, các
mơ hình luồng điều khiển thường sử dụng để hỗ trợ kiểm thử cấu trúc
1.2.4. Kiểm thử liên quan đến các thay đổi
Confirmation testing (Kiểm thử xác nhận)

-

+ Khi kiểm thử bị lỗi, chúng ta cần thực hiện kiểm tra một lần nữa để xác định rằng
lỗi thực sự đã được sửa.
+ Phải đảm bảo rằng thử nghiệm được thực hiện chính xác giống như lần đầu tiên,

sử dụng cùng một đầu vào, dữ liệu và mơi trường. Sửa lỗi có thể gây ra một lỗi khác trong
phần mềm. Cách phát hiện các bất lợi ngoài ý muốn của việc sửa lỗi là thực hiện kiểm thử
hồi quy.
Regression testing (Kiểm thử hồi quy)

-

+ Giống như kiểm thử xác nhận, kiểm thử hồi quy liên quan đến việc thực hiện các
trường hợp kiểm thử đã được thực hiện trước đó. Sự khác biệt đối với kiểm thử hồi quy,
các trường hợp kiểm thử có thể đúng ở lần cuối cùng chúng được thực thi.
+ Mục đích của kiểm thử hồi quy để xác minh rằng các sửa đổi trong phần mềm hoặc
môi trường không gây ra bất lợi ngoài ý muốn và hệ thống vẫn đáp ứng các yêu cầu của nó.
+ Kiểm thử hồi quy được thực hiện khi phần mềm thay đổi, do sửa lỗi, chức năng
mới. Nó cũng là một ý tưởng tốt để thực thi chúng khi một vài khía cạnh của mơi trường
thay đổi.
1.3. Quy trình kiểm thử
Quy trình kiểm thử có 6 giai đoạn:
-

Requirement Analysis (Phân tích u cầu)

-

Test planning (Lập kế hoạch kiểm thử)


6
-

Test case development (Phát triển kịch bản kiểm thử)

-

Environment setup (Thiết lập môi trường kiểm thử)

-

Test execution (Thực hiện kiểm thử)

-

Test cycle closure (Kết thúc chu kỳ kiểm thử)

1.3.1. Requirement Analysis (Phân tích yêu cầu)
Đây là giai đoạn đầu của kiểm thử. Trong giai đoạn này, các tester sẽ phân tích tài
liệu Prototype (Tài liệu đặc tả yêu cầu) được tạo trong Software development life cycle
(Vòng đời phát triển phần mềm) để kiểm tra các yêu cầu do khách hàng đưa ra.
Yêu cầu được chia làm 2 loại : Functional (Chức năng) và Non-Functional (Phi chức
năng). Yêu cầu về Functional sẽ mơ tả tính năng cịn Non-Functional sẽ mơ tả hiệu năng,
tính bảo mật, tính hữu dụng của phần mềm. Trong q trình phân tích, nếu u cầu cịn mơ
hồ sẽ được xem xét lại, tester đồng thời làm việc với các bên liên quan để làm rõ vấn đề.
Cuối cùng, tester sẽ xác định loại kiểm thử sẽ dùng và độ ưu tiên của các hoạt động kiểm
thử, xác định mơi trường test cần chuẩn bị.

Hình 1. 1 Giai đoạn phân tích yêu cầu
1.3.2. Test planning (Lập kế hoạch kiểm thử)


7
Kế hoạch kiểm thử là một tài liệu tổng quan về việc kiểm thử dự án bao gồm những

thông tin sau:
-

Phạm vi kiểm thử, hướng tiếp cận, quy trình kiểm thử, tài liệu và nhân lực test.

-

Các chức năng/module cần được kiểm tra; các công cụ và các môi trường kiểm thử

cần có.
-

Ai test chức năng nào? Khi nào bắt đầu thực hiện viết và hoàn thành test case? Khi

nào bắt đầu thực hiện và hoàn thành test?
1.3.3. Test case development (Phát triển kịch bản kiểm thử)
Sau khi có test plan, tester bắt đầu xây dựng bộ test case dựa trên yêu cầu của phần
mềm. Test case cần được mô tả chi tiết dữ liệu đầu vào, hành động, kết quả mong đợi để
xác định một chức năng của ứng dụng phần mềm có hoạt động đúng hay khơng. 5 mục đích
chính : ID, mục đích kiểm thử, các bước thực hiện, kết quả mong đợi, kết quả thực tế.
Nếu sử dụng tool để thực hiện test tự động chức năng và giao diện của sản phẩm,
tester sẽ tạo thêm một kịch bản kiểm thử gọi là Test Script (là bản hướng dẫn chi tiết được
viết bằng mã code nhằm hỗ trợ kiểm thử những trường hợp nếu test thủ cơng bằng tay sẽ
rất khó khăn).
Các tester trong cùng một team sẽ review chéo Test Case của nhau tránh bỏ sót
những trường hợp test quan trọng. Một bộ Test Case chất lượng sẽ giúp đảm bảo chất lượng
sản phẩm, hạn chế lỗi và rủi ro nhất cho khách hàng.
1.3.4. Environment setup (Thiết lập môi trường kiểm thử)
Thiết lập môi trường thử nghiệm là một hoạt động độc lập và có thể được bắt đầu
cùng với giai đoạn phát triển kịch bản kiểm thử. Môi trường kiểm thử sẽ do developers tạo

ra để deploy sản phẩm đã được hoàn thiện về phần lập trình.
Sau khi thiết lập mơi trường thử nghiệm, tester thực hiện nhanh Smoke Testing
(Kiểm thử khói) để kiểm tra tính sẵn sàng của mơi trường thử nghiệm đồng thời tính ổn
định của bản build sản phẩm. Nếu mơi trường và bản build đã đủ ổn định để tiến hành test
chi tiết, tester sẽ tiến hành giai đoạn tiếp theo – Thực hiện kiểm thử.


8
1.3.5. Test execution (Thực hiện kiểm thử)
Khi developers đã code và đưa sản phẩm lên môi trường kiểm thử, tester sẽ thực thi
dựa trên Test Case đã viết. Trong quá trình test, nếu phát hiện ra bug thì tester sẽ log trên
các tool quản lý lỗi. Bug của lập trình viên nào sẽ giao lại cho người đấy xử lý. Khi nào
developers fix bug xong, tester sẽ nhận lại và tiến hành kiểm thử.
Nếu lỗi đã được sửa, tính năng hoạt động ổn định, tester sẽ đổi trạng thái thành Close
Bug. Trường hợp lỗi vẫn chưa được fix thành công, trạng thái sẽ được đổi thành Re-open
để developers thực hiện fix lại. Khi nào bug được fix thành công mới được đóng lại việc
test tính năng đấy.
Trong cả q trình kiểm thử phần mềm, tester ưu tiên kiểm tra chức năng chính
trước, chức năng phụ và giao diện sẽ thực hiện test sau. Quá trình kiểm thử phần mềm bắt
buộc phải tuân thủ thời gian đã đề ra, mọi người trong team đôn đốc nhau để kịp tiến độ
bàn giao sản phẩm. Cuối cùng, tester thực hiện làm báo cáo tùy theo yêu cầu của dự án để
đánh giá việc kết thúc quy trình kiểm thử phần mềm.
1.3.6. Test cycle closure (Kết thúc chu kỳ kiểm thử)
Ở giai đoạn cuối cùng, tester chuẩn bị báo cáo kết thúc kiểm thử, tổng hợp lại các
chỉ số trong quá trình test. Cả team phát triển sẽ ngồi họp để đánh giá toàn bộ các tiêu chí
xác định kiểm thử đã đủ hay chưa. Những tiêu chí khác nhau tùy theo từng dự án, thông
thường bao gồm:
-

Số lượng test case tối đa được thực thi Passed.

-

Tỷ lệ lỗi giảm xuống dưới mức nhất định.

-

Deadline được chốt từ giai đoạn làm kế hoạch kiểm thử.
Quy trình kiểm thử phần mềm thường chỉ được kết thúc khi sản phẩm được bàn giao

cho khách hàng. Ngoài ra, hoạt động kiểm thử có thể kết thúc trong các trường hợp sau:
-

Khi 1 dự án bị hủy bỏ.

-

Khi các mục tiêu chính đã hồn thành.

-

Khi việc bảo trì hoặc cập nhật đã hoàn thành.


9
1.4. Các kỹ thuật cơ bản của kiểm thử phần mềm
1.4.1. Kiểm thử Kiểm thử hộp đen (Black Box Testing – BBT)
1.4.1.1. Định nghĩa

Kiểm thử hộp đen hay còn gọi là kiểm tra chức năng và thử nghiệm hành vi.

Xem chương trình như là một “hộp đen”, hồn tồn khơng quan tâm về các mã nguồn
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 tả của nó.
Phương pháp này được đặt tên như vậy bởi vì các chương trình phần mềm, trong
con mắt của các kiểm thử viên, giống như một hộp đen; bên trong mà người ta khơng
thể nhìn thấy. Phương pháp này cố gắng tìm ra các lỗi trong các loại sau:
-

Chức năng khơng chính xác hoặc thiếu.

-

Lỗi giao diện.

-

Lỗi trong cấu trúc dữ liệu hoặc truy cập cơ sở dữ liệu bên ngoài.

-

Hành vi hoặc hiệu suất lỗi.

-

Khởi tạo và chấm dứt các lỗi.

Hình 1. 2 Kiểm thử hộp đen


10

1.4.1.2. Các phương pháp kiểm thử hộp đen
- Đoán lỗi: là một kỹ năng quan trọng của kiểm thử viên, thậm chí có thể gọi là
nghệ thuật, một kiệt tác của trực giác. Phương pháp này đặc biệt dựa vào kinh nghiệm
và kiến thức của kiểm thử viên. Nhiều kiểm thử viên cố gắng đoán xem phần nào
của hệ thống mà có khả năng ẩn chứa lỗi. Với phương pháp này, họ không cần một
công cụ hay một kịch bản kiểm thử nào khi bắt đầu vào việc.
- Phân vùng tương đương (Equivalence Class): là một kỹ thuật kiểm thử phần
mềm có liên quan đến phân chia các giá trị đầu vào thành các phân vùng hợp lệ và
không hợp lệ, sau đó chúng ta sẽ viết ra các kịch bản kiểm thử cho từng phần, chọn
giá trị đại diện từ mỗi phân vùng làm dữ liệu thử nghiệm.
+ Phân vùng tương đương: là kỹ thuật thực hiện kiểm thử theo từng phân vùng
đồng giá trị (tập hợp điều kiện cùng một thao tác).
+ Tập hợp giá trị input có cùng một kết quả xử lý, tập hợp thời gian có cùng một
kết quả xử lý, tập hợp kết quả trích xuất được xử lý cùng một giá trị nhập.
+ Mục đích: Giảm đáng kể số lượng test case cần phải thiết kế vì với mỗi lớp
tương đương ta chỉ cần kiểm thử trên các phần tử đại diện.
+ Chọn tối thiểu một giá trị đại diện từ các phân vùng đồng giá trị để tiến hành
kiểm thử.
+ Nếu có lỗi xảy ra thì các giá trị khác trong phân vùng đồng giá trị cũng sẽ có
lỗi giống nhau.
- Phân tích giá trị biên (Boundary Value Analysis): là một kỹ thuật kiểm thử
phần mềm có liên quan đến việc xác định biên (ranh giới) của điều kiện mô tả cho
các giá trị đầu vào và chọn giá trị ở biên và bên cạnh giá trị biên làm dữ liệu kiểm
thử. Phương pháp phân tích giá trị biên sẽ đưa ra các giá trị đặc biệt, bao gồm loại dữ
liệu, giá trị lỗi, bên trong, bên ngoài biên giá trị, lớn nhất và nhỏ nhất.
+ Kiểm thử giá trị biên được thực hiện theo trình tự dưới đây:
1. Tìm ra đường biên
2. Quyết định giá trị biên

11
3. Quyết định giá trị để kiểm thử
+

Giá trị biên.

+

Dưới giá trị biên. (Nếu là phân vùng đồng giá trị)

+

Trên 1 giá trị biên. (Nếu là phân vùng đồng giá trị)

- Sử dụng bảng quyết định (Decision Tables):
+ Là dùng bảng để hiển thị danh sách các thao tác phần mềm được quyết định
trên các điều kiện khác nhau.
+ Decision table testing chú trọng vào nhiều điều kiện để thực hiện kiểm thử.
+ Ngồi ra, kiểm thử hộp đen cịn có một số kỹ thuật như: Domain Tests,
Orthogonal Arrays, State Models, Exploratory Testing (kiểm thử chủ yếu dựa vào
kinh nghiệm và khả năng tập trung vào việc kiểm tra các chức năng của kiểm thử
viên), All-pairs testing (kiểm thử tất cả các cặp), ...
1.4.1.3. Ưu nhược điểm của kiểm thử hộp đen
- Ưu điểm:
+ Các kiểm thử viên đượ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 kiểm thử viên theo phương pháp black box khơng có “mối ràng buộc” nào với
mã nguồn, và nhận thức của một kiểm thử viên rất đơn giản: một mã nguồn có nhiều lỗi, sử
dụng nguyên tắc: "Hỏi và bạn sẽ nhận" các kiểm thử viên hộp đen tìm được nhiều lỗi ở nơi
mà các lập trình viên khơng tìm thấy.

+ Kiểm thử viên có thể khơng phải IT chun 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 kiểm thử viên có thể được thực hiện bởi một cơ quan độc lập từ các lập trình
viên, 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ộ 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.


12
+ 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.
1.4.2. Kiểm thử hộp trắng (White Box Testing – WBT)
1.4.2.1. Định nghĩa
Kiểm thử hộp trắng là phương pháp kiểm nghiệm dựa vào cấu trúc/mã lệnh
chương trình. WBT kiểm nghiệm một chương trình (một phần chương trình, hay một
hệ thống, một phần của hệ thống) đáp ứng tốt tất cả các giá trị input bao gồm cả các
giá trị khơng đúng hay khơng theo dự định của chương trình. Chiến lược này xuất
phát từ dữ liệu kiểm thử bằng sự kiểm thử tính logic của chương trình. Kiểm thử viên
sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình (và cả mã lệnh
thực hiện chúng).
Do đó người kiểm thử hộp trắng phải có kỹ năng, kiến thức nhất định về ngơn
ngữ lập trình được dùng, về giải thuật được dùng trong thành phần phần mềm để có
thể thơng hiểu chi tiết về đoạn mã cần kiểm thử. Thường tốn rất nhiều thời gian và
công sức nếu thành phần phần mềm quá lớn (thí dụ trong kiểm thử tích hợp hay kiểm
thử chức năng). Do đó kỹ thuật này chủ yếu được dùng để kiểm thử đơn vị. Trong lập
trình hướng đối tượng, kiểm thử đơn vị là kiểm thử từng tác vụ của một lớp chức năng

nào đó.
Có 2 hoạt động kiểm thử hộp trắng :
+ Kiểm thử luồng điều khiển : tập trung kiểm thử giải thuật chức năng.
+ Kiểm thử dòng dữ liệu : tập trung kiểm thử đời sống của từng biến dữ liệu
được dùng trong thuật giải.
1.4.2.2. Các phương pháp kiểm thử hộp trắng

Khi thực hiện kiểm thử bằng whitebox testing thì ta phải có một bộ kiểm thử cho
chương trình đó. Tuy nhiên để biết chắc chắn được là bộ kiểm thử của chúng ta đã
đầy đủ cho tất cả các trường hợp hay chưa, ta sẽ áp dụng các kiến thức của Coverage
tesing để đo đạc kết quả của chương trình khi thực hiện bộ kiểm thử.


13
Coverage testing có thể hiểu là tỉ lệ (tính theo %) test case đã được thực hiện
trên tổng số test case cần thiết cho ứng dụng. Nếu tỉ lệ này càng cao thì ứng dụng càng
được kiểm thử kỹ. Mặc dù việc đảm bảo ứng dụng có test coverage là 100% trong
một số trường hợp là bất khả thi, nhưng ta vẫn sẽ luôn cố gắng để đạt được kết quả
gần với con số đó nhất.
1.4.2.3. Ưu nhược điểm của kiểm thử hộp trắng

- Ưu điểm
+ Kiểm tra được toàn bộ chương trình nguồn
+ Phát hiện lỗi tại chỗ
+ Tự động hóa kiểm thử
- Nhược điểm
+ Yêu cầu người kiểm thử phải am hiểu cấu trúc mã lệnh chương trình. Do dó
địi hỏi tài ngun nhân lực và máy tốn kém.
+ Có khả năng tồn tại các tổ hợp lệnh khác nhau gây lỗi.
+ Không kiểm thử hết đường đi với các vịng lặp lớn, phức tạp.

+ Khó thực hiện và chi phí thực hiện cao
1.5. Kiểm thử hiệu năng
1.5.1. Khái niệm
Kiểm thử hiệu năng (Performance Testing) là một quy trình kiểm thử phần mềm được
sử dụng để kiểm tra tốc độ, thời gian phản hồi, độ ổn định, độ tin cậy, khả năng mở rộng
và mức sử dụng tài nguyên của một ứng dụng phần mềm trong một khối lượng cơng việc
cụ thể. Mục đích chính của kiểm thử hiệu năng là xác định và loại bỏ các tắc nghẽn hiệu
năng trong ứng dụng phần mềm. Nó là một tập hợp con của kỹ thuật hiệu năng và còn được
gọi là “Kiểm thử hoàn hảo” .
Trọng tâm của Kiểm thử hiệu năng là:
+ Thời gian phản hồi: xác định xem ứng dụng phản hồi nhanh hay chậm
+ Khả năng mở rộng: Xác định tải người dùng tối đa mà ứng dụng phần mềm có
thể xử lý.


14
+ Tính ổn định: Xác định xem ứng dụng có ổn định dưới các tải khác nhau hay
không.
1.5.2. Tầm quan trọng của kiểm thử hiệu năng
Các tính năng và chức năng được hỗ trợ bởi một hệ thống phần mềm không phải là
mối quan tâm duy nhất. Hiệu năng của ứng dụng phần mềm, chẳng hạn như thời gian phản
hồi, độ tin cậy, mức sử dụng tài nguyên và khả năng mở rộng, đều quan trọng. Mục tiêu
của Kiểm thử hiệu năng khơng phải là tìm lỗi mà là loại bỏ các tắc nghẽn hiệu năng.
Kiểm thử hiệu năng được thực hiện để cung cấp cho các bên liên quan thơng tin về
ứng dụng của họ về tốc độ, tính ổn định và khả năng mở rộng. Quan trọng hơn, Kiểm thử
hiệu năng phát hiện ra những gì cần được cải thiện trước khi sản phẩm được tung ra thị
trường. Nếu khơng có Kiểm thử hiệu năng, phần mềm có thể gặp phải các vấn đề như: chạy
chậm trong khi nhiều người dùng sử dụng đồng thời, không nhất quán giữa các hệ điều
hành khác nhau và khả năng sử dụng kém.
Kiểm thử hiệu năng sẽ xác định xem phần mềm của họ có đáp ứng các yêu cầu về tốc

độ, khả năng mở rộng và độ ổn định theo khối lượng công việc dự kiến hay không. Các ứng
dụng được đưa ra thị trường có chỉ số hiệu năng kém do không tồn tại hoặc kiểm thử hiệu
năng kém có khả năng bị mang tiếng xấu và khơng đạt được mục tiêu bán hàng dự kiến.
Ngoài ra, các ứng dụng quan trọng như chương trình phóng vào khơng gian hoặc thiết
bị y tế cứu sinh phải được kiểm thử hiệu năng để đảm bảo rằng chúng chạy trong một thời
gian dài mà không bị sai lệch.
1.5.3. Các loại kiểm thử hiệu năng
- Load testing: kiểm thử khả năng của ứng dụng để thực hiện theo tải người dùng dự
đoán. Mục tiêu là để xác định mức độ tắc nghẽn hiệu suất trước khi ứng dụng phần mềm
được phát hành trong môi trường thực tế.
- Stress testing: Liên quan đến việc thử nghiệm một ứng dụng theo khối lượng công
việc quá lớn để xem cách nó xử lý lưu lượng truy cập cao hoặc cách mà nó xử lý dữ liệu.
Mục tiêu là để xác định được điểm giới hạn của một ứng dụng.
- Endurance testing: Mục tiêu để đảm bảo phần mềm có thể xử lý tải dự kiến trong
một khoảng thời gian dài.


15
- Spike testing: Mục tiêu để kiểm tra phản ứng của phần mềm đối với các thay đổi lớn
đột ngột trong tải do người dùng tạo.
- Volume testing: Mục tiêu là để kiểm tra hiệu suất của ứng dụng phần mềm theo khối
lượng cơ sở dữ liệu khác nhau.
- Scalability testing: Mục tiêu của thử nghiệm nhằm đến khả năng mở rộng của ứng
dụng, để xác định hiệu quả của ứng dụng phần mềm khi "mở rộng" để hỗ trợ tăng tải người
dùng, hỗ trợ cho việc lập kế hoạch bổ sung dung lượng cho hệ thống.
1.5.4. Những vấn đề chung về hiệu năng của một hệ thống
Hầu hết các vấn đề về hiệu năng đều xoay quanh tốc độ, thời gian đáp ứng, thời gian
tải và khả năng mở rộng kém. Tốc độ thường là một trong những thuộc tính quan trọng nhất
của ứng dụng. Ứng dụng chạy chậm sẽ mất thời gian, giảm đi sự hài lòng của người dùng
đối với hệ thống, có thể làm mất đi những người dùng tiềm năng. Kiểm thử hiệu năng được

thực hiện để đảm bảo ứng dụng chạy đủ nhanh để thu hút sự chú ý và quan tâm cũng như
đem lại sự thỏa mãn, hài lòng của người dùng.
Dưới đây là danh sách một số vấn đề về hiệu năng chung, qua đây ta cũng nhận thấy
tốc độ là một yếu tố phổ biến nhất:
- Thời gian tải lâu: Thời gian tải thường là thời gian ban đầu để ứng dụng khởi động.
Điều này nói chung nên được giữ ở mức tối thiểu. Mặc dù một số ứng dụng không thể tải
trong vòng một phút, nhưng thời gian tải nên được giữ dưới vài giây nếu có thể.
- Thời gian phản hồi chậm: Thời gian phản hồi là thời gian tính từ khi người dùng
nhập dữ liệu vào ứng dụng cho đến khi ứng dụng đưa ra phản hồi cho dữ liệu đầu vào đó.
Nói chung, điều này sẽ rất nhanh chóng. Một lần nữa, nếu người dùng phải đợi quá lâu, họ
sẽ mất hứng thú.
- Khả năng mở rộng kém: Một sản phẩm phần mềm có khả năng mở rộng kém khi nó
khơng thể xử lý số lượng người dùng dự kiến hoặc khi nó khơng đáp ứng đủ phạm vi người
dùng. Kiểm tra tải nên được thực hiện để chắc chắn rằng ứng dụng có thể xử lý số lượng
người dùng dự kiến.
- Tắc nghẽn cổ chai: Tắc nghẽn cổ chai là những vật cản trong một hệ thống làm giảm
hiệu năng tổng thể của hệ thống. Nghẽn cổ chai là khi lỗi mã hóa hoặc sự cố phần cứng làm


16
giảm thông lượng dưới một số tải nhất định. Hiện tượng thắt cổ chai thường do một đoạn
mã bị lỗi gây ra. Chìa khóa để khắc phục sự cố thắt cổ chai là tìm phần mã gây ra sự chậm
chạp và cố gắng khắc phục nó ở đó. Hiện tượng thắt cổ chai thường được khắc phục bằng
cách sửa các quy trình đang chạy kém hoặc thêm Phần cứng bổ sung. Một số tắc nghẽn
hiệu năng phổ biến là: CPU, bộ nhớ, mạng, hệ điều hành, ổ cứng.
1.5.5. Quy trình kiểm thử hiệu năng
Phương pháp được áp dụng để kiểm tra hiệu năng có thể khác nhau nhưng mục tiêu
của những quá trình kiểm thử hiệu năng vẫn giữ nguyên. Nó có thể giúp chứng minh rằng
hệ thống đáp ứng một số tiêu chí hiệu năng được xác định trước. Hoặc nó có thể giúp so
sánh hiệu năng của hai hay nhiều hệ thống phần mềm. Hoặc nó cũng có thể giúp xác định

các thành phần của hệ thống nào đang làm suy giảm hiệu năng của nó.
Quy trình kiểm thử hiệu năng cơ bản:

Hình 1. 3 Quy trình kiểm thử hiệu năng cơ bản
- Xác định môi trường kiểm thử: Chuẩn bị sẵn sàng môi trường thử nghiệm vật lý,
môi trường sản xuất và công cụ kiểm tra sẵn có. Nắm rõ về cấu hình phần cứng, phần mềm
và mạng được sử dụng trong quá trình kiểm thử trước khi bắt đầu. Nó sẽ giúp tạo ra bộ
Testcase kiểm thử hiệu năng hiệu quả hơn đồng thời nó cũng sẽ giúp xác định các khó khăn
mà người thử nghiệm có thể gặp phải trong q trình kiểm thử hiệu năng.
- Xác định các tiêu chí chấp nhận hiệu năng chấp nhận được của hệ thống: Bao gồm
các mục tiêu và ràng buộc cho thông lượng, thời gian phản hồi và phân bổ nguồn lực. Nó
cũng cần thiết để xác định các tiêu chí thành cơng của dự án. Tester cần xác định được các
tiêu chí và mục tiêu hiệu năng tối thiểu cần đạt của hệ thống bởi vì thông thường các thông
số của dự án sẽ không bao gồm nhiều hoặc khơng có những tiêu chí hiệu năng đủ lớn. Việc
sử dụng một ứng dụng tương tự để so sánh là một cách hay để thiết lập tiêu chí hiệu năng.


17
- Lập kế hoạch và thiết kế kiểm thử hiệu năng: Xác định mức độ sử dụng có thể khác
nhau giữa những người dùng cuối và xác định các tình huống chính để kiểm tra tất cả các
trường hợp sử dụng có thể xảy ra. Cần phải mơ phỏng nhiều người dùng cuối, lập kế hoạch
dữ liệu kiểm tra hiệu suất và phác thảo những số liệu nào sẽ được thu thập.
- Cấu hình mơi trường kiểm thử: Chuẩn bị mơi trường thử nghiệm trước khi thực hiện.
Ngồi ra, sắp xếp các công cụ và các tài nguyên khác.
- Triển khai test design: Tạo testcases kiểm thử hiệu năng theo test design.
- Thực hiện test: Thực thi và theo dõi kết quả thực thi.
- Phân tích, điều chỉnh và kiểm tra lại: Hợp nhất, phân tích và chia sẻ kết quả kiểm
tra. Sau đó, tinh chỉnh và kiểm tra lại để xem có cải thiện hay giảm hiệu suất hay khơng. Vì
các cải tiến thường tăng lên nhỏ hơn với mỗi lần kiểm tra lại, dừng lại khi bị tắc nghẽn do
CPU gây ra. Sau đó, bạn có thể có tùy chọn xem xét tăng tốc độ xử lý của CPU hay không.

1.5.6. Một số công cụ kiểm thử hiệu năng
Có rất nhiều cơng cụ kiểm tra hiệu suất có sẵn trên thị trường. Công cụ bạn chọn để
kiểm tra sẽ phụ thuộc vào nhiều yếu tố, chẳng hạn như loại giao thức được hỗ trợ, chi phí
giấy phép, yêu cầu phần cứng, hỗ trợ nền tảng, v.v. Dưới đây là danh sách các công cụ kiểm
tra được sử dụng phổ biến.
- JMeter: Là phần mềm mã nguôn mở sử dụng 100% ngôn ngữ Java, được thiết kế để
kiểm thử tải (load testing) web and app của máy chủ.
- LoadRunner: là cơng cụ kiểm thử hiệu năng cho phép tìm ra những lỗi về khả năng
thực thi bằng việc phát hiện nguyên nhân, chỗ làm cho phần mềm chạy chậm hoặc không
đúng yêu cầu.
- Load View-Testing: là công cụ kiểm thử hiệu năng cho phép thiết lập đường cơ sở
thời gian phản hồi theo số lượng người dùng tải cụ thể, xác định điểm tắc nghẽn hiệu suất
khi số lượng người dùng đồng thời tăng lên, xác định được giới hạn trên của các hệ thống
hiện tại để lập kế hoạch cho hiệu năng trong tương lai, tăng hiệu năng lên mức cao trên môi
trường test để thấy được cách xử lý dữ liệu và điểm giới hạn hiệu năng của hệ thống.
- LoadStorm: là cơng cụ có khả năng chịu tải rất tốt, có thể kiểm tra hiệu năng của
app thông qua lượng traffic và user. Điểm đặc biệt ở cơng cụ này là nó có thể thiết lập hàng


18
trăm nghìn, thậm chí hàng triệu user để khai thác lỗ hổng trong ứng dụng. Mặt khác, tester
có thể dễ dàng điều chỉnh kịch bản test khi sử dụng công cụ này. Sau khi tiến hành pentest,
bạn sẽ nhìn thấy một bản báo cáo chi tiết.
Kiểm thử hiệu năng (Performance testing) đóng vai trị quan trọng trong việc đảm bảo sự
ổn định và hiệu suất tối ưu của hệ thống. Nó giúp xác định khả năng chịu tải, tìm ra điểm yếu
và tối ưu hóa hiệu suất. Kết quả từ performance testing cung cấp thông tin quan trọng cho việc
đưa ra quyết định về việc nâng cấp hạ tầng, tối ưu mã nguồn và tăng cường khả năng mở rộng.
Điều này đảm bảo rằng hệ thống có thể đáp ứng được yêu cầu tải cao, đảm bảo trải nghiệm
người dùng tốt và tránh các vấn đề về thời gian phản hồi chậm hoặc sự gián đoạn không mong
muốn. Performance testing cũng giúp giảm rủi ro về thất bại hoặc sự cố trong môi trường thực

tế, đảm bảo rằng hệ thống hoạt động một cách ổn định và đáng tin cậy. Tóm lại, performance
testing là một q trình khơng thể thiếu để đảm bảo hiệu suất tối ưu và sự thành công của hệ
thống.