9. 공개SW 테스트 프로세스


▣ 분석/설계

공개SW 시스템의 특성을 고려하여 적합한 테스트 목표 및 실행 전략, 테스트 범위, 접근 방법, 테스트 수행 시 요구되는 자원(도구 포함)등을 사전에 정의하여 프로젝트 수행 시 원활한 테스트 수행을 위한 사전 작업을 진행한다.


테스트 대상 매뉴얼 및 SW 기능 구조 파악

시스템과 관련된 기능을 분석하고 그 기능과 관련된 테스트 요소를 정의한다. 테스트 수행 시 기능 리스크 분석을 통해 테스트 케이스 설계 시 필요한 요소를 파악할 수 있다. 단, SW가 사용하기 쉽지 않다면 처리 결과가 부정확할 수 있다.


【표 III-8. 기능 리스크 분석 상세 예시】
리스크 요소 개발사 리스크 사용자 리스크
리스크 아이템 추가된
기능
상호관계 기능
중요도
결함
발생률
사용자 취급
중요도
안정적
피해
사용
빈도
외부적
가시성
회원가입 3 5 5 5 9 9 3 9
회원탈퇴 3 3 3 0 1 3 1 0
강의등록 5 9 5 1 0 9 9 5
강의수강 9 9 9 9 9 5 9 5
시험신청 5 9 5 5 3 5 3 5
점수산정 9 9 9 5 9 3 9 5
결과통보 5 5 5 3 3 9 5 5


테스트 케이스 및 시나리오 설계

프로젝트 범위 및 상위 요구사항을 분석하여 테스트 범위를 설정한다. 테스트를 통하여 적합성을 검증 받아야 할 테스트 범위는 대상 시스템 전체가 될 수도 있고, 경우에 따라 일부분이 될 수도 있다.

선정된 테스트 범위는 향후 테스트 단계별 상세계획 수립 시, 요구분석 및 설계 단계에서 정의된 각 테스트 요구사항 들을 검토하여 테스트 항목, 테스트할 항목의 특성과 테스트하지 않을 항목의 특성을 명세화 하는 기반 자료로 활용된다.


【표 III-9. 테스트 케이스 도출 기법 예시】
테스트 단계 테스트 유형 내용
단위테스트 기능 개별 Component의 기능 테스트
단위 업무 기능 테스트
표준준수 표준 준수여부 체크
보안 단위 프로그램 내 사용자별 기능 제한 사항 체크
성능 대상 단위업무에 대한 개별 성능 측정
통합테스트 Component통합 Component 통합 하에서 기능 테스트 : 단위테스트에서 수행되기도 함
데이터 연계 업무 처리 흐름에 따른 데이터 흐름 테스트
시스템 간 통합 타 시스템과의 프로세스I/F 테스트
타 시스템간의 데이터 I/F 테스트
SW 통합 가능한 SW 구성에 따른 시스템의 운영여부 테스트
HW 통합 시스템 구성 HW 간의 I/F 테스트
보안 사용자별 접근 제한(통합환경)
시스템 기능 단위 테스트와 통합과정에서 이루어졌던 기능 중 시스템 전반에 걸친 주요 기능에 대해
   테스트
성능 사용자 수 대비 응답시간 측정
시스템테스트 볼륨 시간당 대상 업무에서 처리될 수 있는 최대 건수 측정
스트레스 시스템의 한계상황 하에서의 부족한 리소스 및 시스템 상태 확인
구성 SW들의 구성, SW 환경설정, HW의 물리적 구성 등에서 최적의 운영환경 발견하기 위한
   테스트
보안 시스템 접근 제한에 대한 테스트
설치 시스템의 설치 및 인스톨 프로그램의 설치 테스트

【표 III-10. 사용자 시나리오 설계 예시】
순번 대분류 중분류 소분류 시나리오 명 시나리오 개요
1 콘텐츠 관리 파일 삭제 사용자 사용자의
파일 접근 권한
일반 사용자가 등록되어 있는 콘텐츠에 접근하여
   삭제할 수 있는 권한이 있는지 확인한다.
