测试杂谈-信息冲突

肖恩 · 发表于 2017-1-5 11:59:07

本帖最后由肖恩于 2017-1-5 12:23 编辑

测试杂谈：信息冲突

  前一段在校园招聘的时候，讨论起测试岗位的面试关注点，大家在列举了计算机水平、实践经验、团队合作等之外，特意加了一条“性格开朗一点”。或许大家会有疑问，做测试又不是做销售，性格内向还是开朗关系不大，那我们就从信息冲突在测试工作中的重要性来说一说两者的关系。

  测试的过程，其实就是不断寻找信息冲突的过程。这里面包括，产品设计与需求分析的冲突、需求分析与开发设计的冲突、不同系统之间接口理解不一致的冲突、功能的描述和代码实现的冲突、系统功能与测试预期的冲突等等等等。这些冲突可能在测试过程中发现，也有可能在案例评审的时候发现，甚至可能在你与开发的闲聊中发现。如果你在整个测试周期中都没有遇到信息冲突，那么可能是对项目或产品的理解和测试深度不够。不断的探寻信息冲突，并将这些信息汇总、分析、核对、确认，最终找出问题所在，是测试人员的必修课。

  信息冲突的原因。我们知道信息在传递过程中的衰减是很严重的，特别是在一些大的项目团队中，即使使用了一些信息管理工具，也很难避免这种问题。对于测试人员来说，我们理想的，得到的信息是这样的：

而实际上，我们得到的信息往往是这样的：

而将这些零散的信息还原，是件麻烦的事情，如果我们不来做这件事，仅仅根据这些已被拆解的零散信息来设计我们的测试案例，那么往往在整体上，会造成疏漏。

  我曾经负责设计一个项目的测试方案，项目由不同的模块，分别由不同的开发组负责，也有需求分析人员。其中关于商户退货资金如何处理的问题，向各个开发组询问，得不到明确的信息；向需求分析人员确认，也只是说不需要系统做处理，具体原因说不上来。去看产品提的业务需求书，也找不到答案。几天后，中午吃饭的时候，碰到产品团队的一个熟人，聊起来，他告诉我这块他们团队的某某某可能知道。经过辗转找到该负责人，才把事情的来龙去脉，商户的真实需求搞清楚。最终经过分析，发现是产品和需求分析人员沟通中错误的理解的对方的信息，我们的系统设计方案有bug。为搞清楚这件事情，我前后咨询了5个团队的超过10人。

  那么，我们测试如何有效的利用信息冲突呢？

  首先，要尽可能的搜集这些信息冲突。这些冲突可能来源于不同阶段的项目文档，也可能来源于不同模块的开发方案，可能来源于你去参加的开发方案评审会，也可能来源于你在饭桌上与需求人员的一句闲聊。所以测试切不可闭门造车，将自己锁在自己的小世界里。很多时候我们没有发现问题，并非我们没有发现问题的能力，而是我们没有掌握到足够的信息。这时候，开朗性格的优势就会体现出来，通过与不同人员的沟通，就会获得比其他人更多的信息，这些都是我们发现缺陷的原材料。

  其次，要有刨根问底的精神。有用的信息并非都是那么唾手可得的，很多隐性的信息在传递中被遗漏，且往往掌握在少数人手里。如果你问的人刚好对此不懂或者一知半解，或者你问他的时候，他刚好很忙，或者刚被领导教训心情不好，那么很可能他会告诉你一个不那么准确的信息。这时候，你就要和你得知的其他信息做核对，看是否构成了完整的信息链，如果不是，那么你要对得到的这个信息打上一个“不完全可信”的标记，需要再次求证。在求知一些关键信息的时候，必须持有质疑精神，才能保证你所得信息的价值。所有得到的信息，如果能够构成一个信息链闭环，相互之间佐证，那么这个信息才是有效的。

  第三，有效利用信息冲突设计案例。假设有两个程序员鲍勃和苏珊（是不是很熟悉），分别开发两个对接的系统。苏珊告诉你，她的系统有关金额的数据库字段设计为8位，你又从鲍勃那里得知，他的系统里面，金额相关的字段都是12位的长度，如果鲍勃是上游系统，那么你就要设计金额超过8位，苏珊的系统怎么处理的案例；又如，对于账号字段，苏珊设计的时候是直接读取，而以你对鲍勃的编码和设计习惯了解，他一般会在传递账号字段的时候前两位补上账号长度，那么就好设计关于账号字段系统联调的案例。类似的情况很多，如果提前了解的信息冲突，就会针对性的设计一些案例，这些案例发现问题的概率很高。

最后，要对这些信息做归纳整理。如果你坚持搜集信息冲突的习惯一段时间，那么你手头上一定积累了很多有用的信息。利用闲暇的时间，将这些宝贵的信息分类整理，归档留存将会为以后的工作带来很大便利。