Sự khác biệt giữa kiểm tra chấp nhận và kiểm tra chức năng?

Sự khác biệt thực sự giữa kiểm tra chấp nhận và kiểm tra chức năng là gì?

Những điểm nổi bật hoặc mục tiêu của mỗi là gì? Ở mọi nơi tôi đọc chúng đều giống nhau một cách mơ hồ.

Trong thế giới của tôi, chúng tôi sử dụng các thuật ngữ như sau:

kiểm tra chức năng : Đây là một hoạt động xác minh ; chúng tôi đã xây dựng một sản phẩm làm việc chính xác? Phần mềm có đáp ứng yêu cầu kinh doanh không?

Đối với loại thử nghiệm này, chúng tôi có các trường hợp thử nghiệm bao gồm tất cả các tình huống có thể xảy ra mà chúng tôi có thể nghĩ đến, ngay cả khi kịch bản đó không có khả năng tồn tại "trong thế giới thực". Khi thực hiện loại thử nghiệm này, chúng tôi nhắm đến phạm vi bảo hiểm mã tối đa. Chúng tôi sử dụng bất kỳ môi trường thử nghiệm nào chúng tôi có thể lấy vào thời điểm đó, nó không phải là "sản xuất" tầm cỡ, miễn là nó có thể sử dụng được.

kiểm tra chấp nhận : Đây là một hoạt động xác nhận ; chúng ta đã xây dựng điều đúng đắn chưa? Đây có phải là những gì khách hàng thực sự cần?

Điều này thường được thực hiện trong sự hợp tác với khách hàng hoặc bởi một proxy khách hàng nội bộ (chủ sở hữu sản phẩm). Đối với loại thử nghiệm này, chúng tôi sử dụng các trường hợp thử nghiệm bao gồm các tình huống điển hình mà theo đó chúng tôi hy vọng phần mềm sẽ được sử dụng. Thử nghiệm này phải được tiến hành trong môi trường "giống như sản xuất", trên phần cứng giống hoặc gần với những gì khách hàng sẽ sử dụng. Đây là khi chúng tôi kiểm tra "bất hợp pháp" của chúng tôi:

• Độ tin cậy, sẵn có : Được xác nhận thông qua một bài kiểm tra căng thẳng.

• Khả năng mở rộng : Xác thực thông qua một bài kiểm tra tải.

• Tính khả dụng : Được xác nhận thông qua kiểm tra và trình diễn cho khách hàng. UI có được cấu hình theo ý thích của họ không? Chúng tôi đã đặt thương hiệu khách hàng ở tất cả các vị trí phù hợp? Chúng ta có tất cả các lĩnh vực / màn hình họ yêu cầu?

• Bảo mật (hay còn gọi là Bảo mật , chỉ để phù hợp) : Được xác thực qua trình diễn. Đôi khi một khách hàng sẽ thuê một công ty bên ngoài để thực hiện kiểm toán bảo mật và / hoặc kiểm tra xâm nhập.

• Khả năng bảo trì : Được xác thực thông qua trình diễn cách chúng tôi sẽ cung cấp các bản cập nhật / bản vá phần mềm.

• Khả năng cấu hình : Được xác thực thông qua trình diễn về cách khách hàng có thể sửa đổi hệ thống cho phù hợp với nhu cầu của họ.

Đây không phải là tiêu chuẩn, và tôi không nghĩ có một định nghĩa "tiêu chuẩn", như các câu trả lời mâu thuẫn ở đây chứng minh. Điều quan trọng nhất đối với tổ chức của bạn là bạn xác định chính xác các thuật ngữ này và tuân theo chúng.

Tôi thích câu trả lời của Patrick Cuff. Điều tôi muốn thêm là sự khác biệt giữa cấp độ kiểm tra và loại kiểm tra dành cho tôi một dụng cụ mở mắt.

mức kiểm tra

Mức độ thử nghiệm rất dễ giải thích bằng mô hình V , một ví dụ: Mỗi cấp độ thử nghiệm có mức độ phát triển tương ứng . Nó có một đặc điểm thời gian điển hình, chúng được thực hiện ở giai đoạn nhất định trong vòng đời phát triển.

