软件质量保证及测试基础考试,【软件质量保证及测试基础】软件测试基础

软件质量有多种定义，一种说法是，软件质量是软件产品中能满足给定需求的各种特性的总和。这些特性称为质量特性，它包括功能性，可靠性，易使用性，时间经济性，资源经济性，可维护性和可移植性等。

还有一种说法是，软件质量是软件产品中能满足规定的和隐含的与需求能力有关的全部特征和特性，包括：

软件产品质量满足用户要求的程度。

软件各种属性的组合程度。

用户对软件产品的综合反映程度。

软件在使用过程中满足用户要求的程度。

总的来说，软件质量是软件产品满足使用要求的程度。其中“程度”是由软件的特性或特征集组成的。

一.什么是软件缺陷？为什么说随着时间的推移修复软件缺陷的成本越来越高？

大家常说的“bug”，即我们所说的软件缺陷。软件缺陷，就是计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义：

从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问；

从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

软件生命周期的各个阶段的工作都有可能发生错误，并不只是在编码阶段产生错误，需求和设计段同样会产生错误。由于前一阶段的成果是后一阶段的工作基础，前一阶段的错误自然会导致后一阶段的工作结果中有相应的错误，而且错误会累积、扩散，越来越多。越到后期，修复缺陷的代价就会越大，因此，缺陷发现或解决的越迟，成本就越高。

二.什么是测试用例？如何评判测试用例的好坏？

如何设计好的测试用例？

测试用例是指对一项特定的软件产品进行测试任务的描述，体现了测试方案、方法、技术和策略，其内容包括测试目标、测试环境，输入数据、测试步骤、预期结果和测试脚本等。简单来说，测试用例是针对要测试的内容所确定的一组输入信息，是为达到最佳的测试效果或高效地揭露隐藏的错误而精心设计的少量测试数据。

一个好的测试用例在于它能发现至今未发现的错误。

要想设计好的测试用例，通常需要遵守以下原则：

(1)使用成熟的测试用例设计放大来进行设计；

(2)保证测试用例数据的正确性和操作的正确性；

(3)确保测试用例应该针对单一的测试项；

(4)每个测试用例应该针对单一的测试项；

(5)保证测试结果是可以判定并且可以再现的；

(6)保证测试用例的描述准确、清晰、具体；

(7)测试用例设计应满足项目的时间、人员和资金约束。

三.简述软件测试的原则。

原则1：测试显示存在缺陷。

测试应用程序只能显示在应用程序中存在一个或多个缺陷，但是，仅仅通过测试 并不能证明应用程序没有错误。因此，设计测试用例使其尽可能多的找到缺陷是 很重要的。

原则2：穷举测试是不可行的。

除非受测试应用具有非常简单的逻辑结构和有限的输入，进行所有测试数据和场 景的组合是不可能的事。出于这个原因，风险评估和优先级被用于集中测试最重 要的方面。

原则3：测试活动要今早开始。

我们越早开始测试活动，就越可以更好的利用可用的时间。当最初的产品，例如 要求或设计文件完成后，我们就可以开始测试。测试阶段常会在开发周期的最后 部分也就是开发完成之后遭到时间压缩。因此，尽早开始测试，我们可以针对开 发生命周期的每个阶段进行测试的准备。另一个关于尽早测试的重要的一点是，当缺陷在生命周期中更早的被发现时，它 们更容易解决而且成本更低。改变不正确的要求比起必须改变一个大型系统中没 有按照要求或设计来工作的功能要成本低得多！

原则4：缺陷集群性。

在测试过程中，可以观察到，大多数报告的缺陷都与少数几个系统内的模块有关 。即少量模块包含了系统中大部分的缺陷。这也是帕雷托法则(二八定律)在软 件测试方面的实际应用：约80％的问题被发现在20%的模块中。

原则5：杀虫剂悖论。

如果持续运行同一套测试一遍又一遍，有可能那些测试用例就无法发现新的缺陷 。因为随着系统的发展，许多以前报道的缺陷将会被修好，旧的测试用例就不再 适用了。每当修复完缺陷或添加了新的功能后，我们需要做回归测试，以确保新 更改的软件不破坏该软件的任何其他部分。然而，这些回归测试用例也需要根据 软件本身的变化作出改变，使其能够更加适用并找到新的缺陷。

原则6：测试依赖于测试背景。

不同的测试方法，测试技术和测试类型是根据应用程序的类型和性质来决定的。 例如，运用于医疗设备上的软件应用程序相比游戏软件需要进行更多的测试。更 重要的是医疗设备软件需要基于风险测试，需要符合医疗行业监管以及可能的特 殊测试设计技术。出于同样的原因，一个非常受欢迎的网站，需要经过严格的性 能试验，以及功能性的测试，以确保性能不受服务器上的负载的影响。

原则7：没有失效就是有用系统是一种谬论。

只是因为测试没有发现软件中的任何缺陷，并不意味着该软件是随时可以发布的 。被执行的测试，是否真的找到了大多数缺陷？或者，他们是否根据顾客需求设 计检查软件是否满足要求？在发布软件之前，还需要考虑很多其他因素。