Độ bao phủ kiểm thử trong kiểm thử phần mềm: Cách đo lường nó

Phạm vi kiểm tra là gì?

Phạm vi kiểm thử được định nghĩa là một số liệu trong Kiểm thử phần mềm để đo lường số lượng kiểm thử được thực hiện bởi một bộ kiểm thử. Nó sẽ bao gồm việc thu thập thông tin về phần nào của chương trình được thực thi khi chạy bộ thử nghiệm để xác định nhánh nào của câu lệnh điều kiện đã được thực hiện.

Nói một cách đơn giản, đó là một kỹ thuật để đảm bảo rằng các bài kiểm tra của bạn đang kiểm tra mã của bạn hoặc lượng mã bạn đã sử dụng bằng cách chạy thử nghiệm.

Phạm vi kiểm thử có tác dụng gì?

Trong một dự án thực tế, độ phủ kiểm thử hỗ trợ bốn hoạt động thiết thực:

• Tìm vùng yêu cầu không được thực hiện bởi một tập hợp các trường hợp thử nghiệm
• Giúp tạo các trường hợp thử nghiệm bổ sung để tăng mức độ bao phủ
• Xác định thước đo định lượng về phạm vi kiểm tra, đây là phương pháp gián tiếp để kiểm tra chất lượng
• Xác định các trường hợp thử nghiệm vô nghĩa không làm tăng phạm vi bao phủ

Lợi ích của phạm vi kiểm tra trong Kỹ thuật phần mềm

Những hoạt động đó mang lại những lợi ích kỹ thuật cụ thể.

• Nó có thể đảm bảo chất lượng của bài kiểm tra
• Nó có thể giúp xác định phần nào của mã đã thực sự được chạm vào để phát hành hoặc sửa lỗi
• Nó có thể xác định tất cả các điểm quyết định và đường dẫn trong ứng dụng của bạn chưa được kiểm thử, cho phép bạn tăng phạm vi kiểm thử.
• Ngăn chặn khuyết tật rò rỉ
• Thời gian, phạm vi và chi phí có thể được kiểm soát
• Ngăn ngừa lỗi ở giai đoạn đầu của vòng đời dự án
• Những lỗ hổng trong yêu cầu, trường hợp kiểm thử và lỗi ở cấp đơn vị và cấp mã có thể được tìm thấy một cách dễ dàng

Các loại phạm vi kiểm thử

Phạm vi phủ sóng không bao giờ chỉ là một con số duy nhất. Các đội tracBạn có thể gặp nhiều loại câu hỏi khác nhau cùng một lúc, vì mỗi loại trả lời một câu hỏi khác nhau về cùng một bộ câu hỏi. Bảng dưới đây nhóm các loại câu hỏi bạn thường gặp nhất.

Năm loại đầu tiên là các biện pháp ở cấp độ mã và thuộc về kiểm thử hộp trắngTrong khi đó, các yêu cầu và phạm vi rủi ro nằm ở cấp độ kế hoạch kiểm thử.

Sự khác biệt chính giữa Code Phạm vi phủ sóng và phạm vi kiểm thử?

Code bảo hiểm và phạm vi kiểm tra là các kỹ thuật đo lường cho phép bạn đánh giá chất lượng mã ứng dụng của mình.

Dưới đây là một số khác biệt quan trọng giữa các gian hàng của các phương pháp đưa tin này:

Công thức bao phủ thử nghiệm

Để tính toán phạm vi kiểm thử, bạn cần làm theo các bước dưới đây:

Bước 1) Đếm YTổng số dòng mã trong đoạn phần mềm mà bạn đang sử dụng. thử nghiệm

Bước 2) Đếm X, số dòng mã mà tất cả các trường hợp kiểm thử hiện đang thực thi

Bây giờ, bạn cần tìm (X chia cho Y) nhân với 100. Kết quả của phép tính này là % phạm vi kiểm tra của bạn.

Ví dụ:

