软件测试系列之单元测试（1 基本理论）

软件测试系列之单元测试（1 基本理论）

现象
nbsp;投入太多的精力，找 bug，而新的代码仍然会出现类似 bug；
nbsp;写完代码，心里没底，是否有大量 bug 等待自己；
nbsp;新修改的代码不知道是否影响其他部分代码；
nbsp;由于牵扯太多，导致不敢进行修改代码；
…

一、软件测试基本理论
nbsp;目的：对软件测试有个整体认识
nbsp;软件测试
nbsp;软件测试分类
nbsp;软件开发全过程检测及测试自动化
nbsp;V模型与X模型
nbsp;TDD（ Test-Driven Development）
什么是软件测试
 在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。
 软件测试的概念：
     软件测试是为了发现错误而执行程序的过程。
 或者说，软件测试是根据软件开发各个阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期结果），并利用这些测试用例去执行程序，以发现程序错误的过程。

测试的目的
nbsp;测试是程序的执行过程，目的在于发现错误；
nbsp;一个好的测试用例在于能发现至今未发现的错误；
nbsp;一个成功的测试是发现了至今未发现的错误的测试
nbsp;也可以这样说，测试的目标是以较少的用例、时间和人力找出软件中潜在的各种错误和缺陷，以确保系统的质量
nbsp;一个被人忽略的软件测试目的是：测试可以帮助发现当前开发工作所采用的软件过程（也是一个“软件”）的缺陷，以便进行改进。
nbsp;首先，测试并不仅仅是为了要找出错误。分析错误产生的原因和错误在开发的哪一个阶段产生，具有非常重要的意义。
nbsp;通过分析错误产生于哪一个开发阶段、而又在哪一个阶段被发现，我们可以判断从错误的产生到错误的发现，跨越了多少个开发阶段。
nbsp;软件开发的一条重要原则是尽早发现与修正错误。
nbsp;正确分析与利用测试的结果，我们可以非常有效地进行软件过程改进
软件测试原则 2-1
nbsp;完全测试程序是不可能的
       －输入量太大
        －输出结果太多
        －软件实现途径太多
        －软件说明书没有客观标准。从不同角度看，软件缺陷的标准不同。
软件测试原则 2-2
nbsp; 软件测试是有风险的行为
nbsp; 测试无法显示潜伏的软件缺陷
nbsp;找到的软件缺陷越多，就说明软件缺陷越多
nbsp; 并非所有软件缺陷都能修复
nbsp;软件测试一项讲究条理的技术专业
软件测试分类
从是否需要执行被测软件的角度，可分为：
－静态测试
－动态测试

从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为 ：
－白盒测试
－黑盒测试

软件测试方法－静态和动态
nbsp;静态检查
nbsp;确保系统按照组织的标准和过程运行，主要依赖于评审和非运行的手段来检查。通常包括需求评审、设计评审、代码走查和代码检查。
nbsp;动态检查
nbsp;在生命周期中进行测试（运行）。通常包括单元测试、集成测试、系统测试、用户的验收测试。

静态测试
nbsp;审查 (Inspection)
      －软件的一种基本测试方法，它以一系列典型问题为依据进行检测。
nbsp;走查 (Walkthrough)
       －一对一的审查，比审查更加仔细。
nbsp;回顾(Review)
        －以发现软件中存在的错误和缺陷为目的的一种软件测试方法，它是在软件证实执行之前完成。

静态和动态测试进行结构和功能测试
测试技术
黑盒测试

 黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

      “黑盒”测试着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
       它不仅应用于开发阶段的测试，更重要的是在产品测试阶段及维护阶段必不可少。主要用于软件确认测试。
    黑盒测试方法主要有：
nbsp; 等价类划分
nbsp;   边值分析
nbsp; 因果图
nbsp; 错误推测
    
白盒测试
　  白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。
  使用被测单元内部如何工作的信息，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。
