レポート動画：
vimeo.com/93944414
プレゼンテーション：
www.slideshare.net/slideshow/embed_code/33725306#
私はこの業界で8年間働いていますが、問題があると思います）
まず第一に、テストは面白くない職業と見なされます。 これから何が続きますか？ 経験の浅い人や不十分な資格者が業界に参入します。 ハードワーク、なぜなら 経験の浅い人、誰もやるな。 そして、私たちは簡単な仕事をしていることがわかりました。 そして以来 私たちは簡単な仕事をします 私たちは望んでいるほど多くのビジネスをもたらしません。 そして、円が閉じます。
その結果、才能のある人がテストに陥った場合、偶然です。 そして、彼らはまだ開発に入ります。 つまり、テストは単純で面白くないIT専門家と見なされ、テストの質は低くなります。
まず第一に、覚えておくようにお願いします：私たちは誰ですか？ ソフトウェアテストエンジニア。 エンジニア つまり、テスター、テスターなどとは呼ばれず、エンジニアです。 そして、エンジニアは技術スキルやアプローチによって状況を変えることができると信じています。
私たちの仕事は一見思われるよりも複雑です。 私は今テストについて話していますが、私にとってはテストと自動化が1つに統合されました。なぜなら、自動化がテスターのメインツールであるべきだと思うからです。
名前が役割を果たします。
•テストの自動化（私たちは手で何かをし、それを自動化します）
•自動テスト（彼が私たちにビジネスをしてほしいのは、テストが自動的に自動的に行われ、そこでログを見るなどです。目標はテストを自動化するのではなく、テストを自動化することです）
•効果的な自動テスト
真空中の抽象的な設計を検討してください。
これはモデルであり、人生の状況をある程度近似して記述します。
5つのモジュールがあります。 最初の5つのオプション、2番目のオプション-8、3番目のオプション-2などをテストする必要があります。 全部で、すべてが機能することを確認するために800のテストを行う必要があります。
数値をVに変更します。V1* V2 * V3 * ... * Vn結果として、Vnはモジュールの平均複雑度です。 Vnとは何ですか？ 数学的な複雑さと指数。 すべては、そのような複雑さを持つタスクが非常に不十分に解決されるという事実に基づいています。
指数関数的な複雑さ。 スケジュールをご覧ください。
緑色のグラフ。長い間、他のグラフより下にありますが、ある時点で急速に上昇します。 そして、ブラックボックスメソッドでテストするとき、すべてのオプションを並べ替えようとすると、ブラックボックス（このようなテストの複雑さ）は指数関数的な複雑さであることがわかります。 何時間も動作する多くの自動テストがありますが、次に何をしますか？ それらを並行して開始します。 この複雑さを定数に分割します。 指数は同じですが、定数がわずかに減少しています。 つまり、これは問題を解決しません。
分割して征服する
反対側からタスクを見てみましょう。
26のテストがありました（各モジュールを個別にテストする場合）。 しかし、これらすべてが一緒に機能することを確認する必要があると言うでしょう。 それでは、各接続を個別のテストケースでテストし、ある種のエンドツーエンドのシナリオを実行してみましょう。 31のテストが判明しました。 その結果、指数関数的複雑度を線形に変更します。 そして、タスクは効果的に解決されます。 つまり、テストが不十分で、さらに10人のテスターを雇用した場合、単純に10を並列化し、タスク自体の複雑さを変更した場合、テストに必要なリソースをそれほど増やす必要はありません。
1つのバージョンを含むある種の抽象システムがあり、最後に10を掛けると、合計10のテストケースがあり、合計で14です。また、接続を確認します-19。しかし、テストは簡単になりました。 1つの長いテストの代わりに、10個の小さなテストを作成します。 つまり、実際には、テストの複雑さは依然として簡素化されています。
自動化の「ピラミッド」。
この「ピラミッド」でテストを構築しないと、タスクであるテストの指数関数的な複雑さが得られます。 最小のタスク分解モジュールは、個別のクラス、個別のメソッドです。 主なものは、タスクの分解です。 単音節の場合は乗算を取得し、そうでない場合は加算を実行します。長期的には改善されます。
テストはそれほど単純ではありません。 なぜなら、1つのブラックボックスを多くの小さなボックスに分解するためには、最後まで、つまり作業を行う技術的なスタンドの最低レベルまで把握する必要があるからです。 つまり 開発者の資格に見合った資格が必要です。 これがなければ、私たちは指数に頼り、定性的に仕事をしません。 したがって、私たちは学ぶ必要があり、これにより、私たちの仕事は見た目ほど単純ではないように思えます。
人生からのプロジェクト。
Siebel、Oracleは厳しいエンタープライズソリューションであり、Siebelテクノロジーに基づくモバイルオペレーターソリューションの実装のためのカスタマイズプロジェクトです。 プロジェクトに参加する前に、テストはQTPで作成されました。 それらはそのような構造でした。内部APIがあり、テストに進み、ボタンをクリックします。中央にはブラックボックスがあり、データベースは下にあります。 かなり典型的な写真。
その結果、テストが長くなり、テストが不安定になります。 課題は次のとおりです。数時間にわたって行われる前提条件を最適化すること。
GETリクエストの送信、XMLの解析、XMLの確認、別のGETリクエストの送信などを行うスクリプトをJavaで作成しました。 テストは20分間機能し始め、うまく並行し始めました。
ブラウザーを放棄した結果、テストの動作が速くなり、同期に問題がなくなり、テストの信頼性が高まり、並行して簡単に実行できるようになりました。 マイナスの点：テストがどのように機能するかは見えません。 自信がなく、エントリーのしきい値が高い。
「見えない」という質問は、古いジョークのように解決されました。「確認しますか、それとも行きますか？」テストを見る必要がありますか、それともテストを行う必要がありますか？ つまり ここでの質問は、自動テストまたは自動テストが必要ですか？
ソリューション構造：Java + TestNG + Maven + HttpClient。 直接動作せず、リクエストを書き込まず、Siebelに固有のエンティティで動作するように、いくつかのレベルの抽象化を配置します。
しかし、ブラウザーからのエスケープはなく、ロジックの一部がブラウザー自体に実装されていることが判明しました。 つまり ロジックの一部はサーバー上にあり、ロジックの一部はブラウザ内にありました。 したがって、セレンが登場しました。 しかし、ブラウザが長く不安定で壊れやすいことを知って、慎重に行いました。 ブラウザーに実際に実装され、テストするロジックがテストケースに表示される（ブラウザーの約3％）ときに、ブラウザーが本当に必要なときにのみ起動されました。 ブラウザなしの対話によるヘッドレスセッションも再利用されています。
次に、この問題をいくつかの断片に分解します。 ブラウザのレイアウトはSiebel自体によって生成されることが判明しました。 また、ボタンを押すのが本物であることは重要ではありません。Siebelで既に開発されており、Siebelでテストされています。
ブラウザーロジックの開発には、（Oracleドキュメントの）APIがあります。UIで何かをしたい場合は、そのメソッドを呼び出してください。
データベース。
これはシステムを操作する最も速い方法ですが、そこに直接記述しない方が良いです（ただし、これはプロジェクトの特異性でした）。 特別に検証されたストアドプロシージャを使用してデータベースにいくつかの変更を加えましたが、これはチェックに適しています。
Webサービス
JAX-WSは、Webサービスを操作するためのJavaプロトコルです。 Siebelを他のすべてのシステムのコンテキストでテストする代わりに、すべての外部対話を消し去り、Siebelから何かが出ていることを確認する必要がある場合、一部の外部システムではなくスタブを調べました。 また、発信情報を確認するために、WebサービスのJavaリクエストを送信しました。
サーバーは、Webサーバーとアプリケーションサーバーの2つの部分で構成されています。 Webサーバーは、タイプセットと応答の送信を担当し、アプリケーションサーバーはアプリケーションロジックを担当します。 また、Java Data Beanを介してロジックにアクセスし、JavaからSiebelアプリケーションロジックを作成するための完全なプログラミングインターフェイスを取得しました。
パフォーマンステスト。
なぜなら テストはJavaで書かれています、なぜなら それらはうまく並行しており、JMeterでテストを「設定」するだけで、基本的にはシステムに機能テストをロードできます。 また、機能テストのサポートとともにテストがサポートされました。 つまり 新しいビルドに新しいバージョンのスクリプトが必要な場合、機能テストを実施するためにこれらのスクリプトを更新します。
テクノロジースタックがどのように機能するかを理解し、インタラクションのオプションを理解しました。
その結果、次のものを受け取りました。
•クイックテスト
•簡単にスケーリングできる予測可能な結果
•任意のレベルでSiebelと対話する機能
私の報告書が「Siebelでの作業方法」という指示として認識されることは望ましくありません。 テクノロジースタックを見て、内部にあるものを確認してください。 これは私たちの仕事をより良く、より面白くします。
システムの実装からのテストを見ると、次のことができます。
•テストタスク自体の複雑さを軽減する
•スクリプトの複雑さと長さを減らす
•速度と安定性を高める
•自動テストの新しいアプリケーションを見つける