見出し画像

テスト設計パターンを考える会 考えてみたメモ 仕様スニペット002

かいり

こちらについて今回も考えてみました！

気づいたのですが私は大体

  1. 要件（今回でいう仕様スニペット）と関連資料の読み込み

  2. そこから実装イメージ（≒詳細設計）への落とし込み

  3. さらにそこからテストケースへ変換

という思考ルーチンに沿って進める癖があるようです。

というわけで仕様の理解から

以下コピペです。

■ 仕様スニペット002：「アカウントロック」
1. ユーザはログインの際に、アカウント名とパスワードが求められます。
※アカウント名・パスワードの文字列長・文字種などについては、議論の対象外とする。
2. アカウント名とパスワードの組み合わせが正しい場合、ログインが成功します。
3. アカウント名とパスワードの組み合わせが正しくない場合、ログインが失敗します。
4. あるユーザ名に対し、ログインが3回連続で失敗した場合、アカウントがロックされます。
※アカウントロックの解除については、議論の対象外とする。
5. ログインが成功した際に、ログイン失敗回数はゼロにリセットされます。
このアカウントロックについてのテスト観点を考えてください。

仕様スニペット002

  • いわゆるパスワードログイン。おそらくアカウント名でDBを検索して、引っかかったもののパスワードハッシュと比較する普通のやつでしょう。

  • 成功すればログイン（アカウントロックされれば「アカウントロックされています」と表示が出てログインができなくなるものと想定しますが、この辺は要確認）、失敗すればログインできません。

  • 同一アカウントに対し3回連続で失敗すれば、アカウントがロックされます。

    • 数字が出てきましたので、境界値分析を使うことが確定します。

    • また、「ロック」という「状態」が出てきたので状態遷移図を使うことも視野に入ります。

  • ところで、個人的にはこれは結構リスクと隣り合わせの仕組みであると考えます。なぜかというと、「悪意を持って他人のアカウントにアクセスを仕掛ければ、他人のアカウントを容易にロックすることができる仕組み」だからです。調べたら以下のような記事がありました。

  • 実際のところ、近しい仕組みを持っているシステムで心当たりがあるのは銀行のネットバンキングです。他人のログインIDはそう簡単に類推できない&扱っている情報が最高レベルの個人情報なのでそれくらいやらないと逆に怖いですが、特に他人のログインIDが容易に類推できるようなアプリケーションである場合はリスクの検討が必要だと感じました。もちろんアカウントが乗っ取られる方がリスクが高いのは言うまでもないですが。

  • 機械的アクセス対策でreCAPTCHAを導入することも検討したいところです。（完全に話が逸れている。今回は導入しないということで話を進めます）

  • 話を戻して、（アカウントロックがなされていなければ）ログインが成功し、ログインの失敗回数は0に戻ります。

こんな感じで、要件を読んだ時点で思いついたリスクや検討事項をPdMと相談するフェーズが挟まることが多いです。ちなみに思考回路を文章化しておくと、アカウントロック→不正アクセス対策→心当たりは銀行くらい、なんでだろう→ゲームとかは？→嫌がらせできちゃいそう・・・→調べたら実例あった、という、あんまり性格の良くない想像力を働かせています。

実装イメージへの落とし込み

  • 影響のあるControllerのメソッド（API的なやつ）は一つ、ログイン処理のみです。

  • DBのパスワードハッシュ＝入力されたパスワードをハッシュ化したものと比較して、完全一致していればtrue, そうでなければfalseを返すような一般的な処理があるものと予想します。

  • ログイン失敗回数を保存しておかないといけないのでそういったカラムがDBにあるのでしょう。論理名『ログイン失敗回数』というカラムがあり、型はtinyint、デフォルト値0、null不可と仮定します（ちゃんと開発者に確認取ります）。それが失敗するごとに1, 2, 3とカウントアップしていき、3ならアカウントがロックされます。桁あふれの心配があるので、3に達したらカウントアップはしないことにします。ログインに成功すればログイン失敗回数は0に戻ります。パスワードがDBと一致しても、アカウントがロックされていればログインはできないものと考えます。

  • ついでに、『アカウント失敗回数』が3未満でも事情があってロックしたい場合もある気がするのと、アカウント失敗回数で直接判定するのがいまいちいけてない気がしたので、論理名『ロックされているか』（物理名：is_locked）というカラムも想定しておきます。

テストケースへの落とし込み

  • 3回という数字が出てきているので、境界値分析を使います。

  • また、アカウントロックされているか否かで結果が変わるので、今回はデシジョンテーブルを用いることにします。

  • 状態遷移図に関しては、複数ステータスが出てきたら整理に使ったかもしれませんが、今回は使わないことにします。

  • 境界値分析はデシジョンテーブルの水準に内包できるので、とりあえずデシジョンテーブルを作ってみます。

条件をテーブルに整理

  • デシジョンテーブルを作るときは、因子に対して水準がMECE（漏れなく被りなく）であることと、それぞれの水準が必ず1パターンは使われていることを確認しています。縦が1ケースなので、横に見るイメージです。

  • ここには以下のようなユースケースも含まれます。

    • （今回は除外対象ではありますが）アカウントロックを解除したケース（No.4）

    • なんらかの理由でログインに失敗していなくてもアカウントをロックしたいケース（No.5）

  • 番号をグレーにしているのは、処理があまり変わらなそうなので削れる可能性のあるケースです。ただし、この手の判定はログイン判定処理として一つのクラスに詰め込まれる可能性が十分に考えられるため、その場合は全部を網羅するユニットテストを書く（書いてもらう）かもしれません。

  • 結構条件が細かかったので境界値というよりは実質全数みたいになってます。しかし境界値的に「3」という数字はチェックできたのでまあよし。（としたい）

テスト観点の決め方まとめ

好評だったので今回もまとめてみます。

  • 数字が出てきたので境界値分析を使うことにしました。

  • 「アカウントロックされているとパスワード認証が成功してもログインができない」や「ログインの失敗回数の状態変化」など、条件が複数あったので脳内整理も兼ねてデシジョンテーブルを使うことにしました。

  • 状態遷移図や表は状態が複数あったら使ったと思うのですが、デシジョンテーブルの数字で割とまかなえてる気がするのと、状態が２つしかないので必要ないかなと考えています。

総じて、状態遷移にしろ、デシジョンテーブルにしろ、条件ないし状態が複数出てきたら図を使って整理する、という思考回路のようです。

この記事が気に入ったらサポートをしてみませんか？