LỜI CAM ĐOAN
Em xin cam đoan đây là phần nghiên cứu và thể hiện đồ án tốt nghiệp của
riêng em, dưới sự hướng dẫn của Th.S Hoàng Thị Cành. Những phần sử dụng tài
liệu tham khảo trong đồ án đã được nêu rõ trong phần tài liệu tham khảo. Nếu sai
em xin chịu hoàn toàn trách nhiệm và chịu mọi kỷ luật của khoa và nhà trường đề
ra.

Người cam đoan

Nguyễn Thị Thu Hoài

1


LỜI CẢM ƠN
Để có được kết quả như ngày hôm nay, trước tiên em xin gửi lời cảm ơn sâu
sắc tới ThS. Hoàng Thị Cành, giảng viên bộ môn Công nghệ phần mềm, khoa Công
nghệ thông tin, Trường Đại học Công nghệ thông tin và truyền thông Thái Nguyên
đã tận tình hướng dẫn, giúp đỡ em trong suốt quá trình nghiên cứu và thực hiện đồ
án tốt nghiệp.
Em cũng xin bày tỏ lòng biết ơn chân thành tới các thầy cô giáo trong Trường
Đại học Công nghệ thông tin và truyền thông Thái Nguyên, đặc biệt là các thầy cô
trong khoa Công nghệ thông tin đã tận tụy dạy dỗ em trong quá trình học tập, rèn
luyện suốt thời gian qua, giúp em có được những kiến thức không chỉ để hoàn thành
đồ án mà còn học tập và làm việc sau này.
Trong quá trình thực hiện đồ án, mặc dù đã cố gắng để hoàn thiện đề tài tốt
nhất có thể, nhưng chắc chắn không thể tránh khỏi những thiếu sót. Vì vây, em rất
mong nhận được sự góp ý của thầy cô và các bạn để đồ án của em được hoàn thiện
hơn.
Em xin chân thành cảm ơn!
Thái Nguyên, ngày 27 tháng 5 năm 2020

Sinh viên thực hiện

Nguyễn Thị Thu Hoài

2


MỤC LỤC
LỜI CAM ĐOAN...........................................................................................................1
LỜI CẢM ƠN................................................................................................................. 2
MỤC LỤC...................................................................................................................... 3
DANH MỤC HÌNH ẢNH...............................................................................................5
LỜI NÓI ĐẦU................................................................................................................ 6
CHƯƠNG 1. MỘT SỐ KIẾN THỨC CƠ BẢN VỀ KIỂM THỬ PHẦN MỀM................8
1.1. Kiểm thử phần mềm là gì?........................................................................................8
1.2. Quy trình kiểm thử phần mềm...................................................................................8
1.3. Phân loại kiểm thử..................................................................................................10
1.3.1. Căn cứ vào kỹ thuật kiểm thử (Testing Techniques)..........................................10
1.3.2. Căn cứ vào mức độ giai đoạn (Testing Level)...................................................11
1.3.3. Căn cứ vào phương pháp kiểm thử (Testing Methods).......................................14
1.4. Kiểm thử ứng dụng website.....................................................................................16
1.4.1. Khái Quát........................................................................................................16
1.4.2. Đặc điểm về chất lượng của một ứng dụng Website..........................................17
1.5. Công việc khi kiểm thử một ứng dụng website.........................................................18
1.5.1. Kiểm tra chức năng (hồi quy, tích hợp, kiểm thử khói…)..................................19
1.5.2. Kiểm tra sự tương thích trình duyệt..................................................................21
1.5.3. Thử nghiệm tính năng......................................................................................22
1.5.4. Kiểm tra bảo mật.............................................................................................22
1.5.5. Giám sát sản xuất.............................................................................................23
1.5.6. Kiểm tra khả năng sử dụng...............................................................................23

CHƯƠNG 2: NGHIÊN CỨU VỀ CÔNG CỤ KIỂM THỬ JMETER, POSTMAN..........25
2.1. Giới thiệu chung về Jmeter......................................................................................25
2.1.1. Tổng quan về Jmeter........................................................................................25
2.1.2. Sử dụng Jmeter................................................................................................31
2.2. Giới thiệu chung về Postman...................................................................................34
2.2.1. Tổng quan về Postman.....................................................................................34
2.2.2. Sử dụng Postman.............................................................................................38

3


CHƯƠNG 3: TRIỂN KHAI KIỂM THỬ TRÊN WEBSITE CỔNG THÔNG TIN
ĐIỆN TỬ HYNDAI THÀNH CÔNG............................................................................41
3.1. Giới thiệu Website Công thông tin điển tử Hyundai Thành Công...............................41
3.2 Thực thi kiểm thử website........................................................................................43
3.3. Thực thi test............................................................................................................44
3.3.1. Kiểm thử hộp đen............................................................................................44
3.3.2. Kiểm thử hộp trắng..........................................................................................45
3.3.3. Tiến hành thực thi test bằng công cụ Jmeter......................................................49
3.3.4. Tiến hành thực thi test bằng công cụ Postman...................................................55
KẾT LUẬN..................................................................................................................63
TÀI LIỆU THAM KHẢO.............................................................................................64
PHỤ LỤC..................................................................................................................... 66

4


DANH MỤC HÌNH ẢNH

Hình 1.1: Giai đoạn kiểm thử phần mềm..........................................................9

