UI 테스트는 주로 무엇을 측정합니까?

사용자 인터페이스의 배색, 전체 레이아웃, 행간, 정렬, 균일한 스타일 등을 테스트합니다. 또한 일부 컨트롤이 합리적인지 여부, 프롬프트 정보 및 페이지 정보에 구문 오류가 있는지 여부 등이 있습니다. 특히 테스트는 일반적으로 다음과 같은 목표를 달성해야 합니다.

1. 제품의 약속 또는 발표 기능을 보장하며, 모든 사용자가 액세스할 수 있는 기능에는 명확한 서면 설명이 있습니다. 어떤 의미에서 iso900 1 은 아이디어입니다.

명확한 서면 서류가 없는 것은 공장의 단기 행위로 무책임한 표현이다. 단기적 행동이란 명확한 서면 서류가 부족하여 제품의 원활한 배달에 불리하고, 사용자와 충돌하기 쉬우며, 공급업체의 신용도와 향후 사용자와의 협력에 영향을 주는 것을 말합니다. 제품의 사후 유지 관리에도 불리하며, 공급업체는 사용자 교육 및 기술 지원 비용을 너무 많이 지출할 수 있습니다. 장기적인 이익으로 볼 때, 이것은 수지가 맞지 않는다. 지도자가 접촉한 소프트웨어 제품은 매우 적고, 큰 제품, 얇은 문서이다.

물론, rad (Rapid Prototyping Act) 개발 프로젝트에서는 서면 문서의 작성과 유지가 가장 중요하고, 가장 어렵고, 간과하기 쉽다.

마지막으로, 서면 문서의 미비, 심지어 부정확함도 테스트 작업에서 가장 큰 골칫거리입니다. 직접적인 결과는 테스트 효율이 낮고, 테스트 목표가 불분명하며, 테스트 범위가 부족해 최종 테스트의 역할을 충분히 발휘하지 못하고, 테스트 결과가 좋지 않다는 것이다.

제품이 성능 및 효율성 요구 사항을 충족하는지 확인하십시오.

비효율적 (성능 저하), 사용자 인터페이스가 불친절하고 사용자 조작이 불편한 (비효율적인) 제품은 경쟁력 있는 제품이라고 할 수 없습니다.

사용자가 가장 염려하는 것은 당신의 기술이 얼마나 진보하고 강한지가 아니라, 그가 이러한 기술과 기능으로부터 얼마나 많은 이익을 얻을 수 있느냐이다. (알버트 아인슈타인, 지식명언) 다른 말로 하자면, 사용자가 관심을 갖는 것은 그가 얼마나 많은 것을 꺼낼 수 있느냐가 아니라, 네가 얼마를 투입했는지가 아니다.

제품이 견고하고 사용자 환경에 적응할 수 있는지 확인하십시오.

견고성, 즉 안정성은 제품 품질의 기본 요구 사항, 특히 업무 또는 시간에 중요한 작업 환경입니다.

또한 일부 프로젝트를 제외한 사용자의 환경을 가정할 수 없습니다. 예를 들어, 많은 신문사 사용자의 구성이 비교적 낮으며 일부 타사 제품과 함께 사용됩니다.

테스트의 원칙-충분히 좋다

비교적 복잡한 제품이나 시스템에 대해 0 버그는 이상적이고 충분히 좋은 것이 우리의 원칙이다.

충분한 원칙은 입/출력 비율을 측정하는 원칙이다. 테스트가 불충분하다는 것은 무책임하다. 과잉 테스트는 자원에 대한 낭비이자 무책임한 표현이다. 우리의 운영상의 어려움은 어떤 테스트가 부족한지, 어떤 테스트가 과도하다는 것이다. 현재 사용할 수 있는 유일한 답은 가장 낮은 시험 합격 기준과 시험 내용을 제정하고 구체적인 문제를 구체적으로 분석하는 것이다. 가장 분명한 예는 중국판 fit3.0 의 제품 테스트입니다.

검사의 법칙-코니킨의 법칙과 80-20 의 원리

1, 코니킨의 법칙.

