Rational Robot 是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面 IBM Rational TestManager 上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。 网址：http://www-306.ibm.com/software/rational/ WinRunner 是一种企业级的用于检验应用程序是否如期运行的功能性测试工具。通过自动捕获，检测，和重复用户交互的操作，WinRunner 能够辨认缺陷并且确保那些跨越多个应用程序和数据库的业务流程在初次发布就能避免出现故障，并且保持长期可靠运行。 网址：http://www.mercury.com QuickTest Professional 是一个功能测试自动化工具，主要应用在回归测试中。QuickTest针对的是GUI应用程序，包括传统的Windows应用程序，以及现在越来越流行的Web应用。它可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。其中包括：创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果和维护测试等方面。 网址：http://www.mercury.com AdventNet QEngine AdventNet QEngine是一个应用广泛且独立于平台的自动化软件测试工具，可用于Web功能测试、web性能测试、Java应用功能测试、Java API测试、SOAP测试、回归测试和Java应用性能测试。支持对于使用HTML、JSP、ASP、.NET、PHP、Javascrīpt/VBscrīpt、XML、SOAP、WSDL、e-commerce、传统客户端/服务器等开发的应用程序进行测试。此工具以Java开发，因此便于移植和提供多平台支持。 网址：http://www.adventnet.com SilkTest 是业界领先的、用于对企业级应用进行功能测试的产品，可用于测试Web、Java或是传统的C/S结构。SilkTest提供了许多功能，使用户能够高效率地进行软件自动化测试。这些功能包括：测试的计划和管理；直接的数据库访问及校验；灵活、强大的4Test脚本语言，内置的恢复系统(Recovery System)；以及具有使用同一套脚本进行跨平台、跨浏览器和技术进行测试的能力。 网址：http://www.segue.com QA Run QARun的测试实现方式是通过鼠标移动、键盘点击操作被测应用，即而得到相应的测试脚本，对该脚本可以进行编辑和调试。在记录的过程中可针对被测应用中所包含的功能点进行基线值的建立，换句话说就是在插入检查点的同时建立期望值。在这里检查点是目标系统的一个特殊方面在一特定点的期望状态。通常，检查点在QARun提示目标系统执行一系列事件之后被执行。检查点用于确定实际结果与期望结果是否相同。 网址：http://www.compuware.com Test Partner 是一个自动化的功能测试工具，它专为测试基于微软、 Java和Web技术的复杂应用而设计。它使测试人员和开发人员都可以使用可视的脚本编制和自动向导来生成可重复的测试，用户可以调用VBA的所有功能，并进行任何水平层次和细节的测试。TestPartner的脚本开发采用通用的、分层的方式来进行。没有编程知识的测试人员也可以通过TestPartner的可视化导航器来快速创建测试并执行。通过可视的导航器录制并回放测试，每一个测试都将被展示为树状结构，以清楚地显现测试通过应用的路径。 网址：http://www.compuware.com Holodeck - 强大的故障植入软件测试工具 Holodeck is an advanced fault-injection tool that gives you the power to attack an application while it monitors and logs everything your application does - every function call, registry entry, piece of data read or written. 网址：http://www.securityinnovation.com/holodeck/ Telelogic TAU TAU第二代包含三个最新的、最强大的技术用来加速大规模软件开发和测试：统一建模语言(UML) 及它的许多最新修订版本中的特性，UML2.0；功能强大的测试语言TTCN-3和新的构造系统的方法：Model Driven Architecture(模型驱动构架)。这三个新的业界标准结合成TAU的已经过认可的软件开发平台，形成了一个系统，一个一流的稳定可靠的工具解决方案。TAU第二代是系统与软件开发解决方案的一个突破，它把业界从使用了太长时间的手工、易出错、以代码为中心的方法中释放出来，自然而然地迈向下一步，一个更加可视化、自动化及可靠的开发方法。 Telelogic TAU/Tester是基于通用测试语言TTCN-3,用于自动化的系统和集成测试的强大工具。TAU/Tester以现代化的开发工具为基础，提供高层测试功能，支持整个测试生命周期，加速自动化测试。TAU/Tester可使用户特别关注于测试的开发，因为TTCN-3语言是独立于开发语言或测试设备的，且是抽象和可移植的。 网址：http://www.telelogic.com

   这几天又开始看蔡为东的《软件测试实战  ——测试WEB MSN》，深刻感受到测试里面学问实在是大。

   印象最深的是当时看到退出功能测试，有点发癫。

   原文大致如下：

1. 点击窗口链接中的“退出”链接
2. 主窗口标题栏上的“关闭”按钮
3. Alt+F4
4. 长时间不使用
5. 网络断开
6. 浏览器进程被强行结束
7. 计算机断电
[8.] 使用同一个帐号再次登录
[9.] 接到服务器命令，被要求退出（服务器错误或者超负荷）

一个退出功能的测试就如此强悍，实在让人惊叹！

 

扩展性评测，大家知道测试软件中，数据至关重要。如登陆测试中，需要验证所有用户是否可以成功登录。用手工测试工作量太大，利用测试工具脚本的强大功能，就可以减少工作量.对任意用户进行登陆测试，脚本从用户文件中读取数据，每次测试人员需要测试新的用户，只要添加用户到用户列表中，就可以自动测试新用户登陆是否成功。

 

 

1.    Winrunner

设计user.txt文本格式：用户<kTab>密码<kReturn>

如：  admin<kTab>jetspeed<kReturn> 

 

脚本如下：

web_browser_invoke(IE,"http://192.168.1.42");
win_max("Browser main Window");
//打开文件

file_open("F:\\user.txt",FO_MODE_READ);

//读取文件数据，填写用户名，密码
while(file_getline("F:\\user.txt",line)==0)
{
    win_mouse_click ("html_frame_2", 402, 36);
    win_type("html_frame_2",line);
    win_mouse_click ("html_frame_2", 566, 33);
}
file_close("F:\\user.txt");

 

