Các loại kiểm thử tự động và những ngộ nhận

Trước tiên, mình xin giới thiệu sơ lược về các loại kiểm thử tự động và sau đó là phần quan trọng hơn, mình sẽ nói rõ hơn một số ngộ nhận về kiểm thử tự động.

Trong kiểm thử tự động, có ba loại chính sau:

Kiểm thử đơn vị (Unit test)

- Tự động hóa kiểm thử đợn vị là gì ?

Kiểm thử đơn vị là viết các ca kiểm thử ngay ở mức độ mã của ứng dụng. Lỗi được xác định bên trong các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method) đều có thể được viết bởi các kỹ sư phát triển. Mục đích chính là để cô lập mỗi đơn vị của hệ thống để xác định, phân tích và sửa chữa các lỗi. - Lợi ích của Unit test

• Khi refactor code, sửa code hay thêm chức năng mới, Unit Test đảm bảo chương trình chạy đúng, phát hiện những lỗi tiềm tàng mà ta bỏ lỡ.
• Giảm chi phí kiểm thử vì các lỗi được phát hiện trong giai đoạn rất sớm.
• Cải thiện thiết kế và cho phép tái cấu trúc mã tốt hơn.
• Tăng sự tự tin khi code, vì đã có Unit Test phát hiện lỗi.

Vài công cụ phổ biến hiện này trên thị trường là NUnit và JUnit. Microsoft cũng cung cấp một nền tảng riêng cho kiểm thử đơn vị, gọi là MSTest. Trong các trang web của những công cụ này, các bạn sẽ tìm thấy các ví dụ và bài hướng dẫn cách sử dụng công cụ để viết các bài kiểm thử.

Kiểm thử tự động API/dịch vụ Web (API test)

API là từ viết tắt của Application Programming Interface. - Tổng quan

Trong mô hình này, toàn bộ ứng dụng được chia thành ba phần: lớp dữ liệu, mức logic và giao diện. Mức logic là API

Kiểm thử API là hoàn toàn khác biệt với kiểm thử GUI và các thành phần chủ yếu khác trong tầng business logic của kiến trúc phần mềm. Loại kiểm thử này không tập trung vào phần giao diện và thao tác giao diện của một ứng dụng.

Thay vì sử dụng các đầu vào(bàn phím) và đầu ra tiêu chuẩn, trong kiểm thử API, bạn có thể sử dụng một phần mềm để gửi các yêu cầu đến API, nhận đầu ra và ghi lại phản hồi của hệ thống. Công cụ nổi tiếng nhất cho kiểm thử API là SOAPUI, với cả hai phiên bản: bản quyền và cộng đồng (tính phí và miễn phí). Bên cạnh đó, còn nhiều công cụ khác mà bạn có thể tìm dựa vào nhu cầu của dự án.

Kiểm thử tự động giao diện đồ họa người dùng (GUI test)

Kiểm thử giao diện là một kỹ thuật kiểm thử trong đó giao diện người dùng của ứng dụng được kiểm thử xem có thực hiện đúng yêu cầu đối với hành vi giao diện người dùng hay không.

Một số danh mục cần kiểm thử trong GUI test

• Kiểm tra về giao diện
• Kiểm tra tính hợp lệ
• Kiểm tra phương pháp di chuyển/duyệt web
• Kiểm tra tính thân thiện của chương trình
• Kiểm tra tính ràng buộc dữ liệu

Các công cụ điển hình cho kiểm thử GUI là QTP (bây giờ là UFT), Selenium, Test Complete hay Microsoft Coded UI (một phần của Visual Studio phiên bản Ultimate và Premium)

Ngộ nhận 1: Tự động hóa là để thay thế việc của kỹ sư kiểm thử thủ công

Kiềm thử tự động là dùng để giúp đỡ kỹ sư kiểm thử thực thi kiểm thử nhanh hơn và đáng tin cậy hơn Nó không bao giờ có thể thay thế con người.

Hãy nghĩ kiểm thử tự động như một chiếc xe. Nếu bạn đi bộ, bạn sẽ phải tốn hơn 20 phút để về đến nhà. Nhưng nếu bạn đi xe, bạn có thể đến nơi trong vòng 4-5 phút. Người lái xe vẫn là bạn, một con người, nhưng… chiếc xe giúp chúng ta đến đích nhanh hơn. Hơn nữa, năng lượng của bạn sẽ được tiết kiệm, bởi vì bạn không đi bộ. Vậy, bạn có thể dùng năng lượng này để làm những việc quan trọng hơn.

Như James Back đã nói: "Công cụ không kiểm thử. Chỉ có con người làm kiểm thử. Công cụ chỉ mô phỏng hành động để “giúp” chúng ta kiểm thử. Công cụ có thể nhấn vào một đối tượng. Nhưng, nhấn vào đâu sẽ luôn luôn cần một kỹ sư kiểm thử hướng dẫn."

Ngộ nhận 2: Mọi thứ đều có thể tự động hóa

Nếu cố gắng tự động hóa 100% các ca kiểm thử, vậy chắc có lẽ không cần đến kỹ sư kiểm thử thủ công. Điều này lại gây mâu thuẫn với điều 1?

Sự thật là, bạn không thể tự động hóa 100% số lượng các bài kiểm thử. Bởi vì, chúng ta, các kỹ sư kiểm thử, tin rằng không có một ứng dụng nào có thể kiểm thử 100%. Có những kịch bản mà chúng ta bỏ qua. Sẽ có những lỗi chỉ khi ứng dụng đến tay người dùng.

Vậy, nếu một ứng dụng không thể kiểm thử 100%, làm cách nào đề tự động hóa 100%?

Có những kịch bản, mà ở đó rất khó để tự động hóa và dễ làm bằng thủ công.

Ví dụ, một người dùng nhập dữ liệu trên ứng dụng, một người dùng thứ hai sẽ kiểm tra dữ liệu đó, người dùng thứ ba chỉ xem dữ liệu và một người khác bị cấm xem dữ liệu. Kịch bản này có thể được tự động hóa, nhưng sẽ tốn nhiều thời gian và công sức. Để dễ dàng, bạn có thể làm nó một cách thủ công.

Hãy nhớ rằng, chúng ta dùng xe để di chuyển, nhưng sẽ có những tín hiệu đường trên đường đi, tiêu tốn nhiên liệu, chỗ đậu xe, phí đậu xe và đau đầu hơn khi lái xe. Trong vài trường hợp, chúng ta nên đi bộ đến nơi chúng ta muốn.

Vậy, bạn không nên tự động hóa mọi thứ mà chỉ nên sử dụng khi gặp những vẫn đề quan trọng và tốn thời gian nếu làm một cách thủ công.

Ngộ nhận 3: Tự động hóa chỉ có Record và Playback

Tự động hóa là mọi thứ ngoại trừ Record và Playback. Một kỹ sư kiểm thử tự động thuần túy không dùng Record/Playback. Record/Playback chỉ được dùng để có ý tưởng ban đầu về cách mã được sinh ra cho những bước kiểm thử. Một khi bạn đã quen với các đoạn mã thi bạn có thể tự viết các ca kiểm thử tự động. Hãy nhớ, bạn cần phải biết lập trình nếu bạn muốn làm kiểm thử tự động.

Không còn gì tuyệt vời hơn nếu bạn trở thành một kỹ sư vừa có khả năng lập trình và có khả năng kiểm thử ứng dụng mà mình tạo ra.

Mình hy vọng bài viết này sẽ giúp mọi người có một khái niệm rõ ràng về kiểm thử tự động và tránh những ngộ nhận không đáng có.