软件测试质量的控制
从事软件测试行业久矣，一直在思考如果把控软件测试的质量
--在有限的时间内，提高产品的质量
众所周知，测试是无法发现全部的BUG的，所以测试一定会漏测，这是铁律。
那么为什么还需要测试呢？主要原因是经过测试的产品，能够降低90%以上的BUG，这样能够避免许多损失
但是聪敏的小伙伴可能会想到，如果重大BUG就在这10%呢，那又应该怎么办？
所以我们测试需要抓重点：
* 优先对用户核心业务流程进行测试
* 优先对用户常用的功能进行测试
但是抓了重点就能确保质量了吗？也不一定
所以我们还要从多维度来进行测试，最大限度的保障质量
在开发生命周期中，我们从项目立项开始就要接入测试；到文档，到代码、到单元、模块、系统
在测试执行的用户群体中，我们要有测试人员的测试、内部人员的测试（包括开发、项目经历、产品经历、管理人员）、外部人员的测试（首次接触这个产品的非公司、非专业的用户)
在技术等级中，要有普通用户、骨灰级用户、破坏性用户三个划分。越高级测试越深入
在测试设计用例时中，测试人员需要覆盖、功能、兼容性、安全、性能、易用性、专项测试等
在测试流程上，我们可以设计准入测试、交叉测试、灰度测试等流程
在测试的具体方法上，我们可以使用生产数据进行测试，从而高精度匹配用户实际的使用场景
还有多轮测试
目前产生了精准化测试，它主要是基于代码覆盖率这个技术实现，通过记录功能测试时覆盖的代码链路，来要求开发把这条链路的代码都自测一遍，从而进行精准化测试。
除此以外，随着技术越来越庞杂，大数据、分布式、云原生、人工智能等技术的兴起，也诞生了相关的测试专业岗位，这些岗位的目前测试质量的控制上还不够成熟，例如如何"证明人工智能对人类没有危害"，这类安全测试问题，恐怕是我们测试小伙伴们要追求的目标之一。
测试的方法、方案、策略是如此之多，以至于它非常的臃肿，只有大公司才玩得起。小公司基本上能搞个功能测试+一点点自动化就很不错了。
但是这并不妨碍思考测试质量的控制。
除了进行测试设计以外，我们要需要对测试的过程进行控制。
例如：测试人员要认真的分析需求的可测试性、开发设计的可测试性和逻辑性、要求测试人员对用例进行认真的评审、认真的执行测试用例并记录执行结果
还有需要对测试的工作量进行评估，目前比较有效的手段就是记录每条用例执行时所需要的时间，然后进行控制，当然这里是有弹性空间的。
还有需要对测试的结果进行质量评估，我们需要记录每一次发版时的测试数据，
如：V1.0.0 发现的BUG总数、 致命的多少个、严重的多少个、普通的多少个、易用性的多少个、多少个没有修复、上线后发现了生产的BUG有几个、BUG按照模块划分时的分布、按照责任人划分时的分布、
BUG的来源（历史遗留BUG、新增功能BUG、第三方模块BUG、修复BUG引发的BUG、回归测试发现的BUG、交叉测试发现的BUG等等）
这些数据的统计能够评估出当前测试、开发的技术水平，从而为后续的持续优化提供参考对象，技术差的培训，态度不端正的严加管理等等
对了，还有需要引入"随机测试"和"混沌测试"
利用随机测试对软件进行各种随机的扫描，从而发现一些潜在的问题
混沌测试主要对分布式系统进行测试，主要目的是模拟各种异常状态下系统的处理方式，从而更早的提醒技术人员，让技术人员早做预案，
从而可以提高技术人员水平，降低生产故障的时间。
最后就是各种测试工具的开发：
静态代码测试工具：可以用于检查开发们写的代码是不是有逻辑错误、编码符不符合公司的规范；具有成熟静态代码扫描的团队，可以研究扫描规则，一条新的规则诞生，往往能打开视角，用扫描的方式就能发现大量BUG
SQL审核工具：审核开发写的SQL是否符合规范
日志平台：
用例平台：
持续集成平台：
测试数据构造的小工具等等
当然还可以开发各种分析工具，这种工具现在已经很多了例如linxu的trace、perf等等
然后我们还需要对生产环境进行监控
第一个：比用户先发现BUG
* 通过记录日志的方式、BUG告警的方式来做到任何用户一旦出现BUG就会提醒技术人员，从而快速修复；
之前小编遇到一个面试官提问：如果用户出现了BUG，但是没有日志怎么办？这个问题临场应变没有反应过来，后来想到没有日志那么就需要分情况讨论了
1. 开发的日志设计存在漏洞，所以需要走读代码，查看是否会出现某个地方不打印日志的情况；这种情况下导致的没有日志，那测试人员就只能寄希望于发布前的测试足够充分来确保尽可能少的出现BUG了，否则一旦用户出现BUG了，那么我们内部人员很难得知。
2. 用户的操作不是后端的错误，所以后端没有日志；那么这个时候我们可以采用埋点的方式记录日志，并在合适的时机上传给技术人员
第二个：能让用户反馈BUG
* 通过客服、用户反馈的方式让用户能够反馈自己遇到的问题
第三个：我们需要监控正常行为的异常状态
例如用户在正常状态下登陆，应该就顺利的登录了，然后突然这个用户就失去联系了，或者身份发生了变化，那我们应该能检测到这种变化，并给出预警提示
这个可以用于卡顿检测、网络检测等等
其实测试本身不会产生价值，测试的价值是产品潜在价值的体现，是概率的体现。
如：一个产品的价值可能是10000亿，但是产品可能会出现一些BUG导致重大世故，一旦出现重大事故，这个产品的价值就会归0。
在这种情况下，产品的创造者们肯定会愿意投入一部分资金来用于测试当中，并且希望将这个重大事故的概率无限归0。这就是测试价值的体现。
所以测试质量的工作，需要先有产品。
所以未来测试的工作，将会是与开发、产品交错的，难舍难分的。
后话：
测试的发展前景：从企业发展角度，企业的主要觉得其实有：管理、开发、测试、产品、运维、DBA、架构师等等
但是其实管理可以让开发、测试、产品中的某一个去进行；运维可以让测试去做；DBA、架构师等觉得可以让开发做
这样就会发现，我们只需要三个角色：开发、测试、产品三个角色，当然他们最终统一都对老板负责。
如果继续做减法，可以只要开发和产品
还继续做减法，就只需要开发了，哈哈
所以开发肯定是最重要的
但是如果能够写代码的人工智能诞生后，也许就不一样了。
可能那之后，我们人人都是测试了。
亦或者连测试都不需要？