Hình 1.2: Quy trình kiểm thử phần mềm........................................................10
Hình 1.3: Sơ đồ các cấp độ kiểm thử..............................................................11
Hình 1.3: Mô hình kiểm thử hộp trắng............................................................14
Hình 1.4: Mô hình kiểm thử hộp đen..............................................................15
Hình 2.1: Giao diện màn hình của Jmeter.......................................................26
Hình 2.2: Cách hoạt động của Jmeter.............................................................28
Hình 2.3: Các thành phần một kế hoạch kiểm thử..........................................29
Hình 2.4: Giao diện ban đầu khi chạy phần mềm JMeter...............................30
Hình 2.5: Giao diện Theard Group..................................................................30
Hình 2.6: Các yếu tố trong Thread Group.......................................................31
Hình 3.7: Giao diện Thread Group..................................................................31
Hình 2.7: Giao diện Postman..........................................................................36
Hình 2.8: Các thành phần của Settings...........................................................37
Hình 2.10: Các thành phần của API content...................................................37
Hình 3.1: Giao diện trang web........................................................................42

5


LỜI NÓI ĐẦU
Các ứng dụng Web càng ngày càng phát triển mạnh mẽ nhằm đáp ứng tối đa
những nhu cầu của người dùng và dần trở thành nền tảng kết nối thông tin thiết yếu
trong nhiều doanh nghiệp, đóng vai trò quyết định của thương mại điện tử, trao đổi
thông tin. Để có thể đạt được điều này, các ứng dụng Web cần phải có hiệu năng
cao, đáng tin cậy, … Việc đưa ra một ứng dụng Web hoàn hảo cho những người
đang và sẽ sử dụng ứng dụng đã trở thành một thách thức chính trong đảm bảo chất
lượng phần mềm. Sự phức tạp, tính linh hoạt và sự phụ thuộc của các ứng dụng vào
một dịch vụ với nhiều người sử dụng trên các nền tảng khác nhau (hệ điều hành,
trình duyệt, …) là một thách thức mà các nhà phát triển Website phải đối mặt. Điều
này dẫn tới việc kiểm thử ứng dụng Web trở nên thiết yếu đối với các dự án phần

mềm và cần phải có những phương pháp đặc biệt khác với phần mềm truyền thống.
Kiểm thử phần mềm là hoạt động cần thiết vì không có bất cứ một sản phầm
phần mềm nào được tạo ra một cách hoàn hảo, không có lỗi. Một số những lỗi sẽ
không gây ảnh hưởng nhiều đến sản phẩm tuy nhiên có một số lỗi rất lớn cần phải
được sửa chữa kịp thời. Chúng ta cần kiểm tra tỉ mỉ mọi thứ, bất cứ thứ gì chúng ta
tạo ra bởi vì mọi thứ luôn không hoàn hảo 100%. Có một số lý do rõ ràng cho
chúng ta biết lý do tại sao kiểm thử phần mềm là quan trọng và những điều chúng ta
cần lưu ý nên xem xét khi thử nghiệm bất kỳ sản phẩm hoặc ứng dụng nào. Sau khi
tìm hiểu và xem xét, em quyết định chọn đề tài “Kiểm thử Website Cổng thông
tin điện tử Huyndai Thành Công” với mong muốn có được cái nhìn xác thực, rõ
ràng hơn về kiểm thử phần mềm và tiếp cận được với các công cụ kiểm thử tự động
như Jmeter, Postman để làm tiền đề cho định hướng tương lai khi tốt nghiệp đại học
sẽ trở thành một kỹ sư kiểm thử phần mềm.
Mục tiêu đồ án
Đồ án được thực hiện nhằm mục đích tìm hiểu về kiểm thử phần mềm, công
cụ kiểm thử tự động phần mềm. Đồ án tập trung nghiên cứu các loại kiểm thử và
công cụ kiểm thử đối với Website. Từ đó, thực hiện phân tích, xây dựng các test
case cho các chức năng của một website; sử dụng công cụ kiểm thử để kiểm thử
Website. Kết quả kiểm thử góp phần đánh giá được chất lượng của Website đó.

6


Với mục tiêu đặt ra như trên, những nội dung và kết quả chính của đồ án được
trình bày trong ba phần như sau:
Chương 1: Một số kiến thức cơ bản về kiểm thử phần mềm.
Chương 2: Nghiên cứu về công cụ kiểm thử Jmeter, Postman.
Chương 3: Triển khai kiểm thử tự động trên Website Cổng thông tin điện tử
Huyndai Thành Công.
Em xin chân thành cảm ơn!

Sinh viên

Nguyễn Thị Thu Hoài

7


CHƯƠNG 1. MỘT SỐ KIẾN THỨC CƠ BẢN VỀ KIỂM THỬ PHẦN MỀM
1.1. Kiểm thử phần mềm là gì?
Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới
những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía
cạnh nào đó của hệ thống hay thành phần đó.
Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm
lỗi.
Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ
phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp
cho người có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch
vụ phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm
khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong
nhiều ngành khác nhau.
Có thể định nghĩa một cách dễ hiểu như sau: 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ế để đảm bảo mã hóa máy tính thực
hiện theo cái mà chúng đã được thiết kế để làm, và không thực hiện 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,
giúp cho người xây dựng hệ thống và khách hàng thấy được hệ thống mới đã đáp
ứng yêu cầu đặt ra hay chưa.
1.2. Quy trình kiểm thử phần mềm
Mục đích của kiểm thử là thiết kế một chuỗi các trường hợp kiểm thử mà có
khả năng phát hiện lỗi cao. Để cho việc kiểm thử đạt được kết quả tốt cần có sự
chuẩn bị về kế hoạch kiểm thử, thiết kế các trường hợp kiểm thử và các dữ liệu

