Các kỹ thuật kiểm thử phần mềm nhúng và ứng dụ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: Lập kế hoạch Thiết kế kiểm thử Phát triển kịch bản kiểm thử Thực hiện kiểm thử Bản kế hoạc

ĐẠI HỌC QUỐC GIA HÀ NỘI

ĐẠI HỌC QUỐC GIA HÀ NỘI

LUẬN VĂN THẠC SĨ NGÀNH CÔNG NGHỆ THÔNG TIN

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

Hà Nội – 2014

LỜI CẢM ƠN

Lời đầ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 Bình, 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 thân, bạn bè của tôi đã luôn cổ vũ, động viên, tạo điều kiện giúp đỡ tôitrong 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

Học viên: Nguyễn Thùy Dương

LỜI CAM ĐOAN

Tôi xin cam đoan toàn bộ nội dung 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 đề gì 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

MỤC LỤC

LỜI CẢM ƠN 1

LỜI CAM ĐOAN 2

MỤC LỤC 3

DANH SÁCH CÁC BẢNG 5

DANH SÁCH CÁC HÌNH 6

MỞ ĐẦU 7

CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 8

1.1 Khái niệm kiểm thử phần mềm (Software Testing) 8

1.2 Mục đích của kiểm thử phần mềm 8

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

1.3.1 Tình huống kiểm thử (Test Case) 8

1.3.2 Kịch bản kiểm thử (Test Script) 9

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

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

1.3.3.2 Thiết kế kiểm thử 10

1.3.3.3 Phát triển kịch bản kiểm thử 11

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

1.3.3.5 Đánh giá quá trình kiểm thử 12

1.4 Các mức kiểm thử phần mềm 12

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

1.4.2 Kiểm thử tích hợp (Integration Test) 13

1.4.3 Kiểm thử hệ thống (System Test) 14

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

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

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

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

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

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

CHƯƠNG 2: CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM NHÚNG 18

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

2.1.1 Hệ thống nhúng 18

2.1.2 Phần mềm nhúng 19

2.2 Vòng đời phát triển phần mềm nhúng 20

2.2.1 Giới thiệu 20

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

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

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

2.2.3.2 Hoạt động lập kế hoạch kiểm thử tổng thể 25

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

2.2.5 Kiểm thử bởi nhóm người kiểm tra độc lập 28

2.3 Các kỹ thuật kiểm thử phần mềm nhúng 28

2.3.1 Chiến lược đánh giá rủi ro (Risk-base test strategy) 28

2.3.1.1 Giới thiệu 28

2.3.1.2 Chiến lược kiểm thử trong lập kế hoạch kiểm thử tổng thể 30

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

2.3.1.4 Chiến lược thay đổi trong quá trình thử nghiệm 31

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

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

2.3.2.1 Giới thiệu 32

2.3.2.2 Thủ tục 32

2.3.3 Thanh tra (Inspections) 33

2.3.3.1 Giới thiệu 33

2.3.3.2 Thủ tục 33

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

2.3.4.1 Giới thiệu 34

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

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

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

2.3.6.1 Kiểm thử sự chuyển tiếp trạng thái (State Transition Testing – STT) 36 2.3.6.2 Kiểm thử điều khiển luồng (Control Flow Test) 37

2.3.6.3 Kiểm thử so sánh cơ bản (Elementary Comparison Test – ECT)38 2.3.6.4 Phương pháp phân loại cây (Classification-Tree Method – kCTM)38 2.4 So sánh các kỹ thuật kiểm thử phần mềm nhúng với kiểm thửphần mềm nói chung 39

CHƯƠNG 3: THỰC NGHIỆM 41

3.1 Một số công cụ được dùng trong kiểm thử phần mềm nhúng 41

3.1.1 Giới thiệu về trình biên dịch CodeWarrior 41

3.1.2 Giới thiệu về công cụ JTAG (Joint Test Action Group) 42

3.1.3 Giới thiệu về chuẩn SWD (Serial Wire Debug) 43

3.2Tổng quan về mạch MKL46Z256 và phần mềm điều khiển chuẩn (Standard Software Driver - SSD) 44

3.2.1 Tổng quan về mạch MKL46Z256 44

3.2.2 Phần mềm điều khiển chuẩn cho mô-đun Flash của mạch MKL46Z256 (Standar Software Driver – SSD) 45

3.2.3 Thiết kế tình huống kiểm thử cho phần mềm SSD 46

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

3.4 Demo chương trình 51

3.5 Kết quả thực hiện chương trình kiểm thử 53

KẾT LUẬN 54

PHỤ LỤC 55

Phụ lục A: Tài liệu thiết kế chi tiết của phần mềm SSD 55

Phụ lục B: Danh sách test case của từng hàm trong phần mềm SSD 68

TÀI LIỆU THAM KHẢO 72

DANH SÁCH CÁC BẢNG

Bảng 1: Các giá trị trả về của hàm FlashCommandSequence() 55

Bảng 2: Các giá trị trả về của hàm FlashEraseAllBlock() 57

Bảng 3: Các giá trị trả về của hàm FlashEraseSector() 58

Bảng 4: Các giá trị trả về của hàm FlashVerifyAllBlock() 60

Bảng 5: Các giá trị trả về của hàm FlashVerifySection() 61

Bảng 6: Các giá trị trả về của hàm FlashProgramCheck() 63