1. kiểm tra thành phần / đơn vị => xác minh thiết kế chi tiết
2. thử nghiệm tích hợp thành phần / đơn vị => xác minh thiết kế toàn cầu
3. kiểm tra hệ thống => xác minh yêu cầu hệ thống
4. kiểm thử tích hợp hệ thống => xác minh yêu cầu hệ thống
5. kiểm tra chấp nhận => xác nhận yêu cầu người dùng

loại kiểm tra

Một loại thử nghiệm là một đặc điểm, nó tập trung vào một mục tiêu thử nghiệm cụ thể. Các loại thử nghiệm nhấn mạnh các khía cạnh chất lượng của bạn, còn được gọi là các khía cạnh kỹ thuật hoặc phi chức năng. Các loại thử nghiệm có thể được thực hiện ở bất kỳ cấp độ thử nghiệm . Tôi thích sử dụng làm loại thử nghiệm các đặc tính chất lượng được đề cập trong ISO / IEC 25010: 2011.

1. thử nghiệm chức năng
2. kiểm tra độ tin cậy
3. kiểm tra năng suất
4. kiểm tra khả năng hoạt động
5. kiểm tra bảo mật
6. kiểm tra tương thích
7. kiểm tra khả năng bảo trì
8. kiểm tra khả năng chuyển nhượng

Để làm cho nó hoàn thành. Ngoài ra còn có một thứ gọi là kiểm tra hồi quy . Đây là một phân loại bổ sung bên cạnh mức độ thử nghiệm và loại thử nghiệm . Một thử nghiệm hồi quy là một thử nghiệm mà bạn muốn lặp lại vì nó chạm vào một cái gì đó quan trọng trong việc sản phẩm của bạn. Thực tế, đây là một tập hợp các bài kiểm tra mà bạn đã xác định cho từng cấp độ kiểm tra . Nếu có một lỗi nhỏ trong sản phẩm của bạn, người ta không luôn có thời gian để lặp lại tất cả các thử nghiệm. Kiểm tra hồi quy là một câu trả lời cho điều đó.

Sự khác biệt là giữa kiểm tra vấn đề và giải pháp. Phần mềm là một giải pháp cho một vấn đề, cả hai đều có thể được kiểm tra.

Kiểm tra chức năng xác nhận phần mềm thực hiện một chức năng trong ranh giới về cách bạn đã giải quyết vấn đề. Đây là một phần không thể thiếu trong việc phát triển phần mềm, có thể so sánh với thử nghiệm được thực hiện trên sản phẩm được sản xuất hàng loạt trước khi rời khỏi nhà máy. Một thử nghiệm chức năng xác minh rằng sản phẩm thực sự hoạt động như bạn (nhà phát triển) nghĩ rằng nó làm.

Kiểm tra chấp nhận xác minh sản phẩm thực sự giải quyết vấn đề được thực hiện để giải quyết. Điều này có thể được thực hiện tốt nhất bởi người dùng (khách hàng), ví dụ như thực hiện các nhiệm vụ của mình mà phần mềm hỗ trợ. Nếu phần mềm vượt qua thử nghiệm trong thế giới thực này, nó sẽ được chấp nhận để thay thế giải pháp trước đó. Thử nghiệm chấp nhận này đôi khi chỉ có thể được thực hiện đúng trong sản xuất, đặc biệt nếu bạn có khách hàng ẩn danh (ví dụ: một trang web). Do đó, một tính năng mới sẽ chỉ được chấp nhận sau vài ngày hoặc vài tuần sử dụng.

Kiểm tra chức năng - kiểm tra sản phẩm, xác minh rằng sản phẩm đó có những phẩm chất bạn đã thiết kế hoặc xây dựng (chức năng, tốc độ, lỗi, tính nhất quán, v.v.)

