软件测试打字程序毕业论文毕业设计（论文）word格式

1、目 录摘要.1 引言.1 第一章 白盒测试研究.2 1.1 软件测试概述.2 1.2白盒测试.3 1.3代码测试.4 1.3.1静态测试.4 1.3.2动态测试.5 1.3.3接口测试.6 1.4白盒测试六种覆盖方法.7 1.5主流白盒测试工具.10 1.5.1parasoft白盒测试工具集.10 1.5.2compuware白盒测试工具集.10 1.6测试管理工具.11 第二章 项目分析与规划测试.12 2.1项目分析.12 2.2主要功能模块.12 2.3 测试环境配置.13 2.4 测试思路与测试方案设计.13 第三章 系统白盒测试实例的实现.15 3.1测试的目的.15 3.2测试项.

2、15 3.3通过的准则.15 3.4测试步骤.15 3.4.1静态测试.16 3.4.2动态测试.16 3.5测试实施.16 3.5.1接口测试.16 3.5.2数据流测试.20 3.5.3基本路径测试.23 3.5.4导出测试用例.24 3.5.5设计测试用例.24 3.8 测试总结.25 3.8.1软件测试的误区.25 3.8.2测试项目中的常见问题及处理方法.28 3.8.3测试的提高.29 总结与展望.31 致谢.32 参考文献.33 打字程序白盒测试摘要 软件开发和使用的历史已经留给了使用者很多由于软件缺陷而导致的巨大财力、物力损失的经验教训。这些经验教训迫使软件开发者们必须添加一个

3、相应的流程，并在此流程中采取强有力的检测措施来检测未发现的隐藏的软件缺陷，也就是软件测试。 软件测试的核心是测试思维，你的思维能深入到什么程度，测试就能做到什么程度，本次课题旨在训练我们的测试思维，同时通过本次的课题实例掌握测试流程与技巧，为我们成为真正的测试人员打下坚实的基础。 随着计算机软件的规模越来越大，软件测试成为了软件质量保障的关键环节，软件测试自动化也成为了软件测试领域所无法逾越的发展阶段。 本文将使用白盒测试技术对打字练习程序进行测试，通过设计测试方案，对程序进行系统的单元测试，收集测试数据，对测试数据进行分析等手段，最终生成相关资料及最终测试报告，详细介绍及探讨软件测试技术和白

4、盒测试实例的设计与实现。 本文的展开将通过以下三个部分： 第一部分：白盒测试及黑盒测试技术的相关介绍，市场上主流测试管理工具的对比分析。 第二部分：本文相关项目的案例分析和测试规划，打字练习程序白盒测试的测试思路和测试方案设计 第三部分：打字练习程序白盒测试的具体实现细则 关键字：黑盒测试，白盒测试，测试管理，测试桩，测试点 引言 信息技术的飞速发展，使软件产品应用到社会的各个领域，软件产品的质量自然成为人们共同关注的焦点。不论软件的生产者还是软件的使用者，均生存在竞争的环境中，软件开发商为了占有市场，必须把产品质量作为企业的重要目标之一，以免在激烈的竞争中被淘汰出局。用户为了保证自己业务的顺

5、利完成，当然希望选用优质的软件。质量不佳的软件产品不仅会使开发商的维护费用和用户的使用成本大幅增加，还可能产生其他的责任风险，造成公司信誉下降，继而冲击股票市场。在一些关键应用 (如民航订票系统、银行结算系统、证券交易系统、自动飞行控制软件、军事防御和核电站安全控制系统等) 中使用质量有问题的软件，还可能造成灾难性的后果。 软件危机曾经是软件界甚至整个计算机界最热门的话题。为了解决这场危机，软件从业人员、专家和学者做出了大量的努力。现在人们已经逐步认识到所谓的软件危机实际上仅是一种状况，那就是软件中有错误，正是这些错误导致了软件开发在成本、进度和质量上的失控。有错是软件的属性，而且是无法改变的

