Giáo án bài giảng: Công nghệ thông tin về cách kiểm thử phần mềm

Chi phí cho việc sửa lỗi phần mềmKiểm thử và sửa lỗi có thể được thực hiện tại bất kỳ giai đoạn nào của vòng đời phần mềm Chi phí cho việc tìm và sửa lỗi tăng một cách đáng kể theo qu

Trang 1

Kỹ thuật kiểm thử phần mềm

GV: Th.s Nguyễn Quang Vũ

Trang 3

 Giảm thiểu sai sót trong quá trình vận hành

 Thuận lợi trong bảo trì và nâng cấp

Trang 4

Chương 1 Phần mềm và lỗi phần mềm

Phần mềm ?

 là một tập các đoạn mã hoặc câu lệnh viết ra để cài đặt trên máy tính nhằm thực hiện một hoặc một nhóm chức năng nào đó.

Các công việc để tạo ra một phần mềm:

 Phân tích – Đặc tả yêu cầu

Trang 5

Có nhiều quy trình phần mềm khác nhau

(Software Development Process – SEP)

 Đóng vai trò quyết định chất lượng PM.

 Các nhóm công việc được triển khai theo những cách khác nhau.

 Có 4 nhóm công việc nền tảng: Đặc tả yêu cầu – Phát triển – Kiểm thử - Cài đặt và bảo trì

 Một PM có thể dùng nhiều mô hình khác nhau.

 Không phải tất cả các mô hình đều thích hợp cho mọi phần mềm ứng dụng

Trang 8

Trang 10

Phân loại phần mềm:

Phần mềm

Sản phẩm tổng quát

Sản phẩm Chuyên ngành

Trang 12

Chất lượng phần mềm: Các nhân tố ảnh hưởng đến chất lượng PM có thể là

 Nhân tố đo trực tiếp

 Nhân tố đo gián tiếp

Trang 15

Lỗi phần mềm

Thế nào là phần mềm được gọi là đúng ?

Để đánh giá CẤP ĐỘ ĐÚNG của phần mềm, phải kiểm tra CHẤT LƯỢNG PHẦN MỀM

Trang 16

Tài liệu thiết kế

Tài liệu kiểm thử Lịch biểu

Phản hồi từ phiên bản cũ

Thông tin cạnh tranh

Khảo sát khách hàng Dũ liệu

Duyệt lại sản phẩm

Kiến trúc

Setup, Help Files, Sample as Examples, Readme Files, Error Messages, Icons, User Manuals, Product Support Information,

Trang 17

Thiết kế

Trang 18

Nguyên nhân làm đặc tả nhiều lỗi ?

 Đặc tả không được viết ra

 Đặc tả không đủ cẩn thận

 Đặc tả thay đổi

 Chưa phối hợp tốt trong nhóm

Trang 19

Ví dụ: Bài toán phân số

một số nguyên, m là một số tự nhiên lớn hơn 0; t được gọi là tử số, m được gọi là mẫu số của phân số

toán học để mô tả.

Phân số = {(t,m) | t  Z, m  N + } (*) Trong đó: N = {0, 1, 2, 3, …}

N + = {1, 2, 3, …}

Z = {0, 1, 2, 3, …}

Trang 21

Ví dụ: Chia nhóm và mỗi nhóm tìm một bài toán (đặc tả phi hình thức, đặc tả hình thức, và một trường hợp có thể không đúng với đặc tả)

Trang 22

Các lỗi phần mềm thường gặp

Sản phẩm phần mềm được được xây dựng thiếu,

sai, thừa so với đặc tả được xem là có lỗi.

Thậm chí, một phần mềm khó hiểu, khó sử dụng, thực thi chậm, … cũng được xem là lỗi

Trang 23

Các lỗi phần mềm thường gặp

Lỗi chiến lược

Phân tích không đủ yêu cầu hoặc lệch lạc

Hiểu sau về chức năng

Vi phạm nguyên lý đối tượng

 Nguyên lý đóng – mở

 Nguyên lý nghịch đảo phụ thuộc

 Nguyên lý thay thế Liskov

 Nguyên lý phân tách Interface

Trang 24

Các lỗi phần mềm thường gặp (tt)

Lỗi các thủ tục chịu tải

Lỗi lây lan

Lỗi cú pháp

