1.なぜ自動化を行います
- 今は多くの作業をより機敏、少しポイントを処理するので、短いサイクル
- レッサー各ライン機能、多くの機能を複製し
- 書き込み後には、ユニットテストコードの開発、品質保証、実施通常はテストの点2、
- それぞれの新しい機能、はるかに長い製品サイクル、より複雑な機能、より多くの機能、各バージョン、すべての機能必要があり、再びポイント
- 言及バグ、解決のバグは、バグがより多く生成します
- 各バージョンは、ちょうど、テスターが何の原因が他のバグが存在しないことを確認し、全額をテストする必要があり、独自の検証（セルフテスト）を開発しません、バグを変更します
- 3今週のオンライン版、バグ完全に解決されますが、ライン上の次の再び、バグの再生は、そのリリース前に迅速な検証自動化機能を行います
- 需要のバグ履歴機能は、それが推奨されます
- 長いサイクル、多機能
- たとえば、次の歴史的特徴があり、テスト、次のバージョンの完全な量の最初のバージョンは、各テストポイントの全額が同じではないことがないだろう。全体の量が以前に試験されているので、何の問題、次のバージョンこのバージョンでは、十分な時間またはオンデマンドではありませんので、全額がテストされることはありません
- 長いサイクル、機能、あまりにも面倒、繰り返しのバージョン
2.現在のプロジェクトであれば、どのような自動化の定期的な選択肢に変わるの？
- 安定性は、以下の論理は単純で、高速な実装モジュール
- 主な流れ
- 高い再現
- 重要な機能モジュール、コアビジネス
- バグモジュールの観点からオンライン高
- ほとんどのユーザーはモジュールを使用し、最大の機能
3、どのように二つのプロジェクト場合の時間を割り当てます
- プロジェクト緊急、優先順位、プロジェクトの時間に及び計画によると、
4、インタフェース、又は自動テスト時間配分
- まず、機能要件を理解して、1〜2週間をテストする必要があり、ビジネスの前に精通テストの自動化
- 自動テストサイクルは、歴史の回帰関数長く、複雑で多機能であります
- ウェブの自動化、ページへの過度の依存、同じページ、ページが安定しています
- 例えば：
- 初期の開発は、ときに私のテスト担当者、開発にまだあったコネクタOK最初のテスト・インタフェース、インタフェースのOKは、基本的な機能を示した後、フロー需要によって書かれたユースケースの疑いことができない、私はちょうどライン上のプロセスにページを取る必要が出ページたら、達成することです
- これは、後者が自動的に行うことができるかどうか、である。準備作業は非常に素晴らしいですテスターBUGを検索する当社の能力を複雑にしています。だから、この段階で、私は特定のポイントにバグを見つけるためにしようとします
5、関数は、すべての例自動変換を使用したいと思います
- 必要はありません。
- 何故
- 何を何をすべきかを安定させるためのウェブオートメーション機能
- ウェブの自動化はそれほど高くカバーしていません。いくつかのUIインターフェイスはなるだろう
- 自動化に繰り返しウェブテストケースを自動化します
- ウェブ各ラウンドは、ファンクションポイントの少しを行かなければならないテストの自動化 - 主に回帰テスト
*******転載するなど、オリジナルを尊重してください、ソースを明記してください：からの転載：https://www.cnblogs.com/shouhu/、ありがとうございました！！*******