Android 앱 테스트 프로세스와 일반적인 문제는 무엇입니까?

1. 자동화된 테스트

자동화된 테스트에는 주로 여러 부분, UI 기능의 자동화된 테스트, 인터페이스의 자동화된 테스트 및 기타 전문적인 자동화된 테스트가 포함됩니다.

1.1 UI 기능 자동화 테스트

자동화 테스트라고도 알려진 UI 기능 자동화 테스트는 주로 UI 인터페이스를 기반으로 하는 자동화 테스트로, 수동 자동화 테스트를 대체하는 UI 기능 클릭이 스크립트를 통해 구현됩니다.

이 테스트의 장점은 반복성이 높은 인터페이스 기능 테스트를 위해 테스트 인력을 효과적으로 방출하고 스크립트 실행을 사용하여 빠르고 효율적인 기능 반환을 달성한다는 것입니다.

그러나 이러한 종류의 테스트에는 높은 유지 관리 비용, 쉬운 판단, 불충분한 호환성 등의 단점도 분명합니다. 인터페이스 운영을 기반으로 하기 때문에 인터페이스의 안정성이 스크립트 유지에 가장 큰 제약이 되었습니다. 자주 변경되는 인터페이스 상호 작용은 테스트 케이스 스크립트를 지속적으로 업데이트해야 하며 많은 양의 테스트 리소스를 차지한다는 것을 의미합니다.

=

오판이 발생하기 쉬운 이유는 주로 UI 컨트롤을 기반으로 한 식별로 인해 네트워크 상태, 기기 구성, 테스트 환경 등에 따라 로딩이 느려지거나 비정상적인 로딩이 발생하기 쉽고, 이로 인해 테스트 케이스 실행 시 부정확한 판단이 발생할 수 있기 때문입니다. 따라서 테스트의 정확성에 영향을 미칩니다. 호환성이 부족하다는 것은 주로 다양한 장치, 다양한 운영 체제, 다양한 하드웨어 환경 등에서 테스트 스크립트를 실행하면 예측할 수 없는 상황이 발생하여 테스트 케이스 실행 결과가 부정확해지는 것을 의미합니다.

위의 장단점 비교를 바탕으로 UI 기능 자동화 테스트에서는 주로 APP 핵심 경로에 대한 테스트를 구현하고, 다수의 반복 실행, 반복 검증이 필요한 기능 모듈에 대해 UI 기능 자동화 테스트를 수행합니다. , UI 인터페이스 변경 빈도가 낮습니다.

많은 수의 반복 실행과 반복 검증이 필요하다는 것은 자동화 후 활용률이 높다는 것을 의미하고, UI 인터페이스 변경 빈도가 낮다는 것을 의미합니다. 이는 후속 유지 관리 비용이 높지 않다는 것을 의미합니다. 사용 사례 중 입출력 비교는 상위 부분에서는 UI 기능의 자동화된 테스트 실행을 최우선으로 생각합니다.

UI 기능 자동화 테스트 과정에서 관련 컨트롤, 테스트 케이스, 테스트 세트를 효과적으로 분류 및 관리할 수 있으며, 반복 가능한 작업을 적시에 병합하여 리소스 낭비를 줄일 수 있습니다. UI 기능이 변경되면 더 적은 비용으로 유지 관리할 수 있어 유지 관리 비용이 절감됩니다.

1.2 인터페이스 자동화 테스트

UI 기능 자동화 테스트 섹션에서 자동화의 제약 조건인 안정성에 대해 언급했습니다. 바로 UI 인터페이스가 불안정하기 때문에 UI 기능을 자동화하는 데 드는 비용이 상대적으로 높기 때문에 우리는 자연스럽게 UI 기능보다 더 안정적이고 자동화에 도움이 되는 부분, 그것이 바로 인터페이스라고 생각합니다.

APP의 인터페이스는 다양한 단계의 제품 관리자의 다양한 요구로 인해 변경될 수 있지만, 그 뒤에 있는 인터페이스는 일반적으로 상대적으로 안정적이므로 자동화된 테스트를 수행할 수 있는 좋은 보장을 제공합니다.

APP에서 호출하는 인터페이스를 준비하고, 기능 모듈에 따라 정렬 및 요약하고, 자동화를 위해 우선순위를 지정하고, 각 인터페이스의 의미와 다양한 매개변수의 값 범위를 이해하고, 다양한 입력에 대해 다양한 출력을 생성해야 합니다. 인터페이스 테스트의 효율성과 완전성을 보장하기 위해 상황을 파악하고 오류 또는 예외 반환을 요약합니다.

