Nếu bạn bắt buộc bảo hiểm mã phần trăm tối thiểu cho các thử nghiệm đơn vị, thậm chí có thể là một yêu cầu để cam kết với một kho lưu trữ, thì nó sẽ là gì?

Vui lòng giải thích cách bạn đi đến câu trả lời của mình (vì nếu tất cả những gì bạn đã làm là chọn một số, thì tôi có thể tự mình làm điều đó;)

Bài văn xuôi này của Alberto Savoia trả lời chính xác câu hỏi đó (theo cách giải trí độc đáo ở đó!):

http://www.artima.com/forums/flat.jsp?forum=106&thread=204677

Testivus trên phạm vi kiểm tra

Một buổi sáng sớm, một lập trình viên hỏi ông chủ vĩ đại:

Tôi đã sẵn sàng để viết một số bài kiểm tra đơn vị. Tôi nên nhắm đến phạm vi bảo hiểm nào?

Đại sư trả lời:

Không cần lo lắng về phạm vi bảo hiểm, chỉ cần viết một số bài kiểm tra tốt.

Lập trình viên mỉm cười, cúi đầu, và rời đi.

...

Cuối ngày hôm đó, một lập trình viên thứ hai cũng hỏi câu hỏi tương tự.

Ông chủ vĩ đại chỉ vào một nồi nước sôi và nói:

Tôi nên bỏ bao nhiêu hạt gạo vào nồi đó?

Các lập trình viên, nhìn bối rối, trả lời:

Làm thế nào tôi có thể nói với bạn? Nó phụ thuộc vào số lượng người bạn cần cho ăn, họ đói như thế nào, bạn đang phục vụ loại thực phẩm nào khác, bạn có bao nhiêu gạo, v.v.

Chính xác thì, hoàng tử nói.

Lập trình viên thứ hai mỉm cười, cúi đầu và rời đi.

...

Đến cuối ngày, một lập trình viên thứ ba đã đến và hỏi cùng một câu hỏi về phạm vi bảo hiểm mã.

Tám mươi phần trăm và không kém! Trả lời ông chủ bằng giọng nghiêm khắc, đập bàn tay lên bàn.

Lập trình viên thứ ba mỉm cười, cúi đầu và rời đi.

...

Sau câu trả lời cuối cùng này, một người học việc trẻ tuổi đã tiếp cận ông chủ vĩ đại:

Đại sư, hôm nay tôi tình cờ nghe bạn trả lời cùng một câu hỏi về bảo hiểm mã với ba câu trả lời khác nhau. Tại sao?"

Ông chủ vĩ đại đứng dậy khỏi ghế:

Hãy đến uống trà tươi với tôi và hãy nói về nó.

Sau khi họ rót đầy cốc của mình bằng việc hút trà xanh nóng, vị đại sư bắt đầu trả lời:

Các lập trình viên đầu tiên là người mới và mới bắt đầu thử nghiệm. Ngay bây giờ anh ta có rất nhiều mã và không có bài kiểm tra. Anh ấy có một chặng đường dài để đi; tập trung vào bảo hiểm mã tại thời điểm này sẽ gây thất vọng và khá vô dụng. Anh ấy tốt hơn là chỉ quen với việc viết và chạy một số bài kiểm tra. Anh ấy có thể lo lắng về bảo hiểm sau này.

Mặt khác, lập trình viên thứ hai, khá kinh nghiệm cả về lập trình và kiểm tra. Khi tôi trả lời bằng cách hỏi cô ấy nên bỏ bao nhiêu hạt gạo vào nồi, tôi đã giúp cô ấy nhận ra rằng lượng thử nghiệm cần thiết phụ thuộc vào một số yếu tố và cô ấy biết rõ những yếu tố đó hơn tôi - đó là mã của cô ấy . Không có câu trả lời đơn giản, đơn giản nào và cô ấy đủ thông minh để xử lý sự thật và làm việc với điều đó.

Tôi thấy, tên là người học việc trẻ tuổi, nhưng nếu không có câu trả lời đơn giản nào, thì tại sao bạn lại trả lời lập trình viên thứ ba 'Tám mươi phần trăm và không kém'?

Ông chủ vĩ đại cười to và to đến nỗi bụng của anh ta, bằng chứng là anh ta uống nhiều hơn là chỉ uống trà xanh, lật lên xuống.

Lập trình viên thứ ba chỉ muốn những câu trả lời đơn giản - ngay cả khi không có câu trả lời đơn giản, và sau đó không theo dõi họ.

Người học việc trẻ và vị chủ nhân vĩ đại đã uống xong trà trong sự im lặng chiêm nghiệm.

Bảo hiểm mã là một số liệu sai lệch nếu bảo hiểm 100% là mục tiêu của bạn (thay vì kiểm tra 100% tất cả các tính năng).

• Bạn có thể nhận được 100% bằng cách nhấn tất cả các dòng một lần. Tuy nhiên, bạn vẫn có thể bỏ lỡ việc kiểm tra một chuỗi cụ thể (đường dẫn logic) trong đó các dòng đó được nhấn.
• Bạn không thể nhận được 100% nhưng vẫn kiểm tra tất cả các đường dẫn mã được sử dụng 80% / freq của bạn. Có các bài kiểm tra kiểm tra mọi 'ném ExceptionTypeX' hoặc bảo vệ lập trình phòng thủ tương tự mà bạn đặt vào là 'tốt để có' không phải là 'phải có'

