thiết kế và xây dựng quy trình kiểm thử tự động

1
MỤC LỤC
MỞ ĐẦU…………… 2
CHƯƠNG 1. TỔNG QUAN VỀ KIỂM THỬ VÀ KIỂM THỬ TỰ ĐỘNG 5
1.1 Chất lượng phần mềm và kiểm thử phần mềm 5
1.1.1 Vòng đời phát triển phần mềm và kiểm thử 5
1.1.2 Kiểm thử phần mềm và chất lượng phần mềm 8
1.1.3 Các giai đoạn kiểm thử và điểm xác định 9
1.1.4 Các kỹ thuật kiểm thử phần mềm 10
1.2 Kiểm thử tự động 10
1.2.1 Khái niệm về kiểm thử tự động: 10
1.2.2 Mục tiêu 10
CHƯƠNG 2. MỘT SỐ QUY TRÌNH KIỂM THỬ TỰ ĐỘNG 13
2.1 Quy trình kiểm thử phần mềm 13
2.2 Khái quát về quy trình kiểm thử tự động 20
2.3 Các bước cơ bản của quá trình KTTĐ: 22
CHƯƠNG 3. CÔNG CỤ KIỂM THỬ TỰ ĐỘNG 24
3.1 Tổng quan về công cụ kiểm thử tự động 24
3.1.1 Công cụ kiểm thử tự động mã trình 24
3.1.2 Công cụ kiểm thử tự động dữ liệu 24
3.1.3 Công cụ kiểm thử tự động cài đặt 25
3.2 Giới thiệu và đánh giá một số công cụ KTTĐ 25
3.2.1 QuickTest Pro 26
3.2.2 Load Runner 30
KẾT LUẬN ……………………………. 32
TÀI LIỆU THAM KHẢO 33


2
MỞ ĐẦU

1. Lý do chọn đề tài
Với sự phát triển như vũ bão của công nghệ thông tin nói chung và công
nghệ phần mềm nói riêng, việc phát triển phần mềm ngày càng được hỗ trợ bởi
nhiều công cụ tiên tiến, giúp cho việc xây dựng phần mềm đỡ vất vả và hiệu quả
hơn. Tuy nhiên, vì độ phức tạp của phần mềm và những giới hạn về thời gian và chi
phí, cho dù các hoạt động đảm bảo chất lượng phần mềm nói chung và kiểm thử nói
riêng ngày càng chặt chẽ và khoa học, vẫn không đảm bảo được rằng các sản phẩm
phần mềm đang được ứng dụng không có lỗi. Lỗi vẫn luôn tiềm ẩn trong mọi sản
phẩm phần mềm và cũng có thể gây những thiệt hại khôn lường.
Kiểm thử phần mềm là một quá trình liên tục, xuyên suốt mọi giai đoạn phát
triển phần mềm để đảm bảo rằng phần mềm thoả mãn các yêu cầu thiết kế và các
yêu cầu đó đáp ứng các nhu cầu của người dùng. Các kỹ thuật kiểm thử phần mềm
đã, đang được nghiên cứu, và việc kiểm thử phần mềm đã trở thành qui trình bắt
buộc trong các dự án phát triển phần mềm trên thế giới. Kiểm thử phần mềm là một
hoạt động rất tốn kém, mất thời gian, và khó phát hiện được hết lỗi. Vì vậy, việc
kiểm thử phần mềm đòi hỏi phải có chiến lược phù hợp, một kế hoạch hợp lý và
việc thực hiện được quản lí chặt chẽ.
Kiểm thử tự động là một lĩnh vực nhằm thu hút được lợi ích tối đa với nỗ lực
tối thiểu đối với các công việc lặp đi lặp lại. Lợi ích tối đa ở đây chính là khả năng
gia tăng hiệu quả các nguồn nhân lực, gia tăng độ bao phủ của việc kiểm thử, nâng
cao chất lượng và độ tin cậy của phần mềm. Với những quy trình phần mềm hiện
đại, thời gian sản xuất phần mềm ngày càng ngắn, trong khi chi phí về nhân lực
cũng như kinh tế ngày càng thấp đòi hỏi việc tự động hóa trong quá trình sản xuất
phần mềm. Kiểm thử tự động trở thành một yêu cầu bức xúc với các công ty sản
xuất phần mềm hiện nay. Chính vì lý do đó, tôi mong muốn tìm hiểu về “Kiểm thử
tự động” nhằm đưa ra những cái nhìn khái quát về loại hình kiểm thử này.
2. Tình hình nghiên cứu
Trong quy trình công nghệ phần mềm, kiểm thử chiếm khoảng 40% khối
lượng công việc và là khâu quyết định chất lượng cũng như uy tín của phần mềm,
tuy nhiên kiểm thử phần mềm chưa được coi trọng trong các nền công nghiệp phần

mềm nhỏ, chẳng hạn như Việt Nam. Việc áp dụng các kỹ thuật kiểm thử còn mang
tính cục bộ ở các công ty phần mềm và quá trình kiểm thử hầu như được thực hiện
một cách thủ công gây ra hạn chế trong việc phát hiện lỗi, cũng như thời gian hoàn
thành dự án; Kiểm thử tự động đang trở thành xu thế của ngành công nghiệp phần

3
mềm, do vậy việc nghiên cứu lý thuyết, quy trình cũng như tìm hiểu, đánh giá các
công cụ kiểm thử tự động đang là một đòi hỏi bức thiết. Trong phạm vi đề tài của
mình, tôi mong muốn đưa ra cái nhìn tổng quan về kiểm thử tự động, quy trình thực
hiện và việc lựa chọn sử dụng công cụ kiểm thử tự động phù hợp.
3. Mục đích nghiên cứu
Nghiên cứu về kiểm thử, đặc biệt là vấn đề kiểm thử tự động (KTTĐ) nhằm
tìm hiểu những lý thuyết cơ bản về KTTĐ, quy trình KTTĐ và nghiên cứu đánh giá
một số công cụ KTTĐ đang được sử dụng hiện nay.
Trau dồi kiến thức về kiểm thử, đặc biệt là xu hướng kiểm thử phần mềm
hiên nay nhằm phục vụ cho việc giảng dạy học phần “Nhập môn Công nghệ phần
mềm”
4. Đối tượng nghiên cứu
 Lý thuyết kiểm thử và đánh giá chất lượng phần mềm, vai trò, nhiệm vụ của
