『いちばんやさしいソフトウェアの本』

ソフトウェア開発に携わる全ての人必見の本です。しかし、あくまで、初心者向け。この業界に就職が決まった人がまず読むべき本だと思います。ソフトウェア開発の流れ・品質の重要性といったことをざっくり学ぶことができます。
薄いわり（２時間で読める）に内容は濃かったです。お薦めの一冊です。

セキュリティテスト

『知識ゼロから学ぶ　ソフトウェアテスト』   高橋寿一著

5. 攻撃に耐えうるソフトウェアの構築
        セキュリティテスト

2001年7月、Code Redというワームが世界中のMicrosoft llSサーバを攻撃し、30万台以上がダウンする大事件に発展しました。ソフトウェアのセキュリティ問題は、機能のバグと同じくらいユーザに迷惑をかけ、顧客の財産を侵害するものです。
しかし、残念ながら、現代の開発でセキュリティテスト手法が確立されているとは言いがたいです。
悪意のある攻撃が引き起こす問題を見つけることは、ソフトウェア開発の範疇外であったために、この分野のテスト手法はかなりの遅れを取ったのです。

攻撃手法　バファオーバーフロー
バッファオーバーフローは、現在最も多い攻撃手法といえます。
プログラミングで使われるリターンアドレスをハッカーに取られると、ハッカーは自由にアプリケーションやシステムをコントロールすることができます。
こうした自体を防ぐには、開発者は注意しながらプログラムを書く必要があります。
具体的には、使う関数を気をつけることです。strcpyやsprintfはまず使うべきではありません。

そうした情報はインターネット上に多く記載されているので、開発者が確実にセキュアなコーディングを実行するようにテスト担当者は見張らなければなりません。

攻撃手法　フォーマットバグ
これもバッファオーバーフロー同様スタック情報を取得して書き換えを許すバグです。
printfやsprintfなど書式付き文字列を扱う関数は正しく使わないと、スタック情報を書き換えられることがあります。
テスト開発者は、C言語でprintfを使うと非常に危険だということを認識するべきでしょう。
これらの情報もインターネット上に多く記載されているので、テスト担当者はチェックしておく必要があるでしょう。


セキュリティ機能テスト
プログラミング言語の選択がセキュリティテストに与える影響の大きさについて触れておきましょう。

まず、C/C++を選んだ場合、セキュリティテストチームは絶望的だと言えます。
毎週のようにセキュリティパッチをリリースする必要があります。実際にそんなプロジェクトをたくさん抱えている会社があります。Microsoftです。
優秀な人材が集まっている会社でもこの状況なのです。

Java言語を選ぶと、セキュリティに関するテストタスクは著しく減ります。
十分にCPUのパワーがあり、メモリが必要なだけ使える状態ならば、Javaをプログラミング言語として選ぶのは悪い選択ではありません。

そして、セキュリティ機能テストに関しては、以下の項目を徹底的にテストすることになります。
・コードレビュー
・入力テスト
・モジュール指向のテスト
・静的解析ツール


セキュリティシステムテスト
システムレベルのセキュリティを確保することがシステムセキュリティテストの目標になります。
ここでは、システムレベルで、期待されないデータやプログラムを侵入させないテストを紹介します。

セキュリティシステムテストでは実際の攻撃の種類に合わせてテストを行います。
主な攻撃方法としては次のようなものがあります。
・不正プログラム
・情報漏洩、なりすまし（パスワード）
・クロスサイトスクリプティング
・スパイウェア

具体的なテスト方法としては、上に挙げた攻撃を想定して、アプリケーションが、”解析”・”変更or削除”・”監視” を適切に行えるかをテストする必要があります。


最後に、セキュリティテストに携わる人材を確保することは非常に困難です。
一般にいわれているテスト担当者のスキルセット以外に、暗号化、セキュリティシステム、最低限のアセンブラの知識が必要になります。
セキュリティに興味あるテスト担当者は、目指すのも悪くないかもしれません。

システムテスト

『知識ゼロから学ぶ　ソフトウェアテスト』   高橋寿一著　　④システムテスト


4. ソフトウェアの性能をチェックする
~システムテスト~



システムテストおという手法は、どんな状況下であってもソフトウェアが期待された動作をするかをテストする手法です。

“ システムテストの手法というものは存在しないので、テスト担当者は非常に多くの創造性が求められる ” 　　Edward Kit

