Nghiên cứu và đề xuất các phương pháp kiểm thử giao diện phần mềm

4


MỤC LỤC
LỜI CAM ĐOAN 3
DANH MỤC CÁC BẢNG 9
DANH MỤC CÁC HÌNH VẼ 9
CHƢƠNG I – TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 12
1.1. Các khái niệm cơ bản 12
1.1.1. Lỗi phần mềm 12
1.2.2. Chi phí cho việc sửa lỗi 12
1.1.3. Kiểm thử phần mềm 13
1.2. Tiến trình kiểm thử phần mềm 14
1.2.1. Kiểm thử đơn vị 14
1.2.2. Kiểm thử tích hợp 15
1.2.3. Kiểm thử hệ thống 15
1.2.4. Kiểm thử hồi quy 16
1.2.5. Kiểm thử chấp nhận 17
1.3. Các phƣơng pháp kiểm thử phần mềm 17
1.3.1. Kiểm thử hộp trắng 17
1.3.2. Kiểm thử hộp đen – Black box testing 18
1.3.3. Kiểm thử hộp xám 20
1.4. Các kỹ thuật kiểm thử cơ bản 20
1.4.1. Kiểm thử luồng điều khiển 20
1.4.2. Kiểm thử luồng dữ liệu 22
1.4.3. Kỹ thuật phân lớp tƣơng đƣơng 23
1.4.4. Kỹ thuật phân tích giá trị biên 24
1.4.5. Kỹ thuật đồ thị - nhân quả 24
1.5. Kiểm thử tự động 25
1.5.1. Kiến trúc kiểm thử tự động 26
1.5.2. Ƣu và nhƣợc điểm của kiểm thử tự động 28

1.5.2. Lựa chọn công cụ kiểm thử tự động 28
5


CHƢƠNG II – GIAO DIỆN VÀ CÁC VẤN ĐỀ CẦN QUAN TÂM 34
2.1. Khái niệm giao diện ngƣời dùng 34
2.2. Tại sao cần thiết kế giao diện 34
2.3. Các dạng giao tiếp ngƣời dùng - máy tính 35
2.3.1. Giao tiếp dòng lệnh 35
2.3.2. Giao tiếp bảng chọn 36
2.3.3. Giao tiếp bằng ngôn ngữ tự nhiên 36
2.3.4. Giao tiếp dạng hỏi đáp truy vấn 36
2.3.5. Giao tiếp dạng form-fill 36
2.3.6. Giao tiếp dạng WIMP 37
2.4. Tính tiện lợi của hệ thống tƣơng tác 38
2.5. Nguyên lý thiết kế hệ thống có tính tiện lợi 39
2.5.1. Sự rõ ràng 40
2.5.2. Sự phản hồi 40
2.5.3. Tính ràng buộc 40
2.5.4. Tính ánh xạ 41
2.5.5. Tính nhất quán 41
2.5.6. Tính gợi ý 41
2.6. Các lỗi giao diện ngƣời dùng 42
2.6.1. Lỗi chức năng 42
2.6.2. Lỗi giao tiếp truyền thông 42
2.6.3. Lỗi cấu trúc lệnh 42
2.6.4. Thiếu lệnh 43
2.6.5. Lỗi thi hành 43
2.6.6. Đầu ra 43
CHƢƠNG 3 – KIỂM THỬ GIAO DIỆN PHẦN MỀM 44

3.1. Khái niệm kiểm thử giao diện phần mềm 44
3.2. Kiểm thử nhƣ thế nào 44
3.2.1. Nguyên tắc chung khi kiểm thử giao diện phần mềm 45
3.3.2. Chiến lƣợc kiểm thử giao diện 49
6


3.3. Danh mục kiểm thử giao diện 49
3.3.1. Kiểm thử sự tuân thủ chuẩn Windows 50
3.3.2. Danh mục kiểm tra sự hợp thức hóa màn hình 53
3.3.3. Các hoạt động chuẩn 61
3.4. Kiểm thử giao diện tự động 62
3.4.1. Tạo kế hoạch kiểm thử giao diện cho công cụ kiểm thử giao diện tự động 63
3.4.2. Sử dụng công cụ kiểm thử giao diện tự động 63
3.4.3. Mƣời điều cần nhớ khi kiểm thử giao diện tự động 64
3.4.4. Các thủ thuật khi kiểm thử giao diện tự động 64
3.4.5. Một số vấn đề thƣờng gặp với kiểm thử tự động 66
3.5. Đánh giá mức độ hài lòng ngƣời dùng 66
CHƢƠNG 4 – KIỂM THỬ GIAO DIỆN THEO PHÂN LOẠI PHẦN MỀM 67
4.1. Phân loại phần mềm 67
4.2. Kiểm thử giao diện phần mềm nghiệp vụ 67
4.3. Kiểm thử giao diện đối với phần mềm nhúng 68
4.3.1. Hệ thống nhúng và các đặc điểm cơ bản 68
4.3.2. Kiểm thử giao diện hệ thống nhúng 69
4.4. Kiểm thử giao diện đối với các ứng dụng Windows 70
4.5. Kiểm thử giao diện với các ứng dụng Web 72
4.5.1. Ứng dụng Web (Web Application) 72
4.5.2. Kiểm thử ứng dụng Web 73
4.5.3. Các công cụ kiểm thử giao diện tự động 74
CHƢƠNG 5 – ÁP DỤNG CÁC KỸ THUẬT KIỂM THỬ TRONG KIỂM THỬ

GIAO DIỆN ỨNG DỤNG “PHẦN MỀM QUẢN LÝ BÁN HÀNG” 85
5.1. Giới thiệu ứng dụng “Phần mềm quản lý bán hàng” 85
5.1.1. Thành phần và chức năng 85
5.1.2. Mô-đun tiến hành kiểm thử giao diện 87
5.2. Lựa chọn phƣơng pháp và kỹ thuật kiểm thử 88
5.2.1. Kiểm thử giao diện màn hình chính 89
7


5.2.2. Kiểm thử giao diện màn hình “Phiếu nhập hàng” 89
5.3. Tiến hành kiểm thử giao diện ứng dụng 91
KẾT LUẬN 108
TÀI LIỆU THAM KHẢO 109

8


DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT
Thứ tự
Ký hiệu / Chữ
viết tắt
Tên đầy đủ
Ý nghĩa
1
CFG
Control Flow Graphic
Đồ thị luồng điều khiển
2
DFG
Data Flow Graphic

Đồ thị luồng dữ liệu
3
KTTĐ
Kiểm thử tự động
Phƣơng pháp kiểm thử tự
động
4
MSExcel
Microsoft Excel
Phần mềm Microsoft
Excel
5
GUI
Graphic User Interface
Giao diện đồ họa ngƣời
dung
6
UI
User Interface
Giao diện ngƣời dung
7
QTP
Quick Test Professional
Công cụ kiểm thử tự động
QTP
8
WIMP
Window - Icons - Menus -
Pointers
Giao tiếp dạng WIMP