giai đoạn kiểm thử trong một số quy trình phần mềm
 Kiểm thử tự động và quy trình kiểm thử tự động
 Một số công cụ kiểm thử tự động.
5. Phạm vi nghiên cứu
 Lý thuyết cơ bản về quy trình phần mềm, kiểm thử và vai trò của kiểm thử
trong quy trình phần mềm
 Kiểm thử tự động, quy trình kiểm thử tự động.
 Nghiên cứu, thực nghiệm và đánh giá một số công cụ kiểm thử tự động.
6. Phương pháp nghiên cứu
Trong quá trình thực hiện đề tài tôi đã sử dụng những phương pháp nghiên
cứu sau:

 Phương pháp tư liệu: Thu thập và phân tích các tài liệu liên quan đến quy
trình phần mềm, kiểm thử và KTTĐ.
 Phương pháp thực nghiệm: Tìm hiểu QTP, cài đặt và đánh giá phần mềm
7. Đóng góp của đề tài
Tổng hợp lý thuyết liên quan đến kiểm thử, kiểm thử tự động; Tìm hiểu quy
trình kiểm thử tự động khi áp dụng vào dự án phần mềm. Nghiên cứu và đánh giá
một số công cụ kiểm thử tự động.
8. Bố cục
Đề tài gồm 3 chương

4
Chương 1. Tìm hiểu lý thuyết chung về kiểm thử, đưa ra 1 số quy trình phần
mềm phổ biến để đánh giá vai trò của kiểm thử, tính cần thiết của kiểm thử tự động
Chương 2. Đưa ra những kiến thứ cơ bản về quy trình kiểm thử tự động
Chương 3. Nghiên cứu, phân loại và đánh giá một số công cụ kiểm thử tự
động
Kết luận


5
CHƯƠNG 1. TỔNG QUAN VỀ KIỂM THỬ VÀ KIỂM THỬ TỰ ĐỘNG
1.1 Chất lượng phần mềm và kiểm thử phần mềm
1.1.1 Vòng đời phát triển phần mềm và kiểm thử.
1.1.1.1 Mô hình thác nước
Một mô hình phát triển phần mềm tuần tự. Chuyển đổi giữa các giai
đoạn được thực hiện bằng một đánh giá chính thức. Đánh giá là một điểm kiểm tra
để xác nhận là bạn có đi đúng hướng hay không. Trong mô hình này việc kiểm thử
phần mềm được bắt đầu sau giai đoạn mã hóa phần mềm.

Hình 1. Mô hình thác nước

1.1.1.2 Phương pháp Agile
Đặc điểm của mô hình Agile:
 Cá nhân và các tương tác quan trọng hơn quy trình và công cụ.
 Tập trung làm cho phần mềm chạy được thay vì viết tài liệu.
 Cộng tác trực tiếp với khách hàng thay vì dựa trên hợp đồng.
 Phản ứng với các thay đổi thay vì tuân theo một kế hoạch định sẵn.
 Dự án thực hiện với mô hình Agile thường có rất nhiều test unit được thực
hiện bởi các người phát triển (developer).
Các dự án có đặc điểm sau đây có thể phù hợp với Agile:
 Mức độ rủi ro thấp.
 Thành viên nhóm có kinh nghiệm.
 Yêu cầu thay đổi thường xuyên.
 Kích thước nhóm nhỏ. Các thành viên làm việc cùng một địa điểm.
 Văn hóa công ty ưa thích sự “không trật tự” (thrive on chaos).

6

Hình 2. Mô hình Alige
1.1.1.3 Sản phẩm phần mềm và vấn đề lỗi phần mềm
Quá trình sản xuất 1 phần mềm dù sử dụng quy trình nào thì cũng bao gồm nhiều
giai đoạn chứ không đơn giãn chỉ là viết code chương trình, vì vậy, việc mắc lỗi
không chỉ xảy ra trong khi lập trình mà còn xảy ra cao hơn trong các công đoạn
khác của qui trình phát triển một sản phẩm phần mềm. Việc kiểm thử cũng vì thế
phải được tiến hành trong tất cả các phần tạo nên một sản phẩm phần mềm.

7

Hình 3. Sản phẩm phần mềm
Khi phần mềm thực thi không đúng với đặc tả thì ta nói phần mềm xuất hiện
lỗi. Lỗi phần mềm được chia thành các dạng :

 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 đưa vào đặc tả nhưng lại không có trong sản
phẩm phần mềm đã 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ả hoặc
yêu cầu khác với đặc tả.
Ngoài ra lỗi phần mềm có thể do tính khó hiểu, khó sử dụng, chậm hoặc giao
diện không phù hợp với đối tượng sử dụng…
Nguyên nhân xuất hiện lỗi phần mềm cũng rất đa dạng, khác với sự cảm
nhận thông thường, lỗi xuất hiện nhiều nhất không phải do lập trình. Nhiều nghiên
cứu đã được thực hiện trong các dự án từ rất nhỏ đến các dự án rất lớn và kết quả
luôn giống nhau. Số lỗi do đặc tả gây ra là nhiều nhất, chiếm khoảng 80%. Có một
số nguyên nhân làm cho đặc tả tạo ra nhiều lỗi nhất. Trong nhiều trường hợp, đặc tả
không được viết ra. Các nguyên nhân khác có thể do đặc tả không đủ cẩn thận, nó
hay thay đổi, hoặc do chưa phối hợp tốt trong toàn nhóm phát triển. Sự thay đổi yêu
cầu của khách hàng cũng là nguyên nhân dễ gây ra lỗi phần mềm. Khách hàng thay
đổi yêu cầu không cần quan tâm đến những tác động sau khi thay đổi yêu cầu như
phải thiết kế lại, lập lại kế hoạch, làm lại những việc đã hoàn thành. Nếu có nhiều

