测试用例的编写方法步骤

测试用例的编写方法

嗯，做测试，好多时间是在琢磨分析测试用例怎么去写，这个每个公司规范可能不太一样，但是大致思想是一致的。都是想要通过测试用例，把每一个分析到位，进行测试。测试用例包括像测试编号，测试所属模块，测试步骤，预期结果，测试结果这些栏位，当然这些还可以在细分，比如我们有些时候还会根据模块差异，平台差异等设计其他测试用例规范形式。

用例编写步骤：

拿到测试需求 -> 分析需求（画思维导图） -> 编写用例 -> 划分用例优先级

**

测试用例栏位

**

           测试用例编号 
           测试用例名称(测试注册用例) 
           测试用例设计者 
           软件版本号 
           测试目的 
           参考信息  
           测试环境 
           输入数据(页码) 
           操作步骤(打开网站,输入信息,点击搜索…等)  
           预期结果
           测试结果 
           测试模块 
           前置条件

**

用例编写特性：

**

• · 一致性：主要包括用例模板一致；各同事的编写手法一致；以及用例的细粒度一致。

  · 覆盖率：主要包括对需求的覆盖（也包含隐含的需求）；新需求可能对那些功能会 产生影响的覆盖；对各种场景的覆盖等
  。

  ·可执行性：主要是指步骤易于理解、信息描述准确、且能快速识别出测试点 。
  
  ·执行准确性：是指用例执行的准确度，本身没什么技术含量。但这里需要注意的是执行人对待执行用例的态度。不要因为用例简单或者一些外界的因素，导致部分用例未实际执行标为通过的情况。
  
  ·持续更新：要及时不断的更新，要尽量减少用例库中失效的用例 。
  
  ·复用性：主要用例可以被不断的复用，从而减少维护成本
  

**

编写测试用例常用的五种方法

**
1. 等价类
具有相同属性或方法的集合；
该集合中某个个体所表现的特征与其他个体一致；
有效等价类：输入是合理的、有意义的、可接受的；
无效等价类：输入时不合理的、无意义的、不可接受的；
根据需求，划分有效等价类和无效等价类；
设计一个新的测试用例，使其尽可能的覆盖所有尚未覆盖的有效等价类，知道所有的有效等价类都被覆盖；
设计一个新的测试用例，使其只覆盖一个无效等价类，知道覆盖所有的无效等价类；
2. 边界值
比如小组名称长度是4-12位
确定离点
整数域[4，12]：上点是4，12且都在域内，离点是3，13；
整数域(4，12]：上点是4，12，一个在域内，一个在域外，离点是5，13；
整数域(4，12)：上点是4，12，都在域外，离点是5，11；
边界值应用规则
如果需求规定了取值范围：[4，12]，边界值取：4，12，3，13，5；
如果需求规定了取值的个数比如4件商品5折，边界值取：3，4，5；
3. 场景设计法
分析软件的应用场景，从实际应用场景的角度来设计测试用例，是一种面向用户的测试用例的设计方法；
关心用户做什么，而不关系产品做什么；
实用性强，设计的用例有价值，不校验单个功能节点的正确性，只关心流程是否走通；
基本流（正常流），比如输入正确的用户名和密码，登录成功；
备选流，第1次输入错误的用户名和密码，第2次输入正确的用户名和密码；
异常流，一直输入错误的用户名或密码；
场景法设计用例的步骤
根据实际场景，画出流程图，确定基本流和备选流；
根据基本流和备选流，确定场景；
针对每一个场景，设计测试用例；
4. 判定表
判定表是分析和表达多种输入条件下，系统执行不同动作的工具；
将复杂的逻辑关系和多种条件组合的情况表达的清晰明了；
条件桩：系统的所有输入；
条件项：针对所有条件桩的取值；
动作桩：系统可能采取的操作；
动作项：根据动作桩取值情况下应采取的动作；
动作项和条件项组合一起，形成业务逻辑处理规则；
确定条件桩和动作桩；
设计和优化判定表；
填写动作项；
提取测试用例；
5. 因果图
用于描述输入与输入、输入与输出之间存在的约束关系；
输入与输出之间的关系有：恒等、与、或、非；
输入与输入之间的关系有：异、或、唯一、要求；
设计步骤
根据需求文档确定输入与输出；
根据输入与输入、输入与输出的关系，画出因果图；
画出判定表，根据因果图，得到最终的判定表；
根据判定表得到用例规则，细化用例；