Tài liệu Kỹ nghệ phần mềm ppt

Trang 1

B ộ môn Công nghệ phần mềm – Khoa CNTT- ĐHCN- ĐHQGHN K ỹ nghệ phần mềm Slide 1

Bài 7:

X ác minh và thẩm định

KỸ NGHỆ PHẦN MỀM

Trang 3

© Bộ môn Công nghệ phần mềm – Khoa CNTT- ĐHCN- ĐHQGHN Kỹ nghệ phần mềm Slide 3

Trang 4

 Xác minh (Verification)

- có đúng đặc tả không, có đúng thiết kế không

- phát hiện lỗi lập trình

 Thẩm định (Validation)

- có đáp ứng nhu cầu người dùng không

- có hoạt động hiệu quả không

- phát hiện lỗi phân tích, lỗi thiết kế (lỗi mức cao)

V & V - Validation & Verification

ĐẠI CƯƠNG – Các khái niệm

Trang 5

 Thẩm định/xác minh tĩnh

( kiểm tra - software inspection )

- xét duyệt yêu cầu, thiết kế, mã nguồn

- tiến hành ở mọi công đoạn phát triển

- khó đánh giá tính hiệu quả của sản phẩm

Trang 6

- đánh giá tính hiệu quả phần mềm

- là cách duy nhất để kiểm tra yêu cầu phi chức năng

Trang 7

ĐẠI CƯƠNG – Mục tiêu

được các yêu cầu (độ tin cậy)

Trang 8

ĐẠI CƯƠNG - Thời điểm tiến hành

Tiến hành ở mọi công đoạn phát triển phần mềm

Trang 9

- đảm bảo kiểm tra hết các trường hợp

 Được lập tài liệu

- kiểm soát tiến trình/kết quả

Trang 10

 Trong môi trường của phía phát triển

 Kiểm thử hệ thống thông tin

CÁC GIAI ĐOẠN KIỂM THỬ

Trang 11

CÁC GIAI ĐOẠN KIỂM THỬ - Phía phát triển

Trang 12

• Unit test/Module test

• Dựa vào TL thiết kế chi tiết

• Test 1 module (hàm, thủ tục, đoạn code, component…)

• Dựa vào TL thiết kế tổng thể

• Kiểm tra sự tương tác giữa các module

• Dựa vào TL đặc tả yêu cầu phần mềm

• Kiểm tra toàn bộ hệ thống

•Dựa vào yêu cầu nghiệp vụ của khách hàng

CÁC GIAI ĐOẠN KIỂM THỬ - Phía phát triển

Trang 13

Trang 14

 Mở rộng của alpha testing

 Được tiến hành với một lượng lớn users

 User tiến hành kiểm thử không có sự hướng dẫn của người phát triển

 Thông báo lại kết quả cho người phát triển

CÁC GIAI ĐOẠN KIỂM THỬ - Phía khách hàng

Trang 15

 M r ng ph m vi ki m th , nhìn nh n ph n m m ở rộng phạm vi kiểm thử, nhìn nhận phần mềm ộng phạm vi kiểm thử, nhìn nhận phần mềm ạm vi kiểm thử, nhìn nhận phần mềm ểm thử ử ận phần mềm ầu đối với kiểm thử ềm

là m t y u t trong m t HTTT ph c t p ộng phạm vi kiểm thử, nhìn nhận phần mềm ếu tố trong một HTTT phức tạp ối với kiểm thử ộng phạm vi kiểm thử, nhìn nhận phần mềm ức tạp ạm vi kiểm thử, nhìn nhận phần mềm

 Ki m tra các y u t : ểm thử ếu tố trong một HTTT phức tạp ối với kiểm thử

• Kh n ng ph c h i sau l i ả năng phục hồi sau lỗi ăng phục hồi sau lỗi ục hồi sau lỗi ồi sau lỗi ỗi

• Động phạm vi kiểm thử, nhìn nhận phần mềm an toàn

• Hi u n ng và gi i h n c a ph n m m ệu năng và giới hạn của phần mềm ăng phục hồi sau lỗi ới kiểm thử ạm vi kiểm thử, nhìn nhận phần mềm ủa phần mềm ầu đối với kiểm thử ềm

CÁC GIAI ĐOẠN KIỂM THỬ - Phía khách hàng

