2010-04-17 24 views
7

Có bất kỳ lý do nào để tự động hóa các bài kiểm tra tập trung vào GUI (chứ không phải cho những thứ dưới nó) không? Trong GUI ý kiến ​​của tôi (và thay đổi trong nó) nên luôn luôn được kiểm tra bởi một người thực sự.GUIs có thử nghiệm tự động của riêng mình không?

Bạn có thể đạt được gì với các thử nghiệm lấy nét GUI tự động? Kinh nghiệm của riêng tôi là các bài kiểm tra tập trung vào GUI hầu như luôn bị phá vỡ bởi vì ai đó đã thay đổi điều gì đó vì một lý do thực sự tốt. Họ hiếm khi dường như tìm thấy bất cứ điều gì thú vị.

Trả lời

4

Đây là một điều khó khăn. Các công cụ và khung công cụ thử nghiệm tự động thực hiện một công việc tuyệt vời và đáng giá thời gian và công sức miễn là GUI không thay đổi quá nhiều. Vấn đề với thử nghiệm tự động là nó phân tích chính xác khi bạn cần nó nhất: khi GUI đang thay đổi nhanh chóng trong một chu kỳ phát triển.

Kết quả là tôi đã giải quyết theo cách tiếp cận lai cho các dự án mà tôi lãnh đạo và quản lý. Tôi thích sử dụng kiểm tra thủ công trên các vùng của GUI đang thay đổi nhanh chóng trong một chu kỳ phát triển. Khi mọi thứ khá ổn định, chúng tôi thực hiện một số loại thử nghiệm GUI tự động (ví dụ: Selenium cho ứng dụng web) mà chúng tôi đưa vào quá trình xây dựng để bảo vệ chống lại sự hồi quy trong tương lai. Nếu có thể, người QA viết các bài kiểm tra tự động. Đôi khi các nhà phát triển phải ghép nối với người kiểm tra QA để thực hiện việc này khi công cụ tự động quá mã hóa quá mức.

Phương pháp kết hợp này có vẻ hoạt động tốt miễn là chúng tôi sử dụng các phương pháp thiết kế tốt để tách riêng các mối quan tâm để kiểm tra đơn vị có thể thực hiện tất cả các logic cơ bản đúng cách. Một điều bạn phải tránh là đưa logic ứng dụng vào lớp GUI.

+0

Tôi đồng ý với phương pháp "tạo thử nghiệm tự động trễ trong chu trình dev", khi GUI ổn định hơn. Việc viết các kiểm tra tự động cho một GUI là rất khó thực hiện trên một GUI đang thay đổi liên tục. –

0

Phụ thuộc vào phần "gì" của GUI bạn kiểm tra. Bạn có kiểm tra hành vi của hệ thống bằng cách chạy thử nghiệm GUI hay bạn muốn kiểm tra xem GUI của bạn có được hiển thị chính xác mọi lúc không.

Trong trường hợp thứ hai, tùy thuộc vào đơn đăng ký của bạn. Nếu bố trí và thiết kế là importang, tôi đồng ý. Tuy nhiên, nếu nó là một số ứng dụng mà chức năng cốt lõi không phải là bố trí chính nó, không có điểm trong thời gian đầu tư để thử nghiệm bố trí. Nó sẽ là tốt hơn để viết thử nghiệm GUI mà kiểm tra chức năng bằng cách sử dụng GUI thay vì một số cuộc gọi chức năng. Bằng cách này, hành vi thực sự được mô phỏng tốt hơn.

0

Con người rất giỏi trong việc thử nghiệm GUI. Tuy nhiên, chúng đắt tiền. Các công cụ kiểm thử tự động, về mặt lý thuyết ít nhất, giảm chi phí kiểm tra UI. Nếu bạn phát hành thường xuyên, thời gian thử nghiệm giao diện người dùng thủ công có thể đi qua mái nhà thật nhanh chóng.

Cá nhân tôi chưa bao giờ thấy công cụ kiểm tra giao diện người dùng tự động trả gói chi phí thiết lập của họ, cho các dự án tôi đã tham gia. Các xét nghiệm của họ có xu hướng giòn và không phản ứng tốt với các thay đổi bố trí. Vì lý do đó, tôi do dự để đặt nhiều niềm tin vào họ. Tôi rất vui khi được chứng minh là sai.

0

Điều đó là có thể. Đối với trình duyệt, bạn có các bộ thử nghiệm như selen, tương tác với trình duyệt.

2

Điều đó tùy thuộc.

Nếu GUI của bạn là một lớp tương đối mỏng so với logic nghiệp vụ của bạn và các lỗi nhỏ trong GUI không quan trọng đối với doanh nghiệp của bạn thì bạn có thể chọn không dành thời gian kiểm tra GUI một cách khó khăn với các bài kiểm tra đơn vị. Thời gian đó có lẽ có thể được đầu tư tốt hơn trong việc kiểm tra mã quan trọng hơn.