Thử nghiệm chấp nhận - thử nghiệm sản phẩm trong ngữ cảnh của nó, điều này đòi hỏi (mô phỏng) tương tác của con người, thử nghiệm nó có hiệu quả mong muốn đối với (các) vấn đề ban đầu.

Câu trả lời là ý kiến. Tôi đã làm việc trong rất nhiều dự án và là người kiểm tra và phát hành và tất cả các vai trò khác nhau và các mô tả trong các cuốn sách khác nhau, vì vậy đây là biến thể của tôi:

kiểm tra chức năng: thực hiện các yêu cầu nghiệp vụ và kiểm tra tất cả các yêu cầu tốt và mạnh mẽ từ quan điểm chức năng.

thử nghiệm chấp nhận: khách hàng "trả tiền" thực hiện thử nghiệm mà anh ta thích làm để anh ta có thể chấp nhận sản phẩm được giao. Nó phụ thuộc vào khách hàng nhưng thường thì các thử nghiệm không kỹ lưỡng như thử nghiệm chức năng đặc biệt nếu đó là một dự án nội bộ vì các bên liên quan xem xét và tin tưởng vào kết quả thử nghiệm được thực hiện trong các giai đoạn thử nghiệm trước đó.

Như tôi đã nói đây là quan điểm và kinh nghiệm của tôi. Kiểm thử chức năng là có hệ thống và kiểm thử chấp nhận thay vì bộ phận kinh doanh kiểm tra điều đó.

1. Khán giả. Kiểm tra chức năng là để đảm bảo các thành viên của nhóm sản xuất phần mềm rằng nó làm những gì họ mong đợi. Kiểm tra chấp nhận là để đảm bảo người tiêu dùng đáp ứng nhu cầu của họ.

2. Phạm vi. Kiểm tra chức năng chỉ kiểm tra chức năng của một thành phần tại một thời điểm. Kiểm tra chấp nhận bao gồm bất kỳ khía cạnh nào của sản phẩm quan trọng đối với người tiêu dùng đủ để kiểm tra trước khi chấp nhận phần mềm (nghĩa là, bất cứ điều gì đáng giá thời gian hoặc tiền bạc sẽ mất để kiểm tra để xác định khả năng chấp nhận của nó).

Phần mềm có thể vượt qua kiểm tra chức năng, kiểm tra tích hợp và kiểm tra hệ thống; chỉ để không kiểm tra chấp nhận khi khách hàng phát hiện ra rằng các tính năng không đáp ứng nhu cầu của họ. Điều này thường sẽ ngụ ý rằng ai đó đã làm hỏng thông số kỹ thuật. Phần mềm cũng có thể thất bại một số kiểm tra chức năng, nhưng vượt qua kiểm tra chấp nhận vì khách hàng sẵn sàng xử lý một số lỗi chức năng miễn là phần mềm thực hiện những điều cốt lõi mà họ cần chấp nhận tốt (phần mềm beta thường sẽ được chấp nhận bởi một tập hợp con của người dùng trước đó là hoàn toàn chức năng).

Kiểm thử chức năng: Áp dụng dữ liệu kiểm tra xuất phát từ các yêu cầu chức năng được chỉ định mà không liên quan đến cấu trúc chương trình cuối cùng. Còn được gọi là thử nghiệm hộp đen.

Thử nghiệm chấp nhận: Thử nghiệm chính thức được tiến hành để xác định xem một hệ thống có thỏa mãn các tiêu chí chấp nhận của nó hay không, cho phép người dùng cuối xác định có chấp nhận hệ thống hay không.

Theo quan điểm của tôi, sự khác biệt chính là ai nói nếu các bài kiểm tra thành công hay thất bại.

Một thử nghiệm chức năng kiểm tra mà hệ thống đáp ứng các yêu cầu được xác định trước. Nó được thực hiện và kiểm tra bởi những người chịu trách nhiệm phát triển hệ thống.

