3 loại hình tự động thử nghiệm phổ biến

Hãy bắt đầu với những kiến thức cơ bản! Khám phá hai chế độ kiểm thử chung và 3 loại tự động hoá kiểm thử phổ biến.

Chúng ta đều đã từng gặp phải: meme lập trình định kỳ nào thường xuyên xảy ra trong cuộc sống thực?

Một chiếc tủ có hai ngăn mà bạn không thể mở cùng một lúc.

Meme này tóm tắt khá rõ ràng: mỗi ngăn hoạt động hoàn hảo riêng lẻ, nhưng khi kết hợp với ngăn khác, chúng sẽ chặn lẫn nhau và không hoạt động. Bạn muốn cả hai ngăn hoạt động tốt với nhau và có thể hoạt động cùng lúc.

Cùng một chiếc tủ nhưng có hai ngăn mà bạn có thể mở cùng một lúc.

Áp dụng điều này cho việc phát triển web: bạn đã viết một số chương trình kiểm thử, thậm chí có thể đạt được mức độ sử dụng chương trình kiểm thử 100%, nhưng ứng dụng của bạn vẫn cần hoạt động sau khi các phần khác được đưa vào đúng vị trí. Các đơn vị có thể hoạt động tốt riêng lẻ nhưng không liên quan đến nhau. Việc viết một số bài kiểm thử là rất quan trọng nhưng đó chỉ là một phần của quá trình thiết lập kiểm thử lý tưởng cho dự án của bạn. Bước đầu tiên, bạn cần xác định những phần chất lượng ứng dụng cần đảm bảo và cách đạt được điều đó.

Nói một cách đơn giản, bạn cần có kế hoạch trước khi bắt đầu viết mã kiểm thử thực tế. Để tiếp cận chủ đề về cách kiểm thử thực tế, hãy bắt đầu bằng một bảng trống và trả lời hai câu hỏi cơ bản:

  • Bạn muốn kiểm thử như thế nào?
  • Bạn muốn thử nghiệm nội dung nào?

Bài viết này tập trung vào những điều chung mà bạn cần biết để trả lời câu hỏi đầu tiên. Để bắt đầu từ một nền tảng chung, trước tiên, hãy tìm hiểu xem có những chế độ kiểm thử nào, sau đó tập trung vào các loại kiểm thử phổ biến. Trong các bài viết sau, chúng ta sẽ trả lời câu hỏi thứ hai, kết hợp các câu trả lời và tìm ra chiến lược kiểm thử phù hợp nhất với dự án của bạn. Bắt đầu! 🙌

Bắt đầu từ những kiến thức cơ bản: Chế độ kiểm thử chung

Khi trả lời câu hỏi về cách kiểm thử, điểm đầu tiên cần làm rõ là rất trừu tượng. Bạn nên kiểm thử theo cách thủ công hay để máy tính kiểm thử? Tuy nhiên, điều quan trọng là bạn không được rơi vào lối tư duy nhị phân ở đây.

Kiểm thử thủ công so với kiểm thử tự động

Nếu bạn yêu cầu các kỹ sư đảm bảo chất lượng xác định hoạt động kiểm thử, trước tiên, họ có thể chia hoạt động này thành hai "chế độ":

  • Kiểm thử thủ công. Đây là phương pháp kiểm thử điển hình do con người thực hiện. Kỹ sư đảm bảo chất lượng sẽ nhấp vào ứng dụng, kiểm tra xem ứng dụng có hoạt động hay không và đồng thời cố gắng làm hỏng ứng dụng. Cách phổ biến nhất là kiểm thử thăm dò, trong đó kỹ sư kiểm tra ứng dụng bằng kiến thức của họ về ứng dụng đó dựa trên một lộ trình hoặc danh sách kiểm tra được xác định trước.
  • Kiểm thử tự động. Đây là một loại hình kiểm thử do máy tính thực hiện. Các kỹ sư đảm bảo chất lượng triển khai công cụ này để tự động hoá các quy trình kiểm thử lặp đi lặp lại và đơn điệu.

