đồ án 1 phương pháp và công cụ để hỗ trợ kiểm thử phần mềm android

Giáo viên hướng dẫn: ThS Nguyễn Thị Thanh Trúc

Nhóm sinh viên thực hiện:

Tp Hồ Chí Minh, 12/2023

LỜI CẢM ƠN

Lời đầu tiên, chúng em xin gửi lời cảm ơn sâu sắc tới ThS Nguyễn Thị ThanhTrúc đã tận tâm chỉ bảo, hỗ trợ và hướng dẫn chúng em trong quá trình thực hiện Đồ án1.

Đồng thời, chúng em cũng bày tỏ lòng biết ơn chân thành đến Trường Đại họcCông nghệ Thông tin – Đại học quốc gia thành phố Hồ Chí Minh đã tạo ra môi trườnghọc tập tích cực với đội ngũ giáo viên nhiệt tình, cung cấp đầy đủ cơ sở vật chất và cácnguồn tư liệu học tập phong phú, thuận tiện cho việc tìm kiếm, nghiên cứu thông tin.

Và cuối cùng, chúng em xin gửi lời cảm ơn đến gia đình, tất cả thầy cô trong KhoaCông nghệ Phần mềm và tập thể lớp KTPM2021 là những người luôn sát cánh, chia sẻnhững khó khăn và giúp đỡ nhau trong học tập và cuộc sống.

Trong quá trình làm đồ án này chúng em không tránh khỏi nhiều sai sót Vì vậy,chúng em mong nhận được sự quan tâm, đóng góp của quý thầy cô để đồ án này có thểhoàn thiện hơn và làm nền tảng để phát triển Khoá luận tốt nghiệp trong tương lai.

Chúng em xin chân thành cảm ơn!

NHẬN XÉT CỦA GIẢNG VIÊN

NHẬN XÉT CỦA GIẢNG VIÊN 2

CHƯƠNG 1: TỔNG QUAN ĐỀ TÀI 9

1.1 Lý do chọn đề tài: 9

1.2 Mục tiêu 9

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

1.4 Phương pháp thực hiện 11

CHƯƠNG 2: CƠ SỞ LÝ THUYẾT VÀ CÔNG NGHỆ 12

2.1 Các phương pháp kiểm thử phần mềm Android 12

2.1.1 Phương pháp Compatibility Test Suite(CTS) 12

2.1.2 Phương pháp kiểm thử mờ (Fuzz) 17

2.1.3 Phương pháp kiểm thử Monkey 22

2.1.4 Phương pháp kiểm thử ghi và phát lại (Record and Playback) 25

2.1.5 Phương pháp kiểm thử dựa trên mô hình (Model based) 27

2.2 Các công cụ hỗ trợ kiểm thử phần mềm Android 32

2.3.1 So sánh giữa Appium và Selenium 39

2.3.2 So sánh giữa Appium và Robotium 40

CHƯƠNG 3: PHÂN TÍCH THIẾT KẾ 43

3.1 Ứng dụng áp dụng phương pháp Monkey Testing 43

3.1.1 Phân tích phương pháp 43

3.1.2 Phân tích kỹ thuật 46

3.1.3 Phân tích nghiệp vụ 47

3.2 Ứng dụng áp dụng phương pháp Play and record 49

4.2.2 Mô tả chi tiết màn hình 61

CHƯƠNG 5: KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 69

5.1 Kết luận 69

5.2 Hướng phát triển 69

TÀI LIỆU THAM KHẢO 71

Bảng 2 So sánh các loại của Monkey Test 41Bảng 3 So sánh các phương pháo kiểm thử ngẫu nhiên 43Bảng 4 Danh sách màn hình 59

DANH MỤC HÌNH ẢNH

Hình 1 Quy trình đạt được Google’s certification 11

Hình 2 Luồng làm việc của phương pháp CTS 12

Hình 3 Danh sách các tệp apk và xml 13

Hình 4 Danh sách các ca kiểm thử trong mỗi tệp xml 14

Hình 5 Danh sách các package trong Plan 15

Hình 6 Mô hình kiểm thử Fuzz 17

Hình 7 Các giai đoạn của kiểm thử Fuzz 18

Hình 8 Quy trình thực hiện của kiểm thử Monkey 23

Hình 9 Mô hı̀nh sinh ca kiểm thử chương trình viết môt bài thơ trong notepad 27

Hình 10 Máy trạng thái thể hiện trạng thái của 1 bài báo trên trang tin tức 28

Hình 11 Mô hình biểu đồ trạng thái hê ̣thống quản lý lỗi 29

Hình 12 Các giai đoạn của kiểm thử dựa trên mô hình 30

Hình 13 So sánh giữa Appium và Selenium 38

Hình 14 Nhập lệnh Monkey 46

Hình 15 Hình ảnh mô tả trạng thái của quá trình kiểm thử 46

Hình 16 Usecase chi tiết cho nghiệp vụ Quản lý hóa đơn 49

Hình 17 Sơ đồ hoạt động của Thêm kịch bản 50

Hình 18 Sơ đồ hoạt động của Sửa kịch bản 51

Hình 19 Sơ đồ hoạt động của Xóa kịch bản 52

Hình 20 Sơ đồ hoạt động của Chạy kịch bản 53

Hình 21 Sơ đồ hoạt động của Thêm hành động 54

Hình 22 Sơ đồ hoạt động của Xóa hành động 55

Hình 23 Sơ đồ hoạt động của Tìm kiếm kịch bản 56

Hình 24 Hình màn hình trước khi kiểm thử 58

Hình 25 Hình ảnh báo cáo lỗi 59

Hình 26 Hình ảnh video ghi hình trong quá trình kiểm thử 59

