2018-12-7
学习总结：
Google测试之道：第一章（测试相关介绍）
1、敢于创新、勇于放弃
2、维护不能真正解决问题，而是通过前期规划；测试与开发共同努力，甚至达到不分彼此的程度，在角色上却又是完全分离
3、质量不是被测试出来的（质量是开发过程的问题，而不是测试问题），但未经测试也不可能开发出有质量的软件
4、测试人员的存在是为了让开发的工作更有效率，很大一部分体现在避免因马虎粗心而导致的返工
5、SET（软件测试开发工程师）：关注质量的提升和测试的覆盖，写代码的目的让SWE测试自己的功能
6、TE（测试工程师）：把用户放在第一位思考，代表用户的利益，是真正的产品专家、质量顾问和风险分析师，组织整体质量实践，分析解释测试运行结果，驱动测试执行，构建自动化测试
2018-12-10
学习总结：
Google测试之道：第二章（SET）
1、 测试工作是由整个工程团队负责，而不仅仅单独由那些头衔上带着“测试”的工程师来负责
2、 只有软件产品变的重要的时候质量才显得重要
3、 SET会审阅所有设计文档，且审阅时应始终保持强烈的目的性：完整性、正确性、一致性、设计、接口与协议（定义、描述、标准等） 、测试（可测性、测试框架、易测性等）
4、 任何阶段，集成测试总是依赖mock和fake
5、 端到端的自动化测试计划：必须合情合理且有影响力。避免投入过多
2018-12-11
学习总结：
1、 只有加速开发过程的自动化测试才有意义？？
2、 测试大小（小、中、大型测试）
3、 针对不同的测试规模限制不同的资源配置，要求不同的时间目标和时间限制
4、 不同规模的测试有不同的优缺点，一个项目中，不同规模的测试占比不同，也根项目类型有关
5、 代码覆盖率与测试规模的关系？？
6、 测试运行要求
每个测试和其他测试之间都是独立的，使它们能够任意顺序执行
测试不做任何数据持久化的工作。在这些测试用例离开测试环境的时候，要保证测试环境的状态与测试用例开始执行之前的状态时一样的。
7、“绿色”构建？？构建依赖原则—通过依赖树决定执行哪些测试，会不会有遗漏？？
8、改变开发文化：把测试工作也变成每个功能开发人员的职责
2018-12-12
学习总结：
Google测试之道：第三章（TE）
1、 理想情况下，测试计划应当在执行中发挥核心作用，应当在软件的整个生命周期中持续有效
做出一个不直接指导测试的计划纯粹是在浪费时间
希望测试计划具有的特性：
l 及时更新
l 描述软件的目标和卖点
l 描述软件的结构、各种组件和功能特性
l 描述软件的功能和操作简介
l 不必花过多时间撰写，必须随时可被修改
l 应描述必测点
l 在测试中能提供有用的信息
2、 ACC（特质、组件、能力）--测试计划的替代方法
特质----代表产品的品质和角色，区别于竞争对手的关键，产品存在的根本原因（比如：Chrome定位是快速、安全、稳定和优雅）；特质列表：简单（短时间内完成）、精确（有依据）、变化、短小
2018-12-13
学习总结：
Google测试之道：第三章（TE）
1、 组件----在特质被识别之后确定。是构成待建系统的模块（例如：在线商店的购物车和结账系统），正是测试人员要测试的对象
2、 能力—代表系统在用户指令之下完成的动作。是对输入的响应、对查询的应答，以及代表用户完成的活动（例如：Chrome具有渲染Web页面和播放Flash文件的能力）
2018-12-14、18
周会总结：
git相关：
l git 是一种版本控制系统，是一种工具
l gitlib 是用于实现git功能的开发库
l github 是一个基于git实现的在线代码仓库，包含一个网站界面，向互联网开放
l gitlab 是一个基于git实现的在线代码仓库软件，你可以用gitlab自己搭建一个类似于github一样的系统，一般用于在企业、学校等内部网络搭建git私服
git：
what：开源的分布式版本控制系统
有效、高速处理从很小到很大的项目版本管理
why：分布式（每台开发机器都等同于一台服务器）
公共服务器压力和数据量不会太大
速度快、灵活
开发之间易解决冲突
可以离线工作
how：网上教程，主要通过命令操作
when、who：适合所有代码提交人员在任何时间提交
持续集成：
背景：开发人员一天至少集成（提交代码、构建-编译测试打包）一次代码，集成过程中可能出现集成错误，为了尽早发现集成错误
解决：持续集成工具（jenkins、Travis、gitlab、buddybuild等）
把开发人员从繁杂的集成中解脱出来
实时监控集成中存在的错误，并提供详细的日志文件和提醒功能
部署：将打包好的代码部署到服务器
覆盖率：测试完整性度量标准之一
背景：客户端历史case上千个，每次变更代码都全部回归一下用例，不实际，所以通过覆盖率结果进行针对性的回归（精准回归）。起初需求与代码之间，需求与用例之间都有覆盖关系，现将代码与用例之间建立一种覆盖关系，从而达到精准回归。
几种覆盖：
语句覆盖：程序中每个语句至少执行一次
路径覆盖：程序中每条路径都需要覆盖
判定覆盖（分支覆盖）：每个判断的取真分支和取假分支至少经历一次
条件覆盖：判定中的每个条件表达式获得各种可能的结果
判定/条件覆盖：判定中每个条件表达式取到各种可能的值，并使每个判定取到各种可能的结果
条件组合覆盖：判定中的条件表达式获得各种组合的结果
方法覆盖：方法被调用的情况
学习总结：
Google测试之道：第三章（TE）
1、风险分析两要素：失败频率和影响
2、风险不大可能被消除，可以通过实际行动缓解
3、用例管理：正在淘汰一些老的，更多依靠人工回归的项目及测试用例。使用工具管理，便于查找和复用
4、bug管理：很多来自于用户反馈的bug，经过聚类算法自动识别重复记录并确定最频繁的问题
5、发现bug，分析bug，分项讨论bug，提供bug依据，通知相关人员，该bug对应的用例归入回归用例集
6、测试常忽略的一面是做确认，确认一个应用是否达到用户预期
7、看到需求第一件事不是立刻写用例，而是提出一些问题，在问题被澄清后，才开始编写用例，测试人员应该从整体角度看问题，看得更广泛，更全面
8、自动化回归的趋势
9、很难发现解决方案的问题，但又有影响更多用户的风险的情况下，需首先花费时间精力来解这个问题，甚至可以求助
10、问题描述一定要清晰，尽量达到让一个不熟悉平台的新人都能执行的程度
11、how-to文档，描述如何执行自动化和手工测试
2018-12-19
学习总结： 精益产品开发
1、 软件危机：随着复杂度提高，软件项目普遍出现预算超支、质量低、性能差、不符合实际需求和延期等问题。
2、 注意力成为最稀缺的资源，交付有用的价值则成为关键
3、 精益创业的核心理念：把价值的持续探索和发现融入产品交付过程，通过“开发、测量及认知循环”建立“经过实证的认知”
|
| 精益创业过程 | 传统创业过程 |
| 初始计划 | 商业模式，并把它看成待验证的假设 | 商业计划，并把它当做指导行动的蓝图 |
| 对失败的态度 | 失败在预料之中，把失败当成机会，并从中学习，修正假设，精化商业模式和产品 | 把失败当成意外，通过计划和跟踪和管控加以避免 |
| 指标的应用 | 关注最终业务目标，并再不同阶段聚焦不同的业务指标，将指标用于即时反馈和方案验证 | 关注会计指标，各职能部门分离的KPI，KPI用于考核和强化管理 |
| 产品设计方法 | 从业务目标及其相关指标出发，以用户行为为中心设计产品，并持续验证产品设计 | 从商业计划出发，设计产品功能，形成规格说明书 |
| 客户开发和产品交付 | 把客户开发融入产品交付过程，走出办公室，持续验证问题和解决方案 | 按部就班，产品交付和客户开发分离进行 |
| 开发方法 | 精益和敏捷开发方法，端到端的迭代和持续交付 | 基于规格说明书的瀑布式开发迭代也局限于产品开发内部 |
2019-1-2
1、 精益方法：定义价值（用户视角）—》识别价值观（避免不必要的价值和活动）—》让价值持续流动—》用户价值拉动—》精益求精（重复前几步，持续改进）
2、 精益价值观：持续改进（挑战现状、改善、现地现物），尊重人（尊重理解、团队协作）
3、 精益原则：找到有用的价值（弹错和发现有用的价值），让价值顺畅流动（聚焦和提升价值流动效率）
4、 精益实践：看板（信号卡）
5、 建立看板系统的三个实践：
l 可视化价值流动（用户价值流动）
l 显示化流程规则（价值流转规则）
l 控制在制品数量（暴露瓶颈和问题，减少并行，加速交付）--较困难
6、 运作看板系统的两个实践：
l 管理价值的流动（就绪队列填充活动（输入），看板站会（过程），发布评审-可选（输出））
l 建立反馈，持续改进（流动反馈、质量反馈）
878
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
