基本的な概念とモデルが導入されています。
我々は三つのレベル、すなわち、UI層、サービス層と層ユニットに分割テストします。
インタビューでは、ので、会社は多くの学生のテストの制限がテスト要件に基づいていることが判明し、テストインターフェイス機能コード開発にアクセスできず、さらにいくつかの企業、テスターはテスト環境、データベース、など、これらの活動を制御することはできません、ベースそこに乾燥するために開発されています。いくつかの企業の現状について、理解しやすいですが、それはテスターの開発のためだけでなく、製品の品質は非常に良いです。
一部の学生はテストケースは完全に要件文書のバージョンをコピーされ、長年にわたって動作しますが、テスト要件に基づいています。欠陥に起因する問題の多くは、多くの場合、考慮にニーズを取らされていないため、テストは段階的に行くために、必要に応じて、まだ堅固であるので、もし何の説明、省略または誤解は、機能の開発につながるん要求し、このテストでは、それは重要な役割を失いました尺度は、それは多くの場合、テストの役割が半分以上を失い、非常に深刻な問題を欠場します。
テストだけで要件をテストしていない、暗黙の需要に焦点を当てる必要があり、それは、ユーザーの真のニーズ、本音、本当のシーンです。需要への別の追加は、我々は発展を達成するために集中しなければならない、開発、デザインを開発する方法を、どのような技術を実現するために何を意味するのかでありますか？彼らのデザインは、正しいと合理的なのですか？要件を満たしていますか？それは非常に効率的ですか？スケーラブルかどうか？堅牢かどうか？プロセスが制御されているかどうか、それが閉ループを形成するかどうか、異常な状況と互換性がありますか？基礎となるデータ処理が合理的ですか？だから、実際には私たちのテスターの懸念の多くは、多くのニーズがあります。
私たちのチームにすぐに私たちの古いテストのアイデアを統一するために新入社員や従業員を確保するために、私たちのチームはあなたと共有するためにここに、テスト戦略モデルの数を確立しました。階層型テスト戦略モデルでは、モデルは、私は、参照のみを目的として作成し、私に属している;、だけでなく、実際のチームによると、実際のアイテムが調整されているフルかどうか、あなたのチームのために右です。
