技术文章

软件测试级别——需求测试&组件/单元测试

针对不同研发阶段的测试目的,软件测试活动分为需求测试、组件/单元测试、集成测试、系统测试、验收测试、Alpha测试、Beta测试、UAT测试等级别。
5.9.1 需求测试
软件测试双V模型要求测试工程师在需求阶段就开始制定系统测试计划,考虑系统测试方法,但这还不够。全面的质量管理要求在每个阶段都要进行验证和确认的活动。因此在需求阶段,测试工程师还需对需求本身进行测试。这个测试是必要的,因为在许多失败的项目中,70%~85%的返工是由于需求方面的错误所导致。因需求错误导致大量返工,造成进度延迟,缺陷发散甚至项目失败,这是一件极其痛苦的事情。因此测试工程师需在软件生产源头-需求就开始测试。
需求测试(Requirement Test)的重点是检查需求规格说明书中是否存在描述不准确、定义模糊、需求用例不正确、语言存在二义性等问题。主要从以下几个方面考虑。
1、完整性。
每一项需求都必须将所要实现的功能描述清楚,为开发人员设计和实现这些功能提供所有必要的需求依据。
2、正确性。
每一项需求都必须准确地陈述其要开发的功能。
3、一致性。
一致性是指与其他软件需求或高层(系统、业务)需求不相矛盾,或者与项目宣传资料一致。
4、可行性。
每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
5、无二义性。
对所有需求说明书的读者都只能有一个明确统一的解释,由于自然语言极易导致二义性,所以尽量把每项需求用简洁明了的用户语言表达出来。
6、健壮性。
需求说明中是否对可能出现的异常进行了分析,并且对这些异常进行了容错处理。
7、必要性。
必要性可理解为每项需求都是用来授权编写文档的“根源”。要使每项需求都能回溯至某项客户的输入,如需求用例或其他来源。
8、可测试性。
每项需求都能通过设计测试用例或其他的验证方法来进行测试。
9、可修改性。
每项需求只应在软件需求规格说明书中出现一次。这样更改时易于保持一致性。另外,使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。
5.9.2 组件/单元测试
软件系统中,系统对象的基本组成单元称为组件或程序单元。程序代码中的函数或者类称为“单元”,或者实现某个独立需求的功能模块,称为组件/单元。组件可能由多个单元组成。
组件/单元测试(Unit Test)是针对软件基本组成单元(软件设计的最小单位)来进行正确性检验的测试工作,其目的是检测被测组件/单元与详细设计说明书的符合程度。通过组件/单元测试活动验证被测对象的功能特性或非功能性特性,发现其可能存在的内存泄露、算法冗余、分支覆盖率低、循环调用效率低等问题,此类缺陷在系统测试层面很难发现。因此,组件/单元测试能够尽早地发现缺陷,修复缺陷成本相对较低。
组件/单元测试一般由开发人员负责,成本较高。在敏捷研发模型中,测试工程师也可能需要实施此测试活动。组件/单元测试活动亦可以使用自动化测试方法。
组件/单元测试活动依据包括组件/单元需求说明、详细设计文档、被测代码、编程规范等,典型的测试对象一般有组件、函数、类、数据转换/移植程序、数据库模型、关键字典等,关注被测对象内部数据结构、逻辑控制、异常处理等实现的正确性。
【案例5-4 计算器单元测试】
一个计算器软件具有加、减、乘、除4种基本功能,对其实现单元测试,利用Junit单元测试工具实施如下。
计算器功能代码:
软件测试

单元测试代码:
软件测试
测试结果如图5-7所示。
软件测试
图5-7单元测试示例
从上述案例可以看出,除法功能测试失败,期望结果是4,但实际结果为3,查看代码,原因是除法功能代码错误,“a/b”错误写成“a-b”。执行单元测试时,仅关注每个函数或类单元的输入输出,根据预期结果与实际结果的对比,判断被测对象的正确与否。