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

ĐẠ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

Danh mục các bảng

4


1

LỜI NÓI ĐẦU

1. Lý do lựa chọn đề tài
Hiện nay, Internet đã trở thành một phần không thể thiếu trong cuộc sống với
hàng tỉ website cung cấp các dịch vụ thiết yếu như tìm kiếm thông tin, giải trí, học tập,
mua bán hàng hóa,… Bên cạnh những yếu tố ảnh hưởng tới chất lượng website như
giao diện, khả năng tương thích, chức năng của ứng dụng web và bảo mật thì yếu tố
hiệu năng là một trong những vấn đề rất quan trọng để đánh giá hệ thống và khả năng
mở rộng của web.
Việc xác định số người dùng tối đa, sức tải công việc cũng như thời gian xử lý các
giao tác của các ứng dụng web là rất quan trọng trong quá trình xây dựng và phát triển
web. Kiểm thử hiệu năng nhằm xác định tốc độ, khả năng phân tải và mức độ tin
tưởng của ứng dụng trong môi trường nhiều người dùng, có nhiều hoạt động khác
nhau. Công cụ kiểm tra tự động để kiểm tra hiệu năng ứng dụng web ở điều kiện có sự
điều chỉnh về mức độ tải có thể kể đến như: LoadRunner, Jmeter Apache, LoadStorm,
Pylot, The Grinder,… tuy nhiên, với khả năng chạy trên nhiều hệ điều hành, hỗ trợ đa
giao thức và hoàn toàn miễn phí nên Jmeter được xem là nổi trội hơn.
Vì vậy, xuất phát từ nhu cầu thực tiễn, em chọn đề tài báo cáo thực tập chuyên
ngành là :
“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”
2. Mục tiêu

Đề 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

hoặc thành phần đó.
Kiểm thử là tiến trình thực thi chương trình với mục đích tìm thấy lỗi (Myers, The
art of software testing).
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
những 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 đả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 (Wikipedia).
Mỗi cách định nghĩa đều đưa ra các khía cạnh khác nhau trong việc tìm hiểu kiểm
thử phần mềm, nhưng nói chung lại, Software testing là một trong những kỹ thuật
phần mềm “xác minh và xác nhận” (Verification and Validation). Đầu tiên, đó là hành
động Verification tức là quá trình đánh giá một hệ thống hoặc thành phần để xác định
xem các sản phẩm của một giai đoạn phát triển nhất định đáp ứng các điều kiện áp đặt
vào lúc bắt đầu của giai đoạn đó hay không. Các hoạt động Verification bao gồm việc
kiểm thử và đánh giá. Validation là quá trình đánh giá một hệt thống hoặc một thành
phần trong hoặc ở cuối của quá trình phát triển để xác định xem nó đáp ứng yêu cầu
quy định hay không.

1.2 Các kỹ thuật cơ bản của kiểm thử phần mềm
1.2.1 Kiểm thử hộp đen (Black Box Testing – BBT)
1.2.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”, 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 tả của nó.

7

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.

8


 Kiểm thử dựa vào đồ thị nguyên nhân - kết quả (Cause Effect Graphing): là một kỹ
thuật thiết kế kiểm thử phần mềm liên quan đến việc xác định các trường hợp (điều
kiện đầu vào) và các hiệu ứng (điều kiện đầu ra). Vì các hệ thống hiện nay đều được
phát triển trên nền tảng OOP, do đó, chúng ta có thể có được một đồ thị các đối tượng
mà hệ thống định nghĩa và kết nối. Từ đồ thị này, chúng ta dễ dàng biết các mối quan
hệ của những đối tượng mà hệ thống xử lý, từ đó sẽ cho chúng ta các kịch bản kiểm
thử phù hợp.
 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 test theo từng class đồ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ả export đượ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 test 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 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.

•

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

•

Trên 1 giá trị biên. (Nếu là class đồng giá trị)
9


 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 test.

Ngoà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 focus vào việc test các chức năng của tester), All-pairs testing (kiểm thử tất
cả các cặp), ...
1.2.1.3 Ưu nhược điểm của kiểm thử hộp đen
• Ưu điểm
- Các tester được thực hiện từ quan điểm của người dùng và sẽ giúp đỡ trong
việc sáng tỏ sự chênh lệch về thông số kỹ thuật.
- Các tester theo phương pháp black box không có “mối ràng buộc” nào với
code, và nhận thức của một tester rất đơn giản: một source code có nhiều lỗi, sử
dụng nguyên tắc: "Hỏi và bạn sẽ nhận" các tester black box tìm được nhiều bug

