Số liệu kiểm thử phần mềm: Là gì, loại và ví dụ
Thomas Hamilton
⚡ Tóm tắt thông minh
Các chỉ số kiểm thử phần mềm là thước đo định lượng về tiến độ, chất lượng và năng suất của quy trình kiểm thử. Hướng dẫn này bao gồm ba loại chỉ số, sự khác biệt giữa chỉ số cơ bản và chỉ số được tính toán, vòng đời của chỉ số và bảng thuật ngữ công thức mà bạn có thể áp dụng trực tiếp.
Các chỉ số đo lường kiểm thử phần mềm là gì?
Số liệu kiểm thử phần mềm là các thước đo định lượng được sử dụng để ước tính tiến độ, chất lượng, năng suất và sức khỏe của quá trình kiểm thử phần mềm. Mục tiêu của các số liệu kiểm thử phần mềm là nâng cao hiệu suất và hiệu suất trong quy trình kiểm thử phần mềm và giúp đưa ra quyết định tốt hơn cho quá trình kiểm thử tiếp theo bằng cách cung cấp dữ liệu đáng tin cậy về quy trình kiểm thử.
Chỉ số đo lường thể hiện, bằng định lượng, mức độ mà một hệ thống, một thành phần hoặc một quy trình sở hữu một thuộc tính nhất định. Một ví dụ đơn giản là mức tiêu thụ nhiên liệu thực tế hàng tuần của một chiếc ô tô so với con số mà nhà sản xuất công bố.
Số liệu kiểm thử phần mềm - Cải thiện hiệu suất và hiệu quả của quy trình kiểm thử phần mềm.
Số liệu kiểm thử phần mềm hoặc phép đo kiểm thử phần mềm là dấu hiệu định lượng về mức độ, công suất, kích thước, số lượng hoặc kích thước của một số thuộc tính của một quy trình hoặc sản phẩm.
Ví dụ về đo lường kiểm thử phần mềm: Tổng số lỗi
Tại sao các chỉ số kiểm thử lại quan trọng?
“Chúng ta không thể cải thiện những gì chúng ta không thể đo lường.” Các chỉ số kiểm thử tồn tại để giúp quá trình kiểm thử có thể đo lường được.
- Hãy quyết định giai đoạn hoạt động tiếp theo nên là gì.
- Cung cấp bằng chứng cho một tuyên bố hoặc dự đoán về chất lượng.
- Xác định loại cải tiến nào cần thiết.
- Hãy chứng minh sự cần thiết của việc thay đổi quy trình hoặc công nghệ.
Đọc thêm về nó Tầm quan trọng của số liệu kiểm tra
Các loại số liệu kiểm tra
- Số liệu quy trình: Nó có thể được sử dụng để cải thiện hiệu quả quá trình của SDLC (Chu trình phát triển phần mềm)
- Số liệu sản phẩm: Nó liên quan đến chất lượng của sản phẩm phần mềm
-
Chỉ số dự án: Nó có thể được sử dụng để đo lường hiệu quả của một nhóm dự án hoặc bất kỳ công cụ kiểm tra đang được các thành viên trong nhóm sử dụng
Việc lựa chọn các chỉ số đo lường phù hợp quan trọng hơn việc thu thập nhiều chỉ số. Hãy cân nhắc những điều sau đây trước khi quyết định chọn một bộ chỉ số:
- Cố định đối tượng mục tiêu để chuẩn bị số liệu
- Xác định mục tiêu cho các chỉ số
- Giới thiệu tất cả các số liệu liên quan dựa trên nhu cầu của dự án
- Cân nhắc chi phí và lợi ích của từng chỉ số, cũng như giai đoạn nào trong vòng đời dự án mà chỉ số đó mang lại giá trị cao nhất.
Số liệu kiểm tra thủ công
In Kỹ thuật phần mềm, Số liệu kiểm tra thủ công được phân thành hai lớp
- Chỉ số cơ sở
- Các chỉ số được tính toán
Số liệu cơ sở là dữ liệu thô được Nhà phân tích kiểm thử thu thập trong quá trình phát triển và thực hiện trường hợp kiểm thử (Số ca kiểm thử được thực hiện, số ca kiểm thử). Trong khi các số liệu được tính toán được lấy từ dữ liệu được thu thập trong các số liệu cơ sở. Các số liệu được tính toán thường được người quản lý kiểm tra tuân theo nhằm mục đích báo cáo kiểm tra (% Hoàn thành, % Phạm vi kiểm tra).
Tùy thuộc vào dự án hoặc mô hình kinh doanh, các chỉ số quan trọng nhất thường là:
- Chỉ số năng suất thực hiện trường hợp thử nghiệm
- Chỉ số năng suất chuẩn bị ca kiểm thử
- Số liệu lỗi
- Khiếm khuyết theo mức độ ưu tiên
- Khiếm khuyết theo mức độ nghiêm trọng
- Tỷ lệ trượt khuyết tật
So sánh số liệu kiểm thử thủ công và tự động
Các chỉ số được mô tả ở trên giả định một bộ kiểm thử được thực thi thủ công. Một bộ kiểm thử tự động được đo lường theo cách khác, bởi vì nỗ lực thực thi không còn là yếu tố hạn chế nữa.
| Tiêu chí | Số liệu kiểm thử thủ công | Số liệu kiểm thử tự động |
|---|---|---|
| Tiêu điểm chính | Nỗ lực và tiến độ thực hiện | Phạm vi phủ sóng, độ ổn định và thời gian hoạt động |
| Biện pháp điển hình | Số lượng vụ kiểm thử được thực thi mỗi ngày | Tỷ lệ bao phủ tự động hóa |
| Tín hiệu chất lượng | Số lỗi được phát hiện mỗi giờ kiểm tra | Tỷ lệ kiểm thử không ổn định, tỷ lệ các bài kiểm thử không ổn định |
| Biện pháp chi phí | Giờ thử nghiệm | Số giờ bảo trì kịch bản cho mỗi lần phát hành |
| Đo tốc độ | Chu kỳ kinh nguyệt (ngày) | Thời gian thực thi bộ kiểm thử (phút) |
Automation Coverage = (Test cases automated / Total test cases) x 100 Flaky Test Rate = (Tests with inconsistent results / Total automated tests) x 100
Tỷ lệ kiểm thử không ổn định cần được đặc biệt chú ý. Khi tỷ lệ này vượt quá khoảng 5%, các nhóm bắt đầu bỏ qua các bản dựng lỗi (red build), và tại thời điểm đó, bộ kiểm thử sẽ ngừng cung cấp thông tin bất kể độ bao phủ của nó cao đến mức nào.
Vòng đời đo lường thử nghiệm trong Kỹ thuật phần mềm
| Các giai đoạn khác nhau của vòng đời Số liệu | Các bước trong mỗi giai đoạn |
|---|---|
| nghiên cứu |
|
| Giao tiếp |
|
| Đánh giá |
|
| Report |
|
Cách tính toán chỉ số kiểm thử
| Sr # | Các bước để kiểm tra số liệu | Ví dụ |
|---|---|---|
| 1 | Xác định chìa khóa kiểm thử phần mềm các quá trình được đo lường | Tiến độ thử nghiệm tracquy trình vua |
| 2 | Trong Bước này, người kiểm tra sử dụng dữ liệu làm cơ sở để xác định số liệu | Số lượng ca kiểm thử dự kiến thực hiện mỗi ngày |
| 3 | Xác định thông tin cần theo dõi, tần suất của tracnhà vua và người chịu trách nhiệm | Việc thực hiện kiểm thử thực tế mỗi ngày sẽ được người quản lý kiểm thử nắm bắt vào cuối ngày |
| 4 | Tính toán, quản lý và giải thích hiệu quả các số liệu đã xác định | Các trường hợp thử nghiệm thực tế được thực hiện mỗi ngày |
| 5 | Xác định các lĩnh vực cần cải thiện tùy thuộc vào việc giải thích các số liệu đã xác định | If trường hợp thử nghiệm Nếu tiến độ thực hiện không đạt mục tiêu đã thỏa thuận, hãy điều tra nguyên nhân và đề xuất các biện pháp khắc phục. |
Ví dụ về cách tính toán chỉ số kiểm thử
Lấy tỷ lệ phần trăm các trường hợp kiểm thử đã được thực thi làm ví dụ. Để thể hiện trạng thái thực thi dưới dạng phần trăm, hãy sử dụng công thức:
Percentage test cases executed= (No of test cases executed/ Total no of test cases written) X 100
Nếu có 250 trường hợp kiểm thử được viết và 175 trường hợp đã được thực thi, thì kết quả là (175 / 250) x 100 = 70%.
Mô hình tương tự áp dụng cho mọi tham số thực thi khác: các trường hợp kiểm thử không được thực thi, đã vượt qua, thất bại và bị chặn. Mỗi trường hợp chỉ đơn giản là một tử số khác nhau trên cùng một mẫu số.
Các chỉ số kiểm thử quan trọng nhất Track
Bảng thuật ngữ ở cuối hướng dẫn này liệt kê tất cả các công thức thường dùng. Trên thực tế, một bộ báo cáo hiếm khi cần nhiều hơn tám công thức. Đây là những công thức luôn chi phối quyết định.
| metric | Câu trả lời cho câu hỏi đó là gì | Xem ra cho |
|---|---|---|
| Tỷ lệ thực thi trường hợp kiểm thử | Chúng ta đã thực hiện được bao nhiêu phần trăm kế hoạch ban đầu rồi? | Không nói gì về chất lượng, chỉ nói về sự tiến bộ. |
| Mật độ khuyết tật | Tính số lỗi trên mỗi đơn vị kích thước, vậy mô-đun nào yếu nhất? | Phụ thuộc vào thước đo kích thước nhất quán. |
| Hiệu quả loại bỏ khuyết tật | Chúng ta đã phát hiện được bao nhiêu lỗi trước khi đưa sản phẩm ra thị trường? | Chỉ có thể hoàn tất sau khi có dữ liệu sản xuất. |
| Rò rỉ do lỗi | Có bao nhiêu sản phẩm lỗi đến tay khách hàng? | Tín hiệu chất lượng quan trọng nhất |
| Phạm vi kiểm tra | Mức độ thực hiện của bộ yêu cầu là bao nhiêu? | Việc đưa tin dày đặc nhưng kèm theo những luận điểm yếu kém không chứng minh được điều gì. |
| Chỉ số mức độ nghiêm trọng của khuyết tật | Các khuyết điểm hở đó là nghiêm trọng hay chỉ mang tính thẩm mỹ? | Việc đếm số lỗi mà không cân nhắc đến trọng lượng sẽ dẫn đến kết quả sai lệch. |
| Thời gian sửa chữa trung bình | Đội ngũ kỹ thuật khắc phục sự cố nhanh đến mức nào? | Bị sai lệch do một vài lỗi kéo dài. |
| Năng suất thực thi kiểm thử | Mỗi người kiểm thử hoàn thành bao nhiêu ca kiểm thử mỗi ngày? | Khuyến khích các thử nghiệm nông nếu được sử dụng làm mục tiêu. |
Hai công thức đáng được bổ sung vào bảng thuật ngữ vì chúng là những công thức mà ban quản lý thường yêu cầu:
Defect Removal Efficiency = (Defects found before release / Total defects found) x 100
Defect Leakage = (Defects found in production / Defects found before release) x 100
Cái bẫy đo lường. Bất kỳ chỉ số nào được sử dụng làm mục tiêu đều không còn là thước đo tốt nữa. Đặt mục tiêu năng suất là 30 trường hợp kiểm thử mỗi ngày, người kiểm thử sẽ chỉ viết 30 trường hợp đơn giản. Hãy báo cáo các chỉ số theo nhóm, không bao giờ riêng lẻ, và ghép mỗi chỉ số năng suất với một chỉ số chất lượng.
Bảng thuật ngữ công thức đo lường kiểm thử phần mềm
- Tỷ lệ nỗ lực làm lại = (Số nỗ lực làm lại thực tế đã tiêu tốn trong giai đoạn đó/tổng số nỗ lực thực tế đã tiêu tốn trong giai đoạn đó) X 100
- Leo yêu cầu = (Tổng số yêu cầu bổ sung/Số yêu cầu ban đầu)X100
- Lịch trình phương sai = (Ngày giao hàng thực tế – Ngày giao hàng dự kiến)
- Chi phí để tìm ra lỗi trong quá trình kiểm thử = (Tổng công sức dành cho việc kiểm thử/các lỗi được tìm thấy trong quá trình kiểm thử)
- Lịch trình trượt = (Ngày kết thúc thực tế – Ngày kết thúc dự kiến) / (Ngày kết thúc theo kế hoạch – Ngày bắt đầu theo kế hoạch) X 100
- Tỷ lệ phần trăm trường hợp thử nghiệm đã vượt qua = (Số lần kiểm tra đạt/Tổng số lần kiểm tra đã thực hiện) X 100
- Tỷ lệ phần trăm trường hợp thử nghiệm thất bại = (Số lần kiểm tra thất bại/Tổng số lần kiểm tra đã thực hiện) X 100
- Tỷ lệ phần trăm trường hợp thử nghiệm bị chặn = (Số lượng bài kiểm tra bị chặn/Tổng số bài kiểm tra đã thực hiện) X 100
- Tỷ lệ phần trăm lỗi đã sửa = (Đã sửa lỗi/Đã báo cáo lỗi) X 100
- Tỷ lệ lỗi được chấp nhận = (Lỗi được nhóm phát triển chấp nhận là hợp lệ/Tổng số lỗi được báo cáo) X 100
- Phần trăm khiếm khuyết hoãn lại = (Các lỗi được hoãn lại cho các bản phát hành trong tương lai /Tổng số lỗi được báo cáo) X 100
- Tỷ lệ lỗi nghiêm trọng = (Khiếm khuyết nghiêm trọng / Tổng số lỗi được báo cáo) X 100
- Thời gian trung bình để nhóm phát triển sửa chữa lỗi = (Tổng thời gian sửa lỗi/Số lỗi)
- Số lượng bài kiểm tra chạy mỗi khoảng thời gian = Số lần chạy thử/Tổng thời gian
- Hiệu quả thiết kế thử nghiệm = Số lượng bài kiểm tra được thiết kế/Tổng thời gian
- Kiểm tra đánh giá hiệu quả = Số bài kiểm tra được xem xét/Tổng thời gian
- Tỷ lệ tìm lỗihoặc số lỗi trên mỗi giờ thử nghiệm = Tổng số lỗi / Tổng số giờ thử nghiệm
