读书笔记(十二)核心测试过程：计划，准备和完善
第12章
必要的移交：管理测试版本
12.1一个测试版本的过程
测试版本的过程：
| 步骤序号 |
步骤内容 |
完成？ |
| 1. |
为一个特定的测试版本选择内容（错误修正，新的功能和文档） |
|
| 2. |
实现错误修正和新功能需要的修改，当完成了这些修改并通过了单元测试之后，将这些修改存储到源代码存储器。 |
|
| 3. |
从存储器取回源文件；编译，链接并汇编这些构建；（在构建和存储器中）用一个版本号来标记这些构建。 |
|
| 4. |
对于构建进行smoke测试。如果测试通过就进入下一步；如果测试失败，找出什么地方出现了错误，修正问题，然后回到前一步。 |
|
| 5. |
给构建制作一份可以安装的媒体图像，好好地包装它，并将它提交给在测试环境中安装这个软件的负责人。 |
|
| 6. |
在测试环境中安装这个软件。 |
|
| 7. |
在测试环境中对这次构建进行smoke测试。如果测试通过，就开始测试的周期；如果测试失败，卸载这个构建，退回到以前的测试周期，并将构建返回到开发组，从第一步重新开始。 |
|
A Test Release Process
| Step # |
Step |
Done? |
| 1. |
Select the content (bug fixes, new features, and documentation) for a particular test release. |
¨ |
| 2. |
Implement the changes required for the bug fixes and new features, checking those changes into the source repository as they are completed and unit tested. |
¨ |
| 3. |
Fetch the source files from the repository; compile, link, and otherwise assemble the build; and, mark (in the build and in the repository) the build with a version number. |
¨ |
| 4. |
Smoke test the build. If the tests pass, continue with the next step; if the tests fail, figure out what went wrong, fix the problem, and return to the previous step. |
¨ |
| 5. |
Create an installable media image of the build; package it appropriately; and, deliver it to the person responsible for installing it in the test lab. |
¨ |
| 6. |
Install the build in the test lab. |
¨ |
| 7. |
Smoke test the build in the lab environment. If the tests pass, begin the test cycle; if the tests fail, uninstall the build, resume the old test cycle, and return the build to the development team to start over at the first step. |
¨ |
构建，版本，测试版本（build，release，test release）
一个可以安装的软件，硬件或系统的组件---或者甚至是整个系统---提交给测试组进行测试。
12.2将大构建提交给实验室
12.3 认识好的测试版本过程
12.3.1 提供可安装的，改进的和稳定的测试发行
一个好的测试版本过程将会提交一份可以安装，比上次更好的构建。在构建中的改进生产的这种总体趋势的部分原因是程序员的认真开发和对错误的修正。
12．3.2制作可预测的，及时的和规则的测试版本
12.3.3 使用定义的，顾客一样的安装和卸载过程
构建ID，版本名称，修正版，修正号，版本，版本号（Build ID, Release Name, Revision, Revision name, version, version number）
一些数字或字母的序列，唯一地确定一个发行版本。
12.3.4 给测试版本一个它知道的名称
12.3.5 从认真选择的，协调的和有文档记录的内容构建
项目组在什么修改将会实现和什么修改将不会实现的问题上达成意向性协议。开发组将会然后实现尽可能多提议的修改，并提交一份测试版本。另外，测试组应该收到发行注解。这些发行注解告诉测试人员开发组实现了哪些提议的修改。
12.4 处理挑战
12.4.1 谁拥有测试版本的过程？
12.4.2 待测系统的复杂性
版本工程师，构建经理，发行经理，源代码控制工程师（release engineer， build manager，source code control engineer， release manager）
负责从源代码，数据，元数据，帮助文件，web屏幕和其他构建系统需要的资源生成测试版本的人员。
12.4.3 不完整的和不现实的系统验收测试版本
在后期的测试中，测试不完整的或不现实的测试版本具有不可避免的危险性。它为没有探测到的回归创建了机会，给微妙的错误提供了隐藏的地方。
12.5 实现改进
1. 考虑每次测试版本的安装媒体，坚实的自动化单元和组件测试，以及回归测试和smoke测试的潜在测试效率方面的好处。
2. 考虑配备修正版的名称和询问能力可能产生的项目效率方面的好处。
3．查看测试执行和错误报告过程中低效率的来源。