ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

KHOA CÔNG NGHỆ THÔNG TIN
----------

BÁO CÁO
THỰC TẬP CHUYÊN NGÀNH
Đề tài:

TÌM HIỂU CÔNG CỤ KIỂM THỬ JMETER VÀ ỨNG
DỤNG KIỂM THỬ HIỆU NĂNG WEBSITE
Sinh viên thực hiện
Lớp
Giảng viên hướng dẫn

: Ngô Khánh Ly
: KTPM – K12A
: Nguyễn Thu Phương

Thái Nguyên, tháng 03 năm 2017


Mục Lục

2


Danh mục hình ảnh

3


Đề tài tìm hiểu cơ sở lý thuyết của kiểm thử, kiểm thử hiệu năng cũng như cách
triển khai sử dụng công cụ Jmeter để thực hiện kỹ thuật kiểm thử hiệu năng.
3. Ý 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.

5


LỜI CẢM ƠN

Trong quá trình thực hiện đề tài, em đã nhận được sự giúp đỡ và chỉ bảo tận tình
của cô giáo hướng dẫn Nguyễn Thu Phương. Em xin chân thành cảm ơn cô đã giúp
em hoàn thành báo cáo này.
Mặc dù đã cố gắng hoàn thiện đề tài nhưng trong quá trình thực hiện có thể còn
nhiều thiếu sót mong quý thầy cô tận tình chỉ bảo. Em xin chân thành cảm ơn!
Thái Nguyên, tháng 3 năm 2017
Sinh viên thực hiện
Ngô Khánh Ly

6


CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
1.1 Khái niệm
Theo IEEE, kiểm thử là quá trình vận hành hệ thống hoặc thành phần dưới những
điều kiện xác định, quan sát hoặc ghi nhận kết quả và đưa ra đánh giá về hệ thống

Hình 1.1 Kiểm thử hộp đen
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 tester, 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.

1.2.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 tester, 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
tester. Nhiều tester 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.


Chọn tối thiểu một giá trị đại diện từ các class đồng giá trị để tiến hành test.

--> Nếu có lỗi xảy ra thì các giá trị khác trong class đồ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.
•

Test 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

3.

Quyết định giá trị để test

•

Giá trị biên.


ở 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.
- 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.
10


1.2.2 Kiểm thử hộp trắng (White Box Testing – WBT)
1.2.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 tì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ề thuật giải ₫ược dùng trong thành phần phần mềm để có thể
thông hiểu chi tiết về đoạn code 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

•

Bao phủ điều kiện (Branch Coverage, Decision coverage) : Kiểm thử đòi hỏi
phải đủ trường hợp thử nghiệm như vậy mà mỗi điều kiện trong một quyết định có
trên tất cả các kết quả có thể ít nhất một lần. Đó là các nhánh (quyết định) lấy cả 2
trường hợp đúng và sai. Nó giúp trong việc chứng thực tất cả các ngành có mã đảm
bảo rằng đó không có chi nhánh dẫn đến hành vi bất thường của ứng dụng. Ví dụ đoạn
mã:

Ta có thể sinh các test case bao phủ các điều kiện của nhánh:

Hình 1.2 Bao phủ điều kiện trong kiểm thử hộp trắng
•

Bao phủ nhánh (Path Coverage) : Trong các trường hợp kiểm thử được thực
hiện trong một cách mà mọi con đường được thực hiện ít nhất một lần. Tất cả các con
đường kiểm soát có thể được thực hiện, bao gồm tất cả những con đường vòng lấy
bằng không, một lần, và nhiều (lý tưởng là tối đa) các trường hợp thử nghiệm được
chuẩn bị dựa trên các biện pháp phức tạp logic của một thiết kế thủ tục. Để hoàn thiện
bao phủ nhánh, chúng ta phải xét thêm 2 trường hợp bug(a) khi đúng và khi sai.

12


Hình 1.3 Bao phủ nhánh trong kiểm thử hộp trắng
1.2.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ử

• Thiết kế các ca kiểm thử
• Tạo dữ liệu thử
- Kiểm thử với tất cả các dữ liệu vào là cần thiết, không thể kiểm thử “vét cạn”.
- Chọn tập các dữ liệu thử đại diện từ miền dữ liệu vào dựa trên các tiêu chuẩn
chọn dữ liệu thử.
• Thực thi chương trình trên dữ liệu thử:
- Cung cấp dữ liệu thử,
- Thực thi,
- Ghi nhận kết quả.
• Quan sát kết quả kiểm thử
- Thực hiện trong khi hoặc sau khi thực thi.
- So sánh kết quả nhận được và kết quả mong đợi.

