Nhận viết luận văn đại học, thạc sĩ trọn gói, chất lượng, LH ZALO=>0909232620 Tham khảo dịch vụ, bảng giá tại: https://baocaothuctap.net Download luận văn thạc sĩ ngành công nghệ thông tin với đề tài: Phương pháp và công cụ để hỗ trợ kiểm thử phần mềm android, cho các bạn làm luận văn tham khảo

1. ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Phan Thị Huế
PHƯƠNG PHÁP VÀ CÔNG CỤ ĐỂ HỖ TRỢ
KIỂM THỬ PHẦN MỀM ANDROID
LUẬN VĂN THẠC SĨ
HÀ NỘI - 2016

2. ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Phan Thị Huế
PHƯƠNG PHÁP VÀ CÔNG CỤ ĐỂ HỖ TRỢ
KIỂM THỬ PHẦN MỀM ANDROID
Ngành: Công nghệ thông tin
Chuyên ngành: Kĩ thuật phần mềm
Mã số: 60.48.01.03
LUẬN VĂN THẠC SĨ
NGƯỜI HƯỚNG DẪN CHÍNH: PGS.TS. Trương Ninh Thuận
NGƯỜI HƯỚNG DẪN PHỤ: TS. Trịnh Thanh Bình
HÀ NỘI – 2016

3. Lời cảm ơn
Trước tiên, em xin bày tỏ lòng biết ơn chân thành và sâu sắc tới Thầy giáo
PGS.TS Trương Ninh Thuận và TS Trịnh Thanh Bình đã tận tình chỉ bảo, hướng dẫn,
động viên và giúp đỡ em trong suốt quá trình thực hiện đề tài luận văn.
Em xin gửi lời cảm ơn sâu sắc tới các Thầy Cô trong Khoa Công nghệ thông tin
đã truyền đạt kiến thức quý báu cho em trong hai năm học vừa qua.
Con xin nói lên lòng biết ơn vô hạn đối với Cha Mẹ luôn là nguồn động viên,
chăm sóc và khích lệ con trên mỗi bước đường học vấn.
Cuối cùng, xin chân thành cảm ơn các Anh Chị và Bạn Bè, các thành viên lớp
K19, K20 KTPM đã ủng hộ, giúp đỡ tôi trong suốt thời gian tôi học tập trên giảng
đường và thực hiện đề tài luận văn này.
Tôi xin chân thành cảm ơn!
Hà Nội, ngày 01 tháng 10 năm 2016
Học viên
Phan Thị Huế

4. PHƯƠNG PHÁP VÀ CÔNG CỤ ĐẺ HỖ TRỢ KIỂM THỬ
PHẦN MỀM ANDROID
Phan Thị Huế
Khóa K20KTPM, ngành công nghệ thông tin.
Tóm tắt Luận văn:
Ngày nay với sự phát triển rộng rãi của hệ điều hành Android trên các dòng điện
thoại thì việc tạo ra các phần mềm, dự án liên quan đến Android càng ngày càng tăng
lên. Do đó các giải pháp hỗ trợ kiểm thử phần mềm Android sẽ rất có ý nghĩa trong
việc kiểm thử chất lượng sản phẩm của các nhà phát triển trước khi đưa đến người
dùng. Theo thống kê của Google Android chiếm 75% thị phần điện thoại thông minh
trên toàn thế giới vào thời điểm quý 3 năm 2012 và sau 2 năm đã có hơn một tỷ máy
được kích hoạt Android. Sự thành công của hệ điều hành này đã dẫn đến “cuộc chiến
điện thoại thông minh” giữa các hãng sản xuất điện thoại. Và bất kỳ một chiếc điện
thoại nào muốn kích hoạt Android đều phải trải qua tất cả các ca kiểm thử của Google.
Các ca kiểm thử đó được Google phát triển và tích hợp trong công cụ CTS
(Compatibility Test Suite) mà các đối tác phải tuân theo.
Với mỗi nền tảng của Android được ra đời, Google cung cấp các bộ API tương
ứng với nền tảng đó. Tương ứng với bộ API này tương ứng là tập các ca kiểm thử
CTS. Mục đích là kiểm tra sự tương thích của các thiết bị Android với nền tảng đó.
Với bộ kiểm thử CTS này Google cũng hỗ trợ các đối tác một công cụ để có thể kiểm
thử nhanh với các thiết bị trước khi ra thị trường nằm trong bộ CTS.
Sau khi nghiên cứu phương pháp CTS Google hỗ trợ các đối tác kiểm thử trên
thiết bị di động chạy Android, luận văn đã áp dụng phương pháp này và xây dựng một
công cụ hỗ trợ kiểm thử trên dự án Android Junit Test và mang lại những lợi ích đáng
kể và có hiệu quả cao so với việc kiểm thử trực tiếp trên IDE (eclipse).

5. Lời cam đoan
Tôi xin cam đoan phương pháp và công cụ để hỗ trợ kiểm thử phần mềm Andoid
được trình bày trong luận văn này là do tôi thực hiện dưới sự hướng dẫn của PGS.TS
Trương Ninh Thuận và TS Trịnh Thanh Bình.
Tất cả những tham khảo từ các nghiên cứu liên quan đề được nêu nguồn gốc một
các rõ ràng từ danh mục tài liệu tham khảo trong luận văn. Trong luận văn, không có
việc sao chép tài liệu, công trình nghiên cứu của người khác mà không chỉ rõ về tài
liệu tham khảo.
Hà Nội, ngày 01 tháng 10 năm 2016
Tác giả
Phan Thị Huế

6. MỤC LỤC
CHƯƠNG 1: GIỚI THIỆU VỀ LUẬN VĂN VÀ LÝ DO CHỌN ĐỀ TÀI...................5
1. Kiểm thử ứng dụng trên hệ điều hành Android.........................................5
2. Nội dung luận văn......................................................................................6
3. Cấu trúc của luận văn ................................................................................7
CHƯƠNG 2: KHÁI QUÁT VỀ KIỂM THỬ ỨNG DỤNG TRÊN ĐIỆN THOẠI
THÔNG MINH................................................................................................................8
1. Các yếu tố ảnh hưởng đến hoạt động của phần mềm trên điện thoại thông
minh ..........................................................................................................................8
2. Lựa chọn điện thoại thông minh để kiểm thử............................................8
3. Các dạng kiểm thử trên Android. ..............................................................9
4. Nền tảng kiểm thử Android.....................................................................10
4.1. Instrument framework (IF).................................................................11
4.2. Kiến trúc kiểm thử trên Android ........................................................12
5. Các mục tiêu kiểm thử.............................................................................13
CHƯƠNG 3: GIỚI THIỆU VỀ CTS.............................................................................14
1. Giới thiệu về Compatibility Test Suite (CTS).........................................14
2. Nguyên lý và cách thức làm việc của CTS [3]........................................15
2.1. Docs....................................................................................................16
2.2. Repository...........................................................................................16
2.3. Tools...................................................................................................17
3. Cài đặt phương pháp CTS .......................................................................18
3.1. Môi trường vật lý trên thiết bị kiểm thử.............................................18
3.2. Cài đặt môi trường máy tinh ..............................................................18
3.3. Cài đặt trên thiết bị kiểm thử..............................................................18
4. Cách chạy các ca kiểm thử CTS..............................................................19
4.1. Sao chép dữ liệu vào thiết bị. .............................................................19
4.2. Kiểm thử một Plan..............................................................................19
4.3. Các câu lệnh hỗ trợ tối ưu thời gian kiểm thử....................................20
4.4. Tái kiểm thử trên kết quả cũ...............................................................21
4.5. Báo cáo kết quả ..................................................................................21

7. CHƯƠNG 4: ỨNG DỤNG CHẠY CTS TRONG KIỂM THỬ ANDROID JUNIT
TEST PROJECT............................................................................................................23
1. Phương pháp CTS áp dụng kiểm thử với dự án Android Junit Test .......23
2. Cách tạo tệp tin .apk và .xml từ Eclipse ..................................................25
2.1. Tạo tệp tin .apk sử dụng Eclipse ........................................................25
2.2. Cách tạo tệp tin .xml từ dự án trên Eclipse ........................................26
3. Quá trình kiểm thử trên thiết bị ...............................................................28
4. Ưu điểm của công cụ so với kiểm thử trực tiếp trên Eclipse. .................29
CHƯƠNG 5: XÂY DỰNG CÔNG CỤ CTS EXECUTOR..........................................30
1. Môi trường và các công cụ sử dụng để thực nghiệm...............................30
1.1. Cấu hình phần cứng............................................................................30
1.2. Các phần mềm sử dụng ......................................................................30
2. Phân tích thiết kế phần mềm....................................................................31
2.1. Phân tích các ca sử dụng ....................................................................31
2.2. Biểu đồ trình tự...................................................................................32
2.3. Biểu đồ hoạt động...............................................................................33
3. Mô tả công cụ hỗ trơ kiểm thử ................................................................34
3.1. Tổng quan về công cụ ........................................................................34
3.2. Chi tiết các chức năng ........................................................................35
4. Xây dựng tập ca kiểm thử thử nghiệm với công cụ CTS Executor.........40
4.1. Xây dựng tập các ca kiểm thử ............................................................40
4.2. Kết quả thực nghiệm với công cụ CTS Executor...............................40
CHƯƠNG 6: KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN..............................................42

