ISO/IEC 25010 품질 특성 정리

2024. 7. 17. 17:21·QA성장하기/테스팅 전문 지식 쌓기

 

 

ISO/IEC 25010은 소프트웨어 제품의 품질 모델을 정의한 국제 표준으로,

소프트웨어 제품의 품질 측정 및 평가하기 위한 기준을 제공하며, 품질향상에 중요한 역할을 한다.

 

나 또한 일할 때, ISO/IEC 25010은 QA를 시작할때마다 어느부분을 봐야할 지 많이 참고하곤 했다.

 

예를 들어, 모바일 애플리케이션을 테스트할 때에는 호환성 테스트를 통해서

다양한 디바이스 및 안드로이드 버전에서 애플리케이션 실행 시, 문제가 없는지 확인하고

리뉴얼을 진행하거나 디자인을 변경하게 될 때에는 사용성을 위주로 사용성을 테스트를 진행했다.

 

이때, 사용자와 밀접하게 만날 수 있어, 휴리스틱 평가방법이나 인지적 워크쓰루 등의 방법도 진행했다.

 

이렇게 ISO/IEC 25010의 모든 내용을 구지 알기보다는 테스트를 진행할 때

소프트웨어 제품의 품질을 체계적으로 평가하고 품질을 향상시킬 때 유용하게 사용된다.

 

아래 내용을 통해 ISO/IEC 25010의 품질구성에 대한 설명과 어떻게 테스트할 수 있는지 확인할 수 있다.