2 관리자 관리자의
파일 접근 권한
관리자가 등록되어 있는 콘텐츠에 접근하여
   삭제할 수 있는 권한이 있는지 확인한다.

【표 III-11. 테스트 케이스 설계 예시】
순번 테스트 케이스 입력데이터 예상결과
1 문서목록보기 Page 목록에서 다른 사용자가 등록한 문서를 클릭 Add_001 Add_001이 등록한 문서로 이동
2 문서내용보기 Page에서 수정버튼을 클릭   정보입력 Page로 이동
3 등록한 문서의 내용을 변경한 후 등록버튼 클릭 Test_023.txt 내용보기 Page로 이동
4 변경한 내용이 적용되었는지 확인   Test_023 적용

【표 III-12. 성능 테스트 케이스 설계 예시】
테스트 목표 상황을 고려한 Workload Model이 적용된 테스트로써 38.23 TPS를 목표로 함
목표치 사용자수 10000 호출간격 44.4
TPS > 38.23 응답시간 Read<1Sec
측정항목 거래 성공 비율, TPS, 응답시간, 시스템 사용률
시나리오 Ramp-UP Model : (100 Users/3초) * 51초(51초 후에 1000 Users 유입, 측정 시작)
1000 User 유입 완료 후 2분 동안 부하 발생, 성능 측정
Ramp-Down Model : (300 Users/초) * 30초(30초 후에 시험 종료)
Think Time Model : 호출 간격(1.4초) - Real 응답 시간
사전 확인 사항 테스트 시작 시간   테스트 종료 시간  
스크립트 수행(N번)   부하 발생기 상태 확인  
데이터베이스 상태 확인   시나리오 확인  
Configuration 확인   테스트 데이터 Import  


테스트 도구

공개SW 역량프라자에서는 효율적인 비기능 테스트 진행을 위해 TTA와 협력하여 성능 테스트를 수행하며, 다양한 테스트 도구 중 LoadRunner, Jmeter 등의 성능 테스트 도구를 활용한다.


- LoadRunner

업계 표준의 애플리케이션 부하 테스트 도구로 Web, C/S, SAP, Oracle 등의 다양한 환경의 애플리케이션에 대하여 성능 시험과 부하 시험을 정확하고 효율적으로 진행할 수 있으며 부하 또는 성능 테스트를 진행하는 동안 해당 시스템의 성능과 기능성을 측정, 감시하고 분석하여 성능 개선을 위한 자료를 제공한다.



【그림 III-6. LoadRunner 수행 화면 예시】

- Jmeter

Apache Jakarta 프로젝트의 일환으로 만들어진, 테스트 기능과 퍼포먼스를 측정하는 공개SW로 100% 순수 자바로 작성되었으며, 본래 웹 애플리케이션을 위해 디자인되고 사용되었으나, 현재는 다른 기능의 테스트를 위해 확장되고 있다. static, dynamic 한 모든 자원(파일, 서블릿, perl script, java object, database and query, ftp, soap 등)에 대해 성능을 테스트할 수 있다.



【그림 III-7. Jmeter 수행 화면 예시】


▣ 테스트 실행


테스트 환경설정

HW와 지원 SW(예, 운영 시스템, 데이터베이스, 미들웨어 등)를 포함한 테스트 환경의 접근 권한을 설정한 후 테스트 대상 모듈을 인스톨한다.


【표 III-13. 테스트 환경구성 예시】
테스트 대상 Version
Moodle 2.0.2+

구성 OS WEB DB
A Stack CentOS 5.3 (64bit) Apache2.2.14
(PHP:5.3.2)
MySQL 5.1.4
B Stack CentOS 5.3 (64bit) Apache2.2.14
(PHP:5.3.2)
PostgreSQL 8.4
C Stack Ubuntu 10.04 (64bit) Apache2.2.17
(PHP:5.3.5)
MySQL 5.0.77
D Stack Ubuntu 10.04 (64bit) Apache2.2.17
(PHP:5.3.5)
PostgreSQL 8.4

