Tìm hiểu về kiểm thử phần mềm tự động và ứng dụng

LỜI NÓI ĐẦU
Cùng với sự phát triển nhanh chóng của ngành gia công phần mềm,
ngành kiểm thử phần mềm tại Việt Nam cũng đang có những bước phát triển vượt
bậc với hàng loạt các đơn hàng kiểm thử phần mềm từ những tập đoàn công nghệ
thông tin (CNTT ) hàng đầu trên toàn thế giới. Thực tế cho thấy, số lượng đơn vị
đào tạo chuyên sâu, các tester chuyên nghiệp về kiểm thử phần mềm không nhiều,
chưa thể đáp ứng được các dự án doanh nghiệp. Nếu xét theo chuẩn quốc tế, tỷ lệ
lập trình viên và tester là 1:3 (cứ 3 lập trình viên thì có 1 tester), đôi khi tỷ lệ này là
1:1 với những dự án đặc thù; thì tại Việt Nam, tỷ lệ ứng với công việc tester chỉ rơi
vào khoảng 1:5. Dù biết công tác kiểm thử, đảm bảo chất lượng giữ vai trò quan
trọng trong việc mang lại tỷ lệ thành công của các dự án phần mềm song không phải
công ty nào cũng có đủ chuyên môn và điều kiện cho phép để thực hiện quy trình
này. Tuy nhiên với những lợi thế cạnh tranh như: nguồn nhân lực rẻ có sẵn trình độ
ký thuật; đầu tư phát triển cơ sở hạ tầng nhanh; môi trường đầu tư an toàn; chất
lượng dịch vụ nổi trội và tỷ lệ thay đổi nhân sự thấp… Việt Nam có thể hi vọng và
tin tưởng vào khả năng trở thành đối tác kinh doanh đầy tiềm năng và hấp dẫn trong
ngành kiểm thử. Do đó, kiểm thử phần mềm hiện đang là một trong những ngành
nghề hấp dẫn nhất trong lĩnh vực CNTT tại Việt Nam hiện nay. Theo thông tin
được các diễn giả chia sẻ tại hội nghị kiểm định phần mềm quốc tê(Vistacon) diễn
ra tại thành phố Hồ Chí Minh đến hết ngày 26-4-2012, Việt Nam liên tục được tổ
chức AT Kearney (UK) đánh giá là 10 điểm đến hàng đầu về kiểm thử phần mềm
trên thế giới.

Ngày nay, tự động hóa được ứng dụng ở rất nhiều lĩnh vực, mục đích thường
rất đa dạng và tùy theo nhu cầu đặc thù của từng lĩnh vực, tuy nhiên điểm chung
nhất vẫn là giảm nhân lực, thời gian và sai sót. Ngành công nghệ thông tin mà cụ
thể là phát triển phần mềm cũng không ngoại lệ. Như chúng ta biết, để tạo ra sản
phẩm công nghệ thông tin hay phần mềm có chất lượng thì hoạt động kiểm thử
phần mềm đóng vai trò rất quan trọng, trong khi đó hoạt động này lại tiêu tốn và
1

chiếm tỷ trọng khá lớn công sức và thời gian trong một dự án. Do vậy, nhu cầu tự
động hoá quy trình kiểm thử phần mềm cũng được đặt ra. Qua thực tế cho thấy, việc
áp dụng kiểm thử tự động hợp lý sẽ mang lại thành công cho hoạt động kiểm thử
phần mềm. Kiểm thử tự động giúp giảm bớt công sức thực hiện, tăng độ tin cậy,
giảm sự nhàm chán và rèn luyện kỹ năng lập trình cho cán bộ kiểm thử.
Năm 2006 IBM cho ra đời sản phẩm The 2007 developerWorks Software
Evaluation Kt (SEK) for Windows, đây là một trong số nhiều phần mềm dùng cho
việc kiểm thử. SEK bao gồm 6 Tool và công cụ Rational Functional Tester nằm
trong số đó, đây là công cụ kiểm thử chức năng của phần mềm, một công cụ kiểm
thử hồi quy tiên tiến, được tự động hóa cho Tester và người phát triển GUI.
Bất kỳ một tổ chức nào cũng có một sự tin cậy của riêng mình vào việc phát
triển của những trình ứng dụng để phục vụ cho những việc cần thiết như đáp ứng
được chức năng của khách hàng đưa ra, để cho khách hàng tỏ ra hài lòng về chất
lượng của những trình ứng dụng và những đòi hỏi về những chức năng, điều kiện
được đáp ứng đầy đủ và không xảy ra sự tùy tiện trong sản phẩm. Một thành phần
chủ yếu cho sự thành công này là tính hiệu quả, quy trình ứng dụng đã hoàn thành
đến mức độ nào, đó là sự phù hợp thích đáng hay là vượt ra khỏi những mong đợi
trong đề án. Lịch trình làm việc không đúng, thường xuyên thay đổi những vấn đề
chung của chương trình ứng dụng IBM Rational Functional Tester được xây dựng
trên những vấn đề này.
Đây chính là lý do thúc đẩy em thực hiện đề tài “Tìm hiểu về kiểm thử phần
mềm tự động và ứng dụng” làm đồ án tốt nghiệp . Mục đích của đề tài là tìm hiểu
cơ sở lý thuyết về kiểm thử cũng như cách triển khai công cụ kiểm thử phần mềm tự
động để giảm nhân lực kiểm thử và đảm bảo chất lượng phần mềm hơn với công
việc kiểm thử bằng tay.
Mục tiêu chính của đề tài là nghiên cứu giai đoạn nào cần áp dụng công cụ
kiểm thử tự động, các yếu tố nào cần kiểm thử chức năng.
Đồ án được hoàn thành dưới sự chỉ bảo tận tình của Th.S Đỗ Thị Tâm –
Giảng viên khoa Công Nghệ Thông Tin, Trường Đại học Công Nghiệp Hà Nội.

Ngoài ra, để có các kiến thức để hoàn thành đồ án này, em cũng xin cảm ơn tới các
giảng viên của Khoa Công Nghệ Thông Tin, Trường Đại Học Công Nghiệp Hà Nội
đã tận tình giảng dạy em trong quá trình học tại trường. Tuy đã hoàn thiện song đồ
án này vẫn sẽ có những thiếu sót. Em hi vọng sẽ nhận được sự đóng góp ý kiến của
các thầy cô và các bạn để đồ án này được hoàn thiện hơn.
Sinh viên thực hiện
Võ Thị Thanh Sang

2