备注：由于winrunner脚本为语言为c，所以注意c语言特性，对于特殊字符需要利用转义字符“\”, file_open("F:\\user.txt",FO_MODE_READ)，这里f:\user.txt,就需要加转义字符。

2.    Robot

设计user.txt文本格式：用户 密码

如：admin jetspeed

脚本如下：

 

Sub Main

    Dim Result As Integer

    Dim Temp as String

    dim FileNumber as integer

    Dim iPos as integer

    Dim UserName as string

    Dim pw as string

    'Initially Recorded: 2003-12-22  17:07:58

'scrīpt Name: Demo

 

   

StartBrowser "http://192.168.1.42", "WindowTag=WEBBrowser"

   

    Window SetContext, "WindowTag=WEBBrowser", ""

    Browser NewPage,"HTMLTitle=Dynaweb EPS 2003企业门户服务器",""

   

   

'  

    FileNumber = FreeFile

//循环读取文件中数据，登陆

//自读形式 打开文件

    Open "f:\user.txt" For Input As #FileNumber

Do While Not EOF(1)

 // 读取数据，进行处理

      Line Input #FileNumber, Temp

      iPos = InStr(1,Temp," ")

      //提取用户名

UserName = left(Temp,iPos-1)

     //提取密码

pw = Right(Temp,len(Temp)-6) 

      //找到用户，密码文本框，填写用户名，密码

EditBox Click, "Name=username", "Coords=35,12"

      Inputkeys UserName

      EditBox Click, "Name=password", "Coords=15,8"

      inputkeys pw

      //提交数据，退出当前用户

      PushButton Click, "Name=submit"

      Browser NewPage,"HTMLTitle=Dynaweb EPS 2003企业门户服务器",""

      HTMLImage Click, "Index=7", "Coords=11,7"

    Loop

    Close #FileNumber

    //关闭Ie

    Window CloseWin, "", ""

 

End Sub

 

 

3.    quick test

设计user.txt文本格式：用户 密码

如：admin jetspeed

脚本如下：

Dim iPos
Dim UserName
Dim pw
Dim fso
Dim ts
Dim Temp
 
   Set fso = CreateObject("scrīpting.FileSystemObject")
   Set ts = fso.OpenTextFile("F:\user.txt",1)
  
   Do While not ts.AtEndOfStream  
      Temp = ts.ReadLine
      iPos = InStr(1,Temp," ")
      UserName = left(Temp,iPos-1)
      pw = Right(Temp,len(Temp)-6)

      Browser("Dynaweb EPS").Page("Dynaweb EPS").WebEdit("username").Set UserName
      Browser("Dynaweb EPS").Page("Dynaweb EPS").WebEdit("password").Set pw
      Browser("Dynaweb EPS").Page("Dynaweb EPS").WebButton("v{ _U ").Click
     Browser("Dynaweb EPS").Page("Dynaweb EPS_2").Link("恄 Q | ~ ").Click
      Browser("Dynaweb EPS").Page("Dynaweb EPS_3").Sync
    
 loop
 
 ts.close

备注：quick test脚本

一．中文注释要引号加空格

二．Vbscrīpt脚本语言有限制，它只是vb语言的子集

三．声明不需要添加类型，否则脚本编译不通过，差错很困难

    在上一篇文章中，简单的而介绍了一些测试覆盖率相关的工具，由于大部分工具笔者并没有使用的经验，因此只是简单地从网络搜索了一下相关资料并将其整理出来，关于上篇文章的详细内容，参见：测试覆盖率之四——测试覆盖率工具汇总。

    这篇文章中，主要讨论的是如何提高测试覆盖率的相关问题。其实，提高测试覆盖率最基本，甚至是唯一的办法就是增加测试用例，但是怎样通过增加测试用例而帮助我们“迅速”提高我们的测试覆盖率呢？

    代码走查 对于代码的不熟悉造成了我们的代码覆盖率迟迟上不去，我们需要了解到代码里面究竟有多少条件分支，多少怎样的循环，分支和循环向来是导致我们代码覆盖率比较低的原因，另外，是不是存在一些过时的代码，没有运行过代码监测工具的代码中很可能存在一些没有被引用的死代码，而代码走查，尤其是对于覆盖率低的模块的代码走查将有助于你增加相关的用例而提高代码覆盖率。

    工具 这里倒不是说有些工具可以帮助你直接提高代码覆盖率，这样的工具至少我还没有就见过。这里提到的工具主要包括两种，一是代码分析工具另外一种就是上篇文章中提到的代码覆盖率工具。代码分析工具可以帮助我们分析代码中的冗余部分，这样可以帮助我们干掉那些总是不可能覆盖到的死函数，有的编译器已经提供了类似的功能。使用代码覆盖率工具则可以帮助我们快速监测代码覆盖率低的地方，这样我们可以快速定位我们测试的薄弱环节，通过代码走查或其他方式可以快速增加用例。一般来讲，某一模块的代码覆盖率从30%提高到50%所需的时间遥远小于从60%提高到80%的时间。

    规则  这里所指的规则其实是指一些基本测试方法，如等价类划分，边界值分析。我们有时候需要通过这些手段来逐一检查我们那些方面的测试用例没有考虑到，从而帮助我们增加相关的测试用例。

    经验  这个看起来有点像废话，因为一般都知道测试经验丰富有助于测试用例的设计，写出别人没有想到的测试用例。我在这里把这句话提出来的主要意图是告诉大家注意平时的积累，某些时候的灵光一现可能成为日后的一个重要用例。以前的失败教训也可以帮助我们从中学到经验，毕竟“经验是人为其错误而找的代名词”。

    注意  有一点我想有必要再次提醒大家：单方面的提高测试覆盖率并不能有效的帮助测试质量的提升，尤其是在代码质量低劣的情况下。就拿一个经典的三角形测试用例来讲，开发人员的代码可能仅仅判断了“两边之和大于第三边”然后就返回“这是三角形”。在测试用例中，我们可能考虑了很多的问题，考虑了输入数据的类型，合法性等等的问题，但是这并无助于增加测试覆盖率。运行这些测试结果是万里江山一片红，记住在你的测试用例没有运行通过的时候考虑测试覆盖率是没有意义的，我目前想到了两条理由：一是这些测试用例可能在代码的中间部分就已经出了问题，所以用例本该覆盖到语句没有覆盖到，这降低了代码覆盖率数据；第二个理由测试用例没有通过可能就如刚才提到的三角形问题中一样，开发人员压根就没有那么多语句给你去覆盖，这时候的代码覆盖率数据显然是没有多大作用的。这也印证了前面文章中提到的“高代码覆盖率比低代码覆盖率更加‘没用’”。

     写到这里，我的观点已经表达完毕了。这一系列文章也差不多可以做个了结了。当然我们还留了一些重要的"尾巴"——测试覆盖率工具。在昨天的文章中提到，笔者将实际学习使用一些工具，并将整理相关的资料，当然我是不会爽约的，不过这些内容恐怕要等一段时间才能开始了。

    测试覆盖率系列中文章均为作者个人观点，如有问题或者建议请联系unique.wuchaodong@hotmail.com或直接留言。

    上一篇文章中，介绍了测试覆盖率的意义之类的东西。测试覆盖率可以帮助我们检查测试质量，检查测试用例的有效率。如果有兴趣的话，可以阅读测试覆盖率之二——测试覆盖率有什么用？

     关于测试覆盖率，我个人的感觉是说的多，用的少。最近在网络上看到一篇文章，讨论一个问题“测试需要100%的覆盖率吗？”被转载了很多次，有兴趣的同行可以找来看看。的确，一想到测试覆盖率，立马就有完美主义者跳出来说100%。100%的测试覆盖率有什么好处呢？
    1， 100%的覆盖率表示我们的测试覆盖到了所有语句，分支，条件
    2， 100%的覆盖率表示我们测试考虑的很完全，我们可以回去睡大觉了~~
