Đã đăng vào Jul 24th, 2016 6:31 p.m. 23 phút đọc

2.2K

Test Effort Estimation

Bài đăng này đã không được cập nhật trong 7 năm

1. Test Estimation là gì ?

Test Estimation là ước tính quy mô kiểm thử,effort kiểm thử, chi phí kiểm thử và lịch trình kiểm thử cho một dự án kiểm thử phần mềm trong môi trường quy định sử dụng các phương thức, công cụ và kỹ thuật đã được định nghĩa.

Dưới đây là một số khái niệm

Quy mô kiểm thử: Số lượng kiểm thử cần được thực hiện .
Effort kiểm thử: Effort của một người trong ngày hoặc số giờ của một người cần thiết để thực hiện kiểm thử.
Chi phí kiểm thử: Chi phí cần thiết để thực hiện kiểm thử.
Lịch trình kiểm thử: Số ngày hoặc tháng cần thiết để thực hiện các kiểm thử.

2. Mục tiêu của ước tính nỗ lực kiểm thử (Approaches to Test Effort estimation )

Để thực hiện ước tính nỗ lực kiểm thử (Test Effort Estimation) có các phương pháp dưới đây :

Kỹ thuật Delphi
Estimation dựa trên phép loại suy
Estimation dựa trên các trường hợp kiểm thử
Estimation dựa trên các nhiệm vụ (task)
Estimation dựa trên quy mô kiểm thử

Trong bài viết này sẽ tập trung vào ba kỹ thuật Estimation dựa trên các nhiệm vụ (task), Estimation dựa trên quy mô kiểm thử, Estimation dựa trên các trường hợp kiểm thử.

3. Estimation dựa trên quy mô kiểm thử

Một dự án kiểm thử đang trong giai đoạn đầu của nó quy mô phần mềm sẽ có sẵn. Chúng ta sẽ áp dụng quy mô phần mềm này như quy mô dự án kiểm thử. Sau đó sẽ chỉ định một con số hiệu suất (tỷ lệ đạt được) cho quy mô phần mềm để đi đến các yêu cầu, để thực hiện các dự án kiểm thử.

Cần 2 giờ để một người kiểm thử một function point . Sử dụng quy tắc này, có thể đưa ra effort cần thiết cho các dự án kiểm thử dựa trên quy mô của phần mềm.

Giả sử quy mô của phần mềm được kiểm thử là 1000 function point, sau đó, sử dụng quy tắc 2 giờ một người kiểm thử một điểm chức năng, sẽ có 2000 giờ để một người kiểm thử quy mô của phần mềm.

3.1: Ưu điểm của ước tính dựa trên quy mô của phần mềm

Rất đơn giản để tìm hiểu và sử dụng
Rất nhanh chóng - mất rất ít thời gian để ước tính nỗ lực
Tổ chức và duy trì các quy tắc này sử dụng đúng quy trình, các ước tính sử dụng kỹ thuật này có thể mang lại kết quả chính xác đáng ngạc nhiên.

3.2: Nhược điểm của ước tính dựa trên quy mô của phần mềm

Quá đơn giản - không thể kiểm tra
Khi quy mô của kiểm thử là không có, hiệu suất có thể không xác định được. Tuy nhiên, năng suất kiểm thử có thể được bắt nguồn lại với quy mô phần mềm.
Số lượng kiểm thử khác nhau tùy theo loại ứng dụng mặc dù quy mô có thể giống nhau.
Tổ chức phải giữ hồ sơ tỉ mỉ và sử dụng các chuyên gia toàn thời gian để lấy được các chỉ tiêu và duy trì chúng. Các bảng chấm công cần phải được thay đổi để nắm bắt dữ liệu phù hợp,để lấy được những chỉ tiêu chính xác. Thu thập dữ liệu phải chặt chẽ.

4. Estimation dựa trên các trường hợp kiểm thử

Kỹ thuật này bao gồm các bước sau :

Liệt kê tất cả các trường hợp kiểm thử
Ước tính nỗ lực kiểm thử cần thiết cho mỗi trường hợp kiểm thử
Sử dụng trường hợp tốt nhất, trường hợp bình thường và trường hợp xấu nhất để ước lượng nỗ lực cần thiết cho mỗi trường hợp kiểm thử.
Tính toán nỗ lực dự kiến cho từng trường hợp sử dụng phân bố Beta.

Case tốt nhất + Case xấu nhất + (4 * Case bình thường) / 6

Một ví dụ về Estimation dựa trên các trường hợp kiểm thử

