【软件工程】软件测试

测试的目的是试图说明一个程序可以做我们期望它所做的工作和在投入使用之前发现程序的缺陷。当我们测试软件时，使用人工数据来执行这个程序。我们审查测试运行的结果，找出关于程序的非功能属性的错误、异常或其他信息。

测试过程有两个截然不同的目标：

1. 向开发者和用户展示软件满足了需求。对于定制软件，这意味着对用户和系统需求文档中的每个需求至少要有一个测试。对于通用软件产品，这意味着要对每个集成在产品发布版本中的所有系统特征以及这些特性的组合进行测试。
2. 为了找出软件中的缺陷和不足，即软件的行为是不正确的、所不希望的或不符合它的描述的。这些是软件缺陷的后果。缺陷测试关心的是找出所有不希望出现的系统的行为根源。例如系统崩溃，与其他系统的不期望的交互，不正确的计算和数据毁坏。

有效性测试可达成第一个目标，即在这一阶段中使用系统所希望的使用方式的一组测试案例来测试系统的表现。缺陷测试可达成第二个目标，即在这一阶段测试案例是设计来暴露系统的缺陷。测试案例可以是故意模糊的并且不需要反映系统通常是怎样使用的。当然，在这两个测试方法之间没有确定的边界。在有效性测试过程中，我们将会发现系统的缺陷;在缺陷测试过程中，一些测试案例将会表明这个程序满足它的要求。

下图会帮助我们理解有效性测试和缺陷测试之间的差别。我们把被测试系统看做是一个黑盒子。这个系统接收来自输人集合I的输人数据，在输出集合0中产生输出结果。一些输出结果可能是错误的，这些错误输出在集合0中，这些结果是由于集合I中的输入而产生的。在缺陷测试中，优先去发现在集合I中的输入，因为这会暴露系统的问题。有效性测试需要正确的输入来进行测试，这些输入是来自I之外的。这些模拟系统产生所期望的正确的结果。

有效性验证的目的是审查软件满足它的所规定的功能和非功能性需求。然而，检验是一个更一般的过程。检验的目的是确保软件符合用户的期望。为了证明这个软件的确可以做到用户所期望的，不简单地是看它是否与需求描述是一致的，还要看它是否真的是客户所期待地那样去执行的。检验是必要的，因为正如第4章中所讨论的，需求描述不可能一直反映用户和使用者的真实愿望和系统需求。

检验和有效性验证过程的最终目的是建立信心，即这个软件系统是“达到目的”的。这意味着这个系统必须足够好。这种对系统的信心水平取决于系统的目的、系统用户的期望和系统当前市场环境：

1. 软件目的这个软件越重要， 它的可靠性就越重要。例如，与一个为展示新产品构思所开发的原型系统相比，用于控制安全要求极高的系统所需的信心水平要更高一点。
2. 用户期望由于他们在问题频出 、不可靠的软件上的一些经验，许多用户对软件的质量抱有很低的期望。当软件出错时，他们一点也不奇怪。当新的系统建好时,用户会忍受它的失败，因为使用的好处超过了故障恢复的成本。在这些情况之下，我们不必花费更多的时间在测试上。然而，随着软件的成熟，用户希望它能更可靠，所以需要更彻底地测试后期版本。
3. 市场环境当一个系统推到市场后， 系统的卖家必须充分考虑竞争的产品和用户愿意付出多少钱来购买这个系统，以及为实现这一系统所需的时间表。在竞争的环境中，一个软件公司可能在这个项目完全测试和调试之前就投放到市场中，因为他们想成为第一个进入市场的公司。如果一个软件产品非常便宜，用户可能会忍受一个较低的信任度。

如下图是一个“传统”测试过程的抽象模型，用在计划驱动的开发中。测试用例是一个对输入和在特定环境下的期望的输出以及所测试的对象的一个描述。测试数据是为了测试系统而设计的输入。在一些情况下测试数据可以自动产生。但自动测试用例生成是不可能的，因为了解系统应该怎样执行的人必须对期待的测试结果给出定义。然而测试可以自动执行。预期的结果自动地和预测的结果相比较，所以在测试过程中不需要人来查找错误和异常。

