Chương 2: Các giai đoạn cuối cùng của thiết kế nhúng : Thực hiện và Kiểm tra
2.2 Đảm bảo chất lượng và kiểm tra thiết kế
Trong các mục tiêu của việc kiểm tra và đảm bảo chất lượng của hệ thống là tìm ra lỗi trong thiết kế và theo dõi xem lỗi đã được sửa chưa. Đảm bảo chất lượng và kiểm tra tương tự như gỡ lỗi, được thảo luận trước đó trong chương này, ngoại trừ mục tiêu của việc gỡ lỗi là để sửa các lỗi đã phát hiện. Sự khác biệt chính khác giữa gỡ lỗi và kiểm tra hệ thống là việc gỡ lỗi thường xảy ra khi nhà phát triển gặp sự cố khi cố gắng hoàn thành một phần của thiết kế và sau đó là kiểm tra để vượt qua bản sửa lỗi (nghĩa là kiểm tra chỉ để đảm bảo hệ thống hoạt động tối thiểu trong các trường hợp bình thường). Mặt khác,với thử nghiệm các lỗi được phát hiện do cố gắng phá vỡ hệ thống, bao gồm cả thử nghiệm để vượt qua và thử nghiệm để thất bại, nơi các điểm yếu trong hệ thống được thăm dị.
Trong q trình thử nghiệm, các lỗi thường xuất phát từ việc hệ thống không tuân thủ các đặc điểm kiến trúc nghĩa là, hoạt động theo cách mà nó khơng nên theo tài liệu, không hoạt động theo cách cách nó phải theo tài liệu, hoạt động theo cách không được đề cập trong tài liệu hoặc khơng có khả năng kiểm tra hệ thống. Các loại lỗi gặp phải trong thử nghiệm phụ thuộc vào loại thử nghiệm đang được thực hiện. Nói chung, các kỹ thuật thử nghiệm thuộc một trong bốn mơ hình: thử nghiệm hộp đen tĩnh, thử nghiệm hộp trắng tĩnh, thử nghiệm hộp đen động hoặc thử nghiệm hộp trắng động (xem ma trận trong Hình 2-9). Kiểm tra hộp đen xảy ra với người kiểm tra khơng có khả năng hiển thị các hoạt động bên trong của hệ thống (khơng có sơ đồ, khơng có mã nguồn,...). Kiểm tra hộp đen dựa trên tài liệu yêu cầu sản phẩm chung, trái ngược với kiểm tra hộp trắng (còn được gọi là kiểm tra hộp trong hoặc hộp kính), trong đó người kiểm tra có quyền truy cập vào mã nguồn, sơ đồ,... Thử nghiệm tĩnh được thực hiện khi hệ thống không chạy, trong khi thử nghiệm động được thực hiện khi hệ thống đang chạy.
Thử nghiệm với hộp đen Thử nghiệm với hộp trắng Thử nghiệm
tĩnh
Kiểm tra các thông số kĩ thuật của sản phẩm bằng cách: 1. tìm kiếm các vấn đề cơ bản, sơ suất, thiếu sót ở mức độ cao (tức là coi như mình lầ khách hàng, nghiên cứu các hướng dẫn/tiêu chuẩn hiện có, xem xét và kiểm tra phần mềm tương tự, v.v.).
2. kiểm tra đặc điểm kỹ thuật cấp thấp bằng cách đảm bảo tính đầy đủ, chính xác, độ chính xác, tính nhất quán, mức độ liên quan, tính khả thi,… Quy trình xem xét phần cứng và mã một cách có phương pháp để tìm ra lỗi mà khơng cần thực thi.
Thử nghiệm động
Yêu cầu xác định phần mềm nào và
phần cứng bao gồm:
• kiểm tra dữ liệu, kiểm tra thông tin về đầu vào và đầu ra của người dùng
Kiểm tra hệ thống đang chạy trong khi xem mã, sơ đồ, v.v.
Trực tiếp kiểm tra mức thấp và mức cao
dựa trên kiến thức hoạt động chi tiết,
• kiểm tra điều kiện ranh giới,
đó là truy cập các biến và kết xuất bộ nhớ. kiểm tra các tình huống ở cạnh
các giới hạn hoạt động theo kế hoạch của phần mềm
• kiểm tra ranh giới nội bộ, đó là
thử nghiệm lũy thừa của hai, bảng ASCII
Tìm kiếm lỗi tham chiếu dữ liệu, dữ liệu
lỗi khai báo, lỗi tính tốn, lỗi so sánh, lỗi luồng điều khiển, lỗi tham số chương trình con, lỗi I/O,... • kiểm tra đầu vào, kiểm tra dữ
liệu trống, dữ liệu khơng hợp lệ • kiểm tra trạng thái, là kiểm tra các chế độ và chuyển đổi giữa các chế độ mà phần mềm đang thực hiện với các biến trạng thái tức là, điều kiện tương tranh, thử nghiệm lặp lại (lý do chính là phát hiện rị rỉ bộ nhớ), ứng suất(đói phần mềm = thấp bộ nhớ, mạng chậm cpu chậm), tải (phần mềm nguồn cấp dữ liệu = kết nối nhiều thiết bị ngoại vi, xử lý lượng lớn dữ liệu, web máy chủ có nhiều máy khách truy cập,..).
Hình 12-10: Ma trận mơ hình kiểm tra
Trong mỗi mơ hình (được hiển thị trong Hình 12-10), thử nghiệm có thể được chia nhỏ hơn nữa để bao gồm thử nghiệm đơn vị / mô-đun (thử nghiệm gia tăng các phần tử riêng lẻ trong hệ thống), thử nghiệm tính tương thích (thử nghiệm xem
phần tử đó khơng gây ra sự cố với các phần tử khác trong hệ thống), thử nghiệm tích hợp (thử nghiệm gia tăng các phần tử tích hợp), thử nghiệm hệ thống (thử nghiệm toàn bộ hệ thống nhúng với tất cả các phần tử được tích hợp), thử nghiệm hồi quy (chạy lại các kiểm tra đã vượt qua trước đó sau khi sửa đổi hệ thống) và thử nghiệm sản xuất (thử nghiệm để đảm bảo rằng việc sản xuất hệ thống không tạo ra lỗi).
Từ các thử nghiệm này, tập hợp các trường hợp thử nghiệm hiệu quả có thể được rút ra để xác minh rằng một hệ thống hoặc cấp độ đáp ứng các thông số kỹ thuật kiến trúc, cũng như xác nhận rằng phần tử đó hoặc hệ thống đáp ứng các yêu cầu thực tế, có thể đã hoặc chưa được phản ánh một cách chính xác hoặc hồn toàn trong tài liệu. Khi các trường hợp thử nghiệm đã được hoàn thành và các thử nghiệm được chạy, cách xử lý kết quả có thể khác nhau tùy thuộc vào tổ chức, nhưng thông thường khác nhau giữa các trường hợp khơng chính thức, nơi thơng tin được trao đổi mà không cần tuân theo bất kỳ quy trình cụ thể nào và đánh giá thiết kế chính thức hoặc đánh giá đồng cấp nơi các nhà phát triển đồng nghiệp trao đổi các yếu tố để kiểm tra, hướng dẫn nơi kỹ sư chịu trách nhiệm chính thức xem qua sơ đồ và mã nguồn, kiểm tra khi ai đó khơng phải là kỹ sư chịu trách nhiệm thực hiện bước này. Các phương pháp và mẫu thử nghiệm cụ thể cho các trường hợp thử nghiệm, cũng như tồn bộ quy trình thử nghiệm, đã được xác định trong một số tiêu chuẩn thử nghiệm và đảm bảo chất lượng phổ biến trong ngành, bao gồm tiêu chuẩn Đảm bảo chất lượng ISO9000, Mơ hình trưởng thành (CMM) và chuẩn bị ANSI/IEEE 829, Chạy và Hoàn thành Các tiêu chuẩn kiểm tra.
Cuối cùng, cũng như gỡ lỗi, có rất nhiều cơng cụ tự động hóa và kiểm tra cũng như cơng nghệ kỹ thuật có thể hộ trợ tốc độ, hiệu quả và độ chính xác của việc kiểm tra các yếu tố khác nhau, bao gồm các công cụ tải, công cụ ứng suất, bộ phun nhiễu, bộ tạo nhiễu, cơng cụ phân tích, macro, ghi và phát lại, và macro được lập trình bao gồm các công cụ được liệt kê trong bảng 2-1.
Lời khuyên thực tế
Các sửa đổi pháp lý tiềm năng (ở Hoa Kỳ) KHÔNG thử nghiệm
Luật của Hoa Kỳ về trách nhiệm sản phẩm được coi là rất nghiêm ngặt, và khuyến nghị rằng những chịu trách nhiệm về việc đảm bảo chất lượng và kiểm tra hệ thống nên được đào tạo về luật trách nhiệm sản phẩm để nhận biết khi nào sử dụng luật để đảm bảo một lỗi nghiêm trọng đã được khắc phục và khi nào thì nhận rằng một lỗi có thể gây ra trách nhiện pháp lý nghiêm trọng cho tổ chức.
Các luật chung mà người tiêu dùng có thể kiện về các vấn đề sản phẩm là: • Vi phạm Hợp đồng (nghĩa là nếu các bản sửa lỗi được nêu trong hợp đồng không được đưa ra kịp thời)
• Vi phạm bảo hành và bảo đảm ngầm định (nghĩa là cung cấp hệ thống mà không có các tính năng đã hứa)
• Trách nhiệm pháp lý nghiêm ngặt và sơ suất đối với thương tích cá nhân hoặc thiệt hại đối với tài sản (tức là do lỗi gây ra thương tích hoặc tử vong cho người dùng)
• Sơ suất (tức là khách hàng mua sản phẩm bị lỗi)
• Khai báo sai và gian lận (tức là sản phẩm được phát hành và bán không đáp ứng được các quyền sở hữu như quảng cáo, dù cố ý hay vô ý)
Hãy nhớ là, các luật này áp dụng cho dù “sản phẩm” của bạn có phải là dịch vụ tư vấn nhúng, công cụ nhúng, thiết bị nhúng thực tế hay phần mềm/phần cứng có thể được tích hợp vào thiết bị.
- Dựa trên chương “Hậu quả pháp lý của phần mềm bị lỗi”của Cem Kaner - Kiểm tra phần mềm máy tính. 1999