一般に、自動化された思考、モデル、ツールから、自動化されたテスト技術、テストフレームワーク、未来志向の自動化技術を含むあらゆるレベルのテストプラットフォームに至るまで、議論全体は非常に長くなります。また、内容が広範囲にわたるため、内容の一部にまだ深い部分がありますが、誰でも理解できるように文脈を完全に説明するように努めていますが、不明な点や間違っている点があれば（知識は常に限られています）、お気軽にお問い合わせください。正してください。
01. 自動テストの考え方
私に詳しい読者は、私が特定のアプリケーションを作成する前に考えることについて話すことに慣れていることを知っているはずです。なぜなら、何事も最初に理解すべきは本質であり、本質を理解すると現象がより見やすくなると思うからです。このように言えます。一流のテストは思考として使用され、二流のテストはモデルとして使用され、三流のテストはツールとして使用されます（ここでの「テスト」は動詞であり、人ではありません。ただ撫でるだけです） ）。
自動テスト システムの設計となると、多くの人はピラミッド モデルに反応します。しかし、今日に至るまでのテスト理論の発展により、ピラミッド モデルの適用性はもはや高くなくなっており (詳しくは後述します)、古いモデルや古い考え方に固執するだけでは済みません。ビジネスにどのモデルを採用する必要があるか、またはどのような新しいモデルを生み出すことができるかは、すべて自動化されたテストの考え方によって決まります。多くのチームは、自動化アプリケーションの失敗の原因を、偏ったモデルのエラーに起因すると考えています。問題はモデルではなく、モデルの背後にある思考の欠如です。
自動テストの考え方とは何ですか? 文字通りの意味は、テスト作業を機械が自動的に実行する形にすることです。この点は誰でも理解できるはずですが、問題はアイデアと実践の関係です。理解したからといって使えるわけではありません」 。たとえば、実稼働環境でのマシンの監視は自動テストだと思いますか? それもそのはず、エラー検証の問題もシステムの形で解決する、手段や目的を問わず、一種の自動テストです。では、なぜ多くの人が依然としてそれが運用と保守の一部であると考えているのでしょうか?
したがって、自動テストについて語るときは、単体テスト、インターフェースの自動化、UI の自動化に限定されるのではなく、あらゆる面で自動テスト機能を実現できるかどうか、また、その機能を導入した後の入出力も考慮する必要があります。比較して総合的に判断して、これが自動テストの考え方です。これまでのところ、自動テスト思考の適用で最も成功しているのは 2 つあると思います。1 つはフロー再生技術、もう 1 つは画像認識と機械学習を組み合わせた自動化技術です。後ほど詳しく説明しますので、ご心配なく。
02. 自動テストモデル
自動テスト モデルに関しては、ピラミッド モデルは避けられないしきい値である必要があり、10 -> 20 -> 70 の比率が自動化実践の黄金律とみなされます。しかし、ピラミッドモデルが提唱されてから10年以上が経過し、現在のビジネス形態、テスト理論、自動化技術は大きく変化しました。実際のところ、このモデルを厳密に使用しているチームは何チームありますか? 国内の発想が追いついていないだけなのでしょうか？
まず、自動化の最大の課題は何かを見てみましょう。自動化の目的が人件費の節約であることは誰もが知っていますが、自動化自体のコストが高くても、それでも意味があると思いますか? もちろん違います。そのため、過去から現在に至るまで、自動化の技術開発はコストの問題と格闘してきました。録画再生、トラフィック再生、画面比較、画像認識などは、自動化コストを削減するために生まれたものではないことをよく思い出してください。したがって、ピラミッド モデルの基礎は、当時の技術的制約により、このモデルを使用するコストが最適であるという前提に基づいています。
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036
しかし現在は 2023 年であり、トラフィック リプレイ テクノロジーにより API (実際、トラフィック リプレイは複数のレベルで使用できます。これについては後ほど詳しく説明します) は自動回帰のコストが 0 に近くなり、新しい機械学習が可能になりました。画像認識によるUIの自動化も可能 回帰コストは0に近い この2つの技術を採用すると、モデルは直接紡錘形、さらには逆三角形に進化しますが、これは無理があると言えるでしょうか？明らかに違います。したがって、コストはモデルの「形」を決定する核心要素であり、ピラミッドでもスピナーでも逆三角形でも、ROI が高ければ良いモデルと言えます。
また、ピラミッドといっても既存のグラフィックは様々に描かれています。統合テストはインターフェイス テストと混同され、インターフェイス テストはエンドツーエンド テストと混同されます。たとえば、エンドツーエンドでは、実際には、元の「システム テスト」の概念にいくつかの拡張が加えられており、Paas/Iaas サービスの場合、エンドポイントはインターフェイスではなくインターフェイス、または単にコマンド ラインであることがよくあります。したがって、エンドツーエンドがインターフェースであると考えることはできません。それは同じものではありません。
厳密に言うと、ピラミッド構造には 2 つのタイプがあり、1 つは単体テスト -> 結合テスト -> システムテスト (エンドツーエンド) などの粒度に基づくものと、もう 1 つはデバイス層などの階層の深さに基づくものです。 > コーディング層 -> インターフェース層 -> インターフェース層。これは、すべてのレイヤーが存在する必要があり、それぞれのビジネスに応じて分析する必要があるという意味ではありません。
03. 自動テストカバレッジ
モデルを作成した後は、モデルの各レイヤーの「太さと薄さ」に応じてそのカバレッジを決定するだけでよいのでしょうか? それとも、カバー率が高ければ高いほど良いという可能性はありますか？私たちは自動化の各レベルを個別に扱い、そのカバレッジ指標を個別に策定することに慣れていますが、レベルとレベル間の関係について考える人はほとんどいません。次の例では、製品価格が異なると割引も異なります。ビジネス コードが次のとおりであり、アクセス インターフェイスがパッケージ化されていると仮定します。
public float getDiscount(float commodityPrice) {
float discount;
if (commodityPrice >= 500.0) {
discount = 0.3;
} else if (commodityPrice >= 300.0) {
discount = 0.2;
} else if (commodityPrice >= 100.0) {
discount = 0.1;
} else {
discount = 0.0;
}
return discount;
}このロジックは、コード (単体) テストでもインターフェイス テストでも実装が容易で、(当面は境界や例外を考慮せずに) 4 つのユースケースを実行できるため、ほとんどの人はコード テストとインターフェイス テストの自動化を追求します。 100% カバレッジ (コード 4 つ + インターフェイス 4 つ) なので、コストはそれほど高くありません。しかし、有効性の観点から見ると、冗長性は 75% にもなります。ビジネス ロジックはコード層で実行されているため、インターフェイス テストでは、インターフェイス リンクが接続されていることを確認するだけでよく、各ロジック ブランチの検証を繰り返す必要はありません。
例えば、私たちが家庭で使っている浄水器には通常、堆積物などの大きなものからバクテリアなどの小さなものまで、3～5層のフィルタースクリーンがあり、それぞれの層に目的と機能があります。1層目から最高級の濾材を使用すると、材料の無駄やコストアップが避けられません。
自動化の階層化についても同様で、できるだけ多くのユースケースをカバーするために、実装コストが最も低いレイヤー (これも必ずしもコードレイヤーである必要はありません) から始めてから、前のレイヤーでカバーされなかった部分を分類する必要があります。コスト順にレベル自体の特性と組み合わせて補います。したがって、自動階層化のアイデアは実際には補完的なアイデアであり、独立して考える必要はありません。
注意しなければならないのは、高いカバレッジを過信しないことです。たとえば、次のコード:
public float test(float divisor) {
return 100.0/divisor;
}100% カバレッジを達成するには test(10.0) だけが必要ですが、明らかにコードはゼロ除数のケースを処理していないため、100% (コード) カバレッジにバグがないとは言えません。そのため、カバレッジ率はビジネスカバレッジ率とコードカバレッジ率に分けられ、有効性をテストする手法もミューテーションテストやカオスエンジニアリングなど数多くあります。テストの有効性と自動化の間に厳密な関係はないため、この記事では関連する内容を簡単に紹介し、残りについてはあまり説明しません。自動化に関する今日の内容は当面ここで取り上げますが、来週も続きます :)
以下はサポート学習教材です。[ソフトウェア テスト] を行う友人にとって、これは最も包括的で完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を私に同行させてくれました。あなたにも役立つことを願っています。
ソフトウェアテストインタビューアプレット
ソフトウェア テストの質問バンクには、何百万人もの人が参加しました。！！誰が知っているのか！！！ネットワーク全体で最も包括的なクイズ ミニ プログラムです。携帯電話を使用して、地下鉄やバスの中でもクイズに答えることができます。
次の面接の質問セクションが取り上げられます。
1. ソフトウェアテストの基礎理論、2. Web、アプリ、インターフェース機能テスト、3. ネットワーク、4. データベース、5. Linux
6. Web、アプリ、インターフェイスの自動化、7. パフォーマンス テスト、8. プログラミングの基本、9. 時間面接の質問、10. 公開テストの質問、11. セキュリティ テスト、12. コンピューターの基本
情報取得方法：
