|
|
|
|
|
|
知识路径：
> 电子商务系统程序设计基础
> 电子商务系统的测试
|
被考次数：1次
被考频率：低频率
总体答错率：23%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
考试要求：了解
相关知识点：61个
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
按照测试过程是否在实际应用环境中运行来分类，软件测试方法一般可以分成静态测试和动态测试。测试方法又可以分为分析方法与非分析方法。其中，分析方法包括静态分析法与白盒法，非分析方法又称为黑盒法。
|
|
|
|
|
|
静态测试实际上是确认在给定的外部环境中软件的逻辑正确性，它应该包括规格说明和程序等的确认。静态测试一般不在计算机上实际执行程序，它针对的是软件规格说明等文档及源程序代码文件。软件正确性的确认主要通过以下手段：人工测试、计算机辅助静态分析及程序正确性证明。
|
|
|
|
|
|
人工测试是通过人工阅读分析以及评审软件的文档、程序资料等，以发现程序中的错误。人工评审能找出那些设计中在机器上不易发现的逻辑错误。据统计，好的人工评审可以发现30%～70%的逻辑设计和编码错误。
|
|
|
|
人工评审具有许多优点。它可以成批地发现错误并成批纠正，具有较高的测试效率，而且能在早期发现错误及早纠正，降低了测试的成本，也减少软件错误可能造成的损失。另外，人工评审有利于软件开发人员在一个开发组内取长补短，互相学习。
|
|
|
|
静态分析中进行人工测试的主要方法有桌面检查、代码评审和走查。
|
|
|
|
桌面检查是一种传统的检查方法，主要由程序员检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析、检验，并补充相关的文档，以发现程序中的错误。由于程序作者熟悉自己编写的程序，可以节省检查时间，但也要避免主观片面性。
|
|
|
|
代码评审是由若干程序员和测试人员组成一个评审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。首先让评审人员阅读软件的各种文档和源程序资料，然后召开程序审查会，对各种问题进行讨论，审查问题是否存在。
|
|
|
|
走查与代码评审基本相同。但它不是简单地阅读程序和对照错误检查表进行检查，而是让与会者“充当”计算机，集体扮演计算机的各种角色，让事先准备的有代表性的测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。
|
|
|
|
通过对规格说明文档及源程序资料的检查，对程序的逻辑和功能提出各种问题，并开展热烈的讨论和争议，能够发现软件更多的错误。
|
|
|
|
|
|
使用静态分析工具对被测试的程序进行静态分析，从中提取一些有用的信息，可以显著提高测试的效率。例如，可以用静态分析工具检查程序中的局部变量和全局变量、参数的匹配、判断与循环的嵌套匹配、潜在的死循环、无法执行到的代码段、过程调用层次等。
|
|
|
|
|
|
程序正确性证明就是试图利用某种特定的方法，去证明所开发出来的程序是正确的，不存在任何错误。所谓证明，就是确信一个断言真实性的论证。这种证明可以是形式化的或非形式化的。断言是一种逻辑表达式，它规定必须存在的一个程序状态，或者规定在程序执行过程中某一个特定点上程序变量必须满足的条件集合。
|
|
|
|
|
|
动态测试也称为机器测试，就是直接在计算机上运行所要测试的软件，从实际运行的结果发现并纠正错误。动态测试主要是通过动态分析以及程序测试来检查程序的执行状态，以确认程序的正确性。动态测试的工作包括设计一组测试用例，执行被测试的程序，分析执行后的结果并发现错误。
|
|
|
|
动态测试的基本思想是：将程序视为一个函数，该函数描述了程序的输入与输出的关系。输入的全体称为函数的定义域，输出的全体称为函数的值域。动态测试的过程实际上是取定义域中每个数位作为输入，实际运行程序，判定执行结果是否全部包含在函数的值域中，用以检验程序的正确性、有效性和可靠性。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
⑤将第④步的结果（程序执行结果）与第②步的结果（预期结果）相比较，不吻合则表明程序存在错误。
|
|
|
|
用定义域中的每个元素执行上述测试过程，可以证明程序中是否存在错误，这就是穷尽测试。实际使用的测试方法是一种抽样检查，它把穷尽测试变成一个可行的测试过程。为了进行选择测试，首先就要寻找一个合适的定义域中具有代表性的测试数据集。专家们已经证明，并不存在寻找测试数据集的标准算法。而测试用例中的预期结果实际上是与所选出来的定义域子集相对应的值域子集。
|
|
|
|
常用的动态测试方法有白盒测试和黑盒测试。白盒测试和黑盒测试是软件测试中的两大方法，传统的测试活动基本上都可以划到这两类方法当中。如果了解软件产品的内部逻辑结构，针对某些特定条件设计测试用例对软件的逻辑路径进行测试，可以用白盒法。如果已经了解软件产品规定的功能，测试是为了证实各个功能已经被软件实现，并在各功能中查找其中的错误，可以用黑盒法。
|
|
|
|
|
|
白盒测试是对软件的开发过程中细节做细致的检查，把测试对象看作一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有的逻辑路径进行测试。通过在不同点检查程序状态，以确定实际状态是否与预期的状态一致。因此，白盒测试又称为结构测试或逻辑驱动测试。
|
|
|
|
白盒测试只测试软件产品的内部结构和处理过程，而不测试软件产品的功能。白盒测试用于纠正软件系统在描述、表示和规格上的错误，是进一步测试的前提。
|
|
|
|
白盒测试方法分为静态测试和动态测试。静态测试是不通过执行程序而进行的测试，用于检查软件的表现和需求规格说明描述是否一致。动态测试是指软件执行时，在模拟或真实的软件环境中对软件系统执行之前、执行之中和执行之后进行测试，根据程序的控制结构设计测试用例，具体原则如下：
|
|
|
|
（1）保证一个模块中的所有独立路径至少被使用一次。
|
|
|
|
（2）对所有的逻辑值均需测试true和false。
|
|
|
|
|
|
|
|
|
|
逻辑覆盖法又称为控制流覆盖，是选择一组实体以满足覆盖标准，如语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖和路径覆盖等，然后再选择一组覆盖该组实体的有限路径。下面通过示例来讲解逻辑覆盖方法。
|
|
|
|
|
|
基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径的集合，从而设计测试用例的方法。
|
|
|
|
基本路径测试的关注点在于条件判定节点与循环节点对程序路径带来的复杂度的提高，它通过对程序执行路径的遍历来实现程序的覆盖。该法所遵循的基本测试原则是：对程序模块的所有独立执行路径至少测试一次。
|
|
|
|
|
|
程序的控制流图（可简称流图）是对程序流程图进行简化后得到的，它可以更加突出地表示程序控制流的结构，如下图所示。
|
|
|
|
|
|
|
|
|
|
结点由带标号的圆圈表示，可代表一个或多个语句、一个处理框序列和一个条件判定框（假设不包含复合条件）。
|
|
|
|
控制流线由带箭头的弧或线表示，可称为边。它代表程序中的控制流。
|
|
|
|
|
|
环形复杂度也称为圈复杂度，它是一种为程序逻辑复杂度提供定量尺度的软件度量。
|
|
|
|
可以将环形复杂度用于程序基本路径测试。环形复杂度可以提供：程序基本集的独立路径数量和确保所有语句至少执行一次的测试数量的上界。
|
|
|
|
其中独立路径是指程序中至少引入了一个新的处理语句集合或一个新条件的程序通路，即独立路径必须至少包含一条在本次定义路径之前不曾用过的边。
|
|
|
|
测试可以被设计为基本路径集的执行过程，但基本路径集通常并不唯一。
|
|
|
|
环形复杂度以图论为基础，为我们提供了非常有用的软件度量。可用如下三种方法之一来计算环形复杂度：
|
|
|
|
|
|
|
|
|
|
其中，E是控制流图中边的数量，N是控制流图中的节点数量。
|
|
|
|
（3）给定控制流图G的环形复杂度V（G），也可定义为
|
|
|
|
|
|
|
|
|
|
|
|
|
|
②计算得到控制流图G的环形复杂度V（G），导出程序基本路径集中的独立路径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。
|
|
|
|
|
|
④根据③中的独立路径，设计测试用例的输入数据和预期输出。
|
|
|
|
|
|
黑盒测试又称为数据驱动测试、基于规格的测试、输入输出测试或者功能测试。黑盒测试基于产品功能规格说明书，从用户角度针对产品特定的功能和特性进行验证活动，确认每个功能是否得到完整实现，用户能否正常使用这些功能。
|
|
|
|
黑盒测试在不知道系统或组件内部结构的情况下进行，不考虑内部逻辑结构，着眼于程序外部结构，在软件接口处进行测试。黑盒测试主要具有如下功能：
|
|
|
|
（1）检查程序功能能否按需求规格说明书的规定正常使用，测试各个功能是否有遗漏，检测是否满足性能等特性要求。
|
|
|
|
（2）检测人机交互是否错误，检测数据结构或外部数据库访问是否错误，程序是否能适当地接收输入数据而产生正确的输出结果，并保持外部信息（如数据库或文件等）的完整性。
|
|
|
|
|
|
黑盒测试方法主要有等价类划分、边界值分析、决策表、因果图、错误推测和功能图法等测试方法，本节主要介绍等价类划分、边界值分析、决策表和元素分析法与错误推测法。
|
|
|
|
|
|
等价类是指某个输入域的子集合。在该子集合中，测试某等价类的代表值就等于对这一类其他值的测试，对于揭露程序的错误是等效的。因此，将输入的全部数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据取得较好的测试结果。
|
|
|
|
|
|
（1）有效等价类。对于程序的规格说明来说，它是由合理的、有意义的输入数据构成的集合，利用它可检验程序是否实现了规格说明中所规定的功能和性能。
|
|
|
|
（2）无效等价类。与有效等价类相反，它是由对程序的规格说明无意义、不合理的输入数据构成的集合。
|
|
|
|
测试用例的设计不仅接收合理的数据，也能经受意外的不合理数据的考验，这样才能确保软件具有较高的可靠性。
|
|
|
|
分析可能的输入情况，按照如下几条规则对等价类进行划分。
|
|
|
|
（1）在输入条件规定了取值范围或值的个数的情况下，确立一个有效等价类和两个无效等价类。
|
|
|
|
例如，若输入条件规定了x的取值为1～100的整数，则等价类划分有效等价类1≤x≤100，两个无效等价类分别为x<1或x>100。
|
|
|
|
（2）按照数值集合划分。在输入条件规定了输入值的集合或者规定了“必须如何”的条件下，确立一个有效等价类和一个无效等价类。
|
|
|
|
例如，输入条件规定了x的取值为偶数，则有效等价类为x的值为偶数，无效等价类为x的值不为偶数的整数。
|
|
|
|
（3）输入条件是一个布尔量的情况，确定一个有效等价类和一个无效等价类。
|
|
|
|
（4）规定输入数据取一组值（假定n个），并且程序要在对每一个输入值分别处理的情况下，确立n个有效等价类和一个无效等价类。
|
|
|
|
例如，分房方案中对教授、副教授、讲师、助教分别计分，则有效类为4个；无效类为1个。
|
|
|
|
（5）按照限制条件或规则划分。在规定输入数据必须遵守的规则的情况下，确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
|
|
|
|
例如，C程序设计语言的语法规定．每个语句应以“；”结束，则其有效类有1个，而无效类有若干个（如以“，”结束、以“：”结束、以空格结束等）。
|
|
|
|
（6）在确知已划分的等价类中各元素在程序处理方式不同的情况下，再将该等价类进一步划分为更小的等价类。
|
|
|
|
|
|
|
|
|
|
根据等价类表，确定测试用例。首先，为每一个等价类规定唯一编号；其次，设计新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；最后，设计新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止（通常，程序在执行一个错误后不继续检测其他错误，故每次只测一个无效类）。
|
|
|
|
|
|
软件测试实践中，大量的错误往往发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。例如，数组下标、循环控制变量等边界附近往往出现大量错误。因此，作为等价类划分方法的补充，边界值分析方法不是选择等价类的任意元素，而主要是针对各种边界情况设计测试用例。
|
|
|
|
|
|
（1）对16位的整数而言，32767和-32768是边界。
|
|
|
|
|
|
|
|
|
|
（5）循环的第0次、第1次和倒数第2次、最后一次是边界。
|
|
|
|
边界值分析法应着重测试的情况，一般选取等价类划分的输入和输出的边界正好等于或刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
|
|
|
|
|
|
（1）如果输入条件规定了值的范围，则应选取刚达到范围的边界值，以及刚刚超越边界的值作为测试的输入数据。
|
|
|
|
（2）如果输入条件规定了值的个数，则用略低于最小值、最小值、略高于最小值、正常值、略低于最大值、最大值和略高于最大值作为测试数据。
|
|
|
|
（3）如果程序规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
|
|
|
|
|
|
决策表又称为判定表，用于分析多种逻辑条件下执行不同操作的技术。在程序设计发展的初期，决策表是程序编写的辅助工具。决策表可以把复杂的逻辑关系和多种条件的组合情况表达明确，与高级程序设计语言中的if-else、switch-case等分支结构语句类似，它将条件判断与执行的动作联系起来。但与程序语言中的控制语句不同的是，决策表能将多个独立的条件和多个动作联系清晰地表示出来。
|
|
|
|
|
|
（1）条件桩：列出了问题的所有条件。通常认为，列出的条件次序无关紧要。
|
|
|
|
（2）动作桩：列出了问题规定可能采取的操作，这些操作的排列顺序没有约束。
|
|
|
|
（3）条件项：列出了针对条件桩的取值在所有可能情况下的真假值。
|
|
|
|
（4）动作项：列出了在条件项的各种取值的有机关联情况下应该采取的动作。
|
|
|
|
规则即任何条件组合的特定取值及其相应要执行的操作。在决策表中，贯穿条件项和动作项的列就是规则。显然，决策表中列出多少个条件取值，也就有多少个规则，条件项和动作项就有多少列。
|
|
|
|
所有条件都是逻辑结果的决策表称为有限条件决策表。如果条件有多个值，则对应的决策表就叫做扩展条目决策表。决策表用来设计测试用例，条件解释为输入，动作解释为输出。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
有n个条件的决策表有2n个规则（每个条件取真、假值）。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
元素分析法主要是对测试对象中的各个元素的属性、范围、特点等进行分析，通过对元素的分析，寻找出测试空间和缺陷空间，设计测试用例的方法。
|
|
|
|
|
|
|
|
（2）分析每个元素的特点和属性，确定测试空间与缺陷空间。
|
|
|
|
|
|
错误推测法是基于经验和直觉的推测，列举出程序中所有可能错误和容易发生错误的特殊情况，有针对性地设计测试用例。
|
|
|
|
经验表明，一段程序中已发现的错误数目和尚未发现的错误数目成正比。程序中容易出错的情况如下所示：当输入数据为零时，或者输入或输出的数目允许变化（例如，被检索的或生成的表的项数），或者输入或输出的数目为0和1的情况（例如，表为空或只有一项）等，都较容易发生错误。又如，在单元测试时曾列出许多在模块中常见的错误，以前产品测试中曾经发现的错误等，这些就是经验的总结。
|
|
|
|
错误推测法是根据测试人员的经验来确定测试的范围和程度，主要采用如下技术：
|
|
|
|
|
|
|
|
（3）根据测试类似或相关系统的经验，了解在以前的这些系统中曾在哪些地方出现过缺陷。
|
|
|
|
|
|
|
