Sử dụng selenium để kiểm thử phần mềm quản lý thông tin tuyển dụng cho công ty 2NF software, hà nội

LỜI CẢM ƠN
Để hoàn thành bài đồ án tốt nghiệp này, lời đầu tiên em xin gửi lời biết ơn
chân thành và sâu sắc nhất đến cô giáo TS.Trần Thị Ngân đã tận tình hướng dẫn,
truyền đạt những kinh nghiệm quý giá cho em trong suốt quá trình nghiên cứu và
thực hiện đề tài.
Em xin gửi lời cảm ơn đến các thầy cô giáo trong khoa Công nghệ thông tin
cùng toàn thể các thầy cô giáo đã truyền đạt vốn kiến thức quý báu cho chúng em
trong suốt quá trình học tập vừa qua. Em đã được quý thầy cô cung cấp và truyền
đạt tất cả kiến thức chuyên môn cần thiết và quý giá nhất. Ngoài ra em còn được rèn
luyện một tinh thần học tập và làm việc độc lập và sáng tạo. Đây là nền tảng hết
sức cần thiết để có thể thành công khi bắt tay vào nghề nghiệp trong tương lai.
Đồ án tốt nghiệp là cơ hội để em có thể áp dụng, tổng kết lại những kiến thức
mà mình đã học. Đồng thời, rút ra được những kinh nghiệm thực tế và quý giá trong
suốt quá trình thực hiện đề tài. Sau một thời gian em tập trung công sức cho đề tài
và làm việc tích cực, đặc biệt là nhờ sự chỉ đạo và hướng dẫn tận tình của cô
TS.Trần Thị Ngân cùng với các thầy cô trong trường Đại học Công nghệ thông tin
& Truyền thông - Đại học Thái Nguyên, đã giúp cho em hoàn thành đề tài một cách
thuận lợi và gặt hái được những kết quả mong muốn. Bên cạnh những kết quả
khiêm tốn mà em đạt được, chắc chắn không tránh khỏi những thiếu sót khi thực
hiện báo cáo của mình, kính mong thầy cô thông cảm. Sự phê bình, góp ý của quý
thầy cô sẽ là những bài học kinh nghiệm rất quý báu cho công việc thực tế của em
sau này.
Em cũng xin chân thành cảm ơn Ban lãnh đạo nhà trường và toàn thể các
thầy cô giáo trong nhà trường đã tạo mọi điều kiện thuận lợi, cung cấp cơ sở vật
chất, trang thiết bị cần thiết cho quá trình học tập của chúng em.
Kính chúc quý thầy cô mạnh khoẻ, tiếp tục đạt được nhiều thắng lợi trong
nghiên cứu khoa học và sự nghiệp trồng người.
Em xin chân thành cảm ơn!

1

LỜI CAM ĐOAN
Em xin cam đoan rằng:
Số liệu và kết quả nghiên cứu trong đồ án này là hoàn toàn trung thực và chưa từng
được sử dụng hoặc công bố trong bất kỳ công trình nào khác.
Mọi sự giúp đỡ cho việc thực hiện đồ án này đã được cám ơn và các thông
tin trích dẫn trong đồ án đều được ghi rõ nguồn gốc.
Sinh viên

Mạc Thị Thanh Hương

2


MỤC LỤC
LỜI CẢM ƠN ......................................................................................................... 1
LỜI CAM ĐOAN.................................................................................................... 2
MỤC LỤC .............................................................................................................. 2
DANH MỤC HÌNH ẢNH ....................................................................................... 5
LỜI MỞ ĐẦU ......................................................................................................... 6
CHƯƠNG 1: TÌM HIỂU CHUNG VỀ KIỂM THỬ PHẦN MỀM .......................... 7
1.1. Định nghĩa kiểm thử phần mềm..................................................................... 7
1.2. Mục tiêu của kiểm thử phần mềm.................................................................. 7
1.2.1 Mục tiêu trực tiếp ..................................................................................... 7
1.2.2 Mục tiêu gián tiếp .................................................................................... 8
1.3. Các nguyên tắc cơ bản của kiểm thử phần mềm ............................................ 8
1.4. Quy trình kiểm thử phần mềm ....................................................................... 9
1.4.1 Lập kế hoạch kiểm thử ............................................................................. 9
1.4.2 Phân tích và thiết kế trường hợp kiểm thử .............................................. 11
1.4.3 Thực hiện kiểm thử ................................................................................ 12

1.4.4 Báo cáo kết quả test................................................................................ 13
1.5. Các kỹ thuật kiểm thử.................................................................................. 13
1.5.1 Kiểm thử hộp đen- Black box testing...................................................... 13
1.5.2 Kiểm thử hộp trắng-White box testing .................................................... 14
1.5.3 Kiểm thử hộp xám- Gray box testing ...................................................... 15
1.6. Các cấp độ kiểm thử phần mềm................................................................... 15
1.6.1 Kiểm thử đơn vị - Unit Testing ............................................................... 16
1.6.2 Kiểm thử tích hợ -Integration Test .......................................................... 16
1.6.3 Kiểm thử hệ thống- System Test............................................................. 17
1.6.4. Kiểm thử chấp nhận- Acceptance Test .................................................. 19
CHƯƠNG 2: TỔNG QUAN VỀ KIỂM THỬ TỰ ĐỘNG VÀ CÔNG CỤ KIỂM
THỬ SELENIUM ................................................................................................. 21
2.1 Kiểm thử tự động ........................................................................................ 21
2.1.1 Tổng quan về kiểm thử tự động............................................................. 21
2.1.2 Các bước tiến hành kiểm thử phần mềm tự động................................... 23
2.1.3 Quy trình kiểm thử tự động ................................................................... 24
2.1.4 Kiến trúc của một bộ công cụ kiểm thử tự động .................................... 24
3


2.1.5. Công cụ kiểm thử tự động Selenium...................................................... 26
2.2 Selenium IDE.............................................................................................. 27
2.2.1 Cài đặt Selenium IDE............................................................................ 27
2.2.2 Các icon của Selenium IDE................................................................... 28
2.2.3 Các thao tác với Selenium ..................................................................... 30
2.3 Selenium Remote Control (Selenium RC) ................................................... 34
2.3.1 Máy chủ RC .......................................................................................... 35
2.3.2 Thư viện máy khách.............................................................................. 35
2.4. Selenium webdriver..................................................................................... 36
2.4.1. Selenium WebDriver là gì ..................................................................... 36

