Nghiên cứu và ứng dụng công cụ selenium webdriver trong kiểm thử tự động ứng dụng web

LỜI CẢM ƠN

Em xin chân thành cảm ơn sự giúp đỡ nhiệt tình của thầy giáo - Tiến sĩ Nguyễn
Văn Núi, người đã cung cấp cho em những kiến thức cơ bản về kiểm thử phần mềm
cũng như định hướng cho em những phương pháp, công cụ kiểm thử và cung cấp tài
liệu tham khảo, để em có thể hoàn thành tốt đề tài của mình.
Em cũng xin gửi lời cảm ơn đến các thầy cô giáo, giảng viên trong Khoa Công
Nghệ Thông Tin – Trường ĐH Công Nghệ Thông Tin và Truyền Thông Thái Nguyên
– Đại học Thái Nguyên và các thầy cô đã giảng dạy em trong suốt quá trình em học
tập tại trường.
Con cũng xin gửi lời cảm ơn chân thành đến gia đình, bố mẹ và bạn bè đã luôn là
nguồn động viên to lớn giúp đỡ con vượt qua những khó khăn trong suốt quá trình học tập.
Mặc dù đã cố gắng hoàn thiện đồ án với tất cả nỗ lực của bản thân, nhưng chắc
không thể tránh khỏi những thiếu sót. Kính mong quý thầy cô đóng góp ý kiến để em
có thể hoàn thiện kiến thức của bản thân!
Là sinh viên công nghệ thông tin, em rất tự hào về ngồi trường mà mình đang
theo học, và tự hào về tất cả thầy cô của mình!
Em xin chân thành cảm ơn!
Thái Nguyên, tháng 5 năm 2017
Sinh viên

Nguyễn Thị Ngoan

1


LỜI CAM ĐOAN

Để hoàn thành đồ án tốt nghiệp đúng thời gian quy định và đáp ứng được yêu cầu
đề ra, em đã cố gắng tìm hiểu, học hỏi, tích lũy kiến thức đã học. Em có tham khảo
một số tài liệu đã nêu trong phần “Tài liệu tham khảo” nhưng không sao chép nội dung

từ bất kì đồ án nào khác.
Em xin cam đoan những lời khai trên là đúng, mọi thông tin sai lệch em xin hoàn
toàn chịu trách nhiệm trước Hội đồng.
Sinh viên

Nguyễn Thị Ngoan

2


MỤC LỤC

LỜI CẢM ƠN ............................................................................................................. 1
LỜI CAM ĐOAN ........................................................................................................ 2
MỤC LỤC ................................................................................................................... 3
DANH MỤC HÌNH ẢNH ........................................................................................... 6
LỜI NÓI ĐẦU............................................................................................................. 7
CHƯƠNG 1: TỔNG QUAN VỀ PHẦN MỀM ............................................................ 8
1.1. Phần mềm là gì? ................................................................................................ 8
1.1.1. Khái niệm .................................................................................................... 8
1.1.2. Phân loại phần mềm .................................................................................... 8
1.1.3. Vòng đời phát triển phần mềm (Software Development Life Cycle) ............ 8
1.1.4. Các mô hình phát triển phần mềm ............................................................. 10
1.2. Kiểm thử phần mềm ........................................................................................ 15
1.2.1. Khái niệm kiểm thử phần mềm .................................................................. 15
1.2.2. Các mức kiểm thử ..................................................................................... 15
1.2.3. Các phương pháp kiểm thử ........................................................................ 16
1.2.4. Các loại kiểm thử ...................................................................................... 18
1.3. Quy trình kiểm thử phần mềm (STLC) ............................................................ 20
1.4. Kế hoạch kiểm thử (test plan) .......................................................................... 21

1.5. Thiết lập môi trường kiểm thử ......................................................................... 22
1.5.1. Khái niệm môi trường kiểm thử ................................................................. 22
1.5.2. Thiết lập môi trường kiểm thử ................................................................... 22
1.6. Testcase, kỹ thuật thiết kế testcase ................................................................... 23
1.6.1. Khái niệm về testacase .............................................................................. 23
1.6.2. Các kỹ thuật thiết kế testcase ..................................................................... 23
1.7. Kiểm thử tự động. ............................................................................................ 26
1.7.1. Kiểm thử tự động là gì? Quy trình kiểm thử tự động.................................. 26
1.7.2. Ưu điểm và nhược điểm của kiểm thử tự động. ......................................... 27
1.7.3. Các trường hợp nên áp dụng kiểm thử tự động. ......................................... 27

3


CHƯƠNG 2: KIỂM THỬ ỨNG DỤNG WEB .......................................................... 29
2.1. Kiểm thử ứng dụng web .................................................................................. 29
2.1.1. Khái quát ................................................................................................... 29
2.1.2. Đặc điểm về chất lượng của một ứng dụng Web ........................................ 29
2.2. Công việc khi kiểm thử một ứng dụng web ...................................................... 30
2.2.1. Kiểm tra chức năng (hồi quy, tích hợp, kiểm tra khói) ............................... 31
2.2.2. Kiểm tra sự tương thích trình duyệt ........................................................... 32
2.2.3. Thử nghiệm tính năng................................................................................ 33
2.2.4. Kiểm tra bảo mật ....................................................................................... 33
2.2.5. Giám sát sản xuất ...................................................................................... 34
2.2.6. Kiểm tra khả năng sử dụng ........................................................................ 34
2.3. Thiết kế testcase cho ứng dụng web ................................................................. 35
2.3.1. Quy trình thiết kế testcase cho ứng dụng web ............................................ 35
2.3.2. Các Check list ........................................................................................... 35
2.4. Giới thiệu một số công cụ hỗ trợ kiểm thử ứng dụng web ................................ 37
2.4.1. Công cụ test bảo mật web .......................................................................... 37

