Trong bài viết trước về “Các thành phần cơ bản của một dự án Automation Test” thì một trong những số đó là script Test case. Đối với các bạn mới bắt đầu tìm hiểu về kiểm thử tự động, cụ thể hơn là các bạn mới bắt đầu học thì một trong những điều làm các bạn bối rối là không biết là phải triển khai một kịch bản kiểm thử thủ công sang một script Automation test như thế nào. Có rất nhiều lý do làm các bạn bối rối như vậy, nhưng một trong những nguyên nhân ấy đến từ việc các bạn chưa có được cái nhìn tổng quan về một script test case. Trong bài viết này, Test Mentor sẽ đưa ra những thành phần không thể thiếu trong một script Test case qua đó sẽ có những lưu ý cho các bạn khi viết test case.

Xem thêm: Thiết kế test case trong kiểm thử phần mềm

Những thành phần không thể thiếu trong script Test case

Trước khi tìm hiểu về các thành phần này, chúng ta hãy cùng nhìn lại các thành phần có trong một kịch bản kiểm thử thủ công:

1. Mục đích kiểm thử (Title/Purpose)
2. Các bước thực hiện (Procedure/Steps)
3. Dữ liệu đầu vào (Data input)
4. Kết quả mong đợi (Expected Result)
5. Kết quả thực tế (Actual Result) – Thành phần không cần thiết phải có trong script Test case mà thay vào đó là kết quả được ghi nhận (Pass/Fail) sau khi đã đối chiếu với Expected Result.

Mà như chúng ta biết, muốn kiểm thử tự động thực thi kịch bản giống như thủ công làm thì chúng ta không được thiếu những gì cơ bản mà con người làm đúng không nào? 

Nhìn vào các thành phần trên, thì “Mục đích kiểm thử” là trong script automation test không cần thiết phải thể hiện trong Automation script vì bản thân cách các bạn thiết kế script đã thể hiện được việc này nên Test Mentor sẽ nói về nội dung này. Tuy nhiên, các bạn nên viết chúng dưới dạng comment ở đầu mỗi script Test case để tất cả mọi người trong team khi xem lại hoặc người khác tiếp nhận script đó có thể hiểu mục đích của nó nhanh chóng và dễ dàng. Còn các thành phần khác thì sao nhỉ? Dưới đây sẽ là các thành phần không thể thiếu trong một script test case mà đó được ánh xạ với các thành phần trong manual test case.

Để các bạn dễ hình dung, Test Mentor sẽ đưa một ví dụ về phần “Bước thực hiện” của một kịch bản kiểm thử thủ công cho chức năng “Đăng nhập” được viết như sau:

• Bước 1: Truy cập link…
• Bước 2: Nhập vào … giá trị …
• Bước 3: Nhập vào … giá trị …
• Bước 4: Click …

Event/Action của mỗi Test Step

Đây là một trong những thể hiện của bước thực hiện trong Kịch bản kiểm thử thủ công. 

Với mỗi một từ khóa trên chính là một Event/Action của một Test Step. Và rõ ràng trong script test case phải thể hiện được những điều này. Ví dụ: một số Keyword trong Katalon (các tool khác có thể sẽ có những tên gọi khác nhưng sẽ có chức năng tương tự) có thể kể đến: navigateURL, setText, sendKey, click (đối với WebUI), sendRequest (đối với API), tap (đối với mobile),…

Test Object tương ứng với mỗi Test Step

Tiếp tục với ví dụ ở phần đầu, thì ở bước 2 – bước 4, chúng ta có thể thấy “Nhập vào …” và sau đó là “Click …” các dấu “..” chính là các object mà các Event/Action sẽ tương tác.

Để có thể dễ hình dung, các Test Object sẽ giúp các bạn trả lời các câu hỏi:

• Nhập vào đâu?
• Click cái gì?
• Gửi cái gì? (thường là đối với API testing)
• …

Đối tượng tiếp nhận Data input

Như trong bài viết về “Các thành phần cơ bản của một dự án Automation Test” thì Test Data là một thành phần rất quan trọng trong một script Automation test. Vậy thì muốn đưa một data input vào trong script thì phải làm sao nhỉ?

Nhìn vào ví dụ trên, ở bước thứ 2 và bước thứ 3, với test object sẽ giải đáp cho phần điền vào chỗ trống của dấu “…” đầu tiên, thì thành phần này sẽ giúp các bạn điền tiếp vào dấu “…” còn lại đó là nhập vào đối tượng nào cái gì?

Đối với mỗi một keyword của một tool sẽ luôn có một tham số để hỗ trợ cho người viết script truyền một giá trị nào đó vào tham số đó và các bạn hoàn toàn có thể viết trực tiếp vào đó, nhưng ở đây mình hoàn toàn khuyên các bạn không nên truyền một giá trị cố định vào tham số đó mà hãy thông qua một Variable hoặc Object nào đó, lý do mình sẽ nói chi tiết hơn ở phần bên dưới.

