你开始自动化测试了吗？

忘是亡心i 2022-07-14 11:25 220阅读 0赞

我不是标题党！

当我开始觉得自动化测试很吊的时候，就学习了自动化测试工具（比如Selenium），满腔的热情和无限的期望啊 还给我。。。。。呵呵

所以当你决定不再依赖测试人员，和我一样想兼顾测试，对于自动化测试向往的同学，先看看我转载的这篇文章吧

感谢：

https://zhidao.baidu.com/question/201064448536746045.html

http://www.s3d4.cn/xue/show/48415

文章一内容：

有关自动化测试的误区  
　　目前，有些人对自动化测试的认识存在一定的误区，因此有必要对自动化测试树立正确的认识，以防止对其有过高的期望。  
　　1．自动化测试工具是“万能”的  
　　很多人一听到自动化测试，就认为自动化测试工具可以完成一切测试工作，从测试计划到测试执行再到测试结果分析，都不需要任何人工干预。显然，这是一种理想状态，现实中还没有哪个测试工具有这个能力，并且将来也不会有。在现实中有关的测试设计、测试案例，以及一些关键的测试任务还是需要人工参与的，即自动化测试是对手工测试的辅助和补充，它永远也不可能完全取代手工测试。  
　　2．测试工具可适用于所有的测试  
　　每种自动化测试工具都有它的应用范围和可用对象，所以不能认为一种自动化测试工具能够满足所有测试的需求。针对不同的测试目的和测试对象，应该选择合适的测试工具来对它进行测试。在很多情况下，需要利用多种测试工具或者开发自动化测试框架才能达到自动化测试的目的。商业和开源的测试工具能够用来进行自动化测试，但是我们需要根据自身产品的特点，开发自动化测试框架，在框架中提供常用的测试用例，加快测试速度，达到测试用例复用，这是今后测试自动化发展的道路。  
　　3．测试工具能使工作量大幅度减少  
　　事实上，引入自动化测试工具不会马上减少测试工作，相反，在更多情况下，首次将自动化测试工具引入企业时，测试工作实际上变得更艰巨了。只有在正确合理地使用测试工具，并有一定的技术积累之后，测试工作量才能逐渐减轻。  
　　4．测试工具能实现100%的测试覆盖率  
　　由于自动化测试可以增加测试覆盖的深度和广度，利用白盒测试工具可能实现语句全覆盖、逻辑路径全覆盖等，但因为穷举测试必须使用所有可能的数据，包括有效的和无效的测试数据，所以在有限的资源下也不可能进行100%的测试。  
　　5．自动化测试工具容易使用  
　　对于这一点，很多测试工程师有同样的错误观点，认为测试工具可以简单地通过捕获（录制）客户端操作生成脚本，且脚本不加编辑就可用于回放使用。事实上，自动化测试不是那么简单的，捕获的操作是否正确，以及脚本编辑是否合理都会影响测试结果。因此，自动化测试需要更多的技能，也需要更多的培训。  
　　6．自动化测试能发现大量新缺陷  
　　发现更多的新缺陷应该是手工测试的主要目的，不能期望自动化测试去发现更多新缺陷。事实上，自动化测试主要用于发现原来的缺陷。自动化测试用于回归测试，而大量的新业务测试更多地还是依赖手工测试。

文章二：

自动化测试的成本高效果差，那么自动化测试的意义在哪呢？  
  
我觉得这个问题带有很强的误导性，是典型的逻辑陷阱之一。“自动化测试的成本高效果差”是真的吗？当然不是。而且我始终相信，回答问题的最好方式是把问题本身弄清楚。也就是问关于问题的问题。楼主也学可以进一步 说明下面几个问题，有助于自己理解自己的问题，更有助于问题得到准确的回答：  
  
    请定义“自动化测试”的范畴。自动化测试简单来讲，包括用例的撰写，代码的实现，环境的搭建，用例的执行，报表的生成，结果的分析，缺陷报告等等。每个项目自动化程度不一样，测试人员对自动化的理解有偏差，实际实行自动化的范畴差别很大  
    请定义“成本“包括哪些  
    请定义什么是“高”。高是相对的。比较对象可以是另外的项目或者项目组，也可以是他人的期望  
    请定义什么是”效果“  
    请定义什么是”差“。差也是相对的，可以是同手工测试比较，也可以是同老板的期望比较  
  
如果楼主仔细思考并且回答了以上的问题，我有七成的把握楼主要么不想问这个问题，要么想换个问题。  
  