ở nơi mà các DEV không tìm thấy.
- Tester có thể không phải IT chuyên nghiệp, không cần phải biết ngôn ngữ lập
trình hoặc làm thế nào các phần mềm đã được thực hiện.
- Các tester có thể được thực hiện bởi một cơ quan độc lập từ các developer, cho
phép một cái nhìn khách quan và tránh sự phát triển thiên vị.
- Hệ thống thật sự với toàn bộ yêu cầu của nó được kiểm thử chính xác.
- Thiết kế kịch bản kiểm thử khá nhanh, ngay khi mà các yêu cầu chức năng
được xác định.
• Nhược điểm
- Dữ liệu đầu vào yêu cầu một khối lượng mẫu (sample) khá lớn.
- 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

trình hướng đối tượng, kiểm thử đơn vị là kiểm thử từng tác vụ của 1 class 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ử thuật giải 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.2.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ộ test cho
chương trình đó. Tuy nhiên để biết chắc chắn được là bộ test 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ử.
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 test 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.
Có 3 kĩ thuật kiếm thử hộp trắng là:

11


•

Bao phủ câu lệnh (Statement Coverage) : Kiểm thử sao cho mỗi câu lệnh được
thực thi ít nhất 1 lần. Ví dụ đọan mã:
Public int foo(int x, int y) Int z = 0; If (x > 0 && y > 0) { z = x; } Return z; }
Nếu ta gọi foo(1,1) thì dòng z = x sẽ được thực hiện, còn nếu gọi foo(0,1) thì dòng
z = x sẽ không được thực hiện, lúc đó test case của ta sẽ không thỏa điều kiện bao phủ
câu lệnh.

•

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ử

• 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 nguyên 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.2.3 Kiểm thử hộp xám (Gray Box Testing – GBT)
1.2.3.1 Định nghĩa
Kiểm thử hộp xám là một phương pháp kiểm thử phần mềm được kết hợp giữa
kiểm thử hộp đen và kiểm thử hộp trắng. Trong kiểm thử hộp đen, tester kiểm thử các
hàng mục mà không cần biết cấu trúc bên trong của nó, còn trong kiểm thử hộp trắng
thì tester biết được cấu trúc bên trong của chương trình. Trong kiểm thử hộp xám, cấu
trúc bên trong sản phẩm chỉ được biết một phần. Tester có thể truy cập vào cấu trúc
dữ liệu bên trong và thuật toán của chương trình với mục đích là để thiết kế test case,
nhưng khi test thì test như là người dùng cuối hoặc mức hộp đen. Được gọi là kiếm
thử hộp xám vì trong chương trình phần mềm, mắt của tester giống như hộp xám/bán
trong suốt – nhìn qua hộp này ta chỉ có thể thấy được một phần.

13


1.2.3.2 Ứng dụng
Mặc dù phương pháp kiểm thử hộp xám có thể ứng dụng vào nhiều mức test khác
nhau nhưng chủ yếu nó hữu dụng trong mức Intergration Testing – kiểm thử tích hợp.
1.2.3.3 Ưu nhược điểm của kiểm thử hộp xám
Ưu điểm và nhược điểm của Kiểm thử hộp xám được quyết định dựa vào sự kết
hợp các ưu nhược điểm của kiểm thử hộp đen và hộp trắng.

1.3 Quy trình kiểm thử phần mềm
Kiểm thử phần mềm thường bao gồm các bước:

• 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.

