Bài giảng Đảm bảo chất lượng phần mềm và kiểm thử - Phần II: Kiểm thử phần mềm 2

§¹i häc Quèc gia Hμ néi - §¹i häc c«ng nghÖ Bé m«n C«ng nghÖ phÇn mÒm BÀI GiẢNG ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM VÀ KiỂM THỬ NguyÔn V¨n Vy Email: vynv@coltech.vnu.vn, mobile: 0912.505.291 Hà nội - 2005 2005 Bộ môn CNFM – Đại học Công nghệ 2 NguyÔn V¨n Vþ KIỂM THỬ PHẦN MỀM Phần II 2005 Bộ môn CNFM – Đại học Công nghệ 3 NguyÔn V¨n Vþ „ Các loại kiểm thử „ Thẩm định và xác minh ™ Roger S. Pressman. Software Engineering, a Practitioner’s Approach. 3th Edition, McGraw-Hill, 1992, Bản dich của Ngô Trung vIệt, Phần 4, tập 4 (Chương 17, 18, 23 –bản 2001) ™ Ian Sommerville. Software Engineering, Sixth Edition, Addion Wesley, 2001, Phần 5 và 6. chương 20 ™ E.M.Bennatan, Software Project Management : a practitioner’s approach, McGRAW-HILL Book Company, 2001 ™ Nguyễn Văn Vỵ, Nguyễn Việt Hà. Giáo trình kỹ nghệ phần mềm, Đại học Công nghệ, ĐHQGHN, 2006. Nội dung – Tài liệu 2005 Bộ môn CNFM – Đại học Công nghệ 4 NguyÔn V¨n Vþ a. Khái niệm ‰ Chiến lược kiểm thử là sự tích hợp các kỹ thuật thiết kế ca kiểm thử tạo thành một dãy các bước nhằm hướng dẫn quá trình kiểm thử phần mềm thành công. ‰ Nó phác thảo lộ trình để: † nhà phát triển tổ chức việc bảo đảm chất lượng, † khách hàng: hiểu được công sức, thời gian và nguồn lực cần cho kiểm thử. D. Chiến lược kiểm thử phần mềm 2005 Bộ môn CNFM – Đại học Công nghệ 5 NguyÔn V¨n Vþ Chiến lược kiểm thử phải: „ tích hợp được việc lập kế hoạch, thiết kế ca kiểm thử, tiến hành kiểm thử, thu thập và đánh giá các thông tin kết quả. „ đủ mềm dẻo để cổ vũ óc sáng tạo, đáp ứng được yêu cầu khách hàng „ thích ứng với mức kiểm thử cụ thể „ đáp ứng các đối tượng quan tâm khác nhau b. Yêu cầu của chiến lược kiểm thử 2005 Bộ môn CNFM – Đại học Công nghệ 6 NguyÔn V¨n Vþ Các đặc trưng có tính khuôn mẫu: „ Bắt đầu ở mức môđun và tiếp tục cho đến khi tích hợp ở mức hệ thống trọn vẹn. „ Các kỹ thuật kiểm thử khác nhau là thích hợp cho những thời điểm khác nhau. „ Được cả người phát triển và nhóm kiểm thử độc lập cùng tiến hành. „ kiểm thử đi trước gỡ lỗi, song việc gỡ lỗi phải thích ứng với từng chiến lược kiểm thử . c. Các đặc trưng chiến lược kiểm thử 2005 Bộ môn CNFM – Đại học Công nghệ 7 NguyÔn V¨n Vþ ■ Chiến lược cần thích ứng với từng mức kiểm thử: • kiểm thử mức thấp: xác minh từng khúc mã nguồn có tương ứng và thực thi đúng đắn không? • kiểm thử mức cao: xác minh và thẩm định các chức năng hệ thống chủ yếu có đúng đặc tả và đáp ứng yêu cầu của khách hàng không?. d. Sự thích ứng của chiến lược kiểm thử 2005 Bộ môn CNFM – Đại học Công nghệ 8 NguyÔn V¨n Vþ ■ Mỗi chiến lược đáp ứng được yêu cầu người quan tâm: • Có các hướng dẫn cho người thực hiện tiến hành kiểm thử. • Có các cột mốc cho các nhà quản lý kiểm soát hoạt động đảm bảo chất lượng. • Có thước đo để có thể nhận ra các vấn đề càng sớm càng tốt và khách hàng nhận biết được quá trình kiểm thử e. Sự đáp ứng của chiến lược kiểm thử 2005 Bộ môn CNFM – Đại học Công nghệ 9 NguyÔn V¨n Vþ † Kiểm thử phần mềm là một phần của hoạt động “xác minh và thẩm định”: „ Xác minh là một tập các hoạt động để bảo đảm rằng: phần mềm thực hiện đúng chức năng đã được đặc tả „ Thẩm định là một tập hợp các hoạt động để bảo đảm rằng: phần mềm đã đáp ứng đúng yêu cầu của khách hàng. Câu hỏi: Ai làm? Làm cái gì? Khi nào? Và mối quan hệ? E. Tổ chức kiểm thử 2005 Bộ môn CNFM – Đại học Công nghệ 10 NguyÔn V¨n Vþ † Các kỹ sư phần mềm làm ra phần mềm. Một cách tự nhiên họ cần tiến hành các kiểm thử ban đầu. Về nguyên tắc, người làm sản phẩm, kiểm tra sản phẩm là không hợp lý. † Có một số hiểu lầm : „ Người phát triển không tham gia kiểm thử . „ Cho phép người lạ kiểm thử một cách tàn nhẫn. „ Người kiểm thử chỉ quan tâm khi kiểm thử bắt đầu a. Trách nhiệm kiểm thử phần mềm 2005 Bộ môn CNFM – Đại học Công nghệ 11 NguyÔn V¨n Vþ Từ thực tiễn dẫn đến sự phân công: † Người phát triển chịu trách nhiệm kiểm thử đơn vị do mình phát triển để bảo đảm thực hiện đúng theo thiết kế (một yêu cầu của xác minh). † Người phát triển có thể tham gia kiểm thử tích hợp. † Nhóm kiểm thử độc lập bắt đầu làm việc khi các khoản mục cấu trúc phần mềm đã đày đủ. b. Phân công trách nhiệm kiểm thử 2005 Bộ môn CNFM – Đại học Công nghệ 12 NguyÔn V¨n Vþ † Nhóm kiểm thử độc lập giúp gỡ bỏ những thành kiến cố hữu: “người xây dựng không thể kiểm thử sản phẩm tốt”: „ gỡ bỏ mâu thuẫn giữa những người tham gia. „ đánh giá công sức người phát triển bỏ ra tìm lỗi. † Nhóm kiểm thử độc lập tạo ra báo cáo đầy đủ cho tổ chức bảo đảm chất lượng phần mềm. † Người phát triển „ không đẩy chương trình cho người kiểm thử rồi bỏ đi „ cùng làm việc với người kiểm thử xuyên suốt một dự án (bảo đảm việc kiểm thử được tiến hành triệt để). c. Vai trò của những người kiểm thử 2005 Bộ môn CNFM – Đại học Công nghệ 13 NguyÔn V¨n Vþ ‰ Tiến trình thực hiện kiểm thử tương ứng với tiến trình phát triển (theo từng mô hình). ‰ Tiến trình kiểm thử thông thường (mô hình chữ V): F. Tiến trình thực hiện kiểm thử Kiểm thử đơn vị Kiểm thử tích hợp Kiểm thử hệ thống môđun đơn vị Môđun chức năng, hệ con cả phần cứng, phần mềm Kiểm thử thẩm định hệ thống thực 2005 Bộ môn CNFM – Đại học Công nghệ 14 NguyÔn V¨n Vþ † Nội dung kiểm thử: „ giao diện „ cấu trúc dữ liệu sử dụng cục bộ „ đường điều khiển Câu hỏi: 1. Định lượng/dạng gì (biến, mô đun qua giao diện)? 2. Yếu tố nào cần (vào/ra dữ liệu)? 3. Sai xử lý, lôgíc (phép toán, biểu thức)? 4. Sai điều khiển (vòng lặp, giá trị biên)? 5. Sai tiềm ẩn (ghi chép, mô tả)? a. Kiểm thử đơn vị ƒ Điều kiện lôgic ƒ Phép toán xử lý 2005 Bộ môn CNFM – Đại học Công nghệ 15 NguyÔn V¨n Vþ † Kiểm thử dòng dữ liệu qua một giao diện của môđun liên quan đến định lượng và định dạng của các biến và các môđun sử dụng trên giao diện. † Đặc trưng cụ thể: „ Số lượng? „ Định dạng? a1. Kiểm thử dữ liệu qua giao diện Cường độ, loại tia Áp lực, bước sóng Mùi vị, nồng độ Món ăn, kích cỡ, độ mềm 2005 Bộ môn CNFM – Đại học Công nghệ 16 NguyÔn V¨n Vþ Các đặc trưng qua giao diện là: ƒ Số tham số = số đối số? ƒ Tính chất của tham số ≡ tính chất đối số? ƒ Đơn vị của tham số ≡ đơn vị đối số? ƒ Số đối được truyền gọi môđun = số các tham số đầu vào của môđun? ƒ thuộc tính các đối được truyền gọi môđun ≡ thuộc tính của các tham số? ƒ Đơn vị của đối được truyền để gọi môđun ≡ đơn vị các tham số môđun? a1. Đặc trưng dữ liệu qua giao diện X1,X2,..,Xn Y1,Y2,..,Yn 2005 Bộ môn CNFM – Đại học Công nghệ 17 NguyÔn V¨n Vþ ƒ Thuộc tính và các cái khác của các đối số định sẵn có đúng đắn hay không? ƒ Mọi tham chiếu liên quan tới các tham số hiện không kết hợp với đầu vào chứ? ƒ Các đối số chỉ đọc đã được đổi chưa? ƒ Định nghĩa biến toàn cục có trong suốt môđun không? ƒ Các ràng buộc lên biến đã chuyển qua như tham số chưa? a1. Đặc trưng dữ liệu qua giao diện 2005 Bộ môn CNFM – Đại học Công nghệ 18 NguyÔn V¨n Vþ † Khi thực hiện I/O ngoại lai cần tiến hành thêm: „ Tính chất của các file có đúng đắn hay không? „ Các câu lệnh OPEN/CLOSE có đúng đắn không? „ Đặc tả hình thức có đúng với các câu lệnh I/O? „ Cỡ của buffer có đúng với cỡ của bản ghi không? „ Các file có mở trước khi sử dụng không? „ Các điều kiện end-of-file có được xử lý? „ Các sai lầm I/O có được xử lý? „ Có sai văn bản nào trong thông tin ra? a2. Kiểm thử liên quan đến vào/ra 2005 Bộ môn CNFM – Đại học Công nghệ 19 NguyÔn V¨n Vþ † Cấu trúc dữ liệu cục bộ cho môđun có thể sai. Vì thế thiết kế các kiểm thử cần làm lộ ra các loại lỗi sau: „ Đánh máy không đúng hoặc không nhất quán? „ Giá trị ngầm định hoặc giá trị khởi thuỷ sai? „ Tên các biến không đúng (sai chữ hoặc mất chữ)? „ Kiểu dữ liệu không nhất quán? „ Ngoại biệt về địa chỉ, underflow, overflow. a3. Kiểm thử cấu trúc dữ liệu cục bộ 2005 Bộ môn CNFM – Đại học Công nghệ 20 NguyÔn V¨n Vþ † Các sai về trình tự, độ chính xác là: „ Thứ tự ưu tiên các phép tính số học? „ Sự nhất quán của các phép toán trộn mode? „ Khởi sự/kết thúc không đúng đắn? „ Sự chính xác của kết quả? a4. Kiểm thử về các xử lý 2005 Bộ môn CNFM – Đại học Công nghệ 21 NguyÔn V¨n Vþ † Các sai kiểu, toán tử, ngữ nghĩa: „ So sánh các kiểu dữ liệu khác nhau. „ Ưu tiên hoặc toán tử logic không đúng đắn. „ Dự đoán một biểu thức so sánh, trong khi sai số làm cho đẳng thức không chắc có thực. „ Các giá trị so sánh không đúng đắn. (Α∩Β) ∪ (Φ ≤ Ω) a5. Kiểm thử các điều kiện lôgic 2005 Bộ môn CNFM – Đại học Công nghệ 22 NguyÔn V¨n Vþ † Các sai biến lặp, số vòng lặp: „ Vòng lặp không kết thúc hoặc kết thúc không chính xác. „ Sự lặp phân kỳ khó thoát được „ Các biến lặp bị cải biên không chính xác. † Sai ở các biên „ kiểm thử biên là nhiệm vụ cuối cùng của bước kiểm thử đơn vị. Phần mềm thường thất bại tại các biên của chúng. a6. Kiểm thử dòng điều khiển/biên ? 2005 Bộ môn CNFM – Đại học Công nghệ 23 NguyÔn V¨n Vþ † Các sai tiềm ẩn cần được đánh giá là: „ Mô tả sai (khó hiểu) „ Dữ liệu ghi không tương ứng với sai đã gặp. „ Điều kiện sai có trước khi xử lý sai. „ Xử lý điều kiện ngoại lệ là không đúng đắn. „ Mô tả sai không cung cấp đủ thông tin để trợ giúp định vị nguyên nhân của sai. a7. Kiểm thử sai tiềm ẩn 2005 Bộ môn CNFM – Đại học Công nghệ 24 NguyÔn V¨n Vþ † Sau khi mã nguồn được phát triển, rà soát và kiểm tra tính đúng đắn cú pháp (thanh tra), thiết kế ca kiểm thử đơn vị bắt đầu. † kiểm thử đơn vị là phần phụ thêm của mã hoá. † Kết quả rà soát thiết kế cung cấp các chỉ dẫn để thiết lập các ca kiểm thử nhằm bộc lộ các sai trong mỗi loại đã nêu. † Mỗi ca kiểm thử phải gắn với một tập các kết quả mong đợi. a9. Thủ tục kiểm thử đơn vị Lập mã Thanh tra Rà soát Kiểm thử Đơn vị 2005 Bộ môn CNFM – Đại học Công nghệ 25 NguyÔn V¨n Vþ † Môđun không phải là chương trình cô lập, nên cần phát triển các phần mềm bộ lái và/hoặc cuống cho kiểm thử mỗi đơn vị. † Bộ lái (driver) là một hàm “main” điều khiển việc đưa dữ liệu vào và nhận kết quả ra của module † Cuống (stub) dùng để thay cho các module là thứ cấp của nó. a10. Kỹ thuật kiểm thử đơn vị 2005 Bộ môn CNFM – Đại học Công nghệ 26 NguyÔn V¨n Vþ m10. Kỹ thuật kiểm thử đơn vị (t) A C B D E B Hệ thống xây dựng Kiểm thử môđun B Cuống (thay D,E) Bộ lái (thay A) Giá trị trả về Đầu vào Dữ liệu Kết quả 2005 Bộ môn CNFM – Đại học Công nghệ 27 NguyÔn V¨n Vþ † Một cuống (stub) hoặc “dummy program” dùng các giao diện của môđun thứ cấp: làm được các thao tác tối thiểu, kiểm chứng đầu vào và giá trị trả về. † Bộ lái và Cuống cần chi phí hành chính. Chúng cần viết ra nhưng không được phân phối kèm với sản phẩm cuối cùng. † Chi phí hành chính thấp nếu đơn giản, nhưng không may đa số là cao, khi đó người ta hoãn kiểm thử đày đủ cho tới bước kiểm thử tích hợp. a10. Kỹ thuật kiểm thử đơn vị 2005 Bộ môn CNFM – Đại học Công nghệ 28 NguyÔn V¨n Vþ b1. Khái niệm ‰ Kiểm thử tích hợp (integration testing) nhằm nhận được 1 bộ phận chức năng hay 1 hệ con tốt. ‰ Là một lỹ thuật có tính hệ thống để xây dựng cấu trúc chương trình. ‰ Từ các môđun đã kiểm thử đơn vị, xây dựng cấu trúc chương trình đảm bảo tuân theo thiết kế. ‰ Có hai cách tích hợp „ Tích hợp dần: từ trên xuống, dưới lên, kẹp „ Tích hợp đồng thời 1 lúc: “big bang” b. Kiểm thử tích hợp 2005 Bộ môn CNFM – Đại học Công nghệ 29 NguyÔn V¨n Vþ Các sai có thể gặp khi tích hợp : „ Dữ liệu bị mất khi đi qua một giao diện. „ hiệu ứng bất lợi 1 môđun vô tình gây ra đối các môđun khác. „ Sự kết hợp các chức năng phụ có thể không sinh ra chức năng chính mong muốn. „ Sự phóng đại các sai sót riêng rẽ có thể bị đến mức không chấp nhận được. „ Vấn đề của cấu trúc dữ liệu toàn cục có thể để lộ ra . b1. Các sai gặp khi tích hợp 2005 Bộ môn CNFM – Đại học Công nghệ 30 NguyÔn V¨n Vþ ‰ Kết hợp tất cả các môđun đã kiểm thử đơn vị thành chương trình. ‰ Tiến hành kiểm thử toàn bộ chương trình. ‰ kết quả: là 1 mớ hỗn Độn! Với 1 tập các sai, chỉnh sửa chúng là khó khăn vì cô lập các nguyên nhân là phức tạp: sai này được sửa, có thể xuất hiện nhiều sai khác, cứ thế triền miên! b2. Chiến lược “big bang” & hậu quả modul2 3 4 Module 1 2005 Bộ môn CNFM – Đại học Công nghệ 31 NguyÔn V¨n Vþ † là một cách tiện lợi để xây dựng và kiểm soát cấu trúc chương trình. † Gộp dần các môđun từ trên xuống theo trật tự dòng điều khiển, bắt đầu từ môđun điều khiển “main”, gắn từng môđun phụ trợ vào môđun điều khiển thượng cấp. Có thể theo 2 cách: „ Theo chiều “sâu trước” „ Theo chiều “rộng trước”. b3. Chiến lược tích hợp từ trên xuống 2005 Bộ môn CNFM – Đại học Công nghệ 32 NguyÔn V¨n Vþ † Tích hợp từ trên xuống thực hiện theo 5 bước: 1. Môđun điều khiển chính được dùng như bộ lái kiểm thử (test driver) và tất cả các môđun phụ trợ trực tiếp được thay thế bởi các cuống (stub). 2. Thay thế dần từng cuống bởi môđun thực thi tương ứng. 3. Sau khi tích hợp môđun đó, tiến hành các kiểm thử tương ứng. b3.1. Tiến trình tích hợp trên xuống 2005 Bộ môn CNFM – Đại học Công nghệ 33 NguyÔn V¨n Vþ 4. Khi hoàn thành các kiểm thử này thì thay một cuống khác bằng môđun thực (nghĩa là quay lại bước 2). 5. Có thể kiểm thử lại (toàn bộ hoặc một phần các kiểm thử trước – kiểm thử hồi quy) để bảo đảm rằng không có sai mới nào được sinh ra. 6. Tiếp tục lặp lại từ bước 2 cho tới khi toàn bộ cấu trúc chương trình được xây dựng b3.1. Tiến trình tích hợp trên xuống 2005 Bộ môn CNFM – Đại học Công nghệ 34 NguyÔn V¨n Vþ b3.2. Sơ đồ - tích hợp trên xuống A B C D E F I K HG A B A BCuống (C,D) Cuống(E,F) Cuống(E,F) Cuống (D,I,K) Cuống C Kiểm thử A Kết hợp theo chiều rộng Kết hợp theo chiều sâuHệ cần kiểm thử Chưa xong 2005 Bộ môn CNFM – Đại học Công nghệ 35 NguyÔn V¨n Vþ ƒ Nó không phức tạp, nhưng có các vấn đề logic: khi xử lý ở mức thấp lại đòi hỏi phải đủ tương xứng với mức cao. ƒ Khi cuống được thay thế cho các môđun mức thấp, do đó không 1 dữ liệu có ý nghĩa nào được truyền lên trên. b3.3. Bình luận tích hợp trên xuống 2005 Bộ môn CNFM – Đại học Công nghệ 36 NguyÔn V¨n Vþ ‰Người kiểm thử có 3 cách chọn: „ Trì hoãn nhiều kiểm thử cho tới khi các cuống được thay thế bằng các môđun thực sự. „ Phát triển các cuống sao cho chúng hoàn thành như một phần hạn chế các chức năng mà môđun dưới thực thực hiện. „ Kết hợp tích hợp các môđun từ dưới lên (chiến lược dưới lên) b3.4. Giải pháp tích hợp từ trên xuống 2005 Bộ môn CNFM – Đại học Công nghệ 37 NguyÔn V¨n Vþ ‰ Bắt đầu xây dựng và kiểm thử từ các môđun nguyên tố: việc xử lý nếu có đòi hỏi các môđun phụ trợ thì các môđun thực sự đã sẵn sàng (cuống- đã bị loại). b4. Chiến lược tích hợp từ dưới lên 2005 Bộ môn CNFM – Đại học Công nghệ 38 NguyÔn V¨n Vþ ‰ Thực hiện 4 bước: 1. Các môđun mức thấp được tổ hợp vào trong các cụm (cluster) thực hiện một chức năng phụ trợ đặc biệt. (các cluster gọi là các cụm) 2. Một bộ lái được viết để phối hợp đầu vào và đầu ra của ca kiểm thử. 3. kiểm thử cụm đó. 4. Tháo bỏ các driver & các cụm tổ hợp ngược lên trong cấu trúc chương trình b4.1. Tiến trình tích hợp từ dưới lên 2005 Bộ môn CNFM – Đại học Công nghệ 39 NguyÔn V¨n Vþ b4.2. Sơ đồ tích hợp dưới lên Bộ lái Bộ lái Bộ lái Vòng 1 Vòng 2 Vòng 3 Cụm 2005 Bộ môn CNFM – Đại học Công nghệ 40 NguyÔn V¨n Vþ ‰ phương pháp trên-xuống: „ Nhược điểm: cần các cuống „ những khó khăn kèm theo cuống. „ Có ngay chức năng điều khiển hệ thống. ‰ Phương pháp dưới –lên: „ luôn chưa có chương trình chỉnh thể „ thiết kế ca kiểm thử dễ và không cần cuống. b5. Bình luận phương pháp tích hợp 2005 Bộ môn CNFM – Đại học Công nghệ 41 NguyÔn V¨n Vþ ‰ Việc lựa chọn chiến lược kiểm thử phụ thuộc vào đặc tính của phần mềm và đôi khi vào lịch trình dự án. ‰ Phương pháp hỗn hợp (kiểm thử sandwich) có thể có triển vọng nhất: trên-xuống cho mức cao của cấu trúc chương trình và dưới-lên cho mức phụ trợ. b5. Bình luận phương pháp tích hợp 2005 Bộ môn CNFM – Đại học Công nghệ 42 NguyÔn V¨n Vþ ‰ Người kiểm thử cần định rõ các môđun tới hạn, là các môđun có các đặc tính sau: „ Chú trọng đến 1 vài yêu cầu phần mềm. „ Có mức điều khiển cao (trong cấu trúc chương trình). „ Phức tạp hoặc dễ có sai (có thể dùng Độ phức tạp vòng lặp, chẳng hạn). „ Có các yêu cầu thực hiện được xác định rõ. ‰ Các môđun tới hạn cần được kiểm thử càng sớm càng tốt n5. Bình luận phương pháp tích hợp 2005 Bộ môn CNFM – Đại học Công nghệ 43 NguyÔn V¨n Vþ ‰ Một kế hoạch kiểm thử tổng thể và một mô tả các kiểm thử đặc biệt phải được đưa vào “đặc tả kiểm thử ”. ‰ Đặc tả này phải được phân phối trong tiến trình kỹ nghệ phần mềm và trở thành 1 bộ phận cấu hình phần mềm. ‰ Nội dung tài liệu: b6. Tài liệu kiểm thử tích hợp 2005 Bộ môn CNFM – Đại học Công nghệ 44 NguyÔn V¨n Vþ ƒ Phạm vi kiểm thử ƒ Kế hoạch kiểm thử ƒ Các pha kiểm thử và các cụm ƒ Lịch trình ƒ Phần mềm chung (overhead) ƒ Môi trường và nguồn lực ƒ Thủ tục kiểm thử cụm n ƒ Thứ tự tích hợp ƒ Mục đích ƒ Các môđun được kiểm thử ƒ Các môđun đơn vị cho các môđun trong cụm b6.1. Nội dung tài liệu kiểm thử tích hợp 2005 Bộ môn CNFM – Đại học Công nghệ 45 NguyÔn V¨n Vþ ƒ Mô tả kiểm thử cho cụm m ƒ Mô tả phần mềm chung (overhead) ƒ Các kết quả mong đợi ƒ Các kỹ thuật và các công cụ đặc biệt ƒ Mô tả phần mềm chung ƒ Dữ liệu cho ca kiểm thử ƒ Các kết quả chờ đợi cho cụm n ƒ Các kết quả kiểm thử thực ƒ Các tham khảo ƒ Phụ lục b6.1. Tài liệu kiểm thử tích hợp 2005 Bộ môn CNFM – Đại học Công nghệ 46 NguyÔn V¨n Vþ ‰ Phạm vi kiểm thử : tổng quát các tính chất về chức năng đặc biệt, về sự thực hiện, về thiết kế nội tại cần kiểm thử; công sức kiểm thử được giới hạn lại; tiêu chuẩn đầy đủ cho từng pha kiểm thử được mô tả và ràng buộc về lịch trình được lập tài liệu. ‰ Kế hoạch kiểm thử : mô tả chiến lược tích hợp tổng thể; kiểm thử được chia thành các pha và các cụm nhắm đến các tính chất ứng xử và các chức năng đặc biệt. b6.2. Nội dung phạm vi, kế hoạch kiểm thử 2005 Bộ môn CNFM – Đại học Công nghệ 47 NguyÔn V¨n Vþ ƒ Tích hợp giao diện: các giao diện trong và ngoài được kiểm thử mỗi khi một môđun (hoặc cụm) được tích hợp vào trong cấu trúc. ƒ Thẩm định chức năng: tiến hành kiểm thử chức năng đã thiết kế nhằm bộc lộ các sai chức năng ƒ Nội dung thông tin: tiến hành kiểm thử dữ liệu đã thiết kế nhằm bộc lộ các sai gắn với các cấu trúc dữ liệu cục bộ và toàn cục ƒ Thực thi: tiến hành kiểm thử đã thiết kế nhằm kiểm nghiệm thực thi các hạn chế đã được thiết lập trong quá trình thiết kế phần mềm b6.3 Tiêu chuẩn kiểm thử tích hợp 2005 Bộ môn CNFM – Đại học Công nghệ 48 NguyÔn V¨n Vþ † kiểm thử so sánh (comparision testing) còn được gọi là kiểm thử dựa vào nhau (back-to- back testing): † Khi triển khai nhiều bản phần mềm từ cùng 1 đặc tả. Kiểm thử hộp đen cho các sản phẩm này được thực hiện với cùng ca kiểm thử & cùng các dữ liệu vào. † So sánh các kết quả thu được: nếu có khác biệt nghĩa là có sai trong một sản phẩm nào đó! c. Kiểm thử so sánh 2005 Bộ môn CNFM – Đại học Công nghệ 49 NguyÔn V¨n Vþ † Khái niệm: hệ thời gian thực là hệ thống đáp ứng đúng, chính xác các sự kiện của môi trường † Mô hình chung d. Kiểm thử hệ thời gian thực - Kịp thời - Chính xác điều phối đáp ứng Bộ công tác sự kiện Phản hồi điều khiển dữ liệu vào xử lý dữ liệu - Tiếp nhận kịp thời - Chuyển dạng DL - Sắp thứ tự truyền - Xử lý nhanh - Phối hợp các bộ công tác - Đáp ứng kịp thời Cảm biến 2005 Bộ môn CNFM – Đại học Công nghệ 50 NguyÔn V¨n Vþ † Rất khó khăn & kết quả chưa nhiều . † Chiến lược kiểm thử 4 bước: 1. kiểm thử tác vụ: kiểm thử từng tác vụ một cách độc lập với nhau (kt:hộp trắng và hộp đen).Nó cho phép: • phát hiện sai về logic & chức năng. • chưa phát hiện sai về thời gian & ứng xử. 2. Kiểm thử ứng xử: a. Sử dụng công cụ CASE tạo mô hình hệ thống để mô phỏng ứng xử, xem ứng xử của nó như hậu quả của sự kiện từ ngoài. Dùng kết quả hoạt động phân tích