Nếu GUI của bạn rất tinh vi và là điểm bán hàng lớn cho ứng dụng của bạn thì bạn có thể muốn đầu tư thời gian để thử nghiệm nó một cách tự động và thủ công. Thử nghiệm tự động không hoàn toàn thay thế kiểm tra thủ công, vì bạn vẫn cần người thử nghiệm để đảm bảo giao diện GUI có vẻ chính xác và giao diện rõ ràng và trực quan.

Xem Wikipedia để biết thêm thông tin về thử nghiệm GUI - ví dụ bằng cách ghi chuột và nhập phím và phát lại. Ngoài ra còn có a list of software có thể hỗ trợ bạn trong việc tạo thử nghiệm đơn vị GUI.

+0

Tôi chưa bao giờ nghe nói đến * GUI không quan trọng trước đây. –

+2

@Robert Harvey: GUI sẽ chỉ được sử dụng bởi nhân viên nội bộ - có lẽ chỉ bởi các nhà phát triển khác - có thể không yêu cầu nhiều thử nghiệm như một GUI được chuyển đến khách hàng của bạn. Bạn nên thực hiện phân tích lợi ích chi phí. –

0

Phương pháp tiếp cận của tôi trong trường hợp này thường là các lớp không có GUI thử nghiệm đơn vị, sử dụng kiểm tra tự động cho GUI càng nhiều càng tốt và sau đó kiểm tra thủ công mọi thứ còn lại. Tôi cũng sử dụng thử nghiệm thủ công để phát hiện lỗi đặc biệt để xác định các trường hợp kiểm tra bị thiếu.

Đối với tôi, điều này cung cấp tỷ lệ bao phủ thử nghiệm tốt nhất cho chi phí. Cuối cùng nó phụ thuộc vào những gì bạn đang cố gắng để đạt được - là phần mềm nhiệm vụ quan trọng này hoặc một ứng dụng đơn giản mà thất bại hoàn toàn là một sự bất tiện?

0

Bạn nên kiểm tra khả năng sử dụng trước tiên. Bên cạnh việc bạn sẽ thử nghiệm GUI đơn vị như thế nào? Điều gì sẽ là đầu ra? Nếu ai đó nhấp vào một cái gì đó và nhận được những gì ông "ban đầu" đang tìm kiếm? Điều gì nên được coi là một hành vi không được chấp nhận?

Bạn sẽ nhận được hàng tấn bullcrap để xem xét. Khả năng sử dụng là một từ lớn, nhưng thử nghiệm khả năng sử dụng đơn giản là thuê một người bạn đời của bạn (tốt nhất là không phải ai đó bạn biết, một người bạn của một người bạn) mà bạn có thể xem xét trong ứng dụng 'đối tượng mục tiêu'. Đưa vào một camtasia/camstudio (phần mềm ghi âm máy tính để bàn, có thể là tốt để ghi lại khuôn mặt của mình). Cung cấp cho anh ta một số nhiệm vụ trên một mảnh giấy (hoặc trong người, đôi khi giấy là tốt hơn gây ra bạn sẽ không can thiệp - scenrio sống động hơn). Và xem những gì anh ấy đang làm!

Nếu cần hỗ trợ, bạn sẽ thấy các phần chú ý cho sự phát triển trong tương lai. Đừng bao giờ cố gắng gây ảnh hưởng đến anh chàng nói với anh ta những thứ như "nhưng nhìn ở đây là cái nút này, tôi nghĩ nó thuận lợi hơn theo cách này".

Bạn sẽ nhận được kết quả tốt hơn nhiều của thử nghiệm như vậy, thay vì lãng phí thời gian của bạn với thử nghiệm từ máy tính đến máy tính. GUI là một giao diện giữa con người và máy tính. Đơn vị kiểm tra gui giống như cố gắng phân tích cú pháp cuốn sách bạn vừa viết và thấy nó có tốt không. Chắc chắn nó sẽ loại bỏ lỗi chính tả ví dụ, nhưng nó là một điều rất nhỏ -> so với mục tiêu thực sự của cuốn sách.

+0

Kiểm tra khả năng sử dụng không thực sự giống với thử nghiệm tự động và không có cùng mục tiêu. –

+0

Tôi chắc chắn. Nhưng tôi thấy rất ít cảm giác trong giao diện thử nghiệm đơn vị. Quá nhiều dữ liệu hoạt động adn để nhận bất kỳ kết quả nào. Tôi biết có những công ty làm thử nghiệm nặng như thế này. Biến các siêu máy tính lớn thành dạng bất cứ thứ gì có thể - có vẻ như nó lãng phí thời gian cho tôi. –

0

Có, tất nhiên GUIS nên có các bài kiểm tra đơn vị riêng. Xem ví dụ IcuTest.

Vấn đề là kiểm tra GUI phức tạp. Một khi bạn đã giải quyết xong, thế giới là của bạn.

0

Nếu bạn có các tác vụ đơn điệu lặp đi lặp lại trong thử nghiệm GUI và cần thực hiện điều đó cho nhiều kết hợp trình duyệt và hệ điều hành, việc tự động hóa GUI rất đáng giá. Với kỹ thuật duy trì, câu hỏi nổi tiếng "Thay đổi giao diện người dùng sẽ làm cho tự động hóa không liên quan" có thể được trả lời.

Các vấn đề liên quan