google软件测试之道读后感（二）

这几天又翻了几页这本书，觉得妙语连珠，关键语录摘抄如下，并补充自己的一些思考：

“如果你想要求一个团队去尝试新的事物或者做某些改进，给他们提供一个联系人会更好一些，这个联系人来源于更大的社区，并可以从他那里得到帮助”；

“不要陷入尝试去创建一个包含独立指标的完美系统的陷阱中。对所有人都完美的事情是不存在的。在没有可替代的方案时，在合理的地方达成一致并勇往直前是很重要的。需要灵活的时候就灵活一些，但一定要坚持你的原则底线”。

当考虑团队建设方面时，在以前总是收获理想很丰满，现实很骨感的局面，最后总是不了了之的结局。这比没开展还坏，因为会打击团队的积极性，忙乱一顿，却看不到明显的产出，而且有很强的受挫感。这里提到要有一个指导者，而且最好有一个这样的联盟，大家一起来做这件事情，形成一种社区的氛围，那事情的成功性会较大。而且，做事情，不要太过死板，既然是尝试，就没有板上钉钉的事情，一直强调考核和目标，这样的行政指标会让人反感和排斥。适当的转弯，可以让团队走的更远。

“专注于你的用户，理解他们的需求并解决他们的问题。”

“缺陷驱动开发，一旦用户发现了一个bug，我就立刻去修复它，然后再宣布它没有问题了，更加完美无瑕”。

产品的最终目标，是满足用户的需求，无论是真实功能上的需求，还是用户无法提出来的隐形需求。要做到缺陷驱动开发，当然不能把缺陷都放到市场上等待用户发现，而是在实验室内多次迭代，多次从用户角度去试用，通过快速的迭代，持续的集成来实现。这是敏捷的思想，我想到了今天，世界上测试技术那样多，但有一点是不变的，那就是要快。只有测试足够的快，能快速执行，快速出结果，快速评估，才能提高生产力和效率。

“试验性工作、尚无明确目标或用户故事的早期产品，TE很少参与，甚至不参与。”

“过度早期地投入测试意味着资源上的浪费，尤其是在SET已经深度介入的时候”

“以策略上将，给一个项目配备多少测试人员，取决于项目风险和投资回报率”

”TE擅长发现需求中的模糊之处，分析沟通不明确的问题“

”一旦找到薄弱点，TE就会通过测试使软件出错，然后与开发、产品、SET一起推动解决这些bug“

”如果做测试计划已经来不及了，那就干脆不做了。如果一个项目最需要的是测试，那就做一个简单够用的指导性计划，一些测试教条所倡导的从头就介入的模式，在google并不适用。“

google一直在强调，传统的测试模式在快速迭代的今天已经有些跟不上了，至少从我工作的经验来看，确实是这样。测试跟不上研发的进度，研发抱怨测试拖了项目的后腿。测试什么时候介入，也无需一味按照传统的开发模型来生搬硬套。但是这里提到的测试指的是系统测试，而其他的测试，例如单元测试、集成测试，以及测试脚本的开发和维护，则是在项目之初就开始了。测试的角色是更加全方位的，测试是真正意义上的测试开发工程师，产生的测试代码和产品功能代码一样属于产品功能完整性的一部分。这其实给测试提出了更大的要求和期待，既要熟悉测试方法，兼具用户视角，又要有很强的编程能力，是真正意义上的开发工程师。google内部对测试工程师的角色划分也非常细致，可以看出是真正重视人员培养的。越发觉得，别人是真正讲求效率和实效性的，和自己当下的处境相比，现实差距太大啦。。。

”测试人员不应该对测试文档过于珍爱。糟糕的测试用例不会受到足够的关注和改善，他们只会被抛弃，而最后留下来的是更好的测试用例。“

”作为一种测试文档，测试计划的生命周期是所有测试产物中最短的“

”测试计划是最早出现，最先被遗忘的测试产物“

”伴随着计划内或计划外的变更，维护一份测试计划是要花费大量精力的，除非多数项目的成员会定期查看，否则测试计划并没有什么价值“

这里道出了现实中测试计划的尴尬局面。有时候甚至会产生要测试计划何用的叹息，测试计划执行完后，我们对于测试的程度和产品质量的好坏仍然不能评估，不知道还有哪些没测，哪些是风险点，哪些对于产品来说是至关重要的。每次的测试计划不能相互关联，一次测试计划完成后，就永久性的搁置。而且最大的尴尬是，测试计划似乎无人在乎，开发不在乎，连测试人员也不太在乎，测试中随时可能会更改测试用例（有些步骤被证明是失效的，维护测试用例需要花费很大的精力），测试主管又不能根据测试计划做出合理评估！google提出的ACC方法确实有见地，在测试中一直在追问产品的核心价值，一切活动溯源都是产品的定位与价值。这其实给我们现在的测试管理敲了个警钟，要不忘初心！作为测试管理人员，是否能在10分钟内准确说出产品的特质？如果不能，说明对产品不够熟悉，还不能有效地测试它。一切都是为了提高效率，那就要时刻牢记最终的目标，这是测试的愿景，否则，在浩瀚的测试海洋中，是会迷失方向的。

愿在工作中，能尽快实践书中的一些理念，对于测试，实在要有长远的信心和行动才行！