研发项目测试基础-《软件测试的经验与教训》学习心得

1、1 12013年2月1日星期五第2页一一二二三三四四五五过 程 管 理过 程 管 理项项 目目 概概 述述 测 试 设 计测 试 设 计测 试 工 具测 试 工 具工 作 产 品工 作 产 品一一概概 述述第3页角度角度关注点关注点内容内容测试方独立性与公正性第一方测试、第二方测试、第三方测试测试员用户测试、测试、强力测试（bug bash）、相关领域的专家测试、结对测试、自用测试覆盖率测试内容功能测试、特性或功能集成测试、菜单浏览、域测试、等价类分析、边界测试、最佳代表测试、输入矩阵、逻辑测试、基于状态的测试、路径测试、语句与分支覆盖率、配置覆盖率、基于规格说明的测试、基于需求的所有测试、组

2、合测试潜在问题测试原因基于风险测试管理确定测试内容，基于风险分析确定测试约束活动测试方法回归测试、脚本测试、冒烟测试、探索式测试、游击式测试、场景测试、安装测试、负载测试、长序列测试（疲劳测试）、性能测试评估准则是否通过基于自校验数据的测试、基于规格说明或文档的测试、基于理念（oracle）的测试第4页类类 目目STET测试与测试用测试与测试用例的关系例的关系测试用例在之前就设计和记录好，过后再测试执行或被其他测试人员执行测试设计和执行时在同一时间完成，而且他们不是必须记录下来，但也有可能与测试执行的与测试执行的关系关系可以控制测试执行可以提升测试设计过程的交互性过程的交互性就像做个已准备好的

3、演讲，由之前想好的想法引导着就像一个对话，是自动向导的第5页探索式测试（探索式测试（exploratory testingexploratory testing） 是一种自由的软件测试风格，强调测试人员同时开展测试学习、测试设计、测试执行和测试结果评估等活动，以持续优化测试工作。 作为一个特定的技术术语，它是由测试专家Cem Kaner博士在1983年提出的，并受到语境驱动的软件测试学派（context driven testing school）的支持。p 是一种软件测试风格（style），而不是一种具体的软件测试技术（如等价类划分、边界值分析、组合测试等）。p 强调独立测试人员（indiv

4、idual tester）的个人自由和责任其目的是为了持续优化其工作的价值（value）。p 探索测试建议在整个项目过程中，将测试相关学习、测试设计、测试执行和测试结果解读作为相互支持的活动，并行地执行。第6页第7页一一二二三三四四五五过 程 管 理过 程 管 理概概 述述测 试 设 计测 试 设 计测 试 工 具测 试 工 具工 作 产 品工 作 产 品二二测 试 设 计测 试 设 计第8页五个圈代表项目具体的资源和约束，中间代表测试团队的选择测试策略。第9页 产生将要测试的产品的系统。如何接收该产品？该产品的可测试性如何？开 发 成功产品的评判准则。该产品的风险是什么？有关质量谁的意见最重

5、要？需 求 能够投入该产品测试的人员。有合适的人选吗？能够及时完成任务吗？测试团队 使测试团队能够完成测试任务的系统、工具和材料。有合适的设备吗？程序错误跟踪系统状态是否良好？测试实验室 测试团队必须按照客户认可的成功标准解决的问题。快速找出重要问题？对质量做出准确评估？任 务第10页基于产品成熟度第11页基于产品成熟度第12页局部测试设计关注点：输入、状态、用户数据、代码路径、执行环境。局部探索式测试法第13页局部测试设计关注点例子：I/O攻击输入。局部探索式测试法第14页p商业区：软件包装盒上描述的那些特性，这里可以用Story法进行区分；p历史区：前一个版本遗留下来的代码、问题或则曾经出

6、现多次缺陷的功能；p旅游区：新特性，老用户一般不会访问；p娱乐区：辅助特性和功能，补充测试计划的充分性；p旅馆区：存储在交互分区中的数据，包含：数据仓库、文件及一切中间介质；p破旧区：一般不会有大的修改或者集成下来后比较平稳的功能片段。全局探索式测试法第15页一一二二三三四四五五过 程 管 理过 程 管 理概概 述述测 试 设 计测 试 设 计测 试 工 具测 试 工 具工 作 产 品工 作 产 品三三测 试 工 具测 试 工 具第16页 可以给测试数据产生、测试执行、状态监视、数据收集、统计分析等带来帮助的各种软硬件、设备等，都是测试人员可以利用的测试工具。例如：p专门测试工具：性能、功能、