Nếu số dòng mã trong một thành phần hệ thống là 500 và số dòng được thực thi trên tất cả các trường hợp kiểm thử hiện có là 50, thì độ phủ kiểm thử của bạn là:

(50 / 500) * 100 = 10%   // executed lines divided by total lines

Ví dụ về phạm vi kiểm tra

Tỷ lệ phần trăm đơn thuần không bao giờ phản ánh toàn bộ câu chuyện, như các ví dụ dưới đây cho thấy.

Ví dụ 1:

Ví dụ, nếu "dao" là một mặt hàng bạn muốn kiểm tra. Thì bạn cần tập trung vào việc kiểm tra xem nó có cắt rau củ quả chính xác hay không. Tuy nhiên, còn có những khía cạnh khác cần xem xét, chẳng hạn như người dùng có thể cầm nắm thoải mái hay không.

Ví dụ 2:

Ví dụ, nếu bạn muốn kiểm tra ứng dụng ghi chú. Việc kiểm tra các tính năng thiết yếu của nó là điều bắt buộc. Tuy nhiên, bạn cần xem xét các khía cạnh khác như ứng dụng ghi chú hoạt động như mong đợi khi sử dụng cùng với các ứng dụng khác, người dùng hiểu cách sử dụng ứng dụng, không bị lỗi khi người dùng cố gắng thực hiện thao tác bất thường, v.v.

Các kỹ thuật kiểm thử độ phủ

Cả hai ví dụ đều chỉ ra cùng một kết luận: đạt được mục tiêu về độ phủ kiểm thử phụ thuộc ít hơn vào việc viết thêm nhiều bài kiểm thử và phụ thuộc nhiều hơn vào việc lựa chọn kỹ thuật thiết kế kiểm thử phù hợp. Các kỹ thuật dưới đây mở rộng độ phủ trong khi vẫn giữ được...ping Căn phòng nhỏ.

• Phân tích giá trị biên: Chọn các đầu vào ở rìa của mỗi phạm vi hợp lệ, nơi các lỗi tập trung nhiều nhất. Xem phân tích giá trị biên đối với các trường hợp đã được xử lý.
• Phân vùng tương đương: Nhóm các giá trị đầu vào mà ứng dụng xử lý giống hệt nhau, do đó một trường hợp duy nhất có thể đại diện an toàn cho toàn bộ một lớp giá trị.
• Kiểm thử bảng quyết định: Bao gồm các tổ hợp điều kiện và kết quả dự kiến ​​của chúng trong một lưới duy nhất.
• Kiểm tra chuyển đổi trạng thái: Thực hiện mọi thao tác hợp lệ và không hợp lệ giữa các trạng thái ứng dụng.
• Kiểm thử đường dẫn cơ bản: Tìm ra tập hợp tối thiểu các đường dẫn độc lập từ đồ thị luồng điều khiển.
• Kiểm tra dựa trên rủi ro: Xếp hạng các tính năng theo tác động đến kinh doanh và ưu tiên xử lý các tính năng có rủi ro cao nhất trước.
• Thử nghiệm thăm dò: Phát hiện ra những lỗ hổng mà các trường hợp được dàn dựng và các báo cáo đưa tin không bao giờ đề cập đến.

Làm thế nào để đạt được độ phủ kiểm thử?

Sau khi lựa chọn các kỹ thuật, bốn tuyến đường đã được thiết lập sẽ cung cấp vùng phủ sóng.

• Phạm vi kiểm tra có thể được thực hiện bằng cách thực hiện các kỹ thuật đánh giá tĩnh như đánh giá ngang hàng, kiểm tra và hướng dẫn
• Bằng cách chuyển đổi các lỗi đặc biệt thành các trường hợp kiểm thử có thể thực thi được
• Ở cấp độ mã hoặc cấp độ kiểm tra đơn vị, phạm vi kiểm tra có thể đạt được bằng cách sử dụng các công cụ bao phủ mã hoặc kiểm tra đơn vị tự động
• Phạm vi kiểm tra chức năng có thể được thực hiện với sự trợ giúp của các công cụ quản lý kiểm tra thích hợp