9


DANH MỤC CÁC BẢNG
Bảng 3.1 - Các mức kiểm thử và các loại kiểm thử giao diện phù hợp
Bảng 5.1- Danh sách các ca kiểm thử với màn hình chính
Bảng 5.2 - Danh sách các ca kiểm thử với màn hình “Phiếu nhập hàng”
DANH MỤC CÁC HÌNH VẼ
Hình 1.1 - Chi phí sửa lỗi theo thời gian 13
Hình 1.2 – Các giai đoạn phát triển và kiểm thử trong mô hình chữ V 14
Hình 1.3 – Kiểm thử hồi quy tại các mức kiểm thử phần mềm khác 17
Hình 1.4 – Kiểm thử hộp trắng 17
Hình 1.5 – Kiểm thử hộp đen 19
Hình 1.6 – Chu trình sinh dữ liệu đầu vào kiểm thử cho kiểm thử luồng điều khiển 21
Hình 1.7 – Các ký hiệu trong CFG 21
Hình 1.8 – Các thành phần của một kiến trúc KTTĐ 26
Hình 2.1 – Mô hình cấu trúc UI 34
Hình 2.2 – Mô hình giao tiếp dòng lệnh trong window 35
Hình 2.3 – Mô hình giao tiếp Menu 36
Hình 2.4 – Giao tiếp form-fill 37
Hình 2.5 – Bảng tính 37
Hình 2.6 - Mô hình sự chấp nhận đƣợc của hệ thống 39
Hình 2.7 – Ví dụ về tính ràng buộc 41
Hình 2.8 – Tính gợi ý trong window 42
Hình 3.1 – Ứng dụng thỏa mãn sự đồng bộ Caption 50
Bảng 3.2 – Một số phím tắt và chức năng của chúng 62
Bảng 4.1 - So sánh giữa các ứng dụng Desktop, Client Server và Web 71
Hình 4.1 – Các thành phần giao diện của QTP 77
Hình 4.2 – Tạo Group trong AppPerfect 80

Hình 4.3 – Hỗ trợ thành phần Validation trong AppPerfect 81
Hình 4.4 – Định nghĩa tham số trong AppPerfect 82
Hình 4.5 – Phân tích kết quả kiểm thử với AppPerfect Test 83
Hình 4.6 – Lập lịch kiểm thử 83
Hình 5.1 – Mô-đun Hệ Thống 85
Hình 5.2 – Mô-đun Danh Mục 86
Hình 5.3 – Mô-đun Chức Năng 87
Hình 5.4 – Mô-đun Trợ Giúp 87
Hình 5.5 – Cấu trúc giao diện phần mềm Quản lý bán hàng 88
10


MỞ ĐẦU
Trong thởi đại công nghệ số hiện nay, ta có thể bắt gặp các sản phẩm công nghệ
ở tất cả các lĩnh vực: quân sự, y khoa, văn hóa nghệ thuật, đời sống xã hội,… Sự bùng
nổ của công nghệ thông tin và sự ra đời của Internet tác động to lớn tới bộ mặt xã hội.
Nhu cầu trao đổi thông tin ngày càng tăng, việc sử dụng máy tính không đơn thuần là
ngƣời dùng thực thi chức năng chuyên biệt nào đó trong một lĩnh vực cụ thể, mà có thể
sử dụng trong tất cả các lĩnh vực, các ngành nghề, với những mục đích khác nhau: làm
việc, nghiên cứu, học tập, giải trí, trao đổi thông tin, Và ngƣời dùng cũng không đơn
thuần là một nhóm chuyên gia với trình độ nhất định, mà họ có thể là bất kỳ ai với bất
kỳ công việc, bất cứ trình độ, ở bất kỳ lứa tuổi nào Để có thể đáp ứng thị trƣờng rộng
lớn, cực kỳ đa dạng đó, sản phẩm công nghệ thông tin nói chung cũng nhƣ công nghệ
phần mềm nói riêng, phải đảm bảo chất lƣợng tốt đồng thời cả chức năng hệ thống lẫn
giao diện ngƣời dùng. Giao tiếp và chức năng là hai mặt tƣơng hỗ và bổ sung cho
nhau. Phần mềm có chức năng tốt đến đâu, mà giao diện tồi cũng sẽ gây khó khăn cho
ngƣời dùng, làm giảm hiệu quả chức năng hệ thống. Ngƣợc lại, với giao tiếp đƣợc
thiết kế tốt, ngƣời dùng có thể dễ dàng sử dụng phần mềm và phát huy tối đa hiệu quả
chức năng hệ thống.
Kiểm thử là một trong những giai đoạn của quá trình phát triển phần mềm.

Trƣớc khi sản phẩm đƣợc phát hành tất cả các chức năng cũng nhƣ giao diện của phần
mềm đều cần qua kiểm thử. Giao diện tuy đƣợc thiết kế tốt nhƣng cũng không thể
tránh khỏi các sai sót. Kiểm thử giao diện hiệu quả sẽ phát hiện ra đƣợc các sai sót
này, tránh các lỗi về giao diện khi phát hành sản phẩm. Kiểm thử giao diện đứng dƣới
vai trò của ngƣời sử dụng, sẽ giúp phần mềm có sự thích ứng phù hợp hơn với thị hiếu
và nhu cầu của ngƣời dùng. Chính vì lẽ đó, kiểm thử giao diện phần mềm là việc hết
sức cần thiết, cần nghiên cứu về kiểm thử giao diện để tìm ra phƣơng pháp kiểm thử
hiệu quả phù hợp với ứng dụng phần mềm.
Luận văn trình bày lý thuyết về giao diện phần mềm, lý thuyết kiểm thử phần
mềm, đi sâu vào kiểm thử giao diện phần mềm với phƣơng pháp nghiên cứu theo
hƣớng từ khái quát tới chi tiết, lần lƣợt tìm hiểu các khái niệm, các phƣơng pháp, các
công cụ kiểm thử giao diện, Trên cơ sở đó, sẽ có đánh giá khách quan về việc lựa
chọn phƣơng pháp hay công cụ kiểm thử giao diện phù hợp đối với ứng dụng đƣợc
nghiên cứu.
Kết quả nghiên cứu có thể làm tài liệu tham khảo về kiểm thử phần mềm, đồng
thời hỗ trợ kiểm thử viên cũng nhƣ các nhà phát triển phần mềm có cơ sở để lựa chọn
phƣơng pháp hay công cụ kiểm thử giao diện phù hợp để kiểm thử ứng dụng đƣợc xây
dựng.
11


