Vấn đề nào kiểm tra giao diện người dùng tự động giải quyết?

Chúng tôi hiện đang điều tra thử nghiệm giao diện người dùng tự động (chúng tôi hiện đang thực hiện kiểm tra đơn vị và tích hợp tự động).

Chúng tôi đã xem Selenium và Telerik và đã giải quyết vấn đề sau là công cụ được lựa chọn do máy ghi linh hoạt hơn nhiều - và chúng tôi thực sự không muốn người kiểm tra viết quá nhiều mã.

Tuy nhiên, tôi đang cố gắng để hiểu lợi ích tổng thể. Quan điểm của mọi người là gì và những thứ gì hoạt động tốt và những gì không?

Hệ thống của chúng tôi đang được phát triển liên tục và chúng tôi thường xuyên phát hành các phiên bản mới của nền tảng (dựa trên web) của chúng tôi.

Cho đến nay, lợi ích chính mà chúng ta có thể thấy là cho thử nghiệm hồi quy, đặc biệt là trên nhiều triển khai máy khách của nền tảng của chúng tôi.

Thực sự tìm kiếm quan điểm của người khác. Chúng tôi "nghĩ" đó là điều nên làm nhưng trong một lịch trình bận rộn đang tìm kiếm một số hiểu biết bổ sung.

Khi nhóm của tôi thực hiện kiểm tra giao diện người dùng tự động, rất nhiều điều tuyệt vời đã xảy ra.

Đầu tiên, nhóm QA trở nên hiệu quả hơn nhiều trong việc thử nghiệm ứng dụng cũng như thành thạo hơn với ứng dụng. Trưởng nhóm QA nói rằng anh ta có thể nhanh chóng đưa các thành viên QA mới tăng tốc bằng cách giới thiệu họ đến các bộ thử nghiệm cho UI.

Thứ hai, chất lượng vé QA trở lại đội Dev tốt hơn. Thay vì 'Trang bị hỏng khi tôi nhấp vào nút Gửi', chúng tôi đã nhận được trường hợp chính xác không thành công để chúng tôi có thể thấy những gì được nhập vào biểu mẫu. Nhóm QA cũng tiến thêm một bước bằng cách kiểm tra tất cả các trường hợp thất bại và thử nghiệm các kịch bản khác xung quanh trang đó để cho chúng tôi cái nhìn rõ hơn về những gì đã xảy ra.

Thứ ba, nhóm QA đã có nhiều thời gian hơn. Với thời gian thêm này, họ đã có thể tham gia vào các cuộc họp thiết kế nhiều hơn. Điều này đến lượt họ cho phép họ viết các trường hợp bộ thử nghiệm mới cùng lúc với các Dev đang mã hóa các tính năng mới đó.

Ngoài ra, thử nghiệm căng thẳng mà bộ thử nghiệm chúng tôi sử dụng có giá trị bằng vàng. Nó thành thật giúp tôi ngủ ngon hơn vào ban đêm khi biết rằng ứng dụng của chúng tôi có thể mất khá nhiều thứ ném vào nó. Chúng tôi đã tìm thấy khá nhiều trang bị áp lực mà chúng tôi có thể sửa chữa trước khi phát hành trực tuyến. Hoàn hảo.

Điều cuối cùng mà chúng tôi tìm thấy là với một số chỉnh sửa của nhóm QA, chúng tôi cũng có thể thực hiện một số thử nghiệm tiêm SQL trên ứng dụng của mình. Chúng tôi đã tìm thấy một số lỗ hổng mà chúng tôi có thể khắc phục nhanh chóng.

Việc thiết lập bộ kiểm tra giao diện người dùng mất một khoảng thời gian tốt. Nhưng, một khi nó đã ở đó, nó trở thành một phần trung tâm của quá trình phát triển của chúng tôi.

Kiểm tra giao diện người dùng tự động là các thử nghiệm tích hợp thực sự . Họ kiểm tra toàn bộ hệ thống theo cách nó thực sự được sử dụng khi nó hoạt động. Điều đó làm cho chúng các bài kiểm tra có ý nghĩa nhất. Tuy nhiên, chúng cũng có xu hướng giòn nhất và chậm nhất để thực hiện.

