ソフトウェアテストの基礎

こんにちは、AIR Design for Apps事業部 Android チームの堀口です

今回のブログは基礎から学ぶソフトウェアテストを読んだまとめを書いていこうと思います。

経緯

弊社ではアプリの開発後、QA チームによるテストが行われます。

エンジニアとしてはできるだけ不具合を出さないようにしたいので、テストの段階でどれだけ不具合を減らすことができるのか？と考え、ソフトウェアテストについて基礎から学ぼうと思い立ちました。

まとめ

全章を読みましたが、ソフトウェアテストビギナーにとって全てを理解するのは難解でした。

その点については本書「第6章ソフトウェアテスト運用の基本-テスト成功の方程式-」の冒頭にも書かれており、「読者がビギナーレベルのテスト担当者であれば、本書の1章と2章を理解すれば十分です。(引用)」とあるので本ブログでは 1章、 2章についてまとめました。

本書のブログ

juichi.blog.ss-blog.jp

第1章はじめに

1.1 ~ 1.3 章

「どんなソフトウェアにもバグはある(引用)」という話でした。

具体例として、南米フランス領で打ち上げられた ESA のロケット (Arianne 5) が墜落した話、NASA の火星探査機が墜落した話など挙がっていました。

1.4 章

「バグを全て見つけるのは無理。しかし、ソフトウェアのどの部分にバグが出やすいのかを理解し、適切なテスト手法を適用すれば十分な品質を得ることが可能」という話でした。

根拠として、実際に行われた調査報告の中に、ソフトウェアに含まれる 47%のバグがプログラムの4%の部分に偏在しているというデータがあることが述べられていました。参考文献はこちら

1.5 章

「全くバグのないソフトウェアを作ることはできないが、十分な品質を持ったソフトウェア製品を開発するためのテスト手法を紹介する」という話でした。

インプットされた2つの整数(1以上999以下)を掛け算するプログラムですら100万通りのテストケースがあり、仮にこれらを網羅したとしても、コンパイラや CPU のバグなどまで考慮してテストを行って初めて完全無欠なソフトウェアになるという話しがありました。

2つの整数の積を計算するだけの小さいプログラムが完璧に動作するかを確認するだけでこれだけの手間がかかるのであれば、Android アプリをテストし切るのは現実的に無理。。。

2章ホワイトボックステストと具体的なテスト手法について

2.1 ~ 2.8章

ホワイトボックステスト

e-words.jp

本書の説明と大まかに合致していて、論理構造の正しさをテストするもの。ただし、ソフトウェアの仕様が間違っていることで発生するバグは発見できないという特徴を持ったテストのことです。

制御パステスト法

e-words.jp

本書の説明とも大まかに合致しています。(IT 用語辞典にはステートメントカバレッジの記載がないため)

制御パステスト法には以下の 2種類があり、

ステートメントカバレッジ
ブランチカバレッジ

例えば以下のコードで

    if (num == 0) {
        commonNum++ // ①
    } 
    if (num1 > 1) {
        commonNum *= 2 // ②
    }

①と②を一行ずつ実行して確認するのはステートメントカバレッジ。処理の流れをフローチャートに描き起こして、分岐までカバーするのがブランチカバレッジです。

ステートメントカバレッジのメリットは記載なし、デメリットはバグを見逃すこと。

ブランチカバレッジのメリットはバグの見逃しがステートメントカバレッジより少ないこと、デメリットはテストケースの数が多いこと。

結論としては、テストが大変だからという理由でブランチカバレッジを実行しないことは避けたほうが良いです。特に、バグが頻発しているコードに対して実行すると品質向上に有効そうです。

カバレッジ基準

ソースコード全体を 100% とした時、そのうち何%がカバレッジテストをクリアしたか？という基準です。

一般的なソフトウェアであれば 60 ~ 90 % 程度で十分と言えるようです。

というのは、エラー処理、コメントアウトされたコードなどはテストしようがないからですね。

また、カバレッジで検出できないバグとして下記があります。

ループ処理
仕様の間違い
データに関するバグ
タイミングに関するバグ(マルチタスク、割り込みなど) (引用)

エンジニアが主に関わる必要があるのは 1 , 3 。2 については仕様通り動くかをテストするべきで、4 については優れた研究はあるが実務で使うのは困難なようです。

2.9 章ホワイトボックステスト(TDD)

アジャイル開発が流行っていることから、ブラックボックステストに代わってホワイトボックステストが復活したという話です。

TDD のテストを書く

実践的なことはここに書いてありました、TDD の基本は

小さい動作しないテストを書く
テストを通るコードを書く
重複したコードを削除する(リファクタ)

(引用)

です。TDD の参考文献をネットを検索すると以下のような本が出てきますが、この本で書いてある基本をベースに読めばスッと入りそうな気がしています。読んだらまたブログ書きます。

www.amazon.co.jp

以上です。

弊社ではいっしょに働く Android エンジニア、iOS エンジニアを募集しています！
ご興味のある方はぜひご応募いただけますと嬉しいです。

Androidエンジニアの方はこちらから： www.wantedly.com
iOSエンジニアの方はこちらから： www.wantedly.com

腕に覚えのある方はリードエンジニアの求人もありますので是非ご検討ください。Android、iOSの両方の開発ができるエンジニアも大歓迎です！ www.wantedly.com

Galapagos Tech Blog

株式会社ガラパゴスのメンバーによる技術ブログです。

ソフトウェアテストの基礎

経緯