通用技术谈谈我对自动化测试的理解

扫地僧 · 2016年10月20日 · 最后由 hr 回复于 2016年10月26日 · 2408 次阅读

首先，衷心希望入行做测试的，对于技术类文章更要理性的去看和体会，这不是小说，文笔精彩就觉得好。每篇文章的发表都有其主观局限性，取其精华，去其糟粕，不能判断的可以通过多途径去佐证观点是否靠谱。特别对于刚入行的，要学会多问为什么，尽信书不如无书，可能轻信一个错误的观点，会让你走向错误的方向。
我对自动化的理解，也是随着行业的发展在改变，以下仅代表个人观点，是否有营养还请读者自己体会。

自动化的目的

把测试从枯燥的重复劳动中解放出来，例如：回归测试等；
协助手工测试完成很难模拟或无法模拟的的工作，例如：篡改服务返回的数据验证前端对各种数据场景的处理，弱网模拟、特殊协议数据包解析验证等；
尽早发现 Bug，例如：数据层的存储过程、Package 批量调用验证、接口自动化等偏底层的问题；
协助定位问题，现在的自动化提出了更高的要求，例如：接口层发现问题了，可以通过添加的 traceID 定位到日志错误或错误代码行，app 运行中异常可捕获错误日志等；
线上监控报警，现在的自动化不仅限于线下，线上的也已覆盖，测试和运维的工作可能存在交集，我们不能把质量问题寄托于他人，一旦发现问题，立即报警通知到人，让损失到最小。
提高工作效率，这个面有点广，例如，测试环境的自动化编译、打包、部署、持续集成甚至持续交付等。

关于自动化介入的若干问题

是否要考虑成本？当然要考虑，我们总会遇到在成本和质量之间找平衡点，可能一些特殊的行业，特殊的项目，质量的权重更高点，如果引入自动化能提高质量，该介入的还是要介入。
是不是只有大公司能做，小公司和初创公司就不适合搞自动化？这不是绝对的，还是要看公司的资源和人员配备，如果有能力做为什么不？况且小公司的自动化不一定要做到大公司的程度，只要能提高工作效率，提高质量就可以，滴水穿石，聚沙成塔。
自动化何时介入？条件许可的还是尽早介入，越是底层的 Bug，影响面越广，修复成本也是最低的。但这不是硬性标准，一般公司都是从 UI 自动化开始积累经验的，拔苗不能助长。

如何开展自动化工作

这个信息量比较大，人才和技术就不多说了，我更关心的是做事的方式

抓住业务测试工作中的痛点和领导的痛点，多沟通多交流，优先解决基层的工作痛点，我相信一个好的领导会看到你的责任心和付出；
技术选型和方案可行性调研，多投入时间和精力，有的人性子急，前期做的很快，如果一开始的方向错了，最终会得不偿失；
如果是比较复杂的解决方案，尽量前后端分离、保证各模块的独立性、可融合性、解耦不解体，做到灵活可扩展，要有下一盘大棋的准备。

9 个赞

如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！

打赏支持

共收到 16 条回复时间点赞

0x43 #1 · 2016年10月21日

每个公司的所谓的管理层对自动化理解的层面可能不一样，需要根据实际情况来做自动化，至少中心点不能偏离，需要紧扣业务，另外就是要能实际落地，还有一个就是维护成本及投入产出比。

扫地僧 #3 · 2016年10月21日 Author

#1 楼 @CwXwWw
是否要考虑成本？当然要考虑，我们总会遇到在成本和质量之间找平衡点，可能一些特殊的行业，特殊的项目，质量的权重更高点，如果引入自动化能提高质量，该介入的还是要介入。
抓住业务测试工作中的痛点和领导的痛点，多沟通多交流，优先解决基层的工作痛点，我相信一个好的领导会看到你的责任心和付出

0x7C00 #5 · 2016年10月21日

看到题主关于自动化的分享，有几个延伸问题，自己在工作中一直思考，但是一直没有找到合适的答案。

