对象引言

面向对象：0-2年软件测试工程师

今天论述的这个问题，其实在很多中小企业项目团队常见之

特别还是今天的这个敏捷开发时期，版本快速迭代中，一个月一个版 ，甚至2周1周一个版

这种迭代方式对于刚入测试行业的测试人员来说，从思想、思维、技术、做事方法有很大一个考验

面临的问题

问题一：版本开发质量差

问题二：测试人员发现问题，总是只看其表不看其里

一个版本开发首次提测 质量很差，测试人员提很多的bug，依然还是没解决问题根本，导致项目不断的发版，一天六七次 四五次 ，问题依然很多。

就聊聊 防范此问题出现我们可以从哪几个角度去避免该问题

# 问题一：版本开发质量差

相信很多同学会想到让开发做单元测试、冒烟测试，进行自测，那么开发测试了压根不知道。版本提过来发现还是很多问题

# 测试人员可以做的：

1.对团队开发试行bug引起人 绩效考核制度 (治根：让开发重视版本质量，严格执行自测)

2.单元测试执行的测试用例，框架搭建带其邮件报告通知到开发经理、项目经理、研发总监、测试经理(要求其技术团队研发技术较高)

3.提测版本经过开发自测后，测试人员首轮测试，执行冒烟测试用例，不通过打回(不需要执行大范围的测试)

4.限制每天发版的次数。比如一天2次，代码构建发版权限将开发收回，由测试人员掌控。

# 问题二：测试人员发现问题，总是只看其表不看其里

这点体现出我们测试人员的技术层次，发现问题总是没找到真正的原因，就给开发新增bug+1

并且提bug 一个模块相关联的bug  同类型的bug 提多个，还有为进行关联，导致开发改问题，耗费时间成本太大

# 测试人员可以做的：

1.提bug，不要只发现问题，我们测试人员要学会定位问题，不会就要学习定位

例如：一个报表数据展示，发现数据与需求不对，与开发沟通一下开发的实现逻辑；这个数据是由后端传回来的，还是前端直接写死的，是不是做了什么处理方式；弄清楚其原理；在分析问题根本；同事进行查看请求的返回值，以及查看日志。

这里要强调的是：弄清楚bug是前后端谁引起的，直接指派给相关人，这点很体现测试技术的专业度，也很受开发欣赏；因为你为他节约了他的时间成本，问题从创建到解决，流程很迅速。

2.同类型的bug；例如测试一个模块，有几个相同的请求，只不过类型不同，你每个类型给开发提一个bug；开发此时心里绝对会骂你，这测试是不是欠打，会不会提bug，提这么多bug，绩效都扣完了。。。

同类型 bug 提一个，在问题描述 ，将几个场景描述清楚 ；如果是2个完全不相同的模块，可有将问题单相关联，很多缺陷管理自带的链接问题功能。这也是体现出一个测试人员在项目中做事的方法，专业性。

推荐一个做事的方法，不仅仅对于测试岗位，其实生活中也很受用， 东西不要远远只看表面，要深入其里，抓其要害，解之

3W分析是一种优秀的实践方法，即碰到任何问题，不要急于解决它，不要只看表面现象，头痛医头、脚痛医脚，而是要明确真正的问题，找出根本原因，这样才能彻底地解决问题。不要急于提一个bug，丢失了自己的专业度。

3W分析其实就是回答下面三个问题：

·What is the problem?（真正的问题是什么？）

·What is the root cause?（根本原因是什么？）

·What is the solution?（解决方案是什么？）

大家好我是你们的小编：石可乐

专注软件测试行业前景分析、测试思想、管理领域分享；划水之余带领1W+测试开发攻读功能、接口自动化测试、Python好文，

希望在有空之余，给大家多分享点个人经验。觉得有用分享之，打赏之，让我看到生活的希望以及写作的动力，最后发布一个消息，最近创建了一个针对软件测试工程师在工作中提问以及面试少简历不会做的圈子，点击阅读原文可以查看详情。欢迎加入学习。

题图：日常经验总结