6、，因为软件是由人来完成的，所有由人做的工作都不会是完美无缺的。问题在于我们如何去避免错误的产生和消除已经产生的错误，使程序中的错误密度达到尽可能低的程度。 有鉴于此，本课题将基于白盒测试作为主要研究方向，本文将以打字练习程序作为对象，对软件测试（重点白盒测试）进行研究，以美国mercury公司生产的td软件为工具进行测试用例的管理 本文将通过对对打字练习程序进行白盒测试，对代码，接口等测试进行研究，以实现软件测试在实际项目中的应用，并深刻的理解白盒测试，及白盒测试在测试中所占地位 第一章 白盒测试研究 1.1 软件测试概述 软件测试就是在软件交付用户使用或投入运行前，对软件需求规格说明、设计规

7、格说明和编码的最终复审，是软件质量保证的关键步骤。 软件测试是为了发现错误而执行程序的过程。 软件测试在软件生命周期中横跨两个阶段：通常在编写出每一个模块之后就需要对它做必要的测试（称为单元测试）。编码和单元测试属于软件生命周期中的同一个阶段。在结束这个阶段后对软件系统还要进行各种综合测试，如集成测试、系统测试、性能测试和配置测试等，这是软件生命周期的另一个独立阶段，即测试阶段。 软件测试的目的： 测试的最终目的是为了避免错误的发生，确保应用程序能够正常高效的运行；好的测试用例在于发现至今未发现的错误；成功的测试是发现了至今未发现的错误的测试；好的测试工程师应该做到不仅发现问题，还能够帮助开发

8、人员分析问题； 软件测试的原则： 应把“尽早和不断地进行软件测试”作为软件开发者的座右铭，实践证明单元测试能够尽早发现问题，减少后期测试的错误量。可以采用junit和jtest来辅助进行单元测试;测试用例应由测试输入数据、测试执行步骤和与之对应的预期输出结果三部分组成;应当避免由程序员检查自己的程序。（指后期系统测试阶段，不包括单元测试）;测试用例的设计要确保能覆盖所有可能路径。在设计测试用例时，应当包括合理的输入条件和覆盖所有可能路径不合理的输入条件。不合理的输入条件是指异常的，临界的，可能引起问题的输入条件;充分注意测试中的群集现象。经验表明，测试后程序残存的错误数目与该程序中已发现的错误

9、数目或检错率成正比。应该对错误群集的程序段进行重点测试;严格执行测试计划，排除测试的随意性。测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的配置方式，跟踪规则，调试规则，以及回归测试的规定等等以及评价标准;应当对每一个测试结果做全面的检查;妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。 软件测试的对象：软件测试并不单纯等同于程序测试。软件测试应该贯穿整个软件定义与开发整个期间。因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说

10、明、详细设计规格说明以及源程序，都应该是软件测试（评审）的对象。 在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中，任何一个环节发生了问题都可能在软件测试中表现出来。 1.2白盒测试由于逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。由于我们经常相信某逻辑路径不可能被执行, 而事实上,它可能在正常的情况下被执行。由于代码中的笔误是随机且无法杜绝的，因此我们要进行白盒测试。 白盒测试又称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的,你清楚盒子内部的东西以及里面是如何运

11、作的。 白盒的测试用例需要做到： (1)保证一个模块中的所有独立路径至少被使用一次 (2)检查内部数据结构以确保其有效性 白盒测试的目的：通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。 白盒测试的特点：依据软件设计说明书进行测试、对程序内部细节的严密检验、针对特定条件设计测试用例、对软件的逻辑路径进行覆盖测试。 白盒测试的实施步骤： 测试计划阶段：根据需求说明书，制定测试进度 测试设计阶段：依据程序设计说明书，按照一定规范化的方法进行软件结构划分和设计测试用例。 测试执行阶段：输入测试用例，得到测试结

12、果。 测试总结阶段：对比测试的结果和代码的预期结果，分析错误原因，找到并解决错误。 白盒测试的方法：总体上分为静态方法和动态方法两大类。 静态分析是一种不通过执行程序而进行测试的技术。静态分析的关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。 动态分析的主要特点是当软件系统在模拟的或真实的环境中执行之前、之中和之后 , 对软件系统行为的分析。动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。在动态分析技术中,最重要的技术是路径和分支测试 白盒测试的优缺点 优点：迫使测试人员去仔细思考软件的实现;可以检测代码中的每条分支