Luận văn bao gồm năm chƣơng. Chƣơng 1 trình bày các lý thuyết tổng quan về
kiểm thử phần mềm: các khái niệm cơ bản, tiến trình kiểm thử phần mềm, các phƣơng
pháp, kỹ thuật kiểm thử phần mềm. Chƣơng 2 trình bày các kiến thức về giao diện và
các vấn đề cần lƣu ý khi thiết kế và kiểm thử giao diện phần mềm. Chƣơng 3 tập trung
vào kiểm thử giao diện phần mềm, nêu các hƣớng giải quyết và các vấn đề cần kiểm
thử giao diện. Chƣơng 4 cũng nói về kiểm thử giao diện nhƣng đi sâu vào từng loại
ứng dụng phần mềm. Chƣơng 5 đƣa ra ví dụ áp dụng các kiến thức đã đƣợc nêu trong
bốn chƣơng đầu để kiểm thử giao diện phần mềm “Quản lý bán hàng”.
12

CHƢƠNG I – TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
1.1. Các khái niệm cơ bản
1.1.1. Lỗi phần mềm
 Khái niệm
Có rất nhiều định nghĩa khác nhau về lỗi phần mềm (bug), 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 đồng nhất giữa
chương trình với đặc tả của nó”. Cụ thể là:
 Phần mềm không thực hiện đúng những gì đã nêu trong đặc tả.
 Phần mềm thực hiện những hành vi mà đặc tả đã nêu không đƣợc thực hiện.
 Phần mềm thực hiện những hành vi không đƣợc nêu trong đặc tả.
 Phần mềm không thực hiện các yêu cầu không đƣợc nêu trong đặc tả, nhƣng
nên thực hiện nó.
 Phần mềm khó hiểu, khó sử dụng,
 Các dạng lỗi phần mềm
 Sai sót (Error): Error là một trạng thái của hệ thống, là một sự nhầm lẫn hay
sự hiểu sai trong quá trình phát triển phần mềm của ngƣời phát triển. Error có
thể gây nên hỏng hóc hệ thống nếu không có các hành động khắc phục.
 Lỗi (Fault / Defect): xuất hiện trong phần mềm nhƣ là kết quả của error gây ra.
 Hỏng hóc (Failure): Failure đƣợc coi là xảy ra khi các hành vi bên ngoài hệ
thống không thực hiện đúng nhƣ đặc tả hệ thống đã đƣợc quy định trƣớc. Nó là
kết quả của một lỗi xuất hiện làm cho hệ thống không thể hoạt động hoặc hoạt
động nhƣng cho kết quả không nhƣ mong đợi.
1.2.2. Chi phí cho việc sửa lỗi
Vòng đời phát triển phần mềm (chu trình phát triển phần mềm) đƣợc chia làm
nhiều giai đoạn. Bao gồm:
 Lập kế hoạch
 Thiết kế
 Mã hóa và viết tài liệu

 Kiểm thử và sửa lỗi
13


 Phát hành và bảo trì
Theo thống kê bảo trì là phần chi phí chính của phần mềm và kiểm thử là hoạt
động chi phí đắt thứ hai, ƣớc tính khoảng 40% (15/33) chi phí trong quá trình phát
triển ban đầu của sản phẩm phần mềm [6].
Kiểm thử cũng là phần chi phí chính của giai đoạn bảo trì do phải tiến hành
kiểm thử lại những thay đổi trong quá trình sửa lỗi và đáp ứng yêu cầu ngƣời dùng.
Kiểm thử và sửa lỗi có thể đƣợc thực hiện tại bất kỳ giai đoạn nào của vòng đời phần
mềm. Tuy nhiên chi phí cho việc tìm và sửa lỗi tăng một cách đáng kể trong quá trình
phát triển. Trong tài liệu “Software Engineering” của Boehm (1976), có trích dẫn kết
quả nghiên cứu của IBM, GTE và TRW, tổng kết rằng lỗi đƣợc phát hiện càng muộn
thì chi phí cho việc sữa lỗi càng lớn [6]. Chi phí tăng theo hàm mũ nhƣ Hình 1.1:

Hình 1.1 - Chi phí sửa lỗi theo thời gian
Nhƣ vậy, có thể thể thấy kiểm thử là một khâu rất quan trọng trong quá trình
phát triển phần mềm, kiểm thử càng sớm, càng chặt chẽ thì sẽ càng giảm đƣợc những
chi phí phát sinh không đáng có cho việc sửa lỗi.
1.1.3. Kiểm thử phần mềm
Kiểm thử phần mềm là quá trình thực thi hệ thống phần mềm để xác định xem
phần mềm có thực hiện đúng với đặc tả hay không và thực hiện trong môi trƣờng
mong đợi hay không.
 Xác minh: Chỉ ra sản phẩm có đáp ứng đƣợc các đặc tả yêu cầu hay không.
Đƣợc thực hiện mỗi khi kết thúc một pha trong quy trình sản xuất, nó giúp
quyết định xem sản phẩm có đáp ứng các yêu cầu tại thời điểm kiểm tra, trƣớc
khi bắt đầu pha kế tiếp.
 Thẩm định: Chỉ ra sản phẩm có đáp ứng đƣợc yêu cầu ngƣời sử dụng hay
không. Thực hiện khi kết thúc quá trình sản xuất, nhằm đảm bảo sản phẩm đã

đƣợc sản xuất là đúng nhƣ mong đợi.
14


1.2. Tiến trình kiểm thử phần mềm
Kiểm thử đƣợc thực thi ở các mức khác nhau bao gồm cả hệ thống hoàn chỉnh
hay các phần của hệ thống trong suốt chu trình phát triển phần mềm. Một hệ thống
phần mềm phải trải qua bốn giai đoạn kiểm thử trƣớc khi nó đƣợc triển khai. Bốn giai
đoạn đó đƣợc biết nhƣ là bốn mức kiểm thử: unit, integration, system và acceptance.
Các giai đoạn kiểm thử tƣơng ứng với các giai đoạn khác nhau trong tiến trình phát
triển phần mềm và đƣợc khái quát hóa qua mô hình chữ V – Hình 1.2 [7].

Hình 1.2 – Các giai đoạn phát triển và kiểm thử trong mô hình chữ V
Trong đó:
 Các yêu cầu: đƣa ra các yêu cầu về sản phẩm
 Đặc tả chức năng: xây dựng phần mềm để đáp ứng với đề nghị.
 Thiết kế mức cao: kiến trúc hệ thống ở mức tổng thể.
 Thiết kế mức thấp (mức chi tiết): chi tiết các đặc tả của các mô-đun trong kiến
trúc.
 Lập trình: mã hóa các mô-đun.
1.2.1. Kiểm thử đơn vị
Kiểm t hử đơn vị là mức thấp nhất của kiểm thử trong mô hình chữ V. Giai đoạn
này đƣợc thực hiện bởi các lập trình viên. Họ chia nhỏ và kiểm thử từng đơn vị
chƣơng trình, nhƣ các thủ tục, các hàm, các phƣơng thức, hay các lớp. Mục đích của
15


kiểm thử đơn vị là bảo đảm thông tin đƣợc xử lý và xuất là chính xác, trong mối tƣơng
quan với dữ liệu nhập và chức năng của đơn vị đó. Điều này thƣờng đòi hỏi tất cả các
nhánh bên trong đơn vị, từng mô-đun đều phải đƣợc kiểm tra để phát hiện nhánh phát

