测试开发详谈：三种高性价比测试方法

lsekfe

1 引言
　　最近也是临近年底，各位小伙伴也是蠢蠢欲动，
　　小鱼最近也是没闲着，除了加班，还在做一项"公益活动"：one by one 的指导想要体现自己价值的小伙伴。
　　在面试指导过程中，小鱼发现，即使有10N+工作经验的小伙伴，其实对测开的理解，还停留在3N左右的经验上，这不禁让小鱼我惊叹(下巴没惊掉)…
　　所以，小鱼也是决定，开一个专栏，来详细分享测开领域的专业知(zi)识(shi)~~
　　我们都知道，测试领域的测试方法，很多种(多的不少于100种)，
　　所以那些所谓的说测试很简单的人，你就呵呵 他 就行！！
　　而在这100多种测试方法中，有三种，是能非常体现出高效产出比的。
　　我们今天，就来聊一聊 这三种测试方法：
　　灰度测试
　　冒烟测试
　　单元测试
　　小鱼一直推崇的都是高效产出比，
　　有的时候，要屈服于现实…但，这不等于放弃
　　2 单元测试
　　2.1 单元测试引入
　　软件的问题，90% 都是编码的问题
　　在编码阶段发现问题，不会对任何人有影响，并且可以随手改掉。这也是成本最低，效率最高的。
　　那么，单元测试，如何执行呢？
　　一句话，就是 一行一行执行代码。
　　只要让代码跑起来，才能发现代码的问题。
　　单元测试带来的收益，还有很多，例如：更好的模块设计，更放心的代码重构等等。
　　当然，任何事情都有两面性，单元测试也不例外，这需要持续的编写测试代码。
　　这也就是出现了两极分化的情况，支持派与反对派。
　　一般的大厂，都会做单元测试，因为这是减少缺陷，提高效率的方式；
　　而一些小厂，可能就不会考了这么多，毕竟人员，资源都有限…
　　但是，小鱼还是那句话：
　　任何事情，都量力而行！
　　2.2 投入产出比
　　测试投入：3
　　测试产出：5
　　测试指数：5
　　3 冒烟测试
　　3.1 冒烟测试引入
　　每个测开的大佬，都会经历过：
　　修复了1个缺陷，引入10个缺陷；
　　开发大佬提供的版本，不是闪退，就是无法运行，计划中的特性测试根本没办法开展。
　　每次出现这种情况，都需要PM出面，否则…（可能会休长假…）
　　而解决这些问题，最好的方法就是，给开发提交测试版本设置的一道防线，即冒烟测试。
　　如果说回归测试是追求大而全，那么冒烟测试追求的就是小而精。
　　冒烟用例/测试环境/执行入口 由测开人员提供，覆盖本次提交版本的核心功能，涉及主流程。
　　冒烟测试通过，可以说明开发的代码改动没有很大问题，软件也有了基本的质量保证，后续的测试阶段也可以陆续展开。
　　冒烟测试作为开发提测的一道防线，可以减少浪费，提交效率。
　　冒烟测试用例比较少，因为开发和维护成本就低很多。
　　主要的成本是冒烟用例失败的定位分析成本，这是一件持续的事情。
　　3.2 投入产出比
　　测试投入：2
　　测试产出：5
　　测试指数：5
　　4 灰度测试
　　4.1 软件的依赖
　　软件测试中，有一个根深蒂固，也是很普遍存在的问题：
　　预发环境都OK的功能，
　　上线后，就出现各种问题
　　我想这在大厂的人，是很有感触的。
　　我们都知道，软件是运行在特定环境中的，软件的的实际行为与其所处的环境具有高度依赖性。
　　软件运行的中级环境时生产环境，只有在生产环境测试通过，我们才能说软件有风险的几率非常低。
　　但是，在生产环境做测试，风险是很大，对用户的影响也很大，那这个时候，就需要引入了 灰度测试。
　　4.2 引入灰度环境
　　在灰度测试中，通常将待发版的软件部署到部分生产环境(即 灰度环境)上，然后将测试流量或者部分用户流量引入到灰度环境。
　　如果你是某软件非常活跃的用户，你会收到某新功能的体验邀请…
　　例如：支某宝邀请你参加体验xx新功能；
　　某信邀请你体验xx新功能。
　　灰度测试实现了在生产环境对软件的终极验证，是软件发布前的最后一道防线。
　　它的投入(环境配置/引流/自动化用例)等是一次性的，但是其产出是显著的(提前于用户发现问题)，并且可以持续产出(每一次软件升级都受益)
　　4.3 投入产出比
　　测试投入：1
　　测试产出：5
　　测试指数：5
　　5 总结
　　今天聊的三种测试方法，
　　不期望每个公司都能够完全推行，但是至少各位测开同学，能够了解，熟悉，掌握。
　　至少在测开领域，掌握足够多的知识，是进大厂的资本，也是提升收入的资本。