8. 1
Danh sách hình vẽ
Hình 2.1 : Định dạng file manifest trong Android Junit Test........................................11
Hình 2.2 : Kiến trúc testing framework [1]..................................................................12
Hình 3.1 : Qui trình đạt được Google’s certification ....................................................14
Hình 3.2 : Phương thức sử dụng CTS ...........................................................................15
Hình 3.3 : Cấu trúc của CTS .........................................................................................15
Hình 3.4 : Danh sách các ca kiểm thử...........................................................................16
Hình 3.5 : Danh sách các tệp .xml và .apk ....................................................................16
Hình 3.6 : Danh sách các pakage trong Plan.................................................................17
Hình 3.7 : Thư mục kết quả chạy ..................................................................................21
Hình 3.8 : Minh họa cho kết quả chạy bằng phương pháp CTS ...................................22
Hình 3.9 : Chi tiết kết quả chạy của một ca kiểm thử ...................................................22
Hình 4.1 : Xây dựng tệp .apk và .xml từ dự án .............................................................24
Hình 4.2 : Tệp tin .apk được biên dịch từ dự án Android Junit Test.............................24
Hình 4.3 : Nội dung cho tập tin .xml.............................................................................24
Hình 4.4 : Cấu trúc của tệp Plan....................................................................................25
Hình 4.5 : Kiểm tra trạng thái của thiết bị kiểm thử......................................................25
Hình 4.6 : Xây dựng tệp .apk từ dự án kiểm thử sử dụng Eclipse ................................25
Hình 4.7 : Đường dẫn chứa tệp .apk sau khi build bằng Eclipse ..................................26
Hình 4.8 : Công cụ tạo file .xml từ dự án Android Junit...............................................26
Hình 4.9 : Test suite diagram ........................................................................................27
Hình 4.10 : Tệp tin .xml sau khi được tạo ra từ dự án kiểm thử ...................................27
Hình 4.11 : Multi USB Port...........................................................................................28
Hình 4.12 : Quá trình kiểm thử trên thiết bị di động.....................................................28
Hình 5.1: Biểu đồ ca sử dụng khởi động chương trình .................................................31
Hình 5.2: Biểu đồ ca sử dụng khi kết nối điện thoại .....................................................31
Hình 5.3: Biểu đồ ca sử dụng thực hiện chạy chương trình CTS executor...................32
Hình 5.4: Biểu đồ trình tự khi người dùng kết nối điện thoại .......................................32
Hình 5.5: Biểu đồ trình tự khi chạy chương trình CTS Executor .................................33
Hình 5.6: Biểu đồ hoạt động chạy chương trình CTS Executor ...................................33

9. 2
Hình 5.7: Màn hình CTS Executor................................................................................34
Hình 5.8 : Cài đặt thư mục các ca kiểm thử và lưu trữ báo cáo kết quả .......................37
Hình 5.9 : Tập các test case dùng trong chương trình kiểm thử....................................38
Hình 5.10 : Kết quả chạy chương trình kiểm thử..........................................................39
Hình 5.11 : Kết quả kiểm thử xuất dưới file .excel......................................................39

10. 3
Danh sách bảng biểu
Bảng 3.1 : Bảng minh họa CTS versions cho các phiên bản Android ..........................14
Bảng 3.2: Câu lệnh hỗ trợ kiểm thử trong CTS.............................................................17
Bảng 4.1 : Bảng minh họa ưu điểm của công cụ CTS Executor...................................29
Bảng 5.1 : Bảng minh họa cấu hình phần cứng để chạy công cụ CTS Executor..........30
Bảng 5.2 : Danh sách các phân mềm sử dụng...............................................................30
Bảng 5.4 : Bảng hiển thị icon cho các trạng thái kết nối...............................................35
Bảng 5.5 : Bảng hiển thị cho các trạng thái của Bluetooth ...........................................35
Bảng 5.6 : Bảng các trạng thái hiển thị của wifi ...........................................................35
Bảng 5.7 : Bảng các trạng thái hiển thị của sim...........................................................36
Bảng 5.8 : Bảng hiển thị các trạng thái để chạy và dừng chương trình ........................36
Bảng 5.9 : Tập các ca kiểm thử thực nghiệm................................................................40
Bảng 5.10 : Kết quả thực nghiệm..................................................................................40

11. 4
Danh sách các từ viết tắt
CTS Compatibility Test Suite
CDD Compatibility Defination Document
IDE Integrated Development Environment
API Application Programming Interface
DUT Device Under Test
ADB Androi Debug Bridge
AAPT Asset Package Tool
IF Instrument framework

12. 5
CHƯƠNG 1: GIỚI THIỆU VỀ LUẬN VĂN VÀ LÝ DO CHỌN
ĐỀ TÀI
1. Kiểm thử ứng dụng trên hệ điều hành Android
Với sự phát triển không ngừng của Internet cộng với trào lưu mạng xã hội bùng
nổ điện thoại thông minh đang ngày càng được sử dụng nhiều nhằm đáp ứng nhu cầu
giải trí đa dạng của người dùng. Từ một chiếc điện thoại thông minh chỉ được cài sẵn
vài ba ứng dụng của nhà sản xuất thì nay với các thiết bị chạy hệ điều hành nhúng như
Android có thể dễ dàng đáp ứng được nhu cầu của người dùng bằng cách cài thêm
phần mềm bên thứ ba không gây trở ngại nào.
Từ đây lại đặt ra một vấn đề hiển nhiên là kiểm thử các phần mềm chạy trên các
thiết bị di động xem chúng có đáp ứng được các yêu cầu đề ra ban đầu hay không
trước khi phân phát sản phẩm đến tay người tiêu dùng. Có hàng nghìn các thiết bị và
các phiên bản Android mà ứng dụng của bạn cần phải tương thích với chúng. Một vài
lỗi, sai lầm xuất hiện trong phần mềm Android như sau [1]:
- Cài đặt ứng dụng bị lỗi.
- Ứng dụng bị treo khi hoạt động.
- Màn hình hiển thị ứng dụng có vấn đề.
- Ứng dụng bị treo khi tài nguyên không khả dụng.
- Hiển thị lỗi khi ứng dụng ở chế độ màn hình xoay ngang hoặc dọc.
Những lầm tưởng phổ biến và thực tế trong quá trình kiểm thử phần mềm
Andoird thường thấy gồm có [4]:
Lầm tưởng 1: Tất cả các thiết bị Android đều giống nhau thử nghiệm trên giả lập
là đủ. Điều này hoàn toàn sai lầm, ví dụ một ứng dụng hoạt động hoàn hảo trên thiết bị
giả lập nhưng trên một số thiết bị thực tế, nó bị treo trong quá trình thực hiện. Thiết bị
giả lập không đủ để thực hiện kiểm thử trên điện thoại di động. Do đó phải thử nghiệm
ứng dụng trên các thiết bị thực tế.
Lầm tưởng 2: Thực hiện kiểm thử trên một số thiết bị phổ biến là đủ. Điều này
hoàn toàn sai vì các thiết bị khác nhau ứng dụng được hiển thị khác nhau, vì mỗi thiết
bị có phần cứng, kích cỡ màn hình, bộ nhớ khác nhau...Phải kiểm thử ứng dụng trên
các thiết bị khác nhau, phiên bản hệ điều hành khác nhau và địa điểm khác nhau, tốc
độ mạng khác nhau...
Lầm tưởng 3: Kiểm kê thăm dò trước khi ra mắt sản phẩm là đủ.
Lầm tưởng 4: Nếu có một số lỗi trong ứng dụng thì người dùng sẽ hiểu, điều này
hoàn toàn sai lầm. Nếu ứng dụng không hoạt động và có lỗi xảy ra thì người dùng sẽ
gỡ bỏ ứng dụng đó. Vì thế vấn đề chất lượng là yếu tố tiên quyết ảnh hưởng đến danh
tiếng và niềm tin của khách hàng.

13. 6
Do đó để có một phần mềm chất lượng trước khi đến tay người dùng cần một
chiến lược kiểm thử chính xác trên nhiều các thiết bị khác nhau, phiên bản hệ điều
hành Android khác nhau gồm có:
- Kiểm thử đơn vị (Unit test)
- Kiểm thử tích hợp (Integration test)
- Kiểm thử hoạt động (Operational test)
- Kiểm thử hiệu năng (Performance test)
- Kiểm thử hệ thống (System test)
- Kiểm thử người dùng hay kiểm thử chấp nhận.
Giảm lược được thời gian kiểm thử và có một kết quả kiểm thử chính xác nhất
thì việc tìm ra các phương pháp và xây dựng công cụ hỗ trợ kiểm thử là rất cần thiết.
Hiện nay trên thị trường việc kiểm thử đơn vị (Unit test) chỉ được thực hiện trực tiếp
trên các môi trường phát triển như Eclipse, Android Studio mà chưa có một công cụ
nào hỗ trợ kiểm thử đơn vị nào thay thế. Đây chính là lý do để em tìm hiểu phương
pháp và xây dựng công cụ để hỗ trợ kiểm thử Android Junit Test.
2. Nội dung luận văn
Luận văn khái quát về kiểm thử trên các thiết bị thông minh sử dụng hệ điều
hành Android và giới thiệu về nền tảng kiểm thử của hệ điều hành này. Sau đó đi sâu
vào nghiên cứu phương pháp kiểm thử CTS do Google đề xuất để kiểm tra sự tương
thích của Android với các thiết bị sử dụng hệ điều hành này. Từ phương pháp nghiên
cứu đã xây dựng cách tiếp cận kiểm thử một dự án Android Junit Test, đồng thời xây
dựng công cụ hỗ trợ kiểm thử các phần mềm Android Junit trên các thiết bị di dộng
thực tế. Công cụ đã mang lại những ưu điểm đáng kể so với việc kiểm thử trực tiếp
hiện nay trên các môi trường phát triển như Eclipse hay Android Studio. Nó mang đến
một giao diện thân thiện với người dùng và hỗ trợ nhưng tính năng trực quan. Luận
văn cũng đưa ra việc thử nghiệm công cụ CTS Executor trên dự án Android Junit Test
thực tế Knox custom API Test để so sánh với việc kiểm thử trực tiếp dự án này trên
Eclipse. Qua thực nghiệm đã chỉ ra những ưu điểm công cụ CTS Executor mang lại
cũng như chỉ ra những hướng phát triển thêm của luận văn trong tương lai.

14. 7
3. Cấu trúc của luận văn
Nội dung của luận văn được chia thành các chương như sau:
 Chương 1: Giới thiệu về luận văn và lý do chọn đề tài.
 Chương 2: Khái quát về kiểm thử ứng dụng trên điện thoại thông minh sử dụng
hệ điều hành Android.
 Chương 3: Luận văn trình bày phương pháp kiểm thử CTS của Google hỗ trợ
các đối tác kiểm thử thiết bị di động sử dụng nền tảng Android trước khi ra thị
trường.
 Chương 4: Luận văn trình bày cách thức áp dụng phương pháp CTS để xây