Hình 1.4 Quy trình kiểm thử phần mềm
Quá trình kiểm thử phần mềm có hai mục tiêu riêng biệt:
1. Chứng minh cho người phát triển và khách hàng thấy các yêu cầu của phần
mềm. Với phần mềm truyền thống, điều này có nghĩa là ta có ít nhất một thử
nghiệm cho mỗi yêu cầu của người dùng và tài liệu hệ thống yêu cầu.Với
các sản phẩm phần mềm chung, điều đó có nghĩa là ta nên thử nghiệm tất cả
các đặc tính của hệ thống sẽ được kết hợp trong sản phẩm phát hành.

14


2. Phát hiện các lỗi và khiếm khuyết trong phần mềm: phần mềm thực hiện
không đúng, không như mong đợi hoặc không làm theo như đặc tả. Kiểm tra
khiếm khuyết tập trung vào việc tìm ra tất cả các kiểu thực hiện không như
mong đợi của hệ thống, như sự đổ vỡ hệ thống, sự tương tác không mong
muốn với hệ thống khác, tính toán sai và sai lạc dữ liệu.


động này lặp đi lặp lại cho đến khi kết hợp toàn bộ thành phần phần mềm.
- Kiểm thử tích hợp làm việc để tìm ra lỗi trong các giao diện và giao tiếp giữa
các thành phần (module).
- Các nhóm thành phần phần mềm đã được kiểm thử lớn dần từng bước tương
ứng với các yếu tố của thiết kế kiến trúc đã được tích hợp và kiểm thử cho đến khi
phần mềm hoạt động như một hệ thống.
1.4.3 Kiểm thử hệ thống (System Test)
Kiểm tra hệ thống đã được tích hợp hoàn chỉnh để xác định rằng nó đáp ứng
được yêu cầu. Kiểm thử tích hợp hệ thống chứng thực rằng hệ thống đã được tích
hợp với các hệ thống bên ngoài hoặc hệ thống thứ ba đã được xác định trong các
yêu cầu hệ thống.
Kiểm thử hệ thống gồm nhiều loại kiểm thử khác nhau, trong số đó, các mục
tiêu kiểm thử quan trọng nhất là:
- Kiểm thử chức năng
- Kiểm thử hiệu năng
- Kiểm thử an toàn thông tin
Mục đích: Kiểm tra xem hệ thống được làm ra có thỏa mãn yêu cầu hay
không về nhiều khía cạnh: hoạt động, độ tin cậy, hiệu năng của hệ thống.
Việc lập kế hoạch cho kiểm thử hệ thống nên bắt đầu từ giai đoạn bắt đầu dự
án.
1.4.4 Kiểm thử hồi quy (Regression Test)
Kiểm thử hồi quy là hoạt động trợ giúp để đảm bảo rằng các thay đổi không đưa ra
những hành vi hoặc những lỗi bỏ sung không mong đợi.
Kiểm thử hồi quy có thể được thực hiện thủ công, bằng cách thực hiện lại tập con
tất cả các trường hợp kiểm thử hoặc sử dụng công cụ tự động. Bộ kiểm thử hồi quy
gồm ba lớp các trường hợp kiểm thử khác nhau:
- Một mẫu đại diện của các kiểm thử sẽ được thực hiện tất cả các chức năng của
phần mềm.
- Các trường hợp kiểm thử bổ sung tập trung vào các chức năng phần mềm có khả
năng bị tác động khi có sự thay đổi.

Kiểm thử đang được xem là giải pháp chủ yếu nhằm đảm bảo chất lượng
cho các sản phẩm phần mềm. Tuy nhiên, các hoạt động kiểm thử hiện nay chủ
yếu được thực hiện một cách thủ công và tiêu tốn khoảng 30-50% tài nguyên
(thời gian, nhân lực và chi phí) của quá trình phát triển sản phẩm phần mềm.
Hơn nữa, độ phức tạp của các phần mềm ngày càng tăng và trong môi trường
cạnh tranh như hiện nay đòi hỏi các công ty phần mềm phải áp dụng các
phương pháp và công cụ nhằm tự động hóa các hoạt động kiểm thử.

17


1.5.1 Tổng quan về kiểm thử tự động
Kiểm thử tự động là quá trình thực hiện một cách tự động các bước trong một
kịch bản kiểm thử. Kiểm thử tự động bằng một công cụ nhằm rút ngắn thời gian
kiểm thử.
Mục đích của kiểm thử tự động là giảm thiểu thời gian, công sức và kinh
phí, tăng độ tin cậy, tăng tính hiệu quả và giảm sự nhàm chán cho người kiểm
thử trong quá trình kiểm thử sản phẩm phần mềm.
Kiểm thử tự động sẽ được sử dụng khi dự án không đủ tài nguyên (thời gian,
nhân lực và chi phí), phải thực hiện kiểm thử hồi quy khi sản phẩm được sửa
đổi hoặc nâng cấp và cần kiểm thử lại các tính năng đã thực hiện tốt trước đó,
kiểm tra khả năng vận hành của sản phẩm trong các môi trường đặc biệt (đo tốc
độ xử lý trung bình ứng với mỗi yêu cầu, xác định khả năng chịu tải tối đa, xác
định cấu hình tối thiểu để thực thi hệ thống, kiểm tra các cơ chế an ninh và an
toàn,...).
1.5.2 Quy trình kiểm thử tự động