白盒测试的主要方法
nbsp;逻辑驱动测试
nbsp;基本路径测试
      
     主要用于软件验证。
     使用程序设计的控制结构导出测试用例。

 逻辑驱动测试：
 主要是测试覆盖率，以程序内在逻辑结构为基础的测试。包括以下6种类型：
nbsp;语句覆盖
nbsp;判断覆盖
nbsp;条件覆盖
nbsp;判定-条件覆盖
nbsp;条件组合覆盖
nbsp;路径测试
白盒测试的主要目的
nbsp;保证一个模块中的所有独立路径至少被执行一次；
nbsp;对所有的逻辑值均需要测试真、假两个分支；
nbsp;在上下边界及可操作范围内运行所有循环；
nbsp;检查内部数据结构以确保其有效性。
概念

nbsp;语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次；
nbsp;判定覆盖（也称为分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次；
nbsp;条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次；
nbsp;判定-条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的所有可能取值至少执行一次，并且每个可能的判断结果也至少执行一次，换句话说，即是要求各个判断的所有可能的条件取值组合至少执行一次；
nbsp;条件组合测试：设计足够多的测试用例，运行所测程序，使程序中每个判断的所有可能的条件取值组合至少执行一次；
nbsp;路径测试：设计足够多的测试用例，运行所测程序，要覆盖程序中所有可能的路径。
软件开发全过程检测及测试自动化
nbsp;单元测试（unit test ）
  由编程的开发人员自行计划与完成的，针对单个或相关联的一组程序单元的测试。 
nbsp;组装测试（inegration test ）
  计划于设计阶段，由开发人员与测试人员合作完成的，针对结合起来的不同单元以及它们的接口的测试。
nbsp;系统测试（system test ）：（可认为包括“可用性与图形用户界面测试”）
  测试整个系统，以证实它满足要求所规定的功能、质量和性能等方面的特性。 
nbsp;回归测试（regression test ）：
  用于验证改变了的系统或其组件仍然保持应有的特性。 
nbsp;验收测试（acceptance test ）：
  测试整个系统，以保证其达到可以交付使用的状态。

V模型
V模型
nbsp;单元测试、集成测试、系统测试、验收测试。是“从小到大”、“由内至外”、“循序渐进”的测试过程，体现了“分而治之”的思想。
nbsp;单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。
nbsp;集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既要验证“设计”又要验证“需求”。
V模型
nbsp;系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。
nbsp;验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。

测试内容
nbsp;测试内容一般包含
nbsp;接口与路径测试。
nbsp;功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试…
测试阶段对应表
接口与路径测试 3-1
nbsp;接口测试：数据一般通过接口输入和输出，接口测试一般是白盒测试的第一步。
―  输入参数有“典型值”、“边界值”、“异常值”
―  输出包括函数的返回值和输出参数。
―  实际输出与期望的输出不一致，那么说明程序有错误。
nbsp;一个函数体内的语句可能只有十几条，但逻辑路径可能有成千上万条。所以应该根据经验选择关键的路径测试。
接口与路径测试 3-2
nbsp;路径测试的检查表
nbsp;－数据类型、变量值、逻辑判断、循环、内存管理、文件I/O、错误处理 
nbsp;预防一些重要的路径没有被测试的措施有：
― 观察是否有程序语句从来没有被执行过。
― 要特别留意函数体内的错误处理程序块。

功能测试 3-3
nbsp;功能测试用例的参考模板
性能测试 3-1
nbsp;性能测试即测试软件处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考。
nbsp;绝对值考虑：如数据送输速率是每秒多少比特。 “相对值”考虑：如某个软件比另一个软件快多少倍。
nbsp;性能测试中考虑运行环境的影响：例如 络环境、计算机主频，总线结构和外部设备都可能影响软件的运行速度。
性能测试  3-2
nbsp;性能测试的一些注意事项：
― 应当编写一段程序用于计算时间以及相关数据。
― 应当测试软件在标准配置和最低配置下的性能。
― 应当关闭那些消耗内存、占用CPU的其它应用软件（如杀毒软件）。
― 应当分档记录。例如传输文件的容量从100K到1M可以分成若干等级。
― 同一种输入情况在不同的时间可能得到不同的性能数据，可以取其平均值。

