Vai trò của kiểm thử tự động trong quy trình kiểm thử phần mềm

1

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ




NGUYỄN THỊ HUỆ


VAI TRÕ CỦA KIỂM THỬ TỰ ĐỘNG TRONG QUY
TRÌNH KIỂM THỬ PHẦN MỀM







LUẬN VĂN THẠC SĨ

Hà Nội - 2012







2


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ



NGUYỄN THỊ HUỆ


VAI TRÕ CỦA KIỂM THỬ TỰ ĐỘNG TRONG QUY
TRÌNH KIỂM THỬ PHẦN MỀM

LUẬN VĂN THẠC SĨ

Ngành CÔNG NGHỆ THÔNG TIN
Chuyên ngành CÔNG NGHỆ PHẦN MỀM
Mã số 60 48 10









NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. Đặng Văn Hưng








Hà Nội - 2012

Hà Nội - 2011
3


BẢNG CÁC CHỮ VIẾT TẮT 4
DANH SÁCH CÁC HÌNH VÀ BẢNG BIỂU 5
– 7
1.1 Đ 7
1.2 N 7
1.3 C 8
CHƢƠNG 2 – QUY TRÌNH KIỂM THỬ PHẦN MỀM 9
2.1 QUY TRÌNH PHÁT TRIểN PHầN MềM: 9
2.2 QUY TRÌNH KIểM THử PHầN MềM 9
2.3 G PHầN MềM TRONG VÕNG 11
2.4 CÁC Kỹ THUậT KIểM THử PHầN MềM 12
2.4.1 Kiểm thử hộp trắng (White-box) 12
14
15
CHƢƠNG 3 –TỰ ĐỘNG HÓA KIỂM THỬ PHẦN MỀM 17
3.1 ĐịNH NGHĨA: 17
3.2 MÔ HÌNH CHUNG CủA Tự ĐộNG HÓA KIểM THử PHầN MềM 17
3.3 CÔNG Cụ KIểM THử Tự ĐộNG 18
3.3.1 Lý do sử dụng công cụ kiểm thử 18
3.3.2 Các bước thực hiện kiểm thử tự động 19
3.3.3 Công cụ hỗ trợ trong quy trình kiểm thử phần mềm 20
3.4 CHUYÊN MÔN HÓA CON NGƯờI 22
3.5 CHI PHÍ TRONG KIểM THử Tự ĐộNG PHầN MềM 23
3.6 MộT Số HạN CHế TRONG Tự ĐộNG HÓA KIểM THử 23

CHƢƠNG 4 – TÌM HIểU CÔNG Cụ TESTCOMPLETE 9 26
4.1 L 26
4.2 H 27
4.3 C TESTCOMPLETE9 27
4.4 N SCRIPT 28
4.5 S TESTCOMPLETE9 28
4.6 CÁC BƯớC TạO MộT Dự ÁN KIểM THử VớI TESTCOMPLETE 9 33
4.7 V 34
4.8 ĐÁNH GIÁ CÔNG Cụ KIểM THử TESTCOMPLETE 9 56
4.8.1 So với mô hình chung của kiểm thử tự động 56
4.8.2 So với công cụ kiểm thử khác 57
4.9 NGHIÊN CứU Kỹ THUậT KIểM CHứNG THIếT Kế. 59
59
9 60
4.9.3 Ví dụ minh họa: 61
CHƢƠNG – 71
O 72
4


BẢNG CÁC CHỮ VIẾT TẮT

Từ viết tắt
Ý nghĩa
Giải thích tiếng Việt
ECG
Electrocardiography
Điện tim đồ
PDA
Personal Digital Assistant

Thiết bị kỹ thuật số hỗ
trợ cá nhân
ADL
Activities of Daily Living
Các hoạt động hàng
ngày
SAECA
Signal Algorithm Event
Condition Action
Tín hiệu thuật toán
hoạt động điều khiển
sự kiện
UML
Unified Modeling Language
Ngôn ngữ mô hình
hóa

5

DANH SÁCH CÁC HÌNH VÀ BẢNG BIỂU

Số
Tên hình/bảng biểu
trang
Hình 2.1
Quy trình kiểm thử phần mềm
10
Hình 2.2
Mô hình chữ V hiển thị thiết kế kiểm thử sớm
12

Hình 3.1
Mô hình chung của tự động hóa kiểm thử
17
Hình 3.2
Công cụ hỗ trợ trong quy trình kiểm thử phần mềm
20
Hình 4.1
Giao diện Project Explorer của TestComplete
29
Hình 4.2
Cửa sổ làm việc chính của TestComplete
30
Hình 4.3
.
31
Hình 4.4
Đối tượng Process trong TestComplete
32
Hình 4.5
Ứng dụng hộp đen trong TestComplete
32
Hình 4.6
Ứng dụng hộp trắng trong TestComplete
33
Hình 4.7
Giao diện Patients Management
34
Hình 4.8
Hộp thoại Create New Project
35

Hình 4.9
Xác định ứng dụng cần kiểm thử
36
Hình 4.10
Thêm ứng dụng kiểm thử vào dự án
36
Hình 4.11
Thêm tùy chọn Autorun cho ứng dụng kiểm thử
37
Hình 4.12
Thiết lập chế độ hiển thị trực quan kiểm thử
38
Hình 4.13
Chọn ngôn ngữ viết Script
39
Hình 4.14
Hộp thoại ghi kiểm thử Recording
41
Hình 4.15
Chức năng Append to Test trên thanh công cụ của trình soạn thảo
42
Hình 4.16
Thực hiện chạy ứng dụng cần kiểm thử
42
Hình 4.17
Giao diện quản lý bệnh nhân Patients Management
42
Hình 4.18
Hộp thoại chỉnh sửa thông tin bệnh nhân
43

