总结

这本书零零散散的看了一个多月了，整本书都大概的读了一遍，收货还是很大的。虽然这本书的有些知识都已经很古老了，但是里面的经验，精华还是值得我们去吸收，值得推荐！
有机会值得我再次回顾！

按测试员的方式思考

36.不要将试验与测试混淆起来

测试至少要包含以下四中活动：

• 配置：测试环境和发布环境的搭建。
• 运行：与产品进行交互。
• 观察：收集有关产品的行为信息和数据。
• 评估：推理和分析所观察到数据中存在的问题。

47.除非重新发明测试工具，否则不能精通测试

测试专家之路
把东西分解，琢磨其工作原理，再以新的方式组装在一起。不要把自己限制为只是接受智慧的服务者，而应该使自己成为智慧的创造者
。

目前只是学习测试基础知识和了解测试工具，并使用工具。

测试手段

48.五要素测试手段：

1. 测试员：进行测试的人员。
2. 覆盖率：测试了哪些内容。
3. 潜在问题：要测试什么的风险。
4. 活动：如何测试，选择哪种测试策略。
5. 评估：如何判定测试是否通过。

测试过程中要有意识的想到这五要素。

程序错误分析

测试员是要提供信息服务的，不光要填写报告模版，并假设报告能够被完全理解。要了解如何编写和表达自己的测试结果，以便读者能够真正得到结果。我们把这个过程叫做“程序错误分析”

98.不要坚持要求修改所有程序错误，要量力而行。

有时候不修改特定程序的错误是有理由的。最重要的一个理由就是风险。谁也不能保证修改错误后不会产生新的程序错误。特别是在项目快结束的时候，对代码的修改就变得十分的谨慎了。
所以如果不能说明这个程序错误很重要，那么我还是建议把这个错误先挂起来，等下个版本在处理

测试自动化

1.没有好的测试设计的自动化可能会产生大量活动，但是没有什么价值！就是说你自动化测试的时候都是在进行弱测试，设计的自动化只是容易实战自动化而已，这样很难找到真正的问题。
2.没有很好理解自动化可能性的测试设计，可能会低谷一些最有价值的自动化机会。要对真正有价值的地方进行自动化

104.如何选择自动化测试策略:

• 测试需求
• 产品的技术架构
• 测试人员的技能

测试文档

很多测试人员会花费大量的时间去写没有什么价值的测试文档。可是测试文档是要产出有价值的信息才会被信赖。

147.在决定要构建的产品之前先分析需求

需求分析，需求评审过后，就要决定好什么内容要包含到测试文档中，什么内容不包含。

148.如何分析测试文档需求

• 测试小组的使命是什么？产品的目标是什么？
• 需求变更有多频繁？
• 测试结果是要保证与需求说明文档一致，还是以客户要求为主？
• 测试文档及其测试用例的可维护性有多高？能否保证测试用例的变更能够跟上代码的变更？

149.归纳核心文档需求

• 测试文档主要支持我们找出产品版本中的程序错误，指派工作和工作状态。
• 为新的测试小组成员提供培训材料。
• 产品的测试维护。

与研发交互

153.测试员报告问题时要注意以下问题：

• 要干脆的报告问题。准确地描述失效征兆。
• 测将自己的判断建立在产品行为的实际观察基础上。因为测试人员对程序内部并不是很清楚，所以不要猜测内部问题。
• 如果失效是不可重现的，那么要在测试报告中展示自己为了重现失效所进行的各种尝试。
• 不要假装了解自己并不了解的东西。
• 不要夸张错误报告，也不要缩小错误报告。

154.将关注点放在产品上，而不是人上

有些测试员走的太远，以至于认为惩罚程序员犯错误，遗漏截止日期，没有遵循过程要求等，都是自己的工作。这样的想法是糟糕的！
测试员如果发现一些自己感到可能解决不了的问题，单独把证据提供给合适的经理，由经理处理。测试员只做自己份内的事。

管理测试项目

157.测试的角色定位：

测试员的角色究竟是服务还是控制：

• 服务提供者控制他尽更大努力所提供服务的质量和相关性，以取得最终结果。我们向所需要服务的人们提供优质服务
• 服务提供者控制最终产品的质量，控制其他服务提供者所使用过程，有权不批准或拒绝产品的发布。服务提供者不是项目经理，而是要向项目经理提供服务。

159.测试的权利