Theo dõi tỷ lệ chi phí / lợi ích (với độ giòn là một phần của chi phí) và đừng vội có một số thứ chỉ được kiểm tra thủ công (nhưng hãy chắc chắn rằng chúng đã được kiểm tra). Và nếu có thể, hãy tạo điều kiện cho các nhà phát triển chạy các phần cụ thể của bộ kiểm tra giao diện người dùng so với phiên bản ứng dụng đang chạy cục bộ của họ, để họ có thể hưởng lợi từ các thử nghiệm trong quá trình phát triển.

Tất nhiên, có các bài kiểm tra chạy tự động trên một máy chủ xây dựng (ít nhất một lần một ngày) là điều bắt buộc tuyệt đối.

chúng tôi không thực sự muốn người kiểm tra viết quá nhiều mã.

IMO đây là một giấc mơ ống. Tạo các bài kiểm tra tự động là viết mã. Chức năng ghi có thể giúp bạn viết một số mã đó nhanh hơn và bắt đầu nhanh hơn bằng cách viết thủ công (và làm chậm bạn một cách khủng khiếp nếu bạn bỏ lỡ điểm viết mã thủ công trở nên nhanh hơn), nhưng cuối cùng viết mã theo cách thủ công là những gì bạn sẽ kết thúc làm rất nhiều Hy vọng tốt hơn khung thử nghiệm của bạn hỗ trợ tốt cho nó và đã không phát triển nó tập trung quá nhiều vào giấc mơ ống (rất bán được) cho phép những người không thể viết mã để tạo ra các thử nghiệm tự động.

và chúng tôi không thực sự muốn người kiểm tra viết quá nhiều mã

Chúng tôi đã thực hiện các phương pháp ngược lại. Chúng tôi muốn những người thử nghiệm viết mã.

Đây là quy trình công việc chúng tôi bắt đầu áp dụng. Không dễ để làm điều này bởi vì quản lý hoàn toàn không phụ thuộc vào kiểm tra tự động của giao diện người dùng. Họ sẵn sàng giải quyết cho "đủ gần".

1. Câu chuyện của người dùng.

2. Khái niệm hoạt động. Làm thế nào câu chuyện có thể sẽ làm việc. Đánh giá thiết kế.

3. Phác thảo màn hình: Thiết kế giao diện người dùng. Nó trông như thế nào.

4. Tập lệnh Selenium. Nếu tất cả các kịch bản đều hoạt động, chúng tôi đã hoàn thành việc phát hành.

5. Mã hóa và thử nghiệm cho đến khi kịch bản hoạt động.

Kiểm tra tự động là cách duy nhất để chứng minh rằng chức năng tồn tại.

Kiểm tra thủ công dễ bị lỗi và chịu sự ghi đè của quản lý: "đủ tốt rồi, những thử nghiệm thất bại đó không thực sự quan trọng bằng việc phát hành này đúng hạn."

"Bất kỳ tính năng chương trình nào mà không có kiểm tra tự động đơn giản là không tồn tại."

Trình bày trực quan là một câu chuyện khác. Kiểm tra thủ công bố cục hình ảnh là một trường hợp đặc biệt bởi vì nó có thể liên quan đến phán đoán thẩm mỹ hoặc xem xét các vấn đề cụ thể (nhỏ) trên một màn hình pixel rất lớn và phức tạp.

Cho đến nay, lợi ích chính mà chúng ta có thể thấy là cho thử nghiệm hồi quy, đặc biệt là trên nhiều triển khai máy khách của nền tảng của chúng tôi.

Tự động hóa kiểm tra hồi quy của bạn là một điều tốt. Điều này giải phóng những người thử nghiệm của bạn để thực hiện nhiều công việc thú vị hơn - có thể là việc thêm các thử nghiệm tự động hơn, kiểm tra căng thẳng ứng dụng của bạn hoặc bất kỳ số lượng nào khác.

