Mục đích của kiểm thử phần mềm là gì? [đóng cửa]

Đã đọc nhiều sách, có một mâu thuẫn cơ bản:

Một số người nói, "mục tiêu của thử nghiệm là tìm ra lỗi" trong khi người khác nói "mục tiêu của thử nghiệm là cân bằng chất lượng sản phẩm", nghĩa là lỗi là sản phẩm phụ của nó.

Tôi cũng đồng ý rằng nếu việc kiểm tra sẽ chủ yếu nhắm vào việc săn lỗi, ai sẽ thực hiện xác minh thực tế và thực sự cung cấp thông tin mà phần mềm đã sẵn sàng?

Ngay cả ví dụ Kaner đã thay đổi định nghĩa ban đầu về mục tiêu thử nghiệm từ săn lỗi sang cung cấp đánh giá chất lượng nhưng tôi vẫn không thể thấy sự khác biệt rõ ràng. Tôi quan niệm cả hai đều quan trọng như nhau.

Tôi có thể xác minh phần mềm theo thông số kỹ thuật của nó để đảm bảo phần mềm hoạt động và trong trường hợp đó, các lỗi được tìm thấy chỉ là do sản phẩm. Nhưng tôi cũng thực hiện các bài kiểm tra chỉ để phá vỡ mọi thứ.

Ngoài ra định nghĩa nào chính xác hơn?

_{Lưu ý ở trên tôi chủ yếu đề cập đến kiểm thử phần mềm như là một quá trình.}

Như tôi chắc chắn rằng bạn biết, có nhiều loại thử nghiệm phần mềm khác nhau, chẳng hạn như thử nghiệm đơn vị, thử nghiệm tích hợp, thử nghiệm chấp nhận, v.v ... Vì vậy, đây là một thuật ngữ ô cho tất cả các loại đó, và ở mức độ rất cao này thảo luận, chúng ta chỉ có thể thực sự nói về "chất lượng", như một thuật ngữ rộng. Bạn chỉ đơn giản là xác nhận phần mềm dựa trên bất kỳ phép đo nào về khả năng chấp nhận mà bạn muốn áp dụng. Ở các cấp độ và loại thử nghiệm khác nhau, chúng sẽ khác nhau rất nhiều, và điểm chung duy nhất thực sự là khía cạnh chất lượng.

Lỗi (theo truyền thống được xác định) là một loại vấn đề cụ thể với phần mềm, nhưng có nhiều vấn đề khác. Trừ khi chúng ta thảo luận về một mức độ thử nghiệm cụ thể, thấp hơn, không có nghĩa là giới hạn định nghĩa đối với các lỗi. Là một giao diện người dùng hơi chậm một lỗi ? Điều gì về thực tế là chúng tôi quên nói với các nhà phát triển để thêm một giỏ vào cửa hàng web của chúng tôi? Có lẽ sự nhầm lẫn xuất hiện với các loại thử nghiệm cụ thể được gọi là "thử nghiệm phần mềm", nhưng nó thực sự chỉ là ngữ nghĩa.

Nếu được thúc đẩy để chính thức hóa định nghĩa, tôi sẽ nói rằng thử nghiệm là một quá trình xác nhận phần mềm theo yêu cầu của bạn (cũng có thể là định tính). Một lỗi chỉ là một sự vi phạm các yêu cầu rất cụ thể (cụ thể, một lỗi mà nhà phát triển nghĩ rằng đã hoạt động chính xác).

EDIT: Tôi có lẽ nên thêm rằng từ "bug" có ý nghĩa rất khác nhau đối với những người khác nhau và chúng ta thực sự nên bắt đầu cuộc thảo luận ngữ nghĩa này bằng cách định nghĩa nó. Tôi đang sử dụng định nghĩa từ quan điểm của nhà phát triển - điều này không hoạt động như tôi (nhà phát triển) dự định. Nó thường dựa trên một yêu cầu rất cụ thể hoặc một cách giải thích rất cụ thể về một yêu cầu. Định nghĩa của khách hàng thường tương tự - điều này không hoạt động như tôi (khách hàng) dự định, đó thực sự là một điều rất khác. Sử dụng định nghĩa sau, bạn gần như có thể đánh đồng chất lượng và lỗi, bởi vì bất cứ điều gì không đáp ứng mong muốn của khách hàng là "lỗi".

