《软件测试实战:微软技术专家经验总结》读书笔记

《软件测试实战:微软技术专家经验总结》读书笔记,第1张

软件测试实战
  • 第一章 软件测试基础
  • 第二章 缺陷报告
  • 第三章 测试文档
  • 第四章 测试建模

第一章 软件测试基础

定义1: 测试是为了发现错误而执行程序的过程
定义2: 测试是一个获取信息的过程,用来降低决策风险

  • 测试是服务性的工作:通过测试,向整个团队提供关于产品质量和项目环境的信息,帮助他们做出决定
  • 团队的决策可能与我的期望不一致,要去理解导致该决定的其他信息
第二章 缺陷报告
  1. 测试人员需要合理地分配时间,以提供“足够好”的信息。


    “足够好”指“有足够的信息可供客户作出好的决策”

  2. 测试人员可用时间盒来管理自己的时间
  3. 关于是否继续测试的问题,也可以采用时间盒来试探
  4. 时间盒是一种常用的时间限制启发式方法(使当前的任务获得稳定的时间,又确保其他有价值的任务不会被长时间延后)
  5. 后续测试的一个切入点是评估当前缺陷的风险


    评估风险要考察两个因素:风险暴露的可能性和风险暴露的损失。


    风险暴露的可能性是要评估风险转变为实际失败的概率。


    测试人员需要评估用户遇到此缺陷的可能性,测试人员的目标是找到最容易暴露缺陷的用户情景。


    风险暴露的损失是要估计失败所造成的损失。


    测试人员需要估计缺陷暴露所带来的最大用户损失。


  6. 测试人员可以参考James Bach提出的7大产品元素:结构、功能、数据、接口、平台、 *** 作、时间。


    结构是软件所拥有的组成元素。


    功能是软件所拥有的功能。


    数据是软件所使用的数据。


    接口是软件所提供的 *** 作界面,如用户界面、系统界面、API、编程平台上的SDK、数据导入和导出功能等。


    平台是软件所依赖的软硬件环境,包括硬件平台、网络环境、 *** 作系统、软件依赖的其他软件和网络服务等。


    *** 作是软件可能的使用方式。


    时间是软件与时间相关的元素。


  7. 对于难以重现的缺陷,测试人员的任务是发现更多的因素,以稳定地重现该缺陷,或以更高的概率重现该缺陷。


    测试过程中,在测试机上安装调试器、抓包软件Fiddler、性能分析工具等。


  8. 难以重现的缺陷与软件调试非常相似,可以借鉴一些调试原则和方法。


    调试专家David J.Agans的9条调试规则

理解系统
制造失败
观察先于思考
分而治之
一次只做一处修改
保持审计跟踪
检查基本假设
获得全新视角
如果你没有修复它,它就一直存在

  • 软件错误可能是因为软件不能获得某种 *** 作系统资源,如内存、文件、网络端口、注册表键值等,也可能是因为它错误地使用了资源
  • 软件错误可能是因为软件处于不正确的状态
  • 软件错误可能是因为 *** 作的顺序或时序不正确
  • 软件错误可能是因为软件所调用的软件或服务返回了它不能处理的数据
  • 软件错误可能是数据库返回了它所不能处理的数据
  • 有些软件内建了一些调试辅助功能,能够提供软件运行的详细信息

缺陷报告

  • 测试人员需要认真编写标题。


    一个较好的模式是“条件?失败“,即阐述在何种情况下软件会发生什么样的失败。


    标题要客观陈述软件所遇到的问题,描述触发问题的情景和问题的症状。


  • 一些字段值:标题、测试配置/前置条件、复现的步骤、预期结果、实际结果、附加信息。


    附加信息可以考虑如下信息:用户影响、重现此缺陷的其他情景、有助于调试的任何信息(运行日志、屏幕截图等)、能否稳定复现、相关缺陷。


  • 在编写缺陷报告时,考虑缺陷查询
  • 注意链接相关的缺陷