Hình 4.19
Giao diện hiển thị các tùy chọn cho Checkpoint
44
Hình 4.20
Giao diện tạo Property Checkpoint
44
Hình 4.21
Nội dung ca kiểm thử
46
Hình 4.22
Giao diện Test Visualizer
47
6


Hình 4.23
Giao diện Visualizer Frame
47
Hình 4.24
Giao diện hiển thị các thao tác trong ca kiểm thử
48
Hình 4.25
Thao tác đăng nhập hệ thống đang kiểm thử
49
Hình 4.26
Thao tác chỉnh sửa thông tin bệnh nhân
50
Hình 4.27
Tổ chức cấu trúc cây các thao tác trong TestComplete 9
51

Hình 4.28
Giao diện hiển thị chức năng Run Test
52
Hình 4.29
Cửa sổ hiển thị quá trình thực hiện kiểm thử
53
Hình 4.30
Giao diện hiển thị kết quả kiểm thử
54
Hình 4.31
Giao diện Log hiển thị kết quả kiểm thử
55
Hình 4.32
Giao điện hiển thị chi tiết thao tác tạo lỗi
56
Hình 4.33
TestComplete 9 trong mô hình chung của tự động hóa kiểm thử
57
Hình 4.34
Nền tảng kiến trúc của hệ thống
62
Hình 4.35
Tổng quan về hệ thống
62
Hình 4.36
Lược đồ tuần tự trong UML của giao thức thiết kế - SAECA
63
Hình 4.37
Phân tích dữ liệu ECG và chèn thêm thông tin của mẫu
64

Hình 4.38
Sơ đồ xử lý dữ liệu ECG
64
Hình 4.39
Mô hình trạng thái của hệ thống
65
Hình 4.40
Mô hình trạng thái của module lưu trữ dữ liệu
66
Hình 4.41
Ứng dụng mô phỏng trên máy chủ IIS
66
Hình 4.42
Giao diện chạy thử ứng dụng
67
Hình 4.43
Mã nguồn ứng dụng mô phỏng
67
Hình 4.44
Mã nguồn chương trình khách
68
Hình 4.45
Giao diện chương trình khách
68
Hình 4.46
Kết quả mong đợi xây dựng trước
69
Hình 4.47
Kết quả chạy thực tế bằng TestComplete 9
70

Hình 4.48
Kết quả chạy kiểm thử của TestComplete 9
70
7

–

-
- (thực hiện kiểm tra
một cách nhanh chóng và “rẻ nhất” có thể).
.
Các
chạy bằng tay.
Trong lĩnh vực Kiểm thử tự động hiện có khá nhiều công cụ kiểm thử thương
mại nổi tiếng, phổ biến như TestComplete, QuickTest Professional, WinRunner,
Rational Robot, SilkTest, JTest,…Trong số đó, Test Complete phiên bản 9 của
Automated‟s QA SmartBear khá tốt và mạnh, bao gồm nhiều chức năng điển hình của
một công cụ kiểm thử tự động. Nó có thể thực thi kiểm thử ở nhiều mức: Kiểm thử
đơn vị, tích hợp, hệ thống và chấp nhận. Đây là một trong những loại công cụ phổ biến
nhất đang được sử dụng hiện nay.
Việc thực hiện kiểm chứng thiết kế trong quá trình tạo ra sản phẩm phần mềm
đặc biệt là những phần mềm phức tạp sẽ giúp làm tăng hiệu quả kinh tế nhờ việc phát
hiện lỗi sớm – ngay từ bước thiết kế phần mềm sẽ rút ngắn thời gian và chi phí hoàn
thành sản phẩm, đảm bảo tính tin cậy, an toàn của hệ thống được làm ra. Tuy nhiên,
thiết kế thường không ở dạng chương trình có thể cài đăt và chạy được. Một câu hỏi
đặt ra ở đây là liệu có thể áp dụng công cụ kiểm thử vào kiểm chứng thiết kế không?
Trả lời cho câu hỏi này luận văn có trình bày cách tiếp cận dùng công cụ kiểm thử vào
việc kiểm thử thiết kế mà cụ thể ở đây là công cụ kiểm thử TestComplete 9. Dùng kỹ
thuật trừu tượng hóa, biến đổi thiết kế thành mô hình có thể tiến hành để kiểm thử
bằng công cụ kiểm thử nhằm phát hiện lỗi ở giai đoạn sớm hơn.

1.2
Luận văn tập trung nghiên cứu về sự tự động hóa trong kiểm thử phần mềm gồm
khái niệm, lợi ích và cách thức thực hiện tự động hóa, chỉ ra một số công cụ kiểm thử
phần mềm và tập trung vào việc tìm hiểu công cụ kiểm thử TestComplete 9 – công cụ
đang được sử dụng khá phổ biến hiện nay. Ngoài ra, luận văn có trình bày một phương
pháp sử dụng công cụ kiểm thử TestComplete trong kiểm chứng thiết kế phần mềm.
8


1.3
Phần còn lại của luận văn có cấu trúc như sau:
Chương 2: Quy trình kiểm thử phần mềm. Chương này trình bày về mô hình phát
triển phần mềm và quy trình kiểm thử trong các mô hình phát triển phần mềm
Chương 3: Các kỹ thuật kiểm thử phần mềm. Chương này trình bày sơ qua về hai
kỹ thuật kiểm thử: Hộp đen (Black box), Hộp trắng (White box) và việc lựa chọn kiểu
kiểm thử cho hệ thống phần mềm.
Chương 4: Tự động hóa trong kiểm thử phần mềm. Chương này trình bày về khái
niệm, mô hình chung của tự động hóa kiểm thử, lợi ích và cách thức thực hiện tự động
hóa trong kiểm thử phần mềm. Giới thiệu một số công cụ kiểm thử tự động và đi sâu
vào việc tìm hiểu công cụ kiểm thử TestComplete 9. Trình bày phương pháp sử dụng
công cụ kiểm thử này trong kiểm chứng thiết kế.


