Software Testing Metrics & KPIs

Ngày nay, chất lượng là động lực thúc đẩy tính phổ biến cũng như thành công của một sản phẩm phần mềm. Điều này đã làm tăng đáng kể nhu cầu cần các biện pháp hiệu quả để đảm bảo chất lượng hơn.

Do đó, nhân viên kiểm thử phần mềm đang sử dụng một cách để xác định được mục tiêu và hiệu quả cho công việc của mình. Điều này có thể thực hiện được bằng cách sử dụng các số liệu kiểm thử phần mềm khác nhau và các chỉ số hiệu suất chính (của KPI).

Các số liệu và KPI đóng vai trò quan trọng, giúp xác định các số liệu tính toán hiệu quả của đội ngũ kiểm thử và giúp họ đánh giá chất lượng, hiệu quả, "tiến độ và sức khỏe" của thử nghiệm phần mềm.

Do đó, để giúp bạn đo lường các nỗ lực kiểm thử và quy trình kiểm thử, nhóm chuyên gia của chúng tôi đã tạo danh sách một số chỉ số kiểm thử phần mềm quan trọng cũng như các chỉ số hiệu suất chính dựa trên kinh nghiệm và kiến thức mà họ có.

Các số liệu kiểm tra phần mềm cơ bản:

Các số liệu kiểm thử phần mềm, còn được gọi là đo kiểm thử phần mềm, cho biết mức độ, số lượng, kích thước, công suất, cũng như sự gia tăng của các thuộc tính khác nhau của quy trình phần mềm và cố gắng cải thiện ảnh hưởng và hiệu quả của nó ngay lập tức.

Số liệu kiểm thử phần mềm là cách tốt nhất để đo lường và giám sát các hoạt động kiểm thử khác nhau được thực hiện bởi nhóm người kiểm thử trong vòng đời kiểm thử phần mềm.

Hơn nữa, nó giúp truyền đạt kết quả của một dự đoán liên quan đến sự kết hợp của dữ liệu. Do đó, các số liệu kiểm thử phần mềm khác nhau được sử dụng bởi các kỹ sư phần mềm trên khắp thế giới là:

1. Derivative Metrics (Các số liệu chuyển hóa):

Các số liệu chuyển hóa giúp xác định các vùng khác nhau có vấn đề trong quy trình kiểm thử phần mềm và cho phép nhóm thực hiện các bước hiệu quả giúp tăng độ chính xác của kiểm thử.

2. Defect Density (Mật độ lỗi):

Một số liệu kiểm thử phần mềm quan trọng khác, mật độ lỗi giúp nhóm xác định tổng số lỗi được tìm thấy trong một phần mềm trong một khoảng thời gian cụ thể của hoạt động hoặc phát triển.

Các kết quả sau đó được chia cho kích thước của mô-đun cụ thể đó, cho phép nhóm quyết định liệu phần mềm đã sẵn sàng để phát hành hay chưa hoặc cần kiểm thử thêm hay không.

Mật độ lỗi của một phần mềm được tính trên một nghìn dòng code, còn được gọi là KLOC. Công thức được sử dụng cho việc này là:

Mật độ lỗi = Số lượng lỗi / Kích thước của bản phát hành hoặc Mô-đun

3. Defect Leakage (Rò rỉ lỗi):

Một số liệu quan trọng cần được đo bởi đội ngũ kiểm thử là rò rỉ lỗi. Rò rỉ lỗi được sử dụng bởi những người kiểm thử phần mềm để xem xét hiệu quả của quá trình kiểm thử trước khi thực hiện kiểm thử chấp nhận người dùng (UAT) của sản phẩm.

Nếu bất kỳ lỗi nào được phát hiện bởi nhóm và người dùng tìm thấy, nó được gọi là rò rỉ lỗi.

Rò rỉ lỗi = (Tổng số lỗi được tìm thấy trong UAT / Tổng số lỗi được tìm thấy trước UAT) x 100

4. Defect Removal Efficiency (Hiệu quả loại bỏ lỗi):

Hiệu quả loại bỏ lỗi (DRE) cung cấp thước đo khả năng của nhóm phát triển để loại bỏ các lỗi khác nhau khỏi phần mềm, trước khi phát hành hoặc triển khai.

Được tính toán trong và trên các giai đoạn kiểm thử, DRE được đo trên mỗi loại kiểm thử và cho biết hiệu quả của nhiều phương pháp loại bỏ lỗi được nhóm kiểm thử áp dụng.

Ngoài ra, nó là một phép đo gián tiếp về chất lượng cũng như hiệu suất của phần mềm. Do đó, công thức để tính toán Hiệu quả Loại bỏ Khiếm khuyết là:

DRE = Số lỗi được giải quyết bởi nhóm phát triển / (Tổng số lỗi tại thời điểm đo)

5. Defect Category (Phân loại lỗi):

Đây là một loại số liệu quan trọng được đánh giá trong vòng đời phát triển phần mềm (SDLC).

