不得不说之用例设计
作者:网络转载 发布时间:[ 2014/7/23 14:35:23 ] 推荐标签:
自动化测试用例如何设计,对于新手来说也是比较难理解的问题。
不少新手刚刚掌握了写脚本的能力,一上来拿着功能测试用例一条一条的转化成自动化用例。在写的过程中,会发现诸多问题,例如,脚本中重复代码很多,一个脚本的执行结果影响到另一个脚本的执行,有些功能用例很难转化成自动化用例等。
站在用户角度设计自动化
在功能测试的时候我们一般会遵循这个原因,但是自动化测试往往可以实现更强大的功能,所以,我们在设计脚本的时候很容易违背这个原则。例如,你要获得的数据是用户不可见的,你要判断用例是否成功的信息也是用户不可见的,或者你要模拟的是用户永远不可能做的操作等。
设计简单傻瓜的用例
自动化脚本本来是很傻瓜的。记得有同学问我,百度输入有个自动联想功能,是在用户输入的过程中自动配置热门搜索的关键词,例如,用户输入“自”,会自动联想“自我评价”,“自行车”等。用继续输入“自动”,会自动联想“自动化”,“自动关机”,“自动档”等。他想定位自动联想下拉列表的某个关键词,这个关键词是百度根据用户搜索热度的变化而变化的。
再比例有同学问我,下拉列表功能,我想脚本执行时随机选择某一个选项,那么如何如何去判断随机的结果呢?换句话说,你都不知道你做了什么,怎么去判断做的结果对不对?
所以,我们在设计用例时尽量考虑简单傻瓜的用例,操作步骤简单,预期结果容易判断等。
从简单开始
对于新需要自动化的项目来说,自动化测试的实施是循序渐进的,不要一上来设计几百条用例,而是逐步的将功能用例转成自动化用例,在转的过程中需要不断的调整测试结构。然后,再增加稳定的测试用例。然后,再调整测试结构。随着功能的增加你的自动化测试框架也在逐渐稳定,基础测试用例也在增加。一上来几百条用例,需求的稍微变化,用例可能大调整,那么你很可能每天疲惫于用例的维护。
所以,在开始自动化的时候,你可以只对登录功能写个十来条的自动化用例。从而,渐渐的考虑将更多功能自动化起来。
半自动化对于测试人员是个不错的开始,这样你可以将更多的精力花在安全测试,探索性测试,甚至是用例体验上等。不要觉得全职自动化是多么高大上的职位。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11