Vì vậy, hãy tin tưởng bản thân hoặc nhà phát triển của bạn để kỹ lưỡng và bao quát mọi con đường thông qua mã của họ. Hãy thực dụng và đừng theo đuổi phạm vi bảo hiểm 100% huyền diệu. Nếu bạn TDD mã của bạn, bạn sẽ nhận được bảo hiểm 90% + dưới dạng tiền thưởng. Sử dụng phạm vi bảo hiểm mã để làm nổi bật các đoạn mã bạn đã bỏ lỡ (không nên xảy ra nếu bạn TDD mặc dù .. vì bạn chỉ viết mã để thực hiện kiểm tra. Không có mã nào có thể tồn tại mà không có kiểm tra đối tác của nó.)

Bảo hiểm mã là tuyệt vời, nhưng bảo hiểm chức năng thậm chí còn tốt hơn. Tôi không tin vào việc viết từng dòng tôi viết. Nhưng tôi tin vào việc viết phạm vi kiểm tra 100% tất cả các chức năng tôi muốn cung cấp (ngay cả đối với các tính năng thú vị bổ sung mà tôi tự đi kèm và không được thảo luận trong các cuộc họp).

Tôi không quan tâm nếu tôi có mã không được bao gồm trong các thử nghiệm, nhưng tôi sẽ quan tâm nếu tôi sẽ cấu trúc lại mã của mình và cuối cùng có một hành vi khác. Do đó, bảo hiểm chức năng 100% là mục tiêu duy nhất của tôi.

Câu trả lời được chấp nhận làm cho một điểm tốt - không có một con số nào có ý nghĩa như là một tiêu chuẩn cho mọi dự án. Có những dự án không cần một tiêu chuẩn như vậy. Theo ý kiến ​​của tôi, câu trả lời được chấp nhận trong trường hợp mô tả cách người ta có thể đưa ra quyết định cho một dự án nhất định.

Tôi sẽ có một shot tại làm như vậy. Tôi không phải là một chuyên gia về kỹ thuật kiểm tra và sẽ rất vui khi thấy một câu trả lời nhiều thông tin hơn.

Khi nào cần đặt yêu cầu bảo hiểm mã

Đầu tiên, tại sao bạn muốn áp đặt một tiêu chuẩn như vậy ngay từ đầu? Nói chung, khi bạn muốn giới thiệu sự tự tin theo kinh nghiệm trong quá trình của bạn. Ý tôi là "tự tin theo kinh nghiệm" nghĩa là gì? Vâng, mục tiêu chính xác thực sự . Đối với hầu hết các phần mềm, chúng tôi không thể biết điều này trên tất cả các đầu vào, vì vậy chúng tôi giải quyết việc nói rằng mã được kiểm tra tốt . Điều này dễ hiểu hơn, nhưng vẫn là một tiêu chuẩn chủ quan: Nó sẽ luôn mở để tranh luận về việc bạn có đáp ứng nó hay không. Những cuộc tranh luận là hữu ích và nên xảy ra, nhưng chúng cũng phơi bày sự không chắc chắn.

Bảo hiểm mã là một phép đo khách quan: Một khi bạn thấy báo cáo bảo hiểm của mình, không có sự mơ hồ về việc các tiêu chuẩn đã được đáp ứng có hữu ích hay không. Liệu nó có chứng minh sự đúng đắn? Hoàn toàn không, nhưng nó có một mối quan hệ rõ ràng với việc mã được kiểm tra tốt như thế nào, đến lượt nó là cách tốt nhất của chúng tôi để tăng sự tự tin về tính chính xác của nó. Bảo hiểm mã là một xấp xỉ có thể đo lường được của các phẩm chất vô lượng mà chúng ta quan tâm.

Một số trường hợp cụ thể khi có một tiêu chuẩn thực nghiệm có thể tăng thêm giá trị:

• Để thỏa mãn các bên liên quan. Đối với nhiều dự án, có nhiều tác nhân khác nhau quan tâm đến chất lượng phần mềm, những người có thể không tham gia vào việc phát triển phần mềm hàng ngày (người quản lý, lãnh đạo kỹ thuật, v.v.) Nói rằng "chúng tôi sẽ viết tất cả các thử nghiệm mà chúng tôi thực sự cần "không thuyết phục: Họ cần phải tin tưởng hoàn toàn hoặc xác minh với sự giám sát chặt chẽ đang diễn ra (giả sử họ thậm chí có hiểu biết về kỹ thuật để làm như vậy.) Cung cấp các tiêu chuẩn có thể đo lường và giải thích cách họ hợp lý các mục tiêu thực tế là tốt hơn.
• Để bình thường hóa hành vi nhóm. Bỏ qua các bên liên quan, nếu bạn đang làm việc trong một nhóm có nhiều người đang viết mã và kiểm tra, sẽ có chỗ cho sự mơ hồ về những gì đủ điều kiện là "được kiểm tra tốt". Có phải tất cả các đồng nghiệp của bạn có cùng một ý tưởng về mức độ thử nghiệm là đủ tốt? Chắc là không. Làm thế nào để bạn hòa giải này? Tìm một số liệu mà tất cả bạn có thể đồng ý và chấp nhận nó như một xấp xỉ hợp lý. Điều này đặc biệt (nhưng không độc quyền) trong các nhóm lớn, nơi các khách hàng tiềm năng có thể không có sự giám sát trực tiếp đối với các nhà phát triển cơ sở, chẳng hạn. Mạng lưới của vấn đề niềm tin là tốt, nhưng không có các phép đo khách quan, rất dễ để hành vi nhóm trở nên không nhất quán, ngay cả khi tất cả mọi người đang hành động trong đức tin tốt.
• Để giữ cho mình trung thực. Ngay cả khi bạn là nhà phát triển duy nhất và là bên liên quan duy nhất cho dự án của bạn, bạn có thể có những phẩm chất nhất định cho phần mềm. Thay vì thực hiện các đánh giá chủ quan liên tục về mức độ phần mềm được kiểm tra tốt (hoạt động tốt), bạn có thể sử dụng phạm vi bảo hiểm mã như một xấp xỉ hợp lý và để máy đo lường cho bạn.