2.4.2. Công cụ test hiệu năng............................................................................... 38
CHƯƠNG 3: SỬ DỤNG CÔNG CỤ HỖ TRỢ TEST SELENIUM WEBDRIVER ĐỂ
TEST ỨNG DỤNG WEB .......................................................................................... 39
3.1. Giới thiệu chung về Selenium, cách cài đặt và sử dụng Selenium. ................... 39
3.1.1. Giới thiệu chung về Selenium .................................................................... 39
3.1.2. Các đặc điểm của Selenium ....................................................................... 39
3.1.3. Các thành phần của Selenium .................................................................... 40
3.2. Selenium IDE .................................................................................................. 43
3.2.1. Giới thiệu về Selenium IDE ....................................................................... 43
3.2.2. Hướng dẫn cài đặt Selenium IDE .............................................................. 43
3.2.3. Các câu lệnh chính của Selenium IDE ....................................................... 45
3.2.4. Locator (Xác định đối tượng UI) ............................................................... 47
3.3. Selenium WebDriver ....................................................................................... 48
3.3.1. Giới thiệu về Selenium WebDirver ............................................................ 48
3.3.2. Cài đặt Selenium WebDriver ..................................................................... 49

4


3.3.3. Các câu lệnh sử dụng trong Selenium WebDriver. ..................................... 57
3.3.4. Bài toán thử nghiệm tiến hành test Selenium WebDriver trên trang
............................................................................... 61
3.3.5. Kịch bản kiểm thử tự động ........................................................................ 63
3.3.6. Sự khác nhau giữa kịch bản kiểm thử thử công và kịch bản kiểm thử tự động 65
KẾT LUẬN ............................................................................................................... 67
TÀI LIỆU THAM KHẢO ......................................................................................... 68

5

DANH MỤC HÌNH ẢNH
Hình 1.1: Vòng đời phát triển phần mềm ..................................................................... 9
Hình 1.2: Mô hình thác nước ..................................................................................... 10
Hình 1.3: Mô hình mẫu .............................................................................................. 11
Hình 1.4: Mô hình phát triển ứng dụng nhanh RAD................................................... 12
Hình 1.5: Mô hình tiến hóa ........................................................................................ 12
Hình 1.6: Mô hình chữ V ........................................................................................... 13
Hình 1.7: Mô hình Agile Scrum ................................................................................. 14
Hình 1.8: Phương pháp kiểm thử hộp đen .................................................................. 16
Hình 1.9: Phương pháp kiểm thử hộp trắng................................................................ 17
Hình 1.10: Phương pháp kiểm thử hộp xám ............................................................... 18
Hình 1.11: Quy trình kiểm thử phần mềm .................................................................. 20
Hình 1.12: Kỹ thuật phân vùng tương đương ............................................................. 24
Hình 1.13: Kỹ thuật phân tích giá trị biên .................................................................. 25
Hình 3.1: Cấu trúc của Selenium ............................................................................... 39
Hình 3.2: Minh họa kiến trúc của WebDriver và Selenium RC ................................. 42
Hình 3.3: Thao tác mở Selenium IDE trên thanh công cụ........................................... 44
Hình 3.4: Giao diện chính của Selenium IDE............................................................. 44
Hình 3.5: Cấu trúc của Selenium WebDriver ............................................................. 49
Hình 3.6: Download và cài đặt JDK........................................................................... 50
Hình 3.7: Download Eclipse IDE ............................................................................... 50
Hình 3.8: Download Selenium Java Client Driver...................................................... 51
Hình 3.9: Tạo một project mới ................................................................................... 51
Hình 3.10: Đặt tên và chọn tạo phương thức .............................................................. 52
Hình 3.11: Tên Class trong Eclipse ............................................................................ 52
Hình 3.12: Thêm Selenium Java Client Driver (.jar) vào trong project. ...................... 53
Hình 3.13: Đăng nhập thành công trên Firefox .......................................................... 63
Hình 3.14: Đăng nhập thành công trên Chrome ......................................................... 64
Hình 3.15: Giao diện báo cáo kết quả kiểm thử thành công........................................ 64
Hình 3.16: Giao diện báo cáo kết quả kiểm thử thất bại ............................................. 65

Hình 3.17: Bảng tóm tắt các trường hợp testcase đã chạy .......................................... 65

6


LỜI NÓI ĐẦU
1. Lí do chọn đề tài
Các ứng dụng Web đã được phát triển và trở thành nền tảng kết nối thông tin
thiết yếu trong doanh nghiệp, đóng vai trò quyết định trong thương mại điện tử, trao
đổi thông tin. Để có thể đạt được điều này, các úng dụng web cần phải có hiệu năng
cao, đáng tin cậy…Việc đưa ra một ứng dụng web hoàn hảo cho người đang và sẽ sử
dụng ứng dụng đã trở thành một thử thách chính trong vấn đề đảm bảo chất lượng.
Kiểm thử ứng dụng web đã vượt quá giới hạn của kiểm thử những hệ thống phần mềm
truyền thống. Như chúng ta đã biết, một ứng dụng web thường có rất nhiều nhóm
người sử dụng với nền tảng khác nhau (hệ điều hành, trình duyệt,..) điều này dẫn tới
việc kiểm thử ứng dụng web cần phải có những phương pháp đặc biệt khác với phần
mềm truyền thống.
Selenium WebDriver là một công cụ kiểm thử ứng dụng Web tiêu biểu. Đây là
một công cụ mã nguồn mở, mạnh mẽ hỗ trợ trên nền Web, nhiều platform và các trình
duyệt phổ biến. Công cụ này được phát triển chủ yếu trong JavaScript và các công
nghệ trình duyệt như HTML và các khung hình, và do đó hỗ trợ tất cả các trình duyệt
chính trên các nền tảng. Selenium WebDriver có lẽ là một trong những công cụ tốt
nhất trên thị trường cho các ứng dụng Web. Điều đáng lưu ý là kiểm thử phần mềm
nói chung và kiểm thử Web nói riêng đều chưa được phổ biến ở Việt Nam. Đây cũng
là lí do em chọn đề tài “Nghiên cứu và ứng dụng công cụ Selenium WebDriver trong
kiểm thử tự động ứng dụng Web” với mong muốn giúp nhiều người hiểu rõ hơn về
kiểm thử ứng dụng Web cũng như cách sử dụng công cụ Selenium WebDriver vào
công việc này.
2. Mục tiêu nghiên cứu
Đề tài giới thiệu về tổng quan phần mềm, các phương pháp kiểm thử và các công

