Automation test giúp đỡ trong việc test như nào năm 2024

Manual Testing được thực hiện bởi người kiểm thử, lặp đi lặp lại công việc bằng việc test tay. Automation Testing được thực hiển bởi công cụ kiểm thử để thực hiện các bộ testcase. Phần mềm tự động có thể nhập dữ liệu test vào hệ thống được thử nghiệm, so sánh kết quả mong muốn và kết quả thực tế, đưa ra báo cáo chi tiết. Kiểm thử tự động cũng đòi hỏi đầu tư đáng kể vào chi phí và nguồn lực. Chu kỳ phát triển nối tiếp sẽ yêu cầu thực hiện các bộ test lặp lại nhiều lần. Việc sử dụng công cụ kiểm thử tự động, nó có thể ghi lại bộ test này và chạy lại khi được yêu cầu. Khi bộ test được chạy tự động, sự can thiệp của con người là không cần thiết. Mục đích của tự động là làm giảm số lượng testcase được chạy thủ công và không hẳn sẽ loại bỏ kiểm thử thủ công.

Tại sao lại là Automation Testing?

Kiểm thử phần mềm tự động là quan trọng vì những lí do sau:

• Việc kiểm thử thủ công tất cả các quy trình, các lĩnh vực, các kịch bản dường như rất tốn thời gian và chi phí
• Thật khó để kiểm thử thủ công các trang web đa ngôn ngữ
• Kiểm thử tự động không yêu cầu có sự can thiệp từ người kiểm thử. Bạn có thể chạy qua đêm mà không cần giám sát
• Kiểm thử tự động giúp tăng tốc độ thực thi kiểm thử
• Kiểm thử tự động giúp tăng độ bao phủ
• Kiểm thử thủ công có thể trở nên nhàm chán và dễ bị lỗi

Những trường hợp để kiểm thử tự động?

Các trường hợp kiểm thử tự động được lựa chọn sử dụng theo các tiêu chí sau để tăng tự động hóa:

• Rủi ro cao - Các trường hợp kiểm tra quan trọng
• Các trường hợp được thực thi lại nhiều lần
• Các trường hợp rất tẻ nhạt hoặc khó để kiểm tra thủ công
• Các trường hợp tiêu tốn nhiều thời gian

Phân loại các trường hợp không phù hợp cho kiểm thử tự động:

• Các trường hợp được thiết kế mới và chưa được thực hiện thủ công ít nhất một lần
• Các trường hợp luôn có sự thường xuyên thay đổi về yêu cầu
• Các trường hợp được thực hiện dựa trên các trường hợp đặc biệt

Quy trình kiểm thử tự động

Lựa chọn công cụ kiểm thử tự động

Công cụ kiểm thử tự động được lựa chọn phụ thuộc vào ứng dụng đang được xây dựng. Ví dụ, QTP không hỗ trợ tin học, vì vậy nên QTP không thể được sử dụng cho ứng dụng tin học.

Xác định phạm vi

Phạm vi tự động là phạm vi mà ứng dụng của bạn đang tiến hành thử nghiệm. Các điểm sau giúp bạn xác định phạm vi:

• Mang tính chất đặc thù kinh doanh
• Kịch bản với lượng dữ liệu lớn
• Các chức năng chung trên các ứng dụng
• Tính khả thi về kĩ thuật
• Sự mở rộng các thành phần kinh doanh được tái sử dụng
• Sự phức tạp của các trường hợp kiểm thử
• Khả năng sử dụng các trường hợp kiểm thử tương tự để kiểm thẻ trên nhiều trình duyệt

Kế hoạch, thiết kế và phát triển

Trong giai đoạn này, bạn cần tạo ra các kế hoạch và chiến lược tự động, bao gồm:

• Lựa chọn công cụ tự độg
• Thiết kế framework và các đặc điểm của nó
• Những điều trong phạm vi và ngoài phạm vi tự động
• Chuẩn bị thử nghiệm tự động
• Lên lịch, thời gian của kịch bản và thực thi
• Bàn giao sản phẩm kiểm thử tự động

Thực thi kiểm thử

Kịch bản tự động được thực thi trong giai đoạn này. Kịch bản này cần dữ liệu đầu vào trước khi chúng được thiết lập để chạy. Khi chạy, chúng sẽ cung cấp chi tiết báo cáo thực thi Sự thực thi có thể được thực hiện bởi các công cụ tự động trực tiếp hoặc thông qua công cụ quản lí thực thi - công cụ tự động