Những số liệu để sử dụng

Mã bảo hiểm không phải là một số liệu đơn lẻ; có một số cách khác nhau để đo phạm vi bảo hiểm. Cái nào bạn có thể đặt tiêu chuẩn phụ thuộc vào những gì bạn đang sử dụng tiêu chuẩn đó để đáp ứng.

Tôi sẽ sử dụng hai số liệu phổ biến làm ví dụ về thời điểm bạn có thể sử dụng chúng để đặt tiêu chuẩn:

• Bảo hiểm tuyên bố : Bao nhiêu phần trăm các báo cáo đã được thực hiện trong quá trình thử nghiệm? Hữu ích để hiểu được mức độ bao phủ vật lý của mã của bạn: Tôi đã thực sự kiểm tra bao nhiêu mã mà tôi đã viết?
  • Loại bảo hiểm này hỗ trợ một đối số chính xác yếu hơn, nhưng cũng dễ dàng đạt được hơn. Nếu bạn chỉ sử dụng phạm vi bảo hiểm mã để đảm bảo rằng mọi thứ được kiểm tra (và không phải là một chỉ số về chất lượng kiểm tra vượt quá điều đó) thì có thể bảo hiểm tuyên bố là đủ.
• Phạm vi chi nhánh : Khi có logic phân nhánh (ví dụ: một if), cả hai nhánh đã được đánh giá chưa? Điều này mang lại cảm giác tốt hơn về phạm vi logic của mã của bạn: Tôi đã kiểm tra bao nhiêu con đường có thể có mà tôi đã thử nghiệm?
  • Loại bảo hiểm này là một chỉ báo tốt hơn nhiều cho thấy một chương trình đã được thử nghiệm trên một tập hợp toàn diện các đầu vào. Nếu bạn đang sử dụng phạm vi bảo hiểm mã là xấp xỉ theo kinh nghiệm tốt nhất của bạn để tự tin về tính chính xác, bạn nên đặt tiêu chuẩn dựa trên phạm vi bảo hiểm chi nhánh hoặc tương tự.

Ví dụ, có nhiều số liệu khác (độ bao phủ của dòng tương tự như độ bao phủ của câu lệnh, nhưng mang lại kết quả số khác nhau cho các câu lệnh nhiều dòng, ví dụ, độ bao phủ có điều kiện và độ bao phủ đường dẫn tương tự như độ phủ của nhánh, nhưng phản ánh cái nhìn chi tiết hơn về các hoán vị có thể có của thực hiện chương trình bạn có thể gặp phải.)

Bao nhiêu phần trăm để yêu cầu

Cuối cùng, trở lại câu hỏi ban đầu: Nếu bạn đặt tiêu chuẩn bảo hiểm mã, con số đó phải là bao nhiêu?

Hy vọng rằng rõ ràng vào thời điểm này, chúng ta đang nói về một xấp xỉ bắt đầu, vì vậy bất kỳ số nào chúng ta chọn sẽ là gần đúng.

Một số số mà người ta có thể chọn:

• 100% . Bạn có thể chọn điều này bởi vì bạn muốn chắc chắn mọi thứ đã được thử nghiệm. Điều này không cung cấp cho bạn cái nhìn sâu sắc về chất lượng thử nghiệm, nhưng nó cho bạn biết rằng một số thử nghiệm về chất lượng đã chạm đến mọi tuyên bố (hoặc chi nhánh, v.v.) Một lần nữa, điều này trở lại mức độ tin cậy: Nếu phạm vi bảo hiểm của bạn dưới 100% , bạn biết một số tập hợp con mã của bạn chưa được kiểm tra.
  • Một số người có thể lập luận rằng điều này là ngớ ngẩn và bạn chỉ nên kiểm tra các phần trong mã của bạn thực sự quan trọng. Tôi sẽ lập luận rằng bạn cũng chỉ nên duy trì các phần trong mã của bạn thực sự quan trọng. Bảo hiểm mã có thể được cải thiện bằng cách loại bỏ mã chưa được kiểm tra, quá.