sinh lỗi. Một nhánh thƣờng là một chuỗi các lệnh đƣợc thực thi trong một đơn vị. Thực
tiễn đã chỉ ra rằng, việc phát hiện sớm các lỗi ở mức kiểm thử đơn vị sẽ giảm đƣợc rất
nhiều chi phí cho kiểm thử ở các mức sau đó.
1.2.2. Kiểm thử tích hợp
Sau khi kết thúc quá trình kiểm thử đơn vị, các mô-đun đƣợc tích hợp lại tạo
thành hệ thống con có cấu trúc lớn hơn, đồng thời cần tiến hành kiểm thử tích hợp.
Kiểm thử tích hợp đƣợc thực thi với sự kết hợp của cả lập trình viên và các kỹ sƣ kiểm
thử tích hợp. Kết quả khi kết thúc giai đoạn kiểm thử tích hợp là dựng nên một hệ
thống ổn định, hợp lý, có thể chịu đƣợc những rung động ở mức kiểm thử hệ thống.
Mục tiêu chính của kiểm thử tích hợp đó là:
 Phát hiện lỗi tƣơng tác giữa các đơn vị
 Tích hợp các đơn vị thành hệ thống con và hệ thống hoàn chỉnh để chuẩn bị cho
kiểm thử ở mức hệ thống.
Các kỹ thuật kiểm thử áp dụng ở mức kiểm thử tích hợp:
 Kiểm thử cấu trúc: kiểm thử cấu trúc mã nguồn hệ thống.
 Kiểm thử chức năng: kiểm thử sự đáp ứng tốt các chức năng đặc tả của hệ
thống.
 Kiểm thử hiệu năng: Kiểm thử việc vận hành của hệ thống.
 Kiểm thử khả năng chịu tải: Kiểm thử hoạt động của hệ thống dƣới áp lực về
tải hay điều kiện môi trƣờng.
Để tích hợp các mô-đun của hệ thống, tùy từng hệ thống mà kiểm thử viên lựa
chọn chiến lƣợc tích hợp phù hợp. Có ba kiểu chiến lƣợc phổ biến nhất, đó là: Tích
hợp từ trên xuống (Top – Down), tích hợp từ dƣới lên (Bottom – Up), và chiến lƣợc
BigBang.
1.2.3. Kiểm thử hệ thống
Kiểm thử hệ thống là một giai đoạn quyết định trong tiến trình phát triển phần
mềm, bởi vì cần thiết phải lên lịch chặt chẽ ngày phát hành, cần phát hiện hầu hết các
lỗi, và kiểm tra việc gỡ lỗi đang thực hiện, đảm bảo không phát sinh lỗi mới. Kiểm thử
hệ thống bao gồm các hoạt động khác nhau: lập kế hoạch kiểm thử, thiết kế bộ kiểm
16

thử, chuẩn bị môi trƣờng kiểm thử, thực thi kiểm thử theo một chiến lƣợc rõ ràng, và
kiểm tra quá trình thực thi kiểm thử.
Sau khi hoàn thành kiểm thử tích hợp, một hệ thống phần mềm đã đƣợc hình
thành cùng với các thành phần đã đƣợc kiểm tra đầy đủ. Tại thời điểm này, lập trình
viên hoặc kiểm thử viên bắt đầu kiểm thử phần mềm nhƣ một hệ thống hoàn chỉnh.
Việc lập kế hoạch cho kiểm thử hệ thống nên bắt đầu từ giai đoạn hình thành và phân
tích các yêu cầu.
Kiểm thử hệ thống kiểm tra cả các hành vi chức năng của phần mềm lẫn các
yêu cầu về chất lƣợng nhƣ độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật.
Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm
hoặc phần cứng bên ngoài, chẳng hạn các lỗi "tắc nghẽn" (deadlock) hoặc chiếm dụng
bộ nhớ. Sau giai đoạn này, phần mềm thƣờng đã sẵn sàng cho khách hàng hay ngƣời
dùng cuối cùng kiểm thử chấp nhận sản phẩm (Acceptance Test) hoặc dùng thử
(Alpha/Beta Test).
Các kỹ thuật kiểm thử áp dụng cho kiểm thử hệ thống:
 Kiểm thử chức năng: Bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu
cầu thiết kế.
 Kiểm thử hiệu năng: Bảo đảm tối ƣu việc phân bổ tài nguyên hệ thống (ví dụ
bộ nhớ) nhằm đạt các chỉ tiêu nhƣ thời gian xử lý hay đáp ứng các truy vấn.
 Kiểm thử khả năng chịu tải: Bảo đảm hệ thống vận hành đúng dƣới áp lực cao
(ví dụ nhiều ngƣời truy xuất cùng lúc). Kiểm thử tập trung vào các trạng thái tới
hạn, các "điểm chết", các tình huống bất thƣờng nhƣ đang giao dịch thì ngắt kết
nối (xuất hiện nhiều trong kiểm tra thiết bị nhƣ POS, ATM ).
 Kiểm thử cấu hình: Quá trình kiểm thử hệ thống với mỗi cấu hình của phần
mềm và phần cứng đƣợc hỗ trợ.
 Kiểm thử bảo mật: Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ
thống.
 Kiểm thử khả năng phục hồi: Bảo đảm hệ thống có khả năng khôi phục trạng

thái ổn định trƣớc đó trong tình huống mất tài nguyên hoặc dữ liệu; nó đặc biệt
quan trọng đối với các hệ thống giao dịch nhƣ ngân hàng trực tuyến
1.2.4. Kiểm thử hồi quy
Kiểm thử hồi quy là một mức khác của kiểm thử mà đƣợc thực hiện trong suốt
quá trình phát triển hệ thống. Mỗi khi một thành phần nào đó của hệ thống có sự thay
đổi, cần tiến hành kiểm thử hồi quy. Mục đích chính trong kiểm thử hồi quy đó là đảm
17


bảo không phát sinh lỗi mới trong các thành phần không có sự thay đổi. Rõ ràng kiểm
thử hồi quy không phải một mức kiểm thử riêng biệt trong tiến trình kiểm thử. Mối
quan hệ giữa nó với các mức kiểm thử khác trong mô hình chữ V đƣợc thể hiện qua
Hình 1.3 [7].