내부/외부 품질

  1. 기능성 : 요구되는 기능을 만족시키는 능력
    1. 기능 성숙성 : 기능 집합이 모든 명시된 요구 사항을 포괄하는 정도.
      • 명세기반 테스트 방법으로 테스트할 수 있음.
      • 사용자 요구사항으로부터 TC추출 및 추적성 정보를 유지하여 시스템의 기능제공 정도를 파악할 수 있음.
    2. 기능 정확성 : 시스템의 정확한 정밀도로 정확한 결과를 제공하는 정도
      • 사용자의 의도된 목적을 달성할 수 있을 정도로 정확하게 동작하는 기능의 수
      • 명세 기반 및 구조 기반 테스트 방법을 사용할 수 있음
    3. 기능 타당성: 기능이 목적 달성에 도움을 주는 정도
  2. 신뢰성 테스트 : 특정 조건에서 특정 기간동안 시스템 요구 서비스를 오작동 없이 제공하는 정도.
    1. 성숙성 : 시스템 또는 구성요소가 정상작동 상태에서 신뢰성 요구를 충족하는 정도.
    2. 결함허용성 : HW나 SW 결함이 있음에도 시스템 또는 구성요소가 의도대로 작동하는 정도
    3. 복구 용이성 : 중단 또는 장애가 발생한 경우, 시스템이 데이터 복구 후 상태 재설정할 수 있는 정도
    4. 가용성 : 사용자가 시스템 또는 구성요소를 사용할 때 사용 및 접근이 가능한 정도.
    5. 신뢰성 테스팅 방법
      • 통계적 테스트 방법 : 시스템 실제 사용자가 쓰는 패턴, 운영 프로파일을 사용하여 테스트 케이스 생성
      • 운영 프로파일 작성 > 각 클래스 발생 확률에 따라 TC 생성
      • 오류 발생 시간과 다음 오류 발생까지 걸리는 동작 시간을 기록 후 신뢰성 추정 모델로 신뢰성 추정
  3. 사용성 테스트 : 사용자가 이해하고 배우기 쉬운 정도
    1. 사용성
      • 특정 사용자들이 주어진 사용 환경에서 특정 목적 달성을 위해 제품 및 시스템을 사용시 효율성/효과성 및 만족도로 정의됨
      • 효과성 : 사용자가 특정 목표를 달성하는 정확성 및 완전성
      • 효율성 : 사용자가 목표달성 정확성 및 완전성 관련 소비되는 자원
      • 만족도 : 지정 환경에서 사용자가 불편함이 없는 정도와 제품 사용에 대한 태도, 사용자 요구 충족 정도
    2. 이해 용이성 : 사용자가 자신의 필요에 시스템이 적합한지 여부를 인식 가능 정도
    3. 학습 용이성 : 사용자가 SW 사용법을 배워 명시된 목적을 달성할 수 있는 정도
    4. 운영성 : 시스템이 쉽게 조작하고 제어할 수 있는 속성을 갖는 정도
    5. 사용자 인터페이스 심미성 : 사용자 인터페이스가 사용자에게 만족스러움을 주는 정도
    6. 사용자 오류 방지성 : 사용자로 하여금 오류를 범하지 않게 하는 정도
    7. 접근성 : 사용자 특성이나 능력에 관계없이 시스템을 사용할 수 있는 정도
    8. 사용성 평가 방법
      • 휴리스틱 평가 : 사용자 평가 전문가가 제품 관련 사용성 원칙을 기준으로 사용성에 관한 문제점을 도출하는 방법.
        • 적은 인원의 전문가를 활용하여 비교적 쉽게 실시할 수 있음
        • 중요한 사용성 문제를 많이 도출할 수 있고 효율적이고 빠르게 수행 가능.
      • FGI : 그룹 인터뷰 방식으로, 주로 시스템 개발 이전에 사용자 요구사항 파악에 많이 쓰이는 평가방식.
      • 인지적 워크쓰루 : 학습 용이성 분석에 중점을 둔 방법
        • 실제 사용자를 대상으로 사전설명 없이 제품을 사용하여 주어진 과제를 달성하도록 함.
        • 과제 달성 각 단계에서 적합한 행동을 취하는 지 분석.
      • 사용성 평가는 시스템 개발 전 주기에 걸쳐 진행되어야 하며 평가 목적에 따라 방법을 달리하는 것이 좋음.
  4. 성능 효율성 테스트 : 적절한 자원의 사용 및 적절한 반응시간 정도
    1. 소프트웨어 시스템 성능
      • 소프트웨어 시스템 성능 평가 요소는 시스템 특성에 따라 주로 결정됨
      • 성능 요구사항은 구체적이면서 검증 가능한 형태로 명세서에 기술되어야 함.
      • 실사용자들의 시스템 사용 패턴, 시스템 운영 프로파일이 필요함.
        • 사용 정보를 수집하지 못한 경우 주위 유사한 시스템이 있는지 살펴보아야 함.
    2. 시간 효율성: 기능 수행 시 시스템 응답/처리시간 및 처리율이 요구 사항을 충족시기키는 정도
    3. 자원 활용성 : 기능 수행 시, 시스템이 사용하는 자원이 요구 사항을 충족시키는 정도
    4. 기억 용량 : 시스템 매개변수의 최대한계가 요구 사항을 충족시키는 정도
    5. 벤치마크 테스트
      • 실존 비교대상을 두고 HW 및 SW 성능을 비교 시험하고 평가하는 것.
      • 시스템이 동작되는 운영 환경 및 작업 부하를 대표해야 함.
      • 부하 테스트 : 부하를 계속 증가시키면서 시스템의 임계점을 찾음
        • 임계점이란, 처리량이 더이상 증가하지 않거나 CPU이용률/메모리 사용량이 비정상적으로 증가하는 지점
        • 이 테스팅을 통해 병목 지점을 찾고 병목 현상을 제거하는 과정 반복.
      • 스트레스 테스팅 : 시스템 처리 능력 이상의 부하, 임계점 이상의 부하를 가하여 비정상적 상황에서의 처리를 테스트함.
      • 스파이크 테스팅 : 짧은 시간에 사용자가 몰릴 때 시스템의 반응을 측정.
      • 내구성 테스트 : 오랫동안 시스템에 높은 부하를 가하여 시스템 반응 파악.
    6. Little's Law와 성능 테스트
      • 시스템에 장기간 머물러있는 고객의 평균 수치 = 오랫동안 걸친 평균 실제 도착률 * 시스템에서 고객이 머문 평균 시간
      • 동시 사용자 = Active user + Inactive user
        • Active user : 요청 후 응답을 기다리는 사용자
        • Inactive user : 세션정보를 가지고 있지만 요청을 보내지 않는 사용자
      • 처리량 : 단위시간동안 시스템에서 처리되는 요청 수 (TPS)
      • 응답 시간 : 요청을 보낸 후 응답이 처리되어 결과가 사용자에게 전달될 때까지 걸리는 시간\
      • 씽크 타임 : 요청 보낸 후 응답결과 수신 후 다음 요청을 보낼때까지 걸리는 시간
      • 요청 간격 : 요청을 보낸 후 다음 요청을 보낼 때까지 걸리는 시간 (=응답시간 + 씽크 타임)
      • 동시 사용자 = TPS * 요청 간격 = TPS * (응답시간 + 씽크 타임)
      • 성능 테스트에서 사용되는 목표 처리량에 요구되는 동시 사용자 수 선정에 사용됨
    7. Ramp up/down
      • Ramp up : 가상 사용자를 이용해 부하를 주는 패턴
        • 가상 사용자를 동시에 유입할지 어느정도 시간 간격에 따라 유입할 지 정의함
      • Ramp down : 성능테스트 종료 후 가상 사용자 수를 줄이는 패턴.
  5. 유지보수성 테스트 : 시스템 수정 및 변경 용이성
    1. 분석성 : 부분의 의도된 변경이 전체 시스템에 미치는 영향 평가 or결함에 대한 진단 및 수정될 부분을 식별가능 정도.
    2. 변경 용이성 : 결함이나 품질 저하 없이 효과적/효율적으로 수정될 수 있는 정도
    3. 테스트 용이성 : 테스트 수행을 용이하게 하는 정도
    4. 모듈성 : 시스템 또는 컴퓨터 프로그램이 개별 구성요소로 구성된 정도
    5. 재사용성 : 시스템 자산이 하나이상의 시스템에서 사용될 수 있는 정도
    6. 유지보수성 테스팅 방법
      • 모듈성/분석성/재사용성/변경 용이성
        • 모듈화 정도 / 모듈 간 결합도 / 모듈 응집도 / 모듈 복잡도 특성을 검토해야 함.
        • 모듈화는 시스템 분할 후 각 부분이 정의된 기능을 잘 수행하도록 하는 설계기법
        • 모듈화 측정 척도 : fan-in / fan-out
          • fan-in : 주어진 모듈을 호출하는 모듈 수
          • fan-out : 주어진 모듈이 호출하는 모듈 수
          • fan-in과 fan-out이 높으면 모듈 변경 시, 많은 모듈이 영향을 받아 정적 분석에서 식별 후 재구성해야 함.
        • 모듈간의 결합도는 낮게 설계되어야 한다.
          • 모듈 결합도가높다 = 모듈이 의존하는 모듈들이 변경될 때 영향을 받을 가능성이 큼
        • 모듈의 응집도는 높을수록 좋다.
          • 모듈의 응집도는 개개의 모듈을 구성하는 요소가 얼마나 관련되어있는가를 나타냄
          • 응집도가 높을수록 다른 모듈에 의존 관계가 낮아 재사용성이 좋음.
        • 모듈의 복잡도는 낮을수록 좋다.
          • 모듈의 복잡도가 높은 경우, 결함수정을 위해 수행한 작업이 새 결함을 발생시킬 가능성이 매우 큼
          • 정적 분석으로 순환복잡도가 높은 모듈 식별 후 리팩토링/재구성을 통해 낮게 만들 필요가 있음.
          • 리팩토링 : 외부 동작을 바꾸지 않으면서 내부 코드를 개선하는 방식.
      • 테스트 용이성
        • 제어 용이성 : 프로그램 실행 제어가 용이하도록 설계함 (제어용이성이 높을수록 테스트 자동화 부분이 많아지고 최적화가 가능)
        • 관찰 가능성 : 프로그램 내부 상태가 어떤 상태인지 쉽게 파악할 수 있는 기능을 갖추도록 설계
        • 단순성 : 가능한 시스템 구조 등을 단순하게 설계
          • 코딩 표준에 따라 프로그램을 작성하여 쉽게 코드를 이해할 수 있게 함
          • 프로그램 구조를 단순화하여 결함이 발생했을 때 다른 곳으로 쉽게 전이되지 않도록 설계
        • 분할 용이성 : 테스트할 대상 영역 제어를 통해 문제 발생 위치를 고립 후 독립적인 모듈테스트 수행 가능하도록 설계
        • 운영 용이성 : 프로그램 결함이 발생해도 테스트 작업을 계속할 수 있도록 설계
        • 안전성 : 테스트 중 소프트웨어 변경이 자주 발생하지 않도록 설계
        • 이해 용이성 : SW 설계 정보가 잘 조직화되어 쉽게 접근 가능하도록 하여 이해 용이성을 높임
  6. 이식성 테스트 : 사용자의 HW/SW 환경이 달라도 동등한 서비스를 제공하는 지 테스트
    1. 적응성 : 시스템이 다른 HW/SW 혹은 기타 사용 환경에 효과적/효율적으로 적용 가능 정도
    2. 설치 용이성 : 특정 환경에서 시스템을 성공적으로 설치 및 제거할 수 있는 정도
    3. 치환성 : 시스템이 동일 환경에서 동일 목적을 위해 다른 지정된 소프트웨어 제품으로 대체될 수 있는 정도.
  7. 호환성 테스트 :  다른 시스템과의 상호 연동 능력.
    1. 상호공존성 : 다른 SW에 나쁜 영향을 미치지 않고 자원을 공유하면서 기능을 효율적으로 수행하는 정도
      1. 시스템의 장애 발생이 인명손실 및 막대한 재산 피해를 가져올 수 있는 안전성 필수 시스템에서 매우 중요함.
    2. 상호운영성 : 둘 이상의 시스템 또는 구성요소가 정보 교환 및 교환정보를 사용할 수 있는 정도
      1. 사물인터넷 혹은 국방정보시스템을 구축할 때 매우 중요함.
  8. 보안성 테스트 : 정보 및 데이터를 보호하는 능력.
    1. 기밀성 : 접근 권한이 있는 사람에게만 데이터에 액세스할 수 있도록 하는 정도
    2. 무결성 : 시스템 또는 구성요소가 컴퓨터 프로그램 또는 데이터에 무단접근 혹은 이의변경을 방지하는 정도
    3. 부인 방지성 : 사건 및 행위 후 부인 못하도록 입증할 수 있는 정도
    4. 책임성 : 각 개인을 유일하게 식별하여 행위기록 및 행위자 추적할 수 있는 능력
    5. 인증성 : 사건 및 행동에 대해 실제 행위자임을 증명가능한 정도.
    6. 보안성 테스팅 방법
      • 침입 테스트 : 해커의 관점에서 소프트웨어 시스템 취약성을 찾는 테스트 방법.
        • 가능한 많은 침입 시나리오들을 이용하여 소프트웨어 취약성을 찾고 해결책을 제시
      • 정적 분석 : 보안성 높은 SW가 준수해야할 소스코드 수준에 코딩 규칙 정의 후 준수하는지 분석