• 99% (hoặc 95%, các số khác trong những năm chín mươi.) Thích hợp trong trường hợp bạn muốn truyền đạt mức độ tự tin tương tự 100%, nhưng hãy để lại cho mình một chút lề để không lo lắng về góc khó kiểm tra thường xuyên của mã.
• 80% . Tôi đã thấy số này được sử dụng một vài lần và hoàn toàn không biết nó bắt nguồn từ đâu. Tôi nghĩ rằng nó có thể là một hành vi chiếm đoạt kỳ lạ của quy tắc 80-20; nói chung, mục đích ở đây là chỉ ra rằng hầu hết mã của bạn đã được kiểm tra. (Có, 51% cũng sẽ là "nhất", nhưng 80% phản ánh rõ hơn về ý nghĩa của hầu hết mọi người .) Điều này phù hợp với các trường hợp ở giữa, nơi "được kiểm tra tốt" không phải là ưu tiên cao (bạn không ' không muốn lãng phí nỗ lực vào các bài kiểm tra giá trị thấp), nhưng đủ ưu tiên mà bạn vẫn muốn có một số tiêu chuẩn tại chỗ.

Tôi đã không nhìn thấy những con số dưới 80% trong thực tế và có một thời gian khó tưởng tượng ra một trường hợp mà người ta sẽ đặt chúng. Vai trò của các tiêu chuẩn này là tăng độ tin cậy về tính chính xác và con số dưới 80% không đặc biệt truyền cảm hứng cho sự tự tin. (Vâng, điều này là chủ quan, nhưng một lần nữa, ý tưởng là đưa ra lựa chọn chủ quan một lần khi bạn đặt tiêu chuẩn, và sau đó sử dụng phép đo khách quan trong tương lai.)

Ghi chú khác

Những điều trên cho rằng sự đúng đắn là mục tiêu. Mã bảo hiểm chỉ là thông tin; nó có thể liên quan đến các mục tiêu khác Ví dụ, nếu bạn lo lắng về khả năng bảo trì, bạn có thể quan tâm đến khớp nối lỏng lẻo, có thể được chứng minh bằng khả năng kiểm tra, từ đó có thể được đo lường (trong thời trang nhất định) bằng phạm vi bảo hiểm mã. Vì vậy, tiêu chuẩn bảo hiểm mã của bạn cung cấp một cơ sở thực nghiệm để tính gần đúng chất lượng của "khả năng bảo trì".

Bảo hiểm mã yêu thích của tôi là 100% với dấu hoa thị. Dấu hoa thị xuất hiện bởi vì tôi thích sử dụng các công cụ cho phép tôi đánh dấu các dòng nhất định là các dòng "không được tính". Nếu tôi đã bao gồm 100% các dòng "tính", tôi đã hoàn thành.

Quá trình cơ bản là:

1. Tôi viết các bài kiểm tra của mình để thực hiện tất cả các chức năng và các trường hợp cạnh mà tôi có thể nghĩ đến (thường làm việc từ tài liệu này).
2. Tôi chạy các công cụ bao phủ mã
3. Tôi kiểm tra bất kỳ dòng hoặc đường dẫn nào không được bảo hiểm và bất kỳ đường nào tôi cho là không quan trọng hoặc không thể truy cập (do lập trình phòng thủ) tôi đánh dấu là không tính
4. Tôi viết các bài kiểm tra mới để bao gồm các dòng còn thiếu và cải thiện tài liệu nếu các trường hợp cạnh đó không được đề cập.

Bằng cách này nếu tôi và cộng tác viên của mình thêm mã mới hoặc thay đổi các bài kiểm tra trong tương lai, sẽ có một dòng sáng để cho chúng tôi biết nếu chúng tôi bỏ lỡ điều gì quan trọng - phạm vi bảo hiểm giảm xuống dưới 100%. Tuy nhiên, nó cũng cung cấp sự linh hoạt để đối phó với các ưu tiên thử nghiệm khác nhau.

Tôi có một mật mã khác trong phạm vi kiểm tra mà tôi muốn chia sẻ.

Chúng tôi có một dự án lớn trong đó, qua twitter, tôi lưu ý rằng, với 700 bài kiểm tra đơn vị, chúng tôi chỉ có độ bao phủ mã 20% .

Scott Hanselman trả lời bằng những lời khôn ngoan :

Có phải là QUYỀN 20%? Đây có phải là 20% đại diện cho mã mà người dùng của bạn đạt được nhiều nhất không? Bạn có thể thêm 50 bài kiểm tra nữa và chỉ thêm 2%.

Một lần nữa, nó trở lại Testivus của tôi về Trả lời Bảo hiểm Mã . Bạn nên cho bao nhiêu gạo vào nồi? Nó phụ thuộc.

Đối với một hệ thống được thiết kế tốt, trong đó các bài kiểm tra đơn vị đã thúc đẩy sự phát triển ngay từ đầu tôi sẽ nói 85% là một con số khá thấp. Các lớp nhỏ được thiết kế để có thể kiểm tra không nên khó bao quát hơn thế.

Thật dễ dàng để loại bỏ câu hỏi này với một cái gì đó như:

• Các dòng được bao phủ không bằng logic đã được kiểm tra và người ta không nên đọc quá nhiều vào tỷ lệ phần trăm.

Đúng, nhưng có một số điểm quan trọng cần thực hiện về phạm vi bảo hiểm mã. Theo kinh nghiệm của tôi, số liệu này thực sự khá hữu ích, khi được sử dụng một cách chính xác. Phải nói rằng, tôi chưa thấy tất cả các hệ thống và tôi chắc chắn có rất nhiều trong số chúng khó thấy phân tích bảo hiểm mã bổ sung bất kỳ giá trị thực nào. Mã có thể trông rất khác nhau và phạm vi của khung kiểm tra có sẵn có thể khác nhau.

Ngoài ra, lý luận của tôi chủ yếu liên quan đến các vòng phản hồi thử nghiệm khá ngắn. Đối với sản phẩm tôi đang phát triển vòng phản hồi ngắn nhất khá linh hoạt, bao gồm mọi thứ, từ kiểm tra lớp đến báo hiệu quá trình. Việc kiểm tra một sản phẩm phụ có thể phân phối thường mất 5 phút và đối với vòng phản hồi ngắn như vậy, thực sự có thể sử dụng kết quả kiểm tra (và cụ thể là số liệu bảo hiểm mã mà chúng tôi đang xem xét ở đây) để từ chối hoặc chấp nhận các cam kết trong kho lưu trữ.

Khi sử dụng số liệu bảo hiểm mã, bạn không nên chỉ có một tỷ lệ phần trăm cố định (tùy ý) phải được đáp ứng.Làm điều này không mang lại cho bạn những lợi ích thực sự của phân tích bảo hiểm mã theo quan điểm của tôi. Thay vào đó, hãy xác định các số liệu sau:

• Low Water Mark (LWM), số lượng dòng chưa phát hiện thấp nhất từng thấy trong hệ thống được thử nghiệm
• High Water Mark (HWM), tỷ lệ bao phủ mã cao nhất từng thấy cho hệ thống đang được thử nghiệm

Mã mới chỉ có thể được thêm vào nếu chúng tôi không vượt lên trên LWM và chúng tôi không đi dưới CTNH. Nói cách khác, phạm vi bảo hiểm là không được phép giảm và mã mới phải được bảo hiểm. Lưu ý cách tôi nói nên và không phải (giải thích bên dưới).

Nhưng điều này không có nghĩa là sẽ không thể dọn sạch rác cũ đã được kiểm nghiệm tốt mà bạn không còn sử dụng nữa? Vâng, và đó là lý do tại sao bạn phải thực dụng về những điều này. Có những tình huống khi các quy tắc phải bị phá vỡ, nhưng đối với sự tích hợp hàng ngày điển hình của bạn, kinh nghiệm của tôi cho rằng các số liệu này khá hữu ích. Họ đưa ra hai hàm ý sau.

• Mã thử nghiệm được quảng bá. Khi thêm mã mới, bạn thực sự phải nỗ lực để làm cho mã có thể kiểm tra được, bởi vì bạn sẽ phải thử và bao gồm tất cả mã đó với các trường hợp thử nghiệm của bạn. Mã thử nghiệm thường là một điều tốt.

• Kiểm tra bảo hiểm cho mã di sản đang tăng theo thời gian. Khi thêm mã mới và không thể bao phủ nó bằng một trường hợp thử nghiệm, người ta có thể cố gắng bao gồm một số mã kế thừa để thay đổi quy tắc LWM. Việc gian lận đôi khi cần thiết này ít nhất mang lại hiệu quả tích cực rằng độ bao phủ của mã kế thừa sẽ tăng theo thời gian, khiến việc thực thi các quy tắc này có vẻ nghiêm ngặt trong thực tế.

Và một lần nữa, nếu vòng phản hồi quá dài, có thể hoàn toàn không thực tế để thiết lập một cái gì đó như thế này trong quá trình tích hợp.

Tôi cũng muốn đề cập đến hai lợi ích chung hơn của số liệu bảo hiểm mã.

• Phân tích bảo hiểm mã là một phần của phân tích mã động (trái ngược với phân tích tĩnh, tức là Lint). Các vấn đề được tìm thấy trong quá trình phân tích mã động (bởi các công cụ như họ thanh lọc, http://www-03.ibm.com/software/products/en/rational-purify-f Family ) là những thứ như đọc bộ nhớ chưa được khởi tạo (UMR), rò rỉ bộ nhớ, vv Những vấn đề này chỉ có thể được tìm thấy nếu mã được bao phủ bởi một trường hợp thử nghiệm được thực thi . Mã khó bảo vệ nhất trong trường hợp kiểm tra thường là các trường hợp bất thường trong hệ thống, nhưng nếu bạn muốn hệ thống không hoạt động một cách duyên dáng (ví dụ như theo dõi lỗi thay vì sự cố), bạn có thể muốn thực hiện một số nỗ lực để bao gồm các trường hợp bất thường trong phân tích mã động là tốt. Chỉ cần một chút xui xẻo, UMR có thể dẫn đến một vụ đột nhập hoặc tệ hơn.

• Mọi người tự hào giữ 100% cho mã mới và mọi người thảo luận về các vấn đề thử nghiệm với niềm đam mê tương tự như các vấn đề triển khai khác. Làm thế nào chức năng này có thể được viết theo cách dễ kiểm chứng hơn? Làm thế nào bạn sẽ đi về cố gắng bao gồm trường hợp bất thường này, vv

Và một tiêu cực, cho sự hoàn chỉnh.

• Trong một dự án lớn có nhiều nhà phát triển tham gia, chắc chắn mọi người sẽ không phải là một thiên tài thử nghiệm. Một số người có xu hướng sử dụng số liệu bảo hiểm mã làm bằng chứng cho thấy mã được kiểm tra và điều này rất xa sự thật , như đã đề cập trong nhiều câu trả lời khác cho câu hỏi này. Đó là MỘT số liệu có thể cung cấp cho bạn một số lợi ích tốt đẹp nếu được sử dụng đúng cách, nhưng nếu sử dụng sai nó thực tế có thể dẫn đến thử nghiệm xấu. Ngoài các tác dụng phụ rất có giá trị được đề cập ở trên, một dòng được bảo hiểm chỉ cho thấy hệ thống được thử nghiệm có thể đạt đến dòng đó đối với một số dữ liệu đầu vào và nó có thể thực thi mà không bị treo hoặc gặp sự cố.

Nếu đây là một thế giới hoàn hảo, 100% mã sẽ được bao phủ bởi các bài kiểm tra đơn vị. Tuy nhiên, vì đây KHÔNG phải là một thế giới hoàn hảo, nên bạn có thời gian để làm gì. Do đó, tôi khuyên bạn nên tập trung ít hơn vào một tỷ lệ phần trăm cụ thể và tập trung nhiều hơn vào các lĩnh vực quan trọng. Nếu mã của bạn được viết tốt (hoặc ít nhất là một bản fax hợp lý), sẽ có một số điểm chính mà API được tiếp xúc với mã khác.

Tập trung nỗ lực thử nghiệm của bạn vào các API này. Đảm bảo rằng các API là 1) được ghi chép tốt và 2) có các trường hợp thử nghiệm được viết phù hợp với tài liệu. Nếu kết quả dự kiến ​​không khớp với tài liệu, thì bạn có lỗi trong mã, tài liệu hoặc trường hợp kiểm tra. Tất cả đều tốt để bác sĩ thú y.

