온전성 검사

Sanity check

건전성 검사 또는 건전성 검사는 청구 또는 계산 결과가 사실일 수 있는지 여부를 신속하게 평가하기 위한 기본 시험이다. 생산된 물질이 이성적인지(물질의 창조자가 이성적으로 생각하고, 온전함을 적용하고 있었는지를 확인하는 간단한 점검이다. 분별력 테스트의 요점은 명백한 허위 결과의 특정 계층을 배제하는 것이지 가능한 모든 오류를 포착하는 것이 아니다. 테스트를 수행하기 위해 점근법 또는 개발 후 계산을 점검할 수 있다. 초기 건전성 테스트를 수행할 때의 장점은 기본 기능을 신속하게 평가할 수 있다는 것이다.

예를 들어, 산술에서, 9를 곱할 때, 9를 곱할 때, 결과의 자릿수 합계가 9로 나누어질 수 있는지 검증하기 위해 9를 곱한 규칙을 사용한다. 즉, 모든 곱셈 오류를 잡는 것은 아니지만, 가능한 많은 오류를 발견하는 빠르고 간단한 방법이다.

컴퓨터 과학에서 건전성 시험은 시스템이나 방법론의 일부가 예상대로 대략적으로 작동하도록 보장하기 위해 컴퓨터 프로그램, 시스템, 계산 또는 기타 분석의 기능성을 아주 간략하게 실행하는 것이다. 이것은 종종 더 철저한 시험 전에 일어난다.

수학적

건전성 테스트는 다양한 크기의 순서 및 교차 확인 수학 계산에 적용되는 기타 간단한 규칙 장치들을 참조할 수 있다. 예를 들면 다음과 같다.

  • 만약 738을 제곱하려고 하고 54,464를 계산한다면, 빠른 분별력 검사를 통해 이 결과는 사실일 수 없다는 것을 알 수 있을 것이다. 700 < 738, 그러나 7002 = 72 × 1002 = 490,000 > 54,464를 생각해 보자. 양의 정수를 제곱하면 불평등이 유지되기 때문에 결과는 참이 될 수 없으며, 따라서 계산된 결과는 부정확하다. 정답은 7382 = 544,644로 54,464보다 10배 이상 높다.
  • 곱셈에서 918 × 155는 3으로 나누어지므로 142,135가 아니라 142,135이다(자릿수는 3의 배수가 아니라 16까지 더해진다). 또한 제품은 끝자리의 제품과 같은 숫자로 끝나야 하는데, 142,135는 "40"처럼 "0"으로 끝나지 않고, 정답은: 918 × 155 = 142,290이다. 훨씬 더 빠른 점검은 짝수와 홀수의 곱이 짝수인 반면 142,135는 홀수라는 것이다.

물리적인

  • 자동차의 출력은 700 kJ가 될 수 없다. 단위는 전력(단위 시간 당 에너지)이 아니라 에너지의 척도이기 때문이다. 이것은 치수 분석의 기본적인 적용이다.
  • 물리적 특성을 결정할 때, 알려진 물질이나 유사한 물질과 비교할 때, 종종 결과가 타당한지 아닌지에 대한 통찰력을 제공할 것이다. 예를 들어 대부분의 금속은 물에 잠기므로 대부분의 금속의 밀도는 물의 밀도(~1000kg/m3)보다 커야 한다.
  • 페르미 추정치는 종종 기대값의 크기에 대한 통찰력을 제공할 것이다.

소프트웨어 개발

소프트웨어 개발에서, 온전성 시험("빠르고 넓고 얕은 시험"을 제공하는 소프트웨어 시험의 한 형태)[1]은 애플리케이션 기능성의 서브셋의 결과를 평가하여 전체 애플리케이션의 추가 시험을 진행하는 것이 가능하고 합리적인지 여부를 결정한다.[2] 두 용어가 추가 시험을 계속하는 것이 가능한지 그리고 합리적인지를 결정하는 시험을 나타내는 한, 건전성 시험은 때때로[3] 연기 시험과 교환하여 사용될 수 있다. 반면에, 매연 테스트는 추가 테스트를 진행하기 전에 프로그램의 가장 중요한 기능이 작동하는지 여부를 확인하는 비배출 테스트라는 구별이 있는 반면, 온전한 테스트는 특정 버그 수정과 같은 특정 기능이 광범위한 기능을 테스트하지 않고 예상대로 작동하는지 여부를 가리킨다.소프트웨어의 반복.[citation needed] 즉, 건전성 테스트는 코드 변경의 의도된 결과가 제대로 작동하는지 여부를 판단하는 반면 매연 테스트는 그 과정에서 다른 중요한 결과가 깨지지 않았는지 확인하는 것이다. 건전성 테스트와 매연 테스트는 응용프로그램에 결함이 너무 많아 더 엄격한 QA 테스트를 수행할 가치가 있는지 여부를 신속하게 확인함으로써 시간과 노력을 낭비하지 않지만 개발자 디버깅이 더 필요하다.

건전성 테스트 그룹은 종종 개발 코드를 테스트 또는 트렁크 버전 제어 분기로 병합하기 전에 기능, 라이브러리 또는 애플리케이션의 자동화된 단위 테스트를 위해 함께 묶이거나,[4][5] 자동화된 건물을 위해 또는 지속적인 통합과 지속적인 구축을 위해 함께 묶인다.[6]

건전성 테스트의 또 다른 일반적인 용도는 프로그램 코드 내에서, 대개 기능 또는 반환에 대한 인수에 따라 수행되는 검사를 표시하여 정답이 맞는 것으로 가정할 수 있는지 확인하는 것이다. 루틴이 복잡할수록 대응을 점검하는 것이 중요하다. 사소한 경우는 함수의 반환 값이 성패를 나타내는지 여부를 확인하고 따라서 실패 시 추가 처리를 중단하는 것이다. 이 수익가치는 사실 그 자체로 제정신 점검의 결과인 경우가 많다. 예를 들어, 함수가 파일을 열고, 쓰고, 닫으려고 시도했다면, 건전성 검사를 사용하여 프로그래머가 종종 무시하는 건전성 검사인 이러한 동작 중 어느 하나에도 실패하지 않았는지 확인할 수 있다.[7]

이러한 종류의 건전성 점검은 개발 중에 디버깅을 위해 사용될 수 있으며 소프트웨어 런타임 오류를 해결하는 데에도 도움이 될 수 있다. 예를 들어, 은행 계좌 관리 애플리케이션에서, 인출이 마이너스(이상적으로 건전하지 않은) 계좌를 허용하는 것보다 총 계좌 잔액보다 더 많은 돈을 요구하면 건전성 검사가 실패하게 된다. 또 다른 건전성 테스트는 예치금이나 구매금액이 과거 데이터에 의해 확립된 패턴에 해당한다는 것이다. 예를 들어, 카드 소지자가 방문한 적이 없는 대규모 구매 거래나 해외에서의 현금 인출은 확인을 위해 플래그가 표시될 수 있다.

또한, 호환되는 운영 체제와 링크 라이브러리와 같은 모든 종속성이 충족되는지 확인하기 위해 새로운 컴퓨팅 환경에 안정적이고 생산적인 소프트웨어 코드를 설치할 때 건전성 검사를 수행한다. 컴퓨팅 환경이 온전성 검사를 모두 통과했을 때, 설치 프로그램이 합리적인 성공을 기대하며 진행되도록 하는 것은 온전한 환경이라고 알려져 있다.

"Hello, World!" 프로그램은 유사한 방식으로 개발 환경을 위한 온전한 테스트로 종종 사용된다. 일련의 단위 테스트를 실행하는 복잡한 스크립트가 아니라, 이 간단한 프로그램이 컴파일이나 실행에 실패하면 지원 환경에 어떤 코드도 컴파일이나 실행을 방해하는 구성 문제가 있음을 증명한다. 그러나 "Hello world"가 실행된다면, 다른 프로그램과 관련하여 경험하는 모든 문제는 환경보다는 그 응용 프로그램의 코드의 오류에 기인할 수 있다.

참고 항목

참조

  1. ^ Fecko, Mariusz A.; Lott, Christopher M. (October 2002). "Lessons learned from automating tests for an operations support system" (PDF). Software: Practice and Experience. 32 (15): 1485–1506. doi:10.1002/spe.491. S2CID 16820529. Archived from the original (PDF) on 17 July 2003.
  2. ^ Sammi, Rabia; Masood, Iram; Jabeen, Shunaila (2011). Zain, Jasni Mohamad; Wan Mohd, Wan Maseri bt; El-Qawasmeh, Eyas (eds.). "A Framework to Assure the Quality of Sanity Check Process". Software Engineering and Computer Systems. Communications in Computer and Information Science. Berlin, Heidelberg: Springer. 181: 143–150. doi:10.1007/978-3-642-22203-0_13. ISBN 978-3-642-22203-0.
  3. ^ ISTQB® 국제 소프트웨어 테스트 검증 위원회® 소프트웨어 테스트 검증 체계용 용어집, ISTQB 용어집 국제 소프트웨어 테스트 검증 위원회
  4. ^ http://webhotel4.ruc.dk/~http://webhotel4.ruc.dk/j/리서치/리서치/freebsd.pdf
  5. ^ 하산, A. E.와 장, K. 2006. 의사결정 트리를 사용하여 빌드의 인증 결과 예측 제21회 IEEE/ACM 국제 자동화 소프트웨어 엔지니어링 회의의 진행 중(2006년 9월 18일~22일)에서. 자동 소프트웨어 엔지니어링. IEEE 컴퓨터 협회, 워싱턴 DC, 189–198.
  6. ^ http://jitm.ubalt.edu/XXIX-2/article4.pdf
  7. ^ Darwin, Ian F. (January 1991). Checking C programs with lint (1st ed., with minor revisions. ed.). Newton, Mass.: O'Reilly & Associates. p. 19. ISBN 0-937175-30-7. Retrieved 7 October 2014. A common programming habit is to ignore the return value from fprintf(stderr, ...