典型地，一个商业软件系统要经过3个阶段的测试：

1. 开发测试：即在开发中进行系统测试来发现故障和缺陷。在测试过程中很可能涉及系统设计师和程序员。
2. 发布测试：即一个测试小组对一个系统的完整版本进行测试，然后发布给用户。发布测试的目的是审查系统是否满足系统信息持有者的要求。
3. 用户测试：即系统的用户或是潜在的用户在他们自己的环境中测试这个系统。对于软件产品来说，“用户”可能是一个内部营销组，它决定该软件是否可以投放市场、发布版本和销售。接收测试是用户测试的一种，即客户正式测试一个系统，以决定是否应该从系统供应处接收，或是否需要进一步开发。

开发测试

开发测试包括系统开发团队所进行的所有测试活动。软件的测试人员通常是开发这个软件的编程人员，虽然并非总是如此。一些系统是由编程人员和测试人员配对(结对)开发的(Cusamano和Selby, 1998), 每个程序员都有一个相关测试人员，这个测试人员开发测试用例并辅助测试过程。对要求极高的系统，会采用一个更正规的测试过程，由独立的测试人员负责所有阶段的测试。他们负责开发测试用例和维护测试结果的详细记录。

在开发过程中，可在3个粒度级别进行测试：

1. 单元测试：即对单独的程序单元或对象类进行测试。单元测试应该着重测试对象或方法的功能。
2. 组件测试：即将多个程序单元整合创建一个合成的组件。组件测试应该着重测试组件的接口。
3. 系统测试：即集成系统中的一些或所有的组件作为一个整体进行测试。系统测试应该着重测试组件的交互。

开发测试主要是一个缺陷测试的过程，即测试的目的是发现系统中的错误。因此，它通常和调试交错执行。调试是定位有问题的代码的过程,然后修改程序来解决这些问题。

测试驱动开发

测试驱动开发是一种程序开发方法。

测试驱动的基本过程如下图。这个过程的步骤如下：

1. 从识别所需要的功能增量开始。这个通常应该比较小，用几行代码就可以实现。
2. 针对此功能编写一个测试并实现为一个自动测试。这意味着测试是可执行的，并将报告它是通过或是失败。
3. 然后运行此测试，以及所有已实现的其他测试。最初，我们并没有实现这个功能，因此这个新的测试将是失败的。这是有意的，因为它可以表明测试添加了一些新东西到测试集中。
4. 然后是实现这个功能，并重新运行这个测试。这可能涉及重构现有的代码来改善它，并添加新的代码到已经存在的代码中。
5. 一旦所有的测试成功，我们可以转去实现下一个功能块。

除了对问题有较好的理解外，测试驱动开发还有其他的优势：

1. 代码覆盖：原则上，我们所写的每个代码片段都至少有一个测试。因此，我们可以确信系统中的所有代码都实际执行过。因为代码边写边进行测试，在开发过程中可以提早发现缺陷。
2. 回归测试：随着一个程序的开发， 一个测试套件也增量式开发出来。我们可以一直运行回归测试来审查程序中的变更没有引起新的错误。
3. 简化调试：当一个测试失败的时候，问题出在何处是很明显的。新写的代码需要审查和修改。我们不必使用调试工具来对问题定位。使用测试驱动开发的报告显示，在一个测试驱动开发中，几乎没有必要使用自动调试器。
4. 系统文档：测试本身就表现为一种文档形式，它描述了代码应该做什么。阅读测试可以使得理解代码变得更容易。

测试驱动开发的最重要的优势之一是它减少了回归测试的代价。

发布测试

发布测试是为开发组以外的用户使用的系统的一个特殊版本所做的测试过程。通常，系统发布版本是为了客户和使用者。但在一个复杂项目中，发布版本可能是为了正在开发有关系的系统的另一个小组。对于软件产品来说，发布版本可能为了将来出售它的产品管理者而准备的。

