编写测试用例
2018-09-21 11:14:03 0 举报AI智能生成
登录查看完整内容
为你推荐
查看更多
软件测试，功能测试用例编写经验和原则，方法论
作者其他创作
大纲/内容
如何编写测试用例
用例标准
黑盒测试关注输入和输出，那么用例编写时输入就是我们的条件，输出则为结果
完整的用例应该是在某某条件下，怎么做，得到什么结果
一个用例应该描述一种情况，并且是可执行的，避免描述多个情况
用例选择
等价类划分
一个等价类或者等价划分是指测试相同目标或者暴露相同软件缺陷的一组测试用例
在寻找等价划分时，考虑把软件具有相似输入、输出、操作的分在一组。这些组就是等价划分
数据测试
边界条件
指软件运行在计划操作界限的边界的情况
如果要选择在等价划分中包含哪些数据，就根据边界来选择
测试边界
提出边界条件时，一定要测试这些数据
临近边界的有效数据
最后一个可能有效的数据
刚超过边界的无效数据
次边界条件
用户无感知，但软件内部存在的边界情况
默认、空白、空值、零值和无
非法、错误、不正确、垃圾数据
状态测试
测试软件的逻辑流程
状态转换图
梳理被测实体的状态转换逻辑，从而组织用例
状态扭转前置条件
合法状态
非法状态
失败状态测试
竞争条件和时序错乱
并发问题
跳过限制，试图直接扭转实体状态
重复、压迫和重负
重复执行相同操作，如幂等性
压迫，限制执行条件，如网络异常，外部异常
重负，加大处理量，如提供大量任务
用例组织
基于角色行为的用例设计
描述
从业务包含的角色出发，梳理角色的行为
优劣势
优势
能很好地展示用户的行为，以及可以覆盖用户的使用场景
用例按角色独立编写，多人测试时可各自编写
劣势
角色交互时存在用例重复的情况
适用场景
业务流程包含明显的角色及其行为
基于业务场景的用例设计
梳理所有业务场景，关联所有用户行为和系统功能
用例结构清晰，容易覆盖核心业务流程
用例重合性低
用例分工不明确，不利于多人合作编写
场景容易梳理不全
单一功能
接口类
基于产品原型的用例设计
按照产品原型，页面进行用例编写和组织
编写简单，直接按原型组织用例
分工简单
场景容易遗漏
用例组织容易混乱
几乎所有场景，复杂或单页面功能都适合
基于实体状态扭转的用例设计
通过描述一个实体的完整生命周期或状态，对涉及的用户行为、操作和系统功能进行编写
状态扭转可穷举，易于用例划分和编写
始终关注在实体上，清晰各种状态
用例组织上存在不连贯的情况，可能不利于执行
用例编写上分工可能不明确，存在用例重复
有明显状态扭转的业务功能，并且主要是围绕实体进行操作
必须花费一定时间进行用例的组织，更有利于用例的编写、分享、执行
特殊用例
安全性
越权
水平权限校验
垂直权限校验
敏感信息
展示层
传输层
存储层
常见安全漏洞
SQL注入
xss
未校验的重定向
csrf
兼容性
多端实现
客户端
wap
pc
...
浏览器兼容
客户端兼容
系统
版本
体验性
交互是否合理
文案是否会引起疑惑
页面跳转是否合理
关联性
页面是否存在其他功能，是否会受影响
性能
是否有多余的io，比如多余的数据库查询
sql检查
是否可以添加缓存，缓存添加是否合理
数据预估
预估的访问量有多少
接口响应时间是多少
职业：本科
0 条评论
回复 删除
下一页
