夕方に報告が重なるとき、保存と一覧の速さをどう試す？

保存と一覧の、誰が待つどの操作を試すか決める

性能テストは、システムへ仕事の負荷をかけ、その条件での応答や処理の様子を確かめるものです。本稿では、夕方に重なる報告の保存と一覧表示を扱います。「保存できるか」という動作の確認に加え、どんな使われ方のときに、どこまで待ち、失敗せずに必要な結果を得られるかを試す条件へ落とします。

同じ夕方に、点検担当と管理者は、それぞれ何が終わるのを待つのでしょうか。

ここでいう負荷は、単なる社員の総数ではありません。どの役割が、何を、どの頻度で繰り返し、どれくらいの時間重なるかを含みます。画面を開いて内容を読んでいる状態と、保存要求を繰り返す状態は同じではありません。

Oracleの負荷テストの説明も、利用者の振る舞いによって処理量が変わる点を扱っています。この記事では人数から負荷を自動計算する式や他社の値を採用せず、夕方の実際の使い方を調べ、想定と観測を区別する考え方に使います。

必要な速さ自体がまだ説明できない場合は、業務に必要な速さなどの非機能要求を決める方法へ戻ります。本稿は、その条件を特定の操作・負荷・測定の記録へ結ぶ段階です。

保存と一覧で、測る始点・終点と判断条件をそろえる

測定値の比較では、時計の始まりと終わりをそろえます。サーバーの内部処理が終わるまでの時間と、利用者の画面へ結果が出るまでの時間は、そのまま同じ値として比べられません。どこを測った結果か、記録を読めるようにしてから試します。

保存と一覧で、測り始める操作と、測り終える表示は同じでしょうか。

必要な結果が出たことも確かめる

速く応答が返っただけでは、保存したかった内容が保存されたとは限りません。エラーの案内がすぐ返った結果を、速い保存成功へ数えないようにします。保存確認の表示と必要な記録、一覧に出るべき内容を何で確かめるかは、対象仕様と試験目的に合わせて開発側と決めます。

APIなど内部の要求を使って負荷をかける場合は、その要求が実際の画面操作のどこに当たるかを聞きます。画面の描画や端末側の処理まで含むかも明示してもらいます。ツールの緑色の表示だけで、利用者の仕事が終わったと判断しないためです。

何を「目標を満たした」と扱うか先に合わせる

保存と一覧のそれぞれで、どの時間の測り方を使い、どの失敗をどう数え、どの負荷範囲で評価するかを決めます。平均だけか、遅い操作がどれくらいあるかも見るかによって、同じ結果の読み方が変わります。必要な測り方を目的に合わせ、業務側が何に困るかと対応させてください。

この架空メモで合意した応答時間の目標、エラーの条件、同時利用の条件、時間あたりの処理量の条件は、いずれも未確認です。目標がないまま得た観察は、次の条件を相談する材料にはできますが、後から都合のよい値を置いて合格にしません。

保存だけ・一覧だけ・重なる場面を、別の記録にする

保存だけ、一覧だけ、両方が重なる場面を分けると、どの条件の結果かを指せます。単独の試験は、一つの操作の様子を読む材料です。重なる場面は、同時利用という目的に対応した別の記録です。単独でよかったという結果だけを寄せ集めても、夕方の重なりを確かめたことにはなりません。

三つの場面は、どの操作を単独で、どの操作を同じ時間帯に試すのでしょうか。

この節の解説図を原寸で見る

報告の保存だけ

行う役割は「点検担当」、操作は「点検報告を保存して確認表示を見る」です。

予定する負荷は未取得、実施した負荷も未取得です。応答時間とエラーの観測はいずれも未取得で、結果と判断もいずれも未確認です。

点検担当が保存する一回の始まりと終わり、繰り返す間隔を試験の操作へ結びます。どの報告データを使い、保存の繰り返しでデータの量や状態が変わるかも確認します。保存だけの記録に、管理者の一覧利用が含まれるとは読みません。