Hình 27 Màn hình trang chủ 61

Hình 28 Màn hình Thêm kịch bản kiểm chứng 62

Hình 29 Màn hình Thêm tác động “Click” trong kịch bản 63

Hình 30 Màn hình Thêm tác động “Swipe” trong kịch bản 64

Hình 31 Màn hình Sửa kịch bản 65

Hình 32 Màn hình Sửa hành động 66

Hình 33 Màn hình Tìm kiếm kịch bản 67

CHƯƠNG 1: TỔNG QUAN ĐỀ TÀI1.1.Lý do chọn đề tài:

Ngày nay, với sự phát triển mạnh mẽ của Internet và nhu cầu sử dụng mạng xã hội, cácphần mềm trên điện thoại ngày càng nhiều nhằm đáp ứng nhu cầu về nhiều mặt củangười sử dụng.

Chính vì nhu cầu sử dụng điện thoại với nhiều mục đích khác nhau đang tăng cao nêncàng nhiều ứng dụng được tạo ra để phục vụ nhu cầu đó

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 để đánh giá chúng có đáp ứng tốt những yêu cầu đề ra hay không trước khi ngườidùng tiếp cận chúng Và android là hệ điều hành di động phổ biến nhất trên thế giới vàđược sử dụng trên rất nhiều thiết bị khác nhau Vì vậy, việc kiểm thử các phần mềmAndroid là rất cần thiết để đảm bảo chất lượng sản phẩm trước khi phát hành.

Trong quá trình kiểm thử các phần mềm Android, các công ty phần mềm gặp nhiều khókhăn bởi các lý do sau:

- Các kỹ thuật viên kiểm thử chưa có một phương pháp thích hơp để kiểm tra tínhđúng đắn của các sản phẩm trên điện thoại.

- Trong quá trình phát triển phần mềm, sản phẩm luôn phải cập nhật liên tục Mỗilần phiên bản mới được phát hành, người kiểm thử phải tiến hành kiểm thử hồiquy tất cả các thành phần, để tránh gây ra xung đột.

- Có quá nhiều ràng buộc dữ liệu đầu vào và ra.

- Giao diện phải nhất quán theo chuẩn nhằm tạo cho phần mềm có tính khả dụng.Vì những lý do trên mà chúng em chọn đề tài "Phương pháp và công cụ để hỗ trợ kiểmthử phần mềm Android".

1.2.Mục tiêu

- Tìm hiểu về phương pháp kiểm thử phần mềm Android: Nghiên cứu các phươngpháp và kỹ thuật kiểm thử phần mềm đang được sử dụng trong lĩnh vực Android,bao gồm kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hoạt động, kiểm thử hiệu

năng, kiểm thử hệ thống, kiểm thử giao diện, kiểm thử cài đặt, kiểm thử bảo mật,và kiểm thử tự động.

- Phân tích các công cụ kiểm thử phần mềm Android hiện có: Nghiên cứu các côngcụ tự động hóa kiểm thử phần mềm Android hiện có trên thị trường, bao gồm cáccông cụ mã nguồn mở và các công cụ thương mại, và phân tích ưu điểm và hạnchế của từng công cụ.

- Xây dựng công cụ kiểm thử phần mềm Android tự động: Phát triển một công cụ tựđộng hóa kiểm thử phần mềm Android dựa trên phương pháp kiểm thử đã đề xuất,giúp đơn giản hóa và tăng cường hiệu quả của quá trình kiểm thử.

- Thực hiện công cụ kiểm thử phần mềm Android và đánh giá kết quả: Áp dụngcông cụ kiểm thử phần mềm Android đã phát triển vào một số ứng dụng di độngthực tế, thực hiện quá trình kiểm thử và đánh giá hiệu quả của công cụ theo cáctiêu chí như độ bảo mật, độ tin cậy và tốc độ kiểm thử.

- So sánh và đánh giá phương pháp và công cụ kiểm thử phần mềm Android với cáccông trình liên quan: So sánh kết quả của phương pháp và công cụ kiểm thử phầnmềm Android đã phát triển với các công trình liên quan khác trong cùng lĩnh vực,nhằm xác định ưu điểm và hạn chế của đề tài nghiên cứu.

- Đề xuất các hướng phát triển và cải tiến: Dựa trên kết quả nghiên cứu, đề xuất cáchướng phát triển và cải tiến trong lĩnh vực kiểm thử.

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

- Các phương pháp kiểm thử phần mềm Android: CTS(Compatibility Test Suite),phương pháp kiểm thử mờ(Fuzz), kiểm thử Monkey, ghi và phát lại(Record andPlayback), phương pháp kiểm thử dựa trên mô hình(Model based).

- Các công cụ hỗ trợ kiểm thử phần mềm Android: Appium, Robotium(kiểm thửgiao diện), Espresso, UI Automator(kiểm thử tự động), Android Studio,Robolectric.

- Các ứng dụng Android: các ứng dụng di động từ đơn giản đến phức tạp như tròchơi, mạng xã hội, ngân hàng, quản lý,

1.4.Phương pháp thực hiện

- Phương pháp làm việc: Làm việc nhóm 2 thành viên thông qua sự hướng dẫn trực tiếp hoặc hướng dẫn qua Teams của giảng viên.

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

 Thu nhập và phân tích các tài liệu và thông tin liên quan đến đề tài. Thảo luận, lựa chọn phương hướng giải quyết vấn đề.

 Kiểm tra, thử nghiệm và đánh giá kết quả.- Phương pháp công nghệ:

 Sử dụng Google drive để quản lý tiến trình và tài liệu. Quản lý source code thông qua Github.

 Tìm hiểu và kiểm thử 1 số phần mềm qua các công cụ hỗ trợ kiểm thử.

