これは フェンリル デザインとテクノロジー Advent Calendar 2022 23日目の記事です。
インフラ担当の柴田です。今回はプライベートで関心を寄せていることということで、負荷テストについて書きますが、特にオチ（結論）はありません。
負荷テストとは？
負荷テストは、非機能テストの一部で、システムの品質特性を評価します。ただ、一言で負荷テストと呼んでいても、実際のテストではさまざまな目的をもって実行されています。 私がなぜ負荷テストに関心を寄せているかというと、いざ自分が負荷テストをしようとすると、なかなかに難しく「こんな難しいのを他の人は本当に適切に実施できているのか？」と考えたからです。
負荷テストの難しさ
負荷テストではインフラも重要なため、私も負荷テストを手伝うことがあります。少ない経験の中で、次のような点で難しいと感じています。
1. 非機能テストはそもそも難しい
私は非機能テストは、機能テストと比べると目標に具体性がない場合が多く、難しいと考えています。
目標に具体性がないのは、そもそも非機能要件をまとめるのが難しい点からきていると思います。IPAの「システム構築の上流工程強化（非機能要求グレード）」のページにある「機能／非機能要求の相違点と課題」が分かりやすいのですが、非機能要件は具体的に定義するのが難しく、要件定義から漏れるか、要件定義に項目があったとしても内容が曖昧な場合が多いように思います。
2. 将来の負荷の予想、あるいは負荷モデルの作成が難しい
負荷テストでは多くの場合、将来の負荷に対してシステムがどのように動くのかを評価します。 そのためには、当然将来の負荷を予想する必要があります。しかし、将来どのぐらいのユーザーが使うのか、またそれぞれのユーザーが、どのように操作するのかを予想するのは非常に困難です。
例えば、既存のシステムがあり、負荷は既存のシステムと同じを想定するとした場合も、それぞれのユーザーがどのように操作するのかを考えるという難しさが残ります。
3. テストツールを使いこなすのが難しい
ウェブ系のシステムはそもそもが複数のユーザーから利用されることが前提になっているため、負荷テストではツールを使って負荷をかけます。そのため、負荷テストを行うには負荷テストツールに習熟する必要があります。
負荷テストのツールは多数ありますが、私の周りではApache JMeterやLocustをよく聞きます。
Apache JMeterは、GUIでテストケースを作成するため、始めやすいのですが、要件にあうテストをつくるためには、多くのプラグインの使いかたを覚えたり、BeanShellで処理を書いたりと習熟には時間がかかります。 一方、LocustはPythonでテストケースを記述するため、Pythonの習熟が必要です。
4. テストに使える時間が少ない
負荷テストでは動くシステムが必要なため、システム開発の後半で行われます。しかし、開発者はギリギリまで開発に時間を使いたいと考え、顧客はできる限り早くシステムの運用を開始したいと考えます。これらの思惑が交差した結果、負荷テストに使える時間が短くなります。もしくは、短くならないにしても時間へのプレッシャーが強くなります。したがって、短い時間で質の良いテストをする必要があり、うまく行うのは難しいです。
負荷テストを適切に実施できているのだろうか？
負荷テストが難しいとはいえ、現実にはなんとかなっています。 現実の負荷と誤差があることを念頭に、安全マージンをとることもありますし、あらゆる原因でシステムが停止することを念頭に、システムの回復性を高めているので、多少想定外の負荷が発生したとしても問題にならないこともあります。
しかし、問題にならないからといって実施した試験が適切だったのでしょうか。もちろん目的を定めその目的を達成するために適切と考える試験を実施していますが、そもそも目的すら自分の能力の限界によって、本来適切な負荷テストからは遠い試験になってはいないだろうか。そんな疑問がふと頭をよぎります。
理想の負荷テストをもとめて
理想の負荷テストとはどういうものでしょうか、その謎を解明するため我々はアマゾンの奥地へと向かった……。
終わりに
本来は理想の負荷テストについてまで書きたかったのですが、どうにもまとまらず締め切りを迎えてしまったので理想の負荷テストについては次回へ持ち越しとなります。 特に、負荷の設計については、よければ皆さんが考える理想の負荷テストについて教えていただけると嬉しいです。負荷の設計は現実的に可能な範囲で実現するために、理想とのずれができているので、本当はこうしたいみたいなのがあるのではと思っています。