2.4.2. Các hàm xử lý chung trong Selenium WebDriver.................................. 43
CHƯƠNG 3. KHẢO SÁT VÀ XÂY DỰNG QUY TRÌNH TEST PHẦN MỀM... 47
3.1. Khảo sát phần mềm. .................................................................................... 47
3.1.1.Mục đích ................................................................................................ 47
3.1.2. Quy ước văn bản. .................................................................................. 47
3.1.3. Giới hạn người sử dụng ......................................................................... 47
3.1.4. Phạm vi dự án ....................................................................................... 48
3.1.5. Tham khảo ............................................................................................ 48
3.1.6 Yêu cầu cụ thể....................................................................................... 49
3.2. Phạm vi test................................................................................................. 52
3.3. Quy trình test phần mềm ............................................................................. 52
CHƯƠNG 4: XÂY DỰNG TESTCASE VÀ THỰC HIỆN KIỂM THỬ PHẦN MỀM .. 55
4.1. Trang đăng nhập.......................................................................................... 55
4.2. Module quản lý người dùng......................................................................... 60
4.3 Kết quả sử dụng selenium kiểm thử chức năng trên phần mềm quản lý thông
tin tuyển dụng cho công ty 2NF- Software. ........................................................ 76
4.3.1 Chức năng đăng nhập. ............................................................................ 76
4.3.2 Chức năng thêm mới người dùng ........................................................... 77
KẾT LUẬN........................................................................................................... 78
TÀI LIỆU THAM KHẢO ..................................................................................... 79

4


DANH MỤC HÌNH ẢNH
Hình 1.1. Quy trình kiểm thử...................................................................................9
Hình 1.2. Sơ đồ kế hoạch kiểm thử........................................................................10
Hình 1.3: Sơ đồ các cấp độ kiểm thử. ....................................................................15
Hình 2.1: Mô hình chung của một bộ kiểm thử tự động .........................................24
Hình 2.2: Giao diện cài đặt selenium .....................................................................28

Hình 2.3: Giao diện sử dụng selenium ...................................................................28
Hình 2.4: Giao diện chính của selenium. ...............................................................33
Hình 2.5: Giao diện Selenium RC..........................................................................34
Hình 2.6: Các hệ điều hành ứng dụng selenium Webdriver....................................36
Hình 2.7: So sánh giữa Selenium WebDriver và các công cụ kiểm thử tự động khác .37
Hình 2.8: Tổng quan về đối tượng UI (Locators) ...................................................38
Hình 2.9: Xác định phần tử Web theo ID..............................................................38
Hình 2.10: Xác định phần tử Web theo Name........................................................39
Hình 2.11: Xác định phần tử Web theo LinkText...................................................39
Hình 2.12: Xác định phần tử Web theo TagName..................................................40
Hình 2.13:Xác định phần tử Web theo ClassName ................................................40
Hình 2.14: Xác định phần tử Web theo CSS. .........................................................41
Hình 2.15: Ví dụ cấu trúc HTML của một trang web.............................................41
Hình 2.16: Kịch bản kiểm thử đơn giản cho phép người dùng login .....................44
Hình 2.17: Cấu trúc POM......................................................................................45
Hình 3.1 : Biểu đồ Use Case..................................................................................50
Hình 3.2 : Quy trình kiểm thử ...............................................................................52
Hình 4.1: Giao diện trang đăng nhập .....................................................................55
Hình 4.2:Giao diện module quản lý người dùng ....................................................60
Hình 4.3 : Giao diện màn hình login khi đăng nhập sai mật khẩu ..........................76
Hình 4.4 : Kết quả khi thực hiện test......................................................................76
Hình 4.5 : Giao diện khi đăng nhập thành công .....................................................76
Hình 4.6 : Kết quả khi thực hiện test......................................................................77
Hình 4.7 : Giao diện thêm mới người dùng không thành công ...............................77
Hình 4.8 : Kết quả khi thực hiện test......................................................................77
5


LỜI MỞ ĐẦU
Trong giai đoạn hiện nay công nghệ thông tin phát triển nhanh như vũ bão,

hàng năm có rất nhiều sản phẩm phầm mềm ra đời đáp ứng nhu cầu của người sử
dụng trên toàn thế giới. Yêu cầu các sản phẩm phầm mềm ra đời đáp ứng được yêu
cầu của khách hàng như giao diện thân thiện, dễ sử dụng bên cạnh đó các chức năng
phải hoạt động đúng theo yêu cầu từ đó việc kiểm tra các sản phẩm phầm mềm
cũng là một phần quan trọng trong quy trình phát triển phần mềm.
Kiểm thử là một giai đoạn không thể thiếu trong quá trình tạo ra một sản
phẩm phần mềm hoàn thiện nó giúp cho sản phẩm hoạt động đúng như mong đợi,
việc thực hiện kiểm thử đòi hỏi người kiểm thử phải có kiến thức cũng như cách
nhìn khách quan với sản phẩm đồng thời cũng tiêu tốn khá nhiều thời gian và công
sức do vậy để giảm bớt thời gian và tiền bạc cũng như sự nhàm chán khi kiểm thử
thủ công thì việc kiểm thử bằng công cụ tự động làm cho công việc trở nên nhẹ
nhàng, rút ngắn được thời gian thực hiện.
Có rất nhiều công cụ thực hiện việc kiểm thử tự động, trong đợt làm đồ án
này em lựa chọn đề tài: “Sử dụng selenium để kiểm thử phần mềm quản lý thông tin
tuyển dụng cho công ty 2NF - Software, Hà Nội” để có một cái nhìn tổng quát về
công cụ này cũng như quá trình kiểm thử động.
Trong khuôn khổ thực hiện và khả năng có hạn dó đó có những phần em
thực hiện chưa được tốt em mong sự chỉ bảo của các thầy cô để bài làm của em
được hoàn thiện hơn.

6


