Thử nghiệm GUI

Question

Tôi đang nghiên cứu vấn đề thử nghiệm GUI của mình và tôi không hoàn toàn chắc chắn về cách tiếp cận tốt nhất ở đây. GUI của tôi được xây dựng bằng cách sử dụng một khung MVC truyền thống vì vậy tôi có thể dễ dàng kiểm tra các phần logic của GUI mà không cần phải nâng cấp GUI. Tuy nhiên, khi nói đến việc thử nghiệm chức năng của GUI, tôi không thực sự chắc chắn liệu tôi có nên lo lắng về việc thử nghiệm từng thành phần GUI hay không hoặc nếu tôi chủ yếu chỉ tập trung vào chức năng kiểm tra hệ thống. Đó là một hệ thống khá phức tạp, trong đó kiểm tra GUI thường xuyên liên quan đến việc gửi một tin nhắn đến máy chủ và sau đó quan sát phản ứng trên GUI. Suy nghĩ ban đầu của tôi là thử nghiệm chức năng là cách để đi ở đây vì tôi cần một hệ thống toàn bộ chạy để thực sự kiểm tra giao diện người dùng. Nhận xét về vấn đề này sẽ được đánh giá cao.

Cảm ơn, Jeff

Answer 1

Bạn có (ít nhất) 2 vấn đề - độ phức tạp của môi trường (máy chủ) và độ phức tạp của GUI.

Có nhiều công cụ để tự động kiểm tra GUI. Tất cả chúng đều có ít hoặc mỏng manh và yêu cầu bảo trì liên tục khá nhiều khi đối mặt với việc thay đổi bố cục. Có lợi ích từ việc sử dụng chúng, nhưng đó là một lợi ích lâu dài.

Môi trường, mặt khác, là một khu vực có thể được thuần hóa. Nếu ứng dụng của bạn được cấu trúc bằng cách sử dụng kỹ thuật Dependency Injection/Inversion (nơi bạn 'tiêm' thành phần máy chủ vào ứng dụng), thì bạn có thể sử dụng một 'mô hình' của các giao diện máy chủ có liên quan để cho phép bạn kiểm tra kịch bản lệnh.

Kết hợp hai kỹ thuật này sẽ cho phép bạn tự động kiểm tra GUI.

Một ý nghĩ cuối cùng - chúc bạn may mắn!

Answer 2

gì bạn đang tìm kiếm là "kiểm tra chấp nhận." Cách bạn làm điều đó phụ thuộc vào các khung công tác bạn đang sử dụng, loại ứng dụng bạn đang tạo và ngôn ngữ nào. Nếu bạn google công nghệ cụ thể của bạn và cụm từ trên, bạn nên tìm một số công cụ bạn có thể sử dụng.

Answer 3

Thủy ngân QuickTest Pro, Borland SilkTest và Ranorex Recorder là một số công cụ kiểm tra GUI.

Answer 4

Nếu ứng dụng của bạn dựa trên web, bạn có thể viết kiểm tra bằng các công cụ như WatiN hoặc Selenium.

Nếu ứng dụng của bạn là Windows .NET, bạn có thể thử White.

Answer 5

Tùy thuộc vào vị trí trong phạm vi của MVC (đó là cụm từ quá mức) mà bạn ngồi, kiểm tra xem có thể là một quá trình cơ học đảm bảo rằng các phương pháp mô hình chính xác được gọi để đáp ứng với các đầu vào chính xác. xác thực phía khách hàng cho những người biết.

Rất nhiều mẫu đã được phát triển từ MVC (tôi nghĩ là passive view, supervising controller) đang cố gắng làm cho chế độ xem yêu cầu rất ít thử nghiệm vì nó thực sự chỉ là đầu vào của người dùng dây cho người trình bày hoặc mô hình (tùy thuộc vào biến thể chính xác của mẫu bạn đang sử dụng).

"kiểm tra GUI thường xuyên liên quan đến việc gửi thư đến máy chủ và sau đó quan sát phản hồi trên GUI" Tuyên bố này làm tôi lo lắng. Tôi nghĩ ngay lập tức rằng GUI nên được kiểm tra bằng cách sử dụng một mô hình hoặc sơ khai của máy chủ để kiểm tra xem các tương tác chính xác có xảy ra không và GUI phản hồi một cách thích hợp. Page 5

Nếu bạn cần kiểm tra chức năng tự động của máy chủ, tôi không thấy cần phải có GUI tham gia vào những thứ đó.

Answer 6

Lời khuyên của tôi: quên kiểm tra GUI truyền thống. Nó quá đắt. Mã hóa các thử nghiệm mất rất nhiều thời gian, các công cụ không thực sự ổn định, do đó bạn sẽ nhận được kết quả kiểm tra không đáng tin cậy. Sự kết hợp giữa mã và thử nghiệm là rất mạnh và bạn sẽ dành rất nhiều thời gian với việc bảo trì.