接口自动化和 UI 自动化的用例是完全重新设计，还是从业务用例中筛选？IF 从业务用例中筛选的话，筛选的标准有哪些呢？（PS：接口用例中的接口参数类型的用例设计，暂不考虑）
接口自动化和 UI 自动化，互相之间有影响吗？或者说接口覆盖的用例和 UI 覆盖的用例之间是否有某种关联？IF 有关联，请问需要多大粒度的关联比较合适？ELIF 没关联，请问两者之间各自为战吗？（PS：这样会不会导致测试覆盖率重复呢？）
如果 UI 层的用例 Faile，是不是需要定位到对应的接口层？相反，接口层用例 faile，是否需要定位到 UI 层，IF 以上需要，如何有效关联呢？Or 是否需要在分层测试的工程中，让他们互相成为彼此的辅助？

chen #6 · 2016年10月21日

自动化是必须要做的，特别是对需要快速迭代的业务系统。没有一个领导不喜欢提高效率的事，成本太大？我觉得那是测试代码写的太烂，抽象度不高等的问题（当然也有特例）

0x43 #7 · 2016年10月21日

#4 楼 @taflo 一个测试组中每个测试人员的代码能力不一样，甚至不敢想象有的测试人员根本不懂代码（我真的遇到过），所以那些喊成本太大的也就能理解了，所以说提高测试人员的整体素质和门槛还是很有必要的，不能被这个浮躁的社会左右。个人见解。

chen #8 · 2016年10月21日

#5 楼 @CwXwWw 代码能力不一可以靠 code review，写多自然会提高。不会代码那就要学啊，测试也是技术岗位会代码是件很正常的事。不想学？呵呵，那就等着被淘汰吧！

0x43 #4 · 2016年10月21日

#6 楼 @taflo 是的而且这种趋势已经越来越明显了没有 code 能力的 tester 真的很快失去竞争力的尤其是这两年看各个岗位对测试的招聘要求也相对前面几年在不断提高

扫地僧 #9 · 2016年10月21日 Author

#3 楼 @xie_0723 你提的问题很好，我也曾思考过这些问题，以下答案仅供参考：
接口自动化和 UI 自动化的用例是完全重新设计，还是从业务用例中筛选？IF 从业务用例中筛选的话，筛选的标准有哪些呢？（PS：接口用例中的接口参数类型的用例设计，暂不考虑）
－－我觉得接口自动化案例要重新设计，这里涉及到分层的概念，接口层更关注对数据的验证，处理各种请求参数正交场景下返回数据的正确性，涉及到增、删、改的接口还要关注数据落地的有效性。

接口自动化和 UI 自动化，互相之间有影响吗？或者说接口覆盖的用例和 UI 覆盖的用例之间是否有某种关联？IF 有关联，请问需要多大粒度的关联比较合适？ELIF 没关联，请问两者之间各自为战吗？（PS：这样会不会导致测试覆盖率重复呢？）
－－接口测试不一定和 UI 测试有关联，传统的接口测试，不需要等 UI 开发完成就可以介入了，从这点来说属于前置阶段的，通过 Mock Client 实现的接口测试；
－－UI 测试和接口测试一定有关联，因为 UI 层的数据渲染大部分是通过调用接口获取的，在执行 UI 自动化的同时，有很多眼睛看不到摸不着的接口在来回穿梭，这些不是 Mock Client 发起的，而是由真实的程序发起的，场景化内部的参数动态关联等一系列问题，程序都会帮你自动处理。所以由 UI 测试发起的接口测试，只要你能劫持到接口返回的报文，实现起来比传统的要简单多了。

如果 UI 层的用例 Faile，是不是需要定位到对应的接口层？相反，接口层用例 faile，是否需要定位到 UI 层，IF 以上需要，如何有效关联呢？Or 是否需要在分层测试的工程中，让他们互相成为彼此的辅助？
－－UI 层 Fail，接口层不一定 Fail，因为即便接口是正确的，也不能保证 UI 层的数据再处理不会犯错。相反，接口层 Fail 了，与之相关的 UI 层必定 Fail。如果接口层 Fail，我们可以通过一些手段，例如：获取接口关键字、定制 traceID，通过这些唯一性标识去定位错误日志或代码行。

最后，建议你看一下关于 Mock Better 的这篇文章，和你的问题有相关，https://testerhome.com/topics/6121。