CHƯƠNG 2: CƠ SỞ LÝ THUYẾT VÀ CÔNG NGHỆ2.1.Các phương pháp kiểm thử phần mềm Android

2.1.1 Phương pháp Compatibility Test Suite(CTS)2.1.1.1.Giới thiệu CTS

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ượtqua 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ácca 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 1 Quy 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 TestSuite 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 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ộtbộ kiểm thử bao gồm các API mới của phiên bản Android đó.

Bảng 1 Bảng thể hiện các phiên bản CTS của từng phiên bản Android

Quy trình làm việc sẽ được mô phỏng đơn giản theo mô hình sau:

Hình 2 Luồng làm việc của phương pháp 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.1.1.3.Các loại testcases

- CTS bao gồm các loại trường hợp thử nghiệm sau:

 Unit tests: Kiểm thử các đơn vị mã nguyên tử trong nền tảng Android; ví dụ: một lớp duy nhất, chẳng hạn như java.util.HashMap.

 Functional tests: Kiểm tra sự kết hợp của các API với nhau trong use-case cấp cao hơn.

- Những phiên bản tương lai của CTS sẽ bao gồm những loại testcases dưới đây:

 Robustness tests: Kiểm tra độ bền của hệ thống dưới áp lực.

 Performance tests: Kiểm tra hiệu suất của hệ thống dựa trên các tiêu chuẩn đã xác định, chẳng hạn như kết xuất khung hình trên giây.

2.1.1.4.Cấu trúc của Android CTS

Phương pháp CTS gồm 3 phần chính Repository, Tools, Docs.

a) Docs

Tài liệu này liệt kê các yêu cầu phải đáp ứng để thiết bị tương thích với phiên bảnAndroid 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ênAPI, các tham số của nó và miêu tả chi tiết hoạt động của API đó.

b) Repository

Respository gồm 3 phần: Testcases, Plans và Result.

- Tescases: 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

Hình 3 Danh sách các tệp apk và xml

 Danh sách các ca kiểm thử được liệt kê theo tệp xml như sau:

Hình 4 Danh sách các ca kiểm thử trong mỗi tệp xml

 Tệp apk (android application package) là bộ cài đặt ứng dụng trên hệ điều hànhandroid Khi build các ca kiểm thử tương ứng sẽ được tệp này.

- 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 “.\androidcts\repository\plans” Nó khai báo tên gói “package”của tệp tin apk cần được kiểmthử.

Hình 5 Danh sách các package trong Plan

- 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ếtquả này sẽ được lưu trữ trong thư mục “.\android-cts\repository\results”.

c) 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 tincts-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ínhlà 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ử.

- Với Android 6.0 hoặc thấp hơn, hãy sử dụng CTS v1 command console Còn vớiAndroid 7.0 trở lên, hãy sử dụng CTS v2 command console Cả 2 CTS v1 và CTSv2 đều có hai câu lệnh là help(hiển thị bảng tóm tắt những câu lệnh được sử dụngphổ biến) và help all(hiển thị danh sách đầy đủ các câu lệnh) Để có thể biết thêmchi tiết về các câu lệnh có thể tham khảo tại [2]

2.1.1.5.Ưu điểm

- Tiêu chuẩn hóa: CTS là một bộ tiêu chuẩn kiểm tra được phát triển bởi Google,nhằm đảm bảo sự tương thích của các thiết bị chạy hệ điều hành Android với cácứng dụng và công nghệ Android CTS giúp định rõ các yêu cầu về sự tương thích

của các thiết bị Android, giúp đồng nhất quy trình kiểm tra và đảm bảo sự tươngthích giữa các công nghệ và thiết bị khác nhau.

- Đáng tin cậy: CTS được áp dụng rộng rãi trong cả cộng đồng phát triển Androidvà các nhà sản xuất thiết bị, do đó bộ kiểm tra này đã được kiểm chứng và xácminh rất kỹ lưỡng Điều này làm cho CTS trở thành một tiêu chuẩn đáng tin cậyđể kiểm tra sự tương thích của các thiết bị Android.

- Kiểm tra tự động: CTS là một bộ kiểm tra tự động, giúp rút ngắn thời gian và côngsức cho việc kiểm tra sự tương thích của các thiết bị Android Điều này giúp tiếtkiệm thời gian và tiền bạc cho các công ty và nhà sản xuất thiết bị Android.

2.1.1.6.Nhược điểm

- Chỉ kiểm tra tương thích phần cứng và phần mềm cơ bản: Mặc dù CTS giúp xácđịnh sự tương thích giữa các thiết bị Android và ứng dụng Android cơ bản, nhưngnó không kiểm tra các tính năng và chức năng đặc biệt của các thiết bị cụ thể.Điều này có thể dẫn đến việc các tính năng đặc biệt không hoạt động đúng trên cácthiết bị.

- Giới hạn kiểm tra: CTS chỉ kiểm tra các yêu cầu tối thiểu của tương thích Androidvà không kiểm tra tính năng hoặc hiệu suất của các thiết bị Android Do đó, việcsử dụng CTS không đảm bảo rằng các thiết bị Android đạt tiêu chuẩn cao về hiệusuất hoặc tính năng.

- Cần kiểm tra bổ sung: Mặc dù CTS có thể cung cấp một số thông tin về sự tươngthích của các thiết bị Android, nhưng nó không thể kiểm tra hoàn toàn mọi khíacạnh của sự tương thích, chẳng hạn như: khả năng tương thích với thiết bị bênngoài, tuỳ chỉnh giao diện người dùng, quản lý quyền truy cập và bảo mật,…