kiểm thử cho các trường hợp. Đây chính là đầu vào cho giai đoạn kiểm thử. Và sản
phẩm công việc của giai đoạn kiểm thử chính là “báo cáo kiểm thử” mà tài liệu hóa
tất cả các trường hợp kiểm thử đã chạy, dữ liệu đầu vào, đầu ra mong đợi, đầu ra
thực tế và mục đích của kiểm thử, … (như Hình 1.1)

8


Hình 1.1: Giai đoạn kiểm thử phần mềm
Quy trình kiểm thử bao gồm một số giai đoạn:
Lập kế hoạch kiểm thử: Bước đầu tiên là lập kế hoạch cho tất cả các hoạt động sẽ
được thực hiện và các phương pháp được sử dụng. Các chuẩn IEEE bao gồm các
thông tin về tác giả chuẩn bị kế hoạch, danh sách liệt kê của kế hoạch kiểm thử.
Vấn đề quan trọng nhất đối với kế hoạch kiểm thử:
+ Mục đích: Qui định về phạm vi, phương pháp, tài nguyên và lịch biểu của

-

các hoạt động kiểm thử.
+ Các tài liệu tham khảo.
Giai đoạn bố trí nhân viên kiểm thử: Việc kiểm thử thường phải tiến hành một
cách độc lập và các nhóm độc lập có trách nhiệm tiến hành các họat động kiểm

-

thử, gọi là các nhóm kiểm thử.
Thiết kế các trường hợp kiểm thử: Các trường hợp kiểm thử là các đặc tả đầu
vào cho kiểm thử và đầu ra mong đợi của hệ thống cùng với các câu lệnh được

-


kiểm thử.
Các phương pháp hộp đen để kiểm thử dựa trên chức năng.
Các phương pháp hộp trắng để kiểm thử dựa vào cấu trúc bên trong.
Xử lý đo lường kiểm thử bằng cách thu thập dữ liệu.
Đánh giá sản phẩm phần mềm để xác nhận sản phẩm có thể sẵn sàng phát hành
được chưa?

9


Hình 1.2: Quy trình kiểm thử phần mềm
1.3. Phân loại kiểm thử.
1.3.1. Căn cứ vào kỹ thuật kiểm thử (Testing Techniques).
• Kiểm thử tĩnh: (Static Testing)
Là phương pháp kiểm thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và các đặc
tả bằng tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết mà
không cần chạy chương trình. Kiểu kiểm thử này thường được sử dụng bởi chuyên
viên thiết kế người mà viết mã lệnh một mình.
Kiểm thử tĩnh cũng có thể được tự động hóa. Nó sẽ thực hiện kiểm tra toàn bộ bao
gồm các chương trình được phân tích bởi một trình thông dịch hoặc biên dịch mà
xác nhận tính hợp lệ về cú pháp của chương trình.
• Kiểm thử động: (Dynamic Testing)
Là phương pháp kiểm thử phần mềm thông qua việc dùng máy chạy chương trình
để điều tra trạng thái tác động của chương trình. Đó là kiểm thử dựa trên các ca
kiểm thử xác định bằng sự thực hiện của đối tượng kiểm thử hay chạy các chương
trình. Kiểm thử động kiểm tra cách thức hoạt động của mã lệnh, tức là 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. Trong kiểm
thử động, phần mềm phải thực sự được biên dịch và chạy. Kiểm thử động thực sự
bao gồm làm việc với phần mềm, nhập các giá trị đầu vào và kiểm tra xem liệu đầu


10


ra có như mong muốn hay không. Các phương pháp kiểm thử động gồm có kiểm
thử Unit – Unit Tests, Kiểm thử tích hợp – Intergration Tests, Kiểm thử hệ thống –
System Tests, và Kiểm thử chấp nhận sản phẩm – Acceptance Tests.
1.3.2. Căn cứ vào mức độ giai đoạn (Testing Level)
Kiểm thử phần mềm gồm có các cấp độ: Kiểm thử đơn vị, Kiểm thử tích hợp,
Kiểm thử hệ thống và Kiểm thử chấp nhận sản phẩm. (hình 1.3)

Hình 1.3: Sơ đồ các cấp độ kiểm thử
• Kiểm tra mức độ, đơn vị (Unit Test)
Một đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được. Ví
dụ, các hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức (Method)
đều có thể được xem là Unit.
Vì Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động
đơn giản, chúng ta không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận và
phân tích kết quả kiểm thử. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc
phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể Unit đang kiểm
tra. Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test sẽ được đền bù
bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm thử và sửa lỗi ở các
mức kiểm thử sau đó.
Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực hiện
càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần

11


mềm. Thông thường, Unit Test đòi hỏi kiểm thử viên có kiến thức về thiết kế và

