现代软件工程讲义 8 稳定阶段 (测试的计划和执行)

[来自 移山之道 第 13 章]
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应该是这样的：

标题：购物网站的某个具体页面（URL），在回复中如果提交大于100KB的文字的时候出错。
内容有以下几点：
环境：在Windows XP下，使用IE7。允许Cookie。购物网的版本是1.2.40。
重现步骤：
（1）用[用户名，密码] 登录。这一用户在系统中是一般用户。
（2）到某一产品页面（链接为：……）。
（3）选中一个帖子，例如：帖子号为579。
（4）回复帖子，在内容中粘贴100KB的文字内容（文本内容见附件）。
结果：
网站出错，错误信息为：[略]
预期结果：
网站能完成操作，或者提示用户文本内容过大。
[在附件中加入100KB的文本文件]。
测试人员还可以附上其他分析，应该鼓励测试人员追根溯源。
如果看到这样的报告，那么开发人员就能够很快地重现这一问题，从而有效地分析和解决问题。

15.6 测试修复，关闭缺陷报告

当开发人员修复了一个缺陷并签入代码后，一个新的构建就会包含这一个修复（Bug fix）。测试人员所要做的就是验证修复，并且搜寻有无类似的缺陷，验证修复有没有导致其他的问题（回归，regression），了解修复的影响（是对一个简单的显示文字的修改，还是内部算法的改变），并且检查系统的一致性是否受影响（例如：修改了默认的/是/否/取消/选择次序，要检查整个产品中其他的对话框是否遵循同一模式）。
在完成了测试之后，测试人员可以关闭缺陷报告，同时在“历史（History）”这一栏内说明是如何做的验证。
当测试人员验证了一个Bug被正确修复了之后，还要考虑是否把这一个Bug变成一个测试用例，这样可以保证以后的测试活动会包括这个Bug描述的情况。这是一个很重要的步骤。

15.7 测试报告（Test Report）

在一个阶段的测试结束后，我们要报告各个功能测试的结果，这就是测试报告。移山公司不喜欢过多的文档，我们就不必写洋洋万言的报告了，只需简单地列出一些数字即可，如：
对于某一功能，我们要收集下列数据：
（1）多少测试用例通过？
（2）多少测试用例失败？
（3）多少测试用例未完成？
（4）多少在测试用例之外的Bug被发现？
所有功能的测试报告相加，我们就能得到整个项目的统计信息。这样的信息能帮助我们从宏观上了解还有多少事情没办完，各个功能相对的质量如何。

15.8 运用测试工具

前面说了这么多理论和规定，我们看看实际工作如何进行。VSTS既然是一套软件工具，它一定有一些帮助测试人员的工具。Visual Studio 2005/8 的众多套件中，有一款是：Visual Studio Team Edition for Software Tester。我们在这里也简单地介绍基本工具的使用。
15.8.1 运用工具记录手工测试
不管多少人，多少文章描述了“测试自动化”及其前景，这些自动化的东西最初还是得有人“手动”地进行。下面的步骤演示了如何创建手工测试。
（1）在VSTS（有Team Edition For Tester 套件）中，新建一个项目，在Visual C# 或其他类型中，选中Test。填入适当的项目名字和解决方案的名字，可以把它加入源码控制中。我们会看到新的项目新建了不少文件（如图15-2所示）。其中有UnitTest1.cs，我们之前已经谈过。另一个文件是ManualTest1.mht。



图15-2 创建新的测试项目
（2）打开ManualTest1.mht，你会看到它是模板（又一个模板），在这个文件中，你可以填入下面的内容：
a. 测试的标题（Test Title）——简明的标题。
b. 测试的详情（Test Details）——测什么。
c. 测试的对象（Test Target）——测试什么功能。
d. 测试的步骤（Test Steps）——提供详细的测试步骤和每一步期望的结果。
e. 修改的记录（Revision History）——对这一测试进行修改的历史记录。
九条：不就是这样一个简单的文件么，我自己不用写也可以记住。
阿亨：好记性不如烂笔头，当测试矩阵有上百个可能的设置，产品又日趋复杂的时候，我们需要把一些手工测试记下来。另外，如果来了个新手接班，项目移交，怎么办？
15.8.2 运用工具记录自动测试
对于网络程序，我们可以把对网页的访问和操作像录音一样录下，“录音”主要是记录HTTP请求的URL，以及header和body中的各个参数。记录是否成功取决于服务器返回的状态码。当然，我们也可以自己定义pass/fail的条件。这样以后测试的时候重新放录音带即可。
操作：鼠标右键选中测试项目，选择 Add | Web Test（如图15-3所示）。