2.1.2 Phương pháp kiểm thử mờ (Fuzz)2.1.2.1.Khái niệm

- Kiểm thử Fuzz là một phương pháp kiểm thử hộp đen hiệu quả, chuyên dùng để pháthiện lỗi bảo mật quan trọng trong sản phẩm mà các phương pháp kiểm tra thôngthường thường không thể phát hiện Phương thức của kiểm thử Fuzz là cố ý nhập các

dữ liệu ngẫu nhiên không hợp lệ để gây ra các điều kiện lỗi hoặc làm cho phần mềmgặp lỗi

- Vì là một phương pháp kiểm thử hộp đen, nên kiểm thử Fuzz không đòi hỏi truy cậpvào mã nguồn, cho phép nó nhanh chóng phát hiện lỗi và tránh việc phải xem xét mãnguồn

- Kiểm thử Fuzz về cơ bản cũng giống như các kỹ thuât kiểm thử phần mềm khác, tuynhiên nó đươc sử dung để phát hiện ra một loạt các vấn đề như là lỗi mã hóa, lỗ hổngbảo mât giống như kịch bản hóa trang web chéo (Cross Site Scripting - XSS), tràn bộđệm (Buffer Overflow), từ chối dich vu ̣ (DoS), chèn câu truy vấn (SQL Injection).

Hình 6 Mô hình kiểm thử Fuzz

- Các chương trình và framework được sử dụng để triển khai kiểm thử Fuzz hoặc thực hiện kiểm thử Fuzz được gọi là Fuzzer Phụ thuộc vào môi trường và ứng dụng cụ thểcần kiểm tra, người ta có nhiều phương án khác nhau để xây dựng bộ kiểm thử Fuzz.

2.1.2.2.Quy trình thực hiện

Hình 7 Các giai đoạn của kiểm thử Fuzz

a) Xác định hệ thống muc ̣ tiêu (Identify Target System)

Các mục tiêu được đánh giá có nguy cơ rủi ro cao gồm:

- Các lỗ hổng do lỗi của người lập trình hệ thống: SQL đơn ánh, mã nguồn đơn ánh,kịch bản hóa trang web chéo, chuyển hướng URL … Hoặc các lỗi do việc cấu hìnhhệ thống không an toàn như để đường dẫn vào trang quản trị hệ thống là mặc định, tàikhoản mặc định…

- Các ứng dụng nhận dữ liệu qua mạng - có khả năng bị tổn hại từ xa vì tạo điều kiệncho việc thực thi mã từ xa để tạo ra các chương trình độc hại (virus, worm …).

- Các ứng dụng chạy ở mức ưu đãi cao hơn so với thông thường - gây chú ý cho kẻtấn công thực thi mã ở mức độ đặc quyền cao hơn, được gọi là leo thang đặc quyền.

- Các ứng dụng xử lý thông tin có giá trị - loại ứng dụng này thu hút kẻ tấn công phávỡ các điều khiển, sự toàn vẹn, tin cậy của ứng dựng để lấy dữ liệu có giá trị.

- Các ứng dụng xử lý thông tin cá nhân – kẻ tấn công có thể lấy dữ liệu cá nhân có giátrị để dùng cho mục đích riêng không hợp pháp (ví dụ: Windows Explorer, WindowRegistry, tập tin đa phương tiện, tài liệu văn phòng, các tập tin cấu hình).

b) Xác định đầu vào (Identify Inputs)

Một số bộ kiểm thử Fuzz đã được tạo ra để phục vụ cho nhiều loại đầu vào Cáclớp đầu vào ứng với các bộ kiểm thử Fuzz phổ biến như sau:

- Đối số dòng lệnh

- Các biến môi trường (ShareFuzz)- Các ứng dụng Web (WebFuzz)- Các định dạng tệp tin (FileFuzz)- Các giao thức mạng (SPIKE)- Bộ nhớ

- Các đối tượng COM (COMRaider)

c) Sinh dữ liệu kiểm thử Fuzz(Generate Fuzzed Data)

Mục đích của một bộ kiểm thử Fuzz là để kiểm tra sự tồn tại của lỗ hổng bảo mật cóthể truy cập thông qua đầu vào trong các ứng dụng phần mềm Do đó dữ liệu sinh ratrong kiểm thử Fuzz phải đạt được những yêu cầu sau:

- Tạo ra dữ liệu thử nghiệm ở các mức độ khác nhau, đảm bảo thỏa mãn điều kiện đầuvào của ứng dụng.

- Dữ liệu đầu vào được tạo ra có thể có dạng tệp tin nhị phân (Binary files), tệptin văn bản (Text files) được sử dụng lặp đi lặp lại trong quá trình kiểm tra

- Việc tạo ra dữ liệu kiểm thử với nhiều ca kiểm thử lặp đi lặp lại để bắt lỗi khi chạychương trình.

d) Thực hiện các ca kiểm thử sử dụng dữ liệu Fuzz(Execute test using fuzz data)

Trong giai đoạn này, các bộ kiểm thử Fuzz thực hiện phần lớn các chức năng của các cách tiếp cận nêu trên nhưng bằng các giải pháp đặc biệt để tự động hóa quá trình xử lý kiểm thử.

Đối tượng tiếp cận của kiểm thử Fuzz bao gồm: - Số(số nguyên dương, số âm, số thực )

- Ký tự (urls, đầu vào dòng lệnh)- Siêu dữ liệu

- Các chuỗi nhị phân, đinh dạng tệp tin(.pdf, png, wav, mpg…)- Các giao thức mạng(http, SOAP, SNMP…)

