Tôi đã viết hầu hết các phần mềm máy tính thử nghiệm hơn 25 năm trước. Kể từ đó tôi đã chỉ ra một số phần của cuốn sách mà tôi cho là lỗi thời, hoặc đơn giản là sai. Xem http://www.kaner.com/pdfs/TheOng tiếnRevolution.pdf
Bạn có thể xem thêm (các chế độ xem hiện tại, nhưng không có con trỏ rõ ràng quay lại TCS) tại trang web của tôi cho Khóa học kiểm thử phần mềm Hộp đen (video và các slide có sẵn miễn phí), www.testingeducation.org/BBST
Văn hóa thử nghiệm trước đó phần lớn là xác nhận.
Trong thử nghiệm hiện đại, cách tiếp cận kiểm thử đơn vị phần lớn là xác nhận - chúng tôi viết các bộ sưu tập lớn các thử nghiệm tự động chỉ đơn giản xác minh rằng phần mềm tiếp tục hoạt động như dự định. Các thử nghiệm đóng vai trò là trình phát hiện thay đổi - nếu một cái gì đó trong các phần khác của mã và phần này hiện có vấn đề hoặc nếu các giá trị dữ liệu không thể có trong thế giới thực hiện đang tiếp cận ứng dụng, thì trình phát hiện thay đổi sẽ kích hoạt, cảnh báo lập trình cho một vấn đề bảo trì.
Tôi nghĩ rằng tư duy xác nhận là phù hợp để thử nghiệm đơn vị, nhưng hãy tưởng tượng một thế giới trong đó tất cả các thử nghiệm hệ thống là xác nhận (đối với những người phân biệt, vui lòng diễn giải "thử nghiệm tích hợp hệ thống" và "thử nghiệm chấp nhận" như trong các nhận xét của tôi về hệ thống thử nghiệm.) Quan điểm của thử nghiệm là xác nhận rằng chương trình đáp ứng các thông số kỹ thuật của nó và cách tiếp cận vượt trội là xây dựng một trăm (hoặc ít nhất vài trăm) thử nghiệm hồi quy cấp hệ thống, ánh xạ các phần của thông số kỹ thuật theo hành vi của chương trình. (Tôi nghĩ rằng xác nhận hành vi cụ thể là hữu ích, nhưng tôi nghĩ đó là một phần nhỏ của mục tiêu lớn hơn.)
Vẫn có những nhóm thử nghiệm hoạt động theo cách này, nhưng nó không còn là quan điểm thống trị nữa. Hồi đó, nó đã như vậy. Tôi đã viết một cách dứt khoát và vẽ ra những sự tương phản sắc nét để tạo điểm nhấn cho những người luôn được đào tạo về tư duy này. Ngày nay, một số tương phản sắc nét (bao gồm cả một trong những trích dẫn ở đây) đã lỗi thời. Họ bị hiểu sai là các cuộc tấn công vào các quan điểm sai lầm.
Như tôi thấy, kiểm thử phần mềm là một quá trình thực nghiệm để tìm hiểu thông tin liên quan đến chất lượng về một sản phẩm hoặc dịch vụ phần mềm.
Một bài kiểm tra nên được thiết kế để tiết lộ thông tin hữu ích.
Trước đó, nhân tiện, không ai nói về việc thử nghiệm như một phương pháp để tiết lộ "thông tin". Trước đó, kiểm tra là để (một số phiên bản ...) tìm lỗi hoặc cho (một số phiên bản ...) xác minh (kiểm tra) chương trình theo thông số kỹ thuật. Tôi không nghĩ rằng sự khẳng định rằng các bài kiểm tra là để tiết lộ thông tin hữu ích đã đi vào từ vựng kiểm tra cho đến thế kỷ này.
Hãy tưởng tượng kiểm tra đánh giá về giá trị thông tin của họ. Một bài kiểm tra rất có khả năng dạy cho chúng tôi điều gì đó mà chúng tôi không biết về phần mềm sẽ có giá trị thông tin rất cao. Một thử nghiệm rất có khả năng xác nhận một cái gì đó mà chúng tôi đã mong đợi và đã được chứng minh nhiều lần trước đó, sẽ có giá trị thông tin thấp. Một cách để ưu tiên kiểm tra là chạy thử nghiệm giá trị thông tin cao hơn trước khi kiểm tra giá trị thông tin thấp hơn.
Nếu tôi áp dụng quá mức ưu tiên này để nó thu hút sự chú ý của lập trình viên, người quản lý dự án hoặc người quản lý quy trình, người không biết gì về kiểm thử phần mềm, tôi sẽ nói "KIỂM TRA RATNG KHÔNG ĐƯỢC THIẾT KẾ ĐỂ KIẾM ĐƯỢC . " Đây không phải là một bản dịch hoàn hảo, nhưng đối với những độc giả không thể hoặc sẽ không hiểu bất kỳ sự tinh tế hay trình độ nào, điều đó sẽ gần như sẽ có.
Trước đó, và tôi thấy nó một lần nữa ở đây, một số người không hiểu thử nghiệm sẽ trả lời rằng một thử nghiệm được thiết kế để tìm các trường hợp góc là một sự lãng phí thời gian so với thử nghiệm sử dụng chính của một chức năng chính. Họ không hiểu hai điều. Đầu tiên, bằng cách người kiểm tra thời gian tìm thấy thời gian để kiểm tra các giá trị biên, việc sử dụng chính các chức năng chính đã được thực hiện nhiều lần. (Có, có những trường hợp ngoại lệ và hầu hết các nhóm kiểm tra sẽ chú ý cẩn thận đến những ngoại lệ đó.) Thứ hai, lý do để kiểm tra với các giá trị cực đoan là chương trình có nhiều khả năng thất bại với các giá trị cực đoan. Nếu nó không thất bại ở mức cực đoan, bạn kiểm tra một cái gì đó khác. Đây là một quy tắc hiệu quả. Mặt khác, nếu nó KHÔNG thất bại ở một giá trị cực đoan, người kiểm tra có thể dừng lại và báo cáo lỗi hoặc người kiểm tra có thể khắc phục sự cố thêm, để xem liệu chương trình có bị lỗi theo cùng một cách ở các giá trị bình thường hơn không. Ai thực hiện việc khắc phục sự cố đó (người kiểm tra hoặc lập trình viên) là vấn đề của văn hóa doanh nghiệp. Một số công ty dự trù thời gian của người kiểm tra cho việc này, một số ngân sách dành cho các lập trình viên và một số dự kiến các lập trình viên sẽ sửa các lỗi trường hợp góc dù chúng có thể khái quát hóa hay không để việc khắc phục sự cố không liên quan. Sự hiểu lầm phổ biến - rằng người kiểm thử đang lãng phí thời gian (thay vì tối đa hóa hiệu quả) bằng cách kiểm tra các giá trị cực đoan là một lý do khác cho thấy "Một thử nghiệm không được thiết kế để phát hiện ra lỗi là lãng phí thời gian" là một thông điệp thích hợp cho người kiểm tra. Đó là một sự đối nghịch với sự khuyến khích từ một số lập trình viên để (không có hiệu lực) không bao giờ chạy các bài kiểm tra có thể thách thức chương trình. Thông điệp được đơn giản hóa, nhưng toàn bộ cuộc thảo luận là quá mức.
Nhân tiện, "giá trị thông tin" không thể là hệ thống ưu tiên duy nhất. Đó không phải là quy tắc của tôi khi tôi thiết kế các bộ thử nghiệm đơn vị. Đó không phải là quy tắc của tôi khi tôi thiết kế kiểm tra xác minh bản dựng (còn gọi là kiểm tra độ tỉnh táo). Trong cả hai trường hợp đó, tôi quan tâm đến các loại bảo hiểm hơn là sức mạnh của các thử nghiệm riêng lẻ. Có những trường hợp khác (ví dụ: các thử nghiệm tự động khối lượng lớn có giá rẻ để thiết lập, chạy và giám sát) trong đó sức mạnh của các thử nghiệm riêng lẻ đơn giản là không liên quan đến thiết kế của tôi. Tôi chắc rằng bạn có thể nghĩ về các ví dụ bổ sung.
Nhưng như một quy tắc chung, nếu tôi chỉ có thể nêu ra một quy tắc (ví dụ như nói với một giám đốc điều hành có đầu phát nổ nếu anh ta cố xử lý nhiều hơn một câu), thì việc kiểm tra giá trị thông tin thấp thường là lãng phí thời gian.