TÓM TẮT ĐỒ ÁN
Đề tài “Tìm hiểu về kiểm thử phần mềm tự động và ứng dụng”
Đồ án này cung cấp các lý thuyết về kiểm thử phần mềm, kiểm thử phần
mềm tự động và ứng dụng kiểm thử tự động trong việc kiểm thử phần mềm với mục
đích:
-

Tìm hiểu về lý thuyết kiểm thử phần mềm.
Tìm hiểu phương pháp xây dựng các tài liệu: test plan, test case.
Nghiên cứu về kiểm thử tự động
Ứng dụng.

3


MỤC LỤC

4

Danh sách các hình vẽ

Danh sách các bảng biểu

5


MỞ ĐẦU
Với mục đích là tìm hiểu cơ sở lý thuyết về kiểm thử cũng như cách triển
khai công cụ kiểm thử phần mềm tự động để giảm nhân lực kiểm thử và đảm bảo
chất lượng phần mềm hơn với công việc kiểm thử bằng tay.
Mục tiêu chính của đề tài là giới thiệu các vấn đề trong kiểm thử, tìm hiểu
giai đoạn nào cần áp dụng công cụ kiểm thử tự động, các yếu tố nào cần kiểm thử
chức năng và đi sâu vào nghiên cứu các tính năng cơ bản của công cụ IBM Rational
Functional Tester, đưa ra tài liệu hướng dẫn cài đặt, sử dụng công cụ một cách đơn
giản và hiệu quả.
Đối tượng và phạm vi nghiên cứu: Đồ án nghiên cứu lý thuyết kiểm thử
phần mềm; bên cạnh đó nghiên cứu công cụ kiểm thử tự động và các tính năng cơ
bản của Tool Rational Functional Tester.
Phương pháp nghiên cứu: Nghiên cứu tổng quan về kiểm thử phần mềm,
các kỹ thuật kiểm thử, nghiên cứu công cụ kiểm thử phần mềm tự động Rational
Fucional tester và ứng dụng vào một chương trình ứng dụng cụ thể.
Với mục tiêu đặt ra như vậy, những nội dung và kết quả nghiên cứu chính
của đồ án được trình bày trong các chương như sau:
Chương 1: Tổng quan về kiểm thử: Chương này giới thiệu về quá trình kiểm
thử, những khái niệm, những thuật ngữ, vấn đề liên quan đến kiểm thử, những mô
hình kiểm thử và các loại kiểm thử thông dụng hiện nay.
Chương 2: Nghiên cứu kiểm thử phần mềm tự động.
Chương 3: Nghiên cứu về phần mềm SEK của IBM và công cụ kiểm thử

IBM Rational Functional Tester.
Chương 4: Nghiên cứu
Phần kết luận đưa ra những đánh giá về những kết quả đạt được và thảo luận
về huớng nghiên cứu tiếp của đồ án.
Trong quá trình thực hiện đồ án, do thời gian cũng như trình độ còn có
những hạn chế nhất định nên không thể tránh khỏi những sai sót. Rất mong nhận
được sự góp ý của các thầy, cô giáo và các bạn để đồ án hoàn thiện hơn. Em xin
chân thành cảm ơn sự hướng dẫn, và giúp đỡ tận tình của cô giáo Th.S Đỗ Thị Tâm
- Giảng viên khoa Công Nghệ Thông Tin, Trường Đại học Công Nghiệp Hà Nội đã
giúp đỡ em trong quá trình học tập cũng như trong quá trình làm đồ án.

6


CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
1.1.

Các khái niệm cơ bản về kiểm thử

1.1.1. Khái niệm phần mềm
Phần mềm là một (bộ) chương trình được cài đặt trên máy tính nhằm thực
hiện một nhiệm vụ tương đối độc lập nhằm phục vụ cho một ứng dụng cụ thể việc
quản lý họat động của máy tính hoặc áp dụng máy tính trong các họat động kinh tế,
quốc phòng, văn hóa, giáo dục, giải trí,…
1.1.2. Lỗi phần mềm
Có rất nhiều định nghĩa khác nhau về lỗi phần mềm, nhưng nhìn chung, có
thể phát biểu một cách tổng quát: “Lỗi phần mềm là sự không khớp giữa chương
trình và đặc tả của nó.”
Dựa vào định nghĩa, chúng ta có thể thấy lỗi phần mềm xuất hiện theo ba
dạng sau:

•

Sai: Sản phẩm được xây dựng khác với đặc tả.

•
Thiếu: Một yêu cầu đã được đặc tả nhưng lại không có trong sản
phẩm được xây dựng.
•

Thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong đặc tả.

Cũng có trường hợp yêu cầu này có thể là một thuộc tính sẽ được người dùng
chấp nhận nhưng khác với đặc tả nên vẫn coi là có lỗi.
a. Vòng đời của lỗi
Một lỗi trong phần mềm là một cái gì đó gây ra cho phần mềm chạy
theo cách mà nó không nhất quán với những yêu cầu hay sự cần thiết của
khách hang hay những chuẩn liên quan. Để có phần mềm chất lượng cao,
sản phẩm cuối cùng nên có có vài lỗi có thể.
• Một lỗi được tìm thấy và phải được ghi lại trong DMS
(Document management system) bởi một nhân viên. Lỗi được
vào trong DMS với trạng thái “Error” và thông tin khác.
• Lãnh đạo dự án phải xem xét lại dữ liệu của một lỗi (như dạng
lỗi, ngồi gốc, tính nguy hại,…), sửa nó và giao cho người sửa
lỗi. Thông thường thành viên được giao là tác giả cảu văn bản
hay đoạn mã nguồn mà lỗi được tìm thấy trong đó. Trạng thái
của lỗi được thay đổi thành “Assigned”.
• Sau khi sửa lỗi, tác giả đổi trạng thái lỗi thành “Pending”.
• Người kiểm thử kiểm thử lại lỗi chưa giải quyết và cập nhật
trạng thái thành “Tested” nếu lỗi được sửa một cách hài long
hay thành “Error”.

7


•

Nếu một lỗi với trạng thái “Error” có thể được chấp nhận mà
không có một hành động hiệu chỉnh nào, lãnh đạo dự án cần
đổi trạng thái thành “Accepted”.

Vòng đời của lỗi được mô hình hóa trong flowchart sau đây:

Hình 1.1.Quá trình bắt lỗi

8


b. Lỗi dữ liệu
Thông tin quan trọng của lỗi bao gồm:
TT

Dữ liệu

Mô tả dữ liệu

1
2

Project Code
Defect ID

Dự án hay sản phẩm bị mắc một lỗi.
Tên của lỗi.

