Hãy bắt đầu với những thông tin cơ bản! Khám phá hai chế độ kiểm thử chung và ba loại kiểm thử tự động hoá phổ biến.
Ai trong chúng ta cũng đều gặp gỡ: vậy là meme lập trình định kỳ xuất hiện quá thường xuyên trong đời thực là gì?
Meme này tóm tắt nội dung của bạn khá đẹp: mỗi ngăn đều hoạt động hoàn toàn riêng biệt, 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 được. 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.
Áp dụng điều này vào việc phát triển web: bạn đã viết một số thử nghiệm, thậm chí có thể đạt được mức độ kiểm thử 100%, nhưng ứng dụng của bạn vẫn cần hoạt động khi các phần khác đã sẵn sàng. Các đơn vị này có thể hoạt động tốt khi đứng riêng rẽ nhưng không liên quan đến nhau. Việc viết một số chương trình kiểm thử rất quan trọng nhưng đó chỉ là một phần trong quá trình thiết lập chương trình 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 của chất lượng ứng dụng mà bạn cần đảm bảo và cách bạn có thể đạ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ủ đề cách kiểm thử trong thực tế, hãy bắt đầu bằng một bảng tổng quát và trả lời hai câu hỏi cơ bản:
- Bạn muốn thử nghiệm 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 bạn cần biết để trả lời câu hỏi đầu tiên. Để bắt đầu từ một cơ sở chung, trước tiên, hãy tìm hiểu 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 tôi 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 thử nghiệm phù hợp nhất với dự án của bạn. Bắt đầu! 🙌
Bắt đầu từ thông tin cơ bản: Chế độ kiểm thử chung
Khi trả lời câu hỏi về cách kiểm tra, đ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 soát? Tuy nhiên, điều quan trọng là không rơi vào 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 thử nghiệm, trước tiên, họ có thể sẽ chia nhỏ thành hai "chế độ":
- Kiểm thử thủ công. Đây là một phương pháp thử nghiệm điển hình do những người thực tế thực hiện. Một kỹ sư đảm bảo chất lượng nhấp vào ứng dụng, kiểm tra xem ứng dụng có hoạt động hay không, đồng thời cố gắng phá vỡ ứng dụng. Cách phổ biến nhất là thử nghiệm khám phá, trong đó kỹ sư sẽ điều tra ứng dụng bằng cách sử dụng kiến thức của họ về ứng dụng dựa trên đường dẫn hoặc danh sách kiểm tra xác định trước.
- Kiểm thử tự động. Đây là loại thử nghiệm do máy tính thực hiện. Các kỹ sư đảm bảo chất lượng triển khai giải pháp này để tự động hoá việc loại bỏ các thử nghiệm lặp lại và đơn điệu.
Loạt hướng dẫn này chủ yếu sẽ 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 thử nghiệm. Ngay cả khi công nghệ tự động hoá giúp tiết kiệm nhiều thời gian và công sức, thì con người và việc kiểm thử thủ công vẫn luôn đóng vai trò quan trọng. Thay vào đó, tính năng tự động hoá thử nghiệm nên giúp mọi người có thời gian tập trung vào thử nghiệm khám phá và giải quyết vấn đề sáng tạo. Ví dụ: đảm bảo chất lượng của 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ự động hoá sẽ hỗ trợ bạn. ❤️
Hộp mờ so với hộp trong suốt
Vậy là bạn đã xác định được các chế độ kiểm thử chung. Tuy nhiên, như vậy là vẫn chưa đủ. Để lập kế hoạch cho chiến lược thử nghiệm, cần trả lời thêm một câu hỏi nữa: bạn nên biết nâng cao cách ứng dụng của bạn hoạt động hay tốt hơn là nên thử nghiệm mà không cần kiến thức này? Tuỳ thuộc vào câu trả lời, có hai quy trình để lấy và chọn trường hợp kiểm thử:
- Kiểm thử hộp mờ (hoặc kiểm thử hộp đen). Mô hình tổ hợp tiếp thị dựa trên việc phân tích các yêu cầu (quy cách) về 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 bên trong của thành phần hoặc hệ thống đó.
- Kiểm tra hộp trong suốt (hay kiểm thử hộp trắng) là một quy trình có tính đến cấu trúc bên trong của hộp nói trên. Nói cách khác là tìm hiểu sâu về cách ứng dụng của bạn hoạt động.
Bạn có thể áp dụng cả hai quy trình cho việc 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 chế độ này – chúng ta sẽ đề cập đến vấn đề này sau. Bây giờ, hãy chia nhỏ hơn về hoạt động tự động hoá kiểm thử thành các loại.
Thử nghiệm các loại tự động: Bạn muốn thử nghiệm như thế nào?
Khi gần đến bước trả lời được câu hỏi "cách thực hiện", bạn đã quyết định thực hiện một số thử nghiệm thủ công. Tuy nhiên, việc chọn và áp dụng các kiểu tự động kiểm thử sẽ khó khăn hơn một chút. Các loại kiểm thử tự động có liên quan chặt chẽ đến các chỉ số mà bạn muốn tạo trong dự án của mình. Hãy cùng tìm hiểu kỹ hơn về những chỉ số quan trọng nhất.
Như minh hoạ trong meme đã đề cập trước đó, bạn đã gặp hai loại: kiểm thử đơn vị và kiểm thử tích hợp. Thử nghiệm toàn diện là yếu tố quan trọng thứ ba cần cân nhắc. Nhưng đó không phải là tất cả các nguyên nhân đó. 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 hình kiểm thử trong đó các phần hoặc đơn vị nhỏ có thể kiểm thử của một ứng dụng được kiểm thử riêng lẻ và độc lập nhằm đả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ừ chức năng, lớp hoặc giao diện cho đến dịch vụ hoặc thành phần hoàn chỉnh. Đặc điểm chính của những ứng dụng này là tốc độ thực thi, tính tách biệt và khả năng bảo trì thoải mái. 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ị.
Kiểm thử tích hợp
Hoạt động kiểm thử tích hợp tập trung vào 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à khả năng phối hợp của các công cụ này. Ví dụ điển hình về kiểm thử tích hợp là API hoặc kiểm thử thành phần.
Thử nghiệm toàn diện
Những 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 chức năng của chúng thậm chí còn tốt hơn. Các bài 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, đồng thời kiểm thử ứng dụng từ đầu đến cuối.
Các thử nghiệm này giống như một thử nghiệm hệ thống nếu bạn dùng lý thuyết về đảm bảo chất lượng. Các bài kiểm thử này mô phỏng người dùng thật và các hoạt động tương tác của họ. Hoạt động kiểm thử toàn diện cần nhiều thời gian chạy hơn vì các hoạt động này liên quan đến toàn bộ hệ thống, còn thời gian chạy càng đòi hỏi nhiều công suất tính toán hơn. Do đó, nỗ lực bổ sung này khiến chi phí bảo trì tăng lên.
Kiểm thử giao diện người dùng trực quan
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 chương trình kiểm thử này là các chương trình kiểm thử toàn diện mở rộng nhằm cung cấp một phương thức để xác minh kết quả hiển thị của một ứng dụng. Một quy trình kiểm thử như vậy sẽ chụp ảnh màn hình sau khi bạn thực hiện thay đổi và một ảnh chụp màn hình khác có chứa “hiện trạng” (hoặc tệp vàng), sau đó cung cấp những kết quả đó cho nhân viên đánh giá để họ kiểm tra và kiểm tra. Nói cách khác, công cụ này giúp tìm "lỗi trực quan" xuất hiện trên 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 viết rõ ràng vào câu nhận định.
Phân tích tĩnh
Tôi xin giới thiệu thêm một thứ nữa ở đây, đó là: bản phân tích tĩnh. Theo ý nghĩa của sách giáo khoa, thử nghiệm này không phải là một loại hình kiểm thử. 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. Hãy tưởng tượng rằng tính năng này hoạt động như một chức năng kiểm tra lỗi chính tả: nó quét mã của bạn để tìm các khiếm khuyết và lỗi cú pháp nghiêm trọng hơn mà không cần chạy chương trình, nhờ đó có thể 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à một điểm hữu ích để tìm hiểu về phương pháp Phân tích tĩnh nếu bạn muốn tìm hiểu chi tiết hơn.
Thử nghiệm ở mọi hình dạng: Tất cả những tính năng này hoạt động cùng nhau như thế nào?
Trong khi tìm kiế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 giải pháp khả thi trong một số trường hợp tương tự. Riêng trong cộng đồng web và cộng đồng kiểm thử, nhà phát triển có xu hướng sử dụng những dữ liệu tương tự này để cho bạn biết số lượng chương trình kiểm thử mà bạn nên sử dụng.
Năm 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:
- Thử nghiệm hình chóp
- Thử nghiệm Kim cương
- Kem ốc quế (còn gọi là Thử pizza)
- Thử nghiệm tổ ong
- Cúp thử nghiệm
Đây thực sự là rất nhiều thông tin cần xử lý. Làm cách nào để bạn quyết định về một chiến lược thử nghiệm phù hợp dựa trên tất cả những thông tin trên? Đừng lo, chúng tôi sẽ hỗ trợ 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 cho dự án của bạn. Hãy tiếp tục theo dõi! 🔥