- Các giao diên đầu I/O , các dòng lệnh tùy chọn, nhập/ xuất, các biểu mẫu, nội dung hay yêu cầu do người dùng tạo ra,…

Cách tiếp cận chung cho kiểm thử Fuzz là :

- Sinh tập dữ liệu giá trị nguy hiểm (còn được gọi là fuzz vectors) ứng với từng loại đầuvào cụ thể, các lỗ hổng, các định dạng tệp tin, mã nguồn, các giao thức hoăc ̣ tổ hợp của các dữ liệu này.

- Chèn thêm mã thực thi vào mã máy của chương trình.

- Phân tích hoạt động của chương trình trong quá trình thực thi.

e) Giám sát hành vi hệ thống(Monitor System Behavior)

Trong giai đoạn này, các bộ kiểm thử Fuzz không chỉ phát hiện lỗ hổng thông quaquá trình kiểm thử, mà còn phải xác định một cách rõ ràng những lỗi đã được phát hiện.Điều này đặc biệt quan trọng trong việc phân tích và tạo báo cáo về các lỗi Để tạo ra mộtbáo cáo lỗi đầy đủ và dễ hiểu, yêu cầu có hiểu biết sâu rộng về cách mà ứng dụng xử lýthông tin Quá trình này có thể được tích hợp tự động vào quá trình phân loại lỗi.

f) Đăng lỗi

Sau khi một hoặc một số lỗi phần mềm đã được xác định, các bộ kiểm thử Fuzz gửi mộtdanh sách các lỗi này tới đội ngũ phát triển để họ có thể sửa chữa chúng.

2.1.2.3.Các lỗi được phát hiện hiện bởi phương pháp Fuzz

- Lỗi khẳng định và rò rỉ bộ nhớ: Phương pháp này thường được sử dụng cho các ứngdụng lớn nơi các lỗi ảnh hưởng đến an toàn của bộ nhớ, điều này là một lỗ hổngnghiêm trọng

- Dữ liệu đầu vào không hợp lệ: Trong kiểm thử Fuzz, các trình tạo dữ liệu đầu vàokhông hợp lệ được sử dụng để tạo ra một đầu vào không hợp lệ được sử dụng để kiểmtra các quy trình xử lý lỗi, và điều này quan trọng đối với phần mềm không kiểm soátđầu vào của nó Kiểm thử Fuzz đơn giản có thể được biết đến như một cách để tựđộng hóa kiểm thử âm tính

- Lỗi về tính đúng đắn: Kiểm thử Fuzz cũng có thể được sử dụng để phát hiện một sốloại lỗi về "tính đúng đắn" như việc hỏng cơ sở dữ liệu, kết quả tìm kiếm kém,

2.1.2.4.Ưu điểm

- Kiểm thử Fuzz cung cấp một cái nhìn tổng quan về chất lượng của hệ thống và phầnmềm mục tiêu Sử dụng kiểm thử Fuzz, bạn có thể đánh giá dễ dàng tính mạnh mẽ vàtình hình rủi ro bảo mật của hệ thống và phần mềm đang được kiểm thử

- Kiểm thử Fuzz là phương pháp chính được các hacker xấu dùng để tìm lỗi phầnmềm Sử dụng nó trong chương trình bảo mật của bạn giúp bạn ngăn ngừa khỏi việclợi dụng các lỗ hổng từ các lỗi chưa biết đến (zero-day exploits) và các điểm yếutrong hệ thống của bạn

- Kiểm thử Fuzz có overhead thấp về cả chi phí và thời gian Một khi một trình tạo dữliệu đầu vào (fuzzer) đã được thiết lập, nó có thể tự mình tìm kiếm lỗi mà không cầncan thiệp thủ công hoặc con người và có thể tiếp tục làm điều đó trong thời gian cầnthiết

- Kiểm thử Fuzz giúp phát hiện lỗi mà thông qua các phương pháp kiểm thử truyềnthống hoặc kiểm tra thủ công thông thường không thể phát hiện được

2.1.2.5.Nhược điểm

- Các trình tạo dữ liệu đầu vào có thể không tìm thấy tất cả các lỗi, đặc biệt nếu nhữnglỗi này không gây ra sự cố hoàn toàn của chương trình, hoặc nếu các lỗi chỉ xảy ratrong điều kiện cụ thể, định rõ và rất cụ thể

- Kiểm thử Fuzz không cung cấp nhiều kiến thức về hoạt động nội bộ của các phầnmềm vì nó là kiểm thử hộp đen.

- Các chương trình phần mềm có đầu vào phức tạp yêu cầu các trình tạo dữ liệu đầuvào thông minh và tiên tiến có khả năng cung cấp độ bao phủ kiểm thử toàn diện cầnthiết để bảo vệ phần mềm.

2.1.3 Phương pháp kiểm thử Monkey2.1.3.1.Khái niệm

- Kiểm thử Monkey là một loại kỹ thuật kiểm thử hộp đen bằng cách tạo ra các đầu vàongẫu nhiên, độc lập Kết quả đầu ra được so sánh với thông số kỹ thuật của phầnmềm để xác minh rằng kết quả kiểm tra đạt hay không đạt.

2.1.3.2.Phân loạia) Smart monkey tests

Kiểm thử Smart monkey thường được nhận dạng bới các đặc tính dưới đây:

- Có ý tưởng ngắn gọn về ứng dụng hoặc hệ thống.

- Người thử nghiệm biết họ đang thử nghiệm ở đâu và điều này sẽ dẫn đến đâu.

- Biết được khả năng của hệ thống.

- Tập trung vào phá huỷ hệ thống

- Báo lỗi khi tìm thấy