8
sự thay đổi, rất khó nhận biết hết được phần nào của dự án phụ thuộc và phần nào
không phụ thuộc vào sự thay đổi. Nếu không giữ được vết thay đổi rất dễ phát sinh
ra lỗi.
Nguồn gây ra lỗi lớn thứ hai là thiết kế. Ðó là nền tảng mà lập trình viên dựa
vào dể nỗ lực thực hiện kế hoạch cho phần mềm.
Lỗi do lập trình gây ra cũng khá dễ hiểu. Ai cũng có thể mắc lỗi khi lập trình,
nhất là trong thời kỳ đầu. Ngày nay, công việc lập trình với sự hỗ trợ của nhiều
công cụ cao cấp, việc lập trình trở nên nhẹ nhàng hơn, mặc dù độ phức tạp phần
mềm lớn hơn rất nhiều. Do đó, lỗi do lập trình gây ra cũng ít hơn. Tuy nhiên,
nguyên nhân để lập trình tạo ra lỗi lại nhiều hơn. Đó là do độ phức tạp của phần
mềm, do tài liệu nghèo nàn, do sức ép thời gian hoặc chỉ đơn giản là những lỗi

“không nói lên được”. Một điều cũng hiển nhiên là nhiều lỗi xuất hiện trên bề mặt
lập trình nhưng thực ra lại do lỗi của đặc tả hoặc thiết kế. Một nguyên nhân khác tạo
ra lỗi là do bản thân các công cụ phát triển phần mềm cũng có lỗi như công cụ trực
quan, thư viện lớp, bộ biên dịch,…
Khi phần mềm có lỗi chi phí để sửa lỗi phụ thuộc vào thời điểm phát hiện
lỗi, lỗi phát hiện càng muộn thì chi phí càng cao.
1.1.2 Kiểm thử phần mềm và chất lượng phần mềm
1.1.2.1 Kiểm thử phần mềm
Kiểm thử phần mềm thường đồng nghĩa với việc tìm ra lỗi chưa được phát
hiện. Tuy nhiên, có nhiều bối cảnh kiểm thử không bộc lộ ra lỗi. 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.
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í.
1.1.2.2 Chất lượng phần mềm
Chất lượng phần mềm là một khái niệm đa chiều, không dễ định nghĩa đơn
giản theo cách chung cho các sản phẩm là: “Sản phẩm được phát triển phù hợp với
đặc tả của nó.” [8]. Có một số vấn đề khó trong hệ thống phần mềm, đó là:

9
 Đặc tả phải định hướng theo những đòi hỏi về chất lượng của khách
hàng(như tính hiệu quả, độ tin cậy, tính dễ hiểu, tính bảo mật,…) và những
yêu cầu của chính tổ chức phát triển phần mềm vốn không có trong đặc t(như
các yêu cầu về khả năng bảo trì, tính sử dụng lại, )
 Một số yêu cầu về chất lượng cũng rất khó chỉ ra một cách rõ ràng.
 Những đặc tả phần mềm thuờng không đầy đủ và hay mâu thuẫn.

Hình 4. Ngữ cảnh kiểm thử phần mềm
Trên quan điểm qui trình, kiểm thử phần mềm là một phần của xác minh và
thẩm định phần mềm. Xác minh và thẩm định nằm trong công nghệ phần mềm,
công nghệ phần mềm lại là một phần của công nghệ hệ thống (Hình4a). Nhìn từngữ
cảnh chất lượng (Hình 4b), kiểm thử phần mềm cũng là một phần của xác minh và
thẩm định phần mềm, nên cũng có thể xem như là một phần của đảm bảo chất
lượng phần mềm. Nếu phần mềm là thành phần của hệ thống lớn hơn thì kiểm thử
phần mềm cũng được xem như là một phần của quản lý và đảm bảo chất lượng.
Và để đạt phần mềm chất lượng cao, thì kiểm thử có thể coi là một thành
phần chủ yếu của hoạt động đảm bảo chất lượng phần mềm.
1.1.3 Các giai đoạn kiểm thử và điểm xác định
Test
phrase
Pre- Alpha
Alpha
Beta
GM/Release
Unit (Đơn vị)

Intergration
(Tích hợp)
System
(Hệ thống)
Acceptance
(Chấp nhận)
Thực
hiện
Developer
Developer /

Technical
Tester
Tester
User
Định
nghĩa
Kiểm thử một
đơn vị code
trong một thời
gian
Lặp đi lặp lại
một hệ thống
hoàn chỉnh.
kiểm tra các
đơn vị code
Là mức độ kiểm
thử toàn bộ chức
năng hệ thống.
Kiểm tra như sản
phẩm được đưa ra
Đánh giá phần mềm
có đáp ứng được các
yêu cầu của người
dùng đã đề ra hay
không? Có thể triển

10
 Giai đoạn phát triển: là một khối thời gian trong vòng đời của việc phát
triển phần mềm với một số các hoạt động phải làm trong khối thời gian này.
 Mốc phát triển: Đánh dấu một sự kiện trong tiến trình phát triển phần mềm,

