编辑推荐
资深软件测试架构师10年测试经验结晶,帮你系统梳理测试技术,建立自己的测试体系,轻松转型测试架构师!
深度解密四步测试策略制定法、四步测试设计制定法、软件质量评估模型、测试方法车轮图,用通俗的语言和取自一线的案例阐述各种测试技术的细节、方法和实践。
随着测试工作经验的不断累积,很多测试者会发现自己逐渐陷入了一个职业发展的“怪圈”——对产品业务已经比较熟悉,基本的测试技术也掌握了,但是不知道接下来该如何深入,如何更好地进行测试。尽管国内不乏软件测试方面的优秀书籍,但是大多数书籍都是在讲测试管理、测试基础或者性能测试、自动化测试等专业测试技术,而描述如何把测试技术和业务结合起来,讲解如何有“策略”地进行“刚刚好”的测试的书籍却几乎没有。
本书作者花费3年业余时间,总结了自己10多年来在确定产品“测试策略”方面的经验,集结成本书。本书系统描述了如何制定“测试策略”,并首次揭秘作者独创的四步测试策略制定法、软件质量评估模型和两份checklist——风险分析checklist和老功能分析checklist,能够帮助读者快速明确测试目标,确定测试重点和难点、测试深度和难度。其中,“软件质量评估模型”能帮助读者在项目中实时评估项目情况,调整测试策略。除此之外,本书还介绍了四步测试设计制定法、测试方法车轮图这两个模型,其能够按照被测对象的特点来提供适合的测试分析和设计方法,使得测试设计有章可循。书中提供的模板、表格还能方便地让“测试设计”符合“测试策略”,满足测试的深度和广度,可以让整个测试团队有序、系统、全面地进行测试设计。
本书很注重理论和实践的结合,书中总结的各种方法均能够直接应用到测试项目中。作者已将这套方法开发成了相关课程,并在现在任职的公司的各个研发中心巡讲、推广,取得了非常好的效果。
对于所有从事或者欲从事测试类相关工作的读者来说,这是一本不容错过的好书!
内容简介
本书并不是一本单纯讲述测试技术或测试管理的书籍。“测试策略”是本书的核心,本书通过大量策略把测试理念和各种测试技术串了起来,并讨论了该如何把测试技术和产品结合起来,如何确定测试目标、测试范围、测试的深度和广度、测试的重点和难点。旨在帮助广大奋斗在一线的测试工程师们系统梳理自己的测试技术并构建自己的测试体系,迅速升级为测试架构师!
本书的核心内容可以概括为“4个模型”和“2份checklist”,其中4个模型是四步测试策略制定法、软件质量评估模型、四步测试设计制定法、测试方法车轮图,2份checklist指风险分析checklist和老功能分析checklist。这些内容不仅能够直接运用到实际的产品测试中,还可以帮助我们系统思考,梳理自身的测试技术,找到自己的知识短板,突破瓶颈。
本书一共8章,分为三大部分,组织上,我们不是从技术的角度来展开的,而是以“软件测试架构师”来作为全书的主线。
本书先从中国的软件测试行业现状入手,帮助大家分析自身的瓶颈(第1~2章),为软件测试者的职业规划提供建议——如果想在测试技术上进一步发展,可以将软件测试架构师作为职业发展的目标,并讨论作为软件测试架构师在测试过程中需要关注和不需要关注的内容。
接下来(第3~5章)深入讲解了软件测试架构师需要掌握的基本测试技术和实用的软能力,包括软件质量模型、测试类型、测试方法、测试设计、探索式测试、自动化测试、沟通和协商以及写好测试用例的表达技法,帮读者向软件测试架构师的目标快速前进。
最后(第6~8章)详细介绍了软件测试架构师的核心技能——测试策略该如何去分解和制定,在产品测试中如何评估产品质量并根据质量评估情况来修正测试策略,最后达到理想的测试目标,帮助读者在软件测试架构师的道路上进行自我修炼。
书中还包含了大量对各种测试技术的总结,这些不仅可以直接运用在实际测试项目中,还可以帮助读者梳理自己掌握的测试知识,建立自己的测试体系。
作者简介
刘琛梅,资深测试者,从事软件测试工作10年,现就职于北京神州绿盟科技有限公司,曾就职于华为(华赛),主要从事安全产品的测试工作。在华为深圳研发中心工作期间担任测试经理、软件测试架构师,目前担任绿盟科技下一代防火墙产品测试代表,对各种测试技术,安全业务均有系统深入的研究。
目录
前 言
第一部分 瓶颈:软件测试工程师该如何进行职业规划
第1章 软件测试工程师的“三年之痒” 3
1.1 软件测试发展简史 3
1.2 中国的软件测试行业 4
1.2.1 软件测试整体起点较高 4
1.2.2 软件测试的困境和迷局 5
1.2.3 迷茫的软件测试工程师 7
1.3 认识软件测试的优势和劣势 9
1.3.1 软件测试的优势 9
1.3.2 软件测试的劣势 10
第2章 软件测试工程师的职业规划 12
2.1 软件测试的职业发展方向 13
2.1.1 软件测试在管理上的发展 13
2.1.2 软件测试在技术上的发展 14
2.1.3 “角色”和“段位” 16
2.1.4 软件测试在质量领域的发展 18
2.2 软件测试工程师职业规划建议 20
2.2.1 做管理还是做技术 20
2.2.2 对测试工作“跳槽”的建议 22
2.2.3 软件测试创业 23
第二部分 突破:向软件测试架构师的目标迈进
第3章 软件测试架构师应该做和不该做的事情 29
3.1 软件测试架构师需要关注和不需要关注的事情 29
3.1.1 测试架构师在需求分析中 30
3.1.2 测试架构师在测试分析和设计中 32
3.1.3 测试架构师在测试执行中 34
3.1.4 测试架构师在测试质量评估中 35
3.2 像软件测试架构师一样的思考 36
3.3 软件测试经理可以替代软件测试架构师吗 36
3.4 系统架构师可以替代软件测试架构师吗 38
第4章 软件测试架构师的知识能力模型 40
4.1 软件产品质量模型 41
4.1.1 软件产品质量六属性 41
4.1.2 功能性 43
4.1.3 可靠性 45
4.1.4 易用性 46
4.1.5 效率 49
4.1.6 可维护性 50
4.1.7 可移植性 51
4.2 测试类型 52
4.3 测试方法 54
4.3.1 产品测试车轮图 54
4.3.2 功能测试方法 55
4.3.3 可靠性测试方法 61
4.3.4 性能测试方法 68
4.3.5 易用性测试法 72
4.4 测试设计技术 74
4.4.1 测试点不等于测试用例 75
4.4.2 四步测试设计法 77
4.4.3 对测试点进行分类 79
4.4.4 流程类测试设计:路径分析法 84
4.4.5 参数类测试设计:“输入—输出表”分析法 96
4.4.6 数据类测试设计:等价类和边界值分析法 102
4.4.7 组合类测试设计:正交分析法 107
4.4.8 控制用例粒度:测试点的组合和拆分 111
4.4.9 错误推断法 116
4.5 探索式测试 117
4.5.1 探索式测试的基本思想:CPIE 117
4.5.2 选择合适的探索式测试方法 118
4.5.3 开展探索式测试 121
4.6 自动化测试 124
4.6.1 需要知道的一些自动化测试真相 124
4.6.2 如何评估自动化的收益 126
4.6.3 自动化测试工具介绍 127
第5章 软件测试架构师的软能力修炼 130
5.1 沟通和协商 131
5.1.1 产品测试中的沟通原则 131
5.1.2 通过沟通来获得对产品测试有用的信息 134
5.1.3 和测试团队成员沟通 136
5.1.4 和领导或投资决策者沟通 140
5.2 写出漂亮的测试用例 141
5.2.1 测试用例模板 141
5.2.2 测试用例标题要是一个完整的句子 142
5.2.3 用条件而不是参数来描述测试用例标题 143
5.2.4 如果一个用例中包含有多个参数,用例中应该是每个参数的取值 145
5.2.5 不要在测试用例中引用别的测试用例 147
5.2.6 避免测试用例中包含过多的用户接口细节 149
5.2.7 明确测试步骤和预期结果的对应关系 150
5.2.8 避免在测试步骤中使用笼统的词 151
第三部分 修炼:软件测试架构师的核心技能
第6章 如何才能制定好测试策略 155
6.1 理解测试策略 155
6.2 四步测试策略制定法 159
6.3 产品质量评估模型 165
6.3.1 优秀的产品质量评估模型的特征 165
6.3.2 软件产品质量评估模型 167
6.4 测试覆盖度评估 167
6.4.1 需求覆盖度评估 168
6.4.2 路径覆盖度评估 170
6.5 测试过程评估 171
6.5.1 测试用例评估 171
6.5.2 测试方法分析 173
6.5.3 测试投入分析 174
6.6 缺陷分析 174
6.6.1 缺陷密度 174
6.6.2 缺陷修复率 176
6.6.3 缺陷趋势分析 177
6.6.4 缺陷年龄分析 183
6.6.5 缺陷触发因素分析 188
6.6.6 组合使用各种缺陷分析技术 190
6.7 风险分析技术 191
6.7.1 风险分析 192
6.7.2 风险应对 196
6.7.3 老功能分析 198
6.8 分层测试技术 201
6.8.1 V模型 201
6.8.2 设计测试层次 201
第7章 测试策略实战攻略 204
7.1 开始 204
7.2 初次使用“四步测试策略制定法” 205
7.2.1 产品质量等级 205
7.2.2 确定项目中各个特性的质量等级 206
7.2.3 对项目整体进行风险分析 206
7.2.4 确定测试策略的结构 207
7.2.5 初步确定测试分层 208
7.2.6 回顾 209
7.3 制定总体测试策略 211
7.3.1 分解产品质量目标 211
7.3.2 使用老功能分析法来对特性进行分类 214
7.3.3 基于质量和风险来确定测试深度与测试广度 215
7.3.4 确定测试优先级 218
7.3.5 确定测试的总体框架 219
7.3.6 回顾 220
7.4 制定阶段测试策略 222
7.4.1 测试设计策略 223
7.4.2 集成测试策略 230
7.4.3 系统测试策略 234
7.4.4 验收测试策略 236
7.4.5 回顾 238
第8章 版本测试策略和产品质量评估 240
8.1 开始 240
8.2 第一个版本测试策略 243
8.2.1 测试范围以及和计划相比的偏差 243
8.2.2 本版本的测试目标 244
8.2.3 需要重点关注的内容 245
8.2.4 测试用例的选择 246
8.2.5 测试执行顺序 247
8.2.6 试探性的测试策略——需要大家分工合作的地方 248
8.2.7 接收测试策略 249
8.2.8 回顾 250
8.3 跟踪测试执行 251
8.3.1 跟踪测试用例执行情况 251
8.3.2 每日缺陷跟踪 256
8.3.3 调整测试策略 262
8.4 版本质量评估 264
8.4.1 使用软件产品质量评估模型来进行质量评估 265
8.4.2 版本质量评估中的缺陷分析 271
8.4.3 调整测试策略 273
8.4.4 建立特性版本质量档案 274
8.5 后面的版本测试策略 274
8.5.1 回归测试策略 275
8.5.2 探索式测试策略 280
8.5.3 自动化测试策略 283
8.5.4 回顾 286
8.6 阶段质量评估(包括发布质量评估) 287
8.6.1 阶段质量评估项目 288
8.6.2 非测试用例发现缺陷的原因分析 293
8.6.3 组合缺陷分析 295
8.6.4 遗留缺陷分析 297
8.6.5 临近发布时的缺陷修复策略 299
8.6.6 非必然重现bug的处理 299
8.6.7 总结 299
前言/序言
Preface前言 为什么写这本书先讲两个故事吧。 一次我面试了一位有8年名企测试经验的候选者。面试中,我能感受到他对他现在做的业务很熟悉,但他熟悉的这些业务和他现在申请的职位中涉及的业务相差甚远,于是我就问了个问题:“如果我们有幸能够邀请到您加入我们的团队,您可以给我们团队带来些什么呢?”这位候选者竟然语塞——尽管他拥有8年的测试经验,但是除了业务知识,对测试本身,他却几乎没有任何思考和总结。一旦离开了熟悉的业务领域,他就又回到了“新人”的状态,之前的经验很难复用,需要重新积累。 不过这件事情更触动我的是在面试结束后和我一起面试的另一位面试官(这是一场“二对一”的面试)的话,她说她感到有点害怕,害怕8年后她也会陷入这位面试者这样的状况……第二个故事也是面试中的故事。一位有4年名企测试工作经验的候选者,已经开始在大公司里面做测试管理了。我们谈到了对测试技术的理解,他开始谈当前公司的流程,谈得很好。我接着他的话题,提了个问题:“您会在什么时候、从哪些角度去识别测试项目中的风险?以及如何处理这些风险?”这位候选者的答案是:“我们的风险就是项目延期,其他没有风险,流程上写得很清楚什么时候要识别风险,到了那个时候我们就把这个问题提出来,发邮件给大家,包括各个领导,请他们来解决。因为这个问题我们也解决不了。”显然,他一直在被所谓的厉害的“流程”牵着鼻子走,流程中蕴藏的测试理念、方法和实际工作已经无法落地了。 这两个故事,引出了一个值得我们思考的问题:什么是测试的核心?作为测试人员,掌握“业务知识”是必须的,但是“业务知识”并不能和“测试能力”画等号。“测试流程”或者说“测试管理”对测试来说很重要,但是否只要严格遵循它们就能做好测试了?如果上述答案是否定的,那么什么才是测试的核心?我们又该如何去积累沉淀这方面的技能?这就是我写这本书的初衷——想和大家来分享我对“测试核心”的思考,分享这其中的技术总结。 1.测试的核心是什么?我认为测试的核心不是业务、测试方法、测试设计、自动化、测试管理、测试流程等,而是“测试策略”。 我们该如何理解测试策略呢?测试策略通俗来说就是“测什么”和“怎么测”,大致包含了如下内容: 测试的对象和范围是什么?测试的目标是什么?测试的重点和难点是什么?测试的深度和广度如何?如何安排各种测试活动?(先测试什么,再测试什么)如何评价测试的效果?这就需要我们基于“产品的质量目标”,基于“风险”,在充分考虑“产品研发状况”的前提下来安排各种测试活动,在有限的时间里进行“刚刚好”的测试。这也正是本书想要讨论的主要内容。 2.这本书的价值是什么?本书讨论的主要内容是“测试策略”,虽然现在已经有很多优秀的测试类书籍,但是讨论测试策略方面的书籍却比较少,本书可以为读者在测试策略的制定上提供很有价值的参考。 本书也讨论了测试设计、测试方法、缺陷分析、质量评估等大家熟悉的测试技术,本书还使用了大量的篇幅来讨论如何在工作中使用这些技术,制定出如何适应实际情况的策略,来使测试更为有效。 另外本书还提供了一些有很强实用性的模型模板和checklist,读者可以直接在产品中使用。 本书的主要内容本书以“软件测试架构师”为线索,分为三个部分。 第一部分,瓶颈:软件测试工程师该如何进行职业规划。从当前软件测试行业的普遍困惑入手,对中国的软件测试行业、软件测试职业现状进行分析,给出软件测试的职业规划建议。特别指明了软件测试工程师在技术上的发展方向——软件测试架构师。为软件测试架构师画像,讨论作为软件测试架构师在测试过程中需要关注和不需要关注的内容。 第二部分,突破:向软件测试架构师的目标迈进。这部分又可以分为两部分,即软件测试架构师需要掌握的基本测试技术和软能力。 其中需要掌握的基本测试技术包括: 软件产品和质量模型测试类型测试方法测试设计探索式测试自动化测试软能力包括: 沟通和协商写好测试用例的技法第三部分,修炼:软件测试架构师的核心技能。在这一部分,我们首先介绍了与测试策略相关的技术: 四步测试策略制定法产品质量评估模型测试覆盖度评估测试过程评估缺陷分析技术风险分析技术分层测试技术然后具体讲解,如何运用这些测试策略编写技术和基本测试技术,包括我们的测试软技能,来制定总体测试策略、阶段测试策略;如何制定版本测试策略和对产品质量进行评估,以及在质量评估中发现问题时,该如何修正测试策略。 本书的核心思想中国软件测试行业整体起点较高,但对软件测试却普遍缺乏理解和认识。认为软件测试没有或者缺乏技术含量的居多,其中不乏领导或决策者。 软件测试在技术上可以向软件测试架构师发展,成为产品测试专家。软件测试架构师是产品测试的灵魂。 软件测试架构师需要像系统架构师一样理解产品的商业目标和用户的使用场景,要从整体上来把握测试节奏,为团队的关键测试活动(如测试设计、测试执行)提供辅导。要保证测试策略能够在整个团队中落地,而不是自己挽着袖子上。 软件产品质量模型是测试的基础。测试类型、测试方法都是在此基础上衍生出来的。 测试点不等于测试用例。测试点通过测试设计来得到测试用例。 软件测试架构师虽然是测试团队的技术官,但是也不应该忽视沟通协商和文档写作方面的能力。 测试策略是测试的核心。 测试应该基于质量目标、基于风险,围绕研发流程,通过分层来进行“刚刚好”的测试。 本书的独特之处目前已经有很多优秀的软件测试书籍,其中不乏精品,但是我发现这些书籍大多只是单方面地讲授软件测试理念和基础,或是单方面地讲授某种测试技术。本书则规避了这一点,并不单方面讲授理念或技术,而是通过“测试策略”把理念和技术串起来了,教大家该如何来确定测试目标,确定测试范围,确定测试深度和广度、重点和难点……你可以很容易将书中的内容运用到实际工作中去。 本书的另外一个特点是书中使用了5个高度概括模型:四步测试策略制定法、软件质量评估模型、四步测试设计制定法、测试方法车轮图和两份checklist(风险分析checklist和老功能分析checklist)。有了这套模型工具,我们就可以对软件测试工作进行系统思考了,这样有利于我们对自己的工作进行总结,突破“瓶颈”。 不同于一般的测试书籍,本书在行文安排和编写视角上也别具特色:从测试的职业发展规划入手,为软件测试架构师画像,为测试者指出测试技术上的奋斗方向;然后介绍软件测试架构师需要掌握的测试技术(除了我们熟悉的测试设计技术、缺陷分析技术外,本书还特别编写了沟通交流、文档编写等软技能);最后介绍如何使用这些技术来编写测试策略,在整个测试过程中需要设计、安排哪些测试活动以进行“刚刚好”的测试。可见本书并不是以技术为主线来编写的,而是围绕“软件测试架构师”,即“人”来展开的,我希望这样的设计能够让读者在阅读本书的时候感到更为生动和实用。 本书适合谁看本书比较适合有一定经验的软件测试工程师,以及希望在测试技术上有所发展的测试人员阅读。 当然,如果您是一位初涉测试的朋友,本书在测试职业规划方面的描述、测试技术方面的总结和叙述对您来说也会是不错的参考。 如何使用本书如果您是一位有一定测试经验的软件测试工程师,目前感到在测试技术或测试发展中出现了“天花板”,有些迷茫,那么本书就再适合您不过了。建议您不要跳过一些章节,而是按顺序阅读,相信本书一定能帮您答疑解惑,使您找到自己新的
测试架构师修炼之道:从测试工程师到测试架构师 电子书 下载 mobi epub pdf txt