Chapter 11, 응용 SW 기초 기술 활용

1. 소프트웨어 테스트는 소프트웨어 테스트란 개발된 응용 애플리케이션이나 시스템이 사용자가 요구하는 기능과 성능, 사용성, 안정성 등을 만족하는지 확인하고, 노출되지 않은 소프트웨어의 결함을 찾아내는 활동이다.

2. 소프트웨어 테스트의 원리중 (완벽한 테스팅은 불가능)은 무한 경로(한 프로그램 내의 내부 조건은 무수히 많을 수 있음), 무안 입력 값(입력이 가질 수 있는 모든 값의 조합이 무수히 많음)으로 인한 테스트의 어려움을 나타내는 원리이다.

3. 소프트웨어 테스트의 원리 중 결함집중은 적은 수의 모듈에서 대두수의 결함이 발견됨을 나타내는 원리로 파레토 법칙(Pareto Principle)의 내용인 80 대 20 법칙이 적용되는 원리이다.

4. 소프트웨어 테스트의 원리 중 살충제 페러독스는 동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그를 찾지 못한다는 원리로 테스트 케이스의 정기적 리뷰와 관련된 원리이다.

5. 소프트웨어 테스트의 원리 중(오류- 부재의 궤변)은 요구사항을 충족시켜주지 못한다면, 결함이 없다고 해도 품질이 높다고 볼 수 없다는 원리이다.

6. (폭포수모델)은 소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 가장 오래된 생명주기 모델이다.

7. 테스트케이스(TestCase)는 테스트를 위한 설계 산출물로, 응용 소프트웨어가 사용자의 요구사항을 준수하는지 확인하기 위해 설계된 입력값, 실행 조건, 기대 결과로 구성된 테스트 항목의 명세서이다.

8. 테스트 슈트(Test Suit)는 테스트 케이스를 실행환경에 따라 구분해 놓은 테스트 케이스의 집합으로 시나리오가 포함되지 않은 단순한 테스트 케이스들의 모음이다.

9. (테스트시나리오 Test Scenario)는 애플리케이션의 테스트 되어야 할 기능 및 특징, 테스트가 필요한 상황을 작성한 문서로 하나의 단일 테스트 시나리오가 하나 또는 여러개의 테스트 케이스를 포함할 수 있다.

10. (소프트웨어 개발 방법론)은 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법이다.

11. 테스트 스크립트(Test Script)는 테스트 케이스의 실행 순서(절차)를 작성한 문서로 테스트 스텝(Test Step), 테스트 절차서(Test Procedure)라고도 한다.

12. (정적 테스트)는 테스트 대상을 실행하지 않고 구조를 분석하여 논리성을 검증하는 테스트로 종류에는 리뷰와 정적 분석이 있다.

13. (동적 테스트)는 소프트웨어를 실행하는 방식으로 테스트를 수행하여 결함을 검출하는 테스트로 종류에는 화이트박스 테스트, 블랙박스 테스트, 경험 기반 테스트가 있다.

14. 화이트박스 테스트(White-Box Test) 는 각 응용 프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트로 코드 분석과 프로그램 구조에 대한 지식을 바탕으로 문제가 발생할 가능성이 있는 모듈 내부를 테스트 하는 방법이다.

15. 구문 커버리지 or 문장 커버리지 는 프로그램 내의 모든 명령문을 적어도 한 번 수행하는 커버리지로 조건문 결과와 관계없이 구문 실행 개술로 계산한다.

16. 조건 커버리지(Condition Coverage)는 각 분기의 결정 포인트 내의 개별 조건식이 적어도 한 번은 참과 거짓의 결과가 되도록 수행하는 테스트 거버리지 이다.

17. 조건/결정 커버리지(Condition/Decision Coverage)는 전체 조건식 뿐만 아니라 개별 조건식도 참 한번, 거짓 한번 결과가 되도록 수행하는 테스트 커버리지 이다.

18. 변경조건/결정 커버리지(modified Condition Decision Coverage)는 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록 함으로써 조건/결정 커버리지를 향상 시킨 커버리지이다.

19. 다중 조건 커버리지(Multiple Condition Coverage)는 결정 조건 내 모든 개발 조건식의 모든 가능한 조합을 100% 보장하는 커버리지이다.

