缺陷数量最大化。
这与“发现缺陷”的区别就是缺陷总数比其覆盖面更重要。
即使这是及时发现更多缺陷的有用方法，我们也只是狭隘的关注少数几个高风险的方面。
阻止不合格产品的发布。
测试人员发现产品有严重缺陷时阻止其出库，直到这些问题得到解决。在每次的发布决议会上，测试人员的目的是发现新的瑕疵、缺陷。
协助管理者做出库的决定。
管理者普遍都关心这方面的风险。
他们想知道缺陷覆盖面(可能不是过于简单的代码覆盖面统计，而是说明产品发现了多少缺陷，有多少还没有解决)，和已发现问题的重要性。书面上出现的重大而不会引起客户不满的问题，可能不会影响产品的出库决定。 软件测试
技术支持成本最小化。
与技术支持或服务组一起工作，测试组要识别出需要支持的问题。这些通常是与产品相关的外围支撑，是不需要测试的，例如，测试产品需要与特定的打印机一起工作或者从第三方数据库成功地导入数据，可以高频率的访问和数据崩溃。
遵照规格说明书进行评审。
规格说明书中提出的要求都是经过审核的。规格说明书中没有列出的程序特性不(当作目标的一部分)进行审核。
遵照规范。
如果规范指明了覆盖范围内的某个类型(例如，至少对产品的每个声明做一个测试)，那么测试组要创建合适的测试。如果规范为规格说明书或其他文档指明了一个类型，那么测试组可能需要检查这个类型。一般地说，测试组关注规则中覆盖以及没有覆盖的任何事物。
最小化安全诉讼风险。
任何会导致事故或伤害的失误都应该在第一时间被关注。导致时间或数据丢失或数据损坏，但不会对实际事物带来伤害或损坏风险的失误可以不考虑。
发现使用产品的安全情景(即使发现存在缺陷，也能工作的方法)。
有时，寻找的是可以持续不断进行一项作业的方法---其他人依照一组指令会可靠地发送期望产生的有益信息。在这种情况下，测试员不是寻找缺陷。他是在进行试验，按照经验推敲和证实进行作业的方法。
质量评估。
这是一个棘手的目标，因为质量是多维度的。
质量的性质依赖于产品的性质。例如，一个没有娱乐性的摇动物体的电脑游戏是一个令人厌恶的游戏。
进行质量评估--测量并报告质量水平--你可能需要对这个产品的大多数重要质量标准有一个明确的定义，并且需要有相关的定义测试结果的理论知识。例如，可靠性不只是关于产品缺陷数的。它是(或经常被定义成)关于可靠性相关的故障数，这些故障期望在一段时间内或一段时间的应用中发生。(可靠性相关?比如，测量可靠性时，企业可能不关心错误信息中的拼写失误。)为了进行预测，你需要一个精确的、依经验形成的合理原型，使测试结果具有可靠性。测试包括获取模型需要的数据，包括产品绝对稳定和不稳定的方面做深入的工作。设想一个可靠的模型是基于统计(可能以严重性类型来区分)每N行代码或每K小时测试发现的BUG数的。查找BUG是重要的，消除重复也是重要的，发现并解决问题使缺陷报告更易于理解、更可能纠正是(在评估的范围内)超出范围的。
检验产品的正确性。
测试是不可能做到这一点的。你可以证明产品不正确，或者你可以证明你在特定时间内用特定的测试策略没有找到任何错误。但是，你不可能进行详尽的、无一遗漏的测试，并且产品可能在你没进行测试的条件下宣告失败。(如果你有一个实在的、可靠的模型)你能做的最好的就是评估出现错误的概率。(参照下面关于可靠性的讨论)。
质量保证。
尽管质量保证是共同的目标，但是不能通过测试来保证质量，不能通过获取度量值来保证质量，不能通过设置标准来保证质量。
质量保证包括构建一个高质量的产品，以及为此贯穿在整个开发过程中有熟练技能、有时间、有激情、有方向、有创造自由的人。
这超出了一个测试团队的工作范围，但在项目经理和相关实施者的范围内。
在进行技术研究的过程中测试团队可获得一定的帮助，但这些研究并不不能保证质量。
给定一个测试对象，好的测试过程能够提供与这个对象直接相关的信息。
文章来源于领测软件测试网 https://www.ltesting.net/
