Những mô hình cho việc kiểm thử tự động

0

Theo Mohammad Saad

Khi bắt đầu làm việc với kiểm thử tự động, chắc chắn chúng ta phải từng nghe đến cụm từ test automation framework – Mô hình (nền tảng) kiểm thử tự động. Cụm từ này có thể gây khó chịu cho vài người, làm cho họ cảm thấy nó là một khái niệm khó hiểu và khó có thể thực hiện.

Bài này được viết ra với mục đích giải thích vấn đề này một cách đơn giản.

Mô hình kiểm thử tự động – một cách đơn giản – là một tập hợp các quy luật, nguyên tắc dùng trong quá trình viết mã kiểm thử. Các quy luật giúp chúng ta viết mã theo một cách mà kết quả cuối cùng là “giảm thiểu việc chỉnh sửa mã kiểm thử khi ứng dụng thay đổi“.

Những Mô hình phổ biến hiện nay

  • Tuyến tính
  • Hướng module
  • Hướng dữ liệu
  • Hướng từ khóa
  • Hỗn hợp

Chúng ta sẽ đi qua từng kiểu Mô hình và các đặc điểm của nó

Tuyến tính – Linear Framework

Đặc điểm cơ bản

  • Mọi thứ liên quan đến mã đều được định nghĩa bên trong phương thức kiểm thử
  • Không quan tâm đến việc lãng phí và trùng lặp các câu lệnh
  • Việc record/playback thường xuyên sinh ra mã tuyến tính
  • Dễ dàng để bắt đầu
  • Khó khăn trong việc chỉnh sửa

Mô hình này có thể được dùng trong dự án nhỏ, nơi mà không có quá nhiều màn hình giao diện cũng như chức năng. Mặc khác, chúng ta cũng hay dùng Mô hình này khi sử dụng một công cụ kiểm thử tự động lần đâu tiên. Thông qua việc record/playback và phát sinh mã, chúng ta có thể học được cách công cụ tương tác với ứng dụng như thế nào. Ngoài hai lý do trên, Mô hình này không được khuyến khích sử dụng trong kiểm thử tự động.

Hướng modul – Modularity

Đặc điểm cơ bản

  • Các đối tượng được định nghĩa một lần và tái sử dụng trong các phương thức kiểm thử.
  • Các phương thức nhỏ và có mục đích được tạo ra cho những chức năng riêng biệt
  • Kịch bản kiểm thử tự động là một tập hợp các phương thức nhỏ và các đối tượng được định nghĩa từ trước
  • Cho phép chúng ta dễ dàng viết các mã dễ dàng được chỉnh sửa

Mục đích chính của Mô hình này là việc chỉnh sửa dễ dàng. Nếu có bất kỳ thay đổi nào trên giao diện, chúng ta chỉ cần chỉnh sửa trong các phương thức và đối tượng. Mã kiểm thử chính của chúng ta vẫn hoạt động chính xác. Mô hình POM (Page Object Model) – thường được dùng với Selenium – là một dạng của việc ứng dụng Mô hình hướng modul. Toàn bộ trang web sẽ được chia nhỏ thành các trang. Các đối tượng UI của từng trang được định nghĩa bên trong từng lớp của trang đó. Nếu có bất kỳ thay đổi nào trên ứng dụng web, chúng ta chỉ cần chỉnh sửa lớp của trang đó, những lớp của trang khác vẫn giữ nguyên. Kết quả cuối cùng chúng ta sẽ có những đoạn mã được bảo trì tốt hơn và dễ đọc hơn.

Điểm yếu của mô hình này là nó yêu cầu một mức độ kỹ năng lập trình và hiểu sâu về hướng đối tượng. Nếu bạn có nó, khuôn mẫu này được khuyến khích sử dụng.

Hướng dữ liệu – Data driven

Đặc điểm cơ bản

  • Dữ liệu kiểm thử (giá trị đầu vào và đầu ra) được tách khỏi mã nguồn và lưu trong một tập tin bên ngoài. Nó có thể là một tập tin CSV, một bảng Excel hay một cơ sở dữ liệu.
  • Khi mã kiểm thử thực thi, các giá trị này được lấy ra từ tập tin, chứa vào biến và thay thế các giá trị cứng (nếu có) trong mã nguồn.
  • Thực sự hữu ích khi mà cùng một kịch bản kiểm thử cần thực thi với nhiều dữ liệu đầu vào khác nhau.

Có vài ưu điểm khi áp dụng mô hình này. Tất cả các giá trị kiểm thử được lưu bên ngoài mã nguồn, do đó, bất kỳ thay đổi nào xảy ra trong quá trình phát triển ứng dụng, chúng ta chỉ cần thay đổi dữ liệu trong tập tin bên ngoài, và mã kiểm thử tự động của chúng ta vẫn được giữ nguyên.

Một ưu điểm khác là, khả năng sử dụng một kịch bản kiểm thử cho nhiều dữ liệu khác nhau. Ví dụ như, bạn đang làm một kịch bản đăng nhập hệ thống với 100 user. Bạn có thể viết 1 đoạn mã và một tập tin lưu trữ thông tin của 100 user. Sau đó, bạn chỉ cần thực thi 1 lần, và đi qua cả 100 bộ dữ liệu. Bạn dễ dàng phát hiện, với kiểu dữ liệu nào thì đoạn mã Fail. Đây cũng là một thế mạnh khi bạn đang làm kiểm thử phủ định – Negative Test.