Chuỗi hướng dẫn này chủ yếu tập trung vào kiểm thử tự động. Tuy nhiên, bạn không nên chỉ tập trung vào một cách kiểm thử. Mặc dù việc tự động hoá giúp tiết kiệm nhiều thời gian và công sức, nhưng con người và hoạt động kiểm thử thủ công sẽ luôn đóng vai trò quan trọng. Thay vào đó, tính năng tự động hoá kiểm thử sẽ giúp mọi người tập trung vào kiểm thử khám phá và giải quyết vấn đề một cách sáng tạo. Ví dụ: đảm bảo chất lượng trải nghiệm người dùng hoặc bảo vệ logic kinh doanh có rủi ro cao. Nói cách khác, tính năng tự động hoá sẽ hỗ trợ bạn. ❤️

Hộp mờ so với hộp trong suốt

Như vậy, bạn đã xác định các chế độ kiểm thử chung. Tuy nhiên, như vậy vẫn chưa đủ. Để lập kế hoạch chiến lược kiểm thử, bạn cần trả lời thêm một câu hỏi: bạn có nên biết cách hoạt động của ứng dụng hay không hay tốt hơn là bạn không cần biết kiến thức này để kiểm thử? Tuỳ thuộc vào câu trả lời, bạn có thể chọn một trong hai quy trình để lấy và chọn các trường hợp kiểm thử:

  • Kiểm thử hộp mờ (hoặc kiểm thử hộp đen). Phương pháp này dựa trên việc phân tích các yêu cầu (quy cách) chức năng hoặc phi chức năng của một thành phần hoặc hệ thống mà không xem xét cấu trúc nội bộ của thành phần hoặc hệ thống đó.
  • Kiểm thử hộp trắng (hoặc kiểm thử hộp trong suốt) là một quy trình tính đến cấu trúc nội bộ của hộp đó. Nói cách khác, cách ứng dụng của bạn hoạt động.

Bạn có thể áp dụng cả hai quy trình này cho hoạt động kiểm thử thủ công và tự động. Tuy nhiên, một số khía cạnh của chế độ kiểm thử chung có thể tập trung nhiều hơn vào một trong hai khía cạnh này. Chúng ta sẽ đề cập đến khía cạnh đó sau. Hiện tại, hãy phân tích sâu hơn về việc tự động hoá kiểm thử thành các loại.

Loại kiểm thử tự động: Bạn muốn kiểm thử như thế nào?

Khi gần trả lời được câu hỏi "làm cách nào", bạn đã quyết định thực hiện một số kiểm thử thủ công. Tuy nhiên, việc chọn và áp dụng các loại quy trình tự động hoá kiểm thử sẽ khó khăn hơn một chút. Các loại kiểm thử tự động hoá liên quan chặt chẽ đến các chỉ số mà bạn muốn tạo trong dự án. Vì vậy, hãy cùng tìm hiểu kỹ hơn về những tính năng quan trọng nhất.

Như minh hoạ trong meme được đề cập ở trên, bạn đã gặp hai loại: kiểm thử đơn vị và kiểm thử tích hợp. Kiểm thử toàn diện là phương pháp quan trọng thứ ba cần cân nhắc. Nhưng đó chưa phải là tất cả. Hãy cùng tìm hiểu kỹ hơn.

Kiểm thử đơn vị

Kiểm thử đơn vị là một loại kiểm thử trong đó các phần hoặc đơn vị kiểm thử nhỏ của ứng dụng được kiểm thử riêng lẻ và độc lập để đảm bảo hoạt động đúng cách. Các đơn vị này có thể khác nhau về phạm vi từ hàm, lớp hoặc giao diện đến dịch vụ hoặc thành phần hoàn chỉnh. Các thuộc tính chính của chúng là tốc độ thực thi, khả năng tách biệt và khả năng bảo trì dễ dàng. Nếu bạn muốn tìm hiểu sâu hơn về kiểm thử đơn vị, hãy xem hướng dẫn về kiểm thử đơn vị này.

Hình ảnh đơn giản về kiểm thử đơn vị cho thấy dữ liệu đầu vào và đầu ra.

Kiểm thử tích hợp

Kiểm thử tích hợp tập trung vào các hoạt động tương tác giữa các thành phần hoặc hệ thống. Nói cách khác, đó là mức độ phối hợp hiệu quả của các thành phần. Ví dụ điển hình về kiểm thử tích hợp là kiểm thử API hoặc kiểm thử thành phần.

Hình minh hoạ đơn giản về kiểm thử tích hợp cho thấy cách hai đơn vị hoạt động cùng nhau.

