Làm thế nào để viết các bài kiểm tra đơn vị duy trì, không dễ vỡ cho GUI?


16

Tôi đã thử viết các bài kiểm tra đơn vị UI cho các ứng dụng GUI của mình và tôi gặp phải vấn đề là, mặc dù chúng hoạt động tốt khi tôi viết chúng, chúng hóa ra dễ vỡ và chúng bị hỏng bất cứ khi nào thiết kế thay đổi (nghĩa là khá thường xuyên). Tôi đang vật lộn để tìm một bộ hướng dẫn sẽ đưa tôi đến các bài kiểm tra đơn vị có thể duy trì cho GUI.

Hiện tại, một điều mà tôi phát hiện ra là các thử nghiệm nói rằng "thành phần này sẽ hiển thị dữ liệu đầu vào của nó ở đâu đó" là tốt (và điều đó rất dễ dàng với HTML). Các thử nghiệm kiểm tra trạng thái cụ thể của một bộ phận cụ thể của thành phần thường dễ gãy. Các thử nghiệm diễn ra như nhấp chuột nhấp chuột nhấp chuột, mong đợi theo dõi hành vi người dùng và logic nghiệp vụ cơ bản (là phần quan trọng nhất) thường trở nên dễ vỡ. Làm thế nào để tôi viết bài kiểm tra tốt?


Nói chính xác hơn, tôi muốn biết một số mẫu về những gì tôi có thể kiểm tra trong giao diện người dùng của mình, chứ không phải chính xác cách kiểm tra nó. Các quy ước đặt tên và định danh cố định là tốt, nhưng không giải quyết được vấn đề cốt lõi, đó là GUI thay đổi rất nhiều. Tôi muốn kiểm tra những hành vi khó có thể thay đổi nhất. Làm thế nào để tìm đúng thứ để kiểm tra?


1
@MichaelDurrant: Bạn đã chỉnh sửa câu hỏi về kiểm tra giao diện người dùng nói chung, trong khi ban đầu tôi hỏi về kiểm tra đơn vị. Tôi thấy các bài kiểm tra tích hợp khó hơn để duy trì và tôi thích các bài kiểm tra đơn vị hơn chúng, bất cứ khi nào có thể.
mik01aj

2
Tôi nghĩ rằng đây là một phần của vấn đề, về cơ bản, bạn không thể thực sự kiểm tra bất kỳ giao diện nào bằng cách kiểm tra đơn vị một mình vì lý do của họ là giao diện với thứ gì đó. GUI không khác nhau về mặt này.
jk.

m01, bạn có thể thay đổi nó trở lại. Tôi nghĩ về các bài kiểm tra UI như thường được kiểm tra tích hợp. Các thử nghiệm có xu hướng dựa vào dữ liệu hạt giống và vật cố hiện diện và giao diện người dùng làm việc với chúng. Nếu bạn có các bài kiểm tra UI thực sự không dựa vào bất kỳ dữ liệu nào khác là tuyệt vời. Tuy nhiên tôi đã thấy điều này là tương đối hiếm.
Michael Durrant

2
có liên quan nhưng không phải là một bản sao vì đây là về các bài kiểm tra gui: lập trình
viên.stackexchange.com/questions/109703/iêu

Câu trả lời:


3

Một vấn đề phổ biến với các bài kiểm tra GUI ... Lý do chính khiến các bài kiểm tra này được coi là dễ vỡ là vì chúng không thể tồn tại một thay đổi trong GUI không phải là thay đổi trong yêu cầu . Bạn nên cố gắng cấu trúc mã kiểm tra của mình theo cách sao cho một thay đổi trong GUI được tách biệt thành một nơi duy nhất trong các thử nghiệm.

Ví dụ, xem xét một bài kiểm tra có từ:

Khi người dùng nhập '999' vào trường số điện thoại và nhấp vào nút lưu, cửa sổ bật lên thông báo lỗi sẽ nói 'số điện thoại không hợp lệ'.

Rất nhiều chỗ ở đây để thử nghiệm này bị hỏng khi bạn làm lại giao diện, ngay cả khi yêu cầu xác nhận vẫn còn.

Bây giờ, hãy đặt điều này vào một từ ngữ thay thế nhỏ:

Khi người dùng nhập '999' dưới dạng số điện thoại và lưu trang hồ sơ, nó sẽ hiển thị lỗi 'số điện thoại không hợp lệ'

Bài kiểm tra là như nhau, các yêu cầu là như nhau, nhưng loại kiểm tra này sẽ tồn tại một sự thay đổi cho giao diện người dùng của bạn. Bạn sẽ cần phải thay đổi mã, rõ ràng, nhưng mã sẽ bị cô lập. Ngay cả khi bạn có mười hoặc hai mươi bài kiểm tra như vậy cho trang hồ sơ của mình và bạn di chuyển logic xác thực hiển thị lỗi của mình từ cảnh báo javascript sang jquery-popup chẳng hạn, bạn chỉ cần thay đổi phần kiểm tra duy nhất để kiểm tra thông báo lỗi.


