ISS-嵌入式事业部Mini培训.pptVIP

2006-6-1 软通动力 * UT出/入口条件 入口条件： 软件的代码通过评审和编译检查 操作过程： 开发/测试人员根据单元测试计划，以函数为基本单位进行测试，验证函数的功能以及健壮性，然后将测试结果形成单元测试报告，并将错误纪录在单元测试错误报告中 出口条件： 函数功能正确，且测试用例的覆盖率满足要求 2006-6-1 软通动力 * 单元测试用例 用例设计思路： 设计一个最简单的用例使被测单元运行起来(测试执行时一般按顺序执行用例) 使用黑盒测试的方法设计测试用例 使用白盒测试的方法补充测试用例 ※单元测试保证代码质量，覆盖率保证单元测试质量 2006-6-1 软通动力 * 覆盖率 分支覆盖率： 程序的每一个分支的是和否两种情况的覆盖率 条件覆盖率： 判定条件的满足和不满足以及边界值的覆盖率 语句覆盖率： 程序的执行语句的覆盖率 循环覆盖率： 循环条件满足和不满足以及其边界值的覆盖率 2006-6-1 软通动力 * 测试桩和驱动 桩 stub： 由于单元测试是以函数为单元的，为了使函数能够编译并连接成可执行程序，必须提供由被测试函数调用的外部函数的实现，这些外部函数的实现称为桩 驱动 driver： 为了满足覆盖率，需要编写代码来设定不同的条件并调用被测试的函数，这些代码称为驱动 2006-6-1 软通动力 * UT注意事项 单元测试是为了发现问题而不是为了证明代码没有问题，因此应该尽可能的考虑实际运行中可能发生的情况。 单元测试的主要目的是为了验证函数的功能，因此不能片面的只追求覆盖率，更应该注意的是函数的功能是否正确 2006-6-1 软通动力 * 集成测试 内容： 模块的组合、接口测试 关注点： 集成后的模块组件功能、性能 全局变量 模块间的函数接口 模块间的消息接口 2006-6-1 软通动力 * IT出/入口条件 入口条件： 代码通过单元测试 操作过程： 开发/测试人员根据集成测试计划，以接口函数为基本单位进行测试，验证模块的功能以及健壮性，然后将测试结果形成集成测试报告，并将错误纪录在集成测试错误报告中 出口条件： 接口函数功能正确，模块功能正确，而且测试用例的覆盖率满足要求 2006-6-1 软通动力 * 系统测试 内容： 需求的功能测试 关注点： 系统的功能正确性、完备性 性能目标实现的可靠性、可维护性、可操作性 2006-6-1 软通动力 * ST出/入口条件 入口条件： 代码通过单元测试和集成测试，并且系统集成编译并连接通过 操作过程： 开发/测试人员根据系统测试计划，在实际的系统运行环境中，验证软件的功能 出口条件： 软件功能验证通过 2006-6-1 软通动力 * 回归测试策略 测试活动 回归测试策略 单元测试 以函数为单位，测试上一轮未通过测试的函数的所有单元测试用例 集成测试 以功能模块为单位，测试上一轮未通过测试的模块的所有集成测试用例 系统测试 测试所有系统测试用例 验收测试 测试所有系统测试用例、验收测试用例、性能测试、压力测试 2006-6-1 软通动力 * 测试计划 资源需求 软件资源、硬件资源、人员需求、其他设备 过程条件 启动条件、结束条件、挂起条件、恢复条件 进度计划 培训计划 2006-6-1 软通动力 * 测试用例设计方法 边界值分析法 略小于最小、最小、中间、最大、略大于最大。可以在一个用例中对这五种情况进行说明 错误猜测法 凭经验猜测某种情况下很容易出错，特设计一个用例进行测试，检验其结果是否正确。比如空指针的测试，大家经常认为此处不会出现空指针，所以没有进行判断 等价类划分法 比如一个简单Case语句的多个分支可以只设计一个用例，但是测试代码需要进行分支覆盖 2006-6-1 软通动力 * 测试步骤 1. 计划： PPL中的测试策略，各阶段测试计划及用例 2. 准备： 设备、软件、人力等资料的准备，测试环境的搭建 3. 执行： 记录测试结果，修改缺陷后验证、回归测试 4. 报告： 生成测试报告，提交TC审批 2006-6-1 软通动力 * 用例常见问题 不考虑异常测试，只考虑功能测试 用例设计重点不突出，数量多但效果差，许多用例非常相似，完全可以放在一个设计用例中，多分支进行测试 未考虑压力测试、可靠性测试等 自动化程度不高，测试周期过长 2006-6-1 软通动力 * 测试常见问题 修改缺陷后没有及时做PcLint检查，存在引入新Bug的风险 增加用例但没有更新测试用例文档 对问题重要程度没有清晰的概念 问题重要程度 ＝ 严重级别 * 出现概率 严重级别：