在开发过程中，发布测试和系统测试之间有两个重要的区别：

1. 一个独立的与系统开发无关的小组应该负责发布测试。
2. 开发组的系统测试的重点是在系统中发现错误(缺陷测试)。发布测试的目标是检查系统符合它的需求描述，并且足可以对外销售(有效性验证测试)。

这个过程的主要的目标是增加供应商对系统能良好地使用的信心。如果系统满足需求的话，它就可以作为一个产品或移交给客户的软件发布出去。因此，发布测试必须证明系统具有指定的功能、性能和可依赖性，在常规操作下不会出错。它应该将所有的系统需求考虑在内，而不仅仅是系统最终用户的需求。

发布测试通常是一个黑盒测试过程，测试从系统描述导出。系统被作为一个黑盒子,它的行为只能通过输人和与它相应的输出来确定。这种测试的另一个名称叫做“ 功能测试”，因为测试者，只关心系统的功能并不关心软件的实现。

用户测试

用户或客户测试是测试过程中的一个阶段， 在这个阶段,用户或客户提供输入和系统测试建议。这可能会是一个正式的对外部供应商提供的系统的测试，或是一个非正式的过程，用户测试一个新的软件产品来看看他们是否喜欢或这个产品是否能符合他们的需求。用户测试是必不可少的，即使全面的系统测试和发布测试已完成。原因是来自用户工作环境的因索对一个系统的可靠性、性能、可用性以及健壮性有很大的影响。

实际上，存在3种不同的用户测试类型：

1. a测试，软件的用户与开发小组一起在开发者的地点测试这个软件。
2. β测试，该软件的版本是提供给用户让他们进行试验，并向开发者提出他们所发现的问题。
3. 接收测试，客户测试系统来决定他们是否愿意从系统开发者那里接收系统并在客户环境中部署。

接收测试是定制系统开发的一个固有的部分。发布测试之后就是接收测试。它需要客户正式测试-一个系统来决定是否可以从开发商那里接收这个系统。接收意味着要为该系统付费。

在接收测试过程中有6个阶段，如下图。它们是：

1. 定义接收准则：这个阶段理想情况下应该是发生在签订系统合同之前的过程早期。接收准则应该是系统合同-部分，并得到客户和开发者的同意。然而实际上，在早期阶段定义接收准则是很困难的。详细的需求描述可能是不可得的，在开发过程中需求可能会有重大变化。
2. 计划接收测试：这涉及确定接收测试所需要的资源、时间和预算，以及做一个测试计划表。这个接收测试计划也应该讨论对需求所需的覆盖和系统功能测试的顺序。它应该确定测试过程的风险，例如系统崩溃、性能不足，并且讨论这些风险如何得到缓解。
3. 导出接收测试：一旦接收准则确定后，就需要设计测试来检查系统是否可以接收。接收测试目的应该是测试系统的功能性和非功能性特性(例如性能)。理想情况下，接收测试应该提供完整的系统要求覆盖。实际上，很难建立完全客观的接收标准。经常会有关于一个测试是否证明了它确实符合了某个准则的争论。
4. 运行接收测试：经过同意的测试在系统上执行。理想情况下，这个应该发生在系统使用的真实环境中，但是这可能是破坏性和不实际的。因此，必须建立一个用户测试环境来运行这些测试。使这个过程自动运行是很困难的，因为接收测试的一部分可能包含测试最后用户和系统之间的交互。可能需要对最终用户有一些培训。
5. 协商测试结果：所有定义的接收测试全部通过并且系统没有任何问题，这是不太可能的。如果是这种情况的话，则接收测试就完成了，并且系统可以交付了。更常见的是，会发现一些问题。在这种情况下，开发者和客户必须协商来决定该系统是否能够很好地投入使用。他们还必须商定开发者对已确定问题的回应。
6. 拒绝/接收系统：这个阶段包含开发者和客户之间的一个会议，这个会议来决定这个系统是否可以接收。如果该系统不足以来使用，则需要进一步的开发来解决这个已确定的问题。一旦完成，接收测试阶段就循环进行。