인터페이스 자동화 테스트가 시작된 후에는 개발 엔지니어와 함께 인터페이스 문서를 유지 관리해야 하며, 향후 인터페이스의 증가 또는 감소 또는 기존 인터페이스에 관련된 변경 사항이 있는지 테스트 엔지니어가 즉시 알 수 있습니다. 인터페이스에서 자동화된 테스트를 수행하여 사용 사례에 맞게 조정합니다.

1.3 기타 특수 자동화 테스트

위의 두 가지 자동화 범주 외에도 자동화를 사용하여 몇 가지 특수 테스트를 수행하여 테스트 품질과 테스트 효율성을 향상시킬 수도 있습니다. 여기서 우리는 자동화를 통해 어떤 작업을 달성할 수 있는지, 어떤 테스트를 자동화하여 테스트 효율성을 향상시킬 수 있는지, 어떤 기능 포인트를 자동화하여 장기적인 테스트 모니터링을 달성할 수 있는지 등 일상적인 테스트 작업에서 부지런히 생각해야 합니다.

예를 들어 제가 담당하는 프로젝트에는 수동 테스트 중에 제한된 클릭 횟수로만 확인할 수 있고 클릭 빈도도 낮습니다. 그러나 스크립트를 통해 달성할 수 있습니다. 더 빠르고 효율적인 테스트를 위해서는 자동화를 사용하여 장기적인 클릭 작업을 수행할 수 있습니다. 자체 테스트 장비뿐만 아니라 다른 장치에서도 실행할 수 있습니다. 이 자동화된 테스트는 효과적이며 테스트 효율성과 테스트 품질을 향상시킬 수 있습니다. 이 테스트는 여러 가지 이유로 UI 기능 자동화 사용 사례 세트에 추가되지 않지만 현재 버전에서는 자동화가 실제로 우리에게 매우 유용한 도움을 제공했으며 이것이 우리가 옹호해야 할 것입니다.

요컨대, 우리는 다양한 자동화된 테스트 도구와 테스트 방법을 사용하여 테스트에 도움을 줄 수 있으며 이는 인정받을 가치가 있습니다.

2. 성능 테스트

제가 담당하는 프로젝트의 테스트 시스템에서 성능 테스트는 주로 시간 차원 성능 테스트, 리소스 차원 성능 테스트, 유창성 테스트의 세 가지 차원으로 구성됩니다.

2.1 시간 차원

시간 차원의 성능 테스트는 주로 클릭 작업 후 기능적 기능의 시간 응답을 나타냅니다. 우리는 첫 번째 화면 로딩 시간, 클릭 후 응답 점프 열기 시간 등에 더 익숙합니다.

시간 차원에서 성능 테스트를 수행하는 방법에는 여러 가지가 있습니다. 화면 녹화를 사용하여 시간을 계산할 수도 있고, 프로그램의 타임스탬프를 사용하여 시간을 계산할 수도 있고, 타사 스크립트를 사용할 수도 있습니다. 이미지 인식을 사용하여 시간을 계산할 수 있습니다. 시간 등을 계산하는 기술

테스트 과정에서 프로젝트 자체와 연계하여 도구에 대한 사전 조사를 수행해야 합니다. 일회성 테스트인가요, 아니면 지속적인 테스트가 필요한가요? -기간 사용 여부 단일 장치에서 사용해야 합니까? 도구가 오픈 소스인지 또는 팀의 테스트 플랫폼과의 후속 통합을 위한 데이터 인터페이스를 제공하는지 등 다양한 장치 환경에서 사용하기 위한 호환성을 고려해야 합니다.

2.2 리소스 차원

리소스 차원의 성능 테스트는 주로 APP 사용 중 CPU, 메모리, 전력, 트래픽 등 다양한 시스템 리소스의 소비를 의미합니다.

테스트 도구의 선택은 다양한 테스트 터미널에 따라 다릅니다. 테스트 중에 모니터링해야 하는 치수도 프로젝트에 따라 결정됩니다. 여기서는 구체적인 테스트 방법을 논의하지 않습니다.

여기서 말해야 할 것은 리소스 차원의 성능 테스트는 두 가지 작업을 수행할 수 있다는 것입니다. 하나는 테스트 프로세스 중 성능 테스트이고, 다른 하나는 온라인 성능 데이터 수집입니다.

테스트 프로세스 중 성능 테스트는 비즈니스 테스트 요구 사항에 따라 평가할 수 있습니다. 어떤 시나리오를 테스트해야 합니까? 현재 버전에 대한 일회성 테스트입니까, 아니면 각 후속 버전에 대한 비교 테스트만 필요합니까? 로컬 시스템의 성능 데이터가 필요합니까? 여전히 여러 장치에서 성능 데이터를 수집해야 하며, 이 앱을 테스트하기만 하면 되고, 경쟁 제품과의 비교 테스트도 수행해야 합니다.