图15-3 新增加一个 Web Test
Internet Explorer 就会打开，同时Web Test Recorder 也会激活[2]，

测试人员就可以按照场景测试网站的各项功能了，同时注意到Web Test Recorder 会记录每一个网页的地址，以及可能的参数。
测试人员可以进一步增加测试的内容（如图15-4所示）。



图15-4 进一步增加Web Test 的功能
其中值得提出来的是，测试人员可以选中“Generate Code”，生成测试脚本，可以在脚本一级开发测试。测试人员可以用脚本建立循环测试，或者根据某一步测试的结果选择不同的测试分支（path），更加灵活。另外，我们还可以用C#作为测试代码的语言，这个比其他通用工具的脚本强大许多，这也是用VSTS做测试的好处之一。
不同的测试可以把不同的次序结合起来运行，测试人员可以用“Ordered Test”来管理这样的测试集合。可以用和创建Web Test 类似的方法创建 Ordered Test。
15.8.3 如何测试效能
除了功能方面的测试外，我们还要测试那些“服务质量”。如效能测试、负载测试、压力测试。我们在第7章中讲到了这三种测试的区别。在Stone 项目中，以产品搜索为例，这三种测试的区别如下：
效能测试[3]：在100个用户的情况下，产品搜索必须在3秒钟内返回结果。

负载测试：在2 000个用户的情况下，产品搜索必须在5秒钟内返回结果。

压力测试：在高峰压力（4 000个用户）持续48小时的情况下，产品搜索的返回时间必须保持稳定。系统不至于崩溃。


我们可以举一个现实生活中旅客列车的例子：
效能测试：在80%上座率的情况下，期望：列车按时到达，并且乘客享受到优质服务。乘务员不要太累。
负载测试：在100%上座率的情况下，期望：列车大部分按时到达，乘客享受到基本服务。乘务员的疲劳在可恢复范围内。
压力测试：在高峰压力是200%上座率，全国铁路系统增加20%列车，持续15天的情况下，期望：列车能到站，乘客能活着下车，系统不至于崩溃。乘务员也能活着下车。

效能、负载、压力这些方面的测试会产生很多数据，这些数据最好保存在数据库中，以便于跟踪分析。这些数据为以后做网站容量规划（Capacity Planning，又称容量规划，能力规划）提供重要的依据。
在VSTS中，效能和压力测试都可以用“Load Test”来实现，Load Test 牵涉到许多因素，因此我们需要按部就班地设置，如图15-5所示。
负载测试的一个核心概念是“场景”，这和软件设计的场景有所区别，它主要包含负载测试的各种参数：
（1）停顿时间（Think Time）：在每次请求之间和一批测试之间的停顿。



图15-5 创建负载测试向导
（2）负载模型（Load Pattern）：模拟的用户量是恒定在一个数值的（如：总是30 个用户），或者是分级进行的（如：开始是5个用户，每分钟增加10个用户，直到最高50个用户）。
（3）测试混合模型（Test Mix）：此次负载测试要运行多少种测试，每种测试所占的比例是多少。
（4）浏览器混合模型（Browser Mix）：各种浏览器的选择及比例。
（5）网络混合模型（Network Mix）：各种带宽的网络及比例。
设置场景后，下一步要决定我们收集什么样的效能数据（Performance Counter），这时候，我们可以收集代理机器（Agent，模拟的服务请求从这里发出）和控制机器（Controller）的效能数据，更重要的是收集网络服务器的效能数据（如图15-6所示）[4]。


















图15-6 收集效能数据
这些效能数据会反映在负载测试中。
最后一步是设置运行负载测试中的各种参数。
图15-7是一个网络负载测试运行的结果图。
九条：数据太多了，我看这个表有点头晕，比打麻将要看的数据多多了。
阿亨：的确，网络应用的负载测试是一个复杂的领域，我们要下一番苦功把它掌握。一般把所有数据都保存到数据库中，以便将来做分析。但是我们还是要明确测试的目标：看看网络服务器能否在规定时间内处理用户的请求，服务器上有没有出现错误。这两种数据都能够马上得到。



图15-7 负载测试运行结果

[1] TDS应该在设计阶段完成，为了描述的方便，作者把大部分和测试相关的内容放到这一章。

[2]在Vista系统中，可能需要以管理员身份运行VSTT。

[3] 要注意，有些项目定义这里的“时限”是服务器处理的时间，不包括数据在网络传输的时间，和客户端浏览器（如：IE）显示内容的时间，移山公司使用这样的约定。

[4] Controller 和 Agent 要安装VSTS 的特定组件后才能使用。