dựng công cụ hỗ trợ và phát triển phẩm mềm Android Junit test.
 Chương 5: Luận văn trình bày thực nghiệm trong việc áp dụng công cụ để
kiểm thử một dự án Android Junit Test thực tế so với kiểm thử trực tiếp trên
môi trường phát triển Eclipse.
 Chương 6: Tóm lược kết quả đạt được của luận văn và định hướng phát triển
trong tương lai.

15. 8
CHƯƠNG 2: KHÁI QUÁT VỀ KIỂM THỬ ỨNG DỤNG TRÊN
ĐIỆN THOẠI THÔNG MINH
Đã qua rồi cái thời điện thoại chỉ sử dụng để gọi và nghe, máy tính chỉ giới hạn
dùng trong một số các lĩnh vực. Giờ đây với sự phát triển không ngừng của internet và
trào lưu mạng xã hội bùng nổ từ một chiếc điện thoại thông thường chỉ được cài sẵn
một vài ứng dụng của nhà sản xuất thì nay những thiết bị chạy các hệ điều hành nhúng
như Andoird, iOS...Đặc biệt Android là hệ điều hành mã nguồn mở do Google phát
hành cho phép nhà phát triển tạo ra các phần mềm vô cùng đa dạng và phong phú để
đáp ứng nhu cầu sử dụng và giải trí của người dùng. Và các phần mềm đó cần phải
kiểm thử có đáp ứng được các yêu cầu đề ra hay không.Trong chương này luận văn sẽ
đi vào tìm hiểu khái quát về kiểm thử phần mềm trên hệ điều hành Android [1]:
1. Các yếu tố ảnh hưởng đến hoạt động của phần mềm trên điện thoại thông
minh
Tuổi thọ của pin: Bình thường một chiếc điện thoại có thời lượng pin đủ dùng
trong nhiều ngày nhưng với những chiếc điện thoại thông minh do sử dụng rất nhiều
các dịch vụ giải trí như kết nối mạng, nghe nhạc, xem phim... nên thời lượng pin bị rút
ngắn đi rất nhiều thường xuyên phải nạp điện. Vì vậy khi phát triển phần mềm trên
điện thoại thông minh cần tính toán đến dung lượng pin khi phần mềm đó hoạt động.
Kết nối mạng: Các ứng dụng trên điện thoại luôn tiêu thụ tài nguyên khi chúng
kết nối mạng. Bản chất của di động là vị trí luôn thay đổi người dùng có thể ngắt kết
nối mạng ở những vùng không hỗ trợ. Phần mềm phát triển phải thiết kế có khả năng
hoạt động ngay cả khi không có kết nối mạng (offline) chẳng hạn như gửi thư điện tử
hay viết tin nhắn và ngay sau khi mạng được kết nối thì thư và tin nhắn mà người dùng
đã soạn thảo trước đó được gửi tự động.
Phần cứng khác nhau: Sự khác nhau giữa các thiết bị và phần mềm cài trên
từng thiết bị này, bao gồm kích cỡ màn hình, chipset, bộ nhớ trong, bộ nhớ ngoài, và
những cảm biến được hỗ trợ, GPS, bàn phím và đầu vào của thiết bị. Lý tưởng nhất
phần mềm phát triển có thể hoạt động trên mọi thiết bị phần cứng và nền tảng khác
nhau.
Giới hạn về tài nguyên: Hầu hết các thiết bị di động đều có tài nguyên hạn chế
như tốc độ xử lý của CPU, không gian lưu trữ... Vì vậy vấn đề tiết kiệm tài nguyên hệ
thống của các ứng dụng cũng rất cần được xem trọng.
2. Lựa chọn điện thoại thông minh để kiểm thử
Hầu hết các đội kiểm thử đều không có đủ tất cả mọi mẫu điện thoại cần thiết nên
trên mỗi nền tảng ta có thể chọn ra các thiết bị di động tiêu biểu để kiểm thử.
Chọn đúng thiết bị cần kiểm thử, vì mỗi thiết bị đều có những tính năng đặc thù
riêng ví dụ như iOS thì chỉ có năm mẫu có màn hình kích thước khác nhau là iPad (9.7

16. 9
inches), iPad Mini (7.9 inches), iPhone 4S (3.5 inches) và iPhone 5 (4.0 inches) trong
khi Android thì có tới hơn 10 nhà sản xuất phần cứng như Samsung, Sony, HTC,
Google, LG... với hàng trăm mẫu màn hình kích thước khác nhau. Nắm bắt được các
kiến thức cơ bản của môi trường lập trình SDK để từ đó ta có thể tạo được các máy ảo
(Emulator) phù hợp để kiểm thử. Nhưng việc kiểm thử trên máy ảo khác xa hoàn toàn
với việc kiểm thử trên các thiết bị thực tế. Đây là một trong những sai lầm quan trọng
của việc kiểm thử trên các thiết bị di động. Để đảm bảo ứng dụng hoạt động tốt trên
các thiết bị thật thì nên kiểm thử trên một số các thiết bị như sau:
Các thiết bị phổ biển bao gồm: Iphone 5s của Apple, Nokia N73
Các thiết bị Android phổ biến: Samsung Galaxy Nexus chạy Android 4.0
Các thiết bị ít phổ biến: Sony Xperia Z1, 2
3. Các dạng kiểm thử trên Android.
Kiểm thử đơn vị (Unit testing): Được khuyến nghị nên sử dụng cho các đơn vị
mã nhỏ (API). Một đơn vị mã nhỏ có thể có một vài phương thức riêng lẻ hay phương
thức quan hệ trong một tệp chương trình. Kiểm thử đơn vị chỉ kiểm tra một phần nhỏ
của chương trình để xem chúng hoạt động có đúng không. Với Android, kiểm thử đơn
vị được tạo và chạy như một phần của qui trình phát triển phần mềm. Kiểm thử đơn vị
được viết bởi lập trình viên phát triển phần mềm đó. Các lập trình viên nên phân lập
các thành phần để kiểm thử và phải có khả năng tái kiểm thử. Đó chính là lý do tại sao
kiểm thử đơn vị và các đối tượng giả lập thường đặt cùng nhau.
Kiểm thử tích hợp: Khi kiểm thử đơn bị đã thành công thì kiểm thử tích hợp sẽ
giúp ta kiểm thử được cả ứng dụng khi kết hợp các modul với nhau. Như đã đề cập ở
bên trên kiểm thử đơn vị đã đủ linh hoạt để thay thế các loại kiểm thử khác, bao gồm
cả kiểm thử tích hợp. Bởi kiểm thử tích hợp sẽ cần nhiều mã hơn nên mất nhiều thời
gian, nhất là với các thiết bị di động tài nguyên luôn hạn hẹp. Để khắc phục ta có thể
chạy các công việc tốn thời gian một cách bất đồng bộ và chỉ kiểm thử tích hợp khi
kiểm thử đơn vị đã thành công.
Kiểm thử hoạt động (Activity): Activity là khái niệm đồng nhất và cũng là
thành phần quan trọng nhất trong ứng dụng Android. Một activity là một thành phần
rời rạc và liên kết chia sẻ dữ liệu với các thành phần khác trong Android thông qua
giao diện và các nguồn chạy ngầm. Android SDK cũng bao gồm các nền tảng cho
phép kiểm thử tự động các Activity. Thông thường Andoird Activity cần tích hợp với
hệ thống để thực thi được. Các Activity cần ActivityManager cung cấp vòng đời và
truy cập vào các tài nguyên, hệ thống file và cơ sở dữ liệu. Tương tự Service và
ContentProvider, tất cả các thành phần này được Android testing framework hỗ trợ
cho việc kiểm thử dễ dàng.
Kiểm thử hiệu năng: Quá trình kiểm thử này sẽ đo hiệu năng của các thành
phần trong hệ thống bằng cách lặp đi lặp lại việc gọi một chức năng hay một API nào

17. 10
đó. Kiêm thử hiệu nặng được thực hiện để xác định hệ thống hoặc hệ thống con thực
hiện một khối lượng công việc cụ thể nhanh như thế nào. Nó cũng có thể dùng để xác
nhận và xác minh những thuộc tính chất lượng khác của hệ thống như khả năng mở
rộng, độ tin cậy và sử dụng tài nguyên. Một hệ thống được cho là kiểm tra hiệu năng
tốt phải đảm bảo các yếu tố như liệu có đáp ứng đủ cho người dùng một cách nhanh
chóng, liệu việc xử lý dữ liệu có đáp ứng được yêu cầu của người dùng, khả năng chịu
tải và hơn thế nữa. Ngoài ra liệu có xử lý được số lượng giao dịch lớn cùng một thời
điểm.
Kiểm thử hệ thống: Ứng dụng kiểm thử hệ thống là kiểm thử toàn bộ ứng dụng.
Một vài nền tảng bao gồm cả việc kiểm thử cả chương trình nhỏ chạy ngầm bên dưới.
Có một số các phần mềm kiểm thử tự động có thể sinh ra các tác tử (Agent) chạy
ngầm trên thiết bị di động để tạo ra các test scrip kiểm thử một cách tự động. Các tác
tử này có một vài dạng như chạy trên thiết bị và cho phép chúng tương tác với ứng
dụng hay chạy trên các ứng dụng riêng lẻ. Kiểm thử hệ thống cũng đo đặc tính hiệu
năng của các thành phần lặp lại nhiều lần để có thể tối ưu hóa phần mềm.
Kiểm thử giao diện: Là một quá trình rất quan trọng trong kiểm thử trên điện
thoại thông minh. Một ứng dụng lý tưởng là có thể hoạt động trên mọi phần cứng và
mọi nền tảng. Các thao tác như cuộn (scroll), kéo (drag), xoay màn hình (rotate),
(chọn) click, (giữ lâu) long click, chạm (touch)... Mọi ứng dụng cần phải được kiểm
tra xem có thể hoạt động tốt trên thiết bị đó hay chưa.
Kiểm thử cài đặt: Sau khi đóng gói phần mềm cần cài đặt việc kiểm thử có
thành công không trước khi bàn giao cho khách hàng.
4. Nền tảng kiểm thử Android
Nền tảng kiểm thử của Android cung cấp rất tiện dụng được mở rộng từ nền tảng
kiểm thử của Junit chuẩn với nhiều tính năng phù hợp với các chiến lược kiểm thử.
Những tính năng này bao gồm:
 Bổ sung các class Android mở rộng từ JUnit cho phép truy cập vào các