性能测试 3-3
nbsp;性能测试用例的参考模板
压力测试  2-1
nbsp;压力测试也叫负荷测试，即获取系统能正常运行的极限状态。
nbsp;压力测试的主要任务是：构造正确的输入，使劲折腾系统却让它刚好不瘫痪。
nbsp;压力测试的一个变种是敏感测试。在某种情况下，微小的输入变动会导致系统的表现（如性能）发生急剧的变化。
压力测试  2-2
nbsp;压力测试用例的参考模板

其他测试内容
nbsp;健壮性测试
nbsp;用户界面测试
nbsp;信息安全测试
nbsp;可靠性测试
nbsp;安装和反安装测试

测试常见问题 2-1
nbsp;问题1：有了“黑盒”测试为什么还要“白盒”测试br>nbsp;问题2：由于单元测试要写测试驱动程序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢
nbsp;问题3：如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗成测试是否多此一举br>测试常见问题 2-2
nbsp;问题4：在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试
nbsp;问题5：既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试br>nbsp;问题6：能否将系统测试和验收测试“合二为一”
总结 2-1
nbsp;测试可以将测试描述为一个运行程序以发现错误的过程。
nbsp;软件测试的准则:不完全测试、风险测试、无法显示潜伏错误、发现错误成线性增长、缺陷不能完全修复、测试有条理规程
nbsp;测试的方法:黑盒/白盒、静态/动态
nbsp;软件测试的各个阶段：单元测试、集成测试、系统测试、验收测试

总结 2-2
nbsp;测试的内容包括：接口/路径测试、功能测试、性能测试、压力测试、可靠性测试、安全性测试、用户界面测试、安装/反安装测试
X模型
测试驱动开发
nbsp;TDD, Test-Driven Development
nbsp;测试驱动开发以测试作为开发过程的中心，它要求在编写任何代码之前，首先编写用于定义产品代码行为的测试，而编写的产品代码又以使测试通过为目标。测试驱动开发要求测试可以完全自动地运行，在代码进行重构前必须运行测试。
TDD基本做法
nbsp;  1. 写一个测试程序。
nbsp;  2. 让程序编译通过。
nbsp;  3. 运行测试程序，发现不能运行。
nbsp;  4. 让测试程序可以运行。
nbsp;  5. 消除重复设计，优化设计结构。

测试产品说明书
nbsp;对于产品说明书的制定是个很重要的设计阶段，产品说明书的质量会直接影响到整个产品开发。
nbsp;测试产品说明书属于静态黑盒子测试。
常用测试用语－测试用例
nbsp;测试用例：编写用于输入输入的实际数制和预期结果。测试用例还明确指出使用具体测试用例产生的测试程序的任何限制 。
nbsp;使用目的：
―  测试用例应该设计为能够快速容易地发现尽可能多的错误。
―  应该通过使用和产生正确和错误的输入和输出来“检验”程序。
―  其目标是要使用合理范围内的条件，尽可能全面地测试所有模块乃至整个系统。

测试与调试－什么是缺陷
nbsp;缺陷：最终产品同用户的期望不一致
nbsp;缺陷的分类
nbsp;错误
nbsp;遗漏
nbsp;超出需求的部分
nbsp;缺陷（未触发）VS.错误（应首先解决）

