Bài giảng môn học Kỹ nghệ phần mềm: Bài 9 - PGS.TS. Nguyễn Văn Vỵ

Trang 1

Bộ môn Công nghệ phần mềm- Khoa CNTT- ĐHCNEmail: vynv@coltech.vnu.vn

Kỹ nghệ phần mềm

Software Engeneering

Trang 2

Bộ mụn Cụng nghệ phần mềm – ĐHCN2

NguyễnVănVỵ

Nội dung

Bài 9: Xỏc minh & thẩm định

Khái niệm xác minh, thẩm định

Rμ sóat phần mềm

Trang 3

NguyễnVănVỵ

TÀI LiỆU THAM KHẢO

1. Nguyễn Văn Vỵ, Nguyễn Việt Hà Giỏo trỡnh kỹ nghệ phần mềm Nhà xuất bản Đại học Quốc gia Hà nội, 2008

2. Grady Booch, James Rumbaugh, Ivar Jacobson The Unified Modeling language User Guid Addison-Wesley, 1998.

3. M Ould Managing Software Quality and Business Risk, John

Wiley and Sons, 1999.

4. Roger S.Pressman, Software Engineering, a Practitioner’s Approach Fifth Edition, McGraw Hill, 2001.

5. Ian Sommerville, Software Engineering Sixth Edition,

Addison-Wasley, 2001.

Trang 4

NguyễnVănVỵKhái niệm xác minh & thẩm định

Xác minh (Verification)

Kiểm tra xem phần mềm lμm ra có đúng đặc tả (yêu cầu, thiết kế) hay khơng

Thẩm định (Validation)

kiểm tra xem phần mềm có đáp ứng yêu cầu ng−ời dùng không

Trang 5

NguyễnVănVỵ

Hoạt động kiểm chứng phần mềm

Thẩm địnhvàxỏc minhthực hiện ở mọi giai đoạn phỏt triển,với sản phẩm khỏc nhau, do đối tượng khỏc nhau thực hiện

Trang 6

NguyễnVănVỵ

Các hoạt động xác minhCơ sở cho hoạt động xác minh

Bản đặc tả yêu cầu Các bản thiết kế

Mã nguồn

Hoạt động xác minh

Trang 7

NguyễnVănVỵ

Các hoạt động thẩm địnhCơ sở cho hoạt động xác minh

Bản đặc tả yêu cầu Mã nguồn

Hoạt động xác minh

Rμ soát (thanh tra, xét duyệt) Kiểm toán

Kiểm thử thẩm định(chấp nhận)

Trang 8

NguyễnVănVỵ

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

rà soỏt, xột duyệt cỏc tài liệu phần mềm: kế hoạch, yêu cầu, thiết kế, mã nguồn

phỏt hiện một số loại lỗi nhất định

Trang 9

NguyễnVănVỵ

Thẩm định/xác minh động

thực hiện trờn cơ sở cho vận hành sản phẩm phần mềm:

Làm mẫu yờu cầu

Vận hành chương trỡnh (kiểm thử)Mụ phỏng hệ thống

người phỏt triển/người dựng trực tiếp kiểm tra đỏnh giỏ

Trang 10

NguyễnVănVỵ

Rà soỏt phần mềm

■Rà soỏt là xem xột, đỏnh giỏ sản phẩm được tiến hành mỗi giai đoạn để phỏt hiện ra những khiểm khuyết cần sửa trước khi sang giai đoạn sau

■Mục tiờu:

• Chỉ ra cỏc khiếm khuyết cần phải cải thiện.

• Khẳng định những sản phẩm đạt yờu cầu.

• Kiểm soỏt việc đạt chất lượng kỹ thuật tối thiểu của sản phẩm (cú diện mạo khụng đổi, ổn định)

Trang 11

NguyễnVănVỵCỏc hỡnh thức rà soỏt■Cỏc kiểu rà soỏt:Thanh traHọp xột duyệt khụng chớnh thức, Họp chớnh thứcvới cỏc thành viờn: khỏch hàng, nhàquản lý, nhõn viờn kỹ thuật (rà soỏt kỹ thuật chớnh thức –formal technical review: FTR)