| Test Case id | Mô tả Test case|Case tốt nhất | Case xấu nhất| Case bình thường |Dự kiến | |-------|--------|------||-------|--------|------| | US1 | Cài đặt môi trường test | || | | | | US1.1 | Kiểm tra môi trường test | 1 || 2 | 1.5 | 1.500 | | US2| Cài đặt ghi lại màn hình | 0.75 || 1.5 | 1 | 1.042 | | US2.1 | Đảm bảo cơ chế báo cáo lỗi | 1.25 || 3 | 2 | 2.042 | | UI1 | Màn hình đăng nhập trên IE | || | | | | UI1.1 | Đăng nhập chính xác | 0.05 || 0.2 | 0.1 | 0.108 | | UI2 | Id sai và password chính xác | 0.07 || 0.2 | 0.1 | 0.112 | | UI1.2 | Id chính xác và password sai | 0.07 || 0.2 | 0.1 | 0.112 | | UI3 | Chức năng quên password | 0.15 || 0.3 | 0.2 | 0.208 | | UF2 | Màn hình đăng nhập trên Firefox | || | | | | UF2.1 | Đăng nhập chính xác | 0.05 || 0.2 | 0.1 | 0.108 | | UF3 | Id sai và password chính xác | 0.07 || 0.2 | 0.1 | 0.112 | | UF2.2 | Id chính xác và password sai | 0.07 || 0.2 | 0.1 | 0.112 | | UF4 | Chức năng quên password | 0.15 || 0.3 | 0.2 | 0.208 | | | | || | | | | | Tổng ước lượng effort kiểm thử | 3.680 || 8.300 | 5.500 | 5.663 |

4.1. Ưu điểm của Estimation dựa trên các trường hợp kiểm thử

Có thể kiểm tra việc estimate: Estimate có chi tiết đầy đủ để những đồng nghiệp khác có thể xem xét bản estimate và đảm bảo các ước tính đó đầy đủ và chính xác nhất.
Tương đối chính xác: Độ chính xác được đảm bảo vì tất cả các trường hợp kiểm thử được liệt kê và được sử dụng ba lần để đạt được nỗ lực dự kiến.
Giám sát tiến độ được thuận tiện: Bằng cách đánh dấu các trường hợp kiểm thử được hoàn thành và tỷ lệ phần trăm hoàn thành được tính toán một cách dễ dàng.
Tạo điều kiện cung cấp một khoảng giá trị cho việc estimates ví dụ như : Dự án có thể được thực hiện với một effort tối thiểu của rất nhiều người và effort tối đa của rất nhiều người giờ so với effort dự kiến. Điều này cho phép các nhà sản xuất quyết định để thiết lập đàm phán lợi nhuận của họ.

4.2. Nhược điểm của Estimation dựa trên các trường hợp kiểm thử

Không kiểm thử quy mô
Tất cả các trường hợp kiểm thử và các chi phí kèm theo cần được liệt kê vì vậy mất thời gian để hoàn thành việc estimate.

5.Estimation dựa trên các nhiệm vụ (task)

Phương pháp này xem xét dự án từ quan điểm của các nhiệm vụ được thực hiện trong khi thực hiện dự án. Bất kỳ giai đoạn nào được thực hiện trong dự án. Các giai đoạn trong một dự án kiểm thử có thể là

Bắt đầu dự án
Lập kế hoạch dự án
Lập kế hoạch kiểm thử
Thiết kế các trường hợp kiểm thử
Thiết lập môi trường kiểm thử
Tiến hành kiểm thử
- Kiểm thử tích hợp
- Kiểm thử hệ thống
- Kiểm thử trọng tải
- Vân vân ...
Log và báo cáo kết quả kiểm tra
Kiểm thử hồi quy
Chuẩn bị báo cáo kiểm thử
Kết thúc dự án

Các giai đoạn của các dự án và các tổ chức khác nhau có thể khác nhau. Mỗi giai đoạn có thể được chia nhỏ hơn thành các nhiệm vụ. Dưới đây là một ví dụ

Giai đoạn bắt đầu dựa án

Nghiên cứu phạm vi kiểm thử và được làm sáng tỏ nếu cần thiết
Xác định người quản lý dự án (Test)
Lấy dữ liệu của dự án tương tự trong quá khứ và làm cho nó trở thành một phần của hồ sơ dự án
Chuẩn bị số người tham gia và được sự chấp thuận
Tiến hành họp khởi động dự án và bàn giao hồ sơ dự án cho quản lý dự án (Test).

Giai đoạn lập kế hoạch dự án