việc khi kiểm thử một ứng dụng Web.
Đi sâu vào nghiên cứu tính năng của công cụ Selenium WebDriver, các thành
phần của bộ công cụ.
Đưa ra tài liệu hướng dẫn cài đặt, sử dụng một cách đơn giản và hiệu quả bộ
công cụ đó.
Ứng dụng kiến thức về kiểm thử phần mềm và các kiến thức về Selenium
WebDriver để viết kịch bản cho một ứng dụng cụ thể.

7


CHƯƠNG 1: TỔNG QUAN VỀ PHẦN MỀM

1.1. Phần mềm là gì?
1.1.1. Khái niệm
Phần mềm là những ứng dụng chạy bên trong máy tính, (nhằm) cung cấp các
chức năng, đáp ứng các yêu cầu, công việc của người sử dụng thông qua phần cứng
máy tính.
Một phần mềm thường gồm 03 phần:
• Chương trình máy tính: mã nguồn, mã máy
• Cấu trúc dữ liệu: cấu trúc làm việc (bộ nhớ trong), cấu trúc lưu trữ (bộ nhớ ngoài).
• Các tài liệu liên quan: tài liệu hướng dẫn sử dụng, tài liệu phát triển, tài liệu
tham khảo kĩ thuật….
1.1.2. Phân loại phần mềm
Dựa vào môi trường thực thi, phần mềm được chia thành các loại như sau:
• Phần mềm ứng dụng giao diện hệ điều hành: (Windows Form, Windows
Service)
• Phần mềm ứng dụng Web: (Website, Web Service, Web API….)
• Phần mềm ứng dụng Mobile App: (Android App, iOS App, Winphone App…)
• Phần mềm nhúng: (Ti vi, tủ lạnh, điều hòa….)

1.1.3. Vòng đời phát triển phần mềm (Software Development Life Cycle)
Vòng đời phát triển phần mềm là thời kì tính từ khi phần mềm được sinh (tạo) ra
cho đến khi chết đi (từ lúc hình thành đáp ứng yêu cầu, vận hành, bảo dưỡng cho đến
khi loại bỏ không dùng nữa).
Vòng đời của phần mềm được chia thành các pha chính: Phân tích, Thiết kế,
chiết tạo, kiểm thử, bảo trì. Được biểu diễn theo mô hình sau đây:

8


Hình 1.1: Vòng đời phát triển phần mềm
Pha xác định yêu cầu hệ thống: Mọi phần mềm đều được xây dựng, phát triển
trên tài liệu đặc tả (Software Requirement Specification). Dựa vào các đặc tả này của
người dùng, bộ phận xây dựng phần mềm sẽ xác định yêu cầu hệ thống của hệ thống
phần mềm sẽ xây dựng. Xác định phần mềm thuộc loại nào: Windows Form, Web
Form hay Mobile App.
Pha xác định yêu cầu phần mềm: Sau khi xác định được loại của hệ thống sẽ
xây dựng, các kĩ sư phần mềm tiếp tục khảo sát các yêu cầu sử dụng của khách hàng
qua đó xác định các yêu cầu của phần mềm mà khách hàng đang mong muốn xây
dựng, đây chính là pha xác định xem phần mềm sẽ có chức năng gì và tương tác như
thế nào?
Pha thiết kế căn bản: Hay còn gọi là thiết kế sơ bộ hệ thống, ở giai đoạn này
kiến trúc khung của phần mềm sẽ được thiết kế (sử dụng nền tảng nào, ngôn ngữ lập
trình nào, áp dụng những công nghệ gì…).
Pha thiết kế chi tiết: Thiết kế chi tiết các chức năng mà chương trình sẽ có. Xác
định nghiệp vụ cho từng chức năng sẽ xây dựng.

9

Pha lập trình: Đây chính là pha hiện thực hóa phần mềm dựa vào các bản thiết
kế ở các pha trên. Người lập trình cần phải sử dụng những công nghệ, ngôn ngữ lập
trình cũng như những nền tảng đã được xác định để tiến hành lập trình thực hiện các
nghiệp vụ đã được thiết kế.
Pha kiểm thử: Sauk hi phần mềm đã được lập trình xong sẽ được chuyển sang
pha kiểm thử nhằm đảm bảo chương trình có đầy đủ các chức năng, nghiệp vụ mà
khách hàng yêu cầu cũng như tất cả hoạt động tốt theo đúng mong muốn.
Pha vận hành bảo trì: Đây là pha có thời gian dài nhất trong vòng đời của phần
mềm. Sau khi phần mềm được thiết kế, lập trình và kiểm thử xong sẽ bàn giao cho
khách hàng mang vào hoạt động thực tế. Pha này sẽ kéo dài cho tới khi phần mềm
không còn phù hợp nữa thì kết thúc.
1.1.4. Các mô hình phát triển phần mềm
 Mô hình tuyến tính/ Thác nước (Water fall)
