備忘録 〜ソフトウェアテスト〜

こんばんは、うさです。 本日は、「ソフトウェアテスト」について備忘録として 一冊の書籍から重要なことを書いていく。 今回参考にさせて頂いた書籍はこちら!!

第1章はじめに

第1章ではソフトウェアテストをするうえでの心得が書かれており、 ソフトウェアの「バグを全部見つけるのは無理だと心得ろ」と『Cem kaner』という方は言っている。 それは今完全なテスト手法がないからである。 では、テストエンジニアは何を心得てテストを行っていくべきなのか!! それは 「どの部分にバグが出やすいか、 そこにどのようなテスト手法を用いれば 十分な品質が得られるか」 を考えてやっていくことである。 なぜなら、バグの47%はプログラムの4%の部分に偏在しているという例もあるくらいに バグは一カ所に固まっているからである。

第2章ソフトウェアの基本

第2章ではホワイトボックステストについて書かれている。 業務では殆ど使う事はなくなったそうですが、 知っておくべきではある。 ホワイトボックステストとは 一言で言うと、 「プログラムの論理構造がを解析するテスト」である。 では、どんなことをするのかというと、 制御パステスト法を用いる。 これはカバレッジ率の値を取る為に用います。 カバレッジ率とは、ステートメントカバレッジ・ブランチカバレッジ・コンディションカバレッジの3つをどれだけ網羅出来たかを表す値である。
    • ステートメントカバレッジ:コード内の命令文を少なくとも一回実行する事 例を挙げると con1 = 0 とcon2 = 2 でそれぞれ一回命令文を実行します。 これがステートメントカバレッジである。
 
    • ブランチカバレッジ:ステートメントカバレッジでは対処できなかったもう一方の分岐も行う事
 
  • コンディションカバレッジ:書籍には説明が出てきませんでしたが、 コード内の条件式について「true/false」それぞれ一回ずつ出力させる事
ここまでだいぶ用語の説明になってしまいましたが、 ホワイトボックステストを用いてどうすればよいのか。 上記のカバレッジ率を上げる為にコード内の条件を一つ一つ確認していきます。 しかし、量は膨大であるため、カバレッジ率には基準が存在し、 一般商用ソフトウェアでは60〜90%あればよい。 しかし、そこの数値はソフトウェアの利用目的に大きく関わってくるため一概には言えないよう。 そして、意識しなければならないのは、
  • カバレッジテストはテストを行うのに時間がかかる
  • ソフトウェアの仕様が間違っていてもバグは発見できない
といったことです。 時間がかかると書きましたが、 テスト用フレームワークを用いて単体テストのコード書いてテストすることで飛躍的に時間は短縮されカバレッジ率も上がる。

第3章エンジニアが最も使う手法

ということで、続いてはブラックボックステストについて。 ソフトウェアテストの約8割がブラックボックステストを行う会社もあるので重要なテストである。 ソフトウェアとはデータを『入力・出力・計算・保存』という仕事で成り立っている。 まずは、その中の「入力・出力」についてのテストを見ていく
  • 同値分割法:入力領域を同値クラスという部分集合に分割し、その部分集合に入る入力値を等価とみなす作業
  • 境界値分析法;同値分割で得た同値クラスの境目の値のバグを見つける作業 境界値分析法でのバグは4つに分けられる
    1. 「>」と「>=」の間違い
    2. 数字の書き間違い
    3. 境界がない(elseの書き忘れ等)
    4. 余分な境界
    これらのバグを発見するにはOn-Offポイント法を用いる これは異なる処理が行われる最も近い二点を選択してテストすること
  • ディシジョンテーブルテスト:表に、状態・状態の組み合わせ・アクションを書き、 この表の通りに「状態」をテストし、期待通りの「アクション」を起こすかを確認する作業
  • 状態遷移テスト:ある状態からイベント処理(入力が多い)を行い期待通りの遷移が行われるを確認する作業 このテストで、
      1. 期待通りでない状態に遷移
      2. 遷移自体を行わない
    という二つが検出される。
では、これらのテスト手法をどのように使っていくのか!! 例として、 もし、ダイアログボックスが一つだけあれば境界値テスト 複数のダイアログボックスがあればディシジョンテーブルテスト ダイアログボックスの遷移があれば状態遷移テストを行う これらを行いまだバグが見つかるようなら以下の理由が考えられる
  • ブラックボックステストのアプローチの仕方が間違っている
  • ホワイトボックステストでしか見つからないバグが存在した

