Tôi làm việc trong một nhóm phát triển một trang web với số lượng lớn các trang. Anh chàng QA trong đội hiện đang chạy tất cả các bài kiểm tra bằng tay. Tôi đang nghĩ đến việc anh ta tạo ra một loạt các kịch bản Selenium. Tôi không nghĩ anh ta có thể tự động hóa tất cả các bài kiểm tra, nhưng anh ta có thể tự động hóa nhiều bài kiểm tra.
Bởi vì anh ta không có nền tảng lập trình, anh ta sẽ khó khăn thế nào để tạo và quản lý một loạt các tập lệnh Selenium? Những vấn đề anh ấy sẽ cần giúp đỡ?
Câu trả lời:
Tôi nghĩ Selenium như một công cụ "thu âm và phát lại" độc lập là lý tưởng cho người dùng không có kỹ thuật. Thành ngữ ghi lại đường dẫn của tôi và sau đó phát lại nó là trực quan, và giao diện, trong khi rõ ràng hướng đến những người không phải là người mới, không quá đáng sợ.
Selenium 2 / Selenium RC rõ ràng là một mức độ phức tạp cao hơn và tôi không nghĩ bạn có thể yêu cầu một người không lập trình giao diện với điều đó. (Thật ra tôi đã thất vọng với việc thiếu giao diện đầy đủ cho các ngôn ngữ không phải là Java. những gì bạn đang hỏi.)
Tôi nghĩ rằng nếu anh chàng thử nghiệm của bạn chưa biết về Selenium, anh ta sẽ hôn bạn trên miệng vì đã nói với anh ta về điều đó.
Selenium-IDE được thiết kế cho mục đích sử dụng bởi những người không lập trình. Nhưng kinh nghiệm của tôi là các tập lệnh được tạo ra theo cách đó (sử dụng XPath được tạo) rất dễ vỡ.
Vì vậy, tạo ra trong họ nên không có vấn đề gì cả. Quản lý sẽ không quá tệ nếu ứng dụng của bạn khá ổn định. Hoặc gần như không thể nếu ứng dụng của bạn đang được phát triển và / hoặc thay đổi thường xuyên.
Selenium-RC hoàn toàn là một công cụ dành cho nhà phát triển.
data-test-labelthuộc tính tùy chỉnh trên các phần tử. Tôi đã đưa nó lên GitHub, nhưng nó đã được thực hiện vào thời gian của công ty ...
Tôi thực sự khuyên bạn nên đặt câu hỏi này trên trang web beta Thử nghiệm & Đảm bảo Chất lượng Phần mềm hoặc tìm kiếm các câu hỏi tương tự đã được hỏi ở đó. Bạn sẽ tìm thấy một trải nghiệm sâu sắc hơn nhiều khi sử dụng Selenium cho QA thu âm và phát lại.
Câu trả lời của Eric là kinh nghiệm của hầu hết các Kỹ sư QA đã sử dụng các công cụ ghi và phát lại: Các bài kiểm tra kết quả rất dễ vỡ và khó bảo trì. Nhà phát triển có thể sử dụng Đối tượng Trang với Selenium RC để tạo bộ kiểm tra giao diện người dùng dễ bảo trì hơn nhiều và là một tùy chọn tốt hơn khi có sẵn.
Điều này không có nghĩa là Selenium IDE sẽ không hữu ích cho người thử nghiệm của bạn; tuy nhiên, tính hữu ích (và khả năng làm tổn thương các nỗ lực thử nghiệm thay vì trợ giúp) phụ thuộc rất nhiều vào mức độ cố định của UI. Bạn sẽ nhận được kết quả tốt nhất của mình với bản ghi và phát lại nếu UI có thể bị đóng băng sớm trong chu kỳ phát triển. Bạn có thể cần dạy cho người kiểm tra cách nhận XPath mới khi XPath cũ bị hỏng và cách nhận biết nếu thử nghiệm không thành công do thay đổi UI (vì XPath không còn hiệu lực) hoặc do lỗi chức năng.
Tôi nghĩ rằng sử dụng Selenium IDE tốt hơn là không tự động hóa cho bất kỳ dự án nào có giao diện người dùng ổn định chung. Chạy hàng trăm bài kiểm tra thủ công trên giao diện người dùng ổn định mỗi khi có một thay đổi nhỏ là thời gian thực. Chỉ cần đặt kỳ vọng phù hợp và nhận ra rằng việc thay đổi UI sẽ có tác động lớn hơn đáng kể đến lịch trình QA khi bạn bắt đầu sử dụng tự động hóa bản ghi và phát lại cho giao diện người dùng đó. Người kiểm tra của bạn có thể muốn chọn và chọn các khu vực họ tự động hóa một cách khôn ngoan.
Tôi không gặp vấn đề gì trong việc đào tạo dân gian không lập trình để viết các bài kiểm tra Selen với XPath tương đối trong Java / JUnit. Lập trình viên thiết lập nó và viết một mẫu thử nghiệm cơ bản, người thử nghiệm phát triển thêm các thử nghiệm - bằng cách ghi lại và sau đó tinh chỉnh chúng. Nếu người kiểm tra cần bất cứ điều gì cụ thể, anh ta yêu cầu lập trình viên viết nó. Người kiểm thử cần có kiến thức thực sự cơ bản về HTML và XPath, và một chút trợ giúp để nhận API Selenium (cũng như plugin Selenium cho Firefox và Fireorms).
Điều buồn cười là, lúc đầu tôi đã xem xét một thứ gì đó lạ mắt như Cucumber hoặc thứ gì đó tương tự, nhưng sự kết hợp Selenium / JUnit này đã chứng minh đủ tốt và đủ đơn giản. Thật kỳ lạ, những người thử nghiệm không có kinh nghiệm Java trước đó không gặp vấn đề nghiêm trọng nào khi viết các bài kiểm tra JUnit. Điều quan trọng duy nhất là lập trình viên có kinh nghiệm thiết lập thử nghiệm, để về cơ bản người thử nghiệm chỉ cần tạo ra các thử nghiệm mới và gọi các phương thức Selenium.
Xem xét sử dụng một khung kiểm tra dựa trên từ khóa. Ý tưởng là, các nhà phát triển phát triển các từ khóa cấp cao (hoặc bạn sử dụng các từ khóa có trong thư viện) và người kiểm tra chỉ cần lắp ráp các từ khóa này thành các trường hợp kiểm tra cấp cao.
Các đội tôi đã tham gia trong vài năm qua đã nhận được rất nhiều dặm từ phương pháp này. Chúng tôi sử dụng khung robot nhưng có những thứ khác như dưa chuột (được hỗ trợ bởi một số ngôn ngữ) và specflow (triển khai dưa chuột cho .net)
Ví dụ: sử dụng phương pháp này, người thử nghiệm của bạn có thể viết một bài kiểm tra giống như thế này:
| Login with valid credentials
| | Go to page | LoginPage
| | Login as a normal user
| | The current page should be | DashboardPage
Các từ khóa này có thể được viết bằng python (hoặc java hoặc ngôn ngữ .NET), như vậy:
class LoginPage(PageObject):
def login_as_a_normal_user(self):
username = self.browser.find_element_by_id("username")
username.send_keys(DEFAULT_USER)
password = self.browser.find_element_by_id("password")
password.send_keys(DEFAULT_PASSWORD)
... and so on...
Có một thư viện được tạo sẵn cho robot với các từ khóa chung dựa trên selenium ("đi đến trang", "trang nên chứa", "nút bấm", v.v.) mà người kiểm tra có thể ngay lập tức làm việc hiệu quả.
Thông thường các từ khóa chung này là đủ, nhưng sử dụng khái niệm về các đối tượng trang và từ khóa dành riêng cho trang là cách mạnh mẽ để viết bài kiểm tra. Các nhà phát triển của bạn có thể tạo một lớp cho mỗi trang trong ứng dụng của bạn và cho mỗi trang họ có thể viết các từ khóa có mục đích đặc biệt để người kiểm tra có thể tập trung nhiều hơn vào chức năng logic của trang thay vì triển khai thực tế.
Dưới đây là một vài bài đăng trên blog tôi đã viết mà đi sâu vào chi tiết hơn trong việc sử dụng các đối tượng trang với khung robot:
Chúng tôi thực sự đã có tình huống này xảy ra khi chúng tôi có một thành viên nhóm phi kỹ thuật (trong trường hợp này là một SQA không có nền tảng lập trình). Điều này không may đã không đi rất tốt.
Đầu tiên nhóm của chúng tôi đã thử các công cụ thu âm và chơi, nhưng như những người khác đã nói, các bài kiểm tra mà nó tạo ra rất dễ vỡ và khó bảo trì. Cuối cùng, SQA của chúng tôi đã rơi vào tình trạng chỉ đọc lại một bài kiểm tra mỗi khi nó thay đổi, điều đó không thực sự hiệu quả, đặc biệt là khi một thay đổi đã phá vỡ hầu hết các bài kiểm tra của chúng tôi (chúng tôi có một thay đổi trên trang chính của trang web của chúng tôi đã phá vỡ khoảng 60 % bài kiểm tra của chúng tôi).
Chúng tôi đã viết các bài kiểm tra Selen của chúng tôi bằng Java và SQA chưa bao giờ sử dụng Java trước đây, vì vậy anh ấy đã tự học nó. Chúng tôi thấy rằng các bài kiểm tra đã sử dụng một số thực tiễn lập trình thực sự kém:
assertTrue(false)dòng để chấm dứt kiểm traKhi tôi đến đội, SQA ban đầu đã rời đi và chạy bất kỳ bài kiểm tra nào dẫn đến một loạt các ngoại lệ giao diện điều khiển mà chúng tôi được yêu cầu bỏ qua. Sau đó, chúng tôi cố gắng thu hút các nhà phát triển tham gia và viết lại rất nhiều mã để làm cho nó thực sự hoạt động chính xác và có thể duy trì và dễ hiểu.
Tôi nghĩ rằng một số vấn đề có thể tránh được nếu chúng tôi có người kỹ thuật đến và giúp đỡ họ. Nếu họ đã giải thích tại sao các biến tĩnh công khai thay vào đó là các biến thể riêng tư hoặc cách JUnit hoạt động hoặc cách sử dụng WebDriverWait hoặc tại sao phân tán Thread.s ngủ () ở khắp mọi nơi là xấu, thì chúng ta có thể có mã tốt hơn.
Nhưng như là, chúng tôi đã xử lý mã mà cuối cùng không thể nhận ra và cuối cùng, chúng tôi chỉ viết lại phần lớn của nó, dẫn đến lãng phí lớn thời gian và tiền bạc.