13、和路径;揭示隐藏在代码中的错误;对代码的测试比较彻底;最优化。 缺点：昂贵;无法检测代码中遗漏的路径和数据敏感性错误;不验证规格的正确性。 总的来说，白盒测试是一种被广泛使用的逻辑测试方法，是由程序内部逻辑驱动的一种单元测试方法。只有对程序内部十分了解才能进行适度有效的白盒测试。但是贯穿在程序内部的逻辑存在着不确定性和无穷性，尤其对于大规模复杂软件。因此我们不能穷举所有的逻辑路径，即使穷举也未必会带来好运（穷举不能查出程序逻辑规则错误，不能查出数据相关错误，不能查出程序遗漏的路径）。 那么正确使用白盒测试，就要先从代码分析入手，根据不同的代码逻辑规则、语句执行情况，选用适合的覆盖方法。任何一个

14、高效的测试用例，都是针对具体测试场景的。逻辑测试不是片面的测试正确的结果或是测试错误的结果，而是尽可能全面地覆盖每一个逻辑路径。 1.3代码测试 1.3.1静态测试 执行代码静态测试应注意以下方面：同一程序内的代码书写是否为同一风格；代码布局是否合理、美观；程序中函数、子程序块分界是否明显；注释是否符合既定格式；注释是否正确反映代码的功能；变量定义是否正确（长度、类型、存储类型）；子程序（函数和方法）接受的参数类型、大小、次序是否和调用模块相匹配合；函数的返回值类型是否正确；程序中是否引用了未初始化变量；数组和字符串的下标是否为整数；数组和字符串的下标是否在范围内（不“越界”）；进行数组的检索

15、及其它操作中，是否会出现“漏掉一个这种情况”；是否在应该使用常量的地方使用了变量（例： 数组范围检查）；是否为变量赋予不同类型的值；赋值是否符合数据类型的转换规则；变量的命名是否相似；是否存在声明过，但从未引用或者只引用过一次的变量；在特定模块中所有的变量是否都显式声明过；是否可以理解为该变量具有更高的共享级别；是否为引用的指针分配内存；数据结构在函数和子程序中的引用是否明确定义了其结构；计算中是否使用了不同数据类型的变量；计算中是否使用了不同的数据类型相同但长度不同的变量；赋值的目的变量是否小于赋值表达式的值；数值计算是否会出现溢出（向上）的情况；数值计算是否会出现溢出（向下）的情况；除数是

16、否可能为零；某些计算是否会丢失计算精度；变量的值是否超过有意义的值；计算式的求值的顺序是否容易让人感到混乱；比较是否正确；是否存在分数和浮点数的比较；精度问题是否会影响比较；每一个逻辑表达式是否都得到了正确表达；逻辑表达式的操作数是否均为逻辑值；程序中的beginend和dowhile等语句中，end是否对应；程序、模块、子程序和循环是否能够终止；是否存在永不执行的循环；是否存在多循环一次或少循环一次的情况；循环变量是否在循环内被错误地修改；多分支选择中，索引变量是否能超过可能的分支数； 该情况是否能够得到正确处理；全局变量定义和用法在各个模块中是否一致；是否修改了只作为输入用的参数；常量是否

17、被作为形式参数进行传递。 1.3.2动态测试 执行代码动态测试应注意以下方面：测试数据是否具有一定的代表性；测试数据是否包含测试所用的各个等价类（边界条件、次边界条件、空白、无效）；是否可能从客户那边得到测试数据；不可从客户那边得到测试数据的情况下，所用的测试数据是否具有实际的意义（客户业务上的）；是否每一组测试数据都得到了执行；每一组测试数据的测试结果是否与预期结果一致；文件的属性是否正确；打开文件语句是否正确；输入/输出语句是否与格式说明书所记述的一致；缓冲区大小与记录长度是否匹配；使用文件前是否已打开了文件；文件结束条件是否存在；产生输入/输出错误时，系统是否进行检测并处理；输出信息中是

18、否存在文字书写错误和语法错误；数字输入框是否接受数字输入；数字是否按既定格式显示；数字输入框是否拒绝字符串和“非法”数字的输入；组合框是否的能够进行下拉选择；组合框是否能够进行下拉多项选择；对于可添加数据组合框，添加数据后数据是否能够得到正确显示和进行选择；列表框是否能够进行选择；多项列表框是否能够进行多数据项选择；日期输入框是否 接受正确的日期输入；日期输入框是否拒绝错误的日期输入；日期输入框在日期输入后是否按既定的日期格式显示日期；单选组内是否有且只有一个单选钮可选；如果单选组内无单选钮可选，这种情况是否允许存在；复选框组内是否允许多个复选框（包括全部可选）可选；如果复选框组内无复选框可选