1.4 Các giai đoạn hay mức độ kiểm thử phần mềm
1.4.1 Kiểm thử đơn vị (Unit test)
Kiểm thử đơn vị hay còn được gọi là kiểm thử thành phần, đề cập đến việc kiểm
thử chức năng từng phần của mã, thường ở mức độ chức năng. Trong một môi trường
hướng về đối tượng thì điều này thường là cấp độ lớp, và các kiểm thử đơn vị tối thiểu
bao gồm hàm dựng và hàm hủy. Nhiều loại kiểm thử được viết bởi các nhà phát triển
như họ làm việc trong mã (kiểu hộp trắng) để đảm bảo rằng từng hàm riêng biệt hoạt
động đúng như kỳ vọng. Một hàm có thể có nhiều kiểm thử từ đó giúp nắm bắt được
các trường hợp góc hoặc các nhánh trong Code. Kiểm thử đơn vị một mình không thể
đảm bảo hết được từng chức năng của từng bộ phận trong phần phềm nhưng nó được
sử dụng để đảm bảo rằng các khối kiến trúc của phần mềm hoạt động độc lập với
nhau.
Kiểm thử đơn vị là một quá trình phát triển phần mềm có liên quan đến ứng dụng
đồng bộ của một loạt các chiến lược phòng ngừa phát hiện lỗi và để giảm thiểu rủi ro,
thời gian và chi phí. Nó được thực hiện bởi kỹ sư hay nhà phát triển trong suốt giai
đoạn xây dựng của vòng đời phát triển phần mềm. Không chỉ tập trung vào việc đảm
bảo chất lượng truyền thống mà phải gia tăng nó lên vì thế kiểm thử đơn vị có mục
đích loại bỏ những lỗi cấu trúc trước khi mã hóa rồi mới thúc đẩy việc quản lý chất
lượng. Chiến lược này nhằm nâng cao chất lượng cũng như hiệu quả của phần mềm
trong tiến trình quản lý và phát triển chung.
Tùy thuộc vào kỳ vọng của tổ chức phát triển phần mềm, kiểm thử đơn vị có thể
bao gồm phân tích mã tĩnh, phân tích luồng dữ liệu, phân tích dữ liệu, đánh giá mã
cân bằng, phân tích mã bao phủ và các thực hành xác nhận phần mềm khác.
1.4.2 Kiểm thử tích hợp (Intergration Test)
- Kiểm thử tích hợp 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.
15


- Các thành phần 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 đ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.

- Các kiểm thử tập trung vào các thành phần phần mềm vừa bị thay đổi.
Kiểm thử hồi quy là một trong những loại kiểm thử tốn nhiều thời gian và công sức
nhất. Tuy nhiên, việc bỏ qua kiểm thử hồi quy là điều không thể vì có thể dẫn đến tình
16


trạng phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dù ta tưởng rằng
những lỗi đó hoặc không có hoặc đã kiểm thử và sửa chữa rồi.
1.4.5 Kiểm thử chấp nhận (Acceptance Test)
Kiểm thử chấp nhận có thể có là một trong hai điều sau đây:
- 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 quy.
- Acceptance Test đượ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ư thế là kiểm thử chấp
nhận người dùng (viết tắt là UAT). Acceptance Test có thể được thực hiện như là một
phần của quá trình chuyển giao giữa 2 pha của quá trình phát triển phần mềm.
• Alpha test: 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 test thường dùng cho phần mềm đóng gói sẵn để bán 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.
• Beta test: được thực hiện sau Alpha test. 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.5 Kiểm thử tự động (Automate Testing)

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à

thực hiện.
- Kết quả của bước lập kế hoạch là bản tài liệu kế hoạch kiểm thử phần mềm,
bao gồm nhiều chi tiết từ các loại kiểm tra, chiến lược kiểm tra, cho đến thời gian
và phân định lực lượng kiểm tra viên.

18


Hình 1.6 Bản kế hoạch chính và các bản kế hoạch chi tiết
- Các bước lập kế hoạch:
• Xác định yêu cầu kiểm tra: chỉ định bộ phận, thành phần của phần mềm
sẽ được kiểm tra, phạm vi hoặc giới hạn của việc kiểm tra. Yêu cầu
kiểm tra cũng được dùng để xác định nhu cầu nhân lực.
• Khảo sát rủi ro: Các rủi ro có khả năng xảy ra làm chậm hoặc cản trở
quá trình cũng như chất lượng kiểm tra. Ví dụ: kỹ năng và kinh nghiệm
của kiểm tra viên quá yếu, không hiểu rõ yêu cầu.
• Xác định chiến lược kiểm tra: chỉ định phương pháp tiếp cận để thực
hiện việc kiểm tra trên phần mềm, chỉ định các kỹ thuật và công cụ hỗ
trợ kiểm tra, chỉ định các phương pháp dùng để đánh giá chất lượng
kiểm tra cũng như điều kiện để xác định thời gian kiểm tra.
• Xác định nhân lực, vật lực: kỹ năng, kinh nghiệm của kiểm tra viên;
phần cứng, phần mềm, công cụ, thiết bị giả lập... cần thiết cho việc kiểm
tra.
• Lập kế hoạch chi tiết: ước lượng thời gian, khối lượng công việc, xác
định chi tiết các phần công việc, người thực hiện, thời gian tất cả các
điểm mốc của quá trình kiểm tra.
• Tổng hợp và tạo các bản kế hoạch kiểm tra: kế hoạch chung và kế hoạch
chi tiết.
• Xem xét các kế hoạch kiểm tra: phải có sự tham gia của tất cả những
người có liên quan, kể cả trưởng dự án và có thể cả khách hàng. Việc

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ố

