소프트웨어 평론가 - 소프트웨어 테스팅

소프트웨어 테스트 및 소프트웨어 품질

소프트웨어 테스트의 고전적인 정의(자세한 자습서 참조)

为了发现软件中存在的错误而进行的操作。目的：为了发现错误

소프트웨어 테스팅 목적

• 소프트웨어에서 버그 찾기
  软件测试只能证明软件中存在错误，不能证明软件没有错误。

소프트웨어 테스트 대상

• 소프트웨어 코드
• 문서
• 데이터

데이터베이스 테스트 개체

• 데이터베이스 연결
• 데이터베이스 보안 테스트
• 데이터베이스 인터페이스 테스트
• 정의된 저장 프로시저 및 트리거 테스트

소프트웨어 품질

소프트웨어는 特性的总和
또한 지정된 또는 잠재적인 사용자 요구를 충족시키며 能力
소프트웨어 기능의 "기능"을 나타냅니다.

구성

• 내부 품질
• 외부 품질
• 사용 품질 - 사용자의 관점에서

품질 보증(QA) VS 소프트웨어 테스팅

【품질 보증】

• 소프트웨어 완성의 전 과정에서 소프트웨어 개발 과정을 중심으로 过程, 步骤그리고 产物.
  【소프트웨어 테스트】
• 프로세스에 신경 쓰지 않고 프로세스에만 신경을 쓰는 활동 产物.
• 중요한 작업: 문제 분석, 추적 및 회귀 테스트
• 소프트웨어 품질 보증의 중요한 부분입니다.

소프트웨어 제품 품질 평가 기준

• 내부 물성을 측정하여
• 외부 특성 측정 可靠性등
• 사용 품질의 속성을 측정하여 - 生产率, 安全性, 满意度,有效性
  

소프트웨어 테스팅의 원칙(6)

• 모든 테스트는 사용자 요구 사항을 추적해야 합니다(요구 사항 준수).
• 조기에 지속적으로 테스트해야 함
• 테스트 작업은 원래 소프트웨어를 개발한 사람이나 팀이 피해야 합니다(단위 테스트 또는 모듈 테스트 제외).
• 철저한 테스트가 불가능하며 테스트를 종료해야 합니다.
• 테스트에서 클러스터 현상에 주의하십시오.
• 테스트의 무작위성을 피하기 위해 테스트 계획을 엄격히 따르십시오.

소프트웨어 테스트 분류

개발 단계 구분 (5)

• 단위 테스트
• 통합 테스팅
• 시스템 테스트
• 확인 테스트
• 승인 테스트

단위 테스트(모듈 테스트)

• 프로그램 내부 구조에서 테스트 케이스 설계 필요
• 여러 모듈을 병렬 및 독립적으로 단위 테스트할 수 있습니다.

테스트 내용

• 所调用的模块스텁 모듈 - 상위 모듈을 테스트하는 데 사용되는 테스트 중인 모듈 시뮬레이션
• 上一级模块드라이버 모듈 - 하위 모듈을 테스트하는 데 사용되는 테스트 중인 모듈을 시뮬레이션합니다.

통합 테스트(조립 테스트, 공동 테스트)

관련된 문서

• 아웃라인 디자인 문서
• 상세 설계 문서

조립 시 고려 사항

• 모듈을 연결할 때 모듈 인터페이스를 통과하는 데이터가 손실됩니까?
• 한 모듈의 기능이 다른 모듈의 기능에 부정적인 영향을 미치는지 여부
• 다양한 하위 기능의 조합이 기대하는 상위 기능을 달성할 수 있는지 여부
• 전역 데이터 구조에 문제가 있습니까?
• 각 모듈의 누적 오류가 허용할 수 없는 수준으로 확대되는지 여부

모듈 조립 방법

• 1회 조립(빅뱅) - 모든 1회 조립 후 테스트(소형 소프트웨어에 적합)
  장점: 조작이 간단하고 비용이 저렴함
  단점: 테스트 중 발견된 문제점 찾기 어려움
• 부가 가치 조립
  [1] 하향식 부가 가치 방식
  장점: 분기 오류 찾기가 쉽다
  단점: 테스트가 끝날 때까지 오류가 발생하기 쉬운 하위 모듈을 찾을 수 없음
  [2] 상향식 부가 가치 방식
  [3] 혼합부가가치 방식

완료 표시

• 다음에 测试计划지정된 모든 통합 테스트
• 발견된 버그 수정
• 테스트 결과가 특수 그룹의 검토를 통과했거나 업계 표준에 도달했습니다.

시스템 테스트

• 소프트웨어가 시스템 정의를 따르지 않거나 모순되는 부분을 찾으십시오.
• 전체 시스템 요소 통합(하드웨어, 주변 장치, 네트워크, 인력 및 시스템 소프트웨어, 지원 플랫폼 등 포함)

