测试思维的突破

下面内容，有关停了茹老师的分享后的沉淀

一：聊聊自动化

对于自动化，存在几个误区。
1：认为发现问题才是有价值的。
其实不是，需要明白一点，自动化的内容，更多的是已经稳定的功能或者平行产品的回归，那么这个时候，跑了一遍流程，没有出现问题说明是好事，说明质量（至少是自动化测试的对象）上是过关的，相反，如果测出问题，反而项目质量上令人担忧。
所以在评判自动化的成果、或者说老板看工作结果时，不是看发现了多少错误，而是逆向，看成功的概率。

2：一直以来强调的测试左移的思想引导
测试左移大家都听过，测试越早进行，成本越少，但是不适用自动化，自动化的对象需要是稳定了，一般产品迭代中，到第三版了，可以开始自动化了，这个时候，相对稳定，而且前面功能测试已经先行踩了不少的坑，问题也相对少。

3：自动化对象的选择，拍脑袋性的选择模块做自动化。
功能点那么多，哪些对象做自动化，这个需要把握一个点：抓核心
不是说全覆盖就是最好的，要考虑成本和产出比，抓住核心。
怎么获取核心，可以用离散数学，比如说页面的跳转，每个页面的跳转是一个节点，用户实现A->B就是在A、B之间画一个A指向B的有向联系，点击次数为权重，最终数据分析取出核心点，进行测试，同时这个要做到细致。

二：停止低效的工匠精神

less is more。
测试上，不是进行地毯轰炸就是好的，要做到一个精准测试。不是所有的场景都是测试到没有问题就是好的，需要考虑到时间成本，而有些场景下，比如说节日活动，竞商直接竞争，可能粗略、没有测试就上线了，这时策略上采用灰度测试。
灰度测试
假定产品是个简单模型，在一个负载均衡器下挂了多个应用节点，那么发布之前所以结点版本都是1.0.具体做法：
1：在众多结点中找一个结点从负载均衡器下摘下（摘下就是用户请求过来时，这个负载均衡器不会把用户流量引到这个结点）
2：对选中的节点进行发布2.0版本
3：将此节点接入负载均衡器，
4：对负载均衡器配一个流量分发策略，比如让万分之一的流量到此节点，并后台开发、测试实时对server端人肉监控，有报错立刻修改，并发布3.0，以此类推。（其实就是用户来做功能测试）
5：若此节点运行没有问题了，再逐步对其他节点进行版本的更新。
注意！对其他的节点版本更新不能马上全切，因为没有进行压测，所以要逐步，如果到一个开放度发现压力指标不对了，也是要回滚，退回修改。
对于遇到了功能障碍的用户，可以进行一个经济上的反馈等安抚客户。

实际场景下测试模型

大家推崇的都是正三角形模型，单元测试占的比重最多，UI层的测试比重最低。
实际上，更多的是冰淇淋（倒三角）模型，UI测试占大头，单元、API反而占比很小。
然而现在，更多的推崇菱形模型，UI、单元测试比较少，API、接口测试比较多，最上方飘一朵云，是探索性测试，探索性测试的重要性不可忽视。
而对于模型的选择，没有具体的评判标准，具体项目具体分析，更多的时候是项目中融合了各个测试模型，不同的子项用不同的模型处理。

比如说，一个项目系统中各个模块的调用，通过上面说的获取调用关系和权重的比例图后，那些权重的关键节点，要做到严格的单元测试，接口测试，要做到高代码覆盖率，要完全覆盖率，当然，也要接自动化测试。如果是前端的一个展示，那么完全不需要单元测试了，单纯的集中UI测试即可，再加个自动化就饱和了。

实际场景的一些问题

一：浏览器和设备端支持问题，如何平衡兼容性测试
对自己产品数据打点/用友商的数据/公开性的大数据进行分析获取。
举个例子，移动端看兼容性，选取安卓手机系统做法，比如针对某地区安卓产品用户，
1：选出此地区前30%使用占比的手机型号
2：此地区前30%使用占比的Android大版本号
3：此地区前30%使用占比的分辨率（分辨率会影响应用布局的）。
将1、2、3的结果取交集，得到的手机系统分辨率进行兼容性、UI测试。
当然有这种平台，例如testing等。

二：交付给客户，自己又是甲方且无测试人员，如何把握好乙方提交的质量
自己需要的验收标准、测试点上进行细化，写在合同的场景上，测试的粒度要细，也要有维保合同，一开始的需求用测试用例写出来，用BDD、TDD的方式进行。