tôi đã viết một bài đăng blog về cách làm này, bạn có thể tìm thấy hữu ích
http://rburnham.wordpress.com/2011/03/15/bdd-ui-automation-with-specflow-and-coded-ui-tests/
của pro và con của Coded UI thử nghiệm mà tôi có thể nghĩ ra được thử nghiệm của bạn ứng dụng chính xác cách thức người dùng sẽ đang sử dụng nó. Điều này là tốt cho thử nghiệm chấp nhận nhưng nó cũng có những hạn chế của nó. Nó cũng thực sự tốt cho kết thúc để kiểm tra kết thúc. Trong các thử nghiệm giao diện người dùng trước đây đã được biết là mong manh. Ví dụ: khi MS tạo giao diện người dùng VS2010, hầu như tất cả các kiểm tra giao diện người dùng đều bị hỏng. Lý do chính là thay đổi công nghệ. Kiểm tra giao diện người dùng được mã hóa giúp hạn chế điều này xảy ra theo cách nó khớp với một điều khiển. Nó sử dụng nhiều hơn một kết quả dựa trên xác suất. Điều này có nghĩa là nó sẽ cố gắng tìm ra kết quả phù hợp nhất dựa trên thông tin mà nó có như tên điều khiển. Đối với chúng tôi, kiểm tra giao diện người dùng được mã hóa là sự lựa chọn của chúng tôi do các giới hạn về công nghệ. Ứng dụng cũ của chúng tôi là VB và mặc dù CUIT không hoạt động tốt, tôi đang trong quá trình viết phần mở rộng để có được thông tin kiểm soát tốt hơn, đó vẫn là lựa chọn duy nhất của chúng tôi. Cũng nên nhớ CUIT là mới và có những hạn chế riêng của nó. Bạn nên chuẩn bị để được cấu trúc theo cách bạn đặt dự án của mình như duy trì các UIMaps của bạn có thể là một chút công việc thủ công do hành vi kết thúc hiện tại đến cuối trong VS2010, ví dụ như tạo CUIT từ một bản ghi hành động hiện tại. thử nghiệm trong một UIMap được gọi là UIMap.uitest và không có cách nào để thay đổi điều đó hoặc chuyển sang một UIMap khác. Nếu bạn sử dụng nhiều bản đồ ui, điều này có nghĩa là bạn sẽ cần phải ghi lại các bước của mình trước và sau đó sử dụng chúng trong thử nghiệm của bạn. Tuy nhiên đang ở trong .net nó vẫn rất linh hoạt.
Cho đến nay điều tốt nhất về luồng là cú pháp gerkin của nó cho tài liệu dễ đọc và sống. Thông thường các tính năng hoặc hành vi thử nghiệm của ứng dụng của bạn là nơi giá trị đến từ Nó thường nhắm đến việc kiểm tra ngay bên dưới giao diện người dùng. Có một chút ít cơ hội của việc kiểm tra phá vỡ khi giao diện người dùng thay đổi ở đây nhưng ở đó. Specflow cho tôi là tuyệt vời khi ứng dụng của bạn đang được thay đổi liên tục và bạn muốn đảm bảo các tính năng hiện có vẫn hoạt động. Nó phù hợp tốt trong môi trường Scrum cũng như nơi bạn có thể viết kịch bản của bạn như là một mô tả về cách nó hoạt động. Một giới hạn cho specflow tôi có thể thấy là mở của nó để giải thích. Bởi vì điều này có thể dễ dàng để viết một bài kiểm tra mà không phải là rất tái sử dụng và khó khăn để duy trì. Tôi thích sử dụng các thuật ngữ chung chung hơn để mô tả các bước của tôi như "Đăng nhập với tư cách User1" thay vì "Truy cập Trang Đăng nhập, Nhập Tên người dùng và Mật khẩu, Nhấp vào đăng nhập". Mô tả nó chi tiết hơn làm cho việc sử dụng lại các cặp vợ chồng chặt chẽ đến giao diện người dùng trở nên khó khăn hơn. Làm thế nào đăng nhập thực sự làm việc nên được lên đến mã phía sau không phải là tính năng specflow.
Kết hợp 2 tuy nhiên với chúng tôi có vẻ có lợi hơn so với chỉ sử dụng Kiểm tra giao diện người dùng được mã hóa. Nếu chúng tôi quyết định thay đổi hoàn toàn giao diện người dùng, chúng tôi sẽ có ít nhất hành vi được dự kiến được lưu trữ trong các tính năng của chúng tôi theo cách mà mọi người đều có thể hiểu. Cuối cùng, bạn cần phải xem xét cách ứng dụng sẽ phát triển và loại ứng dụng.
Nguồn
2011-08-19 04:38:58