Hình 1.5 Quy trình kiểm thử tự động
 Lập kế hoạch kiểm tra
- Mục đích: Nhằm chỉ định và mô tả các loại kiểm tra sẽ được triển khai và

xem xét nhằm bảo đảm các kế hoạch là khả thi, cũng như để phát hiện
(và sữa chữa sau đó) các sai sót trong các bản kế hoạch.
 Thiết kế Test
- Mục đích: Nhằm chỉ định các Test Case và các bước kiểm tra chi tiết cho mỗi
phiên bản phần mềm. Giai đoạn thiết kế test là hết sức quan trọng, nó bảo đảm
tất cả các tình huống kiểm tra "quét" hết tất cả yêu cầu cần kiểm tra. Hình 1.7
cho thấy việc thiết kế test không phải chỉ làm một lần, nó sẽ được sửa chữa, cập
nhật, thêm hoặc bớt xuyên suốt chu kỳ phát triển phần mềm, vào bất cứ lúc nào
19


có sự thay đổi yêu cầu, hoặc sau khi phân tích thấy cần được sửa chữa hoặc bổ
sung.

Hình 1.7 Thời điểm phù hợp để thiết lập các kế hoạch kiểm tra
- Các bước thiết kế test bao gồm:
• Xác định và mô tả Test Case: xác định các điều kiện cần thiết lập trước
và trong lúc kiểm tra. Mô tả đối tượng hoặc dữ liệu đầu vào, mô tả các
kết quả mong chờ sau khi kiểm tra.
• Mô tả các bước chi tiết để kiểm tra: các bước này mô tả chi tiết để hoàn
thành một Test Case khi thực hiện kiểm tra. Các Test Case như đã nói ở
trên thường chỉ mô tả đầu vào, đầu ra, còn cách thức tiến hành như thế
nào thì không được định nghĩa. Thao tác này nhằm chi tiết hóa các bước
của một Test Case, cũng như chỉ định các loại dữ liệu nào cần có để
thực thi các Test Case, chúng bao gồm các loại dữ liệu trực tiếp, gián
tiếp, trung gian, hệ thống...
• Xem xét và khảo sát độ bao phủ của việc kiểm tra: mô tả các chỉ số và
cách thức xác định việc kiểm tra đã hoàn thành hay chưa? bao nhiêu
phần trăm phần mềm đã được kiểm tra? Để xác định điều này có hai
phương pháp: căn cứ trên yêu cầu của phần mềm hoặc căn cứ trên số

kết quả kiểm tra, liệt kê lỗi, chỉ định các yêu cầu thay đổi, và tính toán các số
liệu liên quan đến quá trình kiểm tra (chẳng hạn số giờ, thời gian kiểm tra, số
lượng lỗi, phân loại lỗi...).
- Đánh giá quá trình kiểm tra thường thông qua các bước sau:
• Phân tích kết quả kiểm tra và đề xuất yêu cầu sửa chữa: Chỉ định và
đánh giá sự khác biệt giữa kết quả mong chờ và kết quả kiểm tra thực
tế, tổng hợp và gửi thông tin yêu cầu sửa chữa đến những người có
trách nhiệm trong dự án, lưu trữ để kiểm tra sau đó.
• Đánh giá độ bao phủ: Xác định quá trình kiểm tra có đạt được độ bao
phủ yêu cầu hay không, tỷ lệ yêu cầu đã được kiểm tra (tính trên các
yêu cầu của phần mềm và số lượng code đã viết).
• Phân tích lỗi: Đưa ra số liệu phục vụ cho việc cải tiến các qui trình phát
triển, giảm sai sót cho các chu kỳ phát triển và kiểm tra sau đó. Ví dụ,
tính toán tỷ lệ phát sinh lỗi, xu hướng gây ra lỗi, những lỗi "ngoan cố"
hoặc thường xuyên tái xuất hiện.
• Xác định quá trình kiểm tra có đạt yêu cầu hay không: Phân tích đánh
giá để xem các Test Case và chiến lược kiểm tra đã thiết kế có bao phủ
hết những điểm cần kiểm tra hay không? Kiểm tra có đạt yêu cầu dự án
không? Từ những kết quả này, kiểm tra viên có thể sẽ phải thay đổi
chiến lược hoặc cách thức kiểm tra.
21


