Tại sao phải sử dụng framework cho kiểm thử tự động?

Hôm nay chúng tôi mang lại cho các bạn một chủ đề thú vị "Test Automation Framework" và "Tại sao chúng ta cần sử dụng framework để kiểm thư tự động

Câu trả lời đơn giản là: chúng tôi nên mang theo bản đồ khi đi lại và chúng tôi nên vẽ ra một bản thiết kết trước khi xây dựng một ngôi nhà.

Không thuyết phục sao?

Chúng ta hãy cố gắng tìm câu trả lời cho lý do tại sao nên sử dụng framework cho kiểm thử tự động- thông qua thảo luận kỹ lưỡng dưới đây.

Kiểm thử tự động không chỉ đòi hỏi về mặt kỹ thuật mà còn về mặt kinh tế. Nó thích hợp nhất cho các vùng nơi mà số lượng kiểm thử lớn phải lặp đi lặp lại nhiều vòng kiểm tra, tuy nhiên không nên thay thế kiểm thử tự động hoàn toàn.

Ngày nay, chúng ta biết rằng sự thành công của việc kiểm thử bằng tay hay tự động thì đều phụ thuộc chủ yếu vào việc lập kết hoạch kỹ lưỡng. Thông thường chúng ta dành 1/3 effort kiểm thử trên kế hoạch- đó là tiêu chuẩn. Kế hoạch này thường liên quan đến thông tin quản lý như ngày tháng, lịch trình, các mốc milestone, con người… Và kỹ thuật kiểm thử dựa trên các mốc deliverable, bao nhiêu chu kỳ, tool, data. Đối với một dự án tự động, một framework là một hướng dẫn thực hiện kỹ thuật. Có ba kỹ thuật trong một dự án tự động:

• Code-script
• Data
• Objects và định nghĩa của chúng trên AUT

Tại sao phải sự dụng framework để kiểm thử tự động

Hãy cố gắng tìm hiểu phần kỹ thuật tốt hơn:

Chúng ta đều biết rằng, một kịch bản tự động hóa tốt nên khởi động AUT, cung cấp dữ liệu, thực hiện các hoạt động, lặp / lặp lại chính nó như là đạo diễn, validate và close đóng AUT, kết quả báo cáo và cuối cùng là thoát. Vâng, đó là một đòi hỏi quá cao!

Một khi chúng ta tạo ra một kịch bản mà làm tất cả điều này, nó làm giảm thời gian cho việc thực hiện báo cáo .Tuy nhiên, hãy tưởng tượng bao lâu nó sẽ mất để viết một kịch bản hoàn hảo mà làm tất cả. Mất bao lâu sẽ có được để hiểu được mục tiêu kiểm tra, tìm ra một giải pháp, thực hiện nó trong mã, tùy chỉnh, gỡ lỗi và hoàn thiện?

Một ví dụ ở đây:

1. Gmail.com trang là AUT.

2. Tính năng để kiểm tra:

• Soạn email
• Tạo địa chỉ liên lạc
• Nhận email

3. Automation testers- giả sử mỗi người đang làm việc trên một tính năng

Vâng, đây là một chút của một qua ví dụ đơn giản. Nhưng cá nhân tôi cảm thấy rằng không có khái niệm trên trái đất mà không thể được chia nhỏ thành từng miếng dễ hiểu. Sau khi tất cả, trái đất được làm bằng các nguyên tử nhỏ. Bây giờ, các kịch bản cần phải có mã mà thực hiện các thao tác như sau:

Soạn email: Gmail.com launch-> Đăng nhập authorization-> Soạn email-> Soạn nội dung, đính kèm tập tin (thông số email) -> Gửi email-> Thoát Tạo địa chỉ liên lạc: Gmail.com launch-> Đăng nhập authorization-> Chọn contacts-> Tạo contact-> Save-> logout Email người nhận: Gmail.com launch-> đăng nhập authorization-> kiểm tra email-> đọc email-> logout Tất cả các kịch bản nêu trên phải được kiểm tra cho nhiều người dùng với nhiều tham số trong mỗi hoạt động.

Rõ ràng từ các đại diện ở trên các thành phần sau đây được định kỳ / lặp đi lặp lại:

1.Gmail.com lauch 2.Login 3.Logout Chúng ta có thể làm giảm đáng kể công sức và thời gian, nếu chúng ta tạo ra các component này một lần duy nhất và làm cho họ có sẵn cho tất cả các kiểm thử khác để sử dụng khi cần thiết - Có thể dùng lại - tạo một lần, gỡ lỗi một lần, hoàn thiện một lần và tái sử dụng nhiều lần.

Tái sử dụng cũng làm cho chắc chắn rằng nếu có sự thay đổi phải được thực hiện, nó có thể được thực hiện một cách tập trung.

Ví dụ, nếu gmail.com thay đổi trang chủ (thành phần đầu tiên trong mỗi kịch bản) -. Chúng tôi không cần phải sửa đổi từng kịch bản (3 lần trong trường hợp của chúng tôi) Chúng tôi chỉ đơn giản là có thể thay đổi nó một lần (trong thành phần tái sử dụng) và tất cả các kịch bản khác sử dụng nó sẽ tự động sử dụng mã thay đổi. Điều này làm giảm rework và đảm bảo rằng những thay đổi đó phù hợp với tất cả Tóm tắt-Mã nguồn và các đối tượng có thể được tối ưu hóa bằng cách tái sử dụng tối đa. Khi các component được làm để tái sử dụng:

a) Thứ tự phải chính xác theo follow phải được tuân thủ trong việc tạo ra chúng (bởi vi nếu chúng ta viết mã cho lần đăng nhập cuối cùng, tất cả các kịch bản khác mà cần phải bước mà có thể không được validate đầy đủ)

b) Tên định danh (có thể đọc được ) phải được gán

c) Lưu trữ ở một vị trí có thể truy cập và / hoặc có sẵn cho tất cả các kịch bản khác.

Tất cả các thông tin này về - Cái gì, ở đâu, như thế nào và khi nào nên thực hiện những factors- là một phần của một framework. Cuối cùng, dữ liệu Bạn có một tùy chọn để hard code dữ liệu của bạn vào mã / Script cái mà sẽ buộc bạn phải tạo ra một kịch bản mới mỗi khi một dữ liệu mới đã được cung cấp. Giải pháp - Tách dữ liệu từ mã . Sử dụng lại mã đến mức tối đa và cung cấp các dữ liệu riêng biệt. Một lần nữa, nơi bạn sẽ tìm thấy những thông tin chi tiết về cách thực hiện quyết định này? Framework.

Framework đóng một vai trò quan trọng trong việc xác định làm thế nào để tổ chức các dự án tự động hóa của bạn để tối đa hóa kết quả. Ngoài các vấn đề thảo luận ở trên, framework cũng có thể hướng dẫn việc kiểm tra tự động trên làm thế nào để thực hiện kịch bản, nơi lưu trữ kết quả, làm thế nào để trình bày chúng, vv .