9


Chƣơng 2 – QUY TRÌNH KIỂM THỬ PHẦN MỀM
quy trình phát triển phần mềm là điều quan trọng. Nếu chỉ viết nh
), bạn sẽ thấy các phương thức bạn sử dụng
sẽ khác nhiều so với những gì các công ty lớn sử dụng để phát triển phần mềm. Để tạo

ra một sản phẩm phần mềm lớn có thể bao gồm hàng chục, hàng trăm, thậ
làm việc chặt chẽ.Chi tiết về những việc họ làm, cách thức họ tương tác, và cách thức
họ quyết định là những thành phần trong quy trình phát triển phần mềm.
2.1 Quy trình phát triển phần mềm:
.
2.2 Quy trình kiểm thử phần mềm
Quy trình kiểm thử gồm các hoạt động sau:
− Kế hoạch kiểm thử (test planning)
− Thiết kế kiểm thử (test design)
− Triển khai kiểm thử (test implementation)
− Thực thi kiểm thử (test execution)
− Đánh giá kiểm thử (test evaluation)
Quy trình kiểm thử được mô tả trong hình vẽ dưới đây:
10




Hình 2.1: Quy trình kiểm thử phần mềm
Mỗi hoạt động đều có một sự chuyển giao riêng từ khâu này đến khâu khác. Cuối
cùng, các báo cáo lỗi và tài liệu sẽ cho kết quả. Đội triển khai sẽ sử dụng các tài liệu
này để xác định nguyên nhân gây ra lỗi và sửa chữa chúng.
Sau khi kế hoạch kiểm thử được xây dựng, dựa trên đầu vào cụ thể (ngân sách,
nguồn lực, thời gian), bước tiếp theo là phân tích các yêu cầu và xác định mục tiêu
kiểm thử cho đội kiểm thử.
Pha thiết kế kiểm thử chủ yếu tập trung vào xác định và thiết kế các thủ tục kiểm
thử. Ở bước này một quyết định sẽ được làm là xác định những gì cần kiểm thử bằng
tay và những gì sẽ được kiểm thử tự động.
Các ca kiểm thử và các thủ tục kiểm thử là kết quả của pha triển khai kiểm thử.
Các kịch bản kiểm thử (Test scripts) được viết bằng các ngôn ngữ lập trình xác định

như Visual Basic, Java hoặc C++. Ở pha này, một số kịch bản kiểm thử có thể được sử
dụng lại từ các kiểm thử trước đó.
Thực thi kiểm thử có các kế hoạch và thủ tục kiểm thử như là đầu vào. Sau khi
thực thi các kiểm thử, kết quả kiểm thử được đánh giá bằng một Oracle. Oracle ở đây
là một chuyên gia có thể quyết định được kết quả đó là đúng hay sai.

11

2.3 Giai đoạn phần mềm

Kiểm thử thường được xem là công việc sẽ được làm sau khi phần mềm đã được
viết. Điều này làm cho giả định rằng kiểm thử chỉ đơn thuần là thực hiện việc kiểm tra,
chạy các kiểm thử. Dĩ nhiên, các kiểm thử không thể được thực thi mà không có phần
mềm cái đã thực sự làm việc. Tuy nhiên, các hoạt động kiểm thử sẽ gồm nhiều hơn so
với việc chỉ chạy các ca kiểm thử.
Mô hình chữ V của phát triển phần mềm minh họa khi nào hoạt động kiểm thử sẽ
diễn ra. Mô hình này chỉ ra rằng mỗi hoạt động phát triển phần mềm có một hoạt động
kiểm thử tương ứng.
Mô hình chữ V được đơn giản hóa ở hình vẽ 2.2 chỉ ra bốn mức của hoạt động
kiểm thử và phát triển. Các tổ chức khác nhau có thể có cách đặt tên khác nhau cho
mỗi giai đoạn. Điều quan trọng là mỗi giai đoạn bên trái của mô hình có một đối tác
bên phải, bất kể là giai đoạn nào.
Yếu tố quan trọng nhất để một ứng dụng thành công trong mô hình chữ V là vấn
đề khi nào các ca kiểm thử được thiết kế. Hoạt động thiết kế kiểm thử luôn luôn tìm
thấy lỗi trong bất kỳ ca kiểm thử nào được thiết kế đối với. Chẳng hạn, thiết kế các ca
kiểm thử chấp nhận sẽ tìm lỗi trong yêu cầu, thiết kế các ca kiểm thử hệ thống sẽ tìm
lỗi trong đặc tả chức năng, thiết kế các ca kiểm thử tích hợp sẽ tìm lỗi trong thiết kế,
và thiết kế các ca kiểm thử đơn vị sẽ tìm lỗi trong mã chương trình. Nếu việc thiết kế
kiểm thử được để lại sau cùng, các lỗi sẽ chỉ được tìm thấy ngay trước khi các ca kiểm
thử sẽ được chạy thì việc chỉnh sửa chúng sẽ rất tốn kém.

Việc thiết kế kiểm thử không cần phải đợi cho đến khi ca kiểm thử sẽ được thực
thi; nó có thể được tạo ở bất kỳ thời điểm nào sau khi có tài liệu để tạo nó. Như vậy,
việc tìm lỗi mới thực sự hiệu quả bởi các lỗi có thể được chỉnh sửa trước khi chúng
được lan truyền.
12