CHƯƠNG 1:
TÌM HIỂU CHUNG VỀ KIỂM THỬ PHẦN MỀM
1.1. Định nghĩa kiểm thử phần mềm
Kiểm thử phần mềm có nhiều định nghĩa khác nhau đề xuất bởi nhiều tổ
chức hay cá nhân khác nhau. Một số định nghĩa nổi bật:
Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới
những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía cạnh

nào đó của hệ thống hay thành phần đó. (Theo Bảng chú giải thuật ngữ chuẩn IEEE
của Thuật ngữ kỹ nghệ phần mềm- IEEE Standard Glossary of Software
Engineering Terminology).
Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm
lỗi.(Theo “The Art of Software Testing” – Nghệ thuật kiểm thử phần mềm).
Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ
phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp
cho người có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch
vụ phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm
khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong
nhiều ngành khác nhau. (Theo Bách khoa toàn thư mở Wikipedia).
Có thể định nghĩa một cách dễ hiểu như sau:
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à môi trường hoạt động có đúng
yêu cầu không.
1.2. Mục tiêu của kiểm thử phần mềm
1.2.1 Mục tiêu trực tiếp
Phát hiện và xác định càng nhiều lỗi càng tốt ở các phần mềm được kiểm thử.
Tiến hành sửa lỗi ở các phần mềm được kiểm thử và kiểm thử lại cho đến khi
đạt một mức độ chất lượng phần mềm chấp nhận được.
Thực thi những trường hợp kiểm thử một cách hiệu quả trong một giới hạn
ngân sách và lịch trình cho phép.

7


1.2.2 Mục tiêu gián tiếp
Để biên dịch một tài liệu về các lỗi phần mềm thường gặp nhằm mục đích
ngăn ngừa và sửa chữa lỗi.
1.3. Các nguyên tắc cơ bản của kiểm thử phần mềm

Có bảy nguyên tắc cơ bản cần chú ý khi kiểm thử phần mềm, các nguyên tắc
đó là:
Kiểm thử để chứng minh sự có mặt của lỗi và không chứng minh điều
ngược lại:Kiểm thử có thể cho thấy sự có mặt của lỗi nhưng không thể chứng minh
điều ngược lại là chương trình không có lỗi. Việc kiểm thử giảm nguy cơ không tìm
thấy lỗi trong phần mềm nhưng ngay cả khi không tìm thấy lỗi thì cũng không thể
chứng minh được sản phẩm phần mềm được phát triển hoàn toàn chính xác.
Không thể kiểm thử vét cạn: Việc kiểm thử không thể thực hiện được cho
tất mọi trường hợp kiểm thử. Do vậy thay vì kiểm thử mọi khía cạnh, ta phải tập
trung vào kiểm thử những yếu tố quan trọng và nhiều rủi do.
Kiểm thử sớm: Các hoạt động kiểm thử nên bắt đầu càng sớm càng tốt trong
vòng đời phát triển phần mềm, và nên tập trung và những mục tiêu kiểm thử nhất định.
Phân cụm lỗi:Một số lượng nhỏ các mô-đun phần mềm có thể chứa hầu hết
các lỗi được phát hiện ra trong suốt quá trình kiểm thử hoặc tập trung hầu hết các
lỗi vận hành.
Kiểm thử ngược: Nếu một phương pháp kiểm thử được lặp đi lặp lại nhiều
lần, các trường hợp kiểm thử giống nhau sẽ không phát hiện được triệt để lỗi mới.
Để khắc phục điều này ta có thể sử dụng nguyên tắc "kiểm thử ngược", các trường
hợp kiểm thử cần phải được xem xét và duyệt lại một cách đều đặn, và việc kiểm
thử mới cần phải được viết lại để thực thi những phần khác của phần mềm hay hệ
thống để tìm ra những lỗi tiềm ẩn.
Kiểm thử phụ thuộc vào ngữ cảnh: Việc kiểm thử được thực hiện trong
những hoàn cảnh khác nhau thì khác nhau.
Sai lầm về việc không có lỗi: Tìm kiếm và sửa lỗi không thể giúp được gì
nếu hệ thống không dùng được hoặc không đáp ứng được yêu cầu và sự mong đợi
của khách hàng.

8

1.4 . Quy trình kiểm thử phần mềm

Hình 1.1. Quy trình kiểm thử
Quy trình kiểm thử phần mềm gồm các bước sau:
- Lập kế hoạch kiểm thử(Test plan)
- Thiết kế các trường hợp kiểm thử(Testcase)
- Thực hiện kiểm thử và ghi nhận kết quả
- Kiểm tra, phân tích, đánh giá kết quả
- Lập báo cáo kiểm thử
1.4.1 Lập kế hoạch kiểm thử
Mục đích: Nhằm chỉ định và mô tả mục tiêu, phạm vi, tài nguyên, ràng
buộc, môi trường, các mạo hiểm, các phương pháp kiểm tra triển khai và thực hiện.
Kết quả của bước lập kế hoạch là bản tài liệu kế hoạch kiểm thử phần mềm, bao
gồm nhiều chi tiết từ các loại kiểm tra, chiến lược kiểm tra, cho đến thời gian và
phân định lực lượng kiểm tra viên.Bản kế hoạch kiểm tra đầu tiên được phát triển
rất sớm trong chu trình phát triển phần mềm, ngay từ khi các yêu cầu đã tương đối
đầy đủ, các chức năng và luồng dữ liệu chính đã được mô tả. Bản kế hoạch này có
thể được coi là bản kế hoạch chính (master test plan), trong đó tất cả các kế hoạch
chi tiết cho mức kiểm tra và loại kiểm tra khác nhau đều được đề cập.

9


Hình 1.2. Sơ đồ kế hoạch kiểm thử
- Tùy theo các đặc trưng và độ phức tạp của mỗi dự án, các kế hoạch kiểm tra
chi tiết có thể được gom chung vào bản kế hoạch chính hoặc được phát triển riêng.
Sau khi bản kế hoạch chính được phát triển, các bản kế hoạch chi tiết lần lượt được
thiết kế theo trình tự thời gian phát triển của dự án. Quá trình phát triển các kế
hoạch chi tiết kiểm tra không dừng lại tại một thời điểm, mà liên tục được cập nhật
chỉnh sửa sao cho phù hợp đến tận cuối dự án.