확인 테스트

• 소프트웨어의 기능 및 성능이 요구 사항과 일치하는지 확인
• 유효성 테스트 수행 - 일반적으로 블랙 박스 테스트
• 소프트웨어 구성 검토

一般由独立的第三方测试机构进行，应当严格遵守操作手册和用户手册规定的使用步骤，以便检查文档资料的完整性和正确性

승인 테스트

• 用户为主
• 일반적으로 프로덕션에서 실제 데이터를 테스트용으로 사용
• 시스템을 수락할지 거부할지 결정

시험기술학부

• 화이트 박스 테스트
• 블랙박스 테스트
• 그레이 박스 테스트

조직 테스트 구현

• 개발자 테스트(α 테스트)
  ——테스터: 개발자 기반
  ——테스트 환경: 개발 환경 아래
• 사용자 측 테스트(β 테스트)
  - 테스터: 사용자
  - 테스트 환경: 사용자의 애플리케이션 환경에서
• 제3자 테스트(독립 테스트)
  - 테스터: 제3자 독립 테스트 기관

소프트웨어 테스팅 프로세스 모델

V 모델

• 저수준 테스트: 소스 코드 정확성 테스트(단위 테스트, 통합 테스트)
• 높은 수준의 테스트: 사용자 요구 사항 테스트(시스템 테스트, 승인 테스트)

V 모델 제한 사항

• 테스트는 소프트웨어 개발이 완료된 후에 수행되며 "조기 및 지속적 테스트"와 상충됩니다.
• 초기 문제(요구 사항 또는 설계 문제)가 끝까지 발견되지 않아 문제 해결 비용이 크게 증가합니다.

W 모델

W 모델 특징

• 문제의 조기 발견에 도움이 되며 "조기 및 지속적인 소프트웨어 테스트" 원칙을 반영합니다.
• 테스트가 전체 소프트웨어 개발 주기에 수반됨을 강조
• V-모델의 소프트웨어 및 개발 단계에서 동시에 수행해야 하는 테스트 추가

W 모델 제한 사항

소프트웨어 개발 및 테스트는 전후 선형 관계를 유지하며 다음 단계가 공식적으로 시작되기 전에 이전 단계가 완전히 완료되었음을 나타내는 엄격한 지침이 필요합니다. 이는 반복, 자발성 및 변화에 대한 조정을 지원하지 못합니다.

H모델

• 소프트웨어 테스팅 모델은独立的流程
• 테스트 시점이 준비되면 소프트웨어 테스트는 테스트 준비 단계에서 테스트 실행 단계로 이동합니다.

X 모델

• 위치探索性测试
  

예비 모델

• 비즈니스 요구 사항은 설계 및 개발 전에 가장 잘 정의됩니다.
• 비즈니스 요구에 기반한 테스트 설계를 옹호하며 设计阶段테스트 실행 및 테스트 설계를 위한 최적의 시기라고 생각합니다.
• 테스트 실행과 개발을 결합하여 “编码-测试-编码-测试-编码-测试”개발 단계에 반영하고, 전달된 각각의 개발 결과는 일정한 방식으로 테스트되어야 함
• 验收测试独立于技术测试, 디자인 및 프로그램 코딩이 최종 사용자의 요구를 충족시킬 수 있도록 보장
  여러 테스트 모델 비교
  일반적인 테스트 모델의 상세 비교

테스트 흐름

입력 스트림

• 소프트웨어 구성(요구사항 명세, 개요 설계 명세, 세부 설계 명세 등)
• 테스트 구성
• 테스트 도구

소프트웨어 장애 분류 및 관리 - 주요 문제 조사

소프트웨어 오류 용어

• 1. 소프트웨어 人为오류——
• 2. 소프트웨어 결함——제품 설명서와 비교偏差
• 3. 소프트웨어 오류 - 内部상태
• 4. 소프트웨어 오류 - 外部행동 결과

소프트웨어 오류의 원인

주요: 제품 설명서에 문제가 있습니다.
보조: 소프트웨어 디자인 설명서에 문제가 있습니다.

소프트웨어 오류 상태(6)

• 새로운 정보 새로운
• 열다 열다
• 고치다
• 거절
• 연기
• 닫기 닫기

자동화 테스트 관련 도구

품질 모델 사용

시스템/소프트웨어 제품 모델

테스트 기록의 내용

• 测试计划또는 테스트 케이스测试规格说明
• 테스트에 관련된 人员신원
• 结果다음을 포함하여 테스트 케이스와 관련된 모든 것所有失败

소프트웨어 테스트 위험의 주요 원인

• 测试计划불충분하다
• 测试过程편차
• 测试方法잘못된