测试仿佛在这里变得不那么可怖了，但是我们至少遗漏了两个重要的地方：怎么达到100%的测试覆盖率或者说是否能够达到100%的测试覆盖率，另外一个就是100%的测试覆盖率到底能告诉我们什么信息。
    首先来讲，我们是否可以达到100%的测试覆盖率？如果我们简单的将测试覆盖率理解为需求覆盖率，代码覆盖率，那么我想这是可以达到的，只要拥有足够的时间，我们的测试覆盖到每一个需求点，我们的测试覆盖到每一条语句，每一个条件，每一个分支，看起来的确没有问题。但是我们还要考虑另外一个问题，是否由我们未曾列入到需求分析中的需求呢，这种情况是存在的，如果我们计算需求覆盖率是根据Feature Spec来的（实际上如果我们需要计算的话，一般就是这样计算得来的），那么当我们有需求没有被写入Feature Spec并且我们也没有在测试中考虑相关的测试，那么我们实际的“需求覆盖率”就不是100%了。在实际开发过程中，是不可能在Feature Spec中将需求全部列出来的，所以我们得到的100%的需求覆盖率是存在水分的。
    另外，对于一个应用程序(除了一些极其简单的程序)来讲，要覆盖到所有的语句。条件，分支是极其困难的，甚至可以说是不可能的。笔者在经历的一个项目中花了一整天写一个模块的单元测试，当我忙完一天并运行了所有的用例之后，我发现我的代码覆盖率仅仅增加了2%，而且是从35%到37%，不要说100%，连80%我当时都觉得是奢望。
     对于第二个问题，100%的测试覆盖率能代表什么？我在上面讲到，100%的测试覆盖率表示覆盖到了所有的语句，分支和条件，但是这又说明什么呢？这是否说明了我们做到了完全测试一个软件呢？很抱歉，答案是否定的。给出下面这一段代码：

private int add（int a，int b）
{
   return a+b;
}

够简单的一段代码了吧，我们可以很轻松的达到100%的覆盖率，比如我们使用用例 add（3，4）就可以覆盖所有的语句，分支，条件（当然这里面是不存在分支和条件的，所以只需要覆盖语句就可以达到代码覆盖率100%了），但是聪明的你一定会发现我们的测试远远不够：如果输入的是add（2147483647，2），这个应用程序是会出现问题的，如果我们仅仅满足于100%的代码覆盖率，是不能保证我们的软件的质量的。
   关于代码覆盖率，由一个很有趣的现象：高覆盖率有时候比低覆盖率还“没用”。注意“没用”是打了引号的，我的意思是高覆盖率不能说明我们做了完全的测试，低覆盖率却可以说明我们测试远远不够，从这一点来讲，低覆盖率似乎更有意义。当然我不是在讲我们不去追求高覆盖率，我的意思是与其把A模块覆盖率从85%提高到90%，还不如把与其类似的B模块的覆盖率从30%提高到50%更有意义。绕一大圈说回来，在任何时候高覆盖率都比低覆盖率好，但是作为一个软件，我们要顾及软件整体的测试质量，我们还要估计成本，时间等等很多问题。
    上面说了不少，最后总结一下我的观点：
    1， 测试覆盖率100%是一个理想的情况，是很难达到的；
    2， 测试覆盖率100%不能说明我们做了完全的测试；
    3， 较低的测试覆盖率能说明我们的测试还不够，反之是不成立的，参考第二条；
    4， 同一模块高覆盖率相对于低覆盖率能说明我们做了更多的测试；
    5， 测试覆盖率达到多少要考虑到软件整体的覆盖率情况，以及项目成本，包括人力，时间等等。

    个人观点，仅供参考。如果问题或意见，请联系 unique.wuchaodong@hotmail.com 或直接留言~
    关于测试覆盖率100%的问题的讨论还会继续下去，如果必要的话，笔者将在本系列文章的后期继续总结，根据计划，在下一篇文章中(测试覆盖率之四——测试覆盖率工具)我将介绍自己使用过的相关工具，以及我未使用但是可以从网上找到相关资料的工具，帮助大家总结一下，以备查看。