3
4
5
6
7
8

Title
Description
Severity
Type
Status
Stage
detected
QC activity
QC activity

9
10
11
12
13
14
15
16
17

18
19
20
21
22
23
24

Miêu tả ngắn gọn của lỗi.
Miêu tả đầy đủ của lỗi.
Tính nguy hại của lỗi.
Phân loại của lỗi.
Trạng thái hiện tại của lỗi.
Phạm vi hoạt động của dự án xác định vòng đời
khi lỗi được phát hiện.
Hoạt động phát hiện ra lỗi.
Dạng của hoạt động QC như là xem lại, kiểm
tra…
Stage injected Phạm vi hoạt động trong dự án xác định vòng đời
mà từ đó lỗi được gây ra.
Process origin Tên hay mà nguồn của đoạn phần mềm mà trong
đó lỗi là nguồn gốc.
Priority
Mức ưu tiên sửa lỗi.
Creator
Người phát hiện lỗi, người kiểm thử hay người
xem lại.
Create date
Ngày ghi lại lỗi trong dữ liệu lỗi
Assigned to

Người chịu trách nhiệm sửa lỗi, thường là tác
giả.
Due date
Hạn chót mà việc sửa lỗi phải hoàn thành.
Work product Trong sản phẩm mà lỗi được tìm thấy.
Module
Phần của sản phẩm mà lỗi được tìm thấy trong
đó.
Corrective
Hành động để sửa lỗi.
action
Close date
Ngày mà lỗi được đóng.
Reference
Tài liệu tham khảo hay miêu tả về lỗi.
History
Thông tin về lỗi. Tất cả những phần như hiệu
chỉnh,… của lỗi đực thể hiện.
Attached
Ảnh minh họa lỗi.
picture

Bắt buộc/
Tùy chọn
B
B
B
B
B
B

B
T
B
B
T
B
T
B
B
T
T
B
T
T
B
T
T
T

9


c. Dạng của lỗi
Sau đây là một số dạng chung của lỗi:
T
T

Dạng lỗi

Ví dụ

Functionality

Chức năng được chỉ ra không làm việc.

Requirement
misunderstanding
Feature missing

Những yêu cầu đầu vào không được hiểu rõ.

Một phần của đặc tính hay đặc tính không hoàn
thành.
Coding logic
Kỹ năng kỹ thuật, đánh giá dữ liệu… hay những lý
do khác không được xác định như là vấn đề viết
code.
Business logic
Không theo luồng công việc.
User Interface
Lỗi trong giao diện, bố cục.
Performance
Tốc độ xử lý chậm hay lỗi hệ thống do cấu hình;
vấn đề bộ nhớ.
Design issue
Thiết kế được chỉ rõ liên quan vấn đề.
Coding standard
Vấn đề với chuẩn viết mã nguồn.
Document
Lỗi phát hiện trong khi xem lại văn bản. Kế hoạch

dự án, SRS (Software requirements specification),
kế hoạch kiểm thử,…liên quan tới chuẩn văn bản
(mẫu, phiên bản, header/footer,…).
Data
and Vấn đề với xử lý dữ liệu hay luồng dữ liệu: Vào/ra.
Database Integrity
Security
and Vấn đề với đặc quyền người dùng, vấn đề bảo mật.
Access Control
Portability
Mã nguồn không độc lập với platform.
Other
Không như những dạng trên.
Tools
Lỗi gây ra bởi sử dụng công cụ.

1

2
3
4
5
6

7
8
9
10
11

d. Lỗi nguy hại
T
T
1
2
3

Dạng nguy hại

Giải thích

Fatal

Lỗi không cho người dùng sử dụng tiếp tục sử
dụng hệ thống, có lẽ hệ thống bị tấn công.
Hệ thống không thể làm việc tốt.
Lỗi này không ngăn người dùng sử dụng xử lý
nhưng gây ra sự bất tiện.

Serious
Medium

10


4

Cosmetic

Một lỗi mà không có cách nào ảnh hưởng đến

hiệu năng của sản phẩm. Nó có lẽ là một lỗi ngữ
pháp.

e. Trạng thái lỗi
Một lỗi có một vài trạng thái sau đây trong vòng đời của nó:
T
T
1

Status

Description

ERROR

Lỗi không được sửa hay sửa nhưng khống được
hài lòng như mong muốn.
Lỗi được xem lại và được giao sửa nó.
Lỗi được sửa xong và được kiểm thử lại.
Lỗi được sửa một cách hài long như mong
muốn.
Lỗi không được sửa một cách hài lòng như
mong muốn nhưng nó được chấp nhận bởi sự
nhượng bộ của tác giả hay khách hàng.
Nó không là một lỗi hay lỗi được loại bỏ bởi
những hành động với sửa lỗi.

2
3
4

ASSIGNED
PENDING
TESTED

5

ACCEPTED

6

CANCELLED

f. Xử lý nguồn gốc
Xử lý nguồn gốc: Là xử lý mà trong nó bị nhiễm lỗi. Xác định rằng
những phân tích yêu cầu của xử lý này là của một lỗi. Nó được đánh giá từ
độ tự nhiên của lỗi và những thông tin khá về lỗi.
T
T

Tên

Code

Ví dụ lỗi

Contract
Management

01-QT

Những thủ tục không thích hợp; những
thông tin khách hàng thiếu; những yêu
cầu khách hàng không hiểu; quản lý
thay đổi yêu cầu khách hàng không chặt
chẽ.
Giả định không đúng; đặc tả giao diện
không hoàn hảo; luồng xử lý không rõ
rang; yêu cầu không có đặc tả, nhập
nhằng, không hoàn hảo.
Yêu cầu không được thực thu đầy đủ;
logic vấn đề; vaassn đề liên quan đến
chuẩn.
Vấn đề với viết code, logic, xử lý dữ
liệu, vào/ra.

1

Requirements 02-QT
2
Design

03-QT

Coding

04-QT

3
4

11


5
6

Deployment

05-QT

Customer
support
Test

06-QT
07-QT

7

Configuration 08-QT
Management
8

9

10

Project
Management

09-QT

Subcontract
Management

10-QT

