Xác minh và thẩm định phần mềm là gì

Trang web này phụ thuộc vào doanh thu từ số lần hiển thị quảng cáo để tồn tại. Vui lòng tắt trình chặn quảng cáo của bạn hoặc tạm dừng tính năng chặn quảng cáo cho trang web này.

Xác minh và Xác nhận là các thuật ngữ thường được sử dụng trong ngữ cảnh của phần mềm. Việc xác minh và xác nhận có thể được phân biệt bởi thực tế là xác minh phần mềm là một quá trình kiểm tra các đầu ra thiết kế và so sánh nó với các yêu cầu phần mềm được chỉ định. Ngược lại, xác nhận phần mềm là quá trình kiểm tra các thông số kỹ thuật phần mềm theo nhu cầu của người dùng. Theo một cách rộng rãi, các hoạt động này hoàn thiện lẫn nhau và là một phần của sự phát triển Phần mềm.

1. Xác minh trong kiểm thử phần mềm là gì?

Xác minh trong ngữ cảnh của công nghệ phần mềm là một nhóm các phương pháp xác nhận việc thực hiện chính xác các chức năng cụ thể trong phần mềm. Nó được sử dụng để kiểm tra xem sản phẩm có được xây dựng chính xác hay không. Trong giai đoạn này của quy trình phát triển phần mềm, các lỗi và lỗi được loại bỏ để đảm bảo độ tin cậy.

Quá trình xác minh cung cấp các thông tin sau:

• Nó cung cấp một cách tiên lượng để phân tích thiết kế tổng hợp để đảm bảo chức năng của chức năng I/O [input/output] sau khi phát triển.
• Độ chính xác và chất lượng của thiết kế cũng được xác minh.
• Nó kiểm tra sản phẩm cuối cùng so với thiết kế, nói một cách đơn giản, sản phẩm có phù hợp với thông số kỹ thuật của sản phẩm không.

Việc xác minh có thể được thực hiện bằng nhiều cách khác nhau như phương pháp mô phỏng, mô phỏng phần cứng và chính thức. Thực tế kiểm thử đơn vị và hệ thống được sử dụng để xác minh mã của phần mềm. Kiểm thử đơn vị xác minh xem hành vi mã có tuân theo đặc tả đơn vị hay không. Khi nói đến kiểm tra hệ thống, các mô-đun được kết nối với nhau theo nghĩa là kiểm tra hệ thống hoàn chỉnh. Kết quả kiểm tra hệ thống bao gồm việc xác minh xem hệ thống có thỏa mãn đặc điểm kỹ thuật của nó hay không.

2. Xác nhận trong kiểm thử phần mềm là gì?
Xác nhận trong kỹ thuật phần mềm là một cơ chế động để kiểm tra và xác nhận xem sản phẩm phần mềm có thực sự đáp ứng được nhu cầu chính xác của khách hàng hay không. Quá trình này giúp đảm bảo rằng phần mềm đáp ứng được việc sử dụng mong muốn trong một môi trường thích hợp. Quá trình xác nhận bao gồm các hoạt động như kiểm thử đơn vị, kiểm thử tích hợp, kiểm tra hệ thống và kiểm thử chấp nhận người dùng.

3. Biểu đồ so sánh

Xác minh [Verification]

Xác nhận [Validation]

4. Sự khác nhau chính giữa Xác minh và Xác nhận

• Quá trình xác minh bao gồm kiểm tra tài liệu, thiết kế, mã và chương trình trong khi quá trình xác nhận bao gồm kiểm tra và xác nhận sản phẩm thực tế.
• Xác minh không liên quan đến executing code trong khi Xác thực liên quan đến executing code.
• Xác minh sử dụng các phương pháp như đánh giá, hướng dẫn, kiểm tra và kiểm tra tại bàn trong khi Xác thực sử dụng các phương pháp như Black Box Testing, White Box Testing và non-functional testing.
• Xác minh kiểm tra xem phần mềm có xác nhận một thông số kỹ thuật hay không trong khi Xác nhận kiểm tra xem phần mềm có đáp ứng các yêu cầu và mong đợi hay không.
• Xác minh tìm thấy các lỗi sớm trong chu kỳ phát triển trong khi Xác nhận tìm thấy các lỗi mà xác minh không thể bắt được.
• So sánh xác nhận và xác minh trong kiểm thử phần mềm. Các mục tiêu của quá trình xác minh trên kiến trúc phần mềm, thiết kế, cơ sở dữ liệu, v.v. trong khi quá trình Xác nhận nhắm mục tiêu đến sản phẩm phần mềm thực tế.
• Việc xác minh được thực hiện bởi nhóm QA trong khi Xác thực được thực hiện bởi sự tham gia của nhóm thử nghiệm với nhóm QA.
• So sánh Xác minh và kiểm tra Xác nhận quy trình xác minh đến trước khi xác nhận trong khi quy trình xác nhận diễn ra sau khi xác minh.

5. Kết luận
Xác minh được mô tả như một tập hợp các hoạt động đảm bảo thực hiện chính xác chức năng cụ thể trong phần mềm. Mặt khác, Xác nhận là một nhóm các hoạt động xác nhận rằng phần mềm được phát triển tuân thủ các yêu cầu của khách hàng.

Lấy từ “//vi.wikipedia.org/w/index.php?title=Xác_minh_phần_mềm&oldid=64366982”