Các hoạt động đánh giá kết quả thực thi test case

Nhìn vào ví dụ đầu bài, hình như chúng ta thiếu một cái gì đó nhỉ? Thực hiện hết các bước rồi thì giờ phải làm gì để máy nó hiểu được là việc thực thi test case nó thành công?

Các bạn đã nhận ra được vấn đề rồi đó. Bình thường trong kịch bản kiểm thử thủ công, việc viết thêm bước kiểm tra kết quả thực tế trong “Bước thực hiện” không phải là điều bắt buộc. Lý do được đưa ra là vì con người chúng ta khi thực hiện các bước trên đồng thời cũng biết được rằng thế nào là Pass dựa vào đối chiếu với Kết quả mong đợi. Chỉ cần quan sát bằng mắt thôi cũng có thể biết được nên cũng không nhất thiết phải có một bước “Kiểm tra kết quả chương trình”.

Và đây cũng chính là điều mà rất nhiều bạn khi mới bắt đầu Automation test hay gặp lỗi nhất, đó là chuyển từ kịch bản thủ công sang script automation test nhưng chạy lúc nào cũng thấy Pass kể cả là chương trình có lỗi.

Cũng giống như manual test case, thì ở các hoạt động đánh giá này sẽ bao gồm hai thành phần đó là Actual Result và Expected Result. Và chúng ta phải thực hiện so sánh Kết quả thực tế với Kết quả mong đợi

Những điều cần lưu ý khi viết Script Test case

Tận dụng tối đa sức mạnh của OOP (Object Oriented Programming – Lập trình hướng đối tượng)

Để có thể là một thể hiện tốt nhất cho một kịch bản kiểm thử thủ công cũng như vận hành dễ dàng, thì mỗi một dòng code trong một script của mỗi script sẽ chỉ nên thực hiện một test step trong kịch bản. Hiện nay, các tool automation test đa phần đều có một bộ thư viện các keyword để có thể giúp cho các automation tester thực hiện được việc này. Tuy nhiên, trong thực tế, không phải lúc nào các keyword trong bộ thư viện đó có thể thực hiện một event/action của một test step trong một dòng code được. 

Ví dụ về một dropdown list trên giao diện của một ứng dụng, một số thư viện của một số tool có keyword là selectionByID() hoặc selectionByValue(),… và các câu lệnh này sẽ chỉ có thể sử dụng được với các Object có dạng cặp thẻ HTML <select> – <option>. Trên thực tế, có rất nhiều các WebApp họ lại không thiết kế theo dạng trên, thay vào đó họ sẽ để dropdown list đó trong một thẻ khác như <div>, <p-dropdown>,…. và danh sách các giá trị sẽ chỉ xuất hiện khi chúng ta click vào dropdown list ấy. Và khi gặp các tình huống kiểu như thế này, chúng ta sẽ phải thực hiện kha khá dòng code.

Nhìn vào ví dụ vừa qua, nếu gặp những tình huống này, phải làm sao để có thể vẫn thực hiện được chỉ với một dòng code nhỉ? Rất đơn giản, các bạn hãy vận dụng tối đa sức mạnh mà OOP (Lập trình hướng đối tượng) mang lại. Trong khuôn khổ của bài viết này, Test Mentor sẽ không đưa ra khái niệm về OOP ở đây, tuy nhiên có một câu thần chú mà mình hay sử dụng đó là: “Cái gì mà nhiều dòng code quá thì giao cho một Object làm.”

Một trong những best practice cho các bạn áp dụng điều này, đó chính là việc làm sao có thế kiểm tra tất cả dữ liệu đầu ra với kết quả mong đợi chỉ trong một dòng code. Như các bạn đã biết, với mỗi một test case sẽ có những cách kiểm tra kết quả đầu ra khác nhau, nhưng thường một nhóm kịch bản có cùng mục đích hoặc mục đích tương tự nhau sẽ có hình thức kiểm tra tương đồng nhau. Và đây chính là gợi ý để các bạn có thể thực hành giải quyết đầu bài trên.

Data input không nên gán trực tiếp vào tham số của Keyword

Như các bạn đã biết, trong một kịch bản sẽ có những data cho một trường dữ liệu mà bạn nhập kiểu gì cũng được vì nó đều cho ra chung một kết quả, nhưng cũng có những data mà nó sẽ là một tập hợp nhiều giá trị mà mỗi giá trị nó lại cho ra một kết quả khác nhau hoặc to hơn một chút đó là một tổ hợp các giá trị đầu vào của nhiều giá trị sẽ cho ra nhiều kết quả khác nhau. Phần này nhìn rõ nhất chính là khi các bạn sử dụng Kỹ thuật Bảng quyết định (Decision Table). Vậy nếu ta gán trực tiếp một giá trị nào đó vào tham số của Keyword sẽ xảy ra điều gì?

