单元测试用例设计原则

点击查看原文

问题：

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格式化工具捕获结果

单元测试用例设计原则相关推荐

自动化测试用例设计原则
自动化测试用例设计原则:每一个用例都是一个闭合的业务操作.用例之间要保持独立 ,不要有操作上的依赖关系,就算有也是测试数据上的依赖.第二个用例依赖第一个用例产生的数据. 转载于:https://w ...
自动化测试用例设计原则（接口自动化用例设计的基本原则）
自动化测试用例设计原则: 1.一个脚本是一个完整的场景,从用户登陆操作到用户退出系统关闭浏览器. 2.一个脚本脚本只验证一个功能点,不要试图用户登陆系统后把所有的功能都进行验证再退出系统 3.尽量只做 ...
自动化测试用例设计原则（转）
内容摘自:http://www.cnblogs.com/jshtest/p/6362677.html 一.自动化测试存在的真正意义: 主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工作中解脱 ...
软件测试单元测试用例设计,单元测试的用例设计
首先,我们先来思考一个问题:单元测试中,哪一个环节更重要? 要回答这个问题,我们先需要了解单元测试到底有哪些环节,读到这里,请暂停一分钟,回忆一下我们平时的单元测试实践(请最小化浏览器). 对于单元测 ...
【软件测试系列三】《测试用例编写原则与设计方法》
1. 概述 1.1. 目的 1.2. 使用范围 2. 测试用例编写原则 2.1. 系统性 2.2. 连贯性 2.3. 全面性 ...
单元测试用例_前端单元测试实践
一说到单元测试,可能对于业务一线同学来说,心理立马就会无形中有一种压迫感,心想 "业务都做不完了,写个球的单元测试,先保证功能完备,赶紧上线才是王道",这句话的核心是以业务为重,没 ...
【转】自动化测试用例设计的原则
很多公司在实施自动化测试的过程中,往往会把所有的手工测试用例作为自动化测试用例,并且直接进行脚本的开发工作,甚至有些公司不写自动化测试用例,直接想当然地开发测试脚本,这些都是极其不规范的做法,甚至很有 ...
设计模式之美总结（设计原则篇）
title: 设计模式之美总结(设计原则篇) date: 2022-10-27 17:31:42 tags: 设计模式 categories: 技术书籍及课程 cover: https://cover ...
设计原则与思想：设计原则12讲
文章目录设计原则与思想:设计原则(12讲) 理论一:对于单一职责原则,如何判定某个类的职责是否够"单一"? 如何理解单一职责原则(SRP)? 如何判断类的职责是否足够单一? 类的 ...
代码设计的内功——代码设计原则
引言好代码是设计出来的,也是重构出来的,更是不断迭代出来的.在我们接到需求,经过概要设计过后就要着手进行编码了.但是在实际编码之前,我们还需要进行领域分层设计以及代码结构设计.那么怎么样才能设计出来 ...

单元测试用例设计原则

单元测试用例设计原则相关推荐

最新文章

热门文章