code của chương trình. Mục đích của Unit Test là bảo đảm thông tin được xử lý và
xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng
của Unit. Điều này thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được
kiểm tra để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các lệnh
được thực thi trong một Unit. Ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa
then ... else là một nhánh. Thực tế việc chọn lựa các nhánh để đơn giản hóa việc
kiểm thử và quét hết Unit đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để
chọn lựa.
Cùng với các mục kiểm thử khác, Unit Test cũng đòi h ỏi phải chuẩn bị trước các ca
kiểm thử (Test case) hoặc kịch bản kiểm thử (Test script), trong đó chỉ định rõ dữ
liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn. Các Test case và
Test script này nên được giữ lại để tái sử dụng.
• Kiểm tra tích hợp (Intergration Test)
Integration testing là một loại kiểm thử phần mềm mà tìm kiếm để kiểm tra các
giao diện giữa các thành phần dựa vào thiết kế của phần mềm. Các thành phần phần
mềm có thể được tích hợp lại với nhau theo cách lặp đi lặp lại (từng phần nhỏ ghép
lại với nhau, rồi ghép tiếp phần nhỏ khác vào nữa, hành động này lặp lại cho đến
khi kết hợp toàn bộ phần mềm) hoặc tất cả các thành phần cùng tích hợp một lần
(gọi là “big bang”). Thông thường trước đây được xem là một cách làm tốt hơn từ
khi nó cho phép các vấn đề về giao diện được xác định vị trí nhanh hơn và cố định.
Integration testing làm việc để tìm ra lỗi (defect) trong các giao diện và giao tiếp
giữa các thành phần (mô-đun). 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.
• Kiểm tra mức hệ thống (System Test)
System testing kiểm thử một hệ thống đã được tích hợp hoàn chỉnh để xác minh
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.


12


• Kiểm tra hồi quy (Regression Test)
Regression testing tập trung vào việc tìm kiếm lỗi sau khi xảy ra việc thay đổi code.
Đặc biệt, nó tìm kiếm theo cách hồi quy (đệ quy) hoặc kiểm tra các bug cũ có bị lại
hay không. Hồi quy như vậy xảy ra bất cứ khi nào mà chức năng phần mềm trước
đây làm việc đúng đã nhưng làm việc theo mong đợi. Điển hình, hồi quy xảy ra như
là một kết quả không mong muốn của việc thay đổi chương trình, khi phần code
của phần mềm mới được phát triển xung độ với code cũ đang có. Phương pháp
thông thường của kiểm tra hồi quy là bao gồm việc chạy lại các kiểm thử trước đây
và kiểm tra xem có lỗi đã được fixed trước đây bị lỗi lại (bị lại các lỗi cũ đã fixed
rồi). Độ sâu của việc kiểm thử phụ thuộc vào các giai đoạn trong quá trình phát
hành và rủi ro của các tính năng được thêm vào. Chúng có thể được hoàn thành – vì
việc thay đổi đã thêm vào sau bản phát hành hoặc coi nó là mạo hiểm, rất hời hợt,
bao gồm các kiểm thử trường hợp đúng (positive) trên từng chức năng – nếu các
thay đổi được thêm vào trước khi phát hành hoặc coi nó ít rủi ro.
• Kiểm tra chấp nhận sản phẩm (Acceptance Testing)
Kiểm thử chấp nhận có thể có là một trong hai điều sau đây:
1. Một smoke test được sử dụng như là một acceptance test trước khi giới thiệu bản
build mới để thực hiện việc kiểm thử chính, có nghĩa là trước khi thực hiện kiểm
thử tích hợp hoặc hồi qui.
2. Acceptance testing được thực thi bởi khách hàng, thường được thực hiện trong
môi trường thí nghiệm trên phần cứng của họ, được biết như là kiểm thử chấp nhận
người dùng (viết tắt là UAT). Acceptance testing có thể được thực hiện như là một
phần của quá trình chuyển giao (hand-off) giữa 2 pha của quá trình phát triển phần
mềm.
• Alpha Test
Alpha testing là việc kiểm thử hoạt động chức năng thực tế hoặc giả lập do người
dùng/khách hàng tiềm năng hoặc một nhóm test độc lập thực hiện tại nơi sản xuất

phần mềm. Alpha testing thường dùng cho phần mềm đóng gói sẵn để bán (ví dụ
như MS office, window, chương trình diệt virus) là một hình thức kiểm thử chấp
nhận nội bộ, trước khi phần mềm được tiến hành kiểm thử beta.

13


• Beta Test
Beta testing được thực hiện sau alpha testing. Các phiên bản của phần mềm - được
biết như là các phiên bản beta – chúng được phát hành tới một số lượng giới hạn
khán giả bên ngoài nhóm sản xuất phần mềm. Sản phẩm được phát hành đến một số
nhóm người để test nhiều hơn nữa có thể chắc chắn rằng sản phẩm có một số bug.
Thỉnh thoảng, các phiên bản beta được phát hành rộng rãi để tăng phạm vi phản hồi
từ một lượng người sử dụng tương lai lớn nhất.
1.3.3. Căn cứ vào phương pháp kiểm thử (Testing Methods)
Ba trong số những chiến lược kiểm thử thông dụng nhất bao gồm: Kiểm thử hộp
đen, Kiểm thử hộp trắng và Kiểm thử hộp xám.
• White box testing
Kiểm thử hộp trắng hay kiểm thử hướng logic cho phép khảo sát cấu trúc bên trong
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).