2.2: Mô hình chữ V hiển thị thiết kế kiểm thử sớm
Dĩ nhiên, các ca kiểm thử không thể được thực hiện cho đến khi phần mềm đã
được làm, nhưng chúng có thể được tạo sớm. Thực tế, các kiểm thử được thực thi theo
thứ tự ngược với thời điểm tạo chúng, ví dụ các ca kiểm thử đơn vị được tạo sau
nhưng chúng lại được thực hiện trước.
2.4 Các kỹ thuật kiểm thử phần mềm
2.4.1 Kiểm thử hộp trắng (White-box)
. Khi biết
được cấu trúc của sản phẩm, kiểm thử có thể kiểm soát được một cách chắc chắn bản
chất thao tác thực hiện có theo đặc tả kỹ thuật không? Và các thành phần có được thực
hiện hợp lý không?
ỹ
thuật trong mã lệnh, bao gồm các kỹ thuật sau:
− Phân đoạn sự kiện: mỗi phân đoạn của cấu trúc điều khiển mã lệnh được thi hành
theo sự phân đoạn nhỏ nhất
− Phân nhánh sự kiện hoặc kiểm thử nút: mỗi nhánh trong mã lệnh được thực hiện
theo mỗi hướng có thể thực hiện được theo mức nhỏ nhất.
− Sự kiện điều kiện ghép: Khi có nhiều điều kiện, chúng ta không cần kiểm thử
từng hướng (từng điều kiện) nhưng phải kết hợp các hướng có thể thực hiện được
của điều kiện, cách thường dùng là bảng chân lý.
− Kiểm thử đường đi cơ bản: Mỗi đường đi độc lập từ đầu đến cuối trong mã lệnh
trong trình tự đã được xác định trước.

13

− Kiểm thử theo luồng dữ liệu (DFT - Data Flow Testing): phương pháp này thực
hiện kiểm tra các biến đặc trưng trong mỗi tính toán có thể được thực thi, như
vậy hạn chế thiết lập các đường trung gian từ đầu đến cuối mã lệnh, … đây là cơ
sở trên mỗi mảnh của mã lệnh để chọn và kiểm tra.
− Kiểm thử đường đi: kiểm thử đường đi là kiểm thử kiểm thử tất cả các đường đi
có thể thực hiện được từ đầu đến cuối mã lệnh được định nghĩa và chuyển đổi.
Kiểm thử này rất phức tạp và tốn thời gian.
− Kiểm thử vòng lặp: bổ sung đơn vị đo lường lớn nhất, đó là chiến lược kiểm thử
căn bản trong kiểm thử vòng lặp. Chiến lược này hướng tới việc kiểm thử các
vòng lặp đơn, các vòng lặp ràng buộc nhau, và các vòng lặp lồng nhau.

các tình huống kiểm thử mà:
− Đảm bảo tất cả các đường đi độc lập trong module được thực thi ít nhất một lần.
− Sử dụng tất cả các quyết định logic trong các giá trị của nó (đúng hoặc sai).
− Thực thi được tất cả các vòng lặp.
− Sử dụng các cấu trúc dữ liệu của nó để đảm bảo giá trị của chúng.
.

nhiều lỗ hổng của các nhược điểm trong lập trình như:
− Các lỗi logic và các giả định không đúng bị đảo ngược. Lỗi này xuất hiện khi
thiết kế và thực thi các hàm chức năng, các điều kiện hoặc các điều khiển.
− Luồng logic của chương trình có những khác thường, nghĩa là giả định của chúng
ta về luồng của điều khiển và dữ liệu có thể tạo ra các lỗi thiết kế mà nó chỉ có
thể phát hiện được khi dùng kiểm thừ đường đi.
− Lỗi sinh các giá trị ngẫu nhiên.
Kỹ năng yêu cầu
ĩa tất cả
các đường logic, mở rộng các tình huống kiểm thử để thực thi và đánh giá kết quả trả

14


về… Nói chung là các tình huống kiểm thử thực thi được tất cả các vấn đề trong
chương trình.
Để thực hiện được điều này chúng ta phải nắm được chương trình, đặc tả kỹ
thuật và mã lệnh được kiểm thử.

:
− Công cụ dò tìm lỗ hổng bộ nhớ và lỗi run-time.
− Công cụ ghi lại chính xác thời gian sử dụng ứng dụng trong khối nhất định của
mã lệnh cho mục đích tìm kiếm những đoạn mã không hiệu quả.
− Công cụ xác định các vùng của ứng dụng được hoặc không được thực thi.
2.4.2
Với kiểm thử hộp đen, người kiểm thử không cần biết đến cấu trúc hoặc cơ chế
làm việc bên trong hộp đen mà cái cần quan tâm là chức năng của nó.
Kỹ thuật kiểm thử nền tảng đồ thị
Kiểm thử phần mềm bắt đầu bằng việc tạo ra đồ thị của các đối tượng quan trọng
và các mối liên quan tới nó, sau đó đưa ra một chuỗi các kiểm thử mà nó bao hàm
được đồ thị để thực thi được các đối tượng và các quan hệ của đối tượng để phát hiện
lỗi.
Kỹ thuật phỏng đoán lỗi
Phỏng đoán lỗi được hình thành qua kinh nghiệm kỹ thuật và dự án. Không có
công cụ và công nghệ giành cho kỹ thuật này, nhưng chúng ta có thể dựng các tình
huống kiểm thử dựa vào trạng thái làm việc của hàm chức năng.
Kỹ thuật phân tích giá trị đường biên
Phân tích giá trị đường biên (BVA - Boundary Value Analysis) là kỹ thuật lựa
chọn dữ liệu kiểm thử (kỹ thuật kiểm thử chức năng) với các giá trị đường biên. Giá trị
đường biên bao gồm: cực đại, cực tiểu. giá trị sát trong/ sát ngoài đường biên, các giá
trị đặc biệt và các giá trị lỗi. Kỹ thuật này thực hiện với kỳ vọng: nếu hệ thống thực

hiện đúng với các giá trị đặc biệt này thì sẽ chạy đúng với tất cả các giá trị trong phạm
vi của nó, thì một lớp tương đối hợp lệ và hai lớp tương đối không hợp lệ được xác
định.
− Nếu điều kiện định rõ thành phần thiết lập, thì một lớp tương đối hợp lệ và một
lớp tương đối không hợp lệ được xác định.
15