在上一篇文章我提到的是关于测试覆盖率100%有关的话题，算是“跟风”谈论了最近关于测试覆盖率最流行的100%问题吧。关于上篇文章的详细内容，参见测试覆盖率之三——测试覆盖率100%相关的话题 

在上一篇文章中，和大家约定下一篇介绍关于测试覆盖率工具相关的东西，可是这两天一直出差，无暇顾及，希望关注我的朋友不要介意~ _ ~ 废话不说了，直接切入正题。由于本人对于测试覆盖率工具的使用仅限于.NET相关的，所以对于其他语言相关的测试覆盖率工具没有经验，因此也少了发言权，这片文章就只能算作对于各种工具的一种简单的介绍罢了，主要内容都来自于google百度，笔者做简单的整理之后发表出来，希望对大家有所帮助。

 

》》》Javascrīpt测试覆盖率工具

JSCoverage是一个用于度量Javascrīpt程序的代码覆盖率的工具。能显示哪些行被执行过了，哪些行尚未执行，这些信息对于测试覆盖率的分析和测试质量的衡量都很有用。JSCoverage通过度量Web页面使用的Javascrīpt代码，收集被Web浏览器执行的Javascrīpt代码信息来达到测试覆盖率统计的功能。JSCoverage支持IE6、IE7、Firefox2、Firefox3、Opera、Safari等流行的浏览器、支持Windows平台和Linux平台。JSCoverage是开源软件，官方网站：http://siliconforks.com/jscoverage/

 

》》》Java测试覆盖率工具

EMMA，开源工具，支持Java 1.2或更高版本的JVM，不依赖于任何第三方类库。EMMA支持maven，ant，报表格式简单。官方网站 http://emma.sourceforge.net/

Coverlipse，一个Eclipse的Code coverage插件。

Cobertura 是一种开源工具，它通过检测基本的代码，并观察在测试包运行时执行了哪些代码和没有执行哪些代码，来测量测试覆盖率。除了找出未测试到的代码并发现 bug 外，Cobertura 还可以通过标记无用的、执行不到的代码来优化代码，还可以提供 API 实际操作的内部信息。

Clover

NoUnit

 

 

》》》.NET测试覆盖率工具

Clover.NET http://www.cenqua.com/clover.net/

Visual Studio的代码覆盖率统计工具

NCover官方网站：http://ncover.org/

PartCover

 

》》》C/C++测试覆盖率工具

Bullseye Coverage 是Bullseye 公司提供的一款C/C++代码覆盖率测试工具除了支持各种Unix 下的编译器之外，在Windows 下支持VC、Borland C++、Gnu C++、Inter C++。提供的代码覆盖率是分支覆盖率而不是一般代码覆盖率，我个人认为分支覆盖率比代码覆盖率更好。Bullseye Coverage 可以从http://www.bullseye.com/上获取

 

》》》Ruby代码覆盖率工具

rcov是一个用于诊断Ruby代码覆盖率的工具，它最主要的用途就是用于确定单元测试是否覆盖到了所有代码，rcov使用一个经过优化的C运行时，因此性能相当惊人，同时它还提供多种格式的输出

 

》》》其他

AutomatedQA公司的AQTime。AQtime运行在windows平台下，它支持.net应用和非.net应用,但不支持JAVA应用。 AQtime除了包含代码覆盖率监测以外，还包括了性能监视等功能。AQTime能够收集服务端C#和VB.net代码的覆盖率，但是不能收集客户端scrīpt脚本的覆盖率。

DevPartner Studio的Web scrīpt Coverage工具。该工具主要是收集Web客户端scrīpt脚本覆盖率的。 它使用起来也很简单，只要启动此工具，然后在浏览器中输入网址，收集工作就开始了。在形成的测试报告中清楚地反映了每个函数的实行情况，给出了覆盖率数据，同时对于执行到的脚本和未执行到的脚本用不同的颜色表示，十分明了。该工具唯一的缺陷就是不能收集服务端脚本的覆盖率，同时存在中文字符无法正确识别的问题。

 

关于测试覆盖率工具，有很多内容，上面提到的只是我平时收集到的一些知识，很大一部分并没有实际验证，因此对于可能出现的纰漏和错误，还望读者原谅。关于测试覆盖率工具，笔者很有兴趣继续学习使用，并会在后期的学习中总结并发表在该系列文章中。在本系列的下一篇文章(测试覆盖率之五——提高测试覆盖率)中，笔者将继续探讨有关提高测试覆盖率的问题。

 