Bảo trì

Khi các chức năng mới được thêm vào hệ thống, kịch bản tự động cũng cần được thêm vào, xem xét và bảo trì cho từng giai đoạn phát triển

Trong phần cuối này, chúng ta sẽ tìm hiểu về công việc thường ngày về của 1 tester và sự hay ho của automation test – một trào lưu khá nổi gần đây (Nói gần đây chứ nổi chắc cũng cả mấy năm rồi) nha.

Series gồm 3 phần:

• Phần 1: Tại sao lập trình viên cần biết về testing?
• Phần 2: Thuật ngữ chuyên ngành testing và các loại testing
• Phần 3: Công việc thường ngày của tester. Automation test có gì hot?

Ở phần trước, mình đã có một sự so sánh nhẹ giữa manual testing và automation testing. Thật ra, manual testing là nền móng cho automation testing. Muốn tự động hoá một thứ gì, bạn phải biết cách thực hiện nó một cách thủ công trước.

Do vậy, mình sẽ kể các bạn nghe về công việc mà một tester phải làm hàng ngày, và automation testing sẽ giúp ta tiết kiệm thời gian như thế nào.

Công việc thường ngày của 1 tester

Nếu như công việc thường ngày của 1 developer là phân tích, thiết kế hệ thống và công thì công việc thường ngày của một tester là phân tích, thiết kế test case và … test.

Chúng ta tiếp tục câu chuyện về bạn Tùng tester phần trước. Mỗi ngày đi làm, Tùng nhận được 1 danh sách các test case để test (Danh sách này có thể do Tùng tự viết ra, hoặc của sếp hoặc các đàn anh đi trước trong team để lại).

Một test case bao gồm các thông tin:

• Tên test case + Mô tả thêm về test case đó
• Các bước thực hiện
• Môi trường + phiên bản test
• Kết quả nên có
• Kết quả thực tế (Phần này Tùng sẽ test sau đó ghi vào)

Dưới đây là một test case mẫu:

• Tên test case: Cho hàng vào giỏ hàng
• Các bước thực hiện: Đăng nhập, click vào nút “Mua Hàng” phía dưới sách Code Dạo Kí Sự trên trang chủ
• Môi trường + phiên bản test: Phiên bản 1.1.22 trên trình duyệt Chrome
• Kết quả nên có: Giỏ hàng có thêm sản phẩm sách Code Dạo Kí Sự với giá 112k
• Kết quả thực tế: Pass

Tùng thực hiện các bước với từng test case, đối chiếu kết quả nhận được với kết quả nên có, sau đó viết vào test report gửi cho sếp.

Khi phát hiện ra bug, Tùng sẽ log bug lại, sau khi có người trong team developer fix, Tùng sẽ vào test lại để xác nhận bug đã được fix.

Qui trình báo bug và fix bug

Test đi test lại là một chuyện … vô cùng nhàm chán và mệt mỏi

Các bạn có thể thấy, công việc của tester mang tính chất lặp đi lặp lại khá nhiều. Khi hệ thống có chức năng mới, tester phải test chức năng đó. Khi developer fix một bug, tester phải test để check lại bug đó.

Quan trọng hơn là, khi hệ thống có thay đổi (đổi design, thêm tính năng, refactor code), tester phải test lại những test case đã pass để đảm bảo những thay đổi này không… tạo thêm bug cho hệ thống (còn gọi là regression test). Nhiều khi các anh developer vô tình hay cố ý giấu bug vào thì sao.

Những việc testing này được thực hiện bằng tay, bằng sức người, gọi là manual test. Việc này vừa mất thời gian, vừa nhàm chán và mệt mỏi nên không thể làm thuường xuyên. Chưa kể, tester cũng là con người, cũng có lúc sai lầm hoặc sơ sót, test đi test lại sẽ để log bug.

Thế rồi, automation test ra đời, giải quyết hầu hết những vấn đề trên!

Automation Test là có gì hot?

Nguyên lý của automation test rất đơn giản. Thay vì test bằng tay, ta để máy thực hiện việc testing mà tester phải làm (Khởi động hệ thống, nhập dữ liệu đầu vào, kiểm tra so sánh với dữ liệu đầu ra và ghi kết quả).

