不得不说之用例设计
设计 不得不 之用
2023-09-11 14:20:31 时间
自动化测试用例如何设计,对于新手来说也是比较难理解的问题。
不少新手刚刚掌握了写脚本的能力,一上来就拿着功能测试用例一条一条的转化成自动化用例。在写的过程中,会发现诸多问题,例如,脚本中重复代码很多,一个脚本的执行结果影响到另一个脚本的执行,有些功能用例很难转化成自动化用例等。
站在用户角度设计自动化
在功能测试的时候我们一般会遵循这个原因,但是自动化测试往往可以实现更强大的功能,所以,我们在设计脚本的时候很容易违背这个原则。例如,你要获得的数据是用户不可见的,你要判断用例是否成功的信息也是用户不可见的,或者你要模拟的是用户永远不可能做的操作等。
设计简单傻瓜的用例
自动化脚本本来是很傻瓜的。记得有同学问我,百度输入有个自动联想功能,就是在用户输入的过程中自动配置热门搜索的关键词,例如,用户输入“自”,会自动联想“自我评价”,“自行车”等。用继续输入“自动”,会自动联想“自动化”,“自动关机”,“自动档”等。他想定位自动联想下拉列表的某个关键词,这个关键词是百度根据用户搜索热度的变化而变化的。
再比例有同学问我,下拉列表功能,我想脚本执行时随机选择某一个选项,那么如何如何去判断随机的结果呢?换句话说,你都不知道你做了什么,怎么去判断做的结果对不对?
所以,我们在设计用例时尽量考虑简单傻瓜的用例,操作步骤简单,预期结果容易判断等。
从简单开始
对于新需要自动化的项目来说,自动化测试的实施是循序渐进的,不要一上来就设计几百条用例,而是逐步的将功能用例转成自动化用例,在转的过程中需要不断的调整测试结构。然后,再增加稳定的测试用例。然后,再调整测试结构。随着功能的增加你的自动化测试框架也在逐渐稳定,基础测试用例也在增加。一上来就几百条用例,需求的稍微变化,用例就可能大调整,那么你很可能每天疲惫于用例的维护。
所以,在开始自动化的时候,你可以只对登录功能写个十来条的自动化用例。从而,渐渐的考虑将更多功能自动化起来。
半自动化对于测试人员是个不错的开始,这样你可以将更多的精力花在安全测试,探索性测试,甚至是用例体验上等。不要觉得全职自动化就是多么高大上的职位。
最新内容请见作者的GitHub页:http://qaseven.github.io/
自动化测试 之 “好用例、坏用例” 自动化测试的重要性显而易见,但自动化测试又无法解决所有问题,所以说完全依赖自动化是不可能的,但完全没有自动化是万万不能。在软件开发项目中,重度依赖人力进行持续回归是一件非常枯燥的重复工作。企业需要花费大量的时间和金钱来维持这样一支队伍以保证产品质量,而队伍中的同学在每天重复劳动的工作之下,也丝毫得不到成长,看不到方向。
自动化测试 之 “好用例、坏用例” 自动化测试的重要性显而易见,但自动化测试又无法解决所有问题,所以说完全依赖自动化是不可能的,但完全没有自动化是万万不能。在软件开发项目中,重度依赖人力进行持续回归是一件非常枯燥的重复工作。企业需要花费大量的时间和金钱来维持这样一支队伍以保证产品质量,而队伍中的同学在每天重复劳动的工作之下,也丝毫得不到成长,看不到方向。
相关文章
- OC中使用UI自己定义控件实现计算器的设计(版本号1简单的加减乘除,连加,连减,连除,连乘)
- 运动图像序列增强重建的matlab设计和仿真
- 《架构真经:互联网技术架构的设计原则(原书第2版)》一第2章 分而治之
- 《为iPad而设计:打造畅销App》——激发讨论
- 《破茧成蝶——用户体验设计师的成长之路》一1.2 邂逅用户体验设计
- 《重构HTML:改善Web应用的设计(修订版)》——2.6 TagSoup
- 基于手势控制的智能体感遥控车设计【100010377】
- 读懂Swift 2.0中字符串设计思路的改变
- DDD领域驱动设计基本理论知识总结
- 从零开始的「校园商铺」毕设全栈开发—设计数据库
- 来自极客标签10款最新设计素材-系列十三
- 子系统设计和FishiGUI的子系统设计