您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 测试用例 > 正文

详谈测试用例

发表于:2018-07-12 作者:祝新新 来源:网络转载 点击数:
  简述:用文字描述出系统测试时的操作步骤
  好处:
   1)清晰思路、避免遗漏
   当系统功能多且复杂时,根据系统每个模块,拆分功能点,花点时间思考并整理成文档,尽可能结合功能与业务,模拟不同场景,从根本上避免了直接测试系统的“手忙脚乱”。
   2)明确测试进展
   参考测试用例,可以清晰看到哪些用例执行了,哪些用例没有执行,从中看到测试进行到哪一步,以及结合问题管理平台,直观地从测试角度,分析项目进展。
   3)系统模块缺陷率
   根据测试用例发现的问题,可以看到哪个功能模块出现的bug较多。
  方法:
   1)等价类划分:输入的子集中选择,假如输入要求输入数字1到10,那么输入4和7去验证;
   2)边界值:输入支持的最大值,假如一个文本输入框最大值为100,输入的内容超过101;
   3)因果图:判定表,通过因果关系判定;
   4)错误推测法:基于测试经验推测系统在什么样的操作可能会出现错误;
  元素:
   1)目录
   根据拆分的系统功能点,每个功能点可以用目录的方式区分,如一个系统的系统管理-用户管理-用户添加,那么系统管理就是一级目录,用户管理就是二级目录,用户添加就是三级目录;
   2)测试项
   同上,根据三级目录,一般用户添加包括的元素有用户名、密码输入框、保存按钮、取消,那么每个元素都可以分成一个测试项;
   3)操作步骤
   每一个测试项,都对应相应的操作步骤,可以分成操作步骤1、操作步骤2,操作步骤可以细化到,点击添加用户的按钮、输入框输入某某用户名密码点击保存按钮;
   4)预期结果
   操作步骤,在完成一系列动作之前,都要有对应预期结果作为参考,这个参考就是最初业务部门提供的需求分析文档,根据需求分析文档来告诉我们每一个功能要有什么样的结果;
   5)实际结果
   操作步骤,完成之后,需要记录实际的情况,如果与预期结果不符,就可以归于bug;
   考虑是否可以将实际结果改成注释,避免与预期结果一一对应关系,解耦合。
   6)优先级
  探索性测试
   在设计测试用例时,并不能完全保证每个功能每个场景都设计到位,而且单纯执行测试的时候非常枯燥,那么加入一点发散性思维,进行一些非常规性操作,以用户的心态去使用系统,或是尽情地“破坏”系统,发现系统的问题。
   真正的探索性测试需要对产品的深入了解,以及软件开发技术有一定的深度和宽度。
  用例评审
   测试用例编写完成后,需要在测试内部进行一次评审,评审的内容包括:功能是否完整、需求是否符合,使每一个测试人员在系统测试过程中,不存在主体思维的偏差。
   同时用例评审也是一个很好的学习过程,每一位测试人在介绍系统时,能够意识到各自设计用例时的不足,包括自动化、性能都可以进行技术的探讨。
  不需要用例情况:
   1)功能过于简单 2)急于交付,弊端就是不能保证测试的覆盖率。