Tài liệu Các kỹ thuật kiểm thử phần mềm nhúng và ứng dụng

  • Số trang: 74 |
  • Loại file: PDF |
  • Lượt xem: 129 |
  • Lượt tải: 0
tailieuonline

Tham gia: 31/07/2015

Mô tả:

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN THÙY DƢƠNG CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM NHÚNG VÀ ỨNG DỤNG LUẬN VĂN THẠC SĨ NGÀNH CÔNG NGHỆ THÔNG TIN Hà Nội – 2014 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN THÙY DƢƠNG 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À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 1 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 đinh, 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 2 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 3 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 4 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 5 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 6 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 7 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. 8 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ử. 9  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: Thực hiện kiểm thử Lập kế hoạch Thiết kế kiểm thử Phát triển kịch bản kiểm thử Đánh giá 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 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. Dự án bắt đầu Yêu cầu Các thời điểm lập kế hoạch kiểm thử Thiết kế Viết Code Kiểm tra Chuyển giao cho khách hàng Bổ sung 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) Kế hoạch kiểm thử đơn vị (Unit test plan) Hình 1. 2: Thời điểm phù hợp để thiết lập các kế hoạch kiểm thử 10 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 11 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 12 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] 13 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ì: 14  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 đó. 1.4.3 Kiểm thử hệ thống (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 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 ). 15  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 Dữ liệu Các tài liệu yêu cầu của khách hàng Tài liệu sử dụng Kiểm tra mức hệ thống (System test) Kiểm thử chức năng Kiểm thử khả năng chịu tải 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 tra đã hoàn thành Hệ thống sẵn sàng để khách hàng kiểm thử chấp nhận 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. 16 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] 17 input output 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] input output 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. 18 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. 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 Hệ thống nhúng (Embedded system) là một thuật ngữ để chỉ một hệ thống có khả năng tự trị được nhúng vào trong một môi trường hay một hệ thống mẹ. Đó là các hệ thống tích hợp cả phần cứng và phần phềm phục vụ các bài toán chuyên dụng trong nhiều lĩnh vực công nghiệp, tự động hoá điều khiển và truyền tin. Đặc điểm của các hệ thống nhúng là hoạt động ổn định và có tính năng tự động hoá cao.[2] 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  …
- Xem thêm -