Kiểm thử toàn diện

Các kiểm thử này thường được gọi là kiểm thử giao diện người dùng và tên này giải thích rõ hơn về chức năng của các kiểm thử này. Các kiểm thử này tương tác với giao diện người dùng của ứng dụng, bao gồm cả ngăn xếp ứng dụng hoàn chỉnh và kiểm thử ứng dụng từ đầu đến cuối.

Hình minh hoạ đơn giản về quy trình kiểm thử toàn diện, trong đó máy tính được xem là một rô-bốt đang xem quy trình làm việc.

Các bài kiểm thử này giống với kiểm thử hệ thống nếu bạn tham khảo lý thuyết về đảm bảo chất lượng. Các thử nghiệm này mô phỏng một người dùng thực sự và hoạt động tương tác của họ. Kiểm thử toàn diện mất nhiều thời gian chạy hơn vì liên quan đến toàn bộ hệ thống và thời gian chạy nhiều hơn đòi hỏi nhiều sức mạnh điện toán hơn. Do đó, việc này sẽ làm tăng chi phí bảo trì.

Kiểm thử giao diện người dùng bằng hình ảnh

Một danh mục phụ thú vị của kiểm thử giao diện người dùng là kiểm thử hình ảnh. Các kiểm thử này là kiểm thử toàn diện mở rộng, cung cấp phương tiện để xác minh kết quả hiển thị của một ứng dụng. Quy trình kiểm thử này sẽ chụp ảnh màn hình sau khi thay đổi và một ảnh chụp màn hình khác chứa "trạng thái hiện tại" (hoặc tệp vàng), sau đó cung cấp kết quả đó cho một người đánh giá để kiểm tra và kiểm tra. Nói cách khác, công cụ này giúp tìm "lỗi hình ảnh" trong giao diện của một trang, ngoài các lỗi thuần tuý về chức năng và không được ghi rõ ràng vào các câu nhận định.

Phân tích tĩnh

Còn một điều nữa cần giới thiệu ở đây: phân tích tĩnh. Đây không phải là một loại kiểm thử theo nghĩa trong sách giáo khoa. Tuy nhiên, đây sẽ là một khía cạnh thiết yếu trong các chiến lược đảm bảo chất lượng sau này. Bạn có thể tưởng tượng công cụ này hoạt động như một hàm kiểm tra chính tả: công cụ này quét mã của bạn để tìm các lỗi cú pháp và lỗi nghiêm trọng hơn mà không cần chạy chương trình, từ đó phát hiện các vấn đề về kiểu mã. Biện pháp đơn giản này có thể ngăn chặn nhiều lỗi. Đây là thời điểm thích hợp để tìm hiểu về Phân tích tĩnh nếu bạn muốn tìm hiểu kỹ hơn về kỹ thuật này.

Kiểm thử ở mọi hình dạng: Tất cả những điều này hoạt động cùng nhau như thế nào?

Trong khi tìm câu trả lời cho tất cả những câu hỏi này, bạn có thể tìm thấy một giải pháp khả thi trong một số phép so sánh. Cụ thể, trong cộng đồng web và kiểm thử, các nhà phát triển thường sử dụng những phép so sánh này để cho bạn biết số lượng kiểm thử bạn nên sử dụng theo loại nào.

Nhiều hình dạng như kim tự tháp, kim cương, kem ốc quế, tổ ong và chiếc cúp; đại diện cho các chiến lược kiểm thử.

5 chiến lược sau đây được mô tả trong hình ảnh này là những chiến lược phổ biến nhất:

  • Kim tự tháp kiểm thử
  • Kim cương kiểm thử
  • Kiểm thử Ice Cone (còn gọi là Kiểm thử Pizza)
  • Kiểm thử Honeycomb
  • Cúp thử nghiệm

Đây thực sự là một lượng lớn thông tin cần xử lý. Bạn nên quyết định chiến lược kiểm thử phù hợp dựa trên tất cả những điều này như thế nào? Đừng lo, chúng tôi sẽ giúp bạn. Trong bài viết tiếp theo, chúng ta sẽ thảo luận chi tiết hơn về các chiến lược này và giải thích cách chọn chiến lược phù hợp nhất với dự án của bạn. Hãy tiếp tục theo dõi! 🔥