19、，这种情况是否允许存在；文本框及某些控件拒绝输入和选择时显示区域是否变灰或按既定规约处理；文本框中数据格式（大小、对齐方向、颜色、背景）是否符合规范；密码输入框是否按掩码的方式显示；控件是否存在默认输入值，若存在，默认值是否得到显示和提交；cancel之类的按钮按下后，控件中的数据是否清空复原或按既定规约处理；submit之类的按钮按下后，数据是否得到提交或按既定规约处理；异常信息表述是否正确；软件是否按预期方式处理错误；文件或外设不存在的情况下是否存在相应的错误处理；软件是否严格的遵循外设的读写格式；产生的文件和数据表的格式是否正确；产生的文件和数据表的计算结果是否正确；打印的报表是否符合既

20、定的格式；错误日志的表述是否正确；错误日志的格式是否正确。 1.3.3接口测试 定义通用的命令接口结构，用文本文件记录接口相关结构信息，通过对该文本文件进行逐行的语法解析，将文件中的描述转化为统一结构的链表，验证来自外层的数据是否正确，以及根据提示用户输入的信息验证发送到其它层的数据是否正确。这种通用接口测试方法，解决了接口测试时重复编写类似功能代码的问题，提供了一种新的描述不同命令结构的思路。通过使用文件形式，不用修改程序就可以实现对新的接口命令的测试，使测试程序得到极大的精简，并且易于扩展和移植到不同项目中。 详细步骤： （1）测试程序要测试的已经具体实现的类。 （2）个抽象的测试类，声明

21、要验证的功能的测试方法。在具体的测试程序实现中继承这个测试类，并修改相应的实现方法。 （3）口的每一个具体实现中都运行该测试程序，但在每个实现中都只验证“接口范围内”的行为 （4）试程序内，找到创建（接口）对象的代码，将该代码改成具体的、已经实现的类的创建方法，但记住将该对象声明为接口的对象，而不是具体实现的类的对象。重复这一过程，直至测试程序中没有已经实现的类的对象。 （5）要在测试中调用的抽象方法。 （6）只涉及接口和一些抽象的测试方法，将测试程序移入抽象的测试类。 （7）这一过程直至所有的测试都移入抽象的测试类。 （8）前面的全部过程，直至除了验证具体实现的特有的方法的测试程序外，所有的

22、测试代码都已完成。 1.4白盒测试六种覆盖方法 首先为了下文的举例描述方便，这里先给出一张程序流程图。（本文以1995年软件设计师考试的一道考试题目为例，图中红色字母代表程序执行路径）。 （1）语句覆盖 主要特点：语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。 用例设计：（如果此时将a路径上的语句1-t去掉，那么用例如表1.4.1） 优点：可以很直观地从源代码得到测试用例，无须细分每条判定表达式。 缺点：由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件和可能到达的隐式逻辑分支，是无法测试的。在本例中去掉了语句1t去掉，那么

23、就少了一条测试路径。在if结构中若源代码没有给出else后面的执行分支，那 么语句覆盖测试就不会考虑这种情况。但是我们不能排除这种以外的分支不会被执行，而往往这种错误会经常出现。再如，在do-while结构中，语句覆盖执行其中某一个条件分支。那么显然，语句覆盖对于多分支的逻辑运算是无法全面反映的，它只在乎运行一次，而不考虑其他情况。 （2）判定覆盖 主要特点：判定覆盖又称为分支覆盖，它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即：程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。 用例设计(如表1.4.2)： 优点：判定覆盖比语句覆盖要多几乎一倍

24、的测试路径，当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。 缺点：往往大部分的判定语句是由多个逻辑条件组合而成（如，判定语句中包含and、or、case），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。 （3）条件覆盖 主要特点：条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。 用例设计(如表1.4.3)： 优点：显然条件覆盖比判定覆盖，增加了对符合判定情况的测试，增加了测试路径。 缺点：要达到条件覆盖，需要足够多的测试用例，但

