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

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 : 
 ƒ Các hoạt ₫ộng con người thường chỉ tìm ₫ược các lỗi dễ. 
 ƒ Do ₫ó 2 phương pháp kiểm thử tĩnh này chỉ bổ trợ thêm 
 cho các kỹ thuật kiểm thử chính qui bằng máy tính. 
7.2 Phương pháp thanh kiểm tra mã nguồn 
 Bao gồm các thủ tục và các kỹ thuật phát hiện lỗi nhờ 1 nhóm 
người cùng ₫ọc mã nguồn. Các vấn ₫ề bàn cải liên quan ₫ến 
phương pháp thanh kiểm tra là các thủ tục vận hành, các form kết 
quả cần tạo ra. 
 ƒ Một nhóm thanh kiểm tra mã nguồn thường gồm 4 người : 
 ƒ người ₫iều hành (chủ tịch hội ₫ồng), thường là kỹ sư QC 
 ƒ lập trình viên TPPM cần kiểm thử. 
 ƒ Kỹ sư thiết kế TPPM (nếu không phải là lập trình viên 
 TPPM này) 
 ƒ Chuyên gia kiểm thử 
1. Người ₫iều hành : 
 ƒ nên là người lập trình kinh nghiệm, uy tín. 
 ƒ không nên là tác giả TPPM cần kiểm thử và không cần 
 biết chi tiết về TPPM cần kiểm thử. 
2. Các nhiệm vụ : 
 ƒ Phân phối các tài liệu cho các thành viên khác trước khi 
 cuộc họp diễn ra. Lập lịch cho buổi họp thanh kiểm tra. 
 ƒ Điều khiển cuộc họp thanh kiểm tra. 
 ƒ Ghi nhận các lỗi phát hiện ₫ược bởi các thành viên. 
Công việc chuẩn bị : 
 ƒ Thời gian và ₫ịa ₫iểm buổi họp : làm sao tránh ₫ược các 
 ngắt quảng từ ngoài. 
 ƒ Thời lượng tối ưu cho mỗi buổi họp là từ 90 tới 120 phút. 
 ƒ 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 : 
 ƒ Người lập trình thường nhận ₫ược các style lập trình tốt mà 
 mình chưa biết, cách thức chọn lựa giải thuật tốt ₫ể giải 
 quyết bài toán, các kỹ thuật lập trình tốt,.. 
 ƒ Các thành viên khác cũng vậy. 
 ƒ Quá trình thanh kiểm tra mã nguồn là 1 cách nhận dạng 
 sớm nhất các vùng code chứa nhiều lỗi, giúp ta tập trung 
 sự chú ý hơn vào các vùng code này trong suốt quá trình 
 kiểm thử dựa trên mày tính sau này. 
7.3 Checklist ₫ược dùng ₫ể thanh tra mã nguồn 
 Checklist liệt kê các lỗi mà người lập trình thường phạm phải. 
Đây là kết quả của 1 lịch sử thanh tra mã nguồn bởi nhiều người, 
và ta có thể bỏ bớt/thêm mới các lỗi nếu thấy cần thiết. Các lỗi mà 
người lập trình thường phạm phải ₫ược phân loại thành các nhóm 
chính : 
 1. Các lỗi truy xuất dữ liệu (Data Reference Errors) 
 2. Các lỗi ₫ịnh nghĩa/khai báo dữ liệu (Data-Declaration 
 Errors) 
 3. Các lỗi tính toán (Computation Errors) 
 4. Các lỗi so sánh (Comparison Errors) 
 5. Các lỗi luồng ₫iều khiển (Control-Flow Errors) 
 6. Các lỗi giao tiếp (Interface Errors) 
 7. Các lỗi nhập/xuất (Input/Output Errors) 
 8. Các lỗi khác (Other Checks) 
Các lỗi truy xuất dữ liệu (Data Reference Errors) 
 1. Dùng biến chưa có giá trị xác ₫ịnh ? 
 int i, count; 
 for (i = 0; i < count; i++) {...} 
 2. Dùng chỉ số của biến array nằm ngoài phạm vi ? 
 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 
 dwMajorVersion As Long 
 dwMinorVersion As Long 
 dwBuildNumber As Long 
 dwPlatformId As Long 
 szCSDVersion As String * 128 ' Maintenance string 
 End Type 
 Private Declare Function GetVersionEx Lib "kernel32" _ 
 Alias "GetVersionExA" (lpVersionInformation As 
OSVERSIONINFO) As Long 
 8. Dùng chỉ số bị lệch ? 
 int i, pi[10]; 
 for (i = 1; i <= 10; i++) pi [i] = i; 
 9. Class có hiện thực ₫ủ các tác vụ trong interface mà nó 
 hiện thực không ? 
 10. Class có hiện thực ₫ủ các tác vụ "pure virtual" của class 
 cha mà nó thừa kế không ? 