对于笔者及文章的任何问题，可以联系unique.wuchaodong@hotmail.com,或直接留言。

     在上一篇文章里面我们介绍了测试覆盖率的分类，举例揭示了需求覆盖率，语句覆盖率，分支覆盖率很条件覆盖率这些问题，在这篇文章里面，则主要介绍为什么要千方百计来找“测试覆盖率”。(关于上一篇文章，参见测试覆盖率之一——测试覆盖率分类)
    关于测试覆盖率讲的最多的地方应该实在测试停止标准里面。在测试停止标准里面经常出现这样的语句“测试覆盖率达到或超过95%”之类的概念。其实，如果你看了我前一篇文章中提到的测试覆盖率分类的话，就知道这是一个不准确的描述。关于更准确的描述，我认为应该是“性能测试需求覆盖率达到100%，功能需求测试覆盖率达到100%，语句覆盖率达到85%”这样的句子。“测试覆盖率”本来就包含了很多子部分，所以提测试覆盖率是不明智的一种做法。而我所说的语句覆盖率85%相对于性能测试需求覆盖率这个数据来讲似乎更难获得准确数值，不过现在已经有了很多工具用于测试“语句覆盖率”，而不用我们自己去计算已执行的测试用例覆盖到了数万或者更多代码中百分之多少，也有一些工具可以帮助我们得到代码覆盖率中“分支覆盖率”等其它数据。关于覆盖率检测工具，我将在本系列的后续文章中给予介绍。
    测试覆盖率是测试结束标准中的一部分，这显然不是我们今天讨论的重点——测试覆盖率有什么用？直观上讲，我们可以这样理解：
    -> 性能测试覆盖率如果没达到100%，表示我们有些性能测试点没有覆盖到，这在一个对于性能有所要求系统显然是不可取的，这表示我们应该增加用例来覆盖到所需要的性能测试点。
    -> 重要模块的语句覆盖率和条件覆盖率很低，表示我们测试用例过少，我们应当增加用例；如果我们已经写了很多用例（相对于代码行数来讲），但是这两项数据还是很低，那我们得检查一下我们的用例了，是否有重复的用例？是否应该重新设计用例结构？
    对于测试覆盖率，我们有这样一个简单的算式，如果A模块的条件覆盖率为80%，B模块也为80%，C模块也为80%，那么我们的总覆盖率则是51.2%，而不是我们想当然的80%。至于为什么这样，我就不解释了。因此在我们审查覆盖率报告时候，我们关注的是覆盖率低的模块，我们要检查为什么低，我们要思考怎么提高，对于覆盖率低的地方，是不是有一个等价类被我们忽略了？
    测试覆盖率的意义在瀑布式的开发模式里面可能显得没那么重要，但是如果在螺旋式开发模式中，如果我们没有控制好我们上一个迭代中的测试覆盖率，当一个版本一个版本累加下来后，你就很难确定我们哪些模块在开发过程中没有给予足够的测试；在近些年兴起的持续集成浪潮中，由于要求短迭代（有人建议3-5天一个迭代），如果没有很好的测试覆盖率保证，很难在这么快的代码变迁中保证测试的质量。在持续集成工作中，代码提交频繁，我们可以通过测试覆盖率来了快速对应新写的，没有对应测试的代码。
    总之，测试覆盖率可以提供给我们两个方面的信息：测试覆盖率低的模块 和 重要模块的测试覆盖率。这些数据可以帮助我们快速定位需要更多测试的模块，可以帮助我们了解重要模块的测试情况，以此来衡量我们测试用例的质量乃至测试的质量。
    个人观点，仅供参考~~（如有问题请联系unique.wuchaodong@hotmail.com）在下一篇文章（测试覆盖率之三——测试覆盖率100%相关的问题）中，我将介绍关于测试覆盖率应该达到的数据，是不是需要100%呢？

   关于覆盖率，网络上最常见的两个词应该是“测试覆盖率”（Test Coverage）和”代码覆盖率“（Code Coverage）。今天就来探探这两个东西。
   在测试里面，一般会将测试覆盖率分为两个部分，即”需求覆盖率“和”代码覆盖率“。可以看到，代码覆盖率其实是测试覆盖率的一部分而已。其中，最常讨论和关心的是”代码覆盖率“，代码覆盖率又分为程序语句和代码行覆盖，分支覆盖和条件覆盖。对于这些概念，我们逐个解释。
   需求覆盖率：如果需求已经定义好，这个时侯我们就需要考虑需求覆盖率了。这个时候需要注意的是，这里的需求不仅仅是指功能需求，还要包括性能需求。衡量需求覆盖率的最直观的方式是我们有多少功能点，我们有多少性能点要求，这些将作为分母；我们写了多少测试用例，覆盖了多少模块，多少功能点，我们的性能测试用例考虑了待测程序多少性能点，这些作为分子。
   代码覆盖率：为了更加全面的覆盖，我们可能还需要测试程序的流程，我们可能会考虑到一个函数的数据的输入与输出，甚至是每一行代码的执行情况，代码的每一条逻辑和分支，这个时候我们的测试执行情况就以代码覆盖率来衡量，这也是我们常在单元测试中念叨的覆盖率覆盖率的问题。
   语句覆盖率：换个名字叫做代码行覆盖率，这就是监视每行代码是否在用例（当然之所有的）中是否被执行到，准确点说是我们的用例里面大概执行了百分之多少的语句/代码行数。需要注意的是，即使所有的语句都被执行到，也不一定执行到了所有的路径。比如有五条语句：ABCDE，如果我们执行了用例覆盖了ABCDE，另外一个用例这个时候我们覆盖了所有语句，但是可能还存在一个路径（如ABC）没有执行,例如：
public verifyToken(string yourname, string yourtitle)
{
A   output（”Hello, my dear friends“）;
B   if(yourname == "uniquestudiowcd")
   {
C      output("Hello, Aaron");
   }
D   if(yourtitle == "tester")
   {
E     output("Hello, my dear tester");
   }
}
这个时候我们输入参数”uniquestudiowcd“和”tester“覆盖到了所有的语句，但是我们漏掉了一个路径：即输入参数”uniquestudiowcd“和”coder“。
   分支覆盖率：我们也给它换个名字即”路径覆盖率“，尽管并不完全对。在上面的例子中，如果我们仅考虑了第一个用例（即输入参数”uniquestudiowcd“和”tester“），我们的语句覆盖率为100%，带式路径覆盖率可就低了，因为它存在ABD,ABCD,ABCDE,ABDE等等很多路径。
   条件覆盖率：这也就是为什么不能说”分支覆盖“不同于”路径覆盖“的原因所在。如果我们在一个IF语句中加入了判断组合，那就要考虑更多的问题了，因为主要出现在条件语句中，所以我们称之为”条件覆盖“。我们更改上述示例代码：
