- Phân tích Pareto: liên quan tới + luật 80-20: trong 20% tổng số các dòng lệnh ban đầu thường có 80% lỗi. + xác định các mođun có lỗi.
- Kiểm tra lỗi ở các giai đoạn phát triển dự án để tránh làm ảnh hưởng đến các giai đoạn khác: để bảo đảm việc đó đội dự án nên chú ý kiểm thử ở thời điểm kết thúc mỗi giai đoạn,
113
nhằm mục đích ngăn ngừa có lỗi tiềm ẩn từgiai đoạn này ảnh hưởng đến các giai đoạn tiếp theo.
- Kéo dài thời gian chạy chương trình để kiểm tra thử khả năng chịu áp lực của hệ thống - Tạo một khoảng thời gian được gọi là “code freezer”, tạm ngừng viết mã chương trình, mà
chỉ tập trung vào công việc gỡ rối các lỗi; thường xảy ra vào các thời điểm tích hợp các chức năng hoặc kiểm thử chức năng của hệ thống.
- Tỉ lệ cán bộ kiểm thử /lập trình viên trong một dự án thay đổi tùy theo từng dự án nhưng thường là 1:3 hoặc 1:4. Cán bộ kiểm thử có thể là cán bộ đảm bảo chất lượng, vì thế nếu tăng số lượng của đội ngũ kiểm thử thì cần có một vị trí quản lý đội ngũ này ngay trong thời gian đầu của dự án.
Thời điểm để kết thúc giai đoạn kiểm thử thường rơi vào một trong hai trường hợp: thứ nhất là tất cả các lỗi đều được giải quyết xong, và phần mềm được bàn giao cho khách hàng, thứ hai là thời gian bàn giao sản phẩm cho khách hàng đã đến mà vẫn chưa giải quyết hết các lỗi. Đôi khi đến hạn cuối cùng phải bàn giao nhưng tất cả các lỗi chưa được giải quyết ngoại trừ những lỗi ở 3 mức cao nhất là rất quan trọng/cao/trung bình (Critical/High/Medium), giai đoạn kiểm thử vẫn phải dừng. Khi dừng thì cần có quyết định được ký bởi khách hàng, các kỹ sư công nghệ và nhà quản lý sản phẩm…
Những tiêu chí kiểm thử
+ Khả năng chịu tải của hệ thống (Load): thời gian chấp nhận được lớn nhất đáp ứng một yêu cầu, số lượng nhỏ nhất những người có thể chạy hệ thống trong cùng một lúc.
+ Khoảng thời gian lớn nhất cho phép hệ thống không làm việc hoặc làm việc với tốc độ chậm + Tính tương thích: sốlượng lớn nhất và nhỏ nhất các trình duyệt và hệđiều hành mà hệ thống có thể hỗ trợ.
+ Tính sử dụng: tỉ lệ chấp nhận nhỏ nhất của các nhóm người quan tâm
+ Tính năng: độ bao phủ các yêu cầu của hệ thống; tỉ lệ thành công của việc kiểm thử các bộ chức năng một cách tự động là 100%.
Những thông số cần thiết đểđo lỗi
Đây là một vấn đề quan trọng đối với người giám đốc dự án. Để đánh giá các lỗi trong quá trình kiểm thử, người ta phân loại các lỗi quan trọng theo mức độ nghiêm trọng của chúng bao gồm các cấp độ sau: rất nghiêm trọng/ Nghiêm trọng/ khá nghiêm trọng/ ít nghiêm trọng và chỉ rõ những người chịu trách nhiệm cho việc đó. Thêm nữa, các lỗi của dự án cũng sẽđược đánh dấu là đã được giải quyết xong (closed) hay vẫn chưa xong (opened).
Việc kiểm soát thực hiện sửa lỗi (Defect tracking)
114
• Công việc này có thểđược thực hiện nhờ sự hỗ trợ của các công cụ như Bugzilla, TestTrack Pro, Rational ClearCase. Một số công cụ tốt thường được cung cấp miễn phí hoặc là với chi phí rất nhỏ.
• Đảm bảo tất cả những thành viên liên quan đều có quyền truy nhập vào hệ thống kiểm thử • Cần tổ chức những buổi họp thường xuyên để xem lại những lỗi đã sửa: thường là hàng tuần
trong quá trình kiểm thửthông thường và hàng ngày đối với thời điểm gấp gáp.
• Những người có thể nhập các lỗi phát hiện được của dự án vào một hệ thống kiểm soát theo dõi lỗi của dự án hoặc của chung công ty là cán bộ đảm bảo chất lượng, lập trình viên, những nhà phân tích, nhà quản lý, và đôi khi có thể chính là những người sử dụng và giám đốc dự án. • Cấu trúc của hệ thống kiểm soát lỗi thường bao gồm những trường sau đây:
+ trạng thái: mở, đóng, đang trì hoãn
+ ngày nhập lỗi vào hệ thống, ngày cập nhật thông tin và ngày đóng lỗi + mô tả vấn đề của lỗi được phát hiện
+ số hiệu phiên bản phần mềm mà lỗi xuất hiện + Người phát hiện ra lỗi
+ Thứ tự ưu tiên được giải quyết của lỗi: thấp, trung bình, cao, rất cao
+ Những nhận xét, chú thích được thực hiện bởi cán bộđảm bảo chất lượng, lập trình viên và những thành viên khác liên quan.
Các thông số về lỗi
Tỉ lệ mở (Open rate): liên quan tới số lỗi xuất hiện mới trong một khoảng thời gian nhất định Tỉ lệđóng (Close rate): liên quan tới số lỗi được sửa xong (đóng) trong cùng khoảng thời gian trên. Tỉ lệ thay đổi (Change rate): số lần cùng một vấn đề được cập nhật
Số lần sửa lỗi sai (Fix Failed Counts): số lỗi mà đã được thực hiện việc sửa nhưng chưa được sửa đúng. Đây cũng là một đơn vị để đo khả năng giao động của dự án (vibration).
Tỉ lệ lỗi trung bình do Microsoft nghiên cứu qua thống kê là 10-20 lỗi trên 1 KLOC được phát hiện trong quá trình kiểm thử và 0.5 lỗi trên 1 KLOC sau khi bàn giao sản phẩm cho khách hàng.
Môi trường kiểm thử
Thường được chia ra làm hai môi trường chính để kiểm thử, đó là môi trường phần cứng và phần môi trường mạng. Việc kiểm thử môi trường phần cứng liên quan tới các nhóm lập trình viên, nhóm cán bộ đảm bảo chất lượng dự án, nền xây dựng dự án và các sản phẩm. Môi trường kiểm thử điển hình cho người lập trình viên chính là cấu hình phần cứng mà tại đó người lập trình phát triển hệ thống và đồng thời thực hiện quá trình kiểm thử các chức năng trên đó. Môi trường kiểm thử cho những cán bộ chất lượng hoặc người kiểm thử là cấu hình phần cứng cho việc thực hiện kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử lại sau khi sửa chữa. Môi trường kiểm thử phần
115
cứng còn cần được xác định cho quá trình kiểm tra khảnăng chịu tải và quá trình triển khai cuối cùng của hệ thống phần mềm.
Các vị trí của đội ngũ cán bộđảm bảo chất lượng dự án (QA)
- Vịtrí nhóm trưởng: trách nhiệm chính là tìm và tuyển người đểđảm bảo đủ nguồn nhân lực cho đội ngũ QA, tạo các kế hoạch kiểm thử, lựa chọn công cụ nếu cần để thực hiện việc kiểm thử, và trách nhiệm cuối cùng là quản lý hoạt động của cả đội QA. Tại Mỹ, tính đến thời điểm năm 2002, lương trung bình của nhóm trưởng QA là $50-80 nghìn USD/ năm hoặc $50-100 USD/ giờ làm việc
- Vị trí người kiểm thử và kỹ sư kiểm thử: thực hiện việc kiểm thử các chức năng, tạo ra các đoạn chương trình nhỏ để hướng dẫn kiểm thử hoặc thực hiện việc kiểm thử một cách tự động. Tại Mỹ, tính đến thời điểm năm 2002, lương trung bình của vị trí này là $35-70 nghìn USD/ năm hoặc $40-100 USD/ giờ làm việc
- Vị trí quản trị hệ thống: trách nhiệm chính là hỗ trợ cho nhóm QA làm việc nhưng lại không phải là một thành viên chính thức của nhóm
- Vị trí biên tập bản sao chép và soạn thảo các tài liệu cho dự án: trách nhiệm chính cũng là hỗ trợ cho nhóm QA nhưng cũng không phải là một thành viên chính thức của nhóm