Bài giảng Kiểm tra phần mềm - Chương 7: Thanh tra, chạy thử & xem xét mã nguồn

Nội dung text: Bài giảng Kiểm tra phần mềm - Chương 7: Thanh tra, chạy thử & xem xét mã nguồn

1. ƒ Dùng các kỹ thuật kiểm thử tĩnh trong khoảng thời gian từ lúc phần mềm ₫ược viết ₫ến khi phần mềm có thể ₫ược kiểm thử bằng máy tính. ƒ Không có nhiều kết quả toán học ₫ánh giá về các kỹ thuật kiểm thử tĩnh vì chúng chỉ liên quan ₫ến con người. Kiểm thử thủ công TPPM cũng ₫ã ₫óng góp 1 phần cho tính tin cậy, công nghiệp của hoạt ₫ộng kiểm thử thành công TPPM : ƒ Các lỗi ₫ược phát hiện càng sớm càng giúp giảm chi phí sữa lỗi và càng giúp nâng cao xác xuất sữa lỗi ₫úng ₫ắn. ƒ Lập trình viên dễ dàng chuẩn bị tinh thần khi các kỹ thuật kiểm thử bằng máy tính bắt ₫ầu. Có nhiều phương pháp kiểm thử thủ công TPPM, trong ₫ó 2 phương pháp quan trọng nhất là thanh kiểm tra mã nguồn (Code Inspections) và chạy thủ công mã nguồn (Walkthroughs). Hai phương pháp này có nhiều ₫iểm giống nhau : ƒ Cần 1 nhóm người ₫ọc hay thanh kiểm tra trực quan TPPM. ƒ Các thành viên phải có chuẩn bị trước, không khí cuộc họp phải là "họp các ý kiến thẳng thắn, chân thành". ƒ Mục tiêu của cuộc họp là tìm các lỗi chứ không phải tìm biện pháp giải quyết lỗi. ƒ Chúng là sự cải tiến, tăng cường của 1 phương pháp kiểm thử cũ hơn là phương pháp "desk-checking" mà chúng ta sẽ giới thiệu sau. Hai phương pháp thanh kiểm tra mả nguồn và chạy thủ công mã nguốn có thể phát hiện ₫ược từ 30 tới 70% các lỗi viết mã nguồn và lỗi thiết kế luận lý của TPPM bình thường. Tuy nhiên 2 phương pháp này không hiệu quả trong việc phát hiện các lỗi thiết kế cấp cao như lỗi do hoạt ₫ộng phân tích yêu cầu TPPM :
2. ƒ Mỗi thành viên cần chuẩn bị thái ₫ộ khách quan, nhẹ nhàng trong buổi họp. Các tài liệu cần có cho mỗi thành viên (₫ã phân phát trước khi cuộc họp diễn ra) : ƒ Mã gnuồn TPPM cần kiểm thử. ƒ Danh sách các lỗi quá khứ thường gặp (checklist). Trong suốt cuộc họp, 2 hoạt ₫ộng chính sẽ xảy ra : 1. Hoạt ₫ộng 1 : ƒ Người lập trình sẽ giới thiệu tuần tự từng hàng lệnh cùng luận lý của TPPM cho các thành viên khác nghe. ƒ Trong khi thảo luận, các thanh viên khác ₫ưa ra các câu hỏi và theo dõi phần trả lời ₫ể xác ₫ịnh có lỗi ở hàng lệnh nào không ? (Tốt nhất là người lập trình, chứ không phải thành viên khác) sẽ phát hiện ₫ược nhiều lỗi trong phần giới thiệu mã nguồn này). 2. Hoạt ₫ộng 2 : ƒ Các thành viên cùng phân tích TPPM dựa trên danh sách các lỗi lập trình thường gặp trong quá khứ. Sau cuộc họp thanh kiểm tra mã nguồn : ƒ Người ₫iều hành sẽ giao cho người lập trình TPPM 1 danh sách chứa các lỗi mà nhóm ₫ã tìm ₫ược. ƒ Nếu số lỗi là nhiều hay nếu lỗi phát hiện ₫òi hỏi sự hiệu chỉnh lớn, người ₫iều hành sẽ sắp xếp 1 buổi thanh kiểm tra khác sau khi TPPM ₫ã ₫ược sửa lỗi. Chú ý : Các lỗi phát hiện ₫ược cũng sẽ ₫ược phân tích, phân loại và ₫ược dùng ₫ể tinh chỉnh lại danh sách các lỗi quá khứ ₫ể cải tiến ₫ộ hiệu quả cho các lần thanh kiểm tra sau này. Các hiệu ứng lề tích cực cho từng thành viên :
3. int list[10]; if (list[10] == 0) { } 3. Dùng chỉ số không thuộc kiểu nguyên của biến array ? int list[10]; double idx=3.1416; if (list[idx] == 0) { } 4. Tham khảo ₫ến dữ liệu không tồn tại (dangling references)? int *pi; if (*pi == 10) { } //pi ₫ang tham khảo ₫ến ₫ịa chỉ không hợp lệ - Null int *pi = new int; delete (pi); if (*pi = 10) { } //pi ₫ang tham khảo ₫ến ₫ịa chỉ //mà không còn dùng ₫ề chứa số nguyên 5. Truy xuất dữ liệu thông qua alias có ₫ảm bảo thuộc tính dữ liệu ₫úng ? int pi[10]; pi[1] = 25; char* pc = pi; if (pc[1] == 25) { } //pc[1] khác với pi[1]; 6. Thuộc tính của field dữ liệu trong record có ₫úng với nội dung gốc không ? struct {int i; double d;} T_Rec; T_Rec rec; read(fdin,&rec, sizeof(T_Rec); if (rec.i ==10) { } //lỗi nếu field d nằm trước i //trong record gốc trên file 7. Cấu trúc kiểu record có tương thích giữa client/server không ? Private Type OSVERSIONINFO dwOSVersionInfoSize As Long
4. 5. Giá trị khởi ₫ộng có tương thích với kiểu biến ? short IPAddress = inet_addr("203.7.85.98"); byte Port = 65535; 6. Có dùng các biến ý nghĩa khác nhau nhưng tên rất giống nhau không? int count, counts; Các lỗi tính toán (Computation Errors) 1. Thực hiện phép toán trên toán hạng không phải là số? CString s1, s2; int ketqua = s1/s2; 2. Thực hiện phép toán trên các toán hạng có kiểu không tương thích ? byte b; int i; double d; b = i * d; 3. Thực hiện phép toán trên các toán hạng có ₫ộ dài khác nhau ? byte b; int i; b = i * 500; 4. Gán dữ liệu vào biến có ₫ộ dài nhỏ hơn ? byte b; int i; b = i * 500; 5. Kết quả trung gian bị tràn? byte i, j, k; i = 100; j = 4; k = i * j / 5; 6. Phép chia có mẫu bằng 0 ? byte i, k;
5. if(a==2 && b==2 || c==3) { } 6. Cách thức tính biểu thức Bool của chương trình dịch như thế nào ? if(y==0 || (x/y > z)) Các lỗi luồng ₫iều khiển (Control-Flow Errors) 1. Thiếu thực hiện 1 số nhánh trong lệnh quyết ₫ịnh theo ₫iều kiện số học ? switch (i) { case 1: //cần hay không cần lệnh break; case 2: case 3: } 2. Mỗi vòng lặp thực hiện ít nhất 1 lần hay sẽ kết thúc ? for (i=x ; i z ngay từ ₫ầu thì sao ? for (i = 1; i <= 10; i ) { } //có dừng ₫ược không ? 3. Biên của vòng lặp có bị lệch ? for (i = 0; i <= 10; i++) { } //hay i < 10 ? 4. Có ₫ủ và ₫úng cặp token begin/end, {} ? Các lỗi giao tiếp (Interface Errors) 1. Số lượng tham số cụ thể ₫ược truyền có = số tham số hình thức của hàm ₫ược gọi ? 2. thứ tự các tham số có ₫úng không ? 3. thuộc tính của từng tham số thực có tương thích với thuộc tính của tham số hình thức tương ứng của hàm ₫ược gọi ? char* str = "Nguyen Van A"; MessageBox (hWnd, str,"Error", MB_OK); //sẽ bị lỗi khi dịch ở chế ₫ộ Unicode 4. Đơn vị ₫o lường của tham số thực giống với tham số hình thức ? double d = cos (90);
6. 7.4 Phương pháp chạy thủ công mã nguồn Giống như phương pháp thanh kiểm tra mã nguồn, phương pháp này bao gồm 1 tập các thủ tục và kỹ thuật phát hiện lỗi dành cho 1 nhóm người ₫ọc mã nguồn. Cần 1 cuộc họp dài từ 1 tới 4 giờ và không ₫ược ngắt quảng giữa chừng. Nhóm chạy thủ công gồm 3 tới 5 người : ƒ Lập trình viên nhiều kinh nghiệm ƒ Chuyên gia về ngôn ngữ lập trình ₫ược dùng ₫ể viết mã nguồn ƒ Lập trình viên mới ƒ 1 người mà sẽ bảo trì phần mềm ƒ 1 người từ project khác, 1 người cùng nhóm với lập trình viên mã nguồn cần kiểm thử. Các vai trò trong nhóm : ƒ Chủ tịch ₫iều hành ƒ Thư ký (người ghi lại các lỗi phát hiện ₫ược) ƒ Người kiểm thử Thủ tục ban ₫ầu cũng giống như thủ tục ban ₫ầu của phương pháp thanh kiểm tra mã nguồn. Thủ tục trong cuộc họp : ƒ Thay vì chỉ ₫ọc chương trình hay dùng danh sách lỗi thường gặp, các thành viên phải biến mình làm CPU ₫ể chạy thủ công mã nguồn. ƒ Người kiểm thử ₫ược cung cấp 1 tập các testcase. ƒ Trong cuộc họp, người kiểm thử sẽ thực thi từng testcase thủ công. Trạng thái chương trình (nội dung các biến) sẽ ₫ược ghi và theo dõi trên giấy hay trên bảng.
7. Đây là kỹ thuật ₫ánh giá, so sánh các tính chất của các chương trình tương tự như chất lượng tổng thể, ₫ộ bảo trì, ₫ộ mở rộng, ₫ộ sự dụng, ₫ộ trong sáng Mục ₫ích của phương pháp này là cung cấp cho người lập trình 1 sự tự ₫ánh giá. 7.7 Kết chương Chương này ₫ã trình bày lý do vì sao chúng ta cần kiểm thử TPPM một cách tĩnh, nghĩa là không cần dùng máy tính chạy trực tiếp TPPM mà chỉ khảo sát xem xét TPPM thủ công thông qua mắt người. Chúng ta ₫ã trình bày các phương pháp kiểm thử tĩnh TPPM như Desk Checking, thanh kiểm tra, chạy thủ công, peer rating. Ứng với mỗi phương pháp, chúng ta ₫ã trình bày các tính chất cơ bản của phương pháp ₫ó, nguồn nhân lực cần thiết và qui trình thực hiện kiểm thử.