khi phần mềm di chuyển từ giai đoạn này qua giai đoạn khác
1.1.4 Các kỹ thuật kiểm thử phần mềm
Để tăng hiệu quả của quá tình kiểm thử cần sử dụng các kỹ thuật kiểm thử
như những công cụ được thiết kế để đảm bảo rằng tất cả các khía cạnh của sản
phẩm đều được khảo sát. Mặt khác, các kỹ thuật kiểm thử là những công cụ để dễ
dàng đạt được hiệu quả kiểm thử. Các kỹ thuật kiểm thử thường được chia thành hai
loại: các kỹ thuật kiểm thử hộp đen (black-box testing) và kỹ thuật kiểm thử hộp
trắng (white-box testing).
Kiểm thử black-box. Các kiểm thử black-box tìm các lỗi như thiếu các chức
năng, khả năng sử dụng và các yêu cầu phi chức năng.
Các kỹ thuật kiểm thử white-box yêu cầu hiểu biết về cấu trúc chương trình
bên trong và các kiểm thử nhận được từ đặc tả thiết kế bên trong hoặc từ mã.
1.2 Kiểm thử tự động
1.2.1 Khái niệm về kiểm thử tự động:
Kiểm thử tự động (KTTĐ) là việc sử dụng các phần mềm để kiểm soát việc
thực hiện các thử nghiệm, so sánh kết quả thực tế kết quả dự đoán, thiết lập các điều
kiện tiên quyết cho các thử nghiệm, và các chức năng kiểm cũng như báo cáo kết
quả thử nghiệm. Thông thường, KTTĐ bao hàm việc việc tự động hoá một quy
trình làm việc bằng tay đã được sử dụng như một quá trình kiểm thử chính thức.
1.2.2 Mục tiêu
Mục tiêu của KTTĐ là làm 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
khi nó làm
việc chung môi
trường với
nhau.
sử dụng.
khai cho công việc
thực tế hay không
Kết quả

Ít lỗi
Tìm lỗi
Tìm lỗi/QC
QC
Mục
đích
Xác nhận giá
trị các modun
độc lập
Tìm lỗi và biết
về sản phẩm,
xác nhận giá
trị các yêu cầu
tích hợp
Tìm lỗi, xác
nhận giá tri hệ
thống, luồng dữ
liệu…
Xác nhận các yêu
cầu của người sử
dụng.

11
đượ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 tốc độ làm việc và hiệu quả của quá trình kiểm thử, đạt được
các tiêu chí kiểm thử, giải phóng cho các kỹ sư kiểm thử phần mềm thoát khỏi việc
thực hiện kiểm thử cách tẻ nhạt và lặp lại nhàm chán.
Để đạt được những mục tiêu đó, quy trình KTTĐ đặt ra nhiều yêu cầu thiết
yếu. Việc phải thành lập một đội ngũ kỹ sư chuyên dụng cho KTTĐ với một kế

hoạch và chiến lược rõ ràng, các kỹ sư phải giỏi kĩ năng lập trình. Các công cụ kiểm
thử phải phù hợp với chiến lược đặt ra, phù hợp với ngân sách dành riêng cho
KTTĐ và tiến độ của dự án. Việc bảo trì các ca kiểm thử cũng là một yêu cầu thiết
yếu của KTTĐ. Việc kiểm thử phải được thực thi nhiều lần, do đó yêu cầu phải có
một quy trình phát triển cụ thể, song song đó, nên có quy trình kiểm thử tại chỗ –
chủ yếu là thủ công. Cuối cùng, cần phải xem xét đến các chi phí liên quan đên chi
phí của công cụ kiểm thử và chi phí đào tạo nếu có.
Để KTTĐ thì cần sử dụng các test tool, nhưng không phải trong mọi trường
hợp đều có thể sử dụng Test tool thay cho việc kiểm thử thủ công. KTTĐ được xem
xét trong một số trường hợp sau đây:
 Không đủ tài nguyên: Khi số lượng Test Case quá nhiều mà KTV không thể
hoàn tất trong thời gian cụ thể.
Ví dụ: Khi kiểm thưr chức năng của 1 website với 6 môi trường gồm 3 trình
duyệt và 2 hệ điều hành. Tình huống này đòi hỏi số lần kiểm tra tăng lên và lặp lại 6
lần so với việc kiểm tra cho một môi trường cụ thể.
 Kiểm tra hồi quy: 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 tra. Thực tế cho thấy
việc đưa ra các phiên bản phần 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 tra tốt chạy sai mặc dù phần code của nó không hề chỉnh sửa. Để
khắc phục điều này, đối với từng phiên bản, tester không chỉ kiểm tra chức năng
mới hoặc được sửa, mà phải kiểm tra lại tất cả những tính năng đã kiểm tra tốt trước
đó. Điều này khó khả thi về mặt thời gian nếu kiểm tra thủ công.
 Kiểm tra khả năng vận hành phần mềm trong môi trường đặc biệt: Đây là
kiểm tra nhằm đánh giá xem vận hành của PM có thỏa mãn yêu cầu đặt ra hay
không. Thông qua đó KTV có thể xác định được các yếu tố về phần cứng, phần

12
mềm ảnh hưởng đến khả năng vận hành của PM. Có thể liệt kê một số tình huống

kiểm tra 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 PM vẫn có thể hoạt động ở
mức cho phép
+ Xác định cấu hình máy thấp nhất mà PM vẫn có thể hoạt động tốt
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".
Ngoài ra, một số trường hợp sử dụng KTTĐ nhằm mục đích kiểm tra, phát
hiện những lỗi của PM trong những trường hợp đoán trước. Điều này cũng có nghĩa
là nó thường được thực hiện sau khi đã thiết kế xong các ca kiểm thử (test case).
Tuy nhiên, như đã nói, không phải mọi trường hợp kiểm tra đều có thể hoặc cần
thiết phải tự động hóa, trong tất cả test case thì tester phải đánh giá và chọn ra
những test case nào phù hợp hoặc cần thiết để áp dụng KTTĐ dựa trên những tiêu
chí đã đề cập bên trên.


13
CHƯƠNG 2. MỘT SỐ QUY TRÌNH KIỂM THỬ TỰ ĐỘNG
Ngày nay, các chuyên gia phần mềm đang phải đối mặt với những thách thức
về việc xây dựng các hệ thống với ít nhân lực, tài nguyên trong một khoảng thời
gian ngày càng bị thu hẹp. Các công ty không chỉ muốn kiểm thử phần mềm một
cách đầy đủ, mà còn đòi hỏi việc kiểm thử phải đưa lại kết quả chính xác.
2.1 Quy trình kiểm thử phần mềm
Mục đích của kiểm thử phần mềm là đánh giá chất lượng của công việc được
thực hiện ở từng bước của qui trình phát triển phần mềm. Người quản lí kiểm thử
phải lập kế hoạch kiểm thử lúc bắt đầu của dự án đồng thời với lúc người quản lí dự
án lập kế hoạch cho các hoạt động dự án. Bản kế hoạch kiểm thử nên bao gồm các