Sự triển khai kế hoạch không thích hợp,
giải pháp; những vấn đề môi trường.
Kế hoạch hỗ trợ không rõ ràng.
Sự cố gắng không thích hợp hay lịch
biểu cho kiểm thử; sự không hảo của
yêu cầu kiểm thử hay vạch kế hoạch;
kiểm thử case sai; kiểm thử dữ liệu
thích hợp không xác định; tiêu chuẩn
kiểm thử không thích hợp.
Cấu trúc quản lý cấu hình không thích
hợp; những vấn đề trong đặt tên và
quản lý cấu trúc; quản lý thay đổi trong
kế
hoạch
CM
(Configuration
Management)còn thiếu.
Nỗ lực hay đánh giá lập biểu không
thích hợp; những vấn đề trong đánh giá
rủi ro; sự không hoàn hảo của kế hoạch
dự án.
Lựa chọn nhà thầu phụ khống thích

hợp; quản lý chất lượng nhà thầu phụ
không chặt chẽ.

g. Ưu tiên lỗi
Tác giả có thể dựa vào ưu tiên lỗi để sửa nó
TT
1
2

Ưu tiên
Immediately
High priority

3
4

Normal priority
Low priority

Miêu tả
Lỗi phải được sửa ngay lập tức.
Lỗi nên được ddwua lên mức chú ý cao
hơn.

1.1.3. Kiểm thử phần mềm
Kiểm thử phần mềm là quá trình thực thi một hệ thống phần mềm để xác
định xem phần mềm đó có đúng với đặc tả không và thực hiện trong môi trường
như mong đợi hay không.
Mục đích của kiểm thử phần mềm là tìm ra lỗi chưa được phát hiện, tìm một
cách sớm nhất và đảm bảo rằng lỗi đã được sửa, mà kiểm thử phần mềm không làm

công việc chẩn đoán nguyên nhân gây ra lỗi đã được phát hiện và sửa lỗi.

12


Mục tiêu của kiểm thử phần mềm là thiết kế tài liệu kiểm thử một cách có hệ
thống và thực hiện nó sao cho có hiệu quả, nhưng tiết kiệm được thời gian, công
sức và chi phí.
Định nghĩa về kiểm thử phần mềm:
− Theo IEEE: Kiểm thử là tiến 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 đó.
− Theo Glenford Myers: Kiểm thử là quá trình vận hành chương trình để tìm ra
lỗi. Một ca kiểm thử tốt là ca kiểm thử có xác suất cao tìm ra một lỗi chưa
được phát hiện. Một ca kiểm thử thắng lợi là ca kiểm thư làm lộ ra được ít
nhất một lỗi còn chưa được phát hiện. ( The Art of Software Testing).
− Kiểm thử thành công là phát hiện ra lỗi, kiểm thử không phát hiện ra lỗi là
kiểm thử dở (Sue A.Conger- The New Software Engineering).
1.1.4. Các giai đoạn trong quá trình kiểm thử
Giai đoạn kiểm thử là quá trình kiểm tra sản phẩm phần mềm để tìm kiếm
lỗi. Quy trình kiểm thử phần mềm được chia thành 4 giai đoạn:
•
•
•
•

Kiểm thử đơn vị ( Unit Testing )
Kiểm thử tích hợp ( Integraction Testing )
Kiểm thử hệ thống ( System Testing )

Kiểm thử chấp nhận ( Acceptance Testing )

Hình 1.2. Bốn giai đoạn trong quá trình kiểm thử
Khi kiểm thử, nếu các lỗi được phát hiện tại bất kì mức nào, chúng đòi hỏi
chương trình phải gỡ lỗi và hiệu chỉnh cho chính xác, sau đó cần kiểm thử lại, tức là
cần được lặp lại những kiểm thử nào đó ở mức trước. Trong quy trình này, thông tin
lỗi gặp phải hay mức độ tin cậy đạt được của chương trình ở mỗi giai đoạn sau đều
13


được phản hồi về giai đoạn trước của tiến trình. Vì vậy, tiến trình kiểm thử là tiến
trình lặp.

Bảng tổng hợp các mức kiểm thử:
Loại hình

Đơn vị

Tích hợp

Hệ thống

Hệ thống phần
Tập môđun chức
Đối tượng Môđun đơn vị
mềm,
môi
năng
trường đích
Thiết kế chi tiết, Thiết kế kiến

Cơ sở đối Thiết kế chi
kiến trúc, đặc tả trúc, đặc tả phần
sánh
tiết
chức năng
mềm
Phương
Hộp
trắng Hộp đen, hộp Hộp đen, mô
pháp
( Hộp đen )
trắng
hình
Người
Nhóm kiểm thử Nhóm kiểm thử
Lập trình viên
tiến hành
độc lập
chuyên

Thẩm định
Hệ thống phần
mềm,
môi
trường thực
Đặc tả yêu cầu
phần mềm
Hộp đen
Người dùng

Bảng 1.1. Bảng tổng hợp nội dung các mức kiểm thử

14


Hình 1.3. Vòng đời của kiểm nghiệm (kiểm thử)
1.1.5. Chiến lược của kiểm thử phần mềm
Chiến lược kiểm thử phần mềm là sự tích hợp các kỹ thuật thiết kế, các phép
thử tạo thành một dãy các bước để hướng dẫn quá trình kiểm thử phần mềm thành
công. Nó mô tả các bước trong quá trình kiểm thử. Vì thế, bất kỳ chiến lược kiểm
thử nào cũng phải tích hợp đượ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.
• 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ử gồm : cung cấp, thực thi và ghi
nhận kết quả.
Quan sát kết quả kiểm thử :
• Thực hiện trong hoặc sau khi thực thi.
•So sánh kết quả thực tế với kết quả mong đợi

15


Hình 1.4. Tiến trình kiểm thử phần mềm

Chiến lược kiểm thử phần mềm phải đủ mềm dẻo tùy theo cách tiếp cận sáng
tạo của người thực hiện. Nhưng với tư cách là một tiến trình trong dự án , nó cũng
phải đủ chặt chẽ để hỗ trợ các kế hoạch và phương thức quản lý.
Một chiến lược kiểm thử phải thích ứng với từng mức kiểm thử : các kiểm
thử mức thấp (xác minh từng khúc mã nguồn xem có thực thi đúng đắn không), và
các kiểm thử mức cao ( thẩm định các chức năng hệ thống có đáp ứng yêu cầu
khách hàng hay không).
Có nhiều chiến lược kiểm thử phần mềm khác nhau như: Kiểm thử từ trên
xuống, kiểm thử từ dưới lên, kiểm thử vụ nổ lớn, kiểm thử hồi quy… Các chiến
lược kiểm thử khác nhau có thể tìm ra các loại lỗi khác nhau. Vì thế, không thể tập
trung vào một chiến lược kiểm thử mà bỏ qua các loại khác. Các mức của quá trình
kiểm thử cần được thực hiện tuần tự và bổ sung cho nhau nhằm tìm ra từng loại lỗi
với các phương pháp thích hợp.
1.1.6. Những thành phần của một kế hoạch kiểm thử
•