이를 바탕으로 후속 재사용을 위해 자동화된 스크립트를 통해 테스트 케이스를 구현해야 하는지 평가합니다. 과거 버전과의 후속 종단적 비교 테스트가 필요한 경우 테스트 결과를 보다 확실하고 신뢰할 수 있도록 테스트 환경과 테스트 장비가 최대한 일관되게 유지되도록 해야 합니다.

추가해야 할 또 다른 작은 점은 자동화된 스크립트를 통해 테스트 데이터의 처리 및 계산을 실현할 수 있어 인적 컴퓨팅 리소스 비용을 절약할 수 있다는 것입니다. 필요한 경우 간단한 플랫폼을 구축하고 후속 분석 및 참조를 위해 모든 테스트 데이터를 플랫폼에 저장할 수도 있습니다.

온라인 성능 데이터를 수집하려면 기능 구현 과정에서 개발 엔지니어가 관련 데이터를 보고해야 하며, 가능한 문제를 발견하기 위해 온라인 데이터를 검색, 처리 및 계산해야 합니다. 개발 엔지니어의 로그와 오류가 있는 사용자의 로그를 협력하여 관련 성능 문제의 위치, 분석 및 해결을 달성할 수 있습니다.

2.3 유창성 테스트

가장 직관적인 사용자 경험인 만큼 유창성 테스트는 많은 성능 테스트에서도 필수입니다. 여기서 유창성 테스트 방법에 대해 자세히 설명할 필요는 없지만 주목해야 할 몇 가지 사항이 있습니다.

첫 번째는 유창성 테스트를 위한 사용 사례를 계획하는 방법이고, 두 번째는 어떻게 유창성 테스트를 수행하는가입니다. 유창성 테스트 후 분석 및 분석을 위해 테스트 결과 데이터를 사용합니다. 세 번째 개선 사항은 APP 출시 후 온라인 데이터에서 유창성을 모니터링하는 방법입니다.

유창성 테스트 케이스 디자인은 앱의 핵심 기능과 사용자가 사용하는 공통 경로를 기반으로 디자인해야 하며, 이 부분을 뒷받침할 수 있는 온라인 데이터가 있는 것이 가장 좋습니다. 너의 머리. 우리가 주목해야 할 것은 데이터의 지원으로 얻은 대부분의 앱 사용자들의 점프 경로입니다. 또한 테스트 과정에서 온라인 데이터에서 모니터링되는 지연이 발생하기 쉬운 경로에도 주의를 기울여야 합니다.

유창성 테스트 후 데이터 분석 및 활용은 물론 온라인 유창성 데이터 모니터링에도 테스트 엔지니어와 개발 엔지니어의 공동 계획과 공동 조사가 필요합니다. 이 기사에서는 이에 대해 자세히 설명하지 않습니다.

3. 안정성 테스트

이 부분은 APP 출시 전 테스트 단계와 출시 후 온라인 운영 단계 2단계부터 시작해서 별도로 작업을 진행하시면 됩니다.

테스트 단계에서는 Monkey 테스트 및 코드 검토에 대한 안정성 테스트를 수행할 수 있으며, 자격을 갖춘 팀은 이 단계에서 정적 코드 검색 도구를 사용할 수도 있습니다. Monkey 테스트 과정에서는 장비, 환경, 테스트 실행 빈도에 주의를 기울여야 하며, 이 과정에서 발견된 문제도 어느 정도 분석되어야 하며, 문제가 발생하기 쉬운 부분에 특별한 주의를 기울여야 합니다. 코드 연습은 기능 테스트 중에 충돌이 발생하기 쉬운 모듈과 결합하여 주요 연습을 수행하고 개발 및 쌍 프로그래밍을 촉진하며 이러한 모듈에서 발생할 수 있는 문제를 확인할 수 있습니다. 정적 코드 스캐닝의 경우 개발 학생은 스캔된 문제를 해결하고 관련 문제가 누출되지 않도록 좋은 코딩 습관을 개발해야 합니다.

운영 단계에서는 외부 네트워크 충돌 데이터 보고 및 분석을 중심으로 안정성 테스트를 수행할 수 있습니다. 이 부분은 개발 엔지니어에게 더 많이 의존하여 해결됩니다. 그러나 이 과정에서 테스트 엔지니어는 보고된 데이터를 분석하고 일반적인 시스템, 모델 등과 같은 일부 기본 데이터를 찾아 일상적인 성 테스트를 개선하고 최적화할 수 있습니다. .

위 내용은 Android 앱 테스트 프로세스와 일반적인 문제는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!