TOC
単語
| 計画する | けいかくする | 计划 | |
| フェーズ | phase | ||
| はさむ | 交叉，重叠 | ||
| 強化する | きょうかする | 加强 | |
| 実施する | じっしする | 实施，实行 | |
| 開発の質 | しつ | 开发的质量 | |
| ホワイトボックステスト | white box test | ||
| ブラックボックステスト | black box test | ||
| パブリック | public | ||
| インターフェース | interface | ||
| おっしゃいました（おっしゃる） | 说（的敬语） | ||
| 正常系 | せいじょうけい | 正常路径（的测试）方式，常规的 | |
| 異常系 | いじょうけい | 异常路径（的测试）方式，非常规的 | |
| 英数字 | えいすうじ | 英文字母和数字 | |
| 変な文字 | 奇怪的字母 | ||
| 英文字 | えいもじ | 英文字母 | |
| シングルクォーテーション | single quotation | ||
| エンティティクラス | entity class | ||
| ドメインクラス | domain class | ||
| コントローラー | controller | ||
| 想定する | そうてい | 设定，想象 | |
| 同時実行 | どうじじっこう | 同时执行 | |
| 相当 | そうとう | 很多 | |
| 一部の機能 | 一部分功能 | ||
| 本番 | ほんばん | 正式的 | |
| 出来上がった | できあがった | 完成以后的 | |
| 仮 | かり | 临时的，假定的 | |
| シミュレーション | simulation | ||
| 導入する | どうにゅう | 导入，引入 | |
| サポート | 支持 | ||
| 少なくとも | 至少 | ||
| 専業 | せんぎょう | 专业的，专门的 |
ポイント
-
皆さんと相談したいです。（上对下）／相談させていただきます。（下对上）
-
～想定しています。 → 我是这样认为的…
-
ケースをいくつか用意しなければなりません。 → 必须准备几个用例。
-
テストケースも計画しておいてください。 → 测试用例请预先计划好。
-
本番と仮
会話
会話の背景
- 詳細設計が終わると、テストを計画することができる。
- テストとは、単体テスト、機能テストと統合テスト、またパフォーマンステストなどがある。計画段階では、テストの範囲、リポートの項目、およびテストの期間と要員などが決まる。
登場人物
- 石田：プロジェクトマネージャー
鈴木：開発チームリーダー
山田、田中：開発チームメンバー
会話内容
-
石田：
- こんにちは。
- さて、詳細設計がそろそろ終わり、これからコーディングに入りますから、この2つのフェーズを挟んで、テスト計画をするため、皆さんと相談しましょう。
-
田中：
- 我々は、普段はコーディングが終わってからテストしますので、現時点で計画するのは、早いのではないでしょうか？
-
鈴木：
- そうですね。これまではそうでしたが、これから我々のチームはテストを強化したいので、コーディングする前に計画した方がいいと思います。
- ここでは、テスト計画としては、具体的に言うと、テストの種類、テストの内容と範囲、またテストリポートの項目などについて議論してください。この計画ができたら、コーディングしながらテストも早めに実施できるので、開発の質を高めることを期待しています。
-
石田：
- その通りです。
- テストとは、単体テスト、機能テストと統合テスト、またパフォーマンステストなどがあります。今日はそれぞれに関して計画してみましょう。
-
鈴木：
- それでは、まず最初はもちろん単体テストです。
- 単体テストはホワイトボックスのテストで、基本的には各プログラマーにやってもらいます。自分が開発したものを、クラス単位で、ちゃんと仕様通り動いているかを確認しなければなりません。
- 単体テストの内容は、原則としては、パブリックなインターフェースを全部テストする必要があります。
-
山田：
- テストの内容はパブリックなインターフェースとおっしゃいましたが、何か注意点があるでしょうか？
-
鈴木：
- そうですね。単体テストを計画する時に、正常系はもちろん考えないといけませんが、異常系のテストはもっと大事だと思います。
- 例えば、パスワードを英数字として定義しましたが、もし変な文字を入力したら、どうなるか？また英文字を入力するときには、定義以外の文字、例えば、シングルクォーテーションを入力したらどうなるか、いろいろテストケースにいれる必要があります。
-
山田：
- 単体テストには、今回もJunitを使いますか？
-
鈴木：
- そうです。今回もJunitを使います。その理由は、Junitを使うと、テストの自動化ができますから。最初書く時には時間がかかりますが、一旦書いたら、何回もテストできますから。
- また、単体テストでも、その中でエンティティクラスのテスト、画面クラスのテスト、ビジネスフロークラスの側面があります。ここまでの経験ではJunitはドメインクラスには一番適切ですが、ウェブ画面のテストはHttpUnitなどのツールを使った方がいいと思います。最後にコントロールのようなActionクラスにはStrutsTestCaseを使ってみてもらいます。
-
田中：
- 機能テストと統合テストはどうなるでしょうか？
-
石田：
- 機能テストと統合テストは基本的にはブラックボックスなので、ユースケースをベースにして、各関連画面を始め、ビジネスロジックおよびデータベースの結果を比べながら、テストを行うことを想定しています。
- そのため、テスト要因はいまからテストプランを書く必要があります。原則としては、単体テストと同じように、正常系と異常系のケースをいくつか用意しなければなりません。
- また、今回はウェブシステムなので、ウェブ上で同時実行が相当あると思います。そのため一部の機能に対して同時実行のテストケースも計画しておいてください。
-
鈴木：
- それと、今回のパフォーマンステストはどうでしょうか？
-
石田：
- パフォーマンステストはウェブシステムにとって大事です。
- 通常、開発する時には、プログラマーが自分のマシン上でウェブサーバーやデータベースも置いていますので、パフォーマンスの問題は気にしないと思います。しかし、実際のウェブサーバーに入れると、例えばISPに本番のマシンを置くと、状況が全然違うことが多いです。それこそ、ISPの本番のマシン上に置いたシステムに対してパフォーマンステストが必要だと思います。
- パフォーマンステストは特定のツールを使って、出来上がったシステムに対して、同時に何百何前回のアクセスをするようにシミュレーションします。最近のパフォーマンステストツールは、仮のサーバー上でもちろんテストできるし、導入した後の本番のサイトでも、テストすることができると思います。
-
鈴木：
- それは分かりました。
- ただし、前回の経験によると、ちゃんとテストするには、時間と要員がかかるので、プロジェクト管理の面では、サポートしていただきたいです。
-
石田：
- そうですね。今回は、単体テストのため、各プログラマーにはコーディング時間を通常の1.5倍に延長しようかと考えます。機能テストと統合テストは、コーディングをしながらやりますので、できれば、少なくとも一人の専業テスターを用意します。パフォーマンステストは大抵コーディングが終わる時点なので、その時点になると、プログラマーから一人が二人をまた追加して、やってもらいたいですけど。
-
鈴木：
- それならばいいと思います。
-
石田：
- それでは、今日のテスト計画に関するミーティングは終了します。
- 皆さん、お願いしますね。
-
皆：
- よろしくお願いします。
「真诚赞赏，手留余香」
WZhong
真诚赞赏，手留余香
使用微信扫描二维码完成支付
