赞
踩
机器代替手工测试,自动验证结果是否符合预期
替代大量重复手工测试
提升回归测试效率,适合敏捷开发
在非工作时间自动执行,工作时间查看测试报告
保证每次测试执行的一致性与正确性,避免人为错误
一般用于回归测试,项目开发初期不适合使用自动化
不能全部取代手工测试,只能替代手工测试中机械化,重复度高的操作,自动化测试极少能够达到100%覆盖率
自动化测试非常脆弱,特别是UI自动化
自动化测试工作量(框架设计+脚本开发)比单次手工测试大很多,当自动化多次执行时,性价比才会凸显
想要开展自动化测试,应该遵循以下几个前提条件:
需求稳定,不会频繁变更
研发和维护周期长,需要频繁执行回归测试
项目资源足够「人力」
自动化测试到底要做到什么程度
自动化测试覆盖范围:
主业务流程
历史BUG较多的模块
基础重复的功能
优先级
测试工具/框架选型
接口自动化:TestNG+HttpClient+Maven+Allure+Log4j
web自动化:TestNG+Selenium
框架设计,自动化测试脚本开发时间计划表
脚本执行的策略,冒烟测试/回归测试的频率
定义自动化测试的输出,测试框架,测试脚本,测试数据,发现的缺陷,测试报告
UI方法:人工方式造数据
接口方法:效率高 用的最多 有保证的
数据库:效率高 添加数据影响到其他的数据表 不能确保正确性
手工测试用例转自动化测试用例的过程
本地执行:IDE调试/执行
持续集成平台:jenkins
自动化用例失败了
BUG
脚本设计/稳定性问题
周期最长
框架优化
需求变更
自动化测试用例覆盖,一般为20%的自动化测试,80%的手工测试
节省的时间成本:手工测试花费的时间-自动化测试所花的时间
自动化测试发现的缺陷数:保证质量,不能保证发现很多BUG
自动化测试的投入产出ROI「越高越好」
(手工测试的成本-自动化测试成本)/自动化测试脚本
有些用例场景无法被自动化
一些验证易用性,友好性,美观的用例不适合做自动化
有些边缘用例很少被重复执行,从ROI角度考虑不适合做自动化
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。