thủ tục kiểm thử, trường hợp kiểm thử, thông tin lỗi, lịch biểu kiểm thử, và dữ liệu
hiệu năng được dùng cho kiểm thử phần mềm. Người kiểm thử không nên chờ đợi
kiểm thử mọi thứ ở lúc cuối của nỗ lực phát triển, sau khi viết mã đã được thực
hiện. Họ phải làm việc với người phát triển qua qui trình phát triển để đảm bảo rằng
phần mềm được phát triển như dự định, và để cải tiến chất lượng, tính tin cậy và
tính bảo trì phần mềm.
Việc kiểm thử phần mềm thường bắt đầu ở mức cấu phần (kiểm thử đơn vị,
kiểm thử chức năng) rồi đi lên tới sản phẩm phần mềm (kiểm thử tích hợp, kiểm thử
rà lại, kiểm thử hệ thống, kiểm thử chấp nhận v.v). Trong dự án nhỏ, những người
phát triển thường làm cả việc viết mã và kiểm thử. Trong dự án lớn hơn, nên có
nhóm kiểm thử độc lập làm kiểm thử để tránh thiên lệch của người phát triển khi
làm kiểm thử công việc riêng của họ. Điều này không có nghĩa là người phát triển
không kiểm thử và người kiểm thử phải làm mọi kiểm thử. Về căn bản, cả người
phát triển và người kiểm thử đều phải làm việc cùng nhau trong toàn dự án để đảm
bảo rằng mọi kiểm thử được tiến hành đúng. Người phát triển phải kiểm thử mã
riêng của họ để loại bỏ các lỗi, đảm bảo thực hiện đúng, và luồng thông tin cũng
như kiểm tra dữ liệu để đảm bảo rằng tính toàn vẹn được bảo trì. (như kiểm thử mô
đun, kiểm thử đơn vị) trước khi người kiểm thử bắt đầu các hoạt động kiểm thử của
họ.
Người kiểm thử thường bắt đầu bằng “kiểm thử chức năng” để làm lộ ra các
lỗi chức năng trong phần mềm rồi tiến hành "kiểm thử tích hợp" để đảm bảo mọi
chức năng làm việc đúng và luồng thực hiện đang xảy ra như dự định. Người kiểm
thử phải tiến hành "kiểm thử nội dung thông tin" để kiểm lỗi trong cấu trúc dữ liệu
cục bộ hay toàn cục. Họ phải kiểm thử "tính toàn vẹn giao diện" để chắc cả giao
diện trong và ngoài làm việc đúng, đặc biệt khi mô đun mới được thêm vào cho

14
phần mềm. Khi thay đổi xảy ra, họ phải tiến hành "kiểm thử rà lại" để kiểm các lỗi
có thể lan truyền từ mô đun nọ sang mô đun kia và đảm bảo toàn bộ sản phẩm phần
mềm làm việc được.

Hình 5. Quy trình kiểm thử phần mềm
Sau khi thẩm tra rằng sản phẩm phần mềm làm việc đúng, người kiểm thử có
thể tiến hành "kiểm thử hệ thống" để chắc cả phần cứng và phần mềm đều làm việc
như đã lập kế hoạch. Trong kiểm thử này, người kiểm thử sẽ cho chạy "kiểm thử an
ninh" để thẩm tra bảo vệ hệ thống chạy đúng để ngăn cản việc thâm nhập không
đúng hay thay đổi dữ liệu. Họ tiến hành "kiểm thử chịu căng thẳng" để kiểm tra
xem nó giải quyết tốt đến đâu với nhưng yêu cầu tài nguyên bất thường (như, chất
lượng, tần xuất, hay khối lượng) và "kiểm thử hiệu năng" để kiểm tra hiệu năng khi
chạy của phần mềm, đặc biệt phần mềm thời gian thực. Họ có thể tiến hành "kiểm
thử phục hồi" để kiểm tra khả năng của hệ thống phục hồi từ hỏng hóc.
Nếu mọi kiểm thử trong "kiểm thử hệ thống" đều qua được, người kiểm thử
có thể làm việc cùng khách hàng để chuẩn bị cho "kiểm thử chấp nhận" nơi họ đảm
bảo phần mềm làm việc đúng với người dùng được dự định trong môi trường làm
việc của họ. Hai kiểm thử chính trong thời gian này: “kiểm thử Alpha” là thời kì
kiểm thử mà sản phẩm phần mềm sẵn sàng được dùng trong "môi trường kiểm thử"
của khách hàng nhưng có thể có một số lỗi nhỏ. Nó là cơ hội cuối cùng để được trắc
nghiệm từ khách hàng rằng phần mềm làm việc như được dự định. “Kiểm thử Beta"
là thời kì kiểm thử trong đó sản phẩm phần mềm là đầy đủ không có lỗi và dùng
được trong môi trường "sản xuất". Mục đích của kiểm thử Beta là kiểm thử khả

15
năng của công ti hỗ trợ cho sản phẩm. Kiểm thử Beta phục vụ như bằng chứng rằng
sản phẩm phần mềm là sẵn sàng cho việc gửi đi cho mọi khách hàng.
Mục đích của kiểm thử là thiết kế một chuỗi các trường hợp kiểm thử mà có
khả năng phát hiện lỗi cao. Để cho việc kiểm thử đạt được kết quả tốt cần có sự
chuẩn bị về kế hoạch kiểm thử, thiết kế các trường hợp kiểm thử và các dữ liệu
kiểm thử cho các trường hợp. Đây chính là đầu vào cho giai đoạn kiểm thử; kết quả
của giai đoạn kiểm thử là “báo cáo kiểm thử” mô tả tất cả các trường hợp kiểm thử
đã chạy, dữ liệu đầu vào, đầu ra mong đợi, đầu ra thực tế và mục đích của kiểm

