软件测试学习（四）自动测试和测试工具、缺陷轰炸、外包测试、计划测试工作、编写和跟踪测试用例-CSDN博客
| 阿里云国内75折 回扣 微信号：monov8 |
| 阿里云国际，腾讯云国际，低至75折。AWS 93折 免费开户实名账号 代冲值 优惠多多 微信号：monov8 飞机：@monov6 |
目录
自动测试和测试工具
测试软件是一项艰苦的工作。如果在阅读本书的同时已经进行了一些测试就会明白执行测试工作需要投入大量的时间和精力。诚然可以多花- -些时间对测试用例进行等价划分减少执行的数量但是随之就会冒更多风险因为减少了测试覆盖范围选择对某些重要的特性不进行测试。
如果测试员需要做更多测试但是没有时间怎么办?答案是采用人们在其他领域和行业中用了多年的办法一开 发并使用工具使工作更加轻松和高效。本章要讲的就是这方面的内容。
工具和自动化的好处
如果一个小型软件项目有数千个测试用例要执行时间可能只够执行一次测试。 多次执行测试是不可能的更不用说多次测试的单调和枯燥了。通过提供比手工测试更有效的手段软件测试工具和自动化可以帮助解决这个问题。
工具和自动化的主要属性是:
●速度。想一想手工尝试Windows计算器的数千个测试用例要花多少时间。也许大约平均每5秒执行一个测试用例。而自动化可能以10倍、100倍 甚至1000倍这样的速度来执行。
●效率。当测试员忙于执行测试用例时他会无暇干别的。如果有一个测试工具减少了执行测试用例的时间测试员就有更多时间进行测试计划考虑新的测试用例。
●准确度和精确度。测试员尝试几百个测试用例之后注意力可能会分散并开始犯错误。而测试工具则会一如既往地每次执行同样的测试并毫无差错地检查结果。
●节省资源。有时要执行一些测试用例基本上是不可能的比如创建测试条件需要的人数或设备数目可能就不允许。测试工具可以用来模拟真实的情况大大减少执行测试需要
的物理资源。
●仿真和模拟。测试工具常用来代替正常情况下与产品连接的硬件或软件。这些“伪”设备或“伪”程序以选定的方式来驱动或响应软件一- 除此之外实现起来可能困难。
●坚持不懈。测试工具和自动化永远不会劳累或者半途而废。它们就像电视广告中电动的小兔子一不停地跑啊跑。
测试工具
软件测试员会面对一大堆测试工具。使用工具的类型取决于测试的软件类型以及是进行黑盒测试还是白盒测试。
测试工具的好处是使用时并不是总需要深人了解工具在怎样做或者做什么。假设正在测试允许一台计算机同时与1百万台计算机连接的网络软件。即使有可能也很难用1百万个真实的连接进行可以控制的测试。但是如果有人提供能够模拟那些连接的专用工具也许可以从1到1百万调整连接的数目就可以在不搭建实际连接环境的前提下进行测试。测试员不必了解工具是怎样做到的只要知道它做得到就可以了这就是 黑盒测试。
另一方面还可以建立工具监视和改变上百万计算机之间原始通信的工具。要有效使用这些工具测试员需要具备一些白盒技能以及底层协议的知识。
查看器和监视器
查看器(viewer) 或者监视器( monitor)测试工具能够看到正常情况下看不到的软件运行的细节。第7章“带上X光眼镜测试软件”讲述了代码覆盖率分析器是如何提供一种方式来查看哪些代码行得以执行、什么函数正在运行、执行测试时所运行的代码分支的。代码覆盖:串分析器是查看工具的一个例子。大多数代码覆盖率分析器是人侵式工具因为它们需要编译并链接到原程序中才能获得所需信息。
驱动程序
驱动程序是控制和操作被测试软件的工具。最简单的驱动程序例子是批处理文件(batchfile)即依先后顺序执行的程序或命令的一个简单清单。在MS-DOS时代 这是测试员执行测试程序的流行方式。他们会创建包含测试程序名称的批处理文件启动运行批处理文件然后返回。在现今的操作系统和编程语言下执行测试程序有更多复杂的方法。
例如Java和Perl脚本可以取代老的MS-DOS批处理文件并且Windows任务调度程序可以在全天24小时的任意时刻执行各种测试程序。
桩
桩和驱动程序一样属于第7章所述的白盒测试技术。桩与驱动程序本质上是相反的桩不控制或者操作被测试软件;相反它接收或者响应软件发送的数据。给出的例子有助于澄清这一一点。如果测试向打印机发送数据的软件一种方法是输入数据并打印然后查看打印输出结果。这样虽然可行但是太慢、没有效率、易发生错误。怎样分辨输出是缺了一个像素还是一点点色差?如果换成用运行桩软件的另一台计算机来代替打印机读取并解释打印数据就可以非常快捷并且准确地检验测试结果。
压力和负载工具
压力(stress) 和负载(load) 工具用于向被测试软件增加压力和负载。文字处理程序如果作为系统上唯一运行的应用程序有足够的内存和磁盘空间工作状况就可能相当好。但是如果系统资源不足就极有可能碰到许多潜在软件缺陷。虽然可以通过复制文件使磁盘占满运行大量程序耗尽内存等但是这些方法效率不高而且不够恰当。为此专门设计的压力工具可以使测试更加容易。
其他操作系统和语言也有类似的工具软件。压力程序可以分别设置内存量、磁盘空间大小、文件数量以及在该机器上运行软件的其他可用资源。
干扰注入器和噪声发生器
另一.类工具是干扰注入器(interference injectors) 和噪声发生器(noise generators)。 它们类似于压力和负载工具但是在行为上更具有随机性。例如压力工具有随机更改可用.资源的执行模式。某个程序可能在内存充足条件下运行良好也能应付内存不足状况但是如果可用内存不断变化就可能有问题。压力工具的执行模式可以暴露此类软件缺陷。
分析工具
最后一类工具称为分析工具(analysis tool)是余下的- -组最佳工具。大多数软件测试员利用以下常用工具使日常工作简化。它们不- -定像前面的工具-样吸引人。虽然它们常常不受重视但是它们能够促进测试节省大量时间。
●文字处理软件
●电子表格软件
●数据库软件
●文件比较软件
●抓屏和比较软件
●调试器
●二进制一十六进制计算器
●秒表
●录像机或者照相机
当然软件的复杂性和方向性总是在变。要视具体情况来决定最有效的工具是什么以及如何运用他们。
软件测试自动化
虽然测试自动化(test automation)只是另- .类软件测试工具但是它是值得特别考虑的。到目前为止所学的软件测试工具虽然确实有效但是仍然需要手工操作或者监视。假如这些工具结合起来启动、执行几乎不用人工千预会怎样?它们可以执行测试用例、查找软件缺陷、分析看到的信息、记录结果。这就是软件测试自动化。
宏录制和回放
宏录制器和播放器是一种驱动程序工具。如前所述驱动程序是用于控制和操作被测试软件的工具。利用宏程序测试员可以这样做一回 放录制的宏重复执行测试软件的操作。
Macro Magic设置向导可以设置宏的如下选项:
●名称。为宏命名以便以后辨认。即使对于小型软件项目也可能要编写数百个宏。
●重复次数。重复测试是找出软件缺陷的好方法。可以设置宏在运行时重复或者循环的次数。
●触发条件。设置宏如何启动可以按热键( 例如Ctrl + Shift+T).输入一串字符(例如run macro 1)、单击快捷方式、当某个窗口显示出来时(例如一旦计算器启动)或者当系统闲置一段时间之后来启动。
●捕捉对象。可以选择只捕获(记录)键盘操作或键盘以及鼠标的移动和单击都记录。
●回放速度。宏回放的速度比最初录制时最多慢20%最多快500%。这对于软件性能可以变化的情形很重要。假如测试的软件变得有点慢,而宏单击的按钮还未出现在屏幕上结果会怎样?
●回放位置。该选项确定鼠标移动和单击位置与某个窗口的位置是绝对的还是相对的。如果测试某个可能在屏幕上改变位置的应用程序,使鼠标移动相对于应用程序是个好主意:否则鼠标单击位置可能不是预期的位置。
现在该实验宏的录制和回放了。寻找和下载- -些宏软件在几个简单程序( 例如计算器和记事本)。上反复试用 验证想法。要像测试员那样思考!通过实验可以发现虽然宏可以进行一些自动测试使重新执行测试更加容易和迅速但是效果并不理想。最大的问题是缺乏验证。宏无法检验软件是否以预期方式进行。宏虽然可以在计算器中输入100-99,但是不能测试结果是否为1-测试 员仍然要测试。诚然这是一个问题但是许多测试员乐于宏消除了所有重复输人和鼠标移动。只观察宏的执行确认得到预期结果是非常轻松的。
回放速度是宏的另外一个难题。即使可以调整回放的速度也不见得总能保持宏同步执行。网页可能需要1秒或者10秒来加载。虽然可以根据预计最差情形降低宏的速度但是它的执行速度就会一直慢即使软件运行速度变快了也无济于事。此外如果网页加载意外地用了15秒钟宏仍然会出现混乱一在 错误时刻单击错误的位置。
可编程的宏
可编程的宏是在简单录制和回放的变化上的一大进步。
与其通过录制第一次执行测试时的操作来创建可编程的宏不如在创建时编写回放系统遵循的简单指令。此类宏可以通过从菜单中选择独立的操作方式来编程一甚至不必输入命令。
注意此类可编程的宏与录制的宏相比具有真正的优势。尽管仍然无法验证测试的结果但是它可以暂停执行向测试员提示预期结果并询问测试是通过还是失败(见图15-8)。可编程的宏还可以解决录制宏的许多时序问题不是依靠绝对延时而是等待特定条件成立才继续执行。在计算器例子中宏等待程序加载之后继续进行测试一这 是比较可靠的方法。
完全可编程的自动测试工具
这些自动化工具具有的最重要特点是进行验证的能力实际上就是检查软件是否以预期方式运行。实现这一点有以下几种方式:
●屏幕捕获。首次执行自动测试时可以在肯定正确的关键点捕捉并保存屏幕图像。在以后进行测试时自动化工具可以利用保存的屏幕画面与当前屏幕画面进行比较。如果两者不同就说明出现意外自动化工具会把它标记为软件缺陷。注意使用屏幕捕获进行测试有相当大量的工作要进行维护。即使一个像素点的变化都会导致屏幕比较失败。除非软件的用户接口不变化否则在每次测试时进行手工捕获和比较那就违反了自动测试的目的了。
●控件值。比屏幕捕获更进一步可以检查软件窗口中各种控件的值。如果测试计算器程序自动化工具就会从显区域读取数值与预期结果进行比较。还可以判断是否单击了按钮或者选中了复选框。在测试程序中使用自动化工具可以轻松实现这一点。
●文件和其他输出。同样的如果软件把数据保存在文件中一例如文字处理程序一 自动化工具就能在建立文件之后将其读出与已知正确的文件比较。该技术同样适用于通过调制解调器或者网络发送数据的被测试软件。自动化工具可以配置为读回数据与预期数据进行比较。
随机测试猴子和大猩猩
到目前为止我们学习的测试自动化工具和技术主要是使软件测试员的工作更加轻松和富有成效。其设计目标是帮助测试员执行测试用例或者在理想状态下自动执行测试用例而不必管它。
出于该目的使用工具和自动化有助于找出软件缺陷;在工具忙着进行回归测试时软件测试员就有更多时间计划新的测试设计新奇有趣的用例。
然而另一类自动测试不是为帮助执行或者自动执行测试用例而设计的其目标是模拟用户可能的操作。此类自动化工具称为测试猴子( test monkey )。
测试猴子的说法来源于一一个想法如果让一百万只猴子在一百万只键盘上敲- - 百万年从统计的角度讲它们最终就可能写出莎士比亚话剧Adventures of Curious George (好奇乔治历险记)等巨著。胡乱敲键可能无意间碰到正确的字母组合这样猴子瞬间变得才华横溢,如图15-10所示。
当软件公开发布后可能会有成千上万的人使用。除非尽最大努力设计测试用例查找缺陷否则有些软件缺陷就会漏掉而被这些用户发现。在产品发布之前如果用模拟这些用户可能的操作的方式来补充测试用例结果会怎样?这就有可能发现以其他测试方式会漏掉的软件缺陷。这正是测试猴子做的工作。
使用测试工具和自动化的实质
在满怀喜悦地准备开始在测试中使用测试工具和自动化之前需要阅读本节并记在心里。测试自动化不是万能的。如果正确规划和执行的话工具和自动化可以使测试效率大大提高并且能发现其他方式不能发现的缺陷。然而如果自动化和工具步入歧途会导致无数的自动化测试的努力被放弃并且使项目成本大大增加。
在开始使用本章所述的技术之前应该对以下这些重要的问题加以考虑:
●软件变更。产品说明书从未修复过。后期增加了新特性。产品名称在最后一刻被更改。如果录制了数千个宏执行全部测试而在产品发布的前一周 软件改为启动时多显示一屏结果会怎样?所有录制的宏都将运行失败因为它们不知道多出一屏。这时需要编写的自动化程序具备灵活性在需要时能够方便快捷地改变。
●人眼和直觉是不可替代的。编出来的聪明猴子的聪明有限。它们只能执行人交给它们的测试。它们永远不可能看到什么说:“呀这很有趣。我还要做更多检查”一至少 目前不会。
●验证难以实现。如果测试用户界面验证测试结果最简单、最显然的方法是捕捉和比较屏幕画面。但是,屏幕画面是大型文件而且这些屏幕画面在产品开发过程中不断变化。要保证测试工具只检查需要的画面而且能够在产品开发过程中高效处理变化。
●容易过分依赖自动化。永远不要因为执行了全部自动化测试没有发现软件缺陷就认为没有软件缺陷要找了。软件缺陷仍然有这是杀虫剂怪现象。
●不要花费太多时间使用达不到测试软件目的的测试工具和自动化。开始编写宏和聪明猴子虽然轻松愉快但这不是测试。这些工具有助于提高效率但是需要在软件运行时使用它们并进行实际的测试才能找出软件缺陷。
●编写宏、开发工具和编制猴子都属于开发工作。软件测试员应该遵守要求程序员遵守的标准和规范。仅仅因为你是测试员不意味着可以破坏规则。
●某些工具是入侵式的可能导致被测试的软件不正常地失败。如果使用工具发现了一个软件缺陷要设法在不使用该工具的情况下重现这个软件缺陷。结论可能是一个简单的可重现的软件缺陷也可能是工具引起的问题。
缺陷轰炸和beta测试
让别人测试你的软件
人们很容易落入希望自己单独负责测试软件的陷阱中不要这样做。借助他人帮助会有很多收获。
测试共享
可能的话除非软件项目特别小否则至少有几个测试员来测试软件。即使只有几个人也可以多让几个人来查找缺陷。
一个常用方法是在一定时间内简单互换测试任务可以理解为“ 你执行我的测试我执行你的测试”。
双方都得以独立查看软件同时完成基本测试任务。双方还会了解自己不熟悉的软件领城从而可能会想出其他的测试用例来测试。至少可以让他人花时间审查等价划分和测试用例。他们可以根据自身经验为测试提供新的或不同的思路。共享测试任务的有趣方法是安排缺陷轰炸(bug bash)。缺陷轰炸是在一段时间(一般为几个小时)内整个测试小组停下指定的常规测试任务参加轰炸。在缺陷轰炸中选择软件中某一区域所有测试员集中测试这个区域或者这组特性。
选择区域可能是软件缺陷聚集之处看是否还有更多潜伏的问题;也可能是怀疑不存在软件缺陷的区域。利用缺陷轰炸可以确定普通测试是否会遗漏软件缺陷代码编写质量如何。选择区域虽然有不少内在规则但是最终要用缺陷轰炸让许多人从特定的软件区域寻找软件缺陷。请求协助寻找软件缺陷的最佳伙伴是产品支持或者客户服务小组一他们在客户打电话或者通过电子邮件咨询问题时与客户交谈。这些人显然对软件缺陷非常敏感是用来协助你测试的一一个巨大资源。找到产品发布后提供支持的人请他们参加测试共享活动。他们帮忙找到的软件缺陷会出人意料。
beta测试
这里所述的测试共享想法已经成为内部方法也就是说协助共享测试的人要么来自测试小组要么来自产品开发小组。另一种让他人验证和确认软件的常用过程称为beta测试( beta testing)
●谁是beta测试者?由于beta测试可能有不同的目标因此有必要了解谁参加beta测试。例如测试员也许想要指出软件中残留的易用性缺陷但是beta测试者可能全是有经验的技术人员更关心底层操作而不是易用性。如果测试员测试的软件部分要进行beta测试一定要在过程中指定所需的beta测试者类型以便从中获得最大收获。
●同样怎样知道beta测试者使用过软件呢?如果1000个beta测试者拿到软件一个月后报告没有发现问题那么是没有软件缺陷还是看到软件缺陷却没有报告还是邮寄的磁盘丢失了呢? beta测试者先把软件放上几天才开始试用的现象并不少见当他们开始试用时使用时间和特性都很有限。执行beta程序的测试员或者其他人一定要跟踪参加beta测试者以保证他们在使用软件并符合计划的目标。
●beta测试可以成为寻找配置和兼容性软件缺陷的好方法。如第8章“配置测试”和第9章“兼容性测试”中所述明确和测试能代表所有实际硬件和软件设置的典型样本是非常困难的。如果beta测试者挑选得明智能够代表目标客户他们就会帮大忙找出配置和兼容性软件缺陷。
●易用性测试是beta测试能有所作为的另一个领域。条件是精心挑选参加者一有 经验的用户和无经验的用户的完美结合。他们第一次看到软件将会轻松地找出不清楚或者难于使用之处。
●撇开配置、兼容性和易用性beta测试在寻找软件缺陷方面竟然出人意外地差。由于参加者一般没有足够的时间使用软件因此他们只能找出明显的大问题一测试员可能已经知道的。此外因为beta测试一般在开发周期行将结束时进行所以没有太多时间修复找到的软件缺陷。
●Beta测试程序会耗费测试员大量时间测试新手的常见任务是与beta客户一起帮助解决他们的问题回答提问确认他们找到的软件缺陷。如果受命执行该任务还需要和其他测试员合作以了解软件缺陷是怎样溜到beta测试者那里的以及如何改善测试用。
例使得软件缺陷将来能够在内部发现。所有这些可能是满负荷的工作留给自己亲自做实际测试的时间几乎没有。
外包测试
许多公司采用的一种常用做法是向擅长各方面软件测试的其他公司外包或提交部分测试工作。虽然这看上去比由产品小组的测试员来完成要更麻烦、更昂贵但是如果做得好这可能成为共享测试的有效途径。
配置和兼容性测试通常是外包测试的理想选择。这些测试一般需要拥有众多不同硬件和软件组合的大型测试实验室以及一些人员来管理。大多数小型软件公司无法承受维护这些测试实验室的开销因此 向专门从事配置和兼容性测试业务的公司外包测试很有意义。
本地化测试是另一个通常被外包测试的例子除非拥有相当庞大的测试小组否则配备能懂产品支持的各种语言的测试员是不可能的。小组中拥有一批讲外语的测试员来查找基本的本地化问题虽然很有好处但是外包特定语言的测试可能更加有效。专门从事本地化测试的公司拥有能讲各种语言而且具备测试经验的测试员。
以下是有助于使任务执行更顺利需要考虑并与测试经理或者项目经理探讨的问题:
●测试公司究竟要执行哪些测试任务?谁来定义?谁来批准?
●他们遵守哪个进度?谁来制定进度?如果超过最后期限会怎样?
●为测试公司提供哪些内容?例如软件说明书、阶段性软件更新以及测试用例。
●测试公司提供哪些内容?至少要提供他们找出的软件缺陷。
●如何与测试公司联系?是电话、电子邮件、因特网、中心数据库还是每天登门造访谁是两边的联络点?
●怎样知道测试公司是否满足期望?他们怎样知道是否满足期望?
这些不是严格的科学课题但是在匆忙外包测试任务时常常被忽视。把软件扔过去要测试公司“测试它”是--种老毛病。然而花一些时间提前计划能使外包成为非常有效的测试手段否则由于资源限制无法处理测试。
计划测试工作
这一部分各章将把这些知识联系起来说明和软件测试有关的所有工作是如何计划、如何组织以及如何和项目小组之间进行交流的。
测试计划的目标
测试过程不可能在真空中进行。如果程序员编写代码而不说明它干什么、如何工作、何时完成执行测试任务就很困难了。同样如果测试员之间不交流计划测试的对象需要什么资源进度如何安排整个项目就很难成功。软件测试计划( software test plan)是软件测试员与产品开发小组交流意图的主要方式。
根据该定义和IEEE的其他标准我们注意到测试计划采用的形式是书面文档。这虽然并不奇怪但却是非常重要的一点因为尽管最终结果只是一页纸(或者联机文档或者网页),但是这页纸不是测试计划的全部内容。
测试计划过程的最终目标是交流(而不是记录)软件测试小组的意图、期望以及对将要执行的测试任务的理解。
测试计划主题
因此本书中看不到测试计划模板。取而代之的是要遵循一系列重要主题的清单该清单应该在整个项目小组一包括所有 测试员中全面讨论、相互沟通并达成一致。该清单也许不能完全适用所有项目但是因为它列出了常见的与重要测试相关的问题所以比测试计划模板更实用。由于从本质上讲计划是一个动态过程因此如果发现列出的问题不适应具体情况就可以自行调整。
当然测试计划过程的结果是某一种文档。如果行业或者公司有自己的标准格式可以预先定义。软件测试文档的IEEE标准829-1998推荐了一种常用格式。除此之外格式可由项目小组来决定应该能够非常有效地交流工作成果。
高级期望
测试过程中的第1个论题是定义测试小组的高级期望。虽然这是项目小组全部成员必须一致同意的基本论题但是常常被忽视。它们可能被认为“太过明显”并且想当然地假定每个人都了解一但是 优秀的测试员知道永远不要假定任何事。
人、地点和事
测试计划需要明确在项目中工作的人他干什么怎样和他联系。在小项目中这似乎没有必要但是即使是小项目小组成员也可能分散在很远的地方或者人员变动为跟踪谁做什么造成困难。大型团队可能有数十或数百个联络点测试小组很可能要和所有人打交道,知道他们是谁和如何联系是非常重要的。测试计划应该包括项目中所有主要人员的姓名、职务、地址、电话号码、电子邮件地址和职责范围。
该论题最好的描述是“ 测试新手问题指南”。这通常是要测试新手负责的好的测试计划部分。找到所有问题的答案并把发现记录下来。你想知道的也是别人想知道的。
定义
让项目小组中的全部成员在高级质量和可靠性目标上达成一致是一件困难的事情。不幸的是这只是软件项目中需要定义的用词和术语的开始。回顾第1章“软件测试的背景”中关
于软件缺陷的定义:
1)软件未实现产品说明书要求的功能。
2)软件出现了产品说明书指明不应该出现的错误。
3)软件实现了产品说明书未提到的功能。
4)软件未实现产品说明书虽未明确提及但应该实现的目标。
能确认小组全部成员知道、理解一更重要的是 同意该定义吗?项目经理知道软件测试员的目标吗?如果不是这样测试计划的过程就是保证他们要理解和同意。
以下是一些常用术语和相当松散的定义。不要把它当做完整或者定义明确的清单。它取决于具体项目、开发小组遵循的开发模式以及小组成员的经验。该清单列出的术语只是在应该为项目定义哪些内容的考虑上开拓思路并说明使全体人员了解其含义的重要性。
●构造。程序员放在一起需要测试的代码和内容的搜集。测试计划应该定义构造的频率(每天、每周等)以及期望的质量等级。
●测试发布文档(TRD)。 程序员发布的文档。对每-一个构造都声明新特性、不同特性、修复问题和准备测试的内容。
●Alpha版。意在对少数主要客户和市场进行数量有限的分发用于演示目的的早期构造。其无意在实际环境中使用。使用alpha版的所有人员必须了解确切内容和质量等级。
●Beta版。意在向潜在客户广泛分发的正式构造。回顾第16章“ 缺陷轰炸和beta测试”所述进行beta测试的原因需要定义。
●说明书完成。说明书预计完成并且不再更改的日程安排。千过几个项目之后就会知道这个期限只能在虚幻小说中实现但是它确实应该设定,以后只能进行控制范围内的小改动。
●特性完成。程序员不再向代码增加新特性并集中修复缺陷的日期安排。
●软件缺陷会议。由测试经理、项目经理、开发经理和产品支持经理组成的团队每周召
开会议审查软件缺陷并确定哪些需要修复应该如何修复。软件缺陷会议是在测试计划中建立质量和可靠性目标的主要措施之--。
团队之间的责任
团队之间的责任是明确指出可能影响测试工作的任务和交付内容。测试小组的工作由许多其他功能团队驱动一程序员、 项目经理、技术文档作者等。如果责任未明确整个项目一 尤其是测试一 就会出现戏剧化情景:“我拿了不你拿了你还没有处理不我想你已经处理过了”从而导致重要的任务被忘记。
需要定义的任务类型不像测试员的测试、程序员的程序那样容易分清。麻烦的任务可能有多个负责者有时没有责任者或者由多人共同负责。计划这些任务和交流计划最容易的方法是使用如图17-1所示的简表。
哪些要测试、哪些不要测试
有时会惊奇地发现软件产品中包含的某些内容不必测试。这些内容可能是以前发布过或者测试过的软件部分。来自其他软件公司并已经测试过的内容可以直接接受。外包公司会提供预先测试过的产品部分。计划过程需要验明软件的每一部分确定它是否要测试。如果没有测试需要说明这样做的理由。如果由于误解而使部分代码在整个开发周期漏掉未做任何测试就可能导致一场灾难。
测试的阶段
要计划测试的阶段测试小组就会查看预定的开发模式并决定在项目期间是采用一个测试阶段还是分阶段测试。在边写边改模式中可能只有一个测试阶段一不断 测试直到某个成员宣布测试停止。在瀑布和螺旋模式中从检查产品说明书到验收测试可能有几个阶段测试计划也属于其中一个测试阶段。测试的计划过程应该明确每一个预定的测试阶段并告知项目小组。该过程一般有助于整个小组形成和了解全部开发模式。
测试策略
与定义测试阶段相关联的练习是定义测试策略。测试策略描述测试小组用于测试整体和每个阶段的方法。回顾到目前为止所学的软件测试知识。如果你面对需要测试的产品就需要决定使用黑盒测试好还是白盒测试好。如果决定综合使用这两种技术那么在软件的哪些部分什么时候运用它们呢?
某些代码用手工测试而其他代码用工具和自动化测试也许是个不错的想法。如果要使用工具那么是否需要开发或者能够买到已有的商用解决方案?如果是选择哪一种情况?也许更有效的方法是把整个测试工作外包到专业测试公司只要形同虚设的测试员监督他们的工作即可。
资源需求
计划资源需求是确定实现测试策略必备条件的过程。在项目期间测试可能用到的任何资源都要考虑到。例如:
●人员。人员数量、经验和专长?他们是全职、兼职、合同还是学生?
●设备。计算机、测试硬件、打印机、工具。
●办公室和实验室空间。在哪里?有多大?如何布局?
●软件。文字处理程序、数据库程序和自定义工具。要购买哪些东西?要写什么材料?
●外包测试公司。用他们吗?选择他们有什么原则?他们的费用如何?
●其他配备。磁盘、电话、参考书、培训资料。在项目期间还需要别的吗?
特定资源需求取决于项目、小组和公司因此测试计划工作要仔细估算测试软件的要求。开始不做好预算到项目后期获取资源通常很困难甚至无法做到因此创建完整清单是必要的。
测试员的任务分配
一旦定义了测试阶段、测试策略和资源要求这些信息加上产品说明书就可以分配每个测试员的任务。前面讨论的团队之间的责任是指哪些功能性团体(管理、测试和程序员等)负责哪些高级任务。计划测试员任务分配是指明确测试员负责软件的哪些部分、哪些可测试特性。表17-1给出了一个极为简化的Windows写字板程序的测试员任务分配表。
测试进度
测试进度需要以上所述的全部信息并将其映射到整个项目进度中。该阶段一般在测试计划工作中至关重要因为原以为很容易设计和编码的一些必要特性可能后来证实测试非常耗时。一个例子是某程序在不明显的有限区域之外不执行打印。没有人意识到打印对测试的影响而在产品中保留该特性结果导致打印机配置测试要花几周时间。作为测试计划的一部分完成测试进度安排可以为产品小组和项目经理提供信息以便更好地安排整个项目的进度。他们甚至会根据测试进度决定砍掉产品的一些特性或者将其推迟到下一个版本中推出。
许多软件进度安排产品会使该过程容易管理。项目经理或者测试经理最终负责进度安排,可能会使用此类软件但是要求测试员参与安排自己的具体任务。
测试用例
本书前面已经讲过什么是测试用例了。后面会详细讲到如何写测试用例。测试计划过程将决定用什么方法编写测试用例在哪里保存测试用例如何使用和维护测试用例。
软件缺陷报告
第19章“报告发现的问题”将讲述用于记录和跟踪所发现的软件缺陷的技术。报告的各种可能的方式包括:隔着墙壁呼喊使用粘性便签使用复杂的觖陷跟踪数据库。使用哪些过程需要计划以便每个软件缺陷从发现到修复的过程中都被跟踪这样就绝不会被忘掉。
度量和统计
度量和统计是跟踪项目发展、成效和测试的手段。详情见第20章“ 成效评价”。测试的计划过程应该明确收集哪些信息要做什么决定谁来负责收集。实用的测试度量的例子如下:
●在项目期间每天发现的软件缺陷总数。
●仍然需要修复的软件缺陷清单。
●根据严重程度对当前软件缺陷评级。
●每个测试员找出的软件缺陷总数。
●从每个特性或者区域发现的软件缺陷数目。
风险和问题
测试计划中常用而且非常实用的部分是明确指出项目的潜在问题或者风险区域这是对测试工作有影响的地方。假设有十几个测试新手全部软件测试经验来自于阅读本书受命测试新建核电站的软件这就是风险。也许某个新软件要对1500个调制解调器进行测试在项目进度中的时间只能对其中500个进行测试这又是一个风险。软件测试员要负责明确指出计划过程中的风险并与测试经理和项目经理交换意见。这些风险应该在测试计划中明确指出在进度中给予说明。有些是真正的风险而有些最终证实是无关紧要的。重要的是尽早明确指出以免在项目晚期发现时感到惊慌。
编写和跟踪测试用例
测试用例计划的目标
有一句老话:“对鹅是好东西对鸭也是好东西”。意思是说对某个人或者团队有益的事情对其他人或者团队也有益。但愿读者依据目前所学可以得出:程序员拿到产品说明书就立即开始编制代码而不必开发更详细的计划并分发出去审查是错误的。测试员拿到测试计划马上坐下来想出测试用例并开始测试也应该视为错误的做法。如果软件测试员指望项目经理和程序员更加规范向他们灌输-些方法按照规则来使开发过程更加顺利进行这种想法也是错误的。
有条不紊地仔细计划测试用例是达成目标的必由之路。这样做的重要性有如下4条原因:
●组织。即使在小型软件项目上也可能有数千个测试用例。测试用例的建立可能需要一些测试员经过几个月甚至几年时间。正确的计划会组织好用例以便全体测试员和其他项目小组成员有效地审查和使用。
●重复性。我们已经知道在项目期间有必要多次执行同样的测试以寻找新的软件缺陷保证老的软件缺陷得以修复。假如没有正确的计划就不可能知道最后执行哪个测试用例及其执行情况以便重复原有的测试。
●跟踪。同样在整个项目期间需要回答一下这些重要的问题。计划执行多少个测试用例?在软件最终发行版本上执行多少个测试用例?多少个通过多少个失败?有被忽略的测试用例吗?等等。如果测试用例没有计划就不能回答这些问题。
●测试(或者不测试)证实。在少数高风险行业中软件测试小组必须证明确实执行了计划执行的测试。发布忽略某些测试用例的软件实际上是不合法和危险的。正确的测试用例计划和跟踪提供了一种证明测试内容的手段。
测试用例综述
最低要求是测试小组应该创建包含IEEE829大纲中所述信息的测试计划。如果书面文档完全适用(难以置信)那么全力使用它好了。然而如果认为中心数据库更有效而且测试小组有时间和预算开支来开发或者购买就应该使用该方法。这根本无关紧要。要紧的是完成工作后满足了测试用例计划的4个目标:组织、重复性、跟踪和测试证实。
测试设计
整体项目计划在非常高的等级上编制。它把软件拆分为具体特性和可测试项并将其分派到每个测试员头上但是不指明这些特性如何测试。测试计划可能会提到使用自动化测试或者使用黑盒测试或者使用白盒测试但是不会涉及它们在哪里和如何使用的具体细节。为单个软件特性定义测试方法的下一级细节是测试设计说明。
●标识符。用于引用和标记测试设计说明的唯一标识符。该说明还应该引用整个测试计划包含引用任何其他计划或者说明的指示。
●要测试的特性。测试设计说明所包含的软件特性描述一例如 “计算器程序的加法功能”、“写字 板程序中的字体大小选择和显示”和“QuickTime软件的视频 卡配置测试”。该部分还将明确指出作为主要特性的辅助特性需要间接测试的特性。例如“文件打开对话框的用户界面虽然不是本计划的目标但是在测试读写功能的过程中要间接测试加载和保存功能”。还要列出不被测试的特性即计划中由于错误分析包含进来的特性。例如“因为测试计算器程序的加法功能通过自动化方式发送击键信息到程序来运行所以没有屏幕用户界面的间接测试。用户界面测试在单独测试设计计划中说明一CalcU12345中 。”
●方法。描述测试软件特性的通用方法。如果在测试计划中列出方法就应该进行展开描述要使用的技术解释结果如何验证。例如“要开发测试工具顺序读写预先建好的各种大小的数据文件。通过黑盒技术加上程序员提供的白盒示例确定数据文件的数目、大小和包含的数据。通过文件比较工具逐位比较保存的文件和源文件来确定测试通过还是失败。
●测试用例确认。对用于检查特性的具体测试用例的高级描述和引用。它应该列出所选的等价划分并提供测试用例的引用信息以及用于执行测试用例的程序。
●通过/失败规则。描述测试特性的通过和失败由什么构成。哪些可以接受哪些不能接受。这可能是非常简单和明确的一通过是指当执行全部测试用例时没有发现软件缺陷;也可能是令人困惑的一失败 是指10%以上测试用例没有通过。然而无疑总应该有什么构成特性的通过和失败。
测试用例
IEEE 829标准称测试用例说明为“ 编写用于输入的实际数值和预期输出结果数值。测试用例还明确指出使用具体测试用例产生的测试程序的任何限制。”测试用例细节基本上应该清楚地解释要向软件发送什么值或者条件以及预期结果。它可以由一个或多个测试用例说明来引用也可以引用多个测试程序。IEEE 829标准还列出了其他应该包含在内的重要信息:
●标识符。由测试设计过程说明和测试程序说明引用的唯一标识符。
●测试项。描述被测试的详细特性、代码模块等应该比测试设计说明中所列的特性更加具体。如果测试设计说明说“计算器程序的加法功能”那么测试用例说明会说“ 加法运算的上限溢出处理”。它还要提供产品说明书的引用信息或者测试用例所依据的其他设计文档。
●输入说明。该说明列举送到软件执行测试用例的所有输入内容或者条件。如果测试计算器程序输人说明可能简单到1+1;如果测试移动电话交换软件输入说明可能是成百上千种输入条件;如果测试基于文件的产品输入说明可能是文件名和内容的描述。
●输出说明。描述进行测试用例预期的结果。1+1等于2吗?在移动电话软件中上千个输出变量设置正确吗?加载文件的全部内容和预想的一样吗?
●环境要求。环境要求是指执行测试用例必要的硬件、软件、测试工具、实用工具、人员等。
●特殊过程要求。描述执行测试必须做到的特殊要求。测试写字板程序也许不需要任何特殊条件但是测试核电站软件就有特殊要求。
●用例之间的依赖性。第1章“软件测试的背景”中讲述了一个导致美国航天局火星极地登陆者号探测器在火星上撞毁的软件缺陷。这是一个用例之间依赖性未形成文档的好例子。如果一个测试用例依赖于其他用例或者受其他用例的影响就应该在此说明。
表述测试用例的其他选择有简单列表、大纲甚至诸如状态表或数据流程图之类的图表。请记住测试员在设法与他人交流测试用例时应该使用最有效的方法。发挥创造性但是要讲求实际不要偏离编写测试用例的目的。
测试程序
编写完测试设计和测试用例文档之后余下的是要执行测试用例的程序。IEEE 829标准称测试程序(test procedure)说明为“ 明确指出为实现相关测试设计而操作软件系统和试验具体测试用例的全部步骤”。测试程序或者测试脚本(test script) 说明详细定义了执行测试用例的每一步操作。以下是需要定义的内容:
●标识符。把测试程序与相关测试用例和测试设计捆绑在一起的唯一 标识符。
●目的。程序的目的以及将要执行的测试用例的引用信息。.
●特殊要求。执行程序所需的其他程序、特殊测试技术或者特殊设备。
●程序步骤。执行测试的详细描述: .
●日志。指出用什么方式、方法记录结果和现象。
●设置。说明如何准备测试。
●启动。说明用于启动测试的步骤。
●程序。描述用于运行测试的步骤。
●度量。描述如何判断结果一例如用秒表或者肉眼判断。
●关闭。说明由于意外原因挂起测试的步骤。
●重启。告诉测试人员如果出现故障或关者关闭以后如何在恰当的时候重启测试。
●终止。描述测试正常停止的步骤。.
●重置。说明如何把环境恢复到测试前的状态。
●偶然事件。说明如何处理计划之外的情况。
测试用例组织和跟踪
在建立测试用例文档时应该考虑的一个问题是如何组织和跟踪信息。想一想测试员或者
测试小组应该能够回答的下列问题:
●计划执行哪些测试用例?
●计划执行多少个测试用例?执行需要多少时间?
●能否挑选出测试集(test suites,相关测试用例组)测试某些特性或者软件部分?
●在执行测试用例时能否记录哪-一个通过、哪-一个失败?
●在失败的测试用例中哪些在最近的一次执行时也失败了?
●最近一次执行测试用例时通过的百分比是多少?
这些重要问题的例子在多数项目的过程中要反复地问。第20章“成效评价”将详细讨论数据收集和统计。眼前先考虑管理测试用例和跟踪执行结果所需的一些过程。管理和跟踪系统基本上有以下4种:
●凭脑子记。绝对不要考虑这一种即使对于最简单的项目也不例外除非测试的软件仅限于个人使用没有理由跟踪测试。不能这样做。
●书面文档。对于非常小的项目可以用纸笔来管理测试用例。检查清单的表格和框图得到了有效利用。这显然是管理和搜索数据的低劣方法但是它提供了一个非常重要的物证----包含测试员亲笔签字注明执行测试的书面检查清单在法律上是证明测试执行过的极佳证据。
●电子表格。使用电子表格是跟踪测试用例非常奏效的流行方法。图18-4给出了一个这样的例子。电子表格在一个地方保存测试用例的全部细节从而可以提供测试状态的一目了然的查看方式。这种方法容易使用比较容易建立可以为测试提供很好的跟踪和证明。
●自定义数据库。跟踪测试用例的理想方法是使用测试用例管理工具(TestCaseManagement Tool),一种为处理测试用例而专门编程设计的数据库。已经有许多完成这项任务的商业应用程序。访问第22章“软件测试员的职业”中所列的- - 些Web链接可以得到详细信息和其他测试员的推荐。如果有兴趣建立自己的跟踪系统诸如ClarisFileMaker Pro, Microsoft Access之类的数据库软件提供几乎完全拖放式的数据库建立方法仅用几个小时就可以建立反映IEEE 829标准的数据库。在此基础上可以建立能够回答任何有关测试用例问题的报表和查询。