职业经验 测试团队的痛点
痛点：
- 测试流程不清晰，没有很好的规范来引导产品测试
- 测试要点设计薄弱，团队成员用例设计能力参差不齐
测试人员的个人能力竟然会决定产品的质量！！！---非链接，请勿点击
在你们的团队中是否有这样的问题？你们是怎么解决的，希望和大家一起交流。
天天在谈测试技术，回过头来发现，技术背后的基础是测试最本质的内容：测试用例。
做了将近 5 年的产品测试，一直都在研究测试技术，突然有一天（就在最近）产品质量发生雪崩，让我开始思考原因：
为什么：产品出现 BUG；因为：测试发布了带 BUG 的线上产品
为什么：测试发布了带 BUG 的线上产品； 因为：测试用例不完善
为什么：测试用例不完善； 因为：？？？？？
项目流程是否合理
- 需求阶段：段是否讨论的充分
- 开发阶段：是否有设计，设计是否被评审
- 测试阶段：测试用例是否被评审
- 预发布阶段：上线前除了本次改动的功能，产品上下游功能是否有回归测试 5.可以考虑灰度发布 6.缺陷总结：对于线上 Bug 或者事故的 review 及经验分享，优化流程，改进工具等避免同样的问题再次发生
人员能力是否能胜任当前的工作
- 执行力&态度问题？
- 能力问题？对自己负责产品的架构及实现细节是否了解？有没有能力 review 开发设计？。。。
我们说的测试技术，未必就是做做自动化&&性能测试。一个了解被测系统架构，懂代码的测试同学，在深入了解产品需求的情况下，可以指出开发设计是否合理，除了功能外，还能从性能，安全等角度评估出项目的风险，这些最终都能在测试用例中体现出来。
套用 monkey 在新书中的话，“测试不是比技术精深，不是比谁代码写得好，最终要提升项目，团队的效率，解决问题才是真的。”
测试用例不完善？因为（）：
A.产品上线时间紧迫，没有充足的时间去分析需求、功能。
B.产品和开发侧提供的原型、需求和详细设计等有缺陷，无法有效地供测试人员进行参考分析。
C.测试人员本身不重视/分析设计能力不足。
D.以上都是
跟踢后卫一样，不能犯致命的错误；再怎么防守，也有牛逼的前锋踢进门。
警告 @aizaimenghuangu 一次，下次再有广告植入，直接删账号了。
测试用例的策略不能一概而论。看产品类型，看产品所处的阶段。
互联网 To C 的产品，迭代快，发布时间不可妥协，明知一堆 bug 还发布的情况太常见了。 业务不一样，用例策略也不一样。每次发布前回归主流程，不必事皆巨细。监控和 troubshooting 的速度很重要。就算你用例做的特别好，特别细，也是跑不完的。
产品前期，堆功能的时候。连用例都可以不写。 所处的阶段不一样，用例策略也不一样。这时候业务不稳定，产品能活多久还不一定，所以没必要投资源写用例。
以上两种情况都是弱化用例策略的。因为修复成本低，监控做的好，trouble shooting 快。要快速发布抢占市场，出问题直接线上一修就行了。所以互联网才高度重视监控，高可用，trouble shooting 机制等等。如果在这里用例设计的特别全，特别细。恐怕测试没跑完呢市场已经让别人占了。很可能大家都是在用 excel 写用例，连用例管理平台都没有
相反如果是 TO B 的业务，尤其进场部署困难。升级困难的。一定是高度重化用例策略的。这种项目发布周期长，有足够的时间进行全覆盖的验收测试。并且是一锤子发布，一旦发布几乎没什么后悔药，你没机会玩监控。所以这种项目在发布前搞个一两周的测试时间都正常。测试流程极其严谨，用例管理平台里堆积着大量的 case。这种产品弱化监控，trouble shooting。重视自动化,CI，流程和文档。
不同种类的业务，测试策略是不一样的。
#4 楼 @Lihuazhang 抱歉 真心没有广告植入的想法，只是想突出这句话，而链接可以，就随便给了一个链接，无心的还请见谅。
为什么：产品出现 BUG；因为：测试发布了带 BUG 的线上产品
### 测试背锅？？？Bug 是谁生产的？
为什么：测试发布了带 BUG 的线上产品； 因为：测试用例不完善
### 测试背锅？？？
为什么：测试用例不完善； 因为：？？？？？
### 测试用例完善了就没有 bug 了吗？
业务和技术不是对立的 是个层次关系 作为一个 qa 团队 职责的核心是保证业务质量 业务质量是目的 而达到这个目的 你可以堆人可以堆技术也可以堆资金 (购买咨询和服务) 这只是方式不同 不能因为人做不到就认为人的能力不行 技术没达到目标就坏技术无用 商业服务没达到效果就怪商业模式不行 你得找到你们的核心问题 举个简单的例子 如果你们漏测 可能是你们的用例不充分 这个时候你可以堆人加强用例覆盖申请更多人力和时间 也可以堆技术分析代码覆盖率业务建模加强问题分析规则 也可以堆资金加强灰度联调找众测云测和咨询 公司不可能给你足够的资源 剩下的问题就是找最低的成本最短的路径去解决问题
@ycwdaaaa 认同你的观点，现在我们也面临同样的窘境，每次都是到上线前发现严重的问题导致加班到天亮进行修复，有可能上线后还有 bug，甚至延期一个工作日，产品设计开发变更频繁，自动化接入的时机靠后，前期只能依靠大量的人工去覆盖...不知道有没有好的建议，接口也做了一些，但是没有什么明确的体系化的东西形成
按照我之前的工作流程是这样的，上线由测试提交上线申请 (并且说明存在的问题情况)，产品确认后开发才打包提交给运维。产品确认的标准是没有不能容忍的 bug,测试漏 bug 在所难免，但是致命的肯定不能有吧，要说要背锅三者都要背...
#8 楼 @seveniruby 非常认同你得观点，我们现在基本就是按这个套路走的
这个痛点大概都经历过，质量是个系统性的问题，测试部门只是这个系统的最后环节，往往成为背黑锅的。提高质量的策略就是全民皆兵，这个是制度设计的问题了，好的管理制度可以迫使每个环节每个角色都会很自觉的注重质量问题，也只有这样才可以最大限度的消灭 bug
#8 楼 @seveniruby 线上产品出现问题，站在测试的角度，难道不是测试漏测？
#14 楼 @aizaimenghuangu 如果出现之前的测试和研发模式未曾覆盖的点, 那么就不应该算是测试漏测, 也不需要质量背锅. 共同改进即可. 比如在人力资源紧张的情况下, 明确只测试主流的平台, 如果某个偏门的浏览器, 或者偏门的改造版 rom 或者浏览器爆出问题, 就针对性的解决即可. 不需要非要拉人背锅.
杯水车薪,看前面大佬们已经说得很多了。其实我个人觉得质量这个问题 谁背锅都不对,我们的目的是解决问题,而不是让谁背锅。
Boxer
回复
版本上线前才发现严重的问题，那是不是项目管理有问题，导致测试滞后？
如果项目管理合理的话，研发按时交付经过自测的产品，那么测试进展会不会顺利一点？
从你的描述来看，首先应该在项目管理和研发质量问题，其次才是测试侧的问题。