Ngoài ra, bằng cách làm cho nó tự động, bạn có thể khiến các nhà phát triển của mình chạy thử nghiệm và do đó các vấn đề về rừng chỉ được phát hiện sau đó trong quy trình.

Chúng tôi đã xem Selenium và Telerik và đã giải quyết vấn đề sau là công cụ được lựa chọn do máy ghi âm linh hoạt hơn nhiều

Tôi không chắc bạn đã nhìn vào nó bao nhiêu. Chắc chắn có những lựa chọn khác là tốt. Bạn đã nhìn vào Watir , WatiN , Sikuli để đặt tên cho một vài?

và chúng tôi không thực sự muốn người kiểm tra viết quá nhiều mã.

Tôi cảm thấy tồi tệ cho những người phải duy trì các kịch bản này. Thông thường, không có mã có thể dễ dàng sửa đổi, các tập lệnh trở nên dễ vỡ và bắt đầu mất nhiều thời gian hơn để sửa đổi tập lệnh so với việc ghi lại nó, điều này làm lãng phí nhiều thời gian hơn.

Tuy nhiên, tôi đang cố gắng để hiểu lợi ích tổng thể. Quan điểm của mọi người là gì và những thứ gì hoạt động tốt và những gì không?

Kiểm tra tự động hóa là một điều đẹp khi được thực hiện chính xác. Nó tiết kiệm thời gian cho các bài kiểm tra / kiểm tra hồi quy để giúp người kiểm tra của bạn có thêm thời gian để làm những gì họ làm tốt nhất, kiểm tra. Đừng tin một chút rằng đó là viên đạn bạc. Các kịch bản tự động hóa đòi hỏi thời gian đáng kể để phát triển nếu ứng dụng đã tồn tại nhưng các thử nghiệm thì không và yêu cầu cập nhật liên tục với mỗi bản phát hành. Kiểm tra tự động cũng là một cách tuyệt vời cho những người mới trong nhóm để xem hệ thống được cho là hành xử như thế nào. Ngoài ra, hãy chắc chắn rằng người kiểm tra của bạn có quyền quyết định những gì cần được tự động hóa. Nếu đó là một kiểm tra nhỏ không mất nhiều thời gian để kiểm tra, thì rất đơn điệu và dễ tự động hóa, hãy bắt đầu với điều đó. Luôn bắt đầu với các kiểm tra đạt được nhiều nhất thông qua tự động hóa và làm việc từ đó.

Cho đến nay, lợi ích chính mà chúng ta có thể thấy là cho thử nghiệm hồi quy, đặc biệt là trên nhiều triển khai máy khách của nền tảng của chúng tôi.

Đó là lợi ích chính và nếu được thiết lập chính xác, có thể kiểm tra hầu hết các trình duyệt mà bạn cần với một thay đổi cấu hình nhỏ.

Chúng tôi "nghĩ" đó là điều nên làm nhưng trong một lịch trình bận rộn đang tìm kiếm một số hiểu biết bổ sung.

Như tôi đã nói trước đó, tự động hóa thử nghiệm cần nhiều nỗ lực đáng kể, tuy nhiên, khi được thực hiện chính xác, tôi chưa gặp một nhóm nào nói rằng "Tôi ước chúng tôi không thiết lập tự động hóa thử nghiệm của mình."

Bạn đúng rằng hồi quy là một số lớn. Cũng thế -

• nếu các bài kiểm tra của bạn được viết theo mô-đun, bạn có thể kiếm được nhiều tiền hơn bằng cách trộn và kết hợp các bộ kiểm tra

• chúng tôi đã sử dụng lại các tập lệnh kiểm tra tự động để tải dữ liệu để chúng tôi không phải loại bỏ cơ sở dữ liệu để thực hiện kiểm tra kích thước lớn

• kiểm tra hiệu suất

• kiểm tra đa luồng

