Mô hình tự động hóa giao diện người dùng và thực hành tốt nhất cho các ứng dụng máy tính để bàn

Lý lịch

Tôi hiện đang tự động hóa một số thử nghiệm cho một plugin cho MS Office. Chúng tôi đang tạo các thử nghiệm UI được mã hóa trong VS 2010. Tôi cho rằng tôi có thể sử dụng công cụ "Trình tạo thử nghiệm UI được mã hóa ", nhưng nó không thực sự phù hợp với trường hợp cụ thể của tôi.

Do đó, tôi đã tạo lớp UI Map của riêng mình và các phương thức mở rộng cho mỗi Điều khiển / Bản đồ UI nơi tôi thêm chức năng hành động khác nhau. Ví dụ nhấn nút hoặc khẳng định một số giá trị UI.

Các kịch bản của các trường hợp thử nghiệm là trong các lớp thử nghiệm.

Tôi là người mới trong lĩnh vực này và tôi cũng mới làm việc như một người thử nghiệm tự động hóa.

Câu hỏi

Mọi người có đủ tử tế để chia sẻ kinh nghiệm và lời khuyên của họ cho một số thực tiễn tốt để tự động hóa thử nghiệm trên các ứng dụng máy tính để bàn theo quan điểm lập trình / thiết kế không?

Cách thực hành tốt nhất để kiểm tra tự động hóa giao diện người dùng là làm ít nhất có thể. Giao diện người dùng thay đổi thường xuyên, điều đó có nghĩa là bạn liên tục phải cập nhật tự động hóa. Nói chung, tốt hơn là cấu trúc mã sản phẩm theo cách cho phép kiểm tra tự động mà không cần Tự động hóa giao diện người dùng.

Điều đó nói rằng, bạn không thể luôn thoát khỏi Tự động hóa giao diện người dùng. Bạn đề cập đến văn phòng vì vậy tôi giả sử bạn đang mã hóa cho Windows và sử dụng .Net. Tôi làm khá nhiều trong công việc hiện tại của tôi. Đây là một số trong những điều tôi đã học được.

1) Nhìn vào các thư viện UIAutomation đã được giới thiệu trong .Net 3.0. Họ cung cấp một thư viện rộng rãi và khá đơn giản để sử dụng cho tự động hóa. (http://msdn.microsoft.com/en-us/l Library / ms753107.aspx)

2) Tải xuống UISpy (http://msdn.microsoft.com/en-us/l Library / ms727247.aspx)

3) Làm cho UI của sản phẩm của bạn tự động.

3a) Nếu WPF đặt Tự động hóa lên mọi thứ.

3b) Cố gắng tạo các tên lớp cửa sổ và điều khiển riêng biệt (tên lớp UI, không phải tên lớp mã nguồn). Nếu bạn không hiểu ý tôi, hãy tải UI Spy và bắt đầu nhìn vào windows. Lưu ý có bao nhiêu cửa sổ trên các ứng dụng khác nhau có tên lớp là # 32770. Đây là tên lớp cho Hộp thoại Windows. Bất kỳ cửa sổ nào mở rộng hộp thoại và không đặt tên riêng của nó, mặc định là. Điều này gây ra tất cả các loại đau buồn từ quan điểm Tự động hóa giao diện người dùng.

4) Tránh các câu lệnh Thread.S ngủ (). Thay vào đó, hãy thử sử dụng Waiters (xem tài liệu UIAutomation).

5) KHÔNG BAO GIỜ trộn mã kiểm tra với mã Tự động hóa giao diện người dùng. Tạo các thư viện riêng biệt để thực hiện Tự động hóa giao diện người dùng. Gọi các thư viện này từ các bài kiểm tra của bạn. Khi UI thay đổi, điều này sẽ giúp cập nhật tự động hóa dễ dàng hơn nhiều.

6) Luôn đăng ký người nghe cho Sự kiện UI trước khi thực hiện hành động khiến sự kiện này phát sinh. Trong thực tế, điều này có nghĩa là bạn sẽ làm việc với các chủ đề.

6a) Ví dụ: không bắt đầu chờ đợi một sự kiện Mở cửa sổ sau khi bạn đã nhấp vào nút để mở cửa sổ. Cửa sổ có thể mở trước khi người phục vụ được đăng ký và không bao giờ nhận được sự kiện.

7) Đừng bao giờ cho rằng cửa sổ vừa mở là cửa sổ bạn muốn. Tất cả các loại cửa sổ có thể mở bất ngờ trong Windows.

Tôi có thể tiếp tục nhiều hơn, nhưng điều này sẽ hơi lâu.

Xây dựng các bài kiểm tra chức năng từ các trường hợp sử dụng có thể sử dụng lại

Khi đến lúc kiểm tra ứng dụng của bạn kết thúc tại chỗ, bạn đang thực hiện kiểm tra chức năng. Thông thường, bạn sẽ có một bộ các yêu cầu mà bạn đang thử nghiệm và bạn sẽ có thể xây dựng các trường hợp sử dụng khác nhau đại diện cho chúng.

Ví dụ, xem xét trường hợp sử dụng "Đăng nhập như người dùng chuẩn". Khung kiểm tra của bạn kích hoạt ứng dụng, chờ màn hình đăng nhập, nhập một số thông tin đăng nhập, nhấp vào nút đăng nhập và xác minh rằng màn hình phù hợp hiện đang hiển thị rằng đăng nhập đã thành công.

Sau khi bạn thực hiện trường hợp sử dụng "Đăng nhập với tư cách người dùng chuẩn", bạn sẽ muốn xây dựng trường hợp đó để làm việc khác, có lẽ là trường hợp sử dụng "Chỉnh sửa chi tiết người dùng của tôi". Bạn sẽ không muốn lặp lại tất cả mã từ trường hợp sử dụng "Đăng nhập với tư cách là người dùng chuẩn", vì vậy bạn chỉ cần tham chiếu đến mã khung kiểm tra thực hiện bit đó.

Điều này ngụ ý rằng bạn có một số loại kiểm tra chức năng cung cấp quá mức có chứa một danh sách các trường hợp sử dụng. Các trường hợp sử dụng này chứa các phương thức khung kiểm tra để gây ra hành vi ứng dụng (nhấp vào nút X) và xác minh hành vi (màn hình chuyển sang màu xanh).

Nhìn chung, bạn có thể xây dựng một nhóm các trường hợp sử dụng có thể sử dụng lại, nhắm mục tiêu các chuỗi cụ thể và kiểm tra các phản ứng cụ thể, sau đó tổng hợp chúng thành các thử nghiệm chức năng khác nhau có liên quan chặt chẽ với các yêu cầu kinh doanh. Khi bạn đã có được điều đó, thì bạn đang ở một vị trí tuyệt vời để tự động hóa hoàn toàn toàn bộ quá trình xây dựng của bạn .

Nếu bạn muốn đọc thêm, tôi đã viết về cách tiếp cận này ở nơi khác, nhưng bài viết nhắm mục tiêu các ứng dụng web trong Java (sử dụng Maven và SeleniumRC) thay vì các ứng dụng máy tính để bàn mà bạn đã yêu cầu.