Tin tức về PCB - Tìm lỗi phần mềm trong tiến trình thiết kế PCB

Bài báo này sẽ giới thiệu làm thế nào để tránh những lỗi ẩn nhưng phổ biến, và sẽ áp dụng nhiều kỹ thuật để giúp kỹ sư tìm lỗi ẩn trong phần mềm bản sao PCB. Phần lớn các dự án phát triển phần mềm dựa trên một sự kết hợp Kiểm tra mã, kiểm tra cấu trúc và kiểm tra chức năng để xác định thiếu sót phần mềm. Mặc dù kỹ thuật truyền thống này rất quan trọng và có thể tìm thấy nhiều vấn đề về phần mềm, nhưng chúng không thể phát hiện nhiều lỗi thông thường trong hệ thống phức tạp ngày nay.

Xét nghiệm cấu trúc hay thử nghiệm hộp trắng có thể tìm ra logic, Dòng điều khiển, Lỗi tính toán và dữ liệu trong mã. This test requires a complete overview of the internal workings of the software (hence the term "white box" or "glass box") in order to understand the details of the software structure. Nó kiểm tra mọi biểu hiện, thao tác toán, nhập và xuất. Nhờ có rất nhiều chi tiết cần kiểm tra, kiểm tra cấu trúc kiểm tra từng phần mềm một, thường là hàm hay hạng.
Báo cáo mật mã cũng dùng cùng các kỹ thuật phức tạp như các khiếm khuyết trong ứng biến và các vấn đề tiềm năng.. Thử hộp trắng, thông qua được thực hiện cho mỗi đơn vị của phần mềm, bởi vì một tiến trình kiểm tra hiệu quả đòi hỏi kiểm tra kỹ lưỡng..
Khác với kiểm tra hộp trắng, thử nghiệm có chức năng hoặc thử nghiệm hộp đen giả sử không có gì được biết về việc sử dụng phần mềm. Thử kết quả do người dùng khống chế.. Ứng dụng thử nghiệm gồm các thủ tục thử nghiệm được viết bởi người thử nghiệm hay phát triển, nó chỉ định sản xuất chương trình dự kiến tương ứng với một bộ nhập chương trình cụ thể.. Sau khi kiểm tra xong, người thử so sánh sản xuất thực tế với sản xuất dự kiến để tìm ra vấn đề. Kiểm tra hộp đen có thể tìm thấy yêu cầu chưa được đáp ứng, vấn đề giao diện, Áp lực, và lỗi trong các chức năng thường dùng nhất của chương trình.
Mặc dù kết hợp các công nghệ này có thể tìm thấy hầu hết lỗi ẩn trong một chương trình phần lớn phần mềm, cũng có giới hạn. Xét nghiệm mã hóa và thử nghiệm hộp trắng chỉ nhắm vào một phần nhỏ của mã vào một thời điểm, phớt lờ phần còn lại của hệ thống. Kiểm tra hộp đen thường xử lý toàn bộ hệ thống, Bỏ qua chi tiết tiến hành. Một số vấn đề quan trọng chỉ có thể được phát hiện bằng cách tập trung vào chi tiết giao tiếp của chúng trong toàn bộ hệ thống; Các phương pháp truyền thống không thể xác định chắc chắn.. Phần mềm phải được kiểm tra to àn bộ để tìm ra nguyên nhân cụ thể của vấn đề cụ thể.. Vì thường thì không thể phân tích kỹ lưỡng mọi chi tiết trong chương trình và giao tiếp với mọi phần khác của mật mã., Phân tích nên hướng tới các khía cạnh cụ thể của chương trình mà rõ ràng gây ra các vấn đề..
This article will explore three potential problem areas:
* stack overflow
* Race conditions
* deadlock
Readers can read the second part of this article online, which will explore the following issues:
* Timing issues
* Reentrant conditions
All of the above problems are quite common in systems that use multi-task real-time design technology.
stack overflow
The processor uses the stack to store temporary variables, Chuyển tham số cho chức năng được gọi, lưu lại sợi chỉ "bang", và vân vân.. If the system does not use virtual memory (in other words, it cannot transfer memory pages to disk to free up memory space for other uses), chất liệu sẽ được định sẵn theo kích thước của sản phẩm khi nó rời nhà máy. Nếu vì lý do nào đó chồng đĩa ra ngoài phạm vi phân bổ bởi lập trình viên, chương trình sẽ trở nên mơ hồ. Sự bất ổn này có thể gây ra lỗi hệ thống. Do đó, Nó cần thiết để đảm bảo rằng hệ thống có thể phân số lượng cây trong trường hợp xấu nhất.
Cách duy nhất để đảm bảo rằng một chồng tràn không bao giờ xảy ra là phân tích mật mã, xác định mức độ sử dụng chồng tối đa của chương trình dưới nhiều điều kiện có thể., rồi kiểm tra xem có phân đủ chồng không. Không có khả năng thử nghiệm sẽ kích hoạt một sự kết hợp cụ thể của các nhập tức thời và gây ra kịch bản tồi tệ nhất trong hệ thống..
The concept of stack depth analysis is relatively simple:
1. Tạo một cây gọi cho mỗi sợi chỉ độc lập.
Name. Chọn cách sử dụng chồng của mỗi hàm trong cây gọi.
Comment. Kiểm tra mỗi cây gọi để xác định đường dẫn cuộc gọi từ gốc cây tới'lá'bên ngoài đòi hỏi chồng chất lớn nhất.
4. Thêm tổng dụng tối đa của mỗi cây chỉ điểm độc lập.
Comment. Determine the maximum stack usage of each interrupt service routine (ISR) in each interrupt priority level and calculate the total. Tuy, nếu bản thân ISR không có một chồng và dùng chất của sợi chỉ bị ngắt., Số cây tối đa dùng bởi ISR nên được thêm vào chồng của mỗi sợi..
Comment. Cho mỗi cấp cao, thêm số cây được dùng để lưu trạng thái xử lý khi ngắt quãng xảy ra.
7. Nếu dùng RTOS, add the maximum number of stacks required for the internal use of the RTOS itself (different from the system call caused by the application code, which is included in step 2).
Thêm nữa., có hai điều quan trọng cần xem xét. Đầu, một cái cây gọi chỉ được chế tạo từ mật mã nguồn ngôn ngữ cấp cao có thể chưa hoàn tất. Phần lớn máy soạn thảo dùng thư viện chạy thời gian để tối ưu các công việc vi tính chung, như đa số và phân chia các số nguyên, thao tác điểm nổi, Comment. Những cuộc gọi này chỉ được nhìn thấy trong ngôn ngữ tập hợp do người soạn thảo tạo ra. Các chức năng thư viện thời gian có thể sử dụng rất nhiều không gian chồng, và chúng phải được đưa vào cuộc phân tích. If you are using the C++ language, all the following types of functions (methods) must also be included in the call tree: structurers, phá, quá tải, sao chép, và chức năng chuyển đổi. Tất cả các hàm nhọn phải được phân tích, và các chức năng họ gọi được cung cấp trong phân tích.