Chapter 4: Planning to Test
2011/03/17(木) 18:49 ［Javascript］｜→親記事へ｜
まずテストの概念の前にいくつかの問題への理解が必要になる
- テストを行うためにテストプランが必要か?
- テストプランを開発するのはいつ?
- いつくのテストが必要?
■A very brief introduction to the software lifecycle
ソフトウェア開発のライフサイクルを知ることは大事です。1. Analysis
2. Design
3. Implementation
4. Testing
5. Deployment
6. Maintenance
通常、テストは実装の後にきている。
The agile method
コードが安定したときに十分なテストを実行するThe agile method and the software cycle in action
この本もアジャイルとライフサイクルに基づいてるよ■Do you need a test plan to be able to test?
多くの場合、テストを実行するためのテストプランが必要となるでしょう。ミスをなくすために、何をテストするのか、いつテストするのか、どのようにテストするのかをより強固なプランがあるといい。
When to develop the test plan
ライフサイクルでは実装の後にテストがきていますが、実際には実装プロセスの前にテストプランを考えることを勧めます。テストプランは大きく分けてシステムテストとユーザー受け入れテストに分けることができます。
システムテストは機能-非機能要件テスト全部をカバーします。ユーザー受け入れテストは実際にエンドユーザーに使わせる前に行うテスト。
■How much testing is required?
どれをテストすればいいのかまよってしまうこともあるので、ポイントを決めるWhat is the code intended to do?
まずはそのコードが何を目的に作られたのかを理解する必要がある。Testing whether the code satisfies our needs
コードがその目的を満たしているかをテストする。入力に対して出力が正しいかをテスト。
ホワイトボックステストではコードが受け付けられる最小と最大値における境界値をテストする。
Testing for invalid actions by users
ユーザーは常に正しい値を入力してくれるとは限らないので、間違った入力値に対して間違いという出力が返されることをテストする。Testing for invalid actions by users
ここまでを簡単にまとめると、何を目的としたコードなのかを知ることとユーザーの間違った行動を検知することがテストプランで定義すべきことである。次は主要なテストの概念と戦略。
■Major testing concepts and strategies
それぞれのテストの趣旨- Functional requirement testing
- Non-functional requirement testing
- Acceptance testing
Functional requirement testing
機能要件のテストとはコードをテストすることを意味します。たとえば、ユーザーの入力値の正当性をチェック、その入力値に基づく動作のチェック、入力値に対する出力のチェックのような感じ。
この章では以下のような範囲をカバー
- Web page tests
- Boundary testing(境界値テスト)
- Equivalence partitioning(同値分割)
Non-functional requirement testing
非機能要件テストとは機能やソフトウェアの特定の挙動に関係しないものをテストすること。ソフトウェアの動作を判定するために使われる基準を指定することともいえる。
たとえば、機能要件は値を保存することに対して、非機能要件はそのデータベース亜リアルタイムで更新されていることとなる。
この章では以下のような非機能要件についてカバー
- Performance testing
- Usability testing
- Integration testing(総合テスト)
Fast loading of pages
Search engine optimized web pages
Documentation of the software that you have created
Efficiency of the system
Reliability of the software
Interoperability of the software code that you have produced. For instance, you can
code JavaScript across major browsers
Acceptance testing
受け入れテストは通常テストプロセスの最終段階となる。実際に使ってみてテストする。
アジャイルではこのようなテストケースは stories と呼ばれたりします。
■Black box testing
ブラックボックスはボックスアプローチに基づいていて、プログラムの内部構造を知らない状態でテストする。出力が正しいのかどうかを判断するためにvalid ,invalidな入力を使用します。ブラックボックステストにはユーザビリティテスト、境界テスト、ベータテストが含まれています。
valid and invalid inputs
ユーザー視点でそのプログラムが使いやすいかをテストする。- パフォーマンス
- Recall : 一定期間たった後に使う時に使い方が覚えていられるか
- Accuracy : エンドユーザーの間違いに対する結果のデザインは正しいか
- フィードバック : 特にAjaxアプリケーションの場合、通信が成功したのかのフィードバックがあるかどうかなど
Boundary testing
境界テストでは最小と最大のテスト行い、たまにエラーな値や標準値も含まれていることがあります。Equivalence partitioning
データ範囲を分割してその代表例でテストすること。(結構経験則混じる場所
ソフトウェアテスト入門（ブラックボックステスト） — ディノオープンラボラトリ
Beta testing
メジャーリリースの前にαやβ版をリリースして試してもらう。jQueryやDjangoやUbuntuなど最近ではよく使われてる感じ
■White box testing
ホワイトボックステストは透過テストとして知られてる。ブラックボックステストとは違い内部構造を知っているので、テストプランを作る時にこれを利用します。
データ構造にアクセスする権限を持っているのが特徴で、 Branch testingやPareto testingを含む。
Branch testing
ブランチテストは少なくても一回は各ブランチのコードについてテストを行うというコンセプトです。これはすべての関数やコードはテストされるべきということを意味する。ソフトウェアテストにはコードカバレッジというプログラムのソースコードがどれだけテストされたという指標があります。ブランチテストカバレッジは以下のような重要な種類を含んでいます。
- Functional coverage :コードの各関数が何回呼ばれたか
- Decision coverage : それぞれのif elseステートメントがテストされているか
Pareto testing
パレートテストは現実世界のテストとも呼ばれる。厳格な時間とお金の基に行われる。
■Unit tests
ユニットテストはテストのためにコードを論理的な塊に分けてテストします。通常は関数うあメソッドごとにのテストする。これは各ユニットがほかのすべてから独立していないといけないことを示しています。
ユニットテストの利点はユニットごとに行えるためエラーの最小化や変更が容易にできることがあげられます。またユニットテストは柔軟であることやドキュメントが容易にできることもメインとなる利点です。新しい機能をテストするときに何が問題であるかを簡単にメモできるため、テスト結果をドキュメント化するのが簡単です。
またユニットテストはボトムアップアプローチを主軸にintegrated testing(統合テスト)の重要な一部となっています。
新しいコードが書き始められた時の継続的インテグレーションの一部としてユニットテストはよく見られる。継続的インテグレーションとは結合エラーを防ぐために、開発者が頻繁にコードの結合を行うプロセスのことです。これはしばしば自動化されてインテグレーションテストが行われます。新しいコードを書いて、すでに書かれたコードと結合したときに互換性やバグなどが発生市内かを見るためにこのプロセスは重要です。
継続的インテグレーションは結合ユニットテスト、リビジョン管理、ビルドシステムからなることが多いです。
Web page tests
Webページテストでは各ブラウザで問題なく表示されているかやSQL,HTMLインジェクションやリンクや画像のチェックなどに焦点を当てます。Performance tests
パフォーマンステストといっても幅が広いですが、ここでは二つに焦点を当てる。- JavaScriptファイルをダウンロードしてからの実行までの時間(minifyなどをする
- 各コードの実行スピード
■Integration testing
統合テストは受け入れテストする前の最後のテストになります。各ユニットが正しく動いていて、それらをビルドしたものも同様かどうかを確認します。
統合テストではtop-down , bottom-up の異なったアプローチをとることができます。
ボトムアップはユニットテストと似たような方針。
■Testing order
個人的にはボトムアップテストが望ましいと考える。ユニットテストから初めて、統合テストで終える。
大きな理由は蓄積からくるエラーを防ぐことができるのと、柔軟性があり、テスト結果のドキュメント化がしやすいことがあげられる。
現実的にはボトムアップテストとトップダウンテストとの間（少なくとも概念的には）区別することは困難で、両方のテストを同時に必要とする場合もあり得る。
■Documenting your test plan
テストプランの文章化The test plan
サンプルに入ってる sample_test_plan.doc を見てくりゃれVersioning
テストプランもバージョン管理するTest strategy
テスト戦略について。sample_test_plan.doc見ながら内容についての解説
コメント（0件）
- TB-URL http://efcl.info/adiary/0106/tb/