读书笔记（google）：
1、质量不等于测试。到开发和测试不能区分彼此，就得到了质量，质量更像是一种预防行为而不是检测。
2、质量是效率的一部分。
3、产品发布：金丝雀版本（每天一版）——>开发版本（每周一版）——>测试版本（一月一版）——>beta或发布版本（对外发布第一版，已经过所有质量考核的一个版本）
4、测试类型为：小型测试（自动化）、中型测试（自动化）、大型测试（自动化+手动测试），能自动化就不手工测试。
5、mock测试是对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法。
fake测试是有实际可工作的实现，但是通常有一些缺点导致不适合用于产品(基于内存的数据库就是一个好例子)。
6、在产品初级阶段强调测试是非常愚蠢的行为。
7、TE在进入产品时，需要考虑的问题：
当前软件的薄弱点在哪里？
有没有安全、隐私、性能、可靠性、可用性、兼容性、全球化和其他方面的问题？
主要用户场景是否功能正常？对于不同语言环境的用户都这样吗？
这个产品能与其他产品互操作吗？
当问题发生时，是否容易诊断问题所在？
8、TE这个角色，需要敏锐的洞察力和领导力，测试重点在于真实用户的使用方式和系统级别的体验上。
9、ACC(特质、组件、能力)是测试计划的替代方法，指导原则：简明的列表、不必推销、简洁、有用的内容、渐进式描述、指导计划者的思路、测试用例，最终达到的结果是详细的描述测试用例怎么执行。
特质是系统的形容词，代表产品的品质和竞争，区别于竞争对手的关键。
组件是系统的名称，构成待建系统的模块，关键代码块。
能力是系统的动词，代表系统在用户指令下完成的动作，是可测试的。
10、风险分析的两个要素：
发生频率：罕见、少见、偶尔、常见
影响范围：最小、一些、较大、最大
11、用户故事来缓解风险，用户有一个需求，而故事通常描述了该用户如何使用软件来满足需求。
12、众包是测试领域的新现象，一部分懂测试的高级用户参与到测试工作中来，利用群众的力量。
13、GTCM谷歌测试用例的管理工具，提供了一种灵活的标签格式，任何项目可以自行定制，使得测试用例便于查找和复用。
14、Bug分析思路：优先级分布、各个等级的平均年龄分布（和严重程度成反比）、Bug发现的趋势（Bug的增加速度要小于测试人员和开发人员增加的速度）、Bug修复趋势（Bug的修复速度要大于Bug的发现速度，否则不再进行新功能的开发）
15、追求数量而非质量，是一种低效的工作方式。
16、测试一个web页面，上面有一个输入框，一个计数按钮，用于计算文本字符串中A出现的次数。
首先，提出问题而不是直接埋头写测试用例，明白是否区分大小写，只能输入英文吗，点击计算后文本会被清除吗，多次连续点击会有什么影响吗，然后再写测试用例
其次，考虑到界面外观问题，文本框最多可以输入多长字符串，多个用户同时进行会串扰吗，安全性数据会被记录吗，计算够快吗，能够承载大负载吗
17、作为一个测试工程师，要学会质疑，要求确定性的数据，不断评估领导的指令。
18、接触到一个新项目的正确做法
首先，站在用户角度了解产品，以个人的账户和数据去使用产品，看所有的设计文档，查看已有的bug，分析bug；
其次，积极和团队沟通，快速融入到团队中去，查看已有测试用例的覆盖性、完整性；
然后，将产品分模块，并根据bug考虑到每个模块的风险；
最后进行测试，目标就是遗留到客户的bug为0，利用用户的反馈来督促bug的修复
19、分析Bug是一种技能。
20、自动化脚本需要能够快速编写、快速执行、解决特定问题，因为花费大量时间编写脚本一旦功能有变就是最大的浪费。大量的重复性工作最需要自动化测试。
21、测试工程师关注点：case、用户故事、用户场景、探索性测试。
22、查看设计文档时的关注点：完整性（找出残缺或需要特殊背景知识的地方）、正确性（语法、拼写、标点）、一致性（图文一致、内容没有出入）、设计（目标、技术框架、是否复杂）、接口与协议（是否统一标准、是否可以自定义数据格式）、测试（可测试性、易测试性）
22、用户故事包含了她是谁，她有什么需求以及她为什么有这样的需求。对于一个项目可以确定好用户角色再构建用户场景
网友评论