换一种问法  
  
  
好吧，为了避免灌水嫌疑，我且以最大的善意揣摩楼主的意图。楼主是想问：  
  
如果有的项目的自动化测试，我们发现成本高于预期，效果不符合预期，那么问题可能出在哪里？怎么判断自动化测试是否有效？  
  
\-----------------这里是正文开始--------------  
  
  
关于错误的预期  
  
  
我一点都不奇怪有人会告诉我说：  
  
    我都不知道我或者我的老板对自动化测试有什么预期，没人跟我说过。  
  
  
或者：  
  
    自动化不就是不用手工测试了吗？用例用代码实现都能自己跑，测试人员就可以去干别的了，可以少招几个不产生价值的测试攻城狮了。老板就是这样计划的。  
  
这是两种非常典型的关于自动化测试的预期问题：  
  
    根本就不清楚自动化测试的目标，以及为达到目标所计划的投入  
    对自动化测试（通常是总监以上的老板，开发人员或者手动测试人员）抱有不切实际的幻想型期望，认为自动化测试能够干很多活同时省很多钱  
  
自动化测试的第一目标从来都不是节省测试的人力成本。成功的自动化测试，作为软件测试的一种工具，从业务最终效果来看，应该是能够节省成本和提高产品质量的。但是把节省测试的人力成本作为自动化测试的直接目标是错误的，而且是致命的。  
  
每个人对自动化测试理解都不一样，每个项目组做自动化的方式都不一样。我讲个故事，是我认识之前一个印度自动化项目的真实例子。这个项目95%以上的测试场景都是比较复杂的UI测试（Web +Windows Application）他们的自动化是这样做的：  
  
    手工测试人员把测试用例录入到用例管理系统，精确到每一步的描述和每一个数据  
    自动化测试人员用代码（java，python等）实现自动化用例，保存到SCM  
    准备好测试环境  
    打开Eclipse  
    定位到要执行的用例的源代码  
    Run As Junit （因为统一用JUnit做封装）  
    两眼直视显示器，目不转睛  
    如果有步骤执行不成功，比如某个按钮点击不成功，手动帮助点击，继续  
    一个用例执行完毕，重复步骤5到9  
  
你觉得这个自动化做的怎么样？我当时的感觉是几乎要吐血了，因为这个项目是我要接手的。更加吐血的还在后面，这个部门的QA的VP对自动化测试的效果很不满意（绝对的），他的设想包括：  
  
    自动化应该是一种Service（Automation As A Service)，所有的测试人员和开发人员都应该可以自己很方便的去跑自动化  
    自动化测试的运行结果应该是可以自动分析的，占用很少的时间  
    自动化测试的成功率应该是要很高的（比如95%以上）  
    自动化应该是写一次，运行很多次，为什么你们花那么多时间还要去改自动化代码？  
  
这个就是一个典型的不懂自动化的团队+期望脱离现实的老板。  
  
关于什么是自动化  
  
James Bach 曾经在一篇博文提到，自动化测试这个名字是非常有误导性的。它让一般的人误以为就是测试完全被自动化了，就像一个自动的咖啡机一样，我只需要把杯子放在那里，按一个button就够了。James说更加准确的叫法应该是“工具辅助的测试”。当然他还有另一层意思，就是好的测试用例是没有办法100%被自动化的，测试人员的经验，逻辑判断和探索性的测试方法都不能被有效自动化。我非常同意这个观点。作为这个论断的补充和扩展，自动化应该是审视软件研发活动的每一个环节，去发现那些可以被工具化自动化的重复性活动，然后去实现。广义的自动化应该包括但不限于以下环节：  
  
    测试环境的搭建和管理  
    测试环境的检查，监控和报警  
    测试代码的编译和测试构建  
    测试代码的静态检查和报警  
    测试用例的分发和执行  
    测试结果的保存与管理  
    测试报告的生成  
    测试优先级的建议  
  
自动化的成本与收益（ROI）  
  
一个过于简化的公式可以这样写：  
  
自动化的收益 = 迭代次数 \* 全手动执行成本 - 首次自动化成本 - 维护次数 \* 维护成本  
  
  
或者如果假设迭代次数和维护次数近视相等，这个在某些情况下可以成立，比如一个比较新的产品：  
  
自动化的收益 = 迭代次数 \* (全手动执行成本 - 维护成本) - 首次自动化成本  
  
  
解读：  
  
    自动化的收益与迭代次数成正比  
    自动化收益可能为负数：即当自动化成本和维护成本比手动执行成本还高时  
    很多时候自动化成本并不比手动成本高，但是维护成本很高  
  
