测试价值提升之路读书笔记-王宝中整理
2022-01-19 14:23:54 1 举报AI智能生成
登录查看完整内容
软件测试价值提升之路，作者杨晓慧根据自己多年测试、研发与实战经验总结了软件测试的实现价值，提出了主要遇到的问题和关键技术。 脑图由测试经理王宝中整理
作者其他创作
大纲/内容
看不到产出
说不清投入
显不出能力（或者能力没有进化）
测试目前困局
工作成果被别人用的越多、看到的越多，越容易被别人认可，价值也就更明显但测试不是这样
发现缺陷多少说明不了测试的价值
测试发现了bug？
更好的开发工具
更好的编程语言
更好的软件重启和恢复机制
更好的 分层隔离架构
更好的测试工具
测试提升了质量？
但测试参与度太低
软件出问题影响较大
出问题后常伴随无法承担的经济或人身损失
过去
基础架构改变
产品成本结构发生了变化
现在
很多缺陷不会再造成无法挽回的损失
测试是蓝军，把红军攻下来就是成绩？
错误的反击
能证明有问题，不能证明没问题
质量是设计出来的，不是测试出来的
测试领域认为理所当然的“准则”已不合时宜
外行指挥内行，在困局中越陷越深
没有真正理解项目经理想要解决的问题
弊端
①老版说什么我做什么
1.对产品掌握程度较深入
2.测试过程数据掌握较深入
测试优势
主导产品指标改进
通过过程数据分析项目短板，并制定改进措施，持续改善
缺陷预防
内建质量标准
主导产品集成
主导用户体验分析
主导用手测试活动
用验收用例实例化需求
持续赋能团队业务能力
主导团队业务培训
举例
②主动寻求新的测试价值拓展新的职能
解决目前困局的做法
1、工作价值的质疑
测试是测试团队的事
要根据风险找最有价值的BUG，没有风险就不用测试
测试组核心的就是找BUG，找的越彻底越好
如体验测试、验收测试、产品上线等活动
与质量相关的活动都有测试的用武之地
测试团队是做研发内部测试的团队
寻求测试新价值的障碍
需要打破的常规
推出快
变化频繁
接口杂
开放性
云测试、探索式测试、急速测试、基于模型的测试（MBT）、基于风险的测试（RBT）、测试过程改进（TPI）
新技术
重体验
匹配新的业务要求
需要测试人员适应
需要找到有测试角色主导来实现的、在质量、成本、效率上的“显性”价值。以这些价值来带动团队能力的提升乃至个人的发展
面向企业商业成功
测试结果数据不完整，测试结果和客户使用的感知不一致
测试太贵
测试太花时间
对于产品质量和风险，测试没有提供有价值的信息和建议
测试没有在第一时间发现最重要的缺陷
寻找价值的最佳人选是自己
测试必须实现的价值
测试可以实现的价值
理想的测试工作场景
测试价值的层次
2、价值实现的起点
一、引子
测试最基本的价值
建立基本测试用例基线
尽可能实现100%自动化测试
做好客户的数据、环境、应用场景等信息管理
解决思路
基本功能缺陷
扩展基本用例集，使之包含安装、升级、应用场景、性能的部分用例
形成测试设计要素及，完善测试设计方法
强化测试分析
常规使用缺陷
在产品中增加安全防护、备份恢复、过载控制、故障检测和恢复机制
一般处理原则
①分类
②故障模式
③优先级
④故障处理
⑤故障模拟方法
模式库包含的内容
形成安全性漏洞和可靠性故障的模式库
通过攻击的方法实现缺陷拦截
受攻击暴露的缺陷
提升代码质量并未产品加上故障检测和自动恢复的能力
使用静态测试工具对代码进行检查
进行代码走查，排除代码逻辑上的错误
提升代码质量
首选代码静态测试
利用工具进行静态检查
加上人工的代码走查
在测试过程中通过后台的、自动化的检测，确保能够发现偶然问题
数据一致性
异常宕机core dump文件
告警
文件数目和大小
产品和系统异常日志
业务流程阻塞或挂起或未正常释放
系统资源异常波动
应具备的功能
或者开发错误检测工具
方法
如随机出错较严重，需组织代码质量改进的的专项工作
减少随机出错方法
分支主题
就缺陷拦截的方法与技术
随机出现的缺陷
缺陷分类
3、拦截缺陷
1、产品质量的结论
2、研发过程的分析
3、风险情况
包含内容如下
提供数据
基本价值
指在某项测试完成后，根据测试过程中获得的数据、现象等信息给出的，指示产品质量的结论性信息
范围
产品发布前提供
提供的时间
供产品团队的各个角色确定：1.产品是否发布2.在什么范围发布3.上线时和上线后需要做什么安排
作用
包含缺陷数量、严重等级及对应的规避措施、计划修改时间
遗留缺陷数据
容量、TPS、在线用户数、吞吐量、业务处理成功率、系统资源占用情况、平均操作耗时、平均响应延时、数据同步延时
性能指标
安装升级耗时、升级扩容影响业务的时长和比例、告警有效性、故障定位回复有效性和对业务的影响、统计报表的性能和对业务的影响；按产品资料完成安装、升级、故障处理的时长、求助次数、试错次数等
服务相关指标
故障自动恢复率、故障检测率、备份操作耗时和对业务成功率的影响、故障恢复的耗时和回复期间业务的性能、系统过载时业务的性能等
可靠性相关指标
安全性
对产品所需要遵循的协议规范的遵从度
对第三方产品的兼容性
对历史版本的前向兼容性
平台产品对业务主流历史版本的兼容性
兼容性
体验相关指标
各项指标的实测值
和风险相关的测试结果
数据内容
最重要的信息是：可能导致发布推迟的信息
重要的结论放在最开始的位置
然后是得出结论所依据的各种证据
采用金字塔原理
根据读者的角色职责将数据分类并突出重点
测试报告编写方法
测试结果数据
此处风险指——技术风险
风险含义
供产品各角色人员决定：1.产品是否发布2.发布的范围3.上线时和上线后需要做什么安排
把有限的资源用到最重要的地方
严重的缺陷能够尽早发现
初衷
要测试的特性与质量属性；新、老特性与版本、客户、产品相关的专项内容
1）确定测试范围
两个维度：失效概率、失效影响
2）风险等级评估
原则：高风险的内容尽可能早、尽可能多测试；低风险内容灵活性可以大一些；持续评估风险变化
3）基于风险的测试
测试完成后重新进行风险评估打分
4）风险闭环评估
实施过程
a.同类特性的历史表现
b.全新特性（无同类老特性）
①综合
c.需求变更频繁
d.用户参与不足（特性的需求调研、澄清和开发过程中）
②需求
e.评审活动未开展或开展质量差（特性的分析、设计、代码评审活动）
f.功能复杂，代码量大
g.外部接口数量笔平均水平多
h.开发过程中第一次使用了特定工具或技术
③设计
i.首次采用新的研发流程
j.设计、开发时间过于紧迫
k.开发过程中开发工程师变更
l.新员工开发的特性
m.团队成员分散在多地办公
④流程和人员
可能出现风险的场景
降低盲目套用模板、方法导致的测试场景遗漏
将特性的风险评级和具体风险点作为专项工作之一，研发各个角色共同实施
应更关注评分人给出的评分依据，而不是只关注风险评分结果
如何用
测试脑图中将风险或影响面作为专项进行设计；提测清单中增加开人员的影响性分析与风险提示；是否需要增加风险提示与跟踪表(避免风险遗漏)？？？
将风险作为重要的测试输入信息
策略制定的主要依据
包含哪些特性、项目目标、哪些DFX提升目标
a.项目情况
主要的技术风险
b.风险
1）产品研发状况分析
①开展的所有测试活动
②各活动开展的时间、阶段
③各活动有哪些测试内容
④每个测试内容采用什么方法、达到什么程度的覆盖
⑤各活动的重点测试内容
⑥有时间或资源冲突 时怎么处理
测试策略最重要的结论
a. 测试项目和策略
b.集成部分的测试策略
哪些内容实现自动化
什么阶段实现自动化
c.自动化测试策略
2）测试策略综述
a.测试重点
b.环境和工具
c.入口准则、出口准则
3）集成、系统、验收测试的策略
对数据、研发和客户信息的特殊需求
4）其他信息和数据
测试策略文档内容
测试策略评审
最有效的工具
过程中的每个环境都不能是测试的单方面行动
风险识别需融入到设计阶段的各个研发活动中
风险需要进行持续的更新与跟踪
如何真正发挥风险信息的价值
风险评估
基于风险的测试（RBT）
头脑风暴后形成风险评估表
头脑风暴法
风险等级评估方法
尽量安排经验丰富的工程师
加强开发、设计、测试评审
加强影响面分析
开发、联调、测试验收等活动尽量提前
产品经理在开发过程中增加确认频次
视情况评估是否需进行需求二次评审
风险高的特性对应措施
风险评估数据
计划执行
缺陷
工作量
覆盖
测试项目过程数据
用例执行过程数据
测试结论支撑
发现改进点
用于评估新项目的工作量与进度
建立基准
有助于判断测试能否按计划结束
有助于发现测试的薄弱环节
分析研发各环节（设计、开发、测试）的周期比例
定义
可以作为项目估计工时的参考
可以作为项目质量表现的参考
适用范围
基准分析
找到最耗时的工作：按特性或研发活动统计工作量
推动开发、产品进行过程改进
找到引入缺陷的主要原因
可以按缺陷引入原因
找到错误最多的操作类型缺陷
按缺陷发现手段
找到最影响质量的因素：按特性、测试类型、根源对象等正交缺陷分类法分类统计缺陷
例
将工作量、效率、缺陷等按特定的维度分类汇总绘制柏拉图，据此分析影响质量和效率的主要因素
分布分析
将两个或以上的数据组合起来进行分析，找到数据组合异常的部分进行风险分析和排查
四象限分析法
常用方法
分析工作量密度-缺陷密度，用于发现可能测试不足的特性
典型事例
组合分析
将缺陷总数按时间轴绘制成成长曲线
较大型的、采用瀑布、V、W流程模型的研发项目
敏捷模型不适用
预测遗留到下一阶段的缺陷数
趋势分析
用于衡量测试的强度
覆盖率分析
分析方法
过程数据的分析
用于测试策略的调整
用于研发过程的改进
每个项目组都可进行的应用
将多个项目的数据进行综合分析，说明研发活动需要改进的问题及其根本原因，进而启动专项的研发改进活动
更重要的作用
可使用的场景
一旦用于考核，就无法再保证其客观性
原因
绝不能用于对人和项目的考核
绝不能使用的场景
过程数据的应用
发现隐藏的缺陷
目的
性能测试数据
可靠性测试数据
可服务性测试数据
体验测试数据
功能测试数据
包括
我的结论是什么
我依据什么做出的结论
为什么我做的测试是足够的
用数据讲好测试故事
测试过程数据
4、测试提供的数据
指测试的周期和投入稳定，工作质量可被产品团队和客户接受。测试的质量、成本和效率的提升和研发整体的提升同步
将个别人的能力总结成为有形资产，成为可学习和传播的团队能力
技术方法和工具
将团队能力固化成流程活动，使之成为持续产生作用的能力
流程
最根本的载体，能力落地的标志
有一定比例的团队和人掌握了相关技术、流程和平台
组织&人员
能力持续发展与传播的环境与保障
平台
能力的载体
概要
能力的稳定和持续提升
本质
被动提升
主动提升
动因
问题的来历
内在原因
测试的问题
然后基于对问题的深入分析
以及对可用方法和工具的广泛了解
首先识别解决什么问题
进行最初的决策
1）从问题出发寻求适合的能力建设方向
测试藏宝图
软件测试全景图
网上直接搜，选择日期比较近的作为参考
网络
STAREAST
STARWEST
EUROSTAR
微软、IBM等业界顶尖公司组织的技术大会
欧美
TiD质量竞争力大会
CSTQB高峰论坛
MSUP的TOP100案例
阿里巴巴的测试嘉年华
国内
会议
向身边的人学习
分享交流
途径
2）拓展测试领域知识的广度
各自解决什么问题？？怎样配合？？
人员
3）能力建设需要有架构设计
能力建设实施要点
解决“怎么做”的问题
1）风险和策略分析
业务场景、性能、易用性、故障注入、安全工具等
a）功能测试设计
b）客户应用场景测试设计
2）测试设计
3）测试执行
4）测试评估
5）探索式测试
6）持续集成（CI）
7）环境管理
8）发布后缺陷的修改和分析
9）测试用例基线
10）测试数据管理
11）客户应用场景信息管理
测试团队中有固定的角色参与到需求分析中
需求分析
向开发者提供测试设计方法、合理规模的用例与测试工具
开发者测试
测试参与特性划分的评审
12）上下游协作
给出对本项目研发活动的改进建议，以及对测试能力（方法、工具、流程、组织、平台）各方面的改进措施
通过对项目过程数据（缺陷、效率、覆盖等）综合分析能够发现设计、开发和测试过程的问题
13）持续改进
技术能力公共部分
要有重点
有必要
有可预见的质量、效率方面的价值
有方法、有能力
成果能够持续应用
能力建设首先考虑实用性
先根据输入信息和经验整理出测试范围；然后针对范围内的所有测试项，边设计测试用例边执行根据测试执行结果决定下一步测试内容和重点
比较符合人的思维模式
较少工作浪费
较好的全系统思维
较快的质量反馈
可以测试的比较深入
优点
不同的人有不同的效果，管理者要有准确的预期
过程不容易回溯
用例不容易被集成和自动化
需要基于信任去管理ET过程
需要注意的问题
探索式测试（ET）
预先设计好测试的范围并实例化成用例，包括用例的测试步骤、数据、预期结果。然后逐个执行设计好的用例，并检查系统的响应和预期结果是否一致。
固化了一部分经验有助于测试质量的稳定有利于自动化实现
剧本式测试（ST）
探索式测试（ET）VS剧本式测试（ST）
工作输出的成果是可长期重复使用的
在质量守鹤和问题快速反馈上起到了决定性的作用
几乎是测试的中级形式
当MBT自动化逐渐成熟，自动化的一些“顽疾”也在解决
好处
①有完成工作所需的技术手段
②技术手段可靠
③技术手段应用成本低
要有技术
根本
是只给测试用
还是开发环节用？上线后用？
目标
目标不同，方法、工具、实现难度上差别会非常大。不要做成：只有测试环节、具备测试技能的人能用
测试结束和工具很难做到“在新特性开发就绪的时候，自动化用例也就绪”
1）无法解决“减员增效”
2）用更高的自动化率是老特性在“未来”的应用中不出问题
不合理的期望
自动化
测试是否有效取决于测试设计
测试的深度和质量取决于测试设计
重要性
最有效的方式：持续的思考、持续的试错、持续的沟通
测试设计只是一个过程文件；需要非常多的信息；测试执行的质量对最终的质量影响也很大
难题
测试设计
1）看团队当前亟需解决的问题是什么
自动化侧重工具能力建设
契机：通畅在产品质量出了问题的时候
测试设计侧重人的能力建设
2）优先改进短板
优先改进测试设计——新开发的功能缺陷多
优先改进自动化——老功能缺陷多
3）视具体问题分析
如何选择
测试设计VS自动化
解决 【什么角色】 在 【什么时候】 按 【什么标准】 做 【什么事】的问题
团队能力的重要体现
流程的作用
通常固化为产品研发流程的一个环节或活动
①根据产品和项目特征形成的客户化测试能力（体验测试、镜像测试、验收测试等）
通常固化为指导书、模板、工具套件，并且通过活动名称检索
②研发流程中各项测试主导或参与的活动所需的信息（方法、工具、模板、学习材料、经典案例、检查表等）
通常固化为流程响应阶段的出入口标准
③一些辅助进行流程控制的活动（缺陷分析、CI）
1、典型的固化在流程中的测试能力包括
作用：使研发流程在测试环节没有明显的技术障碍，测试的主要工作能够正常开展
a）方法和工具完整
作用：1、使测试能够根据跟踪关系评估需求和场景的测试覆盖，提交需求实现的质量信息2、使测试能够根据跟踪关系及时获取变更信息，并同步修改测试的设计和实现
b）需求跟踪
作用：使开发者测试达到必要的覆盖要求，提升研发的质量和效率
c）尽早测试
作用：使研发的整体测试效率最优
测试类型和层次有明确的定义
作用：使重要的需求不满足的问题尽早发现
尽早测试
杜绝存在严重缺陷的版本流入下一阶段，阻塞后续研发工作
测试出入口条件
d）分层开发的多个产品之间，测试策略相互配合
作用：杜绝技术债务向后续迭代持续积压，造成项目风险失控
e）迭代版本质量控制
作用：使产品交付工作得到有效管理
f）现场测试管理
2、技术层面测试能力对研发流程运转效率影响比较大的关键点
测试在流程中发挥的作用
一个优秀实践的经验总结
流程无法对各种可能的问题都确定行之有效
需明确一点
需要在流程复核度和适应项目的灵活处理之间找到各方都能接受的平衡点
各环节尽最大可能遵从流程，项目的成功几率会大很多
做很多无用功，影响后续计划执行，而且不能解决问题
严格追求流程符合度的坏处
将流程作为一个发现问题的工具、处理问题的知道原则，而不是当做法律
更合适的作用
1）搞清楚风险在哪里
2）各角色如何应对风险
3）明确风险的责任人
4）测试要能够及时获得更新信息
处理原则
直接说“不符合流程，不同意研发过程继续”
不可采取的措施
让研发过程带着风险继续进行，做好风险的管控和规避计划，做好风险相关信息及时披露
做好风险管理，风险形成闭环
推荐的做法
流程未满足
1、过程管理的目的是项目的成功，而不是流程符合度
1）不清楚度量数据的含义，那就不要去度量
2）不打算在度量后做些什么
3）能够度量结果就不要度量过程
4）不要把提升度量数据值作为目标，尤其不要把度量结果用于考核
四不要
不适合度量的场景
2、度量的目的是改进
该挥舞大棒测试人员自己作为参与者，边阻止边给出建议，避免做一个站在旁边指手画脚的“裁判”
注意点
测试在流程运转中该不该挥舞大棒
流程中固化的能力
测试专家角色类型
主要指测试相关的工具、方法、流程等，此外还包括业界的技术趋势和思潮
测试专业技能
OS/DB
平台、产品、解决方案
目标客户、目标市场
产品历史质量表现、过往问题
测试流程、技术、工具
相关标准的ISO/IEEE等
竞品、业界技术趋势
产品知识
批判性思维、横向思维、逆向思维、系统思维、发散思维、基线思维、环卫思维、换轨思维等
思维方式
获得必要的支持
准确报告测试的进度、质量、求助
对问题的判断得到研发各角色认可
和上下游形成良好的合作关系
沟通能力
寻找重要的少数
柏拉图（排列图）
进行根因分析
鱼骨图
分门别类的归纳统计
层别法
寻找强相关因素
散布图（四象限）
头脑风暴+归纳
亲和图
质量分析方法
能理解UML图
了解需求分析和设计的常用方法、常用设计模式
掌握产品使用的编程语言
软件工程方法
能力模型
制定测试策略、掌控测试过程、根据测试结果对产品及其研发过程进行质量评估
产品测试方面
达成测试活动乃至研发的能力提升
稳定团队、改进技术、优化流程
测试组织方面
核心测试工程师的职责
测试工程师的能力模型
测试是否成立独立团队，首先取决于是否有继续发展测试能力的必要
结构
产品研发部按模块或特性划分为若干开发组，工程师全部归属于各开发组由开发组主管全权负责所有工程师的任务管理、人员管理
团队高度专注于近期的、项目的目标，有非常强的项目成功导向
有利于任务的调度和安排，沟通成本低，信息传递高效
优势
工程师的能力发展基本上依靠团队主管个人的改进意识
测试能力几乎是止步不前的，甚至随着测试工程师的流失，测试能力还在降低（前提：研发工程师的能力还有比较大的提升空间，对精挑细选的团队无影响）
劣势
能力建设和发展上的投入一般不超过5%——决定了在测试能力方面只能实施技术、流程上的小改进
投入
新项目、重点项目等短期目标比较重要的项目
适用团队
如果本身能力有待提升，又采用这种组织模式——在团队中工作超过3年的工程师，会明显感觉工作重复、枯燥，进步迟缓
长期采用的后果
1）树形结构
产品研发部按模块或特性划分为若干开发组，工程师除了服务于各开发组外，还分别组成了资源部门（测试部、开发部、系统部等）。由开发组主管负责所有工程师的任务管理，资源部门主管负责人员管理。工程师所属实体组织是开发组
人员的日常管理以开发组主管为主开发组主管：工程师的绩效、任务管理资源部门主管：主要职责是规划和实时工程师的能力发展
人员管理的侧重
团队有明确的能力发展目标和计划，追求项目目标和能力发展的平衡兼顾短期目标和长期发展
能力发展工作占用人力资源，而且这部分资源的投入，在产品侧是看不到短期效益的
测试工程师缺乏不同产品的测试经验，难易培养出跨产品解决方案的验证专家，以及专项测试专家
测试工程师达到一定规模（如20人以上）后
产品成功导向应该是团队的主流，避免“技术情节泛滥”，影响测试工程师在产品测试上的投入
需要注意
科室目前采用的组织结构类型
2）矩阵结构（以产品导向为主）
产品研发部按模块或特性划分为若干开发组，工程师除了服务于各开发组外，还分别组成了资源部门（测试部、开发部、系统部等）。由开发组主管负责所有工程师的任务管理，资源部门主管负责人员管理。工程师所属实体组织是资源部
人员的日常管理以资源部门主管为主开发组主管：负责任务管理资源部主管：负责绩效管理、团队建设、人员发展等
可以集中资源实现革新性的提升，如实现自动化测试、引入新的测试类型等
产品测试的投入相对较少，对项目的研发进度有一定影响
对创新有较高要求的团队
强矩阵模式
3）矩阵结构（以分工导向为主）
类型
①测试是一个不断假设求证的过程，测试执行过程中仍在不断更新甚至推翻原先的测试设计，测试设计与执行分离以后增加了沟通成本，降低了效率，场景遗漏风险增高
②开发过程中需求和设计也一直在变更，当工程师拿到可执行的产品时，可能根本无法使用原先设计好的用例
③测试设计工程师长期不对产品进行实际操作，对产品的特性使用方法、限制和约束、陷阱和问题等都不了解，无法设计出真正好的用例。
④认为造成的等级观念，极大削弱了低级别工程师的积极性
不可行
1）测试设计与测试执行分离
根据测试团队承担的职责不同，从1:2~20:1
测试工程师通常会简化甚至省略专项测试、测试设计、缺陷分析等工作，使得测试覆盖却让保障，测试工作也不容易回溯和改进。
低于该比例
测试工程师可以开展更丰富的撰写爱你过测试，或者为研发团队提供其他服务，帮助提高研发质量和效率
高于该比例
全部由测试完成，开发测试比例可以维持在2:1~4:1
黑盒测试
5%左右
比例
负责主要版本的专项测试设计、执行、结果分析、缺陷分析等工作，也负责专项测试所需要的技术和工具准备工作
主要职责
专项测试
2%~4%
帮助提高研发质量和效率，提供产品研发、交付所需要的技术、方法和工具框架
测试工具和技术专业团队
可参考的经验数据
2）开发测试比
两头少，中间多
3）各级别测试工程师比例
测试团队内部的组织设计问题
任务与人员管理方式为不同组织架构的主要区别
组织结构的设计决定了研发团队如何分配自己的资源，而资源的投向决定了研发团队能力提升的速度
组织结构的几种类型
组织结构要与能力现状匹配
最初是通过做好测试设计，保证测试的质量和效率——>到需要做好DFX 测试，通过技术和工具手段提升测试端对的整体能力——>到为研发体系搭建测试架构，提升从需求到交付的整体的质量和效率
从任职资格标准的演变看测试价值
一个测试工程师能够怎样发展，与个体的机遇、性格、特长等客观因素有关，不完全取决于个人意愿
组织建设和人员能力模型
团队文化、信息渠道、专家资源、工作环境、IT流程等
发展平台的构成
实现能力的承载、获取、应用和发展
平台作用
关注的是测试工作所需要的信息能够快速获取
测试知识的管控和治理
产品信息的管控和治理
硬环境
关注的是价值导向、氛围的建设
人员的成长和发展
软环境
内容
如：测试计划、测试策略、测试方案、测试用例、缺陷、测试报告、缺陷分析、项目总结等
模板
工具
指导书、检查表、规范、标准等
指导
培训教材、优秀交付件样例等
参考
案例
行业信息
测试资产
客户信息库
包括测试策略、方案、用例、报告、过程记录等在产品测试过程中产生的信息，以及保存成而是用例及其执行结果的测试用例基线库
测试配置库
产品研发过程中产生的信息，包括①特性、需求清单；②分析、设计过程中产生的模型和文档；③代码；④数据、接口定义等
产品配置库
包含产品所处业务领域的相关规范；产品研发内部桂发；产品开发测试所遵循的其他依据
规范库
研发资产
尽可能把常用的术语进行统一定义，明确每个术语的含义和边界
研发团队的职责
能够获得尽可能全面的信息，特别是需求和设计的变更信息
最基本的要求
需求文档
应用场景说明书
设计文档
验证文档
使用情况
管理的对象是文档。一般以特性清单为主要线索，包含内容如下：
产品信息的管治平台
个人成长和团队所处的业务环境的关系非常大
激励什么，就会得到什么
肯创新、完成工作高效、交付件质量好、并且善于总结分享的
激励对象
1）任务启动之初：花时间讨论明确工作要求，并提供必要的帮助，使测试工程师能够获取必要的资源
2）在任务安排上，既有已经擅长做的事，，也有类似跨团队合作、变革创新、全新业务、技术或业务决策这样更富挑战的职责
3）明确个人职责和团队目标、产品目标之间的关系，并定期讨论回顾取得的进展、遇到的困难、采用的解决方法
日常管理的激励措施
团队管理上
鼓励工程师之间、团队之间面对面的沟通交流
工程师个人成长和发展环境
测试能力和持续发展的环境
测试过程可控涉及的技术
测试的组织能力模型
方法和工具方面的能力建设
5、测试过程可控
测试产品，发现缺陷，报告结果，使每个版本的测试水准稳步提升
基本职责
测试的基本价值
1）测试用例基线的架构
本书采用的定义
2）测试所需全部知识、信息、技术和工具组织架构
测试架构的两种解释
定义流程‘应该’是什么样知道流程执行遇到的问题如何解决
1）流程
计划管理
缺陷管理
风险管理
测试过程改进
2）测试管理
测试范围分析
测试策略制定
3）测试分析
4）功能测试
5）DFX测试
6）静态测试
7）单元测试
8）客户化测试
9）持续集成
10）探索式测试
11）测试环境
12）测试评估
13）测试用例基线库
常规内容
当有了一方面的积累的时候，帮助找到合适的安置位置，方便以后查找和使用。当需要解决什么问题的时候，架构帮助找到需要创建的模块
架构的作用
不可能也不应该追求一个全的架构，需要什么就积累什么
支持基本价值实现的测试架构
6、测试基本价值总结
二、扫门前雪
1）构筑一条“河道”，随时将产品质量约束在可控范围内，防止产品研发过程中质量劣化
2）打造一面镜子，系统、客观地评估产品的质量，使产品团队对产品质量有准确的认识
测试对于质量的价值
个人补充：通过客观数据分析反馈产品团队的不足与薄弱点，并推动改进
早期：证明软件可以工作后来：发展成为发现缺陷现在：参与质量管理，实现缺陷预防
测试目的的几个阶段
以质量管理和缺陷预防为目的的测试，在研发的每个环节都有验证和质量反馈工作，因此测试的工作是分布在整个产品研发过程中的
随时将产品质量约束在可控范围内，防止产品研发过程中质量逐步劣化
价值体现
对研发过程文档交付件进行评审发现缺陷
对处于研发过程中的产品进行测试，验证质量，暴露问题，避免研发团队对产品质量的误判
约束研发过程质量
全流程质量保障的核心工作之一，也是测试在质量管理中独特的作用
识别和纠正信息传递失真
将风险作为主要线索之一，贯穿整个项目的测试活动
识别和管理风险
工作的作用
针对分析和设计文档的评审
静态测试
动态测试
全程软件测试
新代码快速充分验证
老代码持续验证
尽早开展需求验证
4个手段
方法和工具简述
概述
项目一开始即开始测试的各项工作
纠正信息传递湿疹、约束研发过程质量
W模型
第一遍：排除理解偏差
第二遍：前后印证，串联流程和数据模型，纠正逻辑错误、流程断点、设计要素失真
第三遍：代入既有业务流程、审计和维护流程、条件约束等上下文，分析业务流和数据流的变化，发现需求和设计对客户需求的偏离、应用场景的缺失
详细研读文档至少3遍
真正产生价值的评审
1）对产品的架构、设计、接口、相关协议和规范、开发语言等有相当的了解
2）对产品已有的特性、使用情况、质量情况有深入的掌握
3）对用户工作场景比较熟悉
4）最后还需要识别出风险高的特性重点参与评审，帮助识别风险点、控制质量
如何提出更有价值的问题
需要结合特性的业务场景和应用场景测试设计，从特性的业务流程、运营、维护、管理的角度分析
如何提出建设性的问题
1）可读性，需求陈述是否清晰、容易理解
2）文档结构完整，没有章节缺失
3）名次术语有明确解释
步骤一：理解——发现文档标书和需求理解的问题
1）需求定义不明确，可能造成多种解释
2）需求相互之间描述上存在矛盾、冲突
3）对需求不符合要求的地方提出疑问
步骤二：质疑——给予理解对需求产生质疑
1）发现需求不明确、背离用户真实需求
2）发现需求场景上的缺失
3）对需求的合理性进行探讨
步骤三：建设——基于经验对需求提出深层次的问题
评审步骤三步曲
1）参与需求和设计评审，但无法提出有价值的问题，仅仅只是提前熟悉了需求和方案 ，没有起到约束质量的作用
1）通过产品信息的管治平台实现变更信息的及时、准确传递
2）需求和设计阶段只完成对应测试文档的核心分析工作。测试文档补充细节，最终完成的时间，比对应的需求和设计文档落后一个环节
如何减少浪费
2）需求和设计文档与最后完成的软件成品有很大差异，据此完成的测试用例和自动化方案需要进行很大的调整才能使用，造成工作浪费
典型问题
测试尽早开展：全程软件测试
纠正信息传递失真
主要作用
即，对外实现一个完整的功能该或业务流程，对内不依赖其他待开发特性
低耦合高内聚
理想的特性划分
由于特性划分不大容易达到理想状态，测试也就不可能仅仅通过组织、流程上的调整，就顺利实现对迭代的充分测试，导致很多重要问题只能在最后阶段被发现
问题
个人理解：这种场景下需要额外花时间做工具的开发，且该情况下验证出的结果与实际结果可能存在偏差，待开发全部完成并提测后，测试仍需进行完整的功能重复验证，比正常流程需额外多花很多时间。通常测试没那么多时间
指较强的工具开发能力，通过快速开发‘临时组件’，越过在迭代中进行业务场景、应用场景、体验、性能测试的障碍
过墙梯
在迭代过程中进行需求和场景的测试或演示，邀请用户初步体验，以纠正信息传递的偏差，必须搭建一个“过墙梯”
解决方法
迭代模式下必须解决的问题
测试尽早开展：尽早开展需求验证
约束研发过程质量，识别和管理风险
具体说：用例简化到只有标题、主要目的和关键数据特性开发完成，基本功能文档后再实现自动化用例
不合适既没有增加对测试充分性的保障，也没有提升测试的效率
是否合适
①简化用例，延迟自动化实现
具体说：特性的设计和测试文档合并，无单独的测试用例文档；文本用例和自动化用例合并，在自动画平台上管理
不合适开发、测试合作更主动，但大部分测试执行还是积压在开发工作完成之后，在迭代的时间窗内，仍较难完成比较充分的测试和回归测试
②story开发测试文档合并
没看懂
开发和测试共同完成特性的需求和设计模型，特性的设计和开发阶段，测试根据需求和设计方案建立模型并和特性实现方案保持同步修改，在特性开发完成后，经过最后的调试，就可以批量生成测试用例及其自动化脚本
合适但实施门槛较高，需要测试工程师具有很好的建模能力；留给模型和自动化用例的调试时间有限一旦模型调试无法按时完成，新代码测试将面临无用例可用的问题
③MBT
3种做法
1）用例和自动化脚本与特性代码同时就绪、同步更新
环境快速获取
缺陷辅助定位
未覆盖代码风险分析
需要解决的技术问题
2）特性开发完成后，特性的功能、业务场景，以及性能等测试能够在较短时间内完成，特性的绝大部分缺陷能够在迭代测试中法发现和修改
需要解决的两个问题
测试充分性快速提升：新代码快速、充分验证
自动化覆盖率高
自动化用例实现效率高
自动化与CI集成
自动化能力要求
录制的用例无法直接用于CI
录制的脚本只有操作，没有结果检查
录制的脚本不便于理解和修改，可维护性、可继承性不满足长期自动化积累的需要
缺点
robot早起录制回放
TCL是面向对象的语言，没有太成熟的开发环境，用例事项和调试效率低
TCL ( Tool Command Language)
用例可读、可继承性不足
TTCN（Testing and Test Control Notation）
TCL和TTCN编写用例
将测试用例的操作过程和测试数据分离，操作过程用程序实现，用例简化未一条机构化数据
概念
只需要调试过程实现，几乎不用对用例进行调试
对于操作过程复杂且变更频繁的特性，用例的维护很困难，几乎无法复用
数据驱动
将测试用例的操作过程和测试数据分离，并将操作过程分步骤、分层抽象成AW，自动化用例使用 AW搭建
通过关键字的抽象简化了用例脚本，用例实现和调试效率高
自动化实现的主流方案
关键字驱动（ActionWord AW）
在AW的基础上，用建模的方法进行测试设计，测试用例和自动化脚本基于模型生成
不够成熟，对测试工程师的逻辑分析能力有较高要求，模型搭建和调试效率不高
1）使测试快速响应变化
集成模型是成果的继承，也是设计思路和经验的继承
2）提升测试设计的可继承性
3）更有效的参与前端的研发活动
未来的主推方案
基于模型的测试（MBT）
从上到下为自动化的演变阶段
自动化的几个代表方案
新产生的测试用例在第一时间实现自动化
核心能力
测试充分性快速提升：老代码持续验证
全流程质量保障面临的最大问题不是质量，而是进度和效率
用进度和效率作为切入点
目标的设定
尽早开展需求验证；新代码快速、充分验证；老代码持续验证。
1）自然生长模式
先按照标准模型实施阮成软件测试的各项活动，再进行改进
2）削足适履模式
演进策略的确定
全流程质量保障要求在研发各环节都要紧密配合，只靠测试自己不可能做好
效率和进度的风险是引入质量保障活动的切入点
可以有效的将测试的负载分散到研发的各个环节，使研发过程不算释放风险，从而避免全部风险都堆积到产品发布之前
目标方案
全流程质量保障的能力模型
关键测试能力要求
全流程质量保障
基于需求的测试，并且在这些而是中尽可能模拟客户使用产品的各种条件，使得测试结论和客户评价接近或一致
客户需求、客户想要解决的问题、客户的应用场景根本没有落在测试的依据范围之内
使产品团队对产品质量有准确的认知
帮助研发团队做出相应的人员和时间安排
过程质量评估
产品质量评估
核心工作
方法和工具
目前暂无适用范围较广的方法和成功实践
客户视角的过程质量评估
在测试设计和执行时，将客户信息作为输入信息之一
测试设计、指标设计：输入多样化
测试环境：尽可能模拟
用例执行、指标测量：高度仿真
客户视角的产品质量评估
探索测试
常用的方式
探索范围确定
功能差异分析
对主要业务流程指标兼容性、支持的制式、满足的标准和规范等进行对比实测
DFX对比分析
分析过程
找到字眼产品和竞品的差异，进而影响项目走向，帮助完善产品
竞品分析
客户信息获取的渠道
客户视角质量评估能力模型
客户视角的质量评估
7、产品质量屏障
帮助改善需求质量，提前暴露需求问答题，缩短从需求提出到商用的周期
利用需求内容模型（5W1H）促进需求内容完整性的提升；利用测试对产品、业务的理解，通过静态测试法发现需求中的遗漏、矛盾、错误
改善需求质量
根据需求进行单个操作、业务场景和应用场景的测试
基于需求测试
需要做到
业界调查数据：每500份需求文档中只有2分是完全正确、完整的所以不能只是基于需求文档的测试
最核心的就是基于需求测试
在测试设计中针对需求的各个层次，设计特性的应用场景和业务场景测试用例；测试执行时可以邀请客户和需求工程师参与体验和演示等方式进行纠偏
测试人员可以做的工作
主要方法
模型
客户想要解决什么问题，达成什么目的
最重要
业务需求（Why）
由什么角色（Who）在什么条件下（When）在哪个功能入口（Where）使用什么功能的操作（What）来达成业务目的
如何实现用户需求
软件需求（How）
需求变更变的是功能需求，业务需求几乎不会变只是一开始业务需求大家都没说清楚而已如果不能从业务需求角度去分析，就只能看到看似零散的需求，而且每个需求度很急
需求5W1H分析
测试对象：单个操作
测试目的：验证在各种条件、输入的组合情况下，操作结果是否和需求描述一致
基于规格的测试（需求规格说明书）
软件需求
测试对象：完成一次业务处理的一组操作
测试目的：验证在各种条件、输入的组合情况下，业务处理流程和操作结果是否和需求描述一致
业务场景测试
用户需求
测试对象：针对一个商业或管理目标完成的 业务处理、运营、管理等一组操作
测试目的：验证操作的过程、操作结果之间的逻辑关系是否和需求描述一致
应用场景测试
业务需求
需求的分类及对应的测试
基于需求的测试
常用的分析和设计方法
端到端应用场景测试
最基本的质量保障价值
使质量符合设计要求
提升基本型需求的研发质量
使质量符合客户要求
提升期望型、兴奋型需求的研发追李昂
使质量符合客户期望
图
客户访谈、调查问卷、体验测试、特性演示等
业务场景、应用场景测试
领域知识
能力
代表客户测试
测试保障质量的三个层次
主导完成好产品交付相关活动，按计划达成活动目标
除了能够做好测试工作、管好产品交付活动本身，还需要能够承担需求采集的部分工作，有比较全面的问题定界和解决问题的能力，最好还能够制定过程管理和活动实施流程的相关规范，推动研发持续改进
管理与技术并重
研发阶段尽可能拦截问题；使用客户的方法评估产品
及时解决问题，一方面使得活动有序开展，让客户问题不至于影响研发进程；一方面使客户对产品的按计划按要求交付保持信心
减少问题；降低问题影响
问题定界和解决
需求采集和澄清
范围管理
时间和成本管理
质量管理
沟通管理
项目管理和流程制定
具备一定的项目管理能力
掌握基本的需求采集技巧
掌握环境和业务问题的定界、定位和解决方法
产品交付专家的能力模型
产品交付专家
8、产品交付先锋
测试联合研发及客户的相关角色，共同推动研发质量、改进效率，使产品质量、交付效率持续提升
问题分析及指定解决方法
说服利益相干人投资
做好沟通管理，信息及时披露
测试驱动研发改进
测试驱动产品质量改进
测试驱动用户体验提升
注意：直接当事人的原因分析意见必不可少，切忌由测试人员包办根因分析
根因分析法
问题分析方法
自动化——可以帮助开发进行功能验证，提高特性开发质量
基本功能测试用例——作为特性提交的门槛条件，可以控制研发过程质量，提升整体效率
工具——提升产品运营维护的问题定位、健康检查等工作的效率
基于已有的成果开展工作
问题分析及解决方法制定
围绕业务问题而不是技术
背景信息至少包括：问题影响、问题的原因、研发各角色做过的努力和遇到的困难等
问题背景清晰明了
推论的证据链严谨
对问题及其解决方法又独特且具启发性的见解
逻辑清晰、层次分明、概念准确
将“自己”代入问题和解决方案
需要注意的几个基本问题
让问题和解决方法具备说服力
过程目标
需要分解为过程目标，以方便在项目过程中进行沟通
结果目标
研发项目启动的时候需要设定可度量的改进目标
监测过程目标
开发过程中
同时监测过程性目标和结果性目标
项目试点和应用时
包括本阶段的主要过程性目标及其达成情况
目标是什么
对进展进行简短的总结，是否完成看应用结果而不是交付件
已经做到了哪一步
下一步主要工作及其责任人、完成标准
下一步行动
包含的内容
沟通
目标制定和沟通管理
驱动研发改进
如产品必须经过制定的机构测试和认证
认证测试
如兼容性测试
设备成本高昂的测试
如安全性测试
人力成本高昂的测试
分类
测试可做成服务
独立的第三方评估
9、产品测试以外的价值
主要是通过提前测试，实现研发内部的效率改进
（1）全流程质量保障（效率）
工作的侧重点是让测试的数据和结论被客户认可和信任，倒逼研发重视测试的结果
目的是研发改进
（2）客户视角的质量评估（质量）
最终目的：缩短从需求提出到可以商用的周期，即缩短产品交付给客户使用的周期
（3）代表客户测试（质量）
让产品交付活动尽量不呗阻塞，顺畅、高效的开展
（4）产品交付专家（效率）
常见的4类价值
质量屏障与产品交付相关价值的关键技术
测试的拓展价值
需求实现的准确、完整；交付用户使用后的一段时期内，针对既有特性的改进、返工都很少；用户使用中法发现缺陷的数量和级别符合质量要求
支持的改进目标
需求完整
需求透明传递
需求变更同步
实例化需求
商用评估
需要具备的特性
需求的分析、设计和开发
需求的测试
需求的背景
需求和设计评审
测试分析和设计
测试执行和自动化
质量评估
需求的全部信息包括
基于需求测试的测试架构
缺陷修复高效、准确，缺陷一次性修复完成，修改代码不带来新的问题
缺陷定位信息完整
要能够从测试用例集中自动挑选与修改代码相关的用例
高相关性测试用例挑选
测试环境快速获取
自动化测试
需要具备的特点
缺陷快速修复的测试架构
是测试在质量和效率方面的业务能力的集中体现
版本快速稳定
是测试在质量和测试过程方面的管理能力的集中体现
质量随时可视
太简单，5W1H信息不完整，很多“一句话”需求，导致测试只能验证设计，无法真正验证需求：需求变更后设计、实现和测试没有同步变更，导致在开发后期才能开始测试设计，进度过于紧张影响测试设计质量
新功能开发或缺陷修改后，开发者测试的覆盖率低
缺陷修复整体效率低，代码修改后的验证机制不健全、覆盖不完整，缺陷修改容易引入新缺陷。
缺陷修复
需求和设计评审、单元测试等活动发现的缺陷很少，缺陷的发现过于依赖系统测试，研发整体效率不高，风险聚集在研发后端。
测试策略
新特性未恩能够尽早实现自动化测试、DFX测试自动化率低，新特性和老特性的覆盖不足；带病迭代的现象普遍，敏捷开发没有带来质量和效率的提升
迭代测试
子主题 1
测试手段缺乏，难以模拟客户真实的操作场景，导致测试结论与客户使用感知到的产品质量偏差较大
系统测试
总结
质量标志性数据包含两方面：①度量数据（5~7项）②需要特别关注的风险
形成了研发团队一致认可的质量标志性数据
1、质量可视
从研发活动开始，质量标志性数据就在持续刷新，随时可查询
2、随时可视
包含两方面
质量可视
影响目标的主要问题
测试架构的目标工作场景
就是讲各个鼓励的工具和信息集成到面向任务、入口统一、数据源一致的系统之中，实现信息充分共享，并且能高效、便捷地应用
信息内容结构化
信息关联
成熟的集成架构
共性技术问题
测试架构的建立
支持拓展价值实现的测试架构
是BDTPI“商业目标驱动的测试过程改进”
TPI模型全称
可以帮助测试团队确定，达成目标需要开展哪些方面的工作，不仅是技术方面的工作，还包括管理和组织方面的工作
TPI模型作用
用TPI NEXT 模型确定需要开展的工作
客户细分
价值主张
渠道通路
客户关系
核心资源
关键业务
重要伙伴
需考虑点
画布
用商业模式画布进行项目策划
测试主管必须亲自负责，可以避测试团队被产品测试和技术提升两座大山彻底压垮
设定合理目标，管理预期
价值拓展的辅助工具
10、测试拓展价值总结
有能力拓展的、新的价值：①产品质量方向②交付效率
三、展露锋芒
测试存在的根本原因——是因为人都会犯错误
DFX测试——可靠性与安全性测试RBT——基于风险的测试
测试的基本价值：①发现缺陷②提供数据价值切入点：围绕进度、成本、质量去找
测试价值提升
收藏
收藏
0 条评论
回复 删除
下一页
