测试架构师修炼之道
2025-05-18 11:23:01 0 举报AI智能生成
软件测试架构师修炼之道
作者其他创作
大纲/内容
职业规划
1、测试工程师三年之痒
1.1软件测试发展史简介
1968年软件危机
提出软件工程：1、如何维护不断增长、复杂的需求；2、如何维护数量不断膨胀的软件产品
软件测试起步
提出软件工程：1、如何维护不断增长、复杂的需求；2、如何维护数量不断膨胀的软件产品
软件测试起步
1975年《软件数据选择原理》
测试的目的：证明软件工作正确的活动
“证实”
测试的目的：证明软件工作正确的活动
“证实”
1979年《软件测试的艺术》
认为测试是为了“发现错误而进行的活动”
证伪
认为测试是为了“发现错误而进行的活动”
证伪
1983年《软件测试完全指南》
测试是以评价一个程序或者系统属性为目标的任何活动，测试是对软件质量的度量
缺陷预防
测试是以评价一个程序或者系统属性为目标的任何活动，测试是对软件质量的度量
缺陷预防
20世纪90年代
软件成熟度模型（TMM）、测试能力成熟度模型（TCMM）
测试体系化
软件成熟度模型（TMM）、测试能力成熟度模型（TCMM）
测试体系化
2002年《系统的软件测试》
测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程
全生命周期测试
测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程
全生命周期测试
1.2敏捷开发下的软件测试
新需求以及问题
质量高、交付快、适应不断变化的用户需求
瀑布开发模型难以适应要求
版本时间周期长、测试迭代时间周期长、遗留缺陷拉扯周期久、测试对产品发布有一票否决权
新的解决方案
2001《敏捷软件开发宣言》、2008年通信大厂（诺基亚、爱立信、华为、中兴）引入进行敏捷开发，互联网BAT也开始推行敏捷实践
《敏捷软件测试》
专业的测试人员，适应变化，与技术人员和业务人员展开良好协作，并理解利用测试记录需求和驱动开发的思想。他们具有优秀的技术能力，知道如何与他人合作以实现自动化测试，同时也擅长探索性测试。他们还希望了解用户在做什么，以便更好地理解用户的软件需求。
1、协作能力
2、专业技术：实现自动化能力
3、探索性测试
4、了解用户在做什么
2、专业技术：实现自动化能力
3、探索性测试
4、了解用户在做什么
DevOps《开发即运维》
通过持续集成（CI）、持续交付（CD）的自动化流水线，再次缩短产品发布周期，做到每日发布或者每日多次发布
在DevOps开发模式下。测试也从瀑布开发模式下的后端验证，发展为全流程下无所不在的测试。
在DevOps开发模式下。测试也从瀑布开发模式下的后端验证，发展为全流程下无所不在的测试。
不同模型对照
测试人员可以做什么
测试人员可以直接和产品人员沟通交流，参与产品规划；
测试人员可以直接和用户交流，手机需求，澄清问题；
测试人员可以想开发人员一样 去编码
测试人员可以做工具，做自动化；
测试人员可以做流程，做质量改进；
1.3测试人员面临的机遇和挑战
2011年GTAC大会上，抛出“Test is dead”（测试已死）
测试是不是无用了
测试人员是不是要被淘汰了
测试行业是不是要消失了
测试人员的路在何方
究竟无用还是全能的测试
敏捷模式下
测试不再只有测试人员进行的工作
测试人员对业务能有非常深入的了解，可以聚焦创造价值
测试人员对产品设计能够深入理解，可以阅读代码并进行单元测试或者接口测试
敏捷模式需要要求测试人员可以进行规模化的自动化测试
测试独特价值的消失和敏捷开发模式下新的要求，导致出现这种“测试无用论”根源
不同模式下的测试
瀑布
需求—>设计—>开发—>测试—>发布
敏捷
需求—>持续迭代（设计+开发+测试）—>发布（反馈）
DevOps
设计-编码-构建-测试-发布-部署-运行-监控一整套体系
总结
敏捷开发对测试人员来说是一场解放运动，需要测试人员在思维和能力方面做出相应的改变。
项目、产品、研发、运维，每一项都有其自身的专业性，如果测试人员仅凭敏捷的旗号，不去学习和理解这些领域的内容，不去思考测试视角在这些领域能够起到那些作用，对人员和团队来说都是损失
测试的困境和迷局
敏捷模式带来了新的问题，并且没有解决那些测试中的历史问题；
历史问题
1、新生测试力量缺乏对测试行业的正确理解
学校
退而求其次的选择
编程能力不怎么样，先找份测试工作做着
成绩不太好，开发不行，先投测试
。。。。
社招
通过测试培训机构加入软件测试行业，将软件测试作为过渡
2、管理者对测试缺乏正确认知
绩效上更认可开发人员的工作
资源上更偏向开发人员
重开发，轻测试
”只有开发才能创造价值，测试不仅不能创造价值，还是一种开销“
好质量是测试出来的，测试的价值就是找缺陷
3、不合时宜的要求
一些瀑布或伪敏捷团的，在文化、组织、能力、资源没有任何变化的情况下，开始按照敏捷开发的要求对测试团队进行调整
内容
追求低测试开发，盲目减少测试人数
过分看重测试编码能力，否定测试其他能力
追求自动化率，但设计、流程跟不上，接口/UI频繁变化；
要求普通测试人员掌握非常专业的测试，比如安全测试
4、低门槛和测试外包
单从入门看，软件测试确实比较容易，但要想成为测试高手，就必须对用户、系统、设计实现等均有深入了解，还要努力培养测试思维：系统思维、批判性思维、逆向思维和解决问题的思维。
对于测试外包人员来说，频繁地跟换测试产品，导致其无法了解产品核心设计，缺乏归属感，容易一直处于一种低水平的测试状态
5、缺少发展和规划
从质量守护者到产品赋能者
敏捷开发给测试带来的是挑战，更是机遇
VUCA
易变（volatility）
不定（Uncertainty）
复杂（Complexity）
模糊（Ambiguity）
我们已经进入VUCA时代，VUCA时代复杂多变，模糊不确定，没有固定的套路可言，需要我们能够跳出局部，通过系统性思考综合各领域的知识来解决问题
专业、综合、适合变化
警官savoia提出“测试已死”的论调，但在演讲的后面提及
真正死去的，是那些传统模式下重复的、低效的、堆人的测试，取而代之的是那些更加专业的测试，这些测试不仅不会死，还会成为抢手资源
聚焦
场景测试
聚焦如何模拟用户的实际使用场景，如何还原用户的操作
性能测试
聚焦如何测出系统的短板和瓶颈，如何确保系统性能满足用户的真实使用场景
更高效的探索式测试
更有效的测试策略，从根本上提升测试效率和质量
优势
测试人员不容易陷入实现细节中，更关注用户的使用，关注用户显性和隐形的需求，更具备全局性系统思考的条件
遇到问题后，测试人员比开发人员更容易跳出局部，看到问题的根本原因，从而更有效的解决问题
VUCA中对于同一个功能不同的用户可能会有截然相反的意见。使得产品只在开发设计中都没有标准答案，“测试语言”（判断测试是否通过的标准）往往成为解决问题的关键。一个专业的测试人员可以基于“对行业的理解”“对用户行为的剖析”“对使用场景的分析”“对友商和竞争对手的了解”等对测试是否通过做出判断
2、测试工程师执业规划
2.1测试人员的执业发展方向
管理和技术是测试人员的主要发展方向。敏捷开发模式下开发和测试融合，扁平化管理等趋势使得专注于测试技术的人员也有了更多的职业发展选择
管理上的发展
定位
职位
经验要求
管理规模
负责对象
工作内容
基层测试管理者
测试组长
2-3年
2-5人
版本，项目
安排小组工作
提升小组成员测试能力
负责重要测试工作
提升小组成员测试能力
负责重要测试工作
中层测试管理者
测试经理
3-8年
10到几十人
产品
团队管理
团队能力提升
产品测试管理
团队能力提升
产品测试管理
高层测试管理者
测试总监
5-10年
几十到上百人
产品线
团队管理
效能提升
组织能力建设
效能提升
组织能力建设
技术上的发展
产品测试专家：测试架构师
主要职责是对不同的组织、产品、研发模式做出最适合当前状况的选择，进行纲刚刚好的测试，为产品成功保驾护航，提供支撑
作用
负责产品测试的整体架构设计
负责需求和实现向测试的转换
负责测试技术重点的预研和攻关
产品测试的“灵魂”
能力
技术规划能力
业务建模能力
数据分析处理能力
面向产品生命周期的质量保证和持续该机能力
测试技术专家
根据测试活动不同分类
测试分析设计
测试分析设计专家
测试评估
测试质量评估专家、缺陷分析专家
测试执行
探索式测试专家、自动化测试专家
测试流程
测试流程专家
根据质量属性
功能性
安全性测试专家
易用性
易用性/用户体验测试专家
效率
性能测试专家
可靠性
稳定性测试专家
可靠性测试专家
测试开发人员
偏向自动化测试架构测试开发工程师
偏向效能、工具链测试开发工程师
开发结对的测试开发工程师
测试开发技术栈
角色和段位
测试一段： 能执行
能根据测试用例的描述步骤来执行测试用例，能对照用例
的预期结果发现产品的问题，能够清晰准确地将问题记录下来后反馈给
开发，开发能够读懂问题描述的含义；
测试二段：能设计
理解用户需求和产品实现、能够分析、设计测试用例
测试三段：能深入
深入理解用户需求和产品实现，注重测试设计、执行的有效性
测试四段：能带队
带领一个小团队完成测试任务，能有效评估产品质量，给出建议。
测试五段：能固化
能将测试方法标准化，并固话测试工具和流程，关注测试过程改进
测试六段：能引领
在某些领域是行业标签
质量领域的发展
企业流程建设
IPD全流程体系框架
企业质量管理者
质量管理三部曲
第一部：质量策划
致力于指定质量目标并规定必要的运行过程、准备相关资源以实现质量目标
第二部曲：质量控制
致力于满足质量要求
第三部曲：质量改机
致力于增强满足质量要求的能力
研发工程效能领域发展
五个基本流
价值流
从用户需求到产品开发，最后交付给用户产生价值的过程
数据流
从交付件（比如需求文档、特性列表、规格类表、代码、软件包）角度秒速的在不同活动下的输出
活动流
研发过程中各种活动，需求分析活动、开发活动、测试活动等
能力流
主要包括软件需求分析能力、软件建模能力、架构设计能力、编码中对代码进行静态分析和检查的能力、对系统配置管理能力、快速构建能力、自动化测试能力、自动化部署能力、监控当前产品过程数据能力、进行度量分析能力
工具流
通过工具/平台提供管理、规范/知识库以及各种能力
1、自动化工具/平台设计专家
自动化工具/平台建设专家负责自动化测试架构的设计、选型和搭建；保证团建自动化测试高效进行
2、软件工程专家
软件工程
发展方向举例
需求分析
实例化需求；
用户故事/任务；
需求闭环管理
用户故事/任务；
需求闭环管理
代码开发/测试验证
代码静态检查；
CI/CD/DevOps;
TDD
基于各种模型的测试策略；
性能优化/测试
DFX测试
CI/CD/DevOps;
TDD
基于各种模型的测试策略；
性能优化/测试
DFX测试
架构/设计
设计模式
DFX设计
DFX设计
部署/发布/运维
共同主干开发/发布
灰度发布
3、度量专家
工作
为团队或组织设立适合的项
设定团队或组织能力基线
在项目过程中通过度量数据量化分析预测风险
度量项参考
devops
度量项
构建
自动化测试数量
代码构建成功率
单元测试成功/失败率
总缺陷数量
代码覆盖率
代码构建成功率
单元测试成功/失败率
总缺陷数量
代码覆盖率
功能测试
测试的需求覆盖度
严重缺陷
测试用例执行成功/失败率
缺陷密度
风险覆盖情况
严重缺陷
测试用例执行成功/失败率
缺陷密度
风险覆盖情况
端到端测试
端到端自动化测试用例数量
测试的需求覆盖率
总缺陷数量
测试用例执行数量
测试用例覆盖率
测试的需求覆盖率
总缺陷数量
测试用例执行数量
测试用例覆盖率
4、工具开发专家
项目管理工具开发
需求管理系统、测试用例管理系统、缺陷管理系统
知识管理工具开发
wiki、规范库、模式库、知识库等开发
开发工具开发
代码巡检工具、代码安全性工具等
2.2测试执业规划建议
做管理还是做技术
做技术有心得，就可以去做管理，去进一步推行自己的心得；反过来做管理有余力，就应该再去做技术
测试能力
业务能力
立即用户的需求和使用场景、理解产品的核心价值，能够提供有竞争力的产品改进建议
技术能力
指各种测试技术的掌握能力，包括测试分析和设计能力、测试方法和测试执行能力、自动化测试能力、质量分析和评估能力等
管理能力
包括项目管理能力和团队管理能力
关于跳槽
薪资问题
做得不开心
发展问题
不断提升影响力
不是谁资深谁就有影响力，而是谁能解决问题谁就有影响力
测试架构师目标迈进
1、测试架构师应该做和不应该做的事情
1.1需要关注和不需要关注的事情
1.在需求分析阶段
重点工作包括
理解需求
制定一份总体测试策略，以此来确定测什么和怎么测
想要真正对需求有透传理解、理解所测产品的商业目标、核心价值和用户的使用场景是第一步，也是测试策略的源头
理解产品的商业目标和核心价值
了解商务
了解你的公司
了解你的客户
了解你的领域
测试活动考虑的内容
如何验证待测试的产品正确提现了市场价值
所做的测试策略是否和公司的财务、销售、营销目标一致？
梳理用户的使用场景
梳理用户使用场景
产品的用户类型，用户业务，客户从你的产品中获得的价值？
产品的竞争对手为用户提供了哪些有价值的解决方案，和自己产品的差异是什么？
产品所在领域有哪些基本的规范和要求，行业背景有哪些？用户习惯是什么？
归纳测试场景
针对不同用户确定用户的行为习惯和关注点
逐一分析用户会如何使用产品，根据分析结果建议产品的拓扑模型、配置模型、流量模型等，抽象出典型场景
确定各个典型场景下的输入和输出（包括正常输入和异常输入、以及测试时间长短等）
输出产品总体测试策略
总体测试策略是测试架构师的重要输出之一
测试总纲，帮助整个测试团队明确测试的范围、目标，测试的重点和难点，测试的深度和广度，以及如何安排各种测试活动（测试分层）
测试重点和难点
两者不同，重点主要通过产品价值和质量目标等因素确定测试的优先级；测试难点是从测试技术的角度对产品测试验证难易程度分析
测试深度和测试广度
测试广度从覆盖层面对产品进行描述，测试深度从测试方法角度对测试进行描述
测试分层
把一个复杂的测试分成多个不同的阶段，每个阶段都有自己的测试目标和出入口条件
说明：把需求分析、测试分析设计、测试执行、测试质量评估等测试活动比做珍珠，测试策略就是串联所有 珍珠的线
2.测试分析和设计阶段
测试架构师和测试设计负责人一起沟通确定“测试设计大纲”，以此来保证测试设计中测试的覆盖度（深度和广度）“刚刚好”
3.在测试执行阶段
说明：测试架构师不应该把自己完全陷入测试执行中，而应该根据实际情况，分析当前测试项目和计划的偏差，选择适合的测试用例，跟踪测试过程，调整测试策略
确认和计划的偏差
确认项目实际情况和计划的偏差
给出最适合测试和研发团队的方案和建议，还需要具备基本的版本迭代管理知识，应对测试时间被压缩、工作阻塞和返工等情况保持版本节奏
选择合适的测试用例
在测试执行中，测试架构师需要根据不同的测试目标来帮助团队选择合适的测试用例，包括接收测试用例、每个版本的执行测试用例和回归测试用例
跟踪测试过程
确定缺陷修复的优先级，让测试阻塞的部分可以尽快被执行，失败的部分可以尽快通过，对于那些非必现的缺陷，测试架构师制定有效的处理机制
4.在质量评估阶段
测试前，将产品质量评估模型中的内容作为测试目标，以达到测试目标为目的来进行各种测试活动；
测试中，我们不断确认质量目标的完成情况
测试完成后，可以使用产品质量评估模型来确定质量目标的达成情况
1.2像架构师一样思考
很多公司并没有设计测试架构师这样的职位，职位并不重要，需要有人能够像测试架构师那样，从被测对象的实际情况出发，系统思考，抓住本次测试的核心，通盘考虑测试策略
本次测试的目标是什么？
本次测试的范围是什么？
本次测试的深度和广度是什么？
本次测试的重点和难点是什么？
如何安排测试（先测什么，再测什么）？
如何评估测试结果？
1.3测试管理者可以替代测试架构师吗
测试管理者可以兼职但不能替代测试架构师
1.4系统架构师可以替代测试架构师吗
2、测试架构师知识能力模型
2.1测试架构师必备的能力和知识体系
必备的6个关键能力
明确测试目标、测试重点的能力
不仅仅从设计开发明确测试目标，还能从产品价值、质量目标的角度来明确测试目标
敏锐的风险识别和有效的风险应对能力
对产品当前的风险进行多维度的分析，找到有效应对风险的方法
测试分析、设计和执行能力（包括工具和自动化）
不断总结优化测试方法，把繁琐的工作用自动化方式完成
质量分析和评估能力
能够通过过程分析、缺陷分析来评估当前产品/特性的质量
有效沟通的能力
能够通过沟通获取和交换有用信息
持续学习和探索的能力
包括总结、持续探索、持续改进、引入新技术或新方法
2.2软件产品质量模型
理解质量对测试如此重要
测试本身是镜子，照出系统面貌，测试要对有效的质量评估负责
质量的核心目标是满足需求
提出的需求我们不一定理解，我们需要借助模型来进行系统分析，识别那些隐藏的需求，预防缺陷
软件产品质量的8个属性
功能性
说明：软件产品在指定条件下使用时，提供满足明示和隐含要求的功能的能力
子属性
完备性
功能集对指定任务和用户目标的覆盖程度
正确性
产品或系统提供具有所需精度的正确结果
适合性
功能促使指定的任务和目标实现的程度
功能性的依从性
产品或系统遵循与该功能相关的标准、约定或法规以及类似规定的程度
兼容性
说明：软件产品在共享软件或者硬件的条件下，产品、系统或者组件能够与其他产品、系统或组件交换信息，实现所需功能的能力
2.3基于质量的测试方法
2.4功能性测试方法
2.5可靠性测试方法
2.6性能测试方法
2.7易用性测试方法
2.8安全性测试方法
2.9基于车轮图的测试分析方法
2.10基于模型的测试设计技术
2.11控制测试用例的粒度
2.12影响测试设计效果的因素
2.13基于场景的测试方法
2.14探索式测试
2.15自动化测试
3、测试架构师软能力修炼
3.1沟通和协商
3.2写出漂亮的测试用例
3.3组织和管理测试用例
3.4持续学习和探索
架构师核心技能
1、如何制定测试策略
1.1什么是测试策略
1.2四步测试策略的制定法
1.3产品质量评估模型
1.4组合缺陷分析技术
1.5特性价值分析技术
1.6风险分析技术
1.7不同研发模式下的测试分层技术
2、制定基于产品质量的测试策略
2.1项目背景
2.2制定总体测试策略
2.3制定测试设计策略
3、产品质量评估和测试策略调整
3.1确认和计划的偏差
3.2选择测试用例
3.3测试过程跟踪
3.4产品质量评估
4、基于价值的测试策略
4.1再谈测试策略
4.2不同产品阶段的测试策略
4.3探索式测试策略
4.4自动化持续测试策略
0 条评论
下一页
