Sự cần thiết của Framework cho Test Automation
Hôm nay, chúng tôi sẽ đem đến một chủ đề khá thú vị, đó là “Test Automation Framework” và “Tại sao chúng ta cần framework cho việc test automation” . Câu trả lời cũng đơn giản như lý do tại sao khi đi lại ta cần dùng bản đồ và khi xây nhà ta lại cần đến bản thiết kế. ...
Hôm nay, chúng tôi sẽ đem đến một chủ đề khá thú vị, đó là “Test Automation Framework” và “Tại sao chúng ta cần framework cho việc test automation”. Câu trả lời cũng đơn giản như lý do tại sao khi đi lại ta cần dùng bản đồ và khi xây nhà ta lại cần đến bản thiết kế.
Automation khó – không chỉ ở lĩnh vực kĩ thuật, mà cả kinh tế. Nó thích hợp nhất khi có những việc lặp đi lặp lại giữa các chu trình test. Automation testing sinh ra là để bổ sung chứ không hề thay thế được manual testing.
Giờ đây, testers biết rằng sự thành công của việc test (dù là manual hay automation) đều phụ thuộc phần lớn vào việc lập kế hoạch. Thông thường, theo tiêu chuẩn thì ta sẽ dành 1/3 tổng effort test cho việc lên kế hoạch. Việc lên kế hoạch này thường gồm hai phần: thông tin có tính quản lý (ngày tháng, schedule, milestones, thông tin con người) và thông tin có tính kỹ thuật liên quan đến testing (số chu trình, tool, data…). Đối với một dự án automation, framework là tất cả.
Ba thực thể kỹ thuật (resource) trong một dự án automation test gồm có:
- Code- script (Kịch bản)
- Data (Dữ liệu)
- Objects and their definition on the AUT (Các đối tượng và định nghĩa của nó trong UAT)
Tại sao lại cần Test Automation Framework?
Hãy cùng hiểu hơn về technical trước:
Chúng ta đều biết là một kịch bản automation tốt sẽ chạy AUT, cung cấp dữ liệu, thực hiện các hoạt động, tự lặp lại theo chỉ dẫn, xác nhận và đóng AUT lại, báo cáo kết quả và sau cùng sẽ thoát ra.
Khi mà ta đã tạo kịch bản thực hiện tất cả những điều trên, thời gian thực thi và báo cáo sẽ được giảm đi rất nhiều, về chỉ còn mili giây, chứ không phải là hàng phút hay hàng giờ nữa (đặc biệt là khi có liên kết đến một công cụ quản lý test nào đó). Sẽ không có sự bỏ lỡ bước nào trong quy trình và tránh được những lỗi chính tả, cho nên hiệu quả tổng thể sẽ được cải thiện.
Tuy nhiên, tưởng tượng xem tốn bao lâu để viết được một kịch bản hoàn hảo cho những việc trên, tốn bao lâu để hiểu mục tiêu test, để có được giải pháp, để cài đặt những thứ đó trong code, hoặc debug…? Như bạn thấy, nhân tố tốn thời gian thực sự, chính là lúc tạo script cho test. Kịch bản càng hiệu quả và ít tốn thời gian thì cơ hội thành công sẽ cao lên.
Xét ví dụ sau:
- Trang gmail.com là AUT.
- Tính năng cần test:
- Compose email/Soạn thư
- Create contacts/Tạo contact
- Receiving an email/Nhận thư
- Có nhiều automation testers, mỗi người làm việc với một tính năng ở trên.
Giờ thì, kịch bản sẽ phải có code thực hiện các hành động sau đây:
- Soạn thư: Gmail.com được mở lên -> Login -> Soạn email -> Viết nội dung, thêm tệp đính kèm -> Send email -> Logout
- Tạo contacts: Gmail.com được mở lên -> Login -> Chọn contacts -> Tạo contact -> Save -> Logout
- Nhận email: Gmail.com được mở lên -> Login -> Kiểm tra email -> Đọc email -> Logout
Tất cả kịch bản trên phải được test cho nhiều người dùng với các tham số khác nhau cho mỗi hành động.
Ta thấy rằng có vài việc lặp đi lặp lại trong các hành động trên:
- Gmail.com được mở ra
- Login
- Logout
Chúng ta có thể giảm đáng kể thời gian và effort nếu ta tạo ra thành phần chung cho mỗi lần chạy, tức là có tính Tái Sử Dụng, khi đó chỉ tạo 1 lần, debug 1 lần nhưng tái dùng nhiều lần.
Tính tái sử dụng cũng đảm bảo rằng nếu có sự thay đổi nào đó, thì chỉ cần thay đổi ở một nơi. Tức là có sự tập trung.
Ví dụ, nếu trang chủ của gmail.com thay đổi, ta không cần phải thay đổi trong từng kịch bản, mà chỉ cần sửa trong cái thành phần dùng chung.
Tổng kết lại – các tài nguyên Code và Đối tượng có thể được tối ưu lại để tăng tối đa tính tái sử dụng. Khi một thành phần có thể được tạo ra có khả năng tái sử dụng:
a) Một thứ tự chính xác các việc phải làm theo để tạo ra thành phần đó (bởi vì nếu ta viết code cho phần đăng nhập sau cùng, tất cả các kịch bản khác không thể được validated)
b) Cần có một cái tên cho thành phần đó
c) Được lưu trữ tại nơi có thể truy xuất bởi các kịch bản
Tất cả các thông tin này về WHAT, WHERE, HOW và WHEN là một phần của một framework.
Cuối cùng, đó là Dữ liệu. Bạn có thể lựa chọn việc hard-code dữ liệu trong code/script - tức là mỗi khi có dữ liệu mới thì phải thay đổi code/script. Giải pháp: tách dữ liệu ra khỏi code. Tái sử dụng code một cách tối đa và cung cấp dữ liệu một cách tách biệt. Một lần nữa, bạn sẽ thấy chi tiết về cách implement vấn đề này ở đâu? Đó là Framework.
Framework đóng vai trò chính trong việc xác định cách tổ chức 1 dự án automation để tăng tối đa hiệu quả. Ngoài những thứ được nêu ở trên, Framework có thể hướng dẫn automation testers cách thực thi script, chỉ chỗ lưu kết quả, làm thế nào để thực thi chúng...
Tóm lại, test automation framework là thứ bạn cần và có thể giúp đỡ bạn rất nhiều.
Bài tham khảo và dịch từ nguồn: http://www.softwaretestinghelp.com/why-do-we-need-test-automation-framework/