29 | 自动化测试：如何把Bug杀死在摇篮里？
该思维导图由 AI 生成，仅供参考
为什么自动化测试能保障质量？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
自动化测试在软件开发中扮演着至关重要的角色。本文深入介绍了自动化测试的概念、类型和实施方法。作者通过项目经验分享了自动化测试的重要性，指出其能够提高软件质量、降低测试成本，并在持续集成中发挥关键作用。文章详细介绍了小型、中型和大型测试的区别，以及如何编写高质量的自动化测试代码。此外，作者还提供了实施自动化测试的建议，帮助读者在项目中应用自动化测试。总的来说，本文内容丰富，适合技术人员快速了解自动化测试的重要性和实施方法。 文章首先强调了选择适合的自动化测试框架的重要性，针对不同语言和平台提供了相关框架的参考。其次，强调了在持续集成环境中运行自动化测试的重要性，以及新项目和老项目在自动化测试策略上的不同。最后，作者提供了应对时间紧迫任务繁重情况下的建议，并总结了自动化测试的三种类型和基本原则。整体而言，本文为读者提供了全面的自动化测试知识，并鼓励他们思考和分享在项目中提高自动化测试代码覆盖率的方法。 自动化测试是软件开发中不可或缺的一环，本文内容丰富，适合技术人员快速了解自动化测试的重要性和实施方法。
《软件工程之美》，新⼈⾸单¥59
全部留言(24)
- 最新
- 精选
勇闯天涯请教老师，我现在做的是嵌入式设备，要跟很多硬件外设打交道，这块的自动化测试和持续集成有什么好的建议吗？我看到文章中大多提到的都是互联网相关的方法和工具作者回复: 我对嵌入式和硬件不懂，没有这方面的经验。不过软件和硬件的开发，都属于工程开发，这里面其实有很多道理是相通的。 吴军老师写过一篇很好的文章：《把事情做好的三条边》，里面举了莱特兄弟发明飞机的例子，莱特兄弟在试飞之前，打造了一个风洞，进行了上千次的风洞试验，这样可以不需要上天就可以对飞机进行测试。而同时期的很多飞行发明家，自己打造了一个飞机就上天，很多都摔死了。 自动化测试其实有些类似于风洞试验，相对于手工测试，可以“低成本”、“高效率”的对产品进行反复的测试和验证，每次提交代码就可以自动运行测试，马上收到反馈。 从软件的自动化测试和飞机的风洞试验，可以找到一些可以借鉴的点： 1. 找到了一条低成本测试的方式 风洞试验，可以降低飞行测试的成本，不必付出生命代价就可以测试结果； 软件的自动化测试，刚开始写的时候是要付出一些成本的，但磨刀不误砍柴工，运行次数越多成本越低。 嵌入式系统是不是也可以找到一条低成本、模拟的、反复测试的方式？ 2. 可以模块化的测试 软件的自动化测试，主要有单元测试、集成测试、端对端测试这三种自动化测试类型。单元测试成本是最低效率最高的，而集成测试和端对端测试成本要高很多，所以通常单元测试最多，集成测试次之，端对端测试最少。 我想莱特兄弟发明飞机飞机之前，在组装成整个飞机之前，对各个模块也是有单独的测试，而且测试的应该和自动化测试的比例也是类似。 那么嵌入式系统的自动化测试，是否也可以分模块化的进行测试？让模块的测试占更大比例？ 3. 可以即时得到反馈 软件的自动化测试，尤其是结合CI（持续集成），可以即时得到反馈。每次提交代码修改，就会出发自动化测试任务，这样一旦有导致自动化测试失败的代码，能即时发现。 风洞试验也是类似的，飞机不用上天，通过风洞的测试，马上就能得到反馈。 嵌入式系统的自动化测试，是否也可以做到即时反馈？在作出修改后，能否马上得到测试结果的反馈？ 以上三点是我认为可以从软件自动化测试借鉴的地方，希望有所帮助！
2019-10-1419
yu.net core 的同學，我們項目使用 NUint 進行單元測試，集成測試可以使用 WebApplicationFactory，模擬工具可以使用 Moq作者回复: 赞，感谢回复！🙏
2019-05-068
易林林请教宝玉老师：团队成员的能力和素质参差不齐，如何有效的去组织和管理项目的自动化测试，自动化集成？作者回复: 首先，你要先搭建好自动化测试环境，让自动化测试代码能跑起来，最好最好要和CI（持续集成工具）整合在一起，每次提交代码CI都会跑自动测试，然后能看到运行结果。 然后，把自动化测试作为开发流程的一部分，比如说要代码审查和自动化测试通过后才能合并代码。这部分工作如何和CI集成会容易很多。 再有就是要培训，比如遇到不会写的，开始先带着他写几个，确保他学会了自己能写，然后下次代码审查的时候，看到缺了就要求补上，还不会就继续教，来不及写的就创建个TIcket跟踪起来。 简单来说，就是代码审查+CI+培训
2019-05-048
Joey请教宝玉老师： 消息类接口应该通过哪种方式高效、有效维护？ 现状： 系统A属于联机类系统（高并发、低延迟），其中接口B与多个应用相关，当接口B的定义发生变化时，往往忘记通知相关方或者漏通知，从而引发生产事件。 尝试过的手段： 1、通过流程约束，需求评审阶段，强制增加是否有接口变化的评审，但是落实结果不理想，主要因为增加流程，开发人员嫌浪费精力，最后流于形式。 2、通过自动化手段约束，原则上要求接口必须在CI阶段有自动化用例守护，但是效果也不理想，自动化用例缺失或者开发人员懒的写自动化用例，最后流于形式。（我们部门研发和测试属于不同的团队，所以开发人员对于代码质量，都指望测试人员守好最后一道关卡。）作者回复: 我觉得对于API，应该要有版本的概念，也就是一个版本的API在确定前，多论证，多确认，确认后就不要做大的改动，大改动就用新版本，新版本上线时，旧API应该持续运行一段时间。 然后对于API修改后，应该当作一个小项目来看待，也就是要确保通知所有相关方，确定API切换的时间点，帮助调用房升级迁移到新版本。 最后再是自动化测试帮助检测。
2019-06-265
熊猫老师你好，请问下有没有介绍开发如何写好测试不错的书？作者回复: 推荐：《how we test software at microsoft》中文版《微软的软件测试之道》 不过没有书其实你也可以找到很多资料的。比如我平时写前端程序，那么我会去GitHub或者Google，通过关键字、语言找跟我项目类似的开源项目，然后看其中有没有自动化测试写得好的，找到了(例如：reactstrap、electron-react-boilerplate、kitematic)就照葫芦画瓢好了，因为都是真实项目，所以特别简单有效，建议你也可以试试。 另外耐心一点，你也可以看到很多关于测试知识分享的技术文章，多看一看也有收获。
2019-05-074
小老鼠1，小型、中型、大型自动化测试是不是对应单元、集成、系统测试。2、现在测试金字塔模型已经被防锤模型替代了，GUI自动化减少，Interface自动化测试增多。3、有没有必要小、中、大型自动化测试覆盖率均达到100％？4、开头你们前端改造项目自动化测试釆用GUI还是Interface？若是GUI，有多少个测试用例，每个测试用例执行时间有多长，所有测试用例执行有多长。若是Interface ，如何测试前端？5、前端有没有自动化测试框架？作者回复: 1. 一般来说是这么对应的 3. 没有必要达到100%，这样做成本太高，需要有一个平衡和取舍 4. 我们项目集成测试和单元测试都有。 我们前端项目基于React开发的，所以接口的测试基于React的单元测试接口。 各有几百个测试用例。 整个测试单元测试很快，一分钟不到，集成测试要长一点，5-10分钟。 5. 前端框架都有测试框架，比如React/Vue都有单元测试框架，可以查阅其文档
2019-09-243
Liber宝玉老师你好，有个地方感觉有必要再展开谈谈： 以本文注册用户为例，本文分别对这个case写了小、中、大型测试用例，但实际开发过程中，如何权衡对一个场景是该小、中、大都写，还是只写部分？作者回复: 实际开发中，理论上来说一个场景大中小测试都要写的。 通常来说，开发写小型测试和中型测试，测试写大型测试，或者开发帮助写大型测试。 小型测试：中型测试：大型测试比例大约为 7:2:1 小型测试尽可能多覆盖，不要求100%，谷歌是85% 中型测试覆盖大部分用户使用场景 小型测试覆盖主要用户场景
2019-05-133
hua168宝哥，我想问一下： 1.开发哪些测试需要自己写的呀， “测试驱动开发”的概念，开发应该要会写测试吧？ 到底要求会写哪些测试？ 2.现中小公司都没有自动化测试工程师，写好测试手工检查的多，怎搞？ 开发学一点selenium3自动化测试之类会不会好点？ 3.单元测试是不是数据越简单越好，最好不使用数据库，在dao层组或map 4.集成测试和大型测试用数据库则比较好，对吗？作者回复: 1. 文章中的小型测试和中型测试都应该是开发来写的。大型测试一般是测试开发工程师来写，也可以开发写。 2. 这个必须要去学习的， 3. 单元测试不能使用真实数据库，必须要模拟数据访问的，否则速度太慢也不稳定 4. 集成测试一般用本机的数据库，或者也可以模拟数据。大型测试肯定用真实数据库的。
2019-05-043
Zebin宝玉老师，请教下，我们现在LINUX环境下开发项目，主要编程需要是C/C++。 现在想搭建持续集成开发环境，有什么合适的工具可以推荐下吗作者回复: 单元测试你可以用gtest，集成测试工具你可以参考我之前 那篇集成测试的文章，比如说试试Jenkins或者Gitlab CI。 具体怎么搭你可以参考网上的教程，应该已经有很多了
2019-05-0822
起而行老师，持续集成怎么理解呢，我看知乎上说就是团队成员在一天内多次进行编译，发布或自动化测试作者回复: 狭义的持续集成不包括发布，主要指集成，持续的（每次提交代码变更都触发，频繁的提交）对代码进行集成（合并到主干），但集成前要确保自动化测试通过。 广义的持续集成还包括部署，也就是集成后自动部署测试环境(持续交付)或者生产环境（持续部署）。 在《26 | 持续交付：如何做到随时发布新版本到生产环境？》这一篇里面有详细介绍。
2019-05-042