Chúc may mắn!

Nhiều cửa hàng không đánh giá các bài kiểm tra, vì vậy nếu bạn ở trên 0 thì ít nhất cũng có một số đánh giá cao về giá trị - vì vậy, có thể nói là không khác không phải là xấu vì nhiều người vẫn bằng không.

Trong thế giới .Net, mọi người thường trích dẫn 80% là hợp lý. Nhưng họ nói điều này ở cấp độ giải pháp. Tôi thích đo lường ở cấp dự án: 30% có thể tốt cho dự án UI nếu bạn đã sử dụng Selenium, v.v. hoặc kiểm tra thủ công, 20% cho dự án lớp dữ liệu có thể tốt, nhưng 95% + có thể đạt được cho doanh nghiệp lớp quy tắc, nếu không hoàn toàn cần thiết. Vì vậy, mức độ bao phủ tổng thể có thể là 60%, nhưng logic kinh doanh quan trọng có thể cao hơn nhiều.

Tôi cũng đã nghe điều này: khao khát 100% và bạn sẽ đạt 80%; nhưng khao khát đến 80% và bạn sẽ đạt 40%.

Dòng dưới cùng: Áp dụng quy tắc 80:20 và để số lỗi của ứng dụng hướng dẫn bạn.

Mã bảo hiểm chỉ là một số liệu khác. Nói chung, nó có thể rất dễ gây hiểu lầm (xem www . Dùtworks.com/insights/blog/are-test-coverage-metrics-overrated ). Do đó, mục tiêu của bạn không phải là đạt được phạm vi bảo hiểm 100% mà là để đảm bảo rằng bạn kiểm tra tất cả các kịch bản có liên quan của ứng dụng của mình.

