自动化测试的成本高效果差,那么自动化测试的意义在哪呢?

自动化测试的成本高效果差,那么自动化测试的意义在哪呢?_第1张图片

一、自动化测试的成本高效果差,那么自动化测试的意义在哪呢?
我觉得这个问题带有很强的误导性,是典型的逻辑陷阱之一。“自动化测试的成本高效果差”是真的吗?当然不是。而且我始终相信,回答问题的最好方式是把问题本身弄清楚。也就是问关于问题的问题。楼主也学可以进一步 说明下面几个问题,有助于自己理解自己的问题,更有助于问题得到准确的回答:

请定义“自动化测试”的范畴。自动化测试简单来讲,包括用例的撰写,代码的实现,环境的搭建,用例的执行,报表的生成,结果的分析,缺陷报告等等。每个项目自动化程度不一样,测试人员对自动化的理解有偏差,实际实行自动化的范畴差别很大

请定义“成本“包括哪些

请定义什么是“高”。高是相对的。比较对象可以是另外的项目或者项目组,也可以是他人的期望

请定义什么是”效果“

请定义什么是”差“。差也是相对的,可以是同手工测试比较,也可以是同老板的期望比较

自动化测试的成本高效果差,那么自动化测试的意义在哪呢?_第2张图片

你要是刚进入这个行业,可能认为测试就是找bug,但是测试工程师的核心是质量保障。

那么说进行质量保障的过程中,为什么要引入自动化测试呢?

举个例子,以前一个项目,一两个月发布一次,现在是一周,甚至有的时候2天就可以发布一个功能。如果是按照这个节奏,研发只需要改一行代码,你却要写很多的用例,甚至要回归,几十条甚至上百条的都有可能。

他的改动会越来越频繁,每一次的改动,我们都要去做回归的,而这种回归,在这种短时间迭代越来越短的节奏下,其实已经没有办法再靠人力去支撑了。

总结起来就是:

1、突破效率瓶颈,同时降低人力成本(注意不能把降低人力成本放在核心位置);

2、降低人为错误率,规避因为人的疲劳和惯性思维以及投机取巧导致的错误;

3、提升执行效率,以及应对高强度连轴转任务,搞定长时间的系统稳定性测试和高并发场景的压力测试;

4、增加软件的信任程度;

除了这些,与手工测试相比,脚本中是可以记录测试设计思路,拓扑图,测试点等相关的信息,是非常优秀的测试信息存储,另外也可以根据脚本中获取到的代码覆盖率,进行情况分析,进而补充测试用例。 如果有的项目的自动化测试,我们发现成本高于预期,效果不符合预期,那么问题可能出在哪里?怎么判断自动化测试是否有效?

二、关于错误的预期
我一点都不奇怪有人会告诉我说: 我都不知道我或者我的老板对自动化测试有什么预期,没人跟我说过。

或者: 自动化不就是不用手工测试了吗?用例用代码实现都能自己跑,测试人员就可以去干别的了,可以少招几个不产生价值的测试攻城狮了。老板就是这样计划的。 这是两种非常典型的关于自动化测试的预期问题:

根本就不清楚自动化测试的目标,以及为达到目标所计划的投入

对自动化测试(通常是总监以上的老板,开发人员或者手动测试人员)抱有不切实际的幻想型期望,认为自动化测试能够干很多活同时省很多钱

自动化测试的第一目标从来都不是节省测试的人力成本。成功的自动化测试,作为软件测试的一种工具,从业务最终效果来看,应该是能够节省成本和提高产品质量的。但是把节省测试的人力成本作为自动化测试的直接目标是错误的,而且是致命的。 每个人对自动化测试理解都不一样,每个项目组做自动化的方式都不一样。我讲个故事,是我认识之前一个印度自动化项目的真实例子。这个项目95%以上的测试场景都是比较复杂的UI测试(Web +Windows Application)他们的自动化是这样做的:

手工测试人员把测试用例录入到用例管理系统,精确到每一步的描述和每一个数据

自动化测试人员用代码(java,python等)实现自动化用例,保存到SCM

准备好测试环境

打开Eclipse

定位到要执行的用例的源代码

Run As Junit (因为统一用JUnit做封装)

两眼直视显示器,目不转睛

如果有步骤执行不成功,比如某个按钮点击不成功,手动帮助点击,继续

一个用例执行完毕,重复步骤5到9

你觉得这个自动化做的怎么样?我当时的感觉是几乎要吐血了,因为这个项目是我要接手的。更加吐血的还在后面,这个部门的QA的VP对自动化测试的效果很不满意(绝对的),他的设想包括:

自动化应该是一种Service(Automation As A Service),所有的测试人员和开发人员都应该可以自己很方便的去跑自动化

自动化测试的运行结果应该是可以自动分析的,占用很少的时间

自动化测试的成功率应该是要很高的(比如95%以上)

自动化应该是写一次,运行很多次,为什么你们花那么多时间还要去改自动化代码?

这个就是一个典型的不懂自动化的团队+期望脱离现实的老板。

三、关于什么是自动化

自动化测试的成本高效果差,那么自动化测试的意义在哪呢?_第3张图片

James Bach 曾经在一篇博文提到,自动化测试这个名字是非常有误导性的。它让一般的人误以为就是测试完全被自动化了,就像一个自动的咖啡机一样,我只需要把杯子放在那里,按一个button就够了。James说更加准确的叫法应该是“工具辅助的测试”。当然他还有另一层意思,就是好的测试用例是没有办法100%被自动化的,测试人员的经验,逻辑判断和探索性的测试方法都不能被有效自动化。我非常同意这个观点。作为这个论断的补充和扩展,自动化应该是审视软件研发活动的每一个环节,去发现那些可以被工具化自动化的重复性活动,然后去实现。广义的自动化应该包括但不限于以下环节:

测试环境的搭建和管理

测试环境的检查,监控和报警

测试代码的编译和测试构建

测试代码的静态检查和报警

测试用例的分发和执行

测试结果的保存与管理

测试报告的生成

测试优先级的建议

四、自动化的成本与收益(ROI)
自动化测试的成本高效果差,那么自动化测试的意义在哪呢?_第4张图片

一个过于简化的公式可以这样写: 自动化的收益 = 迭代次数 * 全手动执行成本 - 首次自动化成本 - 维护次数 * 维护成本 或者如果假设迭代次数和维护次数近视相等,这个在某些情况下可以成立,比如一个比较新的产品: 自动化的收益 = 迭代次数 * (全手动执行成本 - 维护成本) - 首次自动化成本 解读:

自动化的收益与迭代次数成正比

自动化收益可能为负数:即当自动化成本和维护成本比手动执行成本还高时

很多时候自动化成本并不比手动成本高,但是维护成本很高

为什么强调过于简化,因为这里的自动化收益仅仅考虑时间和资源成本的节省。好的自动化带来的迭代周期的缩短,是可以缩短项目周期,在某些时候能变不能做为能做,进而带来的机会收益是巨大的,也是很难量化的。这个就要求决策者对软件工程和自动化有比较正确的直觉和理解。片面追求自动化的资源节省,或者要求精确量化自动化的收益,本人觉得都不可取。 推论1:什么项目适合自动化 从ROI的简化公式可以看出,下面几中情况比较适合自动化:

回归测试为主的Support Engineering项目,即需要长期做支持维护的产品。或者有过去版本需要长期做支持维护的产品。这种产品(比如企业软件,操作系统等)一个版本在发布之后往往需要支持好多年,做bug fix和patch。这个时候每次小版本的开发都会增加迭代次数,并且每次产品变动都非常有限,维护成本相对偏低,自动化收益就非常好。这也是很多企业级软件或者硬件产品有专门自动化团队的原因。因为产品的支持维护开发的回归测试基本靠自动化

接口比较稳定的产品,同上

手动测试特别费时费力,甚至无法达到测试目的的项目。比如压力测试,大数据或者大量重复数据测试,必须有自动化工具的支持

推论2:自动化的介入时间点 同样从ROI的简化公式推断出,一个项目的初期可能不太适合自动化。因为项目初期用户界面和接口没有稳定,自动化代码会被动的被要求频繁改变,维护成本非常高。自动化收益不好。而反而手动测试能够快速发现问题,反馈给开发人员。而到了项目后期和维护期,自动化再介入为回归测试做准备,可以最大化自动化收益。推论3:自动化的程度和自动化率 这里自动化的程度是指整个软件研发活动中引入自动化的程度。推论2中说,有些项目早期可能不太适合高度自动化,但是项目早期仍然可以选定某些环节进行自动化。比如稳定的公用接口,软件的编译和部署,环境的搭建等从一开始就比较稳定的部分。 自动化率同样也要看产品和项目的特性,对于产品的UI部分如果会频繁改动,可以做比较低的自动化。对于接口比较稳定的服务组件可以提高自动化率。

五、你有什么样的团队,工具和基础设施
其实这个因素是做所有事情都必须考虑的。自动化测试本身就是软件开发。好的自动化测试框架,架构设计很重要。这些会决定自动化的开发成本和维护成本。这些都要求很强的开发能力。如果你的团队只有很有限的开发能力,那么怎么去做自动化,是做最原始的录制回放,还是数据驱动。复杂自动化也需要良好的基础设施支持。比如你有很好的DevOps的虚机管理系统,就不用自己去开发,省下的资源和人力也是很可观的。工具是另外一块,如果公司有实力支持商业测试软件和管理软件,就可以降低编程要求(当然这会带来一些其他问题)。如果没有办法用商业工具,只能考虑开源和自己开发,这个对自动化测试开发的能力要求就高。总之必须选择和团队,技能储备,基础设施与工具匹配的自动化策略。

六、管理层的理解程度和支持
这个就不再展开。我见过很糟糕的情况,一个带好几百人兼顾产品技术的VP,越3到4级直接给测试团队提技术需求和建议。你说是做还是不做,怎么做?还有一个团队,自动化测试人员从来没有写过Java或者其他OO语言的程序,被要求从头设计自动化框架,那就是一场灾难。还有一个团队,管理层几次要求更换自动化工具,相当于整体重写自动化脚本。

七、总结
以上应该是一个很粗浅的回答。自动化测试是一个很专门化的领域,自动化测试又是对工程师的技术广度深度要求很高的工作。对于团队管理和决策者来讲,请不要简单化和孤立看待自动测试。最重要的是确保听取真正理解产品,团队和自动化测试的技术人员的判断

总结:

感谢每一个认真阅读我文章的人!!!

作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助

自动化测试的成本高效果差,那么自动化测试的意义在哪呢?_第5张图片

文档获取方式:

加入我的软件测试交流群:632880530免费获取~(同行大佬一起学术交流,每晚都有大佬直播分享技术知识点)

这份文档,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!

以上均可以分享,只需要你搜索vx公众号:程序员雨果,即可免费领取

你可能感兴趣的:(软件测试,技术分享,职场和发展,测试工具,开发语言)