软件测试实战(微软技术专家经验总结)--前两章(软件测试基础、缺陷报告)读书笔记

前言
一方面,总结了测试专家的见解和方法,将其精华内容综述在本书之中,以帮助读者提高学习效率、快速地掌握综合性技能;另一方面,将经验和反思融入书稿,使它反映出在工作中使用的策略、方法和技巧。总之,这是一本注重实效的书,尝试用理论结合实践的方式来解决现实的问题。
本书的组织方式
第1章阐述对软件测试的 基本观点,介绍测试的 价值观
第2章讨论了测试人员最主要的工作产出-- 缺陷报告,介绍了一批实践方法,帮助测试人员高质量报告缺陷,并利用该过程来改进测试设计。
第3章讨论作为测试辅助工具的 测试文档,介绍了编写和维护文档的原则和方法。
第4章介绍指导测试 设计的模型,通过应用组合测试,阐述了如何根据语境来完善测试模型,然后介绍测试建模的基本原则和常用方法。
第5章介绍一个 测试技术分类系统,以概览各类测试技术。
第6章讨论了 测试开发的基本分类,然后针对自动化测试、计算机辅助测试和大规模自动化测试,阐述了他们的基本概念、设计目标、开发策略和实作方法。
第7章讨论如何从测试视角来 研究软件产品和业务领域,介绍了静态分析、动态分析、关系人研究、需求评审、测试调查、网络调研、领域研究等。
第8章讨论如何从测试视角来 研究项目环境,介绍了团队分析、缺陷分析、源码分析、构建分析、自动化测试分析、基于风险的测试等。
第9章探讨测试人员如何有效地在 团队工作,以及如何恰当地实施 测试管理
第10章分享实施 个人管理的基本方法,包含时间管理、个人学习、经验积累、专业发展等。

