この記事では、フルタイムのパフォーマンステスターの存在を正当化するほどの規模はないプロジェクトにおいて、「従来の」「機能テスト」のテスターおよびテストグループがパフォーマンステストに取り組んだ事例をいくつか紹介します。私が行ったこと、どのようにやったかを説明し、その過程で、パフォーマンステストとパフォーマンスエンジニアリングの違いにも触れたいと思います。
では、始めましょう。
データに溺れる
私がSocialtextで働き始めて間もないころ、Python のまったく新しいバックエンドを使用して開発された新規モジュールをリリースしました。テスターはシステムをよく理解していませんでした。システムのパフォーマンスがどうなるか、私たちにはわかりませんでした。私たちはこの懸念と、一から負荷テストを実施するとどのくらいの時間がかかるかをCEOに伝えました。CEOは臨時のエンジニアリング担当副社長でもありました。CEOは運用開始を望み、負荷テストをスキップするように言いました。
一週間後、チームのレトロスペクティブミーティングに出席したとき、質問が上がりました。「なぜQAはパフォーマンスの問題を見つけられなかったんだ？」CEOはこう答えました。「Mattは問題の可能性を指摘し、いくつかの選択肢を提案した。私は予測されたリスクを取ることを決断し、パフォーマンステストをスキップした。次の議題は？」
これで1、２週間は静かになりましたが、すぐに疑問が再燃しました。QAはパフォーマンステストとして何をするつもりなのか？
簡単に答えれば、何もする必要はありませんでした。どの処理が遅いかを突き止めるためにソフトウェアをテストする必要はありませんでした。私たちはそれが遅いのを知っていました。各URL「ページ」のロードにどれくらい時間がかかっているかというデータ、メトリクスもありました。メトリクスは平均値、中央値、四分位、平均値下位 10%、平均値下位1%などのデータでソート可能でした。これはパフォーマンステストの問題ではなく、パフォーマンス改善の問題でした。
厳密にいえば、そういった議論も成り立ちます。テストは、シナリオを設計し、テストを実行し、運用レベルの負荷のもとでページの保存に6秒かかっているというデータを提供します。これで終わりとかたづけて、さっさと次に行きます。
いっぽうパフォーマンスエンジニアリングは、実際にシステムのどこに弱点があるかを突き止め、補強する方法を探ります。古典的なやりかたは、モニタリングとプロファイリングです。これについてはこの後で触れます。
データベースの問題
また別の例で、こちらは保険会社の業務でした。ご推察のとおり、システムへの新規顧客の追加、担保範囲の追加および削除処理、支払請求の入力および処理など、大量のデータベース処理がありました。大部分の処理はERPシステムが担っていました。プログラマーはデータの入出力と、それらのデータを「ぜんぶ振り混ぜる」（それがWebサイト、データウェアハウス、カスタマイズです）のを自動化していました。
私は「テストの人」としてデータ抽出を支援するために引っ張りこまれました。このデータ抽出は実行に4時間かかり、さらにだんだん遅くなっていました。そのまま長引けば、一晩中実行する必要があり、バッチ処理の時間に食い込んだり、データベース接続がタイムアウトしたりするようになるでしょう。問題無く修正するための時間としておそらく1か月かかり、2か月は大きな問題がありませんでした。これは時間がかかりすぎましたがパフォーマンステストとしては簡単です。完了しました。エンジニアリングにはもう少し手間が必要でした。
プロファイリングでは、トランザクション全体をできるかぎり小さなピースに分割します。Webサイトの場合、ピースは描画時間、サーバー間の遅延、サーバーの処理時間などが考えられます。サーバー上での処理時間がわかれば、アプリケーションをプロファイリングして、コードの各行にどれだけ時間がかかっているかを確認できます。次の図は、Firefox の [(T)ools] -> [(D)eveloper] -> [(N)etwork] を使用し、私のWebサイトである xndev.com をロードしたときのウォーターフォールダイアグラムです。ページは2秒以内にエラーなしでロードされ、描画されていますが、この外側のHTMLについて調べてみたいと思います。
データベースの問題に対処するため、私はPerlで書かれたコードをDevel:Profilerでプロファイリングしました。よく使われるツールの大半には、こうしたプログラムがあります。プログラムが終了すると、ツールが結果を出力し、どのメソッドでどれくらいの時間が使われたか、メソッドが何回呼び出されたかがわかります。プログラムはselect文を実行する行で驚くほど長い時間を消費していました。select文自体はそれほど遅いわけではなく、ほんの数秒でした―しかし、何万回と呼び出されていたのです。
プログラマーは次のように書いていました。
Select every customer_id that qualifies
For each customer_id
Select all customer data where id=customer_id
Export customer data
Next
私はこれを次のように書き換えました。
Select all customer data that qualifies into one query result
For each customer_id
Export customer data
Next
突如、処理時間が何時間も短くなり、45分以内に実行されるようになりました。45分は、データベースレコードを開いたままにしておくには長すぎる時間です。そこで、別のステップを追加して、データをインメモリのデータ構造に入れ、データベース接続をクローズしてからfor loopを実行するようにしました。これによって、処理時間は15分にまで縮まりました。
アプリケーションのパフォーマンスが向上しただけでなく、よりテストしやすくなりました。処理をデータ収集とエクスポーターの2つのピースに分割することができました。
予算はどこに？
エンジニアリングアプローチの興味深い点は、予算を使っていないことです。「パフォーマンスエンジニア」はいません。新しくツールを買う必要も、コンサルタントを雇う必要も、「手法」転換の必要もありません。プロジェクトのスケジュールに影響を与えることなく、自由裁量の時間で完了できるケースも多くあります。
その代わりに、課題に集中し、協力して問題を解決する必要があります。
上記の例は単純なシステムです。コード自体が問題でした。ボトルネックがCPU、ディスク、メモリ、あるいはネットワークではないかを判断するために背後でモニターして修正方法を考える必要はありませんでした。このようなフルタイムのパフォーマンステスターを置くには規模が足りない「最低限の」ケースでパフォーマンスの問題が見つかった場合、多くは問題そのものは非常に単純なものです。誰かが飛び込んでデータを取ってくるだけです。パフォーマンステストからパフォーマンスエンジニアリングへの移行は、役職の垣根を緩和し、価値を増加させ、「QAは重荷だ」という決まり文句を言わせないための大きな進歩です。
試してみてください。
Matthew Heusser はプロジェクト管理、開発、ライティング、システム改善の知識を持ち、Excelon Development の Managing Director を務めています。そしてもちろん、ソフトウェアテストも行っています。
（この記事は、開発元Gurock社の Blog 「Performance Testing with No Budget」2020年9月7日の翻訳記事です。）