微软软件测试自动化.pptVIP

微软软件测试自动化 张金荣 重庆理工大学 软件工程系 提要 微软的软件测试 一个完善的自动化测试系统 自动测试用例设计要点 测试用例的管理和运行控制 提高软件测试自动化的步骤 测试自动化误区和风险 什么是软件测试？--两种经典理念 验证软件是“工作的” 代表人物是软件测试领域的先驱Dr. Bill Hetzel（代表论著《The Complete Guide to Software Testing》） 主流和行业标准 微软软件测试活动的基础和主要线索 证明软件是“不工作的” 代表人物是Glenford J. Myers（代表论著《The Art of Software Testing》） 一个成功的测试必须是发现Bug的测试，不然就没有价值 微软也阶段性地进行这类测试活动 (Bug Bash) 什么是微软的软件测试 是软件开发的依赖 每日建造+自动化测试 开发人员依赖测试来保证开发工作的质量，使开发整体地协调地向前推进 是项目管理的基础 软件项目管理的主要线索就是Bug的管理 软件测试的结果是项管理和决策的主要依据 一个完善的自动化测试体系 自动测流程 实例 自动化测试的核心—测试代码 自动测试程序设计要点 对前提条件进行验证 能处理各种可能的意外，并对有关设置进行彻底清除，以不影响后续测试用例的运行 各测试用例有相对独立性，不相互依赖，便于进行各种运行组合 有好的日志 设计简洁，代码可读性高 易于运行 稳定性重于性能 具有一定的灵活性，能快速适应产品功能设计的更改 测试用例的分级，及运行频度 测试用例管理 测试用例—最小的设置单元 测试用例组合—一系列的测试用例，可以包含其他测试用例组合。是可运行和报告的基本单元 测试报告 高级自动化的关键--硬件的管理 实验室，自动测试机器池 动态的选用测试机器 自动安装测试平台 监控机器工作状态 支持测试工具，进行多机协同运行 测试自动化的发展阶段与计划 测试自动化的风险 代价高，所以要根据项目的特点，团队技术水平确定适当的自动化率 测试覆盖偏向易于自动化的功能。要进行代码覆盖率的度量 错误的测试设计可能使测试情境与用户使用情境相背离 忽视第二类以搜寻缺损为目的的探索性测试 工具的选用不当，过多过杂，频繁更换。 产品的可测性低 参考资料 微软的软件测试方法/forums/8172/ShowPost.aspx 开发环境 开发语言，库程序， 驱动程序，开发工具 测试用例管理 测试用例的定义， 设置，分类 和组合运行 分析报告 单运行结果报告， 多运行综合报告， 长期走势报告 运行环境 机器池，自动安装 和配置, 运行 代码管理 存储，编译 硬件，基础设施 实验室，机器，网络…… 根据需要 每周 隔日 每日 运行频度 压力，性能，安全性…… 所有出错情形下的代码路径 所有非出错情形下的代码路径 最简单的功能验证 定义 高级 第二级 第一级 BVT 注：BVT 是Build Verification Test的缩写 培训和引进测试设计和架构人才 进一步提高实验室系统 建立流程模型和商业服务模型 培训和引进高级编码人才 由开发人员帮助设计测试代码库 系统的选择使用和整合各种工具 培训和引进机算计软件专业人才 尝试测试工具 建立实验室 培训和引进人才 计划和措施 有高水平的测试开发人员，测试架构师 有高度自动化的实验室系统，和专业的系统管理队伍 有完善的自动化测试流程 能对外提供自动测试的商业服务 大量测试用例全部自动化 有自己开发的共用代码库 有测试用例自动运行系统，并与产品建造系统项结合 有测试报告和统计分析服务 有部分测试用例全部自动化 有机算计软件专业人员从事测试代码的开发，使用Java，C#语言 使用工具和专门的实验室测试环境 有脚本文件驱动的半自动测试 无机算计软件专业人员从事测试 无工具，无实验室 无自动测试用例，测试工作全部手工操作 非专业人员从事测试 特征 自动测试高级阶段 自动测试成熟阶段 自动测试发展阶段 自动测试初始阶段 无自动测试阶段 * *