đối tượng hệ thống trong Android.
 Instrumentation framework cho phép kiểm soát và kiểm tra ứng dụng.
 Các đối tượng giả lập (Mock) được sử dụng phổ biến trong hệ thống
Android để kiểm tra khả năng chịu tải của các ứng dụng.
 Các công cụ cho phép thực hiện kiểm thử riêng lẻ hay chạy cả một dãy
các lệnh kiểm thử mà có thể không cần đến Instrumentation framework
(IF).
 Hỗ trợ quản lí kiểm thử trong ADT plugin của Eclipse và cả chế độ dòng
lệnh của hệ điều hành.

18. 11
4.1. Instrument framework (IF)
Instrumentation framework là một phần cơ bản của nền tảng kiểm thử trong
Android. IF điều khiển ứng dụng kiểm thử và cho phép gắn các đối tượng thay thế giả
lập (Mock object) vào ứng dụng để chạy. Ví dụ ta có thể tạo một đối tượng giả lập
Context trước khi ứng dụng bắt đầu và cho phép ứng dụng sử dụng nó. Tất cả mọi
tương tác giữa ứng dụng và môi trường xung quanh có thể sử dụng phương pháp tiếp
cận này. Ta cũng có thể tách riêng ứng dụng của chúng ta trong một môi trường giới
hạn để lấy về kết quả, hoặc các dữ liệu được lưu trữ và không thay đổi như Content
Provider, cơ sở dữ liệu hay thậm chí là hệ thống các tệp tin.
Một dự án Android thường có một dự án kiểm thử tương ứng với tên kết thúc
bằng “Test”. Bên trong một dự án kiểm thử file AndroidManifest.xml khai báo thẻ cho
biết IF là <instrumentation></ instrumentation>. Ví dụ: giả sử dự án Android có file
manifest có dạng sau:
Hình 2. 1 : Định dạng file manifest trong Android Junit Test
Nhìn ví dụ này có thể thấy ngay rằng trong thẻ khai báo IF là <instrumentation>
với thuộc tính name là trình chạy kiểm thử test runner, class mặc định của Android
testing API (android.test.runner), ta cũng có thể tùy biến class này bằng cách kế thừa
từ class InstrumentationTestRunner, thuộc tính targetPackage chỉ ra package của ứng
dụng mà ta muốn kiểm thử (trong ví dụ là AddressContacts).

19. 12
4.2. Kiến trúc kiểm thử trên Android
Hình 2. 2 : Kiến trúc testing framework [1]
Trong kiến trúc này InstrumentationTestRunner làm nhiệm vụ trung gian trong
việc chạy các các ca kiểm thử. Các thành phần chính trong kiến trúc này:
- Application package: chứa toàn bộ ứng dụng để kiểm thử.
- Test projects: chứa các mã nguồn, file manifest và những file khác dùng để
kiểm thử ứng dụng. Ta có thể sử dụng Eclipse để tạo ra dự án kiểm thử này.
- Testing API: Nơi chứa các ca kiểm thử đã được cài đặt.
- Junit: có thể sử dụng các class Junit testcase để kiểm thử đơn vị.
- Instrumentation: Android Instrumentation là một tập các phương thức điều
khiển trong hệ thống Andoird. Các điều khiển này độc lập với vòng đời của ứng
dụng và chúng cũng kiểm soát cách Android tải ứng dụng để chạy. Thông
thường Android framework không cung cấp cách để gọi trực tiếp các hàm
callback trong vòng đời của một ứng dụng như onCreate(), onResume(),...
nhưng với instrumentation ta có thể gọi các hàm này thông qua các phương
thức như getActivity(), activity.finish(),...
- Test case classes: Android cung cấp một vài class kế thừa từ lớp TestCase và
Assert của Junit framework như Application TestCase, Instrumentation
TestCase,...
- Mock Object: để chống sự phụ thuộc (dependency injection) trong kiểm thử,
Adroid cung cấp các class để tạo các đối tượng hệ thống giả lập như
MockContext, MockContentProvider,...

20. 13
- MonkeyRunner: những API để thực thi trong môi trường với ngôn ngữ là
Python.
- Monkey: một công cụ dòng lệnh để kiểm thử khả năng chịu tải của ứng dụng
thông qua công cụ adb của hệ điều hành Android.
5. Các mục tiêu kiểm thử
Trong suốt quá trình phát triển phần mềm, các ca kiểm thử sẽ hướng đến các thiết
bị khác nhau. Từ đơn giản, phức tạp và tốc độ kiểm thử trên máy ảo đến trên một thiết
bị thật cụ thể nào đó. Ngoài ra có một vài trường hợp trung gian như chạy kiểm tra
trên một máy ảo cục bộ JVM hay DVM, phụ thuộc vào từng trường hợp. Mỗi trường
hợp đều có ưu và nhược điểm riêng. Máy ảo có lẽ là thiết bị phù hợp nhất mà ta có thể
thay đổi gần như tất cả các tham số cấu hình để mô phỏng các điều kiện khác nhau cho
các ca kiểm thử.
Thiết bị thật dùng để kiểm thử hiệu năng vì trên máy ảo sẽ không thể tính ra
được các thông số trên thiết bị thật sẽ như thế nào. Rendering, filling, và các trường
hợp khác phải được kiểm tra trước khi ứng dụng được chuyển giao cho người dùng
cuối. Tóm lại ứng dụng nên được kiểm tra ở mọi trường hợp, đây là cách tốt nhất để
phát hiện những lỗi trước hơn khi là lỗi được phát hiện bởi khách hàng khi sử dụng.

21. 14
CHƯƠNG 3: GIỚI THIỆU VỀ CTS
1. Giới thiệu về Compatibility Test Suite (CTS)
Hệ điều hành Android được phát triển bởi Google từ năm 2008 và đã phát hành
12 phiên bản tính đến tháng 10 năm 2016. Tính đến năm 2014 đã có hơn 1 tỉ 3 thiết bị
sử dụng hệ điều hành Android được đưa ra thị trường. Mỗi chiếc điện thoại sử dụng
Android trước khi đến với tay người dùng phải vượt qua tất cả các ca kiểm thử sự
tương thích của phần cứng và phần mềm thông qua bộ các ca kiểm thử của Google
phát hành song song với từng phiên bản hệ điều hành Android. Quá trình bao gồm các
bước sau:
Hình 3.1 : Qui trình đạt được Google’s certification
Để hỗ trợ nhà sản xuất kiểm thử bộ các ca kiểm thử này trên các sản phẩm của
họ, Google đã đưa ra một phương thức CTS (Compatibility test suite). Compatibility
Test Suite [2] là một phương thức nhằm hỗ trợ chạy các ca kiểm thử nhanh và chính
xác nhất. Nếu thiết bị thỏa mãn được bộ các ca kiểm thử này thì Google mới cấp phép
cho sử dụng hê điều hành của họ. Mỗi phiên bản mới của hê điều hành Android được
phát hành Google đều đưa ra ra một bộ kiểm thử bao gồm các API mới của phiên bản
Android đó.
Bảng 3.1 : Bảng các ca kiểm thử cho các phiên bản Android
Phiên bản Android Phiên bản CTS Số ca kiểm thử
Jelly bean 4.2 CTS 4.2_r5 24924
Kit Kat 4.4 CTS 4.4_r4 24924
Lollipop 5.0 CTS 5.0_r8 98926
Lollipop 5.1 CTS 5.1_r9 100970
Marshmallow 6.0.1 CTS 6.0_r8 127028
Nougat 7.0 CTS 7.0_r3 403124

22. 15
Quá trình kiểm thử sẽ được mô phỏng đơn giản theo mô hình sau:
Hình 3.2 : Phương thức sử dụng CTS
Phương thức kiểm thử này gồm bốn bước cơ bản:
- Bước 1: Tải và cài đặt CTS trên máy tính.
- Bước 2: Kết nối thiết bị cần kiểm thử với máy tính qua dây cáp USB.
- Bước 3: Thực thi CTS. Toàn bộ ca kiểm thử sẽ được đẩy qua thiết bị và sẽ
được thực thi trên thiết bị sau đó kết quả sẽ được trả về và lưu trữ trên máy
tính.
- Bước 4: Kiểm tra kết quả của các ca kiểm thử.
2. Nguyên lý và cách thức làm việc của CTS [3].
Hình 3.3 : Cấu trúc của CTS

23. 16
Phương pháp CTS gồm 3 phần chính Repository, Tools, Docs.
2.1. Docs
Phần này bao gồm các tài liệu của Google giới thiệu về hệ điều hành Android
tương ứng với phiên bản đó. Các API được sử dụng trong từng phiên bản của hệ điều
hành này bao gồm tên API, các tham số của nó và miêu tả chi tiết hoạt động của API
đó.
2.2. Repository
Phần này gồm 3 phần: Test case, Plans và Result.
Phần 1: Testcases - Trong thư mục testcase có chứa các tệp .apk( nội dung các ca
kiểm thử) và tệp .xml (tên các ca kiểm thử). Hai tệp này được đặt tên giống nhau
Danh sách các ca kiểm thử được liệt kê theo tệp .xml như sau:
Hình 3.4 : Danh sách các ca kiểm thử
Tệp .apk (android application package) là bộ cài đặt ứng dụng trên hệ điều hành
android. Khi build các ca kiểm thử tương ứng sẽ được tệp này. Nó chính là file nén
ZIP dự trên định dạng JAR sử dụng phần mở rộng là *.apk.
Hai tệp .xml và .apk được đặt tên giống nhau và đặt trong thư mục “.android-
ctsrepositorytestcases”.
Hình 3.5 : Danh sách các tệp .xml và .apk
Phần 2: Plans - Việc gọi các ca kiểm thử (.xml) tương ứng với nội dung ca kiểm thử
(.apk) sẽ được thực thi nhờ vào một tệp tin “plan” trong thư mục “.android-
ctsrepositoryplans”. Nó khai báo tên gói “package”của tệp tin .apk cần được kiểm
thử.

