使用 Visual vs编程软件Studio 进展 C++单元测试
什么是单元测试？单元测试〔unit testing〕在软件开发领域有着悠久的历史。在大多数有关单元测试的观念中都有这么一个共同的理念，即它们由一组独立的测试构成，其中每个测试针对一个单独的软件组件。在过程式程序设计的代码中，“单元”一般来说指的就是函数，而在面对对象的代码中则指的是类。
而单元测试则做到了大型测试所不能做到的那些事情。利用单元测试可以独立地对某一段代码进展测试。我们可以将测试分组以便在某些特定条件下运行某些特定的测试，并在其他条件下运行另一些测试。我们还可以快速定位错误。假设认为在某段代码中存在着一个错误而且又可以在测试用具中使用这段代码的话，我们通常能够快速地编写出一段测试，看看我们所推想的错误是不是真的在那里。
〔一〕关于单元测试的一些流行误会〔反面即为单元测试的好处〕
1.单元测试是在铺张时间
一旦编码完成， 开发人员总是会迫切期望进展软件的集成工作，这样他们就能够看到实际的系统开头启开工作了。 这在外表上看来是一项明显的进步，而象单元测试这样的活动或许会被看作是通往这个阶段点的道路上的障碍， 推迟了对整个系统进展联调这种真正有意思的工作启动的时间。
在这种开发步骤中，真实意义上的进步被外表上的进步取代了。系统能够正常工作的可能性是很小的， 更多的状况是布满了各式各样的 Bug。在实践中，这样一种开发步骤经常会导致这样的结果：软件甚至无法运行。
更进一步的结果是大量的时间将被花费在跟踪那些包含在独立单元里的简洁的 Bug 上面，在个别状况
下，这些 Bug 或许是琐碎和微缺乏道的，但是总的来说，他们会导致在软件集成为一个系统时增加额外的工期，而且当这个系统投入使用时也无法确保它能够牢靠运行。
在实践工作中，进展了完整打算的单元测试和编写实际的代码所花费的精力大致上是一样的。一旦完成了这些单元测试工作，很多 Bug 将被订正，在确信他们手头拥有稳定牢靠的
部件的状况下，开发人员能够进展更高效的系统集成工作。这才是真实意义上的进步，所以说完整打算下的单元测试是对时间的更高效的利用。而调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。
点评：假设产品的规模格外小(例如小工具)，并且产品的质量不重要(或无所谓)，那么“单元测试是在铺张时间”这样的说法在某种程序上是正确的。
假设产品质量格外重要，那么就意味着即使你不在单元测试阶段投入时间觉察并修改 bug，存在的 bug 也会在后续的阶段被觉察，需要说明的是bug 觉察得越晚，修改它所付出的代价越大。这样违反原则：尽早觉察并修改 bug，以削减软件开发本钱。
2.单元测试仅仅是证明这些代码做了什么
这是那些没有首先为每个单元编写一个具体的规格说明而直接跳到编码阶段的开发人员提出的一条普 遍的埋怨，当编码完成以后并且面临代码测试任务的时候，他们就阅读这些代码并出它实际上做了什么， 把他们的测试工作基于已经写好的代码的根底上。固然，他们无法证明任何事情。全部的这些测试工作能够说明的事情就是编译器工作正常。是的，他们或许能够抓住(期望能够)罕见的编译器 Bug，但是他们能够做

