0 Giới thiệu
Nhóm trình bày
Nhóm 5 - Điện tử 10
Nội dung trình bày
Pha kiểm thử trong kĩ thuật thiết kế phần mềm
Trình tự trình bày
1 khái niệm kiểm thử ( Phan Trung Kiên)
2. Các phương pháp kiển thử ( Nguyễn M Tiến)
3. Thiết kế trường hợp thử ( Hoàng Việt Anh)
4. Chiến lược kiểm thử ( Tạ Hồng Nam)


1 Khái niệm kiểm thử
1.1 Khái niện kiểm thử
1.2 Những khó khăn khi kiểm thử
1.3 Một số chú ý
1.1 Khái niện kiểm thử
Là pha quan trọng trong quá trình phát triển hệ thống giúp cho người xây dựng hệ thống và khác hàng đã thấy được hệ thống mới đã thảo mãn yêu cầu đề ra chưa.
Là tiến trình nhằm phát hiện lỗi bằng việc xem xét lại đặc tả, thiết kế và mã hoá.
Kiểm thử thành công là phát hiện ra lỗi: kiểm thử không phát hiện ra lỗi là kiểm thử dở
1.1 Khái niện kiểm thử
Sơ đồ kiểm thử:


Thiết kế trường
hợp

kiểm thử




Chuẩn bị dữ kiệu
kiểm thử

Chạy trương trình
với dữ kiệu kiểm thử
Trường hợp
kiểm thử
dữ liệu kiểm thử
Kết quả kiểm thử
Báo cáo
kiểm thử
So sánh kết quả với
các trường hợp kiểm thử
1.2 Những khó khăn khi kiểm thử
Nâng cao chất lượng phần mềm nhưng không vượt quá chất lượng thiết kế. chỉ phát hiện các lỗi tiềm tàng và sửa chúng
Phát hiện lỗi bị hạn chế do thủ công là chính
Dễ bị ảnh hưởng tâm lý khi kiểm thủ.
Khó đảm bảo tính đầu đủ của kiểm thử.

1.3 Một số chú ý
Chất lượng phần mềm do khâu thiết kế quyết định là chủ yếu, chứ không phải khâu kiểm thử.
Tính dễ kiểm thử phụ thuộc vào cấu trúc chương trình.
Người kiểm thử và người phát triển nên khác nhau
Dữ liệu kiểm thử phải phát hiện ra lỗi mới có tác dụng
Khi phát sinh thêm trưòng hợp thử thì nên thử lại những truờng hợp thử trước đó để tránh ảnh hưởng lan truyền sóng.

2 Các phương pháp thử
2.1 Thử tĩnh
2.2 Thử động
2.1 Thử tĩnh
Khái niệm
Phương pháp thử phần mềm thông qua việc sử dụng giấy, bút trên bàn để kiểm tra logic, lần từng chi tiết ngay sau khi lập trình xong
Chủ yếu kiểm tra mã, các tài liệu đặc tả
Các phương pháp thử tĩnh
Thanh tra
Duyệt

2.1.1 Thanh tra
Khái niệm
Phương pháp kiểm tra ngang hàng sản phẩm phần mềm thực hiện bởi những người nghiên cứu riêng lẻ để tìm ra những lỗi có thể bằng một tiến trình chuẩn cho trước
Một cuộc thanh tra bao gồm:
Đặc tả phần mềm
Kế hoạch thanh tra
Sản phẩm phần mềm
Điều phối viên
Thanh tra viên
Tác giả phần mềm

2.1.1 Thanh tra
Tiến trình thanh tra:
1. Lên kế hoạch
2. Gặp gỡ trước
3. Chuẩn bị
4. Gặp gỡ thanh tra
5. Gia công lại
6. Bám sát
Chú ý: các khâu 3,4,5 có thể thực hiện lặp lại
2.1.2 Duyệt
Khái niệm:
Là một phương pháp kiểm tra ngang hàng với một người thiết kế hướng nhóm phát triển đến các hoạt động chú ý của quá trình sản xuất phần mềm, tham gia đặt câu hỏi và chú thích cho các lỗi có thể có.
Khác biệt với thanh tra:
Cấu trúc mở
Khả năng gợi ý định hướng thay đổi phần mềm

