|
问题： 1没有数据构造和清理的过程 用户数据，业务数据 2．没有对业务数据返回和业务逻辑做判断的一个过程 3. 对于一个业务测试用例单一 4. 方法名比较乱 5.测试方法前没有注释 6.重复代码要重构
单元测试用例目的： 提供覆盖率： 测试的覆盖种类 在开始测试时，要先声明一下，无论你设计多少测试用例，无论你的测试方案多么完美，都不可能完全100%的发现所有BUG，我们所需要做的是用最少的资源，做最多测试检查，
最终目的：通过不通的用例输入来测试代码的业务逻辑问题，在版本发布前提早发现问题。
方式： 所有用例执行后，能覆盖每行代码。
如何设计测试用例：
1、了解软件的原始需求(测试目的) 在编写一个软件或者模块的测试用例时候，一定要明白这个功能的原始需求，也就是软件的使用者(客户)的需求。理解原始需求后，编写的测试用例才更有目的性。 2、熟悉软件的功能需求(测试点) 这个功能需求是指软件的细化需求点，这个一般在需求文档里面都会体现。这里要做的是把需求稳定的“粗略”的需求，细化成一个个小需求点。 熟悉功能需求后，要知道软件是怎么使用的，这也才能覆盖到各种操作。 总之，测试用例一定要全部覆盖所以的需求点，这是最基本的一点。 3、熟悉软件的实现原理(测试点) 在理解原始需求和软件的功能需求后，软件有什么功能，如何使用就基本上都知道啦。这时候在根据需求编写测试用例，基本上都能覆盖的比较全面。 在此基础上，熟悉软件的实现原理，理解软件的内部处理。 (1)熟悉原理的过程是进一步深入熟悉软件的过程。如果单单是从需求点上面覆盖案例，测试用例只能覆盖“表面”的一层。一些内部的处理流程也许没有覆盖到， 而这些没有覆盖到的代码很可能就是一个风险点。 (2)熟悉模块原理后，还有一点就是易于分析软件模块的关联性。一个大型的软件，都是一些小模块的组合而成。软件越是大型，耦合就越大。“互相影响”就会越多， 设计用例单单是从模块本身考虑的话，很可能就会对其他模块造成风险。 4、用户场景和网上问题(测试点) 从用户的使用场景考虑，这些在一些网络设备比较重要。比如软件后期在一些真实的使用环境中使用。 还要就是从一些网上问题总结出来的，那些地方容易出错。在设计案例的时候需要考虑进去
写好单元测试的建议： ·
一次只测试一个代码单元 ·
不要做无谓的断言 ·
让每个单元测试保持独立 ·
模拟所有的外部服务和状态 ·
不要使用测试单元配置 ·
命名单元测试要清晰一致 ·
先为那些有最少依赖的方法写单元测试 ·
不光是对外暴露的方法，所有方法都应该写单元测试 ·
每个单元测试方法只用一个断言 ·
为例外和异常创建单元测试 ·
使用最合适的断言方式 ·
断言的参数顺序要合适 ·
确保测试代码独立于生产代码之外 ·
单元测试内不要有任何打印输出 ·
测试类中不要有静态变量 ·
不要写自己的catch代码块，只有test失败的情况，不存在catch情况 ·
不要依赖间接测试 ·
使用build脚本整合测试用例 ·
不要跳过单元测试 ·
使用XML格式化工具捕获结果
|
|
|