Từ câu trả lời của Daniel B:

Tôi đang sử dụng định nghĩa từ quan điểm của nhà phát triển - điều này không hoạt động như tôi (nhà phát triển) dự định. Nó thường dựa trên một yêu cầu rất cụ thể hoặc một cách giải thích rất cụ thể về một yêu cầu. Định nghĩa của khách hàng thường tương tự - điều này không hoạt động như tôi (khách hàng) dự định, đó thực sự là một điều rất khác.

Đây thực chất là sự khác biệt giữa xác minh và xác nhận. Xác minh trả lời câu hỏi "Chúng tôi đã xây dựng nó phải không?" Xác nhận trả lời câu hỏi "Chúng ta đã xây dựng điều đúng chưa?" Kiểm tra xác minh và kiểm tra xác nhận là những thứ khá khác nhau. Xác minh là một nhiệm vụ dễ dàng hơn nhiều so với xác nhận. Với xác minh, bạn biết phải kiểm tra những gì: các yêu cầu (hoặc câu chuyện) đánh vần những gì phần mềm phải làm. Có một vấn đề ở đây: Điều gì xảy ra nếu những yêu cầu hoặc câu chuyện đó là sai? Làm thế nào để bạn kiểm tra vấn đề đó? Đó là những gì xác nhận cố gắng để giải quyết.

Một thành phần khác được sử dụng trong một số vòng tròn là khái niệm công nhận. Điều này trở nên quan trọng khi phần mềm được sử dụng lại. Ví dụ: Giả sử bạn đang xây dựng một mô phỏng của một chiếc xe và cần một mô hình tốt của đơn vị đo lường quán tính của nó. Bạn tìm thấy một mô hình IMU hiện có trong thư viện mô hình thành phần. Mô hình hiện có này đã được xác minh kỹ lưỡng so với yêu cầu và được xác thực so với thực tế. Việc thử nghiệm rất rộng rãi, bao gồm các so sánh với dữ liệu chuyến bay. Xác minh và xác nhận! Nghe hay đấy! Chỉ cần sử dụng lại như nó là.

Sau đó, một lần nữa, có thể không. Mục đích sử dụng của mô hình đó có thể là các hoạt động không hoạt động, việc sử dụng của bạn là mô hình một tên lửa trong giai đoạn phóng. Hành vi của IMU trong khi khởi chạy sẽ gần với hành vi cụ thể: nói cách khác, tệ hại. IMU thường thực hiện nhiều, tốt hơn nhiều so với thông số kỹ thuật trong các hoạt động không hoạt động. Mục đích sử dụng của mô hình đó không phù hợp với mục đích sử dụng của bạn. Bạn tốt hơn không nên sử dụng lại nó. Nỗ lực công nhận vượt quá xác minh và xác nhận. Nó trả lời câu hỏi "Đây có phải là điều đúng cho mục đích sử dụng cụ thể này không?"

Một ví dụ khác là cuộc thử nghiệm đầu tiên của tên lửa Ariane 5. Lỗi phần mềm dẫn đến sự thất bại của chuyến bay 501 được xếp hạng là một trong những lỗi phần mềm khét tiếng và đắt nhất mọi thời đại. Phần mềm máy bay cực kỳ tốn kém để xây dựng. Để tránh những chi phí khổng lồ này, phần mềm chuyến bay Ariane 5 đã sử dụng lại phần lớn của phần mềm chuyến bay Ariane 4. Xác minh và xác nhận rộng rãi, và đã được sử dụng trong môi trường thế giới thực. Vì vậy, chỉ cần sử dụng lại như nó là. Sai lầm. Nó đã được công nhận để tái sử dụng. Một sự kiện được cho là "không thể xảy ra" liên quan đến sự cố tràn chuyển đổi 64 bit sang 16 bit đã xảy ra và kết quả là chiếc xe đã thất bại.

Mục đích của kiểm thử phần mềm là gì?

