网站品质,cpancel面板搭建WordPress,网站开发公司内部数据字典,定制企业网站目录 一、测试级别二、组件测试三、开发者测试3.1测试与调试3.2 组件测试目标3.3 测试功能 四、稳健性测试4.1 效率的测试4.2 测试可维护性4.3 测试策略4.4 白盒测试 一、测试级别
软件系统通常是由许多子系统组成的#xff0c;而这些子系统又是由多个组件组成的#xff0c;… 目录 一、测试级别二、组件测试三、开发者测试3.1测试与调试3.2 组件测试目标3.3 测试功能 四、稳健性测试4.1 效率的测试4.2 测试可维护性4.3 测试策略4.4 白盒测试 一、测试级别
软件系统通常是由许多子系统组成的而这些子系统又是由多个组件组成的通常被称为单元或模块。由此产生的系统结构也被称为系统的 软件结构 或 “架构”。设计能完美支持系统要求的架构是软件开发过程中的关键部分。
在测试过程中系统必须在其结构的每个层面上进行检查和测试从最基本的组件一直到完整的集成系统。与架构的某一层次有关的测试活动被称为测试 “层次”每个测试层次都是测试过程的一个实例。 以下各节将详细说明各个测试层次在不同的测试对象、测试目标、测试技术和责任/角色方面的区别。
二、组件测试
术语
组件测试包括系统地检查系统结构中的最低层组件。根据用于创建这些组件的编程语言这些组件有不同的名称如 “单元”、模块 或在面向对象编程的情况下“类”。因此相应的测试被称为 “模块测试”、单元测试 或 “类测试”。 组件和组件测试
无论使用哪种编程语言所产生的软件构件是 “组件”相应的测试被称为 “组件测试”。
测试基础
组件的具体要求和组件的设计即规格要被参考以形成测试基础。为了设计白盒测试或评估代码覆盖率你必须分析组件的源代码并将其作为额外的测试基础。然而为了判断组件对测试用例的反应是否正确你必须参考设计或需求文档。
测试对象
如上所述模块、单元或类是典型的测试对象。然而像shell脚本、数据库脚本、数据转换和迁移程序、数据库内容和配置文件也都可以成为测试对象。
组件测试验证了组件的内部功能
组件测试通常只测试与系统其他部分隔离的组件。这种隔离的作用是在测试中排除外部的影响。它还简化了测试用例的设计和自动化因为它们的范围很窄。
组件可以由多个构建块组成。重要的一点是组件测试只需要检查有关组件的内部功能而不是与外部组件的交互。后者是集成测试的主题。组件测试对象通常是 “从程序员的硬盘中获得的”这使得这一层次的测试与开发工作紧密相连。因此组件测试人员需要足够的编程技能来正确地完成他们的工作。
案例研究 测试calculate_price类
经销商折扣是从清单价格中减去的而配件折扣只适用于额外的东西。这两种折扣不能同时使用。最后的价格是用以下方法计算的 为了测试这个计算测试人员通过调用calculate_price()方法和提供适当的测试数据来使用相应的类接口。然后测试人员记录组件对这个调用的反应–即读取并记录方法调用所返回的值。
这段代码是有错误的计算≥5的折扣的代码永远无法到达。这个编码错误可以作为例子来解释第五章详述的白盒分析。
要做到这一点你需要 “测试驱动”。测试驱动是一个独立的程序它进行所需的接口调用并记录测试对象的反应也见第5章。
对于calculate_price()测试对象简单的测试驱动可以是这样的 我们例子中的测试驱动非常简单例如可以扩展到记录测试数据和带有时间戳的结果或者从外部数据表中输入测试数据。
三、开发者测试
要写测试驱动你需要编程技巧。你还必须研究和理解测试对象的代码或者至少是它的接口的代码以便编程正确调用测试对象的测试驱动。换句话说你必须掌握相关的编程语言你需要获得适当的编程工具。这就是为什么组件测试通常是由组件的开发者自己进行的。这样的测试通常被称为 “开发者测试”尽管 组件测试 才是真正的意思。开发者测试自己的代码的缺点将在第2.4节讨论。
3.1测试与调试
组件测试经常与调试相混淆。然而调试涉及消除缺陷而测试涉及系统地检查系统的故障。
使用单元测试框架比如pytest、unittest、junit等大大减少了测试驱动编程的工作量并在整个项目中创建一致的组件测试架构。使用标准化的测试驱动也使团队中不熟悉各个组件或测试环境的其他成员更容易进行组件测试。这些类型的测试驱动可以通过命令行界面控制并提供处理测试数据的机制以及记录和评估测试结果。因为所有的测试数据和日志都是相同的结构所以有可能在多个或所有被测组件中评估结果。
3.2 组件测试目标
组件测试级别的特点是不仅有测试对象的类型和测试环境而且有非常具体的测试目标。
3.3 测试功能
组件测试最重要的任务是检查测试对象是否完全正确地实现了其规范中定义的功能这种测试也被称为 功能测试 或 “功能性测试”。在这种情况下功能等同于测试对象的输入/输出行为。为了检查实现的完整性和正确性该组件要接受一系列的测试案例每个案例都涵盖了输入和输出数据的特定组合。
案例研究 测试VSR-II的价格计算
这种测试输入/输出数据的组合在上例中的测试案例中得到了很好的说明。每个测试用例都输入了特定的价格和特定数量的额外费用。然后测试用例检查测试对象是否计算出正确的总价格。 例如测试用例#2检查 “五个或更多额外项目的折扣”。当测试用例#2被执行时测试对象输出一个不正确的总价格。测试用例#2产生了一个故障表明测试对象没有满足其对这个输入数据组合的指定要求。 组件测试揭示的典型故障是错误的计算或缺失或选择不当的程序路径例如被忽略或错误解释的特殊情况。
四、稳健性测试
软件组件必须与多个相邻的组件进行交互和交换数据不能保证该组件不会被错误地访问和使用即违背其规范。在这种情况下被错误处理的组件不应该简单地停止工作并使系统崩溃而是应该做出 合理 和稳健的反应。因此测试稳健性是组件测试的另一个重要方面。这个过程与普通的功能测试非常相似但是用无效的输入数据而不是有效的数据为被测组件服务。这样的测试案例也被称为 “负面测试”并假设组件将产生合适的异常处理作为输出。如果没有内置足够的异常处理组件可能会产生运行时错误如除以零或空指针访问导致系统崩溃。
案例研究 负面测试
对于我们之前使用的价格计算的例子负测试将涉及到用负的输入值或错误的数据类型例如char而不是int7进行测试
// testcase 20
price calculate_price(-1000.00,0.00,0.00,0,0);
test_ok test_ok (ERR_CODE INVALID_PRICE);...// testcase 30
price calculate_price(abc,0.00,0.00,0,0);
test_ok test_ok (ERR_CODE INVALID_ARGUMENT);各种有趣的事情出现了
除了功能和健壮性组件测试还可以用来检查组件的其他属性这些属性会影响其质量并且只能在更高的测试级别上使用大量的额外工作来测试如果有的话。例如非功能属性 效率 和 可维护性 。
4.1 效率的测试
效率属性表明一个组件与可用的计算资源的交互是多么的经济。这包括诸如内存使用、处理器使用、或执行功能或算法所需的时间等方面。与其他大多数测试目标不同测试对象的效率可以使用合适的测试标准进行精确评估如内存的千字节或以毫秒计算的响应时间。效率测试很少对系统中的所有组件进行测试。它通常只限于那些在需求目录或组件规范中定义了某些效率要求的组件。
例如如果在嵌入式系统中可用的硬件资源有限或者对于必须保证预定的响应时间限制的实时系统。
4.2 测试可维护性
可维护性包含了所有影响增强或扩展程序的容易程度或困难程度的属性。这里的关键因素是开发人员团队需要花费多少精力来掌握现有的程序和它的背景。这对于需要修改他多年前编程的系统的开发者和一个从同事那里接手代码的人来说同样有效。 需要测试的可维护性的主要方面是代码结构、模块化、代码注释、文档的可理解性和最新性等等。
案例分析 难以维护的代码
示例的calculate_price()代码包含许多可维护性问题。例如完全没有代码注释数字常量没有被声明而是硬编码的。例如如果需要修改这样的常量就不清楚在系统中是否需要修改以及在哪里需要修改这就迫使开发者要花大力气去弄清楚。
像可维护性这样的属性当然不能用动态测试来检查见第五章。相反你需要用静态测试和审查会议来分析系统的规范和代码库见第4.3节。然而由于你要检查单个组件的属性这种分析必须在组件测试的范围内进行。
4.3 测试策略
如前所述组件测试是高度面向开发的。测试人员通常可以访问源代码支持组件测试中面向白盒的测试技术。在这里测试人员可以使用组件的内部结构、方法和变量的现有知识来设计测试用例见5.2节。
4.4 白盒测试
在测试执行过程中源代码的可用性也是一个优势因为你可以使用适当的调试工具见第7.1.4节来观察测试过程中变量的行为看看组件的功能是否正常。调试器还可以让你操作组件的内部状态所以在测试健壮性时你可以故意启动异常。
calculate_price()代码包括以下值得测试的语句
满足条件discount addon_discount的额外测试案例很容易从代码中推导出来。但是价格计算规范没有包含相关的信息相应的功能也不是需求的一部分。代码审查可以发现这样的缺陷使你能够检查代码是否正确规范是否需要改变或者是否需要修改代码以适应规范。
然而在许多实际情况下组件测试 只 作为黑盒测试进行–换句话说测试用例不是基于组件的内部结构。软件系统通常由成百上千个单独的构件组成所以分析代码只对选定的组件真正实用。
在集成过程中单个组件越来越多地被组合成更大的单元。这些集成单元可能已经大到无法彻底检查其代码。组件测试是在单个组件上进行还是在更大的单元由多个组件组成上进行这是一个重要的决定必须作为集成和测试计划过程的一部分。