25、条件覆盖并不能保证判定 覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。 （4）判定/条件覆盖 主要特点：设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。 用例设计(如表1.4.4)： 优点：判定/条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足。 缺点：判定/条件覆盖准则的缺点是未考虑条件的组合情况。 （5）组合覆盖 主要特点：要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。 用例设计(如表1.4.5)： 优点：多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改

26、的判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。 缺点：线性地增加了测试用例的数量。 （6）路径覆盖 主要特点：设计足够的测试用例，覆盖程序中所有可能的路径。 用例设计(如表1.4.6)： 优点：这种测试方法可以对程序进行彻底的测试，比前面五种的覆盖面都广。 缺点：由于路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长。而在有些情况下，一些执行路径是不可能被执行的，如： if （!a）b+； fc3

27、q0if （!a）d-； 这两个语句实际只包括了2条执行路径，即a为真或假时候对b和d的处理，真或假不可能都存在，而路径覆盖测试则认为是包含了真与假的4条执行路径。这样不仅降低了测试效率，而且大量的测试结果的累积，也为排错带来麻烦。 1.5主流白盒测试工具 1.5.1parasoft白盒测试工具集 （1）工具名：jtest 支持语言环境：java 简介：代码分析和动态类、组件测试 （2）工具名：jcontract 支持语言环境：java 简介：实时性能监控以及分析优化 （3）工具名：c+ test 支持语言环境：c,c+ 简介：代码分析和动态测试 （4）工具名：codewizard 支持语言环

28、境：c,c+ 简介：代码静态分析 （5）工具名：insure+ 支持语言环境：c,c+ 简介：实时性能监控以及分析优化 （6）工具名：.test 支持语言环境：.net 简介：代码分析和动态测试 1.5.2compuware白盒测试工具集 （1）工具名：boundschecker 支持语言环境：c+,delphi 简介：api和ole错误检查、指针和泄露错误检查、内存错误检查 （2）工具名：truetime 支持语言环境：c+,java,visual basic 简介：代码运行效率 检查、组件性能的分析 （3）工具名：failsafe 支持语言环境：visual basic 简介：自动错误处理

29、和恢复系统 （4）工具名：jcheck 支持语言环境：ms visual j+ 简介：图形化的纯种和事件分析工具 （5）工具名：truecoverage 支持语言环境：c+,java,visual basic 简介：函数调用次数、所占比率统计以及稳定性跟踪 （6）工具名：smartcheck 支持语言环境：visual basic 简介：函数调用次数、所占比率统计以及稳定性跟踪 （7）工具名：codereview 支持语言环境：visual basic 简介：自动源代码分析工具 1.6测试管理工具 随着软件测试的地位逐步提高，测试管理的重要性逐步显现，测试工具的应用已经成为了普遍的趋势。目前用

30、于测试的工具一般可分为白盒测试工具、黑盒测试工具、性能测试工具，另外还有用于测试管理（测试流程管理、缺陷跟踪管理、测试用例管理）的工具。 总的来说，测试工具的应用可以提高测试的质量、测试的效率。但是在选择和使用测试工具的时候，我们也应该看到，在测试过程中，并不是所有的测试工具都适合我们使用，同时，有了测试工具、会使用测试工具并不等于测试工具真正能在测试中发挥作用。 第二章 项目分析与规划测试 2.1项目分析 2.2主要功能模块 英文练习模块：由系统随机调用文档type_english.dat里的内容，以程序中要求取出字符数输出到界面，由用户输入，程序判断用户练习的速度,时间,正确率等数据。 数

31、字练习模块：由系统随机调用文档type_num.dat里的内容，以程序中要求取出字符数输出到界面，由用户输入，程序判断用户练习的速度,时间,正确率等数据。 字符练习模块：由系统随机调用文档type_car.dat里的内容，以程序中要求取出字符数输出到界面，由用户输入，程序判断用户练习的速度,时间,正确率等数据。 所有字符练习：由系统随机调用文档type_all.dat里的内容，以程序中要求取出字符数输出到界面，由用户输入，程序判断用户练习的速度,时间,正确率等数据。 打字练习结果计算模块：计算用户练习的结果信息 打字练习数据修改模块：用户自定义练习数据，修改后确定保存后更新相应数据库 2.3