Lỗi hiệu ứng phụ

Trang 25

Ví dụ: chương trình tính tiền lương được đặc

tả cho từng nhân viên theo qui định làm tròn đến hàng đơn vị, với công thức (1.1)

Lương i = round(hsli*lcb(1- 0.06),0 ) (1.1)

Nhưng khi lập trình:

Lươngi = round(hsli *lcb(1- 0.06),-2 ) (1.2)

Trang 27

Đặc tả thiếu: Một yêu cầu đã được đặc tả

nhưng lại không có trong sản phẩm được xây dựng

Ví dụ: Chương trình quản lý tính vốn vay, khi ngân hàng cho vay vốn thì việc tính lãi được qui định theo hai phương thức là tính lãi đơn và tính lãi kép Nhưng khi thiết kế thì chương trình chỉ tính lãi đơn không tính lãi kép Do vậy, chương trình không đưa vào ứng dụng ngay được mà phải sửa chữa cập nhật lại.

Trang 28

Đặc tả thừa:

Một yêu cầu được đưa vào sản phẩm mà

không có trong đặc tả Cũng có trường hợp yêu cầu này có thể là một thuộc tính sẽ được người dùng chấp nhận nhưng khác với đặc tả nên vẫn coi là có lỗi

Ví dụ: ????

Trang 29

Chi phí cho việc sửa lỗi phần mềm

Kiểm thử và sửa lỗi có thể được thực hiện tại bất

kỳ giai đoạn nào của vòng đời phần mềm

Chi phí cho việc tìm và sửa lỗi tăng một cách đáng

kể theo quá trình phát triển:

 Không đáng kể khi thay đổi yêu cầu ở lần duyệt yêu cầu đầu tiên

 Tăng lên gấp bội khi thay đổi yêu cầu lúc đã lập trình

 Không đáng kể nếu lập trình viên tự phát hiện lỗi của

mình

Trang 30

“Sửa một lỗi trước khi phát hành một phần

mềm sẽ tốn chi phí ít hơn rất nhiều so với

việc khắc phục nó sau khi đã phát hành ”

Lỗi được phát hiện càng muộn thì chi phí cho

việc sữa lỗi càng lớn

Trang 31

Trang 32

 Ví dụ: Sự cố Y2K

Trang 33

Đảm bảo chất lượng phần mềm

Mục đích của nhóm phát triển PM là có PM chất

lượng cao

Hạn chế thấp nhất việc phát sinh lỗi

Đảm bảo chất lượng phần mềm là một hoạt động

có hệ thống và kế hoạch

Trang 34

Đảm bảo chất lượng phần mềm gồm nhiều nhiệm

vụ liên kết và các hoạt động chính sau:

 Áp dụng các phương pháp kỹ thuật,

 Tiến hành các cuộc xét duyệt kỹ thuật chính thức,

 Kiểm thử phần mềm,

 Buộc tôn trọng các chuẩn,

 Kiểm soát thay đổi,

 Đo chất lượng,

 Báo cáo, lưu giữ kết quả.

Trang 36

Tránh lỗi

 Đặc tả hệ thống chính xác

 Tăng cường duyệt và thẩm định

 Chấp nhận triết lý chất lượng tổ chức: chất lượng là bánh lái của quá trình phát triển phần mềm

 Lập kế hoạch cẩn thẩn cho việc thử nghiệm hệ thống

Trang 38

4 hoạt động cần tiến hành để THỨ LỖI

 Phát hiện lỗi

 Định ra mức độ thiệt hại

 Hồi phục sau khi gặp lỗi: Hồi phục tiến hoặc Hồi phục lùi

 Chữa lỗi (Lưu ý các lỗi “tàng hình”)

Trang 39

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

V&V – Verification and Validation

Là một quá trình liên tục xuyên suốt mọi giai đoạn của tiến trình phát triển phần mềm

là từ chung cho các quá trình kiểm thử

Có hai mục tiêu:

 Phát hiện các khuyết tật trong hệ thống.

 Đánh giá xem hệ thống liệu có dùng được hay không?

Trang 40

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

Sự khác nhau giữa xác minh và thẩm định:

 Xác minh: Are we building the product right?

 Thẩm định: Are we buiding the right product ?

Trang 41

Mô hình phát triển phần mềm

Phân tích yêu cầu

Thiết kế