- Các bước lập kế hoạch:
 Xác định yêu cầu kiểm tra: chỉ định bộ phận, thành phần của phần mềm sẽ
được kiểm tra, phạm vi hoặc giới hạn của việc kiểm tra. Yêu cầu kiểm tra cũng
được dùng để xác định nhu cầu nhân lực.
 Khảo sát rủi ro: các rủi ro có khả năng xảy ra làm chậm hoặc cản trở quá
trình cũng như chất lượng kiểm tra. Ví dụ: kỹ năng và kinh nghiệm của kiểm tra
viên quá yếu, không hiểu rõ yêu cầu.
 Xác định chiến lược kiểm tra: chỉ định phương pháp tiếp cận để thực hiện
việc kiểm tra trên phần mềm, chỉ định các kỹ thuật và công cụ (tool) hỗ trợ kiểm tra,
chỉ định các phương pháp dùng để đánh giá chất lượng kiểm tra cũng như điều kiện
để xác định thời gian kiểm tra.

10


 Xác định nhân lực, vật lực: kỹ năng, kinh nghiệm của kiểm tra viên; phần
cứng, phần mềm, công cụ, thiết bị giả lập... cần thiết cho việc kiểm tra.
 Lập kế hoạch chi tiết: ước lượng thời gian, khối lượng công việc, xác định
chi tiết các phần công việc, người thực hiện, thời gian tất cả các điểm mốc của quá
trình kiểm tra.
 Tổng hợp và tạo các bản kế hoạch kiểm tra kế hoạch chung và kế hoạch chi
tiết.
 Xem xét các kế hoạch kiểm tra: phải có sự tham gia của tất cả nhưng người
có liên quan, kể cả trưởng dự án và có thế cả khách hàng. Việc xem xét nhằm bảo
đảm các kế hoạch khả thi, cũng như để phát hiện ( và sửa chữa sau đó) các sai sót
trong các bản kế hoạch.
1.4.2 Phân tích và thiết kế trường hợp kiểm thử
Một trường hợp kiểm thử (Test Case-TC) là một tình huống kiểm tra, được
thiết kế kiểm tra một đối tượng có thỏa mãn yêu cầu đặt ra hay không. Một TC
thường bao gồm 4 phần cơ bản:

 Điều kiện: đặc tả các điều kiện cần có để tiến hành kiểm tra.
 Đầu vào: đặc tả đối tượng hay dữ liệu cần thiết, được sử dụng làm đầu vào
để thực hiện việc kiểm tra.
 Kết quả mong chờ: kết quả mong đợi trả về đối tượng kiểm tra.
 Kết quả thực: kết quả thực tế trả về từ đối tượng kiểm tra.
Mục đích: nhằm chỉ định các TC và các bước kiểm tra chi tiết cho mỗi phiên
bản phần mềm. Giai đoạn thiết kế test là hết sức quan trọng, nó đảm bảo tất cả các
tình huống kiểm tra “quét” hết tất cả yêu cầu cần kiểm tra.
Việc thiết kế test không phải chỉ làm một lần, nó sẽ được sửa chữa, cập nhật,
thêm hoặc bớt xuyên suốt chu kỳ phát triển phần mềm, vào bất cứ lúc nào có sự
thay đổi yêu cầu, hoặc sau khi phân tích thấy cần được sửa chữa hoặc bổ sung.
Các bước thiết kế test bao gồm:
 Xác định và mô tả test case(TC): xác định các điều kiện cần thiết lập trước và
trong lúc kiểm tra. Mô tả mục đích, yêu cầu kiểm tra, đối tượng hoặc dữ liệu đầu vào,
mô tả các kết quả mong chờ sau khi kiểm tra, môi trường kiểm tra.

11


 Mô tả các bước chi tiết để kiểm tra: thao tác này nhằm chi tiết hóa các bước
của một TC, cũng như chỉ định các loại dữ liệu nào cần có để thực thi các TC,
chúng bao gồm các loại dữ liệu trực tiếp, gián tiếp, trung gian, hệ thống…
 Xem xét và khảo sát độ bao phủ của việc kiểm tra: mô tả các chỉ số và cách
thức xác định việc kiểm tra đã hoàn thành hay chưa? Bao nhiêu phần trăm phần
mềm đã được kiểm tra? Để xác định điều này có hai phương pháp: căn cứ trên yêu
cầu của phần mềm hoặc căn cứ trên số lượng code đã viết.
 Xem xét TC và các bước kiểm tra: Việc xem xét cần có sự tham gia của tất
cả những người có liên quan, kể cả trưởng dự án nhằm đảm bảo các TC và dữ liệu
yêu cầu là đủ và phản ánh đúng các yêu cầu cần kiểm tra, độ bao phủ đạt yêu cầu,
cũng như để phát hiện (và sửa chữa) các sai sót

Các kỹ thuật thiết kế TC
 Kỹ thuật dựa trên đặc tả - hộp đen: tìm kiếm lỗi theo cách của hệ thống thực
hiện.
 Kỹ thuật dựa trên cấu trúc – hộp trắng: tìm kiếm lỗi theo cách hệ thống
được xây dựng.
 Kỹ thuật dựa trên kinh nghiệm: tạo kiểm thử chủ yếu nhờ vào sự hiểu biết
về hệ thống, kinh nghiệm quá khứ, phương pháp phỏng đoán về lỗi. Có thể dược
hướng dẫn bởi danh sách các ý kiểm tra, việc phân loại lỗi, liệt kê các kiểu tấn công,
các tiếp cận “săn” lỗi, tập các lý do kiểm thử.
1.4.3 Thực hiện kiểm thử
Testers sẽ được bố trí công việc bởi Test Leader để thi hành kiểm thử.
 Thi hành kiểm thử theo từng test case
 Thực hiện kiểm thử đặc biệt
 Thực hiện kịch bản kiểm thử mà không được định nghĩa trong testcase
 Kiểm thử lại các lỗi đã được sửa
 Tester sẽ tạo ra các báo cáo về lỗi trong suốt quá trình kiểm lỗi và theo dõi
