如果说拦截缺陷、提供数据是研发对测试提出的“
显性需求”，测试过程可控就是对测试提出的“
隐性需求”。
测试过程可控是指测试的周期和投入稳定，工作质量可被产品团队和客户接受。测试的质量、成本和效率的提升和研发整体的提升
同步。
过程可控的本质是测试团队的能力的
稳定和持续提升。团队能力的载体包括：
技术方法和工具、流程、组织和人员、平台。
团队能力各个载体的作用如下：
1、
技术方法和工具：是将个别人的能力总结为有形资产，成为可学习和传播的团队能力。
2、
流程：是将团队能力固化成为流程活动，使之成为持续产生作用的能力。
3、
组织和人员：是能力最根本的载体，能力落地的标志，应该是有一定比例的团队和人掌握了相关的技术、流程和平台。
4、
平台：是能力持续发展与传播的环境和保障。
5.1能力建设实施要点
5.1.1从
问题出发寻求适合的能力建设方向
能力建设分为两类：
被动的（质量或效率出问题，提升能力才能根本解决）；
主动的（有支配资源，主动寻求能力提升，实现团队增值）；
出现各种能力成果差的根源在于
决策环节。
对问题的分析应该包含几个方面：
1、
问题的来历。外在表现？初步判断？
2、
内在原因。掌握问题的根源。
3、
测试的问题。找到问题和原因就找到了工作的目标。
持续搜集和分析客户验收、应用中发现的问题是必须做的日常准备，这事测试能力的根本，与测试设计和执行同等重要。
5.1.2拓展测试领域知识的
广度
拓展测试知识广度比较推荐的途径是，从“
测试藏宝图”或者“
软件测试全景图”开始，以这个藏宝图或全景图为地图，形成对测试技术的框架性了解。
还有一些技术性的
会议。
此外，还有一个非常重要的渠道是向
身边人学习，公司内、团队内的测试工程师也可以进行定期的
分享和交流。
5.1.3能力建设需要有架构设计
测试过程可控面临的真正挑战，是建成的能力如何更好地适配项目环境的变化。
在开始进行一项能力建设时，需要有
顶层设计：方法、流程、人员、平台各自解决什么问题，怎样配合才能使得在具体的项目中，在保证质量、成本、效率目标的前提下，让能力发挥作用。
测试团队能力涵盖的范围非常
广，需要有一个
蓝图性质的视图，蓝图可以从研发流程、测试类型、产品层次等几个角度来设计。蓝图的主要作用是在思考如何解决问题的时候，帮助建立一个全局的
视野，避免过于偏重某个方面。
5.2方法和工具方面的能力建设
典型的有：测试设计方法、测试策略分析的方法、自动化的方法和工具、缺陷分析的方法、环境管理的方法和工具等。
作用：方法和工具在团队能力中是解决“
怎么做”的问题的。理想情况是，每一项具体的工作都有其对应的做事方法，最好有相应的工具提高工作的效率。
5.2.1测试方法和工具方面的能力
测试使用的方法和工具，有多重分类维度。
按
应用阶段分为：测试策略和计划、测试设计、测试执行和自动化、测试评估、环境管理、缺陷分析等方法和工具。
按
验证内容分为：功能、互操作性、一致性、性能、可靠性、安全性、可服务性、国际化等测试方法和工具。
按
测试方式分为：脚本式、探索式测试方法和工具。
按
测试的目的分为：以项目早期控制风险为目的的静态测试，以验证需求发现缺陷为目的的常规动态测试，以评估用户真实感知为目的应用场景测试或体验测试，以保障重要客户正常运营为目的的镜像测试等。
技术能力
公共的部分包括以下内容：
1、
风险和策略分析。主要版本进行了测试策略分析，策略中制订了研发各阶段的测试活动和质量要求，约定了各活动的分工和配合原则。
2、
测试设计。
a、
功能测试设计。测试设计包含了对特性的业务场景、性能、易用性、故障注入、安全攻击等方面的考虑。
b、客户应用
场景测试设计。场景测试设计覆盖了全部功能需求，覆盖了所有用户角色并包含了各角色的常规和非常规使用行为，覆盖了运营行为和管理行为。
c、
性能测试设计。覆盖了指标和稳定性。主要业务流程、业务质量标准都有对应的性能指标用例。性能稳定性考虑了常规、非业务流程的混合，覆盖了常见的压力模型（长时间平稳、线性增大、抖动、浪涌等模型）。
d、
可靠性测试设计。可靠性特性的功能测试；故障注入测试；可靠性指标的测试；
e、
安全性测试设计。进行了脆弱点、敏感数据、安全威胁模型分析。覆盖了网上问题分析发现的漏洞模式，覆盖了组网、接口、OS、DB、应用软件的安全漏洞。
f、
可服务性测试设计。覆盖了新装、升级、日常检查、故障处理场景，覆盖了可服务性相关文档、帮助、工具、特性。
g、
自动化测试方案设计。确定自动化测试的范围、优先级。
3、
测试执行。
a、
自动化测试。能够在测试完成后、测试中、测试前完成自动化用例的编写和调试，且效率满足版本研发进度的要求。
b、
数据准备、采集、分析。具备测试数据的自动生成和数据合法性检查工具，具备功能、性能、可靠性、可服务性测试过程数据的采集工具。具备数据分析辅助工具，能够根据采集的数据绘制图表、自动标识异常数据。
c、
环境安装。利用工具实现测试环境的全部准备工作，包括安装、配置、检测、业务调试、备份、恢复。环境准备效率高，或者能够一键式自动化完成。
d、
仿真测试。能够仿真产品实际使用的环境特征；能够仿真产品使用时的用户特征。
e、
问题检测和定位。利用工具辅助问题的定界和定位，工具整合了日志、告警、检测，和其他记录的信息，并具有辅助分析功能。
4、
测试评估。
a、版本质量
评估。测试结论基于过程、效率、覆盖、缺陷、风险等信息给出。
b、过程数据
分析。对过程数据的分析内容和版本、特性、DFX的质量和风险结论相互印证。
5、
探索式测试。
a、
活动定义。确定了产品测试中如何开展探索式测试。有明确的探索式测试开展的阶段；范围，指哪些测试内容引入探索式测试；启动条件；结束标准。
b、
活动管理。探索测试活动基于session管理，每个测试活动都满足以下要求。有明确的目的；有优选的探索方法或启发式；有确定的时间；有良好的过程记录，包括完成的探索点、缺陷、测试过程中出现的特殊现象等都有记录。
6、
持续集成。
能够自动化完成环境安装、配置、检测、自动化用例测试、错误现场记录、报告生成。自动化用例执行过程无需人工干预，并且在8h内完成。
7、
环境管理。
功能、性能、可靠性以及其他DFX、镜像测试环境统一管理，申请和释放便捷，环境有较高的利用率。
8、
发布后缺陷的修改和分析。严重以上的、由客户发现的缺陷进行RCA分析。
9、
测试用例基线。
10、
测试数据管理。工具实现测试过程数据管理。
11、
客户应用场景信息管理。信息覆盖了业务应用、运营和维护的角色，及各角色对应的应用场景、验收测试，包含组网环境、业务配置等信息。
12、
上下游协作。
a、
需求分析。测试团队中有固定的角色参与到产品需求分析活动中，在需求分析中对需求产生的背景、应用场景、接口、优先级、风险进行了澄清，确保性能、可靠性、安全性等相关的要求明确、可衡量、可验证。
b、
开发者测试。向开发者提供测试设计方法，使这个阶段测试用例质量满足相应的覆盖要求，且用例规模合理。向开发者提供测试工具，使用例能够正确测试，且效率满足进度的要求。
c、
特性划分。从产品到部件均按特性进行研发，产品和部件的特性建立了对应关系。
13、
持续改进。通过对项目过程数据综合分析能够发现设计、开发和测试过程的问题，并给出对本项目研发活动的改进建议，以及对测试能力各方面的改进措施。通过对发布后缺陷的统计分析，发现高风险的客户类别、用户角色类别、组网形式、场景、模块、特性、质量属性等，并给出针对性的能力改进措施。
千万不要把上面的清单作为测试方法和工具能力的蓝本或地图。
我们的产品测试，总的来说还是以
脚本式测试为主，
探索式测试只在缺陷验证、可靠性测试、功能补充测试中用的比较多一些，因此更多强调测试工程方面的方法和工具。
5.2.2能力建设首先考虑实用性
从我的经验看，一个二三十人的团队，同时进行3项能力建设已经是非常理想的情况了。首先做那些
有需要、有方法、能做好的方向。
成功的进行一项测试能力建设，需要“天时、地利、人和”的条件，案例所具备的条件：
天时：有必要（需要这项测试能力，解决问题的时机到了）；
地利：有价值（这项能力带来的好处对研发是明确的，能够获得研发团队的支持）；
人
和：有方法、有能力（能力建设可以在时间窗内完成，不会增加任务造成内部混乱）；
成果能持续应用（测试团队内部在技术方案选择上不会有大的分歧，能够聚焦到方案的实施上）；
需要说明的是，项目目标是所有一切的关键，项目目标决定了团队是否能够取得天时、地利、人和的条件。
总之，让测试技术建设匹配产品研发在整体上面临着问题，着眼于研发，而不是测试一个环节，这样能够让测试获得更宽阔的视野，获得更好地发展。
5.2.3探索式测试（ET）VS剧本式测试（ST）
探索式测试是比较符合人的
思维模式的，测试工程师原本也是在对软件的操作过程中不断产生对于测试设计的新想法。
剧本式测试是在探索式测试提出后，针对传统的先设计后执行的测试方式定义的一个名词。
探索式测试的优势有：
1、
较少工作浪费。尤其是较少文档工作量的浪费。比较快地适应软件开发过程中的需求和设计变化。
2、
较好的全系统思维。让测试工程师比较快速地建立对整个系统的认知。
3、
较快的缺陷暴露。很多测试团队实践数据显示缺陷发现的效率一般会提升20%-40%，BUG是有群聚性的。
4、
较快的质量反馈。探索式测试也是快速软件测试的重要手段。
5、
可以测试得比较深入。有更多精力去验证在开发、交互、组合等情况发生时，系统是否正常。
探索式测试应用中也有很多需要注意的问题。不同的人有不同的效果，管理者要有准确的预期。不同的测试效果是由不同的思维习惯和知识结构决定的。
session划分、session完成后的
总结非常重要。探索式测试和*随意的漫游式测试，最根本的区别就是ET是被仔细地管理起来的过程，session范围和目的的设计、不断质量反馈的
微循环、批判式思维等是ET的核心。
探索式测试的过程不容易追溯。
探索式测试过程中测试的用例不容易被继承和自动化。
需要基于信任去管理ET过程。
探索式测试和剧本式测试的
根本区别，当选择如何搭配好两种方式的测试时，主要考虑的因素是：希望对质量有多大程度上的
确信？测试的成果--用例，是否需要
继承并
自动化？是“群智”还是“英雄”对这个测试任务的影响更大？
纯粹的探索式测试和纯粹的剧本式测试都是比较少的，二者应该进行结合，
各取所长，
优势互补。
5.2.4测试设计VS自动化
当测试团队准备将有限的资源投入到团队的测试技术能力建设时，是该以建设测试设计能力为重点，还是以自动化能力为重点。
自动化常常是测试团队首先想要建设的内容，因为自动化的好处是明显的：
1、工作的
输出成果--工具、脚本框架、自动化用例，都是可以长期重复使用的，是“实在”的“可见”的成果。
2、自动化在
质量守护和问题快速反馈上起到了决定性的作用。
3、自动化几乎是测试活动的
终极形式。
4、当
MBT自动化逐渐成熟，自动化的一些顽疾也正在解决：
实现滞后；杀虫剂悖论；
自动化无法解决的最经典问题莫过于“减员增效”。自动化背负的不合理期望还有：用更高的自动化率使老特性在“未来”的应用中不出问题。
测试工程师需要发掘一些能引起各研发主管的
兴趣的价值，测试团队需要根据产品、团队的能力现状自行确定。和研发主管们就工作价值达成一致的主要目的是，
获得研发各个角色的支持。
测试设计：
测试设计的重要性是明确的。
1、测试
是否有效取决于测试设计。测试设计最重要的是明确测试的范围，测试范围直接决定了到底有多少内容需要测试，也决定了时间点到的时候，是否有可能完成必须的工作。
2、测试的
深度和质量取决于测试设计。测试设计思考的是产品/特性在什么环境、什么场景下使用，使用的时候业务流、数据流是怎样的，有哪些数据和特性参与了这个处理过程，如何产生影响。做好测试设计可能是测试人的终身修炼。有时候测试设计不是产生用例的唯一方法。
测试设计最典型的难题是：
再好的测试设计都是一个过程输出件，测试执行时是否都覆盖到了，观察点是否足够，是否有错误被忽略了，这些对测试质量的影响并不比测试设计小。现在开发-测试-设计一体化团队和探索式测试如此热门，很重要的原因就是，很多软件人意识到，
持续的思考、持续的试错、持续的沟通可能是软件测试最有效的方式。
好的测试设计还有一个难题--需要非常多的信息。除非有技术方面
革命性的突破，否则测试设计的难题，唯有通过时间和项目经验的积累来解决。
进行测试团队的测试技术能力建设时，应该选择自动化还是测试设计？
1、一般来说，如果
急需显示能力方面的建设，自动化是不二之选，因为自动化首先会就问题解决问题，而测试设计首先是分析问题的内在逻辑，自动化通常见效会比较快一些。
2、初此之外，需要抓住两条：第一、
自动化侧重工具能力建设，
测试设计侧重人的能力建设，原则上优先改进短板；第二、根据对问题的分析选择
合适的路径，
原则上新开发的功能缺陷多优先改进测试设计，老功能缺陷多优先改进自动化。
3、自动化和测试设计，并不是非此即彼的选择，理想的方式是，对问题进行
分析，对测试设计进行
改进，进而设计
无需人工介入的方法，最后实现
自动化验证。
从我的经验看，测试最难突破的问题就是
只从测试的视角看问题。总结一下，帮助测试经理找到的关于自动化的价值包括：针对目前严重的问题改善质量；帮助实现高质量、快速的软件研发；帮助产品上线后尽快、安全、稳定的运行。
测试经理跳出测试的单一视角看问题，寻找测试对于研发的真正价值，通常这个价值是围绕进度、成本、质量去找的，这不是一件容易的事情。
5.3流程中
固化的测试能力
流程本身作为一种能力，已经在研发团队有效地运转。测试能力和流程相结合，部分能力固化在流程中，这些能力可以确保流程更健康地运转，同时通过对流程的控制也能够使这些能力在质量、效率上
发挥作用。
测试在流程运转中如何发货作用。
5.3.1测试在流程运转中发挥哪些作用
典型的固化在流程中的测试能力包括：
1、根据产品和项目
特征形成的。这些能力通常固化为产品研发流程的一个环节或活动。
2、研发流程中各项测试
主导或参与的活动所需的信息。这些能力通常固化为指导书、模板和工具套件，并且通过活动名称检索。
3、一些
辅助进行流程控制的测试活动。这些能力通常固化为流程相应阶段的出入口标准。
从技术方面测试能力对研发流程运转效率影响比较大的关键的点包括：
1、
方法和工具完整。这部分能力的作用，是使研发流程在测试环节没有明显的技术障碍，测试的主要工作能够正常开展。
2、
需求跟踪。这部分能力的作用，一方面是使测试能够根据跟踪关系评估
需求和场景的测试覆盖，提交需求实现的质量信息；另一方面是使测试能够根据跟踪关系及时获取
变更信息，并同步修改测试的设计和实现。
3、
尽早测试。这部分能力的作用，是使开发者测试达到
必要的覆盖要求，提升研发的质量和效率。
4、
分层开发的多个产品之间，测试策略相互配合（测试类型和层次有确切的定义；尽早测试；测试出入口条件；）。
5、
迭代版本质量控制。这部分能力作用，是杜绝技术债务向后续迭代持续
积压，造成项目风险
失控。
6、
现场测试管理。这部分能力的作用，使得产品
交付工作做到有效管理。
我们的产品研发流程框架是IPD，其中测试活动和分层与W模型研发流程一致。在IPD应用的过程中，还加入了与流程结合的需求管理和项目过程管理工具，但这部分工具用得还不成熟。
5.3.2测试在流程运转中该不该挥舞大棒
测试由于工作性质的原因，对问题比较敏感，在流程执行和改进的过程中常常扮演
监察者的角色。在扮演这样的角色时，需要注意几点。
过程管理的目的是项目的成功，而不是流程符合度。建议把流程作为一个发现问题的工具、处理问题的指导原则，而不是当作法律。
当遇到流程要求没有满足，测试相关工作也会受到影响的时候，对测试来说，重要的是搞清楚
风险在哪里，设计、开发团队怎么应对，测试团队怎么应对，研发环节有没有责任人对风险进行跟踪。
在提倡遵从流程的同时，也需要在流程符合度和适应项目的灵活处理之间找到各方都能接受的平衡点。
度量的目的是改进。
度量的四要素：
1、如果不清楚数据的含义，那就不要去度量。
2、如果不打算在度量之后做什么，那就不要去度量。
3、能够度量结果就不要度量过程。
4、不要把提升度量数据值作为目标，尤其不要把度量数据作为考核结果。
案例：产品转测试
质量改进
最终实施的方案是：
1、在开发阶段，编码完成之前，测试工程师完成基本功能的用例设计，并组织系统工程师和开发工程师评审通过。
2、在开发阶段，编码完成之后，由开发工程师完成基本功能用例的执行，对用例执行通过负责。
3、测试按月、按版本监测和发布“基本功能测试通过率”和“测试轮次”。
这个案例中，项目的实施经过了如下偏离目标再纠正错误的过程：
1、明晰责任；2、方法错误；3、赋能；4、效率低；5、辅助；6、有分歧；7、合作。
做流程改进有时也有类似的特点，
开始制定目标、确定责任归属、指示数据时，只考虑怎样对解决问题有利，不一定需要考虑太多执行上的可行性，执行上只要确认没有技术上无法攻克的难关即可。
所以，
测试在流程运转中该不该挥舞大棒？该挥舞，而且挥舞大棒应该追求棒球那种本垒打的效果，而不是像打地鼠一样经常挥动但徒劳无功。
5.4组织建设和人员能力模型
测试工作的核心是人。
5.4.1测试专家角色类型
从这些年进行测试工程师的任职资格来看，能够在专业领域逐步做得深入，最终出类拔萃的，通常有几类方向。
|
方向
|
具备的能力
|
基本职责
|
额外成果举例
|
| 测试技术专才 | 对测试自动化、DFX专项测试、测试分析、设计、评估等方法和工具比较了解，与业界同行有分享和互动的渠道，了解软件测试技术趋势和新思路 | 产品的功能、性能、DFX测试 | 根据业务的需要规划测试团队的技术能力建设，并负责具体的实施、推广工作，实现研发质量和效率提升 |
| 产品业务测试专才 | 擅长系统功能测试、也熟悉系统的性能及其它DFX测试。除测试相关的能力以外，对产品的架构、特性、业务流程、过往质量表现等很熟悉，对产品领域的业务术语、运营方式、商业逻辑、客户的组织架构、内部流程等也比较熟悉 | 产品系统测试、DFX测试、客户视角的质量评估 | 既熟悉产品又熟悉客户，成为产品交付给客户调试、验收、上线时的核心技术骨干 |
| （分层开发产品的）跨产品业务测试专才 | 有系统功能和性能测试的良好基础，除此以外，对所有原子产品的解决方案的特性、业务流程、接口都很熟悉 | 解决方案的业务流程调试及测试、DFX验证、配置调优等、是集成解决方案研发团队的核心技术骨干之一 | 主持解决方案和原子产品的跨产品测试策略分析，参与产品集成方案设计，参与集成产品的开发过程质量控制，是解决方案交付给客户调试、验收、上线时的核心技术骨干 |
| 测试项目管理专才 | 有良好的测试技术基础，此外，还擅长沟通和项目管理、擅长分析和总结 | 研发项目的测试组长，协调各类资源，帮助项目团队在要求的时间内、高质量地完成测试工作 | 从测试过程中发现测试团队或研发过程的不足，或者测试团队与外部团队配合问题，并找到方法完成改进；从项目中总结成功经验，并完成推广 |
一个测试工程师能够怎样发展，与个体的机遇、性格、特长等客观因素有关，不完全取决于个人意愿。
5.4.2测试工程师能力模型
通过对各个级别、负责各种不同工作的测试工程师的技能的分析，结合与测试业界同行的分享交流，测试人员的素质和技能包括以下方面的内容：
1、测试专业技能。
2、产品知识。
3、思维方式。
4、沟通能力。
5、质量分析方法。
6、软件工程方法。
一个测试工程师不可能每个方面都精通，需要根据自己目前的角色职责和长处来选择加强哪些方面，哪些只需要了解。
为了使测试按照既定的策略和计划完成，除了基本的工作量估计、计划制定的方法和工具外，更重要的是进行
测试过程的管理，这需要做到以下三点：
1、在项目过程中，
观察进展、发现和规避风险。
2、在项目结束后，
总结过程中的得失并在下一轮中改进。
3、在测试活动结束后的
测试评估中，需要根据软件的质量模型，对照产品的质量要求，采用测试过程管理中采集到的数据，进行基于客观事实的
产品质量和研发过程质量评估。
成长为测试核心角色的路径比较常见的有两条线：
管理线。带领团队完成产品的单个项目乃至所有项目的测试，或者带领团队完成产品交付。
技术线。负责产品项目在测试技术上的把控，带领团队完成某项技术改进，甚至负责整个产品的测试技术能力发展。
|
测试技术专才
|
产品业务测试专才
|
跨产品业务测试专才
|
测试项目管理专才
|
|
| 测试专业技能 |
H
|
H
|
|
|
| 产品知识 |
|
H
|
H |
|
| 软件工程方法 |
|
|
H
|
H
|
| 质量分析方法 |
H
|
|
|
H
|
| 沟通能力 |
|
|
H
|
H
|
| 思维方式 |
H
|
H
|
|
|
在我们的产品团队中，测试工程师还有很大的机会成为优秀的质量工程师、服务工程师、市场技术人员、产品经理、产品业务专家等，由于可能性太多，无法再一一剖析其能力模型，总之相应的能力要求，依赖于团队结构、角色主要职责的需要，同时也和产品的特点有关。
此外，需要特别说明的是
编码能力，现在这几乎是测试工程师的必备能力。很多测试工程师是非常畏惧编码的，以我的经验，这种畏惧更多的是一种心理上的障碍，并非因为编码能力有多么难以掌握。
最后，特别强调一项能力，这也是测试工程师最基础的能力：
英语阅读。测试领域大量的新技术资料都是英文的，翻译成中文的多数是入门书籍，因此，想要获得更广泛、更深入的技术资料，英语阅读能力是必须具备的。
5.4.3组织结构要与能力现状匹配
测试的组织结构对于研发整体的测试能力的发展有
决定性影响。
首先，讨论一个宏观的问题：
测试是否独立于开发自成团队，这是测试领域争论的比较多的问题之一。
产品研发团队的组织结构不是一成不变的，我们的测试团队经历过的组织模式主要有：
大测试部：产品线所有产品的测试工程师都属于同一个测试部门，这个部门承接所有产品的测试任务，并规划实施自己的能力提升；
小测试部：每个产品有自己的测试部负责产品的测试任务，产品线有一个小型的测试技术与工具组负责向各测试部导入技术和工具，各测试组织通过测试技术管理委员会进行能力建设的管理工作；
一体化团队：系统、测试、开发工程师都分配到开发组，开发组对特性或模块从需求到交付负完全责任。
组织结构的设计决定了研发团队如何分配自己的资源，而资源的投向决定了研发团队能力提升的速度。
讨论几个测试团队内部的组织设计问题。
【
测试设计与测试执行分离】测试工程师角色细分并非是注定失败的尝试，只是继续尝试前，需要考虑如何避免一些问题。
测试是一个
不断假设求证的过程；开发过程中需求和设计也一直在
变；测试设计工程师长期不对产品进行实际操作，对产品的特性使用方法、限制和约束、陷阱和问题等都不了解，无法设计出
真正好的用例；人为造成的等级
观念，极大削弱了低级别工程师的积极性。
【
自动化专项团队】测试用例在手工测试执行通过之后，
交给自动化专项团队，完成自动化用例的
实现和后续
回归测试执行。这样做的目的是：保持自动化用例的
规范性和
可继承性，降低产品导入自动化测试时的
学习成本。与自动化专项团队类似，还有持续集成专项团队。
【
专项测试（DFX测试）团队】负责产品一种或者几种DFX测试的团队，研发项目中相关DFX方面的任务基本上都由这个团队承担。这样做的原因是：第一，专项测试需要掌握的方法、工具比较
多，学习和入门的门槛比功能测试
高，独立出专人付出的学习成本比较
小，是更
经济的做法；第二，DFX测试在每个项目的工作量都
不太多，将不同项目的DFX测试任务集中给
专人负责，才能使测试工程师得到足够的实操机会，让能力得到
提升。
【
测试工具和技术专业团队】不参与产品测试，是一个
纯粹做技术的团队。主要负责测试所需的各种工具的设计开发，负责测试技术预研、导入和普及，在产品导入测试工具和技术时，提供技术上的辅导和支持。这样做的原因和成立专项测试团队的原因类似：第一，把需要付出较多学习成本和开发成本的工作交给
专业团队，这样对研发整体来说比较
经济。第二，这些工作需要比较长的
准备时间，这个阶段无法在研发项目中产生收益，在追求产品项目成功的团队中，长期保留技术团队的难度太大。第三，做这部分工作的成果，与产品测试工作的成果缺乏可比性，独立出来便于
管理。
总之，只要产品测试活动中有明确的
业务范围和责任目标，是可以在测试团队内部
再细分角色和组织的。通常，需要从头建设某方面的能力，而当建设这个能力需要比较大的投资时，组建团队承担相关技术的研究、导入、落地，是比较
经济和
自然的选择。当然关于组织结构的这些讨论，只对具有一定规模的团队有意义。
讨论两个关于比例的问题。
【
开发测试比】
黑盒测试：维持在2：1-4：1，可以使测试工程师正常地完成功能和常规专项测试（主要指性能测试、兼容性测试等）的设计、执行、评估、缺陷分析等工作。
专项测试：一般占研发总人数的
5%左右。这部分工程师负责主要版本的专项测试设计、执行、结果分析、缺陷分析等工作，也负责专项测试所需要的技术和工具准备中。
测试
工具和技术专业团队：我们团队中，占研发体系测试工程师总数的
2%-4%左右。这部分工程师主要职责是帮助提高研发质量和效率，提*品研发、交付所需要的技术、方法和工具框架。这个团队只负责适用于大部分产品的工具和技术，一般不为特定的产品特性测试而开发的工具。
【
各级别测试工程师比例】
测试团队的梯队结构与研发团队整体的梯队结构基本是一致的，多数是
梨形的梯队结构：非常新和非常资深的工程师都比较少，大部分是有一定经验，可以独立完成一项测试任务的工程师。
当团队的新人比较多时，应该侧重
基础能力建设，通过可靠地完成本职工作，建立研发对测试基本的信任。当梯队结构趋于成熟时，则可以尝试更具
创造性的能力建设，为测试工程师的多样化发展谋求可能性。
5.4.4从任职资格标准的演变看测试价值
任职资格管理是员工管理的
重要手段之一。
至少经历过3次大的调整，每次调整都是由于研发对测试角色有了
新的期望和认识。
1、2001年版本
分为职责部分和工作经验部分。
级别间的主要区别：年限；责任范围；技术能力；
正向牵引作用：责任范围的划分使得这个角色的各级别职责得到
明确，一直到2013版的标准，这个思路都被沿袭下来；要求高级别工程师在质量、成本、计划、进度和客户满意度以及产品的可测试性、可生产性、可维护性或关键技术解决有
重要影响乃至支持
决策；要求测试的技术是基于对市场、关键竞争对手、商业/技术环境的了解面做出的；可测试性通过这个渠道被明确提出，也因此推动了可测试性技术的发展和积累。
存在的问题：6级
没有确定在产品的责任范围。任职资格标准中没有明确说明随着级别的提高，究竟
什么能力要求高了。能体现能力的职责，并没有包含在任职资格标准中。
2、2007年版本
级别间的主要区别：年限；责任范围；技术能力；
正向牵引作用：与前一版本一样，责任范围的划分使得这个角色的各级别职责得到明确，一直到2013版的标准，这个思路都被沿袭下来；高级别的工程师的责任范围立足于产品而不是项目；
DFX测试、测试用例基线、版本质量评估等内容正式纳入任职资格标准；对高级别的工程师提出了
产品优化的要求，从单个特性或DFX的优化，到提升产品竞争力，甚至提出有提升商业价值的优化建议；对高级别工程师提出了测试
技术建设的要求，从解决测试问题的技术，到对研发全流程产生价值的技术，甚至可以被客户使用、产生商业价值的技术。
存在的问题：3级以上的测试工程师，在测试技术能力上的内容几乎一样，级别之间只有
修饰词的差别；对高级别工程师提出的产品优化的要求
不具备可操作性，测试提出有效的产品优化意见，那是
可遇不可求的。
3、2013年版本
级别间的主要区别：年限；责任范围；技术能力；
产品优化；测试
技术建设。
正向牵引作用：之前的基础上，对高级别工程师提出了产品优化的要求；将高级别工程师的职责从特性、DFX测试、扩展到测试架构的优化、创建和创新。
存在的问题：多数测试工程师在产品优化中起到的是辅助作用，能达到这个要求的测试工程师，更多的还是个人
机遇的结果。
TSE职责：
最初是通过做好测试设计，保证测试的效率和质量；后来需要做好DFX测试，通过技术和工具手段提升测试团队整体能力；再后来是为研发体系搭建测试架构，提升从需求到交付的整体的质量和效率。
5.5测试能力持续发展的环境
测试能力的持续发展，需要环境的支持，这个环境即称为
平台。这里的平台指的是与团队能力发展有关的团队文化、信息渠道、专家资源、工作环境、IT流程等，所有这些构成的工作环境，就是测试团队和测试工程师能力发展的平台。
【作用】
团队能力发展平台的作用，是实现团队能力的
承载、获取、应用和发展。
介绍三方面内容：测试知识的管控和治理；产品信息的管控和治理；人员的成长和发展。前两个算是硬环境，关注的是测试工作所需要的信息能够快速获取；后一个是软环境，关注的是价值导向、氛围的建设。
5.5.1测试知识的管控和治理
测试团队基本上可以依靠自己的力量完成。
测试知识包括测试工作所需的输入或参考信息，以及测试各项工作所生产的信息。
内容大概包括：
1、测试资产，由测试团队
自主管理的信息资产，包括以下内容。
- 模板。各阶段测试需要输出的交付件的模板，主要指测试计划、测试策略、测试方案、测试用例、缺陷、测试报告等产品测试工作所需的模板，也包含缺陷分析、项目总结等其他工作所需的模板。
- 工具。各阶段测试需要使用的工具，主要指功能、性能和其他DFX等测试执行所需的工具，也包括测试设计、数据记录和分析、风险和问题追踪管理等其他日常工作所需的工具。
- 指导。各阶段测试活动的指导书、检查表、规范、标准等。
- 参考。各阶段测试活动的培训教材、优秀交付件样例等。通常把前人犯过的错误、做过的有益尝试总结成培训教材和优秀案例，让今后承担这些工作的工程师可以尽快学习和掌握工作方法，内容主要集中在测试策略、测试设计、DFX测试、缺陷分析、测试结果评估等具有创造性的工作。
- 案例。任何工作中的得失都可以总结出案例，值得总结并供团队成员共同学习的案例如：致命缺陷分析案例、客户问题分析案例、某特性自动化测试总结、某客户验收测试总结等。
- 行业信息。兄弟团队、测试同行、产品同行的相关信息，兄弟团队、业界同行分享的模板、指导、参考、案例类的资产，或者他们使用的测试方法和工具等信息。
2、研发资产，在研发统一框架下管理的信息资产，测试需要用到以下的资产。
- 客户信息库。包括客户采用的组网方案、相关组织结构、业务场景、产品和业务指标、业务相关的主要概念等信息。
- 测试配置库。包括测试策略、方案、用例、报告、过程记录等在产品测试过程中产生的信息，以及保存测试用例及其执行结果的测试用例基线库。
- 产品配置库。产品研发过程中产生的信息，包括特性、需求清单；分析、设计过程中产生的模型和文档；代码；数据、接口定义等；
- 规范库。包含产品所处业务领域的相关规范；产品研发的内部规范；产品开发测试所遵循的其他依据。
测试知识和信息的管治，首先需要
统一术语和缩略语。测试知识和信息的管治平台需要做到信息
随时、
随地可获取。推荐建设
内部网站作为知识和信息管治的平台。
5.5.2产品信息的管治平台
产品信息的管控和治理，是研发团队的职责。从测试的角度看，最基本的需求是，能够获得尽可能全面的信息，特别是需求和设计的
变更信息。
目前产品的信息管理的对象是文档，至少包含特征的以下信息：
需求文档。
应用场景说明书。
设计文档。
验证文档。
使用文档。
产品信息管治平台需要满足：利益相干人能够第一时间、准确地
获得变更信息。
解决这个问题有两种思路：一种是所有的工作都在
云上进行，工作输出不在本地保留；另一种是
裁剪文档，部分设计文档和代码合并。下一步的实践是尝试将管理对象
由文档转变为模型。将特性的应用场景作为核心模型进行管理，对特性功能性的分析、设计、验证都基于这个模型，每个环节都基于自己的目的向模型中补充信息，最终开发会基于模型生产代码框架，测试会基于模型生成测试用例。
产品信息的管控和治理，除了需要让研发各个角色能够便捷、及时地获取信息，还需要更好地服务于研发质量和效率的提升。
5.5.3工程师个人成长和发展环境
个人的成长和团队所处的业务环境的
关系非常大。
鼓励工程师之间、团队之间
面对面的沟通交流，也有助于测试工程师的成长。
5.6测试的组织能力模型
一个组织随着人员变动、时间推移都会发生“知本”流失，
知识管理是抵御知本流失的重要手段。
测试
过程可控设计的技术
| 典型能力 | 作用 | 技术 | |
| 方法和工具 | 测试设计方法、测试策略分析方法、自动化方法和工具、缺陷分析的方法、环境管理的方法和工具等 | 解决怎么做的问题 | 测试技术全景图，测试类型全景图 |
| 流程 | 流程本身作为一种能力，已经在研发团队有效的运转。测试能力和流程结合，部分能力固化在流程中，这些能力可以确保流程更健康地运转，同时通过流程的控制也能够使这些能力在质量、效率上发挥作用。 | 解决什么角色，在什么时候，按什么标准做什么事的问题 | IPD流程中落实的测试关键能力 |
| 组织和人员 | 测试人员的知识结构 | 能力发挥价值的关键 | 测试专家类别；测试人员技能模型 |
| 平台 | 与团队能力发展有关的：团队文化、信息渠道、专家资源、工作环境、IT流程等 | 帮助团队能力的承载、获取、应用和发展 | 测试知识的管治平台、产品信息的管治平台搭建中需要解决的问题 |
测试组织能力中，
技术方法和工具的内容是测试团队作为一个技术型团队，
最核心的能力。
5.7小结
本章汇总了
测试团队和测试工程师的能力模型，这些信息可以作为
测试技术架构设计的参考信息之一。在测试能力建设的实施过程中，需要重点关注那些讨论正确做事方式的话题，比如“从问题出发寻求适合的能力建设方向”“能力建设首先考虑实用性”“测试在流程运转中该不该挥舞大棒”等。