2.1.2 Duyệt
Tiến trình duyệt:
1. Đánh giá đầu vào
2. Chuẩn bị quản lí
3. Lập kế hoạch
4. Gặp gỡ trước
5. Chuẩn bị riêng
6. Duyệt
7. Gia công/ bám sát
8. Kết thúc, đánh giá
2.2 Thử động
Khái niệm
Phương pháp thử phần mềm thông qua việc dùng máy chạy chương trình để điều tra trạng thái từng động tác của chương trình
Tiến trình thử động:
Thiết kế trường hợp thử theo thử tĩnh
Trường hợp thử có kết quả kì vọng
Dịch chương trình nguồn và tạo modul tải để thử
Xác định miền vào ra của tệp nếu cần thiết
Nhập dữ liệu cho truờng hợp thử
Điều chỉnh môi trường thực hiện modul tải
Thực hiện modul tải và ghi nhận kết quả
Xác nhận kết quả
Lặp lại thao tác từ 5-8

2.2 Thử động
Các phương pháp thử động:
Thử nghiệm khuyết tật
Thử nghiệm thống kê
2.2.1 Thử nghiệm khuyết tật
Khái niệm:
Phương pháp thử để tìm ra khuyết tật của phần mềm chủ yếu là lỗi lập trình
Các loại thử nghiệm khuyết tật
Thử nghiệm chức năng
Thử nghiệm cấu trúc
3.Thiết kế trường hợp thử
3.1 Khái niệm
3.2 Vai trò
3.3 Tiến trình thiết kế
3.1 Khái niệm

Quá trình thiết kế trường hợp thử là quá trình xây dựng các phương pháp kiểm thử có thể phát hiện lổi ,sai sót khiếm khuyết của phần mềm để xây dựng một phần mềm đạt tiêu chuẩn
3.2 Vai trò
Tạo ra các trường hợp kiểm thử tốt nhất có khả năng phát hiện ra lỗi, sai sót của phần mềm một cách nhiều nhất.
Tạo ra các trường hợp kiểm thử có chi phí rẽ nhất đồng thời tốn ít thời gian và công sức nhất
3.3 Tiến trình thiết kế

3.3.1 Kiểm thử hộp trắng(White box)
3.3.2 Kiểm thử hộp đen (Black Box)
3.3.3 Kiểm thử Top-Down, Botton-up
3.3.1 Kiểm thử hộp trắng
Khái niệm:
Kiểm thử hộp trắng là kiểm tra cấu trúc và logic phần mềm theo mục tiêu(Trong trường hợp này yêu cầu người kiểm thử phải biết ngôn ngữ lập trình)
Kiểm tra trạng thái của chương trình tại nhiều điểm của chương trình

3.3.1 Kiểm thử hộp trắng
Tiến trình:

Kiểm thử đường diễn tiến của chương trình
Kiểm thử cấu trúc điều khiển


3.3.1 Kiểm thử hộp trắng
Kiểm thử đường diễn tiến của chương trình
Khái niêm: Là việc thiết kế các trường hợp kiểm thử trên từng câu lệnh trong chương trình được sẽ được thực hiện ít nhất 1 lần không quan tâm đến ảnh hưởng lên các đường quyết định.


3.3.1 Kiểm thử hộp trắng

Các bước tiến hành:
Dùng tài liệu thiết kế hay mã nguồn để vẽ thuật toán của chương trình hay hàm
Xác định đồ thị V(G)
Từ đồ thị xác định tập đường độc lập tuyến tính lẫn nhau
Xây dựng trường hợp kiểm thử dựa trên tập đường xác định ở trên

3.3.1 Kiểm thử hộp trắng