chúng cho đến khi được xử lý.
 Ở công đoạn kiểm thử độ chấp thuận, khách hàng sẽ thi hành kiểm thử để
kiểm định xem hệ thống phần mềm có thỏa mãn các nhu cầu người dùng không?

12


1.4.4 Báo cáo kết quả test
Test Manager hoặc Test Leader sẽ phân tích các lỗi trong hệ thống theo dõi
các lỗi.
 Tạo các báo cáo lỗi.
 Đánh giá các kết quả kiểm thử, thống kê các yêu cầu thay đổi.
 Tính và phân phối các thông tin đo lường hoạt động kiểm thử.
 Tạo bảng tổng kết đánh giá hoạt động kiểm lỗi.

 Xác định xem đã đạt tiêu chí thành công và hoàn thành kiểm thử chưa.
1.5 . Các kỹ thuật kiểm thử
1.5.1 Kiểm thử hộp đen- Black box testing
Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen, hướng
dữ liệu hay hướng vào/ra. Kiểm thử hộp đen Xem chương trình như là một “hộp
đen”, nó chỉ quan tâm tới đầu vào và đầu ra của hệ thống mà không quan tâm gì đến
cấu trúc bên trong của chương trình. Thay vào đó, tập trung vào tìm các trường hợp
mà chương trình không thực hiện theo các đặc tả của nó.
Theo hướng tiếp cận này, dữ liệu kiểm thử được lấy từ các đặc tả.
Các phương pháp kiểm thử hộp đen
- Phân lớp tương đương – Equivalence partitioning
- Phân tích giá trị biên – Boundary value analysis.
- Kiểm thử mọi cặp – All-pairs testing.
- Kiểm thử fuzz – Fuzz testing.
- Kiểm thử dựa trên mô hình – Model-based testing.
- Kiểm thử dấu vết – Traceability matriX
- Ma trận dấu vết – EXploratory testing.
- Kiểu thử dựa trên đặc tả - Specification-base testing.Kiểm thử dựa trên đặc
tả tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầu thích
hợp. Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ đối tượng
kiểm thử. Mức kiểm thử này thường yêu cầu các ca kiểm thử triệt để được cung cấp
cho kiểm thử viên mà khi đó có thể Xác minh là đối với dữ liệu đầu vào đã cho, gán
giá trị đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn đã được

13


Xác định trong ca kiểm thử đó hay không. Kiểm thử dựa trên đặc tả là cần thiết,
nhưng không đủ để ngăn chặn những rủi ro chắc chắn.
Ưu nhược điểm của kiểm thử hộp đen

Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viên
chỉ cần đơn giản tâm niệm là: một mà lệnh phải có lỗi. Sử dụng nguyên tắc “Hãy
đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập
trinh viên đã không tìm ra. Nhưng, mặt khác người ta cũng nói kiểm thử hộp đen
“giống như là đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên không
biết các phần mềm được kiểm tra thực sự được thực hiện Xây dựng như thế nào. Đó
là lý do mà có nhiều trường hợp mà một 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, và/ hoặc một số phần của chương trình không được kiểm tra
chút nào.
Vì thế, kiểm thực 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.5.2 Kiểm thử hộp trắng-White box testing
Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộp
đen, kiểm thử hộp trắng hay kiểm thử hướng logic cho phép ta khảo sát cấu trúc bên
trong của chương trình. Chiến lược này Xuất phát từ dữ liệu kiểm thử bằng sự kiểm
thử tính logic của chương trình. Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và
giải thuật bên trong chương trình (cả mã lệnh thực hiện chúng).
Các phương pháp kiểm thử hộp trắng
- Kiểm thử giao diện lập trình ứng dụng – API testing (Application
programming interface): là phương pháp kiểm thử của ứng dụng sử dụng các API
công khai và riêng tư.
- Bao phủ mã lệnh – Code coverage: tạo các kiểm tra để đáp ứng một số tiêu
chuẩn để bao phủ mã lệnh.
- Các phương pháp gán lỗi – Fault injection.
- Các phương pháp kiểm thử hoán chuyển – Mutation testing methods.
- Kiểm thử tĩnh – Static testing: kiểm thử hộp trắng bao gồm mọi kiểm thử
tĩnh
14

Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sự
hoàn thành của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử
hộp đen. Điều này cho phép các nhóm phần mềm khảo sát các phần của hệ thống ít
khi được kiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đã được
kiểm tra.
1.5.3 Kiểm thử hộp xám- Gray box testing
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 là không 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ọn khi quản lý kiểm thử tích
hợp – Intergartion testing giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết
kế khác nhau, trong ffos 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.6 . Các cấp độ kiểm thử phần mềm

Hình 1.3: Sơ đồ các cấp độ kiểm thử.
15


1.6.1 Kiểm thử đơn vị - Unit Testing
Kiểm thử đơn vị là hoạt động kiểm thử nhỏ nhất Kiểm thử thực hiện trên các
hàm hay thành phần riêng lẻ. Cần hiểu biết về thiết kế chương trình và code. Thực
hiện bởi Lập trình viên (không phải kiểm thử viên)
Đơn vị:
Là thành phần nhỏ nhất của phần mềm có thể kiểm thử được. Ví dụ: Các
hàm, lớp, thủ tục, phương thức. Đơn vị thường có kích thước nhỏ, chức năng hoạt

động đơn giản, không gây nhiều khó khăn trong việc kiểm thử, ghi nhận và phân
tích kết quả do đó nếu phát hiện lỗi việc tìm kiếm nguyên nhân và sửa lỗi cũng đơn
giản và tốn ít chi phí hơn.
Mục đích:
Đảm bảo thông tin được xử lý đúng và có đầu ra chính xác trong mối tương
quan giữa dữ liệu nhập và chức năng của đơn vị.
Người thực hiện:
Do việc kiểm thử đơn vị đòi hỏi phải kiểm tra từng nhánh lệnh, nên đòi hỏi
người kiểm thử có kiến thức về lập trình cũng như về thiết kế của hệ thống nên
người thực hiện thường là lập trình viên. Unit Test cũng đòi hỏi phải chuẩn bị trước
các ca kiểm thử (Test case) hoặc kịch bản kiểm thử (Test script), trong đó chỉ định
rõ dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn. Các Test case
và Test script này nên được giữ lại để tái sử dụng.
1.6.2 Kiểm thử tích hợ -Integration Test
Integration test kết hợp các thành phần của một ứng dụng và kiểm tra như
một ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit
riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa
chúng.
Integration Test có 2 mục tiêu chính:
- Phát hiện lỗi giao tiếp xảy ra giữa các Unit.
- Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng
là nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm tra ở mức hệ thống
(System Test).

