Các nhóm thường nói họ "sử dụng tự động hóa" như thể điều đó đã giải quyết được câu hỏi về cách tổ chức các bài kiểm tra của họ. Thực tế không phải vậy. Hai bộ kiểm tra đều có thể được tự động hóa nhưng vẫn có cấu trúc hoàn toàn khác nhau, với chi phí bảo trì cũng khác biệt hoàn toàn. Cấu trúc chính là khuôn khổ, và loại khuôn khổ bạn chọn sẽ định hình tốc độ phát triển của các bài kiểm tra, mức độ dễ dàng để những người không phải lập trình viên đóng góp, và mức độ ảnh hưởng của một thay đổi nhỏ về giao diện người dùng đến mã của bạn.
Bài viết này sẽ đi sâu vào sáu loại khuôn khổ kiểm thử tự động hóa cổ điển: tuyến tính, mô-đun, hướng dữ liệu, hướng từ khóa, lai ghép, và hướng hành vi. Nó giải thích từng loại là gì, điểm mạnh và điểm yếu của từng loại, để bạn có thể chọn một cấu trúc phù hợp với nhóm của mình thay vì thừa hưởng bất cứ thứ gì mà kỹ sư trước đó đã thiết lập. Các khái niệm này áp dụng cho kiểm thử giao diện người dùng (UI), API và kiểm thử đơn vị (unit testing) như nhau.
Khuôn khổ kiểm thử tự động hóa là gì
Khuôn khổ kiểm thử tự động hóa là một tập hợp các hướng dẫn, quy ước và các thành phần có thể tái sử dụng, định nghĩa cách các bài kiểm tra tự động được viết, tổ chức và thực thi. Nó không phải là một công cụ bạn cài đặt. Nó là kiến trúc mà các bài kiểm tra của bạn nằm bên trong.
Một khuôn khổ trả lời các câu hỏi về cấu trúc trước khi bất kỳ ai viết một bài kiểm tra. Dữ liệu kiểm tra nằm ở đâu? Các bước có thể tái sử dụng được chia sẻ như thế nào? Ai có thể đóng góp, chỉ lập trình viên hay cả các nhà phân tích? Kết quả được báo cáo như thế nào? Các loại khuôn khổ khác nhau trả lời những câu hỏi đó theo những cách khác nhau, và đó là điều phân biệt chúng. Nếu bạn mới làm quen với ý tưởng rộng hơn, tổng quan của chúng tôi về kiểm thử tự động là gì sẽ cung cấp kiến thức nền hữu ích trước khi đi vào phân tích từng loại bên dưới.
Lý do điều này quan trọng là vì việc bảo trì. Viết trăm bài kiểm tra tự động đầu tiên thì dễ. Bảo trì một ngàn bài kiểm tra khi ứng dụng thay đổi hàng tuần thì khó, và loại khuôn khổ là yếu tố lớn nhất quyết định chi phí bảo trì đó.
Hãy xem xét một ví dụ cụ thể. Màn hình đăng nhập thay đổi nhãn trường của nó. Trong một bộ kiểm tra, thay đổi đó làm hỏng hai bài kiểm tra và mất mười phút để sửa. Trong một bộ kiểm tra khác, kiểm thử cùng một ứng dụng, nó làm hỏng hai trăm bài kiểm tra và mất hai ngày. Ứng dụng là giống hệt nhau; chỉ có cấu trúc khuôn khổ khác biệt. Khoảng cách đó là toàn bộ lý do tại sao loại khuôn khổ đáng để suy nghĩ trước khi bạn viết mã, chứ không phải sau đó.
Sáu loại khuôn khổ
1. Tuyến tính (ghi và phát lại)
Khuôn khổ tuyến tính ghi lại các hành động của bạn và phát lại chúng như một kịch bản. Mỗi bài kiểm tra là một chuỗi các bước phẳng không có chức năng chung và không tách biệt dữ liệu khỏi logic. Các công cụ tự động tạo kịch bản cho bạn, vì vậy rào cản gia nhập gần như bằng không.
Sức hấp dẫn là tốc độ cho các dự án nhỏ, các bản demo nhanh, hoặc một bài kiểm tra khói (smoke check) một lần. Chi phí xuất hiện nhanh chóng. Bởi vì không có gì được tái sử dụng, các bước đăng nhập tương tự được sao chép và dán vào mọi bài kiểm tra. Khi trang đăng nhập thay đổi, bạn phải chỉnh sửa năm mươi kịch bản. Các khuôn khổ tuyến tính không mở rộng quy mô, và hầu hết các nhóm sẽ vượt qua chúng trong vài tuần.
2. Mô-đun
Khuôn khổ mô-đun chia ứng dụng thành các mô-đun nhỏ, độc lập và viết một hàm có thể tái sử dụng cho mỗi mô-đun. Một bài kiểm tra sau đó là sự kết hợp của các hàm đó: đăng nhập, tìm kiếm, thêm vào giỏ hàng, thanh toán. Khi màn hình đăng nhập thay đổi, bạn sửa một hàm và mọi bài kiểm tra đều được hưởng lợi.
Đây là cấu trúc đầu tiên thực sự có thể mở rộng. Đánh đổi là thiết kế ban đầu. Ai đó phải quyết định ranh giới mô-đun và xây dựng lớp trừu tượng trước khi các bài kiểm tra có thể được thực hiện nhanh chóng. Đối với hầu hết các nhóm kỹ thuật, mô-đun là lựa chọn mặc định hợp lý, và nó kết hợp tốt với nguyên tắc được mô tả trong hướng dẫn của chúng tôi về cách viết kịch bản kiểm thử tự động.
3. Hướng dữ liệu
Khuôn khổ hướng dữ liệu tách logic kiểm thử khỏi dữ liệu kiểm thử. Một hàm kiểm thử chạy nhiều lần với các hàng dữ liệu đầu vào được lưu trữ trong tệp CSV, tệp JSON, bảng tính hoặc cơ sở dữ liệu. Phạm vi kiểm thử mở rộng bằng cách thêm các hàng, chứ không phải bằng cách viết mã.
Loại này lý tưởng khi cùng một quy trình làm việc phải được xác minh với hàng tá sự kết hợp đầu vào: đăng nhập hợp lệ, đăng nhập không hợp lệ, giá trị biên, các biến thể khu vực. Cụ thể đối với API, một phương pháp kiểm thử API hướng dữ liệu với CSV và JSON biến một yêu cầu thành hàng trăm trường hợp. Đánh đổi là logic kiểm thử tự thân là cố định; cấu trúc hướng dữ liệu mở rộng đầu vào, chứ không phải hành vi.
4. Hướng từ khóa
Khuôn khổ hướng từ khóa trừu tượng hóa các hành động thành các từ khóa được đặt tên như Login, SearchProduct, hoặc VerifyTotal. Các bài kiểm tra được viết dưới dạng bảng từ khóa cộng với đối số, thường là trong bảng tính, để người không phải lập trình viên có thể tạo bài kiểm tra mà không cần chạm vào mã.
Điểm mạnh là khả năng tiếp cận. Các nhà phân tích QA và nhân viên kinh doanh có thể xây dựng và đọc các bài kiểm tra trực tiếp. Chi phí là thư viện từ khóa: các kỹ sư phải xây dựng và duy trì việc triển khai đằng sau mỗi từ khóa, và một bộ từ khóa được thiết kế kém sẽ trở thành gánh nặng bảo trì riêng. Cấu trúc hướng từ khóa phù hợp với các nhóm mà việc tạo bài kiểm tra và việc cài đặt kỹ thuật kiểm tra được chia sẻ giữa các vai trò khác nhau.
5. Lai ghép
Khuôn khổ lai ghép kết hợp hai hoặc nhiều loại trên, phổ biến nhất là tái sử dụng mô-đun cộng với đầu vào hướng dữ liệu cộng với trừu tượng hóa từ khóa. Nó ít là một loại riêng biệt hơn là sự thừa nhận thực dụng rằng các dự án thực tế cần các cấu trúc khác nhau ở những nơi khác nhau.
Hầu hết các bộ kiểm thử trưởng thành đều là lai ghép vào thời điểm chúng đạt vài nghìn bài kiểm thử. Rủi ro là sự không nhất quán: nếu sự kết hợp không được thiết kế một cách có chủ ý, bạn sẽ phải chịu chi phí bảo trì của mọi loại mà không có sự rõ ràng của loại nào. Một khuôn khổ lai ghép hoạt động khi sự kết hợp là có chủ ý và được ghi lại.
6. Hướng hành vi (BDD)
Khuôn khổ hướng hành vi thể hiện các bài kiểm tra bằng ngôn ngữ gần tự nhiên sử dụng mẫu Given-When-Then, thường được viết bằng Gherkin và được thực thi bởi các công cụ như Cucumber. Một kịch bản đọc như một câu: nếu một người dùng đã đăng ký, khi họ gửi thông tin đăng nhập hợp lệ, thì họ sẽ đến bảng điều khiển.
Giá trị của BDD là sự hiểu biết chung. Sản phẩm, QA và kỹ thuật đọc cùng một đặc tả, điều này làm giảm khoảng cách giữa những gì được yêu cầu và những gì được xây dựng. Chi phí là hai lớp: Gherkin dễ đọc và các định nghĩa bước (step definitions) triển khai nó. Nếu nhân viên sản phẩm không bao giờ thực sự đọc các kịch bản, bạn đang phải trả giá cho BDD mà không thu được lợi ích. Hướng dẫn Gherkin của chúng tôi cho kiểm thử API BDD trình bày mẫu này được áp dụng cho API.
So sánh các loại khuôn khổ
| Loại khuôn khổ | Khả năng tái sử dụng | Người không phải lập trình viên có thể tạo | Chi phí thiết lập | Khả năng mở rộng |
|---|---|---|---|---|
| Tuyến tính | Không | Có, qua ghi hình | Rất thấp | Kém |
| Mô-đun | Cao | Không | Trung bình | Tốt |
| Hướng dữ liệu | Trung bình | Một phần | Trung bình | Tốt cho đầu vào |
| Hướng từ khóa | Cao | Có | Cao | Tốt |
| Lai ghép | Cao | Đôi khi | Cao | Rất tốt |
| BDD | Cao | Có, để đọc và tạo | Cao | Tốt |
Bảng này làm rõ mô hình. Chi phí thiết lập rẻ hơn thường đồng nghĩa với khả năng mở rộng kém hơn, và các cấu trúc bao gồm người không phải lập trình viên cần đầu tư kỹ thuật nhiều hơn ở hậu trường. Không có lựa chọn miễn phí, chỉ có lựa chọn phù hợp với những ràng buộc của bạn.
Những lỗi phổ biến khi sử dụng khuôn khổ
Ngay cả những nhóm chọn một loại khuôn khổ hợp lý cũng thường làm suy yếu nó trong thực tế. Ba lỗi thường xuất hiện lặp đi lặp lại.
Đầu tiên là sự trừu tượng hóa quá sớm. Một nhóm áp dụng cấu trúc hướng từ khóa hoặc lai ghép cho một bộ kiểm thử chỉ có mười lăm bài kiểm thử. Lớp trừu tượng hóa tốn kém hơn để xây dựng và bảo trì so với các bài kiểm thử mà nó phục vụ. Cấu trúc nên theo quy mô; hãy để sự trùng lặp thực sự biện minh cho lớp tái sử dụng tiếp theo.
Thứ hai là điều ngược lại: từ chối phát triển. Một bộ kiểm thử tuyến tính hoạt động tốt với hai mươi bài kiểm thử vẫn là tuyến tính ở bốn trăm bài, và mọi thay đổi ứng dụng giờ đây đều gây ra một đợt quét đau đớn các kịch bản được sao chép và dán. Chi phí của việc duy trì tuyến tính tích lũy một cách lặng lẽ cho đến khi một thay đổi nhỏ duy nhất làm mất cả một ngày. Hãy chú ý đến tín hiệu, đó là việc chỉnh sửa nhiều bài kiểm thử cho một thay đổi sản phẩm, và tái cấu trúc theo hướng mô-đun trước khi nỗi đau trở thành thói quen.
Thứ ba là chọn một loại khuôn khổ cho đối tượng mà nó không có. BDD chỉ có hiệu quả khi những người không phải kỹ sư thực sự đọc Gherkin. Hướng từ khóa chỉ có hiệu quả khi các nhà phân tích thực sự tạo các bài kiểm thử. Nếu những người đó không bao giờ chạm vào bộ kiểm thử, bạn sẽ phải chịu chi phí của lớp bổ sung mà không thu được lợi ích nào. Hãy chọn loại phù hợp với những người thực sự tham gia, chứ không phải với những người có thể tham gia trên lý thuyết.
Cách chọn loại khuôn khổ
Chọn theo nhóm và dự án của bạn, chứ không phải theo xu hướng.
- Kích thước và vòng đời. Một kịch bản dùng một lần có thể là tuyến tính. Bất cứ thứ gì được duy trì hơn một quý nên là mô-đun tối thiểu.
- Ai viết bài kiểm tra. Tất cả các kỹ sư hướng đến mô-đun hoặc lai ghép. Các vai trò hỗn hợp hướng đến hướng từ khóa hoặc BDD.
- Đa dạng đầu vào. Nhiều kết hợp đầu vào chống lại các quy trình làm việc ổn định hướng đến hướng dữ liệu.
- Khoảng cách giao tiếp. Những hiểu lầm thường xuyên giữa sản phẩm và kỹ thuật hướng đến BDD, vì đặc tả chung là lợi ích chính của nó.
- Kỹ năng hiện có. Loại khuôn khổ tốt nhất là loại mà nhóm của bạn thực sự có thể duy trì. Một cấu trúc thanh lịch mà không ai hiểu sẽ thất bại nhanh hơn một cấu trúc đơn giản mà mọi người đều hiểu.
Hầu hết các nhóm đều chọn một dạng lai ghép: tái sử dụng mô-đun làm xương sống, đầu vào hướng dữ liệu cho các trường hợp có độ biến thiên cao, và BDD nơi sự hợp tác quan trọng nhất. Hãy bắt đầu đơn giản và để những khó khăn thực tế, chứ không phải lý thuyết, biện minh cho việc thêm cấu trúc. Để biết chiến lược kiểm thử vượt ra ngoài loại khuôn khổ, sự phân biệt trong hướng dẫn kịch bản kiểm thử so với trường hợp kiểm thử của chúng tôi sẽ giúp bạn xác định phạm vi mà mỗi bài kiểm thử nên bao gồm.
Nơi một nền tảng hỗ trợ
Việc lựa chọn loại khuôn khổ là một quyết định về kiến trúc. Để thực hiện nó tốt vẫn cần những công cụ phù hợp. Cụ thể đối với kiểm thử API, Apidog hỗ trợ tái sử dụng mô-đun thông qua các yêu cầu được chia sẻ, tham số hóa, chạy hướng dữ liệu từ các tệp CSV và JSON, và một công cụ xây dựng kiểm thử trực quan cho phép những người không phải lập trình viên tạo các bài kiểm thử, đây là tinh thần của cấu trúc hướng từ khóa mà không cần thư viện từ khóa được xây dựng thủ công.
Điều đó quan trọng bởi vì một loại khuôn khổ chỉ tốt khi nhóm có khả năng tuân thủ nó một cách nhất quán. Một nền tảng đã tích hợp cấu trúc vào giúp các bài kiểm thử được mạch lạc khi bộ kiểm thử phát triển và khi mọi người tham gia và rời đi. Bạn có thể tải xuống Apidog để xem các mẫu này hoạt động như thế nào trong thực tế, sau đó quyết định bạn còn cần bao nhiêu mã khuôn khổ tùy chỉnh. Câu trả lời thành thật thường là ít hơn bạn mong đợi, bởi vì Apidog đã xử lý các lớp yêu cầu, dữ liệu và báo cáo mà một khuôn khổ tự xây dựng sẽ phải triển khai lại.
Các câu hỏi thường gặp
Sự khác biệt giữa công cụ tự động hóa và khuôn khổ kiểm thử tự động hóa là gì?
Một công cụ thực thi các bài kiểm thử, chẳng hạn như trình điều khiển trình duyệt hoặc ứng dụng khách HTTP. Một khuôn khổ là cấu trúc xung quanh các công cụ đó: các quy ước để tổ chức các bài kiểm thử, chia sẻ logic, cung cấp dữ liệu và báo cáo kết quả. Bạn có thể có một công cụ mà không có khuôn khổ, nhưng các bài kiểm thử sẽ khó bảo trì. Khuôn khổ là thứ làm cho tự động hóa bền vững.
Loại khuôn khổ kiểm thử tự động hóa nào là tốt nhất?
Không có loại nào là tốt nhất tuyệt đối. Tuyến tính phù hợp với các kịch bản dùng một lần, mô-đun phù hợp với hầu hết các nhóm kỹ thuật, hướng dữ liệu phù hợp với sự đa dạng đầu vào cao, hướng từ khóa và BDD phù hợp với các nhóm có kỹ năng hỗn hợp, và lai ghép phù hợp với các bộ kiểm thử lớn, trưởng thành. Hãy chọn loại phù hợp với kỹ năng của nhóm bạn và vòng đời của dự án thay vì chọn tùy chọn phổ biến nhất.
BDD chỉ dành cho API hay chỉ dành cho kiểm thử UI?
Cả hai đều không đúng. BDD là một mẫu cấu trúc, không phải một lớp. Định dạng Given-When-Then hoạt động cho kiểm thử đơn vị, API và UI như nhau. Yêu cầu thực sự của nó không phải là lớp kiểm thử mà là đối tượng: BDD chỉ có hiệu quả khi những người không phải kỹ sư thực sự đọc hoặc viết các kịch bản.
Tôi có thể chuyển đổi loại khuôn khổ sau khi đã xây dựng một bộ kiểm thử không?
Có, nhưng nó tốn công sức tỷ lệ thuận với kích thước bộ kiểm thử. Chuyển từ tuyến tính sang mô-đun có nghĩa là trích xuất các hàm có thể tái sử dụng từ các kịch bản được sao chép và dán. Bài học là hãy chọn một cấu trúc có khả năng mở rộng sớm, vì việc trang bị lại một loại khuôn khổ cho hàng ngàn bài kiểm thử khó hơn nhiều so với việc bắt đầu với loại đúng.
Các dự án nhỏ có cần khuôn khổ nào không?
Một dự án có vòng đời thực sự ngắn có thể chạy trên một kịch bản tuyến tính, được ghi lại mà không cần khuôn khổ thực sự. Nhưng các dự án "nhỏ" có xu hướng phát triển. Nếu một bộ kiểm thử sẽ tồn tại lâu hơn vài tuần hoặc được nhiều hơn một người chạm vào, ngay cả một cấu trúc mô-đun nhẹ cũng sẽ tự trả giá nhanh chóng.