Mã hoá và kiểm thử đơn vị

Tích hợp và kiểm thử

hệ thống

Hình 1.1–Mô hình WaterFall

Cài đặt và bảo trì

Trang 42

Ưu điểm của mô hình này:

- chuỗi các hoạt động xây dựng phần mềm theo trình

tự, rõ ràng.

Nhược điểm của mô hình này:

- Đòi hỏi tất cả yêu cầu phần mềm phải được xác định

rõ ràng ngay từ đầu dự án

- Sự quay lui là nhu cầu tự nhiên

- Ẩn chứa nhiều rủi ro mà chỉ có thể phát hiện ở giai đoạn cuối cùng

- Chi phí để sửa chữa có thể rất cao

Trang 43

Các hoạt động đồng thời

Đặc tả (Specification)

Phát triển (Development, design, coding)

Kiểm thử (Testing)

Phiên bản đầu tiên

Phiên bản trung gian

Phiên bản Cuối cùng

Yêu lược

ban đầu

Hình 1.2–Mô hình tiến hóa

Trang 44

- Chú trọng việc tái sử dụng mẫu

- Một phần của hệ thống có thể được phát triển ngay trong các giai đoạn phân tích phát triển yêu cầu và thiết kế

- Cho phép thay đổi yêu cầu và khuyến khích người sử dụng tham gia trong suốt chu kỳ của dự án

- chậm quá trình phát triển yêu cầu

- tính chặt chẽ, minh bạch của qui trình phát triển phần mềm kém

Trang 45

Trang 46

Trong mô hình này:

- Một khi sai sót được phát hiện trong một giai đoạn kiểm thử thì giai đoạn phân tích hay thiết kế tương ứng được xem xét lại và chu trình bắt đầu lại từ đó

Trang 47

Trang 48

- Phân tích đánh giá rủi ro để tăng thêm mức độ tin cậy của dự án

- Kết hợp được những ưu điểm của mô hình thác nước

và mô hình tiến hóa

- cho phép thay đổi tùy theo điều kiện thực tế dự án

- Phức tạp và không phù hợp cho dự án nhỏ với ít rủi ro

- Cần có kỹ năng tốt về phân tích rủi ro

Trang 49

Chương 2 Kiểm thử phần mềm

Trang 50

việc đánh giá chất lượng phần mềm

Mục đích của kiểm thử là đảm bảo rằng tất

cả các thành phần của phần mềm ăn khớp, vận hành như mong đợi và phù hợp các tiêu

chuẩn thiết kế

Trang 51

Hình 2.2 - Kiểm thử phần mềm trong một số ngữ cảnh

(a) Ngữ cảnh quy trình (b) Ngữ cảnh chất lượng

Công nghệ hệ thống Quản lý và đảm bảo chất lượng

Trang 52

Trang 53

 KTPM bao gồm việc "chạy thử" phần mềm (PM) hay một chức năng của PM, xem nó "chạy" đúng như mong muốn hay không

để tìm lỗi

Trang 54

Trang 57

Trang 59

Kỹ thuật kiểm thử phần mềm

hộp đen)

hộp trắng)

Trang 60

Kỹ thuật kiểm thử chức năng

Trang 61

trong phần mềm

phần mềm

Trang 62

 Lỗi giao diện

 Lỗi cấu trúc dữ liệu

 Lỗi thi hành

 Lỗi khởi tạo/kết thúc

 …

Trang 63

Trang 64

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

Trang 65

kiện đầu vào khác nhau có thể để giảm thiểu tổng số các trường hợp cần thiết.

một chương trình thành một số xác định các lớp tương đương, sao cho có thể giả định hợp lý

rằng việc kiểm thử một giá trị đại diện của mỗi lớp là tương đương với việc kiểm thử một giá trị bất kỳ trong cùng lớp đó

Trang 66

đương theo 2 bước như sau:

tương đương

mỗi lớp.

Trang 67

giá trị hợp lệ trong đoạn 0 1000

hoạch đầu vào:

Trang 68

giá trị hợp lệ trong đoạn 0 1000 (tt)

năng phát hiện lỗi cao hơn:

Trang 69

Kiểm thử giá trị biên

 Các điều kiện biên là tình trạng trực tiếp ở

phía trên và dưới của các lớp tương đương

đầu vào và lớp tương đương đầu ra.

