제 4장 품질 특성과 비기능 테스트
기능 테스트
: 요구사항 측면의 결함 검출 및 충족 여부 확인, 모든 테스트 수준(컴통시인)에서 진행
*컴통시인 : 컴포넌트, 통합, 시스템, 인수
비기능 테스트
: 품질 요구사항 측면에서 결함 검출 및 충족 확인, 일반적으로 (시,인) 수준에서 진행
*시인 : 시스템, 인수
품질특성 (주특성과 부특성): 기사신호이성보유
좀 복잡한 거 같은데 외우긴 해야한다. 의미는 보다보면 대충 보이고, 주특성 부특성은 암기
외우는 방법은 좀 웃긴거 같아도 나름 도움 됐다.
| 주특성 | 부특성 | |
| 기능적합성 | 기능완전성 | 모든 요구사항 정도 |
| 기능정확성 | 기대 수준을 정확 달성 정도 | |
| 기(완정적) | 기능적절성 | 사용목적 달성 정도 |
| 성능효율성 | 자원효율성 | 자원 효율 |
| 수용성 | 시스템이 많은 사용자와 데이터를 동시처리 할 수 있는지 (시스템 매개변수의)최대 한계가 요구사항 충족하는가 |
|
| 성(자수시) | 시간반응성 | 응답, 처리 시간 충족 |
| 호환성 | 공존성 | 다른 SW에게 환경 등 공유할 때 악영향 없는가 |
| 호(공상) | 상호운영성 | 여러 시스템이 정보 교환,사용 원활한가? (IoT) |
| 사용성 | 오류방지성 | 사용자 오류 방지 되는가 |
| 접근성 | 남녀노소 아무나 사용하기(접근하기) 쉬운지 | |
| 사용자 인터페이스심미성 |
사용자 UI 만족하게 | |
| 적합인식성 | 사용자 스스로 시스템이 적합한지 인식하게 | |
| 운영용이성 | 쉽게 조작 제어 가능한지 | |
| 사(오접심인운학) | 학습용이성 | 사용법 배워 사용 목적을 잘 달성하는지 |
| 신뢰성 | 성숙성 | 정상 작동 상태에서의 신뢰성 있는가? |
| 복구성 | 중단, 장애 시 Data 복구 재설정 정도 | |
| 결함허용성 | 결함에도 작동하는 정도 | |
| 신(성복허가) | 가용성 | 사용 및 접근 가능한 정도 |
| 보안성 | 부인방지성 | 사건 및 행위 부인 못 하도록 입증할 수 있는 정도 |
| 인증성 | 실제 행위자 임을 증명 | |
| 무결성 | 시스템, 구성 요소가 데이터에 무단접근/변경 방지 | |
| 기밀성 | 접근 권한 있는 사람에게만 액세스 | |
| 보(부인무기책) | 책임성 | 개인을 유일하게 식별 행위자 추적 |
| 유지보수성 | 분석성 | 부분 변경했을 때 시스템에 미치는 영향을 평가 / 수정할 부분을 식별할 수 있는 정도 / 결함에 대해 진단 |
| 변경용이성 | 결함이나 품질 저하 없이 수정 가능 정도 | |
| 테스트용이성 | 용이한 테스트 정도 | |
| 재사용성 | 하나 이상의 시스템에서 사용, 또는 다른 자산 구축 | |
| 유(분변테재모) | 모듈성 | 모듈 간에 결합도 낮게, 한 모듈 응집도 높게 (구성요소 변경이 미치는 영향 적게) |
| 이식성 | 적응성 | 다른 환경에 적용 가능 |
| 대체용이성 | 다른 제품으로 대체 가능 | |
| 이(적대설) | 설치용이성 | 특정 환경에 설치 및 제거 가능 |
1. 기능 적합성 테스트 [기(완정적)]
제품 또는 시스템이 요구 충족하는가? 기능 완전, 정확, 적절성
2. 성능 효율성 테스트 [성(자수시)
수용성, 시간반응성, 자원효율성(활용성)
- 성능테스팅 종류
- 부하 테스팅 : 부하를 계속 증가시키며 시스템의 임계점을 찾는다.
- 스트레스 테스팅 : 임계점 이상의 부하를 가한다.
- 스파이크 테스팅 : 짧은 시간에 사용자가 몰릴때 시스템의 반응을 측정한다.(여러번도O)
- 내구성 테스팅 : 오랜 시간 동안 시스템에 높은 부하를 가한다.
- 벤치마크 테스트 : 실제로 비교 대상과 성능을 비교 시험, 평가
3. 호환성 테스트 [호(공상)]
공존성, 상호 운영성 → 다른 프로그램과 호환 잘되는가
- LISI 능력 모델 (격리, 불완전, 연결, 기능적, 도메인, 전군적)
-> 중요한 건지 모르겠습니다. 딱히 필요 없는 것도 같습니다.
4. 사용성 테스트 [사(오접심인운학)]
사용자 오류 방지성, 접근성, 사용자 인터페이스(UI) 심미성, 적합 인식성, 운영 용이성, 학습 용이성
특정 사용환경, 시스템 제품 사용의 효율, 효과, 만족도
- 사용성 평가 방법
- 휴리스틱 평가 (heuristic : 경험적인, 스스로 발견하게 하는) : 사용성 평가 전문가 체크리스트로 사용성에 관한 문제점 도출
- FGI (focus group interview) : 공통점이 있는 사용자들이 그룹 별로 모여 의견을 나눈다.
- 인지적 워크쓰루 (walk through : SW 설계서의 오류를 검토 과정에서 발견하기 위한 회의**)** : 사전 설명/안내 없이 제품을 사용하여 주어진 과제를 달성하도록 한다.
- = 회의 평가 도출 그룹 의견 나누는 = 휴리스틱, FGI, 워크 쓰루 = 사용성 테스트
- 이거 3개는 외울 것
5. 신뢰성 테스트 [신(성복허가)]
성숙성, 복구성, 결함 허용성, 가용성
특정 조건, 기간 동안 오동작 없는가, 기능 수행 하는가
정량화 : 가용성, MTTF(Mean Time To Failure)
주로 통계적 테스트 방법 사용
6. 보안성 테스트 [보(부인무기책)]
부인방지성, 인증성, 무결성, 기밀성, 책임성
- 보안성 검증 : 침입 테스트, 정적 분석(CWE)
7. 유지 보수성 테스트 [유(분변테재모)]
*원래 이게 원조가 유지테 뭐시기였는데, 나는 유지테 보다는 변태가 와닿아서....(??)
찰지게 꽂히는 걸로 그냥 정했다... 유지테도 생각났는데 아 그 뭐 변태로도 할 수 있었는데? 이렇게 희미하게 기억나길래...굳이 막 변태를 좋아하는건 아니고요... ㅜㅜ
분석성, 변경 용이성, 테스트 용이성, 재사용성, 모듈성
- 모듈화 정도 (fan-in, fan-out이 낮아야 한다.)
- 모듈 간 결합도는 낮게 설계되어야 한다.
- 모듈 응집도는 높을수록 좋다.
- 모듈 복잡도 (순환복잡도가 75 이상이면 결함수정할때 새로운 결함 발생 가능성이 매우 높음
8. 이식성 테스트 [이(적대설)]
적응성, 대체 용이성, 설치 용이성
- 다양한 플랫폼에서 운영될 수 있는 SW인가? 하드웨어, 소프트웨어 환경이 달라도 동등한 서비스를 제공하는지 여부 평가
제 5장 위험 기반 테스트 [범위 X]
제 6장 소프트웨어 생명 주기 모델과 테스트
소프트웨어 생명 주기 모델
- 순차적 개발 모델
- 진화적 개발 모델
- 애자일 개발 모델
1. 순차적 개발 모델
- 요구 사항이 개발 초기에 완전히 정의되어있을 때 적합
- 프로세스와 문서 위주의 방법론 → 관습적
1-1. 폭포수 모델
- 요구사항
- 요구사항 분석(명세화)
- 구조 설계(전체적 구조 결정)
- 상세 설계(산출물 : 상세 설계 명세)
- 코딩(산출물 : 프로그램)
- 테스팅(완성된 시스템 결함 검출)
- 운영
- 개발 중심 모델이다. 테스트 작업을 코딩 후 하나의 개발 단계로만 취급
- 요구 사항이 개발자에게 익숙하거나, 변경이 개발 도중 빈번하지 않을 때 적합
- 개발 과정에서 SW 관한 문서 정보 많이 산출
1-2. V-모델 (V모델)
* 이전 포스팅에 나왔던 V&V와 같은 것이다.
예를 들어 컴포넌트 테스팅은 모듈 테스팅, 단위 테스팅 뭐 이렇게도 말하니까
같은 의미의 말들을 적어놓으면 좋다. Exercise 문제 같은거 풀면 알게 된다.
- 개발과 테스트를 동등하게 한다. ↔ 폭포수 모델의 반대
- 개발 시작, 테스트 활동 시작
- 요구 사항 ↔ 인수 테스트 / 요구 사항 분석 ↔ 시스템 테스트 구조 설계 ↔ 통합 테스트 / 상세 설계 ↔ 단위 테스트
- V = V&V(Verification(검증) & Validation(확인)
- ↘ 왼쪽 화살표 : 개발관련단계(SDLC: Software Development Life Cycle),
- ↗ 오른쪽 화살표 : 테스트관련단계(STLC : Software Testing Life Cycle)
* 검증이나 확인이나 같은 말 아닌가.?
Verification(검증)은 시스템이 명세를 만족하는지,
Validation(확인)은 시스템이 사용자의 요구 사항을 만족하는지
2. 진화적 개발 모델
- 현실적으로 요구사항이 명확하지 않을 때 적합
- 점진적, 반복적(Iteration) ( 개선 발전 시켜 나아간다. )
- 대표적인 방법은 나선형 개발 모델
*이터레이션(Iteration) : 프로젝트를 진행 시 짧은 개발 주기를 반복하며 고객 평가, 요구 수용하는 SW 개발 방법
2-1. 나선형 개발 모델
- 반복적·점진적으로 개발하는 모델
- 일반적으로 기술적으로 어렵거나 고객 비즈니스 가치를 최상으로 만드는 요구사항 먼저 프로토 타입 개발, 테스트 평가 하며 개발주기 이어감.
- 개발 주기가 시작 될 때마다 위험 분석을 수행 잠재적 위험을 파악하여 해결해 나갈 수 있다.
- 나선형의 각 타원에서 생명 주기 모델들을 여러개 혼합하여 개발할 수 있다. (메타 생명 주기 모델)
- 요구사항 → 설계 → 프로토타입 → 테스트 및 고객평가 → 재설계 → 프로토타입 → 테스트 및 고객평가 → 재설계 → …. (무수히 반복)→ 구현 → 컴포넌트테스트 → 통합테스트 → 시스템테스트 → 인수테스트
3. 애자일 개발 모델
- 간단하고 빠르다. 폭포수 모델처럼 문서 중심의 매우 복잡한, 프로세스 위주의 방법론과 대치
- 애자일 방법론은 소프트웨어 테스트를 매우 강조한다.
- 이터레이션이 짧기 때문에, 고객이 실제 동작하는 소프트웨어(일의 진척도)를 빠르게 볼 수 있다.
- 반복적이면서 점진적인 개발 접근 방식(IID)을 따른다.
IID는 소프트웨어 개발주기를 여러개의 이터레이션으로 구분
(IID: Iterative and Incremental Development 반복적 및 점진적 개발)
애자일 선언(핵심가치) 암기*
- 사람 및 상호 의사교환이 프로세스나 도구보다 우선한다. (대표적인 애자일 방법인 XP는 개발자가 과도한 작업을 피하는 것이 중요하단 사실을 강조한다.)
- 동작하는 소프트웨어가 포괄적인 문서보다 우선한다.
- 고객과의 협력이 계약 협상보다 우선한다.
- 변화에 반응하는 것이 계획을 따르는 것보다 우선한다.
짝 프로그래밍
: 페이지 115 한 명 보다 두 명이 낫다 손해 아니고 좋다 뭐 그런 뜻
TDD (테스트주도개발) * 그림 암기
- 테스트 케이스를 먼저 작성,
- 실제 프로그램의 코드를 나중에 작성
- 테스트 되지 않는 코드가 없다. → 결함 발생 가능성 하락 → 테스트 용이성 상승
- 실패하는 테스트 작성 → 통과하는 테스트 코드 작성 → 리팩토링 (코드개선)
- 리팩토링 후 리그레션(Regression:회귀) 테스트 진행
