保利威测试总监分享会总结

2018-07-20 本文已影响0人 caison

作者 陈彩华
文章转载交流请联系 caison@aliyun.com

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

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

why 为何做测试

测试的价值.png

what 测试涉及的知识

传统测试VS敏捷测试

	传统测试	敏捷测试
利益一致性	测试团队和开发团队是分开的	测试人员是开发团队的一部分，开发也参与测试，测试与开发利益一致——产品质量，产品可靠性
参与感	开发功能完成后再进行测试，更强调测试的独立性，将“开发人员”和“测试人员”角色分得比较清楚	测试人员在需求分析和设计阶段开始参与，参与全部开发环节，控制质量环节，能够发挥更大作用
测试的重点	测试人员与开发人员是用提bug来交流的，测试人员和开发人员是相对工作的	测试人员会对每一个开发完成的功能点进行测试，并在开发过程中随时反馈遇到的问题

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

测试活动图

测试观

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

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

测试分层概念

测试分层

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

how 如何做好测试

测试现状

生产力改造

生产力改造c

敏捷开发与测试

API统一规范

API模拟调用

API自动化测试

测试团队关注点

岗位的转变

挖掘公司业务测试痛点

注意点

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

合适阶段做合适的事情

提高测试人员思维

测试技术栈参考

测试技术栈

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软件测试之道》