システム開発

September 15, 2020

テスト
品質
機能要件

WEBシステムの品質を保つために最低限やるべきソフトウェアテストとは

software test 1

システムの品質を担保するためには、どの観点でどこまでテストすればよいのか!?

過度にカバレッジを追い求めても、コストに見合った成果が得られないし、セキュリティやパフォーマンスのような非機能要件は終わりがない。コレだけやれば大丈夫!と言える明確な目安はないが、私は開発者として品質を保つため、次の観点に気を配ってきた。

1. コードレビューやコーディング規約を順守し、可読性の向上に努める.

2. xUnitでステートメントカバレッジやバリデーション周りの単体試験を実施.

3. 第一に境界値テストでバグを解消し、必要に応じてディシジョンテーブルや状態遷移を確認.

4. 一般的な脆弱性対策を行っているか(=フレームワークのルールに則った作りであるか)

5. ユーザビリティテストでは、ニールセンの10原則の観点から使いやすさを追求.


ソフトウェアテストの領域は、工程・品質の観点・実行方法・技法など幅広いが、試験に割り当てられる工数は少ないことが多い。限られた工数の中で品質を保つには、開発者視点で最低限やるべき観点を絞ったので、機能要件が中心になっていることは反省すべきかもしれない。

静的テスト *主にコードレビュー

新人時代にリーダブルコードを読み、大変感銘を受けたことを覚えている。


私が携わった開発案件の多くは、コーディング規約と呼べるものがなかったので、本書を定期的に読み返し、その内容に基づいてレビュー指摘をしていた。

最近はJavaScriptのESLintなど、品質を担保するツールが多くあるので適宜利用していくことになる。

ソフトウェアテスト基本テクニック ー 静的テスト
クックパッド ー コーディング規約
PHPコーディング規約まとめ

ホワイトボックステスト

プログラムの論理構造が正しいかを解析するテストで、ホワイトボックスの代表的な手法の 制御パステスト法カバレッジ率 を計測するために使われている。

私はカバレッジ率を正確に算出した経験がないが、言語毎のxUnitでそれなりに単体試験を実施していた。多分肌感覚で60%くらいは網羅できるよう意識していたと思う。

まず単体試験を書くポイントだが、APIであればステータスコードとレスポンスタイプの確認、条件分岐はステートメントカバレッジ、あとはバリデーション周りを重点的に確認することが挙げられる。

本当はブランチカバレッジが望ましいだろうけど、工数が膨大になるし、ステートメントカバレッジだけでも、単体レベルのバグはある程度消せるので、これは最低限やるべきことだと思う。

またカバレッジ率の参考値は、一般的には 60〜90% と言われ、Googleでは ±85% としている。人の生命が関わる場合は限りなく100%であるべきだが、エンタメ系なら多少低くても大丈夫かも。

CakePHP3.6のコントローラでのPHPUnitの使い方メモ
テストカバレッジ100%を追求しても品質は高くならない理由と推奨されるカバレッジの目標値
テストコードの方針を考える(何をテストすべきか?どんなテストを書くべきか?)

ブラックボックステスト

ソースコードを見ずに様々な入力を行う手法で、最もポピュラーな手法だと思われる。

正直私はやりたくない(もしくは新人にアウトソーシングしたい)が、ホワイトボックスではソフトウェアの仕様誤りや、実装の抜け漏れを防げないため、絶対にやらなければならない。

まずブラックボックステストの代表例には、同値分割法境界値分析法 の2つが挙げられ、第一に境界値分析法で境界値付近のバグを解消 すれば良いと思う。同値分割法はあまり見たことがない。

if (a >= 1) {
  // 印刷処理
} else {
  // エラー処理
}

上のサンプルプログラムの場合、境界値分析法の正しいテストケースは次のとおりになる。

テストケース1:aに1を入力 > 結果:正常な処理がなされること

テストケース2:aに0を入力 > 結果:エラー処理がなされること


仕様に誤りがないか、機能の実装漏れが無いかをチェックする必要があるので、確認観点を洗い出し、一つ一つ丁寧に検証していくことになる。システム開発で一番泥臭い作業だ。

最低限のセキュリティチェック

非機能要件の代表であるセキュリティテスト。

まずIPAの普及啓蒙資料に掲載されている内容を理解し、ブラウザ上で特殊文字を入力したり、意図しないSQLが実行されないかを確認する。完全に専門外なので、これくらいしかやってない。

正しくフレームワークを使っていれば、サニタイジングやバインド機構を使うはずなので、問題があればコードレビュー時に発見できるかもしれない。

IPA ー 脆弱性対策脆弱性対策

ユーザビリティテスト

最近はUI/UXの言葉をよく耳にするが、ソフトウェアとして使いやすいかにも厳しい目が向けられる。

専門家ではないので明確な指針はないけど、ニールセンの10原則 は理解し、テスターとして次の★印の観点だけは、重点的にチェックするよう心掛けている。

1. システム状態の視認性を高める

2. 実環境に合ったシステムを構築する

3. ユーザーにコントロールの主導権と自由度を与える

4. 一貫性を保持し、標準に従う

5. エラーの発生を事前に防止する

6. 記憶しなくても、見ればわかるようなデザインを行う

7. 柔軟性と効率性を持たせる

8. 最小限で美しいデザインを施す

9. ユーザーによるエラー認識、診断、回復をサポートする

10. ヘルプとマニュアルを用意する


人間は慣れの動物なので、多少使いづらくても違和感を感じなくなるそうだ。

なるべく初見の人に上の観点でチェックしてもらうのが良いかもしれない。

ソフトウェアテスト基本テクニック ー ユーザビリティテスト

ソフトウェアテストを考える上で参考になる本

日常業務でテストのことを深く考える時間は少なかったかもしれないが、こちらの書籍ではブラックボックス、ホワイトボックスなど基本的なことから、非機能要件や自動化など、幅広く説明されていた


システム開発に携わって日が浅い場合、まずはブラックボックス観点の境界値テストで、境界値に関わるバグを解消し、ディシジョンテーブルや状態遷移テストの実施を推奨している。

相変わらず単体テストを書いていない現場は多く、ブラックボックス中心だとは思うが、xUnitでの単体試験を義務付ける現場も増えており、開発者はホワイトボックスの知見が必須になると思われる。


©Copyright2020 TaNA LABO. All Rights Reserved.