Hình 1.3 – Kiểm thử hồi quy tại các mức kiểm thử phần mềm khác
1.2.5. Kiểm thử chấp nhận
Sau khí quá trình kiểm thử hệ thống kết thúc, phần mềm đƣợc phân phát tới
khách hàng. Khách hang sẽ tiến hành một loạt các kiểm thử của họ, thƣờng đƣợc biết
đến là kiểm thử chấp nhận. Yếu tố quan trọng nhất trong kiểm thử chấp nhận chính là
mức độ hài lòng của ngƣời dùng với hệ thống.
1.3. Các phƣơng pháp kiểm thử phần mềm
1.3.1. Kiểm thử hộp trắng
Kiểm thử hộp trắng, còn biết tới nhƣ kiểm thử cấu trúc hay kiểm thử hƣớng
logic, cho phép kiểm tra tất cả cấu trúc bên trong của phần mềm với mục đích đảm bảo
tất cả các câu lệnh và các điều kiện sẽ đƣợc thực hiện ít nhất một lần. Kiểm thử viên
truy nhập vào mã nguồn chƣơng trình và lấy đó làm cơ sở kiểm thử, họ hoàn toàn nắm
đƣợc cấu trúc lệnh bên trong của hệ thống (Hình 1.4). Trong kiểm thử hộp trắng, tập
trung vào kiểm thử luồng điều khiển và kiểm thử luồng dữ liệu.

Hình 1.4 – Kiểm thử hộp trắng

Các kỹ thuật kiểm thử:
 Kiểm thử luồng điều khiển
18


o Kiểm thử bao phủ dòng lệnh
o Kiểm thử bao phủ nhánh
o Kiểm thử bao phủ quyết định
o Kiểm thử đƣờng cơ sở
o Kiểm thử điều kiện
o Kiểm thử lặp
 Kiểm thử luồng dữ liệu
Kiểm thử luồng dữ liệu là phƣơng pháp lựa chọn đƣờng dẫn kiểm thử của
chƣơng trình dựa vào vị trí khai báo và sử dụng các biến trong chƣơng trình.
Ƣu, nhƣợc điểm:
Kiểm thử hộp trắng chỉ dựa trên mã nguồn chƣơng trình để kiểm thử, do đó tiết
kiệm đƣợc thời gian và chi phí cài đặt phần mềm. Đây là phƣơng pháp kiểm thử đơn
giản nhất, và cũng sớm phát hiện ra lỗi của chƣơng trình ngay trong cấu trúc dòng
lệnh. Nó giúp hạn chế các lỗi tiềm ẩn sẽ phát sinh khi cài đặt và sử dụng chƣơng trình.
Nhƣợc điểm chính của kiểm thử hộp trắng là không thể phát hiện hết các lỗi
phát sinh khi chạy chƣơng trình. Kiểm thử hộp trắng thiếu tính khách quan, kiểm thử
viên cũng là ngƣời lập trình mà không đứng trên vai trò ngƣời sử dụng.
1.3.2. Kiểm thử hộp đen – Black box testing
Kiểm thử hộp đen còn đƣợc biết tới với các tên gọi khác nhƣ kiểm thử chức
năng (function testing), kiểm thử hƣớng dữ liệu (data driven) hay kiểm thử hƣớng vào
ra (input/output driven). Trong kỹ thuật này, kiểm thử viên coi phần mềm nhƣ một hộp
đen, hoàn toàn không quan tâm tới cấu trúc và hành vi bên trong hệ thống – Hình 1.5.
Với bộ dữ liệu đầu vào, họ chỉ quan tâm đầu ra sẽ là gì, có đúng nhƣ đặc tả hay không.
Kiểm thử hộp đen tập trung vào các yêu cầu chức năng của hệ thống. Kiểm thử hộp
đen không thay thế kiểm thử hộp trắng, nó kết hợp với kỹ thuật kiểm thử hộp trắng, bổ

sung các khả năng phát hiện các lớp lỗi khác với các phƣơng pháp kiểm thử khác.

19


Hình 1.5 – Kiểm thử hộp đen
Kiểm thử hộp đen cố gắng phát hiện các loại lỗi sau:
 Các chức năng thiếu hoặc không đúng với đặc tả.
 Các lỗi truy cập cơ sở dữ liệu bên ngoài.
 Các lỗi giao diện.
 Các lỗi thi hành.
 Các lỗi khi khởi tạo hoặc kết thúc.
 …
Các kỹ thuật kiểm thử hộp đen
 Phân lớp tƣơng đƣơng
 Phân tích giá trị biên
 Kiểm thử mọi cặp
 Lập bảng quyết định
 Dự đoán lỗi
 Kiểm thử fuzz
 Kiểm thử dựa trên mô hình
 Ma trận dấu vết
 Kiểm thử thăm dò
 Kiểm thử dựa trên đặc tả
Ƣu, nhƣợc điểm:
Kiểm thử hộp đen hoàn toàn không quan tâm và không liên quan tới mã lệnh.
Với quan điểm chƣơng trình luôn luôn có lỗi và đƣa ra yêu cầu chƣơng trình phải đáp
ứng đƣợc, kiểm thử viên hộp đen tìm ra những lỗi mà các lập trình viên không nhận ra.
Mặt khác kiểm thử viên không biết các phần mềm thực sự đƣợc xây dựng nhƣ
thế nào, do đó có thể kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một

thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng một ca kiểm thử duy nhất, trong khi
đó một số phần của chƣơng trình lại bị bỏ sót không đƣợc kiểm thử.
20


Do vậy, kiểm thử hộp đen có ƣu điểm của “một sự đánh giá khách quan”, mặt
khác nó lại có nhƣợc điểm của “thăm dò mù”.
1.3.3. Kiểm thử hộp xám
Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải
thuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhƣng là kiểm thử ở mức
ngƣời sử dụng hay mức hộp đen. Việc thao tác tới dữ liệu đầu vào và định dạng dữ
liệu đầu ra là không rõ ràng, giống nhƣ một chiếc “hộp xám”, bởi vì đầu vào và đầu ra
rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống đƣợc kiểm tra. Sự
khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp giữa 2 mô-đun mã
lệnh đƣợc viết bởi hai chuyên viên thiết kế khác nhau, trong đó chỉ giao diện là đƣợc
đƣa ra để kiểm thử. Kiểm thử hộp xám có thể cũng bao gồm cả thiết kế đối chiếu để
quyết định, ví dụ, giá trị biên hay thông báo lỗi.
1.4. Các kỹ thuật kiểm thử cơ bản
1.4.1. Kiểm thử luồng điều khiển
Có hai loại câu lệnh cơ bản trong một đơn vị chƣơng trình, đó là: lệnh chỉ định
(assignment statement) và lệnh điều kiện (condition statement). Lệnh chỉ định là
những lệnh đƣợc biểu diễn bằng ký tự chỉ định “ = ”. Ví dụ nhƣ: x = 2 *y, trong đó x,
y đều là biến. Lệnh điều kiện là các lệnh có chứa các lệnh điều khiển, nhƣ if(), lặp
for(), lặp while(), goto. Trƣờng hợp không có lệnh điều khiển, các lệnh chƣơng trình
đƣợc thực hiện theo trình tự mà nó xuất hiện. Sự thành công khi thi hành một lệnh
chƣơng trình bắt nguồn từ luồng điều khiển của đơn vị đó.
Đồ thị luồng điều khiển (control flow graph - CFG) là đồ thị có hƣớng, biểu
diễn một chƣơng trình, với:
 Đỉnh: biểu diễn một lệnh tuần tự hay một khối lệnh.
 Cung: biểu diễn các nhánh rẽ của lệnh điều kiện

 Một đỉnh vào và một đỉnh ra đƣợc thêm vào để biểu diễn điểm vào và ra của
