软件测试实践(二)
A 能有效提高测试效率
B 能够降低测试风险
C 是软件测试过程可持续改进的根本
D 以上全部
A 30%
B 50%
C 80%
D 60%
A 测试策划、测试设计、测试执行、测试总结
B 测试设计、测试策划、测试执行、测试总结
C 测试设计、测试执行、测试总结、测试记录
D 测试策划、测试设计、测试总结、测试记录
A 度量
B 变更
C 可持续改进
D 分析
A 需求理解有误
B 软件变更
C 测试用例不充分
D 数据分析
A 进行系统评测
B 执行测试用例
C 功能验证
D 设计测试大纲
A 选择的测试方法
B 对功能需求的理解程度
C 测试用例设计的完备性
D 测试的时间的长短
A 尽早测试
B 全过程测试
C 尽早测试和全面测试
D 全面测试
A 编写计划
B 配置软、硬件测试环境
C 组织与培训团队
D 以上全部
A 加深测试人员对需求的把握和理解
B 提高需求文档的质量
C 提高测试效率
D 以上全部
A 对软件进行验收测试
B 提高软件产品的稳定性和可靠性
C 减少提交软件系统中的缺陷
D 以上全部
A 一个软件缺陷报告中只应记录一个不可再划分的软件缺陷
B 软件缺陷报告的标题应该能够最简洁表达一个软件缺陷
C 软件缺陷报告中应提供全面的有关该软件缺陷再现的信息
D 同一个软件缺陷可以被重复报告
A 进度
B 方法
C 过程
D 内容
A 独立性
B 迭代性
C 独立与迭代
D 非迭代
A 测试软件系统的哪些模块
B 测试软件系统的哪些指标
C 测试过程何时介入
D 以上全部
A 测试设计的任务是执行测试用例,需要时也可以将测试用例设计与执行并行开展
B 若系统对质量要求很高,则需要开展多次的回归测试验证
C 在实际软件项目中,一个测试团队可能大都是骨干人员
D 测试团队的规模与被测系统规模、测试方资源调配情况有关
A 测试用例的设计
B 测试过程如何控制
C 测试质量如何保证
D 测试任务如何划分
A 1次
B 2次
C n次
D 不一定
A 完全一致
B 基本一致
C 有一定的时间间隔
D 不确定
A 测试设计
B 测试计划
C 测试执行
D 测试总结
A 确定测试范围
B 划分测试任务
C 确定日程表和组织团队
D 以上全部
功能区域 | 功能区域 | 测试人员 | 开发人员 |
安全 | 王军 | 张晓东 | |
工作平台 | 发文 | 李明 | 吕剑秋 |
收文 | 李明 | 吕剑秋 | |
… | … | … | |
归档 | 李明 | 吕剑秋 | |
容量 | 并发用户数 | 周晓松 | 张晓东 |
… | … | … | … |
操作序号 | 操作者 | 执行操作 | 操作后的问题状态 | 测试版本 |
1 | 新建 | |||
2 | 李明 | 检验/再现 | DUCHA1.0_100105 | |
3 | 修复/修复 | DUCHA1.0_100205 | ||
4 | 李明 | 解决/修复 | ||
5 | 打开/再现 | DUCHA1.0_100210 |
功能区域 | 功能区域 | 测试人员 | 开发人员 |
安全 | Test1 | Developerl | |
邮件系统 | 邮件管理 | Test2 | Developer2 |
发邮件 | Test2 | Developer2 | |
… | … | … | |
收邮件 | Test2 | Developer2 | |
性能 | 并发处理能力 | Test5 | Developer3 |
… | … | … | … |
操作序号 | 操作者 | 执行操作 | 操作后的问题状态 | 测试版本 |
1 | 新建 | Lead1.0_090703 | ||
2 | 打开/再现 | |||
3 | 修复/修复 | |||
4 | 打开/修复失败 | Lead1.0_090801 |