Trang 16

 Kiểm thử chức năng (functional testing)

- dựa trên đặc tả chức năng

- phát hiện các sai sót về chức năng

- không quan tâm đến cách cài đặt

(black box )

 Kiểm thử cấu trúc (structured testing)

- kiểm thử có nghiên cứu mã nguồn

- phân tích thứ tự thực hiện các lệnh

(white box )

CÁC LOẠI KIỂM THỬ

Trang 17

end;

Sn C

Trang 19

CÔNG VIỆC CỦA TESTER

 Tham gia phân tích yêu cầu của khách hàng

 Lập kế hoạch test

 Xây dựng tiêu chuẩn nghiệm thu

 Xây dựng hướng dẫn test ( bản thiết kế test, kịch bản test )

 Thực hiện test

 Hỗ trợ các vấn đề liên quan đến test

 Báo cáo và tổng hợp kết quả test

 Lập và lưu trữ các hồ sơ liên quan đến test

 Thu thập và kiểm soát các dữ liệu liên quan đến các hoạt động test

 Tính toán và phân tích các chỉ tiêu liên quan đến các hoạt động test

Trang 21

Construction Lập trình

Solution Thiết kế kiến trúc

Definition Xác định yêu cầu

Termination (Kết thúc)

Transition (Triển khai)

Definition (Xác định yêu cầu) Solution (Thiết kế kiến trúc)

Construction (Xây dựng) Coding (lập trình)

Testing (thử nghiệm)

Initiation (khởi động)

CÁC HOẠT ĐỘNG KIỂM

THỬ

Trang 22

CÁC HOẠT ĐỘNG

 Phân hoạch tương đương

 Đường đi trong mô đun

Vấn đề của thiết kế test

Trang 23

 Dữ liệu vào

- dữ liệu thông thường: số, xâu kí tự, file,

- môi trường thử nghiệm: phần cứng, OS,

- thứ tự thao tác (khi kiểm thử giao diện)

- thông thường: số, xâu kí tự, file,

- màn hình, thời gian phản hồi

 Kết quả thực tế

CÁC HOẠT ĐỘNG – mô tả test case

Trang 24

Thiết kế test cases

Test case description:

Operation procedure:

Required test scripts:

Trang 25

Phân tích và báo cáo

Khi nào tiến hành phân tích và báo cáo?

Khi có lỗi được tìm thấy, cần phải viết báo cáo ngay

Nội dung của báo cáo?

Problem ID current software name, release no and version no

Test type Reported by Reported date Test case ID

Subsystem (or module name) Feature Name (or Subject)

Problem type (REQ, Design, Coding, …) Problem severity (Fatal, Major, Minor, )

Problem summary and detailed description

Cause analysis How to reproduce? Attachments

Trang 26

 Không thể kiểm thử mọi trường hợp

- nhiều lỗi xuất hiện với giá trị biên

Phân hoạch tương đương - Equivalence partitioning

HOẠT ĐỘNG – xác định test case

Trang 27

-20

0

100 20

0

Ví dụ:

Trang 28

Tạo test case cho các trường hợp đặc biệt

- biên của số trong máy tính (vd 32767, -32768)

- số không (0)

- số âm, số thập phân

- dữ liệu sai kiểu

- dữ liệu ngẫu nhiên

Mở rộng test case:

Trang 29

bắt đầu đến điểm kết thúc của mô đun

Đường đi trong mô đun

Trang 30

 Đánh số các khối lệnh

- đánh số các khối lệnh, câu lệnh điều kiện

- đánh số các hợp điểm của luồng lệnh

- các khối tuần tự được tích hợp thành một khối

- tích hợp khối tuần tự vào câu lệnh điều kiện

kế tiếp

Đường đi trong mô đun – Xác định đường đi

Trang 31

1 2

3

4 5

6

9

10 11

Start

End

0

Ví dụ:

Trang 32

2 4

6 5

7

3

1-2-3-8-1-9 1-2-4-6-7-8-1-9

Ví dụ:

Trang 33

- chọn các đường đi độc lập

- có ít nhất một cặp khối lệnh (một cạnh của đồ thị)

chưa xuất hiện trong các đường đi đã có

- mọi khối lệnh đều được thực hiện ít nhất một lần

- mọi điều kiện đều được kiểm thử với hai trường hợp

true và false