一覧を見るだけ

行う役割は「管理者」、操作は「点検報告の一覧を開く」です。

予定する負荷は未取得、実施した負荷も未取得です。応答時間とエラーの観測はいずれも未取得で、結果と判断もいずれも未確認です。

管理者がどんな条件で一覧を開き、何を表示し、どの間隔で再び開くかを確かめます。一覧が空の状態と、必要な報告がある状態を混ぜないようにします。この例では検索条件や表示件数を設定していないため、実際の仕事を業務側に聞いて具体化します。

二つが重なる夕方

行う役割は「点検担当と管理者」、操作は「報告保存と一覧表示を同じ時間帯に試す」です。

予定する負荷は未取得、実施した負荷も未取得です。応答時間とエラーの観測はいずれも未取得で、結果と判断もいずれも未確認です。

保存と一覧がどの時間帯にどのように重なるかを、同じ試験の記録へ残します。二つを一度ずつ続けて実行しただけなら、重なった条件を試したとは限りません。実際に与えた負荷の記録と、それぞれの応答・エラーを対応させて説明してもらいます。

版・環境・データと、予定した負荷・実施した負荷を照合する

三場面の結果を読む前に、対象の版・環境・データと、どんな負荷をかける計画かを対応させます。操作が同じでも、一覧の元データが軽かったり、違う版だったりすれば、単純な比較はできません。目的に必要な条件がそろったか、違いがあるなら何を判断できるかを開発側に説明してもらいます。

保存と一覧の結果は、同じ版・場所・データの、どんな負荷の話でしょうか。

この節の解説図を原寸で見る

1. 対象の版と試す場所を特定する対象のシステムの版は未確認、試験環境も未確認です。対象を識別できる版と構成、試してよい場所を確認します。試験環境が不明なことを、環境が存在しないという断定や、本番へ負荷をかけてよい許可へ変えません。
2. 本番との違いを説明してもらう本番との差は未確認です。機器や構成、通信、つながる相手など、測定へ関係する違いを聞きます。小さな環境の結果を機器の台数だけで倍率計算し、本番でも同じように動くと即断しないでください。
3. 使う報告データの量と状態を合わせるデータ量とデータの状態はいずれも未確認です。報告の内容や一覧の元になる記録、試験前に戻す状態を目的に合わせます。個人情報など実データの利用が必要かも別に確認し、性能の説明のために実顧客の内容を持ち込む前提にはしません。
4. 夕方の重なり方と、予定する負荷を決める時間帯の記述は「夕方の業務が重なる想定（実測時刻未取得）」です。業務担当への聞き取りや利用の記録から、何がどの頻度で重なるかを調べます。想定だけで決めた範囲と観測に基づく範囲を分け、具体的な時刻・人数・件数を本稿から補いません。

負荷をかける側が、予定した仕事を作れたかも見る

試験ツールへ設定した数と、実際にシステムへ与えた負荷は分けて読みます。負荷を作る側が処理しきれず予定に届いていなければ、その応答を予定負荷の結果として合格にはできません。開発会社へ、予定した操作と実施の記録を対応させてもらいます。

始め方、負荷を保つ時間、終え方や中断する条件も、目的と利用環境へ合わせて相談します。いきなり一斉に操作する条件を試したいのか、少しずつ増える利用を試したいのかで、確かめる場面は違います。本文にはその時間や回数を固定していません。

ISTQBの性能テストのシラバスは、対象・環境・データ・負荷の構成を計画に対応させる考え方を示しています。以下の架空例は、その数値や図を転用せず、夕方の二操作を何と結んで相談するかを説明するものです。

応答とエラーを条件へ戻し、判断できない範囲を保留する

結果は、まず「計画した条件で、必要な操作が実際に行われたか」を読み、そのうえで合意した条件と比べます。保存が速く見えてもエラーの応答だけだった、一覧の試験だけ実施負荷が軽かった、といった場合は、数字だけを横に並べて結論を出せません。次は判断の考え方で、今回の架空メモに実際の結果が出た記録ではありません。