* Một số smart monkeys được coi là “brilliant monkey” Lúc này người thử nghiệm cókiến thức nâng cao về cả chức năng của ứng dụng và kiến thức nghiệp vụ; thực hiện kiểmthử từ góc độ của người dùng và có thể ước tính được xác xuất xảy ra các lỗi nhất định.

b) Dumb monkey tests

Kiểm thử Dumb monkey thường được nhận dạng bới các đặc tính dưới đây:

- Không có ý tưởng về ứng dụng hoặc hệ thống.

- Không biết giá trị đầu vào hoặc hành vi là hợp lệ hay không

- Không biết khả năng của hệ thống cũng như là quy trình của ứng dụng

- Có thể tìm thấy ít lỗi hơn kiểm thử Smart monkey nhưng cũng có thể tìm thấy nhữnglỗi quan trọng mà Smart monkey khó bắt được.

2.1.3.3.Quy trình thực hiện

Hình 8 Quy trình thực hiện của kiểm thử Monkey

Vì kiểm thử Monkey là một kiểm thử ngẫu nên quy trình của nó bao gồm những bước sau:

- Bước 1: Xác định miền đầu vào

- Bước 2: Chọn các đầu vào một cách ngẫu nhiên/độc lập từ miền đầu vào

- Bước 3: Sử dụng các đầu vào này để kiểm tra hệ thống và tạo một bộ kiểm thử ngẫu nhiên

- Bước 4: Phân tích và so sánh kết quả kiểm thử với đặc tả phần mềm

- Bước 5: Nếu báo cáo kiểm thử thất bại, thực hiện các hành động cần thiết.

2.1.3.4.Ưu điểm

- Tìm thấy loại Bug mới: Tester có thể thực hiện những testcase ngoài kịch bản đã nêu,do đó có thể cung cấp loại Bug mới đang tồn tại trên hệ thống.

- Việc thiết lập thử nghiệm khỉ rất dễ dàng, do đó phù hợp với mọi ứng dụng.

- Kiểm thử Smart monkey nếu được thiết lập đúng cách với một mô hình trạng thái chính xác, có thể thực sự tốt trong việc tìm ra nhiều loại lỗi khác nhau.

- Ghi và Phát lại là giải pháp nhẹ cho tự động hóa kiểm tra Giá trị của nó nổi bật nhấtđối với các nhóm đang chuyển từ chủ yếu kiểm tra thủ công sang bao gồm một số tựđộng hóa để tăng tốc quá trình kiểm tra và giúp tích hợp nó sớm hơn vào vòng đờiphát triển phần mềm.

- Kiểm thử ghi và phát lại có thể là một cách tuyệt vời để bắt đầu nỗ lực tự động hóacủa bạn, nhưng quan trọng là phải chọn một công cụ phù hợp với cả nhu cầu hiện tạivà tương lai của bạn.

Đảm bảo rằng điều kiện cần thiết và các thành phần hệ thống liên quan đã được càiđặt và hoạt động đúng.

- Bước 3 - Ghi lại dữ liệu và hành vi: Thực hiện kiểm thử ban đầu bằng cách ghi lại cáchành vi và dữ liệu trong quá trình kiểm thử Các công cụ quay video hoặc ghi lại cáchành động của người dùng và các sự kiện liên quan được sử dụng để lưu trữ thôngtin.

- Bước 4 - Phát lại dữ liệu và hành vi: Sử dụng dữ liệu và hành vi đã được ghi lại đểphát lại quá trình kiểm thử Đảm bảo rằng các hành động và dữ liệu được phát lại mộtcách chính xác và có thể được tái tạo.

- Bước 5 - Kiểm thử tự động: Sử dụng các công cụ kiểm thử tự động để kiểm tra tínhđúng đắn và ổn định của hệ thống Các công cụ này giúp tự động hóa quá trình kiểmthử và đánh giá kết quả.

- Bước 6 - Xem xét và phân tích kết quả: Xem xét kết quả kiểm thử, phân tích và đánhgiá hiệu suất, tính ổn định và các vấn đề khác mà hệ thống có thể gặp phải Đưa raphản hồi và tương tác với đội phát triển để cải thiện và khắc phục các vấn đề đượctìm thấy.

- Bước 7 - Lập báo cáo: Lập báo cáo kết quả kiểm thử, bao gồm mô tả quá trình kiểmthử, kết quả đo lường và đánh giá, vấn đề và phản hồi Báo cáo này sẽ giúp cung cấpthông tin cho nhóm phát triển và quản lý hệ thống để đưa ra quyết định và cải tiến.- Bước 8 - Lặp lại quá trình kiểm thử: Nếu cần thiết, quá trình kiểm thử ghi và phát lại

có thể được lặp lại để xác định và khắc phục thêm các vấn đề mới hoặc các vấn đề

chưa được giải quyết trong lần kiểm thử trước 2.1.4.3.Ưu điểm

- Dễ dàng để bắt đầu và sử dụng cho tất cả mọi người

 Nhiều công cụ kiểm thử hiện nay có tính năng ghi và phát lại dưới dạng tính năngtích hợp sẵn và sẵn sàng để sử dụng Bạn không cần phải mất thời gian thiết lậpkhung thử nghiệm.

 Mọi người trong nhóm của bạn có thể ghi lại các bài kiểm thử đơn giản sau khixem một vài hướng dẫn ngắn Vì vậy, những người kiểm thử thủ công hoặc thậmchí các vai trò như quản lý sản phẩm, nhà thiết kế, nhà tiếp thị và những ngườikhông có nền tảng về lập trình cũng có thể tham gia kiểm thử bằng cách ghi lại cácbài kiểm thử.