1. Nếu kịch bản kiểm thử cho một chức năng với các trường hợp dữ liệu đầu vào khác nhau, thì khi gán cứng một giá trị các bạn sẽ phải nhân bản script đó lên tương ứng với số lượng kịch bản mà bạn đã thiết kế ra cho mỗi một nhóm dữ liệu đầu vào như vậy.
2. Khi bạn vận hành một project automation test, nếu cần thay đổi một dữ liệu nào đó, hãy hình dung lúc đó bạn sẽ phải lần sờ từng dòng script trong một mớ các test case để tìm ra được giá trị đó để thay đổi. Mặt khác, nếu như dữ liệu cần phải thay đổi ấy lại nằm ở tất cả các test case mà bạn đã nhân bản thì bạn nghĩ rằng mình sẽ mất bao lâu để thay đổi toàn bộ chỗ dữ liệu ấy.

Và để giải quyết vấn đề này như mình đã nêu ở phần trên, đó là các bạn hãy đặt các biến để có lưu trữ các giá trị data truyền vào test case. Lúc này các bạn sẽ chỉ cần kiểm soát dữ liệu thông qua các file data khi vận hành và bảo trì project automation test của mình.

Các câu lệnh Assertion là khác so với câu lệnh Điều kiện

Đây là lỗi mà các bạn khi mới bắt đầu học Automation test hay mắc phải nhất. Lỗi này nó dẫn đến việc, rõ ràng chương trình khi chạy test bị lỗi nhưng kết quả thực thi kiểm thử tự động lại báo là Pass. Tại sao vậy?

Về bản chất, Automation test là một dạng chương trình cho chạy một đoạn mã lệnh nào đó theo kịch bản để dò tìm vấn đề bất thường khi thực thi kịch bản đó. Nói một cách khác Automation test sẽ thực thi các bước trong script và nếu như một Test Step gặp trở ngại (có thể do lỗi code auto hoặc có thể do lỗi chương trình) nó sẽ được đẩy vào ngoại lệ (Exception). Exception là một vấn đề hoặc một tình trạng bất thường khiến cho chương trình không hoạt động theo cách bình thường.Các câu lệnh Assertion là một dạng của xử lý ngoại lệ trong các tool và framework về automation test.

Nếu các bạn sử dụng câu điều kiện (If…else hoặc switch…case), thì chuyện gì sẽ xảy ra. Khi script automation test được thực thi đến câu lệnh điều kiện và sau đó một câu lệnh nào đó được thực thi nếu đảm được điều kiện của if. Kể cả trong trường hợp không có một trường hợp nào đảm bảo điều kiện của if nó cũng sẽ sang câu lệnh tiếp theo (nếu có). Về bản chất, câu lệnh điều kiện này vẫn được chạy qua mà không gặp trở ngại nào cả. Đấy chính là lý do của việc khi đến bước kiểm tra kết quả đầu ra của kịch bản, mặc dù chương trình bị lỗi nhưng kết quả thực thi kiểm thử tự động lại báo Pass. Vì đơn giản script chạy qua các câu lệnh không hề gặp một trở ngại nào cả.

Tóm gọn lại, khi chúng ta viết bước thực hiện kiểm tra kết quả của một script test case, hãy luôn nhớ sử dụng các câu lệnh về Assertion thay vì sử dụng các câu điều kiện để kết luận test case đó.

Kết luận

Trên đây là những điều cần lưu ý khi các bạn thiết kế một script test case cho một dự án Automation test. Và đây cũng là những điều, theo mình nghĩ đó là cơ bản khi bắt đầu viết kiểm thử tự động dù ở bất kỳ một tool hay framework nào cũng đều có.

P/S: Trong bài viết mình có sử dụng một số hình ảnh liên quan đến tool Katalon để có thể có một góc nhìn trực quan về những điều mình nói. Ngoài các tool đang học và tìm hiểu, các bạn cũng có thể nghiên cứu thêm về tool Katalon để có thể có một góc nhìn tổng thể hơn về dự án cũng như có thêm những cơ hội việc làm tại nhiều Công ty lớn nhé!

Chúc các bạn học tập hiệu quả và thành công trên con đường chinh phục môn phái Automation test đầy thú vị này trong ngành IT và hẹn gặp lại vào các bài viết tiếp theo!

Xem bài tiếp: Test Suite – Công cụ quản lý kiểm thử cho các Test Level

Chuột Béo Tester