Kiểm tra ngắt trong ứng dụng di động
⚡ Tóm tắt thông minh
Kiểm thử gián đoạn (Interrupt Testing) kiểm tra cách ứng dụng di động hoạt động khi có cuộc gọi, báo thức, thông báo hoặc mất kết nối mạng, và liệu ứng dụng có trở lại trạng thái chính xác trước đó sau khi sự gián đoạn kết thúc hay không.
Kiểm tra ngắt là gì?
Kiểm tra ngắt Kiểm thử ứng dụng di động là một nhánh của lĩnh vực kiểm thử ứng dụng di động, nghiên cứu cách ứng dụng phản ứng với sự gián đoạn và khôi phục về trạng thái trước đó. Sự gián đoạn đến từ bên ngoài ứng dụng — hệ điều hành, phần cứng hoặc một ứng dụng khác — và bài kiểm thử xác minh rằng không có dữ liệu, trạng thái màn hình hoặc giao dịch đang diễn ra nào bị mất khi quyền điều khiển được trả lại.
Kiểm thử ngắt (Interrupt Testing) áp dụng cho mọi loại ứng dụng — web, di động, ứng dụng độc lập, v.v. Sự đa dạng của thiết bị, mạng và cấu hình khiến nó trở nên quan trọng hơn nhiều đối với... di động các ứng dụng này dành cho nhiều ứng dụng hơn so với các ứng dụng khác.
Tại sao bạn cần Kiểm tra ngắt?
Điều gần như luôn xảy ra khi bạn tham gia một cuộc họp là gì? Bạn bị gián đoạn, đúng không? Khi điều đó xảy ra, một số người thậm chí không hề chớp mắt, một số cần một phút để lấy lại bình tĩnh, và một số thì hoàn toàn mất tập trung. Nói một cách đơn giản, Kiểm thử Gián đoạn (Interrupt Testing) cố gắng tìm ra hành vi nào mà ứng dụng của bạn thể hiện.
Hãy tạm gác mọi cách diễn đạt sang một bên và xem xét một tình huống thực tế khác. Giả sử bạn có một chiếc đèn pin và bật nó lên. Pin hết, điều này làm gián đoạn trạng thái hoạt động hiện tại của đèn. Thay pin và khởi động lại. Đèn pin sẽ hoạt động bình thường trở lại. Đây là trường hợp sử dụng. Một lĩnh vực kiểm thử tập trung vào việc liệu điều này có xảy ra hay không được gọi là Kiểm thử Gián đoạn (Interrupt Testing).
Lý lẽ kinh doanh rất đơn giản. Sự gián đoạn xảy ra vào thời điểm tồi tệ nhất — giữa chừng quá trình thanh toán, giữa chừng quá trình tải lên, giữa chừng quá trình điền biểu mẫu — và người dùng mất dữ liệu đã nhập hiếm khi thử lại. Các sự cố khi tiếp tục, màn hình trống, giao dịch trùng lặp và mất dữ liệu nhập vào biểu mẫu đều là những lỗi chỉ bộc lộ khi có sự gián đoạn, đó là lý do tại sao chúng vẫn tồn tại ngay cả khi quá trình xử lý diễn ra bình thường mà không có bất kỳ sự gián đoạn nào.
Loại gián đoạn trong ứng dụng di động
Các sự gián đoạn được chia thành một vài nhóm quen thuộc, được tóm tắt trong hình minh họa bên dưới.
Chúng ta đều quen thuộc với những sự gián đoạn thường gặp. Dưới đây là một vài ví dụ:
- Pin yếu
- Pin đầy — khi đang sạc
- Cuộc gọi điện thoại đến
- SMS đến
- Thông báo đến từ một ứng dụng di động khác
- Đã cắm để sạc
- Đã cắm sạc
- Tắt thiết bị
- Thông báo cập nhật ứng dụng
- báo động
- Mất kết nối mạng
- Phục hồi kết nối mạng
Danh sách này không đầy đủ nhưng bao gồm các tình huống phổ biến nhất. Một cách thực tế để sắp xếp nó là theo nguồn gốc: các sự kiện phụ thuộc vào thiết bị như pin và sạc pin, các sự kiện do người dùng khởi tạo như trả lời cuộc gọi hoặc chuyển đổi ứng dụng, và các sự kiện bên ngoài như mất tín hiệu trong thang máy hoặc đường hầm.
Giải quyết trong trường hợp gián đoạn
Hành vi dự kiến trong trường hợp xảy ra những gián đoạn này là một trong bốn hành vi sau:
- Chạy ở chế độ nền: Sự gián đoạn xảy ra trong khi ứng dụng tạm thời ngừng hoạt động. Ứng dụng sẽ giành lại quyền kiểm soát sau khi sự gián đoạn kết thúc. Ví dụ, một cuộc gọi điện thoại hoặc cuộc gọi FaceTime mà bạn tham gia trong khi đang đọc sách điện tử trên iBooks (hoặc một ứng dụng tương tự). Khi người dùng trả lời điện thoại, iBooks sẽ đợi cho đến khi cuộc gọi kết thúc và sau đó tiếp tục hoạt động khi cuộc gọi kết thúc.
- Hiển thị thông báo: Thông báo biến mất và bạn tiếp tục làm việc như bình thường. Một thông báo "Đã nhận SMS" xuất hiện ở đầu trang. Người dùng không để ý đến nó và tiếp tục sử dụng ứng dụng như bình thường. Các thông báo khác của ứng dụng di động, chẳng hạn như yêu cầu kết bạn mới trên Facebook hoặc tin nhắn WhatsApp, cũng thuộc loại này. Nhưng nếu người dùng quyết định đọc tin nhắn, hành vi được mô tả ở điểm 1 sẽ diễn ra. Nếu bỏ qua thông báo, trạng thái của ứng dụng không thay đổi.
- Kêu gọi hành động: Bạn phải tắt hoặc tạm dừng báo thức trước khi tiếp tục làm việc. Điều tương tự cũng áp dụng cho các thông báo cập nhật ứng dụng. Bạn phải hủy hoặc chấp nhận các thay đổi trước khi tiếp tục. Một ví dụ khác là cảnh báo pin yếu — bạn có thể chọn tiếp tục như bình thường hoặc chuyển sang chế độ tiết kiệm năng lượng, nếu thiết bị cho phép.
- Không có tác động: Ví dụ, khi kết nối mạng khả dụng và thiết bị của bạn kết nối với mạng đó, thì cũng không cần thiết. Ngoài ra, khi bạn cắm thiết bị vào để sạc, sẽ không có cảnh báo hay thao tác nào được thực hiện. Thiết bị có thể sẽ tự động sạc trong khi bạn tiếp tục sử dụng ứng dụng.
Do đó, tùy thuộc vào sự gián đoạn mà bạn đang kiểm tra, hãy hiểu hành vi và xem liệu ứng dụng của bạn có đáp ứng được sự gián đoạn đó hay không. Ngoài ra, hành vi được mô tả ở trên không nhất thiết phải giống nhau đối với tất cả các ứng dụng và thiết bị. Hãy chắc chắn tìm hiểu các chi tiết cụ thể cho ứng dụng di động của bạn.
Ngắt quá trình kiểm thử bằng các trường hợp kiểm thử có kết quả mong đợi.
Khi giải pháp mong muốn được thống nhất, mỗi sự gián đoạn sẽ trở thành một trường hợp thử nghiệm thông thường với một yếu tố kích hoạt, một hành động và một kết quả có thể kiểm chứng. Bảng dưới đây cho thấy bốn giải pháp trên được chuyển đổi thành các kịch bản cụ thể như thế nào.
| Gián đoạn | Kịch bản thử nghiệm | Kết quả mong đợi |
| Cuộc gọi điện thoại đến | Khi biểu mẫu mới chỉ điền được một nửa, hãy thực hiện cuộc gọi, sau đó kết thúc cuộc gọi. | Ứng dụng sẽ chuyển sang chế độ nền và tiếp tục hoạt động trên cùng màn hình đó, dữ liệu đã nhập vẫn được giữ nguyên. |
| Tin nhắn SMS đến hoặc thông báo đẩy | Gửi tin nhắn trong khi video hoặc quá trình tải lên đang diễn ra và bỏ qua biểu ngữ. | Biểu ngữ xuất hiện rồi biến mất; trạng thái ứng dụng không thay đổi. |
| báo động | Cho phép báo động theo lịch trình kích hoạt trong phiên làm việc hiện tại và sau đó tắt nó đi. | Chức năng báo động yêu cầu người dùng thực hiện hành động trước, sau đó ứng dụng sẽ tiếp tục hoạt động từ điểm đã dừng lại. |
| Cảnh báo pin yếu | Xả hết pin thiết bị đến ngưỡng cảnh báo trong quá trình giao dịch. | Cảnh báo được hiển thị, giao dịch không bị hủy và chế độ tiết kiệm pin không làm hỏng màn hình. |
| Mất kết nối mạng | Ngắt kết nối giữa chừng khi đang thực hiện yêu cầu, sau đó khôi phục lại. | Thông báo rõ ràng được hiển thị, không xảy ra sự cố và yêu cầu được hoàn tất hoặc báo lỗi an toàn khi khôi phục. |
| Sạc khi cắm điện hoặc không cắm điện | Kết nối và ngắt kết nối bộ sạc trong khi đang hoạt động. | Không có ảnh hưởng gì — ứng dụng vẫn hoạt động bình thường mà không có thay đổi nào đáng kể. |
| Thông báo cập nhật ứng dụng | Hiển thị thông báo cập nhật trong khi ứng dụng đang được sử dụng. | Người dùng có thể hủy hoặc chấp nhận, và màn hình hiển thị bên dưới vẫn giữ nguyên bất kể lựa chọn nào. |
Hãy giữ một dòng cho mỗi lần gián đoạn trên mỗi màn hình quan trọng, thay vì một dòng cho mỗi lần gián đoạn trên toàn bộ ứng dụng. Màn hình thanh toán, màn hình đăng nhập và một biểu mẫu dài đều gặp lỗi khác nhau, và một trường hợp chung duy nhất sẽ che giấu điều đó.
Bây giờ chúng ta đã hiểu Kiểm tra ngắt là gì và những gì cần xác thực khi tiến hành nó, đã đến lúc nói về cách thực hiện nó.
Cách thực hiện kiểm tra ngắt
Hãy xem tuyên bố này: iBooks phải chạy ở chế độ nền khi người dùng nhận được cuộc gọi đến.
Bạn có cho rằng đây không phải là một yêu cầu chức năng của ứng dụng iBooks không? Tôi thì nghĩ là có.
Vì vậy, Kiểm tra ngắt là một tập hợp con của Thử nghiệm chức năng Đối với ứng dụng di động, để thực hiện Kiểm thử Gián đoạn, bạn tuân theo các khung và công cụ kiểm thử ứng dụng di động thông thường. Kỹ năng của người kiểm thử là phải hình dung ra các kịch bản này. Sau khi hoàn thành, bạn thiết kế các trường hợp kiểm thử và thực hiện chúng theo cách tương tự như bất kỳ bài kiểm thử nào khác.
Trên thực tế, chuỗi thao tác này ngắn và có thể lặp lại:
- Liệt kê các hành trình quan trọng của người dùng — đăng nhập, thanh toán, tải lên, điền biểu mẫu dài, phát lại đa phương tiện.
- Hãy lập bản đồ cho mọi sự gián đoạn có thể xảy ra từ danh sách trên vào từng hành trình.
- Hãy thống nhất độ phân giải mong muốn cho từng cặp sản phẩm với chủ sở hữu sản phẩm, vì không có giá trị mặc định chung.
- Hãy thực hiện thao tác gián đoạn vào thời điểm rủi ro nhất, chứ không phải lúc rảnh rỗi, rồi sau đó tiếp tục.
- Kiểm tra trạng thái, dữ liệu, phiên và bộ nhớ sau khi khôi phục, chứ không chỉ đơn thuần là xác nhận ứng dụng vẫn đang mở.
Để biết thêm thông tin về lĩnh vực rộng hơn, vui lòng xem phần... Thử nghiệm di động hướng dẫn và các trường hợp ví dụ trong Thử nghiệm ứng dụng dành cho thiết bị di động.
Các công cụ và kỹ thuật để mô phỏng sự gián đoạn
Các tình huống nêu trên cần được tạo ra theo yêu cầu chứ không phải chờ đợi, và mỗi nền tảng đều cung cấp cách thức để thực hiện điều đó.
- Android Các điều khiển mở rộng của trình giả lập: Bảng điều khiển bên của trình giả lập mô phỏng cuộc gọi đến, tin nhắn SMS, mức pin và trạng thái sạc, cũng như cường độ tín hiệu di động, do đó hầu hết các thông báo lỗi có thể được hiển thị mà không cần thiết bị cầm tay thứ hai.
- Trình giả lập iOS và Xcode: Trạng thái kết nối và phần cứng có thể được thay đổi từ trình giả lập và cài đặt thiết bị, trong khi thiết bị vật lý được ghép nối sẽ xử lý các tình huống cuộc gọi mà trình giả lập không thể tạo ra.
- Một thiết bị vật lý thứ hai: Việc gọi điện hoặc nhắn tin đến thiết bị cần kiểm tra từ một thiết bị cầm tay khác vẫn là cách chính xác nhất để tái tạo sự gián đoạn thực tế, đặc biệt là trong các trường hợp cần độ chính xác về thời gian.
- Cài đặt thiết bị: Chế độ máy bay, bật/tắt Wi-Fi, chế độ Không làm phiền, chế độ tiết kiệm pin và báo thức theo lịch trình giúp khắc phục sự cố kết nối và gián đoạn nguồn điện trên phần cứng thực tế.
- Các khung tự động hóa: Cùng một hệ thống tự động hóa được sử dụng cho phần còn lại của bộ chức năng có thể điều khiển ứng dụng trước và sau khi bị gián đoạn, do đó việc kiểm tra khả năng tiếp tục được thực hiện tự động thay vì dựa vào cảm nhận chủ quan.
- Đám mây thiết bị thực: Hệ thống máy chủ ảo (hosted device farm) mở rộng phạm vi phủ sóng trên nhiều nhà sản xuất và phiên bản hệ điều hành, điều này rất quan trọng vì xử lý gián đoạn là một trong những lĩnh vực mà sự tùy chỉnh của nhà cung cấp khác biệt nhiều nhất.
Bất kể cơ chế nào, hãy ghi lại chính xác thời điểm gián đoạn trong trường hợp thử nghiệm. "Gián đoạn trong quá trình tải lên" và "gián đoạn sau khi tải lên" là hai bài kiểm tra khác nhau với các chế độ lỗi khác nhau.
Các phương pháp tốt nhất để kiểm thử gián đoạn
Một vài thói quen nhất định sẽ tạo nên sự khác biệt giữa một bộ lệnh ngắt hữu ích và một bộ lệnh chỉ mang tính hình thức.
- Ngắt lời vào thời điểm tồi tệ nhất: Target Ngay khi một giao dịch được thực hiện hoặc một tập tin được ghi, đó là thời điểm trạng thái dễ bị tổn thương nhất.
- Hãy kiểm tra sơ yếu lý lịch, chứ không phải sự gián đoạn: Lỗi này hầu như luôn xuất hiện sau khi quyền điều khiển được khôi phục, vì vậy các khẳng định nên được đưa ra trên màn hình đã được khôi phục.
- Bao gồm cả hai hướng thay đổi của mạng: Mất kết nối và khôi phục kết nối là hai trường hợp riêng biệt, và trường hợp thứ hai thường bị bỏ qua hơn.
- Thay đổi thời lượng: Một cảnh báo hai giây và một cuộc gọi mười phút sẽ đẩy ứng dụng đi qua các giai đoạn vòng đời khác nhau, bao gồm cả việc bị loại bỏ khỏi bộ nhớ.
- Trải rộng trên nhiều phiên bản hệ điều hành và phần cứng cấp thấp: Việc loại bỏ ứng dụng chạy ngầm diễn ra mạnh mẽ hơn nhiều trên các thiết bị có cấu hình hạn chế, điều này làm lộ ra những khiếm khuyết mà một chiếc điện thoại cao cấp đang che giấu.
- Tự động hóa các thao tác lặp đi lặp lại: Việc mất kết nối và gián đoạn pin được tự động hóa một cách mượt mà, giải phóng công sức thủ công cho các tình huống gọi điện và báo động.
- Theo dõi mức sử dụng tài nguyên cũng như trạng thái: Việc gián đoạn gây rò rỉ bộ nhớ hoặc làm hao pin khi khởi động lại là một lỗi, ngay cả khi màn hình hiển thị bình thường, điều này liên kết công việc này với... kiểm tra hiệu suất ứng dụng di động.
Kiểm tra ngắt có giống như Kiểm tra khôi phục không?
Thật tiếc là không. Kiểm tra phục hồi Xác nhận khả năng khôi phục sau sự cố. Sự gián đoạn không nhất thiết là một sự cố — nó chỉ là một sự gián đoạn đơn thuần.tracsự.
Nó giống như sự khác biệt giữa dấu phẩy và dấu chấm trong tiếng Anh. Sự khác biệt chỉ mang tính kỹ thuật, nhưng ý nghĩa thì rõ ràng. Kiểm thử phục hồi (Recovery Testing) hỏi liệu ứng dụng có thể hoạt động trở lại sau khi gặp sự cố hay không; Kiểm thử gián đoạn (Interrupt Testing) hỏi liệu có bất kỳ sự cố nào xảy ra khi một tác vụ khác được ưu tiên thực hiện hay không.
Đó là những điều cần biết để bắt đầu với Kiểm thử Ngắt quãng — một nhánh quan trọng và dễ hiểu của Kiểm thử Ứng dụng Di động.

