十三、Bug沟通

　　贯穿整个测试周期，关于Bug的沟通交流，肯定是测试负责人、测试执行人所要面对的工作难点之一。

　　在关于Bug的沟通上，每个团队、每个当事人的风格都不一致，而且人和人之间的勾通交流，也没有死板的流程或套路，如何应用、如何勾通，还需要大家的自行把握。大体而言，会有如下的场景，以供大家参考：

　　◆ 一个bug，当时很容易出现，打给开发人员后，无法复现

　　◆ 一个bug，无法定位具体的开发小组，几个开发小组之间互相推诿

　　◆ 一个bug，修复后又再次出现

　　◆ 一个bug，开发人员定位过程中重启设备，然后要求复现

　　◆ 一个bug，反复复现，开发人员没有明确的思路，还是要求不断复现

　　◆ 一个bug，需要和开发人员描述bug产生时的应用场景

　　◆ 一个bug，测试人员误打，被开发人员指责

　　◆ 一个bug，可以上层业务修改，也可以低层业务修改，无法决定

　　◆ 提出的一些易用性的建议，不被受理

　　十四、每日拷机环节

　　关于研发，有个说法，大家做的是智力劳动，而智力劳动是看效率的，如果思路清晰，也许短世间内成果显著，如果思路不清晰，那么再磨时间，工作成果也不明显。或者直白点，研发工作，不能以单纯的工作时间来考核工作业绩。

　　但是工作时间无疑是一个重要的因素。特别是针对测试人员，面向目前以黑盒测试为主，以手动执行+部分自动化测试覆盖为方法的现阶段。

　　有一个很重要的评判点，是每日的拷机测试。每日的拷机的任务有两个来源：

　　1、按照测试计划和测试用例分解分配的每日性能测试：主要针对规格书中，要求的2、4、8、12小时的功能性能点。

　　2、需要复现的bug，或bug例会沟通分配的专项拷机性能测试。

　　涉及到性能测试、拷机，不是简单的随手运行起来ok。必然涉及到一系列的操作：比如连结串口、捕获保存打印信息、录制自动化脚本、搭建拷机环境、确认设备运行情况等。这些操作都是需要时间的。

　　所以从个人的角度，大家可以观察一下，所有考核较好的同事，肯定很少有卡点下班的。

　　从测试负责人的角度，怎么有效的利用每日的拷机环节，在复现bug、专项测试、性能测试之间平衡安排，以及确认拷机环境搭建运行完毕。第二天收集拷机执行结果，是在性能测试方面，必需要做好的一个工作要点。

　　增加每日拷机流程示意图如下：

　　拷机测试的难点在于打印信息的捕获，原始状态的采集，以及第二天拷机结果的确认环节。