Như các bạn đã biết, một trong những nhiệm vụ của Automation Test là để thực thi một cách tự động các kịch bản của Manual Test lặp đi lặp lại nhiều lần (hay nhóm kịch bản phân vùng Regression Test). Để thực hiện được nhiệm vụ này các các dự án kiểm thử tự động phải đảm bảo có đầy đủ các thành phần cơ bản bắt buộc mà kiểm thử thủ công phải có. Hay nói cách khác thì Manual có thành phần nào thì Automation Test nên có đầy đủ những thành phần đó  để kịch bản được đảm bảo. Vậy trong bài viết này hãy cùng Test Mentor tìm hiểu những thành phần cơ bản của Kiểm thử thủ công từ đó ánh xạ sang Kiểm thử tự động để các bạn đang trong quá trình học tập về Kiểm thử tự động quản lý source code cho dự án của mình thật tốt nhé!

>>> Xem thêm: Manual test là gì? Sự khác biệt giữa manual test và automation test

Những thành phần cơ bản của Manual Test

Môi trường thực thi Kiểm thử (Test Environment)

Một dự án phần mềm sẽ được thực hiện dựa trên yêu cầu của khách hàng. Mỗi một khách hàng sẽ có những yêu cầu khác nhau về môi trường của phần mềm đó. Có thể họ sẽ yêu cầu về phần mềm phải được thực hiện trên một môi trường cụ thể nào đó hoặc không có. Ví dụ: Đối với Web Apps có thể là về trình duyệt như Chrome, Edge, Firefox,… đối với thiết bị di động có thể là trên Iphone, Ipad, các dòng máy Android,… Ngoài ra, có thể còn có các yêu cầu liên quan đến phiên bản của các ví dụ nêu trên.

Nếu như các dự án có yêu cầu cụ thể thì chúng ta có thể dễ dàng lập trình và kiểm thử chỉ trên môi trường theo yêu cầu đó, thì với các dự án không có yêu cầu thì chúng ta sẽ phải trao đổi và thống nhất được danh sách yêu cầu kiểm thử (testing scope) với những stakeholders liên quan để có thể đưa ra được những môi trường phần mềm cần kiểm thử.

Mặt khác, kiểm thử có 04 mức độ (test level) khác nhau. Tương ứng với mỗi level, sẽ là các môi trường cũng khác nhau. Unit Test (môi trường phát triển/Dev), Integration Test (môi trường kiểm thử), System Test (môi trường Staging), Acceptance Test (môi trường pre-production/production). Vậy nên, khi kiểm thử tùy vào mục đích và thời điểm của dự án mà chúng ta sẽ có các loại môi trường thực thi kiểm thử khác nhau.

Kịch bản thực thi Kiểm thử (Test Case/Test Scenario)

Thành phần này thì đương nhiên phải có rồi vì nó là trung tâm của việc kiểm thử. Có người đã từng nói: “Sản phẩm của một Lập trình viên (Developer) là source code họ viết ra thì sản phẩm của một Kiểm thử viên (Tester) chính là kịch bản Test”. Thậm chí, người ta hoàn toàn có thể đánh giá được trình độ chuyên môn hay kinh nghiệm của một Tester thông qua việc đọc Test Case/Test Scenario mà người đó thiết kế.

Đối tượng Kiểm thử (Test Object)

Trong kịch bản kiểm thử, chúng ta thường sẽ đưa ra các hành động tương tác với một đối tượng nào đó ở phần các bước thực hiện. Ví dụ:

• Test giao diện (bao gồm Web và Mobile): Button, Dropdown list, Textbox,….
• Test Web Service: API
• Test Database: Bảng, các trường thông tin của một bảng,…

Các hành động tương tác có thể kể đến như click, set text, choose, send (đối với Web service), query (đối với Database),…. Vậy nên, có thể thấy nếu không có Test Object thì chúng ta sẽ không biết phải tương tác với cái gì khi kiểm thử đúng không nhỉ?

Dữ liệu Kiểm thử (Test Data)