Hướng từ khóa – Keyword driven

Đặc điểm cơ bản

  • Cả dữ liệu và chức năng được định nghĩa bên ngoài mã nguồn
  • Cần phát triển các từ khóa cho nhiều chức năng khác nhau
  • Mã kiểm thử tự động đôi khi được lưu trữ ở một tập tin bên ngoài mã nguồn giống như mô hình hướng dữ liệu. Các bước của kịch bản kiểm thử được viết từng bước với định dạng bảng, nơi mà sử dụng các từ khóa và dữ liệu kiểm thử
  • Mã nguồn chính sẽ đọc các bước trong định dạng bảng và thực thi các chức năng tương ứng
  • Cho phép các kỹ sư kiểm thử thủ công, nhưng người không biết về lập trình, có thể là một phần, ở một mức độ, của nhóm kiểm thử tự động

Ưu điểm của mô hình hướng từ khóa

Mô hình này rất hữu dụng trong những trường hợp mà kịch bản kiểm thử có quá nhiều thay đổi. Nếu bất kỳ bước nào trong kịch bản kiểm thử bị thay đổi, chúng ta không cần phải chỉnh sửa mã nguồn. Chúng ta chỉ cần chỉnh sửa tập tin bên ngoài và như vậy, kịch bản kiểm thử tự động sẽ được chỉnh sửa theo.

Chúng ta định nghĩa toàn bộ kịch bản ở tập tin và đưa cho kỷ sư kiểm thử thủ công, họ sẽ thêm các đoạn văn bản (text) hoặc chỉnh sửa cái có sẵn. Bằng cách này, kỹ sư kiểm thử tự động cũng có thể trở thành một phần của nhóm kiểm thử tự động bởi vì họ không cần phải lập trình gì cả. Họ chỉ cần chỉnh sửa tập tin ở những vị trí cần thiết và kịch bản kiềm thử tự động sẽ được chỉnh sửa một cách tự động.

Một lợi ích khác của mô hình này là, kịch bản kiểm thử của bạn trở thành một công cụ độc lập. Bạn chỉ cần bảo trì kịch bản kiểm thử trong một tập tin và nếu bạn cần thay đổi công cụ kiềm thử tự động ở điểm nào đó, bạn có thể dễ dàng chỉnh sửa bằng cách viết lại cách đọc và thực thi tập tin với công cụ mới.

Mặc khác, khuyết điểm của mô hình này là, bạn cần phát triển các từ khóa cho các chức năng khác nhau. Trong một dự án lớn, có thể có rất nhiều từ khóa mà bạn cấn phải nhớ và tổ chức nó hợp lý. Bản thân việc này có thể sẽ làm một công việc nặng nhọc cho quá trình phát triển kiềm thử tự động.

Ở vài trường hợp phức tạp, khi mà các đối tượng UI không thể được xác định dễ dàng, chúng ta phải sử dụng nhiều kỹ thuật khác nhau để xử lý, mô hình này không hữu dụng cho lắm.

Mô hình hướng từ khóa là một mô hình ưa thích của nhiều kỹ sư kiểm thử tự động. Robot Framework – công cụ kiểm thử tự động được phát triển bởi Google – là một công cụ phổ biến đi theo hướng từ khóa. Những công cụ đi theo hướng từ khóa này còn có Test Architect hay Katalon Studio

Hướng hỗn hợp – Hybrid

Đặc điểm cơ bản

  • Là sự kết hợp của hai hoặc nhiều kỹ thuật ở trên, kế thửa thế mạnh và loại bỏ những điểm yếu của các mô hình khác.
  • Mô hình này sử dụng cách tiếp cận theo hướng modul, kết hợp với hướng dữ liệu hoặc hướng từ khóa
  • Mô hình này có thể dùng mã nguồn để xủ lý những công việc đặc biệt mà quá khó để tạo ra với cách làm từ khóa

Một cách đơn giản, mô hình này sử dụng kết hợp nhiều kỹ thuật với nhau. Chúng ta có thể sử dụng hướng dữ liệu đồng thời với hướng modul. Trong vài trường hợp, chúng ta có thể dùng từ khóa song song với modul. Cơ bản, khi nào chúng ta sử dụng nhiều hơn một mô hình, đó là lúc chúng ta sử dụng hỗn hợp – Hybrid

Kết luận

Mình hy vọng rằng, bây giờ, cụm từ mô hình kiểm thử tự động không còn là gây khó khăn cho bạn. Mình đã cố gắng giải thích vài mô hình phổ biến hiện nay theo cách đơn giản nhất có thể.

Mô hình tồn tại là để cuộc sống của chúng ta dễ dàng hơn. Nó giúp chúng ta viết ra những kịch bản kiểm thử tự động dễ chỉnh sửa và dễ đọc. Không có mô hình, kiểm thử tự động có thể sẽ trở nên cực kỳ khó khăn. Với những thay đổi nhỏ của ứng dụng mà chúng ta phải chỉnh sửa hàng trăm vị trí trong mã nguồn.

Do đó, hiểu và ứng dụng tốt những mô hình là một yêu cầu cần thiết cho bất kỳ ai muốn tham gia và lĩnh vực kiểm thử tự động này.

Share.

About Author

A QA engineer who is interested in software test, willing to learn new technical and share his knowledge to everyone.

Leave A Reply