Kỹ thuật kiểm thử hồi quy ứng dụng trong phát triển các ứng dụng trên điện thoại thông minh

NGUYỄN TRỌNG HÀ

BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
---------------------------------------

Nguyễn Trọng Hà

KỸ THUẬT PHẦN MỀM

KỸ THUẬT KIỂM THỬ HỒI QUY ỨNG DỤNG
TRONG PHÁT TRIỂN CÁC ỨNG DỤNG TRÊN
ĐIỆN THOẠI THÔNG MINH

LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM
…......................................

KHÓA 14B

Hà Nội – 2017


BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
---------------------------------------

Nguyễn Trọng Hà

KỸ THUẬT KIỂM THỬ HỒI QUY ỨNG DỤNG
TRONG PHÁT TRIỂN CÁC ỨNG DỤNG TRÊN
ĐIỆN THOẠI THÔNG MINH

Chuyên ngành : Kỹ thuật phần mềm
LUẬN VĂN THẠC SĨ KỸ THUẬT
…......................................

NGƯỜI HƯỚNG DẪN KHOA HỌC :
TS. PHAN THANH HÙNG

Hà Nội – 2017


LỜ I CAM ĐOAN
Tơi xin cam đoan những gì tơi viết dưới đây là hồn tồn chính thống
khơng sao ché p, những kết quả đo đạc mô phỏ ng có trong luận văn chưa
từ ng đươ c̣ công bố từ bất cứ tài liệu nào dưới mọi hình thức. Cá c thông tin
sử du ṇ g trong luâ ̣n văn có nguồ n gố c và đươ c̣ tri ́ c h dẫ n ro ̃ rà ng.
Tơi xin hồn tồn chịu trách nhiệm nếu có dấu hiệu sao chép kết quả
từ các tài liệu khác.
HỌC VIÊN

NGUYỄN TRỌNG HÀ


LỜI CẢM ƠN
Lời đầu tiên tôi xin chân thành cảm ơn các thầy cô trong Bộ môn
Công nghệ phần mềm - Viện Công nghệ thông tin và truyền thông - Đại học
Bách khoa Hà Nội. Đặc biệt TS. Nguyễn Thanh Hùng, người đã hướng
dẫn vơ cùng tận tình, tâm huyết để tơi có thể hồn thành luận văn này.
Ngoà i ra, tôi cũ ng xin bà y tỏ lò ng biế t ơn sâu sắ c đế n gia đi ̀ n h, ba ̣n
bè , nhữ ng ngườ i đa ̃ luôn ủ ng hô ̣ tôi trong suố t quá tri ̀ n h ho c̣ tâ ̣p và hoà n

thà nh chương tri ̀ n h đà o ta ̣o Tha ̣c sy ̃ Kỹ thuật ta ̣i Viện Công nghệ thông tin
và Truyền thông, Đa ̣i ho c̣ Bách khoa Hà Nội.
Mă ̣c dù tôi đa ̃ nỗ lư c̣ và cố gắ ng hoà n thiê ̣n luâ ̣n văn bằ ng tấ t cả
nhiê ̣t ti ̀ n h và năng lư c̣ củ a mi ̀ n h, tuy nhiên không thể trá nh khỏ i nhữ ng
thiế u só t, rấ t mong nhâ ̣n đươ c̣ nhữ ng đó ng gó p quý bá u củ a quý thầ y cô
và cá c ba ̣n.
Tôi xin chân thà nh cả m ơn.
HỌC VIÊN

NGUYỄN TRỌNG HÀ


MỤC LỤC
LỜI MỞ ĐẦU ...................................................................................................................
CHƯƠNG 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM .........................................5
1.1. Kiểm thử phần mềm ................................................................ 5
1.2. Một số khái niệm .................................................................... 6
1.3. Phương pháp kiểm thử ............................................................ 8
1.4. Các mức kiểm thử ................................................................. 12
1.5. Quy trình kiểm thử ............................................................... 15
1.6. Kiểm thử tự động ................................................................. 16
1.7. Tổng kết chương ................................................................... 19
CHƯƠNG 2. KIỂM THỬ HỒI QUY ỨNG DỤNG DI ĐỘNG ...................................20
2.1. Ứng dụng trên các thiết bị di động (Mobile application) .......... 20
2.2. Kiểm thử ứng dụng cho thiết bị di động ................................. 21
2.3. Kỹ thuật kiểm thử hồi quy trong ứng dụng di động ................. 23
2.4. Qui trình kiểm thử hồi quy .................................................... 24
2.5. Các vấn đề nên kiểm thử hồi quy ........................................... 26
2.6. Công cụ hỗ trợ kiểm thử hồi quy ứng dụng di động ................. 28
2.7. Tổng kết chương ................................................................... 29

CHƯƠNG 3. CÔNG CỤ KIỂM THỬ HỒI QUY ÁP DỤNG CHO ỨNG DỤNG
TRÊN ĐIỆN THOẠI THƠNG MINH ......................................................................30
3.1. Cơng cụ kiểm thử Robotium .................................................. 30
3.2. Công cụ kiểm thử Selendroid................................................. 33
3.3. Công cụ kiểm thử Appium ..................................................... 38
3.4. Công cụ kiểm thử Selenium ................................................... 40
3.5. Áp dụng thiết kế ứng dụng Adapter kiểm thử .......................... 43
3.5.1. Thiết kế chương trình ......................................................... 44
3.5.2. Kiểm thử và kết quả ........................................................... 51
3.6. Tổng kết chương ................................................................... 58
CHƯƠNG 4. KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN ..............................................60
4.1. KẾT LUẬN .......................................................................... 60


4.2. HƯỚNG PHÁT TRIỂN CỦA ĐỀ TÀI ..................................... 61
TÀI LIỆU THAM KHẢO .............................................................................................62

DANH MỤC BẢNG
Bảng 1. 1 Chi phí triển khai bảo trì phần mềm [2] .....................................8
Bảng 2. 1 Danh sách các công cụ kiểm thử hồi quy[10] .........................29
Bảng 3. 1 Bảng so sánh của Appium[16] ...................................................39