第1章 软件测试基础
1.1软件的复杂度已经 超过了人的理解能力
对于复杂的软件,任何人都不可能掌握全部的信息,测试人员应该从各种渠道获取信息, 多角度地研究软件;
软件如此复杂,在项目之初都不甚了解软单件,拟定的测试方案不完善,注重实效的测试人员,会迭代地进行测试, 持续评估反思逐步增强测试方案;
现实世界软件, 穷举测试不可行,任何实用的测试技术都是基于一定策略的采用,测试人员应该 积累多种测试技术, 综合运用他们,并随着项目发展积极 调整
人们处理复杂问题的常用策略是分而治之,软件领域,建立合理的 抽象模型是应对软件复杂性的常见方式,测试领域,可以建立 产品模型来帮助测试;
大规模软件中,少量代码的 变更都不可以掉以轻心,只有运行 大规模的测试,才能保证代码变更的正确性;
单凭人的脑力已经难以应对软件的复杂度了,测试人员需要考虑利用 自动化测试开发强有力的测试策略;
1.2软件测试是获取信息的 技术调查
定义1:测试是为了 发现错误而执行程序的过程。1979年提出,启示:测试人员应该始终质疑并挑战软件;
定义2:测试是一个 获取信息的过程,用来降低决策风险。2008年提出,启示:测试是服务性的工作;低质量的信息不但无助于决策,还可能浪费团队时间,甚至做出错误的决策;团队的决定可能与我的期望不一致,要去理解导致该决定的其它信息;为了更全面地提供信息,除了运行软件,还需要更多的获取信息的方法;除了软件缺陷,测试还可以提供关于项目环境的信息;
定义3:软件测试是一种 技术调查,其目的是向关系人提供有关产品质量的实验信息。2006年提出,启示:测试应该系统地调查被测试对象;测试所提供的信息应该来自科学实验和中立观察;刑侦人员会利用多种方法,从各个信息源收集情报,因为很难预测何处会有重大发现;优秀的潜水员既能够通过浮潜去游历宽阔的水域,也可以利用水肺潜水去探索深海水域;
1.3测试是 迭代过程
测试不是一个线性过程,而是 螺旋向上的:初始的测试提供了正式测试设计所需的信息;正式的测试用例较系统地检查了系统;当正式测试揭示出软件风险时,快速机动地探索相关领域,以确定是否存在严重的问题,并为后续的正式测试提供信息。迭代最大优点就是能够快速获得测试设计的反馈,从而逐步完善测试用例;测试策略在需要保持动态变化。
1.4测试人员的工作效率取决于他对 软件和项目的理解,而不是他掌握的测试技术
产品是一种解决方案,测试人员需要了解软件产品和业务领域,才能设计有效的测试;测试是一种信息服务,要了解服务对象的需求;不同模块采用不同的技术,拥有不同的典型错误;测试设计可能包含错误,吸取经验,不断改进;测试遇到困难,需要知道从哪里寻找信息;人脉有时候极大地提高测试人员的工作效率;测试人员应该养成好的思维方法和测试风格,以便快速地学习并理解产品和项目;
1.5小结
本章介绍了软件测试的基本 价值观
第2章 缺陷报告
缺陷报告是测试人员最主要的工作产出,是测试人员和项目团队广泛联系在一起的纽带。
2.1报告缺陷是为了让缺陷得到 修复
清楚地说明此问题 对用户价值的危害:测试人员在提交缺陷时最好使用自制的缺陷模板(减少工作量,提醒输入必要值);要为使用软件的人仗义执言(代表用户报告反馈问题);要放大格局,软件的关系人还包括程序员、测试人员、运维人员、销售人员等(站在关系人角度,提交缺陷报告);为了提供有说服力的证据,测试人员可能需要做一些研究(调查问题的影响);测试人员还需要找专家支持(对缺陷修复提供帮助);
提供尽可能 多的技术信息,方便程序员调试(应包括 业务层面信息和 技术层面信息,帮助程序员更快修复);
尽早提交缺陷报告(一是 第一时间提交缺陷;二是规划测试时,要使得测试策略能够 尽早发现严重的缺陷);
报告发现的 所有缺陷,即便有些缺陷难以复现(注意重复提交的缺陷、提交不确定且需要深入调查的缺陷、提交难以重现的缺陷);
2.2高质量的缺陷报告来自于 高质量的测试
测试是迭代过程,测试报告是其中重要一环,既是测试的结束,也是测试的开始,让缺陷报告来推动更深入的测试,让高质量的测试产生高质量的缺陷报告。
2.2.1 分配测试时间
提交缺陷时,测试人员常常需要考虑如何使用接下来的测试时间:继续调查当前缺陷,还是开始新的测试,需要测试人员 平衡调查时间和测试时间;继续测试该功能,还是测试其他功能,需要测试人员平衡所提供信息的 深度和广度;测试人员需要合理地分配该资源,以提供足够好的信息。测试人员可以考虑“ 时间盒”来管理自己的时间。总体上,正常的时间盒是为了提供更好的缺陷报告,长时间盒是为了提高测试人员的知识和技能,它简单明了,又不失弹性。
2.2.2通过 技术调查发现更多的信息
做后续测试有两个好处:一是可能会发现 额外的信息,使得缺陷报告更完整;二是可能会发现一些 相似或者相关的缺陷;
后续测试的一个切入点是 评估当前缺陷的 风险(风险暴露的可能性及风险暴露的损失);某些严重的缺陷可能需要更广泛的测试,可以参考James Bach提出的7大产品元素,多角度思考测试覆盖:结构(软件组成的元素)、功能(拥有的功能)、数据(使用的数据)、接口(软件提供的操作界面)、平台(依赖的软硬件环境)、操作(可能的适用方式)、时间(与时间相关的元素);测试人员还可以利用漫游测试、基于典型缺陷的快速测试等,多样化测试获取更多信息,更多地评估缺陷风险。
2.2.3处理 难以重现的缺陷
难以重现的缺陷是测试人员最常遇到的工作挑战之一,需要从多个方面努力应对挑战。
第一、正确地 态度面对缺陷(缺陷可以重现);
第二、应为潜在的缺陷 做好准备,当一个缺陷暴露时,可以收集 更多的信息(有些缺陷没重现,是因为第一次发现时没有记录足够的信息,可以考虑监控工具,挖掘更多诊断信息);
第三、如果第一次收集的信息不能重现或定位缺陷,测试人员需要做 后续测试(可能因为软件不能获得某种操作系统资源;可能软件处于不正确的状态;可能因为操作顺序或时序不正确;可能是因为软件调用的软件或服务返回了不能处理的数据;可能是数据库返回了不能处理的数据;有些软件内建调试辅助功能,启动这些搜集信息);
第四、测试人员应该用 科学实验的策略指导缺陷重现(根据假设或推断);
第五、与软件调试类似,可以 借鉴调试原则和方法(理解系统;制造失败(列举因素);观察先于思考;分而治之(隔离环境,快速测试);一次只做一次修改;保持审计跟踪(记录细节);检查基本假设(质疑假设);获得全新视角(求助他人);如果没有修复它就一直存在);
第六、结束调查后,测试人员需要 提交缺陷报告(注明不能复现;估算重现概率;可能重现的情景;造成的后果;重现缺陷,做了哪些测试及发现;类似缺陷及提供的信息);
2.3编写 高质量的缺陷报告
2.3.1为每一个缺陷 单独提交一份缺陷报告,小缺陷也是如此
避免一份报告中提交了几个缺陷,会导致一些问题(缺陷报告数目少于缺陷数目;缺陷报告中缺陷可能有不同的根源;缺陷报告中的缺陷可能有不同的优先级和严重性;不能很好标识缺陷,可能会被忽略);
2.3.2仔细编写缺陷报告的 标题
阅读报告时,读者总是先读到标题;较好的模式是“条件--失败”
2.3.3像编写详细测试用例那样编写 重现步骤
参照测试用例的编写规则,使得重现步骤尽可能具体、无歧义(测试配置;步骤编号;清楚记录每一步操作;不包含不必要步骤;标明预期结果;标明实际结果;必要时添加附加信息);
2.3.4使用缺陷 模板来提交缺陷
利用模板,提高了编写报告的速度;提醒测试人员报告一些必要的信息;
2.3.5在编写缺陷报告时,要考虑缺陷 查询
查询缺陷是一件常见的任务;
2.3.6 链接相关的缺陷
如果缺陷已经提交,测试人员可以将自己发现的信息补充到已有的缺陷报告中;症状相似的缺陷,可以将他们链接在一起;
2.3.7注意缺陷报告的 可读性
避免错别字和病句;尽量用数字列表记录重现步骤;尽量用符号列表罗列事实;用空行分隔报告的不同部分;屏幕截图、视频录像、内存转储等附件提供更多信息;
2.3.8客观 中立的书写缺陷报告
缺陷报告是对缺陷客观描述,只传递事实,不评价任何人的工作。
2.4对不予修复的缺陷进行 上诉
上诉之前,做一些准备工作(1、可以再做一些测试,研究缺陷的普遍性或严重性;2、改进缺陷报告,强调缺陷普遍性或严重性;3、与缺陷评审小组面对面交流;);缺陷上诉的本质是说服别人采纳自己的建议,可以通过不断积累自己的人脉(持续提交高质量缺陷报告;帮助团队成员,让他人认可的能力和贡献);
2.5周密地 测试缺陷修复
缺陷修复分为两类:普通影响力的缺陷修复;高影响力的缺陷修复。
对于普通的缺陷,测试人员需要尽快完成测试。
可能的测试策略:测试人员可以查看代码的变更集,了解当前设计,从而更有针对性地测试;可以考虑产品元素的7个分类,设计新的用例;对被修改的代码做影响分析,考虑被修代码输入、输出、副作用;考虑哪些功能与被修改功能集成或共享数据;针对缺陷类型做一些有针对性的测试;
对于高影响力的缺陷,需要细致地测试新设计。根据产品成熟度确定测试策略,并动态调整测试活动。
2.6坚持 阅读缺陷报告
测试人员应该持续阅读他人提交的缺陷报告,从而更好地理解项目进展,并激发测试灵感。
每天或每周阅读缺陷报告可以帮助测试人员更好的测试。
了解当前有哪些活跃的缺陷;学习测试技巧,完善测试设计;获得测试灵感;追踪软件设计;总结缺陷模式;
持续回顾缺陷报告能让测试人员更好地理解产品、技术和团队。阅读缺陷报告将成为一项团队学习的活动。
2.7小结
以缺陷报告为中心介绍了一批测试实践,与测试人员的日常工作紧密相关。
1、提交缺陷报告的目的是让正确的缺陷得到修复。
2、为了说服缺陷评审者,测试人员要通过测试去调查缺陷的普遍性(风险的可能性)和严重性(风险的危害性)。
3、为了帮助缺陷修复者,测试人员要通过测试去获得更多的技术信息。
4、测试调查可能需要大量的时间,测试人员可以用时间盒来控制时间。
5、好的缺陷报告是独立的、准确的、便于查询、完整的、易读的、客观的。
6、缺陷上诉的本质是说服别人采纳自己的建议,核心工作是发掘和收集有说服力的证据,并通过交流将证据传递给缺陷评审者。
7、测试人员的人脉来自高质量的缺陷报告、高水准的信息服务和乐于助人的工作态度。
8、测试缺陷修复不要重复已有的测试,应该引入新的测试,在深度和广度上拓展测试设计。
9、定期阅读缺陷报告是一项有益的学习活动,能够帮助测试人员更好地测试。

猜你喜欢

转载自blog.csdn.net/zimingzim/article/details/80158357

相关文章