Chuẩn bị ước tính effort
Xác định yêu cầu nguồn lực
Đưa lên mẫu yêu cầu nguồn lực
Chuẩn bị kế hoạch quản lý dự án
Chuẩn bị kế hoạch quản lý cấu hình
Chuẩn bị kế hoạch đảm bảo chất lượng
Sắp xếp đánh giá ngang hàng các kế hoạch dự án
Kế hoạch dự án được chấp nhận
Kế hoạch dự án cơ bản

Chúng ta có thể phân mỗi giai đoạn thành các nhiệm vụ. sử dụng các nhiệm vụ có thể thực hiện ước lượng nỗ lực kiểm thử. Sau đây là các bước trong Estimation dựa trên các nhiệm vụ (task)

Khoảng thời gian giao cho cho mỗi Nhiệm vụ - số giờ của một người hoặc số ngày của một người
Sử dụng ước lượng ba lần - Trường hợp tốt nhất, xấu nhất và trường hợp bình thường cho mỗi nhiệm vụ

Tính toán thời gian dự kiến sử dụng công thức

 [Trường hợp tốt nhất + Trường hợp xấu nhất + (4 * Trường hợp bình thường)] / 6

Thực hiện điều chỉnh cho dự án quen với nền tảng, kỹ thuật của đội phát triển, công cụ sử dụng.
Tổng hợp tổng effort của dự án
Sử dụng kỹ thuật Delphi để xác nhận các ước tính, nếu nghi ngờ hoặc cảm thấy cần thiết. Bảng dưới đây sẽ cho một ví dụ về Estimation dựa trên các nhiệm vụ (task)

| Task id | Giai đoạn |Nhiệm vụ |Trường hợp tốt nhất | Trường hợp xấu nhất |Trường hợp bình thường |Dự kiến | |-------|--------|------||-------|--------|------||------| | 1 | Kế hoạch kiểm thử | Nghiên cứu đặc tả yêu cầu || 2 | 5 | 3 || 3.167 | | 2 | Kế hoạch kiểm thử | Xác định loại kiểm thử để thực hiện ||0.5 | 1 | 0.65 || 0.683 | | 3 | Kế hoạch kiểm thử | Xác định môi trường kiểm thử || 0.5 | 1 | 0.65 || 0.792 | | 4 | Kế hoạch kiểm thử | Ước lượng quy mô, effort, chi phí và lịch trình của dự án kiểm thử || 2 | 4 | 3 || 3.500 | | 5| Kế hoạch kiểm thử | Xác định quy mô của đội || 0.5| 1.25 | 0.75 || 0.917 | | 6 | Kế hoạch kiểm thử | Đánh giá bản estimate || 1 | 2 | 1.5 || 1.750 | | 7 | Kế hoạch kiểm thử | Chấp nhận bản estimate || 0.5 | 2 | 0.75 || 1.042 | |8| Thiết kế các trường hợp kiểm thử | Thiết kế các trường hợp kiểm thử của mô đun 1 || 5 | 8 | 6 || 7.167 | | 9 | Thiết kế các trường hợp kiểm thử | Thiết kế các trường hợp kiểm thử của mô đun 2 || 6 | 9 |7 ||8.333 | | 10 | Thiết kế các trường hợp kiểm thử | Thiết kế các trường hợp kiểm thử của mô đun 3 | 4 || 6 |5 |5.833 | | 11 | Tiến hành kiểm thử | Tiến hành kiểm thử cho mô đun 1 || 15 | 18 | 16|| 18.833 | | 12 | Tiến hành kiểm thử| Tiến hành kiểm thử cho mô đun 2 | 16 || 19 | 17 | 20.00 | |13 | Tiến hành kiểm thử | Tiến hành kiểm thử cho mô đun 3 || 14 | 16 | 15 || 17.500 | | 14 |Báo cáo lỗi | Báo cáo lỗi cho mô đun 1 ||1| 2 | 1.5 || 1.750 | | | | || | | || | | | | Tổng ước tính effort || 68.000 | 94.250 |77.800 || 91.267 | Chú thích các định nghĩa trong bảng trên

Dự kiến: Thời gian dự kiến để có được ước tính effort mong đợi cho dự án
Trường hợp tốt nhất : Thời gian để kiểm thử trường hợp tốt nhất để có được ước tính cho effort của trường hợp tốt nhất.
Trường hợp xấu nhất : Thời gian để kiểm thử trường hợp xấu nhất để có được ước tính cho effort của trường hợp xấu nhất.
Trường hợp bình thường : Thời gian để kiểm thử trường hợp bình thường để có được ước tính cho effort của trường hợp bình thường.