thử,… (như Hình 5)

Hình 6. Quy trình kiểm thử phầm mềm
Qui trình kiểm thử bao gồm một số giai đoạn:
 Lập kế hoạch kiểm thử. Bước đầu tiên là lập kế hoạch cho tất cả các hoạt
động sẽ được thực hiện và các phương pháp được sử dụng. Các chuẩn IEEE bao
gồm các thông tin về tác giả chuẩn bị kế hoạch, danh sách liệt kê của kế hoạch kiểm
thử. Vấn đề quan trọng nhất đối với kế hoạch kiểm thử [6,7]:
+ Mục đích: Qui định về phạm vi, phương pháp, tài nguyên và lịch biểu
của các hoạt động kiểm thử.
+ Các tài liệu tham khảo.
+ Các định nghĩa.
+ Khái quát về xác minh và thẩm định (V&V): tổ chức, tài nguyên,
trách nhiệm, các công cụ, kỹ thuật và các phương pháp luận.
+ Vòng đời của V&V: các nhiệm vụ, các dữ liệu vào và các kết quả ra
trên một giai đoạn vòng đời.
+ Báo cáo xác minh và thẩm định(V&V) phần mềm: mô tả nội dung,
định dạng và thời gian cho tất cả các báo cáo V&V.
+ Các thủ tục quản lý V&V bao gồm các chính sách, thủ tục, các chuẩn,
thực nghiệm và các qui ước.
 Giai đoạn bố trí nhân viên kiểm thử: Việc kiểm thử thuờng phải tiến hành
một cách độc lập và các nhóm độc lập có trách nhiệm tiến hành các họat động kiểm
thử, gọi là các nhóm kiểm thử.

16
 Thiết kế các truờng hợp kiểm thử: Các truờng hợp kiểm thử là các đặc tả đầu
vào cho kiểm thử và đầu ra mong đợi của hệ thống cùng với các câu lệnh đuợc kiểm
thử.
+ Các phương pháp hộp đen để kiểm thử dựa trên chức năng
+ Các phương pháp hộp trắng để kiểm thử dựa vào cấu trúc bên trong.

 Xử lý do luờng kiểm thử bằng cách thu thập dữ liệu.
 Ðánh giá sản phẩm phần mềm để xác nhận sản phẩm có thể sẵn sàng phát
hành được chưa?
Mô hình chung của qui trình kiểm thử phần mềm được thể hiện trong hình 6.

Hình 7. Quy trình kiểm thử phần mềm
Các pha được cụ thể hóa theo bảng sau:


17
Các bước
Đầu vào
Mô tả
Công việc
Kết quả
Người thực hiện
Lập kế
hoạch kiểm
tra
- Kế hoạch dự
án
- Tài liệu SRD,
SRS, HLD.
- Các tài liệu
mô tả nghiệp vụ
- Nhóm dự án sẽ cung cấp các tài
liệu có liên quan cho nhóm PQA
- Nhóm PQA nghiên cứu các yêu
cầu, thời gian và nội dung các yêu
cầu nhận được để quyết định các

bước tiếp theo.
- Nhóm PQA chuẩn bị nhân lực và
đào tạo nhân lực cần thiết phục vụ
cho nhu cầu của dự án.
- Tiếp nhận yêu cầu kiểm tra.
- Tham gia quá trình phân tích và
xác định yêu cầu.
- Tiếp nhận tài liệu.
- Lập kế hoạch kiểm tra.
- Trình phê duyệt kế hoạch kiểm
tra.
- Phổ biến kế hoạch kiểm tra đã
được phê duyệt.
- Phổ biến kế hoạch kiểm tra đã
được phê duyệt.
- Kế hoạch kiểm
tra đã được phê
duyệt.
- Cán bộ PQA.
- Trưởng nhóm
PQA.
- Giám đốc dự án.
Chuẩn bị
môi trường
kiểm tra
- Kế hoạch
kiểm tra.
- Tài liệu SRD,
SRS, HLD.
- Tài liệu

nghiệp vụ.
- Cán bộ kiểm tra có trách nhiệm
hỗ trợ với bên kỹ thuật để chuẩn bị
môi trường thực tế hay giả lập cho
dự án trước khi tiến hành kiểm tra.
- Xây dựng các công cụ tạo dữ
liệu, kiểm tra cơ sở dữ liệu.
- Tạo dữ liệu kiểm tra hệ thống
cho chương trình
- Xây dựng môi trường phần cứng
- Xây dựng môi trường phần mềm
- Môi trường
kiểm tra đã sẵn
sàng.
- Cán bộ PQA.
- Trưởng nhóm
PQA.
Thiết kế
kiểm tra
- Tài liệu
SRD,SRS,
HDL.
- Prototype (nếu
có)
- Đưa ra các tình huống kiểm tra
- Việc lập tình huống kiểm tra do
cán bộ kiểm tra đảm nhiệm, quá
trình lập tình huống sẽ được
trưởng nhóm kiểm tra thường
xuyên xem xét, sửa đổi, cập nhật

nếu cần.
- Phân tích yêu cầu
- Lập tình huống kiểm tra.
- Tình huống
kiểm tra đã được
phê duyệt.
- Cán bộ PQA.
- Trưởng nhóm
PQA.
- Giám đốc dự án.

18
Thực hiện
kiểm tra
- Kế hoạch
kiểm tra
- Tình huống
kiểm tra
- Môi trường
kiểm tra đã sẵn
sàng.
- Đây là giai đoạn quan trọng nhất
trong toàn bộ quy trình kiểm thử
phần mềm.
- Các công việc kiểm tra cần chỉ rõ
phần mềm đã đáp ứng hoặc chưa
đáp ứng yêu cầu nào, có những lỗi
nào.
- Việc thực hiện tình huống kiểm
tra do cán bộ kiểm tra đảm nhiệm,