32、测试环境配置 测试环境主要包括软件环境和硬件环境，本项目具体测试环境为： 软件环境： 操作系统：microsoft windows xp professional 2002 chs 运行平台：microsoft visual studio 2008 软件支持: mercury testdirector 8.0 硬件环境： cpu：intel(r)pentium(r)m processor 1.86ghz 内存：ddr1g 硬盘：80g(5400转) 显卡：独立ati 64m 网卡：100m/10m 2.4 测试思路与测试方案设计 对程序进行分析，设计测试计划，实施测试，对用例的管理。 第三章

33、系统白盒测试实例的实现 3.1测试的目的 测试主要为打字系统的白盒测试。保证程序的代码规范，代码正确，数据调用正确，以及程序模块单独正常运行，保证局部模块功能完备性，运行正确性与稳定性。使界面符合设计规范，适用于用户。 3.2测试项 所要测试的测试项： 打字程序需求报告，需求规格说明书； 打字程序详细设计文档； 打字程序代码编写规范； 代码中变量的命名标准； 打字程序界面规范。 3.3通过的准则 测试通过主要依照以下标准： 打字程序需求报告，需求规格说明书测试通过的标准：需求报告及需求规格说明书文档中描述的正确性，无异性。 打字程序详细设计文档测试通过的标准：文档中描述的正确性，无异性。 打字

34、程序代码编写规范：创建的变量、接口、函数、属性应与设计文档保持一致；程序的各种命名、注释、代码行的格式等应符合程序开发命名标准和编码规范；程序模块能独立稳定运行。 打字程序界面测试通过的标准：界面的样式、大小、颜色、整体布局的设置；各种标签控件的使用及主题描述以及事件源控件的使用、快捷键使用都应符合nc系统应用框架需求报告和设计文档的相关规范。 3.4测试步骤 需要列出所测试类的调用关系和关键方法的调用关系（依据数据流）。 3.4.1静态测试 变量命名及代码书写规范检查； 变量定义、函数、方法、数组、变量的使用检查； 检查是否有定义未使用的变量； 检查全局变量的使用情况； 检查程序代码循环情况

35、； 检查是否为引用的指针分配内存； 检查数组运算情况。 3.4.2动态测试 控制流分析； 数据流分析； 信息流分析； 画出该代码的控制流程图； 计算程序的圈复杂度； 做基本路径覆盖，设计相应测试用例； 分析测试结果。 3.5测试实施 3.5.1接口测试 (1) 被测试对象（单元）的介绍 接口a：用户选择模块中用户选择所要练习的模块，由参数传至具体模块 接口b：用户选择退出，由参数传至退出模块 接口c：用户自定义练习数据，数据库内容相对更新 (2) 测试范围与目的 检查参数传送的正确性及函数的正确性 (3)测试辅助工具的描述 操作系统：microsoft windows xp professio

36、nal 2002 chs 运行平台：microsoft visual studio 2005 (4) 接口测试用例 接口a：如表3.5.1 接口b：如表3.5.2 接口c：如表3.5.3 3.5.2数据流测试 数据流测试是指关注变量定义点和使用（或引用）点的一种结构测试方式，它和数据流图没有什么联系，实际上，很多数据流测试支持者和研究人员将这种测试方法看做是一种路径测试。早期的数据流分析常常集中于现在叫做定义/引用异常缺陷，如： 变量被定义，但从来没有被使用（引用）。 所使用的变量没有被定义。 变量在使用之前被再次定义。 这些异常可以通过程序的索引表发现。由于索引表信息是有编译器生成的，因此这

37、些异常可以通过所谓景泰分析发现，即在不执行被测程序的情况下发现源代码的一些数据流异常。 首先来分析代码，找出节点及数据流，画出程序流图，如图3.5.2 （1）数据流分析 数据流分析在软件开发、测试和维护中起着十分重要的作用。它将程序中变量的出现分为变量的定义和引用。所谓的数据流分析是指在不运行被测程序的情况下，对变量的定义、引用进行分析，以检测数据的赋值与引用之间是否出现了不合理的现象，如引用未赋值的变量，对以前未曾使用变量的再次赋值等数据流异常现象。 我们根据图4-2给出的一个程序的控制流图，其中每个语句的定义/使用变量由表4-3给出，下面我们来看看详细的表4-3，并对其结果做出分析 通过变