DANH MỤC HÌNH
Hình 1. 1 Chi phí triển khai bảo trì phần mềm [2] .....................................8
Hình 1. 2 Kỹ thuật kiểm thử hộp trắng [5] .................................................10
Hình 1. 3 Kỹ thuật kiểm thử hộp đen [5] .................................................... 11
Hình 1. 4 Kỹ thuật kiểm thử hộp xám [5] ...................................................12
Hình 1. 5 Quy trình kiểm thử phần mềm [9] ..............................................15
Hình 2. 1 Các lĩnh vực ứng dụng mobile [12] ...........................................20

Hình 2. 2 Các loại ứng dụng mobile[11] .....................................................21
Hình 2. 3 Các kỹ thuật thực hiện hồi quy [4] ............................................23
Hình 2. 4 Qui trình tổng quát cho kiểm thử hồi quy ................................24
Hình 2. 5 Kiểm thử hồi quy trong phương pháp phát triển Agile[11] ..25
Hình 3. 1 Danh sách các các lớp của Robotium hỗ trợ kiểm thử [17] ..31
Hình 3. 2 Các bước thực hiện kiểm thử Robotium [17] ..........................31
Hình 3. 3 Kiến trúc của Selendroid[19]. .....................................................34
Hình 3. 4 Đặc điểm của Appium ...................................................................38
Hình 3. 5 Giao diện cơng cụ Appium ...........................................................40
Hình 3. 6 Cấu trúc cơng cụ Selenium[18] ..................................................40
Hình 3. 7 Sử dụng Appium và Selenium cho kiểm thử [16] ..................43
Hình 3. 8 Mơ hình đặc tả ứng dụng cho kiểm thử hồi quy......................44
Hình 3. 9 Giao diện của ứng dụng Adapter Test Smartphone ................45


LỜI MỞ ĐẦU
Kiểm thử phần mềm khơng cịn là một vấn đề mới và tầm quan trọng
của nó thì lại càng không thể bàn cãi. Một phần mềm tốt là một phần mềm
đã được đánh giá tốt từ nhà phát triển đến người sử dụng cuối.
Thời đại hiện nay, với sự bùng nổ về số lượng ứng dụng đặc biệt là
những ứng dụng trên đa nền tảng. Với số lượng ứng dụng như vậy thì cuộc
chạy đua giữa những nhà phát triển đã chuyển dần từ tìm những ý tưởng
mới sang làm thế nào để cải thiện, cải tiến những ứng dụng có sẵn, sao cho
có thể đáp ứng được nhu cầu trải nghiệm ngày càng cao của người dùng.
Với những lí do trên, đề tài đã tìm hiểu và trình bày một số phương
pháp nâng cao hiệu quả kiểm thử của ứng dụng, từ đó có thể áp dụng
phương pháp kiểm thử hồi quy một cách phù hợp vào ứng dụng cụ thể.
Nội dung luận văn “Kỹ thuật kiểm thử hồi quy ứng dụng trong phát
triển các ứng dụng trên điện thoại thông minh” gồm các phần sau:
Chương 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM

Chương 2. KIỂM THỬ HỒI QUY ỨNG DỤNG DI ĐỘNG
Chương 3. CÔNG CỤ KIỂM THỬ HỒI QUY ÁP DỤNG CHO ỨNG
DỤNG TRÊN ĐIỆN THOẠI THƠNG MINH
Chương 4. KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN
Để có thể hồn thành luận văn này, tơi chân thành cảm ơn TS. Nguyễn
Thanh Hùng và các thầy, cô tại Trường Đại học Bách Khoa - Hà Nội đã
nhiệt tình giúp đỡ trong suốt quá trình thực hiện luận văn. Tuy đã cố gắng
hết sức, nhưng do thời gian và kiến thức cịn hạn chế nên luận văn khơng
tránh khỏi sai sót, tơi rất mong sự bổ sung, góp ý của các thầy cô!
HỌC VIÊN

NGUYỄN TRỌNG HÀ


CHƯƠNG 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
1.1. Kiểm thử phần mềm
Kiểm thử phần mềm là một hoạt động kiểm tra để cung cấp cho các bên
liên quan thông tin về chất lượng của sản phẩm hoặc dịch vụ được kiểm
thử. Kiểm thử có thể cung cấp cho doanh nghiệp một quan điểm, một cách
nhìn độc lập về phần mềm để từ đó cho phép đánh giá và thấu hiểu được
những rủi ro trong quá trình triển khai phần mềm.
Trong kỹ thuật kiểm thử không chỉ giới hạn ở việc thực hiện một
chương trình hoặc ứng dụng với mục đích đi tìm các lỗi phần mềm (bao
gồm các lỗi và các thiếu sót) mà cịn là một q trình phê chuẩn và xác
minh một chương trình máy tính [1], ứng dụng, sản phẩm nhằm:
 Đáp ứng được mọi yêu cầu đặc tả khi thiết kế và phát triển phần mềm.
 Thực hiện cơng việc đúng như kỳ vọng.
 Có thể triển khai được với những đặc tính tương tự.
 Và đáp ứng được mọi nhu cầu của các bên liên quan.
Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện

bất cứ lúc nào trong quá trình phát triển phần mềm. Theo qui trình phát
triển phần mềm truyền thống (waterfall process) thì các hoạt động kiểm thử
được tiến hành sau khi các yêu cầu được xác định và việc lập trình được
hồn tất nhưng trong mơi trường phát triển linh hoạt (Agile) thì việc kiểm
thử được tiến hành liên tục trong suốt quá trình xây dựng phần mềm. Như
vậy, mỗi một phương pháp kiểm thử bị chi phối theo một quy trình phát
triển phần mềm nhất định.
Kiểm thử khơng thể xác định hồn tồn được tất cả các lỗi bên trong
phần mềm. Thay vào đó, nó so sánh trạng thái và hành vi của sản phẩm với
các nguyên tắc hay cơ chế để phát hiện vấn đề. Các ngun tắc này có thể
bao gồm (nhưng khơng giới hạn) các đặc tả phần mềm, hợp đồng, sản phẩm
tương đương, các phiên bản trước của cùng một sản phẩm, phù hợp với
mục đích dự kiến nhằm đáp ứng sự kỳ vọng của người dùng, khách hàng,
quy định của pháp luật hiện hành và các tiêu chuẩn liên quan khác [2].
Phạm vi của kiểm thử phần mềm thường bao gồm việc kiểm tra mã lệnh,
thực hiện các mã lệnh trong môi trường và điều kiện khác nhau, và việc
kiểm thử các khía cạnh của mã lệnh, có làm đúng nhiệm vụ của chương
trình hay khơng, và chương trình có làm những gì cần phải làm hay khơng.
5


Trong môi trường phát triển phần mềm hiện nay, một đội kiểm thử có thể
tách biệt với đội phát triển. Các thành viên trong đội kiểm thử giữ các vai
trò khác nhau. Các thông tin thu đư ợc từ kiểm thử có thể được sử dụng để
điều chỉnh q trình phát triển phần mềm .
Mỗi sản phẩm phần mềm có một đối tượng phục vụ riêng. Ví dụ như đối
tượng của phần mềm trị chơi điện tử là hồn tồn khác với đối tượng của
phần mềm ngân hàng. Vì vậy, khi một tổ chức phát triển hoặc đầu tư vào
một sản phẩm phần mềm, họ có thể đánh giá liệu các sản phẩm phần mềm
có được chấp nhận bởi người dùng cuối, đối tượng phục vụ, người mua,

hay những người giữ vai trị quan trọng khác hay khơng. Và việc kiểm thử
phần mềm là một quá trình nỗ lực để đưa ra những đánh giá này.
1.2. Một số khái niệm
Khiếm khuyết (defect) và lỗi (failure)
Không phải tất cả các khiếm khuyết của phần mềm bị gây ra bởi lỗi lập
trình mà nguồn gốc chung của các khiếm khuyết đó nằm ở những thiếu sót
trong u cầu; Ví dụ, u cầu không được xác nhận mà gây ra lỗi là sự sơ
suất của các nhà thiết kế của chương trình. Những thiếu sót yêu cầu thường
thấy trong những yêu cầu phi chức năng như là khả năng kiểm thử, khả
năng mở rộng, bảo trì, tính khả dụng, hiệu suất, và khả năng bảo mật [5].
Lỗi phần mềm xảy ra trong suốt quá trình như sau: Một lập trình viên
tạo ra một lỗi (sai lầm), mà kết quả cho ra là một khiếm khuyết (thất bại,
sai sót) trong mã nguồn phần mềm. Nếu lỗi này được thực hiện, trong
những tình huống nhất định hệ thống sẽ tạo ra kết quả sai, gây ra một sự
thất bại (failure). Không phải tất cả các khiếm khuyết nhất thiết sẽ dẫn đến
lỗi nghiêm trọng. Ví dụ, lỗi trong mã chết sẽ không bao giờ dẫn đến thất
bại. Lỗi có thể biến thành một sự thất bại khi mơi trường thay đổi. Ví dụ về
những thay đổi trong môi trường bao gồm các phần mềm đang chạy trên
một nền tảng phần cứng máy tính mới, thay đổi trong nguồn dữ liệu, hoặc
tương tác với các phần mềm khác nhau. Một khiếm khuyết duy nhất có thể
dẫn đến một loạt các dấu hiệu thất bại.
Một vấn đề rất cơ bản với kiểm thử phần mềm là việc kiểm thử tất
cả các kết nối đầu vào và điều kiện tiền đề (trạng thái ban đầu) là không
khả thi, ngay cả với một sản phẩm đơn giản. Điều này có nghĩa rằng số
lượng các khiếm khuyết trong một sản phẩm phần mềm có thể rất lớn và có
thể xảy ra khơng thường xun nên rất khó để tìm thấy trong quá trình
6


kiểm thử. Quan trọng hơn, những yêu cầu phi chức năng về chất lượng như:

tính khả dụng, khả năng mở rộng, hiệu suất, khả năng tương thích, độ tin
cậy nếu xét về mặt chủ quan thì nó chưa tạo nên giá trị đủ để mọi người có
thể chấp nhận được nó.
Các nhà phát triển phần mềm khơng thể kiểm thử được tất cả mọi thứ,
nhưng họ có thể sử dụng tổ hợp thiết kế kiểm thử để xác định số lượng tối
thiểu của các kiểm thử cần thiết để bao quát được những điều họ muốn. Dù
là kiểm thử tốc độ hay độ sâu thì họ có thể sử dụng phương pháp này để
xây dựng được những cơ cấu khác nhau trong từng trường hợp kiểm thử
(test case) cụ thể [6].
Chi phí cho kiểm thử phần mềm

Một nghiên cứu được tiến hành bởi NIST trong năm 2002 cho biết rằng
các lỗi phần mềm gây tổn thất cho nền kinh tế Mỹ 59,5 tỷ đô mỗi năm, hơn
một phần ba chi phí này có thể tránh được nếu việc kiểm thử phần mềm
được thực hiện tốt hơn [7].
Thực tế chứng minh rằng, một kiếm khuyết nếu được tìm ra sớm hơn thì
chi phí để sửa chữa nó sẽ rẻ hơn. Bảng dưới đây cho thấy chi phí sửa chữa
các khiếm khuyết tùy thuộc vào giai đoạn nó được tìm ra. Ví dụ, một vấn
đề được tìm thấy sau khi đã ra bản phần mềm chính thức rồi sẽ có chi phí
gấp 10-100 lần khi giải quyết vấn đề từ lúc tiếp nhận yêu cầu. Với sự ra
đời của cách thức triển khai thực tiễn liên tục và các dịch vụ dựa trên đám
mây, chi phí tái triển khai và bảo trì có thể làm giảm bớt theo thời gian.
Thời gian phát hiện
Chi phí sửa
chữa một khiếm
khuyết

