这两周产品线加速收敛速度以来，开发和人员陆续的反馈了一些问题，大部分都属沟通类或者细节类。对几种典型问题，测试人员也经过了组内讨论，希望能在细节方面，大家都能注意互相提醒一下，提高产品线的运作效率。

　　一、resolve的bug，验证不通过，然后把bug进行reject操作----------这个处理过程，会出现一些疑义。

　　目前测试组进行约定，测试人员验证resolve的bug，未通过验证后，首先要做的是和开发人员进行沟通，而不是直接把bug进行reject操作。（让开发人员给出原因 这样不是更好吗）

　　bug验证不通过，可能存在很多方面的问题：

　　1.1 版本编译问题（版本控制）

　　1.2 多封闭版本提交错误问题

　　1.3 模块编译和整体编译时间不一致问题

　　1.4 测试人员版本未更新（指定专人更新测试服务器 或者持续化集成）

　　1.5 测试人员验证条件不满足，实际bug未得到有效验证。

　　1.6 开发人员resolve为模块提交时间，和实际版本可获取时间有提前性。

　　很多时候，bug验证未通过，不是开发人员或者测试人员的问题，流转环节的问题，需要大家一起沟通讨论，才能定位，从而提高团队的运作效率。

　　同时，针对resolve的bug，特别是很难复现的bug，也希望开发人员能够说明解决的问题点，给出建议的测试方法。

　　针对必现或者很容易复现的bug，测试人员知道验证方法，按照原来的操作步骤进行多次验证，如果未出现问题，那么就认为解决。

　　针对很难复现的问题，如果没有开发人员的指导，测试人员去验证此类的问题，只能依靠拷机，大规模的覆盖测试，一段时间后没有出现此bug，再进行关闭。实际上，这种验证方式，效率很低，而且不一定真正的验证到了问题点。

　　所以这是一个双向沟通的过程：开发人员主动的说明问题原因、解决方案和相关测试建议；测试人员主动去询问问题原因、解决方案和相关测试建议。

　　二、一个较难复现的问题出现，bug打出去，开发人员要求复现，到底要不要做？（先分严重性，然后按步骤复现）

　　针对这个问题，开发人员和测试人员每天都要纠结好一阵。从产品线现状而言， 也不可能做到一刀切，按照严格的要求去必须复现或者必须不去复现。

　　无论是开发人员或者测试人员，大家都有自己的任务指标。很多时候，就需要动态的把握具体的。

　　是否要复现某问题，给测试人员提出几个判断的标准：

　　1、开发人员是否没有相关测试设备、测试环境，必须要使用测试环境来复现。

　　高清项目以来，很多设备单价都很高，产品线的设备不多，或者新产品的demo板卡不多，针对这种情况，测试肯定是需要协调资源，提供给开发人员自行复现，或者帮忙复现问题的。还有，比如大容量的测试，长考，mcu的三级级联适配逻辑等，都可以根据实际的bug情况，很直观的判断是否需要在测试环境进行复现。

　　2、如果要复现问题，开发人员是否提供捕获信息的要求，提供新版本进行复现？

　　一个bug出现，大家在测试环境查了半天没有定位，然后重启，回头给测试人员说，再复现一下。--------这种表现，是效率很低的体现。

　　如果一定要复现问题，希望能大致判断几个问题点，然后和测试人员沟通下，需要如何捕获信息，捕获那类信息？是不是提供debug版本进行复现，或者根据预判的点增加打印信息版本进行复现？

　　一个很浅显的认识： 一个bug，如果出现问题后，根据结果状态无法定位，那么再复现出现问题，我们认为依然无法定位。那么我们就尝试捕获问题出现前，问题发生过程中的一些状态、逻辑。那么肯定就涉及到对一些信息进行捕获，对一些过程态进行打点、跟踪和反馈。

　　这也是希望开发人员能积极和测试人员沟通的点。

　　如果一定要复现问题，那么，让我们大家的工作更有价值，有效率。

　　3、问题或者项目优先级。

====================================分割线================================

最新内容请见作者的GitHub页：http://qaseven.github.io/