テスト効率の向上

5669 ワード

頻繁に繰り返されるため、最初は私たちにとって重要なものが価値のないものになってきました.--叔本華
「天下武功、唯速不破」、モバイル開発はさらにこのように、敏捷開発、敏捷テスト、快速オンライン.テストはオンラインになる前の最後の一環として、任務は異常に困難である.他のチームにとって、各反復の重心は新しいものにすればいいが、テストだけは新しいものにし、古いものにしなければならない.言い換えれば、反復するたびに、次のテストの内容が1点多くなり、増加した内容と迅速な反復の周期が、どのように速くて良いことを保証するか、本稿はテストチームのいくつかの経験を歌いましょう.

一、合理的にUI自動化を導入し、合理的な自動化を導入する


UI自動化は業界内でずっと賛否両論があり、UIテストの革命であり、テストの両手を大きく解放し、テストを繰り返すことを救ったと考えている.彼を恨んで、これは労民が財を傷つけて、製品のインタフェースの版版が変わって、この版はまだ使っていないで、次の版は書き直さなければなりません.筆者は,後者の気まずい状況をもたらすのは,単純で乱暴な導入にあると考えている.次は、自動化を実施する際の考え方です.
  • UI自動化は、単純な手動インスタンスコード化ではなく、テスト中に新しいテストタイプであり、独立した価値があります.
  • UI自動化は設計当初から、用途目的、テスト内容、実行タイミング、実行方式、期待結果を明確にしなければならない.
  • 投入産出比公式を確立し、大まかに言えば、投入即ちメンテナンスの作成時間、産出即ち自動化代替の人工時間を実行することによって、参入値を設定し、比値が参入値より大きい場合に導入することができる.
  • 適切なフレームワーク、設計モード、言語の作成を選択し、ここでの選択は最高を求めないが、最も熟知していることを求めている.
  • が作成される前に、ビジネスロジックを細分化し、合理的にコンポーネント化し、パッケージ化し、結合度を低減し、各使用例に依存関係を持たないでください.
  • 「小歩快走」は、少量の作成後、迅速に配置し、できるだけ早く問題を発見します.

  • 歌唱録音機能の自動化プロセスを例に挙げます.
    録画プロセスを自動化することを決定する前に、私たちは直接符号化するのではなく、経験に基づいて録画機能を分析し、図1、録画機能の可能なシーンを細分化し、シーンがどのように変換されても、コアプロセスは常に変わらないことを発見するのは難しくないので、コアプロセスを共通の方法にカプセル化することを選択し、異なるシーンは異なるパラメータを伝達することによって実現した.
    [画像のアップロードに失敗しました...(image-31 a 35 a-151360658889)]
    [画像のアップロードに失敗しました...(image-f 36 c 3 a-151360658889)]
    使用例を作成するときにappiumフレームワークjava言語を使用します.メリットは次のとおりです.
  • プラットフォームにまたがるフレームワークで、caseの両端に
  • を使用できます.
  • Appium PageObjectは直接SeleniumのPageObject設計モードに沿って、UI要素と論理を分離して後期メンテナンス
  • を便利にする.
  • java言語の選択は、主に皆さんが最もよく知っている言語
  • を使用することを考慮しています.
    Objectsはすべてのページ要素をカプセル化し、単純なui変更であれば修正するだけでよいという利点があります.
        @WithTimeout(time = 300, unit = TimeUnit.SECONDS)
        @AndroidFindBy(id = "com.changba:id/begin_btn")
        @SelendroidFindBy(id = "begin_btn")
        public static MobileElement startRecordingButton;
        
        @SelendroidFindBy(xpath = "//RecyclerView[@id='recycler_view']/child::*")
        @OverrideWidget(selendroid = AndroidPropsCellWidget.class)
        public static List propCellList;
    

    ページを定義するときに、同じ親要素を持つ子要素をwidgetにカプセル化することで、AndroidのリストなどのItemを操作するのに便利です.
    public class AndroidPropsCellWidget extends PropsCell {
        protected AndroidPropsCellWidget(MobileElement element) {
            super(element);
        }
        
        @SelendroidFindBy(xpath = "//ImageView[@shown='true'][@id='download_image']")
        public MobileElement downloadImage;
    
        @Override
        public MobileElement getDownloadImage() {
            return downloadImage;
        }
    }
    

    Pageページカプセル化要素アクション
        public void startRecording() {
            // 
            if (getCabbie().waitFor(By.id("begin_btn"), 300) != null) {
                getCabbie().pressOnElement(PreviewRecordingPageObjects.startRecordingButton);
            }
        }
    

    コアビジネスロジックをカプセル化し、ビジネスロジックが変化した場合は、このような方法を変更するだけでよい
    public String recordWithConcert(String songName, RecordingType recordingType, SingType singType, int recordTime) {
            singPage.searchSong(songName);
            singPage.clickSingButton(0);
            previewRecordingPage.switchRecordingType(recordingType);
            previewRecordingPage.switchsingTypeButton(singType);
            String recordingSongName = recordingPage.startRecordingAndFinish(recordTime);
            logger.info("start and finish recording with {} time", recordTime);
            compeleteRecordingPage.waitForCompletePage(recordingType);
            clientUtils.waitForPlayStart(CompeleteRecordingPageObjects.playingTime);
            compeleteRecordingPage.saveRecording(AccompanyType.concert);
            return recordingSongName;
        }
    

    異なるパラメータの組み合わせにより、異なる使用例を実現し、コード冗長性を低減する
    @Test
    public void testRecordWithConcertAudioSolo() {
        baseRecordingProcess.recordWithConcert(SONG_NAME, audio_recording, solo, RECORD_TIME);
    }    
    @Test
    public void testRecordWithConcertAudioChorus() {
         baseRecordingProcess.recordWithConcert(SONG_NAME, audio_recording, chorus, RECORD_TIME);
    }
    

    二、三つの原則を堅持する

  • テスト左シフト
  • 統合テスト
  • 継続テスト
  • 具体的な考え方:開発はあるバージョンの開発を行う時、相応のブランチを作成し、このブランチの作成をテストする時、jenkins上でバージョンを構築し、複数のテストを含む組合せタスクを作成し、毎日自動的に実行する.
    次は歌いましょう.テストタスクに合格し、apkサイズ検出、起動速度テスト、checklistテスト、一部の機能性能テストを完了します.
    まずjenkinsでjob:test_を作成しますktv_android_launchSpeed_apksize_Test
    shellコマンドラインによるapk sizeデータ収集および起動速度テストスクリプトの実行
    if [ $APK_SIZE -gt $MAX_SIZE ]
    then
        echo "$APK_SIZE ," >>apksize.csv
    fi
    adb -s $deviceId install -r ${APK_PATH}
    python ./ChangBaLaunchSpeedCollect.py
    

    次にjob:testUIautomation_を作成します.ktv_checklist_Android_8.5_dev、コア機能テストおよびパフォーマンスデータ収集の実行
    このjobのトリガメカニズムは
    [画像のアップロードに失敗しました...(image-76 d 335-151360658889)]
    オートメーション・インスタンスの実行時にパフォーマンス・データを収集する方法
    現在歌っているバーの自動化はAppium+Maven+TestNGの形式に基づいています
    1.新しいスレッドバックグラウンドでパフォーマンスデータを収集
    public static GetPerformance instance = new GetPerformance();
        private GetPerformance() {
            threadPool = Executors.newCachedThreadPool();
            cs = new ExecutorCompletionService<>(threadPool);
        }
        public static GetPerformance getInstance(){
            if (instance == null) {
                instance = new GetPerformance();
            }
            return instance;
        }
    

    2.onTestStartメソッドの書き換え
    @Override
        public void onTestStart(ITestResult result) {
            if (result.getMethod().getMethodName().endsWith("_Perf")) {
                if (getPerformance.getCS() != null) {
                    getPerformance.setStart(true);
                    getPerformance.callable();
                }
            }
        }