- Kiểm tra nhanh và chính xác các yếu tố giao diện người dùng: Người dùng có thể ghilại tương tác của mình với giao diện người dùng và sau đó phát lại chúng để đảm bảokết quả như mong đợi Điều này giúp kiểm tra nhiều tình huống và đảm bảo rằng giaodiện người dùng hoạt động như dự kiến một cách dễ dàng

- Khả năng tái sử dụng: Nó cho phép chúng ta tạo các test scripts có thể được tái sửdụng trong tương lai, làm cho quá trình kiểm tra trở nên hiệu quả và tiết kiệm chi phíhơn.

2.1.4.4.Nhược điểm

- Khi giao diện người dùng của một ứng dụng thay đổi thường xuyên, các kiểm thử đãđược ghi trước đó sẽ không hoạt động Nếu không biết cách cập nhật test scripts, bạnsẽ phải ghi lại các bài kiểm thử Cách tiếp cận “chỉ ghi lại” này có thể mất rất nhiềuthời gian, làm giảm hiệu quả thử nghiệm của bạn.

- Ngay cả khi bạn biết cách cập nhật test scripts, bạn vẫn phải thực hiện rất nhiều thaotác bảo trì thủ công Bạn sẽ cần duy trì các đối tượng kiểm thử và chỉnh sửa các bướckiểm thử như thay đổi thông tin thành phần, thêm nhiều hành động tùy chỉnh hơn đểgiữ cho các bài kiểm thử được ghi ổn định với việc kiểm thử chấp nhận người dùngthay đổi thường xuyên.

- Ghi và phát lại là một cách tốt để bắt đầu với kiểm thử tự động, tuy nhiên, khi các dựán trở nên lớn hơn và phức tạp hơn, có thể có các lựa chọn những phương pháp khác.Để bao phủ các tình huống kiểm thử phức tạp hơn, cần có sự hiểu biết về lập trình vàkhả năng chỉnh sửa hoặc tạo nhanh các test scripts mới.

2.1.5 Phương pháp kiểm thử dựa trên mô hình (Model based)2.1.5.1.Khái niệm

- Kiểm thử dựa trên mô hình là một kỹ thuật kiểm thử phần mềm trong đó các trườnghợp kiểm thử được tạo ra từ một mô hình mô tả các khía cạnh chức năng của hệthống được kiểm thử.

- Đây là một phương pháp kiểm thử phần mềm mới sử dụng cách triển khai thứ cấp,nhẹ nhàng, tiết kiệm thời gian để xây dựng phần mềm được gọi là mô hình Phươngpháp kiểm thử này có thể áp dụng cho cả kiểm thử phần cứng và phần mềm.

- Mô hình dưới đây giải thích về cách tiếp cận đơn giản của việc viết một bài thơ trongnotepad và các hành động có thể liên quan đến trong từng bước Đối với mỗi hànhđộng như là bắt đầu, nhập nội dung bài thơ, lưu lại, các ca kiểm thử sẽ được sinh ravà đầu ra sẽ được xác minh.

Hình 9 Mô hı̀nh sinh ca kiểm thử chương trình viết môt bài thơ trong notepad

2.1.5.2.Phân loại

Có hai hı̀nh thức kiểm thử dưa trên mô hình:

- Offline/ a priori: Sinh ra các bô ̣kiểm thử trước khi thưc thi chúng Bô ̣kiểm thử chı́nhlà tập hợp của các ca kiểm thử.

- Online/ on-the-fly: Sinh ra các bộ kiểm thử ngay trong khi thực thi kiểm thử.

2.1.5.3.Các mô hình khác nhau trong kiểm thửa) Máy trạng thái hữu hạn(FSM)

- Mô hình này giúp người thử nghiệm đánh giá kết quả phụ thuộc vào dữ liệu đầu vàođược chọn Sự kết hợp khác nhau của các đầu vào có thể dẫn đến trạng thái tươngứng của hệ thống.

- Hệ thống sẽ có trạng thái cụ thể và trạng thái hiện tại, được điều chỉnh bởi một tậphợp đầu vào do người kiểm thử viên đưa ra.

Hình 10 Máy trạng thái thể hiện trạng thái của 1 bài báo trên trang tin tức

Ở ví dụ trên: Ta có draft, in review, published là các trạng thái của bài viết Trongkhi đó review, approve, reject, unpublish là các sự kiện (event) Các sự kiện này phát

sinh khi nhận các đầu vào như click lên button, … Các sự kiện này gây ra việc chuyểntrạng thái (ví dụ từ Draft -> In review), gọi là quá trình chuyển đổi (transition)

b) Biểu đồ trạng thái

Nó là phần mở rộng của máy trạng thái hữu hạn và có thể được sử dụng cho các hệthống thời gian thực và phức tạp Biểu đồ trạng thái được sử dụng để mô tả các hành vikhác nhau của hệ thống Nó có một số trạng thái xác định Hành vi của hệ thống đượcphân tích và thể hiện dưới dạng các sự kiện cho từng trạng thái.

Hình 11 Mô hình biểu đồ trạng thái hê ̣thống quản lý lỗi

Ở ví dụ trên: Các lỗi được đưa lên một công cụ quản lý lỗi với trạng thái “Mới”.Một khi lỗi được sửa bởi lập trình viên, nó sẽ chuyển sang “Fixed” Nếu lỗi vẫn chưađược sửa, trạng thái của nó sẽ chuyển sang “Re-open”

c) Ngôn ngữ mô hình hóa thống nhất (UML)

- Ngôn ngữ mô hình hóa thống nhất (UML) là một ngôn ngữ mô hình gồm các ký hiệuđồ họa mà các phương pháp hướng đối tượng sử dụng để thiết kế các hệ thống thôngtin một cách nhanh chóng.