测试与调试－调试的准则
nbsp;调试的方法：归纳法、演绎法和回溯法。
nbsp;常用调试技术使用诊断输出语句 (diagnostic output statement)、快照转储 (snapshot dump) 以及跟踪指令的断点 (instruction-dependent breakpoint)。
二、单元测试基本理论
nbsp;什么是单元测试(Unit Test)
nbsp;什么时候测试br>nbsp;为什么要进行单元测试
nbsp;C/C++单元测试问答（摘要）
单元测试(Unit Test)
nbsp;工厂在组装一台电视机之前，会对每个元件都进行测试，这，就是单元测试。
nbsp;临时单元测试：代码覆盖率要超过70%都很困难
nbsp;充分的单元测试：提高软件质量，降低开发成本的必由之路。
nbsp;单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
单元测试(Unit Test)
nbsp;对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。
nbsp;在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在象C++这样的面向对象的语言中，要进行测试的基本单元是类。对Ada语言来说，开发人员可以选择是在独立的过程和函数，还是在Ada包的级别上进行单元测试。单元测试的原则同样被扩展到第四代语言(4GL)的开发中，在这里基本单元被典型地划分为一个菜单或显示界面。
单元测试(Unit Test)
nbsp;单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行维护。
三、为什么要 进行单元测试
nbsp;一些流行的误解–反调论证
nbsp;其他好处
nbsp;单元测试的重要性

反证1：单元测试浪费了太多的时间
一旦编码完成，开发人员总是会迫切希望进行软件的集成工作，这样他们就能够看到实际的系统开始启动工作了。 这在外表上看来是一项明显的进步，而象单元测试这样的活动也许会被看作是通往这个阶段点的道路上的障碍， 推迟了对整个系统进行联调这种真正有意思的工作启动的时间。

反证1：单元测试浪费了太多的时间
　在这种开发步骤中，真实意义上的进步被外表上的进步取代了。系统能够正常工作的可能性是很小的，更多的情况是充满了各式各样的Bug。在实践中，这样一种开发步骤常常会导致这样的结果：软件甚至无法运行。更进一步的结果是大量的时间将被花费在跟踪那些包含在独立单元里的简单的Bug上面，在个别情况下，这些Bug也许是琐碎和微不足道的，但是总的来说，他们会导致在软件集成为一个系统时增加额外的工期， 而且当这个系统投入使用时也无法确保它能够可靠运行。
反证1：单元测试浪费了太多的时间
nbsp;在实践工作中，进行了完整计划的单元测试和编写实际的代码所花费的精力大致上是相同的。一旦完成了这些单元测试工作，很多Bug将被纠正，在确信他们手头拥有稳定可靠的部件的情况下，开发人员能够进行更高效的系统集成工作。这才是真实意义上的进步，所以说完整计划下的单元测试是对时间的更高效的利用。而调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。
nbsp;使用AdaTEST和Cantata这样的支持工具可以使单元测试更加简单和有效。但这不是必须的，单元测试即使是在没有工具支持的情况下也是一项非常有意义的活动。
反证2：仅仅证明代码做了什么
 这是那些没有首先为每个单元编写一个详细的规格说明而直接跳到编码阶段的开发人员提出的一条普遍的抱怨， 当编码完成以后并且面临代码测试任务的时候，他们就阅读这些代码并找出它实际上做了什么，把他们的测试工作基于已经写好的代码的基础上。当然，他们无法证明任何事情。所有的这些测试工作能够表明的事情就是编译器工作正常。是的，他们也许能够抓住(希望能够)罕见的编译器Bug，但是他们能够做的仅仅是这些。

重要性 1：时间方面
nbsp;如果认真的做好了单元测试，在系统集成联调时非常顺利，因此会节约很多时间，反之那些由于因为时间原因不做单元测试或随便做做的则在集成时总会遇到那些本应该在单元测试就能发现的问题，而这种问题在集成时遇到往往很难让开发人员预料到，最后在苦苦寻觅中才发现这是个很低级的错误而在悔恨自己时已经浪费了很多时间，这种时间上的浪费一点都不值得，正所谓得不偿失。

重要性 2：测试效果
nbsp;根据以往的测试经验来看，单元测试的效果是非常明显的，首先它是测试阶段的基础，做好了单元测试，在做后期的集成测试和系统测试时就很顺利。其次在单元测试过程中能发现一些很深层次的问题，同时还会发现一些很容易发现而在集成测试和系统测试很难发现的问题。再次单元测试关注的范围也特殊，它不仅仅是证明这些代码做了什么，最重要的是代码是如何做的，是否做了它该做的事情而没有做不该做的事情。