的仅仅是这些。假设他们首先写好一个具体的规格说明，测试能够以规格说明为根底。代码就能够针对它的规格说明，而不是针对自身进展测试。这样的测试仍旧能够抓住编译器的Bug，同时也能到更多的编码错误，甚至是一些规格说明中的错误。 好的规格说明可以使测试的质量更高，所以最终的结论是高质量的测试需要高质量的规格说明。在实践中会消灭这样的状况：一个开发人员要面对测试一个单元时只给出单元的代码而没有规格说明这样吃力不讨好的任务。你怎样做才会有更多的收获，而不仅仅是觉察编译器的Bug？ 第一步是理解这个单元原本要做什么，不是它实际上做了什么。比较有效的方法是倒推出一个概要的规格说明。这个过程的主要输入条件是要阅读那些程序代码和注释，主要针对这个单元，及调用它和被它调用的相关代码。画出流程图是格外有帮助的，你可以用手工或使用某种工具。可以组织对这个概要规格说明的走读(Review)，以确保对这个单元的说明没有根本的错误，有了这种最小程度的代码深层说明，就可以用它来设计单元测试了。
点评：合理的单元测试不仅可以保证单元代码正确实现，还可以在编码过程中用来调试单元代码、以及随时了解单元测试掩盖了多少单元代码。
3.我是个很棒的程序员， 我是不是可以不进展单元测试？
在每个开发组织中都至少有一个这样的开发人员，他格外擅长于编程，他们开发的软件总是在第一时间就可以正常运行，因此不需要进展测试。你是否经常听到这样的借口？
在真实世界里，每个人都会犯错误。即使某个开发人员可以抱着这种态度在很少的一些简洁的程序中应付过去。但真正的软件系统是格外简单的。真正的软件系统不行以寄期望于没有进展广泛的测试和 Bug 修改正程就可以正常工作。
编码不是一个可以一次性通过的过程。在真实世界中，软件产品必需进展维护以对操作需求的转变作出反响，并且要对最初的开发工作遗留下来的 Bug 进展修改。你期望依靠那些原始作者进展修改吗？这些制造出这些未经测试的原始代码的资深专家们还会连续在其他地方制造这样的代码。在开发人员做出修改后进展可重复的单元测试可以避开产生那些令人不快的负作用。
点评：我成认你是一个很棒的程序员，你很少犯错误。但很少犯错误不等于不犯错误，并且你的代码一
定有其他人维护的时候(比方你离职了)。试问一下，当其他人修改你写的代码的时候，怎样才能保证他修改后的正确性呢？因此，答案是显而易见地。
4.不管怎样，集成测试将会抓住宅有的 Bug
我们已经在前面的争辩中从一个侧面对这个问题进展了局部的阐述。这个论点不成立的缘由在于规模越大的代码集成意味着简单性就越高。假设软件的单元没有事先进展测试，开发人员很可能会花费大量的时间仅仅是为了使软件能够运行，而任何实际的测试方案都无法执行。一旦软件可以运行了，开发人员又要面对这样的问题：在考虑软件全局简单性的前提下对每个单元进展全面的测试。这是一件格外困难的事情，甚至在制造一种单元调用的测试条件的时候，要全面的考虑单元的被调用时的各种入口参数。
在软件集成阶段， 对单元功能全面测试的简单程度远远的超过独立进展的单元测试过程。最终的结果
是测试将无法到达它所应当有的全面性。一些缺陷将被遗漏，并且很多 Bug 将被无视过去。
让我们类比一下，假设我们要清洗一台已经完全装配好的食物加工机器！无论你喷了多少水和清洁剂， 一些食物的小碎片还是会粘在机器的死角位置，只有任其腐烂并等待以后再想方法。但我们换个角度想想， 假设这台机器是拆开的，这些死角或许就不存在或者更简洁接触到了，并且每一局部都可以毫不费力的进展

清洗。
点评：假设每个开发人员都这样想，那么集成测试有可能进展不下去了，例如：系统集成后格外简洁崩溃，无法进展测试。
另外，即使能够进展正常测试，需要说明的是bug 觉察得越晚，修改它所付出的代价越大。这样违反原则：尽早觉察并修改 bug，以削减软件开发本钱。
5.单元测试的本钱效率不高
一个特定的开发组织或软件应用系统的测试水平取决于对那些未觉察的 Bug 的潜在后果的
重视程度。这种后果的严峻程度可以从一个 Bug 引起的小小的不便到发生屡次的死机的状况。这种后果可能经常会被软件的开发人员所无视(但是用户可不会这样)，这种状况会长期的损害这些向用户提交带有 Bug 的软件的开发组织的信誉，并且会导致对将来的市场产生负面的影响。相反地，一个牢靠的软件系统的良好的声誉将有助于一个开发组织猎取将来的市场。
很多争辩成果说明， 无论什么时候做出修改都要进展完整的回归测试， 在生命周期中尽早地对软件产品进展测试将使效率和质量得到最好的保证。Bug 觉察的越晚，修改它所需的费用就越高，因此从经济角度来看，应当尽可能早的查和修改 Bug。在修改费用变的过高之前，单元测试是一个在早期抓住 Bug 的时机。
相比后阶段的测试，单元测试的创立更简洁，维护更简洁，并且可以更便利的进展重复。从全程的费用来考虑，相比起那些简单且旷日长久的集成测试，或是不稳定的软件系统来说， 单元测试所需的费用是很低的。
点评：单元测试是一个在早期抓住 bug 的时机，符合原则：尽早觉察并修改 bug，以削减软件开发本钱。
〔二〕单元测试不能做什么
1.单元测试解决不了设计失误带来的问题，即使最低劣的设计也可能通过单元测试。
2.单元测试解决不了由于设计和编码不当带来的性能问题。
3.单元测试不能解决产品的可用性和易用性问题。
4.单元测试通常不能解决类和类的一些规律问题。
5.单元测试不能用来测试需要很长时间才能完成的操作(例如：数据连接超时)。
〔三〕好的单元测试(Visual Studio) 标准

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。