Cách cải thiện độ bao phủ kiểm thử

Thiết lập độ phủ sóng là bước khởi đầu; nâng cao độ phủ sóng là một quy trình lặp đi lặp lại. Hãy thực hiện trình tự này vào đầu mỗi chu kỳ phát hành.

1. Xác định con số hiện tại là mức cơ sở. Chạy báo cáo độ phủ và ghi lại độ phủ của câu lệnh, nhánh và yêu cầu một cách riêng biệt, để các lỗ hổng vẫn hiển thị rõ ràng cho từng mô-đun thay vì bị che giấu trong mức trung bình toàn dự án.
2. Hãy liên kết các bài kiểm thử với các yêu cầu. Xây dựng một tracBảng khả năng liên kết mọi yêu cầu với ít nhất một trường hợp thử nghiệm. Bất kỳ hàng trống nào đều là dấu hiệu của thiếu sót đã được xác nhận, chứ không phải là nghi ngờ.
3. Xếp hạng các mô-đun theo mức độ rủi ro. Logic thanh toán, xác thực và di chuyển dữ liệu cần được trình bày chi tiết hơn nhiều so với một màn hình trợ giúp tĩnh, vì vậy hãy dành ngân sách cho những phần mà nếu xảy ra lỗi sẽ gây thiệt hại lớn nhất.
4. Thêm các trường hợp tiêu cực và trường hợp ngoại lệ. Các trường nhập liệu trống, giá trị quá lớn, lỗi hết thời gian chờ mạng và lỗi quyền truy cập sẽ ảnh hưởng đến các nhánh mà các bài kiểm tra trong trường hợp bình thường không bao giờ chạm tới.
5. Xếp chồng các lớp kiểm tra. Kết hợp kiểm tra đơn vị, Thử nghiệm hội nhậpvà kiểm tra từ đầu đến cuối, bởi vì mỗi cấp độ bao quát những gì mà các cấp độ khác về mặt cấu trúc không thể bao quát.
6. Tự động hóa bộ kiểm thử hồi quy. Promocác trường hợp ổn định thành kiểm tra tự động hóa và thực thi chúng bên trong Đường ống CI / CD sau mỗi lần commit.
7. Loại bỏ các trường hợp dư thừa. Xóa các bài kiểm tra trùng lặp làm tăng thời gian thực thi mà không thêm bất kỳ dòng nào chưa được kiểm tra.
8. RevTheo dõi xu hướng trong mỗi chu kỳ sprint. Tracphạm vi phủ sóng k bên cạnh Mật độ khuyết tậtHiện tượng rò rỉ ngày càng tăng so với phạm vi phủ sóng phẳng là dấu hiệu cảnh báo sớm về điểm mù.

⚠️ Cảnh báo: Đừng coi 100% là mục tiêu. Một bộ kiểm thử đạt 85% với các khẳng định mạnh mẽ sẽ bảo vệ bản phát hành tốt hơn nhiều so với 95% các kiểm thử hời hợt chỉ thực thi mã mà không xác minh bất kỳ kết quả nào.

Nhược điểm của việc kiểm thử bao phủ

Phạm vi bảo hiểm vẫn có giá trị, nhưng nó có những hạn chế cần được nêu rõ trước khi công bố bất kỳ tỷ lệ phần trăm nào.

• Hầu hết các nhiệm vụ trong phạm vi kiểm thử đều là thủ công vì không có công cụ nào để tự động hóa. Vì vậy, phải mất rất nhiều công sức để phân tích các yêu cầu và tạo ra các trường hợp thử nghiệm.
• Phạm vi kiểm tra cho phép bạn đếm các tính năng và sau đó đo lường dựa trên một số thử nghiệm. Tuy nhiên, luôn có chỗ cho những sai sót trong phán đoán.

Câu Hỏi Thường Gặp