天津建筑网站建设,双线网站,广西网站建设公司电话,界面设计网站[来自 移山之道 第 13 章] 13.8 测试计划 测试不是在所有的开发工作完成之后才进行#xff0c;而是与开发几乎同步进行的。一个软件项目的各个功能都可以有自己的测试计划#xff0c;它们可以在不同的阶段发挥作用。但是针对整个项目的总测试计划#xff08;又叫测试总纲而是与开发几乎同步进行的。一个软件项目的各个功能都可以有自己的测试计划它们可以在不同的阶段发挥作用。但是针对整个项目的总测试计划又叫测试总纲要在计划阶段大致定下来并指导所有测试工作的进行。 那测试总纲到底讲什么呢 测试计划描述了一次测试活动的主要方面为什么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的格式并未做严格要求。在一定规模的软件项目中我们要求一个好的错误报告要能做到
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。 图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 的特定组件后才能使用。