24. 17
Hình 3.6 : Danh sách các pakage trong Plan
Phần 3: Results - Chứa kết quả sau khi kiểm thử ở thiết bị dưới dạng .xml. Các ca
kiểm thử sau khi được thực thi trên thiết bị kiểm thử sẽ trả về kết quả tương ứng. Các
kết quả này sẽ được lưu trữ trong thư mục “.android-ctsrepositoryresults”.
2.3. Tools
Trong phần này chứa 6 tệp tin phục vụ cho quá trình kiểm thử. Trong đó tệp tin
cts-tradefed chứa tất cả các lệnh điều khiển thực thi của phương pháp CTS. Nó chính
là giá trị cốt lõi của phương pháp CTS. Và được cài đặt các câu lệnh command để hỗ
trợ trong quá trình kiểm thử.
Bảng 3.2: Câu lệnh hỗ trợ kiểm thử trong CTS
STT Câu lệnh hỗ trợ Ý nghĩa của câu lệnh
1 run cts --plan <test_plan_name> Kiểm thử một plan
2 run cts --package <package_name> Kiểm thử một package
3 run cts --class <class_name> Kiểm thử một class
4 run cts --plan
<packageName.className.TestcaseName>
Kiểm thử một testcase
5 run cts --plan <planName> --shards
<number device>
Kiểm thử một plan trên
nhiều thiết bị cùng lúc
6 run cts --continue-session <Session_ID> Kiểm thử lại trên kết quả
đã kiểm thử trước đó
7 run cts --help Gọi lệnh hỗ trợ

25. 18
3. Cài đặt phương pháp CTS
3.1. Môi trường vật lý trên thiết bị kiểm thử
Wifi: Tùy theo nhu cầu của ứng dụng chạy ta yêu cầu phải kết nối wifi hay
không. Thiết bị được kiểm thử (Device Under Test –DUT) có thể là điện thoại di động,
đồng hồ thông minh.. sẽ kết nối wifi phục vụ cho việc kiểm thử để đảm bảo các ca
kiểm thử được thực thi trong môi trường chuẩn và cho kết quả chính xác. Một số
testcase sẽ được kiểm thử bằng môi trường mạng di động nên việc sử dụng dữ liệu di
động từ thẻ sim cũng sẽ được yêu cầu.
Bluetooth: Nếu thiết bị test hỗ trợ bluetooth và yêu cầu phải được kết nối với
bluetooth trong các ca kiểm thử thì phải đặt ít nhất ba điểm phát bluetooth trong bán
kính năm mét.
Thẻ sim: Thiết bị cần được lắp sim nếu nó hỗ trợ tính năng SIM.
Thẻ nhớ: Thiết bị cần lắp thẻ nhớ nếu phần cứng hỗ trợ khe thẻ nhớ.
3.2. Cài đặt môi trường máy tinh
ADB và AAPT: Trước khi chạy CTS phải đảm bảo được cả Android Debug
Bridge (adb) và Asset Package Tool (AAPT) được cài đặt trong đường dẫn hệ thống
máy tính.
Java Development Kit (JDK): Cần cài đặt chính xác phiên bản của java
development kit:
- CTS 5.0 and later: Java 7
- CTS 4.4 and earlier: Java 6
Tải và đọc hướng dẫn sử dụng công cụ CTS của Google tại địa chỉ trang web:
https://source.android.com/compatibility/downloads.html
3.3. Cài đặt trên thiết bị kiểm thử
Trước khi chạy CTS phải khôi phục cài đặt gốc của thiết bị bằng cách truy cập
thiết bị vào phần Cài đặt > Sao lưu và cài đăt > Khôi phục và cài đặt.
Lưu ý: Quá trình này sẽ xóa sạch dữ liệu của người sử dụng thiết bị.
- Cài đặt ngôn ngữ trên thiết bị.
- Bật dữ liệu di động, định vị của thiết bị.
- Kết nối wifi, bluetooth nếu các ca kiểm thử có yêu cầu.
- Đảm bảo thiết bị không được bảo mật.
- Khởi tạo chế độ USB debugging trên thiết bị bằng cách truy cập vào Cài
đặt sau đó chọn cài đặt cho người phát triển và kích hoạt chế độ kết nối
USB.

26. 19
- Khởi tạo chế độ bật màn hình bằng cách truy cập vào Cài đặt sau đó chọn
cài đặt cho người phát triển và bật màn hình.
- Kết nối đến máy tính sử dụng dây cáp USB .
- Đăng nhập tài khoản Google cho thiết bị cần kiểm thử sự tương thích.
Sau khi tải công cụ CTS từ trang web bên trên, giải nén ra và sẽ nhìn thấy một
thư mục “adroid-cts/repository/testcase”. Sau đó cài đặt tệp “CTSDeviceAdmin.apk” sử
dụng câu lệnh “adb install CtsDeviceAdmin.apk”.
Kích hoạt quyền quản trị “administrator” cho thiết bị bằng cách truy cập vào cài
đặt chọn bảo mật và chọn quản trị thiết bị và kích hoạt 2 chức năng sau:
- Android.deviceadmin.cts.CtsDeviceAdminReceiver.
- Android.deviceadmin.cts.CtsDeviceAdminReceiver2.
4. Cách chạy các ca kiểm thử CTS
4.1. Sao chép dữ liệu vào thiết bị.
Việc đầu tiên cần làm là sao chép toàn bô dữ liệu phục vụ kiểm thử vào thiết bị.
Các dữ liệu trong tệp này sẽ được dùng khi thực thi các ca kiểm thử. Và có thể tải về
tại địa chỉ http://dl.google.com/dl/android/cts/android-cts-media-1.0.zip.
Giải nén tệp tin “android-cts-media-1.0.zip” vừa mới tải được bên trên sau đó
chỉnh sửa file” copy_media.sh” sau khi giải nén tại dòng 17 “max_resolution=0” đổi
thành “max_resolution =3”.
Chạy tệp “copy_medias.sh” bằng cách truy cập trực tiếp đường đẫn đến bộ nhớ
chứa nó và chạy trên cửa sổ lệnh.
Đưa thiết bị cần kiểm thử về màn hình chính để bắt đầu kiểm tra sự tương thích
của thiết bị với hệ điều hành Android.
4.2. Kiểm thử một Plan
Bước 1: Kết nối thiết bị cần kiểm thử với máy tính (PC) sử dụng hê điều hành
Linux.
Bước 2: Đưa thiết bị trở về màn hình chính để bắt đầu quá trình kiểm thử.
Bước 3: Trong khi thiết bị chạy CTS không được thực thi bất kỳ một tác vụ nào
khác và phải giữ thiết bị ở trạng thái tĩnh (tránh các cảm biến tác động đến nó).
Bước 4: Không được chạm vào bất kỳ phím nào trên thiết bị khi quá trình kiểm
thử đang diễn ra. Vì đây là kiểm thử tự động nên việc nhấn vào bàn phím hay chạm
vào màn hình của thiết bị kiểm thử sẽ gây trở ngại đến quá trình kiểm thử và gia tăng
số lượng lỗi của các ca kiểm thử dẫn đến mất nhiều thời gian chạy lại để đạt được một
kết quả kiểm thử ổn định nhất.

27. 20
Bước 5: Nếu muốn quá trình kiểm thử diễn ra nhanh hơn thì nên xóa các kết quả
của những lần kiểm thử trước bằng cách truy cập “android-cts/repository/result/...”.
Bước 6: Khởi tạo giao diện điều khiển CTS (console) bằng cách chạy cts-
tradefed script từ thư mục nơi mà gói CTS được tải về và giải nén. Ví dụ: $ ./android-
cts/tools/cts-tradefed.
Bước 7: Kiểm tra xem đã chạy được tệp tin “cts-tradefed” chưa bằng dòng hiển
thị thiết bị đã được kết nối đến máy tính để thực hiện kiểm thử.
Bước 8: Gõ câu lệnh command “run cts--plans CTS-TF” để bắt đầu kiểm thử
trên thiết bị đã được kết nối hoặc cũng có thể chọn Plan mặc định “run cts—plans
CTS”.
Lưu ý: Xem tiến trình thử nghiệm và báo cáo kết quả trên màn hình điều khiển
(console). Nếu thiết bị của bạn là Android 5.0 hoặc mới hơn và hỗ trợ cho một ARM
và x86ABI, có thể thực thi cả 2 gói ARM và x86 CTS.
4.3. Các câu lệnh hỗ trợ tối ưu thời gian kiểm thử.
Thông thường mỗi bộ kiểm thử của Google trên các thiết bị Andoroid từ vài chục
nghìn đến hơn bốn trăm nghìn ca kiểm thử. Vì thế nếu chỉ chạy trên một thiết bị tại
một thời điểm thời gian kiểm thử sẽ mất khoảng 12- 24 giờ. Vì vậy Google đã đưa ra
một giải pháp có thể kiểm thử cùng một lúc với nhiều thiết bị cần kiểm tra bằng cách
tự động phân chia các gói (package) lần lượt cho các thiết bị với các yêu cầu sau:
Các thiết bị kiểm thử được cấu hình cùng phiên bản phần mềm.
Cài đặt môi trường cần thiết để kiểm thử cho tất cả các thiết bị và kết nối các
thiết bị này với máy tính.
Sử dụng câu lệnh “run cts –plan CTS-TF –shard # “ (# số thiết bị đã kết nối với
máy tính để kiểm thử).
Kết quả sau khi kiểm thử sẽ chứa thông tin của tất cả các thiết bị.
Với việc hỗ trợ kiểm thử đồng thời trên nhiều thiết bị cùng lúc đã giảm thiểu
được tối đa thời gian kiểm tra sự tương thích của phần mềm Android đối với phần
cứng của thiết bị. Đây là một ưu điểm cực mạnh của phương pháp CTS đưa ra giúp
các nhà sản xuất tiết kiệm thời gian, công sức trong quá trình kiểm thử.