16


Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng
và cấu trúc nội tại của Unit. Có một số phép kiểm tra đơn giản trên giao tiếp giữa
Unit với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit

thật sự được kiểm tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện
Integration Test.
Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã
được kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được
sửa chữa. Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với
các giao tiếp giả lập thì không cần phải thực hiện Integration Test nữa. Thực tế việc
tích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác.
Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng
Unit. Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích
hợp trước đó và đã hoàn tất (passed) các đợt Integration Test trước đó. Lúc này, ta
chỉ cần kiểm tra giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp
trước đó, điều này làm cho số lượng kiểm tra sẽ giảm đi rất nhiều, sai sót sẽ giảm
đáng kể.
Có 4 loại kiểm tra trong Integration Test:
- Kiểm tra cấu trúc (structure): Tương tự White Box Test (kiểm tra nhằm bảo
đảm các thành phần bên trong của một chương trình chạy đúng), chú trọng đến hoạt
động của các thành phần cấu trúc nội tại của chương trình chẳng hạn các lệnh và
nhánh bên trong.
- Kiểm tra chức năng (functional): Tương tự Black Box Test (kiểm tra chỉ
chú trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong),
chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật.
- Kiểm tra hiệu năng (performance): Kiểm tra việc vận hành của hệ thống.
- Kiểm tra khả năng chịu tải (stress): Kiểm tra các giới hạn của hệ thống.
1.6.3 Kiểm thử hệ thống- System Test
Mục đích System Test là kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích
hợp) có thỏa mãn yêu cầu đặt ra hay không.
System Test bắt đầu khi tất cả các bộ phận của PM đã được tích hợp thành
công. Thông thường loại kiểm tra này tốn rất nhiều công sức và thời gian. Trong
17

nhiều trường hợp, việc kiểm tra đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc
phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc
hệ thống nhúng. Ở mức độ hệ thống, người kiểm tra cũng tìm kiếm các lỗi, nhưng
trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên
quan đến chất lượng của toàn hệ thống.
Điểm khác nhau then chốt giữa Integration Test và System Test là System
Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng
sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Thông
thường ta phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự
tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test.
Sau khi hoàn thành Integration Test, một hệ thống PM đã đượ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 tra viên (tester) bắt đầu kiểm tra PM như một hệ thống hoàn chỉnh. Việc
lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích các
yêu cầu. Phần sau ta sẽ nói rõ hơn về một quy trình System Test cơ bản và điển
hình.
System Test 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 tra này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với PM 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 System Test, PM thường đã sẵn sàng cho khách hàng hoặc
người dùng cuối cùng kiểm tra để chấp nhận (Acceptance Test) hoặc dùng thử
(Alpha/Beta Test).
Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test
thường được thực hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập với nhóm
phát triển dự án.
Bản thân System Test lại gồm nhiều loại kiểm tra khác nhau phổ biến nhất
gồm:
- Kiểm tra chức năng (Functional Test): 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ế.

18


- Kiểm tra khả năng vận hành (Performance Test): 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âu truy vấn…
- Kiểm tra khả năng chịu tải (Stress Test hay Load Test): 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). Stress
Test 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…
- Kiểm tra cấu hình (Configuration Test)
 Kiểm tra khả năng bảo mật (Security Test): 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 tra khả năng phục hồi (Recovery Test): 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; đặ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.
Nhìn từ quan điểm người dùng, các kiểm tra trên rất quan trọng: bảo đảm hệ
thống đủ khả năng làm việc trong môi trường thực.
Lưu ý không nhất thiết phải thực hiện tất cả các loại kiểm tra nêu trên. Tùy
yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự
án, khi lập kế hoạch, trưởng dự án sẽ quyết định áp dụng những loại kiểm tra nào.
1.6.4. Kiểm thử chấp nhận- Acceptance Test
Kiểm thử chấp nhận là một cấp độ trong tiến trình kiểm thử phần mềm nhằm
kiểm thử hệ thống về khả năng chấp nhận được.
Mục tiêu của kiểm thử này là để đánh giá sự tuân thủ của hệ thống với các
yêu cầu nghiệp vụ và thẩm định xem đã có thể chấp nhận để bàn giao chưa.
Kiểm thử chấp nhận nhằm mục đích để chứng minh phần mềm thỏa mãn tất cả
yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm. Kiểm thử chấp nhận

được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện).
Kiểm thử chấp nhận thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm
thử Alpha – Alpha Test và kiểm thử Beta – Beta Test. Với Alpha Test, người dùng
kiểm thử phần mềm ngay tại nơi phát triển phần mềm, lập trình viên sẽ ghi nhận các
lỗi hoặc phản hồi, và lên kế hoạch sửa chữa. Với Beta Test, phần mềm sẽ được gửi
tới cho người dùng để kiểm thử ngay trong môi trường thực, lỗi hoặc phản hồi cũng
19


sẽ gửi ngược lại cho lập trình viên để sửa chữa. Thực tế cho thấy, nếu khách hàng
không quan tâm và không tham gia vào quá trình phát triển phần mềm thì kết quả
Acceptance Test sẽ sai lệch rất lớn, mặc dù phần mềm đã trải qua tất cả các kiểm
thử trước đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong
chờ của khách hàng. Ví dụ đôi khi một phần mềm xuất sắc vượt qua các phép kiểm
thử sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn, thao tác không tự nhiên,
không theo tập quán sử dụng của khách hàng v.v…
Gắn liền với giai đoạn Acceptance Test thường là một nhóm những dịch vụ
và tài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v… Tất cả tài liệu đi
kèm phải được cập nhật và kiểm thử chặt chẽ.