Bảng 7: Các giá trị trả về của hàm FlashProgramLongword() 65

Bảng 8: Các giá trị trả về của hàm PFlashGetProtection() 67

Bảng 9: Các giá trị trả về của hàm PFlashSetProtection() 68

DANH SÁCH CÁC HÌNH

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

Hình 1 2: Thời điểm phù hợp để 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

Hình 1 5: Kiểm thử hộp trắng 17

Hình 1 6: Kiểm thử hộp đen 17

Hình 2 1: Ví dụ về ứng dụng của hệ thống nhúng 19

Hình 2 2: Vòng phát triển theo mô hình đa chữ V 21

Hình 2 3 : Mô hình đa chữ V lồng 22

Hình 2 4 : Xác định các vấn đề liên quan trong vòng đời phát triển của mô hình 22

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 23

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 23

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

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

Hình 2 9: Biểu đồ trạng thái của hệ thống Telephone cho ca “gọi điện thoại” 37

Hình 3 1: Giao diện CodeWarrior 41

Hình 3 2: Giao diện Debugger cho CodeWarrior 42

Hình 3 3: Sơ đồ kiến trúc JTAG 43

Hình 3 4: Bản đồ bộ nhớ Flash 44

Hình 3 5: Sơ đồ khối Flash 45

Hình 3 6: Sơ đồ khối của hàm FlashEraseSector() 47

Hình 3 7: Thiết lập môi trường kiểm thử 51

Hình 3 8: Giao diện chứa chương trình kiểm thử của phần mềm SSD 51

Hình 3 9: Thiết lập kết nối để debug chương trình 52

Hình 3 10: Thực hiện debug chương trình kiểm thử cho hàm FlashProgramLongword 52

Hình 3 11: Kết quả thực hiện chương trình được trả về qua biến testResult 53

Hình A 1: Sơ đồ khối của hàm FlashCommandSequence() 56

Hình A 2: Sơ đồ khối của hàm FlashEraseAllBlock() 57

Hình A 3: Sơ đồ khối của hàm FlashEraseSector() 59

Hình A 4: Sơ đồ khối của hàm FlashVerifyAllBlock() 60

Hình A 5: Sơ đồ khối của hàm FlashVerifySection() 62

Hình A 6: Sơ đồ khối của hàm FlashProgramCheck() 64

Hình A 7: Sơ đồ khối của hàm FlashProgramLongword() 66

Hình A 8: Sơ đồ khối của hàm PFlashGetProtection() 67

Hình A 9: Sơ đồ khối của hàm PFlashSetProtection() 68

MỞ ĐẦU

Ngày nay hệ thống nhúng đang dần trở thành một ngành phát triển mạnh mẽ trong lĩnh vực công nghệ thông tin với rất nhiều ứng dụng trong công nghiệp và đờ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 móc tự động trong công nghiệp, đến những phương tiện di chuyển thông thường như 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 di động được sử dụng hằng ngày, đâu đâu cũng có sự hiện diện của hệ thống nhúng

Để phát triển các hệ thống nhúng thì vấn đề lập trình và kiểm thử các phần mềm 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ác phần mềm nhúng đóng vai trò quan trọng trong việc đảm bảo chất lượng, giảm thiểu rủi ro về các lỗi, nó mang tính sống còn của sản phẩm Đặc biệt với những

hệ thống nhúng đòi hỏi độ tin 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 so với kiểm thử phần mềm thông thường

Hệ thống nhúng ngàycàng được nhiều các nước trên thế giới quan tâm, 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 so với thế giới, đặc biệt 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 nhiề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à một 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úng, một lĩnh vực giàu 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 trình 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 Áp dụng kiểm thử một phần mềm nhúng, cụ thể là phần mềm điều khiển chuẩn cho mô-đun flash của mạch MKL46Z256 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 chương trình được viết bằng ngôn ngữ lập trình 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 2: Nghiên cứu các kỹ thuật kiểm thử phần mềm 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ô-đun flash của mạch MKL46Z256

CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM

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 đích của kiểm thử phần mềm, quy trình kiểm thử phần mềm cơ bản, các mức

kiểm thử phần mềm và một số chiến lược kiểm thử