構成テスト
「Windowsにはバグが多い」という話をよく聞きます。理由を考えたことがあるでしょうか。
開発されたプログラムは、多くの場合それ単独では動きません。その周辺にある多くのリソースを使って動作することがほとんどです。
つまり、上の答えは、「Windowsにはテストすべきシステム環境が多すぎる」ことにあるのです。
DellやNECのパソコン。CPUも命令セットも違う。無限に存在するビデオカード。開発者は、この全ての環境に合ったソフトウェアを作ることになります。

その様々な条件でプログラムが十分動作するためのテストを「構成テスト」と言います。

構成テストは、以下のような構成でソフトウェアをテストする必要があります。
・異なるOS (Windows, Linux 等)
・異なるメーカのコンピュータ (Dell, HP, IBM 等)
・異なるビデオカード (異なるメーカ, 解像度, ビデオメモリの大小)
・異なるメーカのプリンタ (HP, EPSON, Cannon等)


負荷テスト
短い時間に多量のデータを入力し、出力させ、それに伴う処理を実行させるテストのことです。
負荷テストで注意すべき点は以下の２つです。
・想定される最大サイズのデータが、システム上で既定時間内に問題なく処理されるかどうかをテストする。この場合のシステムとは、ソフトウェア・ネットワーク・データベースシステム等・ソフトウェアおよびそれに付随するものすべてです。
・ユーザーもしくはそのソフトウェアに関する人々が行う、目的を達成するための操作が十分可能である。

負荷テストとして、長時間プログラムを走らせるといった負荷を与えるテストもあります。

最後に、「負荷テストに関してはかならず自動化すべきだ」という意見が多いです。
手動の場合だと、どんな原因によって問題が起きたかが分かりにくく再現性のないバグになることが多いからです。


パフォーマンステスト
パフォーマンステストとは、ソフトウェアを設計もしくは企画する段階で、設定されたソフトウェアの性能が期待された通り出ているかをチャックするためのテストです。

パフォーマンステストを行う際には、以下の流れが推奨されています。

1. アーキテクチャバリデーション（アーキテクチャ的に十分なパフォーマンスを発揮しているかをチェック）
2. パフォーマンスベンチマーク（開発されたソフトウェアのテスト）
3. パフォーマンス回帰テスト（回帰テスト）
4. パフォーマンスチューニング、アクセプタンステスト（最終製品が要求定義に定められたパフォーマンスを発揮しているかをチェック）
5. パフォーマンスモニタ（ERPアプリケーションでは、それに近いデータを用意して、パフォーマンスを発揮しているかをチェック）

ユーザビリティテスト
ユーザビリティテストとは、実際にプログラムを使いユーザもしくはそれに近い人に使用してもらい、ユーザインターフェースなどの使い勝手や仕様をチェックしてもらうテストです。

チェックポイントは以下の点です。
・アクセサリビリティ
・効率性
・学習性
・構造の明確さ
・操作性
・ユニバーサルデザインへの配慮

最後に、ユーザビリティテストは、テストチームがするべきでないテストだと著者は思っています。
確かに、テスト担当者がユーザの立場でテストをするのは無理があります。
いくらユーザの立場に立ったといえ、開発者やテスト担当者が一番そのソフトウェア製品を知っている事実に変わりありません。さらに開発に関わる人はコンピュータサイエンスを特別に勉強してきた人々です。

実際にターゲットユーザとなりうる人々を集めたり、第三者機関などを利用してテストすべきなのです。

ブラックボックステスト

『知識ゼロから学ぶ　ソフトウェアテスト』   高橋寿一著　　
　ブラックボックス




3. エンジニアが最もよく使う手法　ブラックテスト

ブラックボックステストは、プログラムを一種のブラックボックスと見立て、様々な入力を行うことによって、ソースコードを利用せずにテストを行う手法です。ほとんどのソフトウェアのテストがブラックボックステスト手法で行っています。それでは、ブラックボックステストの手法を紹介していきます。


同値分割法


予定の作成を例にとります。月を入力する際には、1~12までの整数を入れる必要があります。ここでは、1~12までの整数が有効同値、０以下の整数＆13以上の整数は無効同値になります。その値を実際に入れてソフトウェアが十分対応できるかを確認するテスト手法です。
ここで考えるべきことは、組み合わせです。予定作成で必要なのは月入力だけではありません。日を入力する必要もあります。日も当然のように、0以下の整数&32(または31など)以上の整数は無効同値です。
「月は有効同値にして、日は無効同値に・・・」といったように全てのテストケースを抜き出すと、非常に時間がかかることはお分かりでしょう。ソフトウェアのテスト現場では、ある程度この無効同値のテストを省略する必要が出てきます。もちろん省略されたテストケースでバグが出ることは許されません。
実践的なテストケースを考える必要が出てくるわけです。

