8 min to read

소프트웨어공학-ISTQB-이론 기본 공부

내가 다시 볼려고 정리하는 소프트웨어공학공부

Featured image

ISTQB 공부하기

학부시절 들었던 소프트웨어 공학 다시 되새김질하면서

기본 이론 부터

ISTQB 문제를 풀어보면서 혼자 공부했던것들을

다시 정리해본다.

의식의 흐름 기법으로 계속 줄줄이 이론을 적는다.

만약 찾을단어가 있으면 Ctrl+F 사용

소프트웨어 품질 이란

소프트웨어 품질 - 컴포넌트 시스템,또는 프로세스가 명시된 요구사항과 사용자 고객의 필요 기대를 충족하는정도

1.기능 상의 품질 - 기능 요건이나 사양에 기반하여 주어진 설계를 얼마나 잘 충족하고 있는지 반영 목적 상품가치

2.구조 상의 품질 - 내구성이나 유지보수성, 올바르게 소프트웨어가 개발할수 있는지 가늠하는 척도 비기능 요건충족

내부구조> 소스코드 > 단위수준 > 기술 수준 > 시스템 수준의 분석을 통해 평가 구조의 원칙을 준수하는 방식

기능상의 품질은 소프트웨어 테스트를 통해 강제되어 측정

7가지의 테스팅 원리

1.테스팅은 결함이 존재함을 밝히는 활동

2.완벽한 테스팅은 불가능하다

3.테스팅을 개발 초기에 시작 -초기단계에 테스트 활동을 하면 위험을 줄인다.

4.결함집중 -테스팅에대한 리소스는 SW 모듈별 기능과 관찰된 결함 밀도에 따라 분배되야하는데

대다수의 결함은 소수 특정 모듈에 집중되어 발생되는 경우가 많다.

결함집중될수있는것들-자체적으로 복잡한 구조를 가진모듈

다른모듈과 복잡한 상호작용 하는 모듈

최신기술 개발난이도가 높다

5.살충제 패러독스

-테스트 케이스로 동일한 절차를 반복 수행하면 새로운 결함을 찾을 수 없다.

-A모듈 B모듈 100번 반복이 아니라 AB를 혼합하여 A만 하는게아니라 B도 해야 잠재적인 결함을 발견 가능

-새롭고 다른 시각으로 테스트 하는것이 필요하다.

6.테스팅은 정황에 의존적(도메인분야에따라 다르게 테스팅)

-SW 종류에 따라 테스팅도 영향을 받는다.

7.오류 부재의 궤변 -시스템이 사용성이 현저히 낮다면 테스팅 할 필요가 없다.

테스트 프로세스 단계

1.계획/제어 -테스트환경구축 -테스트 상황/요구사항/데이터식별

2.설계/분석 -테스트우선순위설정, 데이터 생성, 케이스명세화

-기대 결과 비교, 선행테스트

EX)필요한 인프라와 도구를 식별한다.-설계

EX)테스트 베이시스의 테스트 용이성 평가-분석

3.실행/구현 -테스트실행 -최종보고서 작성 -완료조건의달성여부

EX)테스트 스크립트로 테스트 스위트 생성

4.평가/리포팅 -산출물확인

EX)테스트완료-프로세스 개선을 위한 교훈 도출

소프트웨어 생명 주기

요구분석 > 시스템 명세 > 설계 > 구현 > 테스트 > 유지보수

수명주기

테스트 단계

단위테스트

-모듈 개별적 실행

통합테스트 (하향식 , 상향식)

-통합적 테스트

인수테스트(알파테스트-관리자,개발자,베타테스트-사용자)

-안성된 제품으로보고 실제 데이터를 사용하여 시스템 테스트

-예상된 대로 시스템이 동작하는지 확인하고 요구사항에 맞는지 확신을얻는다.

개발 수명주기 모델 에서의 테스팅

-모든 개발 활동은 이에 상응하는 테스팅활동을 동반

-각 테스트 레벨은 그 레벨에 맞는 특정한 목적을 가진다

-개발활동 동안 분석과 설계 시작되어야함

폭포수 모델, V-모델, 순차적 개발 모델

폭포수모델 - 개발이 종료된 후 테스팅을 시작

위에서 아래로 계획 분석 설계 구현 테스트 유지보수 하향식