Trang 12

NguyễnVănVỵ

Rà soỏt kỹ thuật chớnh thức

(formal technical review - FTR)

■ Rà soỏt kỹ thuật chớnh thứclàhoạt động bảo đảm chất lượng phần mềm do những người đang tham gia phỏt triển thực hiện.

■Mục tiờu cụ thể là:

Phỏt hiện cỏc lỗi trong chức năng, logic (chương trỡnh) và triển khai (implementation).

Kiểm thử sự phự hợpcủa phần mềm với yờu cầu

Trang 13

NguyễnVănVỵ

Mục tiờu rà soỏt kỹ thuật chớnh thức■Mục tiờu cụ thể (t):

Bảo đảm FM phự hợp với cỏc chuẩn đó định

Đảm bảo FM được phỏt triển theo một cỏch thức nhất quỏn (uniform manner)

Làm cho dự ỏn dễ quản lý hơn

Trang 14

NguyễnVănVỵ

Tiến trỡnh hoạt động rà soỏt

Trang 15

NguyễnVănVỵ

Cuộc họp rà soỏt

■Thành phần: lónh đạo rà soỏt, cỏc cỏ nhõn rà soỏtvà

người tạo ra sản phẩm được rà soỏt (+ khỏch).

■Kết lũn đưa ra 1trong 3 quyết địnhsau:

• Chấp nhận sản phẩm khụng cần chỉnh sửa

• Khước từ sản phẩm vỡ những lỗi nghiờm trọng

• Chấp nhận cho chỉnh sửa sản phẩm, sau khi chỉnh sửa phải rà soỏt lại

Trang 16

NguyễnVănVỵ

Sản phẩm rà soỏt

■Sản phẩm cuộc họp rà soỏt:

• 1 Bỏo cỏo cỏc vấn đề nảy sinh do cỏ nhõn ràsoỏt nờu ra

• 1 danh sỏch cỏc vấn đềcần giải quyết • 1 bản tổng kết cuộc họp

■Bản tổng kết họp rà soỏt phải chỉ rừ:

• Đó rà soỏt cỏi gỡ• Ai rà soỏt

Trang 17

NguyễnVănVỵ

Sản phẩm rà soỏt (t)

■Danh sỏch cỏc vấn đề tồn tại phục vụ:

Nhận ra cỏc vựng cú vấn đềtrong sản phẩm được rà soỏt

Dựng như1 danh sỏch cỏc khoản mục để chỉcho cỏc người làm ra sản phẩmcần chỉnh sửaThiết lập thủ tục để bảo đảm rằng cỏc khoản

Trang 18

NguyễnVănVỵ

Tiến hành rà soỏt

■Mọi sản phẩm được tao ra ở mỗi bước đều được ràsoỏt (khụng chỉ sản phẩm cuối cựng)

■Tiến trỡnh phỏt triển chung nhất gồm 4 -5 giai đoạn: Kỹ nghệ hệ thống (KH triển khai)

Phõn tớch, xỏc định yờu cầu phần mềm (đặc tả yờu cầu) Thiết kế phần mềm (thiết kế)

Lập mó (mó nguồn)

Kiểm thử phần mềm (kế hoạch kiểm thử) Bao trỡ (kế hoạch bảo trỡ)

Trang 19

NguyễnVănVỵ

Các danh mục sản phẩm cần rμ soát Danh mục rà soỏt kỹ nghệ hệ thống

Danh mục rà soỏt lập kế hoạch dự ỏn

Danh mục rà soỏt phõn tớch yờu cầu phần mềm

Danh mục rà soỏt thiết kế phần mềm

Danh mục rà soỏt khõu lập mó

Danh mục rà soỏt kiểm thử phần mềm

Trang 20

NguyễnVănVỵ

Kiểm thử phần mềm – software testing

-■Kiểm thử là tổ chức vận hành phần mềm 1 cỏch cú kế hoạch và phương phỏp để tỡm ra lỗi

