2012-05-11 15 views
5

Để tất cả các chuyên gia tự động hóa thử nghiệm :-)! Tôi muốn nghe ý kiến ​​của bạn về kịch bản sau:Thử nghiệm ứng dụng web bằng FitNesse và soapUI - bất kỳ phương pháp hay nhất nào về quản lý và bảo trì kiểm tra?

Có một ứng dụng web mà tôi cần kiểm tra. Tôi phải chạy thử nghiệm back-end trên máy chủ và kiểm tra front-end trên máy khách. Tôi cũng cần chạy thử nghiệm từ đầu đến cuối, liên quan đến cả back-end và front-end.

Máy chủ hiển thị các dịch vụ web (SOAP) và máy khách phía trước tiêu thụ dữ liệu từ các dịch vụ này. Ngoài ra còn có các khách hàng bên thứ ba tiêu thụ dữ liệu từ các dịch vụ web. Đôi khi, một kịch bản thử nghiệm yêu cầu tôi thực hiện các kiểm tra từ đầu đến cuối, tức là tôi thực hiện một số thay đổi trong GUI mặt trước và sau đó sử dụng dịch vụ web trên back-end để tìm hiểu xem các thay đổi có thành công hay không.

Tôi thích FitNesse - theo ý kiến ​​của tôi, sự tách biệt WHAT và WHY khỏi HOW là cần thiết để thiết kế các thử nghiệm tốt. Có mô-đun Selenesse, làm cho nó có thể tích hợp các bài kiểm tra Selenium với các trang wiki FitNesse. Điều này làm cho nó dễ dàng để mô tả những gì và tại sao tôi cần phải kiểm tra một cái gì đó (wiki văn bản) từ cách tôi muốn kiểm tra nó (kịch bản bảng và bảng kịch bản) mà là làm thế nào tôi muốn mọi thứ được.

Vấn đề với FitNesse là nó hơi cồng kềnh để kiểm tra các dịch vụ web SOAP. Hoặc là, tôi cần phát triển một ứng dụng khách Java SOAP có mục đích, hoặc tôi phải viết các đồ đạc Java mở rộng lớp ServiceFixture, được viết cho FIT. Dù bằng cách nào, nỗ lực phát triển lớn hơn đáng kể so với nếu tôi thực hiện các thử nghiệm này trong soapUI. Theo quan điểm của tôi, nhược điểm của soapUI, là không có cách nào dễ dàng giải thích WHAT và WHY của một bài kiểm tra (ít nhất là không theo cách trực quan). Vì vậy, giả sử tôi muốn có một nỗ lực phát triển hợp lý cho thử nghiệm từ đầu đến cuối, tôi đã giải quyết cho cách tiếp cận của việc viết các kiểm tra GUI trong FitNesse/Selenesse và các kiểm tra back-end trong soapUI. Bây giờ tôi có sự lựa chọn của cố gắng để chạy các xét nghiệm soapUI từ FitNesse, quản lý tất cả các xét nghiệm ở đó, hoặc để chạy các xét nghiệm FitNesse từ soapUI ...

Tôi có một số lo ngại về quản lý kiểm tra (không dễ dàng để xem kết quả thử nghiệm một cái nhìn) và duy trì (hai công cụ với các laguage khác nhau) của phương pháp này. Bạn có ý tưởng nào về thực tiễn tốt nhất/tốt về vấn đề này không? Bạn có đề xuất công cụ thứ ba để quản lý hai công cụ khác không?

Trả lời

1

Bạn có sử dụng bất kỳ công cụ tích hợp liên tục nào như hudson, tre không?

Tôi đang đặt câu hỏi này vì tôi đề nghị bạn thích cách tiếp cận tích hợp liên tục để bạn có thể có cơ hội tự động kiểm tra các ứng dụng sau mỗi lần commit/build.

Ý tôi là nếu bạn sử dụng hudson hoặc tre, bạn có thể có cơ hội chạy thử nghiệm của mình sau khi nhà phát triển cam kết bất kỳ điều gì. Và bổ sung bạn có thể chạy thử nghiệm của bạn theo lịch trình.

Một lợi thế khác là, các công cụ này (hudson/tre) có thể ghi lại các tập lệnh thử nghiệm và có thể gửi email trong trường hợp thất bại/thành công (lựa chọn của bạn). Vì vậy, bạn có thể theo dõi các bài kiểm tra của mình dễ dàng.

Và bạn cũng có cơ hội thr để chạy selen và soapUI song song hoặc liên tục.


Tôi cũng có một số đề xuất về kiểm tra soapUI.

Bạn càng có nhiều trường hợp thử nghiệm, bạn càng cần nhiều thời gian để phát triển, thực thi và duy trì chúng. Điểm quan trọng là xem xét khả năng bảo trì trong khi thiết kế các thử nghiệm.

Nếu một ứng dụng có sẵn nhiều dịch vụ web, WSDL bị ràng buộc thay đổi và cần được cập nhật trong SoapUI. Với mọi thứ trong một dự án soapUI bạn chỉ cần cập nhật WSDL ở một nơi, không phải trong nhiều dự án. Vì vậy, chỉ tạo một dự án soapUI cho một ứng dụng.

Sau đó, bạn cần tạo bộ thử nghiệm và các trường hợp kiểm tra.

Bao gồm tất cả các luồng chính của dịch vụ (kịch bản thành công) chỉ trong một bộ kiểm tra hồi quy. Yêu cầu của các dịch vụ web phải được sắp xếp theo luồng kinh doanh hợp lý. Ví dụ: nếu bạn kiểm tra các dịch vụ web của một cửa hàng trực tuyến, trước tiên bạn cần tìm kiếm mục đó và sau đó mua nó. Nếu bạn giữ trật tự kinh doanh hợp lý này trong các thử nghiệm soapUI của bạn, bạn có thể dễ dàng thiết lập một biến toàn cầu duy nhất cho mỗi bước kiểm tra. Ý tôi là, ở bước đầu tiên, bạn có thể tìm kiếm mục X sau đó mua cùng một mục, theo cách này cho phép thiết lập biến toàn cục cho mục X. Việc duy trì hoặc mở rộng dự án soapUI đó dễ dàng hơn. Bạn có cơ hội tạo nguồn dữ liệu và thu thập các biến (các mục khác nhau trong ví dụ cửa hàng trực tuyến của chúng tôi) và mở rộng phạm vi cho các mục đó trong một vòng lặp.

+0

Rất tiếc, xin lỗi vì đã trả lời muộn! Cảm ơn rất nhiều cho lời khuyên của bạn, tôi sẽ cố gắng tiếp cận của bạn :-). –

+0

:) bạn được chào đón – Suha

0

Tôi khuyên bạn nên tạo bộ thử nghiệm với soapui và báo cáo kết quả kiểm tra bằng jenkins.

Bạn có thể thực hiện các thử nghiệm soapui và thử nghiệm fitnesse với tệp kết quả thử nghiệm jenkins và genrate xml. Thiết lập này thực sự hữu ích khi xây dựng các thử nghiệm end2end. Chúng tôi có thể kết hợp bất kỳ bộ testet hoặc bộ kiểm thử nào cùng với Jenkins thực sự tốt và bạn phải có cách trình bày và duy trì kết quả kiểm tra tuyệt vời.

Khi tập trung vào một thành phần làm việc, hoàn thành công việc trong chạy nước rút hoặc ứng dụng hoàn chỉnh không đủ ổn định để đầu tư một lượng lớn nỗ lực trong thử nghiệm end2end. Tôi nghĩ bạn nên tập trung vào kiểm tra soapui làm việc riêng.

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