JSTQBから、性能テストのシラバスの翻訳が出ました。
ついつい当たり前に思ってしまいがちですが、テストの知識のデファクト・スタンダードといえるISTQBのシラバスが日本語で読めるというのは、本当にありがたいことですね。訳者のみなさまに感謝。
いわゆる「非機能テスト」というものはそれぞれに独特の難しさがあり、性能テストもその例に漏れません。このシラバスは、性能テストにおいて何を考慮し、何をしなければいけないかについて、全体感を与えてくれます。
この記事では、シラバスを読みながら自分が考えたこと・理解した（気になっている）ことについて書いていきます。
「性能」という品質特性
「性能」（または「性能効率性」）という言葉について、あらためてISO 25010を見てみると、以下のように定義されています（翻訳はわたし）。
なお「性能効率性」が品質特性で、続く3つが副特性。副特性はシラバスではそれぞれ、「時間効率性」「資源効率性」「キャパシティ」に対応します。
性能効率性
明文化された条件のもとで利用されるリソース*1の量にかかわる性能を表す特性。この特性は、以下の副特性からなる。時間的な振る舞い
プロダクトやシステムがその機能を果たす際に、レスポンス・処理時間・スループットが要件を満たしている度合いリソースの利用
プロダクトやシステムがその機能を果たす際に、利用するリソースの量や種類が要件を満たしている度合いキャパシティ
プロダクトやシステムのパラメターの上限が、要件を満たしている度合い
ファミレスのホールで働く店員さんを例にとってみます。
「この人、デキる人かな？」と評価するには、どういう点に着目すればいいでしょうか。
チャイムで呼ばれたらそのテーブルに向かい、オススメやオプションを提示しながら、お客さんの注文を聞き取り、厨房に伝える。
この作業の正確さは、品質特性でいうと「機能正確性」というものにあたるでしょう。
しかし、この作業に毎回10分もかかっていたのでは困ります。お客さんの人数や性質に依るけれど、概ねx分くらいで済ませられる。これが「時間効率性」にあたります。
さて、この店では注文を今も紙とボールペンでメモしている。ベテランの店員さんは、メニューごとに自分なりの符号を編み出していて、一品をカタカナ3文字くらいで表現できるのですが、新人はそれができず、長々と商品名称を書いてしまいます。
紙とボールペン、めっちゃ使います。これが「資源効率性」です。
まあ、紙とボールペンを大量に使うくらいなら、「もったいないなあ」で済むかもしれません。ところがある日、ボールペンのインクが切れてしまう。その店員さんは手書きでしか注文を受けられないので、対応できず固まってしまう・・・。これでは困ります。
さらに、お客さんがたくさんいてひっきりなしに呼ばれたり、1回の注文の内容が大量だったときにも耐えられるか。これが「キャパシティ」ですね。
「キャパシティ」に関する事例
『ポストモーテム みずほ銀行システム障害 事後検証報告』という本では、以下のような事例が紹介（引用の太字はわたし）されています。
e-口座に切り替える定期性預金口座は約259万件。システム上の制限から45万件ずつ6回に分け、2月27日から3月14日までの土日にe-口座への一括切替処理を実施することに決めた。
この一括切替処理のシステムテストに際しては、実機での処理は8万件までしか試さなかった。実は定期性預金口座システムのDBは、前述のインデックスファイルに関する容量制限に起因して、更新件数が64万2969件を超えるとそれ以上は更新できなくなるという問題を抱えていた。しかしテストでの処理件数が不十分だったため、DBの設定にリスクがあることを検出できなかった。
これを性能テストと呼ぶかはちょっと微妙ですが、上述した品質特性でいうと、キャパシティにあたる問題に見えます。
本番環境と同等の環境や条件が手に入らないとき、何らかの仮定に基づいて、本番環境のグレードを一部下げた、サブセット的な環境・条件において性能テストを行うことになるでしょう。
そのリスクについては、「4.2.8 性能テストケース実行のための準備」で以下のように語られています（引用の太字はわたし）。
性能と環境の関係は非線形であることを覚えておくことが重要である。つまり、テスト環境が本番の標準的な環境から離れれば離れるほど、本番の性能を正確に予測することは難しくなる。テストシステムが本番と同等でなくなるほど、予測の信頼性が低くなり、リスクレベルが高まる。
この話については、また考えていきたいと思います。
*1:「時間」もリソースの1つという扱いなのだと思います。
