Giá trị của TESTING METRICS Trong Phát Triển Phần Mềm
Bài đăng này đã không được cập nhật trong 2 năm
1.Giới thiệu
1.1.Test metric là gì?
- Là 1 chuẩn đo lường
- Metric phải được xác định căn cứ vào mục tiêu cụ thể cho từng dự án, quy trình, hoặc sản phẩm
- Đánh giá hiệu quả và hiệu năng của một số hoạt động phát triển phần mềm
- Được tập hợp và tính toán trong suốt quá trình test.
- Cung cấp Công thức đo sự thành công của dự án một cách khách quan.
1.2. Tại sao phải sử dụng test metric
Dựa vào Metric để đánh giá được chât lượng của sản phẩm và năng suất của dịch vụ để đạt được sự hài lòng của khách hàng. Metric sẽ cung cấp số liệu để có thể cải tiến quy trình.
Nếu một tổ chức muốn nâng cao mức độ phát triển phần mềm trong lĩnh vực nào, tổ chức đó phải có một quy mô mà theo đó để đo lường chính nó. Tổ chức đó phải biết đang ở đâu, và họ phải biết họ muốn đi tới đâu. Thật đơn giản: Nếu bạn không thể biết bạn đang ở đâu, bạn không thể chứng minh rằng bạn đang được cải thiện.
Khi được sử dụng đúng cách, metric có thể hỗ trợ trong việc cải tiến quá trình phát triển bằng cách cung cấp bằng chứng khách quan về quá trình thay đổi. Metric được định nghĩa là "tiêu chuẩn đo lường" và từ lâu đã được sử dụng trong ngành công nghiệp CNTT để chỉ một phương pháp đánh giá sự hiệu quả và hiệu năng của một hoạt động cụ thể trong một dự án.
Mặc dù test metric được thu thập trong suốt quá trình kiểm thử, test metric có thể cung cấp số đo của nhiều hoạt động khác nhau được thực hiện trong suốt dự án. Cùng với việc phân tích nguyên nhân gốc rễ, test metric có thể được sử dụng để theo dõi các vấn đề phát sinh (issues)trong suốt quá trình phát triển. Ngoài ra, khi test metric được tích lũy, cập nhật và báo cáo trên cơ sở phù hợp và thường xuyên, nó đảm bảo rằng các vấn đề của dự án sẽ được đánh giá đúng, xử lý kịp thời do đó dễ dàng cho việc quản lý
1.3.Vòng đời của test metric
2. Metric Categories:
- Test metric có thể phân loại dựa trên 1 hoặc nhiều loại sau:
- Project metric: đo lường hướng tới đầu ra của dự án như: phần trăm số test case đã test, đã pass, đã fail.
- Product metric: đo lường một vài thuộc tính của sản phầm như: phạm vi đã được test, mật độ bug.
- Process metric: đo khả năng có thể test được hoặc quy trình phát triển như: Phần trăm bug đã phát hiện được trong quá trình test
- People metric: đo lường khả năng của cá nhân hoặc của một nhóm ví dụ như: khả năng thực hiện các test case trong một khoảng thời gian nhất định.
- Các loại test metric phân loại theo các loại testing
- Metric cho functional testing gồm 3 loại chính:
- Requirement metric
- Test case metric
- Defect metrics
Để xác định được chất lượng thực sự của hệ thống, người quản lý cần phải nhìn vào cả 3 số liệu trên.. Ví dụ: Nếu người quản lý chỉ nhìn vào số bug mà không quan tâm đến số test case đã test được sẽ không thể đánh giá được có bao nhiêu bug tiềm tàng nữa có thể xảy ra. Giả sử một dự án có 10 bug thì dường như nó đang tiến triển thuận lợi.
Tuy nhiên, 10 bug tìm được /10 case đã test và tổng số case cần hoàn thành là 200, thì dường như là không ổn chút nào.
3.Metric nào phù hợp với SDLC (software development lifecycle- Vòng đời phát triển phần mềm)
Hãy xem xets sự phát triển vòng đời phát triển phần mềm (SDLC) được mô tả trong sơ đồ dưới đây. QA team sẽ cần phải trả lời hai câu hỏi như dưới đây.
Q1: Khi nào thì sẽ xác định các số liệu thu thập và ngưỡng chịu đựng là gì?
Q2: Khi nào cần thu thập và bắt đầu báo cáo số liệu?
Trước đây, QA thường tham gia vào dự án sau khi phần mềm đã phát triển xong. Tuy nhiên, do nhận thấy nhiều lợi ích đat được khi QA tham gia vào ngay từ đầu của vòng đời phát triển phần mềm. Trong thực tế, nghiên cứu đã chỉ ra rằng defect được tìm thấy ở những giai đoạn cuối trong SDLC thì sẽ mất nhiều chi phí để sửa chữa hơn so với các defect được tìm thấy ở những giai đoạn đầu của SDLC.
Lý tưởng nhất, QA sẽ lên kế hoạch bắt đầu từ giai đoạn đầu bằng cách xác định loại testing sẽ được thực hiện. Xác định các yêu cầu về đảm bảo chất lượng được bắt đầu từ giai đoạn requirement. Từ đó xác định requirement metric. Khi lập kết hoạch kiểm thử, hoàn thành test metric sẽ giúp các nhóm làm việc hướng tới 1 mục tiêu rõ ràng hơn, tránh các xung đột không cần thiết trong quá trình thực hiện. QA team cần thu thập và báo cáo các requirement metric trong quá trình lập kế hoạch kiểm thử. Từ đó có thể đưa ra được tiến độ của việc viết test case.
Ở giai đoạn Test, thu thập và báo cáo số liệu Test case và số liệu lỗi. Từ đó đánh giá được chất lượng và tiến độ hiện tại của dự án. Nếu chờ đến giai đoạn kiểm thử chấp nhận mới tính toán các số liệu thì quá muộn để đưa ra các quyết định chính xác và hoàn thành dự án đúng thời hạn.
4.Sơ lược về các loại test metric chính
4.1 Requirement metric:
*Định nghĩa: Yêu cầu là gì?
Yêu cầu phải được vạch ra rõ ràng khi bắt đầu bất kỳ dự án phát triển mới nào, nhờ đó các thành viên trong team sẽ hiểu được mục tiêu họ cần hướng tới.
*Vì sao lại quan trọng?
Chất lượng của một phần mềm hoàn chỉnh thường được xác định bởi khả năng đáp ứng những yêu cầu của nhà phát triển đặt ra từ giai đoạn đầu phát triển. Nếu không xác định rõ ràng yêu cầu và những vấn đề sẽ gặp phải, tester sẽ rất khó khăn khi tiến hành công việc của mình. Việc giám sát hiệu quả của các quy định này là hoàn toàn cần thiết để đảm bảo một dự án có khởi đầu tốt đẹp và duy trì được lộ trình của nó. Ngoài ra, tester sẽ có rất nhiều thuận lợi ngay từ khởi đầu dự án khi kiểm tra thật kỹ những yêu cầu và nghĩ ra thật nhiều trường hợp tránh việc bị bỏ lỡ một số lỗi.
*Tính toán như thế nào?
Mức độ bao phủ yêu cầu sẽ dựa vào việc so sánh giữa yêu cầu ban đầu với quy trình và công việc thực tế. Thay vì chỉ tập trung vào từng yêu cầu tiểu tiết thì nên xác định ở mức độ bao phủ.
Khi tính toán mức độ bao phủ, mỗi trường hợp cụ thể của từng tiêu chí sẽ được tính riêng. Để đơn giản hóa, chung ta có thể tính tỷ lệ phần trăm đáp ứng yêu cầu bằng phép tính sau.
số yêu cầu đã đảm bảo
Mức độ bao phủ requirement = (--------------------------------) * 100
tổng số yêu cầu
Chú ý: Việc bao phủ của mỗi quy trình làm việc cần đảm bảo những vấn đề sau: Mức độ bao phủ của việc kiểm tra quy trình nghiệp vụ phải tính toán cho toàn bộ quy trình làm việc, không phải cho từng cá nhân. Trường hợp luồng độc lập với quy trình nghiệp vụ thì sau đó sẽ tính toán theo tiêu chí riêng. Nếu nhìn vào quy trình làm việc có nhiều luồng, mỗi luồng lại lặp lại nhiều lần thì cần tính toán cho mỗi lần lặp lại đó.
4.2 Test case metric:
A. Phần trăm của số TC đã thực hiện test:
Công thức này được sử dụng tính phần trăm của số Testcase đã thực hiện test.
No. of Test cases executed
% Test cases Executed = (-----------------------------------------) * 100
Total no. of Test cases written
Thường thì với mỗi phase test sẽ ứng với mỗi bộ test case, yêu cầu tỉ lệ testcase đã thực hiện test phải đạt 100%, nếu không đặt được mức đó thì team phải check lại những case chưa test để biết được nguyên nhân.
B. Phần trăm của số TC chưa thực hiện test.
Công thức này được sử dụng tính phần trăm của số Testcase chưa thực hiện test.
No. of Test cases not executed
% Test cases not Executed = (-------------------------------------) * 100
Total no. of Test cases written
C. Phần trăm của số TC pass.
Công thức này được sử dụng tính phần trăm của số Testcase đã test pass.
No. of Test cases Passed
% Test cases Passed = (-------------------------------------------) * 100
Total no. of Test cases Executed
Con số % của testcase pass được tăng theo quá trình thực hiện test, nếu nó không tăng và vẫn giữ nguyên thì có lẽ sẽ do các nguyên nhân sau:
- Thời gian test lâu hơn dự kiến
- Quá trình test bị ngăn chặn bởi nhiều bug blocking
- Trong quá trình thực hiện test phát sinh nhiều bug so với dự kiến.
- Defects không được resolved đúng.
- Defects bị Reopen
Vậy nếu tỉ lệ % của số testcase pass thấp, chúng ta cũng nên phải xem sét và đưa ra nguyên nhân để khắc phục triệt để cho các phare tiếp theo.
D. Phần trăm của số TC Failed.
Công thức này được sử dụng tính phần trăm của số Testcase đã test failed
No. of Test cases Failed
% Test cases Failed = (-------------------------------------------) * 100
Total no. of Test cases Executed
Ngược lại với số testcase pass, tỉ lệ số Testcase failed càng it thì chứng tỏ rằng chất lượng sản phẩm tốt. Nhưng song song với nó cũng chính là câu hỏi? Liệu có phải ta test lọt nhiều bug? Vậy nên chúng ta nên tìm hiểu rõ nguyên nhân để đánh giá cho chính xác.
E. Phần trăm của số TC block.
Công thức này được sử dụng tính phần trăm của số Testcase đang bị block
No. of Test cases Blocked
% Test cases Blocked = (-------------------------------------------) * 100
Total no. of Test cases Executed
Có nhiều nguyên nhân dẫn đến việc testcase bị block như: Do case đó đang có bug, Do chưa có device để thực hiện test, Do có change request gấp… chúng ta nên giải quyết những vẫn đề đó nhanh để số lượng testcase càng ít càng tốt.
4.3 Defect metrics
A. Tỷ trọng defect (Defect Density) Tỷ trọng defect là gì ?
Là số lượng defect của phần mềm hoặc một modul trong một giai đoạn phát triển nhất định trên size của phần mềm hoặc modul đó. Nó giúp dự án xem xét liệu đã có thể release phần mềm hoặc modul đó chưa
Size ở đây được hiểu là số function point. Do đó, tỷ trọng defect được tính toán theo số lượng defect trên số function points. Tương tự, tỷ trọng defect cũng có thể được tính như số lượng defect trên mỗi 100 hay 1000 dòng code.
Công thức tính tỷ trọng defect
số lượng defect
Tỷ trọng defect = (------------------------) * 100
size
Ví dụ:
Số lượng defect xác định được là: 30
Số function point là 5
Vậy tỷ trọng defect = 30/5 = 6
Chuẩn đánh giá của tỷ trọng defect: không có môt chuẩn cụ thể nào cho tỷ trọng defect, các nghiên cứu cho rằng 1 defect trên nghìn dòng code là dấu hiệu của một dự án có chất lượng tốt.
Tại sao lại cần tính toán tỷ trọng defect?
Bởi vì, tỷ trọng defect giúp:
- Tính toán được hiệu quả của testing
- Phân biệt defects trong các thành phần/moduls của phần mềm
- Xác định được các khía cạnh, khu vực cần điều chỉnh hoặc cải tiến
- Xác định được các thành phần có độ rủi ro cao
- Xác định nhu cầu training với các nguồn tài nguyên khác nhau
- Ước lượng hoạt động kiểm thử và làm lại do bugs
- Ước lượng được số defect còn lại trong phần mềm
- Trước khi release sản phẩm, chúng ta có thể quyết định được liệu hoạt động kiểm thử đã đầy đủ hay chưa
- Đảm bảo được cơ sở dữ liệu với tỷ trọng defect tiêu chuẩn
B. Hiệu quả loại bỏ lỗi (Defect Removal Efficiency-DRE)
Hiệu quả loại bỏ lỗi là gì?
Là tỷ lệ phần trăm của tổng số lỗi đang tồn tại đã được phát hiện bởi hoạt động kiểm soát chất lượng. Về bản chất, DRE là thước đo khả năng lọc của các hoạt động kiểm soát và đảm bảo chất lượng khi chúng được áp dụng trong tất cả các hoạt động khung tiến trình.
Công thức tính:
Khi xem xét tổng thể 1 dự án, DRE được định nghĩa như sau:
DRE = E/(E+D)
Trong đó:
E: số lượng lỗi (error) được tìm thấy trước khi đưa phần mềm cho người dùng cuối.
D: số lượng lỗi (defect) được tìm thấy sau khi bàn giao.
Lý tưởng là DRE = 1, tức là không có lỗi (defect) nào được tìm thấy trong phần mềm. Thực tế, D >0 nhưng DRE vẫn có thể tiến đến 1. Khi E tăng (đối với giá trị D được đưa ra), giá trị tổng thể của DRE bắt đầu tiến đến 1. Trong thực tế, khi E tăng, có vẻ như giá trị cảu D sẽ giảm (error được lọc trước khi defect). DRE khuyến khích đội dự án tìm ra càng nhiều lỗi trước khi giao càng tốt.
DRE có thể được sử dụng để đánh giá khả năng của đội trong việc tìm kiếm lỗi tại 1 task trước khi chuyển qua task khác. Trong trường hợp này, DRE được định nghĩa như sau:
DREi = Ei/(Ei + Ei+1)
Ei: số lượng lỗi tìm thấy trong task i
Ei+1: số lượng lỗi được tìm thấy trong task i+1 mà không được tìm thấy trong task i
Mục tiêu chất lượng là DRE tiến đến 1, tức lỗi nên được lọc ra trước khi chuyển qua task khác.
độ nghiêm trọng/ưu tiên của các sẽ được sử dụng để quyết định chất lượng của phần mềm.
Công thức tính:
Số Critical Defects
%ge Critical Defects = (------------------------) * 100
Tổng số defects
Số High Defects
%ge High Defects = (------------------------) * 100
Tổng số defects
Số Medium Defects
%ge Medium Defects = (------------------------) * 100
Tổng số defects
Số Low Defects
%ge Low Defects = (------------------------) * 100
Tổng số defects
E. Sự phân phối defect theo loại defect
Số Logic defect
%ge Logic defect = (------------------------) * 100
Tổng số defects
Số Standards defect
%ge Standards defect = (--------------------------) * 100
Tổng số defects
Số Performance defect
%ge Performance Defects = (--------------------------) * 100
Tổng số defects
Số Redundant code defect
%ge Redundant code Defects = (------------------------------) * 100
Tổng số defects
Số User interface defect
%ge User interface Defects = (------------------------------) * 100
Tổng số defects
Số Architecture defect
%ge Kiến trúc Defects = (------------------------------) * 100
Tổng số defects
Số Consistency defect
%ge Consistency Defects = (------------------------------) * 100
Tổng số defects
Số Reusability defect
%ge Reusability Defects = (------------------------------) * 100
Tổng số defects
F. Defect Trend Analysis
Defect trend analysis là gì?
Defect trend analysis = xu hướng số lượng lỗi được tìm thấy trong tiến trình của vòng đời kiểm thử.
Defect trend analysis có thể giúp xác định xu hướng trong việc xác định khiếm khuyết. Xác định xem xu hướng này có được cải thiện trong giai đoạn kiểm thử hệ thống khi gần hoàn thành hay không, hoặc có chiều hướng xấu đi. Thông số này có liên quan chặt chẽ đến "Số lượng khiếm khuyết mới". Số lượng khiếm khuyết mới nên giảm khi giai đoạn kiểm thử hệ thống đi đến hồi kết. Nếu đây không phải là trường hợp kiểm thử thì có nó là một chỉ thị cho thấy khiếm khuyết nghiêm trọng của một hệ thống.
Nếu số lượng khiếm khuyết được tìm thấy tăng thêm ở mỗi phiên bản release tiếp theo, giả sử không có chức năng mới được giao và với cùng một code đang được kiểm thử, một số nguyên nhân có thể được đưa ra, chẳng hạn như:
- Sửa code không đúng với khiếm khuyết trước đó
- Kiểm thử không coverage được hết các trường hợp cho bản build trước đó
- Không có khả năng thực hiện một số kiểm thử cho đến khi một số lỗi đã được fix, cho phép thực hiện kiểm thử, sau đó tìm thấy khiếm khuyết mới.
Công thức tính:
D No. of known defects
DTA = ------- = (-----------------------------------------)
TPE No. of test procedures executed
DTA = Phân tích xu hướng lỗi
D = Số lượng lỗi được tìm thấy
TPE = Số lượng thủ tục kiểm thử được thực hiện theo thời gian.
5.Conclusion - Kết luận
Khi nói đến việc đánh giá chất lượng phần mềm, QA manager có thể thấy họ có quá nhiều số liệu, có thể không có đầy đủ số liệu hoặc số liệu không đầy đủ. Điều này sẽ làm họ không thể đánh giá được chất lượng phần mềm. Do đó, không thể đưa ra những quyết định phù hợp và đúng đắn tại thời điểm đó.
Test metric đưa ra các phép đo rõ ràng về chất lượng và đầy đủ của sản phẩm. Vì vậy, Testing metric đóng góp vai trò rất quan trọng trong việc đưa ra quyết định của dự án dựa trên chất lượng của dự án tại một thời điểm nhất định trong vòng đời dự án , cho phép quản lý hiệu quả quá trình phát triển phần mềm.
Link tham khảo:
http://www.softwaretestinghelp.com/software-test-metrics-and-measurements/
http://support.yourzephyr.com/product_help/4.5/Using_Zephyr/Project_Metrics/Metric_Types.htm
All rights reserved