1.1 Khái niệm kiểm thử phần mềm (Software Testing)

Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm lỗi [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 dự án phần mềm, là khâu mấu chốt để đảm bảo chất lượng phần mềm, là đánh giá cuối cùng

về các đặc tả, 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 tra này có thể thực hiện từng chặng, sau mỗi chức năng hoặc mô-đun được phát triển, hoặc thực hiện sau cùng, khi phần mềm đã được phát triển hoàn tất Trong quá trình phát triển phần mềm, những người phát triển phần mềm

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

1.2 Mục đí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à: Đưa 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 đến Nó có thể phát hiện và loại bỏ lỗi tại mọi giai đoạn của quá trình thiết kế phần mềm, từ ý tưởng đến đặ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 phần mềm cơ bản cần hiểu hai khái niệm sau: tình huống kiểm thử (Test Case) và kịch bản kiểm thử (Test Script)

1.3.1 Tình huống kiểm thử (Test Case)

Khi lập trình một phần mềm hay bất kỳ một cái gì thì việc dự đoán trước các 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ử để dự đ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 huống kiểm thử thường bao gồm ba phần cơ bản:

 Mô tả: Đặc tả các điều kiện cần có để tiến hành kiểm thử

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

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

 Kết 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 thử (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 dù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 khả thi Các kịch 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:

Lập kế hoạch

Thiết kế kiểm thử

Phát triển kịch bản kiểm thử

Thực hiện kiểm thử

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 chi 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 đen, 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ính (Master test plan)

Kế hoạch kiểm thử chấp nhận (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) Các thời điểm lập kế hoạch kiểm thử Chuyển giao cho khách hàng

Kế hoạch kiểm thử đơn vị (Unit test plan)

Dự án

bắt đầu

Hình 1 2: Thời điểm phù hợp để thiết lập các kế hoạch kiểm thử

Các bước trong việclập kế hoạch kiểm thử gồm:

 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, chi 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 dự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 chi 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, chi tiết các phần công việc, 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 chung của dự

án và bản kế hoạch chi 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ử phải có sự tham gia của tất cả những người liên quan để xem xét, đánh giá nhằm bảo đảm các kế hoạch là khả thi, cũng như để phát hiện và sửa chữa các sai sót trong 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 các tình huống kiểm thử (Test Case), mô

tả chi tiết từng tình huống, xác định các yêu 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ử thì 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 thử cần đảm bảo “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 kỳ phần mềm, vào bất cứ lúc nào có sự 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 bước thiết kế kiểm thử bao gồm:

 Xác định và mô tả tình huống kiểm thử: Xác định, mô tả các điều kiện cần thiết lập trước và trong lúc kiểm thử Mô tả đối tượng hoặc dữ liệu đầu vào, mô tả các kết quả đầu ra mong đợi sau khi kiểm thử

 Mô tả các bước chi tiết để kiểm thử: Mô tả chi tiết các bước của một tình huống kiểm thử để dễ dàng cho việc viết mã nguồn kiểm thử và thực hiện kiểm thử Thao tác này cũng chỉ định các loại dữ liệu nào cần có để thực

thi các tình huống kiểm thử chúng bao gồm các loại dữ 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 đã được kiểm thử Để xác định đượ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ử: Nhằm đảm bảo các tình huống kiểm thử và dữ liệu yêu cầu là đủ, phản ánh đúng các yêu cầu cần kiểm thử, độ bao phủ đạt yêu cầu cũng như để phát hiện và sửa chữa các sai sót

1.3.3.3 Phát triển kịch bản kiểm thử

Việc phát triển các kịch bản kiểm thử giúp tự động hóa việc thực thi các bước kiểm thử đã định nghĩa ở bước thiết kế kiểm thử Bước này thường không bắt buộc 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ử:

 Tạo kịch bản kiểm thử: Làm 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ử dụng càng nhiều càng tốt để tối ưu 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 bản kiểm thử hoạt động đúng yêu cầu, thể hiện đúng ý đồ của các bước kiểm thử

 Thành lập các bộ dữ liệu ngoài dành cho các kịch bản kiểm thử: Bộ dữ liệu này sẽ được các kịch bản kiểm thử sử dụng khi thực hiện kiểm thử tự động

 Xem xét và khảo sát độ bao phủ của việc kiểm thử: Bảo đảm các kịch bản kiểm thử được tạo 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 tiến hành tự động) và ghi nhận kết quả

Các bướ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 đảm tất cả các bộ phận liên quan đã được cài đặt sẵn sàng trước khi bắt đầ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 và 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ốt 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 gồm xem xét và đánh giá kết quả kiểm thử, liệtkê lỗi, chỉ định các yêu cầu 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ác đị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ân tích lỗi: Đưa ra số liệu phục vụ cho việc cải tiến các qui trình phát triển, giảm sai sót cho các chu kỳ phát triển và kiểm thử sau đó Ví dụ tính toán tỷ lệ phát sinh lỗi, xu hướng gây ra lỗi…

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

để xem xét các tình huống kiểm thử và chiến lược kiểm thử đã thiết kế có bao phủ hết những điểm cần kiểm thử hay không Kiểm thử có đáp ứng được các yêu cầu dự án hay không 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ử

 Báo cáo tổng hợp: Tổng hợp kết quả các bước ở trên và phải được gửi cho tất cả những người có liên quan

1.4 Các mức kiểm thử phần mềm

Thực tế kiểm thử phần mềm không đơn giản như nhiều người nghĩ, công việc này có nhiều mức độ khác nhau và có mối tương quan với các chặng phát triển trong dựán phần mềm Sau đây là các mức độ cơ bản của kiểm thử phần mềm:[5]

Kiểm thử đơn vị lập trình

(Unit test) Các bộ phận đơn lẻ

Kiểm thử tích hợp các đơn vị lập trình (Integration test)

Kiểm thử hệ thống sau khi tích hợp

(System test)

Kiểm thử để chấp nhận (Acceptance test)

Các nhóm bộ phận

Toàn bộ hệ thống

Toàn bộ hệ thống nhìn từ khách hàng

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ị (Unit) 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)

Vì kiểm thử mức đơn vị được chọn để kiểm thử thường có kích 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ễ dàng 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à chi 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 chu 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 hợp (Integration Test)

Kiểm thử tích 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 phần 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ử tích hợp để tìm lỗi trong quá trình ghép này là rất quan trọng bởi vì:

 Các mô-đun có thể do các nhóm phát triển khác nhau nên mặc dù đã có

