反思下一直以来在做的自动化测试(管理系统BVT)，好似是为了自动化而自动化，虽然也发现了一些BUG，但是总感觉和手工测试差距很大，虽然我知自动化测试与手工测试还是有很大差别的，但是能否做到尽可能多、且快速的发现bug，能够一定程度上的节省手工测试时间。
先以我上周手工测试的一个需求为例，梳理手工测试之流程：
流程梳理：
阅读需求+原型—>编写测试用例—>执行手工测试—>验证bug+需求回归测试
bug情况梳理：
1.链接地址错误，http请求错误；
2.按照结束时间查询，结果列表数据错误；
3.错别字；
4.已被其他推广使用的渠道能删除(需求要求不能删除)；
5.增加相同名称数据抛出数据库错误；
6.删除操作无对应提示提示信息；
过程反思：
1.看看发现的bug，用现有的框架是可以检测到的，所以框架层面代码不需要修改
2.为什么没有在手工测试时编写自动化测试脚本，原因应该有以下几点：
(1).需求本身并不复杂，手工测试时间充裕；
(2).自动化测试涉及页面元素等，且如果要编写自动化用例+调试，其时间已足以支持手工测试；
(3).对自己的框架不够自信，不敢断定抛开手工测试的自动化测试结果准确性；
反驳上述观点：
(1).由于需求中要做bug验证+回归测试，如果这些测试有自动化来完成，势必可以提高效率；
(2).本身该模块就要加到自动化测试(BVT)中，所以是避免不了AT用例编写的；
(3).对框架的自信度应该在一次次的需求测试中提炼，正好也可借机验证其准确性；
以后该怎么做：
(0).编写手工测试用例时，必须同步编写BVT级别自动化用例，使用场景法，保留元素定位为空，待系统发出后再添加；
(1).手工测试优先做；
(2).其后编写(修改)发现bug的点的自动化测试用例；
(3).完善其他必须要的自动化测试用例；
(4).检查自动化结果与手工测试结果一致性，确定是否需要优化框架代码。
网友评论