제조사 모델명 CPU MEM Disk NIC
IBM X3550M2 Intel Xeon(R)CPU 2.40GHz * 4 8GB 320GB Gigabit 1Port


테스트 케이스 실행

분석/설계 단계에서 설계된 테스트 케이스를 실행하며, 테스트를 수행하면서 발생하는 항목들의 로그를 기록한다. 테스트 케이스 명세서에 기술된 테스트 기준 및 예상결과를 실제 테스트 결과와 비교하고, 일치하지 않거나 문제가 발생한 경우 해당 사항을 기록한다.


【표 III-9. 테스트 케이스 도출 기법 예시】
테스트 케이스 입력데이터 예상결과 실제결과
문서목록보기 Page 목록에서
   다른 사용자가 등록한 문서를 클릭
Add_001 Add_001이 등록한 문서로 이동 PASS
문서내용보기 Page에서 수정버튼을 클릭   정보입력 Page로 이동 PASS
등록한 문서의 내용을 변경한 후 등록버튼 클릭 Test_023.txt 내용보기 Page로 이동 FAIL
변경한 내용이 적용되었는지 확인   Test_023 적용 N/A

【표 III-15. 성능 테스트 케이스 수행 예시】
테스트 목표 상황을 고려한 Workload Model이 적용된 테스트로써 38.23 TPS를 목표로 함
목표치 사용자수 10000 호출간격 44.4
TPS > 38.23 응답시간 Read<1Sec
측정항목 거래 성공 비율, TPS, 응답시간, 시스템 사용률
시나리오 Ramp-UP Model : (100 Users/3초) * 51초(51초 후에 1000 Users 유입, 측정 시작)
1000 User 유입 완료 후 2분 동안 부하 발생, 성능 측정
Ramp-Down Model : (300 Users/초) * 30초(30초 후에 시험 종료)
Think Time Model : 호출 간격(1.4초) - Real 응답 시간
사전 확인 사항 테스트 시작 시간 10:00(AM) 테스트 종료 시간 14:00(PM)
스크립트 수행(N번) 50 부하 발생기 상태 확인  
데이터베이스 상태 확인   시나리오 확인 Load_1, Load_2
Configuration 확인   테스트 데이터 Import Moodle_01


테스트 결과 작성

테스트 케이스 명세서에 해당 테스트 케이스 실행 결과를 작성한다. 테스트 결과 보고는 최종 보고서가 아닌 단순한 테스트 케이스 실행에 대한 결과 보고이다. 본 테스트 결과를 기반으로 최종 결과 보고서를 작성한다.


【표 III-16. 사용자 시나리오 테스트 케이스 수행 결과 예시】
예상결과 실제결과 결함내역
Add_001이 등록한 문서로 이동 PASS  
정보입력 Page로 이동 PASS
 
내용보기 Page로 이동 FAIL Add_001 문서의 내용보기 Page가 아닌 Add_003 문서의 내용보기 Page로
   이동함
Test_023 적용 N/A 위 테스트 케이스 오류로 인해 Test_023이 적용되었는지 확인 불가


【그림 III-8. 성능 테스트 케이스 수행 결과 예시】


▣ 테스트 종료


테스트 결과 보고서 작성

공개SW 역량프라자 테스트 결과서는 시스템의 품질에 대한 객관적 평가 결과를 제공하기 위해 작성되며, 내용은 다음과 같다.


【그림 III-9. 공개SW 테스트 결과 보고서 예시】


결과 정보 제공

공개SW 역량프라자 테스트 결과서는 시스템의 품질에 대한 객관적 평가 결과를 제공하기 위해 작성되며, 내용은 다음과 같다.


【그림 III-10. 공개SW 포털 테스트 결과 보고서】



[연재 차례]

① SW 테스트 이해
② SW 테스트 필요성
③ SW 프로세스
④ SW 프로세스와 테스트
⑤ SW 테스트 프로세스
⑥ SW 테스트 기법
⑦ 공개SW 프로세스
⑧ 공개SW 테스트
⑨ 공개SW 테스트 프로세스
⑩ 테스트 도구
맨 위로
맨 위로