sự thống nhất về giao tiếp giữa các mô đun thì vẫn có thể xảy ra lỗi ở đây nê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ô-đun bản chất là phức tạp nên dễ 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ị đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng là hệ thống hoàn chỉnh (system) với các lỗi phát hiện được sửa chữa

để chuẩn bị cho kiểm thử ở mức hệ thống (System Test)

Một chiến lược cần quan tâm trong kiểm thử tích hợplà nên tích hợp dần từng mô-đun 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 đảm bảo 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 Điều này đảm bảo sai sót giảm đi đáng kể và lúc này chỉ cần kiểm thử sự tương thích giữa mô-đun mới thêm vào với hệ thống các mô-đun đã được tích hợp trước đó

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 mãn yêu cầu đặt 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 tác, 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

Điểm khác nhau then chốt giữa kiểm thử tích hợp và kiểm thử hệ thống là kiểm thử hệ thống chú trọng các hành vi và lỗi trên toàn hệ thống còn kiểm thử tích hợp chú trọng sự giao tiếp giữa các đơn 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ử đơn vị và kiểm thử tích hợp để đảm bảo mọi đơn vị và sự tương tác giữa chúng hoạt độ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

Bản 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 Test): 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 hành (Performance Test): bảo đảm tối ưuviệc 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 Load Test): bảo đảm hệ thống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuấtcùnglúc )

 Kiểm thửcấu hình (Configuration Test)

 Kiểm thửkhả năng bảo mật (Security Test): bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống

 Kiểm thửkhả năng phục hồi (Recovery Test): bảo đảm hệ thống có khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ 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ệ thống, tùy 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

Hệ thống đã được tích hợp hoàn chỉnh

Hệ thống sẵn sàng để khách hàng kiểm thử chấp nhận

Kiểm tra đã hoàn thành

Kiểm thử khả năng bảo mật

Kiểm thử cấu hình

Kiểm thử khả năng vận hành

Kiểm thử khả năng phục hồi

Kiểm thử khả năng chịu tải

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 cầu của khách hàng và khách hàng 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 dành 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 và 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 trình 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

Trên thực tế nếu khách hàng không quan tâm và không tham gia vào quá trình phát triển phần mềm thì kết quả kiểm thử chấp nhận sẽ sai lệch lớn mặc dù phần mềm

đã trải qua tất cả các kiểm thử trước đó Sự 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í dụ đô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 dự á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 dịch vụ

và tài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng…Tất cả tài liệu đi kèm phải đượ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 đây không phải 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, B và C Khi có thay đổi mã nguồn của chức năng C nếu chỉ kiểm thử chức năng C thì chưa đủ cần phải kiểm thử lại tất cả các chức năng khác liên quan đến chức năng C trong ví dụ này là chức năng A và B Lý do là khi C thay đổi nó có thể sẽ làm A và B không còn làm việc đúng nữa

Mặc dù không là một mức kiểm thử ,thực tế cho thấy kiểm thử hồi quy là một 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 dù tưở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 đúng đắn là yêu cầu tối thiểu của phần mềm, là mục đích 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 đó, để chỉ ra cách 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 chi tiết bên trong của các modun phần mềm được kiểm thử, ví dụ luồng điều khiển,luồng dữ liệu, v.v … Do đó, hoặc là quan điểm hộp trắng, hoặc là quan điểm hộp đen có thể được thực hiện trong kiểm thử phần mềm

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 Kiểm thử hộp trắng được hỗ trợ bởi một số công cụ phần 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 dò 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 đó thì việc phát hiện và sửa lỗi mới

dễ dàng

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]

Hình 1 6: Kiểm thử hộp đen 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

Dạng đơn giản nhất của kiểm thử hộp đen là bắt đầu chạy 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 dạng dữ

liệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì đầ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

input

output

CHƯƠNG 2: CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM

NHÚNG

Chương này tôi tập trung nghiên cứu các kỹ thuật kiểm thử phần mềm nhúng, sau đó có sự so sánh đánh giá các kỹ thuật kiểm thử phần mềm nhúng với kiểm thử phần mềm nói chung

Hệ thống nhúng thường được thiết kế để thực hiện một chức năng chuyên biệt nào đó Khác với các máy tính đa chức năng, chẳng hạn như má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êu cầu cụ thể và bao gồm một số thiết bị máy móc và phần cứng chuyên dụng

mà 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ác nhà thiết

kế có thể tối ưu hóa nó nhằm giảm thiểu kích thước và chi phí sản xuất Các hệ thống nhúng thường được sản xuất hàng loạt với số lượng lớn Hệ thống nhúng rất đa dạng, 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át các máy năng lượng hạt nhân Xét

về độ phức tạp, hệ thống nhúng có thể rất đơn giản với một vi điều khiển hoặc rất phức tạp với nhiều đơn vị, các thiết bị ngoại vi và mạng lưới được nằm gọn trong một lớp

vỏ máy lớn

Có rất rất 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

 Ôtô, tàu điện

 Truyền thông

 Thiết bị y tế

 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

 Rôbốt

 …

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 nối 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 chóng Vì thế các phần mềm 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ự cẩn thận, tỉ mỉ hơn 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 đều đặn nhận được các tín hiệu watchdog định kì thì hệ thống sẽ bị khởi động lại