Hình 1.3: Mô hình kiểm thử hộp trắng
Các phương pháp kiểm thử hộp trắng:
 Kiểm thử giao diện lập trình ứng dụng API testing (application programming
interface): là phương pháp kiểm thử của ứng dụng sử dụng các API công khai và
riêng tư.
 Bao phủ mã lệnh – Code coverage: tạo các kiểm tra để đáp ứng một số tiêu
chuẩn về bao phủ mã lệnh.


14


 Các phương pháp gán lỗi – Fault injection.
 Các phương pháp kiểm thử hoán chuyển – Mutation testing methods.
 Kiểm thử tĩnh – Static testing: kiểm thử hộp trắng bao gồm mọi kiểm thử tĩnh.
• Black box testing
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 kiểm thử viên là hoàn toàn không quan tâm về cách cư xử 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ó.
Theo hướng tiếp cận này, dữ liệu kiểm tra được lấy chỉ từ các đặc tả.

Hình 1.4: Mô hình kiểm thử hộp đen
Các phương pháp kiểm thử hộp đen:


Phân lớp tương đương – Equivalence partitioning.
Phân tích giá trị biên – Boundary value analysis.
Kiểm thử mọi cặp – Allpairs testing.
Kiểm thử fuzz – Fuzz testing.
Kiểm thử dựa trên mô hình – Modelbased testing.
Ma trận dấu vết – Traceability matrix.
Kiểm thử thăm dò – Exploratory testing.
Kiểm thử dựa trên đặc tả – Specificationbase testing

Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềm theo
những yêu cầu thích hợp. Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ
liệu ra từ đối tượng kiểm thử. Mức kiểm thử này thường yêu cầu các kiểm thử viên


15


xác minh là đối với dữ liệu đầu vào đã cho, giá trị đầu ra (hay cách thức hoạt động)
có giống với giá trị mong muốn trong ca kiểm thử đó hay không. Kiểm thử dựa trên
đặc tả là cần thiết, nhưng không đủ để để ngăn chặn những rủi ro chắc chắn.
Ưu điểm và nhược điểm: Các tester kiểm thử 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. Mặt khác, việc 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.
• Kiểm thử hộp xám
Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuật bên
trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở mức người
sử dụng hay mức hộp đen. Việc thao tác tới dữ liệu đầu vào và định dạng dữ liệu
đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì đầu vào và đầu ra
rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống được kiểm tra.
Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp – Intergartion
testing giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết kế khác nhau,
trong đó chỉ giao diện là được đưa ra để kiểm thử. Kiểm thử hộp xám có thể cũng
bao gồm cả thiết kế đối chiếu để quyết định, ví dụ, giá trị biên hay thông báo lỗi.
1.4. Kiểm thử ứng dụng website
1.4.1. Khái Quát
Các ứng dụng Website đã được phát triển và trở thành một nền tảng kết nối
thông tin thiết yếu trong nhiều doanh nghiệp. Các ứng dụng Website đóng vai trò
quyết định của thương mại điện tử, trao đổi thông tin.
Để có thể đạt được điều này các ứng dụng Website cần phải có hiệu năng
cao, đáng tin cậy,… Việc đưa ra một ứng dụng website hoàn hảo cho những người

đang và sẽ sử dụng ứng dụng đã trở thành một thử thách chính trong đảm bảo chất
lượng. Kiểm thử là một trong những công việc quan trọng để đánh giá chất lượng
của một sản phẩm và đương nhiên là các ứng dụng Website cũng không phải là
ngoại lệ. Các phương pháp kiểm thử thông thường là các kỹ thuật tập trung vào

16


đánh giá các chức năng yêu cầu của ứng dụng. Tuy nhiên, không thể tập trung được
vào hết tất cả các chức năng yêu cầu của ứng dụng. Bởi có rất nhiều chức năng
quan trọng cho người sử dụng ứng dụng như: tính hiệu năng, tính dễ sử dụng, độ tin
cậy và tính bảo mật cần được xem xét. Những yêu cầu và mong đợi của người sử
dụng, những vấn đề về nền tảng và cấu hình, mô hình nghiệp vụ, sự phát triển và
chi phí cho việc kiểm thử là những vấn đề thường hay gặp phải và thay đổi liên tục
đổi xuyên suốt chu trình của một ứng dụng Website. Vì thế, cần thiết phải phát triển
một chiến lược hiệu quả cho việc kiểm thử mà có thể bao quát được giới hạn tổng
thể và rộng lớn của những yêu cầu, chức năng cho một ứng dụng Website qua đó có
thể giúp cho việc cài đặt, hoàn thành ứng dụng cũng như tránh được các rủi ro có
thể gặp.
1.4.2. Đặc điểm về chất lượng của một ứng dụng Website
Người sử dụng không chỉ mong đợi chương trình của họ sẽ vận hành một cách
ổn định, chính xác mà họ còn yêu cầu một số chức năng nào đó phải luôn sẵn sàng
trên 24 giờ trong 1 ngày và 7 ngày trong tuần. Hơn nữa, người sử dụng còn mong
đợi ở chương trình những ưu điểm sau: tính dễ sử dụng, độ tin cậy, tốc độ, tương
thích với các hệ thống khác nhau và tương thích với các phiên bản trong tương lai.
Còn với một ứng dụng Website, thì những yêu cầu về chất lượng gồm:
-

Yêu cầu về chức năng: sự hiện diện của các chức năng đáp ứng những yêu cầu
được xác định. Các yêu cầu cần có nữa là tính phù hợp, chính xác, khả năng


