ソフトウェアのテスト
コンセプト：ソフトウェアの機能を確認するには、ユーザーのニーズを満たしています。
ソフトウェアのテストは、（ソフトウェアのエラー処理がないことを証明することで基本的な活動は、バグを見つけることです）、
ソフトウェア・テストは、正しく実行するには、そのプログラムを証明することです。
一連の操作の機能、私はそれが最終的に私が望むものと一致しているインタフェースに提示ご覧ください。
テストと違いの試運転：
目的不同：
测试的任务是发现程序中的缺陷；
调试的任务是定位并且解决程序中的问题。
参与角色不同：
测试主要是由测试人员和开发人员来执行，黑盒测试主要由测试人员完成、单元/集成测试主要是由开发人员执行；
调试由开发人员完成。
执行的阶段不同：
测试贯穿整个软件开发生命周期；
调试一般在开发阶段。
ソフトウェアテストの目的と原則
目的：問題の有無にかかわらずソフトウェアを検証すること。
原則：顧客の焦点は、規範、手順、基準、ソフトウェアテストの要件に従ってください。
1. 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。
2. 成功的测试是发现了至今为止尚未发现的错误的测试。
3. 测试并不仅仅是为了找出错误。通过分析错误产生的原因、阶段及错误发生的趋势。
一、帮助项目管理者了 解当前软件开发过程中的缺陷，以便及时纠错、改进。
二、帮助测试人员设计出有针对性的测试方法，改善 测试的效率和有效性。
三、让开发人员知道错误产生的重灾区，加强自测试，
四、让客户清楚我们专业的质 量保证团队，可以向他们提交一份满意的答卷。
4. 没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。
5. 根据测试目的的不同，还有回归测试、压力测试、性能测试、安全测试等，
分别为了检验修改或优化过程是否引发新的问题、软件所能达到处理能力和是否达到预期的处理能力等。
6. 软件测试为了建立软件的信心。
7. 从测试的目的出发，大概可以分为两类：
为了验证程序能正常工作的测试；
为了验证程序不能正常运行的测试。
要件は何ですか。
IEEE定义：
软件需求是
(1)用户解决问题或达到目标所需条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面(1)或(2)所述条件或权能的文档说明。
它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，
比如性能要求，质量标准，或者设计限制。
（满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，
包含用户需求和软件需求————满足用户的合理期望）
用户需求：可以简单理解为甲方提出的需求，
如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。
该需求一般比较简略。
软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。
软件需求是测试人员进行测试工作的基本依据。
（把用户需求转化为可以指导开发人员写代码，指导测试人员写测试用例的文档）
テストケース（テストケース）はどのようなものです：
テスト：
テスト中のシステムに提供される実施形態にテストグループセット、含むグループセット：テスト環境の要素、工程、試験データ、期待される結果等。
あなたのレコードをテストするための一連の処理。
良いテストケースは、ビジネスに精通していない人でもすぐにテストケースに従って行うことができます。
コードの品質を比較するための評価基準：テスト基準の評価
用例表达清楚，无二义性。
用例可操作性强。
用例的输入与输出明确。一条用例只有一个预期结果。
用例的可维护性好。
用例对需求的覆盖率高，
暴露程序Bug的能力强力。
基本的な要素では、以下の実施形態の例では見つけることができます：
| テストケースは、ESCP-439を：ユーザ登録が成功するユニット | |
|---|---|
| アクション手順： | 望ましい結果： |
| 登録ページを入力し、登録することを選択します | システムは、登録ページを表示します |
| 要件を満たすためにユニットの名前を入力し、単位のメール、パスワード、「ユーザー登録契約書」、パスワード、組織コード、検証コード、および確認契約書を確認し、登録情報を提出します | アクティベーションメールを送信、登録するためのオペレーティングシステム。登録が成功した後、登録ページに成功したジャンプで、操作をアクティブにするためにユーザに要求します。 |
| 登録に使用Eメール、起動操作を入力します。 | アクティベーションに成功 |
| 書留とパスワードによる操作でログインします | ログインに成功すると、システムは、ウェルカムページを表示します |
| テストモード | 手で |
| 重要性 | 重要 |
| テスト環境 | CHROME、IE10 + |
| テストの前提 | 通常、オペレーティングシステムは、メールサーバーがオンになっています |
| ファンクションモジュール | ユーザ登録ログイン |
テストケースのメリット：
测试执行者的依据
使得工作可重复，自动化测试的基础
评估需求覆盖率
用例的复用
积累测试的方法思路以供后续借鉴
- 苦痛を使用し
たテストケースのデザインは、多くの場合、それが実行にかかる時間よりも、それは時間をテストするために設計された、時間のかかる仕事です - 次のような問題を解決するために：
私はすべての機能テストのより包括的なテストカバレッジはテストの新バージョンの繰り返しテストを測定することはできませんかどうかわからないことは冗長な多数を実現することは困難である影響を与える
テスト効率を
あなたは、テスト中に以下の問題が発生する場合があります。
不知道是否较全面的测试了所有功能
测试的覆盖率无法衡量
对新版本的重复测试很难实施
存在大量冗余测试影响测试效率
测试用例的产生就是为了解决上述的问题。
