Luận văn các kỹ thuật kiểm thử phần mềm nhúng và Ứng dụng

Từ những hệ thống phức tạp như hàng không vũ trụ, phòng thủ quản sự, máy đi chuyên thông thường như móc tu động trong công nghiệp, đến những phương ti máy bay, xe điện, xe hơi, các

ĐẠI HỌC QUÔC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYEN THUY DƯƠNG

VA UNG DUNG

LUAN VAN THAC SI NGANH CONG NGHE THONG TLN

Hà Nội - 2014

NGUYEN THUY DUONG

CÁC KỸ THUẬT KIỂM THỬ PHÄN MÊM NHŨNG VÀ

ỨNG DỤNG

Ngành: Công nghệ thông tin

Chuyên ngành: Kỹ thuật phần mềm

Mã số: 60480103

LUẬN VĂN THẠC SĨ NGÀNII CÔNG NGIIỆ THÖNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS NGUYÊN NGỌC BÌNIL

1

Loi đầu tiên tôi xin gửi lời cảm ơn chân thành và sâu sắc đến PGS.TS Nguyễn Ngọc Binh, người thầy đã định hưởng đề tài, tận tỉnh hướng dẫn, chỉ bão tôi trong suốt

quá trình tôi thực hiện luận văn này

'Tôi xin gúi lời cảm ơn chân thành tới các thấy giáo, cô giáo trong Khoa Công, nghệ thông tin, trường Đại học Công nghệ - Đại học Quốc Gia Hà Nội đã tận tình chỉ bảo, giúp đỡ tôi trong suốt thời gian tôi học tập trường

Tôi xin được gửi lời cảm ơn chân thành tỏi gia đình, người hân, bạn bè của tôi

đã luôn cố vũ, động viên, tạo điều kiện giúp đõ tôirong suốt quá trình học tập và thực

hiện luận vần nảy

Hà Nội, tháng 10 năm 2014

liẹc viên: Nguyễn hủy Dương

LỜI CAM ĐOAN

Tôi xin cam đoan toàn bộ nội đưng trong luậnvăn này là do tôi tự nghiên cứu,

tìm hiểu Các kết quã nêu trong luận văn là trung thực, luận văn không sao chép của ai

Nếu cỏ vẫn để gi tôi xin hoàn toàn chịu trách nhiệm

Người việt cam oan

Nguyễn Thủy Dương

G QUAN VỀ KIỂM THỨ PHÂN MỀM