重要性 3：测试成本
nbsp;在单元测试时某些问题就很容易发现，如果在后期的测试中发现问题所花的成本将成倍数上升。比如在单元测试时发现1个问题需要1个小时，则在集成测试时发现该问题需要2个小时，在系统测试时发现则需要3个小时，同理还有定位问题和解决问题的费用也是成倍数上升的，这就是我们要尽可能早的排除尽可能多的bug来减少后期成本的因素之一。

重要性 4：产品质量
nbsp;单元测试的好与坏直接影响到产品的质量，可能就是由于代码中的某一个小错误就导致了整个产品的质量降低一个指标，或者导致更严重的后果，如果我们做好了单元测试这种情况是可以完全避免的。
nbsp;综上所述，单元测试是构筑产品质量的基石，我们不要因为节约单元测试的时间不做单元测试或随便做而让我们在后期浪费太多的不值得的时间，我们也不愿意因为由于节约那些时间导致开发出来的整个产品失败或重来！

四、 C/C++单元测试问答
nbsp;为什么要进行单元测试br>nbsp;由谁进行测试发部门还是测试部门br>nbsp;由测试部门进行单元测试为什么成本昂贵br>nbsp;由开发部门进行单元测试能保证测试效果吗
nbsp;边编码边测试会影响编码进度吗br>nbsp;实施单元测试需要改变开发流程吗
nbsp;单元测试测试哪些代码br>nbsp;实际工作中，单元测试能实现什么程度的测试覆盖
nbsp;单元测试如何改良项目代码的整体结构br>nbsp;我希望依赖全自动的工具来完成单元测试，这一想法现实吗br>nbsp;如果由开发部门实施单元测试，那么测试部门要做哪些工作br>为什么要进行单元测试br>nbsp;单元测试保证局部代码的质量
nbsp;单元测试改良项目代码的整体结构
nbsp;单元测试降低测试、维护升级的成本
nbsp;单元测试使开发过程适应频繁变化的需求
nbsp;单元测试有助于提升程序员的能力
由谁进行测试发部门/测试部门br>nbsp;应该由开发部门进行单元测试！
nbsp;由测试部门进行单元测试的问题：代价高，人手不足，耽误了测试部门对其他测试的准备工作。
nbsp;由开发部门进行单元测试的问题：担心影响开发进度，程序员不习惯做单元测试，测试自己编写的代码，难于保证测试的效果。
nbsp;无论由哪个部门做单元测试，都要面对一些问题，但开发部门所面对的问题可以借助工具来解决，而由测试部门进行单元测试，要么无法真正实施，要么代价昂贵。
由测试部门来单元测试成本昂贵br>nbsp;需多次重复理解程序
nbsp;反复沟通需要大量时间成本
nbsp;不利于发挥单元测试对代码结构的约束机制
nbsp;耽误测试部门对其他测试的准备工作
nbsp;即使测试部门人手充裕，仅仅从效益来考虑，也不应该由测试部门进行单元测试。如果测试部门本来就人力不充裕(进行单元测试的人员需具备编码能力)，勉强由测试部门进行单元测试，结果往往是—-没有结果。

由开发部门进行单元测试能保证测试效果吗br>nbsp;程序员测试自己编写的代码，往往只考虑“正常状况”，这当然会影响测试效果。但如果所用的单元测试工具能够统计各种白盒覆盖率，就能检查测试效果。当然，只做到这一点还是不够的，因为白盒覆盖具有逾后逾难的特点，达到一定的覆盖率后，覆盖率的提升会很困难。如果测试工具功能足够强大，能提供工具帮助用户快速地设计测试用例，达到完整的白盒覆盖，那么测试效果就能得到完全的保证。
nbsp;实际上，如果没有充分的统计数据，没有达到足够的测试完整性，那么由谁做单元测试，效果都不能保证。

