Test Studio

Xây dựng các kiểm thử giao diện người dùng toàn diện cho ứng dụng canvas của bạn bằng test Studio. Duy trì chất lượng ứng dụng của bạn bằng cách liên tục xác nhận rằng ứng dụng của bạn hoạt động như mong đợi khi các thay đổi hoặc cập nhật mới được triển khai.

Tổng quan

Kiểm thử là một phần quan trọng của vòng đời phát triển phần mềm (SDLC). Kiểm thử có thể giúp đảm bảo chất lượng của ứng dụng cung cấp cho khách hàng. Nó có thể xác định sớm các sự cố hoặc lỗi trong quá trình phát hành và cung cấp cơ hội khắc phục các sự cố này để làm cho ứng dụng trở nên đáng tin cậy hơn trước khi phát hành các thay đổi. Tùy thuộc vào kích thước và cách sử dụng ứng dụng, kiểm thử thủ công các thay đổi mới có thể là đủ. Tuy nhiên, khi độ phức tạp và mức sử dụng ứng dụng tăng lên, bạn có thể cần xem xét chiến lược thử nghiệm thay vì thử nghiệm thủ công. Nếu ứng dụng là nhiệm vụ quan trọng, ngay cả một lỗi nhỏ cũng có thể gây ra ảnh hưởng lớn.

Nhiều thay đổi ứng dụng có thể dẫn đến vòng đời kiểm thử lâu hơn. Cuối cùng, quá trình kiểm thử hồi quy của ứng dụng có thể dài hơn thời gian dành để phát triển các tính năng mới. Trong quá trình phát triển nhanh, việc kiểm tra kỹ lưỡng mọi tính năng trong ứng dụng sẽ trở thành yếu tố cản trở việc phát hành các bản cập nhật phần mềm. Một cách để giảm thời gian thực hiện trong một vòng đời kiểm thử và kiểm thử hồi quy là tự động hóa thử nghiệm. Tự động hóa kiểm thử có thể giúp bạn kiểm thử ứng dụng của mình với nỗ lực tối thiểu, giảm thời gian kiểm thử và xác định các vấn đề quan trọng trước khi phát hành.

Power Apps Test Studio là một giải pháp không cần nhiều mã để viết, sắp xếp và tự động hóa kiểm thử cho ứng dụng canvas. Trong Test Studio, bạn có thể viết kiểm thử bằng cách sử dụng biểu thức Power Apps hoặc sử dụng trình ghi để lưu tương tác ứng dụng để tự động tạo biểu thức. Bạn có thể phát các bài kiểm tra viết lại trong Test Studio để xác thực chức năng ứng dụng và cũng chạy các kiểm thử trong trình duyệt web và xây dựng kiểm thử tự động vào quy trình triển khai ứng dụng của mình.

Test Studio.

Điều kiện tiên quyết

Bạn phải là người tạo hoặc người đồng sở hữu ứng dụng để thử nghiệm ứng dụng đó bằng Test Studio.

Thuật ngữ trong Test Studio

Phần sau đây giải thích thuật ngữ chính của Test Studio.

Trường hợp kiểm thử

Trường hợp kiểm thử được tạo thành từ một loạt các hướng dẫn hoặc hành động, được gọi là các bước kiểm thử. Các trường hợp kiểm thử được thực thi để xác thực rằng ứng dụng của bạn hoặc các tính năng cụ thể trong ứng dụng của bạn đang hoạt động như mong đợi. Ví dụ: trong ứng dụng Chi phí, bạn muốn đảm bảo rằng chỉ những chi phí có chi phí thực tế liên quan mới được gửi. Trường hợp kiểm thử có thể giúp xác minh rằng điều kiện hoặc yêu cầu này luôn được đáp ứng.

Trong Test Studio, các bước kiểm thử được viết bằng cách sử dụng ngôn ngữ biểu thức Power Apps. Biểu thức kiểm thử có thể bao gồm cả hai hàm khả dụng khi xây dựng ứng dụng của bạn và các biểu thức bổ sung để hỗ trợ kiểm thử tự động.

Bộ kiểm thử

Bộ kiểm thử được sử dụng để tổ chức hoặc nhóm các trường hợp kiểm thử với nhau. Khi số lượng trường hợp kiểm thử trong ứng dụng tăng lên, bạn có thể xem xét tổ chức trường hợp kiểm thử theo các tính năng hoặc chức năng cụ thể. Ví dụ: bạn có thể có một bộ kiểm thử với các trường hợp kiểm thử để xác thực việc gửi báo cáo chi phí và một bộ kiểm thử khác chỉ tập trung vào phê duyệt chi phí.

Các trường hợp kiểm thử có trong các bộ kiểm thử được chạy tuần tự. Trạng thái ứng dụng được duy trì trên tất cả các trường hợp kiểm thử trong một bộ. Ví dụ: nếu bạn có một trường hợp kiểm thử hoàn thành trên Màn hình 5 trong ứng dụng, thì trường hợp kiểm thử tiếp theo trong bộ kiểm thử của bạn sẽ bắt đầu chạy từ Màn hình 5. Nó cho phép bạn chia một kịch bản kiểm thử phức tạp thành nhiều trường hợp kiểm thử trong một bộ duy nhất và trạng thái được chia sẻ trên tất cả các trường hợp kiểm thử. Nếu trường hợp kiểm thử thứ hai của bạn dự kiến bắt đầu ở màn hình bắt đầu của ứng dụng, bạn có thể điều hướng đến màn hình bắt đầu như bước đầu tiên trong trường hợp kiểm thử của bạn. Điều quan trọng cần nhớ là ứng dụng không được tải lại vào đầu mỗi trường hợp kiểm thử trong bộ kiểm thử khi lập kế hoạch thực hiện kiểm thử.