Đường đi trong mô đun – Đường đi độc lập

Trang 34

2 4

6 5

7

3

1-2-4-6-7-8-1-9 1-2-4-5-7-8-1-9

Ví dụ:

Trang 35

= độ phức tạp thuật toán

Trang 36

Độ phức tạp V(G) của flow chart G:

1 V(G)=Số miền của đồ thị G +1

2 V(G) = E - N + 2 E: số cạnh

N: số đỉnh

3 V(G) = P + 1 P: số các nút điều kiện

Đường đi trong mô đun – Độ phức tạp thuật toán

Trang 37

1

2 4

6 5

7

8

3 9

Đường đi trong mô đun – Độ phức tạp thuật toán

Trang 38

• không nên tạo các mô đun có độ phức tạp > 10

• phân rã mô đun (tạo các mô đun thứ cấp để giảm độ phức tạp)

Độ phức tạp lớn thì xác suất xuất hiện lỗi cao

Trang 39

1 Kiểm thử top – down

2 Kiểm thử bottom – up

3 Kiểm thử quay lui (regression)

CHIẾN LƯỢC KIỂM THỬ TÍCH HỢP

 Mục đích

- kiểm tra giao diện giữa các unit

- kiểm tra tính đúng đắn so với đặc tả

- kiểm tra tính hiệu quả

 Thường sử dụng kiểm thử chức năng

Trang 40

 Các mô đun mức trên được kiểm thử trước

các mô đun tạm thời (stub function)

 có cùng tên với mô đun thật

Trang 41

Kiểm thử mô đun calender() có gọi đến mô đun tính ngày trong tuần calc_day()chưa được phát triển.

Trang 42

Mô đun tính ngày trong tuần calc_day():

- input: ngày, tháng, năm

- output: trả xâu kí tự là thứ của ngày đã cho

String calc_day(Date d) {

return "Sunday";

}

KIỂM THỬ TÍCH HỢP – Top-down testing

Ví dụ về stub fuction:

Trang 43

Để tăng độ thích nghi, có thể thay thế dữ liệu cố định bằng cách nhập kết quả trực tiếp từ bàn phím.

String calc_day(Date d) {

Trang 44

A B

Các stubs được thay thế từng cái một

Mỗi khi một module mới được tích hợp một số ca kiểm thử được thực hiện lại ( kiểm thử quay lui )

Trang 45

Ưu điểm:

Nhược điểm:

- thao tác với cấu trúc dữ liệu phức tạp

- trả lại kết quả phức tạp (con trỏ, ảnh, )

Trang 46

 Các mô đun cấp thấp được kiểm thử trước

đun điều khiển (test driver), có chức năng

 gọi mô đun cần thử nghiệm

Trang 47

V í dụ Test driver đểm thử ử th nghi m ệu năng và giới hạn của phần mềm calc_day()

void calc_day_test_drive() {

Date d;

String s;

while (1) { cout << ”Enter date: ”);

cin >> d;

s = calc_day(d);

cout << s << endl;

} }

KIỂM THỬ TÍCH HỢP – Bottom-up testing

Trang 48

A B

KIỂM THỬ TÍCH HỢP – Bottom-up testing

Trang 49

- Tránh xây dựng các mô đun tạm thời (stub) phức tạp

- Tránh sinh các kết quả nhân tạo (nhập từ bàn phím)

- Thuận tiện cho phát triển các mô đun để dùng lại

Trang 50

Một số khái niệm

a pass/fail criterion.

satisfied by one or more test cases.

cases and evaluating their results.

(satisfied) or false (not satisfied) of a program, test suite pair

Trang 51

Bài tập

Để kiểm thử hàm tính sin, bộ kiểm thử (tính

theo đơn vị độ của góc) nào dưới đây là tốt:

a -15, 0, 15, 30, 45, 60, 75, 90, 105

b -90, 0, 90, 180, 270, 360, 450

c -55, 0, 30, 90, 135, 630

d -30, 0, 30, 90

Trang 52

CÂU HỎI ÔN

testing)

Tiêu đề	Xác minh và thẩm định
Trường học	Đại học Quốc gia Hà Nội
Chuyên ngành	Kỹ nghệ phần mềm
Thể loại	Bài giảng
Thành phố	Hà Nội

Định dạng
Số trang	52
Dung lượng	247,5 KB