Đầu vào để lập lên kế hoạch kiểm thử: Kế hoạch của dự án, đặc tả yêu
cầu của phần mềm, người lập kế hoạch test, người tham gia test, thời
gian test, phạm vi test, kinh phí giành cho việc test, công cụ test.
• Người lập kế hoạch kiểm thử thường là trưởng nhóm test có kinh
nghiệm dựa vào các yêu cầu của phần mềm mà đưa ra phạm vi test
cho phù hợp với trình độ người test, thời gian, chi phí. Khi đưa ra
phạm vi rồi thì làm tốt phạm vi đó thì coi như đạt yêu cầu theo kế
hoạch test đưa ra.
• Các công việc cần thực hiện là đầu ra của kế hoạch kiểm thử:
 Nghiên cứu tài liệu dự án (phân tích, thiết kế), tìm hiểu công cụ
test cho kiểu test đã đặt ra.
 Thiết kế test case theo phạm vi test.
 Thực hiện kiểm tra phần mềm theo nội dung test case.
 Báo lỗi khi phát hiện được.

 Viết báo cáo kết quả test sau khi thực hiện xong.
16


1.1.7. Những điểm cần tập trung kiểm thử trước nhất nếu không có đủ thời
gian.
•
•
•
•
•
•
•
•
•

Những chức năng quan trong nhất (mục đích) của dự án.
Những chức năng được người dung xem nhiều nhất.
Những chức năng có thể ảnh hưởng nhiều nhất đến độ an toàn.
Những chức năng có thể ảnh hưởng nhiều nhất đến tài chính.
Những phần quan trọng nhất đối với người dùng,
Những phần có code phức tạp nhất.
Những thành phần được code bội vã hoặc áp lực nhất.
Những phần tương tự hoặc liên quan những dự án trước và đã gây lỗi.
Những phần tương tự hoặc liên quan những dự án trước và tốn nhiều
chi phí bảo trì.
• Những phần mà yêu cầu thiết kế không rõ ràng.
1.1.8. Các tiêu chí đánh giá kiểm thử
Tiêu chí đánh giá kiểm thử là đo độ bao phủ và chất lượng của kiểm thử.
•

Sự bao phu của kiểm thử là một tiêu chí quan trọng trong tiến trình
kiểm thử, nó phải bao phủ toàn bộ các yêu cầu cần kiểm thử và các
trường hợp kiểm thử hay toàn bộ chương trình.
• Chất lượn của kiểm thử là một tiêu chí quan trong để đánh giá độ tin
cậy, tính hiệu năng, sự ổn định của chương trình. Chất lượng của kiểm
thử phụ thuộc vào việc đánh giá, phân tích để phát hiện ra lỗi của
chương trình trong suốt tiến trình kiểm thử.
1.1.9. Các nguyên tắc kiểm thử
-

1.2.

Lập trình viên không nên thực hiện kiểm thử trên phần mềm mà mình đã
viết.
Cần phải kiểm tra các chức năng mà phần mềm không thực hiện.
Tránh việc kiểm thử phần mềm với giả định rằng sẽ không có lỗi nào tìm
thấy.
Trường hợp kiểm thử ( Test case) phải được định nghĩa kết quả đầu ra rõ
ràng.
Trường hợp kiểm thử phải được lưu trữ và thực thi lại mỗi khi có sự thay
đổi xảy ra trong hệ thống.

Mục tiêu của kiểm thử
Việc kiểm thử nhằm thực hiện hai mục tiêu:
•

Bằng việc kiểm thử sẽ tìm ra được những lỗi trong phần mềm (Myers,
1979) và thiết lập chất lượng của phần mềm (Hetzel, 1988)
• Việc kiểm thử thành công khi bạn tìm được ít nhất một lỗi, và đưa ra

sự đánh giá với độ tin cậy lớn.

17


1.3.

Vai trò của kiểm thử
•

Testing để tìm ra lỗi, ghi nhận các thông tin về lỗi, nhưng không sửa
lỗi.
• Testing giúp kiểm định phần mềm, đẩm bảo rằng phần mềm “đủ tốt”
với độ rủi ro “thấp nhất” có thể.
1.4.

Phân loại kiểm thử

Ta thực hiện phân loại kiểm thử dựa vào các yếu tố: mục đích kiểm thử, chiến
lược kiểm thử, phương pháp kiểm thử và kỹ thuật kiểm thử .
a. Các kiểu kiểm thử không có sự phân loại cụ thể rõ ràng mà nó phụ thuộc
vào chính mục đích của công việc kiểm thử trong từng giai đoạn cụ thể
nào đó, có thể kể ra như là:
 Test cấp đơn vị (Unit testing): Là kiểu test kiểm tra code xem liệu
chức năng nó đang thực hiện có đúng cách hay không theo như yêu
cầu.
 Kiểm thử unit ứng dụng ở mức mô đun. Thường là được thực

hiện bởi nhà phát triến trước khi các mô đung được tích hợp
với các mô đun khác.

 Kiểm thử Unit là mức thấp nhất trong tiến trình kiểm thử,
thường là áp dụng phương pháp kiểm thử hộp trắng.
 Kết quả của kiểm thử Unit thường tìm ra khoảng 20% lỗi trong
tất cả các lỗi của dự án.
 Test cấu hình (Shakeout testing): Kiểu test này cơ bản là kiểu test về
khả năng của hệ thông mạng, kết nối dữ liệu và sự tương tác của các
modul. Thông thường thì kiểu test này do nhóm quản lý cấu hình
chuẩn bị thiết lập các môi trường test thực sự. Họ cũng test xem liệu
các thành phần chính của phần mềm có hoạt động bất thường không,
Kiểu test này thực hiện trước khi tiến hành thực hiện trong môi trường
test. Sau khi test Shakeout, bước kế tiếp là test smoke
 Test sơ lược (Smoke testing (ad-hoc testing)): Là kiểu test được thực
hiện khi phần code được biên dịch mới chỉ được chuẩn bị tiến hành
trong môi trường test. Kiểu này cơ bản giống kiểu ad hoc để kiểm tra
đại khái để chắc chắn rằng các chức năng chính có bị bất thường hay
không? Nó mở đầu cho quá trình test bởi Tester QA. Sau khi test
smoke, các tester sẽ thực hiện test khả năng thực thi của các chương
trình.
 Test chức năng (Functional testing): Là kiểu test liệu mỗi và mọi chức