38、量的定义/引用分析，可以发现该程序中含有几个数据流异常： 语句1，2对变量i的定义未曾被使用过 语句11使用了变量timeyser,但在执行时并未对其定义过 语句14使用了变量ctime，而在其之前并未对其进行定义（赋值） 经过上面的分析，发现程序中包含有些异常，有些语句执行还有错误，不过这一情况表明， 也许程序中含有错误，也许可以把程序写的更容易理解，从而能够简化验证 工作，以及随后的维护工作（去掉那些多余的语句一般会缩短执行时间） 定义/使用测试假设v是程序p中变量的集合，程序p的控制流图用g(p)表示。g(p)有一个单入口和一个单出口结点，并且不允许有某个结点到其自身的身边。为描述定义/

39、使用测试，下面先定义几个基本术语： 变量v的定义结点n-记做def(v,n) 变量v的定义结点n-记做use(v,n) 谓词使用-记做puse 定义/使用路径-记做dupath 定义明确路径-记做dc-path 表4-4将给出打字程序中变量的定义结点和使用结点。使用这些信息，结合图4-2中的程序控制流图，可以识别各种定义/使用路径和定义明确路径，对于不可执行的语句，例如常量和变量说明语句，是否应该被认为是定义结点，现在还是学术界争论的一个问题。如果沿定义/使用路径跟踪程序的执行情况，则这些结点并不很重要。但是如果出现了问题，包含这些结点有助于发现问题，则可视情况做出选择。 下面将较详细的分析一

40、些定义/使用路径。 变量right_char的定义/使用路径 变量right_char有两个定义结点和两个使用结点def(right_char,3)和def(right_char,31)以及use(right_char,31)和use(right_char,44)，产生了3条定义/使用路径： p1= p2= p3= 3.5.3基本路径测试 根据基本路径测试的方法，我们将先给出打字程序的数据控制流程图。 1画出打字程序的控制流程图流程图用来描述程序控制结构。可将流程图映射到一个相应的流图(假设流程图的菱形决定框中不包含复合条件)。在流图中，每一个圆，称为流图的结点，代表一个或多个语句。一个处理方

41、框序列和一个菱形决策框可被映射为一个结点，流图中的箭头，称为边或连接，代表控制流，类似于流程图中的箭头。一条边必须终止于一个结点，即使该结点并不代表任何语句(例如：if-else-then结构)。由边和结点限定的范围称为区域。计算区域时应包括图外部的范围。 图4-6 打字程序计算模块代码程序控制流程图2.计算圈复杂度 圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于计算程序的基本的独立路径数目，为确保所有语句至少执行一次的测试数量的上界。独立路径必须包含一条在定义之前不曾用到的边。 有以下三种方法计算圈复杂度： 流图中区域的数量对应于环型的复杂性； 给定流图g的圈复杂度v(g

42、)，定义为v(g)=e-n+2，e是流图中边的数量，n是流图中结点的数量； 给定流图g的圈复杂度v(g)，定义为v(g)=p+1，p是流图g中判定结点的数量。 对应上面图中的圈复杂度计算如下： 流图中有个区域 v(g)=23条边-19节点+2= v(g)=判定点+1= 3.5.4导出测试用例 根据上面的计算方法，可得出六个独立的路径。(一条独立路径是指，和其他的独立路径相比，至少引入一个新处理语句或一个新判断的程序通路。v(g)值正好等于该程序的独立路径的条数。) 路径1：b-c-hh-l 路径2：b-c-d-e-f-g-h-k-l 路径3：b-c-d-e-f-i-j-k-l 路径4: m-n

43、-tt-v 路径：m-n-o-p-q-s-u-v 路径：m-n-o-p-r-t-u-v 根据上面的独立路径，去设计输入数据，使程序分别执行到上面六条路径。 3.5.5设计测试用例 为了确保基本路径集中的每一条路径的执行，根据判断结点给出的条件，选择适当的数据以保证某一条路径可以被测试到，满足上面例子基本路径集的测试用例是： （）路径：（b-c-hh-l）的测试用例 输入数据：speed=49&系统界面上打印出“try againy/n_” 期望结果：屏幕上会打印出“try againy/n_” （2）路径2：（b-c-d-e-f-g-h-k-l）的测试用例 输入数据：变量speed小于或等于50或者是变量right_rate小于或等于80，变量ch