NGHIÊN CỨU PHÁT TRIỂN KỸ THUẬT VÀ GIẢI PHÁP KIỂM THỬ ỨNG DỤNG DI ĐỘNG

LỜI CAM ĐOANTôi xin cam đoan tất cả các nội dung trong luận án "Nghiên cứu phát triển kỹ thuật và giải pháp kiểm thử ứng dụng di động" là công trình nghiên cứu của riêng tôi.. dành nhiều

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

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

LỜI CAM ĐOAN

Tôi xin cam đoan tất cả các nội dung trong luận án "Nghiên cứu phát triển kỹ

thuật và giải pháp kiểm thử ứng dụng di động" là công trình nghiên cứu của riêng

tôi Các số liệu, kết quả trong luận án là trung thực, trích dẫn đầy đủ và chưa từngđược ai công bố trong bất kỳ công trình nào khác

Người hướng dẫn khoa học

Đà Nẵng, ngày 15 tháng 12 năm 2019

Tác giả luận án

PGS, TS Huỳnh Quyết Thắng Nguyễn Đức Mận

LỜI CẢM ƠN

Lời đầu tiên, tôi xin chân thành cảm ơn Thầy hướng dẫn PGS, TS Huỳnh QuyếtThắng và TS Nguyễn Thanh Hùng là người đã định hướng, chỉ dẫn, hướng dẫn rấttận tình trong toàn bộ quá trình thực hiện nghiên cứu của luận án này Thầy luônđồng hành, động viên, khích lệ kịp thời và luôn chu đáo, nghiêm túc trong công tácnghiên cứu, điều này đã giúp cho tôi trưởng thành hơn trên con đường học thuật,nghiên cứu khoa học của bản thân

Tôi xin gửi lời cảm ơn đến các nhà khoa học, các thầy cô phản biện, các thầy côtrong hội đồng các cấp cũng như những nhà khoa học độc lập đã có những đónggóp, góp ý rất chi tiết giúp tôi hoàn thành tốt luận án này

Tôi xin chân thành cảm ơn các thầy cô là lãnh đạo và cán bộ khoa học tại KhoaSau đại học của trường Đại học Duy Tân, đặc biệt là sự giúp đỡ của PGS, TS.Nguyễn Gia Như trong quá trình học tập và nghiên cứu tại Khoa Sự hỗ trợ của mọingười đã giúp cho quá trình học tập và nghiên cứu của tôi có được nhiều thuận lợi.Tôi xin gửi lời cảm ơn đến Hội đồng Quản trị và Ban Giám Hiệu Trường Đại họcDuy Tân, tập thể cán bộ giảng viên Khoa Đào tạo Quốc tế đã hỗ trợ, tạo điều kiệncho tôi trong quá trình làm việc cũng như học tập, nghiên cứu để tôi có thể đạt đượcnhững kết quả như ngày hôm nay

Tôi xin cảm ơn Công ty MeU-Solutions và nhóm dự án của công ty, đặc biệt cảm

ơn Anh Đỗ Hoàng Nhật, CEO của công ty MeU Solutions đã tạo điều kiện, hỗ trợnghiên cứu cho tôi và là nơi thực hiện các thử nghiệm nghiên cứu trong luận án.Cảm ơn các thành viên trong nhóm nghiên cứu cùng tham gia trong các côngtrình công bố và cho phép sử dụng kết quả nghiên cứu trong luận án này

Cuối cùng, tôi xin gửi lời cảm ơn đến gia đình, những người thân yêu và bạn bè

đã đồng hành, chia sẻ và giúp đỡ rất nhiều về tình cảm cũng như vật chất trong quátrình học tập, nghiên cứu Đặc biệt là gia đình của tôi, chỗ dựa vững chắc về mọimặt, là động lực để giúp tôi hoàn thành tốt luận án

Mặc dù bản thân tác giả đã có nhiều cố gắng, nỗ lực trong quá trình làm việcnhưng do thời gian và điều kiện nghiên cứu còn nhiều hạn chế, luận án có thể cònnhiều thiếu sót Tác giả của luận án rất mong nhận được sự đóng góp ý kiến của mọingười nhằm giúp tôi hoàn thiện nội dung khoa học của luận án cũng như nhữnghướng đi mở rộng sau này trong con đường khoa học của bản thân

Tác giả luận án

Nguyễn Đức Mận

MỤC LỤC

LỜI CAM ĐOAN i

LỜI CẢM ƠN ii

DANH MỤC CÁC HÌNH TRONG LUẬN ÁN vi

DANH MỤC CÁC BẢNG TRONG LUẬN ÁN viii

DANH MỤC THUẬT NGỮ, TỪ VIẾT TẮT x

MỞ ĐẦU 1

1 Giới thiệu 1

2 Mục tiêu nghiên cứu của luận án 6

3 Phương pháp nghiên cứu 7

4 Đối tượng nghiên cứu và phạm vi thực hiện 8

5 Cấu trúc của luận án 9

6 Các đóng góp khoa học của luận án 10

CHƯƠNG 1 TỔNG QUAN KIỂM THỬ ỨNG DỤNG 11

DI ĐỘNG VÀ PHƯƠNG PHÁP PHÁT TRIỂN LINH HOẠT 11

1.1 Giới thiệu tổng quan 11

1.2 Phân loại ứng dụng di động 13

1.3 Kiểm thử ứng dụng di động 15

1.3.1 Đặc điểm của ứng dụng di động 16

1.3.2.Tính đặc thù của ứng dụng di động ảnh hưởng đến việc kiểm thử phần mềm 17 1.4 Phương pháp phát triển linh hoạt 18

1.4.1 Phát triển hướng kiểm thử TDD 19

1.4.2 Phát triển hướng hành vi BDD 20

1.4.3 Kiểm thử trong môi trường phát triển Agile Scrum 22

1.5 Các thách thức của kiểm thử ứng dụng di động 22

1.6 Kết chương 26

CHƯƠNG 2 CÁC KỸ THUẬT TỐI ƯU HÓA, TÁI CẤU TRÚC VÀ PHÂN TÍCH MÃ NGUỒN CỦA ỨNG DỤNG DI ĐỘNG 28

2.1 Đặt vấn đề 28

2.2 Kỹ thuật phân tích và tái cấu trúc mã nguồn để nâng cao hiệu năng của ứng dụng di động dựa trên PMD và Android lint 30

2.2.1 PMD và Android lint 30

2.2.2 Kiểm thử hiệu năng 32

2.2.3 Các kỹ thuật tối ưu trong phát triển ứng dụng Android 33

2.2.3.1 Tối ưu mã nguồn java 33

2.2.3.2 Sử dụng bộ nhớ hiệu quả 36

2.2.3.3 Đa luồng và đồng bộ hóa 37

2.2.3.4 Tối ưu hóa mã nguồn sử dụng JNI 38

2.2.4 Phân tích và tái cấu trúc mã nguồn dựa trên PMD và Android lint 39

2.2.4.1 Đề xuất kỹ thuật phân tích và tái cấu trúc mã nguồn PMDlint 39

2.2.4.2 Sử dụng luật phân tích mã nguồn 41

2.2.4.3 Sử dụng luật thay đổi mã nguồn 41

2.2.4.4 Chiến lược áp dụng luật phân tích và thay đổi mã nguồn 42

2.2.4.5 Cài đặt luật phân tích và thay đổi mã nguồn 43

2.2.4.6 Kết quả thử nghiệm 45

2.3 Kỹ thuật phân tích mã nguồn tìm lỗi tiềm ẩn cho các phương thức của lớp Java 48

2.3.1 Đề xuất mô hình phân tích mã nguồn và kiểm thử hộp trắng 48

2.3.2 Biểu đồ cấu trúc điều khiển 49

2.3.3 Mô hình các điều kiện 52

2.3.4 Sinh các bộ dữ liệu kiểm thử 53

2.3.5 Thực hiện quá trình kiểm thử 54

2.3.6 Phân tích kết quả kiểm thử 55

2.3.7 Phân loại và lựa chọn các bộ dữ liệu kiểm thử 55

2.3.8 Kết quả cài đặt và thử nghiệm 57

2.4 Kết chương 61

CHƯƠNG 3 CÁC KỸ THUẬT KIỂM THỬ VÀ XÂY DỰNG GIẢI PHÁP TÍCH HỢP TRONG MÔI TRƯỜNG PHÁT TRIỂN LINH HOẠT 62

3.1 Đặt vấn đề 62

3.2 Kỹ thuật sinh ca kiểm thử và dữ liệu dựa trên yêu cầu người dùng và điều kiện chấp nhận 65

3.2.1 Một số thuật ngữ liên quan 65

3.2.2 Đề xuất tiếp cận sinh trường hợp kiểm thử và dữ liệu kiểm thử 67

3.2.2.1 Xây dựng giải pháp AgileUATM 67

3.2.2.2 Bài toán thực nghiệm cho phương pháp đề xuất 77

3.2.2.3 Phân tích dữ liệu thực nghiệm so sánh hiệu quả giải pháp AgileUATM 82

3.3 Phương pháp ứng dụng học máy và đồ thị hóa kết quả kiểm thử 87

3.3.1 Đồ thị hóa hoạt động và kết quả kiểm thử 87

3.3.1.1 Đề xuất cách tiếp cận 87

3.3.1.2 Chi tiết về kỹ thuật xây dựng đồ thị Graph 89

3.3.1.3 Kết quả thực nghiệm 90

3.3.1.4 Một số đánh giá về giải pháp 94

3.3.2 Phương pháp ứng dụng học máy cho kiểm thử ứng dụng di động 95

3.3.2.1 Đề xuất cách tiếp cận 95

3.3.2.2 Xây dựng và huấn luyện bộ phân loại nhận diện đối tượng 97

3.3.2.3 Xây dựng thư viện heuristics 99

3.3.2.4 Kiến trúc mức tổng quát Shinobi 100

3.3.2.5 Phân tích kết quả thực nghiệm 101

3.3.2.6 Đánh giá kết quả 104

3.4 Giải pháp AgileScrum tích hợp các kỹ thuật và phương pháp PMDLint, UniTest,+ AgileUATM, One2Explore và Shinobi 104

3.4.1 Đề xuất giải pháp tích hợp AgileScrum+ 105

3.4.2 Cách tiếp cận thực nghiệm và đánh giá các kỹ thuật, phương pháp và qui trình AgileScrum+ 107

3.4.2.1 Mô hình tăng trưởng độ tin cậy phần mềm 107

3.4.2.2 Mô hình hàm mũ Poision không đồng nhất 108

3.4.2.3 Các bước tiến hành thực nghiệm và đánh giá 110

3.4.2.4 Kết quả thực nghiệm và đánh giá 112

3.5 Kết chương 116

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 118

1 Kết luận 118

2 Hướng phát triển của luận án 121

DANH SÁCH CÁC CÔNG TRÌNH KHOA HỌC ĐÃ CÔNG BỐ LIÊN QUAN ĐẾNLUẬN ÁN 123TÀI LIỆU THAM KHẢO 125

DANH MỤC CÁC HÌNH TRONG LUẬN ÁN

Hình 1.1 Thị trường của ứng dụng trên điện thoại thông minh [79] 12

Hình 1.2 Quy trình phát triển TDD [7] 19

