Bài giảng Kiểm thử phần mềm (Software Testing) - Bài 3: Các cấp độ kiểm thử - Nguyễn Thị Thanh Trúc

ĐẠI HỌC CÔNG NGHỆ THÔNG TIN  
KHOA CÔNG NGHỆ PHẦN MỀM  
KIꢀM THꢁ PHẦN MỀM  
GV: ThS. Nguyễn Thị Thanh Trúc  
Khoa: Công nghệ Phần mềm  
Email: [email protected].vn  
1
BꢂI 3: Cꢃc cꢄp độ kiꢅm thử  
2
Một chiến thuật kiꢅm thử phổ biến  
• Bắt đầu tại từng module rồi tích hợp lớn dần đến  
toàn bộ hệ thống.  
• Các kỹ thuật khác nhau được sử dụng thích hợp  
tại các giai đoạn khác nhau.  
• Kiểm thử có thể được tiến hành bởi người phát  
triển phần mềm, nhưng đối với các dự án lớn thì  
việc kiểm thử phải được tiến hành bởi một nhóm  
độc lập.  
• Kiểm thử và sửa lỗi là các hoạt động độc lập  
nhưng việc sửa lỗi phải phù hợp với các chiến  
thuật kiểm thử.  
Kiꢅm thử từng module  
• Tiến hành kiểm thử trên từng đơn vị nhỏ nhất của  
phần mềm, đó là module mã nguồn, sau khi đã  
thiết kế, mã hoá và biên dịch thành công  
• Thường dùng kỹ thuật kiểm thử white-box  
• Có thể tiến hành kiểm thử cùng lúc nhiều module.  
• Một số vấn đề trong việc xây dựng các test case  
– Test case nào?  
– Dữ liệu đầu vào và đầu ra có tꢀ đâu?  
– Tính độc lập/phụ thuộc hoạt động của các module  
3.1 Kiꢅm thử đơn vị  
• Kiểm thử đơn vị nhằm kiểm tra đơn vị thiết kế  
nhỏ nhất một module phần mềm. Một module  
hoạt động thường có trao đổi thông tin với  
module mức dưới và mức trên nó, do đó phạm vi  
phát hiện lỗmodule này  
• Người tiến hành kiꢅm thử đơn vị: lập trꢁnh  
viên cùng nhóm của mꢁnh.  
• Kỹ thuật kiꢅm thử đơn vị: chủ yếu là hộp trắng,  
trong các trường hợp cần thiết có thể sử dụng  
thêm kỹ thuật kiểm thử hộp đen  
5
3.1.1 Mô hꢆnh kiꢅm thử đơn vị  
• Driver, stub  
6
Kiꢅm thử module  
• Mỗi module mã nguồn không phải là một chương  
trình hoàn chỉnh và đôi khi phải gọi các module chưa  
được kiểm thử khác có thể phải thiết lập driver  
và/hoặc stub: phí tổn khá lớn (70%)  
• Driver là một chương trình chính có nhiệm vụ nhận  
dữ liệu kiểm thử, chuyển dữ liệu đó xuống cho  
module để kiểm tra và in ra các kết quả kiểm tra  
tương ứng.  
• Stub thay thmodule đang  
kiểm tra.  
Làm thế nào để giảm các chi phí tạo driver hay stub  
3.1.2 Nội dung kiꢅm thử đơn vị  
• a) Kiểm thử giao diện(các tham số vào/ra qua giao  
diện)  
• b) Kiểm thử vào/ra (các file, bộ đệm và các lệnh  
đóng mở)  
• c) Kiểm thử ckhai báo và sử  
dụng biến)  
• d) Kiểm thử xử lꢂ (các phép toán và tính đúng đắn  
của kết quả)  
• e) Kiểm thử điều kiện logic  
• f) Kiểm thử sai tiềm ẩn (về ngoại lệ, mô tả)  
• g) Kiểm thử các giá trị biên  
8
a. Kiꢅm thử dữ liệu qua giao diện  
• Kiểm thử dꢃng dữ liệu qua giao diện của  
module liên quan đến định lượng và định  
dạng của các biến và các module sử dụng  
trên giao diện  
• Đặc trưng cụ thể:  
– Số lượng?  
– Định dạng?  
9
a. Kiểm thử dữ liệu qua giao diện  
• Các đặc trưng qua giao diện là:  
• Số tham số= số đối số?  
• Tính chất của tham số= tính chất của đối số  
• Đơn vị của tham số= đơn vị của đối số  
• Số đối số được truyền gọi module= số các tham số đầu vào của module?  
• Thứ tự truyền tham số ko chính xác  
…
• Ví dụ:  
String calc_day(date d) {…}  
Void calc_day_test()  
{
date d;  
string s;  
…
d= calc_day(s);// truyền tham số ko chính xác  
…
10  
}
b. Kiểm thử vào/ra  
• Kiểm thử các file, bộ đệm, các lệnh đóng, mở  
• Khi thực hiện kiểm thử vào/ ra cần xem xét:  
– Tính chất của các file có đúng đắn ko?  
– Các câu lệnh OPEN/CLOSE có đúng đắn ko?  
– Đặc tả hꢁnh thức có đúng đắn ko?  
– Các file có mở trước khi sử dụng ko?  
– Các điều kiện end of file có được xử lꢂ không?  
– Có sai văa?  
11  
c. Kiểm thử cấu trúc dữ liệu cục bộ  
• Kiểm thử khai báo và sử dụng biến  
• Cấu trúc dữ liệu cục bộ cho module có thể sai. Vꢁ thế  
thiết kế các kiểm thử cần làm lộ ra các loại lỗi sau:  
– Đánh máy ko đúng hoặc ko nhất quán?  
– Giá trị ngầ
– Tên các biến ko đúng (sai chữ hoặc mất chữ)  
– Kiểu dữ liệu không nhất quán  
Vd:  
int i;  
d= i*10; // lỗi chưa khai báo biến d  
12  
d. Kiểm thử về các xử lꢂ  
• Kiểm thử các phép toán và tính đúng đắn của kết quả  
• Cần lưu ꢂ các sai về trꢁnh tự, độ chính xác:  
– Thứ tự ưu tien các phép tính số học  
– Sự nhất quán của các phép toán trộn module  
– Khởi tạo/kết thúhông đúng  
– Độ chính xác của kết quả trả về  
• Ví dụ:  
– Thực hiện phép toán trên toán hạng ko phải là số:  
– String s1, s
– Int ketqua=s1/s2;  
13  
e. Kiểm thử các điều kiện logic  
• Các sai kiểu, toán tử, ngữ nghĩa:  
– So sánh các kiểu dữ liệu khác nhau  
– Ưu tiên hoặc toán tử logic không đúng đắn  
– Dự đoán một biểu thức so sánh, trong khi sai số làm cho  
đẳng thức 
– Các giá trị so sánh không đúng đắn  
• Ví dụ:  
int ival;  
char sval
If(ival==sval) {…} //So sánh 2 dữ liệu ko tương thích  
14  
f. Kiểm thử sai tiềm ẩn  
• Các sai tiềm ẩn cần được xem xét là:  
– Mô tả sai(khó hiểu)  
– Dữ liệu ghi không tương ứng với sai đꢄ gặp  
– Điều kiện sai có trước khi xử lꢂ sai  
– Xử lꢂ điều n  
– Mô tả sai không cung cấp đủ thông tin để trợ giúp định vị  
nguyên nhân của sai  
• Ví dụ:  
If (a>0) th
If (a=0) then {…} // thiếu trường hợp xét a<0  
15  
g. Kiểm thử các giá trị biên  
• Các sai biến, số vꢃng lặp:  
– Vꢃng lặp không kết thúc hoặc kết thúc không chính xác  
– Lặp vô hạn  
– Biến lặp bị thay đổi không chính xác  
• Sai ở các biên:  
– Kiểm thử ở biên là nhiệm vụ cuối cùng của kiểm thử đơn  
vị. Các giá trị ở biên thường hay gây ra lỗi.  
• VD:  
Int i,j;  
For (i=1;i<=10,i++)  
For (j=i+1, j<=10, j++) {…}  
16  
3.1.3 Kỹ thuật kiꢅm thử đơn vị  
• Module không phải là một chương trꢁnh độc lập,  
nên cần phát triển thêm các Driver và Stub để tiến  
hành kiểm thử đơn vị.  
• Bộ lꢃi (driver): là một hàm main điều khiển việc  
đưa dữ liệu a module  
đang cần kiểm thử  
• Cuống (stub): là một chương trꢁnh máy tính dùng  
để thay thế cho một module phần mềm sẽ được  
xác định sau (IEEE)  
• Stub (dummy program): Là một đoạn mꢄ dùng để  
mô phỏng hoạt động của thành phần cꢃn thiếu.  
17  
3.1.3 Kỹ thuật kiꢅm thử đơn vị  
18  
Code example -Stub  
void function WeTest(params…) {  
….  
int p= price(param1);  
….  
} // chương trꢀnh chính  
void price(int param) {  
return 10; //không cần quan tâm giá là gꢀ, được  
tính thế nào cst module  
function WeTest  
} // đây là stub  
19  
Code example- Driver  
void function ThatCallPrice(params…) {// đây là  
driver  
int p= price(param1);  
printf(“Price is:%d”,p);  
}
void price(int param){  
….  
// chương trꢁnh chính để tính được giá trị thật  
…
}
20  
Tải về để xem bản đầy đủ
pdf 47 trang yennguyen 13180 Free
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Kiểm thử phần mềm (Software Testing) - Bài 3: Các cấp độ kiểm thử - Nguyễn Thị Thanh Trúc", để tải tài liệu gốc về máy hãy click vào nút Download ở trên

File đính kèm:

  • pdfbai_giang_kiem_thu_phan_mem_software_testing_bai_3_cac_cap_d.pdf