测试员在公司中的权利建立在自己的调查技能和自如沟通的基础上，而不是命令链上。
测试员必须评估自己公司的文化，要在不被解雇或排斥的限度内发挥作用。在这个限度内，我们建议测试员要成为能够为别人带来价值的守信用，高度正直的信息提供者，以此来施展和扩大自己的影响力。与通过管理渠道，例如有权利拒绝批准产品版本发布相比，通过提供信息能够为自己赢得更大的更实际的影响力。

171.测试拒绝版本的一般原则

一般原则是，如果会使测试工作在不能得到明显收益的情况下效率受到了很大影响，或对某个版本的测试结果会被忽略，则应该拒绝测试该版本。

179.当没有提供规格说明文档的时候，应该充分利用其他信息源。

• 测试用例可以请教市场或开发人员。
• 以前的版本手册
• 已出版的标准与规定
• 错误报告
• 人员面谈
• 描述常见性错误的网站

180.好的测试计划便于后期变更

• 不要在测试之前开发大的测试包，特别是需求变更频繁的时候。
• 不要编写维护成本很高的大量测试文档，例如详细的手工测试脚本。应该是自己的文档尽可能的简洁，明了。
• 不要把手工测试或自动化测试绑到特定的用户界面。
• 通过最大化可维护性和跨平台可移植性来设计自动化测试。
• 需要构建一组能够在不同程序中重复使用的通用测试。节省规划时间。
• 构建一组很强的冒烟测试，快速检测被测试软件中的基本失效。
• 协助并跟进研发开发出大的单元测试包，以及相对简单功能的其他测试。每次重新构建代码时，在提交代码之前研发可以自己进行单元测试。

测试小组的管理

218.积极提供技能

由于技术不断变化，竞争市场的变化，开发工具的变化以及来自方方面面的产品。提高自己的技能会变得越来越困难。

225.不要在项目快完成的时候加入新人。

226.士气也是由测试经理来保证和提高的。

软件测试职业发展

本章讲的是关于职业发展，为找新工作做哪些准备，如何提高自己的工资，比如学习脚本语言，学习高级语言，学习最新的测试工具，提高自己的写作技巧和公众表达能力。

计划测试策略

如何进行整个项目的测试设计

283.运用多样化的测试手段

不太彻底但是更具有多样性的测试策略是更有价值的。

285.项目的初始测试策略总是错的

在项目过程中，要不端优化测试策略

286.在项目的每个阶段，可自问“我现在可以测试什么，能够怎样测试？”

不要认为特定手段只在一定的开发阶段才是有用的。要使自己的测试策略能够抓住更多的机会。在任何时候，测试任何值得测试的东西，使用任何能够最好地满足客户要求的手段。

287.根据产品的成熟度确定测试策略

• 项目初期：浅测试
• 项目中期：积极地更加严格，更加复杂的测试。
• 项目末期：多样地测试。
• 项目最后：谨慎地测试。测试的重点应该更具防御性。要仔细测试每个变更，检查这个版本要交付的所有文件。利用成对测试为每个测试再增加一层保障。

288.利用测试分级简化测试复杂性的讨论

• 0级，冒烟测试，能够进行独立测试的简单测试。
• 1级，能力测试，保证每个函数都能够执行其任务。
• 2级，函数测试，检测每个函数及其子函数是否基本可靠。
• 3级，复合测试，包含多组函数之间交互和控制流，已构成复杂场景的测试。

293.测试周期

测试是按周期进行的，出现下面两种情况的时候就说明这个测试周期结束了。

• 下一个版本完成。
• 确认进一步测试不再有意义。

下面介绍一个大概的测试周期流程：

1. 接受产品。要保证得到的是正确版本。
2. 测试环境的准备。
3. 检验可测性。这个版本值得花时间测试吗？先运行冒烟测试看看，保证这个版本包含了所有主要功能，并且基本上能够操作的简单测试。
4. 确定产品哪些是有改动的。
5. 确定修改了哪些程序错误。还要检查被拒绝的问题，并作出相应的响应。
6. 测试程序错误修改。首先要测试程序的错误修改，快速的反馈给研发。
7. 测试新的或经过变更的部分。新代码的引入是否会引入新的问题。
8. 先测试风险较大的部分，在测试其他部分。
9. 报告测试结果。

以上就是一个完整的测试周期了，当然每个公司具体的流程会有所不同。还介绍了如何制定语境驱动的测试计划思路，测试计划需要考虑到哪些问题。对于这块我吸收的还不够完好。我之前只是执行测试用例，并没有完整的写一份测试计划出来。等好好的吸收，研究下。在从我的角度是如何写测试计划的。