Hình 1.3 Mô hình BDD – TDD trong Agile mô phỏng bởi Paul Littlebury [12] 21

Hình 2.1 Kiến trúc của PMDLint được đề xuất trong luận án 40

Hình 2.2 Cấu hình điện thoại a) Motorola moto X, b) HTC One XL 46

Hình 2.3 Giao diện thực hiện phân tích và tái cấu trúc mã nguồn 47

Hình 2.4 Mô hình tổng quan kiểm thử hộp trắng mã nguồn phương thức của một lớp Java 49 Hình 2.5 Mã nguồn phương thức sumAbsolute 50

Hình 2.6 Biểu đồ luồng điều khiển của phương thức sumAbsolute 51

Hình 2.7 Mô hình hóa lại biểu đồ cấu trúc điều khiển của phương thức sumAbsolute 51

Hình 2.8 Mô hình kỹ thuật phân loại, lựa chọn các bộ dữ liệu kiểm thử 56

Hình 2.9 Một số màn hình kết quả thử nghiệm 60

Hình 3.1 Mô hình hoạt động của giải pháp AgileUATM đề xuất 68

Hình 3.2 Xây dựng cú pháp định nghĩa cho ngôn ngữ myDSL 71

Hình 3.3 Ví dụ về đặc tả myDSL cho tính năng đăng ký tài khoản Register 72

Hình 3.4 Workflow sinh test script cho Unit test (BDD) 75

Hình 3.5 Màn hình của công cụ sinh BDD Testscript 76

Hình 3.6 Giao diện của ứng dụng ACM 77

Hình 3.7 Đặc tả hình thức cho US Register gọi là myDSL.agt 81

Hình 3.8 Kết quả sinh Unit test cho Register class sử dụng tính năng sinh kịch bản BDD 82

Hình 3.9 Kết quả so sánh giữa hai lần thực hiện kiểm tra 91

Hình 3.10 Đồ thị tổng hợp các kết quả thực thi của Master Graph 92

Hình 3.11 Một kết quả so sánh giữa thực thi hiện tại và các thực thi trước đó (Master) 93

Hình 3.12 Shinobi framework 96

Hình 3.13 Faster R-CNN [107,118]: 98

Hình 3.14 (a) Độ chính xác với giá trị loss ở mức 0,8, (b) Độ chính xác với giá trị loss ở mức 0,02 99

Hình 3.15 Kiến trúc mức tổng quát của Shinobi 100

Hình 3.16 Kết quả nhận diện các đối tượng web từ dữ liệu kiểm thử 102

Hình 3.17 Shinobi nhận diện các web controls không được tương tác 102

Hình 3.18 Tất cả các kiểu đối tượng điều khiển được nhận diện và sử dụng heuristic data attack để đề xuất giá trị thích hợp 103

Hình 3.19 Kết quả nhận diện dữ liệu kiểm thử nhập vào không có ý nghĩa 103

Hình 3.20 Qui trình phát triển Scrum tích hợp các kỹ thuật kiểm thử và tối ưu hóa mã nguồn AgileScrum+ 106

Hình 3.21 Qui trình thực hiện đánh giá độ tin cậy 111

Hình 3.22 (a) Độ tin cậy của sản phẩm -đội A (b) Độ tin cậy của sản phẩm -đội B 115

Hình 3.23 (a) Số lượng lỗi tích lũy phát hiện theo thời gian -đội A và (b) đội B 115

Hình 3.23 (a) Tỷ lệ lỗi -đội A (b) Tỷ lệ lỗi -đội B 115

DANH MỤC CÁC BẢNG TRONG LUẬN ÁN

Bảng 1.1 So sánh các kỹ thuật, công nghệ phát triển của các loại ứng dụng di động 14

Bảng 1.2 Phân loại ứng dụng di động theo đặc thù riêng và kiểm thử tương ứng [74] 17

Bảng 2.1 So sánh thời gian thực hiện sau tinh chỉnh mã nguồn [69] 34

Bảng 2.2: Danh sách các luật đã thực hiện trong phạm vi của luận án 43

Bảng 2.3: Thống kê % sử dụng CPU đã kiểm thử trên Motorola moto X 46

Bảng 2.4: Thống kê % sử dụng CPU đã kiểm thử trên HTC One XL 46

Bảng 2.5 – Thống kê % sử dụng CPU của kết quả kiểm thử trên HTC One XL cho từng luật 47

Bảng 2.6: Bảng quyết định phân loại các bộ dữ liệu kiểm thử dựa vào kết quả kiểm tra các điều kiện trong mô hình 56

Bảng 2.7: Kết quả kiểm thử các phương thức của lớp UtilityTasks.java 58

Bảng 2.8: Tổng hợp kết quả kiểm thử tất cả các phương thức của lớp UtilityTasks.java 59

Bảng 3.1 Ví dụ mẫu về mô tả một user story 69

Bảng 3.2 Ví dụ về đặc tả tiêu chuẩn chấp nhận cho tính năng Register 69

Bảng 3.3 Mô tả cú pháp của ngôn ngữ đặc tả myDSL 71

Bảng 3.4 Ví dụ mô tả cú pháp chuyển đổi từ MyDSL sang Z3 72

Bảng 3.5 Ví dụ về test case / test input được sinh ra cho tính năng Register 73

Bảng 3.6 Các chức năng của công cụ AgileUATM 76

Bảng 3.7 Danh sách các user stories của ứng dụng ACM 78

Bảng 3.8 Đặc tả điều kiện chấp nhận cho chức năng Register (US01) 80

Bảng 3.9 Kết quả thực hiện theo phương pháp kiểm thử truyền thống 83

Bảng 3.10 Kết quả thực hiện áp dụng giải pháp AgileUATM 83

Bảng 3.11 Danh sách các nhóm dự án được mời tham gia thực nghiệm giải pháp đề xuất của luận án 84

Bảng 3.12 Kết quả thực nghiệm của phương pháp đề xuất AgileUATM 85

Bảng 3.13 Thông tin của các đối tượng người dùng của dự án được lấy ý kiến phản hồi (360-degree feedbacks) 93

Bảng 3.14 Kết quả phản hồi của các đối tượng (360-degree feedbacks) testers, trưởng nhóm kiểm thử và khách hàng 94

Bảng 3.15 Kết quả thực hiện áp dụng kỹ thuật PMDlint và UniTest cho các dự án mã nguồn FOSS và dự án do nhóm nghiên cứu thực hiện 112

Bảng 3.16 Dữ liệu lỗi thu thập của dự án đội A và đội B 113 Bảng 3.17 – Kết quả tính toán và ước lượng độ tin cậy của dự án đội A so với đội B 114

DANH MỤC THUẬT NGỮ, TỪ VIẾT TẮT

Agile (Agile Developemt Methodology) Phương pháp luận phát triển linh hoạt

BDD (Behavior Driven Development) Phát triển hướng hành vi

BVA (boundary value analysis) Phân tích giá trị biên

DSL (Domain-specific language) Ngôn ngữ chuyên biệt

EPC (Equivalence Partition Class) Phân vùng tương đương

Mobile web (Mobile Web Application) Ứng dụng web di động

NHPP (Non-Homogeneous Poisson Quá trình Poisson không đồng nhất

Process)

PMD (Programming Mistake Detector) Bộ phát hiện lỗi lập trình

SMT (satisfiability modulo theories) Các lý thuyết modulo thỏa mãn

SRGM (Software Reliability Growth Mô hình tăng trưởng độ tin cậy phần mềmModels)

TDD (Test Driven Development) Phát triển hướng kiểm thử

UAT (User Acceptance testing) Kiểm thử chấp nhận người dùng