第4章探索的テスト

探索的テストとは、ソフトウェア機能を学習しながらテスト設計とテスト実行を同時に行う事 どういんことか。 テストケースを書いて実際にテストを行ってバグが見つかるのは50%以下。 ならば、テストケースを書くのではなくてソフトウェアをテストしながら考えて実行してしまうということ。 どのように探索的テストを行っていくのか!!
  1. ターゲットソフトウェアを決める
  2. 機能をリストアップ
  3. バグが見つかりそうなエリアを見つける
  4. 各機能のテスト及びバグの記録
  5. 継続的にテストの実行
といった具合に行ってバグを見つけていく。 探索的テストの網羅率はプログラムの構造を理解していることによって、 テストケースベースののテストコード網羅率を上回る。 つまり、プログラミングエンジニアはこのテストを行う方がよいということである。

第5章非機能要求のテスト

今まで書いてきたテストは全て機能要求に対するテストのアプローチであり、 この章では非機能要求のテストを説明する。 非機能要求では品質特性の向上を図る。 まずは、期待通りの性能を引き出す為に、 パフォーマンステストについて行う。 パフォーマンステストとはソフトウェア設計・企画時の段階で設定された性能が期待通り出ているかをチェックするもので、 平均的なWebアプリケーションでは72%しか出ないといった結果となっている。 設計時のパフォーマンスの定義の例として、 要求:20Mバイトのデータを10秒で処理したい 結果:21Mバイトになったとたん30秒かかる(バグ)    1Mバイトに10秒かかる(バグ) といった具合に定量的に明確化して定義する。 パフォーマンステストは次の手順で行う。
  1. アーキテクチャバリデーション:机上でのチェック
  2. パフォーマンスベンチマーク:パフォーマンステストが出来る状態のソフトウェアが出来た時点でテストを行う
  3. パフォーマンス回帰テスト:プログラム開発途上で変更時に行う
  4. パフォーマンスチューニング、アクセプタンステスト:最終製品が要求定義に定められたパフォーマンスを出しているかのチェック
  5. 24×7パフォーマンスモニター:ERPアプリの際、顧客の使用するデータに近いダミーデータでのテスト

第6章ソフトウェアテスト運用の基本

テストを行う際重要になってくるのが、どれだけの時間を割くのかということである。 そして、テストに割く時間は開発のスピードによって左右されるという事。 そうなった場合の選択肢は以下の3通り
  • ソフトウェアの品質を下げる
  • 出荷を遅らせる
  • 機能を削る
もちろん、このような事態にならないように開発での期限は守らなければならないが、 対応策は考えなくてはならない。

第7章ソフトウェアテスト品質管理の基本

品質は目に見えないものである。 しかし、何らかの形に数値として表さなくてはならない。 それは「バグの数」である。 バグの数を数値化してグラフに表すと スクリーンショット 2015-02-12 2.21.01 こういった形でバグの数は徐々に減っていく。 また、重要度の高いバグもどんどん減っていく。 しかし、GUIアプリケーションではオンラインヘルプの文章や文字が欠けているといったUIの問題が継続的に出てくる場合もある。 もちろん、バグの数が減っていくとバグ修正にかかる時間も減っていく事になる。 もし、後の方でバグが見つかると致命的な場合がある。 例えば、設計上からくるバグは一個のバグ修正の為に何カ所もコードを変えなければならなくなる。 最後に、この書籍から学んだ事は、 バグは完全になくなりはしないという事。 重要の高いバグは徹底的に修正をして、 後は市場に出した後に少しずつ修正していく。 テストの種類は色々あり最初はどれを使えばいいのかわからなかったり、 どの程度までテストを行えばいいのかわからないと思われる。 ある程度コードを書いたら探索的テストやブラックボックステストを行うといった方法を使っていけばよいのかなと感じた。 テストの自動化もあるそうだが、それはテストに慣れてきてからだろう。 一番大切な事は、いかに完璧に近い設計書を書けるかだと感じた。 プログラミングでも同じ事が言えるが、 ソフトウェア完成間近で設計ミスによる変更等は時間(コスト)の大幅なロスである。 のちのち設計の仕方についても勉強をしていきたい。 以上、ソフトウェアテストについての備忘録??でした。

Usami Go

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です