Các loại kiểm thử tự động và những ngộ nhận
Theo Mohammad Saad
Trong bài thứ hai này, chúng ta sẽ mô tả sơ lược các kiểu kiểm thử tự động và sau đó, là phần quan trọng hơn, chúng ta sẽ làm rõ một số ngộ nhận về kiểm thử tự động.
Các loại kiểm thử tự động
Trong kiểm thử tự động, chúng ta có ba loại chính.
Tự động hóa kiểm thử đơn vị (Unit test)
Tự động hóa kiểm thử đơn vị là viết các bài kiểm thử ngay ở mức độ mã của ứng dụng. Lỗi được xác định bên trong từng chức năng, phương thức được viết bởi các kỹ sư phát triển.
Vài công ty yêu cầu kỹ sư phát triển tự làm kiểm thử đơn vị và một số công ty khác thì thuê nhân sự đặc biệt cho công việc này. Những nhân sự này có thể truy cập vào mã nguồn của ứng dụng và phát triển các bài kiểm thử đơn vị trên nền tảng mã nguồn đó. Với sự hiện diện của kiểm thử đơn vị, bất kỳ khi nào mã nguồn được biên dịch, tất cả các bài kiểm thử sẽ được thực thi và cho chúng ta biết kết quả của những chức năng nào hoạt động và không hoạt động. Nếu có một bài kiểm thử nào thất bại, nó có nghĩa là đang có lỗi trong mã nguồn hiện hành.
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)
Một giao diện lập trình ứng dụng (API) là phương thức một ứng dụng tương tác với một ứng dụng khác. Cũng như những ứng dụng khác, API cũng cần được kiểm thử. Trong loại kiểm thử này, giao diện đồ họa người dùng (GUI) ít khi được quan tâm đến.
Những gì mà chúng ta kiểm thử ở đây là các vấn đề về chức năng, sự phù hợp và bảo mật. Ví dụ như, trong ứng dụng Web, chúng ta có thể kiểm thử các câu lệnh Request/Response, kiểm thử những câu lệnh này có bảo mật và mã hóa hay khô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)
Loại kiểm thử này là loại khó khăn nhất trong kiểm thử tự động bởi vì nó liên quan đến kiểm thử giao diện người dùng của ứng dụng.
Nó khó khăn bởi vì GUI là đối tượng được thay đổi nhiều nhất. Nhưng, loại kiểm thử này lại gần nhất đối với người sử dụng, mô tả chính xác những gì người dùng làm với ứng dụng. Người dùng sử dụng chuột và bàn phím, bài kiểm thử cũng bắt chước cùng một hành động bằng cách dùng chuột và bàn phím để nhấn hay viết lên một đối tượng trên giao diện. Cùng cách đó, chúng ta sẽ dễ dàng tìm thấy lỗi và nó có thể được dùng trong nhiều tình huống như kiểm thử qui hồi hay điền thông tin vào form mà quá mất thời gian nếu làm thủ công.
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)
Vài ngộ nhận về kiểm thử tự động
Qua nhiều năm làm việc với kiểm thử tự động, chúng tôi từng nghe nhiều ngộ nhận về kiểm thử tự động. Chúng tôi cảm thấy rằng cần phải làm rõ nó trong bài này.
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 bạn cố gắng tự động hóa 100% các bài kiểm thử, có thể bạn có khả năng đó, nhưng nếu bạn làm như vậy, điều ở trên sẽ trở nên không còn đúng nữa. Bởi vì, nếu bạn tự động hóa mọi thứ, kỹ sư kiểm thử thủ công sẽ làm gì?
Mâu thuẫn phải không?
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%?
Mặt khác, có một cơ hội rất nhỏ rằng bạn có thể tự động hóa toàn bộ bài kiểm thử hiện có. 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ứ. Chỉ tự động hóa những gì 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
Đừng sống trong một thế giới nhiệm mầu. Phép lạ này thực tế chỉ được tạo ra bởi các quảng cáo sai làm từ những nhà cung cấp công cụ kiểm thử tự động. Họ nói rằng bạn chỉ cần Record và Playback những bước kiểm thử và, bài kiểm thử của bạn đã được tự động hóa. Oh. Một lời nói dối không hơn.
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 chúng ta đã quen với mã, chúng ta luôn tự viết các bài 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. Mặt khác, đừng thất vọng nếu bạn không biết lập trình. Bởi vì, nhưng mọi công việc khác, lập trình có thể học thông quan luyện tập và cống hiến.
Tôi biết nhiều người, không phải xuất thân từ Công Nghệ Thông Tin, nhưng học lập trình và trở thành những kỹ sư kiểm thử tự động tuyệt vời. Tại Microsoft, họ tuyển kỹ sư kiểm thử có khả năng lập trình. Những kỹ sư này được gọi là SDET (Software development engineers for test). Dòng đầu tiên trong mô tả công việc là: “SDET viết rất nhiều mã…”
Hãy học lập trình, đừng trốn chạy khỏi nó. Nó sẽ làm bạn trở thành một kỹ sư tuyệt vời.
Kết luận
Tôi hy vọng bài này sẽ giúp bạn có một khái niệm rõ ràng về kiểm thử tự động.
Trong bài tới, tôi sẽ thảo luận về cách để bắt đầu kiểm thử tự động trong một dự án.