Các báo cáo bảo hiểm mã riêng biệt cho các bài kiểm tra đơn vị và tích hợp, hoặc một báo cáo cho cả hai?

Nên có một báo cáo bảo hiểm mã riêng cho các thử nghiệm đơn vị và tích hợp, hoặc một báo cáo bảo hiểm mã cho cả hai?

Suy nghĩ đằng sau điều này là phạm vi bảo hiểm mã cho phép chúng tôi đảm bảo rằng mã của chúng tôi đã được bao phủ bởi các thử nghiệm càng nhiều càng tốt (càng nhiều càng tốt cho một máy bây giờ).

Có một báo cáo riêng sẽ thuận tiện hơn cho chúng tôi để biết những gì chưa được bao gồm trong các thử nghiệm đơn vị và những gì chưa được bao phủ trong các thử nghiệm tích hợp. Nhưng theo cách này chúng ta không thể thấy tổng tỷ lệ bao phủ.

Trên hết, bạn cần phải có và phân tích phạm vi kết hợp (tổng cộng). Nếu bạn nghĩ về nó, đây là cách tự nhiên nhất để ưu tiên đúng mức rủi ro của bạn và tập trung nỗ lực phát triển thử nghiệm của bạn.

Kết hợp bảo hiểm chương trình cho bạn những gì mã không được bao phủ bởi các xét nghiệm ở tất cả , tức là rủi ro nhất và cần phải được điều tra đầu tiên. Các báo cáo bảo hiểm riêng biệt sẽ không giúp ích ở đây, vì chúng không cho phép bạn tìm hiểu xem mã có được kiểm tra bằng cách nào khác hay không được kiểm tra.

Phân tích bảo hiểm riêng biệt cũng có thể hữu ích, nhưng nó tốt hơn sẽ được thực hiện sau khi bạn đã hoàn tất với phân tích kết hợp và tốt nhất cũng sẽ bao gồm kết quả phân tích vùng phủ sóng kết hợp.

Mục đích của phân tích bảo hiểm riêng biệt khác với kết hợp một. Phân tích bảo hiểm riêng biệt giúp cải thiện thiết kế bộ thử nghiệm của bạn, trái ngược với phân tích bảo hiểm kết hợp nhằm quyết định các thử nghiệm sẽ được phát triển cho dù thế nào đi chăng nữa.

"Ôi khoảng trống này không được bao phủ chỉ vì chúng tôi quên thêm bài kiểm tra đơn vị (tích hợp) đơn giản đó vào bộ đơn vị (tích hợp) của chúng tôi, hãy thêm nó" - phân tích và phân tích riêng biệt hữu ích nhất ở đây, vì người ta kết hợp có thể che giấu các khoảng trống mà bạn muốn bao gồm trong bộ cụ thể.

Từ quan điểm trên, vẫn còn mong muốn mặc dù cũng có kết quả phân tích bảo hiểm kết hợp để phân tích các trường hợp khó khăn hơn. Hãy nghĩ về nó, với những kết quả này, các quyết định phát triển thử nghiệm của bạn có thể hiệu quả hơn do có thông tin về các bộ thử nghiệm "đối tác".

"Có một khoảng trống ở đây, nhưng việc phát triển một thử nghiệm đơn vị (tích hợp) để bao quát nó sẽ thực sự cồng kềnh, các tùy chọn của chúng tôi là gì? Hãy kiểm tra phạm vi kết hợp ... ồ nó đã được đề cập ở nơi khác, nghĩa là, bao gồm nó trong bộ của chúng tôi không ' t cực kỳ quan trọng. "

Bạn không đề cập đến công cụ kiểm tra của bạn. Nhiều chức năng "kết hợp" cho phép bạn tổng hợp kết quả của nhiều lần chạy hoặc bộ. Nếu bạn muốn một số liệu bảo hiểm tổng hợp, hãy khám phá tính năng kết hợp trong công cụ bảo hiểm của bạn.

Bây giờ, chúng ta có thể nói về con voi trong phòng không?

Không có muỗng. Và không có "tổng tỷ lệ bao phủ." Ít nhất, không đơn giản.

Tỷ lệ bao phủ là một số liệu dễ hiểu được trình bày để giúp hiểu phạm vi, độ sâu và phạm vi của các bộ thử nghiệm. Nhưng giống như bất kỳ điểm chuẩn đơn giản nào, rất dễ trở thành mục tiêu cố định trên giá trị này như một loại bùa phép thuật "thử nghiệm hoàn chỉnh".

Giả sử bạn đã đạt được vinh quang về "phạm vi kiểm tra 100%." Yay! Nhưng điều đó có nghĩa gì? 100% dòng mã được kiểm tra, phải không? Vậy thì dòng này thì sao?

launch_missile = launch_authorized and launch_cmd_given else previous_launch_status

"Bao phủ" dòng đó có nghĩa là một cái gì đó - nhưng không phải là toàn bộ, bởi vì có nhiều điều kiện khác nhau Truehoặc Falsevới một số xác suất, nhưng không chắc là bạn đã thử nghiệm tất cả các kết hợp của các điều kiện đó. Ngay cả khi dòng đó được bảo hiểm hàng chục lần, nếu một trong những điều kiện tương đối không phổ biến, bạn vẫn không thể kiểm tra tất cả các kết quả thực có thể xảy ra trong thực tế. Để làm cho rõ ràng hơn, một ví dụ tổng hợp hơn:

engage_laser = (laser_armed and safety_disengaged) or random.random() < 0.0000003

Bao nhiêu lần bạn sẽ phải bao gồm dòng đó để thực sự kiểm tra toàn diện nó? Bao nhiêu lần bạn sẽ phải bao gồm nó để kiểm tra nó kết hợp với tất cả các biến khác trong chương trình (với xác suất của riêng chúng, có thể tương tự hiếm)?

Tôi không nói rằng các số liệu bảo hiểm là vô ích. Họ thực sự tuyệt vời . Họ tập trung vào một trong những vấn đề chính: Hệ thống phần mềm của tôi được thử nghiệm rộng rãi như thế nào? Họ giúp chuyển từ "chúng tôi có một số bài kiểm tra" sang "chúng tôi đã kiểm tra kỹ lưỡng".

Nhưng trong khi bạn đang làm việc với "điểm số kết hợp", thì thực tế là điểm số của bạn thường sẽ dành cho "phạm vi bảo hiểm tuyên bố" thay vì "điều kiện", "vị ngữ" hoặc "đường dẫn" . Vì vậy, bất kể số điểm tổng hợp nào của bạn cung cấp cho bạn, không chắc là nó cung cấp cho bạn một bức tranh chân thực về bao nhiêu trạng thái tiềm năng của chương trình và các kết hợp trạng thái đang được kiểm tra. Trong khi bạn đang làm việc để tăng tỷ lệ phần trăm bảo hiểm của mình, hãy xem xét việc đo mức độ bao phủ của vị ngữ. Nó sẽ cho bạn một cái nhìn thực tế hơn - và gần như bất biến, một cái nhìn tỉnh táo hơn - về tính mở rộng thử nghiệm.