PCB 기술 - PCB 설계 과정에서 소프트웨어 결함을 발견하는 방법

PCB 설계 과정에서 숨겨져 있지만 일반적인 소프트웨어 결함 오류를 방지하는 방법과 엔지니어가 PCB 복제 보드(www.pcbwork.net) 소프트웨어에서 숨겨진 오류를 찾을 수 있도록 돕는 몇 가지 기술을 소개합니다.대부분의 소프트웨어 개발 프로젝트는 소프트웨어 결함을 식별하기 위해 코드 검사, 구조 테스트 및 기능 테스트의 조합에 의존합니다.이러한 기존 기술은 대부분의 소프트웨어 문제를 해결할 수 있는 중요한 기술이지만 오늘날의 복잡한 시스템에서 자주 발생하는 오류를 감지할 수는 없습니다.

패브릭 테스트 또는 화이트박스 테스트는 코드의 논리, 흐름 제어, 계산 및 데이터 오류를 효과적으로 발견할 수 있습니다.이 테스트는 소프트웨어 구조의 세부 사항을 이해하기 위해 소프트웨어의 내부 작업을 개괄적으로 설명해야 합니다. 따라서 이름은 "흰색 상자" 또는 "유리 상자"입니다.각 조건 표현식, 수학 연산, 입력 및 출력을 검사합니다.많은 세부 사항을 테스트해야 하기 때문에, 구조 테스트는 한 번에 하나의 소프트웨어 단위를 검사하는데, 보통 하나의 함수나 클래스이다.

코드 검토는 결함 및 잠재적 문제 발견을 실현하는 것과 동일한 복잡한 기술도 사용합니다.화이트박스 테스트와 마찬가지로 일반적으로 소프트웨어의 각 유닛을 검토합니다. 효과적인 검토 과정은 집중적이고 상세한 검사가 필요하기 때문입니다.

검토 및 화이트박스 테스트와 달리 기능 테스트 또는 블랙박스 테스트는 소프트웨어의 구현에 대해 전혀 알지 못한다고 가정합니다.제어된 입력으로 제어되는 출력을 테스트합니다.기능 테스트는 테스트 또는 개발자가 작성한 테스트 프로그램으로 구성됩니다.특정 프로그램 입력 세트에 해당하는 예상 프로그램 출력을 지정합니다.테스트 실행 후 테스트 인력은 실제 출력과 예상 출력을 비교하여 문제점을 파악합니다.블랙박스 테스트는 프로그램에서 가장 많이 사용되는 기능 중 충족되지 않은 요구 사항, 인터페이스 문제, 성능 문제 및 오류를 효과적으로 발견할 수 있습니다.

이러한 기술을 결합하면 특정 소프트웨어 프로그램에 숨겨진 대부분의 오류를 발견할 수 있지만 한계가 있습니다.코드 검토 및 화이트박스 테스트는 한 번에 코드의 작은 부분만 대상으로 하고 시스템의 나머지 부분은 무시합니다.블랙박스 테스트는 일반적으로 시스템을 전체로 간주하고 세부 사항을 무시합니다.일부 중요한 문제는 전체 시스템에서 상호 작용하는 세부 사항에만 초점을 맞추어 발견할 수 있습니다.전통적인 방법으로는 이러한 문제를 확실하게 식별할 수 없다.특정 문제의 구체적인 원인을 파악하기 위해 소프트웨어 시스템을 전체적으로 점검해야 합니다.일반적으로 프로그램의 모든 세부 사항과 코드의 다른 모든 부분과의 상호 작용을 철저하게 분석할 수 없기 때문에 분석은 문제를 초래할 수 있는 것으로 알려진 프로그램의 특정 측면을 대상으로 해야 한다.

이 문서에서는 다음과 같은 세 가지 잠재적 문제 영역을 다룹니다.

* 스택 오버플로우

* 경쟁 제품

* 고정 잠금

독자는 다음 문제를 다루는 이 문서의 두 번째 부분을 온라인으로 읽을 수 있습니다.

* 시간 문제

* 재진입 조건

이 모든 문제는 멀티태스킹 실시간 설계 기술을 사용하는 시스템에서 흔히 볼 수 있습니다.

스택 오버플로우

프로세서는 스택을 사용하여 임시 변수를 저장하고, 호출된 함수에 매개 변수를 전달하고, 스레드 "상태" 를 저장합니다. 시스템에서 가상 메모리를 사용하지 않는 경우 (즉, 메모리 페이지를 디스크로 이동하여 메모리 공간을 다른 용도로 사용할 수 없음) 제품이 출고될 때 스택은 제품 크기로 고정됩니다.어떤 이유로 스택이 프로그래머가 할당한 범위를 벗어나면 프로그램이 불확실해집니다.이런 불안정은 심각한 시스템 고장을 초래할 수 있다.따라서 시스템이 최악의 경우 충분한 스택을 할당할 수 있도록 하는 것이 중요합니다.

스택 오버플로가 발생하지 않도록 하는 유일한 방법은 코드를 분석하고 가능한 모든 상황에서 프로그램의 최대 스택 사용량을 확인한 다음 충분한 스택이 할당되었는지 확인하는 것입니다.이 테스트는 순간 입력의 특정 조합을 트리거하여 시스템에 최악의 상황을 초래할 가능성이 거의 없습니다.

스택 심층 분석의 개념은 비교적 간단하다.

1. 각 개별 스레드에 대해 호출 트리를 생성합니다.

2. 호출 트리의 각 함수에 대한 스택 사용을 결정합니다.

3. 각 호출 트리를 검사하여 나무의 뿌리에서 외부 "잎" 까지의 호출 경로에 가장 많은 스택이 필요한지 확인합니다.

4. 각 개별 스레드 호출 트리의 최대 스택 사용량을 추가합니다.

5. 각 인터럽트 우선 순위에서 각 인터럽트 서비스 루틴(ISR)의 최대 스택 사용량을 결정하고 총 스택 수를 계산합니다.그러나 ISR 자체에 스택이 없고 스레드가 중단된 스택을 사용하는 경우 ISR에서 사용하는 최대 스택 수를 각 스레드의 스택에 추가해야 합니다.

6. PCB 레이아웃 및 설계의 각 우선 순위에 대해 중단 발생 시 프로세서 상태를 저장하는 데 사용되는 스택 수를 추가합니다.

7. RTOS를 사용하고 있는 경우 RTOS 자체의 내부 사용에 필요한 최대 스택 수를 추가합니다(2단계에 포함된 응용 프로그램 코드로 인한 시스템 호출과는 다름).

이 밖에 두 가지 중요한 일을 고려해야 한다.우선 고급 언어 소스 코드로만 구성된 호출 트리가 불완전할 수 있습니다.대부분의 컴파일러는 런타임 라이브러리를 사용하여 큰 값 정수의 곱셈과 나눗셈, 부동 소수점 연산 등 일반적인 컴퓨팅 작업을 최적화합니다. 이러한 호출은 컴파일러가 생성하는 어셈블리 언어에서만 볼 수 있습니다.라이브러리 함수를 실행하는 것 자체는 많은 스택 공간을 차지할 수 있으며 분석에 포함해야 합니다.C++ 언어를 사용하는 경우 호출 트리에는 구조체, 분석 함수, 연산자 다시 로드, 구조 복사 및 변환 함수 등의 모든 유형의 함수 (메서드) 도 포함되어야 합니다.모든 함수 포인터도 해석해야 하며 호출된 함수는 분석에 포함됩니다.