单元测试用例设计原则

点击查看原文

问题：

1没有数据构造和清理的过程

用户数据，业务数据

2．没有对业务数据返回和业务逻辑做判断的一个过程

3. 对于一个业务测试用例单一

4. 方法名比较乱

5.测试方法前没有注释

6.重复代码要重构

 

 

单元测试用例目的：

提供覆盖率：

        测试的覆盖种类
        1.语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。
        2.判定覆盖（也叫分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次。
        3.条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次。
        4.判定——条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少执行一次。
        5.条件组合测试：设计足够的测试用例，运行所测程序，使程序中每个判断的所有条件取值组合至少执行一次。
        6.路径测试：设计足够的测试用例，运行所测程序，要覆盖程序中所有可能的路径。
        用例的设计方案主要的有下面几种：条件测试，基本路径测试，循环测试。通过上面的方法可以实现测试用例对程序的逻辑覆盖，和路径覆盖。

 

 在开始测试时，要先声明一下，无论你设计多少测试用例，无论你的测试方案多么完美，都不可能完全100%的发现所有BUG，我们所需要做的是用最少的资源，做最多测试检查，

 

最终目的：通过不通的用例输入来测试代码的业务逻辑问题，在版本发布前提早发现问题。

 

方式：

所有用例执行后，能覆盖每行代码。

 

如何设计测试用例：

 

　1、了解软件的原始需求(测试目的)

　　在编写一个软件或者模块的测试用例时候，一定要明白这个功能的原始需求，也就是软件的使用者(客户)的需求。理解原始需求后，编写的测试用例才更有目的性。

　　2、熟悉软件的功能需求(测试点)

　　这个功能需求是指软件的细化需求点，这个一般在需求文档里面都会体现。这里要做的是把需求稳定的“粗略”的需求，细化成一个个小需求点。

　　熟悉功能需求后，要知道软件是怎么使用的，这也才能覆盖到各种操作。

　　总之，测试用例一定要全部覆盖所以的需求点，这是最基本的一点。

　　3、熟悉软件的实现原理(测试点)

　　在理解原始需求和软件的功能需求后，软件有什么功能，如何使用就基本上都知道啦。这时候在根据需求编写测试用例，基本上都能覆盖的比较全面。

　　在此基础上，熟悉软件的实现原理，理解软件的内部处理。

　　(1)熟悉原理的过程是进一步深入熟悉软件的过程。如果单单是从需求点上面覆盖案例，测试用例只能覆盖“表面”的一层。一些内部的处理流程也许没有覆盖到，

　　而这些没有覆盖到的代码很可能就是一个风险点。

　　(2)熟悉模块原理后，还有一点就是易于分析软件模块的关联性。一个大型的软件，都是一些小模块的组合而成。软件越是大型，耦合就越大。“互相影响”就会越多，

　　设计用例单单是从模块本身考虑的话，很可能就会对其他模块造成风险。

　　4、用户场景和网上问题(测试点)

　　从用户的使用场景考虑，这些在一些网络设备比较重要。比如软件后期在一些真实的使用环境中使用。

　　还要就是从一些网上问题总结出来的，那些地方容易出错。在设计案例的时候需要考虑进去

 

写好单元测试的建议：

·         一次只测试一个代码单元
当你试图测试一个代码单元，而这个单元有多个用例。

·         不要做无谓的断言

·         让每个单元测试保持独立

·         模拟所有的外部服务和状态

·         不要使用测试单元配置

·         命名单元测试要清晰一致

·         先为那些有最少依赖的方法写单元测试

·         不光是对外暴露的方法，所有方法都应该写单元测试

·         每个单元测试方法只用一个断言

·         为例外和异常创建单元测试

·         使用最合适的断言方式

·         断言的参数顺序要合适

·         确保测试代码独立于生产代码之外

·         单元测试内不要有任何打印输出

·         测试类中不要有静态变量

·         不要写自己的catch代码块，只有test失败的情况，不存在catch情况

·         不要依赖间接测试

·         使用build脚本整合测试用例

·         不要跳过单元测试

·         使用XML格式化工具捕获结果