Là mô hình phát triển phần mềm cổ điển gồm có 05 pha: Phân tích, định nghĩa
các yêu cầu, Thiết kế, Cài đặt và kiểm thử đơn vị, Tích hợp và kiểm thử hệ thống, vận
hành và bảo trì được mô tả theo hình dưới đây:

Hình 1.2: Mô hình thác nước
Trong mô hình thác nước 5 pha trên phải được thực hiện một cách tuần tự, kết
thúc pha trước rồi mới thực hiện pha tiếp theo. Do đó, nhược điểm của mô hình thác
nước là rất khó khăn trong việc thay đổi các pha đã được thực hiện. Mô hình này chỉ

10


thích hợp khi các yêu cầu đã được tìm hiểu rõ ràng trong suốt quá trình thiết kế. Tuy
nhiên trong thực tế có rất ít các hệ thống nghiệp vụ có các yêu cầu ổn định.
 Mô hình mẫu (Prototype)

Hình 1.3: Mô hình mẫu

Đây là mô hình thường áp dụng trong giai đoạn đầu của các dự án phức tạp nhằm
làm rõ các yêu cầu cũng như cách thực hiện hóa các yêu cầu bằng cách tạo ra các mẫu
(Prototype). Việc này không những giúp tinh chỉnh yêu cầu, mà đồng thời giúp cho đội
phát triển hiểu hơn về những gì cần được phát triển. Tiếp theo giai đoạn làm prototype
này có thể là một chu trình thiết kế phần mềm nào đó sẽ được áp dụng.
 Mô hình phát triển ứng dụng nhanh (RAD)
Là mô hình được giới thiệu bởi IBM vào những năm 1980. Phát triển phần mềm
gia tăng, tăng dần từng bước với chu kì phát triển ngắn (60-90 ngày).

11


Hình 1.4: Mô hình phát triển ứng dụng nhanh RAD
Hạn chế của mô hình RAD:
• Cần nguồn nhân lực dồi dào để tạo nhóm cho các chức năng chính.
• Cần phải có sự thỏa thuận chặt chẽ giữa các bên tham gia, thiếu trách nhiệm
của bên nào dễ làm dự án đỗ vỡ.
• RAD sẽ bất khả thi với những ứng dụng không thể module hóa hoặc đòi hỏi
tính năng cao.
 Mô hình tiến hóa

Hình 1.5: Mô hình tiến hóa
Phần lớn các hệ thống, phần mềm phức tạp đều tiến hóa theo thời gian: môi
trường thay đổi, yêu cầu phát sinh thêm, hoàn thiện thêm chức năng, tính năng.

12


Các mô hình tiến hóa (Evolutionary models) có tính lặp lại. Kỹ sư phần mềm tạo
ra các phiên bản ngày càng hoàn thiện hơn, phức tạp hơn.

 Mô hình chữ V (V- models)
V Models là tên viết tắt của Verification Software Development Model: Mô hình
phát triển phần mềm xác minh, hay còn gọi là mô hình chữ V đó là mô hình gồm 5
giai đoạn chạy song song:

Hình 1.6: Mô hình chữ V
- Xác định yêu cầu (Requirement definition) và kiểm thử chấp nhận (acceptance
testing): Sau khi đã có yêu cầu của khách hàng, ta thực hiện đồng thời việc phân tích
yêu cầu và xây dựng bản kiểm thử cho người dùng (User Acceptance Testing) dựa trên
các yêu cầu đó.
- Thiết kế chức năng (Function system design) và kiểm thử hệ thống (System
testing): Vừa thực hiện thiết kế các chức năng cho hệ thống, vừa thực hiện xây dựng
các bản kiểm thử cho hệ thống (System testing).
- Thiết kế kiến trúc phần mềm (Architecture design) và kiểm thử tích hợp
(Intergration testing): Thực hiện thiết kế kiến trúc các module và kỹ thuật của hệ
thống, đồng thời xây dựng kịch bản test tích hợp.
- Thiết kế các module và kiểm thử mức đơn vị.
- Lập trình (Programming): Sau khi đã có thiết kế chi tiết thì tiến hành Coding.

13


 Mô hình Agile Scum
Là một quy trình phát triển phần mềm theo mô hình linh hoạt (agile) giúp việc
phát triển phần mềm trở nên nhanh chóng và dễ dàng.
Scum chia dự án thành các vòng lặp phát triển gọi là các sprint. Mỗi sprint
thường mất 2-4 tuần (30 ngày) để hoàn thành => Rất phù hợp với những dự án có
nhiều sự thay đổi và yêu cầu tốc độ cao.
Mỗi sprint hoàn thành một số chức năng, mục đích nào đó trong toàn bộ hệ
thống. Các tác vụ trong sprint được chia ra thành các danh mục, các đội làm việc sẽ

phát triển và đánh giá lại sao cho đạt được mục đích ban đầu đề ra.
Thành phần chính quan trọng của scrum là các Role và các cuộc trao đổi đánh giá
(Meeting).
• Product Owner: Là những người làm những công việc bắt đầu cho một dự
án, tạo ra các yêu cầu trong quá trình phát triển dự án. Phân tích mục tiêu, giải phóng
các kế hoạch.
• Scrum Master: Là người đảm bảo các sprint được hoàn thành đúng mục đích,
bảo vệ đội làm việc và loại bỏ các trở ngại.
• Đội làm việc ở Scrum: Thường từ 5-9 người, tùy theo yêu cầu dự án mà có
thể có nhiều đội, nhiều người tham gia. Sẽ không có những lập trình viên, người thiết
kế hay kiểm thử viên..như thường thấy ở các mô hình truyền thống. Các đội sẽ tiến
hành cài đặt các chức năng sao cho hiệu quả lớn nhất. Tất cả các thành viên sẽ có ảnh
hưởng như nhau đến sự thành công hoặc thất bại của toàn bộ hệ thống.