边编码边测试会影响编码进度吗
nbsp;传统的单元测试是很费时费力的工作，主要时间消耗在于：编写测试代码、设计测试用例，如果开发工具能自动生成测试代码，并且具有快速设计测试用例的功能，那么测试费时就很少；另一方面，如果测试工具还能提供数据，帮助程序员整理编程思路、快速发现错误，更高效地调试，那么就能大量提高开发效率，抵销测试所消耗的时间，不但不会影响编码进度，甚至加快编码进度。
实施单元测试需要改变开发流程吗br>nbsp;边开发边测试，单元测试是编码行为而不是测试行为，测试代码看作是项目代码的一部分，程序员提交产品代码时也要提交测试代码和测试 告，其他流程可以不作任何改变。
nbsp;另一方面，在充分单元测试的基础上，由于具有高质量的局部代码，良好的整体代码结构，保证了代码的可扩展性和可复用性，同时，自动回归测试支持对代码的频繁修改而不用担心引入新的错误，因此，开发流程自然会变得敏捷，可以适应频繁变化的需求，使系统分析、架构设计和后期测试的压力减轻，自然而有效地改进了开发流程。

测试工具的分类和选择
nbsp;白盒测试工具
nbsp;静态测试工具
nbsp;动态测试工具
nbsp;黑盒测试工具
nbsp;功能测试工具
nbsp;性能测试工具
nbsp;测试管理工具
nbsp;其他测试工具
nbsp;测试工具的选择

白盒测试工具
nbsp;白盒测试工具一般是针对代码进行测试，测试中发现的缺陷可以定位到代码级
nbsp;静态测试工具直接对代码进行分析，不需要运行代码，也不需要对代码编译链接，生成可执行文件。静态测试工具一般是对代码进行语法扫描，找出不符合编码规范的地方，根据某种质量模型评价代码的质量，生成系统的调用关系图等。
nbsp;动态测试工具与静态测试工具不同，动态测试工具的一般采用“插桩”的方式，向代码生成的可执行文件中插入一些监测代码，用来统计程序运行时的数据。其与静态测试工具最大的不同就是动态测试工具要求被测系统实际运行。
黑盒测试工具
nbsp;黑盒测试工具适用于黑盒测试的场合，黑盒测试工具包括功能测试工具和性能测试工具。
nbsp;黑盒测试工具的一般原理是利用脚本的录制(Record)/回放(Playback)，模拟用户的操作，然后将被测系统的输出记录下来同预先给定的标准结果比较。黑盒测试工具可以大大减轻黑盒测试的工作量，在迭代开发的过程中，能够很好地进行回归测试。
nbsp;黑盒测试工具的代表有Rational公司的TeamTest、Robot，Compuware公司的QACenter，另外，专用于性能测试的工具包括有Radview公司的WebLoad、Microsoft公司的WebStress等工具。
测试管理工具
nbsp;测试管理工具用于对测试进行管理。
nbsp;内容：对测试计划、测试用例、测试实施进行管理，对缺陷的跟踪管理。
nbsp;测试管理工具的代表有Rational公司的Test Manager、Compureware公司的TrackRecord，Mercury的TestDirector和Quality Center等软件。
测试工具的选择
nbsp;功能
nbsp;基本的功能
nbsp; 表功能
nbsp;测试工具的集成能力
nbsp;操作系统和开发工具的兼容性
nbsp;价格
nbsp;连续性和一致性：
nbsp;全盘考虑，分阶段、逐步的引入测试工具
测试工具引入中的误区分析
nbsp;没有考虑到公司的实际情况，盲目引入测试工具
 专题分析，引入哪些测试工具br>nbsp;没有进行有效的测试工具的培训
 测试工具的培训是一个长期的过程
 系列的培训和交流
nbsp;没有形成一个良好的使用测试工具的环境
 没有能够形成一种机制让测试工具真正能够发挥作用
