第十章
阿基米德的浴缸：设计和实现测试系统
测试环境（test environment）
执行测试工作必须具有的硬件，软件，基础设施，材料和场地。
测试用件（testware）
测试用例，测试数据，测试脚本，测试工具，测试日志，测试报告和相关的用户指南或者文档。
测试执行过程（test execution process ）
在测试环境中测试人员或其他关键的测试参与者使用测试工具的方法。
10．1 一个测试系统的设计与实现过程
测试条件（test condition）
通过执行一个测试用例，特别是评估系统的质量方面感兴趣的案例后创建的系统的状态，输出，结果或者周边环境。
测试用例（test case）
由要再待测试的系统上执行的操作组成的步骤的序列（这些步骤有时候被称为测试过程或测试脚本）。这些操作经常与一些数据集相关（预先载入或在测试中输入）。执行的操作和向正在测试的系统提供的数据的组合构成了测试的条件。这个条件趋向于生成在测试中能够用来与期待值比较的结果，也即在给定的测试条件下评估的质量。操作的执行可以用串联的方法或用并联的方法，或者用一些其他连续的组合。
测试套件（test suit）
逻辑上相关的测试用例的集合，可能会在多个套件中重复使用相同的测试用例。
测试系统设计和实现的过程：
| 步骤序号 | 步骤内容 | 完成？ |
| 1. | 生成或更新一套测试套件的提纲，用来覆盖被指定为建议进行测试操作的系统质量风险 |
|
| 2. | 选择合适的测试套件，并在最重要的还没有覆盖的风险区域发现一套新的有趣的测试条件，例如，可以引起特定的失败集合或模拟真实使用情况的条件。在高层上定义如何评估这些测试条件下得到的结果的正确性。 |
|
| 3. | 根据将要探索的测试条件，希望的期待结果的验证，可用的时间和预算，要测试的系统的可测试性功能，测试环境和测试组中具有的技能，来选择合适的测试技术。 |
|
| 4. | 设计，开发，获取，增强，配置和用文档记录用于生成这些条件的测试用件，测试环境和测试执行过程，并用选择的测试技术验证这些行为。用经验性的技术来增强理论性的测试技术，特别是顾客/用户数据，现场失败报告（以前的竞争对手的版本，相同产品和相似的对于质量风险的风险集），销售和市场预测的将来使用情况以及其他骨科中心的输入。 |
|
| 5. | 如果由于资源，进度或其他限制，任何的测试用件，测试环境或测试执行过程元素在第四步无法获得，迭代地重复步骤四一解决任何这样的限制。 |
|
| 6. | 对测试系统进行测试，使用静态的技术（例如检查）和动态的技术（例如运行测试）。 |
|
| 7. | 检查存放在产品库或配置管理系统中的测试用件，测试执行过程的描述，测试坏境的配置信息，测试系统的测试文档和任何其他方式生成的文档或文件，将测试系统的版本与待测试系统的版本链接起来。将这些东西置于变更控制之下。 |
|
| 8. | 根据在开发这套最新的测试的过程中学到的知识更新质量风险列表，评估新的测试系统对于质量风险的覆盖率。找出剩余的没有覆盖的，但又建议采取测试操作的质量风险。 |
|
| 9. | 重复步骤2-步骤8，直到所有的建议采取测试操作的质量风险范围都得到覆盖。确保在项目存储器内部的质量风险文档得到更新。如果进度或预算的限制妨碍了开发，没有将所有重要的质量风险覆盖，编写没有覆盖的质量风险报告并上交给管理层。 |
|
| 10. | 如果时间和资源允许，使用结构分析重复步骤2-步骤8以找出需要进一步测试的地方。 |
|
A Test System Design and Implementation Process
| Step # | Step | Done? |
| 1. | Create or update an outline of test suites that can cover the risks to system quality for which testing has been identified as a recommended action. | ¨ |
| 2. | Select an appropriate test suite and discover a new set of interesting test conditions within the most critical still-uncovered risk area; e.g., conditions that might provoke a particular set of failures or model actual usage. Define at a high level how to assess correctness of results under those test conditions. | ¨ |
| 3. | Select the appropriate test techniques, given the test conditions to be explored, the verification of expected results desired, the time and budget available, the testability features of the system under test, the test environment, and the skills present in the test team. | ¨ |
| 4. | Design, develop, acquire, enhance, configure, and document the testware, the test environment, and the test execution process to produce those conditions and verify those behaviors using the selected test techniques. Augment theoretical test techniques with empirical techniques, especially customer/user data, field failure reports (previous and competitors’ releases, similar products, and similar set of risks to system quality), sales and marketing predictions on future usage, and other customer-centered inputs. | ¨ |
| 5. | Should any testware, test environment, or test execution process elements prove unattainable during step 4 due to resource, schedule, or other limitations, repeat step 4 iteratively to accommodate any such limitations | ¨ |
| 6. | Test the test system, using static techniques (e.g., reviews) and dynamic techniques (e.g., running the test). | ¨ |
| 7. | Check the testware, test execution process description, test environment configuration information, test system test documentation (from step six), and any other documentation or files produced into the project library or configuration management system. Link the version of the test system to the version of the system under test. Place the item(s) under change control. | ¨ |
| 8. | Update the quality risks list based on what was learned developing this latest set of tests. Evaluate coverage of the quality risks with the new test system. Identify remaining uncovered quality risks for which testing action is recommended. | ¨ |
| 9. | Repeat steps 2 through 8 until all quality risks are covered to the extent testing action was recommended. Ensure that the quality risk documentation in the project repository is updated. If schedule or budget restrictions curtail development without all critical quality risks covered, produce a report of uncovered quality risks and escalate that report to management. | ¨ |
| 10. | If time and resources allow, iterate steps 2 through 8 using structural analysis (e.g., McCabe complexity, code coverage, etc.) to identify areas needing further testing. | ¨ |
10．2 Emma 在工作中寻求强度测试的途径
桩（stub）
一个软件，通常比较小，填入或替代正在测试的系统中的一个组件或测试系统，提供被替代组件的一些功能的模仿，并达到一定的程度，能够执行一些想要进行的测试。
10．3 三种至关重要的考虑
10．3．1 测试先知（test oracle）
测试先知（test oracle）
在具体的条件下用来预测或评估要测试的系统的行为的正确性的系统，方法或技术。This method- a function that determines if the application has behaved correctly in response to a test action.
参照系统（reference system）
一种特定类型的测试方法，已经存在的一个系统是待测试系统中一些或所有的预期行为的模拟或模型.
10．3．2 适当的文档
以下的影响，考虑和因素趋向于正面地关联到货创造了增加文档级别的机会。
l 回归测试和可重复性的需要；
l 审核的需要；
l 目前或将来使用自动化；
l 测试过程和文档的规范化及标准化的需要；
l 系统的风险级别。安全性至关重要的系统和承担重要任务的系统，这些系统在使用过程中的每一个时刻，必须按照一种精确的方法行事。
l 测试执行的紧迫时间窗口；
l 测试执行过程，测试用例和在测试中的系统的复杂性；
l 获取知识的需要；
l 指导缺少经验的测试人员和共享知识的需要；
l 测试系统成为产品的程度。如果测试系统是给一些其他组织的一种可提交物，或是如果不管是为了什么原因，在进行了测试之后它将会或可能是可提交的，那么文档能够帮助转移关于测试如何进行的知识和任何工具，数据，脚本和以后的工作。好的文档也增强了完成测试和进行测试的测试组的专业形象。
以下的影响，考虑和因素趋向于正面地关联到货创造了降低文档级别的机会。
l 能够用于设计和实现测试用例的时间和资源。预算的紧张和进度的紧迫可能会迫使编写更少的文档。
l 测试人员的技能水平。
l 动机方面的考虑。随着时间的推移，测试人员可能会发现，一遍又一遍地重复运行相同的精确文档化的测试用例集是冗长，乏味和不够刺激的，如果其他因素，特别是与安全至关重要的测试中要求有精确的文档，在混合性的任务中平衡制定的时间以及在探索性的测试中的创造性时间可能会有所帮助。
以下的影响，考虑和因素趋以各种复杂的方式影响文档的合适的级别。
l 效率，重用和维护方面的考虑。
l 测试和项目涉众的期待和需求。
l 信念，理性和其他。
l 缺乏知识的混乱。
10．3．3 组合性爆炸
10.4 转移管理层
8万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
