这个“常见”，是说当我们经历多了之后，会发现这个概念其实很常见，在当前你所处的这个人群中，发现大家都挂在嘴上。
在最开始的测试学习中，其实很少提到这些概念，在职业生涯的前期，也很少需要考虑这些概念。
分级测试一般用在系统测试阶段。
分级测试，就是说对测试进行分级，区分什么重要、什么不重要，做区别对待。
之所以需要区别对待，我总结有两个原因。
一个是因为资源上的限制，时间、人力，让我们没有条件来做无差别覆盖。
二是本身的限制，在测试阶段，提测质量往往是不尽人意的，只能是层层深入去做测试。
然后如何去分级呢，从测试周期角度来看，我们有看到有冒烟测试、第一轮测试、第二轮测试、回归测试（有些周期里会有第三轮测试），而从本质上去看呢，这些不同阶段测试执行的标准，其实是测试用例的分级。
那么，如何来对测试用例进行分级呢？
从编写用例的时候，我们会有这么一个根据操作的顺序来编写用例：
基本的功能点，或叫常规操作——>复合操作功能点，关键的组合功能，扩展操作——>前两者以外的，性能、压力等，称为异常操作——>根据经验，进行的探索性操作
我们按重要性，又有一个分级：
非常重要：该功能是后续很多功能的前置功能，若是该功能失败，后续很多功能都无法运行。
重要：该用例对应的功能使用频次较高，为主要功能
一般：该用例对应的功能使用频次较低，功能稳定，出现问题影响不大
次要：功能稳定、发生错误的可能性很小或者危害很小
这两种方式，前者划分会比较清晰。
然后说灰度测试。
灰，就是介于白和黑之间，就是并非是测试人员、也并非直接发布到线上让所有用户看到。
灰度测试，其实已经不在常规测试方法里了。
它的出发点，是发布了一些东西，但不确定效果和稳定性，所以先放一部分特定用户进来。
所以测试过程，并不是由测试人员进行的，而是真实用户，观看效果的，包括技术、客服、运营，都会一起参与。
这个测试方法，是公司层面（往小了说是项目组层面，有些项目组配套会齐全）进行的行为。
一般执行这种测试，有两种办法：
1、软件自带灰度测试发布功能；
2、使用第三方工具进行，比如iOS平台的TestFlight
灰度测试具体执行步骤如下：
1、确定自己的目标；
比如发现稳定性问题、发现品质问题、发现前后转化效果对比；
2、选择策略；
包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略（就是如何发布）；
3、对用户进行筛选；
根据前两者，确定用户画像；
4、部署系统；
部署新系统（灰度要测试的系统），部署用户行为分析系统，设定分流规则，运营数据分析，分流规则微调；
5、发布总结；
用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表；
6、产品完善；
7、新一轮灰度发布或完整发布；
最后说AB测试。
AB测试和灰度测试很相似，但是有本质上的区别。
灰度测试发布的新系统，是一种预发布、预测试，是上线之前，如果没问题，新系统会覆盖旧系统。
所以灰度测试本质上是一种上线前的测试，收集用户反馈。
比如网龙的《魔域》，就有一个给玩家玩的测试服，会提前发布版本，用户在里面能够比其他服务器玩家提前体验到新的游戏内容。
而AB测试，是说通过软件自身，让不同用户面前，对同一个软件功能展现两种不同的方式，进行效果对比获得用户反馈。
AB测试本质上，是上线后的测试，收集用户反馈。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/235000.html原文链接：https://javaforall.cn