28. 21
4.4. Tái kiểm thử trên kết quả cũ.
Do bộ kiểm thử có quá nhiều ca kiểm thử nên khi kiểm thử một lần thì khó có thể
ra một kết quả chính xác hoàn toàn vì vậy viêc chạy lại các ca kiểm thử bị lỗi để xác
định tín đúng đắn của nó là rất cần thiết. Các bước để chạy lại như sau:
Truy cập đến thư mục chứa kết quả vừa mới tạo ra sau khi kiểm thử lần đầu tại
“android-cts/repository/results/2016.xx.xx_xx.xx.xx”. Chọn file “testResult.xml” và
mở nó bằng Notepad hoặc Notepad++. Thay thế toàn bộ những ca kiểm thử “fail” và
“timeout” bằng “notExecute” và lưu kết quả đó lại. Khi đó những ca kiểm thử bị lỗi
“fail” sẽ chưa được thực thi “notExecute”, phương pháp CTS sẽ nhận diện được các ca
kiểm thử này và chỉ tái kiểm thử trên những ca kiểm thử đó.
Ví dụ:
<Test name = “testPermissionDeffiCert” result = ”fail” starttime = “>
Khi đã thực thi xong các ca kiểm thử chúng ta sẽ có danh sách các kết quả.
Sử dụng lệnh “ l r” để check các phiên “session” đã thực thi kiểm thử như hình dưới
đây.
Theo như hình trên Plan này đã được kiểm thử 4 lần, các session ID lần lượt là 0,1,2,3.
Tương ứng với các session là số ca kiểm thử Pass, Fail và Not Executed. Muốn chạy
lại session nào đó thì sử dụng câu lệnh “ run cts – continue-session SESSION_ID”.
Việc chỉnh sửa và thực thi lại các ca kiểm thử lỗi này ít nhất 3 lần thì sẽ được kết quả
kiểm thử tương đối chính xác.
4.5. Báo cáo kết quả
Sau khi tiến trình kiểm thử kết thúc truy cập đến thư mục “android-
ctsrepositoryresults”. Ở đó liệt kê tất cả các kết quả của các ca kiểm thử, tìm đến ca
kiểm thử mới nhất vừa thực thi theo ngày, tháng, năm và giờ kiểm thử dùng để đặt tên
của thư mục kết quả.
Hình 3.7 : Thư mục kết quả chạy

29. 22
Ở thư mục này sẽ nhìn thấy tệp tin “testResult.xml” đó chính là kết quả kiểm thử
được xuất ra theo định dạng .xml. Chọn “testResult.xml” để mở sẽ có kết quả như hình
sau:
Hình 3.8 : Minh họa cho kết quả chạy bằng phương pháp CTS
Kết quả xuất ra định dạng tệp tin .xml, ở kết quả này có thể nhìn thấy các thông
tin như tên thiết bị kiểm thử là Nexus 4, các đặc tính của thiết bị, phiên bản hệ điều
hành và số lượng các ca kiểm thử Pass, Fail...
Kiểm tra số lượng ca kiểm thử “Pass”, “Fail”, “Timed out”, “Not executed”.
Hình 3.9 : Chi tiết kết quả chạy của một ca kiểm thử

30. 23
CHƯƠNG 4: ỨNG DỤNG CHẠY CTS TRONG KIỂM THỬ
ANDROID JUNIT TEST PROJECT
Với mỗi dự án kiểm thử (Android Junit) tạo ra hàng trăm, hàng nghìn ca kiểm
thử cho nên việc áp dụng các phương pháp kiểm thử bình thường sẽ tốn kém rất nhiều
thời gian và nhân lực. Việc áp dụng CTS trong phương pháp kiểm thử các dự án
Android trên các thiết bị di động sẽ tiết kiệm được thời gian thực thi và thực thi được
những ca kiểm thử tự động. Chương này giới thiệu chi tiết việc ứng dụng CTS trong
kiểm thử dự án Android Junit Test.
1. Phương pháp CTS áp dụng kiểm thử với dự án Android Junit Test
Dựa trên phương pháp kiểm thử CTS được Google xây dựng và phát triển luận
văn đã xây dựng một công cụ hỗ trợ kiểm thử các dự án Android Junit Test. Với mỗi
dự án kiểm thử Android Junit test được biên soạn và kiểm thử luôn trên IDE
(Intergrated Development Environment) ví dụ như Eclipse hay Android Studio. Sau
khi biên dịch trình biên dịch sẽ build toàn bộ dự án ra một tệp tin .apk. Tệp tin này sau
đó sẽ được đẩy sang thiết bị cần kiểm thử và chay, kết thúc một ca kiểm thử trên thiết
bị thì kết quả sẽ được hiển thị ra màn hình IDE. Việc kiểm thử trực tiếp như thế này có
rất nhiều mặt hạn chế, ví dụ như không thể kiểm thử đồng thời bộ các ca kiểm thử trên
nhiều thiết bị để giảm thiểu thời gian chạy hoặc quá trình kiểm thử sẽ bị chấm dứt nếu
như thiết bị bị khởi động lại khi chưa hoàn tất kiểm thử hết tất cả các ca kiểm thử... Và
kết quả xuất ra màn hình IDE thì chỉ có thể xuất ra dưới định dạng file .xml rất khó
cho việc báo cáo và thống kê kết quả sau khi kiểm thử. Để giải quyết được các vấn đề
khi kiểm thử một dự án Android Junit Test thì ta có thể áp dụng phương pháp CTS.
Tại sao phương pháp CTS chỉ áp dụng kiểm thử được với các dự án Andoird
Junit Test mà ko áp dụng được cho các dự án khác như Java Juint,... là bởi vì chỉ dự án
Android Junit Test sau khi build sẽ được file .apk (chứa nội dung các ca kiểm thử) cái
mà cần đẩy vào thiết bị kiểm thử và trả về kết quả trên màn hình. Điều này phù hợp
với các yêu cầu của CTS. Còn các loại dư án khác như Java Junit thì kiểm thử trực tiếp
trên máy tính không cần thông qua các thiết bị đi động trực quan.
Hiện nay trên thị trường ngoài việc kiểm thử trực tiếp trên môi trường phát triển
thì chưa có một công cụ nào được xây dựng để hỗ trợ kiểm thử dự án Android Junit
Test. Do đó để áp ứng nhu cầu phát triển của các ứng dụng di động hiện thời thì việc
ra đời một công cụ hỗ trợ kiểm thử là rất cấp thiết và hữu ích cho các nhà phát triển.
Dưới đây là cách tiếp cận dự án Android Junit Test từ phương pháp CTS cho việc phát
triển và xây dựng công cụ CTS Executor.

31. 24
Hình 4.1 : Xây dựng tệp .apk và .xml từ dự án
Bước 1: Từ dự án Android Junit Test cần được kiểm thử trên thiết bị di động
Android, xây dựng tập hợp các ca kiểm thử định dạng .xml
Bước 2: Tệp tin .apk được biên dịch ra từ dự án Android Junit Test
Bước 3: Tệp tin tập hợp tất cả các ca kiểm thử (.xml) từ bước một và tệp .apk từ
bước hai phải được đặt tên giống nhau và cho cùng vào đường dẫn của CTS “android-
ctsrepositorytestcases”. Hình sau biểu diễn ví dụ hai tệp tin .apk và .xml được xây
dựng từ dư án thực tế KNOX.
Hình 4.2 : Tệp tin .apk được biên dịch từ dự án Android Junit Test
Định dạng của tệp .xml như hình sau để đảm bảo các điều kiện của kĩ thuật CTS:
Hình 4.3 : Nội dung cho tập tin .xml
Sau khi đã xây dựng được hai tệp tin .apk và .xml từ dự án Android Junit Test thì cấu
hình lại tệp tin “plan” trong thư mục “android-ctsrepositoryplans” bằng cách gọi tên
gói (package) của tệp tin .apk đó.

32. 25
Hình 4.4 : Cấu trúc của tệp Plan
Sau đó sử dụng các câu lệnh command của CTS để xây dựng lên công cụ thực thi các
ca kiểm thử của dự án Android Junit Test.
2. Cách tạo tệp tin .apk và .xml từ Eclipse
2.1. Tạo tệp tin .apk sử dụng Eclipse
Như đã giới thiệu ở phần một của chương này, muốn đưa nội dung các ca kiểm
thử (.apk) thì phải build từ dự án cần kiểm thử Android Junit Test sử dụng Eclipse
hoặc Android Studio. Phần này luận văn sẽ đi vào chi tiết cách tạo tệp tin .apk từ một
dự án trên Eclipse [5].
Dự án Android Junit Test ở đây luận văn xây dựng có tên là Knox Custom Api
Testcase gồm có 4 package và 416 ca kiểm thử. Để xây dựng được tệp .apk bước đầu
tiên là máy tính được kết nối với thiết bị cần kiểm thử thông qua phương thức “adb”.
Sau khi thiết bị được kết nối, gõ lệnh command “adb devices” để kiểm tra và kết quả
hiển thị như hình sau:
Hình 4.5 : Kiểm tra trạng thái của thiết bị kiểm thử
Sau khi kết nối thành công tên thiết bị sẽ được hiển thị ví du “8ae2fae8”. Sau đó
click chuột phải vào tên dự án sau đó chọn Run as với Andoird Junit Test [6].
Hình 4.6 : Xây dựng tệp .apk từ dự án kiểm thử sử dụng Eclipse

33. 26
Khi build dự án thành công thì sẽ sinh ra một tệp tin .apk trong thư mục
/KnoxCustomApiTestCase/bin của dự án với tên giống với tên dự án. Tệp tin .apk này
sẽ chứa toàn bộ nội dung của dự án.
Hình 4. 7 : Đường dẫn chứa tệp .apk sau khi build bằng Eclipse
2.2. Cách tạo tệp tin .xml từ dự án trên Eclipse
Để tạo tệp .xml từ dự án cần kiểm thử có được định dạng phù hợp đúng chuẩn
của phương pháp CTS luận văn đã phát triển một công cụ hỗ trợ làm việc này có tên là
“Create_CTS _Plan”. Công cụ được phát triển bằng Java, đầu vào là dự án cần kiểm
thử và đầu ra là tệp .xml chứa toàn bộ tên của các ca kiểm thử được include và loại bỏ
đi các ca kiểm thử đã được exclude.
Hình 4.8 : Công cụ tạo file .xml từ dự án Android Junit

