职业经验测试团队的痛点

K米测试 · 2016年10月02日 · 最后由 zhangbb1991 回复于 2019年12月09日 · 3011 次阅读

痛点：

测试流程不清晰，没有很好的规范来引导产品测试
测试要点设计薄弱，团队成员用例设计能力参差不齐

在你们的团队中是否有这样的问题？你们是怎么解决的，希望和大家一起交流。

天天在谈测试技术，回过头来发现，技术背后的基础是测试最本质的内容：测试用例。
做了将近 5 年的产品测试，一直都在研究测试技术，突然有一天（就在最近）产品质量发生雪崩，让我开始思考原因：
为什么：产品出现 BUG；因为：测试发布了带 BUG 的线上产品

为什么：测试发布了带 BUG 的线上产品；因为：测试用例不完善

为什么：测试用例不完善；因为：？？？？？

5 个赞

如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！

打赏支持

共收到 17 条回复时间点赞

zhangbb1991 #16 · 2019年12月09日

对

Boxer 回复

版本上线前才发现严重的问题，那是不是项目管理有问题，导致测试滞后？
如果项目管理合理的话，研发按时交付经过自测的产品，那么测试进展会不会顺利一点？
从你的描述来看，首先应该在项目管理和研发质量问题，其次才是测试侧的问题。

jeff #14 · 2017年07月24日

杯水车薪,看前面大佬们已经说得很多了。其实我个人觉得质量这个问题谁背锅都不对,我们的目的是解决问题,而不是让谁背锅。

思寒_seveniruby #3 · 2016年10月17日

#14 楼 @aizaimenghuangu 如果出现之前的测试和研发模式未曾覆盖的点, 那么就不应该算是测试漏测, 也不需要质量背锅. 共同改进即可. 比如在人力资源紧张的情况下, 明确只测试主流的平台, 如果某个偏门的浏览器, 或者偏门的改造版 rom 或者浏览器爆出问题, 就针对性的解决即可. 不需要非要拉人背锅.

K米测试 #4 · 2016年10月17日 Author

#8 楼 @seveniruby 线上产品出现问题，站在测试的角度，难道不是测试漏测？

扫地僧 #13 · 2016年10月12日 1 个赞

这个痛点大概都经历过，质量是个系统性的问题，测试部门只是这个系统的最后环节，往往成为背黑锅的。提高质量的策略就是全民皆兵，这个是制度设计的问题了，好的管理制度可以迫使每个环节每个角色都会很自觉的注重质量问题，也只有这样才可以最大限度的消灭 bug

daivd #12 · 2016年10月11日

#8 楼 @seveniruby 非常认同你得观点，我们现在基本就是按这个套路走的

jiraqw #7 · 2016年10月08日

按照我之前的工作流程是这样的，上线由测试提交上线申请 (并且说明存在的问题情况)，产品确认后开发才打包提交给运维。产品确认的标准是没有不能容忍的 bug,测试漏 bug 在所难免，但是致命的肯定不能有吧，要说要背锅三者都要背...

Boxer #8 · 2016年10月08日

@ycwdaaaa 认同你的观点，现在我们也面临同样的窘境，每次都是到上线前发现严重的问题导致加班到天亮进行修复，有可能上线后还有 bug，甚至延期一个工作日，产品设计开发变更频繁，自动化接入的时机靠后，前期只能依靠大量的人工去覆盖...不知道有没有好的建议，接口也做了一些，但是没有什么明确的体系化的东西形成

K米测试 #9 · 2016年10月03日 Author 1 个赞

#5 楼 @ycwdaaaa 非常认同你的观点，测试策略不一样，我们公司你说的这两种产品都存在，而我负责的是线上产品，能够实现快速修复，不过有一点 APP 却介于这两者之间，明显是 ToC，却存在 ToB 的问题，更新迭代不会这么快，及时解决了现有问题，用户的更新速度没有想象的这么快，特别是 iOS 的版本。

回过头来还是策略的问题，针对 APP 应该有一个更好的测试策略

思寒_seveniruby #6 · 2016年10月03日 1 个赞

业务和技术不是对立的是个层次关系作为一个 qa 团队职责的核心是保证业务质量业务质量是目的而达到这个目的你可以堆人可以堆技术也可以堆资金 (购买咨询和服务) 这只是方式不同不能因为人做不到就认为人的能力不行技术没达到目标就坏技术无用商业服务没达到效果就怪商业模式不行你得找到你们的核心问题举个简单的例子如果你们漏测可能是你们的用例不充分这个时候你可以堆人加强用例覆盖申请更多人力和时间也可以堆技术分析代码覆盖率业务建模加强问题分析规则也可以堆资金加强灰度联调找众测云测和咨询公司不可能给你足够的资源剩下的问题就是找最低的成本最短的路径去解决问题

我去催饭 #8 · 2016年10月02日

为什么：产品出现 BUG；因为：测试发布了带 BUG 的线上产品
### 测试背锅？？？Bug 是谁生产的？

为什么：测试发布了带 BUG 的线上产品；因为：测试用例不完善
### 测试背锅？？？

为什么：测试用例不完善；因为：？？？？？
### 测试用例完善了就没有 bug 了吗？

K米测试 #15 · 2016年10月02日 Author

#4 楼 @Lihuazhang 抱歉真心没有广告植入的想法，只是想突出这句话，而链接可以，就随便给了一个链接，无心的还请见谅。

孙高飞 #1 · 2016年10月02日 11 个赞

测试用例的策略不能一概而论。看产品类型，看产品所处的阶段。
互联网 To C 的产品，迭代快，发布时间不可妥协，明知一堆 bug 还发布的情况太常见了。业务不一样，用例策略也不一样。每次发布前回归主流程，不必事皆巨细。监控和 troubshooting 的速度很重要。就算你用例做的特别好，特别细，也是跑不完的。
产品前期，堆功能的时候。连用例都可以不写。所处的阶段不一样，用例策略也不一样。这时候业务不稳定，产品能活多久还不一定，所以没必要投资源写用例。

以上两种情况都是弱化用例策略的。因为修复成本低，监控做的好，trouble shooting 快。要快速发布抢占市场，出问题直接线上一修就行了。所以互联网才高度重视监控，高可用，trouble shooting 机制等等。如果在这里用例设计的特别全，特别细。恐怕测试没跑完呢市场已经让别人占了。很可能大家都是在用 excel 写用例，连用例管理平台都没有

相反如果是 TO B 的业务，尤其进场部署困难。升级困难的。一定是高度重化用例策略的。这种项目发布周期长，有足够的时间进行全覆盖的验收测试。并且是一锤子发布，一旦发布几乎没什么后悔药，你没机会玩监控。所以这种项目在发布前搞个一两周的测试时间都正常。测试流程极其严谨，用例管理平台里堆积着大量的 case。这种产品弱化监控，trouble shooting。重视自动化,CI，流程和文档。

不同种类的业务，测试策略是不一样的。