소프트웨어 제품 생산에서, 그것은 전면적인 품질 관리 (TQM) 의 개념이다. 제품 품질의 핵심 요소는 분석, 설계 및 구현입니다. 테스트는 검사의 보조 수단이어야 합니다. 기타 관리, 지원 및 문화적 요인도 최종 제품의 품질에 영향을 줄 수 있습니다. 검사는 제품의 품질을 향상시키는 데 필요한 조건이자 가장 직접적이고 빠른 수단이지만 결코 근본적인 수단은 아니라고 말해야 한다. 반면에, 제품의 품질을 높이는 모든 무게를 테스트에 올려놓는다면, 그것은 끔찍하고 긴 재앙이 될 것이다.

벌레의 80-20 원칙.

일반적으로 80% 의 버그는 분석, 설계 및 구현 단계의 검토 및 테스트 작업에서 발견되고 피할 수 있으며 나머지 80% 의 버그는 시스템 테스트에서 찾을 수 있습니다. 마지막 5% 의 버그는 사용자가 광범위하게 장기간 사용한 후에만 노출될 수 있다. 테스트는 가능한 많은 오류를 발견할 수 있을 뿐, 모든 오류를 발견할 수 있다는 보장은 없기 때문이다.

소프트웨어 테스트 방법:

1, 프로그램의 내부 구조를 점검할지 여부에 따라 다음과 같이 구분됩니다.

(1) 블랙박스 테스트: 입력과 출력에만 관심이 있습니다.

(2) 화이트 박스 테스트: 내부 소스 코드와 프로그램 구조를 연구합니다.

2, 프로그램 실행 여부에 따라 다음과 같이 나뉩니다.

(1) statictesting: 테스트된 소프트웨어를 실제로 실행하지 않고 정적 검사기 코드, 인터페이스 또는 문서에 있을 수 있는 오류를 나타내는 프로세스입니다.

정적 테스트에는 다음이 포함됩니다.

코드 테스트의 경우 주로 코드가 해당 표준 및 사양을 충족하는지 테스트합니다.

인터페이스 테스트의 경우 주로 소프트웨어의 실제 인터페이스가 요구 사항에 부합하는지 테스트하는 것입니다.

문서 테스트의 경우 주로 사용자 설명서와 요구 사항 설명이 사용자의 실제 요구 사항을 충족하는지 테스트합니다.

(5) 동적 테스트 (dynamictesting) 는 테스트 프로그램을 실제로 실행하고 해당 테스트 데이터를 입력하여 출력이 예상 결과와 일치하는지 확인하는 프로세스입니다.

3, 단계에 따라:

(1) 단위 테스트는 검사 및 검증 소프트웨어에서 가장 작은 테스트 가능 단위입니다.

Stud 모듈은 시뮬레이션된 테스트중인 모듈에 의해 호출되는 모듈이고, 드라이버 모듈은 시뮬레이션된 테스트중인 모듈의 상위 모듈입니다. 구동 모듈은 테스트 데이터를 수신하고, 테스트된 모듈을 시작하고, 결과를 출력하는 데 사용됩니다.

(2) 통합 테스트 (integrationtesting) 는 다음 단계의 단위 테스트로, 테스트를 통과한 단위 모듈을 시스템 또는 하위 시스템으로 조립한 다음 다른 모듈의 인터페이스 부문에 초점을 맞춘 테스트를 말합니다.

통합 테스트는 각 장치 모듈이 함께 작동하여 정상적으로 작동하는지 확인하는 데 사용됩니다.

(3) 시스템 테스트 (systemtesting) 는 전체 소프트웨어 시스템을 하나의 단위로 테스트하는 것으로, 테스트 기능, 성능 및 소프트웨어가 실행되는 하드웨어 및 소프트웨어 환경을 포함합니다.

시스템 테스트의 주요 근거는 문서 시스템 요구 사항 사양입니다.

(4) 수용 테스트 (acceptancetesting) 는 시스템 테스트 후기에 주로 사용자 또는 테스터와 같은 품질 보증 담당자가 참여하는 테스트이며 소프트웨어가 사용자에게 정식으로 인계하는 마지막 절차입니다.

