Tài Lê
Active member
Đây cũng là câu hỏi rất thường hay gặp trong các bài phỏng vấn cho các vị trí làm việc liên quan đến automation, tất nhiên là mình đã từng được hỏi câu này rồi haha, thế nên mạn phép chia sẻ một vài tìm hiểu về test automation framework cùng các bạn trong bài viết này để khỏi bỡ ngỡ khi một ngày bất ngờ được hỏi đến nha!
Test automation framework là gì?
Các automated testing framework cung cấp một kiến trúc riêng cho project kiểm thử của chúng ta, điều mà nền tảng của các công cụ test mà chúng ta sử dụng thì lại thường không cung cấp. Mỗi kiểu framework lại có những quy tắc riêng, các hướng dẫn, giao thức và thủ tục riêng dành cho các công việc như tạo test case, tổ chức và thực thi các test case.
Dưới đây là 6 framework dành cho kiểm thử tự động thường gặp nhất. Thứ tự được sắp xếp tăng dần theo độ phức tạp và các mức độ trong việc định hướng để đạt được các mục tiêu kiểm thử. Và các khía cạnh dùng để đánh giá việc đó bao gồm khả năng mở rộng, tính tái sử dụng, nỗ lực dành cho việc bảo trì và chi phí đầu tư dành cho các kỹ năng liên quan đến kỹ thuật như là chuyển giao kiến thức, đào tạo nhân lực hay các nỗ lực cần có để học hỏi các công nghệ mới…
Trong phần lớn các trường hợp, việc tổ chức framework sẽ đóng vai trò quan trọng hơn là việc lựa chọn một framework, vì việc tổ chức tốt sẽ mang lại sự chuẩn hóa nhất định trong quy trình phát triển và kiểm thử, từ đó giúp nâng cao hiệu quả các hoạt động trong project.
1. Module-Based Testing Framework
Với framework này, thì ta sẽ xây dựng các test script độc lập, tương ứng với từng module, các compoment hoặc các function của phần mềm ứng dụng. Việc tránh sử dụng các script phụ thuộc nhau là một yếu tố quan trọng đối với sự ổn định và khả năng bảo trì của framework này.
Với mỗi script của một module sẽ được gắn tương ứng với các thao tác (actions) và dữ liệu (testdata) tương ứng dành cho nó. Nếu như có sự thay đổi về test data thì các script cũng phải thay đổi tương ứng, hoặc là bạn phải tạo mới một test script riêng biệt khác để đáp ứng sự thay đổi đó. Và nếu như dữ liệu test của chúng ra thường xuyên có sự thay đổi hoặc cập nhật thì việc sử dụng data-driven framework sẽ là lựa chọn tốt hơn đấy!
2. Common Library Testing Framework
Framework này thì về cơ bản nó có nền tảng dựa theo Module Based Framework nhưng có một một số ưu điểm hơn. Thay vì chia ứng dụng với các module và các test script tương ứng, thì ở đây ta sẽ thực hiện tách các test script của các chức năng dùng chung vào trong một thư viện chung, và có thể gọi đến bất cứ khi nào cần dùng, mà không phải làm đi làm lại cùng một scipt giống hệt nhau.
Việc này giúp cho code không bị dài và dư thừa, và giảm nỗ lực thực hiện xây dựng script.
Ví dụ đơn giản bạn có thể hình dung trong việc sử dụng framework này như công việc Login vào một ứng dụng nào đó.
Thường thì bước login là bước đầu tiên phải làm trước khi thực hiện các chức năng sau đó. Vì thế, thay vì bước login này phải được xây dựng trước toàn bộ các function cần test, thì ta sẽ xây dựng một Common Lib, có chứa bước login này, vậy là từ sau ta chỉ cần gọi chức năng này ở Common ra dùng thôi chứ không phải làm đi làm lại ở từng script nữa. Việc này còn giúp ta nhàn nhã hơn nhiều trong việc nếu như bước login này có sự thay đổi nào đó cần cập nhật, thì lúc này ta cũng chỉ phải chỉnh sửa ở một nơi thôi chứ không phải đi khắp nơi để chỉnh sửa nữa!
3. Data driven testing Framework
Trong quá trình automation hay trong quá trình kiểm thử thông thường, việc thực hiện test một chức năng phải lặp đi lặp lại nhiều lần với các dữ liệu test khác nhau là việc mà ta sẽ phải gặp rất thường xuyên. Hơn nữa, trong một số trường hợp, ta không thể nhúng dữ liệu test vào trong test script được. Do đó mà người ta phải nghĩ tới việc sẽ lưu trữ các test data ra bên ngoài, tách biệt với các test script.
Hướng tiếp cận theo data-driven trong trường hợp này rõ ràng sẽ hiệu quả và dễ dàng quản lý hơn so với hai cách trên. Các test data cho các script được truyền vào từ một database bên ngoài, do đó tính sử dụng lại của script đó cũng cao hơn. Các database lưu trữ dữ liệu đó có thể là các file xml, excel, file text, CSV,… Các dữ liệu này được lưu trữ theo một quy ước chung là ‘Key – Value’, các key này sẽ được sử dụng để truy cập và truyền dữ liệu vào các test script tương ứng thông qua một số thư viện chung.
Framework này sẽ giúp giảm đáng kể số lượng test script cần có so với việc sử dụng framework hướng module. Test data có thể thay đổi độc lập với các test script, có nghĩa là khi bạn thay đổi các giá trị của test data thì bạn chỉ cần cập nhật ở phần dữ liệu lưu trữ bên ngoài, chứ không phải vào trong từng script để chỉnh sửa gì cả. Tuy nhiên thì về tổng thể nó có phần phức tạp hơn và nó cũng yêu cầu người dùng phải có một kỹ năng lập trình nhất định trong việc setup và bảo trì project.
4. Keyword Driven Testing Framework
Keyword driven là một dạng mở rộng của Data driven framework, nó còn được gọi với một tên khác là table-driven. Đối với hướng tiếp cận này, các test data cũng được tách khỏi các test script, và thêm vào đó các giá trị keywork của các aciton được lưu trữ trong file database bên ngoài. Các key word này chính là các hướng dẫn để xác định các action nào sẽ cần được thực hiện để test ứng dụng.
Đối với keyword driven framework, không yêu cầu quá cao đối với kỹ năng của người tạo các test cript.
Framework này cũng giúp cho các test cript của chúng ta dễ đọc hơn.
Thêm một ví dụ để các bạn có thể hiểu hơn về framework này nhé!
Ex: Mình có một test case theo keyword driven testing framework như sau:
Như bảng dữ liệu trên, ta có cột keywork với các giá trị như login, clickLink và verifyLink. Tùy thuộc vào tính chất của ứng dụng, thì các keyword sẽ được gọi và sử dụng tương ứng. Các keyword này có thể được gọi đến và sử dụng nhiều lần trong quá trình thực hiện test. Cột Locator/Data là giá trị locator của phần tử trên màn hình hoặc các test data cần truyền vào cho phần tử ấy.
5. Hybrid Testing Framework
Cái tên nói tên tất cả, hybrid test framework là sự kết hợp giữa hai hoặc nhiều các loại framework trên. Điểm cộng lớn ở đây chính là việc phát huy các ưu điểm của các framework mà nó kết hợp sử dụng.
Ví dụ, một hybrid có sự kết hợp giữa common library cùng với một kho dữ liệu test là các dữ liệu đầu vào/ra và các action keyword, lúc này mỗi bộ trong kho dữ liệu sẽ bao gồm tên của đối tượng, mô tả, action keyword, UI locator và test data tương ứng.
Đối với hybrid thì các công việc ban đầu có thể phức tạp hơn đối với các hướng tiếp cận là các framework phía trên, nhưng nếu như sự cân bằng giữa các framework được kết hợp được đánh giá và thực thi cẩn thận thì nó lại có một sự linh hoạt rất cao đối với việc nâng cấp và bảo trì project.
6. Behavior Driven Development Framework
Behavior Driven Developmet Framework viết tắt là BDD, framework này không giống như các framework đã kể trên, mục đích của nó là tạo điều kiện cho các bên liên quan trong quy trình phát triển phần mềm như: Business Analysts, Developers, Testes… có thể tiếp cận với các yêu cầu kỹ thuật của sản phẩm sớm nhất có thể. Điều này đòi hỏi sự hợp tác cao giữa team DEV và team test.
Vấn đề trọng tâm đối với framework này đó là việc sử dụng các ngôn ngữ non-technical, semi-formal, hay dễ hiểu hơn là nó sẽ gần giống với ngôn ngữ tự nhiên mà chúng ta vẫn thường sử dụng để mô tả các test case theo hướng hành vi của người dùng. Có một số công cụ hỗ trợ chúng ta trong việc này như Cucumber hay Jbehave, Rbehave…
Nguồn: topdev.vn
Test automation framework là gì?
Các automated testing framework cung cấp một kiến trúc riêng cho project kiểm thử của chúng ta, điều mà nền tảng của các công cụ test mà chúng ta sử dụng thì lại thường không cung cấp. Mỗi kiểu framework lại có những quy tắc riêng, các hướng dẫn, giao thức và thủ tục riêng dành cho các công việc như tạo test case, tổ chức và thực thi các test case.
Dưới đây là 6 framework dành cho kiểm thử tự động thường gặp nhất. Thứ tự được sắp xếp tăng dần theo độ phức tạp và các mức độ trong việc định hướng để đạt được các mục tiêu kiểm thử. Và các khía cạnh dùng để đánh giá việc đó bao gồm khả năng mở rộng, tính tái sử dụng, nỗ lực dành cho việc bảo trì và chi phí đầu tư dành cho các kỹ năng liên quan đến kỹ thuật như là chuyển giao kiến thức, đào tạo nhân lực hay các nỗ lực cần có để học hỏi các công nghệ mới…
Trong phần lớn các trường hợp, việc tổ chức framework sẽ đóng vai trò quan trọng hơn là việc lựa chọn một framework, vì việc tổ chức tốt sẽ mang lại sự chuẩn hóa nhất định trong quy trình phát triển và kiểm thử, từ đó giúp nâng cao hiệu quả các hoạt động trong project.
1. Module-Based Testing Framework
Với framework này, thì ta sẽ xây dựng các test script độc lập, tương ứng với từng module, các compoment hoặc các function của phần mềm ứng dụng. Việc tránh sử dụng các script phụ thuộc nhau là một yếu tố quan trọng đối với sự ổn định và khả năng bảo trì của framework này.
Với mỗi script của một module sẽ được gắn tương ứng với các thao tác (actions) và dữ liệu (testdata) tương ứng dành cho nó. Nếu như có sự thay đổi về test data thì các script cũng phải thay đổi tương ứng, hoặc là bạn phải tạo mới một test script riêng biệt khác để đáp ứng sự thay đổi đó. Và nếu như dữ liệu test của chúng ra thường xuyên có sự thay đổi hoặc cập nhật thì việc sử dụng data-driven framework sẽ là lựa chọn tốt hơn đấy!
2. Common Library Testing Framework
Framework này thì về cơ bản nó có nền tảng dựa theo Module Based Framework nhưng có một một số ưu điểm hơn. Thay vì chia ứng dụng với các module và các test script tương ứng, thì ở đây ta sẽ thực hiện tách các test script của các chức năng dùng chung vào trong một thư viện chung, và có thể gọi đến bất cứ khi nào cần dùng, mà không phải làm đi làm lại cùng một scipt giống hệt nhau.
Việc này giúp cho code không bị dài và dư thừa, và giảm nỗ lực thực hiện xây dựng script.
Ví dụ đơn giản bạn có thể hình dung trong việc sử dụng framework này như công việc Login vào một ứng dụng nào đó.
Thường thì bước login là bước đầu tiên phải làm trước khi thực hiện các chức năng sau đó. Vì thế, thay vì bước login này phải được xây dựng trước toàn bộ các function cần test, thì ta sẽ xây dựng một Common Lib, có chứa bước login này, vậy là từ sau ta chỉ cần gọi chức năng này ở Common ra dùng thôi chứ không phải làm đi làm lại ở từng script nữa. Việc này còn giúp ta nhàn nhã hơn nhiều trong việc nếu như bước login này có sự thay đổi nào đó cần cập nhật, thì lúc này ta cũng chỉ phải chỉnh sửa ở một nơi thôi chứ không phải đi khắp nơi để chỉnh sửa nữa!
3. Data driven testing Framework
Trong quá trình automation hay trong quá trình kiểm thử thông thường, việc thực hiện test một chức năng phải lặp đi lặp lại nhiều lần với các dữ liệu test khác nhau là việc mà ta sẽ phải gặp rất thường xuyên. Hơn nữa, trong một số trường hợp, ta không thể nhúng dữ liệu test vào trong test script được. Do đó mà người ta phải nghĩ tới việc sẽ lưu trữ các test data ra bên ngoài, tách biệt với các test script.
Hướng tiếp cận theo data-driven trong trường hợp này rõ ràng sẽ hiệu quả và dễ dàng quản lý hơn so với hai cách trên. Các test data cho các script được truyền vào từ một database bên ngoài, do đó tính sử dụng lại của script đó cũng cao hơn. Các database lưu trữ dữ liệu đó có thể là các file xml, excel, file text, CSV,… Các dữ liệu này được lưu trữ theo một quy ước chung là ‘Key – Value’, các key này sẽ được sử dụng để truy cập và truyền dữ liệu vào các test script tương ứng thông qua một số thư viện chung.
Framework này sẽ giúp giảm đáng kể số lượng test script cần có so với việc sử dụng framework hướng module. Test data có thể thay đổi độc lập với các test script, có nghĩa là khi bạn thay đổi các giá trị của test data thì bạn chỉ cần cập nhật ở phần dữ liệu lưu trữ bên ngoài, chứ không phải vào trong từng script để chỉnh sửa gì cả. Tuy nhiên thì về tổng thể nó có phần phức tạp hơn và nó cũng yêu cầu người dùng phải có một kỹ năng lập trình nhất định trong việc setup và bảo trì project.
4. Keyword Driven Testing Framework
Keyword driven là một dạng mở rộng của Data driven framework, nó còn được gọi với một tên khác là table-driven. Đối với hướng tiếp cận này, các test data cũng được tách khỏi các test script, và thêm vào đó các giá trị keywork của các aciton được lưu trữ trong file database bên ngoài. Các key word này chính là các hướng dẫn để xác định các action nào sẽ cần được thực hiện để test ứng dụng.
Đối với keyword driven framework, không yêu cầu quá cao đối với kỹ năng của người tạo các test cript.
Framework này cũng giúp cho các test cript của chúng ta dễ đọc hơn.
Thêm một ví dụ để các bạn có thể hiểu hơn về framework này nhé!
Ex: Mình có một test case theo keyword driven testing framework như sau:
Như bảng dữ liệu trên, ta có cột keywork với các giá trị như login, clickLink và verifyLink. Tùy thuộc vào tính chất của ứng dụng, thì các keyword sẽ được gọi và sử dụng tương ứng. Các keyword này có thể được gọi đến và sử dụng nhiều lần trong quá trình thực hiện test. Cột Locator/Data là giá trị locator của phần tử trên màn hình hoặc các test data cần truyền vào cho phần tử ấy.
5. Hybrid Testing Framework
Cái tên nói tên tất cả, hybrid test framework là sự kết hợp giữa hai hoặc nhiều các loại framework trên. Điểm cộng lớn ở đây chính là việc phát huy các ưu điểm của các framework mà nó kết hợp sử dụng.
Ví dụ, một hybrid có sự kết hợp giữa common library cùng với một kho dữ liệu test là các dữ liệu đầu vào/ra và các action keyword, lúc này mỗi bộ trong kho dữ liệu sẽ bao gồm tên của đối tượng, mô tả, action keyword, UI locator và test data tương ứng.
Đối với hybrid thì các công việc ban đầu có thể phức tạp hơn đối với các hướng tiếp cận là các framework phía trên, nhưng nếu như sự cân bằng giữa các framework được kết hợp được đánh giá và thực thi cẩn thận thì nó lại có một sự linh hoạt rất cao đối với việc nâng cấp và bảo trì project.
6. Behavior Driven Development Framework
Behavior Driven Developmet Framework viết tắt là BDD, framework này không giống như các framework đã kể trên, mục đích của nó là tạo điều kiện cho các bên liên quan trong quy trình phát triển phần mềm như: Business Analysts, Developers, Testes… có thể tiếp cận với các yêu cầu kỹ thuật của sản phẩm sớm nhất có thể. Điều này đòi hỏi sự hợp tác cao giữa team DEV và team test.
Vấn đề trọng tâm đối với framework này đó là việc sử dụng các ngôn ngữ non-technical, semi-formal, hay dễ hiểu hơn là nó sẽ gần giống với ngôn ngữ tự nhiên mà chúng ta vẫn thường sử dụng để mô tả các test case theo hướng hành vi của người dùng. Có một số công cụ hỗ trợ chúng ta trong việc này như Cucumber hay Jbehave, Rbehave…
Nguồn: topdev.vn