public verifyToken(string yourname, string yourtitle，string gendar)
{
A   output（”Hello, my dear friends“）;
B   if(yourname == "uniquestudiowcd" && gendar == ”man“)
   {
C      output("Hello, Aaron");
   }
D   if(yourtitle == "tester")
   {
E     output("Hello, my dear tester");
   }
}
很明显即使我们输入参数”uniquestudiowcd“”tester“，”woman“和”uniquestudiowcd“”tester“”man“，这两个用例的路径走的分支是一样的，但是条件覆盖不一样，实际上两者的”路径“也是不一样的。
    上面主要介绍的测试覆盖率的一些基本知识，在关于测试覆盖率的第二篇文章《测试覆盖率之二——测试覆盖率有什么用》中，我将介绍归纳一下测试覆盖率的用处，或者说测试覆盖率的意义。
     个人观点，仅供参考~ 如有问题请联系unique.wuchaodong@hotmail.com

三、测试数据的设计

每一个测试思路最终都要转化成具体的数据才能来执行。关于测试数据设计的方法也不外乎那几种，就不再赘述了。此处单就一些经常易犯的错误，提出一些注意点，作为用例数据设计时的参考：

1、尽量避免可能出现歧义测试结果的数据：即你设计的数据必须能唯一正确地反映出你所希望测试的结果。比如一组测试数据，有可能得到结果A或结果B，此时单用此数据来测试预期结果为A的用例，那明显就产生了歧义。

2、对于不便具体列示的数据，则必须详细描述其各项特性：有时我们在设计用例时为节约时间，不一定要到具体的一个数值，这也是允许的，但前提是你必须要详细描述清楚你要测试的数据特性。比如数据库字段限长20，要测试超长数据时，可以描述为：尝试输入长度为21位的半角英文字符；尝试输入长度为19位的半角英文字符，然后切换到中文全角再输入一位全角字符等。千万不能写成：尝试输入超长字符，因为这只能是测试方案，作为方案是可以这样写，但到用例阶段，必须要是具体的、明确的、可操作的。

3、测试数据的设计必须有明确目的性：即测试数据是从测试方案衍生而来的。如上例测试方案是测超长字符输入控制，所以测试数据就要根据具体字段长度来录入超长数据，如果一味录入长15位、长16位的数据那就没意义了。好的测试数据是可以同时针对多个测试方案的，此时可以在用例边注明一下该数据的测试目的，因为随着时间推移，对着具体的数据你也许会忘了它到底是测什么的，而这对你最后总结测试，查验测试覆盖率是非常不利的，所以随时记下你的思路想法吧，好记性不如烂笔头。

4、测试数据可省略描述：测试数据描述以能让人看懂为准则。所以写用例时当碰到连续几个用例，仅某几个关键数据值改动，其余均是一样的情况下，不必每个用例都要重复描述所有数据，可以在第一个用例描述完整之后，其余用例中仅列示不同的数据，并标明其余数据同上第X个用例，即可。这样测试时仍能复原测试数据，且该用例的测试目的一眼就明，增加了用例的清晰性。

至些，我根据测试用例设计的顺序，从测试数据的切面设计（即测试项划分），到详细测试用例设计，再到测试数据设计三个层面，逐一介绍了如何来提高测试用例的覆盖度。因为具体项目中的具体情况太多，以上叙述的内容也只能是管窥蠡测。至于其中的疏漏错误之处应也难免，只希望各位阅后能打开思路，从自己多年的测试经验中多总结、提炼出一些想法思路，进一步补充完善这个文档，使大家的测试用例设计能力都能进一步提升。

二、详细用例的设计

划分好了测试项，接着就是针对各个测试项，考虑具体的测试用例了。根据测试项的特点，测试用例的设计角度也有所不同。下面我们就来看看通常的功能点测试用例，该从哪些角度出发来进行设计：

1、功能切面表面用例设计

（1）、具体功能测试

根据需求分析设计，按页面提供的各个功能项，采用黑盒测试的各种方法，设计用例。比如页面提供了增、删、改、查功能，那么这四个功能是否正确实现就是我要验证的。这是最简单、最基本，同时也是必须的测试用例，通常我们的编码人员自测也就是做到这个程度。^_^

（2）、组合操作的测试

这是从上一角度扩展出来的，相对而言也是编码人员不会去测试的，所以需要测试人员多作考虑。

所谓组合操作测试，也就是选择某几个操作项，按一定的顺序进行操作，验证系统不会出现意外错误。当然要将所有功能项排列组合一遍来测试不仅不必要，也是不可能的。所以具体要将哪些功能项进行结合，要按怎样的步骤来操作，还是需要测试人员根据实际情况来作设计（所以说在IT业人才就是一切呀，呵呵：）。

一般来说我们会考虑功能项之间的数据是否会存在关联，若有就需要考虑这种组合了。常见的如查询功能，需要将各条件逐一累加进行测试；增完的数据能否改，改完能否删，删完能否再增，这之间能否查询到正确结果；按钮的连续多次点击会否出现异常；有严格前后顺序要求的几个操作，尝试颠倒顺序去操作，系统能否控制等等。

不仅在某功能内部，扩展到有关联的多个功能项之间，同样有组合操作测试的存在。如申报完了能才反馈；如申报成功或失败后再尝试申报等。当然对于这类用例既可以写到某个功能切面中，也可以单独写到完整业务流程的切面中，这就取决于可能涉及用例的数量了，若关系比较复杂，当然是单独写比较好；若也就是三五个用例数，那就直接在某个功能的用例中补充好了。

 

（3）、GUI界面的测试

