Automation Test

Duy Văn | 06/12/2024

  1. Khái niệm
  2. Tại sao kiểm thử tự động
  3. Khi nào kiểm thử tự động
  4. Frameworks

Phần Frameworks này mình sẽ chỉ viết về cách sử dụng cũng như cách viết Auto Test, chứ còn lý thuyết đằng sau cả cái hành động này thì mình chưa nói, nên giờ sẽ nói.

Khái niệm

Đầu tiên, kiểm thử tự động là việc sử dụng các công cụ để thực hiện các test case thay vì bằng tay. Các test case sẽ được thực hiện đúng như theo script kiểm thử được viết lại dưới dạng code để các công cụ có thể hiểu và thực hiện thông qua các driver.Automation Test is the use of tools to perform test cases instead of manually. Test cases will be performed as per the test script written in the form of code so that the tools can understand and perform through the drivers.

Đây là cách hiểu Automation Test ngắn gọn nhất có thể, tuy nhiên để hiểu Auto test thì còn cần nắm được các cái được và mất của việc đi test tự động

Tại sao thực hiện kiểm thử tự động?

Ngắn gọn là, kiểm thử tự động sẽ làm tăng độ chính xác của việc đánh giá test case, cũng như giảm công sức bỏ ra để thực hiện kiểm thử. Tuy nhiên, nó chỉ áp dụng với các test case được tự động hoá.

  • Đầu tiên, vì test case được chạy bằng tool, nên việc đánh giá các điều kiện của test case là rất nhất quán.

Ví dụ, với một test case đã được thông qua và chạy thành công ở khâu Manual Test, giờ team test có hai lựa chọn, hoặc sau này sẽ chạy lại test case đấy bằng tay, hoặc chuyển nó sang Auto.

Thì, khi thực hiện manual test, các tiêu chí Expected Result được đánh giá bằng cảm quan và logic của người thực hiện, các tiêu chí càng trừu tượng thì càng bị đánh giá lỏng lẻo, ví dụ như test case cho UI, việc so sánh layout với thiết kế sẽ đòi hỏi sử dụng tool căn khoảng cách, trên màn hình đúng độ phân giải và scaling, một thay đổi của các yếu tố này sẽ khiến đánh giá của người lung lay.

Ngược lại với auto test, việc tính toán các thông số offset này được tính toán bằng công cụ kiểm thử, công cụ có thể triển khai test case với các điều kiện bất di bất dịch, mở ở độ phân giải nào, scaling bao nhiêu, v.v… sai là sai, đúng là đúng.

  • Tiếp theo, các test case sẽ được thực hiện rất chính xác mà không tốn quá nhiều công sức. Tức là giảm công sức (effort) để vẫn thực hiện test một cách hiệu quả

Lấy cũng ví dụ ở trên, đúng ra, bài test manual cho UI này sẽ cần phải tính đến các cỡ màn hình và scaling khác nhau nên sẽ tồn tại các test case cụ thể cho từng bộ resolution/scaling.

Vậy thì khi thực hiện bài test này bằng tay, sẽ tốn rất nhiều công sức để cài đặt các thông số này cho thiết bị thuộc test environment, dẫn đến tốn thời gian

Trong khi đấy nếu làm auto, việc áp dụng các thông số vào bài test là chuyện rất đơn giản, nếu công cụ có thể làm được, thì tất cả các điều kiện thông số sẽ được áp dụng cực kỳ chính xác trong khoảng thời gian rất ngắn.

  • Cuối cùng là các bước thực hiện test case được làm bằng máy nên toàn bộ các bước đều sẽ được thực hiện giống y như nhau trong tất cả các lần chạy. Còn với thực hiện bằng tay, các yếu tố con người sẽ gây ảnh hưởng lên việc thực hiện bài test mang tính lặp lại.

Một tình trạng hay gặp ở các bài test mang tính lặp lại, nếu được làm bằng tay thì sẽ rất dễ rơi vào bẫy chủ quan, khi mà làm đi làm lại nhiều lần, tester không còn nhìn vào kịch bản để làm, rồi khi chịu ảnh hưởng bởi mệt mỏi (fatigue), mất tập trung, sẽ thực hiện thiếu bước, và khi nhận ra thì sẽ phải làm lại test case từ đầu, rất mất thời gian

Khi nào thì áp dụng kiểm thử tự động?

Như ở trên mình nhấn mạnh, các cái được của kiểm thử tự động chỉ áp dụng cho các test case được tự động hoá. Nôm na là, chúng ta không thể nói thẳng ra là

Kiểm thử tự động tốt hơn bằng tay ở…

Cách nói này là sai, mà phải là

Kiểm thử tự động phù hợp hơn cho bài test này so với bằng tay ở…

Do bản chất mà nói, chúng ta không thể so sánh kiểm thử bằng tay và tự động như thể là làm tự động sẽ thay thế kiểm thử bằng tay, mà Auto test chỉ hỗ trợ kiểm thử nói chung và là một khâu cần thiết sau manual.

Cách hiểu ưa thích của mình để đánh giá khi nào nên auto sẽ nằm ở 3 điều kiện:

  • Điều kiện cần:
    1. Cần phải hiểu và nắm rất rõ cấu trúc sản phẩm.
    2. Các bài test được tự động hoá cần phải được thông qua và thực hiện thành công
  • Điều kiện đủ:
    1. Bài test mang tính lặp lại, làm nhiều lần trong tương lai
    2. Bài test tốn nhiều thời gian để thực hiện
    3. Bài test phức tạp về bước thực hiện
  • Phản điều kiện: Tức là khi nào thì không auto
    1. Bài test thay đổi liên tục
    2. Bài test cần đánh giá cảm quan của người