85% sẽ là nơi khởi đầu tốt cho các tiêu chí đăng ký.

Có lẽ tôi đã chọn nhiều thanh cao hơn cho tiêu chí vận chuyển - tùy thuộc vào mức độ quan trọng của các hệ thống / thành phần con đang được thử nghiệm.

Tôi sử dụng cobertura và bất kể tỷ lệ phần trăm là bao nhiêu, tôi khuyên bạn nên giữ các giá trị trong nhiệm vụ kiểm tra cobertura cập nhật. Tối thiểu, tiếp tục nâng totallinerate và Totalbranchrate xuống ngay dưới mức bảo hiểm hiện tại của bạn, nhưng không bao giờ hạ thấp các giá trị đó. Cũng buộc trong tài sản thất bại xây dựng Ant cho nhiệm vụ này. Nếu quá trình xây dựng thất bại vì thiếu phạm vi bảo hiểm, bạn biết mã được thêm vào của ai đó nhưng chưa kiểm tra nó. Thí dụ:

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />

Khi tôi nghĩ rằng mã của tôi không phải là đơn vị được kiểm tra đủ và tôi không chắc chắn nên thử nghiệm gì tiếp theo, tôi sử dụng phạm vi bảo hiểm để giúp tôi quyết định thử nghiệm gì tiếp theo.

Nếu tôi tăng phạm vi bảo hiểm trong một bài kiểm tra đơn vị - tôi biết bài kiểm tra đơn vị này có giá trị gì đó.

Điều này áp dụng cho mã không được bảo hiểm, được bảo hiểm 50% hoặc được bảo hiểm 97%.

Tôi thích làm BDD, trong đó sử dụng kết hợp các thử nghiệm chấp nhận tự động, có thể là các thử nghiệm tích hợp khác và thử nghiệm đơn vị. Câu hỏi đối với tôi là phạm vi bảo hiểm mục tiêu của bộ kiểm tra tự động nói chung là gì.

Ngoài ra, câu trả lời phụ thuộc vào phương pháp, ngôn ngữ và các công cụ kiểm tra và bảo hiểm của bạn. Khi thực hiện TDD trong Ruby hoặc Python, không khó để duy trì phạm vi bảo hiểm 100% và rất đáng để làm điều đó. Quản lý bảo hiểm 100% dễ dàng hơn nhiều so với bảo hiểm 90 phần trăm.Đó là, việc lấp đầy các khoảng trống bảo hiểm sẽ dễ dàng hơn nhiều khi chúng xuất hiện (và khi thực hiện các khoảng trống bảo hiểm tốt TDD rất hiếm và thường đáng để bạn dành thời gian) hơn là quản lý danh sách các khoảng trống bảo hiểm mà bạn đã mắc phải và bỏ lỡ phạm vi bảo hiểm hồi quy do nền liên tục của mã không được phát hiện.