-

tương tác, tuân thủ và bảo mật.
Yêu cầu về độ tin cậy: khả năng của một ứng dung để duy trì sự hiệu quả của

-

nó trong một điều kiện cụ thể và trong một khoảng thời gian xác định.
Yêu cầu về khả năng sử dụng: Tính dễ sử dụng và hiệu quả của một ứng dụng.

-

Vấn đề này có thể được thẩm định bởi một nhóm người dùng giả định.
Yêu cầu về hiệu quả: Tỷ lệ giữa mức độ hiệu quả của một ứng dụng và các tài
nguyên mà nó sử dụng trong các điều kiện cụ thể.

Các yêu cầu về chất lượng đóng một vai trò thiết yếu khi thử nghiệm các ứng dụng
Website. Mặc dù nhìn chung thì chúng tương tự như những yêu cầu về chất lượng
cho các hệ thống phần mềm truyền thống. Tuy nhiên, chúng có thể có mức độ đòi
hỏi cao hơn về chiều sâu.

17


Do ý nghĩa quan trọng của các đặc điểm về chất lượng và sự khác biệt ở cách mà
chúng được kiểm thử, nhiều phương pháp để kiểm thử một ứng dụng Website tập
trung vào một vài đặc điểm. Tuy nhiên, tất cả các đặc điểm đều quan trọng đối với
một ứng dụng Website. Và công việc kiểm thử phải đảm bảo được những yêu cầu
cài đặt thành công.

1.5. Công việc khi kiểm thử một ứng dụng website
Kiểm thử là một hoạt động để đánh giá chất lượng của một sản phẩm phần
mềm quan trọng là cải thiện nó bằng cách tìm ra những thiếu xót, khiếm khuyết.
Một vấn đề thường hay xảy ra trong quá trình phát triển ứng dụng Website đó là các
yêu cầu thường không đầy đủ, tường minh và có thể thay đổi bất cứ lúc nào. Thông
thường chúng ta cần có cái nhìn khái quát về các chức năng cơ bản mà ứng dụng
Website sẽ có. “Cái nhìn khái quát” này sẽ là tầm nhìn để thực hiện phát hành lần
đầu ứng dụng.
Phương pháp tiếp cận nhanh – tập trung vào tính chất lặp và tiến hóa của
một ứng dụng Website và vòng đời phát triển của chúng mà không hề có bất cứ một
đoạn văn bản cụ thể nào định nghĩa về phương pháp này. Các mục tiêu, mối quan
tâm và mong đợi của các bên liên quan có đẻ hình hành cơ sở cho việc thực
nghiệm.
Để hỗ trợ giúp cho những kiểm thử viên có thể có được những cái nhìn sâu
sắc và thấu đáo những mong đợi, kỳ vọng về chất lượng ứng dụng Website của
người sử dụng thì những kiểm thử viên này cần được tham gia càng sớm càng tốt
vào công việc xác định và định nghĩa các yêu cầu theo các phương pháp kỹ thuật
sau:
- Kiểm tra chức năng (hồi quy, tích hợp, kiểm tra khói… )
- Kiểm tra sự tương thích trình duyệt.
- Thử nghiệm tính năng.
- Kiểm tra bảo mật.
- Giám sát sản xuất.
- Kiểm tra khả năng sử dụng.

18


1.5.1. Kiểm tra chức năng (hồi quy, tích hợp, kiểm thử khói…)
Kiểm tra các website cho chức năng chính xác, định dạng, tập tin cookie, và xác

nhận dữ liệu. Chức năng thử nghiệm là lý tưởng để thực hiện kiểm tra khói, kiểm
tra hồi quy, và thử nghiệm hội nhập.
• Kiểm tra các liên kết:
Liên kết bên trong một cấu trúc siêu văn bản mà điểm đến không tồn tại một nút
(các website, hình ảnh, ...) gọi là liên hết hỏng thường xuyên xảy ra sai sót trong
các ứng dụng website. Để kiểm tra tính chính xác của các trang liên kết (link kiểm
tra), tất cả các liên kết được hệ thống theo sau bắt đầu trên một trang bắt đầu, và sau
đó được nhóm trong một đồ thị liên kết (bản đồ website). Khi chạy một kiểm tra
liên kết thường xuyên , người ta thường thấy các liên kết không chỉ là điểm đến
không tồn tại trang, nhưng cũng có các trang không được interlinked với những
trang khác hoặc cái gọi là các trang mồ côi. Những trang mồ côi có thể đến thông
qua một liên kết, nhưng không có một liên kết đến cấu trúc siêu văn bản. Để đơn
giản cho người sử dụng nó không xác định nơi để đi tới, để chúng rời bỏ website.
Ngoài ra, khi vượt qua các liên kết, người ta thường có thể tìm thấy dữ liệu bổ sung
để cung cấp chỉ dẫn tiềm năng lỗi. Ví dụ, độ sâu và bề rộng của các cơ cấu chuyển
hướng, khoảng cách giữa hai trang liên quan, được đo bằng số lượng các liên kết
hoặc lần tải của các trang.
• Kiểm tra các hình thức website trên trang
Kiểm tra các lĩnh vực logic xác nhận cho từng lĩnh vực.
Kiểm tra các giá trị mặc định cho từng lĩnh vực.
Kiểm tra xem các lĩnh vực mật khẩu không hiển thị nội dung mật khẩu.
Kiểm tra giá trị đầu vào không hợp lệ cho từng lĩnh vực.
Xác nhận đáp ứng với một hình thức gửi.
• Thử nghiệm quản lý phiên làm việc và cookie
Kiểm tra các ứng dụng đăng nhập trong phiên bằng cách cho phép và vô hiệu hóa
các tập tin cookie.
Cookie thử nghiệm tiêu cực bằng cách sử dụng một tên miền không phối hợp.
Kiểm tra xem cookie phiên thiết lập lại giữa các phiên trình duyệt.