这类测试是测试人员的强项，具体测试项目如限长、非法输入等等，就不必赘述了。要提醒的是在测试时，一定要从实际使用者的操作习惯出发。要知道界面原型所能确定的也只是页面的摆放显示，而实际操作时的控制实现仍是编码人员自行实现的，即使有编码指南，其所及范围也是十分有限。而许多编码人员在用户操作方便性上的考虑往往差强人意。所以测试人员就必须要把好这一关。

（4）、数据初始化情况测试

不该为空的数据是否有校验；该有默认值的数据默认值是否正确；引用其它功能生成的数据，是否会实时刷新；页面关闭或系统重启后，数据的初始化设置等都是这类用例。

（5）、业务需求实现是否正确

这类问题往往是由于我们的需求说明欠详细，而编码人员的需求了解程度又较低造成。作为测试人员自然要对需求进行深刻研究，来对软件实现进行把关。这里常见的一些关注点有：

u       数据的长度、类型控制是否合理（比如控制纳税人识别号只能为数字，但实际业务中是会有字母出现的）；

u       业务逻辑控制是否合理（比如某数据项不提供修改，但实际业务中该数据项经常会需要改动）；

u       提供的实现方式是否合理（比如只在某一页面提供某数据的获取功能，但根据业务划分有些人员不能操作此页面，却必须要能看到该数据）；

u       所做的数据控制是否合理（比如必须在A功能中新增数据，然后才能在B功能中操作，但实际业务中有可能会出现相反操作）；

u       所做的数据控制是否完整（如授权的方式有普通按月、有买断、有按数量控制，那么当同一企业尝试同时存在以上几种授权方式时，系统是否能有必要的控制）；

u       还有其它一些操作细节上的满足（如业务上需要批量操作的数据有否提供批量操作功能、导入失败的结果文件是否能修改后直接再导入等）。

对于不满足的需求，经开发组长、需求经理等确认不作修改的，就要作为软件的缺限或限制在测试报告中进行说明民。

2、功能切面隐含测试项用例设计：

（1）、数据完整性的测试

当某数据被其它功能引用；或当前功能要引用其它来源的数据，就会涉及到数据完整性的测试。最常见的如被引用的数据删除了，或关键字被修改了，引用的数据会否出错；两个途径进入的数据会否冲突或重复；此外还有因为相关的几个功能由不同人员编码，从而导致彼此的控制不一致，如A功能进入的数据在可允许的极端情况下，到B功能中引用会否异常（最常见如用户名录入时允许长度10，但引用到某个单子填写时允许长度是8，此时就会异常了）。

（2）、后台的特殊处理

是指某功能除了表面所见以外的程序处理。比如订单录入，表面所见的就是订单的保存，但后台还会有重复数据的判断、非法数据的处理、业务逻辑上冲突情况的处理以及其它种种根据需求设计所特有的处理。又比如备份功能，在备份前可能有数据的清空、备份目录的清空、备份目标是否存在的校验、备份文件重复时的处理等等。类似这些在分析设计中就未必会写全了，还是要测试人员多花心思去思考挖掘。

（3）、功能业务之间的关联与转换

相关联的几个功能之间数据的传递，会否产生影响。比如新增录入的某种特殊字符，要查询时会引起查询SQL语句异常；又如某下载文件名中存在中文等字符，下载时由于编码问题导致乱码的出现；再有报表填写时到小数点后四位，生成报文时会不会被忽略成两位了等等。象这种问题，通常只能是在每个功能设计用例时，尽量保证用例中的数据能涉及到允许范围的各种情况，即充分运用等价类划分+边界值的方法设计出各种“稀奇古怪”的数据，并需验证这些数据从头流到尾，都还是能保持其正确性，而不仅仅是在当前功能中正确。

（4）、从设计实现发掘测试点

这个就是我们测试中最难捉的BUG了，它往往是由编码人员自己在编码时创造出来的，连设计人员都不会知道。

比如内部管理系统中，正常的产品，其类别通常是2位数字；如果是模块，其类别就以产品代码来取代。这时如何来判断该产品是模块呢？最保险的当然是校验其产品类别字段的值能否在产品表中找到；也有比较简单的方法就是直接判断类别代码大于2位还是小于等于2位。此时若能确切知道采用的是哪种实现方法，就可以直接找到其漏洞所在。比如采用后一种方法，当产品类别长度变化时，明显系统会出错。那么即使确认该实现方式不改，测试人员也应将其作为限制写入测试报告，。让大家知道这个产品类别长度是不能随意变化的。

而让人郁闷的是，类似这样的实现，有太多的编码人员都是随性处理的，它们细而隐蔽，在系统数据正常情况下根本不会被发现；而在漫漫的软件使用道路中，由于需求变更等原因对原有一些设计做维护变化，这种问题就会突然暴发出来让人措不及防。所以要杜绝这类漏洞，除了测试人员要做土拨鼠，不停地对软件各功能的实现细节进行挖掘外，也要多给编码人员灌输完美实现的理念，多用复杂但抗压性高的代码，来替代简单但依赖性强的代码。

（5）、并发操作时的测试

即两个或多个用户同时操作同一功能时，会否引起数据的混乱。通常在C/S结构下，如果有同时操作的可能，是需要作此测试的；而在B/S结构下由于其特殊性，此问题通常难以解决。除非就是某用户一旦使用过某功能后，在一定时间内锁定不允许再用，但这也会带来实际应用中的不便，所以除非是特别核心的数据，一般我们也不会去做此控制，当然对于可能出现的并发冲突也就作为系统的限制进行遗留了。

3、特定切面用例设计

所谓特定切面，其实就是从另一个角度切割出来的用例面，所以具体的用例撰写方式其实与功能切面是一致的。

4、隐含切面用例设计

隐含切面分以下几种情况：

（1）、无界面的后台功能