良好的测试工具使用环境
nbsp;约束机制
测试工具并不是策略
nbsp;测试工具并不能教测试员如何测试。如果测试出现问题，则测试工具会加重问题。在实现测试过程自动化之前，应首先解决测试过程中的问题。
nbsp;有些测试工具带有测试策略的建议。但是这种建议很少能够描述得很清楚，并不能针对具体情况，而且往往过于强调他们那种自动化测试的重要性。
nbsp;工具是辅助性的，关键还是靠人的思想和行为！
Parasoft
nbsp;Parasoft Jtest  代码分析和动态类、组件测试
nbsp;Parasoft C++Test代码分析和动态测试
nbsp;Parasoft .TEST代码分析和动态测试
nbsp;Parasoft Insure++ 实时性能监控以及分析优化
nbsp;Parasoft CodeWizard代码静态分析
nbsp;http://www.parasoft.com
Parasoft Jtest
nbsp;是第一个自动化Java单元测试工具。Jtest自动测试任何Java类或部件，而不需要您写一个测试用例、驱动程序或桩函数。只要点击一个按钮，Jtest自动测试代码构造（白盒测试）、测试代码功能性（黑盒测试）、维护代码完整性（回归测试）和静态分析（编程标准执行和指标度量）。不需要复杂的设置，Jtest能够立即使用并指出问题。如果您使用“按合同设计”技术在代码中加入描述信息，Jtest能够自动建立和执行测试用例验证一个类的功能是否符合其功能描述。
nbsp;Jcontract Java 实时性能监控以及分析优化

Parasoft C++Test
nbsp;单元测试和静态分析工具，自动测试C和C＋＋类别、功能或组件，而无需编写单个测试实例、测试驱动程序或桩调用。只需点击按钮，C++Test即会采用业内编码标准执行代码的静态分析，测试代码构造（白盒测试），测试代码功能性（黑盒测试），并保持代码完整性（回归测试）。
Parasoft .TEST
nbsp;单元测试和静态分析工具，自动测试写在MicrosoftNET框架的类别，而无需编写单个测试场景或桩调用。只需点击按钮，.TEST即会在.NET源代码上自动执行完整系列的静态和动态测试。.TEST RuleWizard性能通过图形化表达希望.TEST在自动编码标准执行过程中查找的模式，支持设计定制的编码标准。
Parasoft Insure++
nbsp;一个自动化的内存错误、内存泄漏的精确检测工具。Insure++能够可视化实时内存操作，准确检测出内存泄漏产生的根源。Insure++还能执行覆盖性分析，清楚地指示那些代码已经测试过。将Insure++集成到您的开发环境中，能够极大地减少调试时间并有效地防止错误。
Parasoft CodeWizard
nbsp;高级C/C++源代码分析工具，采用三百种以上行业相关的编码准则，自动识别编译器未检测到的危险的编码构造。CodeWizard可以容易地通过RuleWizard性能，创建新定制的准则，或者抑制用于定制分析的准则。日常使用CodeWizard，可简化代码检查，并使代码更具可读性和可维护性。
Compuware白盒测试工具集
nbsp;http://www.compuware.com
nbsp;BoundsChecker  C++,Delphi API和OLE错误检查、指针和泄露错误检查、内存错误检查
nbsp;TrueTime   C++ ,Java,Visual Basic 代码运行效率检查、组件性能的分析
nbsp;FailSafe    Visual Basic 自动错误处理和恢复系统
nbsp;Jcheck M$   Visual J++ 图形化的纯种和事件分析工具
nbsp;TrueCoverage  C++,Java,Visual Basic 函数调用次数、所占比率统计以及稳定性跟踪
nbsp;SmartCheck   Visual Basic 函数调用次数、所占比率统计以及稳定性跟踪
nbsp;CodeReview   Visual Basic 自动源代码分析工具

