WatiN hay Selenium? [đóng cửa]

Tôi sẽ bắt đầu viết mã một số bài kiểm tra tự động cho bài thuyết trình của chúng tôi sớm. Dường như mọi người đều khuyên dùng WatiN và Selenium . Bạn thích kiểm tra tự động các mẫu web ASP.NET? Những sản phẩm này làm việc tốt hơn cho bạn?

Một lưu ý phụ, tôi nhận thấy rằng WatiN 2.0 đã có mặt trong CTP từ tháng 3 năm 2008, đó có phải là điều đáng quan tâm không?

Chỉ muốn nói rằng tôi hiện đang làm việc chăm chỉ cho phiên bản beta của WatiN 2.0 ở đâu đó trong Q1 năm 2009. Đây sẽ là một bản nâng cấp lớn cho các phiên bản CTP 2.0 hiện tại và về cơ bản sẽ cung cấp cho bạn chức năng tương tự để tự động hóa FireFox và IE như phiên bản 1.3.0 cung cấp để tự động hóa IE.

Vì vậy, không có mối quan tâm ở đó.

Hy vọng điều này sẽ giúp bạn lựa chọn Jeroen van Menen Chì dev WatiN

Nếu bạn đang muốn đầu tư dài hạn nghiêm túc vào một khuôn khổ sẽ tiếp tục được cải thiện và hỗ trợ bởi cộng đồng, Selenium có lẽ là lựa chọn tốt nhất của bạn. Ví dụ: tôi vừa xem thông tin này trên blog của Matt Raible:

Tính đến thứ Sáu, Google có hơn 50 đội chạy hơn 51 nghìn bài kiểm tra mỗi ngày trên trang trại Selenium nội bộ. 96% các thử nghiệm này được xử lý bởi Selenium RC và các máy Farm. 4% khác là một phần do lỗi RC, một phần để kiểm tra lỗi, nhưng việc cách ly nguyên nhân có thể khó khăn. Selenium đã được sử dụng làm công nghệ chính để thử nghiệm chức năng các ứng dụng web trong Google. Đó là tin tốt.

Gần đây tôi cũng đã đến một trong những cuộc gặp gỡ Selenium và được biết rằng Google đang đưa các nguồn lực nghiêm túc vào việc cải thiện Selenium và tích hợp nó với WebDriver, một công cụ kiểm tra tự động được phát triển bởi Simon Stewart. Một trong những ưu điểm chính của WebDriver là nó kiểm soát chính trình duyệt thay vì chạy bên trong trình duyệt dưới dạng ứng dụng Javascript, điều đó có nghĩa là các vấp ngã lớn như vấn đề "cùng nguồn gốc" sẽ không còn là vấn đề nữa.

Chúng tôi đã thử nghiệm cả hai và quyết định đồng hành cùng WaTiN. Như những người khác đã chỉ ra, Selenium có một số tính năng hay không có trong WaTiN, nhưng chúng tôi gặp vấn đề khi Selenium hoạt động và một khi chúng tôi đã làm điều đó thì chắc chắn sẽ chậm hơn khi chạy thử nghiệm so với WaTiN. Nếu tôi nhớ chính xác, các vấn đề thiết lập mà chúng tôi gặp phải xuất phát từ việc Selenium có một ứng dụng riêng để kiểm soát trình duyệt thực tế nơi WaTiN đã làm mọi thứ trong quá trình.

Tôi đã cố gắng cả hai và đây là những suy nghĩ ban đầu của tôi ...

WatiN

Tốt

• Thi công nhanh.
• Các công cụ tạo tập lệnh là các dự án độc lập; có 2 cái mà tôi biết: Wax (dựa trên Excel, được lưu trữ trên CodePlex) và WatiN Test Record (được lưu trữ trên SourceForge). Không mạnh mẽ như Selenium IDE.
• Hỗ trợ IE rất tốt. Có thể đính kèm và tách ra / từ các trường hợp đang chạy. Có thể truy cập tay cầm cửa sổ gốc, vv (Xem ví dụ tập lệnh bên dưới).
• NuGet được đóng gói, dễ dàng chạy trong môi trường .NET, kiểu Visual Studio và luôn cập nhật.

Những người xấu

