本帖最后由 xinkai 于 2011-7-13 15:20 编辑

如何提高测试人员问题分析能力
       这个问题有很多人问过，闲暇时也曾与老Zee、鹤舞等测试领域专家讨论过。今天来自CSDN成都站的一位朋友，又与我聊的这个话题，我们展开了一系列的分析及讨论。
       面对这个纠结的话题？首先，希望与诸位分享的是，测试人员的工作心态。他们是抱着什么目的去探究程序中存在的问题？他们是怎样一群人呢？引用《测试之美》中的一些描述。
        如果只列举少量的关键特质，那么首要的一点是测试人员有好奇心。 他们想弄清楚事物是怎么运行的；其次，他们喜欢动手实验 ，他们想知道尝试使用功能演示时不同的用户场景和实验会发生什么；再次，好的测试人员胆子比较大， 他们不害怕会破坏什么东西，不管你有多位高权重，他们也不害怕把发现的事实告诉你，他们更不害怕站出来据理力争，一定要把他们相信可能影响到产品成功的问题解决掉。测试人员聪明，善于分析，善于学习。事实上，他们总是在学习，他们的工作性质要求如此。技术总是在变化，他们接到的每个项目或多或少跟上一个项目不太一样。有时候他们有很好的文档，有时候没有很好的文档，有时候甚至没有成文的文档。他们必须问出正确的问题，研究正确的问题，把谜题的各个碎片联系在一起，然后得出正确的结论。测试人员一般不关心办公室政治，如果你发现一个测试人员特别精通此道，很有可能他的本职工作做得不是非常出色。当你的工作是发现和报告问题，要想玩好政治游戏是很困难的。经常有人责备测试人员过于直接、粗鲁、团队合作精神不佳等。其实不然，很有可能责备他们的人不了解或者没能意识到项目组中测试人员的角色，他们的工作不允许他们隐瞒任何“不方便说”的信息。
      你可能认识一些并不具备前述特质的测试人员。不是测试团队里的每个人都算得上是测试人员，也不是每个具有测试人员头衔的人都算得上是个测试人员。有的人满足于运行已有的测试，他们没有擅长分析、好奇和喜欢动手实验的天性，他们的胆子不太大，很容易被强势性格的人、位高权重的人或要去做新鲜事情的想法所动摇。他们可能因为害怕人们之后的反应而不报告缺陷；他们主要的顾虑是不要坏了大局，有的人过于“热衷”办公室政治和关注个人的计划和成功，以致失去了让他们在测试团队中与众不同的那些很有价值的特质。总的来说，根据你的部门大小不同，不同性格的人都可以对项目的成功贡献力量，但是花力气去识别和培养你部门里“真正的”测试人才是值得的。只懂执行其他人测试想法的人，不能算是一个真正意义上的测试人员。 当一个测试人员需要运行一大堆已有的测试用例时，容易心生厌烦，可能会尽快运行这些测试，只是想让它们从眼前消失。这意味着他们可能不会非常关注这些测试，当然也就不能像认真彻底的执行者一样找出某些问题。从好的另一方面来看，一个“真正的”测试人员一定会把这些已有测试看作自己的职责范围，重新考虑其中的想法，提出问题，充实和改变测试，探究原来的分析没有考虑到的地方。 如果原来的分析实在很棒，那可能他们也找不出来太多可以更新充实的内容，进而增加了无聊指数。你会发现，如果每天的工作就是按部就班，如运行一大堆已有的手工测试用例，日复一日，那些真正富有创造力、勤勉的、聪明的测试人员的精气神儿、自主性和创造力都会消磨殆尽。为了你的测试人员士气着想，无疑需要让他们把手头工作交给愿意每天按部就班做事的人，或把手工测试自动化，或者不要让他们再做这些事情。他们想做点新的事情，想发现和报告缺陷，想贡献其他人无法贡献的力量。