7、单元、代码分析、安全等商用和第三方测试软件；信令仪、频谱仪、逻辑分析仪等仪表设备p开发调试工具：IDE、版本比较等软件，仿真器等硬件p被测系统自带的维护管理程序：日志、信令跟踪、动态控制、网管、操作维护设备、特殊诊断和测试模式等p运行平台的监控软件：OS、数据库、web服务器的性能监控、内存监视、磁盘工具等p脚本程序、办公软件：excel、perl、SQL、VBA宏等(数据分析、准备)p画图软件：Mindject、Freemind等软件（测试分析设计）p抓包软件：不同接口协议的抓包和发包；数据包准备p其他软件、设备：秒表、计时软件；录像、鼠标跟踪软件（故障重现）等第17页 目的：更好地完成测试

8、使命。因此，不能代替测试设计，而是提供完成手段、提高工作效率，而不是降低成本 测试自动化：是一种重要投资，类似软件开发过程，测试自动化需要关注成本 长处与限制：与手工测试比较自动化测试的适用场合。不能完全替代手工测试。 自动化测试：a) 数据驱动： 测试输入的只是数据b) 关键字驱动：在数据驱动基础上，输入除数据还有指令 脚本开发注意点a) 测试脚本最好与测试数据分开b) 使用标准脚本语言（如perl、python）第18页可测试性往往是比测试自动化更好地投资！第19页 可测试性是可视性和控制，有助于此的就是可测试性设计。例如：p提供查看源代码及其变更记录p日志p诊断：提供断言，错误警告和调试

9、模式支持p错误模拟：例如提供底层模拟错误状态触发：测试异常等很有用p测试点：系统提供不同的控制点检查和修改数据：各种有用p事件触发器：事件开始和结束时提供通知：性能测试等很有用p数据格式转换：新老版本数据转换，数据格式编解码器：接口测试等很有用p测试接口：例如JTAG等：实时性测试、嵌入式系统等很有用p定制控件支持：私有控件开放给GUI测试工具？：界面测试等很有用p允许多实例：性能测试等很有用第20页一一二二三三四四五五过 程 管 理过 程 管 理概概 述述测 试 设 计测 试 设 计测 试 工 具测 试 工 具工 作 产 品工 作 产 品四四过 程 管 理过 程 管 理第21页PH0 项目准

10、备 PH1 项目方案 PH2 测试设计PH3 测试执行PH4 项目验收立项管理项目计划项目监控 风险管理 需求管理结项管理测试需求分析配置管理 质量保证 外包与采购管理 培训管理 服务与维护项目管理过程项目过程机构支撑过程测试评审测试评审根据项目特征确定最合适的测试模型，以线性顺序为主，以并行、迭代为辅。测试说明测试就绪首轮测试回归测试测评总结评审 其它： 人力资源管理 财务管理 行政管理 市场营销 测评大纲评审回归测试（第n轮）第22页第23页SBTM 2000年，Jonathan Bach和James Bach提出了基于测程的测试管理（Session-Based Test Manageme

11、nt，简称SBTM）。SBTM的重要特征是将过程管理分解为一组测程，从而提高整个测试项目的可说明性。p 主题（主题（CharterCharter）：）：是一个测程需要完成的任务。该任务应该是清晰且具体的，可以在一段时间内完成，并提供有价值的简报。主题通常用一段简练的文字描述，其内容可以是测试一个功能、检查一个风险、测试一组用户情景（User Scenario）等。p 时间盒（时间盒（Time BoxTime Box）：）：是一段不受打扰的测试时间，其长度一般在60120分钟，以90分钟较为常见。p 可评审的结果（可评审的结果（Reviewable ResultsReviewable Resul

12、ts）是测程的产出，常见的形式是测程表（Session Sheet）。p 简报（简报（DebriefingDebriefing）：）：通过面对面的交流将测试情况传递给测试领导。第24页一一二二三三四四五五过 程 管 理过 程 管 理概概 述述测 试 设 计测 试 设 计测 试 工 具测 试 工 具工 作 产 品工 作 产 品五五工 作 产 品工 作 产 品第25页 测试技术文档记录 测试报告 测试方案（测评大纲、测试计划、测试需求） 问题报告 测试说明（测试用例、测试脚本） 测试记录（测试结果、抓包记录、分析截图等） 测试项目质量记录 测试工作总结 测试评审报告 接收单、计划、跟踪表、质量监督表、环境建立、会议纪要等第26页 务必先分析测试文档需求，再编写测试文档。这也同样适用务必先分析测试文档需求，再编写测试文档。这也同样适用于测试中使用的各类模板。于测试中使用的各类模板。 文档编写、维护、交互的工作量可能很大，甚至占大头 根据实际输出文档，不同场合需要的文档类型和数量，文档遵循的模板、格式、内容要求等是不同的。 关键的测试文档 测试报告