境界値分析法
同値分割法と境界値分析法は常にセットで用いられる方法であることを覚えていてください。
これは、その名の通り、境界をテストすることになります。
上の予定作成の例を考えると、テストすべきとこは、無効同値の上限である0と有効同値の下限である１、有効同値の上限である12と無効同値の下限である13をテストします。

＊）現場の常識として、ゼロは常に境界値になります。入力値としてゼロが許されている場合は必ずゼロを入力する必要があります。


実践としてまとめます。
データを入力する機能がある場合、かならず『よいデータ』と『悪いデータ』を入力します。
<よいデータ>
・ユーザーがよく使いそうなデータ
・プログラムが許す最小のデータ
・プログラムが許す最大のデータ
・ゼロ（もしくは悪いデータとして）
・５cデータ
<悪いデータ>
・非常に小さなデータ
・非常に大きなデータ
・長いデータ
・無効なデータ


ディシジョンテーブル
ディシジョンテーブルテストも非常に古くから用いられている手法です。ディシジョンテーブルでは、全ての入力の組み合わせを表にし、その入力に対する動作もしくは出力を明記します。表にまとめることで全体のテスト構成を見ることができ、テストケースの抜けを発見しやすくなります。
ただし、多くの項目がある場合だと表を用いることが困難になるので、兼ね合いも考える必要がでてきます。


状態遷移テスト
状態遷移テストとは、「状態」をモデル化してテストを行う手法といえます。
状態遷移には、以下の図のように、大きく分けて状態（state）と遷移（transition）の２つによって表現されます。



ソフトウェアには、ある程度ユーザの操作に制限を加える必要があります。
そうしないと、大量のコードが必要になったり、思わぬとこでバグを生じたりと様々な不具合が発生するからです。
そのために、「状態(state)」という概念が生まれました。

一応の補足として、中には、状態の区別がはっきりしないソフトウェアもあります。
Linuxのコマンドラインインターフェースには、状態遷移テストを仕様する利点がほとんどありません。
なぜなら、いつでも全てのコマンドを受け入れる状態になっているため、状態が１つしかないからです。

さて、状態遷移テストで見るかるバグを紹介します。
・期待していない状態に遷移するバグ
これは、分岐やswitch文が正しく書かれていない場合に起こるバグです。
・遷移自体がない場合
ある状態からある状態に遷移できないバグを発見することができます。

状態遷移テストの問題点を挙げます。
状態遷移テストの場合はいくつか問題点が指摘されています。状態数が増えると、モデルが複雑化します。モデリングに時間がかかりすぎて実際にテストする時間が減ることさえあります。
本格的にソフトウェアテストが必要とされるアプリケーションでは、複雑でモデリングが難しいので、ツールを使うのは必須でしょう。

ランダムテスト
ランダムテストとは、いきあたりばったり、何も考えもなしに入力や操作を行う手法です。
問題点は、山のようにあります。
例えば、テスト手法にのっとったやり方で見つからないバグはありませんが、ランダムテストで見つからないバグは多岐にわたります。

とはいえ、このテスト手法は荒っぽいやり方ながら結構なバグが見つかってしまうところが問題です。全くテストをしていないソフトウェアの倍胃、全体の10％はランダムテストで見つかるとも言われています。

しかし、正当なテスト手法でないため、見つかったバグの何倍ものバグがプログラムの中に潜んでいることを認識すべきです。そして、そのバグは、ランダムテストでは見つからないことも認識すべきです。


＊）ランダムテストが有効な場合だってあります。
たくさんの数をランダムに入力するプログラムを作成して、自動化しておくと、威力を発揮することがあります。
例えば、日本語入力テストなどでは、ご存知のように漢字は数万語もあり、その境界値を見つけるのは、かなり面倒です。そんなときは自動化ツールを使ってランダムに日本語を生成し一昼夜走らせておくのも１つの手です。

ホワイトボックステスト

『知識ゼロから学ぶ　ソフトウェアテスト』   高橋寿一著　　
ホワイトボックス

2. ソフトウェアテストの基本　～ホワイトボックス～

ホワイトボックステスト手法を説明します。この手法はすべてのソフトウェアテストの基盤となるもので、盛んに研究された手法です。実務においてかならずしも有用でよく使われるテスト手法とは限りませんが、知っておく必要はあります。

