13.8 测试计划
测试不是在所有的开发工作完成之后才进行，而是与开发几乎同步进行的。一个软件项目的各个功能都可以有自己的测试计划，它们可以在不同的阶段发挥作用。但是针对整个项目的总测试计划（又叫测试总纲）要在计划阶段大致定下来，并指导所有测试工作的进行。
那测试总纲到底讲什么呢？
测试计划描述了一次测试活动的主要方面：为什么（Why），测试什么（What），谁来测试（Who）和什么时候测试（When），详细地说，包括以下方面：
（1）测试的总体策略和方法。
（2）测试日程安排：何时开始什么样的测试。
（3）质量目标：测试要达到什么样的目标才能算通过——这个目标也决定了“验收测试”的标准。
（4）资源：需要多少人力、物力来达到质量目标。
（5）测试变量矩阵：我们的系统需要支持多少种操作系统、浏览器，以及其他影响功能的变量？
关于这一点，阿亨有一天晚上和大牛在顶球酒吧畅谈理想，讲到激动处，夜不能寐，勾画了这样的测试矩阵（见表13-4）。
阿亨把这个计划拿给大家讨论，大家在惊叹之余，纷纷怀疑我们是否有能力完成这么多种类型的测试。毕竟是184 320种组合！这时候，阿超建议大家看看团队的远景和各种情况所占实际用户的比率，来决定我们真正需要支持的测试矩阵是什么。
经过分析和讨论，大家逐条精简，结果如下：
a. 用户类型不变。
b. 屏幕分辨率降到两种，手机屏幕不要了，我们暂时不在手机上测试。
c. 屏幕DPI不测试高级DPI（屏幕 | 属性 | 高级 | DPI 中可以设置DPI以提高显示效果）。
d. 操作系统只测试3种，二柱强烈支持Linux，同时考虑到一些高收入的网民可能会用Linux操作系统，保留Linux。
e. 操作系统的语言只支持3种，这并不是网站内容的语言，而是操作系统的默认语言。
f. 网络速度3种，无线网络的速度介于拨号与ADSL之间，可以忽略。
g. 浏览器的版本，经过激烈的讨论，浏览器从5种变为3种。
总计648种组合，如表13-5所示。
表13-4 宏伟的测试矩阵
用户 类型 | 屏幕 分辨率 | 屏幕DPI | 操作系统 | 操作系统 默认语言 | 网络速度 | 浏览器 | Flash | JavaScript | Cookie | 组合 总数 | |
变量 数目 | 4 | 4 | 2 | 6 | 6 | 4 | 5 | 2 | 2 | 2 | 184320 |
商户 | 800像素×600像素 | 正常 | WindowME | 中文（简体） | 拨号 | IE6 | 支持 | 支持 | 支持 | ||
用户 | 1024像素×768像素 | 高级DPI | WinXP | 中文（繁体） | ADSL | IE7[1] | 不支持 | 不支持 | 不支持 | ||
浏览者 | 1280像素×1024像素 | WinVista | 英语 | 局域网 | Opera | ||||||
管理员 | 手机屏幕 | Win Server 2003 | 日语 | 无线网络 | Safari | ||||||
Linux/Unix | 阿拉伯语 | Firefox | |||||||||
Mac | 西班牙语 |
表13-5 精简后的测试矩阵
用户 类型 | 屏幕 分辨率 | 操作系统 | 操作系统 默认语言 | 网络速度 | 浏览器 | 组合 总数 | |
变量数目 | 4 | 2 | 3 | 3 | 3 | 3 | 648 |
商户 | 800像素×600像素 | WinXP | 中文（简体） | 拨号 | IE6 | ||
用户 | 1024像素×768像素 | WinVista | 中文（繁体） | ADSL | IE7 | ||
浏览者 | Linux/Unix | 英语 | 局域网 | Firefox | |||
管理员 |
有了这样的测试矩阵，测试人员在设计与执行测试的时候就能够按照矩阵进行全面的测试。同时要指出的是，不同组合的重要性是不一样的，我们最主要的测试环境还是：用户 + 1204像素×768像素 + WinXP + 中文 + ADSL + IE6。必须先保证网站在主要的测试环境下能正常运行。
[1] 这个表还没有考虑IE8/9。
[来自 移山之道 第 15 章]
15.2 测试的文档
九条：测试工作是不是有很多文档要写？
阿亨：各类人员都有文档要写，但是在敏捷模式中，我们要坚决避免为了写文档而写文档。要写真正有用的、重要的文档，如下所示：
在计划阶段，我们就要制定测试计划（Test Plan），特别是测试总纲。然后还要写测试设计规格说明书（TDS）、测试用例（Test Case）、程序错误报告（Bug Report）和测试报告（Test Report）。它们之间的关系如图15-1所示。
图15-1 测试工作中的文档
测试计划和测试总纲主要说明产品是什么，要做什么样的测试，时间安排如何，谁负责什么方面，各种资源在哪里，等等。这些在第14章已经讲过。
我们不是为了写文档而写文档，写文档的目的是要解决问题。到底这些文档会解决什么问题呢？
15.3 测试设计说明书（TDS）
正如开发人员有功能设计说明书，测试人员也要有设计测试说明书。这就是告诉测试人员要如何设计测试。
阿毛：我们在哪里可以找到模板？有了模板就好办了。
阿亨：我们不要一味地依赖于模板，不要被模板淹没了。
对于一个功能，或者相关联的一组功能，TDS主要要描述这些重要的内容：
（1）功能是什么。
（2）要测试哪些方面？有没有预期的Bug比较多的地方（对于测试矩阵有没有要修改的地方）？
（3）如何去测试（什么具体方法，如何做测试自动化，准备什么样的测试数据等）？
（4）功能如何与系统集成，如何测试这一方面？
（5）什么才叫测试好了（Exit Criteria）？
阿毛：有些功能还没有写好，我怎么能知道这些功能的具体情况?
阿亨：TDS应该在功能实现之前，就要根据功能的spec写好，并通过同事的复审[1]。
15.4 测试用例（Test Case）
有了TDS，我们就可以按照TDS 的描述，对每一个功能点进行具体的测试了。具体地说，测试用例描述了如何设置测试前的环境，如何操作，预期的结果是什么。一个功能的所有测试用例合称为这个功能的测试用例集（TEST Suite）。
九条：对于一个功能，用户可能的输入千差万别，我是不是得写成千上万个测试用例？
阿亨：没必要，我们可以把纷繁的情况归类到几个类型中。例如，用户登录时的情况，我们可以将其归为以下几类：
（1）正确输入（用户输入了合法并正确的用户名和密码），预期结果是用户能够正常登录。
a. 用户名又有多种情况（数字、字母、中文）。
b. 用户登录“记得我的账户和密码（remember me）”功能可以正常使用。
c. 用户的密码是否隐式显示，转送。
（2）错误输入，预期结果是系统能给出相应的提示。
a. 用户名不存在；
b. 用户名含有不符合规定的字符（控制字符、脚本语句等）；
c. 用户名存在，但密码错误（具体测试时、可以输入空、超长字符串、大小写错误等）。
15.5 错误报告（Bug Report）
在测试中，如果发现问题，我们就得报告，在移山过程模型中，“Bug”是第二个工作项类型。在这一阶段，我们就主要用Bug进行交流。
在以前的“二人合作”一章中，有些团队成员已经互相找过Bug，但是当时项目相对简单，对Bug的格式并未做严格要求。在一定规模的软件项目中，我们要求一个好的错误报告要能做到：
（1）Bug的标题，要简明地说明问题。
（2）Bug 的内容要写在Description中，包括
a. 测试的环境和准备工作；
b. 测试的步骤，清楚地列出每一步做了什么；
c. 实际发生的结果；
d. （根据spec和用户的期望）应该发生的结果。
（3）如果需要其他补充材料，例如相关联的Bug、输出文件、日志文件、调用堆栈的列表、截屏等，都要保存在Bug 相应的附件或链接中。
（4）还可以设置Bug 的严重程度（Severity）、功能区域等，这些都可在不同的字段中记录。
下面是九条创建的一个Bug：
标题：挂了
内容：我今天在玩移山购物网的时候，发现移山网站挂了。
这个Bug的问题在于对问题的描述不明确，让开发人员无从下手。小飞拿到这个Bug，也是哭笑不得，试了试移山的各个页面，好像也都正常。他于是把这个Bug又推给九条，“哪里挂了？”
过了一会儿，九条回复“在我的机器上是挂了”。
小飞跑到九条的座位上，想看看“犯罪现场”。
九条：我刚把机器重启动……
两人等到启动完毕，打开网页，发现一切正常。
九条：（纳闷了）昨天晚上的确是挂了。网页上还有一些错误信息。我当时正在干什么来着，好像是在留言或在论坛上发帖子，我现在也记不清了。让我再玩玩，等碰到了再叫你。
阿亨：这样九条浪费了两个人各一个小时的时间。最后什么进展也没有。一个好的Bug应该是这样的：