UI/GUI (User Interface/ Graphic User Giao diện người dùng/ Giao diện người

MỞ ĐẦU

1 Giới thiệu

Điện thoại thông minh ngày càng đóng vai trò quan trọng trong cuộc sống ngày nay.Với những tính năng và khả năng của chiếc điện thoại thông minh, con người có thểdùng để giải quyết rất nhiều vấn đề trong cuộc sống của họ Điện thoại thông minh cónhững ưu điểm như tính kết nối giữa con người với con người và với vạn vật, sử dụngcho giải trí, thực hiện giao dịch ngân hàng, mua bán trực tuyến, quản lý lịch trình, quản

lý công việc, tìm kiếm thông tin, kiểm tra sức khỏe và vân vân Một số ứng dụng phổbiến hiện nay như ứng dụng nhắn tin và gọi điện Zalo (Vietnam), WhatsApp, Line,Snapchat hoặc trò chơi PokeMon Go, Flappy Bird (Vietnam), ứng dụng Wallet hoặccác ứng dụng phổ biến khác như Flipboard, Pocket, Vine, ZingMP3 (Vietnam), Uber,Grab, Money Lover (Vietnam) Các nghiên cứu thực tế cho thấy rằng, để người dùng

sử dụng điện thoại nhiều hơn, sử dụng các ứng dụng chạy trên điện thoại thường xuyênhơn cho các mục đích khác nhau thì đòi hỏi các ứng dụng phải đáp ứng được yêu cầu

sử dụng của họ, phải dễ sử dụng, ổn định và đáng tin cậy Khoảng 50% ứng dụng diđộng bị đánh giá kém trên các cửa hàng Play hay Appstore dựa trên các vấn đề như sự

cố, hiệu suất kém và tốn năng lượng Người dùng thường sẽ xóa ngay ứng dụng sau khicài đặt nếu nó gặp sự cố, hiệu năng kém, chất lượng kém và thiếu tin cậy Theo cácthống kê [22, 65, 70, 71], có 77% người dùng xóa ứng dụng kém chất lượng sau 72 giờcài đặt Do đó, việc nghiên cứu, đề xuất giải pháp, phát triển kỹ thuật phân tích mãnguồn, các kỹ thuật và phương pháp kiểm thử nhằm nâng cao chất lượng của sản phẩm,nâng cao độ tin cậy và hiệu năng là điều rất cần thiết và có ý nghĩa Đặc điểm của điệnthoại di động là sự đa dạng về thiết bị, băng thông và bộ nhớ hạn chế, dung lượng lưutrữ và nguồn năng lượng bị giới hạn, sự đa dạng người dùng Những đặc điểm này làthách thức lớn cho các kỹ sư phát triển cũng như các kỹ sư kiểm thử Các kỹ sư kiểmthử phải nghiên cứu nhằm đề xuất các giải pháp hiệu quả cho phát triển ứng dụng diđộng hiện nay Bên cạnh đó, tính cạnh tranh để phát hành sản phẩm ra thị trường sớmnhưng vẫn đảm bảo chất lượng và độ tin cậy của sản phẩm cũng là một trong nhữngthách thức trong phát triển phần mềm nói chung và ứng dụng di động nói riêng Hiệntại, các nhà nghiên cứu phát triển đang

dành nhiều sự quan tâm cho việc nghiên cứu và công bố các đề xuất áp dụng nhưngvẫn chưa thể đáp ứng hay giải quyết đầy đủ các thách thức ở trên, điều này cũng làđộng lực cho việc nghiên cứu để đưa ra các giải pháp, phát triển các kỹ thuật kiểmthử mới nhằm đóng góp vào lĩnh vực kiểm thử ứng dụng di động hiện nay.

Qua khảo sát, hiện tại, có nhiều nghiên cứu liên quan đến vấn đề sinh tự độngtrường hợp kiểm thử dựa trên mô hình (model-based testing), sinh trường hợp kiểmthử dựa trên các biểu đồ UML như biểu đồ Use case, biểu đồ hoạt động (activitydiagram), biểu đồ lớp, biểu đồ tuần tự, phân tích mã nguồn để tối ưu hóa chươngtrình, phân tích và sinh dữ liệu kiểm thử dựa vào mã nguồn, đồ thị hóa dữ liệu kiểmthử và ứng dụng học máy cho kiểm thử tự động Cụ thể:

Các nghiên cứu liên quan hướng phân tích mã nguồn, tối ưu hóa mã nguồn, gồm có:

Shuai Hao và cộng sự [42] đề xuất phân tích chương trình, các kỹ thuật đo lườngdựa trên thống kê; Xueliang Li và John P Gallagher [61] đã đề xuất một khung tối ưuhóa năng lượng bởi việc tối ưu mã nguồn, kỹ thuật này cho phép các nhà phát triểnnhận thức được việc sử dụng năng lượng do mã lệnh gây ra và áp dụng các chiến lượctái cấu trúc mã nguồn hướng mục tiêu Wedyan, F và cộng sự [121] trình bày hiệu quảcủa các công cụ phân tích tĩnh tự động để phát hiện lỗi và tái cấu trúc Một số kỹ thuậtđược tự động hóa và được hỗ trợ bởi nhiều công cụ giúp tăng hiệu suất của người pháttriển và giảm nhẹ gánh nặng của họ Tuy nhiên, trên thực tế, những kỹ thuật này không

đủ để giải quyết khoảng cách giữa việc hiểu nơi tiêu thụ năng lượng và cách mã lệnh cóthể được thay đổi để giảm năng lượng tiêu thụ Những kỹ thuật này cho phép ngườiphát triển hiểu nơi tiêu thụ năng lượng trong một ứng dụng; họ không cung cấp hướngdẫn để cải thiện mức tiêu thụ năng lượng của ứng dụng

Các nghiên cứu liên quan kỹ thuật sinh trường hợp kiểm thử, sinh dữ liệu kiểm thử, gồm có:

Wang và cộng sự [119] đề xuất mô hình hóa ca sử dụng (use case) để sinh kiểm thử

hệ thống Kỹ thuật đề xuất sử dụng các đặc tả trường hợp sử dụng, sơ đồ lớp và cácràng buộc để tạo các trường hợp kiểm thử hệ thống Oluwagbemi và Asmuni [81] trìnhbày phương pháp nâng cao để tạo các trường hợp kiểm thử từ các sơ đồ UML

khác nhau Thu tập các tài liệu từ các sơ đồ được đề xuất, các đại diện trung giancủa các tài liệu là ở dạng cây mà qua đó truyền tải nội dung tạo ra các trường hợpthử nghiệm.

Rane [89] đã thiết kế và triển khai một công cụ để hỗ trợ tự động sinh test casetrong quy trình phát triển phần mềm linh hoạt bằng cách xử lý ngôn ngữ tự nhiên.Công cụ này tăng thời gian cần thiết để tạo ra các trường hợp kiểm thử là 7%, giảmcông sức tạo test case là 31% và cải thiện 23% liên quan đến phạm vi kiểm thử củacác yêu cầu Thời gian và nỗ lực để tạo các trường hợp thử nghiệm cho nhiều userstory của cùng một tính năng được giảm tương ứng 61% và 87%;

Pandit và Tahiliani [84] đề xuất quy trình UAT và công cụ AgileUAT, nhằm tạo

ra một danh sách đầy đủ các trường hợp kiểm thử chấp nhận bằng ngôn ngữ tựnhiên, dựa trên các tiêu chí chấp nhận Công cụ có khả năng lần vết giữa các epics,user stories, tiêu chí chấp nhận (AC) và các trường hợp kiểm thử chấp nhận Mộtphương pháp hướng mô hình cho tiến hóa trường hợp thử nghiệm đã được đề xuất

sử dụng kỹ thuật kiểm thử hộp đen trong đó mọi thứ được coi là mô hình và thôngtin tiến hóa được trích từ phân tích so sánh giữa hai hoặc nhiều phiên bản phát triểncủa ứng dụng di động Nó đã được quan sát thấy rằng những thay đổi có thể ảnhhưởng đến giao diện hoặc mã của ứng dụng đó hoặc cả hai Tương tự, bất kỳ loạithay đổi nào cũng có thể tác động đến các trường hợp thử nghiệm được tạo ra.Dynodriod là một hệ thống sinh dữ liệu đầu vào cho Android, được sử dụng rộngrãi trong các thử nghiệm trong khi một số phương pháp tiếp cận trước đó dựa vàocác kỹ thuật kiểm thử ngẫu nhiên [62] MobiGUITAR [6] được xây dựng trên khungGUITAR sử dụng trích xuất GUI để xây dựng mô hình của một ứng dụng Cáctrường hợp thử nghiệm được sinh ra bằng việc duyệt theo chiều sâu của mô hình.MobiGUITAR dựa trên sự quan sát, trích xuất và trừu tượng hóa trạng thái thời gianchạy của các widget GUI Sự trừu tượng hóa là một mô hình máy trạng thái có thể

mở rộng, cùng với các tiêu chí bao phủ thử nghiệm

Yu [127] đã đề xuất một cách tiếp cận để tạo ra các trường hợp ứng dụng di động thửnghiệm, tập trung vào các ứng dụng Android Cách tiếp cận chủ yếu phụ thuộc vào các

sự kiện bên ngoài Hai khía cạnh của các sự kiện bên ngoài được xem xét: rõ

ràng và ẩn Các sự kiện bên ngoài từ các thành phần bổ sung của thiết bị di độngđược xác định thủ công và được nhóm thành các danh mục Một số ví dụ bao gồmtrạng thái cuộc gọi điện thoại trở thành (1) không hoạt động, (2) tắt máy và (3) đổchuông Các mẫu sự kiện được xây dựng từ các chuỗi các sự kiện bên ngoài, như đổchuông, tắt máy, không hoạt động.

Liu và cộng sự [128] đã đề xuất kỹ thuật ART để tạo các trường hợp thử nghiệmcho các ứng dụng di động Kết quả cho thấy công cụ ART đã giảm số lượng cáctrường hợp thử nghiệm cũng như thời gian cần thiết để phơi bày lỗi đầu tiên so với

kỹ thuật ngẫu nhiên Kỹ thuật đề xuất được sử dụng để đo khoảng cách giữa các đầuvào của ứng dụng di động được thể hiện trong chuỗi sự kiện Các tác giả đã trìnhbày nghiên cứu thực nghiệm đầu tiên, sử dụng khoảng cách trên trường hợp thửnghiệm thế hệ ngẫu nhiên thích ứng cho các ứng dụng di động thực tế Kỹ thuậtđược đề xuất là hiệu quả để tạo ra các trường hợp thử nghiệm ngẫu nhiên về mặtphát hiện lỗi trước đó

Các nghiên cứu liên quan đến việc sinh trường hợp kiểm thử phần lớn dựa trên cácbiểu đồ UML không phù hợp với qui trình phát triển linh hoạt Hiện chỉ có Rane [89],Pandit và Tahiliani [84], Dynodriod [62], MobiGUITAR [6], Yu [127] tập trung nhiềuvào kiểm thử cho ứng dụng di động, sinh trường hợp kiểm thử trong môi trường pháttriển linh hoạt Qua khảo sát, tác giả luận án thấy rằng các nghiên cứu được thực hiện

và nghiên cứu đề xuất cho đến nay chủ yếu liên quan đến thử nghiệm GUI, dữ liệuđược tạo từ mô hình UML hoặc tạo trường hợp thử nghiệm và dữ liệu thử nghiệm từ

mã nguồn Chỉ có một cách tiếp cận được đề xuất bởi Pandit và Tahiliani sử dụng xử lýngôn ngữ tự nhiên để trích xuất thông tin từ câu chuyện của người dùng và tiêu chíchấp nhận để tạo trường hợp kiểm tra và dữ liệu thử nghiệm

Đối với các nghiên cứu về trực quan hóa kết quả kiểm thử và phương pháp ứng dụng học máy vào kiểm thử, gồm có:

Một số nghiên cứu của Chan và cộng sự [19] và Stepien et al [106] đã giới thiệucác kỹ thuật cung cấp cái nhìn toàn cục về kết quả thử nghiệm Các kỹ thuật trực quantập trung vào mối quan hệ giữa người dùng và các vấn đề được báo cáo của họ Các

kỹ thuật hỗ trợ xác định các mẫu chung để xác định vị trí các vấn đề và cách ưu tiêncác trường hợp thử nghiệm phù hợp cho các phiên bản sau.

Chen và cộng sự [20] xây dựng ViViz bằng cách sử dụng các biểu đồ để trực quanhóa một phần mềm; cho phép các nhà phát triển và người thử nghiệm nhanh chóng cóđược cái nhìn sâu sắc về cấu trúc GUI và trạng thái của quá trình thử nghiệm Nó cungcấp các biểu diễn có thể nhìn thấy cho dữ liệu thử nghiệm được tạo bởi GUITAR

TESTAR [109] cung cấp thông tin trực quan về các lần chạy thử Kiểm tra trựcquan giúp người kiểm tra trực tiếp kiểm tra và phân tích cách thức kiểm tra phầnmềm được thực hiện trong quá trình tìm kiếm các lỗi tiềm ẩn

Học máy là một miền của AI được sử dụng rộng rãi trong các giai đoạn khácnhau của vòng đời phát triển phần mềm, đặc biệt là để tự động hóa các quy trìnhkiểm thử phần mềm Theo Wegener [122] các thuật toán tiến hóa đã được sử dụng

để tự động hóa việc tạo trường hợp thử nghiệm Von Mayrhauser và cộng sự [67] sửdụng mạng nơ ron nhân tạo xây dựng một mô hình để ước tính hiệu quả của cáctrường hợp thử nghiệm được tạo ra

Briand và cộng sự [119] đã đề xuất một phương pháp dựa trên thuật toán câyquyết định C4.5 để dự đoán các lỗi tiềm ẩn trong hệ thống phần mềm và bản địa hóacác lỗi để giảm thời gian xử lý gỡ lỗi Tất cả các công việc nghiên cứu liên quan chothấy việc sử dụng các kỹ thuật máy học trong các quy trình thử nghiệm tự động hóa

có hiệu quả cao [94]

Tuy nhiên, hầu hết các nghiên cứu chỉ tập trung vào các kỹ thuật kiểm tra dựatrên thử nghiệm theo kịch bản của Google, như tạo trường hợp kiểm thử, xác minh,kiểm tra mô hình Việc áp dụng ML trong phương pháp CDT còn hạn chế Trongkhi đó, với sự phát triển của AI, CDT, Agile, việc áp dụng ML, Heuristic trong CDT

và Agile rất đáng quan tâm và nên bao gồm các khung hỗ trợ cho người thử nghiệmhoặc QA, cũng như các nhà phát triển Xu hướng là ML đang được các nhà nghiêncứu nghiên cứu về lĩnh vực kiểm thử phần mềm, tự động hóa thử nghiệm Bên canh

đó phương pháp trực quan hóa và hiển thị đầy đủ thông tin của hoạt động kiểm thửthăm dò theo cách tiếp cận hướng ngữ cảnh chưa được nghiên cứu đầy đủ và ứngdụng cho lĩnh vực kiểm thử ứng dụng web và ứng dụng di động

Từ các hạn chế đã được khảo sát và trình bày ở trên cùng với các thách thức củakiểm thử ứng dụng di động hiện nay, nghiên cứu sinh đã lựa chọn và thực hiệnnghiên cứu các kỹ thuật phân tích mã nguồn, tối ưu hóa và tái cấu trúc mã nguồn,phân tích mã nguồn để tìm lỗi tiềm ẩn (kiểm thử tĩnh), kỹ thuật sinh kịch bản kiểmthử, phương pháp trực quan hóa hoạt động kiểm thử, phương pháp ứng dụng họcmáy vào kiểm thử và đề xuất giải pháp tích hợp các kỹ thuật kiểm thử vào qui trìnhphát triển linh hoạt Agile Scrum cho phát triển ứng dụng di động Nội dung nghiêncứu của luận án bao gồm (1) một số kỹ thuật tối ưu và tái cấu trúc mã nguồn nhằmnâng cao hiệu năng, tiết kiệm năng lượng; (2) phân tích mã nguồn tìm lỗi tiềm ẩntrong mã nguồn và kiểm thử hộp trắng; (3) kỹ thuật sinh ca kiểm thử và dữ liệukiểm thử tự động dựa trên câu chuyện người dùng (user story) và điều kiện chấpnhận (acceptance criteria); (4) phương pháp trực quan hóa bằng đồ thị cho hoạtđộng kiểm thử thăm dò và phương pháp ứng dụng học máy cho kiểm thử ứng dụngweb di động; (5) giải pháp tích hợp các kỹ thuật phân tích mã nguồn, kỹ thuật vàphương pháp kiểm thử vào qui trình Agile Scrum; đi kèm với các phương pháp/ kỹthuật được đề xuất là các công cụ hỗ trợ Các kết quả nghiên cứu (1), (2), (3), (4) cóthể vận dụng riêng lẻ hoặc cùng áp dụng vào qui trình Agile Scrum để giúp nângcao chất lượng của sản phẩm, tăng độ tin cậy trước khi phát hành sản phẩm Kết quảnghiên cứu đã được thực nghiệm, phân tích đánh giá và ứng dụng thực tiễn (một số

kỹ thuật) tại doanh nghiệp phần mềm

Kết quả của nghiên cứu của luận án bên cạnh các đóng góp về mặt khoa học còn

có ý nghĩa về mặt thực tiễn, một số kết quả nghiên cứu đã được ứng dụng thực tiễntại công ty MeU Solutions và đã mang lại giá trị cho các dự án với khách hàng thực

tế Các kỹ sư phát triển và kỹ sư kiểm thử sử dụng giúp nâng cao chất lượng cho sảnphẩm, nâng cao độ tin cậy cho ứng dụng và hiệu quả trong sản xuất phần mềm nóichung, cho ứng dụng di động nói riêng

2 Mục tiêu nghiên cứu của luận án

Mục tiêu của luận án là (1) Xây dựng và thử nghiệm các kỹ thuật tối ưu, tái cấu trúc mã nguồn và tìm lỗi tiềm ẩn trong mã nguồn nhằm nâng cao hiệu năng cho ứng

dụng di động; và (2) phát triển và thử nghiệm các kỹ thuật sinh trường hợp kiểmthử, phương pháp trực quan hóa kiểm thử thăm dò, ứng dụng học máy trong nhậndiện đối tượng phục vụ kiểm thử và giải pháp tích hợp vào qui trình Agile Scrumnhằm nâng cao chất lượng, nâng cao độ tin cậy cho ứng dụng di động.

3 Phương pháp nghiên cứu

o Nghiên cứu và đánh giá các nguồn tài liệu liên quan, các nghiên cứu liên quan một

cách có hệ thống để có được cái nhìn tổng quan toàn diện về lĩnh vực kiểm thử phần mềm cho ứng dụng di động Thu thập và hệ thống hóa các vấn đề ảnh hưởng đến việc kiểm thử các ứng dụng di động chạy trên nền tảng Android

o Phân tích tài liệu, kỹ thuật thu thập dữ liệu phân tích đã được áp dụng để thu

thập, xử lý dữ liệu cần thiết cho việc phân tích toàn diện về:

• các vấn đề ảnh hưởng đến việc kiểm thử ứng dụng di động chạy trên nền tảng Android;

• hiệu năng của ứng dụng di động;

• các công cụ kiểm thử tự động, phân tích mã nguồn;

• sinh trường hợp kiểm thử và dữ liệu kiểm thử

• đo độ tin cậy của các ứng dụng thông qua việc áp dụng các kỹ thuật kiểm thử được đề xuất trong luận án

o Sử dụng kỹ thuật mô hình hóa trực quan bằng đồ thị để báo cáo và đánh giá

các hoạt động kiểm thử thăm dò theo cách tiếp cận kiểm thử hướng ngữ cảnh

o Sử dụng phương pháp học máy và vận dụng vào trong hoạt động kiểm thử thông

qua kỹ thuật nhận diện đối tượng, tạo công cụ hỗ trợ triểm thử ứng dụng

web di động

o Phương pháp lấy ý kiến chuyên gia, sử dụng trí tuệ của đội ngũ chuyên gia để

xem xét nhận định, đánh giá các phương pháp, các cách tiếp cận được đề xuất

để từ đó giúp nghiên cứu sinh hoàn thiện các giải pháp một cách hiệu quả

o Thực hiện nhiều thực nghiệm khác nhau để thu thập dữ liệu, đánh giá kết quả

nghiên cứu, so sánh các kết quả của các kỹ thuật, phương pháp được đề xuất

để chứng minh các giải pháp đề xuất là hiệu quả và có ý nghĩa thực tiễn

4 Đối tượng nghiên cứu và phạm vi thực hiện

Đối tượng nghiên cứu:

o Các phương pháp, các kỹ thuật kiểm thử ứng dụng trên điện thoại thông minh

chạy trên nền tảng Android như tối ưu hóa mã nguồn, tiết kiệm năng lượng, nâng cao hiệu năng, tìm lỗi tiềm ẩn của sản phẩm

o Các phương pháp sinh dữ liệu kiểm thử, kịch bản kiểm thử, kiểm thử thăm dò

và sử dụng học máy trong kiểm thử phần mềm

o Qui trình phát triển phần mềm lịnh hoạt Agile Scrum và giải pháp vận dụng

các kỹ thuật được đề xuất trong luận án

o Phương pháp đo lường, đánh giá độ tin cậy của ứng dụng di động.

Phạm vi nghiên cứu trong trong luận án:

o Kỹ thuật phân tích mã nguồn (kiểm thử tĩnh):

- Tối ưu hóa mã nguồn để nâng cao hiệu năng, tiết kiệm năng lượng cho ứng dụng Android,

- Phân tích mã nguồn để tìm lỗi tiềm ẩn và phát hiện lỗi trong các phươngthức của lớp của ngôn ngữ Java (lập trình ứng dụng di động)

o Qui trình ứng dụng và đánh giá chất lượng, độ tin cậy ứng dụng khi sử dụng

các kỹ thuật, phương pháp kiểm thử ở trên

Nghiên cứu của luận án tập trung thực hiện kiểm thử trên điện thoại Android mãnguồn mở, kho ứng dụng mã nguồn FOSS; và trường hợp thực nghiệm cho ứngdụng ACM app, các công cụ xây dựng cũng phục vụ cho ngôn ngữ Java, các IDE hỗtrợ plug-in Java

5 Cấu trúc của luận án

Luận án được trình bày trong 3 chương, cụ thể như sau:

Chương 1 Tổng quan kiểm thử ứng dụng di động và phương pháp phát triển linh hoạt

Luận án trình bày tổng quan về kiểm thử cho ứng dụng di động, phân tích cácvấn đề về kiểm thử, chiến lược, qui trình, thách thức kiểm thử ứng dụng di động,các công trình nghiên cứu liên quan kiểm thử ứng dụng di động Từ đó, nghiên cứusinh đặt vấn đề về các nhiệm vụ cần giải quyết trong luận án:

- (1) Kỹ thuật tối ưu hóa, tái cấu mã nguồn, phân tích mã nguồn tìm lỗi tiềm ẩn

để nâng cao hiệu năng, giảm tiêu thụ năng lượng, nâng cao chất lượng cho ứngdụng di động Android;

- (2) Các kỹ thuật kiểm thử và giải pháp tích hợp trong môi trường phát triển linhhoạt

- (3) Đánh giá độ tin cậy của ứng dụng khi sử dụng các kỹ thuật (1) và (2) để chứng minh các kỹ thuật và phương pháp đề xuất là hiệu quả và có giá trị

Chương 2 Các kỹ thuật tối ưu hóa, tái cấu trúc mã nguồn và tìm lỗi tiềm ẩn cho ứng dụng di động

Luận án trình bày các kỹ thuật phân tích mã nguồn, tối ưu hóa mã nguồn và phân tích mã nguồn tìm lỗi tiềm ẩn trong ứng dụng di động bao gồm:

- Các kỹ thuật tối ưu hóa mã nguồn nâng cao hiệu năng và tái cấu trúc mã nguồn

để tối ưu tiêu thụ năng lượng của ứng dụng (công bố ở công trình CT1, CT3)

- Kỹ thuật phân tích mã nguồn tìm lỗi tiềm ẩn trong chương trình nhằm nâng cao chất lượng mã nguồn cho ứng dụng (công bố ở công trình CT2)

Chương 3 Các kỹ thuật kiểm thử và xây dựng giải pháp tích hợp trong môi trường phát triển linh hoạt

Luận án trình bày các kỹ thuật kiểm thử cho ứng dụng di động, bao gồm:

- Kỹ thuật sinh trường hợp kiểm thử và dữ liệu kiểm thử tự động dựa trên câuchuyện người dùng (User story) và điều kiện chấp nhận (Acceptance criteria)(kết quả công bố ở công trình CT6)

- Phương pháp đồ thị hóa kỹ thuật kiểm thử thăm dò trong kiểm thử hướng ngữ cảnh (CDT) (công bố ở công trình CT4)

- Phương pháp ứng dụng heuristics và học máy trong kiểm thử cho ứng dụng web

và web di động (công bố ở công trình CT5)

- Giải pháp tích hợp các kỹ thuật đã được trình bày ở Chương 2 và Chương 3, đềxuất qui trình ứng dụng trong môi trường phát triển linh hoạt Agile Scrum Từ đó

áp dụng đánh giá thử nghiệm thực tế cho lớp phần mềm ứng dụng Android dựatrên 2 trường hợp: các ứng dụng tại kho mã nguồn FOSS sử dụng để đánh giá các

kỹ thuật kiểm thử tĩnh; tổ chức xây dựng dự án thực tế ACMpp để đánh giá kỹthuật kiểm thử động về độ tin cậy của ứng dụng (công bố ở công trình CT7)

Kết luận và hướng phát triển.

Đánh giá các kết quả đạt được, những hạn chế của luận án và các vấn đề tiếp tục nghiên cứu phát triển để hoàn thiện hướng đi của luận án

6 Các đóng góp khoa học của luận án

Thứ nhất: Xây dựng và thử nghiệm các kỹ thuật tối ưu và tái cấu trúc mã nguồn

nhằm nâng cao hiệu năng cho ứng dụng di động: sử dụng bộ nhớ hiệu quả, đa luồng

và đồng bộ hóa, xây dựng các luật sử dụng Programming Mistake Detector vàAndroid Lint để tối ưu mã nguồn nhằm tiết kiệm năng lượng, nâng cao hiệu năng

cho ứng dụng (PMDLint); xây dựng và thử nghiệm mô hình kiểm thử hộp trắng cho

phương thức trong một lớp để tìm lỗi tiềm ẩn nhằm nâng cao chất lượng mã nguồn

và độ tin cậy cho ứng dụng (UniTest)

Trình bày trong chương 2, có 3 bài báo liên quan (CT1, CT2, CT3), trong đó có

01 công trình Hội nghị Scopus

Thứ hai: Xây dựng và thử nghiệm các kỹ thuật kiểm thử, phương pháp kiểm thử

cho phát triển ứng dụng di động: sinh trường hợp kiểm thử và dữ liệu kiểm thử tựđộng dựa trên câu chuyện người dùng và tiêu chí chấp nhận (AgileUATM); sử dụngphương pháp đồ thị hóa hoạt động kiểm thử thăm dò (One2Explore), phương phápheuristics và học máy trong kiểm thử ứng dụng web và web di động (Shinobi) Đềxuất giải pháp AgileScrum+ tích hợp các kỹ thuật trong môi trường phát triển AgileScrum

Trình bày trong chương 3, có 4 bài báo liên quan (CT4, CT5, CT6, CT7), trong

đó có 02 công trình Hội nghị Scopus và 01 Tạp chí ISI (Q3)

CHƯƠNG 1 TỔNG QUAN KIỂM THỬ ỨNG DỤNG

DI ĐỘNG VÀ PHƯƠNG PHÁP PHÁT TRIỂN LINH HOẠT

Trong chương này, luận án trình bày các số liệu thống kê, các khảo sát về ứng dụng di động, xu hướng phát triển và người dùng ứng dụng di động; phân loại ứng dụng di động, các thách thức trong việc kiểm thử cho ứng dụng di động Ngoài ra, chương này cũng trình bày các khái niệm, các thuật ngữ liên quan đến kiểm thử ứng dụng di động, phương pháp phát triển và qui trình phát triển ứng dụng theo cách tiếp cận linh hoạt (Agile development).

1.1 Giới thiệu tổng quan

Ngày nay, điện thoại di động thông minh đã trở thành một phần không thể thiếucủa nhiều người trong cuộc sống hàng ngày Tiến bộ của công nghệ và trải nghiệmngười dùng đang thúc đẩy sự phát triển của thị trường ứng dụng di động Cứ mỗibản cập nhật hệ điều hành mới cũng sẽ tạo ra những cải tiến mới về thiết kế ứngdụng di động để đáp ứng nhu cầu của người dùng trong thời đại công nghệ

Theo nghiên cứu của Research and Markets [92], thị trường đám mây di động dựkiến đạt trị giá 46,90 tỷ USD vào năm 2019 Kết quả nghiên cứu của Markets andMarkets [65] cho thấy thị trường điện toán và xử lý di động sẽ có giá trị 61,70 tỷUSD vào năm 2020 Theo những số liệu mới nhất từ Gartner, trong năm 2018, hai

hệ điều hành phổ biến nhất trên điện thoại di động đang là iOS và Android khi đangchiếm tới 99.9% thị phần Trong khi các hệ điều hành khác gần như không đáng kể,chỉ chiếm tỷ lệ 0.01%

Hệ điều hành Android vẫn tiếp tục chiếm ưu thế với khoảng 88% thị phần, trongkhi đó iOS là 11.9% ở quý 2 năm 2018 So với năm 2017, con số này có thay đổikhông đáng kể Android tăng thêm hơn 0.2%, iOS giảm 0.3% [39] Trong khi thịtrường điện thoại thông minh trên toàn thế giới dự kiến sẽ giảm 3% trong năm 2018,IDC tin rằng thị trường sẽ có mức tăng trưởng một chữ số từ năm 2019 đến hết dựbáo vào năm 2022 [49][102]

Từ năm 2017, nền kinh tế ứng dụng đã tiếp tục phát triển nhờ vào bối cảnh kỹ thuật

số theo sau Phần lớn các công ty và doanh nhân nhận ra rằng các ứng dụng di động

không còn là một tiện ích giá trị gia tăng mà là sự cần thiết để duy trì và phát triểndoanh nghiệp Các tổ chức lớn đang sử dụng các ứng dụng di động để xây dựngthương hiệu, tiếp thị trực tiếp, tăng sự tham gia của khách hàng, các doanh nghiệpvừa và nhỏ cũng đang đi theo cùng xu hướng để có chỗ đứng trên thị trường Nềnkinh tế ứng dụng tiếp tục mở rộng, phát triển với tốc độ cao được minh chứng bởi

số lượng ứng dụng miễn phí được tải xuống đã tăng lên tới 253,91 tỷ trong năm

2017, so với 57,33 tỷ lượt tải xuống vào năm 2012 Tương tự, số lượng ứng dụngđược trả tiền đã tải xuống tăng lên 14,78 tỷ trong năm 2017 so với 2,89 tỷ ứng dụngtrong năm 2011 Doanh thu ứng dụng được dự đoán sẽ tăng lên tới 188,9 tỷ đô lavào năm 2020, từ mức 69,7 tỷ đô la trong năm 2015 [78,79]

Hình 1.1 Thị trường của ứng dụng trên điện thoại thông minh [79]

Thống kê của Statista về số lượng ứng dụng có sẵn để tải xuống trong các cửahàng ứng dụng kể từ quý 3 năm 2018, người dùng Android có thể chọn giữa 2,1triệu ứng dụng App Store của Apple vẫn là cửa hàng ứng dụng lớn thứ hai với gần

2 triệu ứng dụng có sẵn (xem Hình 1.1)

Thực tế, tính đến tháng 3 năm 2018, Google Play có khoảng 3,6 triệu ứng dụng,nhiều hơn 100 nghìn so với tháng 12 của năm trước Apple Store đã tăng từ 800 ứngdụng trong tháng ra mắt vào tháng 7 năm 2008 lên 2,2 triệu vào tháng 1 năm 2017

Apple ước tính rằng vào tháng 9 năm 2016, các ứng dụng từ Apple App Store đãđược tải xuống tích lũy 140 tỷ lần Tuy nhiên, dữ liệu năm 2016 cho thấy nhiều ứngdụng đã tải xuống không được sử dụng nhiều hơn một lần trong sáu tháng đầu tiên.Danh mục App Store phổ biến nhất là chơi game với khoảng 25% các ứng dụng cósẵn thuộc danh mục này [79].

Các ứng dụng di động ngày nay không chỉ phát triển để phục vụ cho giải trí hay lĩnhvực truyền thông xã hội, mà còn nhắm mục tiêu đến các lĩnh vực cần sự an toàn và tínhtoán quan trọng như hệ thống thanh toán, chính phủ, quân đội, sức khỏe, và nhiều lĩnhvực khác [50] Người dùng di động đang sử dụng các ứng dụng cài đặt trên điện thoạithông minh thay cho các máy tính cá nhân hay máy tính để bàn và họ hoàn toàn hyvọng rằng ứng dụng như vậy là dễ dùng, đáng tin cậy và an toàn để sử dụng Ngườidùng mong đợi các giải pháp dựa trên thiết bị di động đáp ứng hầu hết các tác vụ tínhtoán của họ Ứng dụng di động cần phải được tích hợp tốt, thiết kế tốt, dễ tiếp cận, hiệunăng cao và đáng tin cậy Tuy nhiên, điều này dẫn đến các giải pháp phát triển ứngdụng di động không chỉ phức tạp hơn mà còn thách thức cho việc phát triển cũng nhưkiểm thử, đánh giá tính đúng đắn, độ tin cậy cho ứng dụng [5]

1.2 Phân loại ứng dụng di động

Các ứng dụng di động được phân thành 3 nhóm:

Native Applications: Các ứng dụng bản địa được phát triển cho một nền tảng cụ thể

và được cài đặt trên thiết bị di động Các ứng dụng Android được phát triển bằng Java,trong khi iOS ứng dụng được viết bằng Objective-C hoặc Swift Các ứng dụng này cóquyền truy cập vào tất cả các thư viện nền tảng cụ thể và các API để tận dụng lợi thếcủa tất cả các tính năng của một điện thoại thông minh hiện đại đã cung cấp như có thểtruy cập trực tiếp vào máy ảnh, GPS và tất cả các cảm biến khác

Web Based Applications: ứng dụng được truy cập thông qua trình duyệt của bên

thứ 3 được cài trên thiết bị di động Một ứng dụng Web di động là một trang web

mà có thể được truy cập từ trình duyệt web của điện thoại Trang web đó được tối

ưu hóa cho việc sử dụng trình duyệt di động và độc lập với các nền tảng di động.Các ứng dụng Web di động đang phát triển với các công nghệ web như HTML vàJavaScript, đặc biệt là với HTML5, CSS3 và JavaScript

Hybrid Applications: là sự kết hợp giữa ứng dụng native và ứng dụng web.

Những ứng dụng đó bao gồm các công nghệ Web khác nhau như HTML5 hoặcJavaScript Một khi các phần web đã được xây dựng, việc phát triển có thể biên dịch

mã cơ sở này với định dạng gốc khác nhau: Android, iOS, Windows Phone, hoặcBlackBerry Để biên dịch mã web vào mã di động native, các nhà phát triển cầnphải sử dụng khung (framework) phát triển như PhoneGap Các framework như vậycung cấp API để truy cập các tính năng phần cứng thiết bị cụ thể trong phần webcủa ứng dụng Tương ứng với từng loại ứng dụng sẽ có các công nghệ, công cụ và

kỹ thuật phát triển được thể hiện qua Bảng 1.1

Bảng 1.1 So sánh các kỹ thuật, công nghệ phát triển của các loại ứng dụng di động

Ưu điểm dụng với nhiều giao web với tốc độ truy cập

dụng; 1 sản phẩm nhưngdiện, hay đồ họa thiết bị và kho phân có thể chạy trên nhiều

phối ứng dụng Native nền tảng khác nhauThời gian và chi phí

phát triển lớn Không thể xử lý đồ họa Không xử lý đồ họaTiếp tục bảo trì khó nhiều; yêu cầu phải

Không có tính cơ động quen, thân thiện vớiđiểm (portability) – không các framework phát Không truy cập được

camera, âm thanh

chạy được trên nền triển mobile

Native Hybrid Mobile web

Các ứng dụng hướng

Sử dụng tốt Các ứng dụng hướng cầu đồ họa vừa phải, ứng dụng trò chơi, tậpnhất cho người dùng mà yêu cầu các ứng dụng hướng trung cho các ứng dụng

cập tất cả các thiết bị

Các nghiên cứu [74], [35], [28] cho rằng những đặc thù của kiểm thử ứng dụng diđộng là một phần do sự đa dạng của các nền tảng và tính năng của các thiết bị diđộng Ví dụ, các thiết bị có kích thước màn hình (từ máy nhắn tin hoặc điện thoạithông minh nhỏ đến máy tính bảng lớn); cơ chế tương tác (stylus, ngón tay, bànphím, cử chỉ); băng thông mạng (ví dụ như Bluetooth, 3G, 4G, WiFi); khả năng lưutrữ; tốc độ CPU; kích thước thiết bị và tích hợp thiết bị với thiết bị ngoại vi hay hệthống máy tính khác Điều này làm cho nó rất khó để đảm bảo rằng các ứng dụng cóthể được sử dụng một cách hiệu quả trong bất kỳ hoàn cảnh và môi trường nào.Theo các nghiên cứu hiện tại cho thấy, hiện đang thiếu các nghiên cứu về cách đểđưa ra các yêu cầu kiểm thử cụ thể liên quan đến ứng dụng di động theo vòng đờiphát triển từ các đặc tả yêu cầu [74] Đặc biệt, các nhà phát triển phải xây dựng cácứng dụng để đảm bảo rằng nó sẽ được xem xét và hành xử đúng Những vấn đề trên

đã thúc đẩy nhu cầu cần phải có cách tiếp cận tốt hơn, các phương pháp, các kỹthuật, công cụ tốt hơn để thực hiện kiểm thử cho các ứng dụng di động nhằm đảmbảo chúng hoạt động hiệu quả và tin cậy [74], [28], [126], [57]

1.3 Kiểm thử ứng dụng di động

Kiểm thử ứng dụng di động là một quá trình mà phần mềm ứng dụng phát triểncho các thiết bị di động được thử nghiệm tính năng, khả năng sử dụng và hiệu năng.Kiểm thử ứng dụng di động có thể được thực hiện tự động hóa hoặc thủ công [54].Việc kiểm thử cho ứng dụng di động đang phải phải đối mặt với rất nhiều tháchthức Những câu hỏi nghiên cứu cần được giải quyết là:

(1) Các ứng dụng di động khác biệt gì so với các ứng dụng truyền thống, có yêu cầu đặc biệt nào về các kỹ thuật kiểm thử mới để đáp ứng điều khác biệt này?(2) Những thách thức và hướng nghiên cứu kiểm thử cho ứng dụng di động là gì?

(3) Vấn đề kiểm thử thủ công và kiểm thử tự động được thực hiện như thế nào, vai trò là gì?

(4) Với xu hướng phát triển các ứng dụng theo phương pháp linh hoạt thì vai tròcủa kiểm thử thay đổi như thế nào cho phù hợp nhằm nâng cao chất lượng và độtin cậy cho sản phẩm

1.3.1 Đặc điểm của ứng dụng di động

Việc xem xét tính di động và nhận biết theo ngữ cảnh (context-aware) như là cácđặc điểm đặc biệt nhất của ứng dụng di động Dựa trên những đặc điểm này có thểđịnh nghĩa 2 loại ứng dụng di động cụ thể và từ đó chúng ta phân tích các đặc điểmriêng biệt của ứng dụng di động dẫn đến việc nghiên cứu và đưa ra phương pháp, kỹthuật kiểm thử phù hợp cho quá trình phát triển ứng dụng

Một ứng dụng di động là ứng dụng chạy trên các thiết bị di động [74], [57] vànhận thông tin, dữ liệu đầu vào dựa theo thông tin ngữ cảnh [18] Ứng dụng di độngđược xem xét theo 2 yếu tố sau:

o Xét theo đặc điểm điện toán di động (mobile computing): một ứng dụng được

xem là ứng dụng di động nếu nó chạy được trên các thiết bị điện tử di động nhưmp3 reader, mobile phone, máy ảnh số theo Satyanarayanan [96] đã đưa ra

sự khác biệt và khái niệm về điện toán di động thông qua 4 ràng buộc: hạnchế nguồn tài nguyên; lổ hổng và bảo mật; hiệu suất và tính biến thiên độ tincậy; và nguồn năng lượng hữu hạn

o Xét trên sự nhận biết theo ngữ cảnh (context–aware): một ứng dụng di động là

sự nhận biết của môi trường điện toán mà ứng dụng chạy trên đó và thíchứng/phản ứng theo tính toán của ứng dụng, người dùng, yếu tố vật lý hoặc bốicảnh thời gian [97] Theo Schmidt [98] đã phân loại thông tin ngữ cảnh thànhyếu tố con người (người dùng, môi trường xã hội và các tác vụ) và môi trườngvật lý (vị trí, cơ sở hạ tầng, và điều kiện vật lý) Các thách thức trong nhận biếtngữ cảnh được thể hiện bởi những cảm biến theo ngữ cảnh (như vị trí, thời gian,đối tượng gần đó, hướng, ngữ cảnh xã hội), sự thích ứng hay cấu hình lại, cáchành động ngữ cảnh được kích hoạt và khám phá tài nguyên theo ngữ cảnh

Dựa vào hai yếu tố, đặc điểm trên có thể phân loại ứng dụng di động theo 2 nhómứng dụng như sau:

o Các ứng dụng truyền thống được viết lại để chạy trên các thiết bị di động như

ứng dụng web, tìm kiếm, mạng xã hội, các ứng dụng làm việc cộng tác… được

gọi là ứng dụng cho di động (Apps4Mobile)

o Và các ứng dụng di động sử dụng thông tin ngữ cảnh để sinh ra các kết quả

dựa vào ngữ cảnh thì gọi là ứng dụng di động (MobileApps)

Khi ảnh hưởng trực tiếp điến việc kiểm thử, ứng dụng Apps4Mobile sẽ kế thừanhững đặc tính đặc thù của ứng dụng di động như tính di động, tính đơn thể, tính kếtnối… trong khi MobileApps sẽ kế thừa những thách thức liên quan đến các ứng dụngnhận biết ngữ cảnh Từ quan điểm của kiểm thử, chúng ta xác định Apps4Mobile như

là một ứng dụng mà định hướng bởi user input (đầu vào của người sử dụng), chạy trêncác thiết bị di động với tài nguyên hạn hẹp Còn MobileApps là ứng dụng đặc biệt củaApps4Mobile mà dữ liệu đầu vào từ môi trường xung quanh của thiết bị và từ hànhđộng của người dùng để cho ra kết quả dựa vào ngữ cảnh Do đó, các kỹ thuật kiểm thửkhác nhau sẽ được yêu cầu cho từng loại ứng dụng

1.3.2.Tính đặc thù của ứng dụng di động ảnh hưởng đến việc kiểm thử phần mềm

Có thể nhóm các ứng dụng cho di động nói chung theo đặc thù riêng của nó như Bảng 1.2

Bảng 1.2 Phân loại ứng dụng di động theo đặc thù riêng và kiểm thử tương ứng [74]

Loại ứng Các trạng thái đặc Các loại kiểm thử được xem

Kết nối di động (Mobile Độ tin cậy, hiệu năng, an ninh, kiểm

thử chức năng thông qua các mạng

(*)

Loại ứng Các trạng thái đặc Các loại kiểm thử được xem

Khả năng thích ứng Kiểm thử tính chính xác của khả năng

thích ứng

Ngôn ngữ lập trình mới Kỹ thuật kiểm thử hộp trắng, hộp đen

(*)

Hệ điều hành mới (O.S) Kiểm thử tính tương thích

Sự đa dạng của điện thoại Kiểm thử mức độ bao phủ tính đa dạng

Touch screen- màn hình Tính dễ sử dụng và khả năng phản hồi

(*) các loại kiểm thử được nghiên cứu trong luận án này

1.4 Phương pháp phát triển linh hoạt

Qui trình phát triển phần mềm truyền thống đã không còn phù hợp khi các công

ty đang cố gắng rút ngắn thời gian sản xuất và đưa sản phẩm thị ra trường sớm.Trong nhiều trường hợp, nhiều nghiên cứu khác nhau [23, 32, 33, 44, 103, 105,116,117], việc kiểm soát chất lượng thường giảm hoặc hoãn lại do thời hạn cuối bịgiảm hoặc bị quá thời gian của các giai đoạn phát triển Các công ty phát triển phầnmềm cần có một qui trình phù hợp có thể đánh giá chất lượng trong từng giai đoạnphát triển sản phẩm của họ mà không cần can thiệp vào tiến độ giao hàng Chínhđiều này đã buộc các công ty phần mềm hiện nay chuyển sang việc sử dụng cácphương pháp phát triển linh hoạt (Agile Development Methodology- Agile)

Agile là triết lý phát triển phần mềm mà nhà phát triển sẽ phải thực hiện sản xuấtsản phẩm với lịch trình giao hàng ngắn bằng cách tạo ra một sản phẩm với tính năng

ít hơn thay vì hạ thấp các tiêu chuẩn chất lượng của các sản phẩm tương tự Với triết

lý và phương pháp phát triển phần mềm linh hoạt được cụ thể cho từng công tyriêng và thực hành tốt nhất của họ không thể dễ dàng áp dụng cho một tổ chức haycông ty khác Hơn nữa, nhiều công ty đang gặp phải các vấn đề trong việc chuyểnđổi từ cách tiếp cận truyền thống sang tiếp cận linh hoạt Một trong những nguyênnhân của vấn đề này là các công ty đang cố tái sử dụng các kỹ thuật và công cụ từquá trình phát triển truyền thống mà có thể không được áp dụng trong phương phápphát triển linh hoạt

Agile không phải là một qui trình phát triển phần mềm theo định nghĩa mà là mộttriết lý dựa trên một tập hợp các nguyên tắc Những nguyên tắc này được gọi là

"Tuyên ngôn Agile" [35],[105]

Một số quy trình phát triển phần mềm sử dụng một số các nguyên tắc đó, như:Lập trình cực hạn (XP), Scrum, Dynamic Systems Development Method (DSDM),Feature Driven Development (FDD), thường đề cập đến chúng như là phươngpháp phát triển phần mềm nhanh, linh hoạt

1.4.1 Phát triển hướng kiểm thử TDD

TDD (Test-Driven Development) có thể được hiểu là mô hình phát triển vớitrọng tâm hướng về việc kiểm thử TDD được xây dựng theo hai tiêu chí: Test-First(Kiểm thử trước) và Refactoring (điều chỉnh mã nguồn) [8,10] Hình 1.2 thể hiệnqui trình phát triển TDD Trong đó, khi một yêu cầu phần mềm được đặt ra:

Hình 1.2 Quy trình phát triển TDD [7]

o Người lập trình viên soạn thảo kịch bản kiểm thử (test case) cho yêu cầu đó

trước tiên và chạy thử kịch bản đó lần đầu tiên Hiển nhiên, việc chạy thử sẽđưa ra kết quả thất bại vì chức năng đó chưa được xây dựng (và thông qua kếtquả đó, ta cũng kiểm tra được là kịch bản kiểm thử đó được viết đúng)

o Theo đó, dựa vào mong muốn của kịch bản kia, người lập trình sẽ xây dựng

một lượng mã nguồn (source code) vừa đủ để lần chạy thứ 2 của kịch bản đóthành công

o Nếu trong lần chạy thứ hai vẫn đưa ra một kết quả thất bại, điều đó có nghĩa

là thiết kế chưa đáp ứng yêu cầu, người lập trình lại chỉnh sửa mã nguồn vàchạy lại kịch bản đến khi thành công

o Khi kịch bản kiểm thử được chạy thành công, người lập trình tiến hành chuẩn

hóa đoạn mã nguồn (base-line code) và tiếp tục hồi quy với kịch bản kiểm thửtiếp theo Việc chuẩn hóa bao gồm thêm các chú thích, loại bỏ các dư thừa, tối

ưu các biến

1.4.2 Phát triển hướng hành vi BDD

Trong mô hình TDD nhiệm vụ kiểm thử do lập trình viên đảm nhiệm và vai tròchuyên hóa của người kiểm thử gần như không còn nữa Trong mô hình TDD ngườikiểm thử chấp nhận (Acceptance Tester) không tồn tại Tuy nhiên, việc cộng gộp vaitrò (code-test) phát sinh vấn đề quá tải cho người lập trình viên Để làm tốt côngviệc, xuyên suốt chu trình người lập trình viên phải chú ý thêm những vấn đề thuần

túy của kiểm thử như: “Cái gì cần kiểm thử và cái gì không?”, “Viết bao nhiêu kịch

bản là đủ?”, “Làm sao để hiểu là kiểm thử đó thất bại?”, “Bắt đầu kiểm thử từ đâu?” Để giải quyết vấn đề phát sinh mà vẫn tận dụng triệt để lợi ích của phương

pháp TDD mang lại, Dan North phát triển một mô hình mới với tên gọi (Hình 1.3):Behavior-Driven Development – BDD (hoặc cũng có thể hiểu là Acceptance Test-Driven Development – ATDD) [1, 12,14] Trong đó, vai trò mới trong việc thiết kếkiểm thử (Test Design) được đặt ra:

o Thay vì chờ đợi sản phẩm hoàn thành và kiểm thử, người kiểm thử tham gia

vào quá trình xây dựng mã nguồn với vai trò phân tích và xây dựng kịch bảnkiểm thử dưới góc độ ngôn ngữ tự nhiên dễ hiểu từ các câu chuyện của người

o Đồng thời, người kiểm thử giúp đỡ lập trình viên trong việc giải thích và đưa ra

các phương án xây dựng mã nguồn mang tính thực tiễn với người dùng ngay

trước khi bắt tay vào việc lập trình

o Người lập trình viên liên hệ mật thiết với người kiểm thử và xây dựng mã nguồn

với những phương án mà người kiểm thử cung cấp theo mô hình TDD

o Kịch bản kiểm thử được phân chia làm 2 lớp: Lớp chấp nhận

(feature/acceptance test) và lớp đơn vị (unit test)

o Theo đó, kịch bản kiểm thử lớp đơn vị mang thuần tính thiết kế và phục vụ

cho việc kiểm thử lớp đơn vị (Unit test) còn kịch bản kiểm thử lớp chấp nhận

có thể được tái sử dụng cho quá trình kiểm thử hồi quy về sau

Hình 1.3 Mô hình BDD – TDD trong Agile mô phỏng bởi Paul Littlebury [12]

Từ mô hình BDD -TDD cho thấy được sự ưu việt mà BDD mang lại, đặc biệt làtrong các dự án phần mềm lớn và phức tạp, khi cả hai khía cạnh phân hóa vai trò vàchất lượng phải đi đôi Ngoài ra, việc thực thi kịch bản kiểm thử và xử lý sớm cácvấn đề thiết kế ngay trong khâu xây dựng sẽ giúp giảm thiểu tối đa chi phí và côngsức sửa chữa lỗi

Trong khi khái niệm BDD mang tính lý thuyết, việc ứng dụng của nó lại mangnặng tính thực nghiệm Để phát huy lợi ích về thời gian trong việc xây dựng kịchbản kiểm thử, ngôn ngữ và cách truyền tải là một thử thách khi phải đáp ứng khảnăng đọc hiểu từ cả 2 khía cạnh: tự nhiên và thiết kế Bằng sự vay mượn từ ngônngữ viết câu chuyện người dùng (User Story), ngôn ngữ Gherkin được phát triển đểphục vụ nhu cầu đó với cấu trúc đơn giản, hướng đối tượng và tương đồng cho mọikịch bản: Given – When – Then [12]

Given: Là một chủ thẻ ATM ngân hàng

When: Tôi thực hiện giao dịch rút tiền

Then: Tôi có thể rút được tiền trong tài khoản của tôi và thực hiện một số giao dịch khác

Điều kiện cho kiểm thử chấp nhận được mô tả theo đặc tả này, được phân tích và sinh từ user story

Given: Bối cảnh của hệ thống là gì? Những điều kiện trước nào phải đúng trước khi hành

động được kiểm tra? Dữ liệu gì trong hệ thống?

When: Điều gì sẽ được kiểm tra? Đầu vào những dữ liệu sẽ được kiểm tra thông qua các

quy luật kinh doanh khi các hành động xảy ra?

Then: Để phản hồi với các hành động, các kết quả quan sát được là gì? Các kết quả dự

kiến là gì? Hậu điều kiện hoặc dữ liệu đầu ra quan sát bởi người sử dụng là gì?

Ví dụ cụ thể từ user story sinh kiểm thử chấp nhận:

User story title: Khách hàng rút tiền mặt từ ATM.

As a “Khách hàng”

I want to “rút tiền mặt từ máy ATM”

So that I “không phải xếp hàng ở ngân hàng”

Acceptance Criterion 1 (điều kiện chấp nhận 1)

Given “tài khoản đó là đáng tin cậy”

And “Thẻ là hợp lệ”,

And “bộ phân phối có chứa tiền mặt – còn tiền trong máy ATM”

When “Khách hàng yêu cầu rút tiền”

Then “đảm bảo đây là tài khoản ghi nợ”

And “đảm bảo tiền mặt được phân phối”

And “đảm bảo tiền được nhả ra từ máy ATM”.

Acceptance Criterion 2 (điều kiện chấp nhận 2)

Given “khách hàng rút quá số tiền mặt cho phép”

And “thẻ là hợp lệ”,

When “khách hàng yêu cầu rút tiền mặt”

Then “đảm bảo thông báo từ chối được hiển thị”

And “đảm bảo rằng tiền sẽ không được nhả ra từ máy ATM”.

1.4.3 Kiểm thử trong môi trường phát triển Agile Scrum

Các mô hình hướng Agile như TDD-BDD đang dần thay đổi vai trò của một kiểmthử viên (Acceptance Tester) truyền thống trong việc kiểm thử Công việc kiểm thử dựatrên nguyên tắc đợi sản phẩm phần mềm hoàn tất (một phần hoặc toàn phần) và thực thikiểm thử trên sản phẩm như một người dùng cuối không còn phù hợp Thay vào đó, vaitrò của người kiểm thử có xu hướng chuyển dần sang việc bảo trì chất lượng phần mềm

và hỗ trợ kỹ sư lập trình trong việc tối ưu sự tiện dụng của sản phẩm ngay từ khâu xâydựng Các kỹ sư kiểm thử cần có khả năng xây dựng và thực thi các bộ kiểm thử mangtính bảo trì chất lượng Đặc biệt, kiểm thử hồi quy tự động và các bộ kiểm thử tải làphần việc duy nhất kỹ sư phát triển không đảm nhiệm [93,110]

1.5 Các thách thức của kiểm thử ứng dụng di động

Nghiên cứu của luận án tập trung phân tích những thách thức và các hướngnghiên cứu tiềm năng trong tương lai về (i) qui trình và môi trường kiểm thử, (ii) kỹthuật kiểm thử, (iii) các mức kiểm thử, (iv) phạm vi kiểm thử được thực hiện

Một số thách thức và xu hướng kiểm thử cho ứng dụng di động:

o Khách hàng: Kỳ vọng của khách hàng là một trong những thách thức chính đối

với các nhà phát triển di động Mỗi người dùng có kỳ vọng từ các ứng dụng diđộng là duy nhất, dẫn đến việc phát triển và cung cấp một sản phẩm thỏa mãncho khách hàng là khá khó khăn Theo khảo sát của Compuware [71], có gần80% người dùng xóa một ứng dụng sau khi sử dụng nó lần đầu tiên Bốn lý dohàng đầu để xóa ngay lập tức sau khi cài đặt là: thiết kế xấu, khả năng sử dụngkém, thời gian tải chậm, treo máy Gần 60% người sử dụng sẽ xóa một ứng dụng

mà có yêu cầu đăng ký và hơn một nửa số người dùng mong đợi một ứng dụng

có thể khởi động trong 2 giây Dựa trên những con số cho thấy rằng, người dùng

di động có kỳ vọng thực sự cao khi nói đến khả năng sử dụng, hiệu năng và độtin cậy của ứng dụng di động Hướng kiểm thử về hiệu năng, tính

dễ sử dụng và độ tin cậy của ứng dụng là rất quan trọng cần phải được thực hiện

o Nền tảng di động và sự phân mảnh thiết bị: Các nhà cung cấp điện thoại di động

khác nhau và các nền tảng di động khác nhau sẽ là một thách thức lớn cho pháttriển và kiểm thử Dựa trên các số liệu từ OpenSignal [7], gần 19.000

thiết bị Android có sẵn trên thị trường Cho nên không thể và không cần thiếtphải thử nghiệm trên tất cả các thiết bị Các phần cứng và phần mềm có thểkết hợp trên các nền tảng cũng là một thách thức lớn cho phát triển và kiểmthử Giải pháp thực hiện là phân nhóm thiết bị, thực hiện kiểm thử tổ hợp đểlàm giảm số lượng kiểm thử, giảm khối lượng công việc của kiểm thử, tăngnăng suất

o Vòng đời của ứng dụng di động: Đối với các ứng dụng di động, chu kỳ sống

(vòng đời) được coi là các trạng thái khác nhau mà một ứng dụng có thể trải quatrong thời gian chạy của nó và chuyển đổi giữa các trạng thái Khi phát triển cácứng dụng di động chạy trên hệ điều hành Android hay iOS, các nhà phát triểnphải quan tâm các trạng thái của chu kỳ sống để đảm bảo chính xác hành vi củaứng dụng trong mọi trường hợp Điều này sẽ đảm bảo rằng các nhà phát triển cóthể xây dựng một ứng dụng di động đáng tin cậy và đầy đủ, hoạt

động một cách chính xác và có thể duy trì tính toàn vẹn dữ liệu [45,60 ,88] Cóhai nghiên cứu đã đề xuất và đánh giá cách tiếp cận kiểm tra sự phù hợp của

các ứng dụng di động cho các mô hình vòng đời [35], [36] Tuy nhiên, cácphương pháp được đề xuất là rất cơ bản và hầu hết các bước quan trọng được

đề xuất là thủ công và phụ thuộc vào các nhà phát triển hoặc nhận thức củakiểm thử viên về vấn đề này

o Qui trình kiểm thử: Qui trình kiểm thử ứng dụng di động bao gồm nhiều hoạt

động khác nhau nhưng chỉ tập trung vào khâu chọn lựa kỹ thuật, phương pháp,lựa chọn kịch bản kiểm thử và cách thức thực thi Các ứng dụng MobileAppsnhận các giá trị đầu vào từ các đối tượng ngữ cảnh khác nhau như người dùng,sensor và các thiết bị kết nối, các dữ liệu vào từ các ngữ cảnh khác nhau và luônthay đổi Điều này sẽ dẫn đến việc không thể dự đoán được mức độ biến

động của các giá trị đầu vào mà ứng dụng sẽ nhận Do đó, các điều kiện kiểmthử mới sẽ được yêu cầu cung cấp các hướng dẫn, các luật và chiến lược choviệc sẽ lựa chọn kịch bản kiểm thử nào để đảm bảo mức độ bao phủ tối đatrong trường hợp không dự đoán được mức độ biến đổi của dữ liệu vào theongữ cảnh Đối với các ứng dụng Apps4Mobile, việc thực thi kiểm thử cơ bảngiống với các ứng dụng truyền thống Còn đối với các ứng dụng MobileApps,thông tin ngữ cảnh sẽ là thách thức cho việc thực thi các trường hợp kiểm thử.Hiện tại các trình giả lập không thể mô phỏng được thực tế của các điện thoạivới các sensor, GPS, hay các kết nối Kỹ thuật ghi (capture) và chạy lại(replay) mới có thể được triển khai cho việc thực thi các trường hợp kiểm thửvới dữ liệu vào phụ thuộc ngữ cảnh trong suốt giai đoạn lựa chọn trường hợpkiểm thử Áp dụng phương pháp kiểm thử hướng ngữ cảnh, kiểm thử hướng

mô hình là hướng giải quyết cho thách thức này

o Kiểm thử chức năng: Các kỹ thuật kiểm thử chức năng sẽ yêu cầu xác định cả

ứng dụng và môi trường mà nó hoạt động Cách tiếp cận dựa trên trạng thái cóthể được xem là một phần hữu hiệu cho việc xác định các trạng thái khác nhaucho một ứng dụng di động có thể tính đến khi nhận các dữ liệu cảm ứng khácnhau Cũng có thể sử dụng cách tiếp cận dựa trên trạng thái (State-based) cho môhình các chế độ thực thi kiểm thử khác nhau như (chế độ low battery, flightmode, meeting) Các công cụ hiện tại như Robotium có thể được sử dụng;

MonkeyRunner có thể dùng kiểm thử chức năng cho ứng dụng Android.MobileTest là công cụ kiểm thử tự động hộp đen cho các ứng dụng di động.

o Kiểm thử đơn vị và kiểm thử tích hợp: Các công cụ, các nghiên cứu hiện nay

tập trung nhiều cho kiểm thử đơn vị (Unit test) còn kiểm thử tích hợp dườngnhư ít được quan tâm khai thác Đối với việc lập trình các ứng dụng di độnghiện nay, kiểm thử đơn vị được tập trung triển khai và hỗ trợ nhiều, iOS cóhướng dẫn cho kiểm thử đơn vị; Android có Junit Tuy nhiên cả 2 trường hợpđều không xem xét đến giá trị ngữ cảnh (contextual values)

o Kiểm thử tích hợp: Trong khi hầu hết các cách tiếp cận kiểm thử hiện tại đềuxem xét các ứng dụng di động trong sự cô lập Kiểm thử tích hợp các ứng dụng

di động là nói đến việc kiểm thử tính giao tiếp giữa các ứng dụng thông qua ýđịnh hoặc nơi cung cấp nội dung trong nền tảng Android [76] Thông thường cácứng dụng di động không tồn tại riêng một mình mà nó có nhu cầu trao đổi dữliệu với các thành phần khác hoặc các ứng dụng thuộc hệ điều hành Tương tự,các ứng dụng di động cũng thường yêu cầu giao tiếp với các ứng dụng khác bênngoài như các trang web mạng xã hội (như Facebook, Twitter và MySpace)

[79]

o Kiểm thử độ tin cậy và hiệu năng: Hiệu năng và độ tin cậy của ứng dụng phụ

thuộc rất lớn vào tài nguyên của thiết bị di động, phụ thuộc vào chế độ hoạt độngcủa thiết bị, chất lượng kết nối và mức độ biến thiên thông tin ngữ cảnh Các kỹthuật kiểm thử mới cho phân tích độ tin cậy và hiệu năng của ứng dụng phải xemxét đến các đặc tính liên quan sự thay đổi ngữ cảnh và sự khác nhau của thiết bị.Các kỹ thuật phân tích khi run-time có thể cũng được thích ứng để

giám sát tài nguyên và trạng thái kết nối

o Kiểm thử bộ nhớ và năng lượng: Lãng phí, rò rỉ bộ nhớ có thể làm hạn chế tài

nguyên của hệ thống, các tiến trình đang hoạt động có thể làm giảm năng lượngcủa thiết bị Có thể sử dụng các độ đo để đo lường, ước lượng năng lượng sửdụng và tiêu thụ năng lượng được đề xuất để tự động dự đoán mức độ rò rỉ bộnhớ và mất mát năng lượng Nghiên cứu hiện tại có iOS Instruments cho phépphân tích rò rỉ bộ nhớ (memory leaks) Tuy nhiên, việc phân tích như vậy là chưađầy đủ Thompson et al [41] [111] đã đề xuất một công cụ hướng mô

hình để mô hình hóa các kiến trúc phần mềm di động một cách liên tục được

sử dụng để sinh mã mô phỏng ước lượng tiêu thụ điện năng

o Kiểm thử bảo mật: Tính bảo mật đặc biệt có liên quan đến tính di động của thiết

bị vào các vùng mạng có mức độ an ninh là khác nhau Một trojan có thể truyxuất vào thông tin cá nhân, các mạng riêng và thông tin ngữ cảnh riêng tư như vịtrí người dùng ứng dụng đang đứng Các mạng khác nhau đại diện cho tính đặcthù của các ứng dụng di động nên phương pháp kiểm tra an ninh truyền thốngđược thay đổi để xem xét các yếu tố ngữ cảnh phải được mô phỏng nhằm

kiểm tra những dữ liệu được truyền từ các thiết bị di động

o Kiểm thử tự động: Hầu hết các phát triển ứng dụng di động được coi là phát triểnnhanh chóng và các đội dự án sẽ phân phối các ứng dụng cho thị trường trongmột thời gian ngắn để theo kịp với nhu cầu thị trường Với sự hỗ trợ của kiểmthử tự động, kỹ sư kiểm thử có nhiều khả năng để có thể bắt kịp với các kỹ sưphát triển để duy trì sự nhanh nhẹn này Hơn nữa, kiểm thử tự động giúp tiếtkiệm thời gian cho các kỹ sư kiểm thử, hạn chế sai sót của các kiểm thử thủcông Những công cụ hỗ trợ kiểm thử tự động hiện tại chủ yếu là kiểm thử đơn

vị và kiểm thử giao diện UI [34]

o Kiểm thử dòng sản phẩm: Kiểm thử một ứng dụng trên nhiều thiết bị khác

nhau thực sự là một thách thức quan trọng, đặc biệt như Android OS, các diệnthoại khác nhau sẽ cung cấp các thành phần phần cứng và tính năng khácnhau cũng như các nhà sản suất điện thoại tùy biến hệ điều hành khác nhau.Việc xem xét hơn 130 điện thoại di động khác nhau đang chạy Android OSvới 7 phiên bản khác nhau và nếu cứ mỗi thiết bị có 02 firmwares thì sẽ cóđến 1800 tổ hợp khác nhau Do đó, việc kiểm thử trên nhiều thiết bị sẽ đượcthay thế bởi các kỹ thuật được tự động hiệu quả hơn về mặc chi phí Một cáchtiếp cận khác là cho phát hành bản kiểm thử beta (miễn phí) trên các thiết bịkhác nhau, từ đó thu thập dữ liệu lỗi, dữ liệu khi chạy để phân tích và tìm lỗi

1.6 Kết chương

Trong Chương 1, luận án đã trình bày tổng quan về điện thoại di động thông minh, ứng dụng cho điện thoại di động, phân loại ứng dụng di động, các số liệu thống kê và

xu hướng sử dụng ứng dụng di động Các thách thức trong phát triển và kiểm thửứng dụng di động, qui trình phát triển và kiểm thử ứng dụng di động Các nội dungtrình bày trong chương này thể hiện được các cơ sở lý luận và thực tiễn yêu cầu mànhiệm vụ của luận án cần phải đưa ra để giải quyết.

Trong các Chương tiếp theo, luận án sẽ được cụ thể hóa các đề xuất và cách thựcnghiệm để đánh giá các phương pháp, kỹ thuật hay cách tiếp cận thực hiện kiểm thửứng dụng di động Android

CHƯƠNG 2 CÁC KỸ THUẬT TỐI ƯU HÓA, TÁI CẤU TRÚC VÀ PHÂN TÍCH MÃ NGUỒN CỦA ỨNG DỤNG

DI ĐỘNG

Trong chương này, các kỹ thuật được nghiên cứu và phát triển bao gồm (1) kỹ thuật phân tích, tối ưu mã nguồn Java dựa trên PMD và Android lint, xây dựng tập qui tắt mới (sau đây gọi là “tập luật” hay “luật”) cùng với công cụ hỗ trợ phân tích mã tự động, tái cấu trúc mã nguồn để giảm tiêu thụ năng lượng, nâng cao hiệu năng cho ứng dụng Android và (2) Kỹ thuật phân tích mã nguồn nhằm đánh giá mức độ bao phủ mã nguồn, xác định lỗi cấu trúc, lỗi logic tiềm ẩn trong chương trình cũng như đánh giá khả năng chịu lỗi của một chương trình viết bằng Java.

2.1 Đặt vấn đề

Phân tích và tối ưu hóa mã nguồn là các kỹ thuật cải thiện chất lượng phần mềm vàtăng hiệu suất của hệ thống Thanh tra và xem xét mã nguồn là các kỹ thuật kiểm thửtĩnh được sử dụng để nâng cao chất lượng và độ tin cậy của ứng dụng Phân tích mãnguồn nhằm phát hiện ra các khiếm khuyết và các vấn đề tiềm ẩn trong một ứng dụngdựa trên kinh nghiệm đã có [1-3] Kiểm thử tĩnh là một hình thức kiểm thử phần mềm

có thể được áp dụng trong từng giai đoạn phát triển khi mà phần mềm chưa được thựcthi Hoạt động chủ yếu là kiểm tra sự minh bạch của mã, thuật toán hoặc tài liệu Ngườilập trình có thể sử dụng loại thử nghiệm này để cải thiện chất lượng của mã nguồn vàsản phẩm [15] Ngoài ra, việc phân tích và đánh giá mức độ bao phủ mã nguồn, xácđịnh lỗi cấu trúc, lỗi logic cũng như đánh giá khả năng chịu lỗi của một chương trình,của một phương thức (hay một hàm) khi kiểm thử hộp trắng là hoạt động rất quan trọng

và cần thiết để đảm bảo chương trình hoạt động đúng và tin cậy Do đó, sự cần thiếtphải có kỹ thuật, phương pháp kiểm thử hộp trắng để giúp người phát triển có thể biếtđược mức độ bao phủ các câu lệnh, bao phủ các nhánh, bao phủ các đường của từngphương thức Hơn nữa, thông qua phương pháp và mô hình kiểm thử này, người pháttriển có thể biết được phương thức đó tồn tại những loại lỗi nào và thông tin vị trí lỗi,với bộ dữ liệu đầu vào như thế nào thì phương thức bộc lộ ra các lỗi nhưng không biếtđược chính xác vị trí lỗi, hoặc phương thức chưa xử lý chặt khiến nó kém khả năngchịu lỗi Từ tất cả các thông tin thu được từ mô