对这类测试项，需要通过参数设置、代码调用等方式来实现测试，但具体的测试设计其实与普通功能测试并无二致。这里要注意，因为测试时往往前台、后台是分开来分别进行的，而实际运行时两者很可能是交集的，所以测试时要多注意后台功能的执行与前台的一些功能执行会否产生冲突？比如后台有个文件搬运的服务，那有没有可能在前台文件生成过程中，后台执行文件搬运了？若有可能就要注意会否出现问题了。

（2）、与业务流相关的测试

这类测试用例的设计，就要从完整业务角度来设计数据了。从理论上来讲，应该要将各个功能可能出现的各种数据排列组合到一起，按业务流程逐一进行测试。但实际上我们不可能去做全覆盖。所以设计这类用例时，最好有一张草稿，将所有相关功能按业务流程逐一列示，然后再将每个功能可能出现的特定数据一一标上，最后将图中最可能出现的、最可能出错的、最核心的数据取出来，分别组合成一个个完整的业务数据用例，来进行测试。这样就可以按清晰的思路，找出最实用、最有效的测试数据。

（3）、其它测试类型

这一类的测试通常都有其特定的方法。如要测可靠性就准备大量数据不停地执行；要测安全性就考虑数据的加密、数据的传输、数据的破坏；恢复性一般从网络、电源方面着手；配置安装则根据系统可支持的配置，搭建相应环境进行功能验证，此处的验证也要掌握技巧，即要多测试那些涉及到：数据库读写、磁盘文件读写、文件上传下载、文件加解密、数据统计、图表展现、打印等方面的功能。

一、测试用例的切面设计

所谓测试切面设计，其实就是测试用例大项的划分。测试用例划分的经典方法是瀑布模型，也就是从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。但仅仅如此是不够的，我们还要从更多的角度切入系统，从不同的角度把系统切分成一块一块的，来进行测试，从而确保测试大项的完整性。

1、功能点切面

这是最常见的切面，通常我们认为页面上的一个按钮就是一个功能点。然后我们可以根据功能的复杂程度，按每个功能；或一个功能点分多页；或多个功能点合成一页来进行用例的撰写。

2、特定切面

除此以外，还有一种特定切面的划分方法，也是用例撰写时经常会用到的。所谓的特定切面，就是忽略掉表面上的功能点，而关注测试对象的某一个面。比如我们的内部管理系统提供了销售录入导入、注册录入导入等功能，从菜单划分上对应了七八个功能点。但这些功能处理后台有个共同的处理项就是授权记录的生成，这时我们就可以把“授权记录生成”单独拿出来做一个测试项，而在其它测试项中涉及这一部分的用例就不必再一一撰写。此外象一些界面共通的操作用例单独写成一页，也是一种特定切面。所以如果说将用例按功能点划分是一种纵向划分法，那么特定切面就是从横向的角度分析所得到的切面。在普通功能点划分上再根据实际情况设计特定切面，可以使我们的用例阅读性、理解性、操作性更强。

3、隐含切面

这类用例是最容易被忽略的。它往往不是明显的某个功能项，可能是功能项后台的隐含处理，也可能是多个功能项之间的关联处理，甚至可能是在某种特定情形下的处理。这都需要测试人员通过对软件的学习了解，来进行挖掘。

（1）、后台功能

常见的如一些定时自动启动的服务；以及某种特定情况下自动执行的操作等。它们在界面上往往是不体现的，但许多在需求设计中还是会提到，也有一些比较细小的功能可能会被忽略，就需要测试人员根据对项目的了解程度来进行挖掘。所以说一个熟悉项目的和一个不熟悉的测试人员，写出来的用例就完全是两个层次的。

 

（2）、完整业务流程的测试

我们都知道测试用例的设计是从点、线、面三个层次去考虑的。完整的一个功能项是线，其中的某个按钮是点，多个相关功能结合成完整业务流就是面。从实际来看这类用例往往被我们忽略。

事实上目前公司的软件本来都是业务型应用软件，将各种功能从业务流中切割出来单独写用例，肯定也会有涉及到整体流程的情况。若不加以区分，将细节与全局搅在一起，不仅思路混乱，也容易考虑不周。因此在系统测试阶段，建议用例设计要有分有合，针对具体功能的就只围着这个功能转：而在业务流程测试项中，再完全从整体的业务流角度出发去考虑用例，这样不仅不容易产生疏漏，用例阅读与执行也更清楚。

（3）、某种特定情况下的系统运行

这类用例的设计往往与系统实际业务情况密不可分。比如财务软件，通常需要在月尾一天、月头一天、年尾一天、年头一天，对所有相关功能中的日期处理进行测试；又比如WIN 2000环境开发测试的系统，要测试在98、XP、2003等操作系统下是否能运行自如；再有如存在大量动态图片视频等的网页，在普通网速下的展现速度等等。总之就是要尽可能从实际应用的角度出发考虑，来进行测试补充。

（4）、其它相关系统

即指在当前项目中直接使用的其它成果，包括公司自有的系统模块、组件、函数；以及购买或免费得到的一些功能组件。对这些内容需要预先与开发组长等讨论清楚，是否需要测试。若时间紧张或其它原因决定不测的，应在测试计划中说明。若需要测试的，则具体可根据实际情况来设计，可以是通过系统某个功能的测试来涉及，此时就不需要单独划分测试项；若相对比较独立的，也可以通过单独的测试项来对其专门进行测试。

（5）、除功能测试外的其它测试类型

包括可靠性、安全性、恢复性、配置安装测试等等，这些测试类型都是一个单独的测试项。

所谓好的开始是成功的一半，保证测试项划分的完整、合理、正确，会直接影响到本次测试的成效。通常建议该阶段工作要花1-2天的时间来考虑，并要在测试过程中随着对软件的深入了解，不断进行调整补充。可千万不要认为把分析设计中的功能模型图搬搬过来就可以了。