Các lỗi khai báo dữ liệu 
 1. Tất cả các biến ₫ều ₫ược ₫ịnh nghĩa hay khai báo tường 
 minh chưa? 
 int i; 
 extern double d; 
 d = i*10; 
 2. Định nghĩa hay khai báo ₫ầy ₫ủ các thuộc tính của biến dữ 
 liệu chưa? 
 static int i = 10; 
 3. Biến array hay biến chuỗi ₫ược khởi ₫ộng ₫úng chưa ? 
 int pi[10] = {1, 5,7,9} ; 
 4. Kiểu và ₫ộ dài từng biến ₫ã ₫ược ₫ịnh nghĩa ₫úng theo 
 yêu cầu chưa ? 
 short IPAddress; 
 byte Port; 
 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; 
 i = 100 / k; 
 7. Mất ₫ộ chính xác khi mã hóa/giải mã số thập phân/số nhị 
 phân ? 
 8. Giá trị biến nằm ngoài phạm vi ngữ nghĩa ? 
 int tuoi = 3450; 
 tuoi = -80; 
 9. Thứ tự thực hiện các phép toán trong biểu thức mà người 
 lập trình mong muốn có tương thích với thứ tự mà máy 
 thực hiện? Người lập trình hiểu ₫úng về thứ tự ưu tiên các 
 phép toán chưa ? 
 double x1 = (-b-sqrt(delta)) / 2*a; 
 10. Kết quả phép chia nguyên có chính xác theo yêu cầu 
 không ? 
 int i = 3; 
 if (i/2*2) == i) {...} 
Các lỗi so sánh (Comparison Errors) 
 1. So sánh 2 dữ liệu có kiểu không tương thích ? 
 int ival; 
 char sval[20]; 
 if (ival == sval) {...} 
 2. So sánh 2 dữ liệu có kiểu không cùng ₫ộ dài ? 
 int ival; 
 char cval; 
 if (ival == cval) {...} 
 3. Toán tử so sánh ₫úng ngữ nghĩa mong muốn? Dễ lộn giữa 
 = và ≠, =, and và or... 
 4. Có nhầm lẫn giữa biểu thức Bool và biểu thức so sánh ? 
 if (2 < i < 10) {...} 
 if (2 < i && i < 10) {...} 
 5. Có hiễu rõ thứ tự ưu tiên các phép toán ? 
 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); 
 5. Tham số read-only có bị thay ₫ổi nội dung bởi hàm không 
 ? 
 6. Định nghĩa biến toàn cục có tương thích giữa các module 
 chức năng không ? 
Các lỗi nhập/xuất (Input/Output Errors) 
 1. Lệnh mở/tạo file có ₫úng chế ₫ộ và ₫ịnh dạng truy xuất 
 file? 
 if ((fdout = open ("tmp0", O_WRONLY| O_CREAT| 
O_BINARY, S_IREAD| S_IWRITE)) < 0) 
 pr_error_exit("Khong the mo file tmp0 de ghi"); 
 if ((fdtmp = open ("tmp2", O_RDWR | O_CREAT | 
O_BINARY, S_IREAD | S_IWRITE)) < 0) 
 2. Kích thước của buffer có ₫ủ chứa dữ liệu ₫ọc vào không ? 
 char buffin[100]; 
 sl = read(fd, bufin, MAXBIN); //MAXBIN <= 100 ? 
 3. Có mở file trước khi truy xuất không ? 
 4. Có ₫óng file lại sau khi dùng không ? Có xử lý ₫iều kiện 
 hết file ? 
 5. Có xử lý lỗi khi truy xuất file không ? 
 6. Chuỗi xuất có bị lỗi từ vựng và cú pháp không ? 
Các lỗi khác (Other Checks) 
 1. Có biến nào không ₫ược tham khảo trong danh sách tham 
 khảo chéo (cross-reference)? 
 2. Cái gì ₫ược kỳ vọng trong danh sách thuộc tính ? 
 3. Có các cảnh báo hay thông báo thông tin ? 
 4. Có kiểm tra tính xác thực của dữ liệu nhập chưa ? 
 5. Có thiếu hàm chức năng ? 
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. 
Lưu ý : 
 ƒ Các testcase thường ở mức ₫ơn giản ₫ể phục vụ như là 
 phương tiện ₫ể bắt ₫ầu và gợi câu hỏi người lập trình về 
 logic thuật giải cũng như những giả ₫ịnh của anh ta. 
 ƒ Thái ₫ộ của từng người tham dự là quan trọng. 
 ƒ Các chú thích nên hướng ₫ến chương trình thay vì ₫ến 
 người lập trình. 
 ƒ Chạy thử thủ công nên có qui trình theo sau tương tự như 
 ₫ã diễn tả cho phương pháp thanh kiểm tra. 
 ƒ Phương pháp chạy thủ công mã nguồn cũng tạo ₫ược các 
 hệu ứng lề y như phương pháp thanh kiểm tra. 
7.5 Phương pháp kiểm tra thủ công (Desk-checking) 
 Phương pháp kiểm tra thủ công có thể ₫ược xem như là 
phương pháp thanh kiểm tra hay phương pháp chạy thủ công mà 
chỉ có 1 người tham gia thực hiện : người này sẽ tự ₫ọc mã nguồn, 
tự kiểm tra theo danh sách lỗi thường gặp hay chạy thủ công và 
theo dõi nội dung các biến dữ liệu. 
 Đối với hầu hết mọi người, phương pháp này không ₫ược công 
nghiệp cho lắm : 
 ƒ Đây là 1 qui trình hoàn toàn không "undisciplined". 
 ƒ Ta thường không thể kiểm thử hiệu quả chương trình do 
 mình viết vì chủ quan, thiên vị....⇒ nên ₫ược thực hiện bởi 
 người khác, chứ không phải là tác giả của phần mềm. 
 Kém hiệu quả hơn nhiều so với 2 phương pháp trước. Hiệu ứng 
synergistic của 2 phương pháp trước. 
7.6 Phương pháp so sánh với phần mềm tương tự (Peer 
Ratings) 
 Phương pháp này không kiểm thử trực tiếp phần mềm, mục 
tiêu của nó không phải ₫ể tìm lỗi của phần mềm. 
 Đâ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ử.