Hình 1.7: Mô hình Agile Scrum
14


1.2. Kiểm thử phần mềm
1.2.1. Khái niệm kiểm thử phần mềm
Kiểm thử phần mềm là một quy trình nhằm đảm bảo độ tin cậy và chất lượng của
phần mềm. Mục đích của kiểm thử phần mềm là chỉ ra rằng phần mềm thực hiện đúng
các chức năng mà khách hàng mong muốn.
Có 02 loại kiểm thử phần mềm:
• Kiểm thử phần mềm thủ công (Manual Testing).
• Kiểm thử tự động (Automation Testing).
Mục tiêu của kiểm thử phần mềm:
• Phát hiện ra các nhiều lỗi (bug) càng tốt trong thời gian kiểm thử xác định trước.
• Chứng minh rằng sản phẩm phần mềm phù hợp với các đặc tả yêu cầu của nó.
• Tạo ra các testcase chất lượng nhằm tìm ra lỗi (nếu có) với chi phí thấp nhất.

Ai là người kiểm thử?
Trong hầu hết các trường hợp, người kiểm thử (Tester) có thể là:
• Software Tester: Nhân viên kiểm thử phần mềm.
• Software Developer: Nhân viên phát triển phần mềm.
• Leader hoặc Manager của dự án.
• Product Owner: Người sở hữu sản phẩm (Acceptance Testing)
• End-User: Người dùng cuối.
Các vai trò trong kiểm thử phần mềm:
• Test Manager: Là người đứng đầu bộ phận kiểm thử, quản lý chung về các vấn
đề liên quan như quy trình làm việc, nhân sự…
• Test Leader: Là người trực tiếp tham gia vào quá trình kiểm thử dự án cùng
với tester. Test leader đảm nhiệm vai trò quản lý công việc của tester, thực hiện xác
nhận các sản phẩm mà tester tạo ra cũng như báo cáo test manager khi có yêu cầu.
• Tester /QC: Là người trực tiếp thực hiện quá trình kiểm thử, đảm bảo chất
lượng của sản phẩm theo những nhiệm vụ được phân công.
1.2.2. Các mức kiểm thử
Có 05 mức kiểm thử phần mềm cơ bản có thể áp dụng trong hầu hết các loại ứng
dụng phần mềm:

15


1. Unit Test (Kiểm thử mức đơn vị lập trình): Là mức kiểm thử tập trung vào
việc xác minh trên các đơn vị nhỏ nhất của thiết kế phần mềm. Sử dụng các mô tả thiết
kế thủ tục để phát hiện lỗi trong phạm vi Module/Function.
2. Module/Fuction Test (Kiểm thử mức chức năng): Là mức kiểm thử tập trung
kiểm tra, xác minh xem một chức năng trong chương trình có hoạt động đúng như nó
được thiết kế hay không?
3. Integration Test (Kiểm thử mức tích hợp): Là mức kiểm thử tập trung kiểm
tra, xác minh các thành phần trong phần mềm có tương tác được với nhau hay không,

có hoạt động phối hợp với nhau được hay không?
4. System Test (Kiểm thử mức hệ thống): Là mức kiểm thử nhằm đưa hệ thống
vào vận hành thử nghiệm tại các môi trường khác nhau nhằm tìm ra các lỗi về hệ
thống, tính tương thích..
5. Acceptance Test (Kiểm thử chấp nhận):Là mức kiểm thử được thực hiện ở
phía người sử dụng, đây được xem là kiểm thử chấp nhận sản phẩm.
1.2.3. Các phương pháp kiểm thử
 Phương pháp kiểm thử hộp đen
Hay còn gọi là kiểm thử hướng dữ liệu. Là phương pháp kiểm thử không quan
tâm tới cấu trúc bên trong của phần mềm (cấu trúc dữ liệu, thuật toán, xử lý..) mà chỉ
kiểm tra dữ liệu đầu vào, dữ liệu đầu ra ứng với các trường hợp trong đặc tả
(Testcase).

Hình 1.8: Phương pháp kiểm thử hộp đen

16


Kiểm thử hộp đen không có “mối ràng buộc” nào với code và nhận thức của một
tester rất đơn giản: một source code có nhiều lỗi =>Các tester sẽ tìm thấy được nhiều
lỗi nơi mà Developer không tìm thấy.
Quy trình kiểm thử hộp đen tổng quát:
• Phân tích đặc tả về các yêu cầu chức năng mà một thành phần phần mềm cần
thực hiện.
• Dùng các kĩ thuật xác định các testcase để định nghĩa ra các testcase. Định
nghĩa testcase là việc xác định 3 thông tin sau:
o Giá trị dữ liệu nhập vào thành phần phần mềm (hợp lệ hoặc không hợp lệ).
o Trạng thái của thành phần phần mềm cần có để thực hiện testcase.
o Giá trị dữ liệu xuất ra mà thành phần phần mềm phải tạo được.
• Kiểm thử các testcase đã định nghĩa.

• So sánh kết quả thu được với kết quả kì vọng trong từng testcase, từ đó lập
báo cáo về kết quả kiểm thử.
 Phương pháp kiểm thử hộp trắng