T
hời
gian

sử
dụng

Pha
xác định
và đặc tả
yêu cầu

Ph
P
a thiết
ha xây
kế kiến
dựng
trúc

Pha
xác định
và đặc tả
yêu cầu

1x

3x

Pha
thiết kế

–

1x

7

5
–10x

1

Ph
a kiểm
thử hệ
thống

S
au khi
phát
hành

10x

1
0–100x

15x

2


0x

kiến trúc
Pha
xây dựng

–

–

5–100x
1

x

10x

1
0–25x

Bảng 1. 1 Chi phí triển khai bảo trì phần mềm [2]
Vai trị của kiểm thử viên

Kiểm thử phần mềm được thực hiện bởi nhiều Tester. Cho đến những
năm 1980, thuật ngữ "nhân viên kiểm thử phần mềm" đã được sử dụng
thường xuyên, nhưng sau đó cũng được coi là một nghề riêng biệt. Liên
quan đến các giai đoạn và các mục tiêu khác nhau trong kiểm thử phần
mềm thì những vai trị khác nhau đã được thiết lập cho các nhà quản lý,
trưởng nhóm kiểm thử, nhà phân tích kiểm thử, nhà thiết kế kiểm thử,
Tester, nhà phát triển tự động hóa và quản trị viên kiểm thử [9].
Lịch sử của kiểm thử phần mềm

