作者：DiKi造型Alen老师 | 来源：互联网 | 2023-05-19 11:42
书承上篇，测试中沟通的方式和方法对解决问题带来很大的影响。我们问问题及求助他人要首先描述问题，对问题讲清楚现象，尤其求助别人的时候先不要讲自己的怀疑和自己下的结论，否则容易
书承上篇，测试中沟通的方式和方法对解决问题带来很大的影响。我们问问题及求助他人要首先描述问题，对问题讲清楚现象，尤其求助别人的时候先不要讲自己的怀疑和自己下的结论，否则容易在错误的道路上越走越远。首先要尽可能将问题现象描述的更详细，在接下来定位的时候可以多提自己的假设，怀疑和建议。这两天测试中明显遇到了两个例子来佐证上述结论。
例子1，一线通过iconfig查询部件配置时，一直超时无显示。该一线人员首先怀疑的是版本问题，让本人确认版本，并更新组件包，更新版本后该问题依然存在。然后就让本人在镜像环境重现该现象，并将现网上要iconfig要查询的配置表中数据导出notes我。当时我听从其建议，在镜像环境导入现网数据，发现我这边的错误跟其不是同一错误。在接下来半天的时间内，我先要解决我这边的错误问题，最终定位是其导出的数据中中文字符在我的数据库中乱码显示导致查询错误。我这边问题解决后也没有重现该现网问题，最终我与其再重现现网环境后定位发现是查询时间过长超过设置超时阀值导致。
例子2，一开发发邮件告知本人进行一次数据割接，当时在忙其它事，告知其发邮件。在后来我打算处理该事情的时候，发现其转发的邮件描述中结论推理不怎么站得住脚，随后看了下转发邮件之前的邮件，明白了该问题是页面查询某内容的时候，无法显示某内容，而该开发的思路是让我利用现网的数据去重现该问题。后经过讨论和确认，由开发先对现网上的无法显示进行定位，看具体什么原因导致然后再看我这边是否重现。最终定位是现网上删除了该内容节目单导致，我这边重现无意义。
上述两个例子都是提出问题的人没有描述清楚现象，根据自己的判断给出结论。换个角度看，这些提出问题的人都是我的客户，我的客户在发出要求的时候，有的并未清楚真正的需求是什么（当然在他提出要求的时候，他认为自己的要求是正确的和合理的），对下游的我来说，相当于供应商，一定要搞清楚这个需求的来龙去脉，不要贸然跟进，跟其一起掉入泥潭，虽然这种泥潭最终可能会被解决，但时间浪费很大，还可能引来其它的问题。比如例子1，我这边根本没有重现其问题，还带来另外的问题去处理，耗时耗力。
在后面的测试，乃至日后的工作中，做事之前要沟通充分，做之前一定要搞清楚做的目的和预期，搞清楚这样做的作用是否是合理的，是否能达到预期效果，不然就可能在一开始就走上了错误的道路并越走越远。
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 