在此，我们必须了解到一个真正的测试人员的必备属性。拥有与生俱来的好奇心、探究能力、擅长分析、不惧权威，敢说真话。后天，我们应该如何选择和培养这些真正的系统设计者？他们的能力是让我们的产品更完善，拥有更好的客户体验、拥有更好的用户感知度。他们不希望提供给用户糟糕的、缓慢的、漏洞百出的交付产品，因为没有客户愿意使用它们。
外围篇
      对于业内大多数企业而言，我认为第一点需要改变的是团队自己的定位。我所了解的大多数团队，都在抱怨这样的一个信息。即测试人员是最底层的项目成员，他们的技术能力仅次于工程，他们不了解架构，不了解程序，除了对业务熟悉，他们对产品一无所知。如果我们的团队的Leader也是这样考虑，那可想这个团队会处于怎样境地？对于团队Leader来说，技术能力（程序、架构、设计）是必备的技能，除此之外你还需要有前瞻的视角和坚强的毅力。当测试团队与研发发生争执的时候，必须跳出来用事实和数据证明程序实现的错误。在很多时候，并不是你的测试成员不懂得如何分析，而是大环境不支持他们做这样的事。由此，他们也不会养成事事分析、事事根因的性格。
第二点，需要谈谈我对IPD体系结构的理解。华为主张的测试观点与业界有很大不同，大多数公司仅仅将测试人员至于软件开发的最底层，他们的工作是验证集成测试产品是否满足客户需求。而华为研发体系IPD-PTM体系，测试人员工作前置到设计开发阶段，全面参与产品的设计中来。测试人员一旦参与设计，就能在软件研发中获得诸多灵感，这种发散性的灵感将在整个产品研发过程中充分表露出来。当研发人员与测试人员结对设计文档时，需求被快速澄清，测试人员参与到关键技术的研讨及讨论中。这种经历使得他们能体会到诸多乐趣，并将这种发散的思维带到后续的工作中去。与其说他们在参与验证，不如说他们在创造产品。让测试人员理解需求、理解架构、理解设计是让他们提高修养、提升分析能力的必要过程。

心态篇
第三点，正如米卢曾说过的那样，心态决定一切。没有找不到重现条件，只有不会思考的测试人员。一个团队成长，除了技术的引导之外，作为团队的Leader你还需要注意心态上的引导，这就是之前讲过的前瞻性。以下这些话，需要我们经常与团队宣贯：
1、        证明给我看，如果你无法证明，那结论就是这是一个问题；
2、        不相信任何人，用事实说话，证明它是错的；
3、        再没有得到证明以前，我们只能认为存在一个问题；
4、        对于测试团队来说我们不仅仅贡献Bug，还能提供优化方案及定位思路；
5、        不要被表面现象所蒙蔽，唯有知道根因，才能找到答案；
6、        在本地化场景哪怕只有1%几率重现，在现网的概率就是100%；
7、        质量驱动交付，信念决定成败；
8、        唯有冷静，才能解决问题；
9、        分析的能力在于思维框架，养成结构化的思考习惯（善用脑图、鱼骨图等技术）；