trong quá trình thực hiện kiểm tra
Trưởng nhóm kiểm tra thường
xuyên xem xét (nếu cần).
- Tạo dữ liệu mô phỏng
- Thực hiện tình huống kiểm tra.
- Ghi nhận lỗi.

- Báo cáo kết
quả kiểm tra
- Tình huống
cập nhật (nếu
có).
- Cán bộ kiểm tra
- Trưởng nhóm
PQA.
- Quản trị dự án
Theo dõi xử
lý lỗi
- Báo cáo kết
quả kiểm tra
- Tình huống
kiểm tra
- Phân tích, tổng hợp các lỗi mới
nhất để gửi tới nhóm phát triển
triển tiến hành sửa đổi cũng như
cập nhật
- Công việc này do Trưởng nhóm
kiểm tra đảm nhiệm kết hợp với
bên phát triển PM.

- Thông báo tình trạng lỗi và yêu
cầu nhóm phát triển khắc phục.
- Theo dõi tiến độ xử lý lỗi.
- Báo cáo kết quả kiểm tra lỗi.
- Có phiên bản
mới nhất sau khi
sửa được lỗi.
- Cập nhật tình
huống kiểm tra
nếu có lỗi mới
phát sinh.
- Cập nhật dữ
liệu mới vào
công cụ kiểm
tra.
- Kết quả xử lý
lỗi phát hiện
- Cán bộ kiểm tra
- Trưởng nhóm
PQA
- Quản trị dự án
- Nhóm phát triển

19
Thống kê
và báo cáo
kết quả
kiểm tra
- Kế hoạch
kiểm tra

- Tình huống
kiểm tra
- Báo cáo ghi
nhận lỗi và xử
lý lỗi
- Nhóm kiểm tra thống kê số lượng
lỗi, các loại lỗi gặp phải, và làm
báo cáo kết quả kiểm tra hệ thống
phần mềm.
- Nhóm PQA có trách nhiệm
chuyển kết quả kiểm tra và các yêu
cầu phát sinh cho Quản trị dự án
để giảm rủi ro phát sinh.
- Chuẩn bị thủ tục phát hành sản
phẩm.
- Thống kê lỗi, lỗi phát sinh
- Báo cáo kết quả kiểm tra hệ
thống phần mềm
- Báo cáo kết
quả kiểm tra hệ
thống phần mềm
- Cán bộ PQA
- Trưởng nhóm
PQA
- Quản trị dự án



Thông báo
phát hành

sản phẩm
- Tài liệu SRS,
SRD
- Kế hoạch
kiểm tra
- Báo cáo kết
quả kiểm tra
phần mềm
- Tình huống
kiểm tra đã cập
nhật.
- Đây là bước cuối cùng của quá
trình kiểm tra nhằm mục đích
thông báo sản phẩm phần mềm
mới đạt yêu cầu và sẵn sàng
chuyển giao cho khách hàng.
- Làm thủ tục thông báo phát hành
- Biên bản thông
báo phát hành
sản phẩm
- Trưởng nhóm
PQA
- Quản trị dự án


20
2.2 Khái quát về quy trình kiểm thử tự động
Khi thực hiện kiểm thử một phần mềm, quy trình kiểm thử đi theo các pha thực
hiện dự án, tuy nhiên không phải mọi bước đều có thể sử dụng kiểm thử tự động; kiểm
thử tư động được lựa chọn để thử hiện một số loại hình kiểm thử, chẳng hạn như khi

kiểm thử nhiều dữ liệu trên 1 hoạt động; kiểm thử phần mềm ở nhiều môi trường khác
nhau; kiểm thử chịu tải…
Quá trình thực hiện kiểm thử thường được thực hiện theo quy trình sau:


Hình 8. Quy trình kiểm thử tự động
Hình trên cho thấy:
 Kiểm thử tự động (KTTĐ) giống như là phát triển một dự án.
 Mối tương quan giữa Kiểm thử tự động với toàn bộ chu trình Kiểm thử phần
mềm.
Kiến trúc của quy trình kiểm thưr tự động được trình bày trong hình 9, Quá
trình KTTĐ sẽ tác động đến hệ thống cần kiểm thử (SUT- System Under Test) bằng
cách lấy dữ liệu từ tập dữ liệu kiểm thử. Sau khi thực hiện việc kiểm thử, kết quả kiểm
thử sẽ được lưu trữ trong kho kết quả.

21

Hình 9. Mô hình kiến trúc của quy trình KTTĐ
Việc kiểm thử thủ công sẽ rất khó để thực hiện hết các ca kiểm thử, đặc biệt với
xu thế hiện nay khi việc thực hiện phần mềm thường làm trong giai đoạn ngắn. Quy
trình KTTĐ tiếp cận theo hướng cấu trúc, mô tả quá trình xử lý để thực hiện các ca
kiểm thử. Theo nghiên cứu của Elfriede Dustin [5] KTTĐ được thực hiện qua 6 giai
đoạn chính như hình 10

22

Hình 10. Các giai đoạn chính của quy trình KTTĐ
2.3 Các bước cơ bản của quá trình KTTĐ:
 Xây dựng yêu cầu: Thu thập các đặc tả yêu cầu hoặc xây dựng Test Case,
lựa chọn những phần cần KTTĐ

 Phân tích, thiết kế: Xây dựng mô hình phát triển KTTĐ
 Phát triển TestScript: Tạo TestScript > Chỉnh sửa TestScript > Chạy
TestScript > Test Report
 Đánh giá kết quả: Thông qua Test Report

23

