本文将带你了解软件测试技术之单元测试编写应该注意哪些问题，希望对大家学测试技术有所帮助

单元测试是通过对单元的某个或者某些内容进行针对性的测试以提高项目整体质量的一种方式。针对单元测试的特殊性，并没有必要针对所有的内容都进行单元测试，如果编写单元测试方案成为了困扰大家的一个问题，下面我们来开一下 单元测试 的编写应该注意哪些问题。
1.在单元测试方面的过程中必须要确保每个测试方法与其它所有的测试方法的关系是正交的（相对独立）
1.1一个测试方法只能用来测试一种行为，不能把一种行为分散到多个测试方法中，否则如果日后行为发生改变，就需要修改多个地方，造成比较繁琐的问题。
1.2在单元测试中不要做不必要的断言（Assert），编写测试方法前一定要先搞清楚验证的行为是什么，只有了解了到自己要做的内容和相应的行为作用才能够更好的实现高效稳定的测试行为
单元测试中的一些规则和思路
a)滥用断言的问题。这个问题是很多新手和有一定工作经验的人经常会犯的一个错误，事实上我们要只得到滥用断言不会提高测试覆盖率，这是一个没有明确测试思路的结果导向的一种体现。
b)如果某个行为不属于测试方法验证的目标，就应该停止对其测试。关于这一点，TDD有个说法为：一个测试方法有且仅有一个断言。
c)要时刻谨记：单元测试的目的是为了验证方法的行为是否符合预期，而不是监视方法在各种情况的行为。
1.3一次只测试一个代码单元
a)你设计的软件架构必须支持对每个单元的独立测试（一个类或功能相关的几个类），不然单元测试之间会有重叠，在这种情况下，某处测试代码的微小改动可能造成数目庞大的级联修改。如果你的软件架构做不到支持单元测试，那么软件质量就无法得到保证，建议使用InversionOfControl（控制反转）的思想进行重构。
b)排除所有对外部服务和状态的依赖
引用外部服务会导致测试重叠，而对外部状态的依赖意味着单元测试在不同的情况会有不同的输出。如果你编写的单元测试必须按照一定的次序运行或者必须在数据库和网络就绪后才能运行，说明你已经走在了错误的道路上。（有时，单元测试代码可能会修改静态变量的值，尽量不要这样做，如果无法避免，至少应在测试结束后将修改过的变量复原）。避免添加前置条件；还要避免在独立的单元测试之前统一执行配置代码（原文为SetupCode），否则我们无法确定每个单元测试依赖的假设是什么，同时这也意味着你的单元测试思路出了问题。
c)不要对配置代码做单元测试。
我们先来明确配置代码的定义。配置代码不是每个代码单元的公共部分。配置代码是可以复制粘贴的，我个人将ASP.NETMVC中的filter也归为配置代码的范畴，像[Authorize]或[RequiresSs]之类的标签则是掺杂在普通代码中的配置代码，对于这些代码，最好使用集成测试的方法，从外部观察它们的行为，使用单元测试是没有意义的，这对你的设计没有帮助，也无法帮您检测缺陷。


    
       

本文由职坐标整理并发布，希望对同学们有所帮助。了解更多详情请关注职坐标软件测试之测试技术频道！