Đầu tiên, để giải thích cho điều kiện cần, rất đơn giản là vì khâu auto test sẽ là viết các test script tự động dựa trên test script manual. Tức là lội về section trước Software Testing Foundation, các test case manual sau khi được viết ra, vận hành bởi manual tester, nếu thuộc vào các test case ở phần điều kiện đủ và không ở trong phản điều kiện, sẽ được đưa sang bên auto test và viết test script tự động. Và test case đã phải được thực hiện thành công rồi, lúc đấy mới có thể automate test case.

Để có thể biến test case vốn làm bằng tay thành dạng code để cho công cụ kiểm thử có thể hiểu thì cần nắm rất rõ sản phẩm phần mềm, cách nó vận hành.

Ví dụ, với một test case để xác minh một pop up cảnh báo, việc của manual test chỉ đơn thuần là quan sát xem cái pop up có xuất hiện và nội dung có đúng hay không. Tuy nhiên, đối với auto test, việc viết phần xác minh này thành script yêu cầu rất phức tạp về mặt technical do phải sử dụng một framework kiểm thử, tìm cách xác định element pop up , xác minh pop up xuất hiện, check nội dung pop up,… tất cả phải làm ở dạng code.

Tiếp theo, với điều kiện đủ, đây đơn giản là các case có thể áp dụng kiểm thử tự động thay vì làm bằng tay để tăng độ chính xác, tiết kiệm công sức như đã nêu ở trên.

  1. Bài test mang tính lặp lại, làm nhiều lần trong tương lai: Một ví dụ kinh điển mà chắc chắn 100% sẽ được chuyển thành auto là smoke test và regression test.
  2. Bài test tốn nhiều thời gian để thực hiện: Ví dụ như performance test, những test tốn quá nhiều thời gian, khi thực hiện thì cũng không thể nào trông mong tester sẽ ngồi dán mắt vào màn hình hay phải chờ đợi.
  3. Bài test phức tạp về bước thực hiện: Những test dạng này thì nên auto để tránh sai sót và tăng độ chính xác.

Cuối cùng là phản điều kiện.

  1. Bài test thay đổi liên tục, với dạng test thế này, thường là do tính chất của test case manual không ổn định.
    Logic đằng sau điều kiện này là : Do Automate các test script tốn rất nhiều thời gian và công sức, cốt cũng là để có ROI (Return Of Investment) cao, tức là bây giờ khổ, sau này sướng. Nhưng nếu test case thay đổi về tính chất liên tục, việc update script xảy ra quá thường xuyên, khiến cho ROI giảm
  2. Bài test cần đánh giá cảm quan của người, đơn giản như những test liên quan đến giao diện, độ mượt mà, transition, animation,… không thể đánh giá bằng máy.

Typical question: What is Automation Testing? - Kiểm thử tự động là gì?

Typical question: Why do we perform Automation Testing? - Tại sao chúng ta thực hiện kiểm thử tự động?

Typical question: When should we apply Automation Testing? - Khi nào thì nên áp dụng kiểm thử tự động?

Frameworks

Framework có thể hiểu là cơ sở hay căn bản để giúp người dùng xây dựng nên sản phẩm hoàn thiện. Vậy thì Testing framework là cơ sở bao gồm các function và method mang tính xương sống để giúp auto tester viết được ra và vận hành được test case.Framework can be understood as the foundation or basis to help users build a complete product. So Testing framework is a foundation that includes functions and methods that help auto tester write and execute test cases.

Có một số kiểu test framework trên thị trường nhắm tới các đối tượng khác nhau và có thể phân loại dựa trên cách mà người dùng tiếp cận

  • Automation Library: Library có thể kể đến như Selenium, Playwright, 2 library này đều là mã nguồn mở (open-source), cập nhật liên tục, cung cấp những function và method cơ bản nhất cho Browser Automation. Hay là cho Desktop Automation có thể kể đến WinAppDriver, cho mobile automation có Appium.
  • Keyword-driven Framework: Framework dạng này thường sẽ cung cấp một số keyword, mà người dùng sẽ sử dụng để viết test case, ví dụ như Robot Framework, hay Katalon Studio. Mục tiêu của nó là viết ra các test case dễ đọc, dễ hiểu, và dễ maintain sử dụng ngôn ngữ người với người. Các framework này sẽ có các library riêng để hỗ trợ việc viết test case, ví dụ như Robot Framework gói SeleniumLibrary, AppiumLibrary, v.v… nó sẽ dùng lại các function và method của Selenium hay Appium, nhưng sẽ viết lại dưới dạng keyword.
  • Behavior-driven Framework: Framework dạng này cũng sẽ cung cấp một số keyword, mà người dùng sẽ sử dụng để viết test case, nhưng sẽ dùng ngôn ngữ tự nhiên và có cấu trúc cụ thể dạng Gherkin (Given-When-Then). Ví dụ như Cucumber, hay SpecFlow. Mục tiêu của nó cũng là viết ra những test case dễ đọc dễ hiểu, nhất là về hướng business.
  • Data-driven Framework: Framework dạng này sẽ cung cấp một số cách để người dùng có thể thay đổi dữ liệu đầu vào của test case mà không cần phải viết lại test case. Ví dụ như TestNG, hay JUnit, hay NUnit. Mục tiêu của nó là viết ra những test case có thể chạy với nhiều dữ liệu khác nhau.

Typical question: What is Testing Framework? - Testing Framework là gì?

Typical question: What are the types of Testing Framework? - Có những loại Testing Framework nào?

Mình sẽ viết về Robot Framework trước, vì mình học Robot đầu tiên.