− Nếu điều kiện vào là giá trị logic, thì một lớp hợp lệ và một lớp không hợp lệ
được xác định.
Kỹ thuật kiểm thử so sánh
Có những tình huống giành cho những phiên bản độc lập của phần mềm ứng
dụng, những phiên bản độc lập này là cơ sở của kỹ thuật kiểm thử hộp đen được gọi là
kiểm thử so sánh hoặc kiểm thử back – to – back
Kỹ thuật kiểm thử chuỗi trực giao
Chiến lược kiểm thử chuỗi trực giao là phương thức thống kê, có hệ thống của
kiểm thử tương tác bắt nguồn từ tập hợp nhỏ thích hợp của các tình huống kiểm thử.
Ưu điểm:
− Người kiểm thử không cần biết về mặt kỹ thuật.
− Kỹ thuật kiểm thử này thích hợp nhất cho việc tìm lỗi như một người dùng thực
thụ.
− Kỹ thuật kiểm thử này hỗ trợ nhận dạng sự gần đúng và trái ngược trong hàm
chức năng.
− Các tình huống kiểm thử được phác họa ngay sau khi hoàn thành hàm chức năng.
Nhược điểm:
− Khả năng kiểm thử phụ thuộc vào người lập trình.
− Dữ liệu đầu vào cho kiểm thử cần một lượng mẫu lớn.
− Rất khó để nhận dạng được tất cả dạng dữ liệu đầu vào cho giới hạn kiểm thử.
− Không xác định được đồ thị cho quá trình kiểm thử.
2.4.3
không đảm bảo được khả năng thực hiện các chi tiết kỹ thuật (đặc điểm kỹ thuật của

phần mềm) một
kỹ thuật, nhưng nó không đảm bảo khả năng thực hiện được hết tất cả các chi tiết kỹ
thuật. Như vậy chúng ta có thể thấy:
− , khi tìm thấy lỗi sẽ xác
định được cụ thể chi tiết kỹ thuật chưa hoàn chỉnh.
16


− , khi tìm thấy lỗi sẽ
xác định được phần lỗi của quy trình.
Vậy nên để hoàn thành kiểm thử cho sản phầm phần mềm cần phải áp dụng cả
hai loại kiểu thử này.
của phần mềm trước khi dựng kế hoạch kiểm thử và nếu như phần mềm xây dựng
không chính xác theo yêu cầu kỹ thuật thì rất khó xác định dữ liệu đầu vào phù hợp.
(LLD
– Low Level Design) là hoàn thành. LLD sẽ ghi địa chỉ cho tất c
kiểm thử theo yêu cầu.
Vai trò của giai đoạn giải quyết lỗi kiểm thử rất quan trọng vì lỗi của tình huống
kiểm thử có thể có kết quả thay đổi theo từng
. Sự lựa chọn ít phức tạp hơn là coi quá trình kiểm thử có kết quả đúng, sau đó
dùng kết quả này thực hiện lại bước liền trước đó, có thể sẽ tìm thấy lỗi.
17


Chƣơng 3 –TỰ ĐỘNG HÓA KIỂM THỬ PHẦN MỀM
Kiểm thử là khâu quan trọng trong quy trình phát triển phần mềm. Thông qua
việc kiểm thử, chất lượng của ứng dụng phần mềm cuối cùng có thể được cải thiện.
Tuy nhiên, kiểm thử phần mềm cũng là một quy trình tốn kém, nó có thể làm tiêu tốn
nhiều tài nguyên về thời gian, tiền bạc và con người.
3.1 Định nghĩa:

Tự động hóa kiểm thử phần mềm là thực hiện kiểm thử phần mềm bằng một
chương trình đặc biệt với rất ít hoặc không có sự tương tác của con người.Việc thực
hiện tự động phải đảm bảo được rằng không có hoạt động kiểm thử nào bị bỏ qua. Nó
giúp các kỹ sư kiểm thử (tester) không phải lặp đi lặp lại các bước nhàm chán.
3.2 Mô hình chung của tự động hóa kiểm thử phần mềm
Tự động hóa kiểm thử phần mềm bao gồm một chuỗi các quá trình, các hoạt
động, thao tác được quy tụ với nhau để thực hiện phần mềm cần kiểm thử và ghi lại
kết quả kiểm thử.
Phần lớn các kiến trúc kiểm thử thường là những hệ thống mở bởi yêu cầu kiểm
thử là một tổ chức xác định.

Hình 3.1: Mô hình chung của tự động hóa kiểm thử
18


Trong đó, các công cụ được dùng để tự động hóa quy trình kiểm thử trong mô
hình kiểm thử thực hiện các chức năng:
Test Manager: quản lý việc thực hiện các kiểm thử của chương trình, theo dõi dữ
liệu kiểm thử, kết quả mong đợi và các chức năng, tiện ích của chương trình được
kiểm thử.
Test data generator: sinh dữ liệu kiểm thử cho chương trình
Oracle: tạo các phán đoán của kết quả mong đợi. Nó có thể là các phiên bản
chương trình trước đó hoặc các hệ thống prototype. Chú ý, ở đây không phải là cơ sở
dư liệu Oracle
File comparator: Đối chiếu kết quả kiểm thử chương trình với kết quả kiểm thử
trước đó và ghi lại sự khác nhau vào tài liệu
Report generator: cung cấp các mẫu báo cáo và các tiện ích cho kết quả kiểm thử
Dynamic analyzer: thêm mã cho chương trình để tính lượng thời gian mỗi lệnh
được thực hiện.
Simulator: mô phỏng môi trường kiểm thử cho sản phẩm phần mềm.