1.1 Khái niệm kiếm thứ phần mềm (Software 'Testing)

1.2 Mục dích của kiểm thử phần mễm

1.3 Quy trình kiểm tha phan mém co ban

1.3 I Tinh hudng kiém thử (Test Case) 8

1.3.2 Kich ban kid tht (est Script) accesses see

1.3.3 Quy trình kiềm thử phân mein - 9

tch kiểm thứ ceeeieriiieeoeoseof

1.4.1 Kiểm thử đơn vị (Unit Test) - - .13 1.42 Kiểm thú tích hợp (Integration [esf)

1.4.4 Kiểm thử chấp nhận (Acceptance Test) .lŠ

1.4.5 Một số cấp dô kiểm thử khác 16

1.5 Một số chiến lược kiểm thử

1.5.1 Kiểm thử hộp trắng (White-bos Tostine)

1.5.2 Kiểm thữ hộp đen (Black-box Testing)

1.5.3 Kiểm tht hop xaui(Gray box testing)

CHƯƠNG 2: CÁC KỸ THUAT KIEM THỦ PHAN MEM NHỨNG

2.1 Tổng quan về hệ thống nhúng và phần mềm nhúng

2.1.1 Hệ thông nhứng

2.1.2 Phần mềm những

2,2 Vòng đời phát triển phần mềm nhữn;

2.21 Giới thiệu

222 linh thánh mô hình đa chữ

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

1 Các thành phân của kế hoạch kiêm thứ tông thễ

2 Hoại động lập kế hoạch kiểm Unk ting thé

Kiểm thứ bởi nhóm người kiểm tra dộc lập

7 (Multiple V-model)

2.3 Các kỹ thuật kiểm thứ phan mềm nhúng

2.3.1 Chiến lược dánh giá rủi ro (Risk-base test sirategy}

3.3.1.1 Giới thiệu

lượu liểm tra bảo trì

2.3.2 Xem xét khả năng kiểm thử betty Review)

L6 Các kỹ thuật thiết kế kiểm thứ (Test J3esign 'Teebniquss) 35

2.3.6.1 Kiểm thử tự chuyên tiên trạng thái (Siate Transition Testing — S77) 36

gu khiển luỗng (Conirol Flaw Test} see FT

3 Kiểm thữ so sảnh cơ ban (Elementary Comparison Test — FCTJ38

.6.4 Phuong phép phin loa cdy (Classification-Tree Method kC1M)38

3,1 Một số câng cụ được dùng trong kiểm thủ phần mềm nhứng

3.1.1 Giới thiêu về trinh bién dich CodeWarrior -

3.1.2 Giới thiệu về công cụ 'TẠO (Toint Test Aetion Gronp) „ Ad 3.1.3 Giới thiệu vé chuan SWD (Serial Wire Debug) 43

3.2Tổng quan về mạch MKI,467256 và phần mềm điều khiển chuẩn (Standard

Sofware Driver - SSD)

3.2.2 Phần mềm điều khiển chuẩn cho rô-đun Flash của mạch MKL.46Z256

(Standar Sofbware Driver — 88D) 7

3.23 Thiét ké tink huồng kiểm thir cho phan mém SSD 46

3.3 Thiết lập môi trường kiểm thử

Phụ lục À: thiét ké chi tiét cua phan mém SSD

Phụ lục B: Danh sách test case của từng hàm trong phan mém SSD

TÀI LIỆU THAM KHẢO

DANH SACH CAC BANG

tác giá trí trả về của hàn FlashCommameSequenceQ, Các giá trị trả về của hàm TlashraseAlIBloek(

Các giá trị trả về của hàm TrlasbIfraseSeotor(

Cac gia tri tra vé cia ham FlashVerifyAlBlock() Cac gia tri trả về của ham Flash VerifySection(

Cac gid tri trả về của hàm FlashProgramCheck()

1Hinh 1 1: Một quy trinh kiêm thứ phần mễm cơ bán ¬- 2 Hình 1 2: Thời điểm phủ hợp dễ thiết lập các kế hoạch kiểm thử, 9 Hình 1 3: Các mức độ cơ bân của kiểm thử phần mém 13

Hình 1 4: Các loại kiếm thử khác nhau trong kiếm thử hệ thống 15

TRnh 2 2: Vòng phát triển theo mé hinh da chit V 21

Hình 3 5: Sơ đô khói Flash _— —

Tĩnh 3 8: Giao diện chứa chương trình kiểm thử của phân mềm ' SSD „u51

Hình 3 11: Kết quả thực hiện chương Hình dược trả về qua biển lestResul 33

Hinh A 1: Sơ đỗ khối của hàm FlashCommandSequence() - 36

Tinh A 2: Sơ đỏ khỏi của hàm FlashEraseAllBlock() - - 57 Tinh A 3: Sơ đỏ khỏi của hàm ElashiraseSector) 59

THinh A 4: Sơ để khỏi của hàm ElashVerifyAIIloekQ - 60

Hình A 5: Sơ dỗ khối của hảm FlashVerifySectionQ seo 2 Hình A 6: Sơ dé khoi cia ham FlashProgramCheck() 64 Hình A 7: So dé khéi cia ham FlashProgramLongword() 66

Hinh A 8: So dé khdi eda ham PFlashGetProteclion() - - 7

Hinh A 9: So dé khối của hàm PFlashSetProlcetionQ 6R

MO DA

Ngày nay hệ thống nhúng đang din trở thánh raột ngành phát triển mạnh mẽ trong Tình vực công nghệ thông lún với rất nhiều ứng dung trong công nghiệp và dời

sống Từ những hệ thống phức tạp như hàng không vũ trụ, phòng thủ quản sự, máy

đi chuyên thông thường như

móc tu động trong công nghiệp, đến những phương ti

máy bay, xe điện, xe hơi, các trang thiết bị y tế trong bênh viện, cho tới những thiết bị

truyền hình và điện thoại đi động được sứ dụng hãng ngày, dau đầu cũng có sự hiện

điện của hệ thông nhúng,

Tổ phát triển các hệ thống rửưng thì vẫn đề lập trinh và kiểm thử các phần miễn

nhúng trước khi được tích hợp vào các hệ thông nhúng là phân rất quan trọng Việc kiểm thử cáo phần mềm nhúng đóng vai trò quan trong trong việc đảm bão chat kong,

ác lỗi, nó mang tính sống càn của sản phẩm Dặc biệt với những,

giảm thiểu rủi ro về

hệ thống nhúng dỏi hỏi độ tín cậy rất cao, việc kiêm thứ các hệ thắng nảy yêu cầu cân

thận, tỉ mĩ hơn sơ với kiểm thử phản mềm thông thường,

Hệ thống nlưàng, ngàycàng được nhiều các nước trên thể giới quan tam, nghién cứu và phát triển Tuy nhiên ở Việt Nam lĩnh vực nảy vẫn phát triển khá khiêm tốn sơ

với thế giới, đặc bí

lĩnh vực kiểm thử phần mềm nhúng lại cảng khiêm tốn hơn Các tải liệu liên quan đến hoạt động kiểm thử phần mêm nhúng cũng không rhiêu Nên việc nghiên cứu, tìm hiểu các kỹ thuật kiểm thử phần mềm nhúng là raội vẫn để cản

thiết hiện nay Nó sẽ góp phần thúc đây sự phát triển của lĩnh vực hệ thống nhĩmg,, một Tĩnh vực giàn tiêm năng nhưng mới chỉ bước đâu phát triển tại Việt Nam

Mục đích của đề tài nhằm tìm hiểu, giới thiệu vẻ quy trinh kiếm thứ phần mềm

nói chung, đặc biệt là nghiên cứu các kỹ thuật kiếm thử hệ thông nhúng Ap đụng kiểm thử một phân mềm nhúng, eụ thế là phan mém điển khiễn chuẩn cho mô-đun flash của

mnạch MKL46/256 Việc kiểm thứ này sứ dụng công cụ biên dịch CodeWarrior chạy

trên môi trưởng Windows 7 Các chuơng trình được viết bằng ngôn ngữ lập trinh C

Luận văn gòm ba chương

-_ Chương 1: Trình bày tổng quan về kiểm thử phản mềm

~ Chương 3: Nghiên cứu các kỹ thuật kiểm thử phản mẫmt những,

-_ Chương 3: Tiến hành thực nghiệm kiểm thử phân mẻm điêu khiến chuẩn

cho mé-dun flash eta mach MEL 462.256

CHUONG 1: TONG QUAN VE KIEM THU PHAN w

Chương nảy tôi tập trung tìm hiểu tổng quan vẻ kiểm thứ phản mềm, khái niệm, mục dịch của kiểm thử phần mểm, quy trình kiểm thử phin mém co ban, các mức kiểm thử phân mễm và một số chiến lược kiểm thử

1.1 Khai niém kiém thir phan mém (Software Testing)

Kiém thi phan mém bi qua trinh thue thi một chương trình với mục đích tìm

1 [4]

Kiểm thử phản mềm là một phân quan trọng tạo nên thành công của các đự án

phân mêm, là khâu mẫu chết dé dam bao chất lượng phân mắm, là đánh giá cuối cùng,

về các đặc ta, thiết kẻ và mã hỏa

Có thể định nghĩa một cách dễ hiểu như sau: Kiểm thử phần mềm lá quả trình chạy thứ phản mềm hay một chức năng của phản mềm xem nó chạy đúng như mong, muốn hay không Việc kiểm ra nảy có thể thực hiện từng chặng, sau mỗi chức năng, hoặc mé-dun dược phát triển, hoặc thực hiện sau cùng, khi phần miểm dã dược phát triển hoàn tắt Trong quá trình phải triển phần mẫm, rhững người phải triển phần miễn:

và các kỹ sư kiếm thử cùng làm việc để phát hiện lỗi và đảm bảo chat lượng sản phẩm Một sản phẩm phần mềm được phân phối phải só đây đủ cáo chức năng yêu cản và

tương thích với phản cứng của khách hàng,

1.2 Mục dích của kiểm thứ phần mềm

Kiểm thủ phản mềm nhằm vào hai mục đích chính lá: Dura ra những chứng nhận vẻ chất lượng và phát hiện sửa lỗi phần mẻm Thiết kế kiểm thử là một trong những công cụ ngăn chặn lỗi tốt nhất được biết dến Nó có thể phát hiện và loại bỏ

†ại mọi piai doạn của quả trinh thiết kế phân mềm, từ ý tướng dén dặc tá, thiết kê, viết

mã và phản còn lại

1.3 Quy trình kiểm thử phần mềm cơ bản

Trước khi tìm hiểu một quy trình kiểm tra pha

Tiêm sau: tình huồng kiểm thứ (Test Case) va kich ban kiểm thữ (Test 8eripl)

1.3.1 Tình huống kiếm thử (Test Case}

hi lập trình một phần mềm hay bất ky một cái gỉ thì việc dự đoán rước các

mêm cơ bàn cân hiểu hai khái

tình huồng xáy ra cho chương trình đó là rất quan trọng, Vì thế khi viết chương trình

người kiếm thủviên thường viết trước các tình huồng kiểm thử đề đự đoán các trường

hợp

Một tình huống kiếm thử có thé coi nôm na là một tình huống kiếm tra, được

thiết kế để kiểm thứ một đổi tượng có thỏa mãn yêu cầu đặt ra hay không

Một tình tuồng kiểm thứ thường bao gồm ba phần cơ báu:

«_ Môtá: Đặc tá các điều kiện cân có đề tiên hành kiểm thử

ø Nhập: Đặc lâ đổi tượng hay đữ liệu cần thiết được sử dụng làm đầu vào

để thực hiện việc kiểm thử.

9

© Ket quả mong chờ: Kết quả trả về từ đối tượng kiểm thử chứng tỏ đối

tượng đạt yêu cảu

Tỉnh huồng kiểm thử cảng nhiêu độ tin tưởng cảng cao chất lượng công việc cảng tốt

1.3.2 Kịch bản kiểm thir (Test Script)

Một kịch bản kiêm thử là một nhóm mã lệnh dạng đặc tả kịch bản đủng đề tự

động hỏa một trình tự kiểm thử, giúp cho việc kiểm thử nhanh hơn hoặc cho những trường hợp mả kiêm thử bằng tay sẽ rất khỏ khăn hoặc không kha thi Cac kich bản kiểm thử có thể tạo thủ công hoặc tạo tự động dùng công cụ kiểm thử tự đông

1.3.3 Quy trình kiểm thử phần mềm

Những hảnh động chính trong quy trình kiểm thử phần mềm gồm:

Hình 1 1: Một quy trình kiểm thứ phần mềm cơ bản

1.3.3.1 Lập kế hoạch kiểm thử

Lập kế hoạch kiểm thử là đẻ chỉ ra các loại kiểm thử, chiến lược kiểm thử thâm

chỉ là cả thời gian và xác định lực lượng kiểm thử viên cho dự án cần kiểm thử Kết quả của bước lập kế hoạch kiểm thử là bản tài liệu về kế hoạch kiêm thử phần mẻm

Bản kế hoạch nảy cỏ thể coi là bản kếhoạch chính trong đỏ có tất cã các kẻ hoạch chỉ tiết cho các mức kiểm thửnhư kiêm thử đơn vị, kiềm thử tích hợp, kiểm thử

hệ thông, kiểm thử chấp nhận vả các chiến lượng kiểm thửnhư kiểm thử hộp den, kiểm thử hộp trắng, kiểm thử hộp xảm đều được đề cập

Kế hoạch kiểm thử chấp nhan (Acceptance test plan)

Kế hoạch kiểm thử hệ thông (System test plan)

Kế hoạch kiểm thử tích hợp (Integration test plan)

Kế hoạch kiểm thử don vj (Unit test plan)

Các bước trong viêclập kế hoạch kiểm thữ gm

œ Xác định yêu cầu kiểm thứ: xác định rõ các mô-đun, thành phân của phân

mềm cần được kiểm thứ, chí rồ phạm vi hoặc giới hạn của việc kiểm thử.Các yêu cầu chức năng, phi chức năng của phần mềm cản kiểm thứ

« Khảo sát rủi ro: Xác định và đánh giá ảnh hưởng của các rủi ro có khả

năng xây ra lên dụ án như ánh hướng đến thời gian, chất lượng, chỉ phí kiểm thứ phần mềm

«Xác định chiến lược kiếm thử: Chỉ rõ chiến lược sử dụng để thực hiện

kiểm thử phần mêm, các kỹ thuật thiết kề tỉnh huồng kiểm thủ, các công

cụ hỗ trợ kiểm thử nếu có Các phương pháp đánh giá chất lượng kiểm thử cũng như điều kiện để xác định thời gian kiểm thử

œ_ Xác định nhân lực, vật lực: Xác định số lượng kiểm thử viên cần thiết đựa

vào kỹ năng, kinh nghiệm của kiếm thứ viên Chỉ rõ các yêu câu vẻ phân cứng, phân mềm, công cụ cần thiết cho việc kiểm thử

« Lập kế hoạch chỉ tiết: Tỉnh toán ước lượng thời gian thục hiện và hoàn

thành kiếm thử Xác định khối lượng công việc, chỉ tiết các phân công

„ thời gian cho từng kiểm thứ viên

©) Téng hợp và tạo các bản kế hoạch kiểm thử: Bản kế hoạch chúng của dự

ví

ám và bản kế hoạch chỉ tiết thực hiện kiểm thứ

œ Xem xét các kế hoạch kiểm thử: Sau khi có được bản kế hoạch kiểm thử

kế hoạch là khả thị, cũng như dễ phát hiện và sửa

phải có sự tham gia cũ những rugười liên quan để xcm gia whim bio dim ci

chữa các sai sót trang bản kế hoạch

1.3.3.2 Thiết kế kiểm thứ

Việc thiết kế kiểm thử là để xây dựng

êm thử (Test Case), md

†ã chỉ tiết tùng tình huồng, xác định các yên cầu đâu vào và đầu ra mong đợi của từng,

tỉnh huồng kiểm thử

Sau khi có được kế hoạch kiểm thử thi việc thiết kẻ kiểm thử là việc rất quan trọng vì việc xây dựng, các tỉnh huồng kiếm thir cin dam bao “quét” hết tắt cá các yêu cầu cần kiểm thứ Vị vậy vệc thiết kế kiểm thử không, chỉ làm một lần,nỏ sẽ được sửa chữa, cập nhật, thêm hoặc bớt xuyên suốt chu ky phan mém, vio bat ctr luc nao có sự

tỉnh huồng k

thay đỗi yêu câu hoặc sau khi phân tích thấy cần được sửa chữa hoặc bỗ sung,

Các buốc thiết kế kiểm thử bao gồm

© Xác dịnh và mô tả tình hướng kiểm thủ: Xác dinh, mô tả các diễu kiện

n tết lập trưc trong lúc kiểm thử Mỏ tã đổi lượng hoặc dữ liệu đầu vào, mô tâ các kết quả đầu ra raơng đợi sau khi kiểm thử

© Mé ta cdc bute chi tiết để kiểm thứ: Mô tả chỉ tiết các bước của một tỉnh

huồng kiểm thir dé dé dang cho việc viết mã nguồn thử và thực hiện

nh các loại dữ hệu mào cần có để thục

kiểm thứ Thao tác này cứng chỉ

11

thi cac tinh huéng kiểm thứ chúng bao gẻm các loại đữ liệu trục tiếp, gián tiếp, trung gian, hệ thông

œ Xem xét và khảo sát độ bao phủ của việc kiếm thủ: mô tã các chỉ sẻ và

cách thức xác định việc kiểm thứ đã hoàn thành hay chưa, bao nhiêu phẩn trăm phản mềm đã dược kiểm thử Để xác dịnh dược điều nảy có hai phương pháp: căn cứ trên yêu cảu của phần mềm hoặc căn cử trên số lượng tình huồng kiếm thử và má nguồn đã viết

« Xem xét tình huông kiểm thứ và các bước kiểm thứ: Xhằm đám bảo các tình huồng kiểm thử và đỡ liệu yêu câu là đủ, phán ánh đúng các yêu cầu cân kiểm thé, dé bao pha dat yéu cau cũng như để phát hiện và sửa chữa

trong các loại và các mức kiểm thử

Các bước phát triển kịch bản kiểm thủ:

« Tao kich bản kiểm thử: Làu thủ công hoặc dùng công cụ hỗ trợ đễ phát

sinh các kịch bân một cách tự động Các kịch bản kiểm thử có khã năng

tái sử đựng cảng nhiều cảng tột đề tếi tru hóa công việc

œ Kiểm thử các kịch bản: Xem có “chạy” tốt không nhằm đảm bảo các kịch

‘ban kiém thử hoại động đúng yêu câu, thể hiện đúng ý đỗ của các bước

kiểm thử

«_ Lhành lập các bộ đữ liệu ngoài dành cho các kịch bán kiểm thú: Bộ dữ

liêu này sẽ dược các kịch bản kiểm thử sử dụng kiú thự hiện kiểm thử tự

động,

« Xem xét vả khảo sát độ bao phú của việc kiểm thủ: lão đám các kịch bán kiểm thử được tao ra bao phủ toàn bộ các bước kiểm thử theo yêu cầu

1.3.3.4 Thực hiện kiểm thử

Thực hiện các bước kiểm thứ đã thiết kế (hoặc thi hảnh các kịch bán kiểm thứ

néu én hanh Lự động) và gìủ nhận kết quả

Các buốc thực hiện kiểm thử

«Thực hiện các bước kiểm thử: Thao tácđầu tiên cần làm là xác lập, khởi động môi trường vả điều kiện kiểm thử Việc nảy nhằm bảo dim tat ca các bộ phản liên quan đã dược cài dặt sẵn sảng trước khi bắt dâu kiểm

thử

« Đánh giả quả trình kiểm thứ: Giám sát quả trình kiếm thử đến khi hoàn thành hay bị treo va dùng giữa chững, có cản bổ sung hay sửa chửa gì không đề quá trình kiểm thử được tối hơn

« Thẩm định kết quả kiểm thứ: Sau khi kết thúc kết quả kiểm thứ cần được xem xét để báo đăm kết quả nhận được là đáng tin cậy, cững như nhận

biết được các lỗi xây ra không phải do phân mềm má do dữ liệu dùng để kiểm thủ, môi trường kiểm thử hoặc do các bước kiểm thử gây ra Nếu Thực sự lỗi xảy ra do quả trình kiểm thử càn phải sửa chữa vả kiểm thử lại

từ đầu

1.3.3.5 Đánh giá quả trình kiểm thứ

nh giá toàn bộ quá trình kiểm thử, bao

om xem xót vả đánh giá kết quả

kiểm thủ, liệtzê lỗi, chỉ định các yêu cau thay đổi và tính toán các số liệu liên quan đến

quá trình kiếm thử (chẳng hạn như số giờ, thời gian kiếm thủ, sổ lượng lỗi, phân loại lãi )

Các bước đánh giá kết quá kiểm thứ:

œ _ Phân tích kết quả kiếm thử và để xuất yêu câu sửa chữa: Chỉ định và đánh giá sự khác biệt giữa kết quả mong chờ và kết quả kiếm thử thực tế, tổng hợp và gửi thông tin yêu câu sửa chữa đến những người có trách nhiệm trong dự án, lưu trữ để kiểm thứ sau đó

« Đánh giá độ bao phủ: Xáo định quả trình kiểm thử có đạt được độ bao

phủ yêu câu hay không, tỷ lệ yêu cầu đã được kiếm thủ

œ- Phâu tích lỗi: Ehm ra số liệu phục vụ cho việc câi tiến các qui tinh phát triển, giảm sai sót cho các chu kỳ phát triển và kiếm thử sau đó Ví đụ

tỉnh toán tỷ lệ phát sinh lỗi, xu hướng gây ra lỗi

œ_ Xác dịnh quả trình kiểm thử có dạt yêu cầu hay không: Phân tích đánh giá

được các yêu chu dir an hay khong Từ những kết quả này kiểm thử viên

có thể sẽ phải thay đổi chiến lược hoặc cách thức kiểm thử

« Bao edo ting hop: Tang hợp kết quả các bước ở trên và phôi được gửi cho tát cả những rigười có liêu quan

lG nhau và có THÔI lượng quan VỚI chăng phải triển trong

đuán phần mềm Sau đây là các mức độ cơ bản của kiểm thử phản mềm [S]

Hình 1 3: Các mức độ cơ bản của kiêm thử phần mềm

1.4.1 Kiểm thử đơn vị (Unit Test)

Một đơn vị (UniU) là một thành phần phản mềm nhỏ nhất mà ta có thể kiểm thử

được, ví dụ: các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method),

Vi kiểm thử mức đơn vị được chọn đẻ kiểm thử thường cỏ kich thước nhỏ và

chức năng hoạt động đơn giản, nên không khó khăn gì trong việc tổ chức, kiểm thử,

ghi nhận vả phân tích kết quả kiểm thử Nếu phát hiện lỗi, việc xác định nguyên nhân

và khắc phục cũng tương đổi dé dang vì chỉ khoanh vùng trong mộtđơn vị đang kiểm thử Một nguyên lý đúc kết từ thực tiên: thời gian tốn cho kiểm thử đơn vị sẽ được đền

bù bằng việc tiết kiệm rất nhiều thời gian và chỉ phí cho việc kiểm thử và sửa lỗi ở các mức kiểm thử sau đỏ

Kiểm thử đơn vị thưởng do lập trình viên thực hiện Công đoạn nảy càn được thực hiện cảng sớm cảng tốt trong giai đoạn viết mã nguồn và xuyên suốt chủ kỷ phát

triển phân mềm

Cũng như các mức kiểm tra khác, kiểm thử đơn vị cũng đỏi hỏi phải chuẩn bị

trước các tình huồng (Test case) hoặc kịch bản (Script) trong đỏ chỉ định dữ liêu vào,

các bước thực hiện và dữ liệu mong chờ sẽ xuất ra

1.4.2 Kiểm thử tích hop (Integration Test)

Kiểm thử tich hợp là kiểm thử khi ghép nổi các hàm hay các mô-đun đã được kiểm thử đơn vị lại với nhau Trong khi kiểm thử đơn vị kiểm thử các thành phan và

đơn vị riêng lẻ thì kiểm thử tích hợp kết hợp chúng lại với nhau vả kiểm thử sự tương,

thích giữa chúng

Trong các dự án lớn hệ thông thường được chia thành các mô-đun để nhiều nhóm củng phát triển Các mô-đun nảy thường được lập trình viên kiểm thử bằng kiểm

thử đơn vị Sau đó các mô-đun này được ghép lại với nhau thành hệ thông Việc ghép

nảy có thể xảy ra lỗi ở mức giao diện giữa các mô-đun Việc kiểm thử tich hợp đề tìm

lỗi trong quá trình ghép này là rắt quan trọng bởi vi

«Các mô-đum có thể do các nhóm phát Iriển khác nhau nên mặc dù đã có

sự thông nhất vẻ giao tiếp gia các mồ đun thì vẫn có thế xảy ra lỗi ở đây

xiên kiếm thử tích hợp giúp phát hiện lỗi giao tiếp xảy ra giữa các mô-đun

œ Một số các mé-dun ban chất là phức tạp nên đễ xây ra lỗi, cản phái xác định được các mô-đun nảo gây ra nhiều lỗi nhất

«_ Tích hợp các đơn vị dơn lẽ thành các hệ thống nhỏ (subsystem) và cuối

cũng là hệ thông hoàn chỉnh (systetn) với các lỗi phát hiện được sữa chữa

đề chuẩn bị cho kiểm thir 6 mic hé thong (System Test)

Một chiến lược cần quan tam long kiếm thé Lich hopla nén lich hop dan từng mé-dun vào hệ thống Tại thời điểm chuẩn bị tích hợp mö-đun mới thì phải dam bao các mô-đun được tích hợp trước đó đã được thục hiện kiểm thử tích hợp rồi Diễn này đảm bão sai sói giảm di ding ké va lúc này chỉ cẩn kiểm thử sự tương thích giùa mô- dun mới thêm vào với hệ thông các mô-dun đã dược tích hợp trước dỏ

1.4.3 Kiếm thir hé thong (System Test)

Kiểm thử hệ thông là kiểm thử toản bệ hệ thống sau khi tịch hợp có théa min yêu cầu dặi ra hay không

Kiểm thữ hệ thống bắt đâu khi tắt cả các bộ phân của phần mềm đã được tích

hợp thành công Thông thường loại kiếm thử nảy tốn rất nhiều công sức và thời gian.Ở mức độ hệ thống người kiểm thử cũng tìm kiểm các lỗi nhưng trọng tâm là đánh giá về hoạt động, thao †áe, sự tin cậy và các yêu câu khác liên quan đến chất lượng của toàn

hệ thông

Diễm khác nhau then chốt giữa kiểm thử tích hợp va kiểm thứ hệ thẳng là kiểm thứ hệ thông chủ trọng các hành vị và lỗi trên toản hệ thống còn kiểm thử tich hợp chủ trọng sự giao tiếp giữa cdc don thể hoặc đổi tương khi chúng làm việc cùng nhau Thông thường phải thực hiện kiểm thử don vị và kiểm thử tích hợp dé dam bảo mọi

don vị và sự tương lắc giữa chúng hoại dộng chính xác trước khi thục hiện kiểm thử hệ

thống

Đôi hỏi nhiều công sức, thời gian và tỉnh chính xác, khách quan nên kiếm thử

hệ thống thưởng được thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với nhóm phát triển dự án

Ban thân kiểm thư hệ thống lại gồm nhiều loại kiểm thứ khác nhau, phổ biến nhất gồm:

« Kiểm thủchức năng(Functional TesQ: bão đâm các hành vi của hệ

thống thỏa mãn đứng yêu cầu thiết kể

œ Kiểm thủkhả năng vận hanh (Performance Test): bao dam tdi uuviée

phân bó tải nguyên hệ thông (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng yêu câu truy vẫn

© Kiểm thữkhã năng chịu tải (Stress Test hay Toad TesÙ: bảo đâm lệ thống vận hành đứng dưới áp lực cao (vi dụ nhiều người Huy xuatotnghic )

15

©_ Kiểm thứcâu hinh (Configuration Test)

© Kiem thikha ning bao mat (Security Test): bảo dam tinh toan ven, bao mật của đữ liệu và của hệ thông

© Kiem thikha năng phục hôi (Recovery Test): bảo đảm hệ thông cỏ kha

năng khôi phục trạng thái ồn định trước đỏ trong tình huồng mất tai

nguyên hoặc đữ liệu, đặc biệt quan trọng đối với các hệ thông giao

dịch như ngân hàng trực tuyến

Các loại kiểm thử trên rất quan trọng việc bảo đảm hệ thông đủ khả năng làm việc trong môi trường thực.Nhưng không nhất thiết phải thực hiện tất cả các loại kiểm

thử trên Tủy yêu cầu vả đặc trưng của từng hệ thong, tuy khả năng vả thời gian cho phép của dự án mả áp dụng những loại kiểm thử nào

Kiểm thử

Kiểm thừ | khảnang | Kiểmthừkhả | Kiểm thử cấu | Kiểm thừkhả | Kiểm thừ khả

chức năng | chịutải | nâng bảo mật hình nâng vận hành | năng phục hỏi

+ Kiểm tra đã hoán thánh

Hình 1 4: Các loại kiểm thử khác nhau trong kiểm thử hệ thông

1.4.4 Kiểm thử chấp nhận (Acceptance Test)

Kiểm thử chấp nhận là để chứng minh phân mềm thỏa mãn tất cả các yêu cau của khách hàng và khách hang chấp nhận sản phẩm Kiểm thử chấp nhận có ý nghĩa hết sức quan trọng, mặc dủ trong hâu hết trường hợp các phép kiểm thử của kiểm thử

hệ thông gần tương tự như kiểm thử chấp nhận nhưng bản chất và cách thức thực hiện lại rất khác biệt

Đối với những sản phẩm danh bản rộng rãi trên thị trường cho nhiều người sử

dụng thông thường sẽ qua hai loại kiêm tra gọi là Alpha Test va Beta Test Với Alpha

Test người sử dụng kiểm thử phần mềm ngay tại nơi phát triển phần mềm, lập trinh viên sẽ ghi nhận các lỗi hoặc phản hỏi vả lênkế hoạch sửa chữa VớiBeta Test phần mềm sẽ được gửi tới cho người sử dụng đề kiểm thử ngay trong môi trường thực, lỗi

hoặc phản hỏi cũng sẽ gửi ngược lại cho lập trình viên đẻ sửa chữa

'Lrên thực tế nếu khách hàng không quan tâm và không tham gia vdo quả trình phát triển phân mềm thi két quả kiểm thử chấp nhận sẽ sai lệch lớn mặc du phản mềm

đã trải qua tất cả các kiểm thử trước do Su sai lệch này liên quan đến việc hiểu sai yêu câu cứng như sự mong: chủ của khách hàng

Ví đụ đôi khi một phần mềm xuât sắc vượt qua các phép kiếm thử vẻ chức nắng, thực hiện bởi nhóm thực hiện đự án nhưng khách hàng khi kiểm thữ sau cùng vẫn thất vọng vì bổ cục mản hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sử

dụng của khách hàng

Gắn liễn với giai đoạn kiểm thứ chấp nhận thường lả một nhỏm những dich vu

và tài liệu di kèm, phổ biến như hưởng dẫn cải dặt, sử dụng Tất cả tài liệu di kèm phải dược cập nhật và kiểm tra chặt chẽ

1.4.5 Một số cấp độ kiểm thử khác

Kiểm thủ héi quy (Regression Test)

Trước tiên cần khẳng định dây không phát là một mức kiểm thứ như các mức khác đã nói trên Nó đơn thuận kiểm thử lại phần mềm sau khi có một sự thay đối xảy

ra, để đảm bảo phiên bản phân mềm mới thực hiện tốt các chức năng như phiên bản cũ

và sự thay đối không gây ra lỗi mới trên những chức năng vốn đã làm việc tốt Kiểm

thứ hồi quy có thể thực hiện tại mọi mức kiểm tra

Vì dụ một phần mềm đang phát triển khi kiểm thử cho thấy nó chạy tốt các

chức năng A, và C Khi có thay đôi mã nguồn của chức năng © nếu chỉ kiểm thự

Mặc dit khéng là một mức kiếm thử thưc tẻ cho thấy

trong những loại kiểm thử tôn nhiễu thời gian và công sức nhất Tuy vậy việc bé qua

kiểm thứ hỏi quy là “không được phép” vỉ có thể dẫn đến tình trạng phát sinh hoặc tái xuất hiện những lỗi nghiềm trọng mặc di hưởng rằng những lỗi đó hoặc không có hoặc

đã được kiểm thử và sửa chữa rồi

Kiém thủ tính đúng (Correctness testing)

Tỉnh dúng dẫn là yêu cầu tối thiểu của phần mềm, lá mục dich chủ yếu của kiếm thử Kiếm thử tính đúng sẽ cần một kiếu người đáng tin nào đó,

hoạt động đứng đẫn từ cách hoạt động sai lâm Kiểm thử viên có thế biết hoặc không

biết các chỉ tiết bên trong của các mođun phân mềm được kiểm thứ, ví đụ luẳng điều

1.5 Mật số chiến lược kiểm thử

1.5.1 Kiểm thử hộp trắng (White-box Testing)

Kiểm thử hộp trắng lả phương pháp thiết kế trường hợp kiểm thử khám phá cầu trúc bên trong của chương trình để suy ra các trường hợp kiểm thứ [5]

+ >

Hình 1 5: Kiểm thử hộp trắng Kiem thử hộp trắng được hỗ trợ bởi một số công cụ phan mềm, dạng đơn giản nhất là kiếm thử mọi dòng lệnh thông qua một số công cụ gỡ lỗi (debugging tool hay debugger) giúp đỏ vết khi thực hiện chương trình Do đỏ người kiểm thử có thể biết được khi một lệnh được thực thi, kết quả của nỏ cỏ như mong muôn hay không Ưu điểm của cách kiểm thử này là khi phát hiện được lỗi đồng thời cũng xác định được lỗi ngay, tuy nhiên nó yêu câu người kiểm thử phải thông thạo mã nguồn vả các lỗi về sự thiểu sót, sự sai trong thiết kẻ rất khó được phát hiện Kiểm thử hộp trắng nên được

thực hiện bởi chỉnh những người viết chương trình đỏ thi việc phát hiện và sửa lỗi mới

dé dang

1.5.2 Kiểm thử hộp đen (Black-box Testing)

Kỹ thuật kiểm thử hộp đen xem chương trình như là một hộp đen [5]

® ^ .ằ«sằẲ"

Hình 1 6: Kiểm thử hộp den Các phương pháp kiểm thử hộp đen tập trung vào các yêu cầu chức năng của phần mềm, tức là kiểm thử hộp đen làm cho kỹ sư phần mềm suy ra được tập các điều kiện vào sẽ thao diễn qua tất cả các yêu câu chức năng đối với một chương trình

Dang don giản nhất của kiểm thử hộp đen lá bắt đầu chay chương trình và quan sát để tìm ra những hảnh vi, những hoạt động mong muỏn và không mong muốn Dạng kiểm thử nảy được gọi là kiểm thử vô thể thức.Kiểm thử hộp đen có thể tuân

theo quy trình kiểm thử ở trên, bao gồm các hoạt động chính là lên kế hoạch, thực thi,

phân tích vả theo dõi

1.5.3 Kiểm thử hộp xám(Gray box testing)

Kiểm thử hộp xảm đỏi hỏi phải có sự truy cập tới cầu trúc dữ liệu vả giải thuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở mức người sử dụng hay mức hộp đen Việc thao tác tới dữ liệu đầu vào và định dang dữ liệu đầu ra là không rõ rảng, giồng như một chiếc “hộp xảm”, bởi vi đâu vảo và đầu ra

rõ ràng là ở bên ngoài "hộp đen”vần gọi về hệ thông được kiểm tra

Các chiên lược kiểm thử không loại trừ lẫn nhau, sử dụng riêng rẽ hay đồng

thời Với một ứng dụng phải sử dụng nhiều chiến lược để phát hiện được hết lỗi

NHÚNG

Chương này tới lập rung nghiên cứu các kỹ thuậi kiểm thử phần mềm nhúng,

sau đỏ có sự sơ sánh đành giá các kỹ thuật kiểm thứ phần mễm nhúng với kiểm thử

2.1 Tong quan về hệ thống nhúng và phần mềm nhúng

2.1.1 Hệ thống nhúng

Hệ

khả năng tự trị được nhúng vào trong một môi trường hay một hệ thống mẹ Dó là các

hệ thống tích hợp cả phần cứng và phin phêm phục vụ cáo bài toán chuyên dụng trong nhiều lĩnh vực công, nghiệp, tự dong hoá điều khiển vả truyền từn Đặc điểm của các hệ thông nhúng, là hoạt động ôn dịnh và có tính năng tự động hoá cao.[2]

Hệ thông nhùng thưởng dược thiết kế dễ thực hiện một chức năng chuyên biệt

ống nhúng (Embedided syslem) là muội thuật nữ để chỉ một hệ thống có

xảo đó Khác với các máy tình đa chức răng, chẳng hạn như ruáy tình cả nhân, một hệ

thống nhúng chỉ thực hiện một hoặc một vài chức năng nhất định, thường đi kèm với những yên cầu cụ thể và báo gồm mnột số thiết bị máy móc và phần cứng chuyên dụng

mmả khó tìm thấy trong một máy tính đa năng nói chung,

Vì hệ thông chỉ được xây dụng cho mét số nhiệm vụ nhất định nên cáo nhà thiệt

kế có thể tối ưa hóa nó nhằm giảm thiên kích thước và chỉ phí sản xuất Các hệ thống nhúng thường dược sẵn xuất hàng loạt với số lượng lớn Hệ thông nhúng rat da dang, phong phú về chúng loại Đỏ có thẻ là những thiết bị cảm tay nhỏ gọn như đồng hỗ kĩ

thuật số hay máy chơi nhạc MP3, hoặc những sân phẩm lớn như đèn giao thông, bỗ

kiểm soát trong nhà máy hoặc hệ thống kiểm soái các máy năng lượng hại nhân Xét

về độ phức Lạp, hệ thống nhúng có thế rất đơn giãn với một vì điều khiển hoặc rất phức

tạp với nhiều đơn vị, cáo thiết bị ngoại vì và mạng lưới đượo nằm gọn trong một lớp

võ máy lớn

Co rat rat nhiều các ứng dụng của hệ thông những đang được sử dụng hiện nay

và xu thể sẽ củn tiếp tục tăng nhanh Một số các lĩnh vục vả sán phâm thị trường rộng, lớn của các hệ thống nhúng như:

« Các thiết bị điều khiển

« Ôlô, làu điện

« Truyềnthông

« Thiếtbjytế

«- Hệ thống đo lường thậm định

« Toảnhẻ thông minh

ø _ Thiết bị trong các dây truyền sẵn xuất

« Rabat

Hình 2 1: Ví dụ vẻ ứng dụng của hệ thông nhúng Một ví dụ về hệ thông nhúng mả ngảy nay nhiễu người sử dụng là chiếc điện thoại di động Các chức năng như điểu khiển mản hình hiển thị, máy nghe nhạc vả radio, bộ cảm ứng chụp hình, kết nổi với máy tính vả thiết bị ngoại vi, hoặc cao cấp hơn là kết ni với hệ thông định vị toàn cầu (GPS), tất cả đều là những hệ thống nhúng, được tích hợp chung vào chiếc điện thoại

Độ tin cậy của hệ thống nhúng:

Các hệ thông nhúng thường được tích hợp vào những cỗ máy được kỷ vòng sẽ

chạy ôn định, liên tục trong thời gian dải, tỉnh bảo mật cao, không bị lỗi hoặcnêu có

lỗi xảy ra thì có thể khôi phục lại được nhanh chong Vi thé cac phan mem của hệ

thông nhúng được phát triên và kiêm thử với các yêu câu cao, đảm bảo an toản, cân sự can than, ti mi hon lả phản mêm cho máy tỉnh cá nhân

Ngoài ra, các thiết bị rời không đảng tin cậy như ô đĩa, công tắc hoặc nút bám

thường bị hạn chẻ sử dụng Việc khôi phục hệ thổng khi gặp lỗi có thé được thực hiện bằng cách sử dụng các kỹ thuật như watchdog timer — nêu phân mềm không déu dan nhận được các tín hiệu watchdog định kì thì hệ thông sẽ bi khởi động lại

2.1.2 Phần mềm nhúng

La phan mém trong các hệ thông nhúng Phẩn mềm nhúng cỏ thẻ là những chương trình đơn giản chạy trực tiếp trên nên phần cứng hoặc là những chương trình,

ứng dụng chạy trên nên một hệ điều hành nhúng Phần mềm nhúng thường chạy với số

tải nguyên phần cứng hạn chẻ: không có bản phím, mản hình hoặc cỏ nhưng với kich

thước nhỏ, bộ nhớ hạn chế

Phan mem nhing thường được lập trinh trên máy tính cá nhân của lập trình viên, được biên dịch với một trình biên dịch và một môi trường phát triển, máy tỉnh

đúng để lập trình được gọi là host Sau đó chương trình được nạp lên thiết bị và chạy, thiết bị mà chương trình dược nạp lên gọi là target Với mỗi target khác nhau sẽ có cầu trúc vị điều khiển khác nhau, và sử dụng hệ điều hành nhúng khác nhau, do vậy tủy

từng loại sẽ có các cách thức lập Irình tương ứng

€ là một trong những ngôn ngữ lập trình nhúng phé biển nhất hiện nay Œ có một số tru điểm nổi bật tiêu biểu như khá nhỏ và dé dang cho việc học, các chương trình biên địch Œ thường khả sẵn cho hầu hết các bộ xử lý đang sử đụng hiện nay, và

só rất nhiền người đã biết và làm chủ được ngôn ngữ

Việc kiểm thử phần mễm nhúng củng có cáo đặcđiểm tương tự như kiểm thứ phần mềm nói chưng, ngoài ra do đặc trưng của hệ thống nhúng rất da dạng về môi trường phát triển, da đạng về kiến trúc phần cứng cũng như kiến trúc phan mềm nên

kiểm thử cho phần mềm nhúng có một số đặc trưng riêng,

Trong luận văn này sẽ trinh bảy một số kỹ thuật kiểm thử phảu mềm nhóng hay

được dùng,

2.2 Vàng dời phát triển phần mém nhúng

2.2.1 Giới thiệu

Trong một hệ thông nhúng, đối tượng kiểm thử không chỉ là các đoạn code thục

thị LIệ thông này thường được phát triển qua nhiều giai đoạn sẵn phẩm, kết quả là săn

phẩm cuếi cùng phù hợp với thực tế hơn Mô hình đầu tiên của hệ thống được xây đụng trên máy tinh, mô phỏng các cách hành xử cần thiết của hệ thêng Khi mô hình

do duge xem lá chỉnh xác, mã được tạo ra từ mô hinh vả nhúng vào một nguyễn mẫu

(prototype) Cac phan cứng thi nghiệm của các nguyễn mẫu dược dẫn thay thế bằng, phân cứng thực tế, cho dến khi hệ thống được xảy dựng hoàn chính và dược dưa vào

ấn phẩm trung gián, đó là thay đổ

sử đụng Lý do cho việc xây dựng cá

thử nghiệm rẻ hơn và nhanh hơn là thay đổi các sân phẩm cuối cùng, thậm chí rẻ hơn

và nhanh hơn đề thay đổi mô hinh

2.2.2 Hình thành mô hình đa chữ V (Multiple V-model)

Trong suốt quá trinh phát triển, hình dang của hệ thống cỏ sự thay đối Đâu tiên

Ja mé hình mỏ tá hành vi hệ thông, rồi đến các nguyên mẫu và được lặp đi lặp lại cho tới hình dạng cuối củng của hệ thống Dùng mô hình đa chử V để mô tá vòng, đời phát triển cúa hệ thống nhúng

Mô hình da chữ V là một mộ hình phát triển trong đó tất cả những dạng sản phẩm (mô hình, nguyên mẫu, sản phẩm cuối củng) tuân theo một vòng, phát triển hình chit V, bao gam thiết kế, xây dựng và kiểm thử, Bản chất của mô hình da chữ V là sự khác nhau về phiên ban vật lý của củng một hệ thông đang được phát triển, tất cả các

xử lý đều cân các chức năng chung trong nguyên lý Tức là toàn bộ các chức năng có

thế được kiểm thủ như nhau tại mô hình, nguyên mẫu và sản phẩm cuổi cùng, Tuy

nhiên, trong mỗi giai đoạn phát triển thì có một số chức năng cần thiết phải kiểm thử tương img với giải đoạn đỏ Kiểm thử các phiên bản vật lý khác nhau cần phải có

những kỹ thuật dặc biệt và các mội trường kiểm thử chuyên biệt Vì thể hiên có một

21

mối quan hệ mật thiết giữa mô hình đa chữ V với môi trường kiểm thử Mô hình đa

chữ V có sự phát triển lặp lại và song song với chữ V ở giữa.[1]

những chức năng cần thiết Sau đó có thể phát triển các thành phần (component) một

cách song song và từng bước thực hiện tích hợp các thành phần Mô hình đa chữ V áp

dụng cho tất cà các thành phân Với tất cả các thảnh phan, một mô hình có thể được phát triển, tiếp theo đó lả bước phát triển lặp lại của phần cứng và phần mém, Tich hop các thành phân khác nhau có thẻ được thực hiện tại một số thời điểm trong quy trinh phát triển phần mềm tử rất sớm với phân cứng thi nghiệm trong giai đoạn phát triển

nguyên mẫu hay muôn hơn, với sản phầm cuỏi củng khi các thành phân của sản phầm

đã được phát triển đây đủ vả tích hợp thảnh công

Mô hình “Multiple V° lông: Khi mô hình chữ V ở mức hệ thống kết hợp với mô hình "Multiple V" ở mức độ thành phân sẽ tạo thành mô hình "Multiple V" lỏng Mô hình nảy áp dụng cho các hệ thông quá lớn, quả phức tạp.[1]

High-level

Architectural ca and testing TH

Hinh 2 3 : Mé hinh da chit V léng

Viée kiém thir trong m6 hinh da chit V: Cac nha quan ly can cé một bức

tranh tổng quát vẻ tất cả các hoạt động kiém thi, cac tinh huéng kiểm thử vả môi liên

quan của chúng Các hoạt động vả các tỉnh huông được phân như sau:[1]

®_ Các kỹ thuật kiểm thử

® Loại kiểm thử

® Mức kiểm thử Các mô hình đa chữ V cơ bản trong quá trình kiêm thử toản hệ thông

HW/SW Integration test /p Fairbisctin

SWacosptancetest ¿9 4È Random testing

State transition testing

Control flow testing

Hình 2 5: Xác định các vấn đề liên quan trong vòng đời phát triển của nguyên mẫu

System acceptance test

Random testing

Rare event testing

Hình 2 6: Xác định các vân đề liên quan trong vòng đời phát triển của sản phẩm cuối

củng

Mồ hình đa chữ V không chỉ hữu ích khi lên kể hoạch kiểm thử và thực hiện

trên một sản phẩm hoản toản mới, nỏ còn có thẻ sử dụng trong trường hợp phát hành

một sản phâm đã có sẵn Mô hình đa chữ V và kế hoạch kiểm thử tông thẻ (master test plan) co quan hệ tới quá trinh phát triển của một sản phẩm hoàn thiện trong việc mô tả

rõ ràng các hoạt động kiểm thử cân thiết Đầu tiên cần phải chỉ ra công đoạn mả ở đỏ nhả phát triển cỏ thể bắt đâu áp dụng mô hình đa chữ V Sau đó kế hoạch kiểm thử

tổng thể sẽ phát huy vai trỏ trong việc chọn lựa mô hình tích hợp và lên kế hoạch các hoạt dông kiểm thử cản thiết cho đợt phát hành mới

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

2.2.3.1 Các thành phần của kế hoạch kiểm thử tỗng thể

Kiểm thử một hệ thống lớn là một nhiệm vụ phức tạp yêu cầu phải thực hiện nhiều hoạt động có tỉnh chuyên biệt tại những thời điểm, vị trí khác nhau trong dự án

Do do đội kiểm thử có thể được chia ra hoạt déng với những công việc đặc thủ khác

nhau, làm việc với những mô-đtm khác nhan và vị trí khác rửøu trong đự án Trong

trường hợp đó, xnột kế hoạch kiếm thử tổng thế sẽ cung cấp mốt cơ chế cho phép điện phổi toàn bộ quá trình kiểm thủ

‘Dau tiên cần phân biệt sự khác nhau giữa kiểu kiểm thử và cấp độ kiểm thử Đây là sự khác biệt giữa biểu hiệnđang được kiểm thử và cơ cầu thực hiện hoạt động kiểm thử Kế hoạch kiểm thử tổng thể sẽ giải quyết cả hai vấn dễ này

® Kiểu kiểm thử (Test type): là một tập hợp những hoạt dộng kiểm thử với mục dích đánh giá hệ thông dựa trên một bộ dặc tả chất lượng liên quan

Test type chỉ rõ cái gì s

p được test va không được 1esL[T]

hức và

ap độ kiểm thử (Test levels): là một lập các hoạt động được tổ

điêu hành như một thực thẻ duy nhất Test level chỉ rõ ai sắp sửa thực

hiện hoạt động kiểm thử và vào lúc nào Các test level khác nhau sẽ được liên kết tới các giai đoạn khác nhan trong quá trình phát triển của hệ thông [1]

Quy trình kiêm thứ sẽ dược cơ cầu thông qua vige dap ứng nguyên lý kiếm thứ ting tién (incremental testing) rong giai dean dau phat trién san phẩm, các thành

phan ống được kiểm thử độc lập để kiểm tra hoạt động của chính thành phần

đó Khi nhiều thành phần được chứng thực về chất lượng, chúng sẽ được lích hợp với

nhau để trở thành những thành phân lớn hơn trong hệ thông hoặc một hệ thống con

(subsystem) Dó là lúc tiếp tục quá trình kiếm thử nếu hệ thông con đó thực hiện một

yêu cau & mite cao (hight-level)

Có sự phân biệt giữa kiểm thứ mức thấp (low-level test) vả kiểm thứ mức cao (hipht-level test).Low- level test là thực hiện kiểm thử trên những thành phân dộc lập, được thực hiện vào giai doạn dầu khi phát triển sắn phầm tại môi trường giỏng như

môi trường phát triển, là kiểu kiểm thể thiên về kiểm thử hộp trắng (white-box tcst) THght level-test là kiểm thử trên một hệ thông Lích bợp, được thực hiện vào giai đoạn oust fa qua Irình phát triển sar phẩm, tại mỗi trưởng thực của người sử dụng (sẻ thể

đùng giả lập) và thường thiên về kiểm thử hộp đen (lack-box test)

Người quản trị hoạt động kiếm thứ phải bắt đầu hoạt động cảng sớm cảng tốt và

phải có một cái nhìn tổng, quát về toàn bộ quy trình kiểm thứ Việc dò được thực hiện bằng cách tạo ra một kế hoạch kiểm thử tổng thể Ba vắnđề chính cần quan tam trong, bản kế hoạch kiểm thứ tổng thể là

© Tara chon chiên lược kiếm thử

bì

®_ Phân bổ nguồn nhân lực

® Giao tiếp giữa các bên có liên quan

Những vắnđẻ nàyđược giải quyếtrong phần tiếp theocác hoạt dônglập kế thoạchkiếm thữ tổng thếtương tự

2.2.3.2 Hoạt động lận kề hoạch kiếm thử tống thé

lột cần phải vạch ra phương hướng thực hiện

Một kế hoạch kiểm thử tổng tÍ

nhitng hoat déng[1] sau:

© Céng thite phan céng

® Xem xét va nghiên cứu tổng thé

© Xe dinh chiến lược kiểm thứ tổng thé

®_ Xác định cơ sở hạ tầng

®_ Xáo định các tổ chức

®- Xúc định một lịch trình tổng quát

Công thức phân công:

Ð Người duoc ty quyén (Commissioner): Day có thế là người được ủy

quyền để tạo nên bản kế hoạch tống thẻ hoặc là người quyết định hoạt

động kiểm thử nào cần được thực thi Người được ủy quyên có thể được

coi là có vai trỏ như một khách hàng ở trong đội kiểm thử Thường thì người được ủy quyên là quần trị đưán (general project manager) của hệ thông đang được phát triển

Nhà thầu (ContraeLr) :Lá người chịu trách nhiệm tạo ra bản kế

hoạch

v

kiểm thử tẳng thể, thường gọi là người quản ly kiém dui(test manager)

> Các mức thử (Test level) : Cânquyết định những cấp độ kiếm thử nào sẽ được thực hiện Các cấp độ kiếm thử có thẻ là kiếm thử bộ phận (unit

†est) hay kiểm thử tích hợp (integration tests)

> Phạm vi công việc (Scope): Phạmvi công việc được định nghĩa bởi sự hạn

chế và giới hạn của toàn bộ quả trình kiểm thứ Như các đặc trưng của hệ thông cảnđược kiểm thứ, giao điện với các hệ thông lần cận Một vắnđề

> Cée gifidinh (Assumptions) : Đưa ra các điều kiện nảy sinh trong quá

trình kiểm thử riêng rẽ (tại bên thứ ba), giúp cho qua trình kiểm thổ có

thể diễn ra sudn sé.

Xem xét và nghiên cứu tống thể:1ioạt động nảy hướng tới việc thu thập sự

hệ thếng, như là các kết quả của việc phân tích thông tín

hoặc định hướng nghiên cứu

v Tài liêu dự án, như là những kế hoạch cho hệ thống đang được phát triển

¥ Luge dé té clue va phân công trách nhiệm, kẻ hoạch chất lượng va dự toán khối lượng công việc

L triển hệ thống, bao gồm các tiêu chuẩn

¥ M6 1a về phương thức ÿÌ

vˆˆ Giao kèo với người cung cấp,

> Phông vấn: Rất thiểu người được đưa vào trong quá trình phát Iriển hệ thông cần được phỏng vấn Những vấn đề cẳn được cân nhắc:

Y Dai dién tiép thi san phẩm cung cấp cái nhìn sâu sắc về định hướng cửa công ty và các điều kiện phân phối sản phẩm

lược kiểm thử tổng thể: Mục tiêu của hoạt dộng này là nhằm

ac loại kiểm thi

> Xem xét về quân trị chất lượng hiện thời: Hoạt động kiếm thử là một

trình phát triển sản phẩm Tiệ thẳng chất lượng có thể được cung cấp cho các cuộc thanh kiểm tra, phát triển một kiến trúc nhất định, giúp sản phẩm đỏ đạt được

một số tiểu chuẩn và theo đối sự thay đổi của quả trình dim bao chất

lượng Khi quyết dịnh những hoạt động kiểm thử sẽ được thực tủ thì

những hoạt động liên quan dén việc quản trị chất lượng cũng, phải được cân nhắc

> Quy

+ˆ Quyết định đặc thù chất lượng: Trên cơ sở các rủi ro, một tập các đặc

thù chất lượng cản thiết cho hệ thông được đề xuất Cáo đặc thủ này là

những mình chứng cơ bản cho nhiễu hoạt động kiểm thử khác nhau mà nhà phát triển cần cân nhắc trang các báo cao duoc tao ra trong suốt phân của quá trình đâm bảo chất lượng nằm trong

ö những ý niệm khác nhauvề tâm quan trọng của một số đặc điểm

thống cụ thể Trong quá trình kiểm thử, một vấn đề thường gặp

phải là khi các bên liên quan gặp phải những vân đề khó quyết định là

đúng hay sai Việc này đòi hẻi các bên liên quan phải có kinh nghiệm

27

và hiểu biết về vấn để đỏ Quyết định không phải lúc nào cũng hoản

hảo nhưng sau khi đã cân nhắc cản phải lựa chọn ra giải pháp tốt nhất

v Phân bê đặc diễm chất lượng cho những cấp dỗ kiểm thử: Để tối ưu

hoa việc phâu bố cá

> Xác những môi trường kiểm thử cân thiết

> Xáo định những công cụ kiểm thử cần thiết

®_ Quyết dịnh các kế hoạch về cơ sỡ hạ tâng,

Xác định các tổ chức:Hoạt dộng này sẽ chỉ ra vai trò, nhiệm vụ và kết quả tại

nỗi cấp độ kiểm thử trong toàn bộ quá trình kiểm thử Việc thiết lập một tổ chúc ưực

điện bao gằm ba hành động:

> Quyết dink những vai trò cầu đưết: Mục tiêu của hành động không phải nhằm đến những kiểm thử đơn lẻ mà là toàn bộ quá trình kiểm thử Đá là

về sự phối hợp của các lịch kiểm thủ khác nhau, sử đựng tối ưu nguồn tải

nguyên khan hiểm, thu thập và tạo báo cáo

® Thiết lập các khỏa dào tạo: Việc thực hiện kiểm thứ ở các cấp độ khác nhau sẽ không, giống như nguyên lý kiểm thứ cơ bản với những kỹ thuật

âu báo cao: Chỉ định các nhiệm vụ

thi va kết quả cân báo cáo là một phân quan trọng trong bản xác định các

vai trò Nó phục vụ cho các nhiệm vụ liên quan tới việc chuyến giữa nhiều cấp độ kiểm thử và cáo quyết định bị hủy bỏ

Quyết dịnh lập lịch tổng thể:Mục tiêu của hoạt động, này nhằm thiết kế một

lịch cụ thể cho toàn bộ quả trình kiểm thứ Nó bao gồm mọi cấp độ kiểm thứ (rong, pham vi của bản kế hoạch tổng thể) vả các hoạt động, đặc trưng như phát triển cơ sở hạ

tầng và hoạt động đào tạo Trong hậu áo cấp độ kiểm thủ rưáy bắt đầu và kết tháo sảu phẩm sẽ được bản giao đều được chỉ rõ.Trong giai đoạn lập kế hoạch và điều

khiến các cấp độ kiếm thủ khác nhau, những kế hoạch này sẽ được chỉ tiết hóa

>> Những mô tả các hoạt động ở mức đệ bight-level cần thực hiện

Thời gian cần thiết dành cho việc chỉ dạo

th động khác (có thể lá nằm ngo:

kiểm thử hoặc giữa các cập độ kiểm thử khác nhau)

2.2.4 Kiểm thử hởi lập trình viên

Trong quá trình phát triển phân mềm th các lý do dékiém thử bởi lập trinh viên

là hệt sức quan trọng vĩ

ác môi quan hệ với œ

©_ Các lỗi được phát hiện sớm sẽ dễ dàng được sửa chữa với chỉ phí thấp,

không lổn nhiều thời gian

« Dễ dáng lan tìm ra các lỗi

œ Các lãi được phát hiện khi đã phân phôi sản phẩm sẽ rật khó sửa vi công, tảo thu hồi gặp khó khăn

© Công việc kiểm thử được thực hiện tốt trong giai đoạn phát triển sẵn

phẩm có tác dụng tôi đổi với tổng thời gian hoãn thiện đự ản

œ Kiểm thử các trường hợp bắt ngoại lê chỉ có thể được thục hiện trong giai

đoạn kiểm thiđơn vị (trnf test),

Hữu nữa chất lượng sân phẩm không thê cất tiễn tiêm nêu chỉ thực hiện kiểm

thử vào giai đoạn cuối của quá trình lam ra sản phẩm Kiểm thử chất lượng sắn phẩm ở

mọi giai đoạn phát triển là một điều cần thiết

2.2.5 Kiểm thứ bởi nhám người kiểm tra dậc lập

Các đội kiểm thử độc lập chiếm phản lớn các múc kiểm thủ ở mức cao, các mức kiểm thử xảy ra ở giai đoạn cuối để đảm bảo rằng hệ thống phát triển đầy đủ Các

giai đoạn tiến hành gồm:

« Lập kế hoạch và kiểm soát giai đoạn kiểm thử

©) Giai dean chuẩn bị: xác dịnh xem cơ số thử nghiệm có đủ chất lượng dâm

bảo thực hiện thành công các nường hợp (hữ nghiệm

œ_ Giai doạn dặc tả kỹ thuật: xảy dựng méttapedckiém thubang cachsit dung, cack} thuatthiét ké tht nghiệmdược phân bê

« Giai đoạn thi công: thực thị lệnh kiểm tra theo quy định để thụ được kết qua vé chất lượng cúa đối tượng kiểm tra

Phat triển một chiến lược đánh giá rủi ro dụa trên kiếm thử lä một phương tiện

giao tiếp với các bên liên quan cái gì là quan trọng, nhất về hệ thống nảy vađiều này có

29

nghĩa là cho những thử nghiệm của hệ thống này "Chí cần kiểm thứ tất cá mọi thú" về mắt lý thuyết là không thẻ, hoặc ít nhất là về kinh tế không khả thí nó sẽ là một sự lãng, phí nguồn lực (thời gian, tiễn bạc, con người và cơ sở hạ tằng).Chiễn lược dành giá rủi

rơ là một yêu tố quan trọng trong mội phương pháp kiếm tra cấu trúc và đóng góp lớn

vào một quá trình thứ nghiệm quân lý

Thát triển một chiến lược thữ nghiệm đôi hỏi sự hiển biết sân sắc vê những rủi

ro Liệu quả gì sẽ xảy ra khi các mô-đun xác thực không làm việc chính xác? Diễu gì

sẽ bị thiệt hại khi hệ thống này cho thấy hiệu quả chưa đây đủ?Vớiđặc thù của chiến lược này là phải nhìn thấu đảo những hậu qua ma san phẩm kém chất lượng gây ra Dễ

làm được diễu dỏ các khia cạnh khác nhau của rủi ro được phân tích trong đỏ có nguồn

gốc tử phương trình nỗi tiếng (Reynolds, 1996):|1]

Tủi ro — cơ hội lỗi? hậu quả lỗi gây ra (Eisk-chanceoffailire x damage)

Trong đó cơ hội lỗi liên quan đến tần suất sử dung và cơ hội của một lỗi có mặt trong hệ thống Với một thành phần được sử đụng Tân một ngày bởi nhiều người,

cơ hội lỗi xuất hiệnlà cao Khi đánh giá các cơ hội lỗi xảy ra, đanh sách sau đây cho

thấy những vị trí mà lỗi có xu hướng xây ra:

œ Các thành phân phức tap

«_ Các thành phan mdi hoàn toàn œ_ Các thành phẩn thường xuyên thay đổi

* (4c thanh phan lan dau dung cac công cụ và kỹ thuật nhát định

«_ Các thành phẩn mà chuyển qua nhiều người phát triển

œ Các thành phân được xây dụng đười áp lực rất lớn vẻ thời gian

* Cac thanh phản thường được tối m thường xuyên hơn bình thường

«_ Các thành phan ma nhiều lỗi được tìm thấy trong, các phiên bản trước

œ_ Các thành phân với nhiều giao tiếp với các thành phân khác

Cơ hội lỗi cũng lớn hơn đối với:

«_ Những lập trình viên còn thiểu kinh nghiệm

« Không dủ sự tham gia của dại diện người sử dụng

« Không đủ bảo đảm chất lượng trong quả trình phát triển

œ Không đủ chất lượng của kiếm thử mức độ thấp

Không thể đánh giả rủi ro khách quan đây đủ vả chữnh xác.|3ánh giá rủi ro không chỉ thực hiện bởi quân lý kiểm thử mà còn cả bởi những người liên quan đến dự

án Điều này không chỉ làm tăng chất lượng của chiến lược thử nghiệm, mả mọi người tham gia có thận thức tốt hơn về € túi ro và các thử nghiệm Điều này Ìà cục kỳ quan trọng trong việc "thiệt lập những kỷ vọng đối với thử nghiêm" Nó phải được hiểu rằng thử nghiệm chỉ là một trong những cách thức quân lý rủi ro Hình 2.7 chỉ ra

các lựa chọnđề quản lý rủi ro, [1]

Risk management options

x oN

Loss prevention Loss reduction Risk retention Risk transfer

Y Avoid perils Systems engineering Oostandschedule Insureanoe

Risk assessment progam Reserves Warranties

Design reviews

‘Test, analyze and fix

Cet and cuter»

Hình 2 7: Xủ lý rỗi ro

2.3.1.2 Chiến lược kiếm thủ trong lập kế hoạch kiểm thứ tẵng thể

Mục tiêu của chiến lược kiểm thứ trong, lập kẻ hoạch kiểm tlrử tổng thé la dé nhận thấy được những rủi ro trong các tỗ chức lớn cẩn kiểm thử trên nhiều thử

nghiệm, được thục hiện ở đầu, khi nào trong quá lình phát triển

Những bước phải làm:

© Tam chon cdc dặc tính chất lượng: Một tập các dặc tính chất lượng dược tựa chọn và được lái liệu hóa kết quả

œ- Xác dịnh tàm quan trọng tương dói của các dặc tỉnh có chất lượng: Chính

là việc thảo luận để so sánh sự quan trọng của các thành phan Mé ta bang

ma trên rất trực quan và dễ hiểu Phân trăm tháp nghĩa là nhận ít sự quan

tâm khi kiểm thử

œ Gián các đặc tính chất lượng cho các mức độ kiểm thứ: Trong quá trình phát triển phần mềm cỏ nhiều pha Các hoạt động nay cản được đánh số

ưu tiên

2.3.1.3 Chiến lược kiểm thử cho một mức thử

Mục tiêu của chiến lược kiểm thửcọ một mức thử nghiệm là tạo ra sư lựa chọn

Sau đây là các bước để thục hiện:

©) Lata chon cae dic tinh chat ong œ_ Xác định tâm quan trọng tương đối của các đặc tỉnh chất lượng

œ Xác định tâm quan trọng tương đối của cáo hệ thông con: Sau khi có danh sách các thánh phân của hệ thống, cân phải đãnh trọng số cho các thành

phân Đặt các thành phân trong mỗi tương quan Kết quả sẽ được lâm thành tải liệu, mô tả bằng ma trận Việc đảnh trọng số không dựa vào

độ quan trọng Kết quả của bước này cung cấp một cát nhìn tổng quan về cải mà tổ chức thây lả quan trọng và nên kiểm thử

œ Thiết lập các kỹ thuật kiểm thử dược sử đụng: Đội kiểm thử sẽ dược kì vọng là tổ chức và thực thi một quá trình kiểm thổ mã báo trùm những, phân quan trợng của sản phẩm đã được lỗ chức định nghĩa rà Công việc

của người quan ly kiểm thử là thiết lập một tập các kỹ thuật ma có thé thực hiện để đâm bảo mức đệ bao phủ cao Né phụ thuộc vào nhiều yếu

tổ như các đặc tính chất lượng được kiếm thử, loại ứng đụng, cơ sở kiếm

thử được yêu cầu, tải nguyên được yêu cầu, kiến thửc va kỹ năng được yêu câu

2.3.1.4 Chiến lược thay đỗi rong quả trình thữ nghiệm

Người quân lý kiểm thủkhông, dược phép cho rằng các chiến lược thở nghiệm

sẽ dược phát triển một lần và sau do có dịnh trong suốt quá trình của du án.Quá trình

kiếm thửphải liên lục thay đổi sao cho phù hợp với những thay dỏi của thực tế Sử

iém thửcó thể thảo luận về

cũng nên được thử nghiệm khác hơn trước đó, sau đó những mong đợi của các thứ

nghiệm can dat dược cũng phải thay đổi

2.3.1.5 Chiến lược kiểm tra bảo trì

'Trong thời gian bảo tricác lỗi cỏ nguy cơ xuất hiện khi hệ thống có những thay đối Những thay đối này của hệ thông tất nhiềnphái được kiểm lra Nhưng cũng có thể

là hệ thôốngđã hoại động chỉnh xác Irong bản phát hành trước đỏ, chứkhông làm việc

trong bản phát hành mới bởi vì những thay đổi của hệ thông Hiện tượng này được gọi

ja hồi quy Trong các phiên bản bảo trì phân lán thời gian kiểm thử tập trưng vào kiểm

tra cáo chức năng trư óođó hoạt động chính xác không, Điều này được gọi lả kiếm thử

hồi quy

Kiểm thứ hỗi quy là yếu tổ tiểu chuẩn trong một dự án kiểm tra bảo trì Thông thường một bộ trường, hợp kiểm thử được duy tri cho mục đích này Tuỳ thuộc vào những rỗi ro và ngân sách dành cho việc kiểm thử rà lựa chọn thực luện kiểm thé héi quy diydi hoặc kiểm thữ các tỉnh huồng thích hợp nhất với các [hay dỗi của dưán Các công cụ kiếm thử có thể được sử dụng rất hiệu quả để hỗ trợ việc thực hiện kiếm thử

thứ Việc phát hiện cảng sớm những lỗi trong tải liệu sẽ cảng làm đơn giản việc sửa

chữa và chỉ phí thấp ngược lại nếu các lỗi trong tài liệu không được phát hiện và súa chữa sẽ dẫn dén tiêu tôn chỉ phí nhiều và ảnh hưởng dến thời hạn dua sản phẩm ra thị

trưởng

2.3.2.2 Thũ tực

Xem xét khả năng kiểm thữ nó cáo bước sau |1 |

œ_ Lựa chọn tái liệu liên quan: Trong kế hoạch kiểm thử (test plan) cdn phat xác định các tải liệu nảo sẽ được sử dụng để dẫn ra các trường hợp kiểm

thử Khâu xem xét tỉnh cỏ thể kiểm thử sẽ xác dịnh một cách bình thức cơ

sở kiểm thử và những tài liêu thực

œ Soạn một danh sách hang muc kiểm tra: Danh sách kiếm tra phụ thuộc vào các kỹ thuật thiết kế kiểm thử dược sử đụng,

œ Đánh giá tài liệu: Với đanh sách cáo mục cần kiếm tra, đội kiếm thử sẽ

¡ được phát hiện Phat hiện cảng sớm thí cảng tạo ra cơ hội cải thiện chất lượng cúa việc

33

Cơ sở kiểm thử không lý tưởng: Trong thực tế có khi những yêu cầu chua có sẵn ngay nó có thể nãy sinh trong quá trình phát triển sản phẩm Trong những tỉnh huéng nay không áp dụng xem xét tính khả kiểm thử ma pha chuẩn bị dơn thuận là khoảng, thời gián để gorn lại những thông tin đúng

2.3.3 Thanh tra (Inspections)

2.3.3.1 Giới thiệu

Thanh tra là một kỹ thuật dánh giá trong dó một người hay một nhóm khác với

tác giả xem xéi các yêu

œ Thiết lập những cải thiện chất lượng của sản phẩm và quy trình

Chuẩn bị là giai đoạn quan trọng nhất của thanh tra Trong giai đoạn này, các nhả giảm dịnh đảnh giả các thông số kỹ thuật Một hoặc nhiều vai trỏ được giao cho mỗi giám dịnh và đo đó có thể danh giá dược những chỉ tiết kỹ thuật Mỗi giảm định sẽ

phát hiện các lỗi duy nhâtmả không thể được phát hiện bởi các nhà dánh giá khác vi

vai trỏ khác nhau của họ Thanh tra là một kỹ thuật thích hợp để nâng cao chất lượng, sản phẩm

Uu điểm

œ- Thiếu sói được phái hiện sớm có thể dược điều chỉnh với chỉ phí thấp

«Tỷ lệ phát hiện lỗi là khá cao vi có một nhóm chuyên tập trung thực hiện

việc đánh giá

œ_ Việc đánh giá một sản phẩm bởi một đội sẽ thúc đây sự trao đổi thông tin

giữa các thành viên của nó

œ Thanh tra không chỉ giới hạn với các tài liệu thiết kẻ mà có thể được sử đụng cho tất cã các tài liệu được bàn giao của quá trinh phát triển cũng,

xihư quá trinh kiếm thử

* Vide kiém ma kích thích cao nhận thức và động lực phát triển các sản

phẩm chải lượng 2.3.3.2 Thủ tục

Thanh tra sẽ được thực hiện theo các hước:[1]

Tiếp nhận thanh tra kiểm tra: Người phụ trách tiếp nhận kiểm tra san phẩm, dựa trên các tiêu chuẩn tiếp nhận Các tiểu chuẩn tiếp nhận đưa

cho lác giả của sản phẩm nhưng hưởng dẫn rõ răng về việc khi nào sân

tổ chức ra làm việc nảy và znỗi thành viên cỏ vai trò tương xửng với sự quan tâm và kinh nghiệm của người tham gia sau dó thủng nhất một cuộc

œ_ Kiểm tra tiêu chuẩn chấp nhận

2.3.4 Phân tích an toàn (Safety Analysis)

3.3.4.1 Giới thiệu

Có nhiều hệ thông nhúng được sử dụng trong các tình luồng, quan trọng với các yêu cầu cao về tính an toàn Vi vậy trong, quá trinh thiết kế và phát triển các hệ thông, nay phải xây dựng một số biệt pháp đâm bão an toàn cho hệ thống, Cách tốt nhái để

xử lý các yêu cầu về an toàn của một hệ thống là bắt đầu theo đối nó trong giai đoạn

Hình 2 §: Mối quan hệ giữa nguyên nhân, chức năng chế độ thất bại và kết quả

Phần đóng hộp có thé được phân tích bởi FMIA và toàn bộ được phân tích bởi

TTA

3.3.4.2 Các kỹ thuật phân tích an toàn

FMEA (Failure Mode and Effect Analysis) là một phương pháp phân tích xác

định tác động của một thất bại lên hệ thếng Kỹ thuật nảy được sứ dụng sớm trong quá trình thiết kế để tăng cườngan toàn thông qua thiết kế

FMEA bao gém ba bước

ø Xác định chế độ thất bại tiểm ân

@ivh anh hưởng của chế độ thất bại tiểm ấn lên chức nắng của hệ

thống

* Nang cao an toan của hệ thẳng,

« Nang cao khả nắng theo déi nhiing rai ro trong suédt chu trinh phat tién

œ Sớm xáo định các mối nguy hiểm tiểm ấn

«- Tâm giâm bótrũi ro về tải liệu và các tác động

œ_ Giảm thiểu các thay déi và chủ phi liên quan

œ Là sản phẩm đâu vào đáng tin cậy cao cho chiến lược kiếm thử

ETA (Fault TreeAnalysis) được sử dụng để xác định nguyên nhân của thất bại

Day lá một kỹ thuật để phản tích thiết kế với sự an toàn và độ tín cậy cao Sự thất bại của hệ thống được lây ở trên củng của cây lỗi vá bước kế tiếp là phải xem xét những, trang thái không rong muốn (các bê thống) chịu trách nhiệm về những trục trặc của hệ thông Một e: được sử dụng đễ tìm nguyêu nhân thái bai Những thất bại này ảnh hưởng đến nhiều phan của hệ thông.1 |

FMEA va FTA là các kỹ thuật thường được trình bảy và sử đưng để phân tích

an toàn Tuy nhiên chúng cũng rất hữu ích trong việc xác định chiến lược thử nghiệm

FTA va FMBA sau 46 có thế được áp dung có hiệu quả để xác định các điểm yêu và

phân rủi zo của hệ thông J1]

2.3.5 Danh sách kiểm tra (Checklists)

Danh sách kiểm tra được sử đụng như là một kỹ thuật để cưng cấp trạng thái thông tin theo cách chỉnh thức về tất cá các khia cạnh của quá trình kiểm thử,

Danh sách kiểm tra bao gồm:[1]

«_ Danh sách kiểm tra cho cáo đặc tính chất lượng,

ø- Tổng hợp danh sách kiếm tra cho kiểm thử cấp cao

hệ thông thuc hién ý yêu cầu liên quan đến các đặc tính chất lượng không Các

‘ban danh sách kiểm tra khác được dùng đề hỗ trợ việc quản lý kiểm thử

2.3.6 Các kỹ thuật thiết kế kiểm thử (Test Design Techniques)

Kiém thử câu trúc là trường hợp thử nghiệm cân thiết đề thực hiện cáo mục tiêu được yêu cầu và những trường hợp kiểm thửnäyđược chudn bị trước khi thực hiện kiểm thứ Một kỹ thuật thiết kế kiểm thitla mét phương pháp đã được chuẩn hoá phát sinh các trường hợp kiểm thir bat nguồn từ thông tin tham khảo

Mô lễ các bước:

«Xác định các tình huống kiểm thứ

« Chỉ định các trường hợp kiểm thử logie