2.1.2 Phần mềm nhúng

Là phần 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 kích thước nhỏ, bộ nhớ hạn chế

Phần mềm nhúng thường được lập trình 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

dù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 được nạp lên gọi là target.Với mỗi target khác nhau sẽ có cấu trúc vi đ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 trình tương ứng

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

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

Việc kiểm thử phần mềm nhúng cũng có các đặcđiểm tương tự như kiểm thử phần mềm nói chung, ngoài ra do đặc trưng của hệ thống nhúng rất đa dạng về môi trường phát triển, đa dạng về kiến trúc phần cứng cũng như kiến trúc phần 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ẽ trình bày một số kỹ thuật kiểm thử phần mềm nhúng hay được dùng

2.2 Vòng đờ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 thi Hệ 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 dựng trên máy tính, mô phỏng các cách hành xử cần thiết của hệ thống Khi mô hình

đó được xem là chính xác, mã được tạo ra từ mô hình và nhúng vào một nguyên mẫu (prototype) Các phần cứng thử nghiệm của các nguyên mẫu được dần thay thế bằng phần cứng thực tế, cho đến khi hệ thống được xây dựng hoàn chỉnh và được đưa vào

sử dụng Lý do cho việc xây dựng các sản phẩm trung gian, đó là thay đổi một mẫu 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ô hình

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

Trong suốt quá trình phát triển, hình dạng của hệ thống có sự thay đổi Đầu tiên

là 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 đa 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 chữ V, bao gồm thiết kế, xây dựng và kiểm thử Bản chất của mô hình đa chữ V là sự khác nhau về phiên bản 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 ứng với giai đ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 đặc biệt và các môi trường kiểm thử chuyên biệt Vì thế luôn có một

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]

Hình 2 2: Vòng phát triển theo mô hình đa chữ V Khi thực hiện một dự án lớn và phức tạp việc cần làm là phân rã hệ thống theo 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 phần, 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 Tích hợp 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 trình phát triển phần mềm từ rất sớm với phần cứng thí 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]

Hình 2 3 : Mô hình đa chữ V lồng

Việc kiểm thử trong mô hình đa chữ V: Các nhà quản lý cần có một bức

tranh tổng quát về tất cả các hoạt động kiểm thử, các tình 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:

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

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

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) có quan hệ tới quá trình 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 độ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 đó đội kiểm thử có thể được chia ra hoạt động với những công việc đặc thù khác nhau, làm việc với những mô-đun khác nhau và vị trí khác nhau trong dự án Trong trường hợp đó, một kế hoạch kiểm thử tổng thể sẽ cung cấp một cơ chế cho phép điều phối toàn bộ quá trình kiểm thử

Đầu 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 đề này

 Kiểu kiểm thử (Test type): là một tập hợp những hoạt động kiểm thử với mục đích đánh giá hệ thống dựa trên một bộ đặc tả chất lượng liên quan Test type chỉ rõ cái gì sắp được test và không được test.[1]

 Cấp độ kiểm thử (Test levels): là một tập các hoạt động được tổ chức và đ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 nhau trong quá trình phát triển của hệ thống.[1]