năng của ứng dụng đó đang làm việc có như yêu cầu tài liệu. nó là
kiểu test mà 80% công việc test được thực hiện. Trong kiểu test này
thì các testcase được thực thi.
18


 Test tích hợp (Integration testing): Là kiểu test kiểm tra liệu tất cả các
modul là được kết hợp hoặc chưa kết hợp lại cùng với nhau thực hiện
công việc có đạt được kết quả như tài liệu yêu cầu đã đượ xác định
(do mỗi lập trình viên thực hiện trên các modul khác nhau. Khi họ
hoàn thành đoạn code của họ, nhóm quản lý cấu hình ráp chúng lại

với nhau và chuẩn bị biên dịch. Các tester cần chắc chắn rằng các
module này bây giờ đã được kết hợp và làm việc theo như yêu cầu –
tức là phải test theo như yêu cầu).
 Test hồi quy (Regression testing): Khi một chức năng mới được thêm
vào phần mềm, chúng ta cần chắc chắn rằng phần chức năng mới
được thêm vào không phá hỏng các phần khác của ứng dụng. Hoặc
khi lỗi đã được chỉnh sửa, chúng ta cần chắc chắn rằng lỗi chỉnh sửa
không phá hỏng các phần khác của ứng dụng. Để test điều này chúng
ta thực hiện test lặp đi lặp lại gọi là test hồi quy.
 Thực hiện kiểm thử hồi quy thông thường mất rất nhiều nỗi lực

cố gắng. Vì thế, kiểm thử hồi quy có thể được thực hiện sau
một giai đoạn. Tuy nhiên, kiểm thử hồi quy phải được thực
hiện khi:
- Tổng số những yêu cầu thay đổi xảy ra từ bản cơ sở cuối
cùng với kiểm thử hồi quy lớn hơn 10% tổng số những yêu
cầu trong cơ sở đó.
- Tỉ lệ tổng số lỗi được phát hiện sau kiểm thử kiểm nhận hay
không trong tháo tác chia tổng số man-months của dự án
lớn hơn 1.
Với những dự án bảo trì, khởi động cho kiểm thử hồi quy phải
được xác định trong kế hoạch kiểm thử. Leader kiểm thử phải xác
định khi nào đội dự án kiểm soát kiểm thử hồi quy và phạm vi kiểm
thử hồi quy. Lập biểu của kiểm thử hồi quy phải được xác định trong
lập biểu của dự án.
 Test hệ thống (System testing): Khi tester hoàn thành công việc test
(các tester test ứng dụng trong các môi trường test, nghĩa là họ test với
dữ liệu test, không test trên dữ liệu thật), ứng dụng (phần mềm) phải
được test trên môi trường thật. Nó nghĩa là gì, tức là kể từ khi các
tester test với dữ liệu test, chúng ta phải chắc chắn rằng ứng dụng làm

việc tốt trong môi trường thật. Trong môi trường test, một vài điều
không thể test hoặc thao tác giả. Tất cả sẽ khác nhau và cơ sở dữ liệu
khác nhau, một số thao tác có thể không làm việc như mong đợi khi
ứng dụng được chuyển từ môi trương test sang môi trường sản phẩm.

19


 Test tải dữ liệu (Load testing): Là kiểu test kiểm tra thời gian đáp lại
người dùng với số lượng người dùng bất kỳ trong một ngữ cảnh nào
đó của một ứng dụng tại cùng một thời điểm.
 Test tải trọng (Stress testing): Là kiểu test kiểm tra thời gian đáp lại
người dùng với ứng số lượng người dùng bất ký trong nhiều ngữ cảnh
khác nhau của một ứng dụng tại một thời điểm.
 Test hiệu suất (Performance testing): Trong loại test này dựa vào sức
nặng như sự phức tạp của giá trị, độ dài đầu vào, độ dài của câu truy
vấn… Loại test này kiểm tra bớt phần tải (Stress/load) của ứng dụng
có thể được chắc chắn hơn.
 Test chấp nhận từ người sử dụng (User acceptance testing): Trong
kiểu test này, phần mềm sẽ được thực hiện kiểm tra từ người dùng để
tìm ra nếu phần mềm phù hợp với sự mong đợi của người dùng vwf
thực hiện đúng như mong đợi. Trong thời gian test này, tester có thể
cũng thực hiện hoặc khách hàng có các tester của riêng họ để thực
hiện.
 Test hộp đen (Black box testing): Là kiểu test mà tester thực hiện
không chú ý đến code (hoặc là một hình thức test mà ứng dụng đang
test được xem như một hộp đen và hành vi bên trong của chương trình
hoàn toàn được bỏ qua. Việc test xảy ra dựa trên các đặc tả bên ngoài.
Cũng hiểu như test hành vi, chỉ hành vi bên ngoài của ứng dụng là
được đánh giá và phân tích).


-

Các kỹ thuật thường dùng:
Lược đồ nguyên nhân kết quả.
Phân đoạn tương đương.
Phân tích giá trị biên.

 Test hộp trắng (White bõ testing): Là test mà các tester tìm kiếm lỗi
trong code, sử dụng các đặc tả chi tiết.
 Bao gồm các chỉ dẫn bao quát, bao gồm toàn bộ các câu lệnh

điều kiện đơn, các điều kiện, đa điều kiện.
 Kiểm thử hộp trắng là một thiết kế kiểm thử sử dụng cấu trúc
của thiết lế chi tiết. Sử dụng thiết kế chi tiết người dử dụng có
thể đẩm bảo rằng:
Bảo đảm rằng tất cả các đường dẫn độc lập ở bên trong
mô đun đều được thử tối thiếu một lần.
Thử nghiệm tất cả các trường hợp logic trong các câu lệnh
điều kiện.
Thực hiện tất cả các vòng lặp tới giá trị biên của chúng.
Thử nghiệm tất cả các giá trị biên bên trong đảm bảo
chúng hợp lệ.

20


 Test Alpha (Alpha testing): Trong lại test này, các người dùng được
mời đến điểm tập trung đề xuất ý kiến, nơi mà họ sẽ sử dụng chương
trình và người phát triển chú ý mỗi thông tin liên quan hoặc hành

dộng được đặt ra bởi người dùng. Bất kỳ hành vi bất thường nào của
hệ thống cũng pahir được ghi nhận và chỉnh sửa bởi người phát triển.
 Test Beta (Beta testing): Trong loại test này, phần mềm được phân bổ