- UML cung cấp ký hiệu chuẩn cho nhiều loại sơ đồ, có thể tạm chia thành ba nhómchính: sơ đồ hành vi, sơ đồ tương tác và sơ đồ cấu trúc.

2.1.5.4.Quy trình thực hiện

Hình 12 Các giai đoạn của kiểm thử dựa trên mô hình

- Từ các yêu cầu ban đầu, thực hiện bước đầu tiên trong chuỗi các hoạt động kiểm thửlà mô hình hóa (1) Đồng thời với hoạt động mô hình hóa là việc xác định các tiêu chílựa chọn các trường hợp kiểm thử (2), từ đó sinh ra các tài liệu đặc tả cho các ca kiểmthử (3).

- Từ hoạt động mô hình hóa các tài liệu đặc tả cho các ca kiểm thử sẽ giúp sinh ra cácca kiểm thử (4) Việc sinh ra các ca kiểm thử trừu tượng sẽ được thực hiện hoàn toàntự động từ mô hình bằng cách sử dụng các công cụ kiểm thử dựa trên mô hình.

- Bước tiếp theo trong chuỗi hoạt động là việc chuyển đổi các ca kiểm thử trừu tượngnày thành các kịch bản kiểm thử (Test script) có thể thực thi được bởi các công cụkiểm thử tự động.

- Và cuối cùng, sau khi đã có các kịch bản kiểm thử tự động, các công cụ kiểm thử sẽthực thi việc kiểm thử ứng dụng (SUI) theo các kịch bản đã được xây dựng đó.

2.1.5.5.Ưu điểm

- Cho phép kiểm thử toàn diện ứng dụng.

- Hoàn toàn phù hợp cho kiểm tra chức năng, tính chính xác của ứng dụng.- Các mô hình có thể dễ dàng đáp ứng các thay đổi từ ứng dụng.

2.1.5.6.Nhược điểm

- Yêu cầu phải có một mô hình và tài liệu đặc tả cho các ca kiểm thử.

- Việc sinh các ca kiểm thử phải được điều khiển một cách thích hợp để các ca kiểm thử được sinh ra có khối lượng có thể quản lý được.

- Một thay đổi nhỏ từ mô hình có thể dẫn đến toàn bộ bộ kiểm thử bị thay đổi.

2.2.Các công cụ hỗ trợ kiểm thử phần mềm Android2.2.1 Selendroid

2.2.1.1.Khái niệm

Selendroid là một framework tự động hóa kiểm thử sáng tạo được sử dụng để kiểm thử các ứng dụng di động Android native và hybrid Framework Selendroid hoạt động dựa trên giao diện người dùng của ứng dụng di động hoặc web, và các bài kiểm thử được viết bằng client API của Selenium 2 Selendroid là một framework kiểm thử di động linh hoạt có thể được sử dụng cả trên giả lập và thiết bị Android thực với tùy chọn tích hợp vào Selenium Grid như một node để kiểm thử song song và mở rộng.

2.2.1.2.Đặc điểm nổi bật

- Tương tác với nhiều thiết bị và giả lập cùng một lúc - Khả năng ghi lại chất lượng cao

- Tự động hóa bài kiểm thử mà không cần chuyển sang ứng dụng khác

- Có thể sử dụng trên cả giả lập và thiết bị thực, cũng như là một node trong Selenium Grid

- Hỗ trợ Selenium như một ngôn ngữ script

- Hỗ trợ các ngôn ngữ tương thích với WebDriver như Java, C#, Perl - Hỗ trợ tất cả các phiên bản Android

- Hoạt động cả trên giả lập và thiết bị thực

- Hoạt động trên ứng dụng native, hybrid và dựa trên web

- Selendroid hỗ trợ nhận diện đối tượng bằng các thuộc tính đối tượng

- Selendroid hỗ trợ kết nối nóng của thiết bị phần cứng

- Tích hợp đầy đủ như một node vào Selenium Grid để mở rộng và kiểm thử song song

- Hỗ trợ nhiều phiên bản API mục tiêu Android (từ 10 đến 19)

- Trình kiểm tra tích hợp sẵn để đơn giản hóa việc phát triển các trường hợp kiểm thử - Selendroid có thể được mở rộng vào thời gian chạy với các phần mở rộng của riêng

- Yêu cầu máy tính cấu hình cao

- Không thể sử dụng trên các hệ thống có RAM dưới 4 GB

2.2.2 Robotium2.2.2.1.Khái niệm

- Robotium là một framework kiểm thử mã nguồn mở cho việc viết các bài kiểm thử tựđộng loại hộp xám (gray-box testing) cho các ứng dụng Android Với sự hỗ trợ củaRobotium, các nhà phát triển bài kiểm thử có thể viết các kịch bản kiểm thử chứcnăng, hệ thống và chấp nhận, bao gồm nhiều hoạt động trên Android.

- Robotium là một khung kiểm thử tự động mã nguồn mở, được sử dụng để kiểm thửhộp đen mạnh mẽ và đặc biệt là các ứng dụng Android

2.2.2.2.Đặc điểm nổi bật

- Ngôn ngữ script sử dụng: Java

- API đơn giản để tạo ra các bài kiểm thử nhanh chóng

- Được sử dụng để viết các bài kiểm thử chức năng, hệ thống và chấp nhận của người dùng

- Hỗ trợ thực thi trên các giả lập Android và thiết bị thực - Hỗ trợ tích hợp CI/CD (Maven, Gradle hoặc ANT)

- Độ dễ đọc của các bài kiểm thử được cải thiện đáng kể so với các bài kiểm thử thôngthường trên Android