19



Kiểm tra bảo mật ứng dụng bằng cách xóa các tập tin cookie có chọn lọc trong khi
kiểm tra hoạt động.
• Xác nhận Cascading Style Sheet (CSS) tags
-

Xác định các tag CSS 404 trả lại hoặc lỗi tải khác CSS.
Xác định trên HTML id, class, và các thuộc tính tên không phù hợp với bất kỳ
thẻ CSS nào.

20


• Xác nhận thẻ JavaScript:
-

Xác định các tag Script trả lại lỗi 404 hoặc lỗi tải khác.
Xác định id, tên, trên ... thuộc tính không phù hợp với bất kỳ thẻ Script.

• Kiểm tra nội dung động (kiểm tra cơ sở dữ liệu):
-

Kiểm tra dữ liệu thống nhất trong các hình thức website cơ sở dữ liệu theo định

-

hướng.
Kiểm tra chức năng tạo, chỉnh sửa, xóa, cập nhật công việc.
Kiểm tra dữ liệu cung cấp dữ liệu chính xác.

Xác định kết nối cơ sở dữ liệu và các lỗi truy vấn.

1.5.2. Kiểm tra sự tương thích trình duyệt
Sự khác biệt trong các trình duyệt Website, môi trường hoạt động, và các thiết bị
phần cứng ảnh hưởng đến các hoạt động chính xác của ứng dụng Website của bạn.
• Trình duyệt tương thích:
Thử nghiệm ứng dụng website của bạn cho chức năng chính xác trên một số trình
duyệt như Firefox, IE, Chrome, Opera, và Safari. Lý tưởng nhất là ứng dụng
website của bạn xử lý sự khác biệt trình duyệt thanh lịch.
Kiểm tra chức năng ứng dụng với một loạt các cài đặt cấu hình bảo mật trình
duyệt.
Kiểm tra chức năng ứng dụng với các tính năng trình duyệt bật – tắt (JavaScript,
cookies).
Kiểm tra dựng hình trình duyệt của giao diện người dùng ứng dụng của bạn.
Kiểm tra các thiết lập bảo mật của trình duyệt cho tên miền chéo truy cập và hack.
Kiểm tra chức năng ứng dụng nhất quán trên nhiều phiên bản của một trình duyệt.
• Môi trường hoạt động tương thích:
Kiểm tra ứng dụng giao diện người dùng vẽ trên hệ thống cửa sổ hệ điều hành.
Kiểm tra chức năng tích hợp máy tính để bàn, bao gồm kéo và thả tập tin và lựa
chọn.
thử nghiệm ứng dụng website của bạn trên các hệ điều hành khác nhau, bao gồm
cả Windows, Unix, Mac, Linux, và Solaris.
• Thiết bị di động tương thích:
Kiểm tra khả năng tương thích ứng dụng với các dịch vụ thiết bị, bao gồm cả vị trí
và các dịch vụ quay số.

21


Kiểm tra giao diện người dùng vẽ trên điện thoại di động kích thước màn hình thiết

bị, bao gồm cả màn hình xoay.
Kiểm tra hoạt động ứng dụng chính xác khi điện thoại đang trong và ra khỏi phạm
vi của các dịch vụ mạng.
1.5.3. Thử nghiệm tính năng
 Load Test
- Tuyến tính khả năng mở rộng nơi hiệu suất của một ứng dụng không thay
đổi khi số lượng người dùng tăng lên là Chén Thánh của thử nghiệm ứng
dụng Website. Kiểm tra tải trọng xác định một chỉ số Khả năng mở rộng cho
-

hiệu suất ứng dụng website của bạn.
Kiểm tra phản ứng máy chủ để dưới dạng trình duyệt gửi yêu cầu .
Xác định thay đổi hoạt động trong một khoảng thời gian.
Thử nghiệm cho các chức năng mà ngừng làm việc ở các cấp độ cao hơn của

người sử dụng tải.
- Xác định các vấn đề về độ trễ mạng về chức năng ứng dụng Website.
 Stress Test
- Xác định cách thức ứng dụng đáp ứng theo mức độ tải.
- Xác định các phần của ứng dụng website mà không theo mức độ tải .
- Xác định các chức năng ứng dụng sau khi một vụ tai nạn hệ thống hoặc
-

thành phần thất bại.
Xác định các hình thức và các liên kết hoạt động khác nhau theo mức độ tải.

1.5.4. Kiểm tra bảo mật
-

Bảo vệ dữ liệu ứng dụng Website và duy trì chức năng như thiết kế.


-

Kiểm tra các hoạt động mà không cần loging.

-

Kiểm tra xác thực cơ bản sử dụng tên giả và các thông tin mật khẩu.

-

Kiểm tra giấy chứng nhận X.509 an ninh an toàn trên các website.

-

Thử nghiệm cho các chức năng ứng dụng chính xác dựa trên các giá trị thuộc
tính không hợp lệ URL.