1Ngày 28/06/1962, tàu Mariner I bay đến sao Kim nhưng đã bị phá hủy 293 giây sau khi phóng do bay chệch hướng so với dự kiến ban đầu. Những cuộc điều tra sau đó đã xác định nguyên nhân là phần mềm tính toán đường đi của tên lửa bị lỗi. Nguyên nhân sâu xa: việc xác minh/thẩm định phần mềm tính toán đường đi của tên lửa chưa được chú trọng đúng mức2XÁC MINH/THẨM ĐỊNH PHẦN MỀM1. Giới thiệu chung2. Kiểm thử phần mềm3. Các kỹ thuật kiểm thửKiểm thử hộp đen31. GIỚI THIỆUXác minh/thẩm định:Xác minh [verification]: •kiểm tra xem sản phẩm có đúng đặc tả không  chú trọng phát hiện lỗi lập trìnhThẩm định [validation]:•kiểm tra xem sản phẩm có đáp ứng nhu cầu người dùng không•hoạt động hiệu quả không chú trọng phát hiện lỗi phân tích, lỗi thiết kế41. GIỚI THIỆUXác minh/thẩm định là sự kiểm tra công việc phát triển phần mềmcông việc xuyên suốt quá trình phát triển Mục đích: •phát hiện và sửa lỗi phần mềm•đánh giá tính dùng được của phần mềm đảm bảo chất lượng phần mềm51. GIỚI THIỆUXác minh /thẩm định tĩnh: kiểm tra không thực hiện chương trình•xét duyệt yêu cầu, thiết kế, mã nguồntiến hành ở mọi công đoạn phát triểncó thể phát hiện được hầu hết các lỗi lập trình [lý thuyết]không đánh giá tính hiệu quả của sản phẩm Xác minh/thẩm định động: kiểm tra thông qua thực hiện chương trình tiến hành sau khi có mã nguồn kỹ thuật kiểm tra phần mềm chính hiện nayKết hợp cả 2 kỹ thuật62. KIỂM THỬ PHẦN MỀMKiểm thử là gì ?“Kiểm thử là tiến trình thực thi chương trình với mục đích tìm thấy lỗi” [Myer]Phân biệt kiểm thử với gỡ rối [debug] ?72. KIỂM THỬ PHẦN MỀMTheo nghiên cứu của Boris Beizer và Van Nostrand Reinhold:không có lập trình viên nào có thể lập trình không có lỗitrung bình một lập trình viên loại tốt có từ 1 đến 3 lỗi/ 100 dòng lệnhtìm ra các lỗi chiếm 50% công việc phải làm để có được một phần mềm hoạt động được82. KIỂM THỬ PHẦN MỀMTest case: dữ liệu kiểm traMỗi testcase thường bao gồm: dữ liệu đầu vào [input]điều kiệndữ liệu đầu ra kỳ vọng [expected output] {input; điều kiện; expected output}Thông dụng: xây dựng theo điều kiện92. KIỂM THỬ PHẦN MỀMVí dụ: hàm tính trị tuyệt đối của số nguyênTest case 1: {Input: a=5; Expected output: 5}Test case 2: {Input: -5; Expected output: 5}102. KIỂM THỬ PHẦN MỀMThí dụ: chúng ta cần kiểm thử một thành phần phần mềm “quản lý nguồn nhân lực” với đặc tả chức năng như sau: mỗi lần nhận một hồ sơ xin việc, thành phần phần mềm sẽ ra quyết định dựa vào tuổi ứng viên theo bảng sau:a112. KIỂM THỬ PHẦN MỀM1. Test case 1: {Input : 2 tuổi, Output : không thuê}2. Test case 2: {Input : 17 tuổi, Output : thuê bán thời gian}3. Test case 3: {Input : 35 tuổi, Output : thuê toàn thời gian}4. Test case 4: {Input : 90 tuổi, Output : không thuê}Ngày 25/06/2012122. KIỂM THỬ PHẦN MỀMCác bước kiểm thử:Thiết kế các test case Tạo dữ liệu kiểm thửThực thi chương trình trên dữ liệu thửQuan sát kết quả kiểm thử •kết quả nhận được khác với kết quả mong đợi  kiểm thử thành công132.1 KIỂM THỬ HỘP ĐENKiểm thử hộp đen [kiểm thử chức năng]:dựa trên đặc tả chức năngphát hiện các sai sót về chức năngkhông quan tâm đến cách cài đặt142.1 KIỂM THỬ HỘP ĐENCác test case kiểm thử của Kiểm thử hộp đen bao gồm:các trường hợp bình thường và không bình thường [dữ liệu không hợp lệ ] của module chiến lược chung: phân hoạch [dữ liệu] tương đương•chia miền dữ liệu vào ra thành các vùng, •mỗi vùng chứa các dữ liệu có cùng hành vi •mỗi vùng dữ liệu chỉ cần xây dựng 1 test casemỗi vùng biên có thể sử dụng 1 test case hoặc 3 test case [1 cho giá trị biên, 1 ngay dưới biên và 1 trên biên]152.1 KIỂM THỬ HỘP ĐENTest case ở biên:162.1 KIỂM THỬ HỘP ĐENTest case ở biên:{-1,0,1}, {14,15,16}, {15,16,17}, {16,17,18}, {17,18,19}, {53,54,55}, {54,55,56}, {98,99,100}172.1 KIỂM THỬ HỘP ĐENVà đoạn code hiện thực sau :if [applicantAge < 15] kq ="NO";if [16 < applicantAge && applicantAge