Hình 11. Các bước thực hiện KTTĐ
Bảng sau mô tả rõ hơn các bước phát triển tiến tới đánh giá:
STT
Bước thực hiện
Mô tả
1
Tạo test script
Giai đoạn này chúng ta sẽ dùng test tool để ghi lại các thao tác lên PM cần
kiểm tra và tự động sinh ra test script.
2
Chỉnh sửa test
script
Chỉnh sửa để test script thực hiện kiểm tra theo đúng yêu cầu đặt ra, cụ thể là
làm theo test case cần thực hiện.
3
Chạy test script để
KTTĐ
Giám sát hoạt động kiểm tra PM của test script.
4
Đánh giá kết quả
Kiểm tra kết quả thông báo sau khi thực hiện KTTĐ. Sau đó bổ sung, chỉnh
sửa những sai sót.

24
CHƯƠNG 3. CÔNG CỤ KIỂM THỬ TỰ ĐỘNG
3.1 Tổng quan về công cụ kiểm thử tự động
Các công cụ KTTĐ được thiết kế đặc biệt gắn với một số môi trường kiểm thử
cụ thể. Chẳng hạn như: công cụ cho ứng dụng Windows, công cụ cho ứng dụng web,
v…v… Nó đóng vai trò điều khiển quy trình kiểm thử tự động, có thể trợ giúp tự động
hoá các tác vụ như cài đặt sản phẩm, tạo ra bộ dữ liệu kiểm thử, tương tác giao diện đồ
họa, phát hiện các vấn đề về đăng nhập, v…v…, mà không nhất thiết phải tự động
trông mô hình end-to-end.
Hiện nay, có rất nhiều công cụ kiểm thử tự động đã có sẵn trên thị trường. Một
số dành cho ứng dụng web, một số dụng cho ứng dụng window, một số để kiểm thử cơ
sở dữ liệu… Việc lựa chọn và sử dụng đúng đắn các công cụ kiểm thử tự động đem lại
lợi ích vô cùng lớn cho các công ty phát triển phần mềm. Các công cụ kiểm thử tự
động được chia theo các nhóm sau:
3.1.1 Công cụ kiểm thử tự động mã trình
 Bộ phân tích tĩnh: Các hệ thống phân tích chương trình này hỗ trợ cho "việc
chứng minh" các lý lẽ tĩnh - những mệnh đề yếu kém về cấu trúc và định dạng của
chương trình.
 Bộ kiểm toán mã: Những bộ lọc chuyên dụng này được dùng để kiểm tra chất
lượng của phần mềm để đảm bảo rằng nó đáp ứng các chuẩn mã hoá tối thiểu.
 Bộ xử lý khai báo: Những hệ thống tiền xử lý/hậu xử lý này được sử dụng để
cho biết liệu những phát biểu do người lập trình nêu, được gọi là các khẳng định, về
hành vi của chương trình có thực sự được đáp ứng trong việc thực hiện chương trình
thực hay không.
3.1.2 Công cụ kiểm thử tự động dữ liệu
 Bộ sinh tệp kiểm thử: Những bộ xử lý này sinh ra, và điền các giá trị đã xác
định, vào các tệp đọc vào điển hình cho chương trình đang được kiểm thử.
 Bộ sinh dữ liệu kiểm thử: Những hệ thống phân tích tự động này hỗ trợ cho
người dùng trong việc chọn dữ liệu kiểm thử làm cho chương trình hành xử theo một

cách đặc biệt.

25
 Bộ xác minh kết quả: Những công cụ này đo mức bao quát kiểm thử bên trong,
thường được diễn tả dưới dạng có liên quan tới cấu trúc điều khiển của sự vật kiểm thử,
và báo cáo về giá trị bao quát cho chuyên gia đảm bảo chất lượng.
3.1.3 Công cụ kiểm thử tự động cài đặt
 Các trợ giúp cho quá trình kiểm thử: Các công cụ này hỗ trợ cho việc xử lý các
phép kiểm thử bằng cách làm gần như không khó khăn để:
+ Thiết lập một chương trình ứng cử viên trong môi trường kiểm thử
+ Nuôi chương trình đó bằng dữ liệu vào
+ Mô phỏng bằng các cuống cho hành vi của các module phụ.
 Bộ so sánh đầu ra. Công cụ này làm cho người ta có thể so sánh một tập cái ra
từ một chương trình này với một tập cái ra khác (đã được lưu giữ trước) để xác định sự
khác biệt giữa chúng.
 Hệ tiến hành ký hiệu: Công cụ này thực hiện việc kiểm thử chương trình bằng
cách dùng cái vào đại số, thay vì giá trị dữ liệu số. Phần mềm được kiểm thử vậy xuất
hiện để kiểm thử các lớp dữ liệu, thay vì chỉ là một trường hợp kiểm thử đặc biệt. Cái
ra là đại số và có thể được so sánh với kết quả trông đợi cũng được xác định dưới dạng
đại số.
 Bộ mô phỏng môi trường. Công cụ này là một hệ thống dựa trên máy tính giúp
người kiểm thử mô hình hoá môi trường bên ngoài của phần mềm thời gian thực và rồi
mô phỏng các điều kiện vận hành thực tại một cách động.
 Bộ phân tích dòng dữ liệu. Công cụ này theo dõi dấu vết luồng dữ liệu đi qua hệ
thống (tương tự về nhiều khía cạnh với bộ phân tích đường đi) và cố gắng tìm ra những
tham khảo dữ liệu không xác định, đặt chỉ số sai và các lỗi khác có liên quan tới dữ
liệu.
Hiện nay việc dùng các công cụ tự động hoá cho kiểm thử phần mềm đang phát
triển, và rất có thể là ứng dụng đó sẽ phát triển nhanh trong thập kỷ tới. Các công cụ
kiểm thử có thể sẽ gây ra những thay đổi lớn trong cách chúng ta kiểm thử phần mềm

và do đó cải tiến độ tin cậy của các hệ thống dựa trên máy tính.
3.2 Giới thiệu và đánh giá một số công cụ KTTĐ
Trong lĩnh vực KTTĐ hiện có khá nhiều Test Tool thương mại nổi tiếng, phổ
biến như QuickTest Professional, WinRunner, Rational Robot, SilkTest, JTest, Trong