-

Kiểm tra các chức năng ứng dụng với các lĩnh vực đầu vào không hợp lệ, bao
gồm các lĩnh vực văn bản.

-

Kiểm tra bảo vệ máy chủ website của các thư mục website không thể truy cập
hoặc các tập tin.

-


Kiểm tra để xác định ứng dụng Website vi phạm an ninh, bao gồm cả thông báo
lỗi và vi phạm an ninh nỗ lực đang được đăng nhập.

22


-

Kiểm tra các lĩnh vực CAPTCHA cho các hình thức website và đăng nhập.

-

Kiểm tra các thiết lập bảo mật trình duyệt để di chuyển từ an toàn vào các
website không an toàn.

1.5.5. Giám sát sản xuất
-

Vận hành thử nghiệm ứng dụng website theo định kỳ và lưu các bản ghi kiểm
tra như là bằng chứng của Hiệp định Cấp Servlice (SLA) tuân thủ.

-

Định kỳ kiểm tra kinh nghiệm người dùng cuối.

-

Cung cấp tự động mở rộng quy mô và hệ thống cân bằng tải với cuối số liệu
kinh nghiệm người dùng.


-

Kiểm tra các chức năng ứng dụng đúng từ nhiều vị trí địa lý.

1.5.6. Kiểm tra khả năng sử dụng
Việc thiết kế và trình bày của một ứng dụng có ảnh hưởng lớn đến thành công
người dùng của bạn sẽ có trong việc sử dụng các ứng dụng Website.
 Kiểm tra đối với Danh mục chính:
-

Kiểm tra người sử dụng có kiểm soát rõ ràng và dễ dàng di chuyển từ trang này
sang trang khác.

-

Kiểm tra dòng chảy của một ứng dụng website bằng cách quan sát cách người
sử dụng hoàn thành mục tiêu của họ.

-

Kiểm tra xem người dùng có thể tìm thấy hướng dẫn nên họ không trực giác
biết làm thế nào để vận hành một chức năng

-

Kiểm tra các đối tượng chuyển hướng chung xuất hiện trên tất cả các trang luôn

-

Chức năng tìm kiếm thử nghiệm cho các chức năng ứng dụng thích hợp

 Kiểm tra nội dung:

-

Kiểm tra nội dung là hợp lý sắp xếp và dễ dàng cho người sử dụng hiểu.

-

Kiểm tra lỗi chính tả.

-

Kiểm tra xem trang từ màu sắc đến hoa văn hướng dẫn phong cách, bao gồm
phông chữ, khung hình, và biên giới.

-

Kiểm tra xem các hình ảnh tải một cách chính xác và có kích thước phù hợp.

23


24


CHƯƠNG 2: NGHIÊN CỨU VỀ CÔNG CỤ KIỂM THỬ JMETER,
POSTMAN
2.1. Giới thiệu chung về Jmeter
2.1.1. Tổng quan về Jmeter.
2.1.1.1. Sơ lược về JMeter

Stefano Mazzocchi của Apache Software Foundation là người đầu tiên xây
dựng phần mềm JMeter. Ông đã viết nó chủ yếu để kiểm thử hiệu năng của Apache
JServ (một dự án từ đó đã được thay thế bằng các dự án Apache Tomcat). JMeter
được phát triển và mở rộng để kiểm thử hiệu năng FTP Server, máy chủ cơ sở dữ
liệu, Java servlet và các đối tượng. Ngày nay, JMeter công bố rộng rãi là một công
cụ kiểm thử hiệu năng cho các ứng dụng web. Nhiều công ty, kể cả AOL sử dụng
JMeter để kiểm thử tải cho trang web của họ. SharpMind của Đức sử dụng JMeter
để kiểm thử chức năng và kiểm thử quy hồi cho các ứng dụng của nó.
JMeter là một ứng dụng chạy trên máy khách, được thiết kế để kiểm thử, đo
lường hiệu năng các ứng dụng mô hình khách/chủ, chẳng hạn như các ứng dụng
web hoặc ứng dụng FTP. Hơn nữa, JMeter là một trong những mã nguồn mở được
sử dụng rộng rãi nhất, là một phần mềm kiểm thử được dùng miễn phí mà .Net có
thể cung cấp.
JMeter là ứng dụng được xây dựng dựa trên nền Java và được đánh giá cao
thông qua API (Application Programming Interface) được cung cấp. JMeter thực thi
tại máy khách trong mô hình “khách/chủ”. Nó đo thời gian trả lời từ máy chủ trả về
máy khách, và đo hiệu suất tất cả tài nguyên khác của máy chủ như khả năng tải
CPU, cách sử dụng bộ nhớ, cách sử dụng tài nguyên. Về mặt này, JMeter có thể
được sử dụng hiệu quả để kiểm thử chức năng một cách tự động. Ngoài ra, JMeter
là công cụ hỗ trợ kiểm thử quy hồi các loại ứng dụng tương tự nhau. Mặc dù nó đã
được thiết kế cho việc kiểm thử các ứng dụng web, nhưng nó cũng được phát triển
để hỗ trợ các kiểm thử chức năng khác. JMeter là dự án đầu tiên và hiện tại vẫn
đang phát triển như là một trong những dự án của Apache Jakarta, dự án này đưa ra
tập hợp các giải pháp mã nguồn mở Java khác nhau.

25