Trang 70

 Việc phân tích các giá trị biên khác với phân

hoạch tương đương theo hai điểm:

đương sẽ chọn phần tử bất kỳ làm phần tử đại diện, trong khi việc phân tích giá trị biên sử

dụng một hoặc một số phần tử

đầu vào, các trường hợp kiểm thử cũng được suy ra từ việc xem xét các kết quả ra

Trang 71

 Các THKT tốt nhất là tại các biên của các lớp

 Kiểm thử giá trị biên mở rộng phân hoạch

tương đương trên cơ sở tập trung vào các

biên của miền đầu vào hơn là các giá trị tiêu

biểu của nó

Trang 72

 Ví dụ: Nếu phần mềm cần điều khiển một số

bản ghi bất kỳ trong khoảng từ 1 đến 16383

bản ghi, sẽ có ba lớp tương đương:

Trang 73

 Ví dụ(tt): Khi đó, các THKT có thể là:

 Trường hợp kiểm thử 1: 0 bản ghi, là thành viên của lớp

tương đương 2 và kề sát giá trị biên.

 Trường hợp kiểm thử 2: 1 bản ghi, là giá trị biên.

 Trường hợp kiểm thử 3: 2 bản ghi, kề sát giá trị biên.

 Trường hợp kiểm thử 4: 723 bản ghi, là thành phần của

 Trường hợp kiểm thử 7: 16384 bản ghi, thành phần của

lớp tương đương 3, kề sát giá trị biên.

Trang 74

Đồ thị nhân – quả

 Là một phương pháp thiết kế trường hợp kiểm thử

trên cơ sở đưa ra một sự mô tả súc tích các điều

kiện logic và các hành vi kèm theo

 Sử dụng mô hình quan hệ logic giữa nguyên nhân

và kết quả:

 Nguyên nhân: điều kiện (đúng hoặc sai) của một đầu

vào, hoặc kết hợp các đầu vào

 Kết quả: một biểu thức Bool biểu diễn một kết quả

tương ứng cho những thành phần vừa thực hiện

Trang 75

 Các bước tạo đồ thị nhân – quả

 Tất cả các nguyên nhân (các đầu vào) và các kết quả

(các đầu ra) được liệt kê dựa trên đặc tả và được định danh cho mỗi nhân - quả.

 Các quan hệ giữa các nguyên nhân (các đầu vào) và

các kết quả (các đầu ra) được biểu diễn trong đồ thị làm rõ ràng các quan hệ logic.

 Từ đồ thị tạo ra bảng quyết định biểu diễn các quan hệ

giữa nguyên nhân và kết quả Dữ liệu kiểm thử được sinh ra dựa trên các qui tắc trong các bảng này.

Trang 76

 Các ký hiệu quy ước:

Trang 77

 Các ký hiệu quy ước:

Trang 78

 Ví dụ: để tính thuế thu nhập, người ta có

mô tả sau:

- Người vô gia cư nộp 4% thuế thu nhập

- Người có nhà ở nộp thuế theo bảng sau:

<= 5.000.000 đồng 4%

> 5.000.000 đồng 6%

Trang 79

 Ví dụ(tt): Quan hệ giữa nguyên nhân (đầu

vào) và kết quả (đầu ra) như sau:

Trang 80

 Ví dụ(tt): Đồ thị biểu diễn quan hệ logic rõ

ràng giữa nguyên nhân-kết quả :

Trang 81

 Ví dụ(tt): Bảng quyết định: Từ đây xây

dựng được bốn trường hợp kiểm thử (một trường hợp cho việc nộp thuế 6% và ba

trường hợp kiểm thử cần cho việc nộp thuế 4%):

Trang 82

Kỹ thuật kiểm thử cấu trúc

trình hoặc một mô hình của mã chương trình để

xây dựng các phép thử theo các tiêu chuẩn bao phủ

 Kiểm thử cấu trúc bên trong của phần mềm, với mục đích kiểm tra tất cả các câu lệnh và điều

kiện tồn tại trong phần mềm đó

Trang 83

Kỹ thuật kiểm thử cấu trúc

 Trong kỹ thuật này kiểm thử viên lấy dữ liệu thử xuất phát từ việc kiểm tra logic của chương trình (không quan tâm đến đặc tả)

Trang 84