수락 테스트는 A 테스트와 베타 테스트로 구분됩니다. 여기서 A 테스트는 사용자, 테스터 및 개발자가 함께 참여하는 내부 테스트이며 베타 테스트는 내부 테스트 후 공개 테스트로, 최종 사용자에게 완전히 전달되어 테스트됩니다.

4, 블랙 박스 테스트는 기능 테스트와 성능 테스트로 구분됩니다.

1) 기능 테스트는 블랙박스 테스트의 한 측면으로 실제 소프트웨어의 기능이 사용자의 요구를 충족하는지 확인합니다.

논리적 기능 테스트를 포함합니다.

Ui 테스트 ui = 사용자 인터페이스

가용성 테스트 (Usabilitytesting): 소프트웨어 사용의 합리성, 편리성 등의 관점에서 소프트웨어 시스템을 검사하여 소프트웨어에서 사용자가 사용하기 불편한 곳을 찾는 것을 말합니다.

호환성 테스트: 하드웨어 호환성 테스트 및 소프트웨어 호환성 테스트가 포함됩니다.

2) 성능 테스트

소프트웨어 성능에는 주로 시간 성능과 공간 성능이 포함됩니다.

시간 성능: 주로 소프트웨어별 트랜잭션의 응답 시간을 나타냅니다.

공간 성능: 주로 소프트웨어 런타임 시 소비되는 시스템 리소스를 나타냅니다.

소프트웨어 성능 테스트는 다음과 같이 구분됩니다.

일반 성능 테스트: 테스트된 시스템이 압력을 가하지 않고 정상적인 하드웨어 및 소프트웨어 환경에서 작동할 수 있도록 하는 성능 테스트입니다.

안정성 테스트 (Stability testing) 는 안정성 테스트 (reliabilitytesting) 라고도 하며, 테스트 시스템이 지속적으로 실행되어 실행 중 시스템의 안정성을 확인하는 것을 의미합니다.

로드 테스트 (Loadtesting): 테스트된 시스템이 견딜 수 있는 압력 한계 내에서 계속 실행되도록 하여 시스템의 안정성을 테스트합니다.

스트레스 테스트 (Stresstesting): 테스트된 시스템이 충돌할 때까지 테스트된 시스템의 압력을 계속 늘려 시스템이 견딜 수 있는 최대 압력을 테스트하는 것을 말합니다. (validatethesystemorsoftwarecanallowedthebiggeststress. ) 을 참조하십시오

5. 기타 테스트 유형:

회귀 테스트 (Regressiontesting) 는 새 버전의 소프트웨어를 테스트하고 이전 버전의 사용 사례를 반복적으로 테스트하는 것을 의미합니다. (anewbuildorreleaseisdeployed 는 실행된 테스트 케이스를 재사용합니다. ) 을 참조하십시오

연기 테스트 (Smoketesting) 는 새로운 버전을 대규모로 테스트하기 전에 소프트웨어의 기본 기능이 구현되고 테스트 가능한지 확인하는 것을 의미합니다. (validatethemajorfunctionisdeployedornotinoftwareofsystemwhanewbuildorreleaseisimplement. ) 을 참조하십시오

Randomtesting 은 테스트의 모든 입력 데이터가 무작위로 생성되는 것을 의미하며, 이는 사용자의 실제 작업을 시뮬레이션하여 몇 가지 한계 오류를 찾아내는 것입니다. (sorallthetestdataisrandom, tovalidatethesomeedgebugs 를 의미합니다. ) 을 참조하십시오

소프트웨어 테스트에는 다음 단계가 포함됩니다.

1. 테스트 계획 개발

테스트 케이스를 디자인하고,

3. 테스트 구현 (먼저 테스트 환경을 구축해야 함)

4. 테스트에서 발견된 오류를 관리합니다.

5. 테스트 후 (테스트 후 발견된 오류가 수정됨)

6. 테스트 보고서를 작성합니다 (이렇게 하면 테스트 프로세스가 종료되고 각 테스트 유형 (단위 테스트, 통합 테스트, 시스템 테스트, 검증 테스트) 이 동일합니다.