20. (제어흐름테스트(Control Flow Testing)은 프로그램 제어 구조를 그래프 형태로 나타내어 내부 로직을 테스트 하는 기법이다.

21. (데이터흐름 테스트(Data Flow Testing)은 제어흐름 그래프에 데이터 사용현황을 추가한 그래프를 통해 테스트 하는 기법이다.

22. 블랙박스테스트(Black-box Test)는 프로그램 외부 사용자의 요구사항 명세를 보면서 수행하는 테스트(기능 테스트)이다.

23. 동등 분할 테스트(Equivalence Partitioning Testing)은 입력데이터의 영역을 유사한 도메인별로 유횻값/무횻값을 그룹핑하여 대푯값 테스트 케이스를 도출하여 테스트 하는 기법이다.

24. 경곗값 분석 테스트(Boundary Value Analysis Testing)은 등가 분할 수 경곗값 부분에서 오류 발생 확률이 높기 때문에 경곗값을 포함하여 테스트 케이스를 설계하여 테스트 하는 기법이다.

25. 결정 테이블 테스트(Decision Table Testing)은 요구사항의 놀리와 발생 조건을 테이블 형태로 나열하여 조건과 행위를 모두 조합하여 테스트 하는 기법이다.

26. 상태 전이 테스트(State Transition Testing)은 테스트 대상 시스템이나 객체의 상태를 구분하고, 이벤트에 의해 어느 한 상태에서 다른 상태로 전이되는 경우의 수를 수행하는 테스트 기법이다.

27. 유스 케이스 테스트(Use Case Testing)은 시스템이 실제 사용되는 유스 케이스로 모델링 되어 있을 때 프로세스 흐름을 기반으로 테스트 케이스를 명세화 하여 수행하는 테스트 기법이다.

28. 분류트리 테스트(Classification Tree Method Testing)은 SW의 일부 또는 전체를 트리 구조로 분석 및 표현하여 테스트 케이스를 설계하영 테스트하는 기법이다.

29. 페어와이즈 테스트(Pair-Wise Testing은 테스틑 데이터 값들 간에 최소한 한번씩을 조합하는 방식이며, 이는 커버해야 할 기능적 범위를 모든 조합에 비해 상대적으로 적은 양의 테스트 세트를 구헝하기 위한 테스트 기법이다.

30. 원인 결과 그래프 테스트(Cause-Effect Graphing Testing)은 원인-효과 그래프 테스트는 그래프를 활용하여 입력 데이터 간의 관계 및 출력에 미치는 영향을 분석하여 효용성이 높은 테스트 케이스를 선정하여 테스트 하는 기법이다.

31. 비교테스트(Comparison Testing)은 여러 버전의 프로그램에 같으 입력 값을 넣어서 동일한 결과 데이터가 나오는지 비교해 보는 테스트 기법이다.

32. 회복 테스트는 시스템에 고의로 실패를 유도하고, 시스템의 정상적 복귀 여부를 테스트하는 기법이다.

33. 안전테스트는 불법적인 소프트웨어가 접근하여 시스템을 파괴하지 못하도록 소스 코드 내의 보안적인 결함을 미리 점검하는 테스트 기법이다.

34. 성능테스트는 사용자의 이벤트에 시스템이 응답하는 시간, 특정 시간 내에 처리하는 업무량, 사용자 요구에 시스템이 반응하는 속도 등을 측정하는 테스트 기법이다.

35. (구조테스트)는 시스템의 내부 논리 경로, 소스코드의 복잡도를 평가하는 테스트 기법이다.

36. (회귀테스트)는 오류를 제거하거나 수정한 시스템에서 오류제거와 수정에 의해 새로이 유입된 오류가 없는지 확인하는 일 종의 반복 테스트 기법이다.

37. 변형테스트는 변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과를 비교하는 테스트 기법이다.

38. 부하테스트(Load Testing)은 시스템에 부하를 계속 증가시키면서 시스템으잉 임계점을 찾는 테스트이고, 테스트를 통해 병목 지점을 찾아서 병목 현상을 제거한다.

39. 스트레스 테스트(Stress Testing)은 시스템 처리 능력 이상의 부하, 즉 임계점 이상의 부하를 가하여 비정상적인 상황에서의 처리를 테스트하는 기법이다.

40. 스파이크테스트(Spike Testing)은 짧은 시간에 사용자가 몰릴 때 시스템의 반응 측정 테스트이다.

41. 내구성 테스트(Endureance Testing) 은 오랜 시간 동안 시스템에 높은 부하를 가하여 시스템 반응 테스트이다.

42. 경험기반 테스트는 우사 소프트웨어나 유사 기술 평가에서 테스터의 경험을 토대로 한 직관과 기술 능력을 기반으로 수행하는 테스트 기법이다.

43. 인스펙션(Inspection)은 소프트웨어의 다양한 산출물엥 존재하는 결함을 검출하거나 프로젝트의 진행 상황을 점검하기 위한 활동이다.

44. 워크스루(Walk Throughs)는 검토 자료를 호의 전에 배포해서 사전 검토한 후 짧은 시간 동안 회의를 진행하는 형태로 기뷰를 통해 문제 식별, 대안 조사, 개선 활동, 학습 기회를 제공하는 가장 비 형식적인 검토 기법이다.

45. 주재자(moderator)은 인스펙션 참가자중 검사할 작업물을 기초롤 참가자를 선정, 인스펙션 계획, 회의 주재, 후속 조치 필요를 결정하는 역할을 수행한다.

46. 정적분석(Static Analysis)는 도구의 지원을 받아 정적 테스트를 수행하는 방법으로 자동화된 도구를 이용하여 산출물의 결함을 검출 하거나 복잡도를 측정하고 유형에는 코딩 표준 부합, 코드 복잡도 계산, 자료 흐름 분석 등이 있다.

47. (테스트 커버리지)는 프로그램으이 테스트 수행 정도를 나타내는 값으로 테스트 수행의 완벽성을 측정하는 도구이고, 주어진 테스트 케이스에 의해 수행되는 소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준이다.

48. 맥케이브(McCabe)의 (순환복잡도)는 제어 흐름의 복잡한 정보를 정량적으로 표시하는 기법으로 해당 제어 흐름 그래프에서 선형적으로 독립적인 경로의 수를 나타낸다.

49. 탐색적 테스트(Exploratory Test)는 테스트 스크립트 또는 테스트 케이스를 문서로 작성하지 않고 경험에 바탕을 두고 탐색적으로 기능을 수행하 보면서 테스트 하는 기법으로 구성요소는 테스트 차터(Test Charter), 시간제한(TimeBoxing), 노트(Note), 회고(Debriefing)가 있다.

50. 오류수정(Error Guessing)은 개발자가 범할 수 있는 실수를 추정하고 이에 따른 결함이 검출되도록 테스트 케이스를 설계하여 테스트 하는 기법이다.

51. 테스트 오라클(Test Oracle)은 테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참 값을 입력하여 비교하는 기법이다.

52. 테스트 오라클 기법 중 참(True) 오라클은 모든 입력값에 대하여 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출할 수 있는 오라클이다.

53. 테스트 오라클 기법 중 샘플링(Sampling)은 특정한 몇 개의 입력값에 대해서만 기대하는 결과를 제공해 주는 오라클이다.

54. 테스트 오라클 기법 중 휴리스틱(Heuristic)오라클은 샘플링 오라클을 개선한 오라클로, 특정 입력값에 대해 올바른 결괄르 제공하고, 나머지 값들에 대해서는 휴리스틱(추정)으로 처리하는 오라클이다.

55. 테스트 오라클 기법 중(일관성 검사 오라클) consistent)는 애플리케이션 변경이 있을때, 수행 전과 후의 결괏값이 동일한지 확인하는 오라클이다.

56. 테스트 레벨 중 단위테스트는 사용자 요구사항에 대한 단위 모듈, 서브루틴 등을 테스트 하는 단계로 유형에는 자료구조 테스트, 실행 경로 테스트, 오류 처리 테스트, 인터페이스 테스트가 있다.

57. 테스트 레벨 중 통합테스트 는 단위 테스트를 통과한 모듈 사이의 인터페이스, 통합된 컴포넌트 간의 상호작용을 검증하는 테스트하는 단계로 유형에는 빅뱅 테스트, 샌드위치 테스트, 상향식 테스트, 하양식 테스트가 있다.

58. 테스트 레벨 중 (시스템 테스트)는 통합된 단위 시스템의 기닝이 시스템에서 정상적으로 수행되는지를 검증하는 테스트 단계로 유형에는 기능, 비기능 요구항 테스트가 있다.

59. 테스트 레벨 중 인수 테스트는 계약상의 요구사항이 만족하였는지 확인하기 위한 테스틑 단계로 유형에는 알파, 베타 테스트 등이 있다.

60. 알파테스트는 선택된 사용자(회사 내의 다른 사용자 또는 실제 사용자)가 개발자 환경에서 통제된 상태로 개발자와 함께 수행하는 인수 테스트이다.

61. 베타테스트는 실제 환경에서 일정 수의 사용자에게 대상 소프트웨어를 사용하게 하고 피드백을 받는 인수 테스트이다.

62. 에뮬레이션(emulation)은 한 컴퓨터가 다른 컴퓨터처럼 똑같이 작동하도록 소프트웨어나 마이크로 프로그래밍을 하는 기법이다.

63. 하향식 통합(Top Down)은 메인 제어 모듈(프로그램)로 부터 아래 방향으로 제어의 경로를 따라 이동하면서 아래로 통합하면서 테스트를 진행하며, 메인 제어 모듈에 통합되는 하위 모듈과 최하위 모듈은 '깊이-우선' 또는 '너비-우선' 방식으로 통합되는 방식이다.

64. 깊이-우선 방법은 루트노드(혹은 다른 임의의 노드에서 시작해서 다음 분기(Branch)로 넘어가기 전에 해당 분기를 완벽하게 탐색하는 방법이다.

65. 너비-우선 방법은 루트노드(혹은 다른 임의의 노드)에서 시작해서 인접한 노드를 먼저 탐색하는 방법이다.

66. 상향식 통합(Bottom up)은 애플리케이션 구조에서 최하위 레벨의 모듈 또는 컴포넌트로 부터 위쪽 방향으로 제어의 경롤르 따라 이동하면서 구축과 테스트를 수행하는 방식이다.

67. 샌드위치 통합은 상향식 통합테스트와 하향식 통합테스트 방식을 결합한 테슽트 방식으로 하위 프로젝트가 있는 큰 규모의 통합 테스트에서 사용하는 방식이다.

68. 에러(Error)는 결함(Defect)의 원인이 되는 것으로, 일반적으로 사람(소프트웨어 개발자, 분석가 등)에 의해 생성된 실수이다.

69. 결함 or 결점 or 버그(Bug)는 에러 또는 오류가 원인이 되어 소프트웨어 제품에 포함되어 있는 문제로 이를 제거하지 않으면 소프트웨엉 제품이 실패(Failure)하거나 문제 (Problem)가 발생한다.

70. 테스트 결함관리, 단계별 테스트 수행후 발생한 결함의 재발 방지와 유사 결함 발견 시 처리 시간 단축을 위해 결함을 추적하고 관리하는 기술이다.

71. 결함 분석 방법 중 구체화(specification)은 결함의 원인을 찾기 위해 결함을 발생시킨 입력값, 테스트 절차, 테스트 환경을 명확히 파악하는 방법이다.

72. 결함 생명주기별 결함 상태 중(결함등록)Open은 테스터가 테스트 절 차를 실행하여 발견한 결함ㅇ르 분석 후 구체화, 고립화, 일반화 한 결함으로서 보고된 상태로 결함 보고서에 기록되어 결함추적의 대상이 된 상태이다.

73. 결함 생병주긱 별 결함 생태 중 결함 할당(Assigned) 은 결함을 수정할 개발자가 결정되고 그 개발자에게 결함 해결이 요구된 상태이다.

74. 결함 추이 분석은 테스트 완료 후 발견된 결함의 결함 관리 측정 지표의 속성값들을 분석하고, 향후 애플리케이션의 어떤 모듈 또는 컴포넌트에서 결함이 발생할 지를 추정하는 작업이다.

75. 결함 추이 분석 유형 중 (결함 에이징 분석)은 등록된 결함에 대해 특정한 결함 상태의 지속 시간ㅇ르 측정하여 분석하는 기법이다.

76. 결함 추이 분석 유형중 결함 추세분석은 테스트 진행 시간의 흐름에 딸느 결함의 수를 측정하여 결함 추세를 분석하는 기법이다.

77. 애플리케이션 성능 측정 지표 중 처리량(Throughput)은 애플리케이션이 주어진 시간에 처리할 수 있는 트랜잭션의 수로 웹 애플리케이션의 경우 시간당 페이지 수로 표현한다.

78. 애플리케이션 성능 측정 지표 중(응답시간(Response Time)은 사용자 입력이 끝난 후, 애플리케이션의 응답출력이 개시될 때 까지의 시간으로 애플리케이션의 경우 메뉴 클릭시 해당 메뉴가 나타나기 까지 걸리는 시간이다.

79. 외계인 코드(Aline Code)는 아주 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 아주 어려운 코드를 말한다.

80. 스파게티코드(spaghetti Code)는 컴퓨터 프로그램의 소스 코드가 복잡하게 얽힌 모습을 비유적으로 표현한 말로 작동은 정상적으로 하지만 사람이 코드를 읽으면서 그 코드의 작동을 파악하기는 어려운 코드를 말한다.