技术篇
第四点，我们谈到真正的分析技巧。这里主要讲两种培养模式，一类为非技术类人员，一类为有开发经验的人员。
非技术类人员培养：首先，我们分析一下这类人群的心态？为什么他们不善于发问呢？他们的心态是怎么样的？他们惧怕什么？或者说他们不愿意暴露那种缺陷？
他们为什么不善于发问？这个部分从心态上来讲我的归结是压抑性受挫。当一个人在未知领域探索时，均存在很多不确定性。这个时候我们往往十分胆怯，深怕暴露自己的弱点。但是正是因为这种因素的存在，很多时候测试人员面对开发人员的说法显得无可奈何。因为，他们不了解程序的结构、算法和实现方式。他们认为自己在听天书，他们讲的内容与自己无关，他们将自己定位于问题的发现者而非问题定位者。正是由于这样的心态，许多测试人员因此被埋没、被遗忘？没有人愿意正视他们，他们变的越来越自卑。这是产品团队灾难，TeamLeader的悲哀。
遇到这样的情况，测试Leader应该如何进行牵引呢？是的，我们怎么牵引。其实，很多Leader是很迷茫的，我知道团队症结所在，但不知道该如何下手？
其实，要解决这个问题是很简单？通过我们多年总结和不断实践，这里给大家分享一种思维引导模式。即通过结构化提问方式，将开发人员引导测试人员的设计好的圈套中来。请允许我这样称呼，因为测试实在是一件令我们激动的事情。通过这样长时间的训练及磨合，您可以让团队中每个成员都养成结构化提问的方式，无论他们的工作是开发、测试、或者其它岗位，他们都将变得十分聪明。而非简单的停留在程序实现的角度，他们能够从需求入手，逐步剖析，最终他们得到完美的答案。
以下描述一下这种结构化的提问方式：
例如，需求描述如下：平台需增加SP接入号管理界面，系统维护人员可在该界面上手工添加SP接入号，可设置每个SP接入号进行精确屏蔽和模糊屏蔽。支持对SP接入号的添加、删除、修改、查询以及导出。导出时，以Excel格式的文件导出。
1.1.1.1        Inputs输入
在添加SP接入号时，输入项包括：
SP接入号号码、精确屏蔽还是模糊屏蔽、是否启用、备注
约束：
接入号号首长度最大为20位；
支持多条同时删除；
对SP接入号的操作支持实时生效；
SP接入号最大个数为10W个；
1.1.1.2        Process处理
1）AntiSpamming平台接收系统维护人员的SP接入号各种操作请求，执行内部数据更新；
2）向系统维护人员提示操作结果；
1.1.1.3        Output输出
提示操作结果：成功、失败；
如果成功，则在AntiSpamming平台上能查询到对该号码的操作结果；
分析框架（根据球形模型我们建了以下这个分析模式）：
根据需求构建时序图：
DFD整体数据流：
（前台->校验->数据交换->检验->业务逻辑-> TCP/IP层->数据库->存储设备）
前台实现步骤：
1、        输入数据；
2、        前台检验规则；
3、        数据层转换规则；
4、        后台校验；
5、        业务逻辑；
6、        TCP/IP层；
7、        数据库；
8、        存储设备；
针对，这个需求我们要怎样提问呢？看看以下几个问题，测试经理需要制作这样的模板提供给团队成员，这不仅仅是测试团队财富，而是SBU的精神粮食：
输入数据及前台部分校验规则：
1、        前台数据校验是在页面中通过JS实现的还是通过URL在后台服务器校验的？
2、        通过URL发送的数据包是明码还是密码？密钥是对称还是非对称的？
3、        接入号首长度最大为20位？号首使用什么编码格式？一个字符算几位？
数据层转换，这里需要把这个需求点展开分析一下：对SP接入号的操作支持实时生效；这个如何去分析呢？还是同样的方法，首先时序图将前后台分离，然后分拆发问：
1、        SP接入实时生效？是包括导入与手工添加么？
2、        导入过程是如何实现的？是逐条组包发送变更包还是批量提交后由其它线程在队列中轮循？
3、        前台数据包经过校验后传向后台，配置变更包发送之前我们做了哪些事？和哪些部分相关联
4、        每个配置变更包是多少个字节，是变成的？还是定长的？
5、        数据批量导入时，变更包的接口性能瓶颈在多少？用户可以接受的变更延时是多少？
6、        每100个配置变更包发送需要消耗多少带宽？CPU？和内存？
7、        变更包发送前是先入库还是先替换内存？内存与数据库如何保持同步？
8、        数据发向后台入库前是使用的什么批量提交组件，原理是什么？每次Commit操作的数据量是多大？
9、        数据入库前，前台检验？中间流转？后台存储？分别的耗时是多少？
10、        变更包在发送前要做哪些校验，组包过程每个字段是如何组成的？
11、        变更包超时时间设置为多少？超时后数据包如何发送？丢失还是缓存？
总之，发问的技巧来自于我们的好奇心。
测试人员在探索未知领域，对于无法解释的现象和问题一定要深追到底。
这是华为测试人员给我们最大的感受，他们求知欲总是无穷无尽。
请记住一句话，无法解释的东西一定会潜藏未知问题，不要怕问为什么？每个人都有第一次为什么？
一些典型的场景，看过之后希望明白应该如何提问：
1、数据脚本对比之后，请解释每句修改意味着什么？
2、功能测试时监控初始化程序状态，运行一段时间后检查指标性能？为什么多了5个连接，谁可以为我解释？无法解释，那这就是问题。
3、需求阅读之后？请和我讲讲的他的工作原理？为什么需要调用这个库文件？为什么需要连接这个数据表？