一组经典的测试思想观点

　　测试是不可能穷尽的，当测试出口条件满足时就可以停止测试
　　有测试大师说测试是为了发现错误，一个好的测试是发现以前没有发现的错误。但是这个要求可能会使人走入极端。其实，不同的系统有着不同的质量要求，对于质量要求严格的系统，可能需要进行长时间的，全面的测试，尽可能的去挖掘系统中的缺陷。然而对于质量要求不是很严格的系统，系统是允许可以出现错误的，因此我们通过测试是要使得系统的缺陷数量能够降到可接受的范围内。
　　测试是不可能穷尽的，资源和时间是有限的。因此我们在做测试的时候需要分析哪些功能是对用户很关键的，在这些功能中出现某类型错误对用户是不可接受的，而相对其它一些功能，出现的错误是可以容忍的，这样，我们在测试的时候，重点就应当去寻找那些用户不可接受的错误，而不是漫无目的的去搜索错误。同时我们应当对测试定义合理的出口标准，这是因为测试是没有穷尽的，系统中的问题你总是可以一直发现下去，然而我们不能无休止的去寻找这些问题。当条件满足的时候，我们就应当停止测试。而测试出口条件的设置需要考虑系统的质量要求及系统的资源要求。曾经有人说过：当时间和资源用尽的时候，测试也就停止了。这是没有办法的最好办法。
　　测试是一个持续进行的过程，而不是一个阶段
　　在传统的瀑布式开发模型中定义了专门的测试阶段，如单元测试阶段，集成测试阶段或系统测试阶段。然而，这并不意味着测试只有在这个时候才进行。我遇到过很多项目，在这些项目中，对测试的理解都基于了阶段这个概念，在他们的思维中，测试只有在适当的时候才开始，并且在某个点就可以结束了。这是一个错误的理解，并且对产品的质量来说是很危险的。现代的测试已经发展成为一个全过程的验证和确认活动，它贯穿于整个开发生命周期的始末。为了获得最大的受益，测试的开发和准备必须在编码之前就应当开始，同时为了保证最终的质量，我们必须在开发过程的每个阶段保证其过程的质量。
　　测试必须被计划、被控制，并且被提供时间和资源
　　测试并不是一个随机的活动，测试必须被计划，并且被安排足够的时间和资源。测试活动应当受到控制，测试的中间产物应当被评审并纳入配置管理。
　　测试计划是一个关键的管理功能，它定义了各个级别的测试所使用的策略、方法、测试环境、测试通过或失败准则等内容。测试计划的目的是要为有组织的完成测试提供一个基础。从管理的角度来看，测试计划是最重要的文档，这是由于它帮助管理测试项目。如果一个测试计划是完整并且经过深思熟虑的，那么测试的执行和分析将平滑的进行。
　　测试计划可以分级，也可以是一个总的计划，并且测试计划是一个不断演进的文档。如果不考虑应用软件的最初来源（复用的组件或已实现的组件），软件需求是测试活动的驱动。因此，测试计划应当关注于文档化的需求。此外，支持测试的过程应当被文档化下来以创建一个可重复的过程，该过程将保证开发工作产品的质量。
　　测试不是为了证明程序的正确性
　　正如 Mayer 所说的，测试的目的是证伪而不是证真。事实上，证明程序的正确性是不可能的，一个大型的集成化的软件系统不能被穷尽测试以遍历其每条路径。即使遍历了所有的路径，错误仍有可能隐藏。我们做测试是为了尽可能的去发现错误。因此，测试必须包含一系列测试级别。这些测试级别能最大化对被测对象的覆盖。
　　必须有一些标准可以用于平均所有的测试活动。所有可以跟踪到需求的测试可以通过三个方式进行执行：
　　在正常的数据流量下的有效信息；
　　在一个控制环境中使用超量的数据输入速率；
　　使用一个预先计划的正常数据和异常数据的组合；
　　理想的测试环境要能够使得一个系统在可控的方式下被破坏。例如，数据及数据组合必须不断变化直到系统不能够以正常的方式接受。系统支持变得不可接受的点必须被确认并文档化下来。
　　必须在所有的测试级别上运行测试，且同时使用正常条件和异常条件。这是很严格的，即使在测试环境难以建立的情况下。
　　尽早的、频繁的进行测试
　　现代测试的一个重要哲学要求尽可能早的，尽可能频繁的进行测试，尽可能多的从开发那边获得反馈信息。这包含着要求测试尽可能早的进行准备，并且和开发人员一起进行评审、走读、单元测试、原型评价、早期模拟等等。早期测试的目的是尽可能早的发现任何意想不到的坏的消息，并且帮助开发人员产生高质量的单元。
　　该方法希望在缺陷产生的时候发现并纠正缺陷，它假设了在早期测试中发现的问题能够被描述并及时修正。许多项目管理人员延迟了缺陷修正的时间直到开发人员已经完成了所有特性的设计和编码。这大大提高了系统出错的可能，也增加了修改的成本。一般来说，一次完成一个特性的设计和编码，并保证其正确性将更加有效一些。
　　为什么我们要尽早的发现缺陷和修正缺陷呢？这主要有以下原因：
　　1、缺陷的修改成本随着阶段的推移将急剧上升，在产品发布之后修正一个缺陷的成本将是需求阶段的 100 倍，甚至更高；
　　2、缺陷具有放大的特点，缺陷修改延迟几个星期甚至几个月将使得系统更容易出错；
　　3、设计判定和一些小的代码限制及条件很容易被忘掉；
　　4、尽早修正缺陷可以节省重新分析设计的时间；
　　5、早期的问题反馈有助于防止类似错误的产生；
　　6、大量的缺陷和问题跟踪工作将被减轻；
　　7、如果必要的话，可以重新设计和编码，而这个工作越往后期越不可能
　　测试不能仅仅包括功能性的验证，还需要包括非功能性的验证
　　目前很多公司进行的测试，其范围仅局限在功能领域内进行测试。
　　这一方面可能有产品进度的压力影响，另一方面则是测试人员对测试的理解还比较局限。从用户角度来讲，其需求除了功能性需求外，还包括了非功能性需求，有些非功能需求可能是显性的，而有些非功能需求则是隐性的。我们在测试的时候，应当关注所有的需求，在验证功能的还需要验证产品的性能、可靠性、稳定性、可维护性、安全性、可操作性、可安装性等等。一个产品的缺陷往往会在其性能的边界上产生，如果我们忽视了这部分的测试，很多缺陷将漏过测试进入到用户手上。