34. 27
1. Chọn đường dẫn chỉ tới nơi đặt dự án kiểm thử cần tạo file .xml
2. Chọn nơi lưu trữ tệp tin .xml của dự án sau khi đã được tạo ra.
Với công cụ này việc tạo ra tệp tin .xml thỏa mãn theo điều kiện của phương thức
CTS rất đơn giản và nhanh. Tệp tin sau khi tạo ra sẽ có định dạng phù hợp với chuẩn
của phương pháp CTS. Có chứa tên dự án, tên package và các TestSuite chứa tên của
các ca kiểm thử.
Hình 4.9 : Test suite diagram
Hình 4.10 : Tệp tin .xml sau khi được tạo ra từ dự án kiểm thử

35. 28
Sau khi tạo thành công hai tệp .apk và .xml thì đổi tên hai tệp này cho giống tên
nhau và đưa vào thư mục “android-ctsrepositorytestcases”. Sử dụng công cụ CTS
Executor và thiết bị kiểm thử để chuẩn bị quá trình kiểm thử.
3. Quá trình kiểm thử trên thiết bị
Thiết bị đã được kết nối và hiển thị thông tin thiết bị như tên thiết bị, trạng thái
thiết bị kiểm thử (wifi, bluetooth, sim). Nếu có nhiều thiết bị cùng kiểm thử một lúc
khi đó máy tính sẽ không đủ cổng USB để kết nối, ta có thể sử dụng thêm thiết bị
multi USB port. Mỗi thiết bị này có thể hỗ trợ kết nối từ 5 đến 10 thiết bị cùng lúc.
Hình 4.11 : Multi USB Port
Sau khi thiết bị kiểm thử được kết nối thành công và nhấn vào nút bắt đầu kiểm
thử. Tệp tin .apk chứa nội dung các ca kiểm thử sẽ được chuyển vào thiết bị và cài đặt
trên thiết bị kiểm thử. Sau khi cài đặt thành công, với mỗi lần gọi tên ca kiểm thử
trong tệp .xml sẽ xác định tương ứng với nội dung của ca kiểm thử đó trong .apk và
thực thi nó trên thiết bị kiểm thử. Thiết bị kiểm thử thực thi xong và gửi về kết quả
trên máy tính theo đúng quy trình của phương pháp CTS.
Hình 4.12 : Quá trình kiểm thử trên thiết bị di động

36. 29
4. Ưu điểm của công cụ so với kiểm thử trực tiếp trên Eclipse.
Công cụ CTS Executor mang lại rất nhiều lợi ích như tiết kiệm thời gian kiểm
thử, tái kiểm thử những ca kiểm thử bị fail trên thiết bị mà không cần chạy lại toàn
bộ... Dưới đây luận văn trình bày về những ưu điểm khi áp dụng phương pháp CTS để
xây dựng công cụ hỗ trợ kiểm thử trên dự án Android Junit Test so với cách kiểm thử
trực tiếp bằng công cụ phát triển Eclipse.
Thế mạnh của công cụ CTS Executor là hỗ trợ kiểm thử đơn vị tuy nhiên công cụ
này cũng có những mặt hạn chế như chưa hỗ trợ chạy cho các loại kiểm thử khác như
kiểm thử hiệu suất, security test hay stress test. Đây cũng chính là hướng phát triển
tiếp theo của luận văn để tìm ra nhiều giải pháp hỗ trợ các loại kiểm thử này mà một
số đã được Google xây dựng nền tảng sẵn như UI Automator cho kiểm thử tự động
Android hay Robotium Android Testing tool cho kiểm thử giao diện (user interface).
Bảng 4.1 : Bảng minh họa ưu điểm của công cụ CTS Executor
STT Chức năng Kiểm thử
trực tiếp trên
Eclipse
Kiểm thử bằng công cụ CTS
Excecutor.
1 Tự động chạy lại Không thể Có thể tự động chạy lại đến khi có một
kết quả chính xác đáng tin cậy
2 Kiểm thử đồng
thời trên nhiều
thiết bị cùng lúc
Không thể Có thể kiểm thử trên nhiều thiết bị tối đa:
5 thiết bị
3 Tái kiểm thử khi
thiết bị tự động
khởi động lại
Không thể Quá trình kiểm thử sẽ được tiếp tục sau
khi thiết bị khởi động xong
4 Xuất kết quả ra
file excel
Chỉ xuất được
kết quả dưới
dạng .xml
Xuất kết quả dưới định dạng excel giúp
viêc xác định các ca kiểm thử dễ dàng
hơn
5 Kiểm tra trạng
thái của thiết bị
kiểm thử
Không kiểm
tra được
Hiển thị trên giao diện giúp người kiểm
thử dễ dàng nhận thấy các trạng thái của
thiết bị như wifi, bluetooth, device
connect.
6 Hiển thị tiến độ
kiểm thử của dự
án
Không hiển
thị được tiến
độ kiểm thử
Tiến độ chạy được cập nhật liên tục sau
mỗi ca kiểm thử
7 Đưa kết quả sau
khi kiểm thử lên
Không đưa
được
Kết nối với một server chung. Sau khi
kiểm thử hoàn tất kết quả sẽ được cập
nhật lên để mọi người có thể vào kiểm
tra.

37. 30
CHƯƠNG 5: XÂY DỰNG CÔNG CỤ CTS EXECUTOR
Chương 4 đã đưa ra được phương pháp áp dụng, chương này luận văn xin giới
thiệu về xây dựng công cụ để hỗ trợ kiểm thử dự án Android Junit Test dựa trên
phương pháp CTS. Thay vì phải gõ các dòng lệnh command, công cụ sẽ hỗ trợ giao
diện trực quan giúp người kiểm thử không phải nhớ các dòng lệnh phức tạp mà vẫn có
thể kiểm thử một cách dễ dàng. Đồng thời công cụ sẽ mang lại những ưu điểm, tiện ích
hỗ trợ nhà phát triển trong quá trình kiểm thử.
1. Môi trường và các công cụ sử dụng để thực nghiệm.
1.1. Cấu hình phần cứng
Bảng 5.1 : Bảng minh họa cấu hình phần cứng để chạy công cụ CTS Executor
Thành phần Chỉ số
CPU 2.2 GHz Core Due Intel
RAM 2GB
OS Windows 7
Bộ nhớ ngoài 320GB
1.2. Các phần mềm sử dụng
Bảng 5.2 : Danh sách các phân mềm sử dụng
STT Tên Phần mềm Tác giả Chức năng Nguồn
1 Eclipse Version:
Mars.2 Release
(4.5.2)
Oracle Môi trường
phát triển
http://www.eclipse.org/downloa
ds
2 Android
Development
Tool
Google Môi trường
phát triển
https://developer.android.com/st
udio/tools/sdk/eclipse-adt.html
3 SDK Manager Google Môi trường
phát triển
https://developer.android.com/st
udio/index.html
4 Java SE Runtime
Environment 8
Oracle Môi trường
phát triển
http://www.oracle.com/technet
work/java/javase/downloads/jre
8-downloads-2133155.html

38. 31
Ngoài các phần mềm sử dụng bên trên luận văn còn tiến hành cài đặt các modul
sau:
- Cài đăt biến môi trường Adb từ bộ SDK vào hệ thống.
- Tập các ca kiểm thử để tiến hành thử nghiệm được lấy từ dự án Knox
Custom Api TestCase gồm hai tệp tin .apk và .xml.
- Trên thiết bị kiểm thử cài đặt Wifi, Bluetooth, Sim để tiến hành kiểm thử.
2. Phân tích thiết kế phần mềm
2.1. Phân tích các ca sử dụng
Khi người dùng mở chương trình, các ca sử dụng bao gồm:
- Bắt đầu chương trình (Open program): thao tác của người dùng mở
chương trình
- Hiển thị trạng thái của chương trình (Display program status): tác nhân
phụ hiển thị trạng thái của chương trình ( dừng hoặc đang chạy).
- Hiển thị các CTS Plan (Display CTS plan): hiển thị các case kiểm thử.
Hình 5.1: Biểu đồ ca sử dụng khởi động chương trình
Khi người dùng kết nối điện thoại với máy tính qua cổng usb:
- Kết nối thiết bị (Connect device): người dùng kết nối điện thoại với máy
tính.
- Trả về trạng thái kết nối (Get connection status): chương trình tự động
kiểm tra các trạng thái của điện thoại( wifi, bluetooth, sim,...).
- Display device status: hiển thị các trạng thái của điện thoại
Hình 5.2: Biểu đồ ca sử dụng khi kết nối điện thoại

39. 32
Khi thực hiện chạy chương trình:
- Chạy chương trình (Run program): thao tác người dùng click button
“Start”.
- Kiểm thử các testcase (Execute CTS testcase): chương trình tự động chạy
các ca kiểm thử được chỉ định trước.
- Hiển thị kết quả kiểm thử (Display result of tescase): hiển thị kết quả sau
khi chạy xong lên giao diện chương trình.
- Báo cáo kết quả (Export to excel): tự động xuất file kết quả ra file excel.
Hình 5.3: Biểu đồ ca sử dụng thực hiện chạy chương trình CTS executor
2.2. Biểu đồ trình tự
Hình 5.4: Biểu đồ trình tự khi người dùng kết nối điện thoại

40. 33
Hình 5.5: Biểu đồ trình tự khi chạy chương trình CTS Executor
2.3. Biểu đồ hoạt động
Hình 5.6: Biểu đồ hoạt động chạy chương trình CTS Executor

41. 34
3. Mô tả công cụ hỗ trơ kiểm thử
3.1. Tổng quan về công cụ
Hình 5.7: Màn hình CTS Executor
Giải thích các items:
-1: Biểu tượng thông báo trạng thái kết nối
-2: Biểu tượng thông báo trạng thái Bluetooth
-3: Biểu tượng thông báo trạng thái wifi
-4: Biểu tượng thông báo trạng thái sim của điện thoại
-5: Nút chạy chương trình kiểm thử
-6: Nút cài đặt đường dẫn đến thư mục lưu trữ bộ các ca kiểm thử, thư mục lưu
trữ báo cáo kết quả chạy.
-7: Nút tìm kiếm thiết bị.
-8: Combox hiển thị danh sách các thiết bị đã kết nối.
-9: Các ca kiểm thử trong chương trình.
-10: Hiển thị kết quả chạy.