V모델 - 각 테스트 레벨별로 주체도 다르고 테스트 목적도 다르며 독립적인 테스트 수명주기를 가진다

-테스트 개발이 시작됨과 동시에 진행하며 개발 중간 산출물의 테스팅을 매우 중요시한다.

-요구사항이 변경되었을때 바르게 반영할수 있는 모델은 반복 점증 모델이다.

각각 개발 단계에서 테스팅 접근 방법을 간략히 모델화 한것

개발단계와 테스팅 이 어떻게 통합 될 수 있는 지 설명한다

-단위/통합 테스트 - 하위레벨

-시스템/인수테스트 - 상위레벨

각 테스트 레벨은 서로독립적인 테스트 수명 주기를 가진다. (다른 테스트전략,계획,기법,완료기준)

각 테스트 레벨은 서로종속성을 지닌다. 하나의 레벨에서 다른레벨로 가려면 종료/시작조건맞춰야함

개발자나 시험자의 관점인 Verification(검증)

사용자관점인 Validation(확인) 지원하는 테스트모델

-어느단계에서 발생했는지 추적성 보장

-폭포수모델의 확장된 형태

-높은 신뢰성을 요구하는 소프트웨어에 적용

정적 테스트 기법은 소프트웨어를 실행하지않고 테스팅 하는 기법

리뷰 - 수동적기법 , 소프트웨어 개발 중간산출물을 검토하고 테스팅하는방법

리뷰 장점

1조기결함발견및 수정

2.개발기간단축,개발생산성향상

3.테스팅 비용 감소및 시간단축

4.개발공정 전체 비용감소

5.커뮤니케이션 향상

동적 테스팅 보다 리뷰를 통해 발견하기 쉬운건 -표준 위반, 요구사항결함, 개발설계결함, 불충분한유지보수성,부정확한인터페이스명세 인스펙션-매우공식적인 리뷰 ,시작조건확인

비공식 리뷰 (공식적이지 않은 리뷰)

-워크스루(비공식부터 공식적인것까지 다양함)

-기술적리뷰

정적 분석 - 자동화된 기법