Ta có thể viết code để cho máy làm những điều này, hoặc sử dụng một số công cụ record lại những hành động chúng ta đã làm, sau đó chạy lại những hành động này. Một số công cụ/framework mà các bạn Automation Tester hay dùng là QTP, Appium, Selenium,… .

Automation Test có gì hot?

Nếu các bạn chưa viết Automation Test bao giờ, ở lần đầu tiên chạy Automation test, bạn sẽ ngạc nhiên và sửng sốt vì nó quá cool. Trình duyệt tự động mở lên, nhập dữ liệu, click v…v mà không cần ta động tay động chân làm gì cả!

Automation test với selenium, các bạn bấm vào hình xem cho rõ nhé

Quay lại câu chuyện trên, nếu Tùng là một Automation Test engineer, Tùng sẽ chạy thử test case bằng tay, sau đó viết code hoặc dùng tool để automation. Lần sau, nếu hệ thống thay đổi, Tùng chỉ việc bấm Run để chạy code test và ngồi chờ kết quả, nhanh gọn chưa nào!

Với Automation Test, ta có thể test nhanh hơn, test thường xuyên hơn, test kĩ hơn. Ví dụ như người test chỉ có thể test 3,4 trường hợp, dùng automation test ta có thể test hàng chục hàng trăm trường hợp.

Tất nhiên Automation Test cũng có 1 số ưu khuyết điểm, nó chỉ bổ sung chứ không thể thay thế hoàn toàn manual test được. Có người đã viết kĩ rồi nên mình khỏi tóm tắt lại nhe.

https://viblo.asia/p/khi-nao-thi-su-dung-automation-testing-OeVKBYyE5kW

Automation Engineer – Hot mà hiếm

Như mình đã nói,manual testing là nền móng cho automation testing. Muốn tự động hoá một thứ gì, bạn phải biết cách thực hiện nó một cách thủ công trước.

Do vậy, dù developer chúng ta có thể viết code automation giỏi hơn các bạn tester, nhưng chúng ta thua xa tester về khả năng tìm lỗi, khả năng nghĩ ra testcase để test.

Thật lòng mà nói thì tìm Automation Engineer đôi khi còn khó tìm hơn lập trình viên. Vì vị trí này đòi hỏi phải có tư duy và góc nhìn của tester, vừa có kĩ năng code của developer. Đa phần code được thì họ đi làm developer cả rồi.

Do vậy, đây là vị trí khá “ngon ăn” với các bạn tester. Tuyển tester thường dễ hơn developer một chút. Các bạn làm manual test có thể nhảy từ manual sang automation, công việc thú vị hơn, ít nhàm chán hơn, lương cao hơn nữa (do nhu cầu mà).

Lương của Automation QC Engineer cũng không thua gì senior developer đâu nhe

(Nói nhỏ là mình full-stack nên viết code automation test cũng được luôn, có điều case chắc không cover nhiều bằng các bạn tester rồi).

Túm lại thì bài này mang lại lợi ích gì?

Thông qua bài này, các bạn đã hiểu hơn về công việc của các bạn tester trong công ty, qua đó thông cảm và thấu hiểu họ để làm việc hiệu quả hơn.

Dân developer chúng ta rất thích viết code. Làm Automation QC Engineer cũng viết rất nhiều code, các bạn nào có hứng thú cũng có thể thử nhảy qua luôn.

Ngoài ra, với nhiều team không có tester, developer chúng ta chịu khó viết unit test, automation test cũng sẽ giảm thiếu rất nhiều khả năng phát sinh bug; đâu có lỗ gì đâu phải không nào!

Kết

Như mình đã nói, testing là một mảng khá rộng khá rộng, có thể coi như một chuyên ngành riêng. Nội chuyện viết test case, unit test hoặc automation test cũng tốn 3, 4 cuốn sách rồi nên trong vòng 1, 2 bài viết code dạo sẽ không thể nói hết được.

Liên quan đến testing còn 1 số khái niệm như TDD, BDD nữa mà mình không nhắc đến trong bài viết. Mấy cái này mình chỉ biết về lý thuyết chứ chưa thực sự áp dụng bao giờ. Bạn nào có kinh nghiệm cứ comment chia sẻ cho mọi người nhé!