■Cần vận hành như thế nào để:

hiệu suất tỡm ra lỗi là cao nhất ?

chớ phớ (thời gian, cụng sức) ớt nhất?

■Nội dung hoạt động kiểm thử bao gồm:

Kế hoạch kiểm thử

Trang 22

NguyễnVănVỵ

Cỏc loại kiểm thử

-Tương ứng với mụ hỡnh chữ V cú cỏc loại kiểm thử:

Kiểm thử đơn vị (unit testing)

Kiểm thử tớch hợp (integration testing)Kiểm thử hệ thống (system testing)

y Kiểm thử phục hồi (recovery testing)y Kiểm thử ỏp lực (stress testing)

y Kiểm thử thi hành (performance testing)y Kiểm thử an ninh (security testing)

Trang 23

NguyễnVănVỵ

Kế hoạch kiểm thử

■Kế hoạch kiểm thử tổng thể:

1 Giới thiệu chung

Mụ tả hệ thống cần kiểm thử Cỏc mục tiờu kiểm thử

Phương phỏp sử dụng Tài liệu hỗ trợ

2 Kế hoạch

Thời gian, địa điểm

Tài liệu kiểm thử: cỏc ca kiểm thử, tiến trỡnh, lịch trỡnh Điều kiện

3 Cỏc yờu cầu: phần cứng, phần mềm, nhõn sự

Trang 24

NguyễnVănVỵ Hai phương phỏp phổ biến:

Kiểm thử hộp trắng (white box) Kiểm thử hộp đen (black box) Cỏc chiến lươc Kiểm thử

Ứng dụng cho cỏc mức & loại kiểm thử khỏc nhau.

Một số chiến lược:

Chiến lược nhỏnh & toỏn tử quan hệ: BRO(đơn vị) Kiểm thử từ trờn xuống/dưới lờn/lai (tớch hợp)

Kiểm thử vụ nổ lớn (big bang – tớch hợp) Kiểm thử hồi quy (tớch hợp)

Kiểm thử luồn sợi (hệ thời gian thực)

Trang 25

NguyễnVănVỵ

Sơ đồdũng thụng tincủa tiến trỡnh kiểm thử

Biểu đồ dũng thụng tin kiểm thử

kiểm thử

Trang 26

NguyễnVănVỵ

Tiến trỡnh thực hiện ca kiểm thử

Thiết kế

Ca kiểm thửdữ liệu,đkChuẩn bị

Trang 27

NguyễnVănVỵ

Mục tiờu thiết kế ca kiểm thử nhằm:

tỡm ra nhiều sainhất

với nỗ lực &thời gian nhỏ nhất.

Cỏc phương phỏp tốtphải cho một cơ chế:

bảo đảm tớnh đầy đủ(khụng sút phần nào) và

cung cấp khả năng thật sự phỏt hiện được cỏc saiCa kiểm thử hiệu quả là ca kiểm thử phỏt hiện ra ớt

nhất 1 lỗi

Trang 28

NguyễnVănVỵ

Kiểm thử hộp trắng

Khỏi niệm kiểm thử hộp trắng

Đối tượng: mó nguồn

Mức: cỏc mụ đun đơn vị

Nội dung là khỏm xột:

cỏc chi tiết thủ tục (thuật toỏn)

con đường logic (luồng điều khiển)

Trang 29

NguyễnVănVỵ

Yờu cầu đặt ra:

Mọi con đường độc lậptrong một mụđun cần được thực hiện ớt nhất một lần.

Mọi ràng buộc logic được thực hiện cả hai phớa đỳng (true) & phớa sai (false).

Tất cả cỏc vũng lặpở biờn của nú & cả cỏc biờn vận hành phải được thực hiờn.

Mọi cấu trỳc dữ liệu nội tại được dựng để bảo đảm hiệu lực thi hành của nú

Trang 30

NguyễnVănVỵ

1 Đồ thị dũng (Tom McCabe đưa ra đầu tiờn) 2 Ma trận kiểm thử (số đường đi, trọng số).

3 Điều kiện lụgic – chiến lược miền và BRO

