2018-07-06手工测试还涉及到一个人性的问题。
某些手工测试团队考核的标准就是找到的bug个数，个数越多绩效越好。而开发人员开发的代码，在一些问题上算不算bug有不同的见解。然后就开始扯皮了。作者回复: 以缺陷数量来衡量测试的绩效是不可取的，而且还会激化测试和开发之间的矛盾。
1 26
2018-07-06实际项目中使用自动化的部分，接触过gui自动化测试，接口测试，性能测试。
执行次数肯定是远大于5次的，毕竟开发和维护成本都要算进去，收益远超手工测试时才会考虑去做。除非是“面子工程”，用来应付某些场合。
不过还是很好奇作者的“5次”这样一个分水岭是怎么来的，是否依据经验总结得来。作者回复: 5次完全完全是经验值，因为这个主要取决于自动化测试的开发成本，如果你有很好的框架，自动化用例开发的成本比较低，那么这个值就会偏小，如果有你的测试框架很低效，那么开发自动化用例的代价就很大，那么这个值自然就好大
18
2018-07-06在我之前参与的一个敏捷团队中，对自动化测试理解可能有些不一样，自动化测试更多的是被认为是保护已有软件功能的一张安全网，由QA和dev共同开发，和软件系统本身的功能代码一起成长，每当有新功能代码commit进主线的时候就会触发，以检测新代码是否会破坏原有功能。作者回复: 你说的是正确的，commit之后通常会自动触发静态代码扫描和单元测试，如果两周都通过后、通常会执行自动部署，然后还会自动执行smoke和e2e测试，这些都是自动化的范畴，后面的一篇文章会专门来讨论这个
16
2018-07-11自动化测试如果由自动化测试架构工程师来牵头实现，辅以业务功能的开发或测试人员构成核心团队，这样的企业级自动化测试的成本和收益应该是线性回归的：1.测试架构师负责企业级核心代码的复用设计及实现，2.项目团队内负责功能共用模块的抽取，3.两者结合建立自动化测试数据池仓库的建立，4.结合项目具体情况做自动化代码实现的二次设计。作者回复: 非常棒的分享，我们以前也尝试过这种模式，效果还是不错的
9
2018-07-06现在好多公司完全把业务测试和测试开发分离开来，导致开发自动化的人不理解业务，业务用自动化工具的觉得工具不够符合业务，这样往往就是自动化成效不高，所以我一直建议测试开发要去做业务，业务要去理解怎么利用代码和工具提高效率.作者回复: 是的，你说的这个是很多公司都有的典型问题，懂自动化的不懂业务，懂业务的不懂自动化，必须要让两者能够有机的结合，否则效率很难提高，之前有提BDD其实就是为了解决这个问题，但实际落地过程中大量的mapping又引入了很多新问题
1 9
2018-07-06我们产品迭代很快（一周一个版本）连测试用例都没办法写全，只能写写测试点，更不要提自动化了，每次刚开个头就没有然后了作者回复: 这种短期项目就不太适合自动化测试，对于这类项目的测试重点可以放在如何设计有针对性的测试用例上面，建议可以开展手工探索式测试
8
2018-07-06自动化的出发点是提高效率和质量监控。盲目追求所谓的“全自动化”往往得不偿失，应根据项目实际情况做出选择。可退而求其次选择“半自动化”测试，辅助手工测试来提升效率，比如开发小工具来做资源的整合（脚本执行结果自动同步案例管理系统及缺陷系统、批量执行案例生成可视化报告、表断言检查、依赖开源框架搭建性能测试平台等）。作者回复: 说得非常对，👍
7
2018-07-11老师，您好！我是一名刚毕业的学生，从事软件测试有快两个月，在公司做的是功能测试，最近看第四讲到第六讲都很懵，不知道老师能否给我些建议，如何更好的去了解消化这些知识！作者回复: 这应该不是你一个人会有这种感觉，因为第4-6讲不是基于黑盒来谈测试的，而是从软件实现的内部，即从白盒的视角来谈测试，所以需要你具有一定的代码能力，至少能够明白一门高级语言。但是你也不用太担心，因为基于代码的测试我们后面还会有专门的篇幅，那边我会以更多的实例来讲解，希望能够对你有帮助
5
2018-07-06目前项目中落地的重点还是接口测试的自动化，单元测试推不动，UI自动化耗时耗力效果也不好，项目更新太快，前端页面频繁变更，不适合做UI的自动化测试作者回复: 你说的是很典型的案例，但是还是建议有最基本的GUI测试当作smoke来用，保证产品基本功能的可用性
5
2018-07-29我做自动化测试有8年了，从通信到传感器到现在的车联网。通信领域就非常适合做自动化，无非就是造包解包，各种场景都是可以模拟的，可以说自动化覆盖率基本达到百分百 3
2018-07-09我觉得比较难的部分在于如何使数据准备自动化，尤其当需要的业务场景比较多的时候作者回复: 是的，非常对，尤其是数据参数又很多的时候，这个问题会更突出，后面文章我会专门来讲这块
3
2018-07-06我们这里现在是要求做api开发的后台，都要对自己的功能写测试用例，实现自动化测试，主要是出于对自己的开发功能的保护和负责，并未把自动化测试划给测试的同事来做作者回复: 这个就是目前比较流行的做法，最理想的情况是工程效能团队可以提供更好的工具去支持开发自己做测试，比如提供方便的测试数据准备工具，测试执行服务等等
3
2018-07-06我想说尽管是软件产品，它在不断发展过程中，也有项目迭代非常忙的时候，比如测试时间只有不到5天，质量的方针仍然定为接口测试为主，导致最终线上bug率很高，但是至今TL仍意识不到这个问题，规定一个月要写20个接口的自动化测试用例（补齐老用例），并把此列入绩效考评，可这是按量来的事么，测试人员不去看代码实现逻辑，简单的通过入参返回值去写用例，覆盖率难以提升，最终只能收效甚微，变成面子工程。作者回复: 一定不是为了测试而去测试，测试的根本在于寻求最高效的方法去发现尽可能多的问题，如果单单以用例数量做为衡量标准一定会本末倒置，用例不在于多，而在于针对性和全面性
3
2019-02-28现在想来也就是待得第一家公司做过稳定性测试，属于一点自动化测试的范畴。后面的基本就是接口测试比较多了，且执行次数都没超过5次的，得不偿失，最后腰斩的很多，且流于形式。
现在互联网迭代中周期短，研发测试配比高，很多小的创业公司对于测试人员可有可无的思想阶段。但是从长远看，大的公司，必定把质量放在第一位的，所以，做一个全栈性的测试人员，懂代码、懂沟通，能够全面把控质量关，是我们每一个测试人员努力的方向！ 2
2019-02-12点点到位，拳拳到肉。
非常赞同茹老师的分析，说说我们项目的现状：
1.一直有推进自动化用例覆盖率，但是经常改动的部分需要自动化用例频繁同步更新，不经常改动的部分，自动化的必要性又不大；
2.GUI 改动多，但是实施难度大，就好比茹老师提到的图形验证码的例子；
3.测试开发和业务测试是分开的，导致懂业务的不懂实现，懂实现的不懂业务；
目前我们的解决办法：
1.优先考虑 P1 优先级的用例覆盖，以及需要经常回归的功能点的自动化用例覆盖；
2.开发提供必要的支持，提供特殊版本文件辅助自动化实现；
3.测试开发负责架构实现，并设计好必要的分层，业务测试负责自动化函数需求的提出和调用；
以上，欢迎沟通交流。展开 2
2018-12-12个人觉得测试和测开是可以共存的, 如果把自动化测试当成一个正经的项目去对待,那么测试就是产品,他回去提出需求(比如我需要什么样的工具去帮助我提升手工测试效率);而测开去实现这个需求.
由于资源有限,我司目前的做法是找成熟稳定的自动化测试框架,由组内有代码基础的同学去实现,目前已经完成的有:一些自动生成数据的python小工具, HttpRunner实现接口自动化;Jmeter+zabbix实现接口压测;Appium / TW维护GUI(GUI收效相对较低,由于版本变动,投入的资源多).
建议先从一些小工具入手,既可以提升自己的水平,也能在短期内提升工作效率. 2
2018-07-12测试数据的自动化在自动化测试的维护成本中有着举足轻重的作用，我认为测试数据的多样化和自动化也会给自动化测试带来了探索性和智能化的契机……作者回复: 非常正确👍，所以我们后续会专门来讲测试数据
2
2018-07-06同意自动化测试是安全网的概念，自动化测试的价值点主要会是在回归效率，还有一些复杂场景模拟上，自动化测试脚本的架构设计也会影响维护效率。CI和CD里面，自动化测试、性能自动化和安全自动化（扫描为主）都是重要应用，单元测试也是自动化测试的一种，还有契约测试等。
结合用例和脚本自动生成计划，GUI和API都可以减少编写成本，不过个人对于智能技术在这里会是一个很重要的应用场景，具体怎么落地还没想明白，但大家可以多沟通研究下。作者回复: 你说的很在点子上，后面的一篇文章就会专门讨论这个话题，后续我也还会在适当的时候来谈“如何自动化你的自动化测试”
2
2018-07-06赞同您的说法，软件测试的目的是发现问题，如果自动化测试维护成本高于它带来的测试效率和价值，就失去了本身的意义。测试工程师热衷于自动化测试学习很重要的一个原因也是适应新的工作竞争吧作者回复: 所以有些时候就需要去平衡两者之间的关系
2- 2018-07-06对了，个人理解，CI/CD应该也算自动化测试的范畴吧，也是应用了自动化技术，提高手工效率的，而且非常实用。
作者回复: CI/CD应该属于devops的范畴，CI/CD往往是自动化测试的发起者，关于广义的我自动化测试，在下一篇文章中我会详细来展开
2