Câu trả lời cũng phụ thuộc vào lịch sử dự án của bạn. Tôi chỉ thấy những điều trên là thiết thực trong các dự án được quản lý theo cách đó ngay từ đầu. Tôi đã cải thiện đáng kể mức độ bao phủ của các dự án lớn, và nó đáng để làm như vậy, nhưng tôi chưa bao giờ thấy nó thực tế để quay lại và lấp đầy mọi khoảng trống bảo hiểm, bởi vì mã chưa được kiểm tra cũ không đủ hiểu để làm đúng và Mau.

Nếu bạn đã thực hiện kiểm tra đơn vị trong một khoảng thời gian hợp lý, tôi thấy không có lý do gì để nó không đạt gần 95% +. Tuy nhiên, ở mức tối thiểu, tôi luôn làm việc với 80%, ngay cả khi mới thử nghiệm.

Số này chỉ nên bao gồm mã được viết trong dự án (không bao gồm khung, plugin, v.v.) và thậm chí có thể loại trừ một số lớp nhất định bao gồm toàn bộ mã được viết từ các cuộc gọi đến mã bên ngoài. Loại cuộc gọi này nên được chế giễu / sơ khai.

Nói chung, từ một số tài liệu thực hành tốt nhất về kỹ thuật mà tôi đã đọc, 80% cho mã mới trong các bài kiểm tra đơn vị là điểm mang lại lợi nhuận tốt nhất. Đi lên trên CC% đó mang lại một lượng khiếm khuyết thấp hơn cho số lượng nỗ lực. Đây là một thực tiễn tốt nhất được sử dụng bởi nhiều tập đoàn lớn.

Thật không may, hầu hết các kết quả này là nội bộ cho các công ty, vì vậy không có tài liệu công khai mà tôi có thể chỉ cho bạn.

Bảo hiểm mã là tuyệt vời nhưng chỉ miễn là lợi ích mà bạn nhận được từ nó lớn hơn chi phí / nỗ lực để đạt được nó.

Chúng tôi đã làm việc với tiêu chuẩn 80% trong một thời gian, tuy nhiên chúng tôi vừa đưa ra quyết định từ bỏ điều này và thay vào đó tập trung hơn vào thử nghiệm của chúng tôi. Tập trung vào logic kinh doanh phức tạp, vv

Quyết định này được đưa ra do lượng thời gian chúng tôi dành để theo đuổi bảo hiểm mã ngày càng tăng và duy trì các bài kiểm tra đơn vị hiện có. Chúng tôi cảm thấy rằng chúng tôi đã đạt đến mức lợi ích mà chúng tôi nhận được từ phạm vi bảo hiểm mã của chúng tôi được coi là ít hơn so với nỗ lực mà chúng tôi phải bỏ ra để đạt được nó.

Câu trả lời ngắn: 60-80%

Câu trả lời dài: Tôi nghĩ nó hoàn toàn phụ thuộc vào bản chất của dự án của bạn. Tôi thường bắt đầu một dự án bằng cách kiểm tra đơn vị mọi phần thực tế. Trong lần "phát hành" đầu tiên của dự án, bạn sẽ có tỷ lệ phần trăm cơ sở khá tốt dựa trên loại chương trình bạn đang làm. Tại thời điểm đó, bạn có thể bắt đầu "thực thi" phạm vi bảo hiểm mã tối thiểu.

Kiểm tra Crap4j . Đó là một cách tiếp cận phức tạp hơn một chút so với bảo hiểm mã thẳng. Nó kết hợp các phép đo độ bao phủ mã với các phép đo độ phức tạp và sau đó cho bạn thấy mã phức tạp nào hiện chưa được thử nghiệm.

Câu trả lời của tôi cho câu hỏi hóc búa này là có độ bao phủ 100% của mã mà bạn có thể kiểm tra và độ bao phủ 0% của mã mà bạn không thể kiểm tra.

Cách thực hành hiện tại của tôi trong Python là chia các mô-đun .py của tôi thành hai thư mục: app1 / và app2 / và khi chạy thử nghiệm đơn vị tính toán mức độ bao phủ của hai thư mục đó và kiểm tra trực quan (tôi phải tự động hóa một ngày nào đó) rằng app1 có độ phủ 100% và app2 có độ bao phủ 0%.

Khi / nếu tôi thấy rằng những con số này khác với điều tra tiêu chuẩn tôi và thay đổi thiết kế mã để phạm vi bảo hiểm phù hợp với tiêu chuẩn.

Điều này không có nghĩa là tôi có thể khuyên bạn nên đạt được phạm vi bao phủ 100% của mã thư viện.

Thỉnh thoảng tôi cũng xem lại app2 / để xem liệu tôi có thể kiểm tra bất kỳ mã nào ở đó không và nếu tôi có thể chuyển nó vào app1 /

Bây giờ tôi không quá lo lắng về phạm vi bảo hiểm tổng hợp bởi vì điều đó có thể thay đổi tùy theo quy mô của dự án, nhưng nhìn chung tôi đã thấy 70% đến hơn 90%.

Với python, tôi sẽ có thể tạo ra một thử nghiệm khói có thể tự động chạy ứng dụng của mình trong khi đo phạm vi bảo hiểm và hy vọng đạt được tỷ lệ 100% khi kết hợp thử nghiệm khói với các số liệu không đáng tin cậy.