Đồ thị luồng điều khiển

trong đó:

 Mỗi nút (đỉnh): biểu diễn một lệnh tuần tự hoặc khối lệnh tuần tự.

 Các cung: tương ứng với các quyết định luồng điều khiển

đi ra từ một nút cấu trúc lựa chọn hay lệnh rẽ nhánh Một cung cần phải kết thúc tại một đỉnh, cho dù đỉnh đó không biểu diễn cho một lệnh thủ tục nào

 Một đỉnh vào và một đỉnh ra được thêm vào đồ thị để

biểu diễn cho điểm vào ra tương ứng của chương trình

Trang 85

chương trình giải phương trình bậc nhất

Trang 86

chương trình giải phương trình bậc hai biện luận theo Delta ?

Trang 87

Lộ trình/đường đi (Path) trong đồ thị luồng điều khiển

đỉnh và cung khác và kết thúc tại đỉnh ra.

1, có:

 [n0, a, b, c ,ne] : là một lộ trình

 [a, b, c, ne] : không phải là lộ trình

Vậy trong đồ thị luồng điều khiển đó có tất cả bao nhiêu lộ trình ?

Trang 88

Biểu thức các lộ trình

được biểu diễn dưới dạng biểu thức sau

G1 = n0 a b c ne + n0 a b d ne + n0 a e ne(Dấu ”+” đại diện toán tử ”hoặc”.)

G1 = n0 (a b c + a b d + a e) ne

Trang 89

Dạng lặp: a(bc) * d

Trang 90

 Các tiêu chuẩn bao phủ dựa trên đồ thị luồng điều khiển:

 Phủ tất cả các lệnh (đỉnh).

 Phủ tất các các quyết định (cung).

 Phủ tất cả các điều kiện.

 Phủ tất cả các lộ trình.

Trang 91

Phủ tất cả các lệnh (đỉnh)

lệnh

lệnh phải được thực thi ít nhất một lần

thực hiện được.

Trang 92

cout<<”nhap gia tri: ”; cin>>x;

if(x==0) x++;

g=1/x;

Hãy vẽ đồ thị luồng điều khiển ?

Trang 94

thì không phủ các cung.

Trang 95

Phủ tất cả các cung

của đồ thị luồng điều khiển ít nhất một lần

việc phủ tất các giá trị logic của mỗi đỉnh

quyết định

các đỉnh.

Trang 96

Phủ tất cả các cung

if(a < 2 && a==b)

Trang 98

có thể không phủ tất cả các điều kiện.

Trang 99

Phủ tất cả các điều kiện

 Tiêu chuẩn phủ tất các điều kiện được

thỏa mãn khi và chỉ khi tiêu chuẩn phủ tất

cả các cung được thỏa mãn và mỗi biểu

thức điều kiện được thử với tất cả các giá

trị có thể

Trang 100

được trình bày lại để phủ tất cả các điều

b a

b=a b≠a b=a

Trang 102

Tiêu chuẩn phủ tất các cung và tiêu chuẩn phủ tất cả các điều kiện không thể dò tìm được lỗi trong trường hợp vòng lặp không thực thi.

Trang 104

các cung của đồ thị luồng điều khiểnlà:

a[0]= 1, a[1]=2, a[2]=3, n =1, m=2

Tuy nhiên lỗi sẽ không được phát hiện

trong trường hợp n>m nghĩa là s= 0, => 1/s (1/0) => lỗi

Trang 105

Phủ tất cả các lộ trình

 Tiêu chuẩn phủ tất cả các lộ trình có thể gặp những khó khăn khi số lộ trình là vô

hạn hoặc các lộ trình không thực thi

 Trong trường hợp, chương trình có số lần lặp quá lớn thì chúng ta qui định rằng chỉ

thực hiện i lần lặp hữu hạn nào đó mà thôi

Trang 106

Lộ trình không qua vòng lặp: abd

Lộ trình qua vòng lặp một lập: abcbd

Trang 107

Phủ tất cả các lộ trình

 Như vậy, phủ tất cả lộ trình kéo theo phủ

tất cả các cung và phủ tất cả các đỉnh.

Trang 109

Bài tập tổng kết

Tìm hiểu các hạn chế của kiểm thử phần

mềm ?

Định dạng
Số trang	140
Dung lượng	1,53 MB