Xu hướng mới là bỏ qua các kiểm tra GUI. Xem mô hình ModelViewPresenter từ Fowler làm kim chỉ nam link text

Answer 7

Cách rõ ràng nhất tôi có thể nói đây là:

Đừng lãng phí thời gian của bạn viết bài kiểm tra tự động GUI.

Đặc biệt khi bạn làm việc với ứng dụng MVC - trong trường hợp của bạn, khi bạn gửi tin nhắn đến máy chủ, bạn có thể đảm bảo số lượng tin nhắn phù hợp trở lại và hoàn thành. Bạn có thể thêm một số trường hợp bổ sung - hoặc thử nghiệm khác hoàn toàn để đảm bảo rằng GUI đang chuyển đổi id tin nhắn thành chuỗi đúng, nhưng bạn chỉ cần chạy thử nghiệm đó một lần.

Answer 8

Chúng tôi kết hợp thử nghiệm GUI trong dự án của mình và nó có tác dụng phụ. Tuy nhiên, các nhà phát triển có một nguyên tắc thiết kế quan trọng: Giữ lớp GUI càng mỏng càng tốt!

Điều đó có nghĩa là không có logic trong các lớp GUI. Phân tách điều này trong các mô hình trình bày chịu trách nhiệm xác nhận đầu vào, v.v.

Để thử nghiệm trên máy Unix, chúng tôi sử dụng máy chủ Xvfb làm DISPLAY khi chạy thử nghiệm.

Answer 9

công cụ GUI-thử nghiệm khác tôi có thể cung cấp bao gồm: Thoughtworks White, PyWinAuto, AutoIt, AutoHotKey.

Một điều cần lưu ý khi cố gắng tự động hóa GUI là cách duy nhất bạn có thể làm đó là xây dựng GUI với tự động hóa trong đầu. Nghiền devs nghĩ rằng GUI của họ không hỗ trợ testability sớm trong dự án và vui vẻ phơi bày tất cả các móc có thể giúp tự động hóa theo yêu cầu khi nhu cầu thử nghiệm của bạn yêu cầu điều đó.

Answer 10

Đừng bỏ lỡ 'U' trong 'GUI'
tôi muốn nói: nếu những gì bạn đang cố gắng để kiểm tra là tất cả các công trình đúng và làm việc như nó đã được lên kế hoạch để làm việc, sau đó bạn có thể làm theo Seb Rose's answer.

Nhưng xin vui lòng, đừng quên giao diện người dùng phải được suy nghĩ về NGƯỜI DÙNG và không BẤT K user NGƯỜI dùng nào nhưng NGƯỜI DÙNG MỤC TIÊU đã đăng ký. Vì vậy, sau khi bạn chắc chắn rằng tất cả các công trình đều hoạt động, hãy đặt từng chế độ xem/màn hình/biểu mẫu trong một thử nghiệm với một nhóm người dùng đại diện cho mọi nhóm người dùng khác nhau có thể sử dụng ứng dụng của bạn: người dùng nâng cao, quản trị viên, MS Office người dùng, người dùng hồ sơ máy tính thấp, người dùng hồ sơ máy tính cao ... và sau đó, nhận được những lời phê bình của mọi người dùng, kết hợp, liên lạc lại GUI của bạn nếu cần thiết và ngược lại với kiểm tra của người dùng GUI.

Answer 11

Tôi đã tìm thấy WinTask là một cách rất tốt để thực hiện kiểm tra GUI.Nếu bạn không liên tục thay đổi cách hệ điều hành đề cập đến từng phần tử của giao diện người dùng, WinTask sẽ giải quyết các thành phần giao diện người dùng theo tên, vì vậy ngay cả khi bố cục thay đổi, các yếu tố giao diện người dùng vẫn có thể được nhấn/chỉnh/chọn.

Answer 12

Đối với Web dựa trên thử nghiệm giao diện SIMPLE thử iMacros (một đơn giản Firefox plug-in, có một tính năng mát mẻ để gửi toàn bộ bài kiểm tra cho người khác) Lưu ý rằng SIMPLE được đánh vần với viết tắt ...

Answer 13

Thử hallway usability test. Đó là rẻ và hữu ích: đi đến hành lang gần nhất, lấy người đầu tiên đi qua, làm cho họ ngồi vào máy tính của bạn và sử dụng phần mềm của bạn. Xem qua vai của họ, bạn sẽ thấy những gì họ cố gắng làm, những gì làm họ thất vọng, v.v. Làm điều này một vài lần và nhận thấy các mẫu.