单元测试课件

现象投入太多的精力，找bug，而新的代码仍然会出现类似bug；写完代码，心里没底，是否有大量bug等待自己；新修改的代码不知道是否影响其他部分代码；由于牵扯太多，导致不敢进行修改代码；.现象投入太多的精力，找bug，而新的代码仍然会出现类似b1主要内容主要内容1单元测试基本理论单元测试基本理论2为什么要进行单元测试为什么要进行单元测试3 C/C+单元测试问答单元测试问答 4单元测试工具单元测试工具主要内容单元测试基本理论2一、单元测试基本理论什么是单元测试什么是单元测试(Unit Test)什么时候测试？什么时候测试？为什么要进行单元测试为什么要进行单元测试C/C+单元测试问答（摘要）一、单元测试基本理论什么是单元测试(UnitTest)3单元测试(UnitTest)工厂在组装一台电视机之前，会对每个元件都进行测试，这，就是单元测试。临时单元测试：代码覆盖率要超过70%都很困难充分的单元测试：提高软件质量，降低开发成本的必由之路。单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。单元测试(UnitTest)工厂在组装一台电视机之前，会对4单元测试(UnitTest)对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在象C+这样的面向对象的语言中，要进行测试的基本单元是类。对Ada语言来说，开发人员可以选择是在独立的过程和函数，还是在Ada包的级别上进行单元测试。单元测试的原则同样被扩展到第四代语言(4GL)的开发中，在这里基本单元被典型地划分为一个菜单或显示界面。单元测试(UnitTest)对于程序员来说，如果养成了对自5单元测试(UnitTest)单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行维护。单元测试(UnitTest)单元测试不仅仅是作为无错编码一6二、为什么要进行单元测试一些流行的误解一些流行的误解-反调论证反调论证其他好处其他好处单元测试的重要性单元测试的重要性二、为什么要进行单元测试一些流行的误解-反调论证7反证反证1：单元测试浪费了太多的时间：单元测试浪费了太多的时间一旦编码完成，开发人员总是会迫切希望进行软件的集成工作，这样他们就能够看到实际的系统开始启动工作了。这在外表上看来是一项明显的进步，而象单元测试这样的活动也许会被看作是通往这个阶段点的道路上的障碍，推迟了对整个系统进行联调这种真正有意思的工作启动的时间。反证1：单元测试浪费了太多的时间一旦编码完成，开发人员总是会8反证反证1：单元测试浪费了太多的时间：单元测试浪费了太多的时间在这种开发步骤中，真实意义上的进步被外表上的进步取代了。系统能够正常工作的可能性是很小的，更多的情况是充满了各式各样的Bug。在实践中，这样一种开发步骤常常会导致这样的结果：软件甚至无法运行。更进一步的结果是大量的时间将被花费在跟踪那些包含在独立单元里的简单的Bug上面，在个别情况下，这些Bug也许是琐碎和微不足道的，但是总的来说，他们会导致在软件集成为一个系统时增加额外的工期，而且当这个系统投入使用时也无法确保它能够可靠运行。反证1：单元测试浪费了太多的时间在这种开发步骤中，真实意义9反证反证1：单元测试浪费了太多的时间：单元测试浪费了太多的时间在实践工作中，进行了完整计划的单元测试和编写实际的代码所花费的精力大致上是相同的。一旦完成了这些单元测试工作，很多Bug将被纠正，在确信他们手头拥有稳定可靠的部件的情况下，开发人员能够进行更高效的系统集成工作。这才是真实意义上的进步，所以说完整计划下的单元测试是对时间的更高效的利用。而调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。使用AdaTEST和Cantata这样的支持工具可以使单元测试更加简单和有效。但这不是必须的，单元测试即使是在没有工具支持的情况下也是一项非常有意义的活动。反证1：单元测试浪费了太多的时间在实践工作中，进行了完整计划10反证反证2：仅仅证明代码做了什么仅仅证明代码做了什么这是那些没有首先为每个单元编写一个详细的规格说明而直接跳到编码阶段的开发人员提出的一条普遍的抱怨，当编码完成以后并且面临代码测试任务的时候，他们就阅读这些代码并找出它实际上做了什么，把他们的测试工作基于已经写好的代码的基础上。当然，他们无法证明任何事情。所有的这些测试工作能够表明的事情就是编译器工作正常。是的，他们也许能够抓住(希望能够)罕见的编译器Bug，但是他们能够做的仅仅是这些。反证2：仅仅证明代码做了什么 这是那些没有首先为每个单元编11反证反证2：仅仅证明代码做了什么仅仅证明代码做了什么如果他们首先写好一个详细的规格说明，测试能够以规格说明为基础。代码就能够针对它的规格说明，而不是针对自身进行测试。这样的测试仍然能够抓住编译器的Bug，同时也能找到更多的编码错误，甚至是一些规格说明中的错误。好的规格说明可以使测试的质量更高，所以最后的结论是高质量的测试需要高质量的规格说明。反证2：仅仅证明代码做了什么 如果他们首先写好一个详细的规12反证反证2：仅仅证明代码做了什么仅仅证明代码做了什么在实践中会出现这样的情况：一个开发人员要面对测试一个单元时只给出单元的代码而没有规格说明这样吃力不讨好的任务。你怎样做才会有更多的收获，而不仅仅是发现编译器的Bug？第一步是理解这个单元原本要做什么，-不是它实际上做了什么。比较有效的方法是倒推出一个概要的规格说明。这个过程的主要输入条件是要阅读那些程序代码和注释，主要针对这个单元，及调用它和被它调用的相关代码。画出流程图是非常有帮助的，你可以用手工或使用某种工具。可以组织对这个概要规格说明的走读(Review)，以确保对这个单元的说明没有基本的错误，有了这种最小程度的代码深层说明，就可以用它来设计单元测试了。反证2：仅仅证明代码做了什么 在实践中会出现这样的情况：13反证反证3：我是个很棒的程序员，：我是个很棒的程序员，我是我是不是可以不进行单元测试？不是可以不进行单元测试？在每个开发组织中都至少有一个这样的开发人员，他非常擅长于编程，他们开发的软件总是在第一时间就可以正常运行，因此不需要进行测试。你是否经常听到这样的借口？在真实世界里，每个人都会犯错误。即使某个开发人员可以抱着这种态度在很少的一些简单的程序中应付过去。但真正的软件系统是非常复杂的。真正的软件系统不可以寄希望于没有进行广泛的测试和Bug修改过程就可以正常工作。编码不是一个可以一次性通过的过程。在真实世界中，软件产品必须进行维护以对操作需求的改变作出反应，并且要对最初的开发工作遗留下来的Bug进行修改。你希望依靠那些原始作者进行修改吗？这些制造出这些未经测试的原始代码的资深专家们还会继续在其他地方制造这样的代码。在开发人员做出修改后进行可重复的单元测试可以避免产生那些令人不快的负作用。反证3：我是个很棒的程序员，我是不是可以不进行单元测试？14反证反证4：不管怎样，：不管怎样，集成测试将会抓集成测试将会抓住所有的住所有的Bug？我们已经在前面的讨论中从一个侧面对这个问题进行了部分的阐述。这个论点不成立的原因在于规模越大的代码集成意味着复杂性就越高。如果软件的单元没有事先进行测试，开发人员很可能会花费大量的时间仅仅是为了使软件能够运行，而任何实际的测试方案都无法执行。一旦软件可以运行了，开发人员又要面对这样的问题：在考虑软件全局复杂性的前提下对每个单元进行全面的测试。这是一件非常困难的事情，甚至在创造一种单元调用的测试条件的时候，要全面的考虑单元的被调用时的各种入口参数。在软件集成阶段，对单元功能全面测试的复杂程度远远的超过独立进行的单元测试过程。最后的结果是测试将无法达到它所应该有的全面性。一些缺陷将被遗漏，并且很多Bug将被忽略过去。让我们类比一下，假设我们要清洗一台已经完全装配好的食物加工机器!无论你喷了多少水和清洁剂，一些食物的小碎片还是会粘在机器的死角位置，只有任其腐烂并等待以后再想办法。但我们换个角度想想，如果这台机器是拆开的，这些死角也许就不存在或者更容易接触到了，并且每一部分都可以毫不费力的进行清洗。反证4：不管怎样，集成测试将会抓住所有的Bug？我们已15反证反证5：它的成本效率不高：它的成本效率不高一个特定的开发组织或软件应用系统的测试水平取决于对那些未发现的Bug的潜在后果的重视程度。这种后果的严重程度可以从一个Bug引起的小小的不便到发生多次的死机的情况。这种后果可能常常会被软件的开发人员所忽视(但是用户可不会这样)，这种情况会长期的损害这些向用户提交带有Bug的软件的开发组织的信誉，并且会导致对未来的市场产生负面的影响。相反地，一个可靠的软件系统的良好的声誉将有助于一个开发组织获取未来的市场。很多研究成果表明，无论什么时候作出修改都要进行完整的回归测试，在生命周期中尽早地对软件产品进行测试将使效率和质量得到最好的保证。Bug发现的越晚，修改它所需的费用就越高，因此从经济角度来看，应该尽可能早的查找和修改Bug。在修改费用变的过高之前，单元测试是一个在早期抓住Bug的机会。相比后阶段的测试，单元测试的创建更简单，维护更容易，并且可以更方便的进行重复。从全程的费用来考虑，相比起那些复杂且旷日持久的集成测试，或是不稳定的软件系统来说，单元测试所需的费用是很低的。反证5：它的成本效率不高一个特定的开发组织或软件应用系统的测16反证反证5：它的成本效率不高：它的成本效率不高摘自(CapersJones，McGraw-Hill1991)，它列出了准备测试，执行测试，和修改缺陷所花费的时间(以一个功能点为基准)，这些数据显示单元测试的成本效率大约是集成测试的两倍系统测试的三倍。反证5：它的成本效率不高摘自(Caper17反证反证5：它的成本效率不高：它的成本效率不高(术语域测试(Fieldtest)意思是在软件投入使用以后，针对某个领域所作的所有测试活动)这个图表并不表示开发人员不应该进行后阶段的测试活动，这次测试活动仍然是必须的。它的真正意思是尽可能早的排除尽可能多的Bug可以减少后阶段测试的费用。其他的一些图表显示高达50%的维护工作量被花在那些总是会有的Bug的修改上面。如果这些Bug在开发阶段被排除掉的话，这些工作量就可以节省下来。当考虑到软件维护费用可能会比最初的开发费用高出数倍的时候，这种潜在的对50%软件维护费用的节省将对整个软件生命周期费用产生重大的影响。反证5：它的成本效率不高(术语域测试(Fieldtest)18反证反证 结论结论经验表明一个尽责的单元测试方法将会在软件开发的某个阶段发现很多的Bug，并且修改它们的成本也很低。在软件开发的后期阶段，Bug的发现并修改将会变得更加困难，并要消耗大量的时间和开发费用。无论什么时候作出修改都要进行完整的回归测试，在生命周期中尽早地对软件产品进行测试将使效率和质量得到最好的保证。在提供了经过测试的单元的情况下，系统集成过程将会大大地简化。开发人员可以将精力集中在单元之间的交互作用和全局的功能实现上，而不是陷入充满很多Bug的单元之中不能自拔。使测试工作的效力发挥到最大化的关键在于选择正确的测试策略，这其中包含了完全的单元测试的概念，以及对测试过程的良好的管理，还有适当地使用象AdaTEST和Cantata这样的工具来支持测试过程。这些活动可以产生这样的结果：在花费更低的开发费用的情况下得到更稳定的软件。更进一步的好处是简化了维护过程并降低了生命周期的费用。有效的单元测试是推行全局质量文化的一部分，而这种质量文化将会为软件开发者带来无限的商机。反证结论经验表明一个尽责的单元测试方法将会在软件开发的某19其他好处其他好处1：减少程序的：减少程序的Bug要减少软件中的错误数目，方法之一就是拥有一个专业的测试组，其工作就是尽一切可能使软件崩溃。不幸的是，如果拥有测试组，那么即使是经验丰富的开发人员，也会倾向于花费较少的时间来保证代码的可靠性。软件界有一句俗语：“开发人员不应该测试他们自己的代码”。这是因为开发人员对自己的代码了如指掌，他们很清楚如何采用适当的方法对代码进行测试。尽管这句俗语很有道理，但却忽略了非常重要的一点-如果开发人员不对自己的代码进行测试，又如何知道代码能否按照预期的方式运行？简单说来，他们根本无从得知。开发人员编写那种运行不正常或只在某些情况下运行正常的代码是一个严重的问题。他们通常只测试代码能否在很少的情况下正常运行，而不是验证代码能够在所有情况下均正常运行。其他好处1：减少程序的Bug要减少软件中的错误数目，方法20其他好处其他好处2：提高开发速度：提高开发速度在实践工作中，进行了完整计划的单元测试和编写实际的代码所花费的精力大致上是相同的。一旦完成了这些单元测试工作，很多Bug将被纠正，在确信他们手头拥有稳定可靠的部件的情况下，开发人员能够进行更高效的系统集成工作。这才是真实意义上的进步，所以说完整计划下的单元测试是对时间的更高效的利用。而调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。经验表明一个尽责的单元测试方法将会在软件开发的某个阶段发现很多的Bug，并且修改它们的成本也很低。在软件开发的后期阶段，Bug的发现并修改将会变得更加困难，并要消耗大量的时间和开发费用。无论什么时候作出修改都要进行完整的回归测试，在生命周期中尽早地对软件产品进行测试将使效率和质量得到最好的保证。在提供了经过测试的单元的情况下，系统集成过程将会大大地简化。开发人员可以将精力集中在单元之间的交互作用和全局的功能实现上，而不是陷入充满很多Bug的单元之中不能自拔。其他好处2：提高开发速度在实践工作中，进行了完整计划的单21其他好处其他好处3：使程序代码更整洁，优：使程序代码更整洁，优化程序的设计化程序的设计只有自动的单元测试程序失败时，我们才会去重写代码，在测试驱动开发中，要求我们对程序不停的重构，通过重构，我们可以优化程序的结构设计，消除程序中潜在的错误。同时，为了能够使自己的程序可以很方便的进行测试，开发人员就需要很好地考虑程序的设计，极限编程的方法说可以不需要设计就开始编码，但实际上，它在编写代码的过程中每时每刻都为了方便的进行和通过测试而在优化自己的设计。它实际上是把开始阶段很大很抽象的设计分散到你编写的每个方法中。因此他们会说好设计最后会自然而然的出现。其他好处3：使程序代码更整洁，优化程序的设计只有自动的单22其他好处其他好处4：编写单元测试代码的过：编写单元测试代码的过程实际上就是设计程序的过程程实际上就是设计程序的过程在编写单元测试代码时，我们实际上是在思考我们的程序根据预期会返回什么结果，它实际上就是程序设计的过程。而通过重构过程，我们可以对这些设计进行很好的优化。其他好处4：编写单元测试代码的过程实际上就是设计程序的过程23单元测试的重要性单元测试的重要性单元测试是软件测试的基础，因此单元测试的效果会直接影响到软件的后期测试，最终在很大程度上影响到产品的质量。时间方面时间方面测试效果测试效果测试成本测试成本产品质量产品质量单元测试的重要性单元测试是软件测试的基础，因此单元测试的效24重要性重要性1：时间方面：时间方面如果认真的做好了单元测试，在系统集成联调时非常顺利，因此会节约很多时间，反之那些由于因为时间原因不做单元测试或随便做做的则在集成时总会遇到那些本应该在单元测试就能发现的问题，而这种问题在集成时遇到往往很难让开发人员预料到，最后在苦苦寻觅中才发现这是个很低级的错误而在悔恨自己时已经浪费了很多时间，这种时间上的浪费一点都不值得，正所谓得不偿失。重要性1：时间方面如果认真的做好了单元测试，在系统集成联25重要性重要性2：测试效果：测试效果根据以往的测试经验来看，单元测试的效果是非常明显的，首先它是测试阶段的基础，做好了单元测试，在做后期的集成测试和系统测试时就很顺利。其次在单元测试过程中能发现一些很深层次的问题，同时还会发现一些很容易发现而在集成测试和系统测试很难发现的问题。再次单元测试关注的范围也特殊，它不仅仅是证明这些代码做了什么，最重要的是代码是如何做的，是否做了它该做的事情而没有做不该做的事情。重要性2：测试效果根据以往的测试经验来看，单元测试的效果是26重要性重要性3：测试成本：测试成本在单元测试时某些问题就很容易发现，如果在后期的测试中发现问题所花的成本将成倍数上升。比如在单元测试时发现1个问题需要1个小时，则在集成测试时发现该问题需要2个小时，在系统测试时发现则需要3个小时，同理还有定位问题和解决问题的费用也是成倍数上升的，这就是我们要尽可能早的排除尽可能多的bug来减少后期成本的因素之一。重要性3：测试成本在单元测试时某些问题就很容易发现，如果在27重要性重要性4：产品质量：产品质量单元测试的好与坏直接影响到产品的质量，可能就是由于代码中的某一个小错误就导致了整个产品的质量降低一个指标，或者导致更严重的后果，如果我们做好了单元测试这种情况是可以完全避免的。综上所述，单元测试是构筑产品质量的基石，我们不要因为节约单元测试的时间不做单元测试或随便做而让我们在后期浪费太多的不值得的时间，我们也不愿意因为由于节约那些时间导致开发出来的整个产品失败或重来！重要性4：产品质量单元测试的好与坏直接影响到产品的质量，可28三、C/C+单元测试问答为什么要进行单元测试为什么要进行单元测试?由谁进行测试？开发部门还是测试部门？由谁进行测试？开发部门还是测试部门？由测试部门进行单元测试为什么成本昂贵？由测试部门进行单元测试为什么成本昂贵？由开发部门进行单元测试能保证测试效果吗？由开发部门进行单元测试能保证测试效果吗？边编码边测试会影响编码进度吗？边编码边测试会影响编码进度吗？实施单元测试需要改变开发流程吗？实施单元测试需要改变开发流程吗？单元测试测试哪些代码？单元测试测试哪些代码？实际工作中，单元测试能实现什么程度的测试覆盖？实际工作中，单元测试能实现什么程度的测试覆盖？单元测试如何改良项目代码的整体结构？单元测试如何改良项目代码的整体结构？我希望依赖全自动的工具来完成单元测试，这一想法现实吗我希望依赖全自动的工具来完成单元测试，这一想法现实吗？如果由开发部门实施单元测试，那么测试部门要做哪些工作如果由开发部门实施单元测试，那么测试部门要做哪些工作？http:/www.KaileS三、C/C+单元测试问答为什么要进行单元测试?http:29为什么要进行单元测试为什么要进行单元测试?单元测试保证局部代码的质量单元测试改良项目代码的整体结构单元测试降低测试、维护升级的成本单元测试使开发过程适应频繁变化的需求单元测试有助于提升程序员的能力为什么要进行单元测试?单元测试保证局部代码的质量30由谁进行测试？开发部门由谁进行测试？开发部门/测试部门？测试部门？应该由开发部门进行单元测试！由测试部门进行单元测试的问题：代价高，人手不足，耽误了测试部门对其他测试的准备工作。由开发部门进行单元测试的问题：担心影响开发进度，程序员不习惯做单元测试，测试自己编写的代码，难于保证测试的效果。无论由哪个部门做单元测试，都要面对一些问题，但开发部门所面对的问题可以借助工具来解决，而由测试部门进行单元测试，要么无法真正实施，要么代价昂贵。由谁进行测试？开发部门/测试部门？应该由开发部门进行单元测试31由测试部门来单元测试成本昂贵？由测试部门来单元测试成本昂贵？需多次重复理解程序反复沟通需要大量时间成本不利于发挥单元测试对代码结构的约束机制耽误测试部门对其他测试的准备工作即使测试部门人手充裕，仅仅从效益来考虑，也不应该由测试部门进行单元测试。如果测试部门本来就人力不充裕(进行单元测试的人员需具备编码能力)，勉强由测试部门进行单元测试，结果往往是-没有结果。由测试部门来单元测试成本昂贵？需多次重复理解程序32由开发部门进行单元测试能保证测试由开发部门进行单元测试能保证测试效果吗？效果吗？程序员测试自己编写的代码，往往只考虑“正常状况”，这当然会影响测试效果。但如果所用的单元测试工具能够统计各种白盒覆盖率，就能检查测试效果。当然，只做到这一点还是不够的，因为白盒覆盖具有逾后逾难的特点，达到一定的覆盖率后，覆盖率的提升会很困难。如果测试工具功能足够强大，能提供工具帮助用户快速地设计测试用例，达到完整的白盒覆盖，那么测试效果就能得到完全的保证。实际上，如果没有充分的统计数据，没有达到足够的测试完整性，那么由谁做单元测试，效果都不能保证。由开发部门进行单元测试能保证测试效果吗？程序员测试自己编写的33边编码边测试会影响编码进度吗？边编码边测试会影响编码进度吗？传统的单元测试是很费时费力的工作，主要时间消耗在于：编写测试代码、设计测试用例，如果开发工具能自动生成测试代码，并且具有快速设计测试用例的功能，那么测试费时就很少；另一方面，如果测试工具还能提供数据，帮助程序员整理编程思路、快速发现错误，更高效地调试，那么就能大量提高开发效率，抵销测试所消耗的时间，不但不会影响编码进度，甚至加快编码进度。边编码边测试会影响编码进度吗？传统的单元测试是很费时费力的34实施单元测试需要改变开发流程吗？实施单元测试需要改变开发流程吗？边开发边测试，单元测试是编码行为而不是测试行为，测试代码看作是项目代码的一部分，程序员提交产品代码时也要提交测试代码和测试报告，其他流程可以不作任何改变。另一方面，在充分单元测试的基础上，由于具有高质量的局部代码，良好的整体代码结构，保证了代码的可扩展性和可复用性，同时，自动回归测试支持对代码的频繁修改而不用担心引入新的错误，因此，开发流程自然会变得敏捷，可以适应频繁变化的需求，使系统分析、架构设计和后期测试的压力减轻，自然而有效地改进了开发流程。实施单元测试需要改变开发流程吗？边开发边测试，单元测试是编码35单元测试测试哪些代码？单元测试测试哪些代码？单元测试通常不测试很简单的代码，一般也不测试“边界代码”。很简单的代码容易理解，例如Get/Set函数，这里解释一下“边界代码”。“边界代码”是指用于与外部系统交互的代码，例如用于处理用户界面的代码。数据库、文件、网络都可以看作是外部系统，用于读写数据库或文件、或访问网络的代码也可以看作是“边界代码”，这类代码应该独立出来，可以进行单元测试，但对这些代码的单元测试通常不能自动验证预期输出，而是需要人工察看。编程时，不要把普通代码与“边界代码”混在一起，例如，不要把各种运算直接写在界面类中，做到了这一点，绝大多数代码都可以进行单元测试。单元测试测试哪些代码？单元测试通常不测试很简单的代码，一般也36实际工作中，单元测试能实现什么程实际工作中，单元测试能实现什么程度的测试覆盖？度的测试覆盖？单元测试的最低要求是100%语句覆盖，这个覆盖率还是不够的，最好实现多种覆盖的组全，比较理想的覆盖率组合是：100%的语句、条件、分支、路径覆盖，另外，测试工具最好还能自动生成边界测试用例捕捉未处理特殊输入形成的错误。在达到这种覆盖之后，残留的编码错误可以几乎说没有了（设计方面的错误除外，这些属于集成或系统测试的范畴）。实际工作中，单元测试能实现什么程度的测试覆盖？单元测试的最低37单元测试如何改良项目代码的整体结单元测试如何改良项目代码的整体结构？构？具有良好整体结构的代码，应该符合“低耦合”的特性，即具有“可测性”。测试不具有“可测性”的代码时一般会产生编译错误，或者需要打桩才能测试，从而将问题暴露出来。发现问题后，重构代码、消除不当耦合一般不难，这种简单的重构将有效地改良代码的整体结构。单元测试如何改良项目代码的整体结构？具有良好整体结构的代码，38我希望依赖全自动的工具来完成单元我希望依赖全自动的工具来完成单元测试，这一想法现实吗？测试，这一想法现实吗？完全自动化是一个美妙的愿望，但由于单元测试的基本特性，完全自动化的单元测试是不现实的。与其他不同，单元测试是“隔离”的测试，要求代码具有可测性，一个项目甚至一个文件中，难免会有些影响可测性的代码，编译到这些代码时常常会产生编译错误，因此，全自动的单元测试工具往往只能测试小部分代码，即使使用某种技术手段屏蔽掉编译错误，也得不偿失，因为同时也屏蔽掉了改良代码整体结构的宝贵机会。如果采用自底向上的方式，一个一个文件测试，测试一个文件前，先将该文件加入测试工程并编译，没有编译错误时再测试，这样可以及时发现并消除不当耦合，使代码具有可测性，这种非全自动的方式，可以测试绝大多数代码，也保证了代码具有良好的整体结构。另一方面，主要由测试工具自动生成测试用例来进行测试往往没有实际意义，因为测试工具无法自动了解程序的功能，因此，自动测试用例通常只能发现异常之类的极端错误，大多数一般错误都是无法发现的。测试工具最重要的不是自动生成测试用例，而是能提供快速建立和编辑测试用例的工具。我希望依赖全自动的工具来完成单元测试，这一想法现实吗？完全自39如果由开发部门实施单元测试，那么如果由开发部门实施单元测试，那么测试部门要做哪些工作？测试部门要做哪些工作？推动、组织单元测试的实施。单元测试既然叫做“测试”，开发部门常常认识不到其重要性和必要性，需要由测试部门推动和协助组织实施。制定单元测试规范，培训单元测试技术。检查、审核单元测试结果，保证单元测试的有效性。如果由开发部门实施单元测试，那么测试部门要做哪些工作？推动、40四、单元测试工具测试工具的分类和选择ParasoftCompuwareRationalAutomatedQAAQTimexUnit系列VisualStudio2005VisualUnit四、单元测试工具测试工具的分类和选择41测试工具的分类和选择白盒测试工具静态测试工具动态测试工具黑盒测试工具功能测试工具性能测试工具测试管理工具其他测试工具测试工具的选择测试工具的分类和选择白盒测试工具42白盒测试工具白盒测试工具一般是针对代码进行测试，测试中发现的缺陷可以定位到代码级静态测试工具直接对代码进行分析，不需要运行代码，也不需要对代码编译链接，生成可执行文件。静态测试工具一般是对代码进行语法扫描，找出不符合编码规范的地方，根据某种质量模型评价代码的质量，生成系统的调用关系图等。动态测试工具与静态测试工具不同，动态测试工具的一般采用“插桩”的方式，向代码生成的可执行文件中插入一些监测代码，用来统计程序运行时的数据。其与静态测试工具最大的不同就是动态测试工具要求被测系统实际运行。白盒测试工具白盒测试工具一般是针对代码进行测试，测试中发现的43黑盒测试工具黑盒测试工具适用于黑盒测试的场合，黑盒测试工具包括功能测试工具和性能测试工具。黑盒测试工具的一般原理是利用脚本的录制(Record)/回放(Playback)，模拟用户的操作，然后将被测系统的输出记录下来同预先给定的标准结果比较。黑盒测试工具可以大大减轻黑盒测试的工作量，在迭代开发的过程中，能够很好地进行回归测试。黑盒测试工具的代表有Rational公司的TeamTest、Robot，Compuware公司的QACenter，另外，专用于性能测试的工具包括有Radview公司的WebLoad、Microsoft公司的WebStress等工具。黑盒测试工具黑盒测试工具适用于黑盒测试的场合，黑盒测试工具包44测试管理工具测试管理工具用于对测试进行管理。内容：对测试计划、测试用例、测试实施进行管理，对缺陷的跟踪管理。测试管理工具的代表有Rational公司的TestManager、Compureware公司的TrackRecord，Mercury的TestDirector和QualityCenter等软件。测试管理工具测试管理工具用于对测试进行管理。45测试工具的选择功能基本的功能报表功能测试工具的集成能力操作系统和开发工具的兼容性价格连续性和一致性：全盘考虑，分阶段、逐步的引入测试工具测试工具的选择功能46测试工具引入中的误区分析没有考虑到公司的实际情况，盲目引入测试工具专题分析，引入哪些测试工具？专题分析，引入哪些测试工具？没有进行有效的测试工具的培训测试工具的培训是一个长期的过程系列的培训和交流没有形成一个良好的使用测试工具的环境没有能够形成一种机制让测试工具真正能够发挥作用测试工具引入中的误区分析没有考虑到公司的实际情况，盲目引入测47良好的测试工具使用环境约束机制开发流程例如，单元测试是由开发人员完成，如果没有流程来规范开发人员的行为，在项目进度压力比较大的情况下，开发人员很可能就会有意识地不使用测试工具，来逃避问题。在这种情况下，就必须形成一种有约束力的机制来强制对测试工具的使用。某公司的一种比较好的方式：将测试工具的使用明确定义进公司的开发流程。在开发流程中明确说明，在项目里程碑提交的文档中必须包括测试工具生成的报告，该报告中的数据是决定项目是否合格的依据。根据公司的实际情况，在提交集成测试时需要提交DevPartner工具生成的测试覆盖率报告、Logiscope生成的代码质量报告，并且要求单元测试的代码覆盖率必须达到80%以上，代码质量评价必须在Fair以上。良好的测试工具使用环境约束机制开发流程例如，单元测试是48测试工具并不是策略测试工具并不能教测试员如何测试。如果测试出现问题，则测试工具会加重问题。在实现测试过程自动化之前，应首先解决测试过程中的问题。有些测试工具带有测试策略的建议。但是这种建议很少能够描述得很清楚，并不能针对具体情况，而且往往过于强调他们那种自动化测试的重要性。工具是辅助性的，关键还是靠人的思想和行工具是辅助性的，关键还是靠人的思想和行为！为！测试工具并不是策略测试工具并不能教测试员如何测试。如果测试出49ParasoftParasoft Jtest 代码分析和动态类、组件代码分析和动态类、组件测试测试Parasoft C+Test代码分析和动态测试代码分析和动态测试Parasoft.TEST代码分析和动态测试代码分析和动态测试Parasoft Insure+实时性能监控以及分析实时性能监控以及分析优化优化Parasoft CodeWizard代码静态分析代码静态分析http:/ParasoftParasoftJtest代码分析和50Parasoft Jtest是第一个自动化Java单元测试工具。Jtest自动测试任何Java类或部件，而不需要您写一个测试用例、驱动程序或桩函数。只要点击一个按钮，Jtest自动测试代码构造（白盒测试）、测试代码功能性（黑盒测试）、维护代码完整性（回归测试）和静态分析（编程标准执行和指标度量）。不需要复杂的设置，Jtest能够立即使用并指出问题。如果您使用“按合同设计”技术在代码中加入描述信息，Jtest能够自动建立和执行测试用例验证一个类的功能是否符合其功能描述。JcontractJava实时性能监控以及分析优化ParasoftJtest是第一个自动化Java单元测试工51Parasoft C+Test单元测试和静态分析工具，自动测试C和C类别、功能或组件，而无需编写单个测试实例、测试驱动程序或桩调用。只需点击按钮，C+Test即会采用业内编码标准执行代码的静态分析，测试代码构造（白盒测试），测试代码功能性（黑盒测试），并保持代码完整性（回归测试）。ParasoftC+Test单元测试和静态分析工具，自52Parasoft.TEST单元测试和静态分析工具，自动测试写在Microsoft?.NET框架的类别，而无需编写单个测试场景或桩调用。只需点击按钮，.TEST即会在.NET源代码上自动执行完整系列的静态和动态测试。.TESTRuleWizard性能通过图形化表达希望.TEST在自动编码标准执行过程中查找的模式，支持设计定制的编码标准。Parasoft.TEST单元测试和静态分析工具，自动测53Parasoft Insure+一个自动化的内存错误、内存泄漏的精确检测工具。Insure+能够可视化实时内存操作，准确检测出内存泄漏产生的根源。Insure+还能执行覆盖性分析，清楚地指示那些代码已经测试过。将Insure+集成到您的开发环境中，能够极大地减少调试时间并有效地防止错误。ParasoftInsure+一个自动化的内存错误、内54Parasoft CodeWizard高级C/C+源代码分析工具，采用三百种以上行业相关的编码准则，自动识别编译器未检测到的危险的编码构造。CodeWizard可以容易地通过RuleWizard性能，创建新定制的准则，或者抑制用于定制分析的准则。日常使用CodeWizard，可简化代码检查，并使代码更具可读性和可维护性。ParasoftCodeWizard高级C/C+源代码55Compuware白盒测试工具集http:/BoundsChecker C+,DelphiAPI和OLE错误检查、指针和泄露错误检查、内存错误检查TrueTimeC+,Java,VisualBasic代码运行效率检查、组件性能的分析FailSafeVisualBasic自动错误处理和恢复系统JcheckM$VisualJ+图形化的纯种和事件分析工具TrueCoverageC+,Java,VisualBasic函数调用次数、所占比率统计以及稳定性跟踪SmartCheckVisualBasic函数调用次数、所占比率统计以及稳定性跟踪CodeReviewVisualBasic自动源代码分析工具Compuware白盒测试工具集http:/56Compuware DevPartner Studio针对软件开发小组使用MicrosoftVisualC+，MicrosoftVisualBasic，Java,ASP或HTML设计的一套紧密配合的调试，测试和管理工具。该产品结合了强大的错误检测，性能分析，覆盖率分析，需求管理，测试和发布工具与全面的工程跟踪，错误管理，任务管理和自动的工作流程。DevPartnerStudioEnterpriseEdition通过提高软件生产率,提高代码质量，支持工作流以及通讯标准让你对软件工程有更多的控制权。Win下最好的辅助调试工具。能够帮你检查内存泄漏，GDI泄漏，内存覆盖，数组越界，系统API调用参数是否合适。还能profile，对你的程序的运行时间进行分析，每个函数占用多少运行时间，每一行占用多少运行时间，帮你找出时间的瓶颈。CompuwareDevPartnerStudio针对软57RationalRational PurifyRational QuantifyRational PureCoverageIBM Rational PurifyPlusRationalRationalPurify58Rational Purify面向VC,VB或者Java开发的测试VisualC/C+和Java代码中与内存有关的错误，确保整个应用程序的质量和可靠性。在查找典型的VisualC/C+程序中的传统内存访问错误，以及Java中与垃圾内存收集相关的错误方面，RationalPurify可以大显身手。RationalRobot的回归测试与RationalPurify结合使用完成可靠性测试。网址：http:/ Quantify面向VC、VB或者Java开发的测试性能瓶颈检测工具，它可以自动检测出影响程序段执行速度的程序性能瓶颈，提供参数分析表等等直观表格。帮助分析影响程序短执行速度的关键部分。网址：http:/ PureCoverage面向VC、VB或者Java开发的测试覆盖程度检测工具，它可以自动检测你的测试完整性和那些无法达到的部分。作为一个质量控制工程，可以使用PureCoverage在每一个测试阶段生产详尽的测试覆盖程度报告。网址：http:/ Rational PurifyPlus一套完整的运行时分析工具，旨在提升应用的可靠性和性能。包括Purify、Quantify、PureCoverage。IBMRationalPurifyPlus一套完整的运行62AutomatedQA AQTimeAutomatedQAAQTime是软件项目的测试工具，能实时/静态地分析软件的执行效率和代码性能，发现软件项目客户端和服务器段的瓶颈所在、内存泄漏、消耗资源的代码及未经验证的算法。能够分析Delphi/BCB/VC/VB/GCC等工具开发的软件产品，此外，它有专门ForVS.NET的版本。AQTime是专业Windows开发者在开发过程中消除臆测的完全方案，使开发者在完成项目时开发出坚如磐石的程序。通过AQTime无可匹敌的报告系统和测试分析架构，开发这不仅可以得知其项目中确实存在bug和瓶颈，而且会知道具体到哪个模块、类、线程、代码行出了问题，从而快速消除错误。性能架构和内存分配调试器，适于Win32和.NET互联程序。该工具可以集成到MicrosoftVisualStudio.NET中，也可单独使用。通过AQtime4，您不仅可以发现程序瓶颈，还可以查找瓶颈来源。AQtime4是AutomatedQA的获奖产品performanceprofiling和memorydebugging工具集的下一代替换产品，支持Microsoft,Borland,Intel,Compaq和GNU编译器。新版本结合了旗舰产品Aqtime和AQtimefor.NET的所有优势，前者主要面向Win32应用程序性能分析，而后者则是第一个Microsoft.NET平台的性能和内存分配架构工具。如同其先前产品一样，AQtime4可以为.NET和Win32程序生成全面细致的报告，从而帮助您轻松隔离并排除代码中含有的性能问题和内存/资源泄露问题。AutomatedQAAQTimeAutomatedQA63xUnit系列目前的最流行的单元测试工具是xUnit系列框架，常用的根据语言不同分为JUnit（java），CppUnit（C+），DUnit（Delphi），NUnit（.net），PhpUnit（Php）等等。该测试框架的第一个和最杰出的应用就是由ErichGamma（设计模式的作者）和KentBeck（XP（ExtremeProgramming）的创始人）提供的开放源代码的JUnit。xUnit系列目前的最流行的单元测试工具是xUnit系列框64xUnit系列AunitAdahttp:/www.libre.act-europe.frCppUnitC+http:/ComUnitVB,COMhttp:/DunitDelphihttp:/DotUnit.Nethttp:/HttpUnitWebhttp:/ Unit国产的单元测试工具，据说申请了多项专利，拥有一批创新的技术。VU目前版本适用于C+语言。黑盒方面，可以轻松完成功能测试、边界测试、速度测试，白盒方面，可以轻松完成语句覆盖、条件覆盖、分支覆盖、路径覆盖。这种空前的测试完整性，使代码中的缺陷无所循形。VisualUnit国产的单元测试工具，据说申请了多项专利71