3.3 Công cụ kiểm thử tự động
.
công cụ kiểm thử ?
3.3.1 Lý do sử dụng công cụ kiểm thử
công cụ kiểm thử :
:
ho .
Ví dụ:
.
:
Trong quá trình phát triển phần mềm, nhóm lập trình thường đưa ra nhiều phiên
bản phần mềm liên tiếp để kiểm thử.Thực tế cho thấy việc đưa ra các phiên bản phần
19

mềm có thể là hàng ngày, mỗi phiên bản bao gồm những tính năng mới, hoặc tính
năng cũ được sửa lỗi hay nâng cấp. Việc bổ sung hoặc sửa lỗi code cho những tính
năng ở phiên bản mới có thể làm cho những tính năng khác đã kiểm thử tốt chạy sai
mặc dù
. Điều này sẽ khó khả thi về mặt thời gian nếu
kiểm tra thủ công.

Đây là kiểm tra nhằm đánh giá xem vận hành của phần mềm có thỏa mãn yêu
cầu đặt ra hay không. Thông qua đó, kỹ thuật viên có thể xác định được các yếu tố về
phần cứng và phần mềm ảnh hưởng đến khả năng vận hành của phần mềm.
Có thể liệt kê một số tình huống kiểm thử tiêu biểu thuộc loại này như sau:
− Đo tốc độ trung bình xử lý một yêu cầu của web server.
− Thiết lập 1000 yêu cầu, đồng thời gửi đến web server, kiểm tra tình huống 1000
người dùng truy xuất web cùng lúc.
− Xác định số yêu cầu tối đa được xử lý bởi web server hoặc xác định cấu hình
máy thấp nhất mà tốc độ xử lý của phần mềm vẫn có thể hoạt động ở mức cho

phép.
Việc kiểm tra thủ công cho những tình huống trên là cực khó, thậm chí "vô phương".
3.3.2 Các bƣớc thực hiện kiểm thử tự động
nên :
− Thu thập các đặc tả yêu cầu hoặc test case; lựa chọn những phần cần thực hiện
kiểm thử tự động.
− Phân tích và thiết kế mô hình phát triển kiểm thử tự động.
− Phát triển lệnh đặc tả cho kiểm thử tự động.
− Kiểm tra và theo dõi lỗi trong đặc tả của kiểm thử tự động.
:
20


1. Tạo kịch bản kiểm thử: Giai đoạn này chúng ta sẽ dùng công cụ kiểm thử
để ghi lại các thao tác lên phần mềm cần kiểm tra và tự động sinh ra kịch
bản kiểm thử.
2. Chỉnh sửa kịch bản kiểm thử: Chỉnh sửa để kịch bản kiểm thử thực hiện
kiểm tra theo đúng yêu cầu đặt ra, cụ thể là làm theo ca kiểm thử cần thực
hiện.
3. Chạy kịch bản kiểm thử để kiểm thử tự động: Giám sát hoạt động kiểm tra
phần mềm của kịch bản kiểm thử.
4. Đánh giá kết quả: Kiểm tra kết quả thông báo sau khi thực hiện kiểm thử tự
động. Sau đó bổ sung chỉnh sửa những sai sót.
3.3.3 Công cụ hỗ trợ trong quy trình kiểm thử phần mềm
Công cụ kiểm thử tự động phần mềm rất đa dạng và được sử dụng trong nhiều
giai đoạn kiểm thử khác nhau. Hình vẽ 3.2 chỉ ra các loại công cụ khác nhau và việc sử
dụng chúng trong vòng đời phát triển phần mềm.

Hình 3.2: Công cụ hỗ trợ trong quy trình kiểm thử phần mềm
Công cụ thiết kế kiểm thử (Design testing tools): giúp lấy dữ liệu đầu vào cho
kiểm thử (gọi là dữ liệu kiểm thử). Trong đó, công cụ thiết kế logic làm việc dựa trên
logic của đặc tả, một giao diện hoặc từ mã, đôi khi nó còn được gọi là công cụ sinh ca
kiểm thử (Test case generators). Ưu điểm chính của việc sử dụng công cụ kiểm thử
21

này là loại bớt những kiểm thử dư thừa bằng việc tìm những ca kiểm thử đảm bào bao
phủ tốt nhất mã chương trình. Công cụ thiết kế vật lý thao tác trên dữ liệu tồn tại hoặc
sinh dữ liệu kiểm thử. Nó còn được gọi là công cụ sinh dữ liệu kiểm thử (Test data
generator). Công cụ này được dùng để đổ các dữ liệu kiểm thử vào các tệp tin hoặc cơ
sở dữ liệu. Dữ liệu được chọn ngẫu nhiên hoặc dựa trên một số điều kiện xác định.
Công cụ này thường được sử dụng với khối lượng dữ liệu lớn cần thiết trong kiểm thử
chịu tải và vận hành. Ví dụ một công cụ có thể trích xuất các bản ghi ngẫu nhiên từ
một cơ sở dữ liệu sẽ là một công cụ thiết kế vật lý.Một công cụ có thể lấy được dữ liệu
đầu vào từ đặc tả sẽ là công cụ thiết kế logic.
Công cụ quản lý kiểm thử (Test management tools): bao gồm công cụ trợ giúp
để lên kế hoạch kiểm thử, theo dõi những ca kiểm thử đã chạy, tổ chức các thành phần
tham gia kiểm thử như: các tệp tin kịch script, các ca kiểm thử, báo cáo kiểm thử và
các kết quả kiểm thử. Nó cũng bao gồm các công cụ trợ giúp việc tìm nguồn gốc các
kiểm thử cho các yêu cầu, thiết kế và mã, cũng như các công cụ theo dõi lỗi.
Công cụ phân tích tĩnh (Static alnalysis tools): phân tích mã chương trình mà
không thực thi nó, giúp định lượng độ phức tạp của mã chương trình. Một số công cụ
cho ta thấy cấu trúc đồ họa của mã chương trình. Loại công cụ này rất hữu ích trong
việc tìm các ca kiểm thử cần thiết để thực thi một số điểm của mã trong các mô-đun
phức tạp.
Công cụ bao phủ (Coverage tools) đánh giá xem bao nhiêu phần của phần mềm
cần kiểm thử đã được thực hiện bởi một tập thử nghiệm. Công cụ này được dùng phổ
biến nhất ở giai đoạn kiểm thử đơn vị, nó giúp xác định các chuỗi mã chương trình
không được bao phủ bởi các ca kiểm thử. Chẳng hạn, nhánh bao phủ thường là một