• trên các hệ thống web - hoán đổi giữa các trình duyệt và hoán đổi giữa các hệ điều hành. Với các vấn đề về tính nhất quán của trình duyệt, việc đặt một cơ sở càng rộng càng tốt là một điều rất lớn.

Những điều cần bỏ qua - đặc biệt là trong các hệ thống web, coi chừng các trường hợp các yếu tố hiển thị của bạn được tạo bằng id động, thay đổi - thường các kịch bản kiểm tra tự động không xử lý tốt điều này và bạn có thể cần thiết kế lại nghiêm túc để cập nhật điều này.

Chỉ cần một ví dụ: đo chính xác thời lượng kết xuất trang web

Sử dụng các bài kiểm tra tự động hóa, việc kiểm tra hiệu suất của trình duyệt web sẽ dễ dàng hơn nhiều. Để đo thời gian phản hồi tối đa bạn có thể chấp nhận, chỉ cần đặt một hằng số trong các tập lệnh thử nghiệm của bạn và / hoặc chuyển nó dưới dạng tham số hàm, ví dụ như trong mã giả này: $ sel-> Wait_for_page_to_load ($ mypage, $ maxtime).

Thực hiện kiểm tra trình duyệt chéo với các giá trị thấp có thể khá ngộ.

Thay thế sẽ là nhân viên thực hiện các phép đo thời gian bằng đồng hồ bấm giờ.

Kiểm tra giao diện người dùng tự động giải quyết khả năng:

• nhanh chóng lặp lại thử nghiệm một số lượng lớn các thành phần
• nhớ kiểm tra một số lượng lớn các chức năng mỗi lần
• so sánh thời gian chạy và thời gian chạy của bộ thử nghiệm khi ứng dụng phát triển
• thiết lập chạy với hàng trăm đầu vào khác nhau và các điều kiện khác nhau
• cho phép những người không viết bài kiểm tra chạy nó và xem bất kỳ vấn đề trực quan nào
• cho phép người dùng cuối thấy ứng dụng đang được sử dụng một cách nhanh chóng và dễ dàng
• phân phối UI thử nghiệm chạy đến mạng, máy chủ từ xa hoặc dịch vụ
• bắt đầu kiểm tra khối lượng bằng cách sử dụng các máy song song.

Tuy nhiên, như những người khác đã lưu ý:

Telerik ...

công cụ được lựa chọn do máy ghi linh hoạt hơn nhiều

là một lá cờ đỏ cho nhiều người trong chúng ta.

Các tập lệnh được ghi theo cách này có xu hướng không phải là một giải pháp lâu dài vì:

• cơ sở dữ liệu / ID đối tượng có xu hướng thay đổi theo từng trường hợp
• tập lệnh được ghi thủ công thường dựa vào thẻ bố cục trang thường xuyên thay đổi
• các hành động thông thường sẽ cần được viết đi viết lại nhiều lần thay vì cho phép sử dụng lại (xem cách tiếp cận SitePrism & PageObject)
• đôi khi bạn cần sử dụng các công cụ như xpath để lấy thông tin bổ sung dựa trên thông tin trang hiện tại. Một kịch bản được ghi đơn giản sẽ không làm điều này.
• các nhà phát triển và người kiểm tra viết mã sẽ không được khuyến khích sử dụng các lớp CSS, thuộc tính dữ liệu của ID và HTML5, đây là các thực tiễn sẽ dẫn đến các thử nghiệm bền vững hơn, có thể duy trì hơn.

Telerik có một số lợi thế cần được xem xét mặc dù:

• nhằm vào khách hàng di động
• các công cụ tích hợp để quản lý tăng trưởng
• xử lý Android, iOS và Windows Phone

Một cách tiếp cận có thể giúp thu hẹp khoảng cách là ghi lại tập lệnh ban đầu bằng cách sử dụng trình ghi trang công cụ nhưng sau đó thay đổi tập lệnh để sử dụng ID, các lớp và thuộc tính dữ liệu để ID sẽ tồn tại theo thời gian. Đây là một cách tiếp cận mà tôi đã thực sự sử dụng với plugin firefox selenium.