Là phương pháp kiểm thử dựa vào giải thuật cụ thể, cấu trúc dữ liệu bên trong
của đơn vị phần mềm cần kiểm thử để xác định đơn vị phần mềm đó có thực hiện đúng
hay không?

Hình 1.9: Phương pháp kiểm thử hộp trắng
Để thực hiện được phương pháp kiểm thử hộp trắng thì người kiểm thử phải có
kỹ năng, kiến thức nhất định về ngôn ngữ lập trình được dùng, về giải thuật được dùng
trong thành phần phần mềm để có thể thông hiểu được chi tiết về các đoạn code cần
kiểm thử.

17


 Phương pháp kiểm thử hộp xám
Là phương pháp kiểm thử kết hợp giữa phương pháp kiểm thử hộp đen và phương
pháp kiểm thử hộp trắng. Phương pháp kiểm thử hộp đen dùng để xác định nguồn gây ra lỗi
còn phương pháp kiểm thử hộp trắng xác định xem lỗi đang gặp là lỗi gì.

Hình 1.10: Phương pháp kiểm thử hộp xám
1.2.4. Các loại kiểm thử
 Kiểm thử cài đặt (Installing Testing)
Sau khi chương trình được lập trình xong, để đảm bảo tính toàn vẹn trong việc
phân phối ứng dụng tới người sử dụng, chương trình cần được đóng gói thành các file
cài đặt. Kiểm thử cài đặt là loại kiểm thử kiểm tra xem quá trình cài đặt ứng dụng từ
file đóng gói (package) có tốt không? Có làm được việc trên cấu hình phần cứng của
khách hay không?
 Kiểm thử Smoke (Smoke Testing)

Đây là loại kiểm thử sơ lược hệ thống ngay sau khi cài đặt xem có xảy ra vấn đề
gì nghiêm trọng hay không? Loại kiểm thử này là kiểm thử sơ lược hệ thống, không đi
sâu vào chi tiết các chức năng.
 Kiểm thử chức năng (Function Testing)
Là hoạt động kiểm thử nhằm xác minh xem các chức năng, hoạt động của
chương trình có hoạt động theo đúng như đặc tả được hay không? Phần lớn công việc
của người tester thuộc loại kiểm thử này.

18


 Kiểm thử hồi quy (Regression Testing)
Là loại kiểm thử tập trung vào việc tìm kiếm lỗi sau khi có một sự thay đổi lớn
đã xảy ra nhằm khám phá hồi quy phần mềm xem các lỗi cũ có xuất hiện hay không?
Để thực hiện điều này người tester cần thực hiện kiểu test lặp đi lặp lại các vấn đề gọi
là hồi quy.
 Kiểm thử chấp nhận (Acceptance Testing)
Chấp nhận thử nghiệp được thực hiện bởi khách hàng, còn được gọi là User
Acceptance Testing (UAT). Chấp nhận thử nghiệm có thể được thực hiện như một
phần của quá trình bàn giao giữa bất kỳ hai giai đoạn phát triển.
 Kiểm thử Alpha (Alpha Testing)
Đây là loại kiểm thử được áp dụng nhằm mục đích mô phỏng thực tế hoặc kiểm
thử hoạt động của nhóm người dùng tiềm năng. Đội phát triển sẽ tạo ra một phân bản
(có thời gian hoạt động) và phân phối phiên bản này cho đông đảo người dùng (trong
nội bộ công ty, tập đoàn) sử dụng nhằm tìm ra lỗi trong quá trình sử dụng. Phiên bản
phần mềm này được gọi là Alpha version.
 Kiểm thử Beta (Beta Testing)
Cũng giống như Alpha Testing, nhưng loại test này được áp dụng ở mức độ cao
hơn, rộng hơn. Đội phát triển sẽ tạo ra phiên bản Beta của phần mềm, và phân phối sản
phẩm này cho một nhóm có quy mô rộng lớn (một tỉnh, một quốc gia, một châu lục…)

cùng sử dụng rộng rãi nhằm thu thập những đóng góp hoặc tìm ra lỗi.
 Kiểm thử hiệu năng (Performace Testing)
Kiểm tra thời gian đáp ứng lại người dùng ứng với số lượng người dùng bất kì
trong nhiều ngữ cảnh khác nhau của cùng một ứng dụng tại cùng một thời điểm.
 Kiểm thử bảo mật (Security Testing)
Là quá trình xác định các lỗ hổng bảo mật trong ứng dụng bằng cách đánh giá hệ
thống hoặc mạng với kỹ thuật độc hại khách nhau.
 Kiểm thử tính khả dụng (Usability Testing)
Đây là loại kiểm thử các vấn đề phi chức năng liên quan tới tính tiện dụng, dễ sử
dụng của ứng dụng.

19


1.3. Quy trình kiểm thử phần mềm (STLC)
Software Testing Life Cycle đề cập đến một quy trình Test (Testing process)
trong đó các bước cụ thể được thực hiện theo một trình tự nhất định để đảm bảo mục
tiêu chất lượng được đáp ứng. Trong quy trình kiêm thử phần mềm mỗi hoạt động
được thực hiện một cách có kế hoạch và hệ thống. Mỗi một giai đoạn có các mục tiêu
khác nhau.

Hình 1.11: Quy trình kiểm thử phần mềm
Requirement Analysis (giai đoạn tìm hiểu và phân tích yêu cầu): Đây là giai
đoạn tiếp cận dự án được thực hiện bởi toàn bộ team (project manager, developer,
tester, QA…) cùng tham gia để phân tích các nghiệp vụ trong SRS thành các đơn vị
chức năng của chương trình cần xây dựng.
Test Planning (giai đoạn lập kế hoạch): Đây là giai đoạn được thực hiện bởi
Test Manager/ Test Leader, dựa vào các đặc tả SRS đã phân tích, phối hợp cùng
project manager lập lên kế hoạch test cho dự án (Thời gian thực hiện, nhân lực, các
phương pháp/kỹ thuật sẽ áp dụng, môi trường kiểm thử…).