lượng code đã viết.
• Xem xét Test Case và các bước kiểm tra: Việc xem xét cần có sự tham
gia của tất cả những người có liên quan, kể cả trưởng dự án nhằm bảo
đảm các Test Case và dữ liệu yêu cầu là đủ và phản ánh đúng các yêu
cầu cần kiểm tra, độ bao phủ đạt yêu cầu, cũng như để phát hiện (và sữa
chữa) các sai sót.

 Phát triển Test Script

20


- Mục đích: Bước này thường không bắt buộc trong các loại và mức kiểm tra,
chỉ yêu cầu trong trường hợp đặc thù cần thiết kế, tạ ra các Test Script có khả
năng chạy trên máy tính giúp tự động hóa việc thực thi các bước kiểm tra đã
đinh nghĩa ở bước thiết kế test.
- Các bước phát triển Test Script bao gồm:
• Tạo Test Script: thủ công hoặc dùng công cụ hỗ trợ để phát sinh script
một cách tự đông.
• Kiểm tra Test Script: xem có “chạy” tốt không nhằm đẩm bảo các Test
Script hoạt động đúng yêu cầu, thể hiện đúng ý đồ cqua các bước kiểm
tra.
• Thành lập các bộ dữ liệu ngoài dành cho các Test Script: bộ dữ liệu này
sẽ được các Test script sử dụng khi thực hiện kiềm tra tự động. Việc
tách riêng dữ liệu cho phép dễ dàng thay đổi dữ liệu khi kiểm tra, cũng
như giúp việc chỉnh sửa hoặc tái sử dụng các script sau này.
• Xem xét và khảo sát độ bao phủ của việc kiểm tra: đảm bảo các test
script được tạo ra bao phủ toàn bộ các bước kiểm tra theo yêu cầu.
 Đánh giá quá trình kiểm tra
- Mục đích: Đánh giá toàn bộ quá trình kiểm tra, bao gồm xem xét và đánh giá

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

Nhược điểm

70% nhanh hơn so với kiểm tra thủ công.
Test coverage rộng hơn.
Kết quả đáng tin cậy.
Đảm bảo tính nhất quán.
Tiết kiệm thời gian và chi phí.
Cải thiện độ chính xác.
Không cần sự can thiệp của con người.
Tăng hiệu quả.
Tái sử dụng test scripts.
Kiểm tra thường xuyên và triệt để.

Mất chi phí tạo các script để thực hiện
kiểm thử tự động.
Tốn chi phí cho bảo trì script.
Đòi hỏi kiểm thử viên phải có kỹ năng tạo
các Scripts kiểm thử tự động.
Không áp dụng được trong việc tìm lỗi
mới của phần mềm.

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

1.6 Kiểm thử ứng dụng web
1.6.1 Giới thiệu về kiểm thử ứng dụng web
Các ứng dụng web càng ngày càng trở nên phổ biến và phát triển mạnh mẽ, nhằm
đáp ứng tối đa những đòi hỏi của người dùng khi họ bật trình duyệt web của mình lên.
Gần như những gì phần mềm truyền thống làm được thì ứng dụng web cũng có thể làm
được. Và cho đến nay, các ứng dụng web đóng vai trò quyết định trong thương mại

đ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.