Sự tách biệt giữa việc gỡ lỗi (sửa lỗi, debugging) với kiểm thử (testing)
lần đầu tiên được Glenford J. Myers đưa ra vào năm 1979. Mặc dù sự quan
tâm của ông là kiểm thử sự gián đoạn ("một kiểm thử thành công là tìm ra
được một lỗi") nó minh họa mong muốn của cộng đồng công nghệ phần
mềm để tách biệt các hoạt động phát triển cơ bản, giống như việc tách phần
gỡ lỗi ra riêng khỏi quá trình kiểm thử. Vào năm 1988, Dave
Gelperin và William C. Hetzel đã phân loại các giai đoạn và mục tiêu trong
kiểm thử phần mềm theo trình tự sau [11]:


Trước 1956: Hướng về việc kiểm sốt lỗi



1957-1978: Hướng về chứng minh lỗi



1979-1982: Hướng về tính phá hủy của lỗi



1983–1987: Hướng về đánh giá lỗi



1988–2000: Hướng về việc phòng ngừa lỗi
1.3. Phương pháp kiểm thử
Kiểm thử tĩnh và kiểm thử động

Có rất nhiều phương pháp để kiểm thử phần mềm. Đánh giá, định hướng
hoặc kiểm tra được gọi là kiểm thử tĩnh, trong khi việc chạy mã lập trình
thực tế trong các tình huống được gọi là kiểm thử động. Kiểm thử tĩnh
thơng thường có thể được bỏ qua khi thực hành nhưng kiểm thử động diễn
ra khi bản thân chương trình đó đang được sử dụng. Kiểm thử động có thể
8


bắt đầu trước khi chương trình đã hồn tất 100% để kiểm thử các phần cụ
thể của mã và được áp dụng cho các chức năng riêng biệt hoặc các mơ đun.
Kỹ thuật điển hình cho điều này được sử dụng trong cả mạch nhánh/trình
điều khiển hoặc được thực hiện trong một môi trường gỡ lỗi nhất định.
Kiểm thử tĩnh liên quan đến việc kiểm chứng trong khi kiểm thử động liên
quan đến việc xác nhận. Nó đều cùng giúp cải thiện chất lượng phần mềm.
Phương pháp tiếp cận
Theo truyền thống thì các phương pháp kiểm thử phần mềm được bắt
nguồn từ kiểm thử hộp trắng và hộp đen. Có hai cách tiếp cận được sử dụng
để mô tả quan điểm của một kỹ sư kiểm thử khi thiết kế các Test Case.
Kiểm thử hộp trắng
Kiểm thử hộp trắng giúp kiểm thử được cấu trúc bên trong hoặc hoạt
động của một chương trình, như tương phản với chức năng được bộc lộ của
người dùng cuối. Một góc nhìn nội bộ của hệ thống trong kiểm thử hộp
trắng giống như là các kỹ năng lập trình được sử dụng để thiết kế ra các
tình huống kiểm thử. Các Tester lựa chọn yếu tố đầu vào để thực hiện
đường dẫn thông qua các mã và xác định được kết quả đầu ra thích hợp.
Trong khi kiểm thử hộp trắng có thể được áp dụng tại mức đơn vị, tích
hợp hệ thống và các cấp độ của quá trình kiểm thử phần mềm, nó thường
được thực hiện ở cấp đơn vị. Nó có thể kiểm thử đường dẫn trong một đơn
vị, liên kết giữa các đơn vị trong q trình tích hợp, và giữa các hệ thống

con trong một kiểm thử hệ thống cấp. Mặc dù phương pháp này thiết kế
kiểm thử có thể phát hiện ra nhiều lỗi hoặc các vấn đề, nó có thể khơng
phát hiện các phần chưa thực hiện của các đặc điểm kỹ thuật hoặc yêu cầu
thiếu sót.

9


Hình 1. 1 Kỹ thuật kiểm thử hộp trắng [5]
Các kỹ thuật được sử dụng trong kiểm thử hộ p trắng bao gồm:
 Kiểm thử API (giao diện lập trình ứng dụng) - kiểm thử ứng dụng
có sử dụng các API public và cá nhân.
 Kiểm thử độ bao phủ mã lệnh- tạo ra các trường hợp kiểm thử để
đáp ứng một số tiêu chí bao phủ mã lệnh(Ví dụ, các nhà thiết kế
kiểm thử có thể tạo ra các bài kiểm thử để làm tất cả các câu lệnh
trong chương trình được thực hiện ít nhất một lần).
 Phương pháp chèn lỗi - cố tình đưa ra những lỗi để đánh giá hiệu
quả của các chiến lược kiểm thử.
 Phương pháp kiểm thử đột biến.
 Phương pháp thử tĩnh.
Các cơng cụ bao phủ mã có thể đánh giá đầy đủ của một bộ kiểm thử đã
được tạo ra bằng phương pháp bất kỳ nào đó, bao gồm cả kiểm thử hộp đen.
Điều này cho phép nhóm nghiên cứu phần mềm kiểm thử các bộ phận của
một hệ thống mà hiếm khi được kiểm thử và đảm bảo rằng các điểm chức
năng quan trọng nhất đã được kiểm thử. Bao phủ mã lệnh gồm:


Bao phủ chức năng (hàm): dựa vào các báo cáo của chức năng để
thực hiện.



Bao phủ câu lệnh: dựa vào các báo cáo về số lượng các dịng được
thực hiện để hồn thành kiểm thử.

100% bao phủ câu lệnh đảm bảo rằng tất cả các đường dẫn mã lệnh,
hoặc các nhánh (trong điều kiện của luồng điều khiển) được thực hiện ít
nhất một lần. Điều này hữu ích trong việc đảm bảo đúng chức năng nhưng
10


khơng đủ kể từ khi các mã tương tự có thể thực hiện tiến trình xử lý dữ liệu
đầu vào khác nhau dù đúng hoặc không.
Kiểm thử hộp đen
Kiểm thử hộp đen là kiểm thử chức năng mà không cần bất kỳ kiến thức
về cấu trúc và hành vi bên trong phần mềm. Các kiểm thử viên chỉ biết về
những gì phần mềm phải làm mà khơng biết là nó làm như thế nào. Phương
pháp kiểm thử hộp đen bao gồm: Phân vùng tương đương, phân tích giá tr ị
biên, tất cả các cặp kiểm thử, bảng chuyển đổi trạng thái, kiểm thử bảng
quyết định, kiểm thử dựa trên mô hình, sử dụng Test Case, kiểm thử thăm
dị và kiểm thử dựa trên đặc điểm kỹ thuật.

Hình 1. 2 Kỹ thuật kiểm thử hộp đen [5]
Kiểm thử dựa trên đặc điểm kỹ thuật nhằm mục đích để kiểm tra các
chức năng của phần mềm theo các yêu cầu ứng dụng. Mức độ kiểm thử
thường đòi hỏi Test Case kỹ lưỡng để được cung cấp bởi các Tester, những
người mà sau đó có thể xác minh một cách đơn giản rằng đối với một giá
trị đầu vào hoặc đầu ra (hoặc cách xử lý) có thể giống hoặc khơng giống so
với giá trị kỳ vọng được định vị trong một Test Case nhất định. Các Test
Case được xây dựng quanh các thông số kỹ thuật và các yêu cầu đề xuất,

tức là những tất cả những gì ứng dụng đó phải làm. Nó được sử dụng để mơ
tả mở rộng phần mềm bao gồm các thông số kỹ thuật, các yêu cầu và thiết
kế được mô tả trong tài liệu đặc tả, tài liệu thiết kế, nguồn để xây dựng
Test Case. Các kiểm thử này có thể là chức năng hoặc phi chức năng.
Kiểm thử dựa trên đặc điểm kỹ thuật có thể là cần thiết để đảm bảo
chức năng chính xác, nhưng nó khơng đủ để bảo vệ chống lại các tình
huống phức tạp hoặc có độ rủi ro cao.
11


Phương pháp kiểm thử này có thể được áp dụng cho tất cả các cấp kiểm
thử phần mềm: đơn vị, tích hợp, hệ thống và chấp nhận. Nó khơng thể thực
hiện được tất cả các kiểm thử các cấp độ cao hơn nhưng nó có thể tạo ưu
thế tốt khi kiểm thử từng đơn vị.
Kiểm thử hộp xám
Kiểm thử hộp xám là một phương pháp kiểm thử phần mềm được kết
hợp giữa Phương pháp Kiểm thử Black Box (hộp đen) và White Box (hộp
trắng). Trong Kiểm thử Hộp xám, cấu trúc bên trong sản phẩm chỉ được
biết một phần.

Hình 1. 3 Kỹ thuật kiểm thử hộp xám [20]
Kiểm thử hộp xám liên quan đến hiểu biết về cấu trúc dữ liệu bên trong
và các thuật tốn cho mục đích của các trường hợp kiểm thử thiết kế. Khi
thực hiện kiểm thử với User hoặc mức độ hộp đen, Tester không nhất thiết
phải truy cập vào mã nguồn của phần mềm. Ta có thể thao tác với dữ liệu
đầu vào và định dạng đầu ra không xác định như hộp xám bởi vì đầu vào và
đầu ra rõ ràng ở bên ngoài của "hộp đen" mà chúng được hệ thống gọi ra
trong quá trình kiểm thử. Sự phân biệt này là đặc biệt quan trọng khi tiến
hành kiểm thử tích hợp giữa hai Module được viết mã bởi hai nhà phát
triển khác nhau, mà ở đó chỉ có các giao diện được bộc lộ ra để kiểm thử.

Tuy nhiên, các kiểm thử mà yêu cầu thay thế một kho lưu trữ dữ liệu
back-end như một cơ sở dữ liệu hoặc một tập tin đăng nhập không xác định
như hộp xám, người dùng sẽ không thể thay đổi các kho lưu trữ dữ liệu
trong khi sản phẩm vẫn đang hoạt động bình thường.
1.4. Các mức kiểm thử
Kiểm thử đơn vị

Kiểm thử đơn vị hay còn được gọi là kiểm thử thành phần, đề cập đến
việc kiểm thử chức năng từng phần của mã, thường ở mức độ chức năng.

12


Trong một mơi trường hướng về đối tượng thì điều này thường là cấp độ
lớp, và các kiểm thử đơn vị tối thiểu bao gồm hàm dựng và hàm hủy. Nhiều
loại kiểm thử được viết bởi các nhà phát triển như họ làm việc trong mã
(kiểu hộp trắng) để đảm bảo rằng từng hàm riêng biệt hoạt động đúng như
kỳ vọng. Một hàm có thể có nhiều kiểm thử từ đó giúp nắm bắt được các
trường hợp góc hoặc các nhánh trong mã nguồn. Kiểm thử đơn vị một mình
khơng thể đảm bảo hết được từng chức năng của từng bộ phận trong phần
phềm nhưng nó được sử dụng để đảm bảo rằng các khối kiến trúc của phần
mềm hoạt động độc lập với nhau.
Kiểm thử đơn vị là một q trình phát triển phần mềm có liên quan đến
ứng dụng đồng bộ của một loạt các chiến lược phòng ngừa phát hiện lỗi và
để giảm thiểu rủi ro, thời gian và chi phí. Nó được thực hiện bởi kỹ sư hay
nhà phát triển trong suốt giai đoạn xây dựng của vịng đời phát triển phần
mềm. Khơng chỉ tập trung vào việc đảm bảo chất lượng truyền thống mà
phải gia tăng nó lên vì thế kiểm thử đơn vị có mục đích loại bỏ những lỗi
cấu trúc trước khi mã hóa rồi mới thúc đẩy việc quản lý chất lượng. Chiến
lược này nhằm nâng cao chất lượng cũng như hiệu quả của phần mềm trong

tiến trình quản lý và phát triển chung.
Tùy thuộc vào kỳ vọng của tổ chức phát triển phần mềm, kiểm thử đơn
vị có thể bao gồm phân tích mã tĩnh, phân tích luồng dữ liệu, phân tích dữ
liệu, đánh giá mã cân bằng, phân tích mã bao phủ và các thực hành xác
nhận phần mềm khác.
Kiểm thử tích hợp
Kiểm thử tích hợp là một hình thức kiểm thử phần mềm nhằm tìm cách
xác minh các giao diện giữa các thành phần xung đột của một thiết kế. Các
thành phần này có thể tích hợp theo cách lặp đi lặp lại hoặc tất cả cùng
nhau ("Big Bang"). Thông thường cách thức này được coi là một thực hành
tốt hơn vì nó cho phép các vấn đề về giao diện được định vị một cách
nhanh chóng và cố định hơn.
Kiểm thử tích hợp làm lộ ra các khiếm khuyết trong các giao diện và
tương tác giữa các thành phần tích hợp (Modules). Các nhóm thành phần đã
được kiểm thử lớn dần từng bước tương ứng với các thuộc tính của cấu trúc
thiết kế đã được tích hợp và kiểm thử cho đến khi phần mềm hoạt động như
một hệ thống.

13


Kiểm thử hệ thống

Kiểm thử hệ thống giúp xác minh một hệ thống được tích hợp có đáp ứng
đầy đủ các u cầu hay khơng. Ngồi ra, kiểm thử phần mềm phải đảm bảo
rằng các chương trình hoạt động như kỳ vọng, khơng cịn bị phá hủy hay
lỗi phần nào đó trong mơi trường hoạt động của nó hoặc khơng gặp sự cố
khi hoạt động với tiến trình khác.


Kiểm thử hệ thống bao gồm kiểm thử hộp đen, vì vậy các kiến thức
về thiết kế nội bộ hoặc cấu trúc hoặc code không cần thiết cho loại
kiểm thử phần mềm này.



Kiểm thử hệ thống bao gồm kiểm thử chức năng và phi chức năng.



Kiểm thử hệ thống tập trung nhiều hơn vào các chức năng của toàn
bộ hệ thống.



Các trường hợp kiểm thử hệ thống bao gồm các chức năng của sản
phẩm hoàn chỉnh và được thực hiện các trường hợp kiểm thử mức độ
cao.



Các hành vi của ứng dụng hoàn chỉnh được kiểm tra để đáp ứng các
yêu cầu quy định.



Các trường hợp kiểm thử và dữ liệu kiểm thử được thực hiện và các
dữ liệu thực tế không được sử dụng trong loại kiểm thử này.



Trong kiểm thử tích hợp hệ thống sẽ tích hợp các mơ-đun khác nhau
và kiểm tra giao diện giữa chúng để kiểm tra tính tồn vẹn dữ liệu.



Trong khi thực hiện q trình kiểm thử hệ thống, kiểm tra tính đúng
đắn được thực hiện bởi nhân viên kiểm thử.

Các kỹ thuật kiểm thử khác nhau được sử dụng trong kiểm thử hệ
thống:


Kiểm thử chức năng



Kiểm thử giao diện



Kiểm thử tính sử dụng



Kiểm thử bảo mật



Kiểm thử hiệu năng

Kiểm thử mức chấp nhận
Cuối cùng hệ thống được giao cho người dùng để kiểm thử mức chấp
nhận.

14




Đây là một kiểm thử liên quan đến nhu cầu của người sử dụng, yêu
cầu và quy trình kinh doanh được tiến hành để xác định có hay khơng
một hệ thống đáp ứng các tiêu chí chấp nhận và kiểm tra hệ thống
đáp ứng yêu cầu của khách hàng.



Kiểm thử chấp nhận kiểm thử các chức năng để kiểm tra hành vi của
hệ thống bằng cách sử dụng dữ liệu thực tế. Nó cũng được gọi là thử
nghiệm người dùng doanh nghiệp.



Kiểm thử chấp nhận được thực hiện bởi người dùng cuối để kiểm tra
hệ thống được xây dựng để phù hợp với yêu cầu kinh doanh của tổ
chức.



Trong kiểm thử này, tất cả các giao diện đã được kết hợp và hệ thống

đã hoàn thành và đã được kiểm tra. Người dùng cuối cũng thực hiện
các kiểm thử để kiểm tra khả năng sử dụng của hệ thống.

1.5. Quy trình kiểm thử
Quy trình kiểm thử tổng quát bao gồm các bước sau

Hình 1. 4 Quy trình kiểm thử phần mềm [9]

15


1.6. Kiểm thử tự động
Việc tự động kiểm thử đang ngày càng được quan tâm sử dụng , đặc biệt
là sử dụng mơ hình TDD (Test – Drive – Development). Có rất nhiều
framework tích hợp trong mơi trường phát triển nên thuận lợi cho mỗi
phiên bản được chạy kiểm thử tự động mọi lúc khi tích hợp liên tục phần
mềm [11].
Khi kiểm thử tự động không thể sao chép tất cả mọi thứ như con người
có thể làm nhưng nó có thể rất hữu ích cho việc kiểm thử hồi quy. Tuy
nhiên, nó cũng địi hỏi phải có những kịch bản kiểm thử tốt để tiến hành
kiểm thử.
Kiểm thử tự động sử dụng trong các giai đoạn kiểm thử:
 Unit Testing( Kiểm thử đơn vị)
 Integration Testing( Kiểm thử tích hợp)
 Và trong các loại kiểm thử:
 Smoke Testing( Kiểm thử khói)
 Functional Testing( Kiểm thử chức năng)
 Regression Testing( Kiểm thử hồi quy)
 Và trong kỹ thuật kiểm thử:
 Black Box Testing( Kiểm thử hộp đen)

Các công cụ kiểm thử
Chương trình kiểm thử và phát hiện lỗi có thể được hỗ trợ đáng kể bởi
các công cụ kiểm thử và gỡ lỗi. Những màn hình chương trình cho phép
giám sát tồn bộ hoặc một phần của mã chương trình gồm:
 Lệnh thiết lập giả lập (simulator) cho phép giám sát hoàn chỉnh
cấp hướng dẫn và các thiết bị vi lượng.
 Hình ảnh chương trình cho phép thực hiện từng bước và ngắt đoạn
có điều kiện ở cấp nguồn hoặc trong mã máy.
 Các báo cáo độ bao phủ của mã.
Các công cụ gỡ lỗi biểu tượng hoặc kết xuất định dạng cho phép kiểm tra
các biến tại các chỗ lỗi và tại các điểm được lựa chọn.
Các công cụ kiểm thử GUI chức năng tự động được sử dụng để lặp lại
mức độ kiểm tra hệ thống thông qua GUI (giao diện đồ họa).
Điểm định chuẩn cho phép so sánh hiệu suất chạy thực được hoạt động.
16


Phân tích hiệu suất có thể giúp làm nổi bật các điểm tới hạn và sử dụng
tài nguyên.
Một số các tính năng này có thể được kết hợp vào một mơi trường phát
triển tích hợp (IDE).
Một số cơng cụ để thực hiện kiểm thử tự động
 Selenium
 Khái niệm:
Selenium là một công cụ kiểm tra phần mềm được sử dụng để kiểm tra
hồi quy( Regression Testing). Đây là một công cụ kiểm tra mã nguồn mở
cung cấp chức năng phát lại và thu âm để kiểm tra hồi quy. Các Selenium
IDE chỉ hỗ trợ trình duyệt web Mozilla Firefox.
 Đặc điểm:
 Cung cấp các điều khoản để xuất khẩu ghi lại kịch bản trong các ngôn

ngữ khác như Java, Ruby, RSpec, Python, C #, JUnit và TestNG.
 Nó có thể thực hiện nhiều bộ kiểm thử cùng một lúc.
 Xác định phần tử sử dụng id, tên, đường dẫn X, v.v.
 Lưu trữ các bộ kiểm thử như Ruby Script, HTML và bất kỳ định dạng
nào khác.
 Hỗ trợ tệp tin người dùng selenium-extensions.js.
 Cho phép để chèn ý kiến ở giữa của kịch bản để hiểu rõ hơn nội dung
và mục đích của kịch bản kiểm thử.
 QTP (HP UFT)

 Khái niệm:
QTP được sử dụng rộng rãi để kiểm tra chức năng( Functional Testing)
và hồi quy( Regression Testing), giải quyết các ứng dụng phần mềm và
môi trường cài đặt. Để đơn giản hóa việc tạo và bảo trì thử nghiệm, nó
sử dụng khái niệm kiểm tra từ khóa.
 Đặc điểm:
 Được sử dụng dễ dàng hơn dành cho người kiểm thử viên khơng theo
ngành kỹ thuật để thích ứng và tạo ra các trường hợp thử nghiệm làm
việc.

17


 Sửa lỗi nhanh hơn bằng cách ghi lại và sao chép các lỗi cho nhà phát
triển.
 Thu gọn tài liệu thử nghiệm tại một trang web.
 QTP hỗ trợ mơi trường phát triển .NET.
 Có cơ chế xác định đối tượng kiểm thử tốt.
 Rational Function Tester
 Khái niệm:

Là 1 công cụ kiểm tra tự động hướng đối tượng có khả năng tự động
kiểm tra dữ liệu, kiểm tra giao diện, và kiểm thử hồi quy( Regression
Testing).
 Đặc điểm:
 Hỗ trợ một loạt các giao thức và ứng dụng như Java, HTML, NET,
Windows, SAP, Visual Basic ... .
 Có thể ghi lại và phát lại các hành động theo u cầu.
 Tích hợp tốt với các cơng cụ quản lý kiểm sốt nguồn như Rational
Clear Case và tích hợp Rational Team Concert.
 Cho phép các nhà phát triển tạo ra các kịch bản liên quan đến từ khóa
để có thể được tái sử dụng.
 Bộ biên tập Công cụ Java Developer Toolkit của Eclipse tạo điều kiện
cho nhóm tạo mã thử nghiệm các đoạn mã trong Java với Eclipse.
 Hỗ trợ điều khiển tùy chỉnh thông qua proxy SDK (Java / .Net).
 Hỗ trợ kiểm soát phiên bản để cho phép phát triển song song các kịch
bản thử nghiệm.
 WATIR
 Khái niệm:
Là một phần mềm kiểm tra mã nguồn mở để kiểm thử hồi.
quy( Regression Testing). Watir chỉ hỗ trợ khám phá Internet trên các
cửa sổ trong khi Watir webdriver hỗ trợ Chrome, Firefox, IE, Opera.
 Đặc điểm:
 Hỗ trợ nhiều trình duyệt trên các nền tảng khác nhau.
 Sử dụng một ngơn ngữ kịch bản hiện đại có đầy đủ tính năng.

18


 Hỗ trợ ứng dụng web được viết bởi bất kỳ ngôn ngữ.
 Cho phép bạn viết các test case dễ đọc và bảo trì.

 SilkTest
 Khái niệm:
Silk Test được thiết kế để thực hiện kiểm tra chức năng( Functional
Testing) và hồi quy( Regression Testing). Nó là một ngơn ngữ hướng đối
tượng giống như C ++. Nó sử dụng các khái niệm về đối tượng, các
class và sự kế thừa.
 Đặc điểm:
 Nó bao gồm tất cả các tập tin mã nguồn.
 Chuyển đổi các lệnh script thành các lệnh GUI. Trên cùng một máy,
các lệnh có thể được chạy trên một máy từ xa hoặc máy chủ.
 Để xác định chuyển động của con chuột cùng với các bấm phím,
Silktest có thể được thực hiện. Nó có thể sử dụng cả phương pháp phát
lại và ghi hoặc các phương pháp lập trình mơ tả.
 Xác định tất cả các điều khiển và cửa sổ của ứng dụng được thử
dưới dạng các đối tượng và xác định tất cả thuộc tính và thuộc tính của
mỗi đối tượng.
1.7. Tổng kết chương
Kiểm thử phần mềm là một bước quan trọng trong quá trình phát triển
phần mềm, nhằm đưa đến cho người dùng cuối một sản phẩm tốt. Khi thực
hiện kiểm thử phần mềm cần nhiều bước thực hiện theo thứ tự tuần tự, tùy
thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất cứ
lúc nào trong quá trình phát triển phần mềm. Với phương pháp truyền
thống thì các nỗ lực kiểm thử được tiến hành sau khi các u cầu được xác
định và việc lập trình được hồn tất, nhưng trong Agile (là một tập hợp các
phương pháp phát triển phần mềm linh hoạt dựa trên việc lặp đi lặp lại và
gia tăng giá trị) thì việc kiểm thử được tiến hành liên tục trong suốt quá
trình xây dựng phần mềm. Như vậy, mỗi một phương pháp kiểm thử bị chi
phối theo một quy trình phát triển phần mềm nhất định.

19

CHƯƠNG 2. KIỂM THỬ HỒI QUY ỨNG DỤNG DI ĐỘNG
Công nghệ điện thoại di động và các thiết bị thông minh hiện nay là xu
hướng và cũng là tương lai của thế giới. Mỗi ngày có hàng triệu ứng dụng
được tải (download) từ kho ứng dụng (Appstore hoặc Google Play) về các
thiết bị cá nhân. Các ứng dụng di động rất phong phú đa dạng đáp ứng đủ
các nhu cầu học tập, chăm sóc sức khỏe hay giải trí, kinh doanh của người
dùng. Để kiểm thử được các ứng dụng trên các thiết bị di động (Mobile
App Testing) thì trước hết ta cần hiểu về các thiết bị di động [12].
Khi xây dựng một phiên bản mới của hệ thống (ví dụ sau khi sửa lỗi,
thay đổi hoặc thêm chức năng, v.v.), có thể vơ tình gây ra các lỗi mới.
Nhiều khi thay đổi rất nhỏ cũng gây những vấn đề lớn ngoài sức tưởng
tượng của đội phát triển. Để tránh những việc đáng tiếc này xảy ra cần
kiểm thử lại phần mềm để đảm bảo các chức năng đã chạy tốt vẫn tiếp tục
chạy tốt.
2.1. Ứng dụng trên các thiết bị di động (Mobile application)
Ứng dụng di động là những ứng dụng chỉ được sử dụng cho các thiết bị
di động hoặc tablet thông qua các cửa hàng trực tuyến của các hãng như
App Store của Apple hay Google Play của Google. Những ứng dụng này
phát triển dựa trên mã hoặc framework cho mỗi nền tảng, điều này sẽ gây
cản trở cho một số máy nhất định. Ở những smartphone tầm thấp có thể
khơng chạy được ứng dụng do cấu hình thấp hoặc cần một hệ điều hành
mới hơn.

Hình 2. 1 Các lĩnh vực ứng dụng mobile [12]
20


Các dạng ứng dụng trên thiết bị di động bao gồm:



Native Application: Các ứng dụng này được phát triển cho một nền
tảng cụ thể và được cài trên thiết bị



Web Based Applications: Các ứng dụng được truy cập thơng qua
trình duyệt của thiết bị



Hybrid Application: Là loại ứng dụng kết hợp các yếu tố của cả
Native app và Web app

Hình 2. 2 Các loại ứng dụng mobile[11]

2.2. Kiểm thử ứng dụng cho thiết bị di động
2.2.1 Kiểm thử ứng dụng di động
Kiểm thử ứng dụng di động là một quá trình mà các phần mềm ứng dụng
được phát triển cho các thiết bị di động cầm tay được thử nghiệm chức
năng của nó, khả năng sử dụng và tính nhất quán. Kiểm thử ứng dụng di
động có thể được tự động hóa hoặc thực hiện bằng tay. Ứng dụng di động
hoặc được cài đặt trước hoặc có thể được cài đặt từ các nền tảng phân phối
phần mềm điện thoại di động.
Với mỗi loại ứng dụng thì kiểm thử ứng dụng di động đều đóng vai trị
rất quan trọng. Vì số lượng lượt tải ứng dụng thường lên tới hàng triệu lượt
cho một sản phẩm nào đó. Do vậy, một ứng dụng bị lỗi không bao giờ được
đánh giá cao. Nó thường gây tổn thất về mặt tài chính, vấn đề pháp lý và
khơng thể khắc phục thiệt hại hình ảnh thương hiệu sản phẩm.

21