证明软件是“不工作的”，以反向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的输入以及系统的弱点，试图破坏系统、摧毁系统，目标就是发现系统中各种各样的问题。其代表人物就是上面多次提到的G.J.Myers。他强调，一个成功的测试必须是发现Bug Bug的测试，不然就没有价值。
3.软件测试的风险论
测试被定义为“对软件系统中潜在的各种风险进行评估的活动”，这就是软件测试的风险论。软件测试自身的风险性是大家公认的，测试的覆盖度不能做到100%。测试的这种风险定义一方面源于这层含义，另外软件测试的标准有时不清楚，“软件规格说明书(Specification/ Spec)”是其中的一个标准，但也不是唯一的，因为Spec中有些内容完全有可能是错误的。所以，我们常常强调软件测试人员应该站在客户的角度去进行测试，除了发现程序中的错误，还要发现需求定义的错误、设计上的缺陷，可以针对Spec 去报Bug。但是，测试在大多数时间/情况下,是由工程师完成，而不是客户自己来做，所以又怎么能保证工程师和客户想得一样呢?
有人把开发比作打靶，目标明确，就是按照Spec 去实现系统的功能。而把测试比作捞鱼，目标不明确，自己判断哪些地方鱼多，就去哪些地方捞;如果只捞大鱼(严重缺陷)，网眼就可以大些、撒网区域相对比较集中(测试点集中在主要功能-major features)。如果想把大大小小的鱼捞上来，网眼就要小、普遍撒网，不放过任何一块区域(测试点遍及所有功能——all features)。
在“风险”论的框架下，软件测试可以被看作是一个动态的监控过程，对软件开发全过程进行检测，随时发现不健康的征兆，发现问题、报告问题，并重新评估新的风险，设置新的监控基准，不断地持续下去，包括回归测试。这时，软件测试可以完全看作是软件质量控制的过程。
对应这种观点，产生基于风险的测试策略，首先评估测试的风险，功能出问题的概率有多大?哪些是用户最常用的20%功能——Pareto原则(也叫80/20原则)?如果某个功能出问题，其对用户的影响有多大?然后根据风险大小确定测试的优先级。优先级高的测试，优先得到执行，一般来讲，针对用户最常用的20%功能(优先级高)的测试会得到完全执行，而低优先级的测试(另外用户不经常用的80%功能)就不是必要的，如果时间或经费不够，就暂时不做或少做。
4.软件测试的经济学观点
“一个好的测试用例是在于它能发现至今未发现的错误”，体现了软件测试的经济学观点。实际上，软件测试经济学问题至今仍是业界关注的问题之一。经济学的核心就是要盈利，盈利的基础就是要有一个清楚的商业性目标。同样，商业性目标是否正确，直接决定了企业是否盈利的结果。多数情况下，软件测试是在公司内的执行。正是公司的行为目的，决定了软件测试含义或定义的经济性一面。正如，对软件质量的定义不仅仅局陷于“和客户需求的一致性、适用性”，而且要增加其它的要求——“预算内、按时发布、易于维护”。
软件测试也一样，要尽快尽早地发现更多的缺陷，并督促和帮助开发人员修正缺陷。原因很简单：平均而言，如果在需求阶段修正一个错误的代价是1，那么，在设计阶段就是它的3～6倍，在编程阶段是它的10倍，在内部测试阶段是它的20～40倍，在外部测试阶段是它的30～70倍，而到了产品发布出去时，这个数字就是 40～ 1000倍。修正错误的代价不是随时间线性增长，而几乎是呈指数级增长的。
5. 软件测试的标准论
如果从标准论来看软件测试，可以定义为软件测试就是“验证(Verification)”和“有效性确认(Validation)”活动构成的整体，即软件测试 = V&V。
“验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。验证过程提供证据表明软件相关产品与所有生命周期活动的要求(如正确性、完整性、一致性、准确性等)相一致。相当于，以Spec为标准进行软件测试活动，验证软件产品和Spec的一致性。
“有效性确认”是确认所开发的软件是否满足用户真正需求的活动。相当于，保持对软件需求定义、设计的怀疑，一切从客户出发，理解客户的需求，发现需求定义和产品设计中的问题。这主要通过各种软件评审活动来实现。
需要说明的是，软件测试的对象是产品(包括阶段性产品，如市场需求说明书、产品规格说明书、技术设计文档、数据字典、程序包、用户文档等)，而质量保证和管理的对象集中在软件开发的标准、流程和方法等。
究竟什么是软件测试呢?综上所述，软件测试的定义为：
软件测试是贯穿整个软件开发生命周期、对软件产品(包括阶段性产品)进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。
文章来源于领测软件测试网 https://www.ltesting.net/
