정보마당
9. 공개SW 테스트 프로세스
▣ 분석/설계
공개SW 시스템의 특성을 고려하여 적합한 테스트 목표 및 실행 전략, 테스트 범위, 접근 방법, 테스트 수행 시 요구되는 자원(도구 포함)등을 사전에 정의하여 프로젝트 수행 시 원활한 테스트 수행을 위한 사전 작업을 진행한다.
● 테스트 대상 매뉴얼 및 SW 기능 구조 파악
시스템과 관련된 기능을 분석하고 그 기능과 관련된 테스트 요소를 정의한다. 테스트 수행 시 기능 리스크 분석을 통해 테스트 케이스 설계 시 필요한 요소를 파악할 수 있다. 단, SW가 사용하기 쉽지 않다면 처리 결과가 부정확할 수 있다.
| 리스크 요소 | 개발사 리스크 | 사용자 리스크 | ||||||
| 리스크 아이템 | 추가된 기능 |
상호관계 | 기능 중요도 |
결함 발생률 |
사용자 취급 중요도 |
안정적 피해 |
사용 빈도 |
외부적 가시성 |
| 회원가입 | 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 |
● 테스트 케이스 및 시나리오 설계
프로젝트 범위 및 상위 요구사항을 분석하여 테스트 범위를 설정한다. 테스트를 통하여 적합성을 검증 받아야 할 테스트 범위는 대상 시스템 전체가 될 수도 있고, 경우에 따라 일부분이 될 수도 있다.
선정된 테스트 범위는 향후 테스트 단계별 상세계획 수립 시, 요구분석 및 설계 단계에서 정의된 각 테스트 요구사항 들을 검토하여 테스트 항목, 테스트할 항목의 특성과 테스트하지 않을 항목의 특성을 명세화 하는 기반 자료로 활용된다.
| 테스트 단계 | 테스트 유형 | 내용 |
| 단위테스트 | 기능 | ▶ 개별 Component의 기능 테스트 ▶ 단위 업무 기능 테스트 |
| 표준준수 | ▶ 표준 준수여부 체크 | |
| 보안 | ▶ 단위 프로그램 내 사용자별 기능 제한 사항 체크 | |
| 성능 | ▶ 대상 단위업무에 대한 개별 성능 측정 | |
| 통합테스트 | Component통합 | ▶ Component 통합 하에서 기능 테스트 : 단위테스트에서 수행되기도 함 |
| 데이터 연계 | ▶ 업무 처리 흐름에 따른 데이터 흐름 테스트 | |
| 시스템 간 통합 | ▶ 타 시스템과의 프로세스I/F 테스트 ▶ 타 시스템간의 데이터 I/F 테스트 |
|
| SW 통합 | ▶ 가능한 SW 구성에 따른 시스템의 운영여부 테스트 | |
| HW 통합 | ▶ 시스템 구성 HW 간의 I/F 테스트 | |
| 보안 | ▶ 사용자별 접근 제한(통합환경) | |
| 시스템 기능 | ▶ 단위 테스트와 통합과정에서 이루어졌던 기능 중 시스템 전반에 걸친 주요 기능에 대해 테스트 |
|
| 성능 | ▶ 사용자 수 대비 응답시간 측정 | |
| 시스템테스트 | 볼륨 | ▶ 시간당 대상 업무에서 처리될 수 있는 최대 건수 측정 |
| 스트레스 | ▶ 시스템의 한계상황 하에서의 부족한 리소스 및 시스템 상태 확인 | |
| 구성 | ▶ SW들의 구성, SW 환경설정, HW의 물리적 구성 등에서 최적의 운영환경 발견하기 위한 테스트 |
|
| 보안 | ▶ 시스템 접근 제한에 대한 테스트 | |
| 설치 | ▶ 시스템의 설치 및 인스톨 프로그램의 설치 테스트 |
| 순번 | 대분류 | 중분류 | 소분류 | 시나리오 명 | 시나리오 개요 |
| 1 | 콘텐츠 관리 | 파일 삭제 | 사용자 | 사용자의 파일 접근 권한 |
▶ 일반 사용자가 등록되어 있는 콘텐츠에 접근하여 삭제할 수 있는 권한이 있는지 확인한다. |
| 2 | 관리자 | 관리자의 파일 접근 권한 |
▶ 관리자가 등록되어 있는 콘텐츠에 접근하여 삭제할 수 있는 권한이 있는지 확인한다. |
| 순번 | 테스트 케이스 | 입력데이터 | 예상결과 |
| 1 | ▶ 문서목록보기 Page 목록에서 다른 사용자가 등록한 문서를 클릭 | Add_001 | Add_001이 등록한 문서로 이동 |
| 2 | ▶ 문서내용보기 Page에서 수정버튼을 클릭 | 정보입력 Page로 이동 | |
| 3 | ▶ 등록한 문서의 내용을 변경한 후 등록버튼 클릭 | Test_023.txt | 내용보기 Page로 이동 |
| 4 | ▶ 변경한 내용이 적용되었는지 확인 | Test_023 적용 |
| 테스트 목표 | ▶ 상황을 고려한 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(예, 운영 시스템, 데이터베이스, 미들웨어 등)를 포함한 테스트 환경의 접근 권한을 설정한 후 테스트 대상 모듈을 인스톨한다.
| 테스트 대상 | 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 |
● 테스트 케이스 실행
분석/설계 단계에서 설계된 테스트 케이스를 실행하며, 테스트를 수행하면서 발생하는 항목들의 로그를 기록한다. 테스트 케이스 명세서에 기술된 테스트 기준 및 예상결과를 실제 테스트 결과와 비교하고, 일치하지 않거나 문제가 발생한 경우 해당 사항을 기록한다.
| 테스트 케이스 | 입력데이터 | 예상결과 | 실제결과 |
| ▶ 문서목록보기 Page 목록에서 다른 사용자가 등록한 문서를 클릭 |
Add_001 | Add_001이 등록한 문서로 이동 | PASS |
| ▶ 문서내용보기 Page에서 수정버튼을 클릭 | 정보입력 Page로 이동 | PASS | |
| ▶ 등록한 문서의 내용을 변경한 후 등록버튼 클릭 | Test_023.txt | 내용보기 Page로 이동 | FAIL |
| ▶ 변경한 내용이 적용되었는지 확인 | Test_023 적용 | N/A |
| 테스트 목표 | ▶ 상황을 고려한 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 | ||
● 테스트 결과 작성
테스트 케이스 명세서에 해당 테스트 케이스 실행 결과를 작성한다. 테스트 결과 보고는 최종 보고서가 아닌 단순한 테스트 케이스 실행에 대한 결과 보고이다. 본 테스트 결과를 기반으로 최종 결과 보고서를 작성한다.
| 예상결과 | 실제결과 | 결함내역 |
| 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 테스트 프로세스 ⑩ 테스트 도구 |
0개 댓글