12.

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 quá 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 12-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
Kiểm tra các thông số kĩ thuật Quy trình xem xét phần cứng và
Thử nghiệm của sản phẩm bằng cách: mã một cách có phương pháp để
tĩnh 1. tìm kiếm các vấn đề cơ bản, tìm ra lỗi mà không cần thực thi.
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,…
 Yêu cầu xác định phần mềm Kiểm tra hệ thống đang chạy trong
Thử nghiệm nào và khi xem mã, sơ đồ, v.v.
động phần cứng bao gồm: Trực tiếp kiểm tra mức thấp và
• kiểm tra dữ liệu, kiểm tra mức cao
thông tin về đầu vào và đầu ra dựa trên kiến thức hoạt động chi
của người dùng tiết,
• kiểm tra điều kiện ranh giới, truy cập các biến và kết xuất bộ
đó là nhớ.
kiểm tra các tình huống ở cạnh Tìm kiếm lỗi tham chiếu dữ liệu,
các giới hạn hoạt động theo kế dữ liệu
hoạch của phần mềm lỗi khai báo, lỗi tính toán, lỗi so sánh,
• kiểm tra ranh giới nội bộ, đó lỗi luồng điều khiển, lỗi tham số
là chương trình con, lỗi I/O,...
thử nghiệm lũy thừa của hai,
bảng ASCII
• 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 hoà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ư toà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 12-1.
 Lời khuyên trong thế giới thực

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

12.3 Kết luận: Duy trì hệ thống nhúng và hơn thế nữa

Chương này giới thiệu một số yêu cầu chính đằng sau việc triển khai một hệ thống
nhúng thiết kế, chẳng hạn như hiểu các công cụ phát triển tiện ích, dịch và gỡ lỗi. Các
công cụ bao gồm IDE và CAD, cũng như trình thông dịch, trình biên dịch và trình liên
kết. Một loạt các công cụ gỡ lỗi hữu ích cho cả gỡ lỗi và kiểm tra các thiết kế nhúng, từ
ICE phần cứng, trình giả lập ROM và máy hiện sóng đến trình gỡ lỗi phần mềm, trình
định cấu hình và màn hình. Chương này cũng thảo luận về những gì có thể được mong
đợi khi khởi động một bo mạch mới, cung cấp một vài ví dụ thực tế về mã khởi động hệ
thống.
Cuối cùng, sau khi một thiết bị nhúng đã được triển khai, vẫn có những trách nhiệm điển
hình cần được đáp ứng, chẳng hạn như đào tạo người dùng, hỗ trợ kỹ thuật, cung cấp các
bản cập nhật kỹ thuật, sửa lỗi,... Ví dụ trong trường hợp đào tạo người dùng, tài liệu kiến
trúc có thể được sử dụng tương đối nhanh chóng để làm cơ sở cho các hướng dẫn kỹ
thuật, người dùng và đào tạo. Tài liệu kiến trúc cũng có thể được sử dụng để đánh giá tác
động liên quan đến việc giới thiệu các bản cập nhật (tức là các tính năng mới, sửa lỗi,...)
cho sản phẩm khi sản phẩm đang ở hiện trường, giảm thiểu rủi ro thu hồi hoặc sự cố tốn
kém, hoặc cuộc kiểm tra của các FAE có thể được yêu cầu tại địa điểm của khách hàng.
Trái với suy nghĩ của nhiều người, trách nhiệm của nhóm kỹ sư kéo dài trong suốt vòng
đời của thiết bị và không kết thúc khi hệ thống nhúng đã được triển khai tới đồng ruộng.

Để đảm bảo thành công trong thiết kế hệ thống nhúng, điều quan trọng là phải làm quen
với các giai đoạn thiết kế các hệ thống nhúng, đặc biệt là tầm quan trọng của việc tạo ra
một cấu trúc đầu tiên. Điều này đòi hỏi tất cả các kỹ sư và lập trình viên, bất kể trách
nhiệm và nhiệm vụ của họ là gì, phải có nền tảng kỹ thuật vững chắc bằng cách hiểu ở
cấp hệ thống tất cả các thành phần chính có thể đi vào thiết kế của bất kỳ hệ thống nhúng
nào. Điều này có nghĩa là các kỹ sư phần cứng hiểu phần mềm và các kỹ sư phần mềm
hiểu phần cứng tại ít nhất là cấp độ hệ thống. Điều quan trọng nữa là các nhà thiết kế có
trách nhiệm phải áp dụng, hoặc đưa ra phương pháp luận đã được thống nhất để triển
khai và kiểm tra hệ thống, sau đó có kỷ luật để tuân theo các quy trình bắt buộc.