Nó làm cho "Thử nghiệm chuyên gia" (tương tự như "Thử nghiệm thăm dò", nhưng được thực hiện bởi người dùng cuối hoặc thành viên của nhóm có nhiều kiến ​​thức kinh doanh) dễ dàng thực hiện, ghi lại kết quả, đo lường và tự động hóa.

Tôi đến đây từ một nền tảng khác. Tại các công ty cũ của tôi, chúng tôi đã phát triển các công cụ kiểm tra tự động thương mại (QALoad, QARun, TestPartner, SilkTest, SilkPerfomer).

Chúng tôi đã thấy kiểm tra giao diện người dùng tự động khi thực hiện hai vai trò:

1. Kiểm tra hồi quy đầy đủ

2. Tự động thiết lập môi trường thử nghiệm

Chúng tôi chủ yếu dựa vào các công cụ để thực hiện kiểm tra hồi quy trên cơ sở hàng đêm. Chúng tôi chỉ đơn giản là không có sức mạnh để kiểm tra tất cả các nút và hộp thoại để xác minh rằng chúng tôi đã không phá vỡ bất cứ điều gì giữa UI và logic nghiệp vụ.

Đối với các thử nghiệm quan trọng hơn, chúng tôi thấy rằng một người có thể quay một số máy ảo và sử dụng các tập lệnh để đi đến điểm của một thử nghiệm thực sự. Nó cho phép họ tập trung vào các bit quan trọng và không thử và làm theo trường hợp kiểm tra 24 bước.

Vấn đề duy nhất với kiểm tra tự động là thói quen bỏ quá nhiều bài kiểm tra vào hộp mà không có bất kỳ loại giám sát nào để loại bỏ các bài kiểm tra trùng lặp hoặc không cần thiết. Thỉnh thoảng chúng tôi sẽ phải đi vào và cắt tỉa mọi thứ trở lại để bộ có thể hoàn thành trong vòng dưới 12 giờ.

Kiểm tra tự động, dưới bất kỳ hình thức nào, cung cấp cho kiểm tra hồi quy; bằng cách chạy thử nghiệm đã từng hoạt động, bạn xác minh nó vẫn hoạt động (hoặc không) bất kể bạn đã thêm bất cứ thứ gì khác. Điều này đúng bất kể thử nghiệm là thử nghiệm tích hợp (thường không chạm vào UI) hay AAT (thường yêu cầu UI).

Kiểm tra giao diện người dùng tự động cho phép hệ thống được kiểm tra như thể người dùng đang nhấp vào nút. Do đó, các thử nghiệm như vậy có thể được sử dụng để xác minh điều hướng qua hệ thống, tính chính xác của nhãn và / hoặc tin nhắn, hiệu suất và / hoặc thời gian tải trong một môi trường thử nghiệm cụ thể, v.v. Mục tiêu chính là giảm thời gian bấm nút của anh chàng QA, giống như tích hợp và kiểm tra đơn vị làm cho lập trình viên. Anh ta có thể thiết lập một thử nghiệm một lần (thường bằng cách ghi lại các lần nhấp chuột và nhập dữ liệu của mình vào tập lệnh) và một khi thử nghiệm hoạt động đúng, tất cả những gì anh ta phải làm để xác minh tính chính xác của hệ thống được kiểm tra sẽ chạy lại. Một số khung, chẳng hạn như Selenium, cho phép các thử nghiệm được di chuyển giữa các trình duyệt, cho phép thử nghiệm một số môi trường trong đó trang web sẽ hoạt động chính xác.

Nếu không có kiểm tra tự động, bạn bị giới hạn bởi số lượng và tốc độ của những người kiểm tra QA của bạn; họ thực sự phải có hệ thống thực hành, kiểm tra xem tính năng mới của bạn có đáp ứng yêu cầu hay không và quan trọng là bạn không phá vỡ bất cứ thứ gì đã có ở đó.