chƣơng trình.
Lộ trình trong CFG là đƣờng đi xuất phát từ đỉnh vào, đi qua các đỉnh và cung
trong đồ thị và kết thúc ở đỉnh ra. Chu trình tạo dữ liệu đầu vào kiểm thử cho kiểm thử
luồng điều khiển đƣợc mô tả trong lƣu đồ dƣới đây – Hình 1.6.
21



Hình 1.6 – Chu trình sinh dữ liệu đầu vào kiểm thử cho kiểm thử luồng điều khiển
 Lựa chọn đƣờng đi: đƣờng đi đƣợc lựa chọn từ CFG phải thỏa mãn tiêu chuẩn
lựa chọn đƣờng và dựa trên cấu trúc của CFG.
 Sinh dữ liệu đầu vào kiểm thử: Có hai loại đƣờng đi trong kiểm thử luồng điều
khiển:
o Đƣờng đi đƣợc (feasible path)
o Đƣờng không đi đƣợc (infeasible path)
 Các ký hiệu trong CFG – Hình 1.7

Hình 1.7 – Các ký hiệu trong CFG
Tiêu chuẩn lựa chọn đƣờng đi (Path selection criteria)
22


 Phủ tất cả các đƣờng: tất cả các đƣờng đi (bao gồm cả các đƣờng đi đƣợc và
không đi đƣợc) đều đƣợc lựa chọn.
 Phủ lệnh: Lựa chọn các đƣờng đi sao cho tất cả các lệnh đƣợc chạy ít nhất
một lần.
 Phủ nhánh: Lựa chọn các đƣờng đi sao cho tất cả các nhánh của CFG đƣợc
chạy ít nhất một lần.
 Phủ mệnh đề: Tổng hợp tất cả các khả năng đánh giá True/Fail của tất cả các

đối tƣợng (biểu thức).
Mỗi tiêu chuẩn chọn đƣờng đều có ƣu và nhƣợc điểm riêng của nó. Tùy từng
trƣờng hợp mà lựa chọn tiêu chuẩn chọn đƣờng cho phù hợp với cấu trúc của CFG.
1.4.2. Kiểm thử luồng dữ liệu
Ít nhất một nửa mã nguồn chƣơng trình bao gồm các lệnh khai báo dữ liệu, nhƣ
là: định nghĩa cấu trúc dữ liệu, các đối tƣợng riêng, giá trị mặc định ban đầu và các
thuộc tính. Lỗi dữ liệu là lỗi phổ biến nhất trong các lỗi mã nguồn, do đó kiểm thử
luồng dữ liệu là kỹ thuật không thể thiếu trong kiểm thử cấu trúc.
Một đơn vị chƣơng trình chấp nhận đầu vào, thực hiện tính toán, gán giá trị mới
cho biến, và trả về kết quả. Phƣơng pháp kiểm thử luồng dữ liệu chọn lựa một số
đƣờng diễn tiến của chƣơng trình dựa vào việc cấp phát, định nghĩa, và sử dụng những
biến trong chƣơng trình.
Có hai mức kiểm thử luồng dữ liệu:
 Kiểm thử luồng dữ liệu tĩnh: kỹ thuật này tập trung xác định lỗi tiềm năng,
thƣờng đƣợc biết đến nhƣ luồng dữ liệu bất thƣờng. Ba loại tình huống bất
thƣờng khi sử dụng biến:
o Loại 1: Đã đƣợc khai báo nhƣng sau đó lại đƣợc khai báo lại
o Loại 2: Không đƣợc khai báo nhƣng lại đƣợc tham chiếu tới
o Loại 3: Đƣợc khai báo nhƣng không đƣợc tham chiếu
 Kiểm thử luồng dữ liệu động: liên quan tới việc thực thi chƣơng trình thực tế.
Kỹ thuật này tƣơng tự nhƣ kiểm thử luồng điều khiển: Cần xác định đƣờng đi
để thi hành, và đƣờng đi đƣợc lựa chọn dựa trên tiêu chuẩn kiểm thử luồng dữ
liệu. Các bƣớc cơ bản:
o Vẽ đồ thị luồng dữ liệu (Data flow graph - DFG)
o Chọn một hay nhiều tiêu chuẩn kiểm thử luồng dữ liệu
23


o Xác định đƣờng đi trong DFG đáp ứng tiêu chuẩn đã chọn
o Rút ra các biểu thức vị từ từ các path đƣợc lựa chọn

o Giải các biểu thức vị từ thu đƣợc đầu vào kiểm thử
1.4.3. Kỹ thuật phân lớp tương đương
Việc kiểm thử tất cả các đầu vào của chƣơng trình là không thể. Vì thế, khi
kiểm thử chƣơng trình nên giới hạn một tập con tất cả các trƣờng hợp đầu vào có thể
có. Một tập con nhƣ vậy cần có hai tính chất:
 Mỗi trƣờng hợp kiểm thử nên gồm nhiều điều kiện đầu vào khác nhau có thể để
giảm thiểu tổng số các trƣờng hợp cần thiết.
 Nên cố gắng phân hoạch các miền đầu vào của một chƣơng trình thành một số
xác định các lớp tƣơng đƣơng, sao cho có thể giả định hợp lý rằng việc kiểm
thử một giá trị đại diện của mỗi lớp là tƣơng đƣơng với việc kiểm thử một giá
trị bất kỳ trong cùng lớp.
Hai vấn đề xem xét ở trên tạo thành một phƣơng pháp của kỹ thuật hộp đen và
gọi là phân hoạch tƣơng đƣơng.
Các bƣớc thực hiện trong kỹ thuật phân lớp tƣơng đƣơng – gồm ba bƣớc:
 Đối với mỗi dữ liệu vào, xác định các lớp tƣơng đƣơng từ miền dữ liệu vào.
 Chọn dữ liệu đại diện cho mỗi lớp tƣơng đƣơng
 Kết hợp các dữ liệu thử bởi tích Đề-các để tạo ra bộ dữ liệu kiểm thử
Nguyên tắc phân hoạch lớp tƣơng đƣơng:
 Nếu dữ liệu vào thuộc một khoảng, xây dựng:
o Một lớp các giá trị lớn hơn
o Một lớp các giá trị nhỏ hơn
o “n” lớp các giá trị hợp lệ
 Nếu dữ liệu là tập hợp các giá trị, xây dựng:
o Một lớp với tập rỗng
o Một lớp quá nhiều các giá trị
o “n” lớp hợp lệ
24


 Nếu dữ liệu là điều kiện ràng buộc, xây dựng:

o Một lớp với điều kiện ràng buộc đƣợc thỏa mãn
o Một lớp với ràng buộc không đƣợc thỏa mãn
1.4.4. Kỹ thuật phân tích giá trị biên
Lỗi phần mềm thƣờng xuất hiện gần các giá trị biên của miền dữ liệu đầu vào,
do đó tập trung phân tích các giá trị biên của miền dữ liệu để xây dựng dữ liệu kiểm
thử.
Nguyên tắc kiểm thử dữ liệu vào gồm:
 Giá trị nhỏ nhất
 Giá trị gần kề lớn hơn giá trị nhỏ nhất
 Giá trị bình thƣờng
 Giá trị gần kề nhỏ hơn giá trị lớn nhất
 Giá trị lớn nhất
Nguyên tắc chọn dữ liệu kiểm thử:
 Nếu dữ liệu vào thuộc một khoảng, chọn:
o Hai giá trị biên
o Bốn giá trị test = giá trị biên ± sai số nhỏ nhất
 Nếu dữ liệu vào thuộc danh sách các giá trị, chọn:
o Bốn giá trị test gồm: phần tử đầu tiên, phần tử thứ hai, phần tử kề cuối
và phần tử cuối
 Nếu dữ liệu vào là điều kiện ràng buộc số giá trị, chọn:
o Số giá trị tối thiểu, số giá trị tối đa và một số các giá trị không hợp lệ.
 Tự vận dụng khả năng và thực tế để chọn các giá trị biên cần kiểm thử
1.4.5. Kỹ thuật đồ thị - nhân quả
Đồ thị nhân - quả là một phƣơng pháp thiết kế trƣờng hợp kiểm thử trên cơ sở
đƣa ra một sự mô tả xúc tích các điều kiện logic và các hành vi kèm theo. Phƣơng
pháp này sử dụng mô hình các quan hệ logic giữa nguyên nhân và kết quả cho thành
phần phần mềm. Mỗi nguyên nhân đƣợc biểu diễn nhƣ một điều kiện (đúng hoặc sai)
25

của một đầu vào, hoặc kết hợp các đầu vào. Mỗi kết quả đƣợc biểu diễn nhƣ là một
biểu thức Bool biểu diễn một kết quả tƣơng ứng cho những thành phần vừa thực hiện.
Đồ thị nhân - quả đƣợc tạo nhƣ sau:
 Tất cả các nguyên nhân (các đầu vào) và các kết quả (các đầu ra) đƣợc liệt kê
dựa trên đặc tả và đƣợc định danh cho mỗi nhân – quả.
 Các quan hệ giữa các nguyên nhân (đầu vào) và các kết quả (đầu ra) đƣợc biểu
diễn trong đồ thị để làm rõ ràng các quan hệ logic.
 Từ đồ thị tạo ra bảng quyết định biểu diễn các quan hệ giữa nguyên nhân và kết
quả. Dữ liệu kiểm thử đƣợc sinh ra dựa trên các qui tắc trong các bảng này.
1.5. Kiểm thử tự động
Kiểm thử tự động (KTTĐ) là quá trình mà các bƣớc kiểm thử lặp đi lặp lại đƣợc
thực hiện bởi các công cụ kiểm thử phần mềm nhƣ Winrunner, Load runner, QTP,…,
sử dụng đầu vào của các test case và dự đoán kết quả đầu ra dƣới môi trƣờng đƣợc
kiểm soát. KTTĐ thƣờng đƣợc áp dụng trong kiểm thử hồi quy. Kiểm thử hồi quy
đƣợc tiến hành lặp lại mỗi khi hệ thống có các sự thay đổi lớn, nó tìm ra các lỗi phát
sinh khi hệ thống có những sự thay đổi hay trong quá trình khắc phục các lỗi khác của
hệ thống.
Tự động hóa kiểm thử có thể thay thế kiểm thử thủ công hay không?
Kiểm thử thủ công là quá trình mà chức năng của ứng dụng đƣợc kiểm thử dƣới
các môi trƣờng khác nhau và các điều kiện cho nó đƣợc chỉ định chức năng, giao diện,
tính dễ sử dụng, hiệu năng, khả năng bảo mật,… bởi kiểm thử viên, với các đầu vào
đƣợc yêu cầu từ nhóm phát triển ứng dụng và các tài liệu ứng dụng có tính chất khác
nhau. Kiểm thử thủ công vừa có ƣu điểm vừa có nhƣợc điểm. Kiểm thử đặc biệt (Ad
hoc testing) có thể thực hiện bằng kiểm thử thủ công, nó hầu nhƣ luôn cần thiết nhƣ
chức năng của ứng dụng và đƣợc hiểu rõ hơn bởi một kiểm thử viên. Thực tế cho thấy,
ad hoc testing phát hiện ra nhiều lỗi hơn KTTĐ. Nhƣợc điểm của kiểm thử thủ công là
phải chạy lại nhiều lần một kiểm thử khi xây dựng phức tạp gây mệt mỏi đối với mọi
nỗ lực của kiểm thử viên, và rất dễ xảy ra các lỗi slipping không đƣợc chú ý.
Một trong những ƣu điểm khi so sánh kiểm thử tự động với kiểm thử thủ công
đó là các công cụ kiểm thử sẽ không cảm thấy mệt mỏi trong quá trình kiểm thử lặp đi

lặp lại nhƣ con ngƣời. Tuy nhiên KTTĐ là một quy trình tốn kém hơn khi so sánh với
kiểm thử thủ công. KTTĐ yêu cầu hiểu biết về công việc với các công cụ kiểm thử.
Xây dựng các ca kiểm thử và kiểm thử các framework tốn nhiều thời gian hơn kiểm
thử thủ công. Trƣờng hợp ứng dụng lớn, đƣợc phát triển trên nhiều nền tảng hay đa
26


ngôn ngữ ngƣời dùng và cần lặp lại nhiều lần quá trình kiểm thử thì sẽ hiệu quả hơn
nếu áp dụng KTTĐ.
KTTĐ không hoàn toàn thay thế kiểm thử thủ công, mục đích của KTTĐ là
giảm các hoạt động kiểm thử thủ công và các hoạt động kiểm thử dƣ thừa bằng cách
sử dụng một giải pháp có hệ thống để đạt đƣợc một phạm vi và độ bao phủ các trƣờng
hợp kiểm thử tốt hơn, giảm chi phí và thời gian kiểm thử trong suốt vòng đời phần
mềm. Qua đó nâng cao chất lƣợng, tăng độ tin cậy, tăng hiệu quả của quá trình kiểm
thử, giải phóng các kỹ sƣ kiểm thử phần mềm khỏi việc thực hiện các công việc lặp lại
nhàm chán.
1.5.1. Kiến trúc kiểm thử tự động
Kiến trúc tự động hóa kiểm thử, hay một framework, bao gồm các công cụ
kiểm thử, thiết bị, các kịch bản kiểm thử, tiền điều kiện, và ngƣời điều khiển để hệ
thống tự động kiểm thử có tác dụng và hiệu quả. Tạo và duy trì một framework KTTĐ
là chìa khóa cho thành công của các dự án KTTĐ trong mỗi tổ chức. Sự thi hành một
framework tự động thông thƣờng bao gồm các nhóm KTTĐ: nhóm kiểm thử phát triển
(Development Test Group), nhóm kiểm thử hiệu năng (Performance Test Group),
nhóm kiểm thử khả năng mở rộng (Scalability Test Group), nhóm kiểm thử tự động
(Automation Test Group), nhóm kiểm thử khả năng chống đỡ (Sustaining Test Group).
Mỗi framework KTTĐ bao gồm 6 thành phần nhƣ trong Hình 1.8 dƣới đây:

Hình 1.8 – Các thành phần của một kiến trúc KTTĐ
Hệ thống đƣợc kiểm thử (System to be tested): Đây là thành phần đầu tiên của
một kiến trúc tự động. Các hệ thống con của hệ thống đƣợc kiểm thử phải vững chắc

ổn định. Nếu không, tự động hóa kiểm thử sẽ không có hiệu quả. Tất cả các hệ thống
27


con trong hệ thống phải bền vững và làm việc với nhau chặt chẽ trƣớc khi bắt đầu một
dự án KTTĐ.
Nền tảng kiểm thử (Test platform): là nền tảng hay các điều kiện thuận lợi mà
trên đó hệ thống sẽ đƣợc kiểm thử.
Thƣ viện các ca kiểm thử (Test case Library): Nó hữu ích để biên dịch các thƣ
viện của các bƣớc kiểm thử có thể tái sử dụng của các tiện ích cơ bản đƣợc dùng nhƣ
các khối đƣợc xây dựng trong các kịch bản KTTĐ. Mỗi tiện ích thƣờng thi hành một
nhiệm vụ riêng hỗ trợ tính tự động hóa của ca kiểm thử.
Bộ thực thi kiểm thử tự động (Automated Testing Practices): Các thủ tục mô
tả các ca kiểm thử sử dụng công cụ kiểm thử và các thƣ viện test case đã đƣợc tài liệu
hóa nhƣ thế nào. Một khuôn mẫu ca kiểm thử tự động nhất quán trên tất cả các ca
kiểm thử tự động đƣợc phát triển bởi các kỹ sƣ khác nhau.
Công cụ (Tools): Việc phát triển các kịch bản kiểm thử khác nhau yêu cầu các
loại công cụ khác nhau. Các công cụ hỗ trợ bao gồm nhà máy kiểm thử, bộ phân tích
yêu cầu, bộ theo dõi các khuyết điểm, công cụ quản lý cấu hình. Sự tích hợp của công
cụ KTTĐ và công cụ hỗ trợ nhƣ defect tracking sẽ quyết định báo cáo tự động các
nhƣợc điểm của các ca kiểm thử hỏng.
Bộ điều hành (Administrator): Bộ điều hành framework tự động quản lý các
thƣ viện ca kiểm thử, các nền tảng, và các công cụ kiểm thử; duy trì bảng kiểm kê của
các mẫu thử; cung cấp các hƣớng dẫn; và giúp cho kiểm thử viên sử dụng các thƣ viện
ca kiểm thử để viết kịch bản kiểm thử. Thêm vào đó, bộ điều hành còn cung cấp các
hƣớng dẫn hỗ trợ ngƣời dùng của các công cụ kiểm thử và duy trì mối liên hệ giữa các
nhà cung cấp công cụ và ngƣời dùng.
Kiến trúc tự động hóa đảm bảo:
 Các công cụ kiểm thử khác nhau và các thiết bị kết hợp làm việc chặt chẽ với
nhau.

 Thƣ viện của các kịch bản ca kiểm thử đƣợc tái sử dụng cho các dự án kiểm thử
khác nhau, nhƣ vậy sẽ giảm đƣợc công sức phát triển bị nhân lên.
 Tạo sự nhất quán trong cách viết kịch bản kiểm thử của các kiểm thử viên,
không ai đƣợc viết script theo cách chỉ của riêng mình họ.
 Tính nhất quán đƣợc duy trì trong toàn bộ các kịch bản kiểm thử.
 Quy trình tự động hóa bộ kiểm thử đƣợc kết hợp và sẵn dùng cho mỗi lần kiểm
thử hồi quy.
28


 Con ngƣời hiểu đƣợc sự phản hồi của hệ thống trong KTTĐ.
1.5.2. Ưu và nhược điểm của kiểm thử tự động
Ƣu điểm:
 Không cần sự can thiệp của kiểm thử viên.
 Việc viết script đơn giản và có thể tái sử dụng, ngoại trừ một số trƣờng hợp ứng
dụng phức tạp.
 Giảm chi phí khi thực hiện khi cần kiểm thử số lƣợng lớn ca kiểm thử hoặc ca
kiểm thử lặp lại nhiều lần.
 Có thể giả lập các tình huống khó thực hiện đƣợc bằng tay.
 Phát hiện nhanh các lỗi trong quá trình kiểm thử khi có những sự thay đổi.
Nhƣợc điểm:
 Do yêu cầu công nghệ nên đòi hỏi các kiểm thử viên phải có nhiều kinh nghiệm
và có khả năng viết script.
 Có thể tốn nhiều thời gian và chi phí cho công việc ban đầu khi xây dựng các
framework và các thƣ viện.
 Tốn chi phí cho việc bảo trì và chỉnh sửa các script.
 Việc xây dựng các nguyên lý chức năng trong scripts với các ứng dụng phức
tạp có thể gây mệt mỏi, nhàm chán.
 Phụ thuộc dữ liệu đầu vào thủ công cho dù các scipt có thể tái sử dụng.
1.5.2. Lựa chọn công cụ kiểm thử tự động

Có rất nhiều công cụ KTTĐ với các ƣu và nhƣợc điểm khác nhau. Mỗi ứng
dụng phần mềm hay các ứng dụng web lại đƣợc xây dựng trên một nền tảng với những
đặc điểm riêng. Vì thế việc lựa chọn công cụ kiểm thử cho phù hợp không hề đơn
giản. Trong tƣơng lai, với sự phát triển không ngừng của công nghệ phần mềm, vai trò
của kiểm thử đƣợc đánh giá cao hơn, sẽ cần những đội ngũ chuyên gia chuyên nghiên
cứu và tìm ra bộ công cụ kiểm thử phù hợp với từng sản phẩm phần mềm.
Dƣới đây là các tiêu chí cơ bản, có thể dựa trên đó để lựa chọn công cụ kiểm
thử phù hợp với ứng dụng cần kiểm thử.
1.5.1.1. Tiêu chí 1: Mục tiêu nhóm kiểm thử
Mục tiêu của nhóm kiểm thử là một trong những chìa khóa cho mọi thành công.
Nếu nhóm là một phần của đội QA hay R&D, onsite hay offshore, tất cả các thông số