4 Điều khiển theo dũng dữ liệu

5 Cỏc cấu trỳc chu trỡnh – giỏ trị đặc trưng

Trang 31

NguyễnVănVỵ

xột biểu đồ điều khiển của một chương trỡnh

Vớ dụ: cấu trỳc điều khiển 1 chương trỡnh

Trang 32

NguyễnVănVỵ

luồng điều khiển

Trang 33

NguyễnVănVỵ

Để mọi lệnh đều được kiểm thử ớt nhất một lần, cần tỡm được tất cả cỏc đường điều khiển độc lập trong chương trỡnh (khỏc với cỏc đường khỏc ớt nhất một lệnh).

Số cỏc đường độc lập của 1 chương trỡnh là giới hạn trờn

số cỏc kiểm thử cần phải thực hiện Nú được gọi là độ phức tạp chu trỡnh của chương trỡnh

Cỏc đường độc lập của 1 chương trỡnh trựng với cỏc đường độc lập của đồ thỡ dũng (tim đơn giản hơn).

Trang 34

NguyễnVănVỵ Đồ thị dũng trờn gồm: 9nỳt, trong đú:5nỳt là

vị tự, 11cung, Chia mặt phẳng thành 4 miền

Trang 37

NguyễnVănVỵVớ dụ ma trận kiểm thử (t)123 45678910 11111231145 16271819101111A2 =số trong ma trận cho biết số con

đường cú hai cạnh đi qua cung đú

Trang 38

NguyễnVănVỵTrong chương trỡnh, mỗi rẽ nhỏnh xỏc định bằng biểu

thức logic Điều kiện lụgic cú thể là:

Điều kiện đơn là 1 biến Bool (cú thể cú toỏn tử phủ định): X

Điều kiện đơn là biểu thức quan hệ giữa 2 biểu thức số học

C = (A Θ B) , với Θ là phộp so sỏnh: <, ≤, =, >, ≥hay ≠

A, B là biểu thức số học

Điều kiện phức hợp cấu thành từ hơn 1 điều kiện đơn nhờcỏc toỏn tử Bool: hoặc (∪), và (∩), phủ định (┘)

D = X1& X 2 & … Xn , trong đúXilà điều kiện đơn, & là toỏn tử bool

Trang 39

NguyễnVănVỵ Kiểm thử từng điều kiện logic trong chương trỡnh.

Kiểm thử khụng chỉ phỏt hiện sai trong điều kiện mà cũn làphỏt hiện sai khỏc của chương trỡnh liờn quan.

Nguyờn tắc kiểm thử nhỏnh: với mỗi điều kiện phức hợp C, thỡ mỗi nhỏnh “true” và “false” của C, mỗi điều kiện đơn trong C phải được kiểm thử ớt nhất một lần.

Chiến lược kiểm thử miền cần 3 hoặc 4 kiểm thử cho

một biểu thức quan hệ gồm cỏc trường hợp: <, >, = và cúthể ≠ nữa.

Chiến lược BRO là kết hợp 2 chiến lược trờn

Làm sao chỉ ra tất cả cỏc trường hợp cần kiểm thử?

Trang 40

NguyễnVănVỵ Xột điều kiện C là hội biến Bool vàbiểu thức quan hệ:

C= A ∪ (B = E)

Khi đú cỏc ràng buộc của C là cỏc cặp (t,t), (t,f) & (f,t);

với (B = E) cú giỏ trịt tương ứng với “=“, và giỏ trịf

tương ứng với “<“ hoặc “>”; Bởi vậy tập cỏc đầu vào

để kiểm tra C phải gồm 4 phần tử:

(t,=), (t,<), (t,>) và (f,=).

Đầu vào phủ cỏc ràng buộc C này bảo đảm phỏt hiện được mọi sai biến Bool hoặc toỏn tử quan hệ trong C

Trang 41

NguyễnVănVỵ Đối tượng kiểm thử xem như hộp đen, thụng qua

giao diện để đưa dữ liệu vào và nhận thụng tin ra Là kiểm thửyờu cầu chức năng