5.1.Ưu điểm của estimation dựa trên các nhiệm vụ (task)

Phản ánh sát nhất cách thực hiện dự án
Kỹ thuật này đưa vào xem xét tất cả các hoạt động được thực hiện và đem lại ước tính effort một cách chính xác.
Chi tiết đầy đủ vì vậy phù hợp với đánh giá,kiểm tra và phân tích bằng cách so sánh với các giá trị thực tế.
Đơn giản và dễ dàng để chuẩn bị một estimate
Tiến độ dự án được theo dõi dễ dàng bằng cách đánh dấu các nhiệm vụ đã hoàn thành và tỷ lệ phần trăm hoàn thành có thể dễ dàng được tính toán.
Thích hợp để sử dụng Estimation dựa trên phép loại suy.

5.2.Nhược điểm của estimation dựa trên các nhiệm vụ (task)

Quy mô kiểm thử không được tính

6. Các vấn đề về quy mô của dự án kiểm thử

Để xác định một đơn vị của đo lường quy mô kiểm thử, phải có một định nghĩa rõ ràng về những gì được bao gồm trong nó. Thứ hai, phải có một công cụ để đo quy mô. Sau đó lại phải có một số sự thống nhất không cần giống hệt nhau trong khi thực hiện kiểm thử, cụ thể là, chuẩn bị kế hoạch kiểm thử, tính toàn diện của các trường hợp kiểm thử, các loại kiểm thử được thực hiện và dữ liệu kiểm thử có sẵn để có một độ đo chung.

Các khía cạnh sau đây cần xem xét

Loại ứng dụng - Standalone, Client-Server, Web-Based
Loại kiểm thử - Kiểm thử hộp đen hoặc kiểm thử hộp trắng.
Giai đoạn kiểm thử - Kiểm thử đơn vị, tích hợp, hệ thống
Mục đích của kiểm thử - Độ tin cậy, khách hàng chấp nhận, đảm bảo chức năng.
Độ bao phủ của các trường hợp kiểm thử - Bao nhiêu trường hợp được bao phủ và bao nhiêu trường hợp theo trực giác của người kiểm thử.
Xác định các trường hợp kiểm thử chức năng - Một trường đầu vào được kiểm tra với năm giá trị đầu vào.
Kích thước của các trường hợp kiểm thử ở các mức đơn vị, tích hợp và hệ thống là khác nhau.
Tác động của việc sử dụng các công cụ và các nỗ lực cần thiết.
Các yếu tố môi trường - Kinh nghiệm kiểm thử và kiến thức, độ phức tạp của các ứng dụng, tài nguyên (thời gian và ngân sách) cho phép để kiểm thử
Sự tồn tại của việc đánh giá code trước khi kiểm thử phần mềm.

Đo lường quy mô quan trọng để so sánh giữa hai dự án được thực hiện, để đánh giá tính hợp lý của các ước lượng nỗ lực. Nó cũng tạo điều kiện tính toán năng suất kiểm thử và tỷ lệ đạt được.

Ai có nhu cầu kiểm thử quy mô?

Các tổ chức kiểm thử. Mục tiêu của họ là để đảm bảo rằng các sản phẩm đáp ứng các thông số kỹ thuật và kỳ vọng của khách hàng. Các kỹ thuật sau sẽ được thực hiện:
- Chủ yếu là kiểm thử hộp đen
- Kiểm thử chức năng
- Kiểm thử hệ thống
- Kiểm thử hồi quy
Khách hàng ủy thác phát triển phần mềm của họ cho một nhà cung cấp. Mục tiêu là để đảm bảo rằng họ nhận được những gì họ đang trả tiền cho.

Quy mô của dự án kiểm thử

"Test Point" là đơn vị đo lường cho việc ước lượng vậy Test Point là gì?

Test Point là thước đo kích thước để đo quy mô của một dự án kiểm thử phần mềm và một Test Point tương đương với một trường hợp kiểm thử bình thường.

Có thể ước tính Test point bằng một tập hợp các yếu tố chuyển đổi và điều chỉnh kích thước Test point bằng trọng lượng (weight)khác nhau.

Trọng lượng

Các trọng lượng sau đây được xem xét

Trọng lượng ứng dụng
Trọng lượng ngôn ngữ lập trình
Trọng lượng với từng loại kiểm thử như là :
- Kiểm thử đơn vị
- Kiểm thử tích hợp
- Kiểm thử hệ thống
- Kiểm thử chấp nhận
- Kiểm thử trọng tải
- Kiểm tra song song
- Kiểm thử stress
- Kiểm thử người dùng cuối

