Khi câu hỏi này tạo ra một số tranh cãi, hãy để tôi bắt đầu câu trả lời này với lý lịch của tôi: Ngoài việc tiếp xúc với V & V trong công việc dự án hàng ngày, tôi đã làm việc vài năm trong bộ phận kỹ thuật phần mềm của trường cũ của tôi và là giảng viên cho công nghệ phần mềm. Mặc dù điều này không đảm bảo rằng bất cứ điều gì tôi nói là chính xác, tôi hy vọng nó ít nhất mang lại cho tôi lợi ích của sự nghi ngờ rằng có thể có một số sự thật trong câu trả lời này.
Hãy để tôi đảm bảo với bạn, rằng bạn không bối rối như bạn có thể tin bạn. Những gì bạn đã nêu trong câu hỏi của bạn cũng đúng như nó là sai lệch. Hãy để tôi chỉ ra đầu tiên, những gì bạn đã nêu chính xác:
- Xác minh = xây dựng quyền sản phẩm so với xác thực = xây dựng đúng sản phẩm
- Các kỹ thuật tĩnh là một phần của xác minh - chủ yếu vì chúng lấy chương trình của bạn và một số đầu vào chính thức xuất phát từ các yêu cầu và đánh giá chúng với nhau.
- Xác minh đảm bảo thực hiện đúng các yêu cầu (nghĩa là bạn đã xây dựng nó đúng cách)
Bây giờ hãy để tôi dọn dẹp sự nhầm lẫn về thử nghiệm . Đầu tiên, như nhiều ý kiến đã nêu trước đây, kiểm tra mã động thông qua các kiểm tra tự động (đơn vị, tích hợp, ...) thực sự là một phần của xác minh. Tuy nhiên, điều gây ra sự nhầm lẫn lớn nhất là những người trong quá trình xác nhận cũng sẽ nói về thử nghiệm , nhưng có nghĩa là một điều khác biệt: trong xác nhận, thử nghiệm thường liên quan đến một người sử dụng ứng dụng cho mục đích dự định của mình. Trong trường hợp tối ưu, đây là khách hàng của anh ấy / cô ấy.
Tuy nhiên, "lỗi" [1] được tìm thấy bằng cách kiểm tra xác minh và xác thực khác nhau về cơ bản:
- lỗi kiểm tra xác minh: đây là những lỗi vi phạm yêu cầu của bạn theo cách này hay cách khác.
- lỗi kiểm tra xác nhận: đây là các lỗi với chính sản phẩm bạn đã xây dựng, không phải chức năng của nó, do đó, chúng tiết lộ các lỗi trong các yêu cầu.
Đối với hầu hết mọi người, nó giúp xem xét các ví dụ cụ thể về các trường hợp V & V khác nhau. Sau đây là những ví dụ cực đoan về lỗi:
Bạn có một yêu cầu cấp thấp rằng "f (x) phải trả về x + 1" và việc triển khai "f" của bạn luôn trả về hằng số 2. Bạn có thể tìm thấy lỗi này bằng một số cách tiếp cận xác minh khác nhau, nhưng khách hàng của bạn có thể đã thắng ' Không tìm thấy nó trong khi xác thực, bởi vì bạn đang xây dựng một trang web mua sắm điện tử và anh ta không biết và cũng không quan tâm đến "f".
Bạn có một yêu cầu nói rằng "Hệ thống sẽ có thể xử lý 1000 yêu cầu mỗi giây với mức tải CPU tối đa là 80%". Một lần nữa, xác nhận sẽ có một thời gian khó khăn, giống như hầu hết các kỹ thuật tĩnh. Trên thực tế, cách đơn giản nhất để xác minh điều này là kiểm tra động ứng dụng của bạn bằng cách đập nó với các yêu cầu và theo dõi tải CPU của bạn trong thời gian đó.
Hãy xem xét các yêu cầu trên đối với "f" một lần nữa, lần này với việc thực hiện "chính xác". Tất cả các đánh giá, phân tích tĩnh và kiểm tra động của bạn sẽ báo cáo thành công, nhưng sau đó khách hàng của bạn kiểm tra phần mềm của bạn và nói với bạn rằng anh ta bỏ lỡ biểu tượng giỏ hàng trên trang web. Không có số lượng xác minh sẽ có thể tìm thấy lỗi này, vì bạn đã thực hiện nó trong giai đoạn yêu cầu.
Như bạn có thể thấy, "thử nghiệm" - nếu không được xác định chính xác hơn - là một phần của cả xác minh và xác thực, và trên thực tế, "thử nghiệm" nên được thực hiện cho cả hai.
[1] "lỗi" được sử dụng thông tục ở đây, để tránh sự phân biệt giữa lỗi, thất bại, sai lầm, lỗi, ...