Đối tương: mụ đun, hệ con, toàn hệ thống Đặc trưng:

Thuyết minh: cỏc chức năng đủ & vận hành đỳng

Thực hiện: qua giao diện

Cơ sở: đặc tả, điều kiện vào/ra và cấu trỳc dữ liệu Ít chỳ ý tới cấu trỳc logic nội tại của nú

Trang 42

Bộ mụn Cụng nghệ phần mềm – ĐHCN42NguyễnVănVỵPhần mềmKết quảraĐặc tảhệthống phần mềm1.………2….……………n ………Giao diệnChức năngdữliệuDữliệu đầu vào????Khởi đầu –kết thỳc

Đầu ra liờn quan

Trang 43

NguyễnVănVỵ

Tỡm cỏc loại sai liờn quan:

Chức năng:đủ, đỳng đắn

Giao diện:vào, ra: đủ, phự hợp, đỳng, tiện lợi

Cấu trỳc, truy cập dữ liệu: thụng suốt, đỳng đắnThực thi: trụi chảy, kịp thời, chịu lỗi, phục hồi đượcKhởi đầu - kết thỳc:mỗi tiến trỡnh bỡnh thường

Trang 44

NguyễnVănVỵ1 Phõn hoạch tương đương

Chia tập dữ liệu thành từng lớp tương đương

Mỗi lớp hoặc là đỳng hay sai, chỉ cần kiểm tra 1 sốgiỏ trị đặc trưng của nú ặ rỳt được số ca kiểm thử

2 Phõn tớch giỏ trị biờn

Cỏc sai thường ở giỏ trị biờn

Lựa chọn cỏc giỏ trị biờn của lớp phõn hoạch đểkiểm thử

3 Đồ thị nhõn quả

Lập cỏc đồ thị nhõn quả làm cơ sở xõy dựng ca kiểm thử

Trang 45

NguyễnVănVỵ

Mụ hỡnh phõn hoạch & phõn tớch giỏ trị biờn

xxxxxxxxxxxx ChọnLớp tương đương

Miền rộng Nhiều giỏ trịMiền giới hạn Một số giỏ trị

Trang 46

NguyễnVănVỵ

Là một kỹ thuật để thiết kế ca kiểm thử

Cung cấp một biểu diễn chớnh xỏc giữa cỏc điều kiện logic (đầu vào) và cỏc hành động tương

ứng (đầu ra- kờt quả).

Được xõy dựng dựa trờn cỏc mụ đun chức năng, lụgớc tiến trỡnhvàđặc tả hệ thống

Kỹ thuật gồm 4 bước

Trang 47

NguyễnVănVỵ

Tiến trỡnh kỹ thuật nhõn quả

Trang 48

NguyễnVănVỵ

Vớ dụ: kỹ thuật đồ thị nhõn quả

ModulNguyờn nhõnKết quảĐịnh danh

ASố > ađỳngA1

Số ≥ anghi ngờA2

Số = anghi ngờA3

Số < asaiA4

BSố nguyờn đỳngB1

Trang 49

NguyễnVănVỵ

Vớ dụ: bảng quyết định đồ thị nhõn quả

Định danhĐiều kiệnđỳngnghi ngờsai

Trang 50

NguyễnVănVỵ

Đối tượng: cỏc mụ đun đơn vị chương trỡnh Nội dung kiểm thử:

giao diện: dữ liệu qua giao diện, dữ liệu vào ra cấu trỳc dữ liệu sử dụng cục bộ

đường điều khiển điều kiện lụgic phộp toỏn xử lý

Phương phỏp sử dủ dụng: Phương phỏp hộp trắng

Kỹ thuật:cỏc kỹ thuật phương phỏp hộp trắng và bộlỏi, cuống

Trang 51

NguyễnVănVỵ Kiểm thử tớch hợp (integration testing) nhằm nhận

được 1 bộ phận chức năng hay 1 hệ con tốt.

Một kỹ thuật cú tớnh hệ thống để xõy dựng cấu trỳc

