今年の初めに、テンゾールはイワノボ市でミートアップを開催し、そこで私はインターフェースのファジーテストを使った実験についてプレゼンテーションを行いました。これがこのレポートの写しです。
サルがすべてのQAを置き換えるのはいつですか？手動テストとUI自動テストを中止して、ファジーに置き換えることは可能ですか？単純なTODOアプリケーションの場合、完全な状態と遷移の図はどのようになりますか？実装の例と、そのようなファジーがカットの下でどのように機能するか。
こんにちは！私の名前はセルゲイ・ドクチャエフです。過去7年間、私はTenzorであらゆる形態のテストを行ってきました。
当社の製品の品質には400人以上の責任があります。それらの60は、自動化、セキュリティ、およびパフォーマンステストに専念しています。数万のE2Eテストをサポートし、数百ページのパフォーマンスインジケーターを監視し、産業規模で脆弱性を特定するには、戦闘でテストおよび時間テストされたツールと方法を使用する必要があります。
そして、原則として、彼らは会議でそのようなケースについて話します。しかし、これ以外にも、産業規模での適用が依然として難しい興味深いことがたくさんあります。それは興味深いので、それについて話しましょう。
あるシーンの映画「TheMatrix」で、モーフィアスはネオに赤または青の錠剤を選ぶように勧めています。トーマス・アンダーソンはプログラマーとして働いていました。彼がどのような選択をしたかを覚えています。もし彼が悪名高いテスターだったら、彼は両方のタブレットをむさぼり食って、システムが非標準の条件でどのように動作するかを確認したでしょう。
手動テストと自動テストの組み合わせがほぼ標準になりました。開発者はコードがどのように機能し、ユニットテストを作成するかを最もよく知っており、機能テスターは新しい機能または頻繁に変更される機能をチェックし、すべての回帰はさまざまな自動テストに進みます。
ただし、自動テストの作成と保守では、突然、自動作業が少なくなり、手動作業が非常に多くなります。
- 何をどのようにテストするかを理解する必要があります。
- ページ上の要素を見つけ、必要なロケーターをページオブジェクトに移動する必要があります。
- コードを記述してデバッグします。
- — . / , , ROI .
幸いなことに、テストの世界には2つまたは3つのタブレットはありません。そして全体の分散：セマンティックテスト、正式な方法、ファジーテスト、AIベースのソリューション。そしてさらに多くの組み合わせ。
タイプライターで無限に長い間タイプする猿は、与えられたテキストを事前にタイプすることができるという主張は、テストに固執しています。良さそうです。1つのプログラムで画面をランダムな場所で際限なくクリックさせることができ、最終的にはすべてのエラーを見つけることができます。
そのようなTODOを作成して確認したいとします。私たちは適切なサービスまたはツールを使用して、サルの行動を確認します。
同じ原則で、私の猫はどういうわけか、キーボードの上に横たわって、取り返しのつかないほどプレゼンテーションを壊し、もう一度やり直さなければなりませんでした。
10回のアクションの後、アプリケーションが例外をスローする場合に便利です。ここで、私たちのサルはエラーが発生したことをすぐに理解し、ログから少なくともそれがどのように繰り返されるかを理解できます。 100Kのランダムクリック後にエラーが発生し、有効な応答のように見える場合はどうなりますか？このアプローチの唯一の重要な利点は、最大限のシンプルさです。ボタンを押すだけで完了です。
このアプローチの反対は、正式な方法です。
これは2003年のニューヨークの写真です。地球上で最も明るく混雑している場所の1つであるタイムズスクエアは、通過する車のヘッドライトによってのみ照らされます。その年、カナダと米国の何百万人もの人々が、カスケード発電所のシャットダウンのために3日間ストーンエイジにいることに気づきました。インシデントの主な理由の1つは、ソフトウェアのレース状態エラーでした。
エラークリティカルなシステムには、特別なアプローチが必要です。直感やスキルではなく、数学に依存する方法は、正式と呼ばれます。また、テストとは異なり、コードにエラーがないことを証明できます。モデルは、テストすることになっているコードを書くよりも作成するのがはるかに困難です。そして、それらの使用は、計算に関する講義で定理を証明するようなものです。
スライドは、TLA +言語で記述された2ハンドシェイクアルゴリズムのモデルの一部を示しています。現場で金型をチェックするときにこれらのツールを使用することは、トウモロコシ植物の空気力学的特性をテストするためにボーイング787を構築することに匹敵することは誰にとっても明らかだと思います。
従来、エラーが発生しやすい医療、航空宇宙、銀行業界でさえ、このテスト方法を使用することは非常にまれです。しかし、間違いのコストが数百万ドルまたは人間の生活で計算される場合、アプローチ自体はかけがえのないものです。
ファジーテストは現在、セキュリティテストのコンテキストで最も頻繁に表示されます。そして、このアプローチを示す典型的なスキームは、OWASPガイドから引用しています。
ここにテストが必要なサイトがあります。テストデータとツールを備えたデータベースがあり、指定されたデータをサイトに送信します。ベクトルは、経験的に取得された通常の文字列です。このような文字列は、脆弱性の発見につながる可能性が最も高いです。これは、多くの人がアドレスバーのURLの数字の代わりに自動的に配置する引用符のようなものです。
最も単純なケースでは、リクエストを受け入れるサービスとリクエストを送信するブラウザがあります。ユーザーの生年月日を変更する場合を考えてみましょう。
ユーザーは新しい日付を入力し、「保存」ボタンをクリックします。リクエストは、json形式のデータとともにサーバーに送信されます。
そして、すべてが順調であれば、サービスは200コードで応答します。
プログラムでjsonを操作するのは便利であり、送信されたデータの日付を見つけて決定するためのファジーツールを教えることができます。そして、彼はそれらの代わりにさまざまな値を置き換え始めます、例えば、それは存在しない月を送信します。
また、無効な日付に関するメッセージではなく例外を受け取った場合は、エラーを修正します。
APIのファジー化は難しくありません。ここにjsonで送信されたパラメーターがあります。ここでは、要求を送信し、応答を受信して分析します。 GUIはどうですか？
デモテストの例のプログラムをもう一度見てみましょう。その中で、新しいタスクを追加したり、完了をマークしたり、バスケットを削除して表示したりできます。
分解を扱う場合、インターフェイスは単一のモノリスではなく、個別の要素で構成されていることがわかります。
それぞれのコントロールでできることはあまりありません。ホイールとキーボードの2つのボタンが付いたマウスがあります。要素をクリックし、その上にマウスカーソルを移動すると、テキストフィールドにテキストを入力できます。
テキストフィールドにテキストを入力してEnterキーを押すと、ページはある状態から別の状態に移行します。
概略的には、次のように表すことができます。
この状態から、リストに別のタスクを追加して3番目に移動できます。追加されたタスクを
削除できます。タスク、最初の状態に戻る：
または、TODOラベルをクリックして、2番目の状態のままに
します。次に、このアプローチの概念の証明を実装してみましょう。
ブラウザを操作するには、chromedriverを使用し、状態図とNetworkX pythonライブラリを介した遷移を操作し、yEdを介して描画します。
ブラウザを起動し、グラフインスタンスを作成します。このインスタンスでは、2つの頂点間で方向が異なる多くの接続が存在する可能性があります。そして、アプリケーションを開きます。
次に、アプリケーションの状態を説明する必要があります。画像圧縮アルゴリズムにより、PNG画像のサイズを状態識別子として使用し、__ eq__メソッドを使用して、この状態と他の状態の比較を実装できます。反復属性を通じて、再処理を除外するために、すべてのボタンがクリックされ、この状態のすべてのフィールドに値が入力されていることを修正します。
アプリケーション全体をバイパスする基本的なアルゴリズムを作成します。ここでは、グラフの最初の状態を修正します。ループでは、この状態のすべての要素をクリックして、結果の状態を修正します。次に、次の未処理の状態を選択して、手順を繰り返します。
現在の状態をファジー化するときは、毎回新しい状態からこの状態に戻らなければなりません。これを行うには、nx.shortest_path関数を使用します。この関数は、基本状態から現在の状態に移行するためにクリックする必要がある要素のリストを返します。
アクションに対するアプリケーションの応答が終了するのを待つために、wait関数はNetwork Long Task APIを使用して、JSが作業でビジーであるかどうかを示します。
アプリケーションに戻りましょう。初期状態は以下のとおりです。
アプリケーションを10回繰り返した後、状態と遷移の次の図が表示され
ます。22回繰り返した後、これは次のようになります。
スクリプトを数時間実行すると、すべての可能な状態をバイパスしたことが突然報告され、次の図が表示され
ます。やりました。そして、このスクリプトを実際のWebアプリケーションに設定するとどうなりますか。そして、混乱
が発生します。バックエンドで変更が発生するだけでなく、タイマーやイベントに反応するときにページ自体が常に再描画されます。同じアクションを実行すると、さまざまな状態が発生する可能性があります。しかし、そのようなアプリケーションでも、スクリプトが大幅な変更なしで処理できる機能の一部を見つけることができます。
テストに持っていきましょうVLSI認証ページ：
そしてそれについては、状態と遷移の完全な図を作成するのに十分な速さであることが判明しました：
すばらしい！これで、アプリケーションのすべての状態をトラバースできます。そして純粋に理論的には、アクションに依存するすべてのエラーを見つけます。しかし、プログラムの前にエラーがあることを理解するようにプログラムにどのように教えますか？
テストでは、プログラムの応答は常にオラクルと呼ばれる特定の標準と比較されます。それらは、技術仕様、モックアップ、プログラムアナログ、以前のバージョン、テスターの経験、正式な要件、テストケースなどです。これらのオラクルのいくつかをツールで使用することもできます。
「以前は違っていた」という最後のパターンを考えてみましょう。自動テストは回帰テストに従事しています。
TODOを10回繰り返した後、グラフに戻りましょう。
ショッピングカートを開く原因となるコードを壊して、もう一度10回実行してみましょう。
次に、2つのグラフを比較して、状態の違いを見つけます。
このアプローチを要約できます。現状
では、この手法を使用して、小さなアプリケーションをテストし、明らかなエラーまたは回帰エラーを特定できます。GUIが不安定な大規模なアプリケーションで採用する手法については、大幅な改善が必要になります。
すべてのソースコードと使用されている資料のリストは、リポジトリhttps://github.com/svdokuchaev/venomにあります。テストでのファジーの使用法を理解したい人には、The FuzzingBookを強くお勧めします。そこでは、パートの1つで、単純なhtmlフォームをファジー化するための同じアプローチが説明されています。