•

Báo cáo tổng hợp: Tổng hợp kết quả các bước ở trên và phải được gửi
cho tất cả những người có liên quan.

1.5.3 Ưu nhược điểm của kiểm thử tự động
Ưu điểm

điện tử và trao đổi thông tin.
Muốn tạo ra được ứng dụng web có hiệu năng cao, đáng tin cậy như vậy thì sau
khâu tạo dựng, cần phải kiểm thử ứng dụng đó một cách tỉ mỉ, cẩn thận và chặt chẽ. Về
mặt bản chất, các ứng dụng web cũng là phần mềm, nên các loại kiểm thử áp dụng cho
phần mềm cũng được áp dụng khi kiểm thử ứng dụng web. Tuy nhiên, người kiểm thử
cũng không thể áp dụng một cách cứng nhắc các phương pháp đó, mà cần phải linh
hoạt, biến nó trở nên phù hợp, thích ứng với kiểm thử ứng dụng web.
1.6.2 Phương pháp kiểm thử ứng dụng web
Một ứng dụng web thường có rất nhiều nhóm người sử dụng với nhiều nền tảng
khác nhau (hệ điều hành, trình duyệt…), người ta cũng rất khó có thể đoán được số
lượng người sử dụng một ứng dụng web là bao nhiêu, rồi thời gian hồi đáp yêu cầu của
22


người sử dụng đối với ứng dụng là một trong những yếu tố mang tính quyết định thành
bại của ứng dụng…dẫn đến việc kiểm thử ứng dụng web sẽ có những khác biệt nhất
định so với kiểm thử phần mềm truyền thống. Trong đó, kiểm thử giao diện người
dùng, kiểm thử hiệu năng và kiểm thử bảo mật là những loại kiểm thử mà ứng dụng
web cần chú trọng.
1.6.2.1 Kiểm thử chức năng (Functionality Test)
- Kiểm tra nội dung trình diễn trên trang web: Mỗi thành phần button, textbox,
image, link trên page và bố cục page cần tuân theo chính xác kích thước và vị trí
mà bản thiết kế UI quy định.
- Kiểm tra các link & menu: Kiểm tra tất cả link nội bộ (internal link) và link
ngoại bộ (external link) xem chúng có hoạt động không, có trỏ đến đúng địa chỉ
mong muốn không.
- Kiểm tra các form nhập dữ liệu: Form nhập liệu là nơi browser tiếp nhận thông
tin user nhập vào để chuyển đến server.. Ngoài ra, quá trình chuyển tải thông tin
từ browser đến server cũng cần bảo đảm là thông tin gửi đi khớp với những gì
user nhập vào, không thất lạc và bị sai lệch.

- Tương thích với trình duyệt (trên máy tính và điện thoại di động): Người dùng
khác nhau có thể sử dụng trình duyệt khác nhau tùy theo nhu cầu, thói quen…của họ.
Cần phải kiểm tra ứng dụng web trên càng nhiều trình duyệt càng tốt (IE, Firefox,
Chrome, Safari, Opera…) để kiểm tra sự tương thích. Kiểm tra trên cả các phiên bản
khác nhau của trình duyệt. Kiểm tra trên cả trình duyệt của thiết bị điện thoại thông
minh.
Nếu ứng dụng chạy tốt hơn, hoặc có ưu tiên tương thích hơn với trình duyệt nào đó thì
cần có thông báo tới người dùng.
- Tương thích với hệ điều hành: một số chức năng của ứng dụng có thể không
tương thích với một số hệ điều hành, hoặc có những lưu ý khác khi sử dụng, điều này
cần phải được kiểm tra kỹ và thông báo cho người dùng được biết.
- Tương thích với các thiết bị ngoại vi (máy in…): khi người dùng có lệnh in trang
thì phải đảm bảo tính chính xác của fonts, cỡ chữ, cỡ giấy…mà người dùng đã chọn.
1.6.2.4 Kiểm thử giao diện (Interface test)
Các giao diện chính bao gồm:
•

Giao diện web server và server ứng dụng

•

Giao diện server ứng dụng và giao diện server dữ liệu

24


Kiểm tra tất cả các tương tác giữa các server. Nếu server dữ liệu hoặc web server
trả lại bất kỳ báo lỗi nào cho bất kỳ truy vấn nào từ server ứng dụng thì ngay lập tức
server ứng dụng phải nhận được và cho hiển thị cảnh báo tới người dùng. Kiểm tra các
trường hợp giao dịch bị ngắt đột ngột do người dùng, hoặc kết nối tới server bị gián