chương trỡnh: từ cỏc mụđun đó kiểm,xõy dựng cấu

trỳcchương trỡnh đảm bảo tuõn theo thiết kế. Cú hai cỏch tớch hợp

Tớch hợp dần: từ trờn xuống, dưới lờn, kẹp

Tớch hợp đồng thời 1 lỳc: “big bang”

Phương phỏp: phương phỏp hộp đen

Kỹ thuật:bộ lỏi, cuống

Trang 52

NguyễnVănVỵ

Cỏc sai cú thể gặp khi tớch hợp :

Dữ liệu bị mất khi đi qua một giao diện.

Hiệu ứng bất lợi 1 mụđun vụ tỡnh gõy ra đối cỏc mụđun khỏc.

Sự kết hợp cỏc chức năng phụcú thể khụng sinh ra chức năng chớnh mong muốn.

Sự phúng đạicỏc sai sút riờng rẽ cú thể bị đến mức khụng chấp nhận được.

Vấn đề của cấu trỳc dữ liệutoàn cục cú thể để

lộ ra

Trang 53

NguyễnVănVỵ

Sơ đồ - tớch hợp trờn xuống

ABCDEFIKHGABABCuống (C,D)Cuống(E,F)Cuống(E,F)Cuống (D,I,K)Cuống CKiểm thử AKết hợp theo

chiều rộngKết hợp theo chiều sõuHệ cần kiểm thử

Trang 54

NguyễnVănVỵ

Sơ đồ - tớch hợp dưới lờn

Bộ lỏi

Vũng 1Vũng 2Vũng 3

Trang 55

NguyễnVănVỵ

Chiến lược Big bang

dựng cho chương trỡnh nhỏ phức tạp, khụng hiệu quả

Chiến lược trờn-xuống

nhược điểm: cần cỏc cuống

những khú khăn kốm theo cuống.

cú ngay chức năng điều khiển hệ thống.

Chiến lược dưới –lờn:

luụn chưa cú chương trỡnh chỉnh thể

thiết kế ca kiểm thử dễ và khụng cần cuống.

Trang 56

NguyễnVănVỵ Khỏi niệm kiểm thử hệ thống

Hệ thống dựa trờn mỏy tớnh (phần cứng & phần mềm) do nhiều bờn xõy dựng, người phỏt triển phần mềm chỉlà một Chỳng cần được kiểm tra tổng thể

Những sai cần kiểm tra:

Cỏc dữ liệu qua giao diện của cỏc thành phần được

kiểm thử

Đường xử lý liờn kết cỏc thành phần

Sự tớch hợp lỗi từ cỏc thành phần khỏc nhau

Những hạn chế khỏc đến năng lực do ảnh hưởng từ

cỏc thành phõn: chịu lỗi, an toàn, thực thi

Trang 57

NguyễnVănVỵ

Cỏc loại kiểm thử hệ thống

1 Kiểm thử chức năng (mức hệ thống)

bao gồm cỏc chức năng giao diện, cỏc chức năng mức người dựng hay đầu ra cuối cựng khỏi hệ thống

2 Kiểm thử phục hồi (chịu lỗi)

kiểm thử phục hồi là bắt phần mềm phải thất bại để xem khả năng phục hồi của nú đến đõu Cú 2 mức phục hồi: phụ hồi tự động hay cần đến sựcỏn thiệp của con người

Trang 58

NguyễnVănVỵ

Cỏc loại kiểm thử hệ thống

3 Kiểm thử an ninh (sức chịu tấn cụng)

kiểm tra mọi cơ chế bảo vệ được xõy dựng xem cú đạt hiệu quả đề ra trước cỏc đột nhập hay khụng?

người kiểm thử đúng vai trũ của kẻ đột nhập thực hiện mọi đột nhập cú thể để đỏnh giỏ.

4 Kiểm thử thi hành (thụng suốt, kịp thời)

kiểm thử thi hành được thiết kế để kiểm tra sự vận hành của phần mềm khi hệ thống được tớch hợp.

Định dạng
Số trang	64
Dung lượng	541,61 KB