Số liệu về loại lỗi cung cấp cái nhìn sâu sắc về các thuộc tính chất lượng khác nhau của phần mềm, chẳng hạn như tính khả dụng, hiệu suất, chức năng, tính ổn định, độ tin cậy và hơn thế nữa.

Nói tóm lại, phân loại lỗi là một thuộc tính của lỗi liên quan đến các thuộc tính chất lượng của sản phẩm phần mềm và được đo lường với sự hỗ trợ của công thức sau:

Loại lỗi = Lỗi thuộc về một danh mục cụ thể / Tổng số lỗi.

6. Defect Severity Index (Chỉ số mức độ nghiêm trọng của lỗi):

Đây là mức độ ảnh hưởng của lỗi đối với sự phát triển của một hoạt động hoặc một thành phần của ứng dụng phần mềm đang được kiểm thử.

Chỉ số mức độ nghiêm trọng của lỗi (DSI) cung cấp cái nhìn sâu sắc về chất lượng sản phẩm được kiểm thử và giúp đánh giá chất lượng kiểm thử.

Ngoài ra, với sự hỗ trợ của số liệu này, nhóm có thể đánh giá mức độ ảnh hưởng tiêu cực đến chất lượng cũng như hiệu suất của phần mềm. Công thức sau đây được sử dụng để đo chỉ số mức độ nghiêm trọng của lỗi.

Chỉ số mức độ nghiêm trọng của lỗi (DSI) = Tổng của (Lỗi * Mức độ nghiêm trọng) / Tổng số lỗi

7. Review Efficiency (Hiệu quả của đánh giá lại):

Hiệu quả của đánh giá lại là một số liệu được sử dụng để giảm các khiếm khuyết trước khi chuyển giao sản phẩm phần mềm. Xem xét lỗi có thể được tìm thấy trong các tài liệu. Bằng cách thực hiện số liệu này, người ta sẽ giảm chi phí cũng như những nỗ lực làm việc trong quá trình khắc phục lỗi.

Hơn nữa, nó giúp giảm xác suất rò rỉ lỗi trong các giai đoạn kiểm thử tiếp theo và xác nhận tính hiệu quả của trường hợp kiểm thử.

Công thức tính hiệu quả của việc xem lại là:

Hiệu quả đánh giá (RE) = Tổng số lỗi đánh giá / (Tổng số lỗi đánh giá + Tổng số lỗi trong quá trình kiểm thử) x 100

8. Test Case Effectiveness (Tính hiệu quả của Test Case):

Mục tiêu của số liệu này là để biết hiệu quả của các trường hợp kiểm thử được thực hiện bởi nhóm kiểm thử trong mỗi giai đoạn. Nó giúp xác định chất lượng của các trường hợp kiểm thử.

Tính hiệu quả của Test Case = (Số lỗi được phát hiện / Tổng số Test case thực hiện kiểm thử) x 100

9. Test Case Productivity (Năng suất của Test Case):

Số liệu này được sử dụng để đo lường và tính toán số lượng Test Case được chuẩn bị bởi nhóm kiểm thử và những nỗ lực mà họ đã đầu tư trong suốt quá trình kiểm thử. Nó được sử dụng để xác định năng suất thiết kế test case và được sử dụng làm đầu vào cho việc đo lường và ước tính trong tương lai.

Điều này thường được đo với sự hỗ trợ của công thức sau:

Năng suất của Test Case = (Số lượng Test Case / Nỗ lực dành cho việc chuẩn bị Test Case)

10. Phạm vi kiểm thử:

Phạm vi kiểm thử là một số liệu quan trọng khác xác định mức độ chức năng hoàn thành của sản phẩm phần mềm. Nó chỉ ra việc hoàn thành các hoạt động kiểm thử và có thể được sử dụng làm tiêu chí để kết thúc kiểm thử. Nó có thể được đo bằng công thức sau:

Phạm vi kiểm tra = Số lỗi được phát hiện / Số lỗi dự đoán

Một công thức quan trọng khác được sử dụng khi tính toán số liệu này là:

Phạm vi yêu cầu = (Số lượng yêu cầu được bao trùm / Tổng số yêu cầu) x 100

11. Test Design Coverage:

Cũng giống với Test Coverage, Test Design Coverage đo lường tỷ lệ test case che phủ số yêu cầu.

Công thức:

Test Design Coverage = (Số lượng requirement map với test case / Tổng số requirements) x 100

12. Test Execution Coverage:

Giúp ta có cái nhìn về tổng số test case đã thực hiện cũng như tổng số test case bị tạm dừng. Số liệu này quyết định độ bao phủ của kiểm thử và được đo trong suốt quá trình thực hiện kiểm thử với sự trợ giúp của công thức dưới đây:

Test Execution Coverage = (Tổng số test case đã thực hiện / Tổng số test case dự định kiểm thử) x 100

(còn nữa)

Nguồn dịch: https://www.thinksys.com/qa-testing/software-testing-metrics-kpis/