自动化测试也是得有需求文档的!

自动化测试也是得有需求文档的!

很多时候,我们只注意在了自动化的实现上,而忘记了对自动化测试的需求分析上,从而导致后期做出来的目录结构不合适,改动困难,debug难度高,自动化测试的首要特性就是重复执行,不能重复执行,且易暴露问题的自动化,不如手工测试。
我认为的自动化测试框架必有以下特征:
1.方便指定待测集合(用例、套件)运行
2.方便失败之后的debug过程
3.方便编写(建议用强类型语言)
4.与手工测试能互相呼应,能够很容易明白这条用例要做什么。就好比我们说英语一样,我不想要收到了英语的信息之后,通过翻译软件,告知我的大脑它的中文意思,然后我的大脑再在我的记忆之中找出对应的英语单词,最后由我的口发出。我希望是,我接受到了英语信息,我的大脑不需要把英文翻译成中文,而是直接明白英文的意思,并且用英文发出,整个过程不涉及翻译,所以建议不要搞花式的EXCEL关键字驱动或者其他形式的XX驱动,有这么一句话,show me the code
手工测试用例->自动化测试用例需求分析
我们在最初开发自动化测试框架的时候,一定要记住结合目前已有的手工用例,并且分析,最后定出我们自动化测试框架的结构,不然后期会吃大亏,就像产品人员根据已有竞品,分析出我们的开发需求一样,我们得分析我们的手工用例,定义我们的自动化测试框架需求。
这是一条常见的购物测试手工用例:
1.登录网站首页
2.输入用户名,密码
3.购买一款价值500元的产品
4.检查实际支付金额是否正确
期望结果:
实际支付金额正确。
用例看起来很简单。好像操作步骤也不复杂,应该是一条很容易自动化的测试用例。实际不然,我们在做自动化测试的时候,需要进行详细的分析。按照我们自动化的测试逻辑,分为@测试前(数据准备),@测试过程(执行测试步骤)@测试后(用例失败或成功的数据清理)。这条用例按照自动化的逻辑就变成:
@测试前
1.通过数据库插入语句生成一个用户,“用户名”“密码”固定,传入测试数据
2.通过数据库修改语句修改某产品的价格为500,返回“产品名”,传入测试数据
3.通过数据库修改语句修改已知的用户的账户余额大于500
@测试步骤
1.打开网站首页。在网站首页点击登录按钮
2.在登录弹出层输入“用户名”“密码”,按下确定按钮
3.在搜索框输入测试数据中的“产品名”点击搜索按钮
4.在搜索结果列表页点击第一个搜索结果的标题栏
5.在产品详情页点击加入购物车按钮,点击页面右上角的购物车按钮
6.在购物车页面点击立即结算按钮
7.在支付页面选择账户余额支付,完成支付
8.等待页面挑战提示支付成功字样
9.点击页面右上角会员中心按钮
10.在会员中心检查该订单的实际支付金额。获得订单号,传入测试数据
断言:实际支付金额==500
@测试后
1.根据用户名删除该用户
2.判断是否存在订单号,存在则删除订单表中的该订单数据
3.修改购买的该产品的价格为原价
所以,根据上面的用例,我们可以分析出,我们的测试框架有
–测试用例
–测试页面库
–测试动作库
–测试结果校验库
–组合测试步骤库
–其他工具库(包含数据库操作,API操作等)
流程是:
在通过某些工具准备好数据之后,每一个测试用例包含多个测试步骤。每一个测试步骤会在一个测试页面上进行多次动作。操作多个页面元素。操作完成后会经过一到多个测试结果检查。完成测试结果之后,告诉测试基类这次测试的结果是正确还是错误,记录在日志之中。最后在完成所有测试集合之后,最后统一通过邮件发送出来。
在明确业务流程后,完成自动化测试就是具体的落实工作。如果后续有时间,我会发出我推荐的自动化测试代码框架。
我的建议是用testng+ selenide+ ExtentReports+jenkins+maven+jdbc+httpclient这些工具做自动化应该是比较好的,对于mybatis ,dom4j ,poi这些我感觉是用不到的,我曾经加入过excle,xml等一些貌似很合情合理的功能,但是后续在用例失败debug的时候简直让我爆炸,自动化测试,一切从简,能用代码解决的,就不要用其他工具。

发表回复


苏ICP备18047533号-2