Ví dụ: xét thủ tục average
Int average( )
{int value[100];
int average,totalinput, totalvalid,
minimum, maximum, sum;
int i;
i=0;
totalinput = totalvalid =0;
sum = 0;

3.3.1 Kiểm thử hộp trắng
while( value[i]<>-999 and totalinput <100
totalinput ++;
if( value[i] >= minimum AND value[i] < maximum)
{
totalvalid ++;
sum = sum + value[i]
}


3.3.1 Kiểm thử hộp trắng
i++;
)
if( totalvalid > 0 ){
average = sum/totalvalid
}
else{
average = -999


3.3.1 Kiểm thử hộp trắng









3.3.1 Kiểm thử hộp trắng
Có 6 đường kiểm thử:
Đường 1 : 1-2-10-11-13Đường 2 : 1-2-10-12-13Đường 3 : 1-2-3-10-11-13Đường 4 : 1-2-3-4-5-8-9-2 ...Đường 5 : 1-2-3-4-5-6-8-9-2 ...Đường 6 : 1-2-3-4-5-6-7-8-9-2 ...









3.3.1 Kiểm thử hộp trắng
Kiểm thử cấu trúc điều khiển

Kiểm thử các biểu thức điều kiện

Kiểm thử luồng dữ liệu(DTF)

Kiểm thử vòng lặp

3.3.1 Kiểm thử hộp trắng

Kiểm thử cấu trúc điều khiển
nhất 1 lần không quan tâm đến ảnh hưởng lên các đường quyết định.




3.3.2 Kiểm thử hộp đen
Mục đích của kiểm thử hộp đen là
Bổ xung cho phương pháp kiểm thử hộp trắng để phát hiện ra tất cả các lỗi khác nhau mà kiểm thử hộp trắng không phát hiện ra được
Khái niệm :là phương pháp tập trung về mặt yêu cầu chức năng của sản phẩm. Có thể tạo ra một bộ các điều kiện đầu vào để kiểm thử tất cả
3.3.2 Kiểm thử hộp đen
Kiểm thử hộp đen bao gồm:
Phân vùng tương đương
Phân tích giá trị biên
Kỹ thuạt Cause-Effed Graphing

4 Chiến lược kiểm thử
4.1 Các công đoạn kiểm thử
4.2 Kiểm thử Mô đun
4.3 Kiểm thử tích hợp
4.4 Kiểm thử hệ thống
4.5 Kiểm thử big bang
4.1 Các công đoạn kiểm thử
Quá trình kiểm thử có thể chia làm các giai đoạn :
Kiểm thử mô đun
Kiểm thử tích hợp
Kiểm thử hệ con
Kiểm thử hệ thống
Kiểm thử big bang
Kiểm thử nghiệm thu
Kiểm thử Alpha
Kiểm thử Beta
4.2 Kiểm thử mô đun
Kiểm tra một đơn vị thiết kế nhỏ nhất – một mô đun – của phần mềm.
Người tiến hành kiểm thử thông thường là người lập trình mô đun đó hoặc lập trình viên cùng nhóm.
Các mô đun thứ cấp của mô đun được kiểm thử nếu chưa được phát triển sẽ được thay bằng các chương trình tạm thời gọi là các stub.
Mô đun thượng cấp được thay bằng một trình điều khiển kiểm thử gọi là test driver.
4.2 Kiểm thử mô đun
Ví Dụ:
4.2 Kiểm thử mô đun
VD:
String calc_day(Date d)
{
return "Sunday";
}
hoặc:
String calc_day(Date d)
{
String s;
cout << ”Enter day_of_week of ”<< d;
cin >> s;
return s;
}
4.2 Kiểm thử mô đun
VD:Dưới đây là một ví dụ đơn giản về test driver của nó:
void calc_day_test_drive()
{
Date d;
String s;
while (1) {
cout << ”Enter date: ”);
cin >> d;
s = calc_day(d);
cout << s << endl;
}
}
4.3 Kiểm thử tích hợp
Tích hợp các mô đun và kiểm thử chúng dưới một thể thống nhất.
Các đơn vị phần mềm (unit) được tích hợp dần thành các mô đun, hệ con, và cuối cùng là thành hệ thống hoàn chỉnh.
Một số lỗi giao diện (mô đun) điển hình:
Sử dụng sai giao diện
Hiểu nhầm về giao diện
Xung đột
4.3 Kiểm thử tích hợp
Các chiến lược kiểm thử tích hợp:

Kiểm thử dưới lên (bottom-up testing)

Kiểm thử trên xuống (top-down testing)

Kiểm thử hồi qui (regression testing)

4.3.1 Kiểm thử dưới lên
Là quá trình tích hợp và kiểm thử với các mô đun ở mức độ thấp trước.
Thông thường người ta không thuần túy kiểm thử tất cả các mô đun ở tầng dưới cùng mà nhóm các mô đun này thành các nhóm chức năng, tích hợp và kiểm thử chúng theo từng nhóm.
Tiến hành tích hợp và kiểm thử một số mô đun cấp trên trước
4.3.1 Kiểm thử dưới lên
VD:
4.3.1 Kiểm thử dưới lên
Kiểm thử dưới lên có một số ưu điểm:
Tránh phải tạo các stub phức tạp hay tạo các kết quả nhân tạo
Thuận tiện cho phát triển các mô đun thứ cấp dùng lại được

Nhược điểm của phương pháp bottom-up:
Phát hiện chậm các lỗi thiết kế
Chậm có phiên bản thực hiện được của hệ thống
4.3.2 Kiểm thử trên xuống
Kiểm thử trên xuống tiến hành kiểm thử với các mô đun ở mức cao trước, các mô đun mức thấp được tạm thời phát triển với các chức năng hạn chế.
Thông thường, để sớm có một phiên bản thực hiện người ta thường tích hợp theo một nhánh cho đến các mô đun cấp thấp nhất.
4.3.2 Kiểm thử trên xuống
VD:
4.3.2 Kiểm thử trên xuống
Ưu điểm của kiểm thử trên xuống
Phát hiện sớm các lỗi thiết kế
Có phiên bản hoạt động sớm
Nhược điểm của kiểm thử trên xuống
Khó có thể mô phỏng được các chức năng của mô đun cấp thấp phức tạp
Không kiểm thử đầy đủ các chức năng
Trên thực tế người ta thường tìm cách phối hợp hai chiến lược này, gọi là sandwich testing


4.3.3 Kiểm thử hồi qui
Là tiến hành lại các phép thử đã thành công mỗi khi tích hợp thêm mô đun hoặc khi cập nhật mã nguồn chương trình
4.3.3 Kiểm thử hồi qui
Khi chúng ta tích hợp thêm mô đun vào hệ thống hoặc khi tiến hành nâng cấp chương trình thì sẽ tạo ra một số tổ hợp trạng thái mới dẫn đến:
Xuất hiện lỗi ở mô đun trước đây chưa gây lỗi
Khắc phục một lỗi mới có thể sẽ làm ảnh hưởng tới một lỗi chúng ta đã sửa
Sinh ra lỗi mới mà trước đây chưa có

4.4 Kiểm thử hệ thống
Kiểm thử khả năng hoạt động của hệ thống
Kiểm tra các vấn đề về hiệu năng của hệ thống, khả năng phục hồi khi gặp sự cố,…
4.4 Kiểm thử hệ thống
Một số các dạng kiểm thử hệ thống chính
Kiểm thử phục hồi (recovery testing)
Kiểm thử gây áp lực (stress testing)
Kiểm thử hiệu suất (performance testing)
4.4.1 Kiểm thử phục hồi
Là các kiểm thử được tiến hành nhằm làm hệ thống ngừng hoạt động và đánh giá khả năng phục hồi sau đó
Với các hệ thống có khả năng phục hồi tự động, chúng ta cần đánh giá các công đoạn tái thiết lập thông số, khả năng khôi phục dữ liệu và tái khởi động
Với các trường hợp đòi hỏi khởi động lại thủ công, chúng ta cần đánh giá thời gian ngừng để sửa chữa (MTTR – Mean Time To Repair) và trong một số trường hợp đánh giá cả chi phí cho việc khôi phục.
4.4.2 Kiểm thử gây áp lực
Đây là loại (bước) kiểm thử được tiến hành khi đã có phiên bản làm việc, nhằm tìm hiểu hoạt động của hệ thống trong các trường hợp tải trọng lớn (dữ liệu lớn, số người sử dụng lớn, tài nguyên hạn chế...)
4.4.2 Kiểm thử gây áp lực
Mục đích của kiểm thử áp lực là:
Tìm hiểu giới hạn chịu tải của hệ thống
Tìm hiểu về đặc trưng của hệ thống khi đạt và vượt giới hạn chịu tải (khi bị sụp đổ)
Ngoài ra kiểm thử áp lực còn nhằm xác định các trạng thái đặc biệt như tổ hợp một số điều kiện dẫn đến sự sụp đổ của hệ thống; tính an toàn của dữ liệu, của dịch vụ khi hệ thống sụp đổ
4.4.3 Kiểm thử hiệu suất
Kiểm thử hiệu suất (performance testing) được thiết kế để đánh giá hiệu suất hoạt động của phần mềm trong một ngữ cảnh cho trước, thông thường là trong một môi trường tích hợp các phần mềm và phần cứng cụ thể
Được tiến hành ở tất cả các công đoạn kiểm thử
4.4.3 Kiểm thử hiệu suất
Kiểm thử hiệu suất liên quan chặt chẽ đến ngữ cảnh sử dụng bao gồm cả các phần mềm khác (hệ điều hành, CSDL,…) và môi trường phần cứng (CPU, bộ nhớ, mạng)
Kiểm thử hiệu suất thường được tiến hành cùng với kiểm thử áp lực
4.5 Kiểm thử big bang
Kiểm thử big bang (big bang testing) là một chiến lược kiểm thử hệ thống tiến hành một lần duy nhất khi đã phát triển toàn bộ các mô đun và tích hợp thành một phần mềm hoàn chỉnh
Phương pháp này vẫn thường được tiến hành khi phát triển các phần mềm có kích thước nhỏ