20


CHƯƠNG 2:
TỔNG QUAN VỀ KIỂM THỬ TỰ ĐỘNG VÀ
CÔNG CỤ KIỂM THỬ SELENIUM
2.1 Kiểm thử tự động
2.1.1 Tổng quan về kiểm thử tự động
Kiểm thử tự động là: Quá trình thực hiện một cách tự động các bước trong
một kịch bản kiểm thử hay sử dụng một công cụ kiểm thử tự động để thực thi các

tescase thay cho con người được gọi là kiểm thử tự động.
Ưu và nhược điểm của kiểm thử tự động
Ưu điểm:
Độ tin cậy cao: Nhờ sự ổn định vượt trội của công cụ kiểm thử tự động so
với con người, đặc biệt trong trường hợp có quá nhiều test case cần được thực thi,
nên độ tin cậy của kiểm thử tự động thường cao hơn so với kiểm thử thủ công.
Khả năng lặp: Hãy cùng xét ví dụ sau: Trong một ngày thời tiết xấu chúng ta
phải thực thi một test case với 50 bộ dữ liệu đầu vào khác nhau nếu thực thi cách
thủ công, ngồi trước màn hình nhập dữ liệu, click click, check check … Trong 50
lần có lẽ bạn sẽ gục ngã sớm trên bàn làm việc của mình.Nhưng nếu bạn thực thi
bằng kiểm thử tự động chỉ cần nhập dữ liệu vào script chạy và ngồi rung đùi cho tới
khi nhận được báo cáo. Với độ ổn định cao, chúng ta có thể tin tưởng vào kết quả
thực thi của công cụ kiểm thử tự động.
Cải thiện chất lượng: Kiểm thử phần mềm tự động sẽ làm giảm rủi ro về chất
lượng sản phẩm, việc kiểm thử được thực hiện một cách nhanh chóng.
Khả năng tái sử dụng: Với một bộ kiểm thử tự động, chúng ta có thể sử dụng
cho nhiều phiên bản khác nhau, đây được gọi là sử dụng lại.
Nhanh: Đây là điều không thể phủ nhận khi thực hiện kiểm thử một cách tự
động, nếu cần năm phút để thực hiện một test case thủ công thì có thể chưa đầy 30s
nếu thực hiện tự động,trong vòng năm phút đó bạn có thể thực hiện được hàng chục
test case.
Chi phí thấp: Việc rút ngắn thời gian và tiết kiệm nhân lực giúp cho công
việc kiểm thử tự động trở nên hiệu quả

21


Nhược điểm:
Khó mở rộng, khó bảo trì: Trong cùng một dự án, để mở rộng phạm vi cho
kiểm thử tự động là khó khăn hơn nhiều so với kiểm thử thủ công. Số lượng công

việc cần làm để mở rộng phạm vi cho kiểm thử tự động là nhiều hơn và khó khăn
hơn kiểm thử thủ công. Cũng vậy để cập nhật một test case thủ công chúng ta chỉ
cần mở ra và gõ, rất đơn giản. Nhưng kiểm thử tự động lại không đơn giản như vậy,
cập nhật hay chỉnh sửa yêu cầu rất nhiều công debug, thay đổi dữ liệu đầu vào, cập
nhật code mới.
Khả năng bao phủ thấp: Chính lý do khó ứng dụng, khó mở rộng cũng như đòi
hỏi quá nhiều kỹ năng lập trình nên độ bao phủ của kiểm thử tự động khá thấp.
Vấn đề công cụ và nhân lực: Cho đến nay công cụ hỗ trợ kiểm thử tự động
đã có những bước phát triển mạnh mẽ chúng ta có nhiều công cụ tiêu biểu như Qick
test pro, Selenium, Test Complete…Nhưng nhìn chung vẫn còn nhiều hạn chế.
Ngoài ra nguồn nhân lực đạt yêu cầu không đủ.
Vì sao cần kiểm thử tự động
Một trong những lý do chính để ta thực hiện việc kiểm thử là tiết kiệm thời
gian:
Nhận định này đặc biệt đúng nếu xét trong giai đoạn bảo trì của dự án lớn.
Mỗi tuần chúng ta phải thực hiện từ một đến hai lần kiểm thử quy hồi với số lượng
test case rất lớn thời gian tiêu tốn cũng mất từ một đến hai ngày. Gần như không thể
thực hiện thủ công, trong khi đó nếu thực hiện kiểm thử thủ công hoàn toàn có thể
thực hiện được khối lượng công việc đó với thời gian vô cùng hạn chế. Chính xác
hơn: Nhờ độ ổn định cao, kiểm thử tự động có thể thực thi các test case với độ
chính xác cao hơn rất nhiều so với thực hiện thủ công.
Hoàn thành các công việc mà con người không thể làm được: Nếu chúng ta
muốn thực thi load test, performance test, thì kiểm thử tự động là cách duy nhất.
Khi nào nên kiểm thử tự động
- Những trường hợp kiểm thử cần thực hiện nhiều lần, thường xuyên phải
thực hiện regression test, một số lượng testcase lớn cần thực hiện trong một thời
gian ngắn.
- Kiểm thử cần thực hiện ở nhiều môi trường khác nhau.
22

