测试之美 Part 1

1. 本人曾经在一次电话面试中被问到，为什么你作为一个测试人员，还要别人来告诉你要在哪些平台上去测试，你完全可以自己去定夺。下面的这段话是来自《测试之美》，我觉得很有逻辑的反驳了那位面试官。

把测试人员放在“质量把关人”的位置上，操作起来蛮困难的，也不太公平。所谓“质量把关人”，就是在软件发布前已将该软件看做是一件商品的负责人。

• 大多数测试人员不能很好的权衡风险、必要性、市场需求和成本开销。评估和承担风险其实是项目管理者或公司管理层的任务。
• 测试人员清楚地知道不管发现和解决多少问题，软件代码里总还是潜伏着一些问题。所以他们一般不太情愿盖那个质检合格的红印。这就是说，要等到你的“质量把关人”确定软件代码里的问题已经被尽最大可能地消灭了，你的项目可能要旷日很久。
• 到后来很可能会要求测试人员脱离发现和报告问题的本职工作，而花时间去评估每个问题，甚至可能因此失去其独特的视角和使命感-不再记录下被发现的问题，只依据他们的理解来判断“不够重要”的问题，这样他们的测试视角难免受到限制和约束
• 测试人员不是最终用户，不是市场专家，不是项目经理，不是厂商，不是会计，也不是行政主管，他们可以在项目风险方面给你非常有价值的信息，应该利用和尊重他们在商场领域的顾问意见：那就是测试你的产品并找出问题。测试人员可以为定夺产品去留的决策团队贡献很好的意见，但是让他们承担整个决策团队的担子就有问题了。

 

2. 在商业世界里有多少份工作室付钱让你直言不讳呢？

当唯一的“桃子”显然有些坏掉的时候，测试人员不应该拿着工资却告诉你一切正常。

测试人员拿了工资就是要告诉你他们所了解的一切事实，甚至有时候他们会直白地说你的小宝宝很丑，还给出一系列论据。

 

3. 测试人员到底是什么样的人呢？

• 有好奇心
• 喜欢动手实验：想知道尝试使用功能演示时不同的用户场景和实验会发生什么
• 胆子大：不害怕会破坏什么东西，不管你有多位高权重，他们也不害怕把发现的事实告诉你，他们更不害怕站出来据理力争，一定要把他们相信可能影响到产品成功的问题解决掉
• 聪明，善于分析，善于学习
• 不关心办公室政治
• 容易不信任人：别人总是告诉他们模块X不需要测试，或代码Y“没动过”，这种信息错的次数多到数也数不清了。就算你告诉测试人员草是绿的，他们也要亲自过目才敢相信
• 挑剔
• 质疑

 

4. 只懂执行其他人测试想法的人，不能算是一个真正意义上的测试人员

当一个测试人员需要运行一大堆已有的测试用例时：

• 不好的测试人员：尽快运行这些测试，只是想让它们从眼前消失。这意味着他们可能不会非常关注这些测试，当然也就不能像认真彻底的执行者一样找出某些问题。
• “真正的”测试人员：会把这些已有测试看作自己的职责范围，重新考虑其中的想法，提出问题，充实和改变测试，探究原来的分析没有考虑到的地方。

 

5. 经验丰富的测试团队能用漂亮的包装纸（词汇）和丝带（对问题的理解）来呈现一个缺陷。过了好一阵你才会意识到自己收到的是一大堆恶心的牛粪。

 

6. 测试人员要阅读一切帮助了解测试目标的资料，要问问题--很多很多的问题，一直问到他们满意觉得足够了解该应用程序为止，然后他们要决定如何最好的进行测试并制定一个计划。这个计划也许很正规，也许只是在他们的脑子里，但大多数测试人员在开始测试之前就知道他们想要检查什么，在开始实验的时候也大致知道系统应该是什么样以及如何工作。

 

7. 有经验的项目经理通常在项目早期就让测试人员参与进来。

• 他们希望这些测试专家在流程早期向他们发问，这样可以更快更容易更廉价地消除差异
• 他们希望开发人员注意测试人员要测试的方面以便开发出更好的代码。

 

8. 业界有一个令人遗憾的现实，那就是测试人员不将他们发现的所有错误报告出来。

• 因为反正都不会被解决。
• 因为他们相信从政治上和实际上来说，报告他们发现的一切东西是不“聪明”的，他们应该只报告那些公司在乎的东西

如果公司不看到整个大局，怎么知道在不在乎呢？每个人都明白很多错误是不能再产品发布前解决掉的。成功项目管理的“艺术和工艺”的一个要素是对推迟和解决哪些缺陷做出正确的决策。如果测试团队不报告他们所发现的所有错误，这意味着项目经理和上层的管理者正在根据错误、不全面的信息做决策。

就算是在一个并不解决某类错误的公司，报告每个错误也可能会最终改变公司的政策。