Compuware DevPartner Studio
nbsp;针对软件开发小组使用 Microsoft Visual C++，Microsoft Visual Basic，Java,ASP 或 HTML 设计的一套紧密配合的调试，测试和管理工具。该产品结合了强大的错误检测，性能分析，覆盖率分析，需求管理，测试和发布工具与全面的工程跟踪，错误管理，任务管理和自动的工作流程。DevPartner Studio Enterprise Edition 通过提高软件生产率,提高代码质量，支持工作流以及通讯标准让你对软件工程有更多的控制权。
nbsp;Win下最好的辅助调试工具。能够帮你检查内存泄漏，GDI泄漏，内存覆盖，数组越界，系统API调用参数是否合适。还能profile，对你的程序的运行时间进行分析，每个函数占用多少运行时间，每一行占用多少运行时间，帮你找出时间的瓶颈。
Rational
nbsp;Rational Purify
nbsp;Rational Quantify
nbsp;Rational PureCoverage
nbsp;IBM Rational PurifyPlus
Rational Purify
nbsp;面向VC, VB或者Java开发的测试Visual C/C++ 和Java代码中与内存有关的错误，确保整个应用程序的质量和可靠性。在查找典型的Visual C/C++程序中的传统内存访问错误，以及Java中与垃圾内存收集相关的错误方面，Rational Purify可以大显身手。Rational Robot的回归测试与Rational Purify结合使用完成可靠性测试。
nbsp; 址：http://www-306.ibm.com/software/rational/

Rational Quantify
nbsp;面向VC、VB 或者Java开发的测试性能瓶颈检测工具，它可以自动检测出影响程序段执行速度的程序性能瓶颈，提供参数分析表等等直观表格。帮助分析影响程序短执行速度的关键部分。
nbsp; 址：http://www-306.ibm.com/software/rational

Rational PureCoverage
nbsp;面向VC、VB或者Java开发的测试覆盖程度检测工具，它可以自动检测你的测试完整性和那些无法达到的部分。作为一个质量控制工程，可以使用PureCoverage在每一个测试阶段生产详尽的测试覆盖程度 告。
nbsp; 址：http://www-306.ibm.com/software/rational/

IBM Rational PurifyPlus
nbsp;一套完整的运行时分析工具，旨在提升应用的可靠性和性能。包括Purify、Quantify、PureCoverage。

Visual Studio 2005
nbsp;Team版的VS2005里面包含了完整的Test功能,具体有:Unit Test,WebTest和LoadTest.这一整套的测试基本涵盖了软件开发会使用到的测试功能.
nbsp;我这里先从单元测试开始介绍(Unit Test).说起单元测试,很多使用.net进行开发的人员也许马上就想起了NUnit,实际上它是个很好的工具,在VS2005出来之前,我也一直使用.不过现在VS2005已经提供了与NUnit一样,甚至还要强大的功能,我们又有什么理由不使用呢br>nbsp;微软因该说是很好的领会和贯彻了这个中国的经典儒家思想。Borland的Together好，.Net2005中就集成了了class designer,虽然说功能还不是很强大，同样，在单元测试成为软件开发中必不可少的环节而Nunit好评如潮的时，.Net2005中也加入了自己的单元测试组件。
Visual Studio 2005
nbsp;自动代码生成，是现代的开发环境追求的目标之一，而visual stutio无疑是走在了业界的最前列。在.net 2005中可以在右键菜单中选择unit test，而后针对该类的方法的单元测试的框架便自动生成，为开发者提供了很大的便利。
Visual Studio 2005
Visual Studio 2005
Visual Unit
nbsp;国产的单元测试工具，据说申请了多项专利，拥有一批创新的技术。
nbsp;VU目前版本适用于C++语言。
nbsp;黑盒方面，可以轻松完成功能测试、边界测试、速度测试，
nbsp;白盒方面，可以轻松完成语句覆盖、条件覆盖、分支覆盖、路径覆盖。这种空前的测试完整性，使代码中的缺陷无所循形。

六、如何实施单元测试
nbsp;学习基本理论
nbsp;评估&选择单元测试软件
nbsp;选择范围：静态分析、动态分析、测试程序框架
nbsp;开发平台：
nbsp;VC6.0S2005
nbsp;QNX
单元测试系列讲座
nbsp;基本理论
nbsp;CppUnit

七、讨论