CHƯƠNG III : ỨNG DỤNG THỰC TIỄN
3.4. Kết quả khi áp dụng kỹ thuật kiểm thử
Nhờ hiểu rõ đặc điểm, tính chất và lợi ích của việc áp dụng kỹ thuật kiểm thử hỗ trợ cho kiểm soát chất lượng trong quá trình phát triển phần mềm. Nhóm phát triển dự án VEMIS đã áp dụng một cách linh hoạt các loại kiểm thử và nó đã mang lại kết quả rất khả quan cho sản phẩm phần mềm mà nhóm thực hiện.
Kết quả khi áp dụng kiểm thử đơn vị: thực hiện kiểm thử đơn vị giúp đánh giá nội tại bên trong của sản phẩm, giúp kiểm soát được chất lượng trong của sản phẩm. Thời gian dành cho việc kiểm thử đơn vị khá tốn kém, xong nó lại rất cần thiết, không thể thiếu đối với mỗi quy trình thực hiện phát triển phần mềm. Cũng vì thời gian kiểm thử đơn vị mất nhiều thời gian nên người lập trình phải thật thận trọng trong xây dựng chương trình, tránh những khiếm khuyết không đáng có. Chi phí cho kiểm thử tăng theo quá trình phát triển. Vì vậy kiểm thử đơn vị tốt thì những kiểm thử tiếp theo sẽ giảm bớt và như vậy góp phần làm giảm chi phí trong sản xuất, nâng cao chất lượng của sản phẩm nhằm đáp ứng yêu cầu đảm bảo chất lượng của phần mềm cũng như đáp ứng yêu cầu của khách hàng. Và đặc biệt là, sản phẩm khi giao cho khách hàng mà ít khiếm khuyết sẽ tạo niềm tin cho khách hàng. Khi có được niềm tin của khách hàng thì sự hợp tác giữa nhà phát triển và khách hàng trở lên thuận lợi hơn.
Tuy nhiên, khi thực hiện kiểm thử đơn vị thành công không có nghĩa là phần mềm sẽ không có lỗi khi tích hợp các đơn vị với nhau. Vì vậy, nhóm phát triển phần mềm cần thực hiện kiểm thử tích hợp.
Kết quả khi áp dụng kiểm thử tích hợp: Thực hiện kiểm thử tích hợp giúp đánh giá chất lượng ngoài của phần mềm. Khi chất lượng ngoài được thỏa mãn, nó là cơ sở để khẳng định phần mềm sản xuất ra có chất lượng, đáp ứng yêu cầu chất lượng ngoài. Việc đáp ứng yêu cầu chất lượng ngoài có ảnh hưởng lớn đến chất lượng sử dụng. Khi kiểm soát được kiểm thử tích hợp chính là ta đã kiểm soát được chất lượng ngoài của sản phẩm và góp phần cho việc kiểm soát chất lượng của sản phẩm phần mềm nói chung.
Kiểm thử hồi quy: sau khi thực hiện sửa chữa khiếm khuyết, sai sót xong không có nghĩa là phần mềm đã đảm bảo chạy tốt. Vì vậy cần phải thực hiện kiểm thử lặp lại – kiểm thử hồi quy để đảm bảo là lỗi đó không xuất hiện cũng như không phát sinh ra lỗi mới. Nguyên nhân là do quá trình loại bỏ lỗi, lập trình viên có thể đã tác động vào CSDL, làm thay đổi CSDL, mà CSDL thì được dùng chung nên với CSDL mới này có ảnh hưởng đến mô đun khác cụ thể là không tương thích nên phát sinh lỗi mới. Cũng chính vì lý do đó mà nhóm phát triển phải xem xét kỹ lưỡng xem mức độ nghiêm trọng của lỗi, và lỗi đó khi sửa có thể ảnh hưởng đến mô đun nào để đưa ra cách giải quyết hợp lý. Nếu không kiểm soát được điều này sẽ dẫn đến bùng nổ lỗi và
gây ảnh hưởng rất lớn đến chất lượng của sản phẩm. Như vậy kiểm thử hồi quy không thể thiếu trong quá trình phát triển phần mềm. Thực hiện test hồi quy xong mà mô đun đó chạy ổn định ta bổ sung vào phần ghi chú trong bảng danh sách lỗi.
Kiểm thử chấp nhận: Với bước kiểm thử này sẽ quyết định phần mềm có được chấp nhận hay cần gia hạn sửa chữa rồi kiểm thử lại hoặc cũng có trường hợp xấu là không được chấp nhận.
Để kiểm soát giai đoạn kiểm thử, tất cả các lỗi của các thành viên trong từng mô đun chức năng đều được ghi lại dưới dạng danh sách các lỗi dưới dạng bảng được mô tả ở phần trên. Bảng danh sách lỗi này được xem như tài liệu và được thông báo cho các bên có liên quan, nó rất hữu ích đối với các thành viên trong nhóm phát triển vì:
- Giúp các thành viên có kinh nghiệm hơn trong lập trình - Tránh được các lỗi trong khi lập trình
- Biết được lỗi xuất hiện ở vị trí nào, thuộc trách nhiệm của ai
- Biết được phần nào đã thực hiện kiểm thử giúp việc kiểm thử không bị trùng lặp hoặc có bỏ qua không kiểm thử.
Vì thời gian và điều kiện có hạn nên tôi chỉ xin đưa một số lỗi được trích ra từ tài liệu kiểm thử của nhóm phát triển làm dẫn chứng cho vấn đề được nêu ra.
TT Ngày phát hiện vấn đề (ghi cụ thể hiện
tượng)
Mô tả lỗi Loại (câu hỏi/yêu cầu) Tầm quan trọng Ngày ghi nhận Người phát hiện Thời hạn dự định xử lý Người phụ trách Ngày dự định kết thúc Ngày dự định phúc đáp việc xử lý Ngày thực sự hoàn tất Tình trạng 1 1. Khối học/lớp học 2. Lập danh sách lớp học theo khối==> chọn lớp học 3. Đăng ký môn chuyên==> báo lỗi
hộp thoại xuất hiện--> nhấn chuột 4 lần thì có bảng nhập môn chuyên nhưng không nhập được Lỗi Cao 20/07/11 Lình 25/07/11 Đạt 25/07/11 25/07/11 25/07/11 OK 2 1. Khối học/lớp học 2. Lập danh sách lớp học theo khối==> chọn lớp học 3. Tạo danh sách lớp tự động==> nhập theo yêu cầu
Cột tên lớp học không có form chuẩn, có thể nhập số ký tự bất kỳ không giống như đã có.
Yêu cầu Trung bình 20/07/11 Lình 25/07/11 Đạt 25/07/11 25/07/11 25/07/11 OK 3 1. Thực hiện nhập điểm và tính điểm tổng kết môn học 2. Chọn lệnh in Bảng điểm in ra không đúng như yêu cầu
Yêu cầu Trung
bình 26/07/11 Lình 01/08/11 Hiệp 01/08/11 01/08/11 01/08/11 OK
Cũng nhờ vào danh sách lỗi được thiết lập trong tài liệu kiểm thử mà ta thấy được số lượng lỗi của các thành viên trong nhóm phát triển cũng giảm đi theo thời gian. Việc số lỗi của các thành viên trong nhóm phát triển giảm đi là do: các thành viên thực hiện kiểm soát chất lượng của phần mềm mình tạo ra một cách nghiêm ngặt thông qua việc áp dụng các kỹ thuật hỗ trợ kiểm soát và nhờ vào tài liệu ghi lỗi của các thành viên để từ đó có tránh các lỗi thông thường. Để minh chứng cho điều này, dưới đây tôi đưa ra danh sách thống kê số lỗi gặp phải của các thành viên trong giai hai giai đoạn phát triển khác nhau.
STT Thành viên Số lỗi Trước Sau 1 A 40 15 2 B 43 18 3 C 48 20 4 D 50 20 5 E 55 25 6 F 58 24 7 G 60 25 8 H 67 27
Bảng 3.2: Thống kê số lỗi của các thành viên ở hai giai đoạn phát triển
Dựa vào kết quả thu được mà ta thấy rõ được vai trò việc áp dụng một số kỹ thuật hỗ trợ kiểm soát chất lượng phần mềm vào quá trình phát triển.