- Xác minh HTML/CSS: việc xác minh này đặc biệt quan trọng khi developer
thực hiện tối ưu hóa trang web cho các công cụ tìm kiếm, chủ yếu liên quan tới
lỗi cú pháp HTML. Tester sẽ kiểm tra xem trang web có được nhận diện bởi các
công cụ tìm kiếm khác nhau hay không (ví dụ: Google, Yahoo, Bing…)
- Kiểm tra cookie (browser) & session (server): Người dùng có thể tùy chỉnh trên
trình duyệt nhằm quản lý cookies, thực hiện các thao tác cho phép lưu, hoặc xóa,
hoặc chặn…để kiểm tra các tính năng lưu hoặc không lưu trạng thái đăng nhập,
tính năng bảo mật của ứng dụng web.
- Kiểm tra bản dịch (localization): Nếu ứng dụng cần kiểm thử hỗ trợ đa ngôn
ngữ, test bản dịch từng ngôn ngữ là cần thiết để bảo đảm quá trình dịch và gắn
ráp không có sự cố “râu ông này cắm cằm bà kia”, hoặc bản dịch không sát
nghĩa, bị tràn dòng khi dịch, v…v..
- Kiểm tra dữ liệu gửi về server được xử lý đúng: Cần bảo đảm các hoạt động
của ứng dụng web trên máy server có tuân thủ business rule và bản thiết kế.
Kiểm tra bộ nhớ có bị rò rỉ hoặc cache server có được thu dọn đều đặn với mỗi
phiên xử lý hay không.

23


- Kiểm tra database: Kiểm tra dữ liệu truy xuất ra có khớp với giá trị lưu trữ,
kiểm tra dữ liệu ghi xuống có đúng với những gì server nhận được hay không.
1.6.2.2 Kiểm thử tính khả dụng (Usability Test)
Tính khả dụng của trang web được định nghĩa là trang web dễ sử dụng, có hướng
dẫn sử dụng rõ ràng, rành mạch, mỗi trang đều có menu chính và menu này phải nhất
quán.
- Kiểm tra nội dung
- Kiểm tra các logic liên kết và hướng dẫn
- Kiểm tra văn hóa khu vực và đối tượng sử dụng
1.6.2.3 Kiểm thử khả năng tương thích (Compability test)

- 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

đoạn, bị khởi động lại…
1.6.2.5 Kiểm thử hiệu năng (Performance Test)
- Kiểm thử trọng tải (load test): mỗi web app khi xây dựng, dựa vào nhu cầu và
khả năng đáp ứng cấu hình host server sẽ có một yêu cầu tối thiểu cho web app về các
thông số sau: lượng xử lý truy cập cho phép trong cùng 1 lúc (Throughput), thời gian
tối thiểu cho mỗi request/response (response time), lưu lượng tối đa truy cập (query)
vào server, đường truyền (bandwidth, lag latency) và hiệu suất xử lý back-end
(Resource utilization). Để thực hiện load test, ta cần thu thập yêu cầu tải trọng cho
web app từ nhà cung cấp và cấu hình host server. Ta cần giả lập môi trường cài đặt
web app và học cách dùng performance tool để giả lập các lưu lượng truy cập (Vd:
LoadRunner, Jmeter). Để vượt qua loại test này, web app cần chạy đúng và không xảy
ra lỗi trong tất cả function được test với giả lập trọng tải bằng hoặc dưới yêu cầu tối
thiểu.
- Kiểm thử sức chịu đựng (stress test): tương tự như load test nhưng ta cần tăng
lưu lượng giả lập vượt quá mức yêu cầu tối thiểu và tiến hành đo đạc thời gian hệ
thống có thể chịu được trước khi xảy ra sự cố nghiêm trọng. Thông thường, server sẽ
gia tăng lượng response lỗi (request timeout), xử lý chậm chạp dần tỷ lệ thuận với
lượng truy cập quá tải trước khi thực sự xảy ra chết hệ thống (downtime). Kết quả đo
đạc sẽ là thông tin quý giá để đội ngũ hỗ trợ có kế hoạch hồi phục tốt khi thực tế xảy
ra.
1.6.2.6 Kiểm thử bảo mật (Security Test)
- Kiểm tra Captcha cho các đăng nhập tự động
- Kiểm tra việc mã hóa dữ liệu trao đổi
- Kiểm tra SSL và Certificates: Hệ thống SSL (Secure Socket Layer &
Certificate là một biện pháp bảo mật phổ biến nhằm bảo đảm độ tin cậy của web app
và kênh trao đổi với user.
- Kiểm tra việc truy cập tài nguyên thông qua tên miền: mỗi webpage và tài
nguyên trên server (file download, hình ảnh, video…) đều cần được định danh và có
thể được truy cập từ client thông qua đường địa chỉ URL (phần ký tự loằng ngoằng
25