Test Point có trọng lượng bằng 1 khi là trọng lượng kết hợp của ba kiểm thử : Kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận.

Khi các kiểm thử khác được thêm vào dự án, trọng lượng có thể được chỉ định và bổ sung vào trọng lượng Test Point.

Cần trình biên dịch dữ liệu trọng lượng cho tất cả các kiểm thử và duy trì chúng bằng cách so sánh các giá trị ước tính với giá trị thực tế vào cuối mỗi dự án kiểm thử ,sau khi tiến hành phân tích nguyên nhân trong từng trường hợp.

Sử dụng công cụ kiểm thử được mong đợi sẽ giảm effort kiểm thử. Sử dụng công cụ kiểm thử nếu trọng lượng bằng 1 sẽ cho thấy công cụ không có bất kỳ tác động nào vào effort kiểm thử . Nếu lớn hơn 1 chỉ ra rằng công cụ làm tăng effort kiểm thử và trọng lượng nhỏ hơn 1 cho thấy rằng công cụ sẽ làm giảm effort thử.

Những lý do bổ sung trọng lượng

Kiểm thử đơn vị là kiểm thử hộp trắng
Các môi trường phát triển cho các ngôn ngữ khác nhau là khác nhau

Các bước tính toán quy mô dự án kiểm thử bằng Test Point

Sử dụng một quy mô phát triển phần mềm hiện có
Chuyển đổi quy mô phần mềm vào các điểm kiểm thử chưa được điều chỉnh -Unadjusted Test Points (UTP) sử dụng một yếu tố chuyển đổi dựa vào loại ứng dụng.
Tính toán một yếu tố trọng lượng hỗn hợp - Composite Weight Factor (CWF) bao gồm

Tổng hợp tất cả các trọng lượng riêng của kiểm thử được lựa chọn
Nhân với trọng lượng của trọng lượng ứng dụng
Nhân với trọng lượng ngôn ngữ lập trình nếu kiểm thử đơn vị được chọn
Nhân với trọng lượng sử dụng công cụ(tool test) nếu sử dụng công cụ kiểm thử được chọn

Kiểm tra các điểm chưa điều chỉnh được nhân lên bởi CWF để thu được kích thước kiểm thử
Yếu tố năng chỉ ra số lượng thời gian cho một kỹ sư hoàn thành kiểm thử của một Test Point
Kiểm thử effort của mỗi người được tính bằng cách nhân quy mô kiểm thử điểm

Bảng dưới đây minh hoạ về estimate Test Point

No	Vấn đề	Test Points
1	Quy mô sản phẩm trong Function point	2500
2	Yếu tố chuyển đổi (Test Point qua Function point)	4.5
3	Các điểm kiểm thử chưa điều chỉnh	11250
4	Trọng lượng ứng dụng cho ứng dụng Cleint-Server	1.1
5	Yếu tố trọng lượng hỗn hợp (CWF)	1.375

6	Các điểm kiểm thử đã điều chỉnh	15468.75

7	Yếu tố năng suất của mỗi giờ của một người / Test point	0.2

8	Effort kiểm thử mỗi giờ của một người	3093.75

Bảng dưới đây cung cấp các trọng lượng kiểm thử khác nhau được sử dụng trong tính toán CWF ở bảng trên

	Trọng lượng kiểm thử
1	Kiểm thử chức năng	0.35
2	Kiểm thử hệ thống	0.3
3	Kiểm thử chấp nhận	0.2
4	Kiểm thử miễn phí Virus	0.2
5	Kiểm thử miễn phí phần mềm gián điệp	0.2
	Tổng trọng lượng	1.25

6.1. Ưu điểm của Test Point Estimation

Ước tính được quy mô
Làm quy mô trở nên hữu ích trong ước tính dựa trên phép loại suy

6.2. Nhược điểm của Test Point Estimation

Định nghĩa của một điểm kiểm thử (test point) là những gì
Không đơn giản như những phương pháp khác
Dữ liệu không được chấp nhận rộng rãi hoặc chuẩn hoá trên trọng lượng khác nhau khi sử dụng phương pháp này.
Một người cần phải dành nhiều effort và thời gian để thiết lập các chỉ tiêu

Kết luận

Có rất nhiều phương pháp ước tính effort kiểm thử , tuỳ vào từng dự án bản có thể chọn các phương pháp khác nhau.

Bài viết được dịch từ http://www.chemuturi.com/test effort estimation.pdf