yêu cầu để kiểm thử các hệ thống an toàn quan trọng hoặc liên quan đến an toàn. Công
cụ bao phủ có thể cũng đo phạm vi bao phủ của các cấu trúc mức thiết kế.
Công cụ gỡ lỗi (Debugging tools) thực tế không phải là công cụ kiểm thử vì việc
gỡ lỗi không phải là một phần của kiểm thử.Tuy nhiên các công cụ gỡ lỗi thường được
sử dụng trong giai đoạn kiểm thử, đặc biệt khi ta muốn cô lập các lỗi mức thấp. Công
cụ gỡ lỗi cho phép lập trình viên đi qua mã chương trình bằng cách thực thi theo từng
chỉ dẫn ở thời điểm tương ứng và xem nội dung của vị trí dữ liệu.
Công cụ phân tích động (Dynamic alnalysis tools) đánh giá hệ thống trong khi
phần mềm đang chạy, ví dụ công cụ tìm lỗ hổng trong bộ nhớ. Một rò rỉ bộ nhớ xảy ra
khi một chương trình không giải phóng các khối bộ nhớ khi nó cần, vì vậy
Mô phỏng (Simulators) là các công cụ cho phép các phần của một hệ thống được
kiểm thử theo những cách mà chúng không thể thực hiện được trong thế giới thực.Ví
22


dụ quá trình kiểm tra lỗi rò rỉ lò phản ứng hạt nhân có thể được kiểm thử bằng mô
phỏng.
Các công cụ kiểm thử hiệu năng (Performance testing) đo thời gian thực hiện
các sự kiện khác nhau. Ví dụ, chúng có thể đo được thời gian phản hồi dưới điều kiện
chịu tải hoặc đặc thù riêng. Các công cụ kiểm thử chịu tải (Load testing) tạo ra quá
trình tắc nghẽn của hệ thống. Ví dụ, chúng có thể sinh ra một số giao dịch đại diện cho
các mức tối đa. Loại công cụ này có thể được sử dụng để kiểm thử chịu tải (volume
and stress testing).
Các công cụ so sánh và thực thi kiểm thử (Test execution and comparison) cho
phép các kiểm thử được thực hiện một cách tự động và các kết quả được so sánh với
kết quả mong đợi. Các công cụ này có thể thực hiện ở bất kỳ mức nào: kiêm thử đơn
vị, tích hợp, hệ thống và kiểm thử chấp nhận. Công cụ Capture/playback là công cụ so
sánh và thực thi kiểm thử, nó được dùng để ghi lại các phiên kiểm thử dưới dạng tệp
tin script và cho phép chạy lại chúng sau đó. Công cụ này rất hữu ích cho kiểm thử hồi
quy. Đây là một trong những công cụ đang sử dụng phổ biến nhất hiện nay. Công cụ

TestComplete 9 được trình bày trong luận văn thuộc loại công cụ kiểm thử này.
3.4 Chuyên môn hóa con ngƣời
Để thực hiện kiểm thử phần mềm tự động, con người cần phải được đào tạo.
Trách nhiệm của kỹ sư thực hiện kiểm thử tự động là:
− Phát triển các thủ tục và ca kiểm thử dựa trên yêu cầu (hay đặc tả phần mềm)
− Thực hiện bằng tay các thủ tục kiểm thử
− Kiểm thử các hướng thủ tục
− Tiến hành kiểm thử
− Chuẩn bị các báo cáo về tiến độ kiểm thử và hồi quy
− Sử dụng các tiêu chuẩn kiểm thử
Kỹ năng đòi hỏi tối thiểu đối với kỹ sử kiểm thử tự động là:
− Có kinh nghiệm kiểm thử phần mềm
− Có kinh nghiệm thiết kế các bộ kiểm thử
− Quen với thiết kế giao diện người dùng và các chuẩn thiết kế giao diện người
dùng
− Quen với lĩnh vực kinh doanh của phần mềm được phát triển
23

− Có kinh nghiệm lập trình
Trong nhóm kiểm thử cũng có thể gồm những người không có kinh nghiệm sử
dụng công cụ kiểm thử, ở đó họ sẽ được giao những nhiệm vụ cụ thể trong quy trình
kiểm thử.
3.5 Chi phí trong kiểm thử tự động phần mềm
Chi phí liên quan đến kiểm thử tự động bao gồm:
− Chi phí về công cụ phần mềm
− Chi phí phần cứng
− Chi phí về lương cho kỹ sư kiểm thử tự động
− Chi phí đào tạo
− Phần trăm trả cho các trang thiết bị và công cụ phần mềm sử dụng trong quy
trình kiểm thử

− Chi phí bảo trì cho các thiết bị và công cụ
− Chi phí phân tích khả năng vận hành của sản phẩm dựa trên dữ liệu kiểm thử đã
tạo ra và kết quả của các kiểm thử đã thực hiện trước đó.
So với kiểm thử thủ công thì chi phí kiểm thử tự động là cao hơn, đặc biệt ở thời
điểm bắt đầu của quy trình tự động hóa. Từ công cụ kiểm thử cho đến các trang thiết
bị cần thiết đều rất đắt đỏ. Tuy nhiên, vốn đầu tư sẽ được hoàn lại sau khoảng thời gian
dùng kiểm thử tự động.
Không có sự so sánh rõ ràng giữa chi phí thực hiện các kiểm thử tự động và kiểm
thử thủ công, ở đây ngụ ý về chi phí cho mỗi lần một ca kiểm thử được thực hiện.
Tổng chi phí kiểm thử được xác định bằng tổng chi phí kiểm thử thủ công và tự động:

