转载自   开发人员也要懂点的测试知识

本文来自于作者投稿，作者陈彩华，贝聊后端开发工程师。

最近参加了保利威测试总监李乐的《互联网测试姿势》为主题的分享交流会，收获颇丰，作为一个开放，秉承“不懂产品和测试的开发不是好开发的原则”，总结一下。

分享交流会的主题主要涉及互联网态势下，如何高效测试，如何提升工作效率，提高产品质量，测试团队建设，以及作为互联网从业人如何快速学习成长。

 

why 为何做测试

 

what 测试涉及的知识

传统测试VS敏捷测试

敏捷测试各阶段测试的测试活动

测试观

发现缺陷的时间与缺陷修复成本关系

越后期修复缺陷的成本越高，且指数增长，而缺陷主要是开发前期引入的，且前期缺陷修复成本很低，测试越早越好

测试分层概念

 越往上层，构建速度越来越慢，成本投入越来越大 * 越往下层，构建速度越来越快，成本投入越来越低

 

how 如何做好测试

测试现状

生产力改造

 

 

 

 

测试团队关注点

、

 

挖掘公司业务测试痛点

注意点 * 产品质量改进需要长期投入 产品质量改进的投入产出周期较长，立即投入并不能直接对收益产生重大回报 * 只在合适阶段对测试资源做合理的投入 

提高测试人员思维

测试技术栈参考

 

Q&A

• 1 人员架构组成的困惑 问题：请问您认为成熟度高，利益一致的开发测试团队是人员组织架构是怎么样的？ 回答：测试，开发，产品垂直上隶属各个独立部门统辖管理，针对每一个产品项目，各个目标抽调出相关人员组成小组，共同为产品的质量，产品需求，产品完成效率负责。

• 2 冒烟测试的困惑 关于冒烟测试之前实践的时候遇到的问题：开发完成一个功能的开发，测试完成功能冒烟，后面开发进行功能迭代时改了这个功能，功能没有改完，测试冒烟测出问题并提bug，经常发生类似情况导致项目领导有意见，这种情况如何避免？ 回答：首先，开发需要与测试沟通协商好,确定可测试度，哪些可以测试，哪些不可测试，同时，对于暂时不可测试的部分，开发人员需要给出完成期限，便于测试做测试计划。

• 3 测试人员如何做KPI考核 回答：类似如果基于开发人员写多少行代码做KPI考核没有意义，基于测试人员测出多少Bug来进行考核并没有意义。更倾向用OKR(Objectives and Key Results即目标与关键成果法)考核方法，根据每个成员关键目标完成情况进行考核。

• 4 手机客户端如何做代码覆盖率测试 回答：比较常见的方案是通过定制开发，在测试环境，客户端植入测试覆盖率收集的代码，并上报给服务端的统计中心进行统计

• 5 测试与研发关于bug的修改发生意见分歧的困惑 问题：测试与研发关于bug的修改发生意见，测试人员改bug有必要改，但是开发认为没有必要改，如何协调沟通好该类矛盾？ 回答： 测试人员收集好相关测试统计数据,拉上开发，产品一起评估这个bug的严重程度，计算好投入产出比，bug影响范围，360度环评有没有必要改这个bug,是这个版本马上改还是暂时放一放。一般而言，针对大版本升级本身存在很多风险，建议bug尽快修复。如果是小版本升级，测出以前的旧bug，那么比较倾向于使用保守策略，毕竟改bug有可能引入新bug.

• 6 如何做好性能测试 回答：性能测试除了在生产环境闲时(比如深夜)进行测试，还可以在测试环境做，这时要根据测试环境，线上环境的硬件参数，由测试环境测出的结果再进行比例换算，可以得到线上环境的性能参数。

参考资料

互联网测试姿势 ——李乐

《Google软件测试之道》