Testcase Development (giai đoạn lập các trường hợp kiểm thử): Sau khi có test
plan, đội ngũ tester bắt đầu vào giai đoạn thiết kế các trường hợp kiểm thử cho các
chức năng trong dự án, sau khi testcase được thiết kế xong sẽ được test leader, test
manager phê duyệt để đưa vào giai đoạn thực hiện test sau này.
Environment Setup (giai đoạn thiết lập môi trường kiểm thử): Sau khi hoàn
thành xong giai đoạn thiết kế các trường hợp kiểm thử, đội test sẽ tiếp tục chuẩn bị các
môi trường kiểm thử (hệ điều hành, browser, thiết bị…) để sẵn sàng đưa sản phẩm vào
thực hiện test sau khi hoàn thành xong.

20


Test Execution (giai đoạn thực hiện test): Sau khi dự án hoàn thành được 70%
thì đội test bắt đầu đưa sản phẩm vào thực hiện test vòng 1(test sơ bộ, vừa test vừa
thực hiện nghiệp vụ). Vòng 2 sẽ bắt đầu ngay sau khi sản phẩm hoàn thành 100%
(Test hết tất cả các testcase đã thiết kế và tiến hành log bug vào hệ thống). Vòng 03 sẽ
bắt đầu khi những bug mà tester tìm ra ở vòng test thứ 2 được xử lý hết và đội lập trình
triển khai phiên bản mới.
Chú ý: Số vòng test có thể nhiều hơn hoặc ít hơn tùy thuộc vào quy mô cũng như
yêu cầu của dự án.
Test Cycle Closure (giai đoạn kết thúc): Sauk hi dự án thỏa mãn các tiêu chí về
chất lượng, test leader/test manager tiến hành xác minh, tổng kết quá trình test để sẵn
sàng ra mắt cho khách hàng. Đội test sẽ tiến hành lập báo cáo kiểm thử cho quản lý
trực tiếp phục vụ cho việc làm tài liệu dự án gửi cho khách hàng. Tiếp theo đó, đội test
có thể sẽ tiếp tục làm hướng dẫn sử dụng hoặc tài liệu triển khai phần mềm.
1.4. Kế hoạch kiểm thử (test plan)
Là một bản tài liệu mô tả các mục tiêu, phạm vi, phương pháp tiếp cận và tập
trung vào nỗ lực kiểm thử phần mềm.
Quá trình chuẩn bị test plan là một cách hữu ích để suy nghĩ tới những nỗ lực cần
thiết để xác định xem khả năng chấp nhận của một sản phẩm phần mềm. Các tài liệu

sẽ giúp mọi người bên ngoài nhóm test hiểu được “tại sao” và “như thế nào” để chấp
nhận sản phẩm.
Các mục được bao gồm trong một Test Plan:
• Tiêu đề
• Định nghĩa các phiên bản của Test Plan (Lưu lại quá trình hiệu chỉnh, tác giả,
ngày cập nhật, người duyệt…).
• Mục lục các nội dung.
• Giới thiệu chung (Mục đích của tài liệu, tổng quan, phạm vi, các định
nghĩa/viết tắt, đối tượng sử dụng tài liệu).
• Tài liệu tham khảo.
• Lịch trình công việc (chi tiết cho từng người).
• Những yêu cầu về tài nguyên (Phần cứng, phần mềm, công cụ kiểm thử, môi
trường kiểm thử, nhân sự, vai trò trách nhiệm, đào tạo…).

21


• Phạm vi kiểm thử (Những chức năng được kiểm thử, những chức năng không
được kiểm thử).
• Chiến lược kiểm thử (chiến lược, các loại kiểm thử áp dụng).
• Điều kiện chấp nhận.
• Các rủi ro có thể gặp phải của dự án.
• Phân loại lỗi/ Quy trình xử lý lỗi.
• Test deliverables
1.5. Thiết lập môi trường kiểm thử
1.5.1. Khái niệm môi trường kiểm thử
Môi trường kiểm thử là môi trường thực thi ứng dụng sao cho gần giống với
người dùng nhất (Thông số phần cứng, phần mềm, hệ điều hành….).
Việc thiết lập môi trường kiểm thử giống với người dùng luôn là một thách thức
rất lớn đối với một người kiểm thử do đó trong thực tế những nhân viên kiểm thử

thường xây dựng một số môi trường mang tính đặc trưng chung để thực thi phần mềm
thay vì phải xây dựng giả lập chính xác những gì mà người dùng sử dụng.
Việc thiết lập môi trường giống với môi trường của người dùng thường được bắt
buộc phải thực hiện khi có lỗi mà khách hàng gửi về và ảnh hưởng tới nghiệp vụ phần
mềm. Khi đó cần phải sử dụng mọi nguồn nhân lực để có thể tiến hành dựng được lỗi
=> Giúp lập trình viên xử lý.
1.5.2. Thiết lập môi trường kiểm thử
Là quá trình xây dựng, thiết lập các cấu hình thiết bị, hệ điều hành giống với thiết
bị, hệ điều hành của người sử dụng với mục đích thực thi ứng dụng nhằm tìm ra lỗi
hoặc tái hiện lại lỗi mà người dùng đã gặp phải.
Việc người dùng sử dụng thiết bị như thế nào, luôn là ẩn số đối với những nhà
phát triển phần mềm. Vậy nên để trang bị những thiết bị phần cứng là một điều rất khó
khăn. Hơn nữa việc trang bị các thiết bị luôn đòi hỏi tiêu tốn một chi phí lớn. Do đó,
để có thể thực hiện được điều này, người ta sử dụng các phần mềm hỗ trợ giả lập tạo
môi trường thực thi phần mềm ví dụ như: Virtual Box, Virtual PC, VMWare….