一言で表すと、「プログラムの内部構造を徹底的に分析する」ということです。

何が問題なのか？
まだ、プログラムのファイルサイズが数キロバイトといった一昔前には、内部構造を徹底的に分析することができました。しかし、現代のソフトウェアは巨大で、ファイルサイズが数百メガのソフトウェアを扱うことが多々あります。そんなときに、ホワイトボックステストだのと言っている余裕はありません。

しかし、ホワイトボックステストを使用することで、ソフトウェアの品質が改善されることが証明されているのは確かです。大切なのは、テストをはじめる前にテスト手法を十分吟味・選択することでしょう。

では、具体的なテスト手法を紹介していきます。

制御パステスト法
制御パステスト法は、プログラムがどのような振る舞いをして、どうのように制御され実行されていくかをテストします。
主に、カバレッジ率(coverage rate) の値をとるために使われます。

if文などの分岐条件に対して、判定条件となる値をいれ、結果をチェックするテストです。
ステートメントカバレッジや、より厳密な判定条件でチェックするブランチカバレッジなどがあります。

さて、カバレッジテストで全てのバグを見つけることが理論的に不可能であることを先に述べておきます。
100%カバレッジを達成したからといって、ソフトウェアの品質がよいとはいえません。
なぜなら、カバレッジテストでは、以下に示すようなバグが見つけられないからです。
・プログラムのループに関するバグ
・仕様自体が間違っていたり、機能が備わっていないバグ
・データに関するバグ
・タイミングに関するバグ

まとめると、カバレッジテストはあくまで、数あるテストの一部です。他のテストの兼ね合いや予算等を考慮に入れて、製品によって品質の目標を妥当に設定することが必要です。

「バグ」とは何かを考える

『知識ゼロから学ぶ　ソフトウェアテスト』高橋寿一著　　
「バグ」とは何かを考える

1. テストをはじめる前に (「バグ」とは何かを考える)

まったくバグのないソフトウェアは存在するのでしょうか？
答えはNo。完全なテスト手法が存在しないからです。

先人の言葉より
“バグを全部見つけるのは無理だと心得よ” Cem Kaner
“エラーは見つからないだろうという仮定のもとにテストの計画を立ててはいけない” G.J.Mayers
“プログラム開発グループは、自分たちのプログラムをテストしてはいけない” G.J.Mayers

もちろん時代の背景とともにテストの意義・方法は変わってくるものなので、一概には言い切れませんが、開発者自身でのテストだけでは無理があるみたいです。
何となくバグというものは、プログラムの中に平均的に散らばっているものだと思いがちですが、ある例では、80%のバグが20%のコードに含まれているという報告があります。以下の理由が考えられます。
「プログラムは、単純な計算部分から複雑なアルゴリズムを伴った部分まで多種多様な要素から構成されている。」
つまり、そこを徹底的にテストをする必要があります。

まとめると、ソフトウェアで重要なのは、どの部分にバグが出やすいのか、そこにどのようなテスト手法を適用すれば十分な品質が得られるかを知ることです。

とても興味深い診断テストがあったので紹介します。

<問題> 「このプログラムでは、ユーザが3つの数字を入力します。この３つの値は、それぞれ三角形の３辺の長さを表すものとします。プログラムは、三角形が不等辺三角形・二等辺三角形・正三角形のうちのどれであるかを決めるメッセージを印字します。このプログラムをテストするのに十分と思われる一連のテストケースを書いてください。」

このプログラムを書くことは何の問題もないでしょう。
しかし十分なテストケースを書くとなると非常に難しいみたいです。

<答え> ・有効な不等辺三角形をテストする ・有効な正三角形をテストする ・有効な二等辺三角形をテストする ・有効な二等辺三角形で３種類の辺の組み合わせをテストする ・１つの辺の長さがゼロの値をテストする ・１つの辺の長さが負の値をテストする ・２辺の和がもう１辺と同じである (例：1, 2, 3) ・２辺の和がもう１辺より小さい (例：1, 2, 4) ・全ての辺の長さがゼロ ・入力の個数が間違っている ・それぞれのテストケースに対しその出力が正しいかをチェックする

ソフトウェアテストという作業はプログラミングに劣らず難しい作業であり、かつ創造的な仕事であることが分かるでしょう。
ソフトウェアのテストを不完全な形で実施させ、それを製品として出荷するということは、その製品を使う顧客にも迷惑がかかります。また、企業の良識を問われかねない自体を招く可能性もあります。