Tóm lại: Như các tác giả câu hỏi bình luận nói "nói chung, kiểm thử phần mềm như một quá trình." - Câu hỏi của bạn rất rộng, và đây là định nghĩa của nó trong bài viết Wikipedia .

Kiểm thử phần mềm là một cuộc điều tra được thực hiện để cung cấp cho các bên liên quan thông tin về chất lượng sản phẩm hoặc dịch vụ được thử nghiệm. Kiểm thử phần mềm cũng có thể cung cấp một cái nhìn khách quan, độc lập về phần mềm để cho phép doanh nghiệp đánh giá và hiểu các rủi ro khi triển khai phần mềm.

Vì vậy, mục đích của kiểm thử phần mềm là cung cấp thông tin độc lập về chất lượng sản phẩm / phần mềm. - Làm thế nào nó cần phải được thực hiện và quy trình kiểm thử phần mềm? - là một câu hỏi khác nhau để tìm kiếm.

Chỉnh sửa: Quá trình kiểm thử phần mềm cần được cung cấp độc lập dựa trên yêu cầu nghiệp vụ. Nếu không, sẽ có ít giá trị hơn trong đó. Trên thực tế, các dự án phần mềm phạm vi lớn (như dự án bất động sản quốc gia hoặc tương tự) có một quy định riêng về kiểm soát chất lượng, kiểm tra và quy trình xác nhận / xác nhận phần mềm.

Xác định hồi quy phần mềm ngay khi chúng tự trình bày.

Cụ thể, Kiểm thử đơn vị có nghĩa là xác định hồi quy sớm trong chuỗi xây dựng / thử nghiệm / triển khai

Kiểm tra chấp nhận là nhiều hơn trên các dòng đầy đủ hợp đồng với khách hàng . Nhưng một lần nữa, nếu một phần của bài kiểm tra chấp nhận không vượt qua trong khi nó được cho là thay vào đó, bạn đã xác định được hồi quy để xử lý.

Tôi tin rằng cuốn sách "Nghệ thuật kiểm thử phần mềm" của Glenford J. Myers định nghĩa nó tốt nhất:

"Kiểm tra là quá trình thực hiện một chương trình với mục đích tìm lỗi."

Ông đối chiếu định nghĩa này với một số định nghĩa phổ biến:

• "Kiểm tra là quá trình chứng minh rằng không có lỗi."
• "Mục đích của kiểm tra là chỉ ra rằng một chương trình thực hiện đúng chức năng dự định của nó."
• "Kiểm thử là quá trình thiết lập sự tự tin rằng một chương trình thực hiện những gì nó được cho là sẽ làm."

Thay vì cố gắng chứng minh rằng một chương trình hoạt động, chúng ta nên cho rằng chương trình có lỗi và mục tiêu của kiểm thử phần mềm là tìm ra chúng. Khi làm như vậy, chất lượng của phần mềm được nâng lên, đó là mục đích cuối cùng của kiểm thử phần mềm.

Câu trả lời của @David Hammen rất hay, mặc dù không chính xác như những gì tôi đã nói. Tôi đồng ý rằng câu trả lời Xác minh "Chúng tôi đã xây dựng cái này đúng chưa?". Bất cứ điều gì được tạo ra bởi một quá trình có thể được xác minh. Sản xuất liên quan đến việc xác minh liên tục rằng thứ được sản xuất đã được sản xuất chính xác.

Sau đó, ông định nghĩa Xác nhận, mà chúng tôi đồng ý là khác nhau, là "Chúng tôi đã xây dựng điều đúng chưa?" Tôi sẽ nói rằng Xác thực di chuyển theo hướng ngược lại, để xác nhận một cách thấu đáo chính xác chức năng chính xác của một thiết kế. Giống như "Chứng minh một cách khách quan rằng giải pháp được thiết kế chính xác". Các lớp bên phải của bu lông, kích thước đúng của các biến nội bộ. Các mảnh là tùy thuộc vào công việc.

