Tùy thuộc vào nơi bạn nhìn, bạn sẽ nhận được câu trả lời hơi khác nhau. Tôi đã đọc về chủ đề này rất nhiều, và đây là sự chắt lọc của tôi; một lần nữa, đây là một chút len lỏi và những người khác có thể không đồng ý.
Bài kiểm tra đơn vị
Kiểm tra đơn vị chức năng nhỏ nhất, thường là một phương thức / hàm (ví dụ: được cung cấp một lớp với một trạng thái cụ thể, gọi phương thức x trên lớp sẽ khiến y xảy ra). Các bài kiểm tra đơn vị nên được tập trung vào một tính năng cụ thể (ví dụ: gọi phương thức pop khi ngăn xếp trống sẽ ném một InvalidOperationException). Tất cả mọi thứ nó chạm vào nên được thực hiện trong bộ nhớ; điều này có nghĩa là mã kiểm tra và mã được kiểm tra không nên:
- Gọi ra cộng tác viên (không tầm thường)
- Truy cập mạng
- Lượt cơ sở dữ liệu
- Sử dụng hệ thống tập tin
- Xoay lên một chủ đề
- Vân vân.
Bất kỳ loại phụ thuộc nào chậm / khó hiểu / khởi tạo / thao tác nên được đặt ra / chế giễu / bất cứ điều gì bằng cách sử dụng các kỹ thuật thích hợp để bạn có thể tập trung vào những gì đơn vị mã đang làm, chứ không phải những gì phụ thuộc của nó làm.
Nói tóm lại, các bài kiểm tra đơn vị càng đơn giản càng tốt, dễ gỡ lỗi, đáng tin cậy (do các yếu tố bên ngoài giảm), nhanh chóng thực hiện và giúp chứng minh rằng các khối xây dựng nhỏ nhất của chức năng chương trình của bạn như dự định trước khi chúng được đặt cùng nhau. Thông báo trước là, mặc dù bạn có thể chứng minh rằng chúng hoạt động hoàn hảo trong sự cô lập, các đơn vị mã có thể nổ tung khi kết hợp với chúng ta ...
Kiểm tra tích hợp
Kiểm thử tích hợp xây dựng trên các kiểm thử đơn vị bằng cách kết hợp các đơn vị mã và kiểm tra kết quả hoạt động chính xác. Đây có thể là bộ phận bên trong của một hệ thống hoặc kết hợp nhiều hệ thống lại với nhau để làm một cái gì đó hữu ích. Ngoài ra, một điều khác biệt giữa kiểm tra tích hợp với kiểm tra đơn vị là môi trường. Kiểm thử tích hợp có thể và sẽ sử dụng các luồng, truy cập cơ sở dữ liệu hoặc làm bất cứ điều gì được yêu cầu để đảm bảo rằng tất cả các mã và các thay đổi môi trường khác nhau sẽ hoạt động chính xác.
Nếu bạn đã xây dựng một số mã tuần tự và đơn vị đã kiểm tra bộ phận bên trong của nó mà không chạm vào đĩa, làm sao bạn biết rằng nó sẽ hoạt động khi bạn đang tải và lưu vào đĩa? Có lẽ bạn đã quên tuôn ra và loại bỏ filestreams. Có thể quyền truy cập tệp của bạn không chính xác và bạn đã kiểm tra các bộ phận sử dụng trong các luồng bộ nhớ. Cách duy nhất để tìm hiểu chắc chắn là kiểm tra nó 'thực tế' bằng cách sử dụng một môi trường gần nhất với sản xuất.
Ưu điểm chính là họ sẽ tìm thấy các lỗi mà đơn vị kiểm tra không thể như lỗi nối dây (ví dụ: trường hợp của lớp A bất ngờ nhận được một phiên bản B của null) và lỗi môi trường (nó chạy tốt trên máy CPU đơn của tôi, nhưng tôi Máy 4 lõi của đồng nghiệp không thể vượt qua các bài kiểm tra). Nhược điểm chính là các thử nghiệm tích hợp chạm vào nhiều mã hơn, kém tin cậy hơn, các lỗi khó chẩn đoán hơn và các thử nghiệm khó bảo trì hơn.
Ngoài ra, kiểm tra tích hợp không nhất thiết phải chứng minh rằng một tính năng hoàn chỉnh hoạt động. Người dùng có thể không quan tâm đến các chi tiết nội bộ của các chương trình của tôi, nhưng tôi thì có!
Kiểm tra chức năng
Kiểm tra chức năng kiểm tra tính năng cụ thể về tính chính xác bằng cách so sánh kết quả cho đầu vào đã cho so với thông số kỹ thuật. Các xét nghiệm chức năng không quan tâm đến kết quả trung gian hoặc tác dụng phụ, chỉ là kết quả (họ không quan tâm rằng sau khi thực hiện x, đối tượng y có trạng thái z). Chúng được viết để kiểm tra một phần của đặc tả kỹ thuật, như "hàm gọi Square (x) với đối số 2 trả về 4".
Xét nghiệm nghiệm thu
Kiểm tra chấp nhận dường như được chia thành hai loại:
Kiểm tra chấp nhận tiêu chuẩn bao gồm thực hiện các kiểm tra trên toàn hệ thống (ví dụ: sử dụng trang web của bạn thông qua trình duyệt web) để xem liệu chức năng của ứng dụng có thỏa mãn thông số kỹ thuật hay không. Ví dụ: "nhấp vào biểu tượng thu phóng sẽ phóng to chế độ xem tài liệu lên 25%." Không có kết quả thực sự liên tục, chỉ là kết quả vượt qua hoặc thất bại.
Ưu điểm là các bài kiểm tra được mô tả bằng tiếng Anh đơn giản và đảm bảo phần mềm, nói chung, là tính năng hoàn chỉnh. Nhược điểm là bạn đã chuyển một cấp độ khác lên kim tự tháp thử nghiệm. Các bài kiểm tra chấp nhận chạm vào hàng núi mã, vì vậy việc theo dõi một thất bại có thể khó khăn.
Ngoài ra, trong phát triển phần mềm nhanh, kiểm tra chấp nhận của người dùng bao gồm tạo các kiểm tra để phản ánh các câu chuyện của người dùng được tạo bởi / cho khách hàng của phần mềm trong quá trình phát triển. Nếu các bài kiểm tra vượt qua, điều đó có nghĩa là phần mềm sẽ đáp ứng yêu cầu của khách hàng và câu chuyện có thể được coi là hoàn thành. Một bộ kiểm tra chấp nhận về cơ bản là một đặc tả thực thi được viết bằng ngôn ngữ cụ thể của miền mô tả các kiểm tra bằng ngôn ngữ được sử dụng bởi người dùng hệ thống.
Phần kết luận
Chúng đều bổ sung cho nhau. Đôi khi, việc tập trung vào một loại hoặc tránh hoàn toàn chúng là một lợi thế. Sự khác biệt chính đối với tôi là một số thử nghiệm nhìn mọi thứ từ quan điểm của lập trình viên, trong khi những thử nghiệm khác sử dụng trọng tâm khách hàng / người dùng cuối.