计划
第一章
纵览全局，理解测试在软件过程中的角色
Quality（质量）：
1. 适合使用。存在满足顾客和客户的特性，属性和行为，不存在不满足顾客和用户的特性，属性和行为。
2. 符合需求。存在满足所有提出的需求的功能，属性和行为，不存在不符合需求的功能，属性和行为。
Expectation of Quality（质量预期）：
顾客和用户持有的关于系统应该提供的质量级别的认识。在理想情况下顾客和用户对质量持有合理的预期。
当用户或顾客的预期是不切实际的，这往往表明了需求收集，业务分析或变更控制活动上的不完善。测试过程中，处理不合理的质量预期经常是不可能的，也是不值得的。
Experience of Quality（质量体验）：
关于系统质量的意见，当满意或不满意的总体程度组成，由用户和顾客在使用系统并获得经验时得出。当质量体验与质量预期相符时，用户或顾客往往会感到满意；如果体验超过预期，用户或顾客通常感到惊喜；如果体验低于预期，用户或顾客往往会产生不满。
System Lifecycle（系统生命周期）：
指系统开发，部署，使用和废弃过程中的全部活动，从最初的规格说明设计到实现，测试，到支持和维护，最后到系统过时和废弃的过程。
System Development Lifecycle（系统开发生命周期）：
系统生命周期中的一个子集，与系统的最初的开发过程相关，也即从规格说明设计到实现，测试和最初的部署。
一个测试过程中是如何获得投资的回报呢？
1. 发现已修复的bug-甚至预防；
2. 发现未修复的bug-但是已知的；
3. 运行测试，以降低（潜在高成本）风险；
4. 使用定期的，准确的，可信的信息来指导项目。
1.1 测试过程
测试过程的检查列表：
| 步骤序号 |
步骤内容 |
完成？ |
| 1. |
计划：理解测试工作 |
|
| 1.A |
理解测试的（系统，项目和过程）背景和组织背景 |
|
| 1.B |
定义系统质量的风险，列出优先级，并且让渉众认同测试起到降低风险的作用 |
|
| 1.C |
对执行步骤1.B中的测试所需要的时间，资源和预算进行评估，并且获得管理层的支持。 |
|
| 1.D |
开发一个计划，以确定降低系统质量风险所需要的任务，依赖性和参与者，并且取得渉众对该计划的支持。 |
|
| 2. |
准备：配置人员和测试 |
|
| 2.A |
通过人员的配备和培训，组建一个专业的测试组，该测试组具备了合适的技能，态度和动机 |
|
| 2.B |
设计，开发，采购和验证测试系统，测试组利用这个测试系统来评估待测系统的质量。 |
|
| 3. |
执行测试并收集结果 |
|
| 3.A |
获取并且安装测试版本，包括了待测系统的某些组件或者是所有组件 |
|
| 3.B |
分配，跟踪并且管理用于每个测试版本的测试用例 |
|
| 4. |
完善：指导系统不断适应和改进 |
|
| 4.A |
记录测试实施过程中发现的bug |
|
| 4.B |
与关键渉众交流测试结果 |
|
| 4.C |
根据变化进行调整，优化测试过程 |
|
单元测试：（unit testing）
指对系统的细粒度元素或者单元所进行的测试。
组件测试,子系统测试（component testing， subsystem testing）
主要针对系统组件或者子系统进行测试的阶段。
Alpha测试，Beta测试
在这个测试阶段，利用真实的工作流，数据和环境，提交给内部（alpha）或者是外部（beta）顾客，用户，以进行测试。
集成测试，产品测试（Integration testing，product testing）
在这个测试阶段，针对系统中的组件，子系统之间的关系和接口进行测试。
系统测试（system testing）
在这个测试阶段，把系统当作一个整体，对其整体和特定的行为，功能和响应进行测试。
验收测试，用户验收测试（acceptance testing，user acceptance testing）
在这个测试阶段，用户验证测试系统是否满足需求。
Pilot 测试
在这个测试阶段，系统在严密的监视下投入有限的批量生产。硬件Pilot 测试用于验证装配线大批量生产系统的能力。软件pilot测试验证系统为真实顾客或者硬件处理一般操作的能力。
1.2 了解运营和组织环境
场景过程的检查列表：
| 步骤序号 |
步骤内容 |
完成？ |
| 1. |
了解组织中系统开发，维护或者采购的整个过程，包括任何计划好的或者正在进行的主动过程改进。 |
|
| 2. |
研究测试内容，测试相关文档，质量相关文档，数据和度量的方法，诸如测试计划，bug报告数据库，字段错误数据，测试系统，等等。了解系统是谁创建的，他们为什么这么做，他们为什么按这种方式做，以及在组织中正在进行哪些工作，这产生哪些决定和力量来影响输出结果。 |
|
| 3. |
和其他的参与者讨论他们正在进行的那些测试活动，以及在你参与进来之后他们会继续做哪些事情。 |
|
| 4. |
确定在测试过程中你的同级涉众。和他们进行讨论，了解目前他们和测试人员的关系，他们对测试创造价值的方式抱有哪些期望，过去对测试流程或者参与测试的人有哪些不满或者冲突，等等。 |
|
| 5. |
和你的经理及其他高级经理讨论，界定测试组要创造哪些价值，特别是测试在质量保证中充当的独特角色。 |
|
越是细心谨慎，我们就越能做得更好。
1.3 在系统开发生命周期中的测试
测试人员有三个重要的事项需要考虑：
l 首先在项目环境中，我们应该灵活的使我们的测试与选择的生命周期和方法学相适应。无论如何，我们必须决定如何适应，并提供有价值的服务和信息。我们还应该在我们的计划中建立灵活性，这样的话如果所选择的方法学陷于“边写边改”的混乱状态，我们可以再混乱状态中继续交付的有价值的服务和信息。（首先要给团队灌输这种意识）
l 要选择测试流程，首先要理解顺序和依赖性。
l 流程问题和测试时系统开发过程的一个重要方面。顺序问题能帮助他们理解关键的测试过程。
1.4 组织测试人员和测试工作
独立测试组（independent test team）：指一个小组，有别于负责构建待测试的系统的小组，其职责是通过测试来有效用和有效率地评估和报告待测试系统的质量。
行为测试，黑盒测试（behavioral test，black-box test）：基于系统行为的外部可观察结果的测试，通常在需求和概要设计规格说明中指明了测试的依据。
结构化测试，白盒测试（structural test，white-box test）：基于系统应该如何运行的内部细节的测试。通常是在详细设计，逻辑和数据中指明了测试的方法。
测试阶段，测试级别（test phase，test level）：一些特定测试活动的集合，用于处理特定的质量风险，诸如组件测试，集成测试，系统测试和验收测试。