为什么强调过于简化，因为这里的自动化收益仅仅考虑时间和资源成本的节省。好的自动化带来的迭代周期的缩短，是可以缩短项目周期，在某些时候能变不能做为能做，进而带来的机会收益是巨大的，也是很难量化的。这个就要求决策者对软件工程和自动化有比较正确的直觉和理解。片面追求自动化的资源节省，或者要求精确量化自动化的收益，本人觉得都不可取。  
  
推论1：什么项目适合自动化  
  
从ROI的简化公式可以看出，下面几中情况比较适合自动化：  
  
    回归测试为主的Support Engineering项目，即需要长期做支持维护的产品。或者有过去版本需要长期做支持维护的产品。这种产品（比如企业软件，操作系统等）一个版本在发布之后往往需要支持好多年，做bug fix和patch。这个时候每次小版本的开发都会增加迭代次数，并且每次产品变动都非常有限，维护成本相对偏低，自动化收益就非常好。这也是很多企业级软件或者硬件产品有专门自动化团队的原因。因为产品的支持维护开发的回归测试基本靠自动化  
    接口比较稳定的产品，同上  
    手动测试特别费时费力，甚至无法达到测试目的的项目。比如压力测试，大数据或者大量重复数据测试，必须有自动化工具的支持  
  
  
推论2：自动化的介入时间点  
  
  
同样从ROI的简化公式推断出，一个项目的初期可能不太适合自动化。因为项目初期用户界面和接口没有稳定，自动化代码会被动的被要求频繁改变，维护成本非常高。自动化收益不好。而反而手动测试能够快速发现问题，反馈给开发人员。而到了项目后期和维护期，自动化再介入为回归测试做准备，可以最大化自动化收益。  
  
推论3：自动化的程度和自动化率  
  
这里自动化的程度是指整个软件研发活动中引入自动化的程度。推论2中说，有些项目早期可能不太适合高度自动化，但是项目早期仍然可以选定某些环节进行自动化。比如稳定的公用接口，软件的编译和部署，环境的搭建等从一开始就比较稳定的部分。  
  
自动化率同样也要看产品和项目的特性，对于产品的UI部分如果会频繁改动，可以做比较低的自动化。对于接口比较稳定的服务组件可以提高自动化率。  
  
你有什么样的团队，工具和基础设施  
  
  
其实这个因素是做所有事情都必须考虑的。自动化测试本身就是软件开发。好的自动化测试框架，架构设计很重要。这些会决定自动化的开发成本和维护成本。这些都要求很强的开发能力。如果你的团队只有很有限的开发能力，那么怎么去做自动化，是做最原始的录制回放，还是数据驱动。复杂自动化也需要良好的基础设施支持。比如你有很好的DevOps的虚机管理系统，就不用自己去开发，省下的资源和人力也是很可观的。  
  
工具是另外一块，如果公司有实力支持商业测试软件和管理软件，就可以降低编程要求（当然这会带来一些其他问题）。如果没有办法用商业工具，只能考虑开源和自己开发，这个对自动化测试开发的能力要求就高。总之必须选择和团队，技能储备，基础设施与工具匹配的自动化策略。  
  
管理层的理解程度和支持  
  
  
这个就不再展开。我见过很糟糕的情况，一个带好几百人兼顾产品技术的VP，越3到4级直接给测试团队提技术需求和建议。你说是做还是不做，怎么做？还有一个团队，自动化测试人员从来没有写过Java或者其他OO语言的程序，被要求从头设计自动化框架，那就是一场灾难。还有一个团队，管理层几次要求更换自动化工具，相当于整体重写自动化脚本。  
  
  
总结  
  
以上应该是一个很粗浅的回答。自动化测试是一个很专门化的领域，自动化测试又是对工程师的技术广度深度要求很高的工作。对于团队管理和决策者来讲，请不要简单化和孤立看待自动测试。最重要的是确保听取真正理解产品，团队和自动化测试的技术人员的判断。  
  
懂产品的测试人员，公众号：大话IT公司  
  
短期看，自动化的成本高收益低。  
长期看，自动化的成本低收益高。  
  
感觉好对称的说  
  
吴章金falcon，招聘Android自动化测试工程师/实习生  
  
适用的场景：  
  
1、压力测试  
2、覆盖性测试  
3、回归测试  
  
能够有效解决如下问题：  
  
1、手工测试压力不够，发现不了大规模使用后才会出现的问题  
2、手工测试不够全面，容易错过某些边界情况  
3、手工测试频度不够，容易错过日常修订引入的问题