Một bài kiểm tra chấp nhận được ký bởi người dùng. Lý tưởng nhất là người dùng sẽ nói những gì họ muốn kiểm tra nhưng trong thực tế, đó có thể là một hoàng hôn của thử nghiệm chức năng vì người dùng không đầu tư đủ thời gian. Lưu ý rằng quan điểm này là từ người dùng doanh nghiệp mà tôi giao dịch với các nhóm người dùng khác, ví dụ như hàng không và các vấn đề an toàn quan trọng khác có thể không có sự khác biệt này,

Kiểm tra chấp nhận :

... là thử nghiệm hộp đen được thực hiện trên một hệ thống (ví dụ: phần mềm, rất nhiều bộ phận cơ khí được sản xuất hoặc lô sản phẩm hóa học) trước khi giao hàng.

Mặc dù điều này tiếp tục để nói:

Nó còn được gọi là thử nghiệm chức năng, thử nghiệm hộp đen, chấp nhận phát hành, thử nghiệm QA, thử nghiệm ứng dụng, thử nghiệm độ tin cậy, thử nghiệm cuối cùng, thử nghiệm xác nhận hoặc thử nghiệm chấp nhận tại nhà máy

với một dấu "cần dẫn nguồn".

Kiểm tra chức năng (thực sự chuyển hướng đến Kiểm tra hệ thống):

tiến hành trên một hệ thống hoàn chỉnh, tích hợp để đánh giá sự tuân thủ của hệ thống với các yêu cầu được chỉ định của hệ thống. Kiểm thử hệ thống nằm trong phạm vi kiểm thử hộp đen và do đó, không yêu cầu kiến ​​thức về thiết kế bên trong của mã hoặc logic.

Vì vậy, từ định nghĩa này, họ là khá nhiều điều tương tự.

Theo kinh nghiệm của tôi, kiểm tra chấp nhận thường là một tập hợp con của các kiểm tra chức năng và được khách hàng sử dụng trong quy trình đăng xuất chính thức trong khi các kiểm tra chức năng / hệ thống sẽ là các kiểm tra do bộ phận nhà phát triển / QA điều hành.

Mối quan hệ giữa hai: Kiểm tra chấp nhận thường bao gồm kiểm tra chức năng, nhưng nó có thể bao gồm các kiểm tra bổ sung. Ví dụ kiểm tra các yêu cầu ghi nhãn / tài liệu.

Kiểm tra chức năng là khi sản phẩm được thử nghiệm được đặt vào môi trường thử nghiệm có thể tạo ra nhiều kích thích (trong phạm vi thử nghiệm) môi trường đích thường tạo ra hoặc thậm chí xa hơn, trong khi kiểm tra phản ứng của thiết bị được thử nghiệm.

Đối với một sản phẩm vật lý (không phải phần mềm), có hai loại thử nghiệm Chấp nhận chính : thử nghiệm thiết kế và thử nghiệm sản xuất. Các thử nghiệm thiết kế thường sử dụng số lượng lớn mẫu sản phẩm, đã vượt qua thử nghiệm sản xuất. Người tiêu dùng khác nhau có thể thử nghiệm các cách thiết kế khác nhau.

Thử nghiệm chấp nhận được gọi là xác minh khi thiết kế được thử nghiệm dựa trên đặc điểm kỹ thuật của sản phẩm và thử nghiệm chấp nhận được gọi là xác nhận, khi sản phẩm được đặt trong môi trường thực của người tiêu dùng.

Thử nghiệm chấp nhận chỉ là thử nghiệm được thực hiện bởi khách hàng và bao gồm các loại thử nghiệm khác:

• Kiểm tra chức năng: "nút này không hoạt động"
• Kiểm tra phi chức năng: "trang này hoạt động nhưng quá chậm"

Đối với thử nghiệm chức năng so với thử nghiệm phi chức năng (các kiểu con của chúng) - xem câu trả lời của tôi cho câu hỏi SO này .

Họ là những điều tương tự.

Thử nghiệm chấp nhận được thực hiện trên hệ thống đã hoàn thành giống hệt nhất có thể với môi trường sản xuất / triển khai thực trước khi hệ thống được triển khai hoặc phân phối.

Bạn có thể thực hiện kiểm tra chấp nhận theo cách tự động hoặc thủ công.