như một phiên bản thử nghiệm(sử dụng thử) để người dùng kiểm tra
ứng dụng tại nơi làm việc của họ. Người sử dụng sẽ quan sát phần
mềm, trong trường hợp nếu có bất kỳ lỗi xảy ra thì nó được báo cáo
đến người phát triển.
 Test bảo mật(Security test): Phần test này pahir rà soát, tìm những lỗ
hổng của hệ thống mà từ những lỗ hổng đó hacker có thể xâm nhập,
phá hỏng hoặc làm sai lệch hệ thống -> yêu cầu của loại test này đòi
hỏi tester phải có 1 kiếm thức nhất định về Security. Đối với laoij test
này nên kết hợp hài hào giữa test manual và auto.
b. Dựa vào chiến lược kiểm thử ta có thể phân chia kiểm thử thành hai loại:
Kiểm thử thủ công và kiểm thử tự động.
 Kiểm thử thủ công là Tester làm mọi thứ bằng tay, từ viết test case
đến thực hiện test, mọi thao tác như nhập điều kiện đầu vào, thực hiện
một số sự kiện khác như click nút và quan sát kết quả thực tế, sau đó
so sánh kết quả thực tế với kết quả mong muốn trong test case, điền
kết quả test. Mọi thứ hoàn toàn bằng tay.
 Kiểm thử tự động là quá trình thực hiện một các 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ử.
Chúng ta sẽ tìm hiểu rõ hơn về kiểm thử tự động ở chương tiếp theo.
c. Theo phương pháp tiến hành kiểm thử ta chia kiểm thử làm hai loại:
Kiểm thử tĩnh và kiểm thử động.
 Kiểm thử tĩnh là một hình thức của kiểm thẻ phần mềm mà phần mềm
không được sử dụng thực sự. Điều này ngược với kiểm thử tự động.
Thường thì nó không kiểm thử chi tiết mà chủ yếu kiểm tra tính đứng
dắn của code, thuật toán hay tài liệu.
 Kiểm thử động là một hình thức kiểm thử phần mềm chạy mã lập

trình thực tế trong các tình huống, diễn ra khi bản thân chương trình
đó đang được sử dụng. Kiểm thử động có thể bắt đầu trước khi
chương trình đã hoàn tất 100% để kiểm thử các phần cụ thể của mã và
được áp dụng cho các chức năng riêng biệt hoặc Module.
d. Dựa vào kỹ thuật kiểm thử ta có thể phân chia kiểm thử thành ba loại:
Kiểm thử hộp đen, kiểm thử hộp trắng và kiểm thử hộp xám.Trong ba

21


phương pháp trên, hai phương pháp phổ biến để chọn ra một tập dữ liệu
kiểm thử một cách thông minh.
 Phương pháp hộp đen.
 Phương pháp hộp trắng.
Để kiểm thử hộp đen và kiểm thử hộp trắng một cách thấu đáo là không thể.
Do đó, một chiến lược kiểm thử hợp lý là chiến lược có thể kết hợp sức mạnh
của cả hai phương pháp trên. Mỗi phương pháp lại có những chiến lược phát
hiện và tiếp cận lỗi khác nhau.
1.5.

Các trường hợp kiểm thử và dữ liệu kiểm thử
•
•
•
•
•
•
•
•
•

•
•
•

Kiểm tra các toán tử ở mức giá trị thông thường.
Kiểm tra với các giá trị giới hạn.
Kiểm tra với ngoài vùng giá trị.
Kiểm tra các lỗi ở trong vòng lặp.
Kiểm tra các kết thúc không bình thương trong vòng lặp.
Kiểm tra các kết thúc không bình thường trong đệ quy.
Kiểm tra tất cả các cấu trúc dữ kiệu được truy nhập bởi hàm.
Kiểm tra tất cả các loại file được truy nhập bởi hàm thành viên.
Kiểm tra tất cả các lỗi điều kiện.
Kiểm tra tính hiệu quả của kiểm thử nếu thấy cần thiết.
Đảm bảo rằng mọi câu lệnh đều được thực hiện.
Đảm bảo rằng mọi câu lệnh điều kiện đều thực hiện ở tất cả các

nhánh.
1.6.

Phương pháp xây dựng các tài liệu kiểm thử

1.6.1. Test plan
Test plan là gì?
Kế hoạch kiểm thử phần mềm (test plan) là một tài liệu mô tả các mục tiêu,
phạm vi, phương pháp tiếp cận và tập trung vào quá trình kiểm thử phần mềm. Quá
trình chuẩn bị test plan là cách hữu ích để suy nghĩ về những điều cần thiết để xác
nhận khả năng chấp nhận một sản phẩm phần mềm. Các tài liệu đã hoàn thành sẽ
giúp mọi người bên ngoài nhóm kiểm thử hiểu được 'tại sao?' và 'như thế nào?' để
chấp nhận sản phẩm. Nó cần phải đầy đủ để dùng được nhưng không cần quá hoàn

hảo vì không ai ngoài nhóm kiểm thử sẽ đọc nó. Sau đây là một số nội dung có thể
có trong một test plan, tùy thuộc vào từng dự án cụ thể:
-

Tiêu đề
Định nghĩa phiên bản của phần mềm (phiên bản bàn giao).
Lưu lại quá trình hiệu chỉnh tài liệu như: tác giả, ngày cập nhật,
người duyệt.
Mục lục.
Mục đích của tài liệu, giới thiệu chung.
Mục tiêu của chi phí kiểm thử (test).
Giới thiệu tổng quan về sản phẩm.
22


-

-

Danh sách tài liệu liên quan như tài liệu đặc tả yêu cầu, tài liệu
thiết kế, các kế hoạch test khác,...
Các tiêu chuẩn thích hợp, các yêu cầu hợp lệ.
Nguồn gốc của các sự thay đổi.
Phân tích rủi ro của dự án.
Các vấn đề ưu tiên và tập trung kiểm thử.
Phạm vi và giới hạn kiểm thử
Kiểm thử tự động - giải thích và tổng quan
Các công cụ kiểm thử được sử sụng, bao gồm các phiên bản, bản
sửa lỗi,...v.v
Các qui trình bảo trì và quản lý phiên bản của kịch bản kiểm thử/

