如果说拦截缺陷、提供数据是研发对测试提出的“
显性需求”,测试过程可控就是对测试提出的“
隐性需求”。
测试过程可控是指测试的周期和投入稳定,工作质量可被产品团队和客户接受。测试的质量、成本和效率的提升和研发整体的提升
同步。
过程可控的本质是测试团队的能力的
稳定和持续提升。团队能力的载体包括:
技术方法和工具、流程、组织和人员、平台。
团队能力各个载体的作用如下:
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、
持续改进。通过对项目过程数据综合分析能够发现设计、开发和测试过程的问题,并给出对本项目研发活动的改进建议,以及对测试能力各方面的改进措施。通过对发布后缺陷的统计分析,发现高风险的客户类别、用户角色类别、组网形式、场景、模块、特性、质量属性等,并给出针对性的能力改进措施。
千万不要把上面的清单作为测试方法和工具能力的蓝