선형 코드 시퀀스 및 점프
Linear code sequence and jump넓은 의미에서 LCSAJ(Linear Code Sequence and Jump)는 테스트 대상 코드에서 구조 단위를 식별하는 데 사용되는 소프트웨어 분석 방법입니다.주로 동적 소프트웨어 분석을 사용하여 "테스트가 어느 정도면 충분한가?"[1]라는 질문에 대한 답을 얻습니다.동적 소프트웨어 분석은 소프트웨어 테스트 데이터의 품질 및 유효성을 측정하기 위해 사용되며, 여기서 정량화는 테스트 대상 코드의 구조 단위로 수행됩니다.주어진 시험 데이터 세트에 의해 발휘되는 구조 단위를 정량화하는 데 사용될 때 동적 분석은 구조적 포함 범위 분석이라고도 한다.
좁은 의미에서 LCSAJ는 프로그램 코드의 잘 정의된 선형 영역입니다.이런 의미에서 LCSAJ는 JJ 패스라고도 불리며 Jump-to-jump path의 약자입니다.
역사
LCSAJ 분석 방법은 마이클 헤넬 교수가 리버풀 대학의 핵물리학 연구가 [2][3]의존하는 수학적 라이브러리에 대한 품질 평가를 수행하기 위해 고안했다.Hennell 교수는 나중에 Liverpool Data Research Associates(LDRA) 회사를 설립하여 이 작업을 위해 생산된 소프트웨어 테스트베드를 상용화함으로써 LDRA 테스트베드 제품을 만들었습니다.
1976년에 도입된 LCSAJ는[4] 현재 Jump-to-Jump Path(JJ 패스)[5]라고도 불립니다.그것은 또한 리버풀의 바보 같은 약어와 [citation needed]농담에 대한 기여로 불려왔다.
코드 영역으로서의 LCSAJ의 정의와 특징
LCSAJ는 일련의 코드(선형 코드 시퀀스)에 이어서 제어 흐름점프로 구성된 소프트웨어 코드패스 프래그먼트입니다.다음 3가지 [6]항목으로 구성됩니다.
- 실행 가능한 스테이트먼트의 선형 시퀀스의 시작
- 선형 수열의 끝
- 선형 시퀀스의 끝에서 제어 흐름이 전송되는 대상 라인.
(최대) 기본 블록과 달리 LCSAJ는 LCSAJ 중간에 점프(아웃)가 발생할 수 있지만 기본 블록 중간에 허용되지 않기 때문에 서로 오버랩될 수 있습니다.특히 조건부 점프는 겹치는 LCSAJ를 생성한다. 즉, 조건이 거짓으로 평가될 때까지 이어지는 LCSAJ와 조건이 참으로 평가될 때 점프에서 끝나는 LCSAJ가 있다(이 문서의 추가 예는 그러한 발생을 보여준다).1986년의 한 논문에 따르면, LCSAJ는 일반적으로 기본 [7]블록보다 4배 더 컸습니다.
LCSAJ의 정식 정의는 다음과 [8]같이 기본 블록의 관점에서 제공할 수 있습니다.
코드 유닛의 하나 이상의 연속된 번호부 기본블록 p, (p+1) ..., q의 시퀀스는 코드 [유닛]에서 또는 rll(q+1)로 이어지는 제어플로우 점프이며, 여기서 p=1 또는 그 유닛 내의 다른 블록으로부터 p를 블록하기 위한 제어플로우 점프가 존재한다.(이러한 제어 플로우 점프를 할 수 있는 기본 블록을 [LCSAJ] 점프 대상이라고 한다.)
Jorgensen의 2013년 교과서에 따르면, 영국과 ISTQB 문헌 밖에서는 같은 개념을 [9][dubious ]DD-path라고 부른다.
시험효과비
커버리지 분석 메트릭은 테스트 달성 정도를 측정하기 위해 사용됩니다.가장 기본적인 지표는 실행된 문장의 비율인 테스트 효과 비율 1(TER1)[10]입니다.
특히 [11]다음과 같은 상위 수준의 커버리지 메트릭도 생성할 수 있습니다.
이러한 지표는 순수 계층을 충족하며, TER3 = 100% 달성되면 TER2 = 100% 달성되고 TER1 = 100% 달성된다.
TER1과 TER2 메트릭은 모두 1970년대 초반과 1970년대 후반의 세 번째 날짜에 사용되었습니다.TER1 = 100% 달성을 위한 요건은 1992년 [12]MCDC(위험 조건/위험 범위) 추가 요건으로 보완되기 전까지 DO-178 항전 규격에 대해 원래 선택된 수준이었다.더 높은 수준의 TER3 = 100%는 항공우주, 전화 및 [citation needed]은행 업무를 포함한 많은 다른 프로젝트에서 의무화되었습니다.TER3를 사용하는 경우의 실제적인 문제 중 하나는 LCSAJ에 포함된 조건이 모순되어 많은 LCSAJ를 실행할 수 없다는 것입니다.
예
다음 C 코드를 고려합니다.
#실패하다 <stdlib.h> #실패하다 <문자열>h> #실패하다 <math.h> #MAXCOLUMNS 정의 26 #정의 MAXROW 20 #최대 카운트 90의 정의 #ITERATION 750 정의 인트 주된 (무효) { 인트 세어보세요 = 0, 합계[최대 열], 값 = 0; 메모리 세트 (합계, 0, 최대 열 * 크기(인트)); 세어보세요 = 0; 하는 동안에 ( 세어보세요 < > 반복 ) { 값 = 복근(랜드()) % 최대 열; 합계[값] += 1; 한다면 ( 합계[값] > 최대수 ) { 합계[값] = 최대수; } 세어보세요++; } 돌아가다 (0); } 이 코드에서 이 코드에 대한 LCSAJ 트리플의 전체 목록은 다음과 같습니다.
| LCSAJ 번호 | 시작선 | 결승선 | 줄넘기 |
|---|---|---|---|
| 1 | 10 | 17 | 28 |
| 2 | 10 | 21 | 25 |
| 3 | 10 | 26 | 17 |
| 4 | 17 | 17 | 28 |
| 5 | 17 | 21 | 25 |
| 6 | 17 | 26 | 17 |
| 7 | 25 | 26 | 17 |
| 8 | 28 | 28 | −1 |
이 예에서 LCSAJ 트리플로 식별되는 기본 블록이 의사결정 포인트에 걸쳐 있는 것을 알 수 있습니다.이는 LCSAJ를 실행하기 위해 필요한 조건을 반영하고 있습니다.예를 들어 상기 예의 LCSAJ 2에는while조건이 있는 곳(count < ITERATIONS)true로 평가합니다.
코드의 각 행에는 LCSAJ '밀도'가 관련되어 있습니다.예를 들어 17 행은 6개의 고유한 LCSAJ 내에 표시됩니다.즉, LCSAJ 밀도는 6입니다.이것은 코드의 유지보수성을 평가할 때 도움이 됩니다.코드의 행이 변경되는 경우는, 그 변경에 의해서 영향을 받는 LCSAJ 의 수를 나타내는 밀도입니다.
TER3 = 100%의 적용 범위는 사용된 테스트 데이터가 이러한 각 LCSAJ를 한 번 이상 실행할 때 달성된다.
레퍼런스
- ^ M.A. Hennell, D.헤들리와 M.R.Woodward, "Algol 68 프로그램의 테스트 효과 정량화", 1977년 Strathclyde ALGOL 68 회의 진행, 36–41, ISSN 0362-1340
- ^ M. A. Hennell, 수치 소프트웨어의 시험대. {I}. {Fortran}, 컴퓨터 저널 21(4):333-336, @nov, 1978
- ^ M. A. 헤넬과 D.헤들리, 수치 소프트웨어의 실험용 테스트 베드입니다. {II}. {ALGOL 68}, 컴퓨터 저널 22 (1):53-56, @feb, 1979
- ^ M.A. 헤넬, M.R.우드워드와 D.Hedley, "프로그램 분석", 정보처리 서신, 5(5), 페이지 136–140, 1976
- ^ M. R. Woodward, M. A. Hennell, "모든 JJ 경로와 MCDC의 두 제어 흐름 적용 기준 사이의 관계에 대하여", 정보 및 소프트웨어 기술 48(2006) 페이지 433–440
- ^ M.A. Hennell, D.헤들리와 아이제이Riddell, "Assessing a Class of Software Tools", 1984년 3월 제7회 소프트웨어 엔지니어링 국제회의 진행, 266~277. ISSN 0270-5257페이지
- ^ Martyn A. Ould and Charles Unwin, ed. (1986). Testing in Software Development. Cambridge University Press. p. 102. ISBN 978-0-521-33786-1.
- ^ Groenda, Henning (2013). Certifying Software Component Performance Specifications. KIT Scientific Publishing. pp. 198–200. ISBN 978-3-7315-0080-3. 에서 인용한.
- ^ Paul C. Jorgensen (2013). Software Testing: A Craftsman’s Approach, Fourth Edition. CRC Press. p. 136. ISBN 978-1-4665-6068-0.
- ^ J.R.Brown, "자동 소프트웨어 도구의 실용적 적용", TRW 보고서 번호 TRW-SS-72-05, WESCON, 1972년 발표
- ^ M.R. 우드워드, D.헤들리와 M.A.Hennell, "프로그램 경로 분석 및 테스트 경험", IEEE Transactions on Software Engineering, Vol.6, No.3, 278–286, 1980년 5월
- ^ 항공 시스템 및 기기 인증에 관한 소프트웨어 고려사항-RTCA/DO-178B, RTCA Inc., Washington D.C., 1992년 12월