Android側入出力関連リソースチェックリスト

3578 ワード

一、クラスリストの入力


第三者アカウント申請リスト

  • 共有クラス:友盟社会化androidコンポーネント統合の準備
  • 支払類:支払市場分析報告
  • チャネル情報:
  • はsvn上に配置され、パスと名前は{ }/03.Product/Document/ /APP .xlsx
    • である.
  • チャネル番号はアルファベットで始まることを要求し、アルファベットまたは数字以外の他の文字が現れることを許さないため、360→sanliuling、360→qihoo360

    • 製品原型検査リスト

  • すべてのページには、対応する英語
    • が必要です.
  • には、ページの追加、削除、変更の重要な情報を記録する「プロトタイプ変更履歴」という個別のページが含まれている必要があります.
  • 各入力ボックスは、値の妥当な範囲、およびフロントエンド異常提示テキスト
    • を明確にすべきである.
  • は、対応するテストデータ
    • を提供するべきである.

    ビジュアルデザインチェックリスト

  • テーマカラーのほか、通常のページデザインはAndroidビジュアルスタイルデザイン仕様、
  • 非常规ページには、はっきりした寸法図が必要です.
  • は、ネットワークに対してページをロードするとともに、
    • という状態のページスタイルを設計する.
  • ローカルにネットワークがありません.
  • サービス側は戻ってこない.
  • サービス側プロンプトパラメータエラー;
  • データは空です.
  • 正常データ.
  • プロジェクトの最初からダイアログボックス(Dialog)とポップアップボックス(PopupWindow)の統一スタイル設計
    • を提供する必要があります.
  • アプリケーションアイコンは、
    • のサイズを提供します.
    mipmap-hdpi  57*57
mipmap-mdpi  80*80
mipmap-xdpi  108*108
mipmap-xxdpi  120*120
mipmap-xxxdpi  512*512

    インタフェースチェックリスト

  • インタフェースが入出力したデータはjsonまたはファイルストリームである.
  • json戻りデータは、次のフィールドを含む必要があり、0は成功
    • を表す.
    {"respCode":0,"respDesc":" "}
  • 同じrespCodeは、同じ意味しか表現できません.
  • が返すjson列では数字をkeyとして使用することは許されず、名前が変動するkeyは許されず、例えば3年近くのデータを取った結果、2014、2015、2016というkey値が現れた.
  • インタフェースは、各値の妥当な範囲と、フロントエンドの異常プロンプトテキストがバックグラウンドによって提供されるかどうかを明確にしなければならない.
  • オーロラプッシュ別名は、appuser12345
    • のようなappuser{id}に統一されている.

    Bugチェックリスト

  • は禅道テストBugに発表しなければならない.口頭bugは修復を保証しない.
  • UIバグは単独で1つに列挙されています.美観に関係する場合は、バグを視覚的にコミットしてください.
  • モジュールbugは、抽出メールに基づいてメール送信者に割り当てられる.

    • 追加タスクチェックリスト

  • は禅道プロジェクトの任務に発表しなければならない.口頭任務は完成を保証しない.

    • 二、出力類リスト


    コードチェックリスト:

  • 検視ロジック:
  • 主体論理に適切な注釈があるかどうか、他の人に秒で理解させる.
  • 各クラスの機能分割が合理的かどうか、同じ論理に従うかどうか、MECE
    • に合致するかどうか
  • 検視類:
  • 内部要素の構造順序が以下の順序に合致するかどうか:
  • 定数;
  • 変数:静的優先;
  • 方法:静的優先;公開優先
  • 検視方法:
  • は動詞で始まる.
  • は手のひらの原則に合っている.
  • 方法に注釈があるかどうか、入力、出力を明記する.
  • その他:
  • todoラベルの使用が規範化されているかどうか.
  • すべての文字列はstringsに配置する必要があります.xmlの中の.

    • Apkチェックリスト

  • 特別な説明がない場合、以下の機能はデフォルトです:
  • App更新は、一般的には「パーソナルセンター」モジュールで一緒に完了する必要があります.

    • バグ修復チェックリスト

  • reopenのバグに対して、修復後にリーダーと確認し、禅道状態を修正する.

    • Appオンラインチェックリスト


    適用:最後のテスト検証パッケージ.
  • 採用したサービス側アドレスが要求に合致するかどうかを確認する.
  • サードパーティのdebug機能がオフになっているかどうかを確認します.例えば、jpush、ループメッセージなどです.
  • VersionCodeとVersionNameが要求に合致しているかどうかを確認する
    • # VersionCode   yyyyMMDD+ 
VERSION_CODE=2016032102
# VersionName   . ， 
VERSION_NAME=0.1
  • apkを360で補強またはテンセント楽固に提出し、補強後のapkをダウンロードし、再署名し、抽出検証パッケージを生成する.
  • 測定検証パッケージをテストに渡し、検証に合格したら、テストから関連メールを発行すればいい.

    • メールチェックリストの提出(廃棄、禅道で管理)

  • 受信者:テスト担当者[email protected]および[email protected].
  • 抄送者:[email protected]と[email protected]
  • 添付ファイルのapkは{APP }{ }_{ }_{ }_build{ git/svn }または参照ソフトウェアバージョン命名仕様
    • と命名する.
  • タイトル: -Android- （{ }）
  • 内容参考:

    • せいさんぶつを抽出する

  • 添付ファイル「xxx.apk」は、正常なテストに使用されます.
  • 添付ファイル「xxx.apk」は、テストを更新するために使用されます.サービス側に置いてください.

    • 今回の開発内容

  • 登録モジュール:25個の自己測定例のうち、22個、ブロック3個(ブロック原因:視覚未提供)
  • マイモジュール:51個の自己測定例のうち、31個を通過し、20個のブロック(ブロック原因:インタフェースが提供されていない)
  • トップページモジュール:20個のバグを修復
    • [Fluth]を使用した外観設計
    Linuxコマンドラインとshellスクリプトプログラミング大全(三)