테스트 프로시저(테스트 프로시저명세(테스트 절차명세) 테스트 스크립트,라고도한다.

-효율적인 테스트를 위한 테스트케이스 실행순서

-실행스케줄 수행절차를 얼마나 상세하게 작성할지

블랙박스 vs 화이트박스

블랙박스 - 사용자 관점의 테스트 방법 : 제품에 대한 요구사항 결과물이 일치하는지 확인

-동등분할기법 (프로그램의 입력도메인을 데이터 클래스로 분류

-경계값분석기법 (입력조건의 중간값이아닌 경계값을 넣어서

-오류예측기법 (각 시험기법들이 놓치기 쉬운 오류를 감각및 경험으로

-원인결과그래프 ( 입력 데이터간 관계가 출력에 미치는 영향을 그래프로 표현

-의사결정테이블테스팅 ( 논리적 조건이나 상황에서 입력조건과 결과를 참 거짓으로 표현

-상태전이 테스팅 ( 시스템에 반영되는 이전의 상태가 무엇인지 상태를 변화시키는 이벤트와 입력값을 파악

화이트박스 - 개발자 관점의 단위테스트

-문장 검증

-선택검증

-경로검증

-조건검증

-제어흐름테스팅 기법은 코드를 기반으로 수행

유즈케이스 테스팅 - A배우 S 시스템 시나리오로

사용성테스팅 - 잠재사용자들에게 테스트를 진행하여 제품을 평가하는 기술 (UX를 수립하는 단계에서 진행

사이클로매틱복잡도 = 순환복잡도 사이클로매틱 복잡도 수치는 코드의 복잡성을 나타내는것이며 기본경로

개수를의미한다. 기본 경로는 다른 경로로표현되지 않은 일종 “솟수”에 해당하는 경로의 수를 의미한다.

E 17 - NODE (13) + 2P

테스팅의 독립성 : 테스팅이 개발로부터 얼마나독립적인지

-일정 수준의 독립성 확보는 개발에서 찾기 어려운 결함과 장애를 찾아내는데 효율적

아웃소스 테스트 > 인소스드테스트 (독립성 높은건

개발관련정보와 거리가멀어정보를 적절하게 제공해야함(아웃소스테스트)

테스팅 독립성이 높을때 단점

-테스팅을 제대로 수행하기 위해서 대상 소프트웨어를 상세히 아는 상태에서 수해애야함

-철저히 독립체로 간주된다면 개발팀과 개발및 제품관련 정보로 부터 고립될 수 있다.

-테스트 대상에 대한 정보를 제한적으로 접해서 테스팅을 깊이있게 하기힘들 수도있음.

-독립적인 테스터는 마지막 체크포인트로서의 역할을 수행해서 개발 전체 과정의 병목으로 작용가능

-개발자가 제품 품질에 대한 책임감을 잃을 수 있다.

테스팅 독립성이 높을때 장점 -개발자와 다른 시각에서 다른 종류의 결함 발견 가능

-시스템의 명세와 구현 단계에서 개발 관련자가 만든 가정을 검증 가능

-교육 훈련 받은 전문가에의해 전문적인 시각에서 테스팅 가능

테스트 정책test policy

-조직의 철학을 기술하는 최상위 수준의 문서

-비즈니스 조직 전체 차원에서 테스팅을 정의하고 테스팅이 집중하는영역에 대해 문서화

-테스트 조직 구조와 조직의 핵심역할및 인력관리, 핵심 테스트 프로세스, 테스트 프로세스 개선 등에대한내용

(테스트 정책을 테스트 조직이 가지고 있지 않다는 것은 조직자체의 존재가 모호하거나 가치가낮다)

-테스트 정책은 테스팅이 전문분야로서 개발에 체계적으로 기여하고있다는것을 최고경영층 및 개발

최고관리자와 의사소통하는 가장 중요한 수단이다. 테스트 정책은 추상적으로 생각되지만 구체적을 작성할 수 있으며

한페이지 정도의 분량으로 작성할 수 있으면 유용성이 높아진다.

테스트 계획 수립 관련 주요 작업 내용

-활용할 테스트 설계 기법및 테스트 대상 시틈에ㅢ 테스트 베이시스를 결정한다.

-테스트범위와 테스트를 위한 리스크에 대해 결정하고 이에 기반해 테스트를 접근하는 방식을 기술한다.

-테스트에 필요한 인력과 기간을 산정하고 이해관계자와의 협의를 거쳐 결정한다.

소프트웨어 테스트 추정기술

-작업완료에 걸리는 시간을 대략적으로 나타내는 활동

자원 시간 인간능력 비용

-작업분할구조 기술

-광대역델파이기술

-3포인트 소프트웨어 테스팅기술

-기능점수 / 시험지점분석

-사용 - 사례포인트 방법

-백분율 분포

-리스크 분석및 테스트 전략에 근거하여 추정하는것이좋다

-대표적인 공식적 추정방법으론 TPA가있다.

메트릭기반접근법 : 공식적이거나비슷한 프로젝트에서 측정한 메트릭이나 전형적인 값을 기반

전문성기반접근법 : 전문가나 작업자가 스스로 예측 (와이드밴드델피-팀원들의집단적지식으로 접근)

한번에 드는 노력이 추정되고나면 리소스를 식별하고 일정을 산정가능

리스크 분석및 테스트 전략에 근거하여 추정하는것

대표적인 공식적 추정방법은 tpa

테스트 추정결과는 제품의 특성이나 리스크등 여러가지 요소에 영향을받는다.

리스크 기반 테스팅

1.리스크 식별 : 제품의 품질 관점에서 대상이 될 항목 식별 (기능적 기술적을 분리

(요구사항에따른 하위 레벨 테스트 관련 항목

(아키텍처에 따른 하위 레벨 테스트 관련항목

2.리스크 분석 : 중요하고 복잡하고 잠재적으로 결함이 많은 부분을 분석(리스크 우선순위결정

3.리스크 계획 : 리스크 정보를 근거로 대처방안 수립

4.리스크 추적 : 리스크및 리스크에 대한 대응을 모니터링

정적분석툴

-코드에 대한 이해를 지원한다.

-구조와 의존관계를 분석한다.

-코딩 표준을 지킬것을 강제한다.

자동화 테스팅 이유

-수동 테스팅의 모든 작업 흐름,모든 분야, 부정적인 시나리오들이 시간과 비용을 소비

-수동적으로다양한 언어로 된 사이트들을 테스트하는건 어려움

-자동화는 사람의 개입을 요구하지읂음

-실행속도를 향상시킴

-테스트 범위를 넓히는데 도움을줌

-수동테스팅은 지루해지기떄문에 실수를 범하기 쉬움

자동화 안쓰는거

-새롭게 설계되었고 한번정도 수동으로 실행하지않은거

-요구사항 자주변하는거

-필요에따라 실행되는거

자동화 쓰는거

-높은 위험

-반복적으로 실행

-수동으로하기엔 지루하고 어려운테스트

-시간을 소비하는 테스트사례들

자동화 툴을 도입할때 고려할것

-조직의 성숙도, 강점과 약점을평가

-툴 제작 회사나 베포회사의 교육제공과 지원 능력을 고려한다.

-도입하기전 파일럿 프로젝트에적용하여 기능성을 입증한다.

테스트 컨디션

-테스팅의 기초로 파악된 컴포넌트나 시스템의 테스팅 가능한 측면

틀린말 -컴포넌트나 시스템의 특이성(기능의 정의임)

-소프트웨어를 특정조건에서 사용할 때 설명/제시된 필요기능을 충족할 수 있는
소프트웨어 제품 능력(기능 적합성)

-해당 테스트 케이스로 인한 조건과 행동의 조합을 실행하도록 설계된 테스트케이스 (결정 테이블 테스팅정의)

테스팅과 디버깅의 차이

-디버깅은 결함을 식별하고 테스팅으로 결함의 원인을 식별하지 않는다.

-동적 테스팅은 결함으로 발생하는 장애를 보여주고, 디버깅은 장애의 원인인 결함을 제거한다.

-테스팅은 결점을 제거하지는 않지만 디버깅은 결점의 원인이 되는 결함을 제거한다.

-동적 테스팅은 결함의 원인을 직접적으로 예방하지 않지만, 결함이 존재함을 찾아낸다.

테스팅이나 개발과정에 가장 흔한 장애상황

틀린말

-빌드에 잘못된 버전의 소스코드 파일이 들어갔다. (장애가아닌 겨함에 대한 설명)

-계산 알고리즘에 잘못된 입력값을 사용했다. (잘못된 입력 변수 사용은 장애를 가져오지 않을 수도 있음)

-개발자가 요구사항을 알고리즘으로 구현할 때 잘못 구현했다. (반드시 장애로 이어지지는 않는다.)

테스팅은 어떤면에서 품질 보증의 일부가 될 수 있나

-테스팅은 소프트웨어 품질 저하 리스크 수준을 낮춰준다.

테스트 스위트, 테스트 케이스, 테스트 스크립트, 테스트 차터

-테스트 스위트 : 특정 테스트에서 실행할 일련의 테스트 스크립트 또는 테스트 절차

-테스트 케이스 : 테스트 컨디션에 기반하여 개발된 전제조건, 입력값.

-테스트 스크립트 : 테스트 실행을 위한 일련의 지침

-테스트 차터 : 테스트 목적과 어떤 테스트를 수행할지에 대한 아이디어를 적은 것

점진적 개발 모델

-요구사항 정의, 소프트웨어 설계 및 테스팅은 각각의 단계에 시스템 조각이 추가되는 단계에서 수행한다.

-점증적 개발은 요구사항 수립, 설계, 빌드 및 시스템에 대한 테스팅을 분리된 작업으로 수행

유지보수 테스팅을 유발하는 요인

-새로운 운영 플랫폼으로 시스템을 마이그레이션한 후 테스트할때

-저장된 데이터가 검색 가능한지 테스트

-핫픽스 후 테스트

공식 리뷰의 역할 담당자

-작성자 중재자 리뷰리더 리뷰어 서기

체크리스트에 기반한 공식 프로세스를 따라야 하는 리뷰

-인스펙션은 규정과 체크리스트에 기반한 공식 프로세스

-비공식 리뷰는 공식프로세스를 따르지 않는다.

-기술적 리뷰에서 체크리스트는 선택적으로 사용한다.

-워크쓰루에서 공식 프로세스를 따라야한다는 명시적인 요구는 없다.

정적 테스팅

-결함을 발견하고 제거하는 경제적인 방법이다. (개발 수명주기 후반에 결함을 발견하는 것 보다 초기에 발견하는게 경제적)

1 -출처 구글 추상화 이미지