- Những project có tính ổn định, đặc điểm kỹ thuật được xác định trước, test
màn hình chức năng không thay đổi trong tương lai.
- Những trường hợp kiểm thử xác nhận hoạt động cơ bản ( di chuyển giữa
các màn hình ).
- Kiểm tra sự kết hợp của nhiều giá trị đầu vào ở một bước nào đó.
- Kiểm tra nhiều màn hình của dữ liệu đầu vào.
- Mục đầu vào ở nhiều màn hình đăng ký.
- Khi muốn thực thi performance test hoặc load test, kiểm thử tự động gần
như là lựa chọn duy nhất.
2.1.2 Các bước tiến hành kiểm thử phần mềm tự động
Bước 1: Phân tích khả năng áp dụng kiểm thử tự động
Trước khi xác định phương pháp kiểm thử ta cần xem xét kỹ khi nào nên sử
dụng phương pháp nào cho hợp lý nhất. Chúng ta không thể tự động hóa mọi việc
trong kiểm thử. Có những công việc mà chỉ có thực hiện thủ công, có những việc có
thể thực hiện tự động. Chẳng hạn có những công nghệ mới hay phần mềm mới mà
các công cụ kiểm thử tự động chưa thể kiểm thử hoàn toàn hay chỉ một phần. Tóm
lại trước khi tiến hành kiểm thử ta cần phân tích khả năng nào nên áp dụng kiểm thử
tự động khả năng nào không, không nên lạm dụng việc kiểm thử tự động vì như vậy
sẽ không mang lại hiệu quả tốt.
Bước 2: Lựa chọn công cụ kiểm thử tự động thích hợp
Sau khi xác định được sản phẩm hiện tại có thể kiểm thử tự động hay không,
bước tiếp theo là xác định nên sử dụng công cụ kiểm thử tự động nào. Công cụ nào
hỗ trợ kiểm thử tự động cho sản phẩm sử dụng, ưu điểm của từng công cụ, ngôn
ngữ kịch bản nào mà công cụ kiểm thử sử dụng, nhân sự hiện tại có quen thuộc với
công cụ đó hay không?. Việc lựa chọn bộ công cụ để thực hiện cũng vô cùng quan
trọng nó góp phần vào sự thành công của các ca kiểm thử bởi mỗi bộ công cụ lại có
một số điểm mạnh, điểm yếu riêng.
Bước 3: Xây dựng môi trường làm việc
Môi trường làm việc bao gồm các khái niệm, chu trình, thủ tục và môi

trường mà kịch bản kiểm thử tự động được thiết kế ra. Lưu trữ các kịch bản kiểm
thử cũng như các mối quan hệ logic giữa các thành phần.
23


Bước 4: Viết kịch bản kiểm thử, thực thi và phân tích kết quả
Dựa trên các kịch bản kiểm thử đã được tạo ra bằng kiểm thử thủ công, dựa
vào ngôn ngữ kịch bản mà công cụ kiểm thử tự động hỗ trợ, chúng ta viết các đoạn
mã tương tác với sản phẩm phần mềm trên các môi trường và thực thi nó. Sau khi
thực thi các đoạn mã, chúng ta cần phân tích các kết quả đạt được và ghi lại các vấn
đề của sản phẩm, nếu có.
2.1.3 Quy trình kiểm thử tự động
Quy trình kiểm thử phần mềm tự động được thực hiện thông qua bốn bước
Bước 1: Viết kịch bản kiểm thử, 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 các kịch bản kiểm thử.
Bước 2: Chỉnh sửa để kịch bản kiểm thử thực hiện theo đúng yêu cầu đặt ra
làm theo trường hợp kiểm thử cần thực hiện.
Bước 3: Chạy kịch bản kiểm thử, giám sát hoạt động kiểm tra phần mềm
kịch bản kiểm thử
Bước 4: 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.
2.1.4 Kiến trúc của một bộ công cụ kiểm thử tự động
Trong thực tế, có rất nhiều bộ công cụ hỗ trợ kiểm thử tự động được phát
triển nhằm giải quyết các vấn đề khó khăn của quy trình kiểm thử. Dưới đây là mô
hình chung nhất của một bộ kiểm thử tự động. Trong kiến trúc này, các công cụ
kiểm thử được tích hợp trong một quy trình thống nhất nhằm hỗ trợ đầy đủ các hoạt
động kiểm thử trong quy trình kiểm thử các sản phẩm phần mềm.

Hình 2.1: Mô hình chung của một bộ kiểm thử tự động
24

Quản lý kiểm thử: Công cụ này cho phép quản lý việc thực hiện/ thực thi
các ca kiểm thử. Nó giám sát việc thực hiện các kiểm thử ứng với bộ giá trị đầu vào,
giá trị đầu ra mong đợi và giá trị đầu ra thực tế. Junit là một điển hình trong công cụ
này.
Sinh các ca kiểm thử: Đây là một trong những công cụ quan trọng nhất của
các bộ kiểm thử tự động. Tùy thuộc vào các kỹ thuật kiểm thử được áp dụng, các
công cụ này sẽ sinh ra tập các ca kiểm thử (chưa gồm các giá trị đầu ra mong muốn)
cho chương trình/đơn vị chương trình cần kiểm thử. Các ca kiểm thử được sinh ra
chỉ chứa giá trị đầu vào để thực hiện nó. Các giá trị này có thể được lựa chọn trong
cơ sở dữ liệu hoặc được sinh ngẫu nhiên.
So sánh kết quả kiểm thử: Công cụ này so sánh giá trị đầu ra thực tế và giá
trị đầu ra mong muốn của mỗi ca kiểm thử khi nó được thực hiện chương trình/ đơn
vị chương trình cần kiểm thử.
Tạo báo cáo kiểm thử: Một trong những ưu điểm của các bộ công cụ kiểm
thử tự động là nó có cơ chế sinh báo cáo kiểm thử một các chính xác và nhất quán.
Dựa vào kết quả báo của công cụ so sánh kết quả kiểm thử, công cụ này sẽ tự động
sinh ra báo cáo kết quả kiểm thử theo định dạng mong muốn của đơn vị phát triển.
Phân tích động: Công cụ này cung cấp một cơ chế nhằm kiểm tra việc thực
hiện của các câu lệnh của chương trình cần kiểm thử nhằm phát hiện các lỗi và các
câu lệnh hay đoạn lệnh không được thực hiện bởi một tập các ca kiểm thử cho
trước. Công cụ này cũng rất hiệu quả trong việc đánh giá tính hiệu quả của một bộ
kiểm thử cho trước.
Bộ mô phỏng: Có nhiều loại hình mô phỏng được cung cấp trong các bộ
kiểm thử tự động. Mục đích của các công cụ này là mô phỏng quá trình thực hiện
của chương trình cần kiểm thử. Ví dụ, các công cụ mô phỏng giao diện người dùng
cho phép thực hiện tự động các tương tác giữa người sử dụng và sản phẩm.
Selenium là một ví dụ về một công cụ mô phỏng giao diện người dùng cho các ứng
dụng Web.

25