ở đây bao gồm các phí phát sinh khác.
3.6 Một số hạn chế trong tự động hóa kiểm thử
Không thể thay thế kiểm thử thủ công
Nó là không thể, cũng không phải là đáng mong muốn để tự động hóa tất cả các
hoạt động kiểm thử, tất cả các ca kiểm thử. Sẽ luôn có một số ca kiểm thử mà việc
kiểm thử bằng tay sẽ dễ dàng hơn nhiều so với kiểm thử tự động, hoặc nó là quá khó
24


khăn để tự động hóa hay nó là không kinh tế để thực hiện tự động hóa. Các kiểm thử
như vậy gồm:
− Kiểm thử rất hiếm khi chạy. Chẳng hạn, nếu một ca kiểm thử chỉ chạy một lần
một năm, thì có lẽ không đáng giá nếu tự động hóa kiểm thử đó.
− Phần mềm thường xuyên thay đổi. Chẳng hạn, nếu giao diện người dùng và các
tính năng thay đổi gần như hoàn toàn từ một phiên bản đến phiên bản tiếp theo,
việc nỗ lực thay đổi các kiểm thử tự động sao cho phù hợp gần như là không hiệu
quả.
− Các kiểm thử mà kết quả dễ dàng được kiểm chứng bởi một người, nhưng là rất
khó khăn nếu thực hiện tự động hóa. Ví dụ: sự phù hợp của một bảng màu, tính

hấp dẫn lôi cuốn về mặt thẩm mỹ của một cách bố trí màn hình…
− Các kiểm thử liên quan đến tương tác vật lý. Chẳng hạn, nhận dạng một thẻ
thông qua đầu đọc thẻ, ngắt kết nối một số thiết bị, bật tắt nguồn điện.
Không phải tất cả các kiểm thử thủ công đều nên được tự động hóa – chỉ những
kiểm thử sẽ được chạy lại thường xuyên. Chiến lược kiểm thử tốt cũng sẽ bao gồm
một số kiểm thử bên hay kiểm thử thăm dò, cái được thực hiện tốt bằng thủ công, ít
nhất ở lần đầu tiên. Khi phần mềm không ổn định, việc kiểm thử bằng tay sẽ tìm được
lỗi nhanh hơn.
Kiểm thử thủ công có khả năng phát hiện lỗi tốt hơn kiểm thử tự động
Một kiểm thử hầu hết có thể tìm thấy một lỗi ở lần chạy đầu tiên. Nếu một ca
kiểm thử được tạo để thực hiện tự động hóa, đầu tiên nó phải được kiểm tra đề đảm
bảo chắc chắn nó là chính xác. Việc kiểm tra ca kiểm thử thường được làm bằng bằng
việc chạy ca kiểm thử thủ công. Nếu phần mềm đang được kiểm thử có lỗi mà ca kiểm
thử có thể phát hiện ra, nó sẽ được phát hiện ở lần đầu tiên, khi thực hiện bằng thủ
công.
Sau khi bộ kiểm thử tự động đã được xây dựng, nó được sử dụng để chạy lại các
thử nghiệm. Theo định nghĩa, các thử nghiệm này đã được chạy trước đó, và do vậy,
chúng ít có khả năng tìm thấy lỗi thời điểm này. Các công cụ thực thi kiểm thử không
phải là công cụ „kiểm thử‟, mà chúng là công cụ „chạy lại kiểm thử‟ hay còn gọi là
công cụ kiểm thử hồi quy.
Tự động hóa kiểm thử không cải thiện nhiều về tính hiệu quả
Việc tự động hóa một tập các kiểm thử không làm cho chúng hiệu quả hơn so với
cùng tập kiểm thử đó được thực hiện bằng tay. Cuối cùng tự động hóa có thể cải thiện
25

tính hiệu quả của các kiểm thử. Tuy nhiên dường như tự động hóa sẽ ảnh hưởng bất lợi
đến khả năng cải thiện của kiểm thử.
Tự động hóa kiểm thử có thể làm hạn chế sự phát triển phần mềm
Kiểm thử tự động là “mỏng manh” hơn kiểm thử bằng tay. Chúng có thể bị phá
vỡ bởi những thay đổi dường như vô hại tới phần mềm.

Bởi vì cài đặt và duy trì kiểm thử tự động tốn kém hơn nhiều so với kiểm thử
bằng tay. Điều này làm cho bản thân nó có thể hạn chế các tùy chọn thay đổi và nâng
cấp hệ thống phần mềm hoặc các ứng dụng.
Các công cụ không có trí tưởng tượng
Một công cụ chỉ là một phần mềm, và vì thế chúng chỉ làm theo hướng dẫn. Cả
công cụ và kỹ sư kiểm thử có thể làm theo hướng dẫn để thực hiện một tập các ca
kiểm thử nhưng nếu là kỹ sư kiểm thử với cùng công việc sẽ thực hiện một cách khác
biệt. Chẳng hạn, nếu là một kỹ sư kiểm thử được giao nhiệm vụ chạy một thủ tục kiểm
thử đã được chuẩn bị, họ có thể theo thủ tục đó để bắt đầu với và sẽ kiểm tra được rằng
kết quả thực tế là chính xác. Tuy nhiên, với kỹ sư kiểm thử họ có thể nhận ra được
rằng, mặc dù phần mềm phù hợp với kết quả mong đợi nhưng có thể cả hai đều sai.