42. 35
3.2. Chi tiết các chức năng
Biểu tượng thông báo trạng thái kết nối:
 Thông báo cho người dùng biết trạng thái kết nối của điện thoại với máy
tính, biểu tượng này sẽ tự động thay đổi nếu như kết nối hoặc ngắt kết nối
giữa điện thoại và máy tính.
Bảng 5.3 : Bảng hiển thị icon cho các trạng thái kết nối
Trạng Thái Chưa kết nối Đã kết nối
Biểu tượng
hiển thị
Biểu tượng thông báo trạng thái bluetooth:
 Thông báo cho người dùng biết trạng thái bluetooth của điện thoại đang
được kết nối, biểu tượng sẽ tự động thay đổi nếu trạng thái bluetooth của
điện thoại thay đổi.
Bảng 5.4 : Bảng hiển thị cho các trạng thái của Bluetooth
Trạng Thái Chưa bật bluetooth Đã bật bluetooth
Biểu tượng
hiển thị
Biểu tượng thông báo trạng thái wifi
 Thông báo cho người dùng biết trạng thái wifi của điện thoại đang được kết
nối, biểu tượng sẽ tự động thay đổi nếu trạng thái wifi thay đổi.
Bảng 5.5 : Bảng các trạng thái hiển thị của wifi
Trạng Thái Chưa bật wifi Đã bật wifi và chưa
kết nối
Đã bật wifi và đã kết
nối
Biểu tượng
hiển thị

43. 36
Biểu tượng thông báo trạng thái sim
 Thông báo cho người dùng biết trạng thái sim của điện thoại, có các trạng
thái lắp sim và không lắp, biểu tượng sẽ tự động thay đổi theo tình trạng sim
của điện thoại được kết nối.
Bảng 5.6 : Bảng các trạng thái hiển thị của sim
Trạng Thái Không có sim Có sim
Biểu tượng
hiển thị
Nút chạy chương trình kiểm thử.
 Ban đầu, chọn vào nút này là để bắt đầu chạy chương trình kiểm thử theo
các ca kiểm thử, sau đó nút sẽ tự động thay đổi sang trạng thái đang thực thi,
nếu muốn dừng chương trình lại người dùng có thể chọn chính nút này để
dừng chương trình.
Bảng 5.7 : Bảng hiển thị các trạng thái để chạy và dừng chương trình
Trạng Thái Start
(chọn để chạy chương trình)
Stop
(chọn để dừng chương trình)
Biểu tượng
hiển thị
Nút cài đặt đường dẫn đến thư mục lưu trữ bộ các ca kiểm thử, thư mục lưu
trữ báo cáo kết quả chạy.
 Ban đầu, chương trình có tự động mặc định cho thư mục lưu trữ bộ các ca
kiểm thử, thư mục lưu trữ cho kết quả chạy trong cùng thư mục với nơi để
chương trình chạy, nhưng người dùng hoàn toàn có thể sử dụng nút này để
cài đặt nơi lấy bộ ca kiểm thử và nơi sẽ xuất ra báo cáo về kết quả chạy.

44. 37
 Khi chọn vào nút này:
Hình 5.8 : Cài đặt thư mục các ca kiểm thử và lưu trữ báo cáo kết quả
1: Nơi lưu trữ bộ ca kiểm thử
2: Nơi lưu trữ kết quả chạy.
Nút tìm kiếm thiết bị kết nối.
 Nút này có chức năng tìm kiếm các thiết bị đang được kết nối nếu trong
danh sách các thiết bị đã kết nối chưa có. Nếu không có thiết bị nào đang
được kết nối, sẽ hiển thị pop-up thông báo cho người dùng biết.
Combobox hiển thị danh sách các thiết bị đang được kết nối.
 Combobox này hiển thị danh sách các điện thoại đang được kết nối với
máy tính.
 Khi không có thiết bị nào được kết nối:
 Khi có thiết bị được kết nối:

45. 38
 Từ danh sách các thiết bị đã kết nối, người dùng có thể lựa chọn thiết bị
để chạy chương trinhg kiểm thử.
Danh sách các case kiểm thử dùng trong chương trình.
Hình 5.9 : Tập các test case dùng trong chương trình kiểm thử
 Danh sách các test case trong file .xml này được tự động xuất ra sau khi
chọn đường dẫn đến nơi chứa CTS. Người dùng hoàn toàn có thể lựa
chọn chạy các ca kiểm thử mà mình muốn thực thi, không phải chạy toàn
bộ các ca kiểm thử nếu không cần thiết.
Bảng hiển thị kết quả chạy.
- Hiển thị cho người dùng biết kết quả chạy chương trình kiểm thử bao
gồm:
- Package name: package name của dự án được kiểm thử.
- Class name: Tên class dùng để kiểm thử.
- Test case name: Tên các ca kiểm thử.
- Result: kết quả chạy (Pass/ Fail).

46. 39
Hình 5.10 : Kết quả chạy chương trình kiểm thử
Kết quả kiểm thử cuối cùng được xuất ra dưới định dạng file .excel được đặt
trong thư mục đường dẫn đã chọn trước khi bắt đầu kiểm thử.
Hình 5.11 : Kết quả kiểm thử xuất dưới file .excel

47. 40
4. Xây dựng tập ca kiểm thử thử nghiệm với công cụ CTS Executor.
4.1. Xây dựng tập các ca kiểm thử
Luận văn thực nghiệm trên tập các ca kiểm thử của một dự án Android Junit Test
có tên là KnoxCustomApiTest. Tập các ca thử nghiệm (testcase) được tạo ra để kiểm
tra các API của KnoxCustom trên các thiết bị di động Android [7].
Tập các ca kiểm thử bao gồm 416 Testcase, được chia thành 4 packages (gói) và
được tiến hành kiểm thử đồng thời trên 2 thiết bị Samsung Galaxy A5 sử dụng công cụ
CTS Executor.
Bảng 5.8 : Tập các ca kiểm thử thực nghiệm
Package Nội dung Testcases
KnoxCustomTestDefault
Tập các ca kiểm thử lấy giá trị mặc định
của API
14
KnoxCustomTestGeneral
Tập các ca kiểm thử kiểm tra các API
của project
377
KnoxCustomTestManual
Chứa các ca kiểm thử cần tương tác của
con người
32
KnoxCustomTestStress
Tập các ca kiểm thử gọi API nhiều lần
cùng lúc
19
4.2. Kết quả thực nghiệm với công cụ CTS Executor
Luận văn tiến hành kiểm thử trên tập dữ liệu như bảng 10 và cho kết quả như
sau:
Bảng 5.9 : Kết quả thực nghiệm
Tiêu chí CTS Executor IDE (Eclipse)
Thời gian (chạy 2 thiết bị) 20 phút 40 phút
Testcase Pass (sau lần đầu) 400/416 380/416
Kết quả cuối cùng (Pass) 405/416 380/416
Báo cáo kết quả 1 phút 10 phút
Tự đông chạy lại Có Không
Kiểm thử nhiều thiết bị Có Không
Hiển thị trạng thái thiết bị Có Không
Hiển thị tiến độ kiểm thử Có Không

48. 41
Qua kết quả thực nghiệm đã cho thấy được thời gian kiểm thử tiết kiệm được
50%, tỉ lệ các ca kiểm thử chạy ra kết quả đúng tăng từ 90% lên 96% so với kiểm thử
trực tiếp trên Eclipse. Đặc biệt là kết quả kiểm thử được báo cáo tiết kiêm 90% so với
báo cáo kết quả bình thuờng và hỗ trợ những tính năng đặc biệt thừa kế từ phương
thức CTS.

49. 42
CHƯƠNG 6: KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN
Qua quá trình tìm hiểu về phương pháp CTS, luận văn đã xây dựng được công
cụ hỗ trợ kiểm thử dự án Android Junit test với những ưu điểm vượt bậc so với kiểm
thử trực tiếp trên môi trường phát triển như Eclipse, Android studio.
Luận văn đã đạt được các kết quả như sau:
 Tìm hiểu phương pháp CTS và cách cài đặt cũng như phương thức
hoạt động của nó
 Áp dụng phương pháp CTS để kiểm thử phần mềm Android Junit Test
 Xây dựng công cụ hỗ trợ kiểm thử Android Junit Test thay thế các
phương pháp kiểm thử truyền thống.
Kết quả đạt được đã cho thấy phương pháp CTS áp dụng vào kiểm thử Andoird
Junit test có hiệu quả đáng kể, giảm thời gian kiểm thử và cho kết quả kiểm thử đáng
tin cậy.
Tuy nhiên do hạn chế về mặt thời gian và kiến thức nên luận văn vẫn còn tồn tại
một số hạn chế như sau: công cụ chưa giải quyết được những ca kiểm thử cần tác đông
của con người.
Các bộ kiểm thử, đặc biệt là Android có rất nhiều ca kiểm thử cần đến sự tương
tác của người dùng như nhập text, nhấn button. Để khắc phục được nhược điểm này
cần nghiên cứu sâu và áp dụng phương pháp.
 UI Automator cho kiểm thử tự động Android
 Robotium Android Testing tool cho kiểm thử giao diện (user
interface)
Trong thời gian tới chúng tôi sẽ tiếp tục mở rộng luận văn bằng cách nghiên cứu
các phương pháp hỗ trợ những ca kiểm thử phức tạp. Hoàn thiện giao diện của công cụ
kiểm thử để có thể áp dụng trong thực tế cho các công ty phát triển các ứng dụng
Android.

50. 43
Tài liệu tham khảo
[1] Diego Torres Milano. “Android Application Testing Guide”. June 2011
[2] Compatibility Test Suite: https://source.android.com/compatibility/cts/
[3] Nimda. “Using Android’s Compatibility Test Suite”. May 2010
[4] Paul Blundell, Diego Torres Milano. “Learning Android Application
Testing”. March 2015
[5] JunitPlugwithEclipse:
https://www.tutorialspoint.com/junit/junit_plug_with_eclipse.htm
[6] AndroidTestingTutorial:
https://www.tutorialspoint.com/android/android_testing.htm
[7] AndroidSDK: http://code.tutsplus.com/tutorials/android-sdk-unit-testing-
with-the-junit-testing-framework--mobile-421