2022-01-30 09:52:42|已浏览：2152次
一、单元测试
单元测试引入
软件的问题，90% 都是编码的问题。在编码阶段发现问题，不会对任何人有影响，并且可以随手改掉，这也是成本最低，效率最高的。
那么单元测试如何执行呢？一句话，就是一行一行执行代码。只有让代码跑起来，才能发现代码的问题。单元测试带来的收益还有很多，例如：更好的模块设计，更放心的代码重构等等。
当然，任何事情都有两面性，单元测试也不例外，这需要持续编写测试代码。这也就是出现了两极分化的情况：
一般的大厂，都会做单元测试，因为这是减少缺陷，提高效率的方式；
而一些小厂，可能就不会考虑这么多，毕竟人员、资源都有限…
投入产出比
测试投入：🌟🌟🌟
测试产出：🌟🌟🌟🌟🌟
测试指数：🌟🌟🌟🌟🌟
冒烟测试引入
每个测开的大佬，都会有过修复了1个缺陷，引入10个缺陷的经历。开发大佬提供的版本，不是闪退就是无法运行，计划中的特性测试根本没办法开展。每次出现这种情况，都需要PM出面，否则可能会休长假…..
而解决这些问题，最好的方法就是给开发提交测试版本设置的一道防线，即冒烟测试。如果说回归测试是追求大而全，那么冒烟测试追求的就是小而精。
冒烟用例/测试环境/执行入口 由测开人员提供，覆盖本次提交版本的核心功能，涉及主流程，冒烟测试通过，可以说明开发的代码改动没有很大问题，软件也有了基本的质量保证，后续的测试阶段也可以陆续展开。
冒烟测试作为开发提测的一道防线，可以减少浪费，提高效率，冒烟测试用例比较少，因为开发和维护成本就低很多，主要的成本是冒烟用例失败的定位分析成本，这是一件持续的事情。
投入产出比
测试投入：🌟🌟
测试产出：🌟🌟🌟🌟🌟
三、灰度测试
软件的依赖
软件测试中，有一个根深蒂固，也是很普遍存在的问题：预发环境都OK的功能，上线后，就出现各种问题，在大厂的人，应该是很有感触的。
我们都知道，软件是运行在特定环境中的，软件的的实际行为与其所处的环境具有高度依赖性。
软件运行的终极环境是生产环境，只有在生产环境测试通过，我们才能说软件有风险的几率非常低。但是在生产环境做测试，风险是很大的，对用户的影响也很大，这个时候，就需要引入灰度测试。
引入灰度环境
在灰度测试中，通常将待发版的软件部署到部分生产环境(即灰度环境)上，然后将测试流量或者部分用户流量引入到灰度环境。
如果你是某软件非常活跃的用户，你会收到某新功能的体验邀请。例如：支某宝邀请你参加体验xx新功能、某信邀请你体验xx新功能......
灰度测试实现了在生产环境对软件的终极验证，是软件发布前的最后一道防线。它的投入(环境配置/引流/自动化用例)等是一次性的，但是其产出是显著的(提前于用户发现问题)，并且可以持续产出(每一次软件升级都受益)。
投入产出比
测试投入：🌟
测试产出：🌟🌟🌟🌟🌟
测试指数：🌟🌟🌟🌟🌟
注：尊重原创文章,转载请注明出处和链接 https://www.pxwy.cn/news-id-19342.html 违者必究！部分文章来源于网络由培训无忧网编辑部人员整理发布,内容真实性请自行核实或联系我们，了解更多相关资讯请关注软件测试频道查看更多，了解相关专业课程信息您可在线咨询也可免费申请试课。关注官方微信了解更多：150 3333 6050
