软件单元测试(Software Unit Testing)

软件单元测试

作者 Paul Scanlon, 陈尚义翻译

http://hubpages.com/hub/software-unit-testing

        软件测试重要的一个方面是：最早发现一个软件错误或缺陷，然后以较小代价、比较容易地去修复它们。开发者一写完代码就立即修复错误或缺陷，这是解决问题的最早机会。这类测试叫做单元测试。尽管一般来说，此项工作由开发团队去完成，但是单元测试是质量保证的重要一环，应引起全体员工的高度重视。

     解决复杂问题的计算机程序，其设计可是极其复杂的。可能部署很多例程、对象和方法来完成简单的任务，但这些任务很难再映射到原来的规格说明书。当这些简单的任务一起共同构成最终的规格说明书时，任何任务中的错误都可能导致连带反应，影响很多方面，而且很难找到根源。用面向对象的语言（C++，C#和java）对象的继承、工厂和模板可能使得这个过程更加困难。单元测试采用识别这样的方法，识别最小可能的、可测试的“单元”，并为其设计测试用例。这些代码片段正常情况下是一个单个的例程（routine）或对象方法，很可能他们只有程序代码接口，而不是一个用户图形界面。因为这个原因，单元测试需要具体的编程知识，包括使用的编程语言和环境（内部程序结构、程序库等）。一个常规的测试团队不必通过定义、书写脚本来进行这样的测试，而是编程中的一个环节。这样对待单元测试有很多好处，但也有不足。

       一个最大的好处是，单元测试自动化的先天性优势。因为测试可在代码级上进行，测试自身可以是build过程的一部分，即每次做build时，就进行单元测试。有一些自动化工具可用来做这些--适用于java程序单元测试的junit，适用于c/c++的cunit。这些工具不仅可以帮助测试用例的书写，而且可以帮助单元测试自动化和测试报告。在互联网上有很多资源可以使用。

       如果单元测试正确地做了，大部分软件在提交测试组之前，缺陷将会发现并修复。这对提高产品质量，降低开发成本是有帮助的。然而，在获得优势之前，还有很多障碍。

       一个重要的问题是经验。开发者不擅长于书写完整的测试用例。这并不奇怪，因为他们总认为这些应该由测试组去完成。如果一个例程、对象或一个方法没有经过充分测试，那么极有可能造成一个很显然的BUG溜走，而且在往后的阶段里很难抓住它。一般来说，开发者自己给自己的代码写单元测试用例。这样会带来一个问题，即漏写一个功能的代码，就会漏测那个功能。一个更好的办法是，让程序员为别人的代码写单元测试。

       主要的组织上的问题可能是缺乏管理。很多企业不认为单元测试重要。项目如果进度紧张就不可避免地砍去一些不必要的工作，单元测试首当其冲。然而，正象上面所说的那样，单元测试的目的是为了更早发现缺陷—如果缺陷没有在单元测试阶段发现的话，在后续阶段就会发现，那将花费更多的金钱和时间。

 有一些开发方法，它们很严重地依赖自动化的单元测试，最为瞩目的方法是敏捷编程（Agile），他们把这些测试当成实际的文档从而依据文档来进行编程。这样做，首先是促进了测试的方法，其次是提高代码的质量。

总结：

• 单元测试是软件质量保证计划的重要组成部分，不仅仅是开发者的事。
• 单元测试应该由开发团队来完成。
• 开发者最好不要测试自己的程序。
• 将单元测试自动带到软件build 过程中，能保证单元测试在每次新build中完成。
• 如果时间紧张，砍去单元测试是得不偿失的，这将加大未来成本。

One of the most important aspects of testing computer software is that the earliest you can find an error or bug, then the easier and cheaper it is to fix. There is no earlier opportunity to resolve such a problem, then directly after a developer has written the code. This sort of testing is called Unit Testing, and although a development team may be responsible for conducting it, unit testing is an important part of any quality assurance test plan.

Computer programs that are written to solve any none trivial task, can be very complex in their design. Many routines, objects and methods can be employed to conduct simple tasks that may be difficult to map back to the original specification. When these simple tasks are joined together to form the final application, an error in any one, may be presented in numerous places, and be difficult to track down. With object orientated languages (c++, c# and java to name just a few) object inheritance, factories and templates can make this process even more difficult. Unit testing takes the approach of identifying the smallest possible ‘unit’ of testable code and writing a test case for it. These sections of code are normally single routines or object methods, which will likely only have a program code interface, rather than a user GIU. For this reason detailed programming knowledge is required, both of the language used, and the environment (internal program structure, libraries etc). This prevents a normal test team from defining, scripting and conducting such tests. Rather, it is integrated into the actual programming cycle. This integration has a number of advantages, but also disadvantages as well.