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


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


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:


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

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

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ụ

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


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


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


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

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 )

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


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.


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

 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

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

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

•
•
•

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

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

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


á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