Xem phạm vi bảo hiểm từ góc độ khác: Mã được viết tốt với luồng kiểm soát rõ ràng là dễ che nhất, dễ đọc nhất và thường là mã lỗi ít nhất. Bằng cách viết mã với sự rõ ràng và khả năng bao quát trong tâm trí, và bằng cách viết các bài kiểm tra đơn vị song song với mã, bạn sẽ có được kết quả tốt nhất IMHO.

Theo tôi, câu trả lời là "Nó phụ thuộc vào thời gian bạn có". Tôi cố gắng đạt được 100% nhưng tôi không làm ầm lên nếu tôi không có được nó với thời gian tôi có.

Khi tôi viết bài kiểm tra đơn vị, tôi đội một chiếc mũ khác so với chiếc mũ tôi đội khi phát triển mã sản xuất. Tôi nghĩ về những gì mã được thử nghiệm tuyên bố sẽ làm và những tình huống có thể phá vỡ nó là gì.

Tôi thường tuân theo các tiêu chí hoặc quy tắc sau:

1. Bài kiểm tra đơn vị phải là một dạng tài liệu về hành vi dự kiến ​​của các mã của tôi, nghĩa là. đầu ra dự kiến ​​được cung cấp một đầu vào nhất định và các ngoại lệ mà nó có thể ném ra mà khách hàng có thể muốn nắm bắt (Người dùng mã của tôi nên biết gì?)

2. Bài kiểm tra đơn vị sẽ giúp tôi khám phá điều gì xảy ra nếu điều kiện mà tôi chưa nghĩ đến. (Làm thế nào để làm cho mã của tôi ổn định và mạnh mẽ?)

Nếu hai quy tắc này không tạo ra phạm vi bảo hiểm 100% thì cũng vậy. Nhưng một lần, tôi có thời gian, tôi phân tích các khối và dòng chưa được phát hiện và xác định xem liệu vẫn còn các trường hợp thử nghiệm mà không có kiểm tra đơn vị hay nếu mã cần được cấu trúc lại để loại bỏ các mã không cần thiết.

Nó phụ thuộc rất lớn vào ứng dụng của bạn. Ví dụ: một số ứng dụng bao gồm phần lớn mã GUI không thể được kiểm tra đơn vị.

Tôi không nghĩ có thể có quy tắc B / W như vậy.
Mã cần được xem xét, đặc biệt chú ý đến các chi tiết quan trọng.
Tuy nhiên, nếu nó chưa được thử nghiệm, nó có một lỗi!

Tùy thuộc vào mức độ quan trọng của mã, bất cứ nơi nào từ 75% -85% là một quy tắc tốt. Mã vận chuyển chắc chắn nên được kiểm tra kỹ lưỡng hơn trong các tiện ích trong nhà, v.v.

Điều này phải phụ thuộc vào giai đoạn của vòng đời phát triển ứng dụng của bạn.

Nếu bạn đã phát triển được một thời gian và đã có rất nhiều mã được triển khai và hiện đang nhận ra rằng bạn cần phải suy nghĩ về phạm vi bảo hiểm của mã thì bạn phải kiểm tra phạm vi bảo hiểm hiện tại của mình (nếu nó tồn tại) và sau đó sử dụng đường cơ sở đó để đặt các mốc thời gian mỗi lần chạy nước rút (hoặc tăng trung bình trong một khoảng thời gian chạy nước rút), có nghĩa là nhận nợ mã trong khi tiếp tục cung cấp giá trị người dùng cuối (ít nhất là theo kinh nghiệm của tôi, người dùng cuối không quan tâm một chút nếu bạn đã tăng kiểm tra bảo hiểm nếu họ không thấy các tính năng mới).

Tùy thuộc vào tên miền của bạn, không phải là không hợp lý để bắn 95%, nhưng tôi phải nói rằng trung bình bạn sẽ xem xét một trường hợp trung bình từ 85% đến 90%.

Tôi nghĩ rằng triệu chứng tốt nhất của phạm vi bảo hiểm mã chính xác là số lượng sự cố cụ thể mà các bài kiểm tra đơn vị giúp khắc phục tương đối hợp lý với kích thước của mã kiểm tra đơn vị bạn đã tạo.

Tôi nghĩ rằng điều có thể quan trọng nhất là biết xu hướng bảo hiểm là gì theo thời gian và hiểu lý do cho những thay đổi trong xu hướng. Việc bạn xem những thay đổi trong xu hướng là tốt hay xấu sẽ phụ thuộc vào phân tích lý do của bạn.

Chúng tôi đã nhắm mục tiêu> 80% cho đến vài ngày trước, nhưng sau khi chúng tôi sử dụng rất nhiều Mã được tạo, Chúng tôi không quan tâm đến% tuổi, mà là yêu cầu người đánh giá thực hiện cuộc gọi về phạm vi bảo hiểm được yêu cầu.

Từ bài đăng Testivus tôi nghĩ bối cảnh câu trả lời nên là lập trình viên thứ hai. Đã nói điều này từ quan điểm thực tế, chúng ta cần tham số / mục tiêu để phấn đấu. Tôi cho rằng điều này có thể được "thử nghiệm" trong một quy trình Agile bằng cách phân tích mã chúng tôi có kiến ​​trúc, chức năng (câu chuyện của người dùng) và sau đó đưa ra một con số. Dựa trên kinh nghiệm của tôi trong lĩnh vực Viễn thông, tôi sẽ nói rằng 60% là một giá trị tốt để kiểm tra.