Trong kiểm thử phần mềm, với mỗi một dữ liệu trong một kịch bản test nằm khác phân vùng tương đương (Partition Equivalent) cũng đã cho ra một kịch bản khác rồi. Hoặc nếu bạn đã từng sử dụng bảng quyết định (Decision table), thì việc tổ hợp các điều kiện đầu vào cũng sẽ cho các kết quả khác nhau. Điều này cho thấy được việc chuẩn bị một bộ dữ liệu cho các kịch bản test là quan trọng như thế nào vì nó sẽ quyết định được việc Test có thể bao phủ được hết những rủi ro có thể gặp phải dựa trên các yêu cầu của khách hàng hay không?

Bộ Kiểm thử (Test Suite)

Nếu như 04 thành phần kể trên sẽ liên quan mật thiết với việc thiết kế kịch bản, thì ở thành phần cuối cùng này sẽ giúp cho các bạn quản lý các kịch bản khoa học và dễ dàng hơn. Để các bạn dễ hình dung hơn thì có một câu chuyện như sau:

“Dự án của bạn đang phát triển 01 module và trong module đó sẽ có 03 chức năng A, B, C. Mỗi ngày bạn sẽ thiết kế kịch bản cho một chức năng. Các kịch bản bạn thiết kế của 03 chức năng này sẽ cứ nối đuôi nhau. Đến ngày thứ 4, bạn nhận thấy có một chức năng cần bổ sung thêm kịch bản và bạn viết tiếp vào đó. Và các ngày sau đó bạn cũng thấy mỗi một chức năng mình cần phải hiệu chỉnh lại kịch bản mà mình đã thiết kế.

Cho đến một ngày, khi bạn thực hiện kiểm thử theo kịch bản đã thiết kế, sếp yêu cầu bạn tổng hợp kết quả thực thi các kịch bản mà bạn đã thiết kế cho từng chức năng của module này. Lúc này bạn sẽ phải lần sờ lại từng dòng kịch bản của mình xem mỗi một chức năng có những kịch bản nào mà mình từng thiết kế. Và stress của bạn bắt đầu từ đây.”

Nếu như ở trường hợp trên, bạn gom nhóm các kịch bản kiểm thử mà mình thiết kế ra thành bộ kịch bản (test suite) thì có lẽ câu chuyện stress trên sẽ không bao giờ xảy ra đối với bạn đúng không nào? Mặt khác, khi phần mềm được hoàn thiện, việc test theo Business flow sẽ trở nên dễ dàng hơn cho các bạn rất nhiều khi bạn có thể nhặt các kịch bản mà mình thiết kế để lắp vào flow đó hoặc một tổ hợp các kịch bản Business flow cũng sẽ được gom lại theo từng User Story cũng sẽ giúp bạn dễ dàng đối chiếu vào bảng checklist các yêu cầu của khách hàng hơn.

Như đã nói ở phần mở đầu, về bản chất Automation Test sẽ có nhiệm vụ thay thế một phần công việc của Manual Test mà ở đây đó là việc thực thi các kịch bản mang tính lặp đi lặp lại. Vậy nên, chắc chắn rằng kiểm thử tự động không thể nào thiếu được 05 thành phần vừa được kể trên. Phần tiếp theo Test Mentor sẽ ánh xạ các thành phần này sang project Auto Testing xem có điểm gì khác biệt không nhé!

Những thành phần của cơ bản của project Automation test.

Môi trường thực thi Kiểm thử (Test Environment)

Trong Automation test, Test environment về bản chất là các thông tin, dữ liệu liên quan đến một đối tượng mà các script automation test sẽ thực thi (Ví dụ: link test, driver, …). Và nó sẽ dùng để thực thi xuyên suốt các kịch bản test nên nó sẽ được lưu trữ dưới dạng Global Variable. 

Kịch bản thực thi Kiểm thử (Test Case)

Đây là nơi viết tất cả những dòng code để triển khai các bước thực hiện (Test Steps) trong kịch bản. Có một điều cần lưu ý, nếu trong Kiểm thử thủ công, con người sẽ biết được thao tác này, hành động kia hoặc kịch bản này có thành công hay không. 

Tuy nhiên, trong Kiểm thử tự động, do là máy sẽ thực thi nên các câu lệnh ngoài việc thực hiện các bước như trong kịch bản thủ công đã thiết kế sẽ phải có các câu lệnh đối chiếu với kết quả mong đợi trong kịch bản. Đây là một lỗi mà một số bạn khi mới bắt đầu học hoặc làm về Auto Testing thường hay mắc phải do không có những câu lệnh này. Test Mentor sẽ nói chi tiết hơn về phần này trong các bài viết tiếp theo.