'QA성장하기 > 테스팅 전문 지식 쌓기' 카테고리의 다른 글

네트워크 에뮬레이터 키트 (NEWT for windows) 설치 및 사용방법.  (0) 2024.08.02
네트워크 테스트 준비사항 및 도구  (0) 2024.08.01
테스트 시나리오, 테스트 스크립트, 테스트 케이스의 차이  (0) 2024.07.01
테스트 종료 보고서 만들어보기.  (0) 2024.06.28
테스트 계획서 만들어보기.  (0) 2024.06.27
'QA성장하기/테스팅 전문 지식 쌓기' 카테고리의 다른 글
  • 네트워크 에뮬레이터 키트 (NEWT for windows) 설치 및 사용방법.
  • 네트워크 테스트 준비사항 및 도구
  • 테스트 시나리오, 테스트 스크립트, 테스트 케이스의 차이
  • 테스트 종료 보고서 만들어보기.
몽자비루
몽자비루
코딩공부 정리용 블로그입니다.
  • 몽자비루
    공부하는 블로그
    몽자비루
  • 전체
    오늘
    어제
    • 분류 전체보기 (165)
      • python (30)
        • python_selenium (16)
        • python_pygame (3)
      • appium (0)
      • 쿠버네티스 (60)
        • linux (8)
        • shell programming (8)
        • docker (18)
        • cka (23)
      • postman&API (16)
      • QA성장하기 (30)
        • 개발자에서 아키텍트로 스터디 (6)
        • 소프트웨어 공학 이해도 높이기 (6)
        • 테스팅 전문 지식 쌓기 (18)
      • 에러일기 (1)
      • AWS (27)
      • Jmeter (0)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

  • 공지사항

  • 인기 글

  • 태그

    테스트 계획서 만들어보기
    qa
    .cpu
    도커
    LOSTARK
    python
    vi에디터
    postman
    테스트 결과보고서
    리눅스
    네트워크 테스트
    application log
    API
    개발자에서아키텍트로
    linux
    앱공존성
    애플리케이션로그
    e2c
    테스트스크립트
    스터디
    사드웨어리소스
    cka
    로스트아크
    쿠버네티스
    k8s
    테스트 계획서
    QAKOREA
    로스트아크api
    포스트맨
    공존성테스트
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.3
몽자비루
ISO/IEC 25010 품질 특성 정리
상단으로

티스토리툴바