《领测软件测试网软件测试公开课 观后笔记.doc》由会员分享，可在线阅读，更多相关《领测软件测试网软件测试公开课 观后笔记.doc（8页珍藏版）》请在金锄头文库上搜索。
1、3 领测软件测试网软件测试公开课贺 http:/ http:/ 领测软件测试网 http:/ 领测软件测试论坛 http:/ 软件测试招聘网 http:/ 软件测试服务网 http:/ 软件测试目标的理解/指标： 稳定控制软件产品质量的振幅 高效的提高软件测试用例的覆盖度 典型软件测试过程文档体系结构： 软件测试策略：单元测试阶段、集成测试阶段、系统测试阶段 单元测试计划/集成测试计划/系统测试计划 专项测试方案（手工用例、自动脚本） 测试实施（测试记录、缺陷报告） 阶段报告（测试评估、测试结论） 提高软件测试工作效率： 、 可复用的产品多 无用的工作少 和开发的配合好 测试项目进度贴合度好
2、自动化测试提高效率（指标：测试资源复用率） （指标：有效测试工时率） （指标：协作点数量，协作点正确率） （指标：项目变化率，工期贴合率） （指标：自动化手工测试测试用例率）V 模型：强调测试用例的书写时机，注意对应关系 需求分析，概要设计，详细设计嗦?验收测试，系统测试，集成测试，单元测试 需求分析：用户需求、业务需求、需求规格说明书 概要设计：系统架构、模块划分、模块与模块之间接口和参数传递规则 软件的一般实现过程： 用户要求；用户：我要什么？（理解、表达正确性） 需求说明书；分析员：我可以提供什么？（理解、设计、表达正确性） 设计说明书；设计员：我要让软件做什么？（理解、编码正确性） 源
3、程序；程序员：我要让计算机怎么做（运行、输入正确性） 运行结果；计算机：程序运行得到的结果 软件测试的原则： Good-enough 原则：权衡投入/产出比的原则，测试既不要不充分，也不要过分； Pareto 原则： 分析、 设计、 实验阶段复审和测试 80%bug， 系统软件测试为剩余的 80%bug， 最后 5%bug 为用户大范围、长时间使用后暴露 软件测试的衡量标准： 需求的覆盖（需求追溯表/需求矩阵） 缺陷数量（多、新） 缺陷重现率（BUG 能按照一定的测试过程稳定重现） 效率（平均每人天发现的 BUG 数（5 个/人天） ） 成本（少。合理的测试人力和软、硬件资源安排） 重用价值（
4、测试的数据或者样例可以重用） 质量成本分析：失败 鉴定 POC 销售收入 预防 必要成本 利润 EFCPONC 质量成本 营业成本PONC：不符合要求的代价 POC：符合要求的代价 EFC：无失误运作成本 测试工作无法遍历 黑盒测试： 把测试对象看做一个黑盒子， 测试人员完全不考虑程序内部的逻辑结构和内部特 性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。检查非功能性 需求，是否满足设计要求。理论上，黑盒测试几乎可以发现所有 bug。 测试方法： 是否有不正确或遗漏了的功能？ 数据或者参数传递上：输入能否正确地接受？能否输出正确地结果？ 是否有数据结构错误或外部信息（例如数
5、据文件）访问错误？ 性能上是否能够满足要求？ 是否有初始化或终止性错误？ 白盒测试： 把测试对象看做一个透明的盒子， 它允许测试人员利用程序内部的逻辑结构及有 关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状 态，确定实际的状态是否与预期的状态一致，又称为结构测试或逻辑驱动测试。 灰盒测试：是集成测试，既不要看内部逻辑结构，也不用？ 软件测试的生命周期：单元、集成、系统、用户验收测试。 测试执行步骤：单元、模块（组合测试） 、集成、试车（系统联调） 、系统（全面测试） 、维 护（回归测试） 。软件测试生命周期 开发生命周期 （审查） 需求分析 设计定义 建立 程
6、序编制 建立 建立 修改 测试生命周期 维护测试计划测试设计定制个案测试执行 评估缺陷跟踪软件测试的阶段组成：测试计划、测试设计、测试开发、测试执行、测试评估 完整的测试过程会经历：单元测试、集成测试、系统测试、验收测试（ 、 测试） 、维护 期的测试（小版本发放） 注意： 验收测试是针对项目，给特定客户开发的产品 ； 、 测试是针对产品，给非特定的用户的； 测试针对公司内部的用户； 测试针对公司外部的用户。单元测试、集成测试、系统测试三者区别： 测试类型 单元测试 对象 模块内部的程序 错误 模块间的组装和 调用关系 目的 消除局部模块的 逻辑和功能上的 错误和缺陷 找出与软件设计 相关的程
7、序结 构，模块调用关 系，模块间接口 方面的问题 对整个系统进行 一系列的整体， 有效性测试 测试依据 模块详细设计 （LLD） 测试方法 大量采用白盒测 试方法集成测试概要设计 （HLD） 灰盒测试系统测试整个系统需求规格说明书 （SRS）黑盒测试测试过程输入任务输出项目计划开发文 档，如： SRS、 HLD、 LLD等测试策略制定测试策略 需求跟踪 矩阵测试计划测试计划资源需求测试进度测试用例 测试准备（测 试设计、实 现）代码测试执行测试记录缺陷报告测试报告测试报告单元测试的主要角色：项目经理 PM 审核批准（UT）报告、计划，工具，环境，资源，质 量保证人员 QA，质量协调员 MC，测
8、试监督员，项目组成员，测试策略 单元测试成败因素： 测试意识工具采用 计划制定 测试方法的掌握 标准确定 第三方介入 “别把产品当儿子“ 只有单元测试和集成测试做成并行的，质量才高。集成测试最早开始时间：至少两个模块完 成单元测试 集成策略：主要两种，自顶向下、自底向上，用来确定先做哪个 明确本次测试主要是希望测试哪个模块 这个模块与哪几个模块有最密切关系，可以一二三四按照密切程度排队 把该模块与关系最密切的模块首先集成在一起 这是在考虑这样划分后的外围模块， 这些模块与被及集成模块之间的小溪流是否容易模 块，是否方便控制 一般数据模块、资源模块应该首先集成 集成测试用例设计： 模块的消息借口
9、 模块的功能流程 模块所使用的数据表 模块需要调用到的桩函数 模块对外提供的函数借口 模块的处理性能 集成测试成败因素： 测试意识 工具采用 计划制定 测试方法的掌握 标准确定 第三方介入 集成策略 测试关注点 可测试性设计 立项阶段 测试工作总体 流程图 需求阶段设计阶段编码&单元测试阶段集成测试阶段系统测试阶段验收测试阶段结项总结阶段此图是 V 模型，测试项目细分，测试用例的出现时机注意对应；而瀑布模型则只写测试。需求阶段测试工作流程需求工作培训 编写需求业务，用 户，功能总体测试计划需求评审需求规格说明书系统测试方案需求变更需求跟踪矩阵需求变更记录需求报警需求报警信号进入下一阶段设计&编码阶段测试工作流程上一阶段需求相关文档 需求相关文档 需求相关文档概要设计集成测试方案评审自动测试方案详细设计抽象出验证标准单元测试方案