22


1.6. Testcase, kỹ thuật thiết kế testcase
1.6.1. Khái niệm về testacase
Testcase trong kiểm thử phần mềm là một tập hợp các điều kiện được sử dụng để
xác định xem một ứng dụng đang làm việc tốt hay không? Trường hợp kiểm thử có thể
là tích cực hay tiêu cực.
Trường hợp kiểm thử tích cực được thiết kế để kiểm tra xem ứng dụng có hoạt
động như cách mà nó được dự kiến sẽ hoạt động hay không? Trong khi các trường hợp
kiểm thử tiêu cực được thiết kế để kiểm tra cách hệ thống phản ứng với chuỗi bất
thường của các hành động hoặc giá trị bất ngờ.
Một yêu cầu kiểm thử trong một ứng dụng phải có ít nhất hai trường hợp kiểm
thử - một tích cực và một tiêu cực.

Mục đích sử dụng:
• Tạo ra các ca kiểm thử tốt nhất có khả năng phát hiện ra lỗi, sai sót của phần
mềm một cách nhiều nhất.
• Tạo ra các ca kiểm thử có chi phí rẻ nhất, đồng thời tốn ít thời gian và công
sức nhất.
• Giúp người tester ít kinh nghiệm có thể biết những việc cần làm để đảm bảo
chất lượng của phần mềm.
• Giúp nhà quản lí dự án biết được chức năng nào có lỗi, chức năng nào lỗi
nhiều, lỗi ít.
1.6.2. Các kỹ thuật thiết kế testcase
 Kỹ thuật phân vùng tương đương (Equivalence Partitioning)
Là phương pháp chia các điều kiện đầu vào thành những vùng tương đương
nhau. Tất cả các giá trị trong một vùng tương đương sẽ cho một kết quả đầu ra giống
nhau. Vì vậy chúng ta có thể test một giá trị đại diện trong vùng tương đương.

23


Hình 1.12: Kỹ thuật phân vùng tương đương
Thiết kế testcase bằng kỹ thuật phân vùng tương đương tiến hành theo 2 bước:
• Xác định các lớp tương đương.
• Xác định các ca kiểm thử.
Ưu điểm: Vì mỗi vùng tương đương ta chỉ cần test trên các phần tử đại diện nên
số lượng testcase được giảm đi khá nhiều nhờ đó mà thời gian thực hiện test cũng
giảm đáng kể.
Nhược điểm: Không phải với bất kì bài toán nào cũng đều có thể áp dụng kỹ thuật
này. Có thể bị hack lỗi ở biên nếu chỉ chọn giá trị ở khoảng giữa của miền tương đương.
 Kỹ thuật phân tích giá trị biên (Boundary – Value- Analysis)
Là trường hợp đặc biệt của phân vùng tương đương, dựa trên những phân vùng
tương đương, tester sẽ xác định giá trị biên giữa những phân vùng này và lựa chọn

testcase phù hợp. Các Case chuẩn được lựa chọn dựa vào quy tắc sau:
• Giá trị biên nhỏ nhất -1.
• Giá trị biên nhỏ nhất.
• Giá trị biên lớn nhất.
• Giá trị biên lớn nhất +1.
Trong một số trường hợp muốn kiểm tra sâu hơn thì ta cũng có thể lựa chọn thêm
2 quy tắc: giá trị biên nhỏ nhất +1 và giá trị biên lớn nhất -1

24


Hình 1.13: Kỹ thuật phân tích giá trị biên
Ưu điểm: Thay vì phải test toàn bộ các giá trị trong từng vùng tương đương, kỹ
thuật phân tích giá trị biên tập trung vào việc kiểm thử các giá trị biên của miền giá trị
Inputs để thiết kế testcase do “lỗi thường tiềm ẩn tại các ngõ ngách và tập hợp tại
biên”. Tiết kiệm thời gian thiết kế testcase và thực hiện test.
Nhược điểm: Phương pháp này chỉ hiệu quả trong trường hợp các đối số đầu vào
(input variables) độc lập với nhau và một đối số đều nằm trong miền giá trị hữu hạn.
 Kỹ thuật đoán lỗi (Error Guessing)
Phương pháp này không có quy trình cụ thể vì có tính trực giác cao và không thể
dự đoán trước.
Phương pháp chỉ phù hợp cho những Tester có kinh nghiệm. Họ được đưa cho
một chương trình, họ phỏng đoán dựa vào trực giác, dựa vào kinh nghiệm, dữ liệu lịch
sử về các lỗi đã từng xảy ra với chương trình trước đó… và sau đó viết ra các ca kiểm
thử để đưa ra những lỗi đó.
 Kỹ thuật bảng quyết định (Decision Table)
Là phương pháp chính xác và tối ưu để mô hình hóa các điều kiện logic phức tạp.
Điều kiện là các biểu thức rút ra từ việc rẽ nhánh trong chương trình, như lệnh if,
while, switch…
Cấu trúc của bảng quyết định như sau:

Các điều kiện (nguyên nhân)

Các giá trị của các trường hợp

………

………

Kết quả

Các hành động ứng với từng trường hợp

Mối liên hệ giữa các điều kiện tương ứng với các kết quả sẽ cho biết hành động
nào sẽ được thực hiện khi các điều kiện tương ứng thỏa mãn.

25