mã kiểm thử.
Theo dõi và giải quyết vấn đề - Các công cụ và quy trình
Các thước đo về sản phẩm kiểm thử được sử dụng
Báo cáo các yêu cầu và khả năng bàn giao.
Điều kiện đầu vào và đầu ra của phần mềm.
Giai đoạn và điều kiện kiểm thử ban đầu.
Điều kiện dừng kiểm thử và kiểm thử lại.
Sự bố trí nhân sự.
Những người cần đào tạo trước khi tham gia.
Nơi kiểm thử.
Các tổ chức kiểm thử bên ngoài sẽ sử dụng tài liệu: mục đích,
trách nhiệm, khả năng hoàn thành, người liên hệ và các vấn đề hợp
tác của họ.
Các vấn đề về: phân loại, bảo mật và bản quyền của phần mềm, tài
liệu.
Các vấn đề mở
Phụ lục - bảng chú giải, các từ viết tắt
...v.v…

1.6.2. Test case
a. Khái niệm
Theo IEEE

Test case mô tả một dữ liệu đầu vào, một hành động hoặc một sự kiện và một
kết quả mong đợi để xác định một chức năng của ứng dụng phần mềm hoạt động
đúng hay không?
Một test case có thể có các phần đặc thù khác nhau như mã test case, tên test
case, mục tiêu test, các điều kiện test, các yêu cầu dữ liệu đầu vào (data input), các
bước thực hiện và các kết quả mong đợi. Mức chi tiết có thể được định nghĩa khác
nhau dựa vào ngữ cảnh của dự án và quy mô của công ty sản xuất phần mềm

Thiết kế test – case trong kiểm thử phần mềm là quá trình xây dựng các phương
pháp kiểm thử có thể phát hiện lỗi của phần mềm để xây dựng phần mềm đạt tiêu
chuẩn.
23


b. Vai trò
• Tạo ra các ca kiểm thử tốt nhất có khả năng phát hiện ra lỗi, sai sót

của phần mềm một cách nhiều nhất.
• Tạo ra các ca kiểm thử có chi phí rẻ nhất, đồng thời tốn ít thời gian và
công sức nhất.
c. Quy trình thiết kế test case
Một trong những lý do quan trọng nhất trong kiểm thử chương trình là thiết kế
và tạo ra các ca kiểm thử - các Test case có hiệu quả. Với những ràng buộc về thời
gian và chi phí đã cho, thì vấn đề then chốt của kiểm thử trở thành:
Tập con nào của tất cả ca kiểm thử có thể có khả năng tìm ra nhiều lỗi nhất?
Thông thường, phương pháp kém hiệu quả nhất là kiểm tra tất cả đầu vào
ngẫu nhiên – quá trình kiểm thử một chương trình bằng việc chọn ngẫu nhiên một
tập con các giá trị đầu vào có thể. Tập hợp các ca kiểm thử được chọn ngẫu nhiên
có rất ít cơ hội là tập hợp tối ưu hay gần tối ưu. Hai phương pháp phổ biến để chọn
ra một tập dữ liệu kiểm thử một cách thông minh.
1. Phương pháp hộp đen
2. Phương pháp hộp trắng.
Để kiểm thử hộp đen và kiểm thử hộp trắng một cách thấu đáo là không thể.
Do đó, một chiến lược kiểm thử hợp lý là chiến lược có thể kết hợp sức mạnh của
cả hai phương pháp trên. Mỗi phương pháp lại có những chiến lược phát hiện và
tiếp cận lỗi khác nhau.
Những chiến lược kết hợp đó bao gồm:
Hộp đen

1. Phân lớp tương đương
2. Phân tích giá trị biên
3. Đồ thị nguyên nhân – kết quả

Hộp trắng
1.
2.
3.
4.
5.

Bao phủ câu lệnh
Bao phủ quyết định
Bao phủ điều kiện
Bao phủ điều kiện – quyết định
Bao phủ đa điều kiện.

Mỗi phương pháp có những ưu điểm cũng như khuyết điểm riêng, do đó để
có được tập các ca kiểm thử tối ưu, chúng ta cần kết hợp hầu hết các phương pháp.
Quy trình thiết kế các ca kiểm thử sẽ bắt đầu bằng việc phát triển các ca kiểm thử sử
dụng phương pháp hộp đen và sau đó phát triển bổ sung các ca kiểm thử cần thiết
với phương pháp hộp trắng.

24


Tuy nhiên trong phạm vi của bản báo cáo này tôi xin phép được trình bày kĩ
hơn về cách xây dựng test case bằng phương pháp hộp đen.
-

Phân lớp tương đương – Equivalence Patitioning

Phân lớp tương đương là một phương pháp kiểm thử hộp đen chia miền đầu
vào của một chương trình thành các lớp dữ liệu, từ đó suy dẫn ra các ca kiểm thử.
Thiết kế ca kiểm thử cho phân lớp tương đương dựa trên sự đánh giá về các
lớp tương đương với một điều kiện vào. Lớp tương đương biểu thị cho tập các trạng
thái hợp lệ hay không hợp lệ đối với điều kiện vào.
Thiết kế Test-case bằng phân lớp tương đương tiến hành theo 2 bước:
(1). Xác định các lớp tương đương
(2). Xác định các ca kiểm thử.
-

Xác định các lớp tương đương

Các lớp tương đương được xác định bằng bằng cách lấy mỗi trạng thái đầu
vào (thường là 1 câu hay 1 cụm từ trong đặc tả) và phân chia nó thành 2 hay nhiều
nhóm.
Một mẫu cho việc liệt kê các lớp tương đương:
Điều kiện bên ngoài

Các lớp tương đương
hợp lệ

Các lớp tương đương
không hợp lệ

Chú ý: là hai kiểu lớp tương đương được xác định: lớp tương đương hợp lệ mô tả
các đầu vào hợp lệ của chương trình, và lớp tương đương không hợp lệ mô tả tất cả
các trạng thái có thể khác của điều kiện (ví dụ, các giá trị đầu vào không đúng). Với
1 đầu vào hay điều kiện bên ngoài đã cho, để xác định các lớp tương đương có thể

áp dụng tập các nguyên tắc dưới đây:
1. Nếu điều kiện đầu vào xác định một khoảng giá trị [a,b], thì phân hoạch
thành một lớp tương đương hợp lệ và một lớp tương đương không hợp lệ.
2. Nếu điều kiện đầu vào yêu cầu một giá trị xác định, phân hoạch thành một
lớp tương đương hợp lệ và hai lớp tương đương không hợp lệ. Chẳng hạn,
3. Nếu điều kiện đầu vào xác định một phần tử của tập hợp, thì phân hoạch
thành một lớp tương đương hợp lệ và một lớp tương đương không hợp lệ.
-

Xác định các ca kiểm thử

Với các lớp tương đương xác định được ở bước trên, bước thứ hai là sử dụng
các lớp tương đương đó để xác định các ca kiểm thử. Quá trình này như sau:

25