Biến một nhóm nhỏ điện thoại và trình mô phỏng Android thành phòng thí nghiệm thiết bị có thể lặp lại với các trạng thái bắt đầu rõ ràng, các bước kiểm tra có thể quan sát được, thời gian chờ có giới hạn, bằng chứng lỗi và quy tắc xây dựng so với mua rõ ràng.
Câu trả lời ngắn gọn: tự động hóa vòng vận hành chứ không phải kệ
Phòng thí nghiệm thiết bị Android trở nên hữu ích khi mỗi lần chạy đều bắt đầu từ một trạng thái được đặt tên, thực hiện một lần kiểm tra giới hạn, xác minh hậu điều kiện và để lại bằng chứng mà người khác có thể xem xét. Điện thoại, bộ chia USB, giá đỡ và nhãn chỉ là lớp vật lý. Tự động hóa phòng thí nghiệm thiết bị Android là lớp vận hành biến các thiết bị đó thành các hoạt động kiểm tra bản phát hành, hỗ trợ và bản địa hóa có thể lặp lại.
Nếu bạn vẫn đang chọn điện thoại, cáp, nguồn hoặc bộ lưu trữ, hãy bắt đầu vớihướng dẫn thiết lập phòng thí nghiệm thiết bị Android chi phí thấp. Bài viết này bắt đầu sau khi phần cứng đó tồn tại. Nó giải thích cách kết hợp các thiết bị thực và trình mô phỏng, xác định ma trận thử nghiệm nhỏ, tạo thẻ chạy thiết bị, đồng bộ hóa ở trạng thái có thể quan sát được, chụp ảnh màn hình và nhật ký cũng như quyết định khi nào đám mây thiết bị được lưu trữ là lựa chọn tốt hơn.
Mục tiêu không phải là thay thế các bài kiểm tra đơn vị, bài kiểm tra Compose, Espresso, UI Automator, Appium, Thiết bị được quản lý bởi Gradle hoặc Phòng thí nghiệm kiểm tra Firebase. Những công cụ đó có ranh giới khác nhau. Công cụ tự động hóa AndroidAIhữu ích nhất ở đây dưới dạng lớp quy trình công việc hiển thị để kiểm tra thiết bị thực mà người vận hành, người đánh giá QA và nhóm hỗ trợ cần hiểu.
Cung cấp các công việc khác nhau cho các thiết bị thực và trình mô phỏng
Phòng thí nghiệm thiết bị không cần thực hiện mọi thử nghiệm trên mọi thiết bị. Trình mô phỏng có khả năng tạo, đặt lại, tham số hóa và chạy song song nhanh chóng. Điện thoại thực hiển thị chương trình cơ sở của nhà cung cấp, máy ảnh vật lý, Bluetooth, lời nhắc sinh trắc học, hành vi nhiệt, hạn chế nền, gửi thông báo, trạng thái USB và các bề mặt đầu vào mà thiết bị ảo có thể không tái tạo một cách trung thực. Hãy sử dụng những khác biệt đó để phân chia trách nhiệm thay vì tranh cãi về một nền tảng chung.
| Lớp phòng thí nghiệm | Sử dụng lần đầu tốt nhất | Đừng cho rằng |
|---|---|---|
| Trình mô phỏng cục bộ | Kiểm tra khói nhanh, phạm vi bao phủ cấp API, tái tạo trạng thái sạch | Phần cứng ảo đó chứng minh hành vi cảm biến hoặc nhà cung cấp cụ thể |
| Điện thoại thật địa phương | Bằng chứng phát hành, hỗ trợ tái tạo, giao diện người dùng hệ thống, máy ảnh, Bluetooth, hành vi OEM | Đó là một mô hình đại diện cho thị trường Android |
| Thiết bị ảo được lưu trữ | Chạy song song linh hoạt và cấu hình được quản lý | Rằng mọi thử nghiệm đều cần cơ sở hạ tầng từ xa |
| Thiết bị thực được lưu trữ | Phạm vi mô hình rộng hơn mà không cần bảo trì phần cứng | Thời gian xếp hàng, quyền riêng tư và quyền truy cập tạo phẩm phù hợp với mọi quy trình công việc |
| Kiểm tra nhà phát triển hoặc khung | Xác nhận xác định gần với mã ứng dụng | Rằng một xác nhận vượt qua chứng tỏ một quy trình làm việc hoàn chỉnh có thể nhìn thấy được |
| Luồng hình ảnh có thể quan sát được | Đường dẫn hộp đen có thể lặp lại và bằng chứng thân thiện với người đánh giá | Ảnh chụp màn hình hoặc OCR đó thay thế các xác nhận ngữ nghĩa |
Mẫu khởi đầu thực tế là tầng ảo rộng và tầng vật lý hẹp. Chạy kiểm tra xác định nhanh trên các cấu hình ảo, sau đó định tuyến một gói quan trọng nhỏ qua hai hoặc ba điện thoại thực được chọn để xử lý rủi ro thực tế của khách hàng. Chỉ mở rộng khi dữ liệu lỗi cho thấy một kiểu máy, phiên bản Android, ngôn ngữ hoặc hành vi của nhà cung cấp khác thay đổi kết quả.
Xác định ma trận thiết bị với một lý do trên mỗi hàng
Phòng thí nghiệm kiểm tra Firebase mô tả ma trận thử nghiệm là sự kết hợp giữa các thiết bị đã chọn và cấu hình thử nghiệm. Ý tưởng đó cũng có hiệu quả đối với một phòng thí nghiệm địa phương, nhưng ma trận nên dựa trên rủi ro thay vì toàn diện. Mỗi hàng cần một lý do, một chủ sở hữu và một quyết định dự kiến. Một chiếc điện thoại chỉ tồn tại vì nó có sẵn sẽ âm thầm tiêu tốn thời gian sạc, đặt lại và bảo trì mà không cải thiện độ tin cậy khi phát hành.
- Giữ một đường cơ sở Android hiện tại cho lộ trình phát hành chính.
- Giữ một cấp API được hỗ trợ cũ hơn để có khả năng tương thích và nâng cấp.
- Chỉ thêm một điện thoại thực của nhà cung cấp cụ thể khi chương trình cơ sở, quyền, chính sách pin hoặc chia sẻ khách hàng của nó tạo ra rủi ro rõ rệt.
- Thêm cấu hình màn hình nhỏ hoặc tỷ lệ phông chữ cao khi bố cục và khả năng truy cập quan trọng.
- Chỉ thêm ngôn ngữ, chủ đề, hướng, mạng hoặc trạng thái tài khoản vào các kiểm tra mà kết quả có thể thay đổi theo điều kiện đó.
- Loại bỏ các hàng ma trận không còn tìm thấy lỗi khác biệt hoặc hỗ trợ phân khúc khách hàng hiện tại.
Đặt tên cho quyết định mà mỗi hàng hỗ trợ: chặn bản phát hành, thu thập bằng chứng đánh giá, tái tạo trường hợp hỗ trợ hoặc khám phá lỗi nghi ngờ dành riêng cho thiết bị. Quyết định đó kiểm soát mức độ tin cậy, sự cô lập và báo cáo của hàng. Trình chặn phát hành yêu cầu các quy tắc đặt lại và xác nhận mạnh hơn so với kiểm tra thăm dò có giám sát.
Tạo thẻ chạy trước khi viết tự động hóa
Thông số kỹ thuật hữu ích nhỏ nhất để kiểm tra trong phòng thí nghiệm là thẻ chạy. Nó ngăn chặn các giả định tiềm ẩn tồn tại trong bộ nhớ của người vận hành và mang lại cho tự động hóa một hợp đồng ổn định. Viết thẻ bằng các thuật ngữ có thể quan sát được trước khi chọn nút, bộ chọn hoặc mã khung.
| Trường thẻ chạy | Ví dụ | Tại sao nó quan trọng |
|---|---|---|
| Mục đích | Xác minh đường dẫn khói đăng nhập sau khi triển khai theo giai đoạn | Xác định quyết định mà lần chạy này hỗ trợ |
| Xây dựng bản sắc | Gói, phiên bản, cam kết, môi trường | Ngăn chặn bằng chứng được đính kèm vào bản dựng sai |
| Nhận dạng thiết bị | Model, phiên bản Android, bí danh nối tiếp, kích thước màn hình | Làm cho kết quả có thể lặp lại |
| Trạng thái bắt đầu | Ứng dụng đã dừng, đăng xuất, kết nối mạng trực tuyến, hộp thoại hệ thống đã bị xóa | Loại bỏ trạng thái ngẫu nhiên khỏi các lần chạy trước |
| Dữ liệu đầu vào | Tài khoản thử nghiệm được đặt tên và lịch thi đấu không nhạy cảm | Tách dữ liệu có thể sử dụng lại khỏi quy trình làm việc |
| Hậu điều kiện | Điểm đánh dấu màn hình chính hiển thị và trạng thái tài khoản được xác nhận | Chứng minh hành động tạo ra kết quả như mong muốn |
| Điều kiện dừng | Hộp thoại không xác định, màn hình phá hoại, thời gian chờ, thiếu mục tiêu | Ngăn chặn sự tiếp tục mù quáng |
| Bằng chứng | Ảnh chụp màn hình, trạng thái giao diện người dùng đã chọn, dấu thời gian, kết quả bước, đoạn trích nhật ký có liên quan | Cho phép người khác phân loại mà không cần chạy lại ngay lập tức |
Đừng định nghĩa thành công là một chuỗi các lần nhấn. Xác định trạng thái hiển thị hoặc trạng thái có cấu trúc phải tồn tại sau chuỗi. Bố cục giao diện người dùng thay đổi; các điều kiện sau kinh doanh bền vững hơn. Kiểm tra đăng nhập thành công vì trạng thái tài khoản dự kiến và giao diện trang chủ hiện diện chứ không phải vì tự động hóa đã chạm vào tọa độ nơi từng có nút.
Đặt lại trạng thái mà không xóa bằng chứng
Các thiết bị dùng chung bị lỗi theo những cách trông giống như lỗi ứng dụng: tài khoản cũ, sự đồng ý được lưu trong bộ nhớ đệm, cập nhật đang chờ xử lý, quyền đã thay đổi, bộ nhớ thấp, bàn phím không mong muốn, hộp thoại hệ thống mở, lớp phủ thông báo hoặc lần chạy trước đó còn sót lại giữa chừng trong quá trình thanh toán. Chỉ đặt lại trạng thái được đặt tên theo thẻ chạy và ghi lại lỗi trước khi quá trình khôi phục thay đổi nó.
- Xác định thiết bị và xây dựng trước khi chạm vào trạng thái.
- Chụp lại màn hình hiện tại khi lần chạy trước kết thúc bất ngờ.
- Đưa ứng dụng về trạng thái bắt đầu đã khai báo bằng cách sử dụng thiết lập lại ít phá hủy nhất là đủ.
- Xác nhận mạng, thời gian, bộ nhớ, hướng, ngôn ngữ, tỷ lệ phông chữ và các quyền cần thiết.
- Xác minh điểm đánh dấu trạng thái bắt đầu trước hành động kinh doanh đầu tiên.
- Cách ly thiết bị nếu thiết lập lại nhiều lần không thành công; không biến lỗi cơ sở hạ tầng thành lỗi sản phẩm.
Xóa toàn bộ không tự động an toàn hơn. Nó có thể phá hủy trạng thái chính xác cần thiết để tái tạo lỗi và thêm thời gian thiết lập để khuyến khích các nhóm bỏ qua việc kiểm tra. Giữ các hồ sơ riêng biệt cho các đường dẫn cài đặt mới, cài đặt nâng cấp, đăng nhập, đăng xuất và khôi phục tài khoản khi các trạng thái đó có những rủi ro khác nhau.
Đồng bộ hóa ở trạng thái thay vì ngủ lâu hơn
Hướng dẫn kiểm tra độ ổn định của Android cảnh báo tình trạng ngủ tùy ý vì hiệu suất thiết bị và hoạt động không đồng bộ khác nhau. Độ trễ cố định có thể quá ngắn trên điện thoại bận và chậm không cần thiết trên điện thoại nhanh. Ưu tiên chờ đợi rõ ràng cho một điều kiện có ý nghĩa, có thời gian chờ và tạo phẩm lỗi khi điều kiện đó không bao giờ xuất hiện.
- Sau khi khởi chạy ứng dụng, hãy đợi thành phần giao diện người dùng hoặc trạng thái màn hình ổn định thay vì số giây được đoán.
- Sau một lần nhấn, hãy xác minh hậu điều kiện trước khi gửi dữ liệu đầu vào tiếp theo.
- Sử dụng sự lặp lại có giới hạn cho các trạng thái thực sự cần bỏ phiếu; ghi lại quan sát cuối cùng khi hết thời gian chờ.
- Xử lý các hộp thoại cấp phép hệ thống, lời nhắc cập nhật và lớp phủ OEM dưới dạng các nhánh được đặt tên chứ không phải tiếng ồn ngẫu nhiên.
- Dừng khi trạng thái hiển thị nằm ngoài nhóm đã được phê duyệt, đặc biệt là trước khi thanh toán, xóa, đồng ý hoặc thay đổi tài khoản.
Hợp đồng LaiCai Flow hiện tại tuân theo mô hình hiển thị này: quan sát giao diện người dùng, OCR, khớp mẫu và trạng thái quan sát chụp ảnh màn hình; các nút đầu vào và con trỏ thực hiện một thao tác; các nút luồng xử lý việc chờ đợi, phân nhánh, vòng lặp giới hạn, luồng con, trả về và dừng. Việc tách biệt việc quan sát, quyết định và hành động giúp quy trình làm việc dễ dàng xem xét hơn và duy trì an toàn hơn.
Xây dựng LaiCai Flow có thể đọc được để kiểm tra trong phòng thí nghiệm
LaiCai Flow là một tính năng tự động hóa bên trong LaiCai Screen Mirroring. Để chạy trong phòng thí nghiệm thiết bị, hãy giữ Quy trình chính ở mức mà người đánh giá QA có thể đọc: chuẩn bị thiết bị, mở mục tiêu, chạy kiểm tra quan trọng, thu thập bằng chứng và hoàn tất. Đưa các chi tiết kỹ thuật gồm nhiều bước vào các luồng nhỏ thay vì hiển thị một chuỗi dài các trận đấu, lựa chọn, nhấn và chờ đợi. Hướng dẫnLaiCai Flowgiải thích cách tổ chức Cấu hình và Luồng.
- Đọc ngữ cảnh thiết bị được kết nối và chọn bí danh nối tiếp dự định; đừng cho rằng thiết bị đầu tiên là chính xác.
- Xác nhận gói và trạng thái giao diện người dùng hiện tại trước khi mở hoặc thay đổi ứng dụng.
- Sử dụng trạng thái giao diện người dùng khi thông tin trợ năng ổn định, OCR khi văn bản hiển thị là bằng chứng và chỉ khớp mẫu cho mục tiêu hình ảnh đã xác thực.
- Đặt thời gian chờ rõ ràng giữa các hành động và quan sát phụ thuộc vào màn hình sau này.
- Kiểm tra hậu điều kiện sau mỗi giai đoạn thay đổi trạng thái màn hình hoặc ứng dụng.
- Chỉ chụp ảnh màn hình hoặc ghi lại khi nó hỗ trợ quyết định xem xét được đặt tên.
- Trả về kết quả pha rõ ràng; dừng quá trình chạy khi hành động tiếp theo không được chứng minh bằng quan sát hiện tại.
Trong quá trình chuẩn bị cho hướng dẫn này, ngữ cảnh LaiCai chỉ đọc đã báo cáo 73 loại nút có sẵn và một điện thoại Samsung Android 16 được kết nối. Điều đó xác nhận hợp đồng hiện tại và đường dẫn nhận thức về thiết bị; nó không phải là một chuẩn mực hiệu suất. Xác thực ứng dụng, thiết bị, nội dung và hỗ trợ thời gian chạy của riêng bạn trước khi coi Hồ sơ là cơ sở hạ tầng phát hành.
Thu thập gói tin bị lỗi, không phải dấu chấm đỏ
Kiểm tra không thành công sẽ trả lời những gì đã chạy, nó chạy ở đâu, hệ thống quan sát thấy gì và tại sao quá trình chạy lại dừng. Phòng thí nghiệm kiểm tra Firebase hiển thị một mô hình hữu ích bằng cách trả về trạng thái thử nghiệm cùng với nhật ký, ảnh chụp màn hình và video nếu có. Phòng thí nghiệm thiết bị cục bộ cần có kỷ luật tương tự ngay cả khi việc lưu trữ của nó đơn giản hơn.
- ID chạy, dấu thời gian, phiên bản quy trình làm việc, phiên bản xây dựng và môi trường.
- Kiểu thiết bị, phiên bản Android, bí danh nối tiếp ổn định, kích thước màn hình, ngôn ngữ, chủ đề và hướng.
- Trạng thái bắt đầu, mã định danh thiết bị đầu vào và giai đoạn kinh doanh đã hoàn thành cuối cùng.
- Hậu điều kiện dự kiến và kết quả giao diện người dùng, OCR, hình ảnh hoặc khung đã chọn thực tế.
- Ảnh chụp màn hình trước khi khôi phục, chỉ ghi lại ngắn khi có chuyển động quan trọng và một đoạn trích nhật ký có liên quan được giới hạn.
- Phân loại: lỗi sản phẩm, lỗi kiểm tra, cơ sở hạ tầng thiết bị, dữ liệu, môi trường hoặc cần sự xem xét của con người.
Sử dụng tên tệp ổn định và tệp kê khai thay vì thư mục ảnh chụp màn hình không có cấu trúc. Biên tập lại dữ liệu cá nhân hoặc bí mật trước khi chia sẻ. Không tải lên toàn bộ nhật ký thiết bị khi khoảng thời gian vệ sinh ngắn xung quanh sự cố là đủ. Bằng chứng sẽ làm giảm công việc của người tiếp theo mà không tạo ra vấn đề mới về quyền riêng tư hoặc lưu giữ.
Chọn séc kiếm được thời gian sử dụng thiết bị của họ
Số phút sử dụng trên thiết bị thực rất khan hiếm vì thiết bị cần sạc, dọn dẹp, cập nhật và quyền truy cập của con người. Cung cấp chúng cho các quy trình làm việc có hành vi hiển thị hoặc vật lý quan trọng. Các ứng cử viên phù hợp đầu tiên là kiểm tra khói sau khi triển khai, đường dẫn cấp phép và giao diện người dùng hệ thống, thiết lập camera hoặc Bluetooth, luồng thông báo, bằng chứng bản địa hóa, hồi quy dành riêng cho nhà cung cấp và bản sao hỗ trợ chính xác.
Duy trì logic nghiệp vụ, phân tích cú pháp, định dạng và hoạt động của thành phần trong các thử nghiệm nhanh hơn gần với mã. Sử dụng thiết bị thực để chứng minh ranh giới mà các thử nghiệm đó không thể: bản dựng đã cài đặt, hệ điều hành, ứng dụng bên ngoài, bề mặt đầu vào, quá trình chuyển đổi mạng hoặc thành phần mà con người có thể nhìn thấy.So sánh các công cụ kiểm tra tự động hóa Androidgiúp chỉ định từng yêu cầu cho một lớp thích hợp.
Một gói quan trọng gồm năm hành trình đáng tin cậy có giá trị hơn năm mươi luồng mà không ai tin tưởng. Bắt đầu với một đường dẫn đại diện, đo lường chi phí đặt lại và phân loại, sau đó chỉ thêm phạm vi bảo hiểm khi một lần kiểm tra mới bảo vệ một quyết định phát hành, khách hàng hoặc hoạt động cụ thể.
Đo lường phòng thí nghiệm trước khi bạn mở rộng quy mô
Các nhóm thảo luận về các trang trại thiết bị tự lưu trữ liên tục quay lại cùng một thông tin đầu vào khi xây dựng so với mua: hành vi xếp hàng, đồng thời cao điểm, thời gian chờ, lỗi khởi động hoặc đặt lại, nỗ lực bảo trì và các lỗi chỉ xuất hiện trên thiết bị vật lý. Theo dõi các tín hiệu đó trong vài chu kỳ phát hành trước khi mua thêm phần cứng hoặc di chuyển mọi thứ sang đám mây.
- Xếp hàng đợi theo thời gian trong ngày và mức độ ưu tiên của quy trình làm việc.
- Việc sử dụng thiết bị và thời gian không có sẵn để sạc, cập nhật hoặc sửa chữa.
- Tỷ lệ lỗi trạng thái khởi động hoặc đặt lại theo thiết bị.
- Chạy lại do lỗi tự động hóa chứ không phải do thay đổi sản phẩm.
- Thời gian trung bình từ khi thất bại đến khi phân loại hữu ích.
- Các lỗi riêng biệt chỉ được tìm thấy trên thiết bị thực, nhà cung cấp cụ thể hoặc phiên bản Android cụ thể.
- Số phút vận hành cho mỗi lần chạy thành công và cho mỗi quy trình làm việc được duy trì.
Đây là những số liệu quản lý, không phải bảng điều khiển phù phiếm. Nếu thời gian chờ hàng đợi thấp nhưng việc bảo trì chiếm ưu thế thì dịch vụ được lưu trữ trên máy chủ có thể giảm chi phí sở hữu. Nếu quyền riêng tư, thiết bị ngoại vi cục bộ, gỡ lỗi tương tác nhanh hoặc hỗ trợ tái tạo lặp đi lặp lại quan trọng hơn phạm vi bao phủ mô hình rộng, thì một phòng thí nghiệm cục bộ nhỏ có thể vẫn là trọng tâm phù hợp.
Sử dụng quy tắc xây dựng kết hợp với mua hàng
Các phòng thí nghiệm địa phương và được tổ chức là sự bổ sung. Thiết bị được quản lý theo cấp độ có thể xác định các thiết bị ảo trong bản dựng và nhóm chúng để thực hiện kiểm thử. Phòng thí nghiệm kiểm tra Firebase có thể mở rộng ma trận trên các thiết bị vật lý và ảo được lưu trữ và trả về các thành phần lạ được quản lý. Nhóm cục bộ cung cấp quyền truy cập ngay lập tức, các thiết bị ngoại vi độc quyền, gỡ lỗi được giám sát và các thiết bị ổn định để kiểm tra hoạt động định kỳ.
| ràng buộc | Thường ưu tiên địa phương | Thường được ưu tiên lưu trữ |
|---|---|---|
| Bảo hiểm | Một số thiết bị đã biết | Nhiều mô hình, cấp độ API, định hướng hoặc ngôn ngữ |
| Đồng thời | Khối lượng thấp có thể dự đoán được | Nhu cầu kiểm tra bùng nổ hoặc song song cao |
| Tương tác | Gỡ lỗi trực tiếp thường xuyên và hỗ trợ tái tạo | Bộ tiêu chuẩn không cần giám sát |
| Phần cứng | Phụ kiện USB, thiết bị Bluetooth, mạng cục bộ, đồ đạc tùy chỉnh | Không có thiết bị ngoại vi cục bộ đặc biệt |
| Quyền riêng tư | Dữ liệu phải được lưu giữ trên thiết bị cục bộ được kiểm soát | Tồn tại các biện pháp kiểm soát thực thi và lưu giữ từ xa đã được phê duyệt |
| Hoạt động | Nhóm chấp nhận tính phí, vá lỗi, đặt lại, kiểm kê và sửa chữa | Nhóm ưu tiên tính khả dụng của thiết bị được quản lý |
Một giải pháp kết hợp hợp lý giúp duy trì các thử nghiệm khung nhanh chóng trên cơ sở hạ tầng ảo được quản lý, gửi các kiểm tra khả năng tương thích đã chọn đến các thiết bị thực được lưu trữ và duy trì một băng ghế cục bộ nhỏ cho các luồng vật lý hoặc được giám sát có giá trị cao. Sự phân chia phù hợp có thể thay đổi khi tính đồng thời, quyền riêng tư và bằng chứng về thiết bị của khách hàng thay đổi.
Danh sách kiểm tra tự động hóa phòng thí nghiệm thiết bị Android
- Chỉ định một mục đích và quyết định cho mỗi hàng ma trận thiết bị.
- Các trách nhiệm riêng biệt về trình mô phỏng, thiết bị thực cục bộ, được lưu trữ, kiểm tra khung và luồng trực quan.
- Tạo thẻ chạy với bản dựng, thiết bị, trạng thái bắt đầu, đầu vào, hậu điều kiện, điểm dừng và bằng chứng.
- Xác minh trạng thái bắt đầu trước hành động kinh doanh đầu tiên.
- Chờ các điều kiện có thể quan sát được thay vì thêm những giấc ngủ mù dài hơn.
- Lưu giữ các quan sát, quyết định và hành động của thiết bị dưới dạng các bước có thể kiểm tra riêng biệt.
- Thu thập bằng chứng trước khi thiết lập lại hoặc khôi phục thay đổi lỗi.
- Phân loại riêng biệt các lỗi cơ sở hạ tầng, dữ liệu, thử nghiệm, môi trường và sản phẩm.
- Theo dõi hàng đợi, mức sử dụng, độ tin cậy đặt lại, số lần chạy lại không ổn định, thời gian phân loại và các lỗi chỉ ở vật lý.
- Sử dụng chiến lược kết hợp giữa cục bộ và máy chủ khi có bằng chứng ủng hộ chiến lược đó.
Bắt đầu với một chiếc điện thoại thực tế, một cấu hình trình giả lập và một thẻ chạy quan trọng đối với doanh nghiệp. Làm cho vòng lặp đó đáng tin cậy và có thể xem xét trước khi thêm một thiết bị hoặc quy trình làm việc khác. Khi một lớp phòng thí nghiệm thiết bị có thể quan sát được phù hợp với nhóm của bạn, hãy khám pháTự động hóa AI Android vớiLaiCai Flowvà giữ lại các chi tiết thực hiện trongHướng dẫn Flow có nhận thức về địa phương.
Ghi chú biên tập:BeePOS LLC, công ty đứng sau LaiCai Screen Mirroring, đã nghiên cứu hướng dẫn này bằng cách sử dụng tài liệu chính thức của Android và Firebase được liên kết bên dưới, các hợp đồng sản phẩm LaiCai chỉ đọc hiện tại và các cuộc thảo luận QA công khai. Khả năng của sản phẩm được xác định riêng biệt với hướng dẫn quy trình làm việc trung lập. Các câu hỏi hoặc chỉnh sửa có thể được gửi đến support@laicaiapp.com.