Xác thực của David, "Chúng ta đã xây dựng điều đúng chưa?" là một câu hỏi cấp cao không phải là thứ bạn có thể chạy với bản dựng hàng ngày, bật ngón tay cái hoặc ngón tay cái xuống. Đó là một đánh giá của các yêu cầu và ở mức độ thấp hơn, thiết kế. Đây không phải là một câu hỏi hợp lý được gửi đến hộp văn bản trên màn hình hoặc tham số trong API. Không chắc chắn tên một từ là gì cho tính chính xác của yêu cầu, có thể là Xác thực Yêu cầu. Chứng minh một cách thấu đáo rằng các yêu cầu tương ứng với nhu cầu của người dùng cuối.

Ngược lại, định nghĩa của tôi về Xác thực là bằng chứng về tính chính xác của một thiết kế, các thử nghiệm khách quan cho thấy các phần được chọn sẽ thực hiện công việc. Phần mềm Ariane IV không phù hợp với Ariane V sẽ thất bại ở đây, vì Ariane IV có phạm vi thay đổi tốc độ góc giới hạn. Mã được tối ưu hóa cho phạm vi giới hạn này và Ariane V có khả năng phạm vi góc lớn hơn, gây ra tràn. Khi cả hai máy tính trên máy bay gặp sự cố tràn, và thực hiện lại sau khi tự động khởi động lại, hệ thống hủy được kích hoạt.

Như Dykstra đã nói, "Tối ưu hóa sớm là gốc rễ của mọi tội lỗi."

Trong định nghĩa của tôi, các yêu cầu được cho là chính xác và được chấp nhận, được xác nhận bằng thử nghiệm Yêu cầu. Thiết kế hoặc Xác thực mã chứng minh rằng thiết kế, có lẽ là một chút của việc thực hiện, là chính xác. Nó vẫn phải được thực thi chính xác, nhưng xác nhận đó là Xác minh, thử nghiệm dựa trên Yêu cầu được chấp nhận và Thiết kế được chấp nhận.

Bạn sẽ lưu ý rằng điều này ẩn sâu gần với mô hình Thác nước phát triển, có vẻ có hại nếu được tin là mô tả các hệ thống phức tạp. Dù sao đi nữa, Yêu cầu khác với Thiết kế và Mã là điều thứ ba hoàn toàn. Tôi đoán lời cầu xin của tôi là các yếu tố trong Thác nước là những mô tả hữu ích, nhưng 'hoàn thành' là sai lệch, vì vậy tôi đã thay đổi nó thành 'được chấp nhận', điều này cho thấy sự bất ngờ và khả năng biến đổi.

kiểm thử phần mềm không nhằm mục đích tìm lỗi, nó nhằm mục đích ngăn chặn lỗi. Kiểm tra thích hợp trong giai đoạn đầu ngăn ngừa lỗi làm cho nó vào hệ thống sản xuất.

Tôi nghĩ rằng các khoản đầu tư vào thử nghiệm được thực hiện để "cải thiện trải nghiệm người dùng".

Nhiều lần lỗi còn sót lại vì chúng không ảnh hưởng xấu đến việc sử dụng sản phẩm. Tương tự như vậy, "cân bằng chất lượng sản phẩm" cũng sẽ được chia nhỏ theo mức độ hữu ích của nó khi làm việc trên một khu vực cụ thể. Cuối cùng, tiêu chí "đủ tốt để giao hàng" phải được công nhận ở trạng thái kết thúc để thử nghiệm luôn mang tính chủ quan.

Một phần mềm có chất lượng tuyệt vời là, trong số những thứ khác, một phần mềm có 0 (hoặc rất ít) lỗi. Vì vậy, một cuộc săn lỗi là một quá trình để cải thiện chất lượng.

Một phần mềm đáp ứng tất cả các tính năng của nó cũng là một phần mềm chất lượng tuyệt vời, vì vậy kiểm tra để xác thực các tính năng là một quá trình để cải thiện chất lượng.

Một phần mềm mà trải nghiệm người dùng tốt là một phần mềm chất lượng tuyệt vời, v.v.

Chà, tôi nghĩ mục đích của thử nghiệm sotware là cải thiện chất lượng, sau đó bạn có thể thực hiện một số thử nghiệm săn lỗi, một số xác nhận và xác minh các tính năng, một số thử nghiệm trên UI, v.v.