测试缺陷修复

  • 该活动体现出软件测试的迭代本质:测试人员总是循环测试软件的版本序列,后续的测试任务基于先前发现的信息(如缺陷报告),而先前测试获得的知识会改进后续测试的测试策略
  • 测试缺陷修复大致分为“测试普通影响力的缺陷修复”和“测试高影响力的缺陷修复”两类


    测试高影响力的缺陷修复例如测试架构级别的改动、测试发布前夕做的缺陷修复、测试已发布产品的布丁等。


    高影响力的缺陷修复参考步骤:同情地测试、积极地测试、多样地测试、严谨地测试

  • 测试缺陷修复不要重复已有的测试,应引入新的测试,在广度和深度上拓展测试设计
第三章 测试文档
  1. 测试计划:记录了指导测试过程的一组想法,概括地论述了产品特性、产品风险、测试任务、测试资源、测试进度、测试团队、团队协作等内容
  2. 测试设计规约:记录了测试策略(一组指导测试设计的想法)和详细测试设计
  3. 测试总结报告:汇报执行了哪些测试、覆盖了哪些功能、获得了哪些信息、以及未来的测试行动等内容
  4. 缺陷报告:也称测试事故报告,记录了测试中发现的软件失败
  5. 测试小组或个人使用的测试文档: *** 作文档、测试笔记、测试资料、移交文档和测试知识库
  6. 利用测试的迭代本质,在每一个迭代中“按需更新”测试文档
  7. 测试计划 是一组指导测试过程的想法。


    制订良好的测试计划需要深入评估项目情况,充分利用测试资源,合理安排测试任务。


    可以按照James Bach提出的启发式测试计划的语境模型。


    启发式测试计划的语境模型的特征是测试计划者通盘考虑产品需求、项目环境、测试小组、测试资源,明确测试任务,并制订相应的测试过程。


启发式测试计划的语境模型要素
需求:包括产品愿景、关系人的期望、质量标准、参考资料等
开发:产品开发的环境,包括被测产品、项目周期、项目管理方法、配置管理制度、缺陷预防手段、开发小组等
测试团队:包括专家经验、工作负载、团队凝聚力、团队动力、领导力、项目协作等
测试实验室:测试小组可使用的软硬件资源,包括测试平台、测试工具、测试程序库、缺陷管理系统、办公设备等
任务:测试小组要提供的服务,可能的选择包括寻找重要的缺陷,评估质量和风险、标准认证、满足过程要求、服务关系人、承担责任、对质量保证提出建议、对测试提出建议、对质量提出建议、最大化效率、最小化开销、最小化时间等
测试过程:完成测试任务所需要执行的活动,其要点是测试策略、保障条件、工作产品

  1. 前Google测试总监James Whittaker的“10分钟测试计划”,其基本思路是专注于核心属性、核心功能和核心能力,省略一切不必要的细节
  2. 评估风险时,可从以下维度考虑:自动化测试用例、手动测试、代码变更、代码复杂度、产品缺陷
  3. 测试人员需要建立产品的大局观,同时掌握产品的优点、缺点、概念模型和实现逻辑
  4. 软件测试人员也应该用 检查列表checklist 来指导并追踪测试工作。


    检查列表针对一项复杂任务,由一组工作事项组成,每一个事项提醒工作者检查一组细节或完成一项活动。


    这些工作事项时完成该任务的必要条件

  5. 测试经理需要评估测试团队的生产力、当前测试的进度、测试覆盖的范围、已经暴露的风险、测试人员是否需要帮助等因素
  6. 对于在何处增加测试设计的深度,考虑最可能发生错误的区域、错误最明显的区域、最常使用的程序区域、最有差别的程序区域即卖点、最难修正的区域、测试人员最理解的区域
  7. 测试人员首先编写一个测试草案,明确任务、策略、保障和产品,并建立起测试设计的框架。


    然后,通过测试迭代增加测试设计的广度和深度,将重要的设计成果和测试发现纳入测试文档集

第四章 测试建模

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/langs/578463.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-04-11
下一篇 2022-04-11

发表评论

登录后才能评论

评论列表(0条)

保存