Tên được đặt cho các loại hình kiểm thử khác nhau thường có các chủ đề phổ biến trên các cơ sở mã, nhưng không có các định nghĩa đặc biệt nghiêm ngặt. Khoá học này đưa ra một số nguyên tắc về ý nghĩa của từng loại kiểm thử, nhưng một số tài nguyên khác có thể cung cấp định nghĩa khác.
Trong các trang trước, đã có ví dụ về cả kiểm thử đơn vị và kiểm thử thành phần (trong ví dụ của chúng tôi là đề cập đến thành phần React). Chúng ta có thể đặt cả hai cách này ở mức thấp trên kim tự tháp kiểm thử (hay hình dạng khác!), vì chúng có độ phức tạp thấp và nhanh chóng chạy, nhưng có thể không hữu ích bằng kiểm thử tích hợp phức tạp hơn.
Các loại hình kiểm thử phổ biến
Kiểm thử đơn vị
Kiểm thử đơn vị là kiểm thử nhỏ nhất trong phạm vi. Chúng thường được dùng để kiểm thử các phần nhỏ của mã (hoặc hoàn toàn là mã không có trạng thái) theo gần như một cách toán học: nếu tôi cung cấp mã của bạn với các đầu vào X, Y và Z, thì đầu ra của mã đó sẽ là A, B và C.
Mã có kiểm thử đơn vị thường sẽ không có các phần phụ thuộc bên ngoài, chẳng hạn như tìm nạp từ mạng hoặc ngầm sử dụng bất kỳ hàm hoặc thư viện nào khác. Đây là một nút cây của mã mà bạn có thể "cắt bỏ" và tự kiểm thử.
Mặc dù mã kiểm thử đơn vị thường nhanh chóng viết và chạy, nhưng có khả năng việc kiểm thử các đơn vị mã nhỏ sẽ không cung cấp thông tin hữu ích. Thông thường, một đơn vị mã thiếu tương tác với mã khác nghĩa là bạn nên kiểm thử ở cấp cao hơn để giảm rủi ro.
Kiểm thử thành phần
Đối với các nhà phát triển web, tên "thành phần" bị quá tải, thường có nghĩa là thành phần mà người dùng nhìn thấy, chẳng hạn như thành phần React hoặc thành phần Web. Định nghĩa chung hơn của lớp này là một phần công việc có thể kiểm thử, chẳng hạn như một lớp có các phần phụ thuộc bên ngoài. Để được kiểm thử hiệu quả, thành phần này phải được mô phỏng hoặc bỏ qua các phần phụ thuộc.
Vì các phương pháp phát triển web hiện đại dựa trên khái niệm về một thành phần, nên việc kiểm thử thành phần là một cách thiết thực để xem xét việc kiểm thử, chẳng hạn như bạn có thể quyết định rằng mỗi thành phần đều cần kiểm thử. Việc theo dõi kiểm thử thành phần cũng rất đơn giản trong bối cảnh một nhà phát triển hoặc nhóm nhỏ xác nhận rõ quyền sở hữu đối với một thành phần. Tuy nhiên, có thể khó mô phỏng được các phần phụ thuộc phức tạp.
Kiểm thử tích hợp
Việc này có xu hướng kiểm thử một nhóm nhỏ các thành phần, mô-đun, hệ thống con hoặc các phần có ý nghĩa khác trong mã của bạn cùng nhau để đảm bảo chúng hoạt động chính xác. Đây là một định nghĩa rất mơ hồ. Đối với nhà phát triển web, hãy tưởng tượng rằng mã bạn đang kiểm thử không phải là bản dựng chính thức của trang web (hoặc thậm chí là đóng), nhưng vẫn kết nối nhiều thành phần liên quan trong hệ thống của bạn.
Thậm chí có thể bao gồm các phần phụ thuộc "thực", chẳng hạn như cơ sở dữ liệu bên ngoài ở chế độ kiểm thử, thay vì mô phỏng thuần tuý. Ví dụ: thay vì nói rằng query() sẽ luôn trả về hai mục nhập giống nhau, quy trình kiểm thử tích hợp có thể xác nhận rằng cơ sở dữ liệu kiểm thử có nội dung nào đó trong đó. Bản thân dữ liệu ít quan trọng hơn, nhưng
bạn hiện đang kiểm thử để đảm bảo rằng một cơ sở dữ liệu có thể kết nối và truy vấn thành công.
Bạn có thể viết các chương trình kiểm thử tích hợp tương đối đơn giản với nhiều ngụ ý, có thể kiểm tra bằng cách sử dụng câu nhận định, vì một hành động duy nhất được kết nối với nhiều thành phần có thể gây ra một loạt các tác động có thể đo lường.
Do đó, các quy trình kiểm thử tích hợp có thể chứng minh một cách hiệu quả rằng hệ thống phức tạp của bạn sẽ chạy như dự kiến. Tuy nhiên, chúng có thể khó viết và duy trì, đồng thời có thể tạo ra sự phức tạp không cần thiết. Ví dụ: việc viết FakeUserService cho kiểm thử tích hợp sẽ thêm yêu cầu rằng cả kiểm thử tích hợp và RealUserService đều phải triển khai UserService.
Kiểm tra khói
Đây là các chương trình kiểm thử sẽ hoàn thành rất nhanh chóng và xác định xem cơ sở mã của bạn có đang ở trạng thái hợp lý hay không. Trong thực tế, điều này chủ yếu có nghĩa là thực hiện các kiểm thử đơn giản đối với mã có nhiều tác động đến trải nghiệm của bạn.
Ví dụ: trong một ứng dụng web lớn đã đăng nhập, điều này có thể đảm bảo rằng hệ thống đăng nhập và xác thực hoạt động được, vì nếu không có hệ thống này thì ứng dụng sẽ không dùng được và không cần kiểm thử thêm.
Kiểm thử khói có thể là một đề xuất phù hợp để chạy trong tập lệnh test của package.json trong một cơ sở mã lớn. Việc kiểm tra thủ công cũng có thể hoạt động như một loại kiểm tra khói.
Kiểm thử hồi quy
Kiểm thử hồi quy là một loại kiểm thử xác thực để đảm bảo rằng các tính năng hiện có sẽ tiếp tục hoạt động hoặc các lỗi cũ sẽ không xuất hiện lại sau một bản phát hành mới hoặc quá trình phát triển tính năng khác.
Phương pháp này gắn liền với khái niệm phát triển dựa trên kiểm thử (TDD). Các trường hợp kiểm thử được viết để kích hoạt lỗi một cách rõ ràng và sau đó được dùng để đảm bảo lỗi đã được khắc phục, được tính là trường hợp kiểm thử hồi quy, vì sự tồn tại của các trường hợp đó sẽ ngăn lỗi tương tự quay trở lại.
Tuy nhiên, kiểm thử hồi quy có thể là một vấn đề nếu không có một giải pháp hiệu quả. Đây là một thuật ngữ thường xuất hiện khi có nhu cầu kinh doanh: khi các tính năng đang được phát triển, điều quan trọng là những tính năng cũ không bị hỏng. Một cơ sở mã được kiểm thử tốt sẽ có thể duy trì được tình trạng này, nhưng không phải lúc nào cơ sở mã thực tế cũng hoạt động theo đúng yêu cầu đó. Nội dung này sẽ được đề cập nhiều hơn trong các phần sau.
Kiểm thử bằng hình ảnh
Kiểm thử hình ảnh bao gồm việc chụp ảnh màn hình hoặc quay video về trạng thái của một trang web để kiểm tra một trạng thái tốt đã biết (chẳng hạn như ảnh chụp màn hình trước đó) so với lần chạy kiểm thử hiện tại. Về bản chất, yêu cầu phải chạy một trình duyệt thực để có thể hiển thị HTML, CSS và các phần khác của trang web.
Thay vì kiểm thử trực quan các chương trình kiểm thử toàn diện chạy toàn bộ cơ sở mã, bạn nên tạo các "lớp khai thác" HTML chỉ hiển thị một số thành phần nhất định, đặc biệt là ở nhiều kích thước màn hình để kích hoạt giao diện người dùng thích ứng. Việc này phức tạp hơn so với việc chỉ sử dụng JSDOM hoặc các khung tương tự.
Việc kiểm thử hình ảnh thất bại có thể là một tín hiệu tốt của các loại lỗi khác. Tuy nhiên, các giao diện người dùng phức tạp có thể không kiểm thử được hình ảnh vì những lý do không liên quan đến tính năng mà bạn đang cố gắng kiểm thử, chẳng hạn như các tính năng mới khác thay đổi giao diện của giao diện người dùng, hoặc thậm chí phiên bản hệ điều hành mới hiển thị biểu tượng cảm xúc khác với các phiên bản trước.
Kiểm thử toàn diện
Các thử nghiệm toàn diện thường nằm ở trên cùng của kim tự tháp thử nghiệm. Chúng mô tả tương tác toàn diện với ứng dụng web hoặc trang web của bạn, có thể tập trung vào một tính năng cụ thể. Chúng thường chạy bên trong một trình duyệt do một tác nhân như WebdriverIO, Selenium hoặc Puppeteer kiểm soát. Các tác nhân này có thể chạy cơ sở mã của bạn nhiều hơn hoặc ít hơn vì sẽ được triển khai trong phiên bản chính thức (mặc dù chúng thường được phân phát trên máy chủ cục bộ).
Tuỳ thuộc vào trang web của bạn, quá trình này có thể liên quan đến việc đăng nhập với tư cách người dùng thử nghiệm, thực hiện các thao tác chính và xác nhận rằng trang web hoặc hệ thống của bạn đang ở trạng thái chính xác. Chúng tôi sẽ trình bày thêm các ví dụ về loại hình kiểm thử này trong các phần tiếp theo, vì các ví dụ này có thể rất mạnh mẽ nhưng đôi khi khó duy trì.
Một số chiến thuật để đơn giản hoá có thể là giảm phạm vi hoặc mô phỏng các thành phần cụ thể (nếu phù hợp). Ví dụ: nếu người dùng cần đăng nhập vào trang web của bạn, nhưng đăng nhập không phải là tính năng bạn đang kiểm thử, thì bạn nên đặt cờ cho môi trường kiểm thử cho phép bộ kiểm soát kiểm thử hoạt động như người dùng mà không cần đăng nhập hoặc tạo cookie liên kết.
Mặc dù kiểm thử toàn diện có thể là cách rất hiệu quả để kiểm thử cùng một lúc trên nhiều phần lớn cơ sở mã, nhưng các hoạt động kiểm thử trên quy mô lớn như vậy có nguy cơ không ổn định hoặc không đáng tin cậy do phụ thuộc vào hệ thống bên ngoài. Thường thì các trình kiểm thử này cũng có thể để lại nhiều dữ liệu kiểm thử trong cơ sở dữ liệu của bạn nếu chẳng hạn như mỗi hoạt động kiểm thử tạo hoặc sửa đổi một mục nhập. Việc tích luỹ dữ liệu còn lại như thế này có thể khiến bạn khó xác định cách kiểm thử không thành công.
Kiểm thử API
Kiểm thử API có thể đề cập đến việc xác nhận hành vi của các API mà phần mềm của bạn cung cấp hoặc truy cập vào các API trong thực tế (có thể đang hoạt động) để xác nhận hành vi của các API đó. Dù bằng cách nào, việc này thường có xu hướng kiểm thử sự trừu tượng giữa các hệ thống (cách cuối cùng chúng sẽ giao tiếp với nhau) mà không thực sự tích hợp chúng với nhau như trong quá trình kiểm thử tích hợp.
Các hoạt động kiểm thử này có thể là tiền đề cơ bản cho việc kiểm thử tích hợp mà không cần phải chạy các hệ thống mà bạn đang kiểm thử mối liên kết. Tuy nhiên, việc kiểm thử các hệ thống trong thế giới thực có thể không ổn định.
Các loại khác
Có nhiều phương pháp kiểm thử khác có thể hữu ích, tuỳ thuộc vào nguồn của bạn. Sau đây là một số ví dụ thú vị:
- Kiểm thử theo cách thủ công.
- Thử nghiệm chấp nhận (một hình thức kiểm thử thủ công mà Agile phổ biến) xác nhận rằng sản phẩm "đáp ứng nhu cầu của người dùng".
- Kiểm thử hỗn loạn là việc nhập dữ liệu ngẫu nhiên để xem điều gì sẽ xảy ra nhằm đảm bảo một trang web sẽ không gặp sự cố nếu nhập dữ liệu không hợp lệ.
- Việc kiểm thử lỗi cố ý mô phỏng các lỗi trong các hệ thống phức tạp, chẳng hạn như lỗi mạng, để đảm bảo mã đang được kiểm thử phản hồi theo cách có kiểm soát.
- Kiểm thử bản dựng xác nhận rằng các cấu phần phần mềm bản dựng của cơ sở mã có thể được tạo bằng cách kiểm tra xem các cấu phần phần mềm đó có tồn tại hoặc nội dung của chúng là gì hay không. Loại kiểm thử này có thể hữu ích khi kiểm tra kết quả của một CMS phức tạp.
Mức độ sử dụng mã
Bạn có thể đo lường tỷ lệ phần trăm mã được kiểm thử bằng quy trình kiểm thử tự động và báo cáo tỷ lệ phần trăm này dưới dạng số liệu thống kê theo thời gian. Bạn không nên nhắm đến mức độ sử dụng mã 100% vì điều đó có thể dẫn đến chi phí không cần thiết cũng như các hoạt động kiểm thử đơn giản hoặc được thiết kế kém, không bao gồm các trường hợp sử dụng chính một cách chuyên sâu.
Bản thân mức độ sử dụng cũng có thể là một công cụ hữu ích khi viết hoặc thao tác trên các chương trình kiểm thử, đặc biệt là các chương trình kiểm thử tích hợp. Bằng cách hiển thị tỷ lệ phần trăm hoặc bản phân tích từng dòng về mã được kiểm thử bằng một quy trình kiểm thử duy nhất, bạn có thể hiểu rõ hơn về những đoạn mã bị thiếu hoặc nội dung nào có thể được kiểm thử tiếp theo.
Tài nguyên
Kiểm tra kiến thức
Đâu là loại kiểm thử đã biết?