호환성 테스트
호환성 테스트에는 주로 수동 테스트, 자동 테스트, 클라우드 플랫폼 테스트의 세 가지 방법이 있습니다.
요즘 업계의 주류 모델은 다중 모델 클라우드 플랫폼에서 수많은 장치를 사용하여 설치 및 제거, 안정성, 기능 테스트와 같은 테스트를 수행하는 자동화 아이디어와 호환됩니다. 테스트 중인 앱. 이번 섹션에서는 자동화 구현 부분을 주로 소개하고, 다음 섹션에서는 클라우드 플랫폼 활용 부분을 소개합니다.
Android 기기에 테스트된 애플리케이션 설치 → 테스트된 애플리케이션 시작 → 테스트된 애플리케이션 제거를 통해 다음 두 가지 측면을 확인합니다.
설치 패키지의 설치 호환성
adb(Android 디버그 브리지)를 통해 설치 및 제거합니다. 예를 들어 설치 패키지 test.apk, 패키지 이름은 com.sample.app, 시작 활동은 MainActivity입니다.
설치: adb install test.apk.
시작: adb shell am start–n com.sample.app/.MainActivity.
제거: adb uninstall test.apk.
설치 덮어쓰기: adb install–r test.apk.
위 명령을 사용하여 앱을 설치, 시작 및 제거합니다. 콘솔 출력을 관찰하면 성공, 그렇지 않으면 실패를 의미합니다. 동시에 logcat이 캡처되어 개발자에게 제공됩니다.
b. 테스트 중인 애플리케이션을 시작하여 시작 충돌과 같은 낮은 수준의 치명적인 문제를 감지합니다.
Logcat(DDMS의 도구)의 인쇄 내용을 모니터링하여 Java 계층을 찾습니다. 및 기본 레이어 충돌 정보.
Java 계층 Crash 정보는 다음과 같습니다.
Native 계층 Crash 정보는 다음과 같습니다.
Crash Trace 정보에 해당 패키지 이름이 포함된 경우 테스트된 앱(com.sample .app)인 경우 이 충돌은 테스트 중인 앱으로 인해 발생합니다.
다양한 모델에서 앱의 안정성을 테스트하기 위해 툴 테스트를 통해 수시간 동안 테스트를 진행한 결과 충돌 문제를 발견했습니다. 업계에서는 주로 다음과 같은 두 가지 방법으로 테스트를 진행합니다.
a. 제어 순회 테스트
현재 업계 테스트 구현 방법은 기본적으로 다음 단계를 포함합니다.
(1) 현재 테스트 중인 앱의 모든 제어권을 얻는 방법은 아래 표와 같습니다.
휴대폰(안드로이드) 프로젝트에서는 자동화 도구 세트 지어졌습니다. 내부 클라우드 플랫폼 장치에서 실행할 기능 테스트 자동화 스크립트를 작성합니다. 자동화 프레임워크는 아래 그림과 같습니다.
아래 그림과 같은 테스트 결과를 접했을 때, 텍스트로만 판단한다면 결과는 완전히 정확합니다. 하지만 결과가 긍정적이라고 인정할 수 있나요? 분명히 그렇지 않습니다. 배경색이 희끄무레해서 기대했던 것과는 다릅니다.
문제의 핵심은 자동화가 복잡한 인터페이스 색상, 레이아웃, 배경 및 기타 요소를 확인할 수 없다는 것입니다.
어떻게 해독하나요? 입출력 비율의 관점에서 자동화된 작업과 결과(스크린샷)를 수동으로 확인하는 반자동 방식을 채택합니다.
/s/JNHKJfnW74tDeVilIfnfMg
/topics/7966
/yorkz0909/article/details/76523271
UI 레벨 자동화는 사람들에게 항상 "변화가 너무 크고 수익이 너무 낮다"는 인상을 받았습니다. UI가 크게 변경되면 이전의 자동화된 스크립트도 크게 변경되어 투자는 늘어나고 수익은 낮아집니다.
이 문제를 어떻게 해결하나요? 아이디어는 다음과 같습니다.
(1) 구축 비용 절감: 저자는 자동화된 스크립트 작성을 예로 들어 학습 비용이 낮고 효율성이 높은 프레임워크를 선택하는 것이 중요합니다. 둘째, 공용 기능이 지속적으로 축적되어 스크립트 개발 속도가 몇 배로 빨라집니다.
(2) 사용 빈도 증가: 자동화된 테스트의 사용 빈도가 높을수록 이점도 높아집니다. 현재 버전이 돌아올 때마다 동일한 자동화 스크립트 세트를 사용할 수 있습니다. 마찬가지로 간단한 수정 후에는 다음 버전에서도 중요한 역할을 할 수 있습니다.
(3) 변화에 대응하여 변하지 않음: 자동화된 모듈은 UI의 변화가 상대적으로 작은 모듈에 우선순위를 두어야 합니다. 이는 자동화에 적합한 부분이며 향후 변경 비용을 줄일 수 있습니다.
(4) 다양한 작업 개발: 자동화된 스크립트의 목적은 확실히 기능 검증만을 위한 것이 아닙니다. 적용 범위 설치, 성능 테스트, 설치 패키지 검증 등 다양한 기타 테스트를 사용할 수 있습니다. 더 많이 사용할수록 이점은 더 커집니다.