Kiểm tra xác định nhiều thứ khác nhau. Nhiều trong số các thử nghiệm này có thể được tự động hóa, để cho phép loại bỏ sự vất vả và để thực hiện nhiều hơn. Để xác định xem các bài kiểm tra của bạn có thể được tự động hóa hay không, trước tiên bạn cần xem liệu câu hỏi họ hỏi có phù hợp với nó không.

• Bạn đang xác định nếu một chức năng thành phần theo thông số kỹ thuật?
• Bạn có muốn kiểm tra tất cả các đầu vào và đầu ra khác nhau có thể?
• kiểm tra căng thẳng thành phần?
• Hay bạn đang cố kiểm tra "nó hoạt động"?

Hầu hết trong số này có thể được tự động, bởi vì chúng là cơ học trong tự nhiên. Hàm mới chấp nhận đầu vào, vậy điều gì xảy ra khi chúng ta ném dữ liệu ngẫu nhiên vào nó? Nhưng một số, như kiểm tra nếu hệ thống hoạt động, yêu cầu ai đó thực sự sử dụng nó. Nếu họ không, bạn sẽ không bao giờ biết liệu kỳ vọng của người dùng của bạn có giống như chương trình hay không. Cho đến khi, đó là, hệ thống 'phá vỡ'.

Theo kinh nghiệm của tôi, kiểm tra giao diện người dùng tự động bao gồm nhiều khoảng trống bao gồm:

• Thiếu tài liệu (ví dụ: sử dụng trình chạy thử tự động để demo chức năng hiện có)
• Yêu cầu lỗi thời do creep phạm vi (ví dụ: xác định khoảng cách giữa yêu cầu và mã bằng cách chụp màn hình trong khi chạy thử)
• Doanh thu cao của các nhà phát triển và người thử nghiệm (ví dụ: JavaScript kế thừa kỹ thuật đảo ngược bằng cách chụp màn hình trong khi chạy thử với công cụ dành cho nhà phát triển mở)
• Xác định vi phạm các quy ước đặt tên tiêu chuẩn thông qua các bài kiểm tra hồi quy XPath (ví dụ: tìm kiếm tất cả các nút thuộc tính DOM để tìm tên vỏ lạc đà)
• Nhận biết các lỗ hổng bảo mật mà chỉ máy tính mới có thể phát hiện ra (ví dụ: đăng xuất từ ​​một tab trong khi đồng thời gửi biểu mẫu trong thẻ kia)

Tôi muốn chia sẻ kinh nghiệm của nhóm chúng tôi. Chúng tôi đã sử dụng công cụ kiểm tra giao diện người dùng của riêng mình, Screenster, để kiểm tra các ứng dụng web của khách hàng và của chúng tôi. Nó đã tự chứng minh là một sự thay thế hữu ích cho Selenium cho các nhiệm vụ thử nghiệm trực quan / CSS. Screenster là một công cụ tự động hóa thử nghiệm thực hiện so sánh dựa trên ảnh chụp màn hình của các phiên bản khác nhau của các trang web của bạn. Đầu tiên, nó tạo ra một đường cơ sở trực quan cho một trang, chụp ảnh màn hình cho mỗi hành động của người dùng. Trong lần chạy tiếp theo, nó sẽ chụp ảnh màn hình mới ở mỗi bước, so sánh nó với ảnh chụp từ đường cơ sở và làm nổi bật sự khác biệt.

Tóm tắt, Screenster có các ưu điểm sau: Đường cơ sở trực quan: ảnh chụp màn hình được chụp cho mỗi bước người dùng trong khi ghi kiểm tra So sánh dựa trên ảnh chụp màn hình: Screenster so sánh hình ảnh được chụp trong khi phát lại từ đường cơ sở và làm nổi bật tất cả các khác biệt Bộ chọn CSS thông minh: người kiểm tra có thể chọn Các yếu tố CSS trên ảnh chụp màn hình và thực hiện các hành động với chúng - ví dụ: đánh dấu chúng là các vùng bỏ qua để loại trừ khỏi so sánh thêm