CƠ SỞ LÝ THUYẾT VÀ CÔNG NGHỆ
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)
Mỗi chiếc điện thoại sử dụng Android trước khi đến với tay người dùng phải vượt qua tất cả các ca kiểm thử sự tương thích của phần cứng và phần mềm thông qua bộ các ca kiểm thử của Google phát hành song song với từng phiên bản hệ điều hành Android. Quá trình bao gồm các bước sau:
Hình 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 Test Suite 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ột bộ 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
Phiên bản Android Phiên bản CTS
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ử.
- 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ản Android Các API được sử dụng trong từng phiên bản của hệ điều hành này bao gồm tên API, các tham số của nó và miêu tả chi tiết hoạt động của API đó. 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ành android 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ểm thử.
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ết quả 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 tin cts-tradefed chứa tất cả các lệnh điều khiển thực thi của phương pháp CTS Nó chính là giá trị cốt lõi của phương pháp CTS Và được cài đặt các câu lệnh command để hỗ trợ trong quá trình kiểm thử.
- Với Android 6.0 hoặc thấp hơn, hãy sử dụng CTS v1 command console Còn với Android 7.0 trở lên, hãy sử dụng CTS v2 command console Cả 2 CTS v1 và CTS v2 đề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ụng phổ biến) và help all(hiển thị danh sách đầy đủ các câu lệnh) Để có thể biết thêm chi tiết về các câu lệnh có thể tham khảo tại [2]
- 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ương thí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 Android và các nhà sản xuất thiết bị, do đó bộ kiểm tra này đã được kiểm chứng và xác minh 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ông sứ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ết kiệ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.
- 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ưng nó 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ác thiế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 Android và 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ệc sử dụng CTS không đảm bảo rằng các thiết bị Android đạt tiêu chuẩn cao về hiệu suất hoặc tính năng.
Các công cụ hỗ trợ kiểm thử phần mềm Android
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.
- 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
- Hoàn toàn tương thích với JSON Wire Protocol/Selenium 3 Ready
- Không cần sửa đổi ứng dụng được kiểm thử để tự động hóa
- Kiểm thử web di động bằng ứng dụng webview Android tích hợp sẵn
- Cùng một khái niệm cho việc tự động hóa các ứng dụng native hoặc hybrid
- Các yếu tố giao diện người dùng có thể được tìm thấy bằng các loại trình tìm kiếm khác nhau
- Hỗ trợ các cử chỉ: API Tương tác Người dùng Nâng cao
- Các giả lập hiện tại sẽ được khởi động 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 bạn
- Selendroid có thể tương tác với nhiều thiết bị Android (giả lập hoặc thiết bị phần cứng) cùng một lúc.
- Framework này áp dụng cùng một khái niệm để tự động hóa các ứng dụng native hoặc hybrid
- Mọi yếu tố giao diện người dùng có thể dễ dàng được tìm thấy bằng cách sử dụng các loại trình tìm kiếm khác nhau trong Selendroid.
- Tốc độ kiểm thử chậm
- 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
- 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ủa Robotium, 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ức nă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
- 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ễ viết, mã code ngắn gọn Cần ít thời gian để viết các bài kiểm thử chắc chắn
- Bạn có thể phát triển các bài kiểm thử mạnh mẽ, chỉ cần hiểu biết tối thiểu về ứng dụng cần kiểm thử
- Cung cấp API để tương tác trực tiếp với các điều khiển giao diện người dùng trong ứng dụng
- Framework tự động xử lý nhiều hoạt động trên Android Tích hợp mượt mà của framework có thể được thực hiện với Ant hoặc Maven, giúp thêm framework vào quy trình tự động hóa của dự án
- Độ 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ông thường trên Android
- Thời gian và độ trễ tự động
- Tự động theo dõi Hoạt động hiện tại.
- Tự động tìm kiếm các Views
- Tự động đưa ra các quyết định của riêng nó (ví dụ: Khi cuộn, v.v.)
- Không cần sửa đổi trên nền tảng Android
- Việc thực thi bài kiểm thử nhanh chóng
- Các bài kiểm thử mạnh mẽ hơn nhờ việc liên kết thời gian chạy với các thành phần GUI
- Tích hợp mượt mà với Maven hoặc Ant.
- Robotium không thể xử lý các thành phần Flash hoặc Web
- Robotium chỉ xử lý một ứng dụng trong cùng một thời điểm
- Robotium không thể mô phỏng việc nhấn vào bàn phím mềm bằng Robotium (cần sử dụng ‘enterText()’ để nhập văn bản vào trường EditText)
- Robotium không thể tương tác với Thông báo Thanh trạng thái - nghĩa là, kéo xuống khu vực Thông báo và nhấp vào một Thông báo cụ thể
- Có thể chậm, đặc biệt khi chạy trên các thiết bị cũ.
- Appium thường được sử dụng trong lĩnh vực tự động hóa kiểm thử phần mềm, để giúp xác định liệu chức năng của một ứng dụng cụ thể có hoạt động như mong đợi không Khác với các loại kiểm thử phần mềm khác, tự động hóa giao diện người dùng (UI) cho phép người kiểm thử viết mã để thực hiện các kịch bản của người dùng trên giao diện thực tế của ứng dụng, mô phỏng càng gần càng tốt những gì xảy ra trong thế giới thực, đồng thời khai thác các lợi ích của tự động hóa, bao gồm tốc độ, quy mô và sự nhất quán
- Appium nhằm cung cấp một bộ công cụ hỗ trợ loại tự động hóa này một cách chuẩn mực trên bất kỳ số nền tảng nào Hầu hết các nền tảng đều đi kèm với các công cụ cho phép tự động hóa giao diện người dùng ở mức độ nào đó, nhưng những công cụ này thường là cụ thể cho từng nền tảng và đòi hỏi kiến thức chuyên biệt cũng như kinh nghiệm với ngôn ngữ lập trình cụ thể và các bộ công cụ Appium cố gắng thống nhất tất cả các công nghệ tự động hóa này dưới một giao diện ổn định duy nhất, có thể truy cập thông qua hầu hết các ngôn ngữ lập trình phổ biến nhất (có thể viết kịch bản Appium bằng Java, Python, Ruby, JS, và nhiều ngôn ngữ khác).
- Kế thừa sự phổ biến từ Selenium, Appium là một framework kiểm thử di động nổi tiếng và được ưa chuộng Sử dụng giao thức WebDriver, Appium cho phép người dùng kiểm thử các ứng dụng native, hybrid và web di động.
- Ngôn ngữ script đa dạng: Java, Ruby, Python, PHP, JavaScript và C#
- Dễ áp dụng với những người có kinh nghiệm với Selenium
- Có thể tích hợp với các framework và nền tảng kiểm thử khác
- Loại bỏ nhu cầu biên dịch lại ứng dụng, mã nguồn hoặc các framework khác
- Cho phép tái sử dụng bài kiểm thử và mã nguồn giữa iOS, Android và Windows
- Khả năng tương thích với nhiều ngôn ngữ lập trình: Appium sử dụng giao thức mobile JSON wire cho việc giao tiếp giữa máy chủ và máy khách Điều này cho phép các nhà phát triển và nhóm kiểm thử chất lượng (QA) viết kịch bản kiểm thử bằng ngôn ngữ lập trình ưa thích của họ (Java, Ruby, PHP, Python và các ngôn ngữ khác). Các nhà phát triển có thể viết các bài kiểm thử với các công cụ ưa thích của họ bằng bất kỳ ngôn ngữ tương thích với WebDriver nào như Java, Objective-C và JavaScript Do đó, các bài kiểm thử không phụ thuộc vào ngôn ngữ lập trình cụ thể, và người dùng không cần cài đặt thêm bất kỳ phần mềm nào khác trên thiết bị di động để hỗ trợ Appium.
- Tích hợp mượt mà Appium có thể hoạt động hiệu quả với các ứng dụng bên ngoài khác như Selenium Grid và Selenium WebDriver Hơn nữa, nó không giới hạn lựa chọn công nghệ của bạn, vì nó hỗ trợ nhiều công cụ Kiểm thử bằng Appium cho phép các nhà phát triển chọn framework cơ bản cho việc kiểm thử đơn vị, như XCTest hoặc XCUITest.
- Kiểm thử đa nền tảng: Appium không chỉ hỗ trợ cho Android mà còn cho ứng dụng iOS của bạn Framework tự động hóa kiểm thử này là đa nền tảng, cho phép bạn chạy kiểm thử trên nhiều nền tảng di động Quan trọng hơn, các nhà phát triển có thể tái sử dụng mã nguồn qua các bộ kiểm thử cho cả Android và iOS.
- Tiêu thụ bộ nhớ thấp: Kiến trúc của Appium hoạt động như một proxy giữa bộ công cụ tự động hóa và máy kiểm thử, thường giúp tiêu thụ bộ nhớ thấp.
- Cài đặt phức tạp: Do mô hình máy khách-máy chủ mà Appium hoạt động, các nhà phát triển cần có sự thành thạo vượt trội trong lập trình để cấu hình máy chủ Appium. Điều này làm cho việc tự động hóa với Appium trở nên phức tạp hơn.
- Bài kiểm thử không ổn định: Trong nhiều tình huống, Appium thiếu độ chính xác trong các bài kiểm thử Các bài kiểm thử của Appium có thể qua hoặc không qua với cùng một cấu hình, gây trở ngại cho quy trình làm việc mượt mà của các kỹ sư.
- Tốc độ chậm: Appium thường chậm do kiến trúc của nó Trong nhiều tình huống, nó mất thời gian đáng kể để khởi động máy chủ, và sau đó, việc giao tiếp mỗi hành động yêu cầu thời gian đáng kể vì kiến trúc của nó Vì vậy, rất thường, các nhà phát triển phải đối mặt với sự trì hoãn trong chu kỳ kiểm thử.
- Vấn đề với việc xác định vị trí các yếu tố: Một nhược điểm lớn của Appium là công cụ gặp khó khăn trong việc xác định vị trí các yếu tố và nhận diện hình ảnh Nó không thể tự động thực hiện điều đó Vì vậy, nhóm của bạn sẽ phải nhập vị trí của các yếu tố một cách thủ công.
- Không hỗ trợ các phiên bản cũ hơn của Android: Một nhược điểm chính của việc tự động hóa kiểm thử Android bằng Appium là framework không hỗ trợ bất kỳ phiên bản Android nào cũ hơn 4.2 Điều này hạn chế nhà phát triển khỏi việc thực hiện kiểm thử trên nhiều thiết bị, làm giảm phạm vi kiểm thử Tuy nhiên, vấn đề này có thể được giải quyết bằng cách kết hợp Appium với các framework khác như Selendroid.
2.2.4 Công cụ theo dõi lỗi Bugzilla
So sánh các công cụ
2.3.1 So sánh giữa Appium và Selenium
Hình 13 So sánh giữa Appium và Selenium
2.3.1.1 Thời điểm nên sử dụng Appium
- Không giống như Selendroid, Appium hỗ trợ kiểm thử ứng dụng iOS cùng vớiAndroid Appium cũng mang lại trải nghiệm dễ dàng hơn so với Selendroid bằng việc không cần sử dụng SDK và loại bỏ nhu cầu biên dịch lại ứng dụng để kiểm thử Điều này cũng có nghĩa là ứng dụng người kiểm thử là ứng dụng người kiểm thử phát hành mà không cần phải sửa đổi gì chỉ để kiểm thử Appium có công cụ kiểm tra giao diện người dùng riêng của mình, nhưng cũng có thể sử dụng công cụ Android Studio, uiautomatorviewer
- Mặc dù Appium không thể được sử dụng để kiểm thử ứng dụng cho các API Android thấp hơn 17, nhưng nó đi kèm với chế độ Selendroid để hỗ trợ việc đó Selendroid được gói kèm trong Appium từ phiên bản 1.2 trở đi, và trong chế độ Selendroid của Appium, nó có thể giúp kiểm thử các ứng dụng trên các phiên bản Android cũ hơn, nhưng có một số hạn chế - như thiếu khả năng xác định các yếu tố giao diện người dùng như Selendroid, hoặc khả năng sử dụng cùng một kịch bản trong cả hai chế độ mà không cần sửa đổi Những hạn chế này có thể được vượt qua bằng cách sử dụng Selendroid như một công cụ độc lập, riêng biệt với Appium
2.3.1.2 Thời điểm nên sử dụng Selendroid
- Selendroid là một lựa chọn tốt nếu bạn chỉ đang nghĩ đến việc phát triển ứng dụng Android Điểm bán hàng chính của nó là tính tương thích ngược; nó hỗ trợ Android API từ 10 (Android 2.3.3) đến API 19 (Android 4.4)
- Cũng đáng chú ý là Selendroid có chứa một công cụ Inspector có thể kiểm tra các yếu tố giao diện người dùng của ứng dụng đang được kiểm thử Mặc dù bạn cũng có thể tìm thấy các yếu tố giao diện người dùng trong Appium, nhưng ưu điểm mà Selendroid có so với Appium là Selendroid có thể tìm thấy các yếu tố giao diện người dùng trên các phiên bản Android cũ hơn
- Selendroid còn có một số tính năng khác Trong quá trình kiểm thử, thiết bị có thể được cắm hoặc rút ra mà không làm gián đoạn bài kiểm thử đang chạy, còn được gọi là "hot plugging." Điều này được hỗ trợ bởi khả năng tương tác của Selendroid với nhiều thiết bị Android cùng một lúc, bao gồm cả giả lập và thiết bị phần cứng, giúp người kiểm thử tiết kiệm rất nhiều thời gian trong quá trình này Selendroid cũng hoàn toàn tích hợp với Selenium Grid, hữu ích cho việc mở rộng và kiểm thử song song.
2.3.2 So sánh giữa Appium và Robotium
- Appium là một nền tảng chéo và hỗ trợ iOS, Android và Firefox OS Tester có thể sử dụng Appium để kiểm thử ứng dụng của họ trên các nền tảng được chọn một cách dễ dàng Appium hỗ trợ cả trên thiết bị thực sự và giả lập của Android và iOS Vì vậy, nó dễ dàng cho việc kiểm thử trên giả lập hoặc máy ảo nếu không có thiết bị sẵn có, trong khi Robotium hỗ trợ kiểm thử ứng dụng Android Appium hỗ trợ gần như tất cả các phiên bản và phiên bản con của hệ điều hành di động của Google Các bài kiểm thử có thể được thực hiện trên AVD, Android Virtual Device, hoặc trên thiết bị thực sự.
- Robotium chỉ hỗ trợ Android trong khi Appium hỗ trợ cả iOS và Firefox OS cùng với Android.
- Hầu hết các công ty phát triển ứng dụng native, hybrid, và web di động Sử dụng Appium, chúng ta có thể kiểm thử ứng dụng native và hybrid trên các thiết bị iOS và Android Ngoài ra, chúng ta có thể kiểm tra cách các ứng dụng web di động hoạt động trên các trình duyệt web khác nhau như Chrome, Safari và Firefox, trong khi
- Robotium chỉ hỗ trợ kiểm thử các ứng dụng native và hybrid; nó không hỗ trợ kiểm thử ứng dụng web di động.
- Robotium chỉ giới hạn cho ứng dụng di động trên Android trong khi Appium có thể được sử dụng để kiểm thử ứng dụng web di động cùng với các ứng dụng di động native và hybrid.
- Appium hỗ trợ một số ngôn ngữ lập trình Nó cho phép người kiểm thử viết các bài kiểm thử bằng bất kỳ ngôn ngữ tương thích với WebDriver nào bao gồm Java, PHP, C#, Ruby, Python, Perl, Objective-C, và JavaScript với Node.js Sử dụng Appium, chúng ta có thể viết các kịch bản kiểm thử độc lập với nền tảng bằng ngôn ngữ lập trình ưa thích của mình Sau đó, chúng ta có thể tái sử dụng cùng một kịch bản kiểm thử để kiểm thử ứng dụng trên nhiều nền tảng khác nhau,
- Trong khi đó, Robotium được thiết kế đặc biệt cho kiểm thử ứng dụng Android Do đó, nó không cho phép người kiểm thử viết các bài kiểm thử bằng cách chọn từ một tập hợp các ngôn ngữ lập trình và trở nên khó khăn khi viết các kịch bản kiểm thử độc lập với nền tảng Nó chỉ hỗ trợ một ngôn ngữ lập trình, tức là chỉ Java.
PHÂN TÍCH THIẾT KẾ
Ứng dụng áp dụng phương pháp Monkey Testing
- Bước 1: Xác định hệ thống mục tiêu: truyền các tham số về gói và danh mục của ứng dụng cần thực thi kiểm thử vào trong lệnh chạy.
- Bước 2: Xác định đầu vào: lựa chọn và thiết lập tỉ lệ các sự kiện mong muốn sinh ra trong quá trình thực thi kiểm thử
- Bước 3: Sinh dữ liệu kiểm thử: Monkey sẽ tiến hành việc sinh các đầu vào kiểm thử là các sự kiện tương ứng với yêu cầu được đưa ra.
- Bước 4: Thực thi kiểm thử: Các lệnh ADB này được truyền tới thiết bị kiểm thử.
- Bước 5: Giám sát hành vi hệ thống: các sự kiện sinh ra đều được lưu lại dưới dạng các tệp tin log
- Bước 6: Đăng lỗi và phân tích
Bảng 2 So sánh các loại của Monkey Test
Dumb Monkey Smart Monkey Brilliant Monkey Định nghĩa
Trong kiểm thử Dumb monkey, các người kiểm thử không có kiến thức về sản phẩm hoặc ứng dụng
Họ không có ý tưởng về đầu vào của mình liệu có hợp lệ hay không Đây còn được biết đến là 'Khỉ ngu'
Phương pháp này cũng có thể cung cấp kết quả nhanh chóng, thực hiện các bài kiểm tra thông qua việc nhập vào ứng dụng và cũng không yêu cầu kế hoạch
Trong kiểm thử Smart monkey, người kiểm thử có ý tưởng tốt về hệ thống hoặc ứng dụng Họ biết chính xác về chức năng của sản phẩm Họ cung cấp các đầu vào hợp lệ để thực hiện kiểm thử Ngoài ra,
Trong kiểm thử Brilliant monkey, người kiểm thử có ý tưởng khá rõ về cách người dùng sử dụng sản phẩm Họ tiến hành kiểm thử của mình dưới góc nhìn của người dùng. trước của quá trình kiểm thử Kiểm thử Dumb monkey có thể tìm thấy ít lỗi hơn so với loại kiểm thử khác, nhưng có thể vô tình phát hiện ra những lỗi quan trọng mà khó bắt gặp.
Người kiểm thử phải chỉ định một người kiểm thử không biết về ứng dụng để kiểm thử ứng dụng Hành vi của người kiểm thử nên giống như một người dùng không có kiến thức kỹ thuật đang cố gắng sử dụng ứng dụng.
Người kiểm thử tập trung vào việc phá vỡ ứng dụng, và khi xảy ra lỗi, họ sẽ báo cáo và ghi lại lỗi.
Các người kiểm thử có ý tưởng khá rõ về cách người dùng sử dụng sản phẩm.
Một ví dụ về kiểm thử Smart monkey là kiểm thử tải, được sử dụng để xác định hành vi của ứng dụng dưới điều kiện tải thông thường và dự kiến.
Người kiểm thử có kiến thức về lĩnh vực Mạng Nơ- ron được yêu cầu nhập dữ liệu ngẫu nhiên để kiểm thử một ứng dụng Trí tuệ Nhân tạo Do đó, việc kiểm thử ứng dụng bởi một người có kiến thức về lĩnh vực sẽ có lợi ích vì họ biết đầu vào từ quan điểm của lĩnh vực đó.
3.1.1.3 So sánh Monkey Testing và một số phương pháp tương tự
Bảng 3 So sánh các phương pháo kiểm thử ngẫu nhiên
Monkey Testing Ad hoc Testing Gorilla testing
Phân loại Thực hiện ngẫu nhiên mà không sử dụng bất kỳ ca kiểm thử nào
Thực hiện ngẫu nhiên mà không sử dụng bất kỳ ca kiểm thử nào
Không thực hiện theo định nghĩa trước và cũng không thực hiện ngẫu nhiên.
Mục đích Để kiểm tra xem hệ thống có gặp sự cố không. Để kiểm tra chức năng của hệ thống bằng cách chia hệ thống ngẫu nhiên thành các phần nhỏ. Để kiểm tra xem module có hoạt động đúng cách hay không.
Mô tả Người kiểm thử cần suy nghĩ từ góc nhìn của người dùng, có thể bao gồm việc nhấp hoặc gõ ngẫu nhiên chỉ để xem liệu hệ thống có gặp sự cố hay không.
Người kiểm thử có thể kiểm tra những điều mà họ cảm thấy cần thiết Dựa trên kiến thức của người kiểm thử.
Người kiểm thử phải kiểm tra một cách kỹ lưỡng thông qua cùng một quy trình lặp đi lặp lại. Được tiến hành
Bất kỳ ai mà không có kiến thức về phần mềm hoặc thậm chí cả máy tính Trong các công ty, điều này được tiến hành bởi các nhóm kiểm thử.
Một lập trình viên có kiến thức chi tiết về phần mềm và hệ thống.
Một nhà phát triển hoặc người kiểm thử duy nhất, có thể có hoặc không có kiến thức về phần mềm Khi thực hiện kiểm thử đầy đủ, thường là bởi các nhóm đảm bảo chất lượng.
- Monkey là một công cụ dòng lệnh có thể chạy trên bất kỳ máy ảo hoặc thiết bị nào Nó tạo ra một loạt các sự kiện người dùng giả mạo và ngẫu nhiên, gửi chúng vào hệ thống Điều này tương đương với việc thực hiện một loạt thao tác kiểm thử chặt chẽ đối với phần mềm ứng dụng mà bạn đang phát triển.
- Monkey bao gồm một số tùy chọn, nhưng chúng chia thành bốn danh mục chính:
Các tùy chọn cấu hình cơ bản, chẳng hạn như đặt số lần phát sự kiện.
Các ràng buộc về hoạt động, chẳng hạn như hạn chế thử nghiệm trong một gói duy nhất.
Các loại và tần suất sự kiện.
Các tùy chọn gỡ lỗi.
3.1.2.2 Sử dụng cơ bản Monkey Test
- Vì Monkey chạy trong môi trường trình mô phỏng/thiết bị, nên bạn phải chạy nó từ một màn hình trong môi trường đó Bạn có thể thực hiện việc này bằng cách đặt adb shell vào từng lệnh hoặc nhập trực tiếp vào vỏ và nhập lệnh Monkey.
Hình 14 Nhập lệnh Monkey
- Mô hình trạng thái hoạt động của Monkey Test:
Hình 15 Hình ảnh mô tả trạng thái của quá trình kiểm thử
- Mô tả chi tiết quy trình
Chuẩn Bị: Thiết lập môi trường kiểm thử và mô phỏng các sự kiện ngẫu nhiên trên ứng dụng o Các câu lệnh sử dụng:
Thực Hiện Kiểm Thử: Sử dụng công cụ Monkey Test để tạo ra chuỗi sự kiện ngẫu nhiên và thu thập dữ liệu o Các câu lệnh sử dụng:
adb shell monkey -p com.android.calculator2 -v 2000 > output/monkey.log sleep 10
Thu Thập Dữ Liệu: Ghi lại các màn hình quan trọng và thông tin chi tiết trong quá trình kiểm thử o Các câu lệnh sử dụng:
Bắt đầu ghi hình: adb shell am start -n com.kkbox.sqa.recorder/.MainActivity -a android.intent.action.RUN -d START
Kết thúc ghi hình: adb shell am start -n com.kkbox.sqa.recorder/.MainActivity -a android.intent.action.RUN -d STOP
Chụp màn hình: adb shell screencap /sdcard/monkey.png
Xuất Báo Cáo: Tạo bug report và video testing cho quá trình kiểm thử. o Các câu lệnh sử dụng:
adb bugreport > bugreport.log # Backward Compatibility (Android < 7.0)
adb pull /sdcard/monkey.png monkey.png
adb pull /sdcard/recorder.mp4 monkey.mp4
Ứng dụng áp dụng phương pháp Play and record
- Công cụ này ghi lại các tương tác này dưới dạng một chuỗi các hành động của người dùng (các bước kiểm thử) và các phản hồi của hệ thống, có thể được phát lại sau này để tự động thực hiện lại kịch bản kiểm thử.
- Dưới đây là cách hoạt động thông thường của các công cụ ghi và phát lại kiểm thử:
Ghi lại Kiểm thử: Người dùng tương tác với ứng dụng như khi thực hiện kiểm thử thủ công Công cụ ghi lại mỗi hành động được thực hiện bởi người kiểm thử, như các cú nhấp chuột, phím nhập, việc gửi biểu mẫu và các tương tác khác của người dùng Nó ghi lại chuỗi các sự kiện và xây dựng một kịch bản kiểm thử dựa trên những tương tác này.
Phát lại: Trong giai đoạn phát lại, kịch bản kiểm thử được ghi lại được thực hiện tự động trên ứng dụng Công cụ sao chép lại các hành động được ghi lại trong giai đoạn ghi lại và xác minh các phản hồi từ ứng dụng so với các kết quả dự kiến.
- Công cụ ghi và phát lại kiểm thử thường được sử dụng cho các ứng dụng web và kiểm thử giao diện người dùng đồ họa (GUI) Chúng đặc biệt hữu ích đối với kỹ sư QA có thể không có kỹ năng lập trình mạnh mẽ hoặc để tạo kịch bản kiểm thử nhanh chóng trong giai đoạn đầu của quá trình kiểm thử.
Hình 16 Usecase chi tiết cho nghiệp vụ Quản lý hóa đơn
- Sơ đồ hoạt động của Thêm kịch bản
Hình 17 Sơ đồ hoạt động của Thêm kịch bản
- Sơ đồ hoạt động của Sửa kịch bản
Hình 18 Sơ đồ hoạt động của Sửa kịch bản
- Sơ đồ hoạt động của Xóa kịch bản
Hình 19 Sơ đồ hoạt động của Xóa kịch bản
- Sơ đồ hoạt động của Chạy kịch bản
Hình 20 Sơ đồ hoạt động của Chạy kịch bản
- Sơ đồ hoạt động của Thêm hành động
Hình 21 Sơ đồ hoạt động của Thêm hành động
- Sơ đồ hoạt động của Xóa hành động
Hình 22 Sơ đồ hoạt động của Xóa hành động
- Sơ đồ hoạt động của Tìm kiếm kịch bản
Hình 23 Sơ đồ hoạt động của Tìm kiếm kịch bản
CÀI ĐẶT PHẦN MỀM
Ứng dụng Monkey Testing
Hình 24 Hình màn hình trước khi kiểm thử
- Bug Report: Tạo file báo cáo về các lỗi phát sinh trong quá trình kiểm thử Cung cấp chi tiết về các lỗi và cách tái hiện chúng.
Hình 25 Hình ảnh báo cáo lỗi
- Video Testing: Tạo video ghi lại quá trình kiểm thử để hỗ trợ việc phân tích và xác minh kết quả kiểm thử.
Hình 26 Hình ảnh video ghi hình trong quá trình kiểm thử
Ứng dụng Play and record
Bảng 4 Danh sách màn hình
STT Màn hình Loại màn hình Chức năng
1 Màn hình Trang chủ Màn hình chính Giới thiệu thông tin phòng khám
2 Màn hình Thêm kịch bản Màn hình nhập liệu Giới thiệu thông tin bác sĩ tại phòng khám
3 Màn hình Thêm hoạt động “Click” Màn hình nhập liệu Giới thiệu dịch vụ tại phòng khám
4 Màn hình Thêm hoạt động “Swipe” Màn hình nhập liệu Giới thiệu chi nhánh và thông tin liên lạc của phòng khám
5 Sửa kịch bản Màn hình nhập liệu Cho phép khách hang để lại thông tin để đặt lịch
6 Sửa hành động Màn hình nhập liệu Cho phép nhập thông tin tài khoản cần đăng ký
7 Tìm kiếm kịch bản Màn hình nhập liệu Đăng nhập để được cấp quyền truy cập các màn hình khác dựa vào phân quyền
4.2.2 Mô tả chi tiết màn hình
Hình 27 Màn hình trang chủ
4.2.2.2 Màn hình Thêm kịch bản kiểm chứng
Hình 28 Màn hình Thêm kịch bản kiểm chứng
4.2.2.3 Màn hình Thêm tác động “Click” trong kịch bản
Hình 29 Màn hình Thêm tác động “Click” trong kịch bản
4.2.2.4 Màn hình Thêm tác động “Swipe” trong kịch bản
Hình 30 Màn hình Thêm tác động “Swipe” trong kịch bản
4.2.2.5 Màn hình Sửa kịch bản
Hình 31 Màn hình Sửa kịch bản
4.2.2.6 Màn hình Sửa hành động
Hình 32 Màn hình Sửa hành động
4.2.2.7 Màn hình Tìm kiếm kịch bản
Hình 33 Màn hình Tìm kiếm kịch bản
