软件测试的五个棘手问题
漫无目的、重复性、暂时性、单调性、健忘性。
1、漫无目的
软件测试不是简单地拿起来就做的事情，它要求有计划、有准备、有策略和有多变的战术，这是成功进行软件测试测试的前提。
软件测试中的漫无目的必须停止。我知道，说来容易做来难。毕竟，即使对最简单的应用程序，也有可能有无限的测试用例，但是，我想强调测试的目标是有限的。
决定需要测试什么
软件测试开始通常是把一个应用程序分成组件或特征。用户关心的是功用，即如何通过组件和特性做希望做的事。如果根据功用来做测试，我们的测试就会更接近于实际的使用情况。
为了更好地了解什么地方需要测试，我更注重于细微划分的功用而不是高层次的组件和特性。要测试一个特性，我需要从不同的深度和顺序进行检测。通过明确地列出这些功用，我的工作将变得目的性更强，也更容易统计进度和覆盖范围。
决定何时测试
前期的测试必须尽可能有效地降低“错误噪音”的整体水平。错误噪音是那些琐碎的缺陷和问题，他们会造成测试人员工作效率低下。如果缺陷没有在前期的开发人员自我测试、单元测试或代码审核过程中被发现，积累到靠后阶段的话，测试人员就要花费大量的手工测试时间来找出这种缺陷，这同时也意味着，我们没有时间运行更多的漫游测试，测试人员的工作效率就会下降。
这意味着理解每一个阶段发现缺陷所付出的努力和被发现缺陷之间的关系是非常重要的。基于缺陷的历史数据分析，我们将学会如何在代码审查、单元测试或其他方面有针对性地进行工作。一般需要重复几次才能把这个过程做对，但是这种努力会收到长期的效益。
决定如何测试
许多团队已经做出大量的研究工作来寻找测试技术与缺陷之间的对应关系。最终这些研究将总结出一些非常有价值的规律，可以将某些缺陷类别和某些漫游路径或测试技术联系到一起，从而让测试人员知道：“这种功能或特性最好用这种给定的方法来测试。”
漫游测试是一种确定高层测试技术的方法，也是一种逐渐理解漫游本身和特性之间关系的方法，它适合于测试并善于发现缺陷。在测试团队建立起一套简单和先进的漫游途径之后，他们将得到各类特性和缺陷之间的联系，利用这种联系，漫无目的的测试会比以前大大减少。
2、重复性
我们不断的进行更多的测试，所有测试用例都会过时。即使过时的测试用例也有它的作用。
工业界发现测试用例的重用已经成为一个规范，为了突出它的作用和目的，我们给这种做法一个专门的名字“回归测试”或“回归测试套件”。
把已经熟悉的路径和数据环境组合联系到一起作用非常有限。尽管对于检验缺陷修复有用，但是对于发现新的缺陷，或者对发现由于测试代码改动而造成的潜在副作用并没有多大帮助。他们在测试新的或者具有实质性变化的特性时不会发挥作用。
我们必须有确凿的把握：知道现在已经运行了哪些测试，我们目前和将要进行的测试如何才能增加总体测试效果。
知道已经运行过哪些测试
回归测试套件运行通过后，我们不能确认这是个好消息还是个坏消息。BorisBeizer称这种现象为农药悖论，他描述的太精辟了，我都找不出更好的说法。一旦测试套件发现了大量的缺陷后，那些没被发现的缺陷会对测试套件的未来效用产生免疫力。这看似矛盾却很有道理：使用的农药越多，长期来讲杀死的虫子百分比变得越低。
知道什么时候注入变异
要解决杀虫剂悖论的问题，对于农场主来说，意味着必须修改杀虫剂的配方；对于测试人员来说，意味着必须调整测试用例。通过建立目的明确的测试技术，并了解运用这些技术所能发现的错误类型，测试人员可以选择最适合自己的技术。他们也可以对技术加以改变，或同时把几种技术组合在一起，或以不同顺序和不同方法来使用这些技术，关键是要不断改变测试的重点。
我们也可以简单地改变配方的过程。对于测试人员而言，场景和漫游路径就是杀虫剂。在场景里注入变异可以确保配方不断变化，使得潜在的缺陷永远不会习惯这些变化：在漫游测试时，使用不同顺序，不断变化的数据和环境也会起到相同作用。
3、暂时性
两种人群经常发现缺陷：一种是被雇来找缺陷的测试人员：另一种是偶尔撞上缺陷的用户。简单地说，测试人员不可能是用户，不可能用一种逼真的方法来模拟用户的行动，从而也就不能发现所有的重要缺陷。除非测试人员永远“生活在这个软件里”，否则总会忽略这些重要的问题。大多数测试人员不生活在软件中，他们只是“暂住”而已，一旦应用程序投入市场，他们就会转到下一个项目。
发现软件问题需要实际用户在实际的环境中，用实际的数据，去做实际的工作。测试人员不会接触到这些问题，这些问题的暴露需要时间。
最终测试人员是暂时性的，我们只能做力所能及的工作。我们需要知道自己的能力有限，为解决总要出现的用户问题做好计划。应用程序出厂后项目就结束，这样的假设是完全错误的。我们忽略了保修期，这段时间仍然是测试环节的一部分。
4、单调性
测试是枯燥的。实际上测试充满了有趣的策略问题，它既有娱乐性又有挑战性：测试需要决定测什么，知道如何把多种功能和环境考虑结合在一个测试中，设计出更高级的测试技术和概念，搞清楚一组测试如何帮助总体的测试策略。所有这一切都很有趣，在急于测试的情况下，测试策略问题常常被忽略，因为解决策略问题会增加测试量。测试的战术方面实际上包括运行测试用例并报告错误，这是工作中乐趣较少的那部分。的确，这部分工作又是大多数测试人员每天、每周、每月的主要工作重点。
有头脑的测试经理和测试主管要认识到这种现象，确保每一个测试人员把他们的时间合理分配在测试策略和测试战术上。为了达到这个目的，就要把测试过程中简单重复的工作实现自动化。
测试仍然是一个不成熟的学科。
本书介绍了如何使用漫游方法高度概括测试用例的设计，这满足了人们对测试创造性的渴望。在微软，人们广泛地认为，这种识别、记录、共享和优化以漫游为基础的测试方法的行为，称得上是一种高效率、高产出率、高创造性和更有趣的测试方法。
5、健忘
测试任务从时间上来说比较侧重当前状况。我这么说的意思是指测试人员的精力大多都被当前发生的事情所吸引，而没有功夫去思考下一步。我们计划测试、设计测试、运行测试、分析结果，测试结束后马上就忘。我们没有花大量时间思考如何在应用程序的未来版本中或其他测试项目中使用同样的测试。
测试团队对未来要干什么想的就更少了。测试用例被创建、被运行、最后被废弃。测试完一个特征后、没有文档描述哪些功能工作，哪些不工作，哪些是好的测试，哪些是坏的测试。完成这样的测试后，团队究竟学到了什么？
整个工业界都饱尝健忘症的痛苦。良好的测试和良好的测试过程常常记录在运行测试的测试人员的头脑中，但是测试人员调动工作的现象经常发生，不能指望通过测试人员来延续测试专业知识。
测试用例并不是解决这种记忆问题的最好方法。对应用程序的改变常常导致测试用例的维护开销大幅上升，而且杀虫剂悖论也降低了现有测试用例的价值。
漫游测试在一定程度上效果更好，因为一条漫游路径可以代表任何数量的实际测试用例。如果我们努力地把漫游路径映射到软件特征和缺陷上，我们会留下有关产品的记录，他会帮助下一任测试人员了解内部情况，包括我们所作的测试哪些有效，哪些没有效。
小结
工业界所采用的手工测试方法走的是两个极端，或者准备过于充分，事先写好脚本、场景和文档；或者准备不足，只是无计划地随机测试。漫游探索式测试刚好处于两者之间。它把测试的任务提升到了一个新的高度，从考虑简单的测试用例提高到更为广泛的测试策略和测试技术类型的层面。
拥有测试策略和规范的技术使得测试人员在处理他们的任务时目标更明确，这直接解决了无目标的问题。漫游路径又迫使测试用例的产生具有更多变化，使重复性问题和单调性问题得到积极的处理。另外，漫游测试提供了测试技术的讨论平台，可以促进知识交流和建立测试文化，从而改善暂时性和健忘性。漫游测试的使用情况可以记录下来，包括测试覆盖范围和发现缺陷的可能性，这些统计资料可以归纳成更有意义的可用于指导未来行动的技术报告，测试人员通过学习这些报告改进以后的努力方向。