google软件测试之道-读书笔记
2021-04-22 10:33:44 90 举报
为你推荐
查看更多
Google软件测试之道读书笔记
作者其他创作
大纲/内容
爬取
5.5
第二章
非常稳定的版本，且通过了质量考核
测试总监
1.测试成为了开发的拐杖。
（1）自动截图，保存为bug的附件（2）高亮元素的HTML被附加到bug（3）从打开\"maps.google.com\"开始的所有动作都会被录制下来（4）Map特定的调试URL自动附加到bug上（5）所有浏览器和OS信息被附加到bug上
洞察力领导力
测试工程经理
怎么参与一个新项目？
构建轻量级的自动化框架
职责范围不固定
一些
数据存储
测试
由测试开发工程师编写
2、寻找测试不足的地方
产品能与其他产品互操作
质量机器人实验
优秀
TEM发现自己团队中的好方法、好工具，并积极分享给其他团队
第三章
未来的测试基础设施
1.用BITE报告bug
由软件开发工程师编写
编写单元测试用例
·可以真正用到的突破性技巧
在被要求做测试前主动测试
2.测试开发人员需要更多地利用开源项目并为之贡献，快速组合、利用共享的云计算资源进行测试
TEM管理团队中TE和SET所发挥的影响
展示测试结果以及测试进度
测试版本
\"解铃还须系铃人\"
测试组织结构
手工输入重现步骤、调试信息等工作耗时，浪费时间和人力
集中测试部门中的工程师、经理和总监正逐渐分散到各个更加关注项目的团队和职位上。这种转变迫使他们更加敏捷、更少关注测试流程、更多关注产品本身
年轻的工程师需要完成他自己的工作
重要的是做确认
如何思索问题的解决方案，而不是解决方案的如何体现
如何想
考虑输入、输出类型和兼容性
TE的招聘
需求开发人员参与的难度
SET工作内容
测试执行
3.用BITE录制和回放
管理人员大多来自开发团队或产品团队
第一章
1 撤离之前，把困难的问题解决掉，而不是轻易放过
BITE实验
发布版本
·Google的测试规模
·开辟软件测试的未来
风险分析
少见
2、软件测试开发工程师（SET）
测试代码
测试工程经理事作为独立贡献者的一个技术岗位，负责所有的支持团队（开发、产品管理、产品发布、文档等）之间的联络。
产品经理
工作
优秀团队认证
测试工程师
风险
测试人员对模块进行测试时，BITE会自动浮现相关的bug
较大
3.未来的测试人员将会尽可能多地共享代码、用例和bug数据，而来自社区的回报是新的众包形式和用例创建，以及友善的用户关系
测试运行要求
创建mock和fake
开发和测试必须同时开展
金丝雀版本
项目
针对某个服务开发一系列功能函数
1.站在用户角度了解这个产品，使用这个产品2.看整体的设计文档、主要功能的设计文档3.关注项目状态、质量状态，了解bug详细信息和修复比例4.检查应用代码库，评审自动化测试5.把应用分解成为合理的模块6.再次检查bug库，按优先级遍历所有模块，创建用户故事7.检查bug和应用寻找覆盖度上的不足
组建团队
担心查重麻烦，干脆不报告明显bug
5 时刻准备返回到曾经工作的项目中帮忙
无法确定合适关键词，浪费时间填写重复bug
新特性开发
Google测试团队结构
3、公开一些不可接受的缺陷率数据
收集用户反馈
支持开发工程师
大型测试
项目早期阶段，如果是”测试驱动开发“，则该环节会在最开始运行
爬、走、跑
测试开发工程师
风险缓解
提交代码申请代码审核
安全、隐私、性能是否有问题
索引
动态变化
TE首先必须是工程师的一部分。Google的TE综合了开发者仰慕的技术和以用户为中心检查软件质量而对开发者产生了一定制约的能力
数量减少，不再为某个特别项目的质量或管理负责。
传统意义上测试工程师进行的测试用例的撰写、执行、回归等工作，实际上有了更全面且低成本的形式
并不是每个人都了解debug相关信息，大多数它们都被隐藏了
提交的代码需要通过良好可读性认证
编写代码过程没有明显错误
在代码中注释条件及引用
组件是构成待建系统的模块，核心要素和代码块
基础技术层、需要另一种视角和专业能力
通过Web应用进行资源配置，由TEM发布职位需求
3 两个测试要绑定同一个端口
2、根据优先级分配
可靠性、可用性、兼容性、全球化
面向用户的功能
常见
第四章
SET在审阅过程中要保持强烈的目的性
容易出错的接口做隔离
排序
使用mock接口做私有创建
正确性
GTCM
中型测试
SET是第一个实现protocol buffer定义与接口的人，在系统搭建起来之前，集成测试需要以来这些接口完成
随着敏捷开发、持续构建、早期用户介入、众包测试、在线软件交付的不断兴起，软件开发的问题已经彻底改变。
设计文档
质量是开发过程的问题
控制mock系统的创建和执行
能力是系统的动词，代表系统在用户指令下完成的动作
1 每个测试与其他测试之间独立
TC level等级1-5
把新服务的构建目标设为公共库
所有工程师共享同一套统一的工具，团队成员可以毫不费力的完成新代码的入库、提交、执行测试、创建版本等任务。
高级工程师需要在团队层面和产品层面体现影响力
SET早期提出的建议会反馈在文档中
开发人员日常使用的版本，一周一个
罕见
技术能力
当测试团队内部冲突时可以设置特殊标记
完整性
结果分析
测试的目标是判断质量预防工作做得如何
测试工程会转型成测试设计。负责需要专业技能的地方，如安全性、隐私、性能和探索式测试。
接口与协议
如何推动bug得到修复
5.1
软件测试开发工程师
设计
Google流程中的致命缺陷
1、测试人员以租借方式进入产品团队
5.2
测试类型
测试计划
协调能力
构建并运行测试目标
知道哪个团队测试上做到好并向他们学习
测试环境复杂
检测行为
迭代开发
主要用户场景？全世界不同国家的用户？
1、软件开发工程师（SWE）
Google软件测试之道
结论
与Lindsay Webster的访谈
总监的工作就是发挥领导才能。他们必须建设强大的团队，让工程师专注于发布高质量的、实用的、能够改变世界的软件产品
1.了解你的产品2.知人善用
小型测试
4.用BITE执行手工和探索式测试
5.6
2.用BITE查看bug
角色
一致性
4 确保有一个问题解决通道，愿意承担一些责任
C代表组件
SET需要熟悉了解所负责的系统设计
5.3
最早出现最早被遗忘
4.产品经过最严格的测试发布以后，用户有多大可能性仍然发现测试中遗漏的问题？答案是：几乎必然发现
RPF点击录制，对话框自动记录浏览器主视窗中所有点击动作
Google软件测试改进
TE的未来
时间冲突
领导能力
3.测试人员崇拜测试产物（test artifact）胜过软件本身
创新
处理跨团队沟通
3 留下一份how-to文档，以便其他人使用
通过了持续测试的版本
Google软件测试介绍
SET的未来
获得项目和人员
全职的负责从整体角度发现问题
测试用例
尽早交付经常交付尽快失败
未来
预防行为
面向用户
SET的招聘
5 测试执行系统中每个测试用例获取一个未被使用的端口
不被作为测试活动的指导
面试要求
TEM需要与其他团队的测试工程经理不断的交流
开发团队获得专家的指导，更好的编写小型测试
5.4
痛点
1.按照SET的要求来面试2.降低编程能力要求3.混合模型
汇报
在被要求停止前不断地测试
划分专注领域
排序器深度计算，给出质量分-两个页面之间的百分比相似分
skytap提供虚机
SET工作背景
C代表能力
2 测试不做数据持久化方面工作
代码编译
实现方式
与客户服务代表保持密切联系
使用虚拟机加载webdriver自动化脚本
运行静态代码分析工具
具体的缓解措施很大程度上取决于应用本身以及用户对于安全性的期望。
每日创建的版本，用于排除过滤明显不合适的版本
偶尔
1、工程生产力团队根据不同产品优先级、复杂度，与其他产品进行对比后分配测试人员
爬虫将原始数据传送到索引服务器
3、测试工程师（TE）
开发版本
比起高薪聘请探索式测试专家，未来更倾向于激励大量的真实用户发现并报告实际的bug
瓶颈
职责范围广
质量不等于测试
读书笔记
强调测试规模
证明修复问题而非开发新特性的时间不会浪费
2、SET与TE能够保持新鲜感，并且总是很忙碌
当前软件的薄弱点在哪
TE开始进入产品
促进团队进步
4 两个测试需要在同一个路径下创建相同目录
自动化计划
影响力
6 每个测试运行在自己的数据库实例上
测试认证是：如果一个团队完成了一系列的测试任务，这个团队会得到一个通过\"认证\"的标识
最小
×
数量减少
1.考察测试资质。2.对特定场景进行技术性分析3.好奇心4.处理模糊性、反驳糟糕想法的能力
转变
手工测试效率低下
开发团队得到优秀测试人员的关注
测试经理和总监
报表展示
2 建立小型的，负责端到端测试的自动化测试集
待评估软件的风险概要
联结
测试认证
失败频率
修复bug
TEM组件团队，并把工作分配给他认为合适的人，之后不再干扰工程师完成工作
如何做
1、做提高质量相关的事情
做
A代表特质
支持用户
特质是系统的形容词，代表了产品的品质和特色
测试经理和总监的未来
影响
2.开发和测试的组织结构分离
第五章
版本类型
1.整体迁移测试基础设施到云端。测试用例库，测试代码的编写、录制和执行都依靠浏览器完成
START
正向反馈
转型
通过订阅GTCM产品的测试集，BITE自动推送各个测试人员
本质是互帮互助的形式
发现风险尝试消除
SET的工作
能够向其他认证级别较低的团队进行炫耀
发生问题时是否容易诊断
ACC
最大
维护模式的测试
测试框架
收藏
0 条评论
回复 删除
下一页