Xác nhận kiểm thử

Mỗi trường hợp kiểm thử nên có một kết quả mong đợi. Để xác thực kết quả dự kiến của một kiểm thử so với kết quả thực tế của kiểm thử, bạn có thể viết xác nhận kiểm thử. Xác nhận là biểu thức đánh giá là đúng hoặc sai trong một kiểm thử. Nếu biểu thức trả về sai, thì trường hợp kiểm tra sẽ thất bại.

Trong ví dụ về ứng dụng chi phí ở trên, bạn có thể viết một xác nhận để xác thực xem báo cáo chi phí có được tạo với chi tiết đơn hàng chi phí không có chi phí liên quan hay không.

Thực tiễn tốt nhất

Khi kiểm thử các ứng dụng canvas bằng Test Studio, hãy xem xét các thực tiễn tốt nhất sau đây để đạt được lợi ích tối đa để cải thiện chất lượng ứng dụng của bạn:

  1. Xác định trường hợp kiểm thử sẽ được tự động hóa.

    Thật khó để tự động hóa tất cả các kiểm thử và chúng tôi không khuyên bạn hoàn toàn dựa vào tự động hóa kiểm thử. Cần thực hiện kiểm thử thủ công bên cạnh kiểm thử tự động. Các kiểm thử phù hợp với tự động nhất là:

    • Kiểm thử lặp lại.
    • Kiểm thử chức năng có tác động kinh doanh cao.
    • Các tính năng ổn định và không trải qua thay đổi đáng kể.
    • Các tính năng yêu cầu nhiều tập hợp dữ liệu.
    • Kiểm thử thủ công mất nhiều thời gian và công sức.
  2. Giữ cho trường hợp kiểm thử ở mức nhỏ.

    Mặc dù một trường hợp kiểm thử duy nhất có thể hỗ trợ kiểm thử tất cả chức năng trong ứng dụng của bạn, chúng tôi khuyên bạn nên tránh viết một trường hợp kiểm thử nguyên vẹn và cố gắng chia thành nhiều trường hợp kiểm thử. Mỗi trường hợp kiểm thử có thể kiểm thử một tính năng hoặc chức năng cụ thể trong ứng dụng của bạn. Xác nhận thất bại trong trường hợp kiểm thử lớn có thể khiến chức năng khác không được kiểm thử. Sử dụng nhiều trường hợp kiểm thử trong bộ kiểm thử cho phép các chức năng khác được kiểm thử, bất kể trường hợp kiểm thử trước đó có thất bại hay không. Chiến lược này cũng giúp dễ dàng tìm ra lỗi kiểm thử.

  3. Giữ biểu thức cho một hành động kiểm thử duy nhất.

    Một hành động kiểm thử có thể chứa nhiều biểu thức. Các biểu thức kiểm thử nhiều hành động lớn cho một bước có thể ảnh hưởng đến khả năng gỡ lỗi và tìm lỗi kiểm thử. Cân nhắc chia một bước kiểm thử có nhiều hành động thành nhiều bước kiểm thử của các hành động đơn lẻ để xác định vấn đề nhanh hơn.

  4. Mỗi trường hợp kiểm thử nên có một kết quả mong đợi.

    Mỗi trường hợp kiểm thử nên có một hoặc nhiều kết quả mong đợi. Xác nhận kiểm thử nên được sử dụng để xác nhận kết quả dự kiến của kiểm thử so với các kết quả thực tế. Nhiều xác nhận có thể được viết cho một trường hợp kiểm thử.

  5. Sử dụng bộ kiểm thử.

    Để duy trì, nhóm hoặc phân loại các trường hợp kiểm thử tương tự với nhau và mô tả mục đích và kết quả mong đợi của kiểm thử.

Các giới hạn đã biết

Trong khi cung cấp toàn bộ phạm vi kiểm soát trong Power Apps Test Studio, chức năng sau đây sẽ không dùng được:

  • Thành phần.
  • Các thành phần mã được viết trong Power Apps Component Framework.
  • Bộ sưu tập lồng nhau.
  • Điều khiển phương tiện.
  • Tính năng thử nghiệm quản lý lỗi cấp công thức cần được bật cho ứng dụng.
  • Hỗ trợ cho các điều khiển không được liệt kê trong hàm SelectSetProperty.
  • Cột kiểu người.
  • Test Studio không tương thích với tính năng kiểm soát phiên bản Git thử nghiệm và sẽ không hoạt động bình thường nếu tính năng đó được bật.

Các bước tiếp theo

Xem thêm

Lưu ý

Bạn có thể cho chúng tôi biết bạn thích dùng ngôn ngữ nào cho tài liệu không? Làm một cuộc khảo sát ngắn. (xin lưu ý, khảo sát này bằng tiếng Anh)

Cuộc khảo sát sẽ mất khoảng bảy phút. Không có dữ liệu cá nhân nào được thu thập (điều khoản về quyền riêng tư).