现代软件工程讲义 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所示。

 

 


clip_image001[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所示。

 

 
  clip_image001

 

 

 

 

 

 

 

 

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的格式并未做严格要求。在一定规模的软件项目中,我们要求一个好的错误报告要能做到:

1Bug的标题,要简明地说明问题。

2Bug 的内容要写在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

clip_image003

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,以及headerbody中的各个参数。记录是否成功取决于服务器返回的状态码。当然,我们也可以自己定义pass/fail的条件。这样以后测试的时候重新放录音带即可。

操作:鼠标右键选中测试项目,选择 Add | Web Test(如图15-3所示)。

clip_image005

15-3  新增加一个 Web Test

Internet Explorer 就会打开,同时Web Test Recorder 也会激活[2]

 

测试人员就可以按照场景测试网站的各项功能了,同时注意到Web Test Recorder 会记录每一个网页的地址,以及可能的参数。

测试人员可以进一步增加测试的内容(如图15-4所示)。

clip_image007

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):在每次请求之间和一批测试之间的停顿。

clip_image009

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]

 

 

clip_image011

 

 

 

 

 

 

 

 

 

 

 

 

 

15-6  收集效能数据

这些效能数据会反映在负载测试中。

最后一步是设置运行负载测试中的各种参数。

15-7是一个网络负载测试运行的结果图。

九条:数据太多了,我看这个表有点头晕,比打麻将要看的数据多多了。

阿亨:的确,网络应用的负载测试是一个复杂的领域,我们要下一番苦功把它掌握。一般把所有数据都保存到数据库中,以便将来做分析。但是我们还是要明确测试的目标:看看网络服务器能否在规定时间内处理用户的请求,服务器上有没有出现错误。这两种数据都能够马上得到。

clip_image013

15-7  负载测试运行结果



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

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

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

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

posted @ 2011-11-19 21:40 SoftwareTeacher 阅读(...) 评论(...) 编辑 收藏