この結果から判断できるのは何で、どの材料がなければ保留するのでしょうか。

この節の解説図を原寸で見る

条件が対応し、必要な測定と結果がそろっている

保存と一覧を別々に、合意した測定範囲・負荷・データ条件で照合します。応答だけでなく必要な結果が得られたかとエラーの扱いも確認します。どこまでの条件を満たしたかを残し、別の負荷や本番の全状況へ判断を広げないようにします。

応答は短いが、エラーや処理の不足がある

何の操作がどこまで進み、何が得られなかったかを開発会社へ返します。失敗した要求が短時間で返ると、平均だけでは速く見えることがあります。失敗の扱い、成功と数えた条件、同じ時間帯の処理量を照合し、業務側へ影響する仕事を説明してから修正や追加確認を相談します。

単独では確認できたが、重なった条件が分からない

単独の結果は単独の条件の結果として残し、夕方の同時利用の判断は保留します。重なる場面の実施負荷と、保存・一覧それぞれの結果を求めます。片方だけの合格や、一つの合計平均をもって両方が使えるとしないでください。

合意条件、実施負荷、測定結果のどれかが欠ける

欠けた項目と、そのために判断できない範囲を残します。目標が未確定なら業務責任者へ、負荷や測定の記録が不明なら開発会社へ、同じ場面の説明を添えて確認します。数字がないことをエラーなし、負荷ゼロ、合格、または失敗へ変えません。

回答と修正を同じ操作へ戻し、測定と業務判断を更新する

質問へ回答が届いたり修正が入ったりしたら、何を変えたかを元の記録へ対応させます。目標が決まったこと、試験を実行したこと、条件を満たした結果が得られたことは、それぞれ別の状態です。回答の資料だけをもらって、保存や一覧が速くなったと書き換えないようにします。

届いた回答や修正は、どの条件と、どの再確認の記録へ戻すのでしょうか。

業務側へは、待てる条件と重なりの根拠を聞く

現場と管理者の業務責任者に、どの待ち時間でどの仕事が困るか、夕方の重なりがどこから分かるかを尋ねます。回答で目標や使い方が変われば、その根拠を記録に添えます。実際の回答者や了承を、本稿で決定したことにはしません。

開発側へは、対象・測り方・実結果を対応させて求める

「保存と一覧を、どの版、環境、データ、負荷で試しましたか。予定した負荷に対して実施した記録と、二操作それぞれの応答・エラーを示してください」のように聞きます。データ量や環境を変えた結果なら、変更点と、それでも言える範囲・言えない範囲を説明してもらいます。

修正後は、変わった対象版を明示し、比べたい条件はそろえて再確認します。条件も変えたなら、修正の効果だけによる差と即断せず、変えた点を別に残します。影響する既存の仕事も相談して必要な確認を選び、古い結果を新しい版の合格へ移しません。

この性能確認だけで、業務全体の受入や本番へ進める判断まで済んだとはしません。確認範囲と残る条件を関係者へ渡してください。全体の試験を始める前の準備は、テスト計画で対象・役割・開始条件をそろえる方法、受付と一括集計の時間を選ぶ問題は、受付と一括集計をいつ動かすか考える方法で扱っています。

まとめ：夕方の保存と一覧を、二行の仕事から試験へ結ぶ

最初に何を並べれば、夕方の性能テストを具体的に相談できるでしょうか。

保存だけ、一覧だけ、両方が重なる場面は別に記録します。版・環境・データ、測る範囲、予定した負荷と実施した負荷を対応させ、応答とエラー、得られた結果を合意条件へ戻して読みます。条件が足りなければ、その範囲の判断を保留し、答えられる相手へ具体的に返してください。

元の架空メモの注意は「負荷値、応答時間、失敗率、合格、改善成功、実サービス成果は全て未取得。単独シナリオと重複シナリオは修正前後ではない。」です。