Đối tượng Kiểm thử (Test Object)

Trong một Auto test case, một Step Action sẽ phải tương tác với một đối tượng nào đó. Ví dụ: Navigate Url, Click Button, Set Text Textbox, Send Request Web Service,… Vậy nên, khi viết Script Automation test dù muốn hay không, chúng ta cũng sẽ phải tạo các đối tượng này để có thể tương tác với chúng.

Dữ liệu Kiểm thử (Test Data)

Cũng giống như Manual test mình đã nói ở phần trên, mỗi một hoặc một bộ data sẽ cho ra các kịch bạn khác nhau. Chính vì lẽ đó, automation test cũng không thể thiếu được thành phần này. Nói một cách khác, Test data giống như “huyết mạch” của cả một dự án kiểm thử vậy cho dù nó là Thủ công hay Tự động.

Tuy nhiên, có một điều mà các bạn phải hết sức lưu tâm đó là trong automation test việc truyền data (data binding) sao cho hợp lý để có thể tái sử dụng hoặc không bị lãng phí tài nguyên. Test Mentor sẽ nói chi tiết hơn về phần này trong các bài viết tiếp theo.

Bộ Kiểm thử (Test Suite)

Nếu trong Manual test, việc tạo ra một bộ kiểm thử sẽ giúp chúng ta dễ dàng quản lý các kịch bản kiểm thử một cách hiệu quả, thì trong Automation test ngoài việc trên nó còn giúp chúng ta “nhàn” khi vận hành các kịch bản. Tại sao ư? 

Bạn hãy thử nghĩ xem nếu chúng ta có khoảng 10 cái kịch bản mà cứ phải ngồi canh khi nào kịch bản này xong để bấm cho kịch bản tiếp theo chạy. Hoặc nếu như bạn phải chạy một Business flow với 10 chức năng thì bạn sẽ trải dài nó thành một Test case với trăm dòng code hay là tạo 10 test case cho các chức năng và ngồi canh như trên.

Nếu bạn chỉ cần gom chúng vào một Test suite, bạn chỉ cần ra lệnh thực thi 1 lần sau đó đi làm một tách trà và quay lại thưởng thức thành quả thôi. Quá là “nhàn” đúng không nào.

Ngoài ra, Test suite còn giúp bạn có thể chủ động chọn những test case phù hợp trong những đợt kiểm tra, vì mỗi đợt có thể bạn sẽ cần chạy lại một số test case liên quan thay vì chạy lại tất cả, và những test suite khác nhau sẽ áp dụng cho từng nhu cầu và mục tiêu cụ thể lúc đó.

Kết luận

Một vấn đề thường gặp đối với các bạn mới học Auto qua các tool như Selenium WebDriver, Appium, REST-Assured, … đó là các bạn gặp khó trong việc nhìn ra bức tranh tổng quan của một dự án Automation Test do các thành phần kể trên các bạn học riêng biệt dẫn đến khi lắp ráp nó thành một cỗ máy các bạn không biết phải làm như thế nào. Bài viết trên đây, Test Mentor đưa ra giúp cho các bạn có một bức tranh tổng quan hơn về một dự án từ đấy sẽ giúp các bạn quản lý source code của mình hiệu quả hơn cũng như tiếp thu các kiến thức dễ dàng hơn.

Ngoài ra, một lời khuyên mà Test Mentor dành đến cho các bạn đó là ngoài học những tool cơ bản các bạn nên tìm hiểu thêm những tool dạng Low-code (Codeless) như Katalon Studio vì những lý do sau đây:

• Dễ dàng hình dung được cấu trúc và cách vận hành của một dự án Automation Test
• Thời gian viết script Automation Test nhanh hơn
• Xu hướng các công ty công nghệ, đặc biệt là các công ty lớn là đang chuyển dịch sang các tool này vì nó giúp cho công việc liên quan đến automation test nhanh hơn từ đó đem lại hiệu quả kinh tế tốt hơn.

Từ đó, có thể thấy nếu các bạn có thêm kiến thức và cách sử dụng một tool sẽ giúp cho các bạn tăng được cơ hội việc làm và phát triển bản thân sau này.

Xem bài tiếp theo: Những điều cần lưu ý khi tạo một Scrip Test Case Automation Test

Chuột Béo Tester