• Googling WatiN (watin xyz) thường khiến Google đề xuất "watir xyz" thay thế. Không có nhiều tài liệu ra khỏi đó.
• Những gì có ít (tài liệu), nó là khó hiểu; ví dụ: lúc đầu, có vẻ như không có hỗ trợ riêng cho các bộ chọn CSS. Đặc biệt là có các thư viện tiện ích mở rộng như 'WatiNCssSelectorExtensions' và nhiều bài viết trên blog về các kỹ thuật thay thế (chẳng hạn như tiêm jQuery / sizzle vào trang). Trên Stack Overflow, tôi đã tìm thấy một bình luận của Jeroen van Menen trong đó gợi ý rằng có sự hỗ trợ riêng. Ít nhất là nhà phát triển chính dành thời gian cho Stack Overflow :)
• Không hỗ trợ XPath riêng.
• Không có thực thi từ xa / thực hiện dựa trên lưới.

Ví dụ tập lệnh (C #). Bạn không thể làm điều này với Selenium (ít nhất là tôi không biết), ít nhất):

class IEManager
{
    IE _ie = null;
    object _lock = new object();

    IE GetInstance(string UrlFragment)
    {
        lock (_lock)
        {
            if (_ie == null)
            {
                var instances = new IECollection(true);  //Find all existing IE instances
                var match = instances.FirstOrDefault(ie=>ie.Url.Contains(UrlFragment));
                _ie = match ?? new IE();
                if (match==null)  //we created a new instance, so we should clean it up when done!
                    _ie.AutoClose = true;
            }
        }

        return _ie;
    }
}

Selen

• Chậm hơn WatiN (đặc biệt là khi một quy trình mới phải được tạo ra).
• Bộ chọn CSS / XPath tích hợp hỗ trợ.
• Selenium IDE là tốt (không thể nói tuyệt vời, nhưng nó là tốt nhất trong lớp!).
• Cảm thấy Java-ish nhiều hơn .NET-ish ... nhưng thực sự, đó là ngôn ngữ lập trình bất khả tri; tất cả các lệnh được gửi đến một 'Trình điều khiển' ngoài quy trình. Trình điều khiển thực sự là một quá trình 'máy chủ' cho phiên bản trình duyệt. Tất cả các giao tiếp phải được nối tiếp vào / ra qua các ranh giới quá trình, điều này có thể giải thích các vấn đề tốc độ liên quan đến WatiN.
• Các quy trình tách rời - "Trình điều khiển" và "Điều khiển" có nghĩa là mạnh mẽ hơn, phức tạp hơn, v.v., nhưng cũng dễ dàng hơn để tạo lưới / môi trường kiểm tra phân tán. Sẽ thực sự thích nó nếu cơ chế "phân phối" (tức là giao tiếp giữa Driver & Control) trên khắp WebSphere hoặc trình quản lý hàng đợi tin nhắn mạnh mẽ, hiện có khác.
• Hỗ trợ chrome và các trình duyệt khác ra khỏi hộp.

Bất chấp tất cả, cuối cùng tôi đã đi với WatiN; Tôi chủ yếu có ý định viết các ứng dụng quét màn hình nhỏ và muốn sử dụng LINQPad để phát triển. Đính kèm với một cá thể IE từ xa (một ví dụ mà tôi không tự sinh ra) là một điểm cộng lớn. Tôi có thể nghịch ngợm trong một trường hợp hiện có ... sau đó chạy một chút kịch bản ... rồi lại tiếp tục v.v ... Điều này khó thực hiện hơn với Selenium, mặc dù tôi cho rằng "tạm dừng" có thể được nhúng vào tập lệnh trong thời gian tôi có thể Fiddle trực tiếp với trình duyệt.

Sự khác biệt lớn nhất là Selenium có hỗ trợ cho các trình duyệt khác nhau (không chỉ IE hay FF, xem http://seleniumhq.org/about/pl platforms.html# browsers .

Ngoài ra, Selenium có một máy chủ điều khiển từ xa ( http://seleniumhq.org/projects/remote-control/ ), có nghĩa là bạn không cần chạy trình duyệt trên cùng một máy mà mã kiểm tra đang chạy. Do đó, bạn có thể kiểm tra ứng dụng Web của mình. trên các nền tảng HĐH khác nhau.

Nói chung tôi sẽ khuyên bạn nên sử dụng Selenium. Tôi đã sử dụng WatiN vài năm trước, nhưng tôi không hài lòng với sự ổn định của nó (có lẽ nó đã được cải thiện). Điểm cộng lớn nhất cho Selenium đối với tôi là việc bạn có thể kiểm tra ứng dụng Web. trên các trình duyệt khác nhau.

Cũng không. Sử dụng Coypu. Nó kết thúc Selenium. Bền hơn nhiều. https://github.com/featurist/coypu

Cập nhật Ye Oliver bạn đúng. Ok tại sao nó tốt hơn? Cá nhân tôi thấy trình điều khiển Selenium cho IE đặc biệt rất mong manh - có một số trường hợp ngoại lệ 'tiêu chuẩn' mà tôi đã tìm thấy một lần nữa khi lái Selenium cho Bài kiểm tra đơn vị trên các trang web nặng ajax.

Tôi đã đề cập đến việc tôi muốn viết các kịch bản của mình trong c # dưới dạng Dự án thử nghiệm chưa? Có Kiểm tra chấp nhận trong một triển khai xây dựng liên tục.

Coypu thỏa thuận với ở trên. Đó là một trình bao bọc cho Selenium cho phép các đồ đạc thử nghiệm như,

browser.Visit("file:///C:/users/adiel/localstuff.htm")
browser.Select("toyota").From("make");
browser.ClickButton("Search");

... sẽ quay một trình duyệt (thương hiệu có thể định cấu hình) và chạy tập lệnh. Nó hoạt động tuyệt vời với các khu vực có phạm vi và RẤT có thể mở rộng.

Có nhiều ví dụ tại GitHub và như Olvier dưới đây đề cập, video của Adrian rất tuyệt vời. Tôi nghĩ rằng đó là cách tốt nhất để lái các bài kiểm tra dựa trên trình duyệt trong thế giới .Net và cố gắng làm theo tên của Rubycapybara

Tôi đã sử dụng cả hai, cả hai dường như hoạt động tốt. Cái gật đầu của tôi là dành cho Selenium vì nó dường như có sự hỗ trợ Ajax tốt hơn. Tôi tin rằng WaTiN đã trưởng thành mặc dù kể từ lần cuối tôi sử dụng nó nên nó sẽ có cùng một thứ.

Điều lớn nhất sẽ là môi trường phát triển nào bạn muốn ở? Selenium và Watin có máy ghi âm nhưng Selenium nằm trong trình duyệt và watin nằm trong phòng thu trực quan. + và-cho cả hai.

Cho đến bây giờ, chúng tôi là một Microsoft Shop thuần túy để cung cấp các giải pháp cho doanh nghiệp và đã đồng hành cùng WatiN. Nó có thể thay đổi tương lai.

Là một nguồn gần đây hơn:

Microsoft đã in trên Tạp chí MSDN 12/2010 một BDD-Primer với sự kết hợp của SpecFlow với WatiN (Phát triển theo hướng hành vi của BDD-mát mẻ). Tác giả của nó Brandon Satrom (Nhà phát triển truyền giáo msft) cũng đã đăng vào tháng 12 năm 2010 một bài giảng trên Webcast chi tiết 1: 1 những phát hiện trên của mình.

Có một Whitepaper từ 04/2011 về Hỗ trợ ATDD / BDD với SpecLog, SpecFlow và Team Foundation Server (Phát triển theo hướng chấp nhận thử nghiệm / Phát triển hướng hành vi) từ Christian Hassa , nhóm đã xây dựng SpecFlow.

Tôi sử dụng Watin, nhưng chưa sử dụng Selenium. Tôi có thể nói rằng tôi đã đứng dậy và chạy nhanh trên Watin và không có vấn đề gì. Tôi không thể nghĩ ra bất cứ điều gì tôi muốn làm mà tôi không thể tìm ra với nó. HTH

Tôi thường sử dụng Selenium, chủ yếu vì tôi thích plugin Selenium IDE cho FireFox để ghi điểm bắt đầu cho các thử nghiệm của tôi.

Tôi khuyên dùng WebAii vì đó là những gì tôi đã có bất kỳ thành công nào và khi sử dụng nó, sự hiểu biết của tôi rất ít. Tôi chưa bao giờ thử Selenium và tôi không nhớ sử dụng WaTiN nhiều, ít nhất là không đến mức tôi có thể đưa nó vào công việc thành công. Tôi không biết bất kỳ khuôn khổ nào liên quan đến các hộp thoại Windows một cách duyên dáng, mặc dù WebAii có giao diện để thực hiện các trình xử lý hộp thoại của riêng bạn.

Tôi cân nhắc sử dụng cả hai. Tôi đã sử dụng máy ghi âm cho Selenium để xây dựng một số thử nghiệm trong FF. Tôi đã thử làm điều tương tự trong Watin và thấy rằng Trình ghi Watin (2.0.9.1228) hoàn toàn vô giá trị đối với các trang web của chúng tôi . Nó dường như được hiển thị trang web trong IE6 - làm cho trang web của chúng tôi không thể sử dụng để ghi lại. Chúng tôi không hỗ trợ IE6. Tôi không thể tìm thấy bất kỳ cách nào để thay đổi trình duyệt mà nó đang sử dụng. Tôi chỉ tìm thấy một máy ghi âm Watin ngoài kia. Nếu có nhiều hơn một hoặc một trong số đó được cập nhật, xin vui lòng bình luận.

IDE ghi Selenium cho Firefox rất dễ sử dụng và chuyển các bài kiểm tra sang C #. Nó không tuyệt vời ở đây. Tôi không thể có bộ kiểm thử porting để làm việc, mặc dù đọc một hoặc hai bài đăng trên blog có cách giải quyết. Vì vậy, có một chút thao tác của mã được tạo. Tuy nhiên, nó hoạt động 90% và tốt hơn so với giải pháp thay thế.

Đối với tiền / thời gian của tôi, Selenium vượt trội chỉ vì dễ dàng xây dựng các bài kiểm tra mới . IE không có bất kỳ thanh công cụ phát triển tốt nào có thể hoạt động tốt như Fireorms , vì vậy tôi bắt đầu phát triển Firefox của mình, vì vậy có một trình ghi hoạt động tốt trong Firefox là một phần thưởng rất lớn.

Kết luận của tôi ở đây rất giống với trích dẫn dân chủ của Churchill: Selenium là hình thức thử nghiệm UI tự động tồi tệ nhất. Ngoại trừ tất cả những người khác.

Có nguy cơ đi tiếp tuyến, tôi khuyên dùng Ax / WatiN. Axe cho phép các bài kiểm tra được viết bằng Excel bằng 'Trình kiểm tra' thủ công không có kiến ​​thức về 'ngôn ngữ' kiểm tra cơ bản. Nó cần một 'Kỹ thuật viên' để viết các hành động bespoke (IE. Hôm nay tôi phải thực hiện tra cứu & tham chiếu chéo bảng hơi phức tạp) nhưng một khi đã viết các hành động có thể được sử dụng trong các thử nghiệm của những người thử nghiệm không có kỹ thuật.

Tôi cũng nghe nói rằng dự án Cổng Chính phủ Vương quốc Anh (mà tôi tin rằng đã có các bài kiểm tra tự động 6K +) gần đây đã chuyển tất cả các bài kiểm tra của họ từ Ax / Winrunner sang Ax / Watin trong vòng một tuần !! Và nhiều bài kiểm tra khá phức tạp - tôi biết khi tôi làm việc với nó vài năm trước ...

Hiện tại tôi đang xem Selenium, vì một Khách hàng tiềm năng sử dụng nó. Nhưng tôi thực sự đề nghị một cái nhìn nhỏ bé về Axe như một lớp phía trên công cụ 'ngựa làm việc'.

Nếu bạn phải truy cập iframe, hộp thoại phương thức và iframe tên miền WatiN là một cách để đi. Selenium không thể xử lý các iframe mà nó đang ném ngoại lệ ra lệnh. WatiN bạn có thể làm nhiều thứ hơn nữa, đặc biệt nếu trang web sử dụng các công cụ cụ thể của IE như ShowModalDialog, v.v. WatiN xử lý tất cả chúng rất tốt. Tôi thậm chí có thể thực hiện truy cập iframe tên miền.

Bạn sẽ phải làm cả hai nếu bạn cần làm thử nghiệm IE và FF, nhưng chúng chỉ hoạt động rất tốt để thử nghiệm trình bày. Họ không thể phát hiện nếu một yếu tố hơi tắt, chỉ là các yếu tố có mặt. Tôi không biết bất cứ điều gì có thể thay thế mắt người để kiểm tra giao diện người dùng / trình bày, mặc dù bạn có thể làm một số điều để hỗ trợ nó (chụp ảnh màn hình của các trang ở mỗi bước để người dùng xem xét).