Quy trình kiểm thử sẽ được cơ cấu thông qua việc đáp ứng nguyên lý kiểm thử tăng tiến (incremental testing).Trong giai đoạn đầu phát triển sản phẩm, các thành phần của hệ thố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 tí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) Đó 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 cầu ở mức 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 (hight-level test).Low- level test là thực hiện kiểm thử trên những thành phần độc lập, được thực hiện vào giai đoạn đầ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 test) Hight level-test là kiểm thử trên một hệ thống tích hợp, được thực hiện vào giai đoạn cuối của quá trình phát triển sản phẩm, tại môi trường thực của người sử dụng (có thể dùng giả lập) và thường thiên về kiểm thử hộp đen (Black-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 đó đượ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 tâm trong bản kế hoạch kiểm thử tổng thể là:

 Lựa chọn chiến lược kiểm thử

 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ếttrong phần tiếp theocác hoạt độnglập kế hoạchkiểm thử tổng thểtương ứng

2.2.3.2 Hoạt động lập kế hoạch kiểm thử tổng thể

Một kế hoạch kiểm thử tổng thể tốt cần phải vạch ra phương hướng thực hiện những hoạt động[1] sau:

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

 Xem xét và nghiên cứu tổng thể

 Xác định chiến lược kiểm thử tổng thể

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

 Xác đị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 được ủy quyền (Commissioner): Đây 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ị dựán (general project manager) của hệ thống đang được phát triển

 Nhà thầu (Contractor) :Là người chịu trách nhiệm tạo ra bản kế hoạch kiểm thử tổng thể, thường gọi là người quản lý kiểm thử(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 test) 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 diện với các hệ thống lân cận…Một vấnđề quan trọng là cần xác định rõ những công việc gì không có trong phạm vi công việc

 Mục tiêu (Objective) : Mục tiêu của quá trình kiểm thử là có thể mô tả chính xác các đặc điểm và đưa ra các điều khoản về sản phẩm sắp được phân phối

 Điều kiện tiên quyết (Preconditions) : Định ra các điều kiện cần có để phục vụ cho quá trình kiểm thử Như ngày kết thúc, kế hoạch, các tài nguyên hiện có…

 Các giảđịnh (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 quá trình kiểm thử có thể diễn ra suôn sẻ

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

hiểu biết về tổ chức của hệ thống, mục tiêu của hệ thống, thông tin về hệ thống đang được phát triển và những yêu cầu cần phải đạt được Hoạt động này bao gồm hai hoạt động chính

 Nghiên cứu những tài liệu đã có:

 Tài liệu về hệ thống, như là các kết quả của việc phân tích thông tin hoặc định hướng nghiên cứu

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

 Lược đồ tổ chức và phân công trách nhiệm, kế hoạch chất lượng và dự toán khối lượng công việc

 Mô tả về phương thức phát triển hệ thống, bao gồm các tiêu chuẩn

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

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

 Đại diện tiếp thị sản 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

 Đại diện người sử dụng cung cấp

Xác định chiến lƣợc kiểm thử tổng thể: Mục tiêu của hoạt động này là nhằm

đạt tới sự đồng lòng của các bên liên quan về các loại kiểm thử

 Xem xét về quản trị chất lượng hiện thời: Hoạt động kiểm thử là một phần của quá trình đảm bảo chất lượng nằm trong tiến trình phát triển sản phẩm Hệ 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 dõi sự thay đổi của quá trình đảm bảo chất lượng Khi quyết định những hoạt động kiểm thử sẽ được thực thi thì những hoạt động liên quan đến việc quản trị chất lượng cũng phải được cân nhắc

 Quyết định chiến lược:

 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ác đặc thù này là những minh 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 trong các báo cáo được tạo ra trong suốt quá trình kiểm thử

 Quyết định các vấn đề quan trọng liên quan tới các đặc thù chất lượng: Được cân nhắc dựa trên kết quả của bước trên Những người khác nhau

sẽ có những ý niệm khác nhauvề tầm quan trọng của một số đặc điểm của hệ 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

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

 Phân bổ đặc điểm chất lượng cho những cấp độ kiểm thử: Để tối ưu hóa việc phân bổ các nguồn tài nguyên khan hiếm cần chỉ rõ cấp độ kiểm thử nào cần phải được thực hiện và đảm bảo những đặc điểm chất lượng nào

 Ước lượng cấp độ kiểm thử tổng quát: Đối với hầu hết các cấp độ kiểm thử có thể dễ dàng nhận thấy hoạt động kiểm thử nào sẽ được thực hiện thông qua ma trận chiến lược Tiếp theo đó, việc ước lượng tổng quát công sức bỏ ra cho việc kiểm thử sẽ được thực hiện Trong suốt giai đoạn lên kế hoạch, các ước lượng chi tiết hơn sẽ được thực hiện

Xác định cơ sở hạ tầng: Mục tiêu của hoạt động này là việc xác định những cơ

sở hạ tầng cần thiết cho quá trình kiểm thử ở giai đoạn đầu của hoạt động kiểm thử, đặc biệt là những yêu cầu cần thiết cho việc kiểm thử ở các cấp độ trong quá trình phát triển Hoạt động này bao gồm ba hoạt động cơ bản:

 Xác định những môi trường kiểm thử cần thiết

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

 Quyết định các kế hoạch về cơ sở hạ tầng

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

mỗ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 thực hiện bao gồm ba hành động:

 Quyết định những vai trò cần thiế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ử dụ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 đà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 chuyên biệt và các công cụ sẽ được sử dụng Vì vậy, các khóa đào tạo là cần thiết

 Giao việc và chỉ ra kết quả cần báo cáo: Chỉ định các nhiệm vụ cần thực thi và 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ác quyết định bị hủy bỏ

Quyết đị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ử (trong phạm 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 hết các cấp độ kiểm thử ngày bắt đầu và kết thúc sản 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 chi tiết hóa

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

 Phân phối các hoạt động

 Xác định thời gian (man-hours) cho các cấp độ kiểm thử

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

 Các mối quan hệ với các hành động khác (có thể là nằm ngoài hành động kiểm thử hoặc giữa các cấp độ kiểm thử khác nhau)

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

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

2.2.5 Kiểm thử bởi nhóm người kiểm tra độ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 đoạn chuẩn bị: xác định xem cơ sở thử nghiệm có đủ chất lượng đảm bảo thực hiện thành công các trường hợp thử nghiệm

 Giai đoạn đặc tả kỹ thuật: xây dựng mộttậpcáckiểm thửbằng cáchsử dụng cáckỹ thuậtthiết kế thử nghiệmđược phân bổ

 Giai đoạn thi công: thực thi lệnh kiểm tra theo quy định để thu được kết quả về chất lượng của đối tượng kiểm tra

 Giai đoạn hoàn thành: lưu trữ các phần mềm, hoàn thiện các báo cáo, đánh giá tích luỹ kinh nghiệm chocác phần mềm kiểm thử trong tương lai

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ả thi 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 đánh giá rủi

ro là một yếu tố quan trọng trong một 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ý

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

ro Hậ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? Điề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 quả mà sản phẩm kém chất lượng gây ra Để làm được điều đó các khía 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]

Rủi ro = cơ hội lỗi* hậu quả lỗi gây ra (Risk=chanceoffailure x damage) Trong đó cơ hội lỗi liên quan đến tần suất sử dụng 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ử dụng nhiều lầ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, danh 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 tạp

 Các thành phần mới hoàn toàn

 Các thành phần thường xuyên thay đổi

 Các thành phần lần đầu dùng các 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 dưới áp lực rất lớn về thời gian

 Các thành phần thường được tối ưu thường xuyên hơn bình thường

 Các thành phần mà 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 đủ sự tham gia của đạ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

 Phát triển các công cụ mới và môi trường phát triển mới

 Những đội phát triểnvới các dự án lớn

 Đội phát triển phân tán ở nhiều nơi dẫn đến giao tiếp bị hạn chế

Những thông tin cần thiết để đánh giá rủi ro thường được lấy từ các nguồn khác nhau Bao gồm những người dùng cuối, các kỹ sư hỗ trợ và quản lý sản phẩm Thành viên trong đội dự án như kiến trúc sư, lập trình, kiểm thử viên và nhân viên bảo đảm chất lượng biết rõvề những khó khăn trong việc phát triển sản phẩm Họ có thể cung cấp những thông tin hữu ích trong việc đánh giá rủi ro

Không thể đánh giá rủi ro khách quan đầy đủ và chính xác.Đá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ó nhận thức tốt hơn về các rủi ro và các thử nghiệm Điều này là 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]

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 thử tổng thể là để 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á trình phát triển

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

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

 Xác định tầm quan trọng tương đối của các đặ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 phần Mô tả bằng

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ử

 Gá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 này 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ửcho một mức thử nghiệm là tạo ra sự lựa chọn những gì cần kiểm thử và có các kỹ thuật kiểm thử để áp dụng Chiến lược kiểm thử phải giải thích cho tất cả các bên liên quan biết lý do tại sao thử nghiệm hệ thống theo

cách này là sự lựa chọn tốt nhất có thể, xem xét áp lực thời gian và nguồn lực khan hiếm

Các chiến lược kiểm thửcho các cấp độ thử nghiệm khác nhau được xem như là sàng lọc thêm các mục tiêu cụ thể đã được đặt ra trong chiến lược kiểm thửtổng thể.Các kỹ thuật kiểm thửcụ thể áp dụng cho các phần cụ thể của hệ thống

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

 Lựa chọn các đặc tính chất lượng

 Xác định tầm quan trọng tương đối của các đặc tính chất lượng

 Cách chia hệ thống thành hệ thống con(subsystem): Mỗi thành phần con được gọi là các thành phần (component) hay một đơn vị chức năng (functional unit) Mỗi thành phần này có thể được kiểm thử riêng rẽ và chúng có mức độ rủi ro khác nhau Các hệ thống con được chia theo kiến trúc thiết kế Một cách để chia nữa là dựa vào phạm vi rủi ro

 Xác định tầm quan trọng tương đối của các 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 niệm cá nhân của người quản lý kiểm thử mà phải là từ cái nhìn của người dùng sản phẩm, người quản lý sản phẩm

 Xác định tầm quan trọng của việc kiểm thử mỗi hệ thống con, sự kết hợp các đặc tính chất lượng: Đây là bước làm mịn chiến lược bằng cách kết hợp đánh giá cácđặc tính chất lượng và hệ thống con Có nghĩa là một đặc tính chất lượng cụ thể của một hệ thống con cụ thể sẽ được đánh giá mức

độ quan trọng Kết quả của bước này cung cấp một cái 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ử được sử dụng: Đội kiểm thử sẽ được kì vọng là tổ chức và thực thi một quá trình kiểm thử mà bao trùm những phần quan trọng của sản phẩm đã được tổ chức định nghĩa ra Công việc của người quản lý kiểm thử là thiết lập một tập các kỹ thuật mà 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 dụng, cơ sở kiểm thử được yêu cầu, tài nguyên được yêu cầu, kiến thức và kỹ năng được yêu cầu

2.3.1.4 Chiến lược thay đổi trong quá trình thử nghiệm

Người quản lý kiểm thửkhông được phép cho rằng các chiến lược thử nghiệm

sẽ được phát triển một lần và sau đó cố định trong suốt quá trình của dự á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 đổi của thực tế Sử dụng chiến lược kiểm thửnhư một cơ sở, người quản lý kiểm thửcó thể thảo luận về các chủ đề này với các bên liên quan Khi hoàn cảnh thay đổi yêu cầu việc thử nghiệm

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 cần đạt đượ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 trìcá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 tra Nhưng cũng có thể

là hệ thốngđã hoạt động chính xác trong 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

là 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 trung vào kiểm tra các chức năng trư ớcđó 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 trì 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ử mà lựa chọn thực hiện kiểm thử hồi quy đầyđủ hoặc kiểm thử các tình huống thích hợp nhất với các thay đổ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ử hồi quy

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

2.3.2.1 Giới thiệu

Việc chuẩn bị kiểm thử bắt đầu từ việc xem xét tính có thể kiểm thử Tính có thể kiểm thử được hiểu là sự hoàn thiện, rõ ràng và nhất quán của các tài liệu để kiểm thử Tính có thể kiểm thử cao nhất định sẽ đảm bảo thành công quá trình đặc tả kiểm 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à chi 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 đến tiêu tốn chi phí nhiều và ảnh hưởng đến thời hạn đưa sản phẩm ra thị trường

2.3.2.2 Thủ tục

Xem xét khả năng kiểm thử có các bước sau:[1]

 Lựa chọn tài liệu liên quan: Trong kế hoạch kiểm thử (test plan) cần phải 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 định một cách hình thức cơ

sở kiểm thử và những tài liệu thực tế sẽ được dùng

 Soạn một danh sách hạng mục 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ử được sử dụng

 Đánh giá tài liệu: Với danh sách các mục cần kiểm tra, đội kiểm thử sẽ xác nhận tài liệu và đưa ra một báo cáo lỗi cho một lỗi được phát hiện Phát 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 kiểm thử

 Báo cáo kết quả: Dựa trên các lỗi được phát hiện, đội kiểm thử sẽ bàn giao một báo cáo xem xét tính có thể kiểm thử Báo cáo sẽ cung cấp tóm tắt về chất lượng của tài liệu

Cơ sở kiểm thử không lý tưởng:Trong thực tế có khi những yêu cầu chưa 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 này không áp dụng xem xét tính khả kiểm thử mà pha chuẩn bị đơn thuần là khoảng thời gian để gom 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 đánh giá trong đó một người hay một nhóm khác với tác giả xem xét các yêu cầu phần mềm, thiết kế hoặc mã nguồnđể phát hiện lỗi, vi phạm các tiêu chuẩn phát triểnvà vấn đề khác Thanh tra đã được chứng minh là một cách thức kiểm thử hiệu quả với chi phí rất rẻ cho việc tìm ra các lỗi

Mục tiêu của thanh tra:

 Để xác nhận phần mềm làm đúng đặc tả

 Để xác nhận phần mềm tuân theo các tiêu chuẩn

 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 đị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 định và do đó có thể đánh giá được những chi 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à đánh giá khác vì 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

Ưu điểm:

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

 Tỷ lệ phát hiện lỗi là khá cao vì 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ử dụng cho tất cả các tài liệu được bàn giao của quá trình phát triển cũng như quá trình kiểm thử

 Việc kiểm tra kích thích cao nhận thức và động lực phát triển các sản phẩm chất lượng

2.3.3.2 Thủ tục

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

 Tiếp nhận thanh tra kiểm tra: Người phụ trách tiếp nhận kiểm tra sản 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 tá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 phẩm sẽ được chấp nhận để thanh tra

 Tổ thức thanh tra: Người chịu trách nhiệm sẽ tổ chức một cuộc thanh tra liệu sản phẩm có vượt qua vòng tiếp nhận hay không Một đội phải được

tổ chức ra làm việc này và mỗ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 đó thống nhất một cuộc họp

 Khởi động thanh tra

 Chuẩn bị

 Họp để công bố thiếu sót

 Họp phân tích nguyên nhân

 Thực hiện làm lại

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

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

2.3.4.1 Giới thiệu

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

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

Hai kỹ thuật phân tích an toàn được mô tả:FMEA (Failure Mode and Effect Analysis)và FTA (Fault Tree Analysis)

Phân tích an toàn là mối quan hệ giữa nguyên nhân - kết quả Kết quả luôn luôn liên quan đến những nguy hại

Hình 2 8: 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 FMEA và toàn bộ được phân tích bởi FTA

2.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

 Xác định ảnh hưởng của chế độ thất bại tiềm ẩn lên chức năng của hệ thống

 Xây dựng các hành động để giảm thiểu những tác động hoặc chế độ thất bại

Việc sử dụng phù hợp các FMEA có thể có những lợi ích sau đây:

 Nâng cao an toàn của hệ thống

 Nâng cao khả năng theo dõi những rủi ro trong suốt chu trình phát triển

 Sớm xác định các mối nguy hiểm tiềm ẩn

 Làm giảm bớt rủi ro về tài liệu và các tác động

 Giảm thiểu các thay đổi và chi phí liên quan

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

FTA (Fault TreeAnalysis) được sử dụng để xác định nguyên nhân của thất bại Đây là một kỹ thuật để phân tích thiết kế với sự an toàn và độ tin 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 trạng thái không mong muốn (các bộ phận của hệ thống) chịu trách nhiệm về những trục trặc của hệ thống Một cây lỗi cũng có thể được sử dụng để tìm nguyên nhân thất bại Những thất bại này ảnh hưởng đến nhiều phần của hệ thống.[1]

FMEA và FTA là các kỹ thuật thường được trình bày và sử dụ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 và FMEA sau đó có thể được áp dụng có hiệu quả để xác định các điểm yếu và phần rủi ro của hệ thống [1]

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

Danh sách kiểm tra được sử dụng như là một kỹ thuật để cung cấp trạng thái thông tin theo cách chính thức về tất cả các khía 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ác đặc tính chất lượng

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

 Tổng hợp danh sách kiểm tra cho kiểm thử cấp thấp

 Danh sách kiểm tra các kỹ thuật thiết kế kiểm thử

 Bảng danh sách kiểm tra liên quan đến quá trình kiểm thử

Các danh sách kiểm tra cho các đặc điểm chất lượng được sử dụng để đánh giá

hệ thống thực hiện tốt các yêu cầu liên quan đến các đặc tính chất lượng không Các bản 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ác mục tiêu được yêu cầu và những trường hợp kiểm thửnàyđược chuẩn bị trước khi thực hiện kiểm thử Một kỹ thuật thiết kế kiểm thửlà một phương pháp đã được chuẩn hoá phát sinh các trường hợp kiểm thử bắt nguồn từ thông tin tham khảo

Mô tả 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ử logic