Tác giả hy vọng rằng bạn đánh giá cao cách tiếp cận kiến trúc của cuốn sách này, và
nhận thấy nó là một công cụ hữu ích như một phần giới thiệu toàn diện về thế giới của
các hệ thống nhúng thiết kế. Có những yêu cầu và ràng buộc riêng liên quan đến việc
thiết kế một hệ thống nhúng, chẳng hạn như những yêu cầu và ràng buộc được quyết
định bởi chi phí và hiệu suất. Việc tạo ra một kiến trúc giải quyết những yêu cầu này rất
sớm trong một dự án, cho phép nhóm thiết kế giảm thiểu rủi ro. Chỉ vì lý do này, kiến
trúc của một thiết bị nhúng sẽ tiếp tục là một trong những yếu tố quan trọng nhất của bất
kỳ dự án hệ thống nhúng nào.
Chương 12: Các vấn đề

1. Sự khác biệt giữa máy chủ và mục tiêu là gì?

2. Các công cụ phát triển thường thuộc loại cấp cao nào?

3. [T/F] Một IDE được sử dụng trên đích để giao tiếp với hệ thống máy chủ.

4. CAD là gì?

5. Ngoài CAD, những kỹ thuật nào khác được sử dụng để thiết kế các mạch điện phức
tạp?

6. [a] Bộ tiền xử lý là gì?

[b] Cung cấp một ví dụ trong thế giới thực về cách bộ tiền xử lý được sử dụng liên
quan đến ngôn ngữ lập trình.

7. [T/F] Một trình biên dịch có thể nằm trên một máy chủ hoặc một mục tiêu, tùy
thuộc vào ngôn ngữ.

8. Một số tính năng giúp phân biệt nhu cầu biên dịch trong hệ thống nhúng so với trong
các loại hệ thống máy tính khác?

9. [a] Tệp đối tượng là gì?

[b] Sự khác biệt giữa trình tải và trình liên kết là gì?

10. [a] Phiên dịch là gì?

[b] Kể tên ba ngôn ngữ trong thế giới thực yêu cầu thông dịch viên.

11. Một thông dịch viên cư trú trên:

A. vật chủ.

B. mục tiêu và vật chủ.

C. trong một IDE.

D. A và C.

E. Không có điều nào ở trên.

12. [a] Gỡ lỗi là gì?

[b] Các loại công cụ gỡ lỗi chính là gì?

[c] Liệt kê và mô tả bốn ví dụ trong thế giới thực của từng loại công cụ gỡ lỗi.

13. Năm kỹ thuật rẻ nhất để sử dụng trong gỡ lỗi là gì?

14. Mã khởi động là

A. Phần cứng cấp nguồn cho bo mạch.

B. Phần mềm tắt bảng.

C. Phần mềm khởi động bo mạch.

D. Tất cả những điều trên.

E. Không có điều nào ở trên.

15. Sự khác biệt giữa gỡ lỗi và kiểm thử là gì?

16. [a] Liệt kê và xác định bốn mô hình mà các kỹ thuật kiểm thử thuộc loại nào.

[b] Trong mỗi mô hình này, năm loại thử nghiệm có thể xảy ra là gì?

17. [T/F] Thử nghiệm để vượt qua là thử nghiệm để đảm bảo rằng hệ thống hoạt
động ở mức tối thiểu trong các trường hợp bình thường.

18. Sự khác biệt giữa thử nghiệm để vượt qua và thử nghiệm để thất bại?

19. Nêu tên và mô tả bốn lĩnh vực luật chung mà khách hàng có thể kiện về sản
phẩm các vấn đề.

20. [T/F] Sau khi hệ thống nhúng đi vào quá trình sản xuất, công việc của nhóm thiết
kế và phát triển đã hoàn thành.