实用主义:测试员眼中的测试理论
软件测试是一门需要不断学习补充新知识的学科，要想成为一名的测试员必须像成为一名武林高手一样不断研习武艺，博采众家之长，消化吸收后据为己有，这样才能终称霸武林，并且立于不败之地。 测试的各种理论知识像武功中的内功心法，各种测试技巧和测试工具则像招式和兵器，如果忽略了内功心法的修炼，即使招式和兵器熟练使用，也可能只是花拳绣腿，没有很强的杀伤力。 对待测试理论的辨证态度 测试理论对于一个测试员来讲是必不可少的，像前面讲的，它是内功心法，是基础。 但是有些人对测试理论不屑一顾，认为测试理论不过是那些学院的教授挤尽脑汁想出来唬人的东西。有些人认为测试理论都是大公司、大规模的测试团队才能应用得上。 实用主义测试员是功利的，没有好处的事情是不会做的。但是实用主义测试者会辨证地看待这些问题，实用主义测试者分几步来看待这些理论： 实用测试理论分类 对于实用主义测试者而言，测试理论可以按以下方法进行分类。 按理论化的程度划分： 1.可直接使用类 2.可借鉴概念类 3.研究类 可直接使用的理论知识是我们测试过程与使用条件相符合的情况，这种情况下，拿来即用。例如冒烟测试的理论可直接应用在所有项目的测试中。 可借鉴概念类的理论知识是我们不具备使用的条件，但是理论提出的概念很好，我们可以借鉴或加以改造，从而为我所用。例如：AEP（Automated Error Prevention）自动错误预防的概念可以部分地用在我们的测试过程，把每日构建、自动化冒烟测试整合在一起构成初步的AEP框架。 研究类是理论化程度很深东西，或者对于软件测试来讲还不是很成熟很实用的理论。这些理论我们只作了解，不深入研究，更不会去应用它。 对于测试理论，我们要把握学习的度，不要迷失在理论中不能自拔。例如，对于正交表测试用例设计理论，我们只需要了解正交表的基本原理，使用方法，应用范围即可把正交表试验法应用到测试用例的设计中来，而不需要深入探讨正交表的数学原理。 按测试理论涉及的领域分： 1.测试方法类 2.项目管理类 3.开发心理类 测试方法类是我们需要掌握，也是常接触的。包括如何进行各种类型的测试，例如安装包测试、用户手册测试、性能测试、GUI自动化测试等等。这些是我们要修炼的“硬气功”。 项目管理类包括测试过程方法、质量管理、配置管理等关系开发人员和测试人员一起工作的管理流程方面的理论，多看看CMM、MSF、RUP等软件过程管理的理论知识，可以让你的测试过程更好地进行，为你的测试争取更好的工作氛围。多点掌握这些知识可能在适当的时候让项目组的其他成员对你刮目相看。这是我们要修炼的“正气心法”。 开发心理类，包括软件过程心理、开发人员心理、测试人员心理、用户心理等。平时多想想，尤其是换位想想，则会使它对你的测试工作如虎添翼。这是我们要修炼的“静心法”。 1.首先看这些理论是否有它的道理，它的应用条件是什么。 2.然后看是否能马上应用到自己的测试过程中。 3.如果不能照搬使用，再看是否能通过修改、调整来达到自己适用的目的。 但是，实用主义测试者不会迷恋于测试理论，他们不会像收集各家武功秘籍一样疯狂地寻找各种新奇的概念。 真正的实用主义测试者会在上述步骤之前加上一个初始步骤：分析自己测试过程中存在的问题，然后有选择性地寻找相应的测试理论来支持和充实自己的测试策略。 实用性测试理论的“用武之地” 对于测试理论，我们的目的是学以致用。 使用的地方主要有两个，一个是用于改善测试过程、测试方法、测试策略，从而保证产品质量。这个是主要目的，也是直接的目的。例如：学习用户交互设计理论，是为了把理论知识用到用户界面测试、可用性测试、用户体验检查上，提出这些方面的缺陷，促使开发设计人员进行界面交互上的修改，从而提高这些方面的质量。 第二个是武装你自己，在你与项目组成员发生冲突时，能很好地使用你学习到的东西武装你自己，坚守质量的阵营。“书到用时方恨少”，这句话同样适用于测试理论的积累。如果平时没有注意积累，在关键时候是没办法“捍卫”你自己的，武林高手总是在陷入困境时能应用奇招脱险。 例如：界面测试发现的问题，往往修改率不高，原因当然有很多了，有考虑设计更改工作量的原因，有项目进度压力的原因。但是主要原因还是开发人员对待这些问题的态度。界面问题往往在某些公司认为是小问题，不值一提的问题，有些公司甚至禁止测试员录入这种类型的bug。有时开发人员也会对界面设计有自己的理解，虽然未必恰当，但是至少他们对这些问题进行了考虑，这是好事。但是问题是你作为测试员是否能说服他们按你的“界面规范”修改呢？ 这些问题的解决都需要我们的测试员拥有深厚的“内功”，知道某些界面规范制定出来背后的支撑依据是什么？为什么要尽量使用非模式的方式反馈信息，而不是弹出消息框？为什么要按一定的逻辑顺序排列界面元素？为什么要了解用户技能水平并对用户进行分类？这些都需要我们在平时去多想想，多找相关的理论知识充实自己，这样在跟开发人员“切磋”时才不至于哑口无言，适当时还能抛抛书袋，嘴角冒出一两个术语，将自己置于不败之地。
