# タイトルコール テスティングジャーニーへようこそ。 このチャンネルでは、ソフトウェアテストの世界を観測するコンセプトに、 エンジニアリングマネージャー兼経営リーダーの隅井が、 ソフトウェアテストのコツや品質保証の具深さ、そして日々考えていることを話します。 # 大量のランダムデータで品質が見える？ ファジングテストを身近な例で説明 こんにちは、サミリーです。今日もテストしていますか? いよいよですね、スクラムフェス新潟が明日、明後日になりました。 勉強中になんとか終了ができて、今朝登壇の練習して、今回の時間、発表の枠が45分なので、時間を持つかなぁとか思いながら喋ってたんですけど、 今回お試しで喋ってみた感じ37分だったんで、ちょうどいいかなという感じですね。 スクラムフェス新潟でお会いできるのをお楽しみしております。 ということで今回はファザリングテストの話をします。 最近社内でファザリングテストの話が出たというか、そういう言葉ってあるよねっていう話が出たので、せっかくだなと思って今回このトピックにしております。 名前だけ聞くとよくわからないですよね。なんか難しそうですよね。ファザリングってなんだって感じなんですけど。 ちなみに英単語の意味としてのファザリングは曖昧なとかぼやけたという意味だそうです。 はい、ということでファザリングテストの話に入っていきましょう。 いつもの通りISTQBの定義から紹介をしていきます。 ISTQBっていうのはインターナショナルソフトウェアテスティングクオリティフィケーションボードの略ですかね。 要はソフトウェアテストのインターナショナル国際的な組織、団体で資格試験だったりとか、今回参照しているグローサリーは用語集ですね。用語集も出したりします。 はい、でファザリングテストを日本語で引くと、ファズテストですね。 でファズテストとは大量の意味をなさないデータを使用してテストの入力データを生成するテスト技法というふうに書かれていますね。 ちなみにこの用語が使われているシラマスはアドバンスドのテストアナリストだそうです。 なんか私がイメージしてたファズテスト、ファズテストの定義と違いました。 なんか私のイメージだとファズテストってその大量でランダムなデータを使ってテストをすることで、 脆弱性を見つけるみたいな、そういうテストの手法なのかなとイメージを持ってたんですけど、ちょっと思ってたのと違いましたが、 でもざっくり言うとと言いますか、ポイントは大量というのとランダムデータというところですね。 大量のランダムデータを入力をして脆弱性や異常動作を見つけるテストになります。 正しい入力を使うわけではなくて、変な入力をたくさん投入をして何かセキュリティホールだったりがないか、あるいはクラッシュしないかというものを検知します。 これをですね身近な例で例えてみると、ホールセンターの自動音声とかですかね、普通の人は音声案内に沿ってこれこれだったら1を押してくださいって言われたら1を押すとか2を押すとかっていう風にすると思うんですけど、 ハズイングの考え方だとシャープを10個ぐらい入力してみたりとか、999999ってやったりとか、あとめっちゃ高速でボタンを連打したりとか、 あとは何もしないでずっとほっとくとか、そういう感じになります。 例えば何もせずに放置をした状態で1時間も2時間も3時間もずっと電話を繋ぐままにできちゃうっていうのはあまり良くないですよね。 それでもし何か何か回線が壊れるってことは1本ではないかもしれないですけど、じゃあ複数でとか100人ぐらいが同じことをしたらどうなっちゃうんだろうみたいに壊れちゃうかも、もしかしたら壊れちゃうとかあるかもしれないですよね。 こんな感じでですね、ハズイングテストでは通常想定されていない不正なデータとか、予期せぬデータとか、ランダムなデータをどんどんどんどん与えてですね、 意図的に例外を発生させて、想定していなかったバグだったりとか、脆弱性を見つける手法になります。 なんか想定外っていうのは絶対起きるんですよね。 開発していく中で普通はこう使うよねっていう、ハッピーパスって呼ばれたりもするんですけれど、正常系、まずはこう普通はこうやって使うよねっていうものから設計をして、 その後かわかんないですけど、異常系もこういう時あるよね。 例えば、ボイシーなアプリとかだと、地下鉄とかに入っちゃってネットワークが急にプツって切れた場合どうなるんだろうかとか、 なんかねデータが欠けてしまった状態で何か入力フォームを送信した場合にどうなってしまうのかとか、 あとは、人間の入力じゃなくて何かシステムだったり、ボットが何か操作した時にはどうなるんだろうかとか、 上げたらキリがないぐらい正常じゃないパターンっていうのかな、通常じゃないルートだったり、異常なパターンだったりデータだったりってものすごくたくさんあるんですね。 なので、ソフトウェアテストをする時は、正常系の確認だけでは安心してはいけなくて、どういう風に壊れるのかなとか、ちゃんと壊れるのかなみたいなのも結構大事な観点だったりします。 ちゃんと壊れるのかなっていうのは、私はあんまりよくないんですけど、人間で例えって説明することがあって、 仕事めちゃくちゃ頑張ってハンドマークで労働時間めちゃくちゃ長い時に、急に人がバタンと倒れるというパターンってあると思うんですけど、 その時に、もう無理って言ってバタンって倒れる人と、何も言わずにスッて急に会社休むみたいなパターンってあると思うんですよね。 どっちがいいのかっていうと、一応今日無理とか予兆があるとか、すごく顔色悪そうだなとか、最近欠勤しがちだよねみたいな予兆があったりすると、 この人危ないかもみたいな感じでわかるじゃないですか、そんな状態で予兆があったりとか、もう無理です、休みますって言ってバタンと倒れるというか休むみたいな方が、 今人間の話にしちゃった、例え話にしちゃったんですけど、システムの場合は予兆があったりとか、もう無理ですっていう風にログを書いてくれる方が調査がしやすいわけなんですね。 事実を確認しやすいんですよね。何が起きてるのか、どういう状態になっているのかっていうのが、残っている方がその後の調査がしやすいっていう意味では、ちゃんと壊れてほしいって言ったのはそういうところで、 例えばいつプツッと切れてしまったのかとか、そのプツッと切れる前にはどんな異常だったりエラーが発生してあるのかっていうのは、ちゃんと見れるように、ログで残っているようにというか、ログを終えるように見れるようにみたいな、そういう壊れ方をしてほしいと思うわけなんですよね。 はい、ちょっと話それちゃったんですけど、今回はFuzzingテストについてお話をしました。 Fuzzingテストっていうのは、通常想定されていないような変なデータ、不正なデータ、予期せいなデータ、ランダムなデータを大量にシステムに与え続けて、意図的に例外を発生させて、それによって何か潜在的な不具合だったり、特にセキュリティの問題とか脆弱性を見つけるテストの手法でした。 # #504のコメント返し🥰 コメント返しのコーナーです。今回は504話目。サイゼリアでの体験から学ぶフェールセーフとフォールドトレランスのコメントを開始します。 佐渡健さんからコメントをいただいております。 ある程度以上の面積で人が集まる場所は、停電時に非常灯が点灯する必要があり、これは建築基準法で決められています。 避難できることを担保するために、非常灯の明るさと点灯時間に基準があります。 これがフォールドトレランスですね、というふうにご説明いただきましてありがとうございます。 建築基準法の話は全然知らなかったんですけど、やっぱりフォールドトレランスの考え方で、ちゃんと失敗した時の許容度があるように、安全なように法律にも定められているということで学びになりました。 ありがとうございます。以上コメント返しでした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 明日の放送はですね、特大ほっこり話会にしようかなと思います。 最近ほっこり話はあまりできていないので、特大版にしてしょうもない話をつらつらとしようかなと思いますので、 明日もお楽しみにしていてください。 今回の放送が役に立った、今日もお聞きに来たようなやつでハートマーク、いいねをしていただけるととっても励みになります。 ぜひぜひコメントもお待ちしております。 それではまた明日お会いしましょう。ごきげんよう。