個々のテストサマリー

 
個人的な知識テストサマリー:
自動テストの準備:
1、モバイルプラットフォームAndroidの最終製品の機能及びインタフェーステスト
2、
試験計画:異なる製品スケジュール項目計画に記載された行動計画の要素を説明するための
 
テスト:テスト異なる製品、注意事項ケース管理ツール、ユースケースの内容は、ユースケース
 
テスト:開発者の注目を集め、通信、ユースケースのカバー、および標準回帰により失敗
 
テストケースは、テストは、テストツールおよび方法において使用される基準、試験手順を終了します
 
ベースに、機能テスト、支援するためのインタフェースのテスト
メインのニーズを満たすために、主な機能テスト
メインインターフェイスのテスト問題が見つかりました。
 
テストレポート:異なる製品のテストレポート
 
モバイル製品を構築し、実行するための自動テストフレームワーク
 
テストプロセスを推進し、監視します
 
利点:
図1に示すように、携帯電話アプリの試験方法、プロセス、自動テストツールの開発、おなじみのホワイトボックステスト、コード検査優先精通知識のソフトウェアのテスト理論に精通して自動テストツールに精通
電話での2、携帯端末アプリケーションのテストの経験一年以上
図3に示すように、自動テストツールの開発、おなじみのホワイトボックステスト、コードのテスト優先
 
自動化、テストでは、最初の製品は、自動テストに適しているかどうかを検討してください。この方法は、比較的一般的なコンセンサスは、三つの側面からのトレードオフということです。
 
  ソフトウェア要件は頻繁に変更します
  安定性のテストスクリプトは、自動テストのメンテナンスのコストを決定します。ソフトウェアのニーズがあまりにも頻繁に変更する場合は、スクリプト自体を維持することがコードの開発の過程である一方で、テスターは、需要の変化に基づいて、関連するテストケースとテストスクリプトを更新する必要があり、修正、デバッグ、必要なときに変更するだけでなく、自動化されたテストそれはそのコスト削減の使用をテストするのにかかるコストを下回っていない場合、フレームワークは、その後、自動テストは失敗です。
  プロジェクト内のモジュールのいくつかは、比較的安定しており、需要モジュールにおける大きな変化の一部。私たちは、自動テストのための比較的安定モジュールとすることができ、より大きな変化はまだ手動テストを使用します。
 
  プロジェクトサイクルが長いです
自動化されたテスト要件、設計自動化テストフレームワークの決意ので、書き込みとデバッグテストスクリプトが完了するまでにかなりの時間を必要とします。このプロセス自体は、ソフトウェア開発プロセスのテストで、それが完了するまでに長い時間がかかります。プロジェクトの期間が比較的短い場合には、このようなプロセスをサポートするのに十分な時間がない場合、自動テストは冗談になります。
 
  自動化されたテストスクリプトを再利用することができます
  自动化测试脚本的重复使用要从三个方面来考量,一方面所测试的项目之间是否很大的差异性(如C/S系统和B/S系统的差异);所选择的测试工具是否适应这种差异;最后,测试人员是否有能力开发出适应这种差异的自动化测试框架。

おすすめ

転載: www.cnblogs.com/TomBombadil/p/11122404.html