4

Đây là một vấn đề phổ biến. Tôi sẽ chú ý đến:

  • Cách bạn đặt tên các yếu tố

    Sử dụng css id hoặc class để xác định các thành phần. Ưu tiên sử dụng CSS ID khi đối tượng là duy nhất. Hãy xem xét khung công tác bạn đang sử dụng, ví dụ với Ruby on Rails, namethuộc tính được gán tự động và có thể (không trực quan) tốt hơn so với sử dụng id hoặc lớp css

  • Làm thế nào bạn xác định các yếu tố.

    Tránh các định danh vị trí như table/tr/td/tdủng hộ các hình thức như td[id="main_vehicle"hoặc td[class='alternates']. Cân nhắc sử dụng các thuộc tính dữ liệu khi thích hợp. Thậm chí tốt hơn nên tránh các thẻ bố cục như <td>hoàn toàn để ở trên, bạn có thể thêm một khoảng và sử dụng nó, ví dụ <span id="main_vehicle">hoặc một bộ chọn ký tự đại diện, chẳng hạn như *[id="main_vehicle"]nơi *bây giờ có thể là div, span, td, v.v.

  • Sử dụng thử nghiệm các thuộc tính dữ liệu cụ thể chỉ được sử dụng cho qa và thử nghiệm.

  • Tránh trình độ không cần thiết cho các yếu tố. Bạn có thể thấy mình sử dụng như sau:

    body.main div#vehicles > form#vehicle input#primary_vehicle_name

    Tuy nhiên, điều này đòi hỏi trường đầu vào phải duy trì ở dạng có id chính xác của xe và trên trang có thân xe có lớp chính và div có id xe có dạng con ngay lập tức có id xe cộ. Bất kỳ thay đổi đối với bất kỳ cấu trúc đó và phá vỡ thử nghiệm. Trong trường hợp này bạn có thể thấy rằng

    input#primary_vehicle_name

    là đủ để xác định duy nhất các yếu tố.

  • Tránh các bài kiểm tra đề cập đến văn bản hiển thị. Văn bản trên trang được hiển thị cho người dùng thường thay đổi theo thời gian khi trang web được duy trì và cập nhật, vì vậy hãy sử dụng các định danh như css id và lớp css hoặc thuộc tính dữ liệu. Các yếu tố như form, inputselectđược sử dụng trong mẫu đơn này cũng là bộ phận không tốt của các yếu tố xác định, thường kết hợp với id hoặc class, ví dụ li.vehiclehoặc input#first-vehicle Bạn cũng có thể thêm định danh riêng của bạn, ví dụ <div data-vehicle='dodge'>. Bằng cách này, bạn có thể tránh sử dụng ID phần tử hoặc các lớp, có khả năng sẽ bị thay đổi bởi các nhà phát triển và nhà thiết kế. Theo thời gian, tôi thực sự thấy rằng tốt hơn là chỉ làm việc với các nhà phát triển và nhà thiết kế và thỏa thuận về tên và phạm vi. Thật khó

  • Làm thế nào dữ liệu cố định được duy trì.

    Tương tự như xác định các yếu tố thực tế, cố gắng tránh các bộ chọn mã hóa cứng nội tuyến xác định các giá trị có lợi cho các đối tượng trang - các đoạn văn bản nhỏ được giữ trong các biến hoặc phương thức và do đó có thể được sử dụng lại và cũng được duy trì tập trung. Ví dụ về các biến javascript theo mẫu này cho các giá trị được mã hóa cứng:

    storedVars["eqv_auto_year"] = "2015";
    storedVars["eqv_auto_make_1"] = "ALFA ROMEO";
    storedVars["eqv_auto_make_2"] = "HONDA";`  
    

    Thêm về các đối tượng trang tại tài liệu selenium wikiselenium

  • Giao tiếp với các nhà phát triển.

    Bất kể phương pháp kỹ thuật nào về 'nhà phát triển thực hiện thay đổi và phá vỡ tự động hóa QA' là vấn đề về quy trình làm việc. Bạn cần chắc chắn rằng: mọi người là một đội; nhà phát triển chạy các thử nghiệm tích hợp tương tự; các tiêu chuẩn được thống nhất và tuân theo bởi cả hai nhóm; định nghĩa thực hiện bao gồm chạy và có thể cập nhật các bài kiểm tra UI; các nhà phát triển và người thử nghiệm kết hợp với các kế hoạch kiểm tra và cả hai đều tham dự chải chuốt vé (nếu làm Agile) và nói về kiểm tra giao diện người dùng như một phần của việc chải chuốt. Bạn nên đảm bảo rằng bất kỳ cách tiếp cận và chiến lược nào bạn sử dụng để đặt tên đều được phối hợp với các nhà phát triển ứng dụng. Nếu bạn không vào cùng một trang, bạn sẽ thích xung đột với việc đặt tên đối tượng. Một số ví dụ về các phương thức đối tượng trang mà tôi đã tạo gần đây cho một dự án ruby:

    def css_email_opt_in_true
      'auto_policy[email_opt_in][value=1]'
    end 
    
    def css_phone_opt_in
      '*[name="auto_policy[phone_opt_in]"]'
    end 
    
    def css_phone_opt_in_true
      'input[name=phone_opt_in][value=true]'
    end 
    
    def css_credit_rating
      'auto_policy[credit_rating]'
    end
    

    Đây là các đối tượng trang giống như các biến javascript:

    storedVars["css_email_opt_in"] = "css=*[name='auto_policy[email_opt_in]']";
    storedVars["css_phone_opt_in"]="css=*[name='auto_policy[phone_opt_in]']";
    storedVars["css_phone_opt_in_true"]="css=input[name='phone_opt_in'][value=true]";
    storedVars["css_credit_rating"]="css=select[name='auto_policy[credit_rating]']";
    

2
Đây là những gợi ý hữu ích, và tôi thực sự đã làm theo hầu hết chúng. Vấn đề của tôi là, tôi viết các bài kiểm tra cho một số nút, và sau đó nút này bị xóa trong khi hành động tương tự được xử lý từ một nơi khác. Hoặc nút vẫn ở đó, nhưng nhãn thay đổi và nút cũng chạy một số hành động bổ sung.
mik01aj

1
Ahh, thật tốt khi biết điều đó. Vâng cho những thứ đó tôi sẽ tập trung vào quy trình làm việc và tương tác giữa nhà phát triển và tổ chức
Michael Durrant

1
Tôi cũng đang đăng thông tin cho những người khác tìm thấy câu hỏi của bạn và có thể không có tất cả các phần mà bạn có hoặc thậm chí không biết về họ.
Michael Durrant

1
Tôi đã mở rộng điểm bulllet cuối cùng của mình dựa trên phản hồi của bạn.
Michael Durrant

1
Và tôi đã cập nhật các phần về đặt tên và xác định các yếu tố và về việc không sử dụng văn bản hiển thị.
Michael Durrant

3

Lý do tại sao mọi người phát triển những thứ như MVC, MVP và người trình bày trước tiên, và các mẫu thiết kế tương tự, là để tách logic kinh doanh khỏi giao diện người dùng.

Rõ ràng, phần xem chỉ có thể được kiểm tra bằng cách khởi động chương trình và kiểm tra những gì nó hiển thị - nói cách khác, nó chỉ có thể được kiểm tra trong các thử nghiệm chấp nhận.

Mặt khác, kiểm tra logic kinh doanh có thể được thực hiện trong các bài kiểm tra đơn vị. Và đó là câu trả lời cho câu hỏi của bạn. Kiểm tra mọi thứ trong mô hình và nếu bạn có thể và muốn, bạn cũng có thể kiểm tra mã của bộ điều khiển.


GUI thay đổi rất nhiều

Điều đó chỉ có thể xảy ra khi bạn có yêu cầu thay đổi. Khi một yêu cầu thay đổi, không có cách nào xung quanh nó, ngoại trừ sửa đổi mã. Nếu bạn quản lý để tạo ra thiết kế và kiến ​​trúc tốt, sự thay đổi sẽ không lan truyền ở nhiều nơi.


2
Tôi nghĩ rằng đó là một điểm tốt. Có lẽ tôi chỉ đang làm sai MVC :) Btw, tôi tin rằng việc thay đổi yêu cầu là không thể tránh khỏi khi bạn phát triển một nền tảng web cho nhiều người dùng. Bạn không biết người dùng của mình sẽ hành xử thế nào cho đến khi họ bắt đầu sử dụng GUI.
mik01aj

2

Các thử nghiệm tương tác GUI không được giòn hơn hoặc ít hơn bất kỳ loại thử nghiệm nào khác. Đó là; nếu ứng dụng của bạn thay đổi theo một cách nào đó, các bài kiểm tra cần được cập nhật để phản ánh điều đó.

Để so sánh:

Kiểm tra đơn vị

Bản gốc : validateEmail()nên ném một InvalidDatangoại lệ. Mà được bao phủ chính xác trong bài kiểm tra đơn vị của bạn.

Thay đổi : validateEmail()nên ném một InvalidEmailngoại lệ. Bây giờ bài kiểm tra của bạn không chính xác, bạn cập nhật nó và mọi thứ lại xanh.

Kiểm tra GUI

Bản gốc : Nhập email không hợp lệ sẽ dẫn đến hộp lỗi bật lên có chứa "Dữ liệu không hợp lệ được nhập". Phát hiện chính xác bởi các xét nghiệm của bạn.

Thay đổi : Nhập email không hợp lệ sẽ dẫn đến lỗi nội tuyến có chứa "Email không hợp lệ được nhập". Bây giờ bài kiểm tra của bạn không chính xác, bạn cập nhật nó và mọi thứ lại xanh.


Hãy nhớ rằng bạn đang kiểm tra đầu vào và đầu ra - một số hành vi được xác định rõ. Bất kể đó là bài kiểm tra GUI hay bài kiểm tra Đơn vị hoặc bài kiểm tra Tích hợp, v.v.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.