测试架构师_测试架构师修� - CSDN
精华内容
参与话题
  • 我是国内最早一批从事测试自动化的工程师,并经历了软件测试技术从“原始社会”向...在这期间,我经历了自动化测试用例设计与开发、测试框架选型、测试框架自行研发、测试基础架构设计以及最新的测试服务化(Tes...

    我是国内最早一批从事测试自动化的工程师,并经历了软件测试技术从“原始社会”向“现代文明”发展的整个历程,也经历了从“测试不受重视”到“测试和开发同等重要”的行业理念转变。目前我正在探索由Google等一线互联网巨头主导的“去QE,开发自己测试”的全新模式,也有了很多的感悟和思考。


    在这期间,我经历了自动化测试用例设计与开发、测试框架选型、测试框架自行研发、测试基础架构设计以及最新的测试服务化(Test as a Service,TaaS)等一系列技术的变革与发展。


    我带领过的测试项目也几乎涵盖了所有种类,包括嵌入式系统测试、金融平台单元测试、平台SDK测试、轨道交通安全软件测试、Web Service测试、大型电商网站GUI自动化以及性能全链路压测等。


    由此,我个人也完成了从“小工”到“专家”的蜕变,成为了一名资深的测试架构师。


    如何不再经历之前我走过的坑、快速成为资深的测试架构师呢?


    根据我十六年的心路历程、从业经验与教训,总结了下面这“三部曲”,助你破茧成蝶。


    第一步,成为互联网时代合格的测试工程师。


    如果你是入行不满3年的测试工程师,一定对此有迫切需求。此时,你必须具有快速学习的能力,能迅速掌握被测软件的业务功能与内部架构,并在此基础上运用各种测试方法,尽可能多地发现潜在缺陷,并能够在已知缺陷的基础上进一步发现相关的连带缺陷。


    知识体系上看,你需要有比开发人员更全面的计算机基础知识,还需要了解互联网的基础架构、安全攻击、软件性能、用户体验和常见缺陷等知识。从测试技术上看,你需要能够使用常见的测试框架或者工具,需要具有一定的自动化测试脚本的开发能力,这可以把你从大量重复的工作中解放出来,然后你才能有时间去做更有意思的工作。


    第二步,成为互联网时代优秀的测试工程师。


    如果你想从“合格”变为“优秀”,那必须先认识到两者的差距在哪里


    首先,合格的测试工程师关注的是纯粹的测试,而优秀的测试工程师关注更多的是软件整体的质量,需要根据业务风险以及影响来制定测试策略,有效控制测试的时间和成本,并且能够对测试框架以及工具做出适合项目需求的选型。


    以新房装修为例,合格的测试工程师就是各个工序的装修师傅,他们只管按照设计要求做好自己的工序,而优秀的测试工程师更像是个包工头,他们关心的是整体交付的质量。


    其次,优秀的测试工程师不仅可以娴熟地运用各类测试工具,还非常清楚这些测试工具背后的实现原理,以及多个同类测试工具各自的优缺点和适用场景。


    在遇到问题时,你还需要能够通过二次开发解决工具和框架层面的问题,对于没有合适可用工具的场景,可以自行设计开发一些小工具来更好地展开测试工作。


    当然这个阶段,你很有可能会接触到一些代码级的测试,这就要求你具有一定的开发背景,并能够很好地理解代码级的测试技术。


    最后,随着自动化测试用例的不断增长,自动化测试的关注点也从原本的“如何把手工测试步骤用自动化脚本实现”变成了“如何构建低维护成本,可以灵活组装的自动化脚本”,这就要求你理解自动化脚本的分层设计、页面对象模型以及业务流程模型,并且能够把这些设计应用到你的测试框架里。

    第三步,成为互联网时代的测试架构师。


    当你经历了各种类型的测试项目,就会发现这些项目本身虽然差异巨大,但是有很多东西是相通的


    比如,面对大量测试用例的执行,无论是GUI还是API,都需要一套高效的能够支持高并发的测试执行基础架构;再比如,面对测试过程中的大量差异性数据要求,需要统一的测试数据准备平台。


    这样的例子还有很多,如果你已经能够站在这样的高度看待软件测试,那么恭喜你,你已经具备了测试架构师的视野。当然,你还必须对一些前沿的测试方法和技术有自己的理解,并能够在恰当的时候、因地制宜地把它们应用到实际项目中。


    这就是我给你总结的“三步走”进阶策略了。千里之行始于足下,我在这向大家推荐一个群:672899761,里面有整套的测试学习资料从测试基础知识讲起,结合实际案例,由浅入深地学习,提升自己的软件测试技能。



    展开全文
  • 测试架构师修炼之道--读书笔记

    千次阅读 2018-04-30 14:07:50
    第一部分 瓶颈:软件测试工程师该如何进行职业规划第1章 软件测试工程师的“三年之痒”1.1 软件测试发展简史:调试--证实--证伪--预防--模型--全周期;1.2 中国的软件测试行业:起点高;困境和迷局(不了解、不理解...
    第一部分 瓶颈:软件测试工程师该如何进行职业规划

    第1章 软件测试工程师的“三年之痒”
    1.1 软件测试发展简史:调试--证实--证伪--预防--模型--全周期;
    1.2 中国的软件测试行业:起点高;困境和迷局(不了解、不理解、外包);迷茫(门槛低、深入难)
    1.3 认识软件测试的优势和劣势:优势是入门容易、理解产品、理解用户、多面手;劣势是认可度低、发展受限;
    第2章 软件测试工程师的职业规划
    2.1 软件测试的职业发展方向:管理(初级管理者、中级管理者、高级管理者);技术(产品测试专家、专项测试工程师);角色和段位;质量领域发展(产品流程设计、企业质量管理者、客户满意度管理专家);
    2.2 软件测试工程师的职业规划建议:技术或管理;跳槽的建议;软件测试创业;

    第二部分 突破:向软件测试架构师的目标迈进

    软件测试是一门结合产品领域、管理、心理学和经济学等综合性的技艺。软件架构师的精髓在于找到最适合的软件测试技术,且不断的持续改进。
    第3章 软件测试架构师应该和不应该做的事情
    3.1 软件测试架构师需要关注和不关注的事情
    需求分析:理解商业目标;梳理用户场景;输出总体策略(详见7.1-7.3);
    测试分析和设计:制定阶段策略(详见7.4);落实策略,保证质量;
    测试执行:执行版本策略(详见8.1-8.2,8.4);跟踪执行(详见8.3);质量评估(详见6.3,8.4);
    质量评估:阶段/发布质量评估(详见8.6);
    3.2 像软件测试架构师一样的思考:目标、范围、深度广度、重点难点、如何测试、如何评估;
    3.3 软件测试经理可以替代软件测试架构师吗:合作互补;
    3.4 系统架构师可以替代软件测试架构师吗:协作配合;
    第4章 软件测试架构师的知识能力模型
    测试技术(软件产品质量模型、测试类型、测试方法、测试设计、探索式测试、自动化测试)+产品知识、沟通协调、书面表达
    4.1 软件产品质量模型:六类属性(功能性、可靠性、易用性、效率、可维护性和可移植性);
    功能性:软件产品在指定条件下使用时,提供满足明确隐含要求的功能的能力;5个子属性(适合性、准确性、互操作性、安全性、功能顺从性);
    可靠性:特定条件下使用时,软件产品维持规定的性能级别的能力;4个子属性(成熟性、容错性、可恢复性、可靠性顺从性);
    易用性:产品被用户理解、学习、使用和吸引用户的能力;5个子属性(易理解性、易学性、易操作性、吸引性、依从性)
    效率:相对于所用的资源数量,软件产品可提供适当的性能的能力,也就是我们常说的产品性能;3个子属性(时间特性、资源利用率、效率依从性);
    可维护性:软件产品可被修改的能力;5个子属性(可分析性、可修改性、稳定性、可测试性、依从性);
    可移植性:软件产品从一种环境迁移到另外一种环境的能力,环境可以指硬件、软件或组织等;5个子属性(适应性、可安装性、共存性、易替换性、依从性);
    4.2 测试类型:测试需要考虑的不同角度(功能测试、安全性测试、兼容性测试、配置测试、可靠性测试、易用性测试、性能测试、安装测试等);
    4.3 测试方法
    1、产品测试车轮图:一个软件测试者要从哪些方面(测试类型)用哪些方法(测试方法)去测试产品(质量属性)的关系图;产品测试两个关键问题,分别是全面性和深度;
    2、功能测试方法:运行是指软件测试中,测试人员模拟用户的“操作”或“行为”;
    单运行正常值输入法:系统允许的“正常值”的测试方法;
    单运行边界值输入法:测试系统的“边界值”的测试方法;
    多运行顺序执行法:按照一定顺序来进行多个运行操作的测试方法;
    多运行相互作用法:多个存在相互关系的运行组合在一起进行测试;
    3、可靠性测试方法
    异常值输入法:测试系统容错性,基本可靠性测试方法(系统正常,输入异常);
    故障植入法:把系统放在有问题环境中进行测试的一种可靠性测试方法(系统异常-故障模拟,正常输入);
    稳定性测试法:长时间、大容量运行某种业务,测试系统的成熟性;性能测试是测试真实规格是否与承诺规格一致,稳定性测试是低于性能值前提下测试,压力测试是在高于性能值的前提下测试;四字要诀,多(数量)、并(并发)、复(反复)、异(异常);
    压力测试法:超过系统规格的负载进行测试的一种可靠性测试方法;突发负载模型(希望系统正常)、持续负载模型(系统可能打死);
    恢复测试法:使用超过规格的负载测试、再将负载降到规格以内的测试方法;普通版(高-低)、加强版(高-低-高-低...);测试系统的可恢复性;
    4、性能测试方法:真实规格与承诺规格是否一致;除确认规格之外,还希望发现系统的瓶颈;
    测试出系统最好的性能值:正确处理新业务的最大能力;同时正确处理的最大业务能力;
    分析会影响性能值的各种因素,测试他们对性能的影响:影响因素、影响趋势、最坏值;
    以场景为单位来测试性能:评估产品在用户使用环境中的性能表现,更有实际意义;
    5、易用性测试法:用户理解、使用产品时对产品的能力;
    一致性测试法:测试对象是用户界面,测试风格、布局、元素、提示等;目的是证实;
    可用性测试法:测试对象是用户界面,是否易于理解、使用,需要与功能测试结合,以场景作为测试粒度,以用户视角进行测试;推荐交叉测试法;
    4.4 测试设计技术
    1、测试点不等于测试用例
    测试用例是一份真正能够指导测试的测试说明书;
    2、四步测试设计法
    测试分析是发现性过程,测试设计是创造性过程;
    第一步:建模
    类型1:流程类,绘制“流程图”来建立测试模型;
    类型2:参数类,绘制“输入输出表”来建立测试模型;
    类型3:数据类,绘制“等价类分析表”来建立测试模型;
    类型4:组合类,绘制“因子表”来建立测试模型;
    第二步:设计基础测试用例;
    基础测试用例只确定了测试条件;
    第三步:补充测试数据;
    为基础测试用例确定测试输入,补充测试数据;
    第四步:扩展
    根据经验,补充用例,增加有效性;
    3、对测试点进行分类
    流程类特征:输入的不同进行不同的处理;
    参数类特征:参数值是有限的,系统会对不同的参数值作出不同的处理或响应;
    数据类特征:数据取值是一个范围,系统对允许输入数据作出的处理或响应往往是一样的;
    组合类特征:流程、参数、数据的组合;
    4、流程类测试设计:路径分析法;
    绘制流程图-使用路径分析法(语句覆盖、分支覆盖、全覆盖、最小线性无关覆盖(有两条出边是必要条件,为判定数+1))得到测试条件-使用等价类或边界值等技术确定测试条件-其它需要考虑的;
    5、参数类测试设计:输入输出分析法
    使用“输入-输出表”-100%覆盖“输入输出表”-其它需要考虑的;
    6、数据类测试设计:等价类和边界值分析法
    使用“等价类分析表”-使用“边界值”来为“等价类分析表”确定测试数据-其它需要考虑的;
    7、组合类测试设计:正交分析法
    使用“因子表”-使用“正交分析法”来生成测试用例-其它需要考虑的
    8、控制用例粒度:测试点的组合和拆分
    控制用例粒度,是测试设计中非常重要的一项工作。
    第一:我们希望整个团队测试用例的总数维持在一个比较合理的范围内,同时达到测试验证产品的效果,需要我们控制测试用例的源头(测试点),不要过粗或者过细。
    第二:不同的用例粒度,可能会发现产品不同层次的问题(细粒度用例可能更容易发现功能设计和实现方面问题,粗粒度用例可能更容易从系统角度去发现问题),所以我们不同的测试阶段,对测试点进行拆分和组合,不同层次去测试产品,发现问题。
    还有一种控制测试用例粒度的方法,就是策略覆盖,执行的过程中需要考虑内容的重要性和测试执行的便利性。
    9、错误推断
    错误推断法是一种基于经验的测试设计方法。用到四步测试设计中第四步,作为经验补充的测试用例,是一个比较推荐的方法。错误推断法中的经验,主要源于对产品缺陷的分析。定期组织分析活动,分享经验,拓展思路。
    4.5 探索式测试
    探索式测试非常注重测试思维。
    1、探索式测试的基本思想:CPIE模型;收集C-划分优先级P-分析调研I-实验E;与传统测试相比,探索式测试弱化了流程,强调实践,边学边测,持续改进;优势是快速测试,高效发现产品缺陷,缺点是容易将焦点集中在缺陷发现而偏离对需求的验证,对基本测试覆盖不足,测试点不易复用,不易积累;
    2、选择合适的探索式测试方法:第一步,对产品的特性进行分区;第二步,根据不同分区选择适合的探索式测试方法;
    历史区测试法:老代码,包含修复已知缺陷的代码,多一些时间测试曾经有很多缺陷的代码是特别重要的;包含恶邻测试法(缺陷横行的代码段)、博物馆测试法(老的可执行文件和遗留代码)、上一版本测试法(运行先前版本支持的所有场景和测试用例);
    商业区测试法:销售特性,产品的重要功能和特性,测试的重点测试对象;包含指南针测试法(手册、场景及产品需求)、卖点测试法(吸引用户的特征)、地标测试法(寻找测试点,明确测试项)、极限测试法(向软件提出很多难以回答的问题)、快递测试法(专注于数据)、深夜测试法(不操作时,查看自处理情况)、遍历测试法(最短路径访问对象);
    娱乐区测试法:针对辅助特性,不那么重要的特性;
    配角测试法(特定特征,紧邻主要功能)、深巷测试法(最不吸引人的特性,或最流行、最不流行混着测)、通宵测试法(长时间运行)
    破旧区测试法:问题高发特性,测试思想就是继续“落井下石”;
    破坏测试法(缺陷横行的代码段)、反叛测试法(输入最不可能的数据)、强迫症测试法(强迫一遍又一遍接受同样的数据);
    旅馆区测试法:平台或维护特性,被忽视或者少描述的次要及辅助功能;
    取消测试法(启动相关操作,然后停止,查看处理反应)、懒汉测试法(自行处理空字段及默认值);
    旅游区测试法:针对的是噱头特性,关注如何快速访问文件的各个功能,目的是到此一游;
    收藏家测试法(通过测试收集软件的输出,将那些可以到达的地方都到达一遍)、长路径测试法(访问离应用程序某个开始点尽可能远的特性)、超模测试法(关心表面的东西,只测试界面)、测一送一测试法(同时处理多个功能时,能否正常)
    其他区测试法:无法归类的区域,如产品的可测试性、可维护性等;
    内部测试法(需要进行某项功能测试之前完成,收集那些部分对确认测试结果、定位问题有用的内部输出)、变动区测试法(分析当前版本与之前版本内容的变化,针对变化内容进行测试)
    3、开展探索式测试:
    3.1、确定探索式测试任务:确认任务范围,三种思路(全局场景探索、特性漫游探索、局部功能点探索);确定范围后,确定测试方法;
    3.2、设计探索地图并执行探索式测试:根据被测对象特点,使用测试方法分析得到测试点,然后执行测试,并记录结果;使用探索式测试是能够直接用测试点来进行产品测试的,也是其速度快、效果高的优势所在;测试过程中可以灵活实时调整测试策略;
    3.3、探索式测试总结:哪些方法可以更有效发现产品问题;本次探索测试中的教训;
    4.6 自动化测试
    用好已有的自动化、根据产品测试需求向自动化团队提出合适的自动化需求;
    1、需要知道的一些自动化测试真相
    自动化并不廉价,相反,自动化很贵(时间人力技术成本);自动化脚本往往没有想象中那么可靠(意外发现的缺陷,自动化可能都不会发现;自动化本身可能不可靠);自动化测试不是单靠自测就能搞定的事情(需求要确定清楚,UI或命令行也需要尽早确定,测试用例也要尽快写出来);
    2、如何评估自动化的收益
    自动化测试的实施成本(前期开发成本+后期维护成本);自动化测试的运行次数(优先选择真正需要多次执行的测试用例);自动化测试实施成本比;
    3、自动化测试工具介绍
    单元测试工具、UI测试工具、性能测试工具;
    第5章 软件测试架构师的软能力修炼
    除了硬能力之外,也需要一些软能力。
    5.1 沟通和协商
    产品测试中的沟通原则:1、尽早沟通(帮助我们预防分歧);2、既要对事,也要对人(对人强调的是理解沟通对象,换位思考);
    通过沟通来获得对产品测试有用的信息:1、以测试的视角来读需求、设计文档,来准备沟通的问题(测试的视角,是否可测?怎么测试?怎样才算验证通过?);2、以需求工程师或开发的视角来问问题(沟通是相互启发的过程);3、总结、跟踪和确认;
    和测试团队成员沟通:主动进行反复的沟通(简介-讲解-举例-总结);和领导或投资决策者沟通(更关心:产品测试结果和产品的质量评估结论;重要BUG;重要风险;进度);
    5.2 写出漂亮的测试用例
    测试用例模板:测试用例编号、用例标题、预置条件、测试数据、测试步骤、预期结果;合理控制用例的粒度;
    测试用例标题要是一个完整的句子:状语,主语,谓语,宾语,补语(可选);
    条件而不是参数来描述测试用例标题:参数更适合在测试用例模板中的测试数据部分体现;
    如果一个用例中包含多个参数,用例中应该是每个参数的取值;
    不要在测试用例中引用别的测试用例
    避免测试用例中包含过多的用户接口细节:用例执行者是专业人士,用例不必写的面面俱到;
    明确测试步骤和预期结果的对应关系:增加简单的标记(如check[])来明确对应关系;
    避免在测试步骤中使用笼统的词:避免反复、长时间、大量等描述,应该明确;

    第三部分 修炼:软件测试架构师的核心技能

    第6章 如何才能制定好测试策略
    制定测试策略是软件测试架构师最核心的技能。
    6.1 理解测试策略
    1、什么是测试策略?通俗说,就是测啥咋测;具体说,有测试对象范围、测试目标、测试重点难点、测试深度广度、如何安排测试、如何评价测试;
    2、测试策略等于测试方针?测试方针是产品测试中的通用要求、原则或底线;遵循的测试方针+项目实际情况=测试策略;
    3、测试策略等于测试计划?测试计划属于测试管理的范畴,测试策略属于测试技术的范畴;
    4、测试策略等于测试方案?测试方案主要解决的是特性在测试设计和测试执行方面的问题;测试方案需要遵循测试策略;
    6.2 四步测试策略制定法
    1、明确产品质量目标:我们的测试目标就是让产品在发布的时候能够满足事先约定的质量目标(详见6.3节);围绕产品质量目标进行刚刚好的测试;将目标-行为-评估形成闭环(详见第8章);
    2、进行风险分析:提前识别项目中可能存在阻塞测试的风险,然后基于风险调整测试策略;基于风险来加强和降低测试投入;
    3、适配产品开发流程:测试策略的结构;根据研发流程来安排测试活动;
    4、进行测试分层:通过测试分层,能够将大的目标分到不同层次中阶段完成,合理的测试分层,能够让测试目标SMART化;
    5、四步测试策略制定法中的测试技术;
    6.3 产品质量评估模型
    产品质量评估模型将用在测试目标的确定和评估上,它是整个测试策略的基础。
    优秀的产品质量过程评估模型的特征:多维度(覆盖各个维度,全面分析和考虑);定量和定性(指标和分析结合);过程+结果(还需分析评估);
    软件产品质量评估模型:测试覆盖度分析(需求覆盖度评估、路径覆盖度分析);测试过程分析(测试用例分析、测试方法分析、测试投入分析);缺陷分析(缺陷密度分析、缺陷修复情况分析、缺陷趋势分析、缺陷年龄分析、缺陷触发因素分析);
    6.4 测试覆盖度评估
    需求覆盖度评估:“已经测试验证的产品需求数”与“产品需求规格总数”的比值;两种方法:1、直接在需求表中确认测试情况;2、建立测试用例和需求的对应关系(注意需求变化的部分,设计遗漏可能会影响需求覆盖评估;本方法最好有工具支持);
    路径覆盖度分析:“已经测试到的语句的数量”与“程序中可执行语句的数量”的比值;三步分析法,1、确定路径覆盖策略;2、使用路径分析法设计测试用例;3、跟踪测试用例执行情况;
    6.5 测试过程评估
    分析的对象是测试用例、测试方法和测试投入;
    测试用例评估:测试用例执行率;测试用例执行通过率(首次执行通过率、累积执行通过率);测试用例和非测试用例发现缺陷比;
    测试方法分析:只按照测试策略来确定要使用的测试方法--分析测试设计是否和测试策略中的测试方法符合--分析测试执行时的测试方法是否符合测试策略--通过缺陷分析来确定测试策略是否需要调整;
    测试投入分析;
    6.6 缺陷分析
    缺陷密度:每千行代码发现的缺陷数;缺陷密度可以预测产品中有多少缺陷,帮助我们评估当前以及发现的缺陷总数是否足够多;
    缺陷修复率:指产品“已经修复的缺陷总数”与“已经发现的缺陷总数”的比值;缺陷修复率能够帮助我们确定当前产品发现的缺陷是否被有效修复,为当前的产品质量是否达到测试质量目标提供最直接的判断依据;为保证重要缺陷优先修复,我们按照不同的缺陷严重程度确定缺陷修复;
    缺陷趋势分析:指随着时间的进行,测试发现的缺陷趋势和开发解决缺陷的趋势;能够帮助我们判断当前系统是否还能容易地发现缺陷,进而帮我们确定是否可以退出测试;1、绘制缺陷趋势图(累积发现的缺陷数、新发现的缺陷数、累积解决的缺陷数、当前解决的缺陷数);2、缺陷趋势曲线的“凹凸性”和“拐点”(理想的趋势曲线;趋势曲线拐点出现的过早;趋势曲线拐点未出现);3、缺陷是否收敛(两个条件:趋势曲线变为凸函数;累积发现和累积解决两曲线越来越靠近);缺陷年龄分析:软件产生或引入缺陷的时间(继承或遗留、需求阶段、设计阶段、编码引入、新需求或变更引入、缺陷修复引入);三步走展开年龄分析活动;第一步:确定缺陷的缺陷年龄;第二步:统计各类缺陷年龄的数量,绘制分体图;第三步:进行缺陷年龄分析(理想的年龄分析图;没有在特定的测试层次发现该层的缺陷;继承或历史遗留引入缺陷过多;新需求或变更引入的缺陷过多;缺陷修改引入缺陷过多);
    缺陷触发因素分析:对测试中使用的测试方法进行分析;三步走:确定缺陷的测试方法和测试类型;统计出各种测试方法发现的缺陷数目,绘制缺陷触发因素分析图(有些方法没有发现缺陷或者发现的少;有些方法发现的特别多;);
    组合使用各种缺陷分析技术:进行缺陷分析,并不满足只对产品质量的某一个方面进行评估,需要我们组合使用这些缺陷分析技术;
    6.7 风险分析技术
    涉及的技术主要有风险识别,风险评估,风险应对和老功能分析;
    1、风险分析:风险分析的对象是测试策略;
    风险识别:三步走;第一步,分析该项测试活动需要关注哪些内容;第二步,分析上述内容都能够进行保质保量顺利进行的条件;第三步,逐一分析这些条件是否能够满足;
    风险评估:确定风险的优先级;风险优先级正交表、需求类风险、设计类风险、流程类风险、历史类风险;
    2、风险应对:回避风险、转移风险、减轻风险、接受风险;
    3、老功能分析:差异性分析(老功能在新版本和老版本上的差异,找差异是新版本中做好老功能测试的金钥匙);历史测试情况分析(确认老功能在新版本和老版本中的质量要求是否一致;进行测试方法分析;进行缺陷分析;对组织和人进行分析);
    6.8 分层测试技术
    V模型:单元测试、集成测试、系统测试、验收测试;
    设计测试分层:1、某通信公司测试分层;单元测试、MST(模块级)-BBIT(单元/模块接口)测试、SDV(系统设计)-SIT(系统集成)-SVT(吸引验证)测试、验收测试;2、某公司敏捷测试分层;单元测试、功能测试、非功能测试、探索测试;
    第7章 测试策略实战攻略
    测试策略实战,运用第6章思路和方法;
    7.1 开始
    收集了解项目信息:项目范围、人力投入、历史情况、产品背景、用户市场等;
    7.2 初次使用“四步测试策略制定法”
    1、产品质量等级(第1级完全商用;第2级受限商用;第3级测试;第4级不能使用);
    2、确定项目中各个特性的质量等级(逐一确定项目包含特性的产品质量等级);
    3、对项目整体进行风险分析(项目整体角度进行分析);
    4、确定测试策略的结构(总体策略、阶段策略、执行策略);
    5、初步确定测试分层;
    6、回顾(四步走;质量分析;风险分析;总体、阶段、执行策略;单元、集成、系统、验收);
    7.3 制定总体测试策略
    1、分解产品质量目标:根据质量等级来分解产品的质量目标;为每个测试分层确定测试目标;
    2、使用老功能分析法来对特性进行分类:全新特性;老特性变化;老特性加强;老特性无变化;
    3、基于质量和风险来确定测试深度和测试广度(深度指使用的测试方法,广度指测试的范围):使用产品质量评估模型初步确认测试深度;考虑用老功能分析更新测试深度;基于老功能分析来初步确定测试广度;
    4、确定测试优先级:质量等级越高,优先级越高;相同质量等级下,全新特性比老特性优先级高;改动越多的老特性,优先级越高;根据优先级等级,制定测试投入策略;
    5、确定测试总体框架:三个层次,分别是策略层(类似大脑,负责指挥)、活动层(类似身体,负责执行)、保证层(类似五官,负责保证);
    6、回顾:总体测试策略输出的就是两张表(总体测试策略分析表,测试投入策略表)和一幅图(测试总体框架);
    7.4 制定阶段测试策略
    阶段测试策略向上能够承接总体测试策略,向下能够指导后面的测试执行;
    1、测试设计策略:按照测试深度来进行测试设计,然后执行测试用例,达到执行的目的;
    1.1、使用“测试分析设计表”来保证测试设计符合测试策略(包含3个表,分别是测试分析准备表、测试类型分析表(列为需求,行为测试类型)、功能交互分析表);
    1.2、四步测试设计法和测试广度:参见4.4,输出测试用例;
    1.3、测试用例等级:测试用例分级会为后面进行的分层测试、回归测试、验收测试和自动化测试在如何选择用例方面提供方便;
    2、集成测试策略:俄罗斯方块心项目的集成开发;集成测试的对象和测试目标(新合入功能是否正确;功能集成后系统功能正确性;原来的系统功能没有被合入的功能破坏);入口准则--何时开始(用例输出且评审完毕;测试资源到位;测试环境就位);测试用例选择(功能:级别1;新功能集成:级别2和部分级别3;确认原系统:级别1);出口准则(集成功能开放、集成完成;测试用例执行完成;缺陷分析符合预期;达到集成测试质量目标);
    3、系统测试策略:系统测试的对象和测试目标(系统角度验证测试功能的正确性;系统角度验证各种非功能质量的正确性);入口准则--何时开展(集成测试出口、测试准备到位);测试用例选择(功能测试:级别1和部分级别2;非功能:级别3和级别4);测试执行顺序(考虑以下:有些测试方法本来就需要满足一定条件;先进行复杂的,再进行简单的;组合多种测试方法);出口准则(达到目标);
    4、验收测试策略:Alpha测试(谁来执行(测试人员模拟用户进行测试,了解用户的人及测试组员交叉测试是不错选择)、测试策略(用户学习产品、产品资料、安装部署、升级、移除、上下游设备、业务、故障、管理配置、日志报表等运维功能));Beat测试,用户参加的测试;入口准则--何时开始(系统测试出口,Alpha测试人员及方案已经确认,Beat测试用户已经确定);出口准则--何时推出,发布产品(达到总体策略中产品质量目标);
    5、回顾:确定了测试设计策略;确定了各个测试阶段的测试策略;
    第8章 版本测试策略和产品质量评估
    项目开始进入测试执行阶段,测试架构师也要进入执行测试策略的工作中了;
    8.1 开始
    测试阶段的工作,主要是围绕:制定版本测试策略,跟踪测试执行,质量评估;
    8.2 第一个版本测试策略
    1、测试范围以及和计划相比的偏差:实际提交的功能和设计不符时,如果相关功能对测试人员而言不可测,则不接收测试;反之,接收测试;
    2、本版本的测试目标:以测试对象--测试方法--测试结果这样的方式来描述测试目标,好处是强调了基本测试要求,比数字指标容易理解和执行;
    3、需要重点关注的内容:首先,对提交的功能,提出团队重点关注内容;其次,确定测试的优先级表;
    4、测试用例的选择:根据测试用例等级,选择测试用例就简单多了;
    5、测试执行顺序:质量情况好,可以考虑更多的测试方法组合起来执行;刚提交的功能,质量不好或不明时,不建议组合测试;
    6、试探性的测试策略--需要大家分工合作的地方:全局因素工作量大,可以进行试探测试;一些全局性配置,也可以使用这样的策略;
    7、接收测试策略:开发将版本交由测试人员时,测试人员先进行一次测试,确认版本没有阻塞性问题;如果阻塞可以规避,建议继续测试;
    8、回顾:测试范围及计划偏差、测试目标、重点内容、用例选择、执行顺序、试探性测试、接收测试;
    8.3 跟踪测试执行
    跟踪的目的有三个:确保测试团队按照测试策略来执行;实时关注缺陷,通过缺陷分析评估策略是否适合,是否需要调整;关注项目风险,基于风险调整策略;
    1、跟踪测试用例执行情况:
    1.1、测试团队的测试执行顺序是否和测试策略相符(测试团队是否按照特性优先级顺序来执行测试用例;测试团队是否按照测试策略中的测试方法、测试顺序来进行测试;);
    1.2、被阻塞的测试用例(测试人力不足、测试时间不够、测试环境不具备、其他缺陷导致);
    2、每日跟踪缺陷:缺陷的趋势是否正常、是否存在引入缺陷修改引入的缺陷、本版本必须解决的缺陷、本版本需要解决的缺陷;
    2.1、哪些缺陷必须在本版本中解决:标准只有一个,就是会不会对后续的测试造成阻塞;
    2.2、哪些缺陷需要在本版本中解决:我们希望在本版本中修复的缺陷;优先解决的缺陷类型:
    缺陷的改动越大,越需要尽早解决;缺陷涉及需求、方案、涉及,需尽早解决;优先解决严重程度为致命和严重的缺陷;
    2.3、缺陷趋势是否正常:预估拐点会在哪个版本出现;判断当前版本的缺陷趋势是否正常;
    2.4、是否存在缺陷修改引入缺陷的问题;
    3、调整测试策略:
    发现测试情况与测试策略不符时,需要调整测试策略;如下调整思路:
    被阻塞的测试用例是属于几个功能,还是很多功能;存在阻塞的功能,原计划不在本版本中执行的用例,是否可以调整到本版本;没有阻塞的功能,原计划不在本版本执行的用例,是否可以调整到本版本中测试;
    在缺陷跟踪的时候,发现趋势不符合预期;如果拐点出现的太早,当前测试方法已经不能有效发现缺陷,需要分析原因,调整策略;如果一直未出现拐点,当前测试还能有效发现缺陷,根据项目情况进行调整;
    8.4 版本质量评估
    1、使用软件产品质量评估模型来进行质量评估:
    1.1、在版本质量评估中记录需求和实现的偏差:由开发人员提供的实际提交的功能和需求的偏差;在测试过程发现的实际功能和需求的偏差(与此有关的BUG列表;开发人员、测试人员和SE需求澄清进展、结论及后续进展);
    1.2、在版本质量评估中进行测试过程评估:测试用例通过率(首次执行通过率、累积执行通过率);测试用例在多个版本中的测试结果(出现反复,可能存在隐患,需要根因分析);
    1.3、在版本质量评估中进行缺陷分析;
    2、版本质量评估中的缺陷分析;
    2.1、版本缺陷密度评估;
    2.2、版本缺陷年龄分析;
    2.3、版本缺陷触发因素分析;
    3、调整测试策略:评估发现可能会影响最终发布的质量问题,需要采取相应的措施;
    4、建立特性版本质量档案:至少包括当前测试覆盖度方面的记录、测试过程的分析和记录、缺陷分析;
    8.5 后面的版本测试策略
    进入下一个循环;
    1、回归测试策略:是一种确认性质的测试;测试目标有缺陷回归、功能回归、阶段回归;
    1.1、缺陷验证策略:确认缺陷被开发人员正确修复了;
    1.2、功能回归策略:确认老功能不会因为新合入的功能而失效;新功能回归测试、老功能回归测试;
    1.3、阶段回归策略:确认产品当前的质量达到该阶段的质量目标;集成测试阶段回归测试、系统测试阶段回归测试、验收测试阶段回归测试;
    2、探索式测试策略:将它与传统测试结合起来;
    2.1、将探索式测试和传统测试结合起来:先进行传统测试,再进行探索测试;
    2.2、探索式测试方法的选择策略:集成测试时,先使用商业区测试法和娱乐区测试法,再使用历史区测试法和破旧区测试法;系统测试时,先使用历史区测试法和破旧区测试法,再使用商业区测试法和娱乐区测试法,最后使用旅馆区测试法和旅游区测试法;
    2.3、探索式测试策略在版本策略中:确认范围;根据当前阶段确认主要的探索式测试方法;输出探索式测试任务;
    3、自动化测试策略:主要的还是放在回归测试,如功能回归和BUG回归;需要我们先对需要多次执行的测试用例进行自动化、优先自动化简单的可靠的功能;
    3.1、确定自动化脚本编写的优先级:优先级高的优先实现;优先级一样的,优先实现简单的可靠性高的;
    3.2、自动化开发和测试如何与测试项目配合;
    3.3、关于自动化率;
    3.4、鼓励通过脚本来解决测试中的实际问题;
    4、回顾:形成了版本测试策略关注的所有内容;
    8.6 阶段质量评估(包括发布质量评估)
    每个阶段即将完成时,进行一轮整体性评估,判断是否满足出口标准;
    1、阶段质量评估项目:
    1.1、确认总体测试策略中的质量目标是否完成:发现质量红线未达到;一般质量目标未达到;
    1.2、质量的重要目标(质量红线);
    1.3、对未达到的一般性质量目标制定应对措施:非测试用例发现缺陷的原因分析;组合缺陷分析;
    1.4、遗留缺陷分析;
    2、非测试用例发现缺陷的原因分析:原因分析可以在整个测试团队进行;
    3、组合缺陷分析:一般性的质量目标问题,需要组合分析,系统角度整体评估问题影响;
    4、遗留缺陷分析:版本发布时不准备修复的缺陷;
    4.1、缺陷对用户的影响程度;
    4.2、缺陷发生的概率:用户环境中发生的概率;
    4.3、缺陷风险评估和规避措施;
    4.4、不能遗留的缺陷:致命缺陷、没有规避措施的严重缺陷不应该遗留;
    4.5、缺陷遗留列表:作为讨论和发布的材料;
    5、临近发布时的缺陷修复策略:缺陷遗留标准可能有差异;发布临近,严控缺陷修复的数量;
    6、非必然重现BUG的处理:需要跟踪和处理;
    7、总结:发布阶段,质量评估并给出评估结论是一项重要的工作;保证产品能够按时按质按量发布;贯穿测试项目始终的活动;
    展开全文
  • 一个测试人员如何变成测试架构师

    千次阅读 2018-06-24 16:27:14
    测试架构师必须具备的第一个能力:“准确的商业理解力。”了解自己所在公司测试架构师团队的运作和工作内容,虽然我们之前也从未接触过微软的测试架构师。但随着公司业务的扩大,业务的需要驱动了我们公司内部有一小...

    测试架构师必须具备的第一个能力:“准确的商业理解力。”

    了解自己所在公司测试架构师团队的运作和工作内容,虽然我们之前也从未接触过微软的测试架构师。但随着公司业务的扩大,业务的需要驱动了我们公司内部有一小部分人担当起了测试架构师的职责,其title来源也是有其偶然性。原本公司中测试工程师往上发展就是系统测试工程师,系统测试工程师再往上应该叫什么呢?最后参考软件开发的title,就开创性的在公司内部叫测试架构师。并开始从事了很多从公司层面而仅非单个测试经理层面所需要的新的测试工作职责,例如:领导负责一个产品线或一个大产品的测试技术规划,early testing,系统测试工程师的培养,与开发架构师一起设计和改进架构的设计质量,测试执行活动质量的审查保障,亲自指导重点测试方案的设计,为了不断降低公司研发成本而进行新测试技术研究实践和推广,基于风险的测试,基于模型的测试,安全性测试,兼容性自动化测试,分布式自动化测试,性能压力测试,需求测试等专项测试技术领域的研究,并支撑新领域重点市场项目活动等等。

    与微软的共性是我们的测试架构师都不再亲自写自动化测试脚本,不亲自写测试工具的代码。但我们会从项目初始即项目需求和架构设计阶段就开始考虑未来的自动化测试框架,针对具体的产品特点,思考选择最合适的自动化测试语言;在架构设计中充分考虑如何支撑未来更高的自动化测试率,让架构设计调整具备高的可测试性率;由于参与早期的设计方案讨论选型,能提前识别和规划好未来产品测试组所需要提前准备的测试实现技术。并亲自带着测试工程师提前进行测试技术储备。当然我们也常常亲自去实施一些测试活动:如设计测试工具的架构(主要考虑未来扩展性和更好满足测试需求),然后交给专门的测试工具开发团队来实现;或亲自设计压力测试方案;亲自研究安全性测试策略和方案。推广方式,主要是亲自实践各种新测试技术后,再带着测试人员在实战中掌握相关的方法。

    我们大部分的测试架构师都是写过自动化测试脚本或程序的,只是现在的工作由于需要我们去思考太多的东西,所以没有一丁点精力来编码。特别是负责一个产品线的测试架构师,由于负责多个产品,还要抽取产品间的共性测试技术,要建立起产品线的测试架构图,统一产品间的测试技术,统一测试方案的设计质量标准,需要具备更强的抽取共性的能力。同时,还需要能在短期内快速了解和识别影响产品成败的关键测试技术,因为并不是所有产品都是性能压力测试就是最重要的。例如:某产品线有9个产品,有的产品最需要保障的是可靠性(性能,可用性不是关键);有的产品最需要保障的却是可用性,而不是可靠性;有的产品最需要保障的是安全性,而不是性能;有的产品最需要保障的是可移植能力和可集成能力,而不是性能。那么相应的每个产品测试用例设计就会有所侧重,例如:对于重视可移植能力和可集成能力的产品,测试架构师就应该帮助测试人员系统地做好这2个领域的测试用例。

    因此,测试架构师必须具备的第一个能力就是:“准确的商业理解力。”商业成功的核心竞争力是什么?测试技术和测试资源是否能真正地保障或支撑商业成功的核心竞争力?这些都是测试架构师需要准确识别的,如果测试架构师识别错误了,那么有可能在需要重点保障的领域,测试技术和测试资源投入不足,导致最后产品的商业竞争力得不到支撑,得不到质量保障。例如:某产品对外宣传是业界可靠性最高的产品,可是测试人员在测试活动中惯性地把主要精力都花在了性能测试中,对各种异常的测试验证并不是业界最丰富的。结果在与业内其他产品比较的第三方测试报告中,该产品的可靠性得分却并不是第一,虽然性能是第一,但该产品在特定的重视可靠性的市场中基本失去了商业竞争力。

    某美国公司的一款产品在传统行业中主要功能基本雷同,如何才能与类似产品拉开距离,突出竞争力。后发现产品的用户在使用产品时普通操作时间都较长,因此为了缩短用户的操作时间,该公司决定在产品的可用性领域重点投入设计,核心竞争力是解决用户的可用性问题。其测试团队把大部分的测试设计精力也放在了可用性的测试活动中,构建了业界非常丰富的可用性测试用例,这些测试用例的场景超过了产品设计考虑的原有场景,并最终通过测试驱动设计,与产品设计师一起不断改进产品的可用性。最后不但提供了业界可用性最强的产品,而且其可用性功能的稳定性质量也非常高。测试活动从效率和质量角度支撑了产品的商业成功。

    所以,如果你的公司正准备招募测试架构师,请第一考评他的能力应该是他的商业理解力。具有该能力的测试工程师知道如何选择:做正确的事!确保事半功倍。而不具备该能力的测试工程师可以成为系统测试工程师,由他来保障正确的把事做好!

    测试架构师必须具备的第二个能力:“区分测试重点和测试难点”

    重点和难点两个词汇有时能代表同样的方向,有时却是相差较远的方向。

    为什么我要把是否有能力区分测试重点和测试难点作为测试架构师必备的第二个基本能力。因为,我曾在某产品线对测试活动的质量进行抽查时,与每个产品的系统测试工程师进行了沟通,发现只有一名有6年经验的系统测试工程师在我的的启发下,分清了自己所负责产品的测试重点和测试难点。而其他的系统测试工程师一直都把测试难点误当成了测试重点,作为他技术攻关工作的主力方向。甚至从来没有真正思考过什么测试技术才是自己所负责产品决定成败的测试重点,只是简单地把自己在工作中碰到的所不具有的测试技术都当成测试重点,其实很多都只是测试难点。的确,在某些产品测试难点和测试重点刚好重合。虽然某些产品测试重点在技术上并不难,但是却需要我们把测试重点部分的工作质量做到最佳,时间和资源投入最多,而不要把有限的资源投入到测试难点的工作中去。我很认同华为任正非对华为工程师的要求“要做工程商人”,我们其他公司的工程师同样应该以商业目标为自己的技术工作目标,不应唯技术论,越新的技术,越难的技术就越愿意投入。测试工程师同样要心中一直有一个目标指引着自己的所有技术工作方向。这个目标就是我测试架构师日记中第一篇谈到的“准确的商业理解力”告诉你的工作目标。

    由于项目中每个人的分工不同,因此不可能每个测试人员一开始就能知道自己工作的商业目标是什么,所以也不用去责怪大家。可是领导产品的测试架构师不能准确的识别或培养其他测试工程师具备识别测试重点和测试难点的能力,那么注定这个测试团队的工作不但质量保障会打折扣,而且会浪费不少组织的资源和成本。

    因为资源和时间是有限的,而完美工作的追求是无限的。因此,我们如何在有限的资源和时间下,保障基本的质量目标,并尽可能提升质量目标。就需要在分清测试重点后,优先针对测试重点目标进行系统地测试技术研究,测试技术攻关,测试资源主要投入。对于非测试重点的测试难点部分就要降低优先级,放在最后考虑。

    测试架构师的工作应该牢牢抓住真正的测试重点来开展,甚至在整个产品测试组都方向错误时,要能从商业角度帮助测试组改变观点。那么当从测试经理到普通工程师都误理解了测试重点时,测试架构师应该如何来启发他们呢?我这里就分享一个案例吧:

    在一次到产品测试组进行测试活动质量抽检时。我们问测试经理,你们产品测试目前最大的需求是什么?他说是如何进行压力测试和性能测试,希望我们测试架构师团队能在此领域多给予支持。我心里知道:他所负责的产品特性核心不是性能和压力测试,但我没有反驳他。而是继续问他下一个问题:“你觉得会让你产品未来应用时商业失败的最大担心是什么?”他想了想说:“不能对客户的生产系统产生破坏,让客户的业务中断。”“依据我们的经验,与客户生产系统交互的模块虽然是个小模块,但是在其他产品上经常出现内存泄露的故障从而破坏了生产系统。那你针对该小模块做过哪些系统地测试?有无专门进行内存泄露的测试,因为内存泄露对客户生产系统的破坏最大。”我问到。这时此测试经理才恍然大悟,这个对生产系统质量影响最大的小模块居然没有系统地进行过深入全面的测试。我这时告诉他 “你之所以开始说性能和压力测试是你的重点需求,是因为你们组里没有在性能和压力测试方面的积累,有工作开展的难处,这是困扰你的困惑。但是你的产品形态的质量不是性能或所谓压力测试来保障的,而是需要不对生产系统产生破坏。因此,你唯一能破坏生产系统的那个小模块应该是你整个产品中质量最高的模块,也应该是测试最全面最深入的模块,你的技术力量应该主要投到这个地方”。后来,针对该小模块我们进行专项内存泄露的测试,结果发现了好几个内存泄露的大bug,这些bug每一个都是会导致客户生产系统中断的杀手。

    测试架构师不是团队中专门解决测试难点的专家,而是识别测试重点,并支撑测试重点工作的专家。“区分测试重点和难点的能力”不是测试架构师独有,系统测试工程师和测试工程师一样可以具有。与第一篇“准确的商业理解力”一样,第二篇要做的是:做正确的事。

    在开始描述我理想中的测试架构师必备素质第三篇前,我想先转载一篇来自互联网万欣的文章《好的架构师都是善良的独裁者——万欣》与大家分享,作为测试架构师必备素质第三篇的前言:

    对于任何一个软件开发人员来说,架构师都是一个令人向往的角色。就连世界首富比尔盖茨在2000年卸任公司CEO的同时,也担任了微软公司的荣誉角色“首席软件架构师”,可见“架构师”这一称谓的吸引力。架构师是公司的“金领”,有着非常高的收入,很少需要考虑生存的问题,从而有更多的精力思考关键技术问题,形成“强者愈强”的良性循环。部分优秀的开发人员在工作了一定时间后,就要开始考虑自己的未来到底向哪个方向发展。如果开发人员的沟通能力强过技术能力,在补充一定的项目管理知识后,可以向技术管理的方向转型。如果其对技术一直很感兴趣,而沟通能力也不弱,则可以试着进一步加强技术修养,以期向架构师的方向发展,最终“修成正果”。

    那么,到底什么是架构师呢?所谓的架构师,应该是一个技术企业的最高技术决策者。他主要负责公司软件产品或软件项目的技术路线与技术框架的制订。好的架构师都是善良的独裁者,具有很强的技术、良好的写作能力、良好的口头表达能力,能够在各个层次进行沟通。从开发人员到架构师的成长应该是阶梯式的,一般来讲开发人员在刚刚开始工作时只能开发简单的独立软件模块,慢慢的随着经验的增长,他开始接触一些相互之间有信息传递的模块,而后来,他会发现自己接到的开发任务已经不是一个独立的单体,这些任务由一些专门的软件部分组成,可能包含数据库,工作流引擎,消息服务等等各种功能模块,可能分布在不同的服务器上,所有的部分协同起来,完成软件功能。而这时候,体系结构的好坏将直接决定了系统的性能和可扩展性,而就在这时候,这名优秀的开发人员也开始思考架构师应该思考的问题了,或者说,他向成长为架构师的道路迈出了一大步。

    什么是架构师最具价值的技能呢?就是要了解不同的知识,做一个“杂家”或者说“博学家”。当然,如果你的数据库技术非常棒,或者你在工作流引擎方面具有不可超越的专家知识,那也是很不错的。好的架构师有好多都是从专家成长过来的。但是,这不是架构师应该做的事情,架构师应该做的是了解所有的东西,既了解技术的宏观面,又了解技术的细节。真正的架构师不仅仅要了解软件,也要了解硬件,在关键的部位使用合适的硬件来取代软件,可以成倍甚至成百倍的提高整个系统的效率。下面我将会以互联网行业对的架构师的要求为例,向大家讲解作为架构师应该具备的知识。

    互联网行业是当前最激动人心的行业之一,很多的创新都来自于这个行业,而每一个大型的网站如Google,Yahoo,Myspace等都需要解决一个非常复杂的问题,就是网站的分布式向外扩展(Scale Out)的问题。解决这个问题,需要最优秀的架构师对业务进行剖析,利用软硬件将网站进行重构,甚至根据业务研发相应的分布式技术,解决网站复杂的分布式计算的问题。

    如果你想在这个行业中成为一名架构师的话,需要至少掌握网络知识,硬件,软件,网站优化等方方面面的知识:

    网络知识

    当前的软件已经绝对不是那种仅仅跑在一台单机上的孤立应用了。不仅仅是在互联网行业,任何一个行业的软件,都要求其具有网络功能。因此,网络知识是架构师必备的知识。我们所说的网络知识,不仅仅包括TCP/IP,http等互联网行业常用的软件协议,也包括网络规划,甚至更具体的说,根据网站应用所处的地理环境进行网络规划。比如人们常说:“这世界上最远的距离不是生与死的距离,而是电信到网通的距离”(笑)如果应用是建立在中国的,就要考虑电信用户和网通用户访问网站的速度应该都比较快才可以。这时候的解决方案可能有多种,比如采用CDN(Content Delivery Network内容分发网络)使得网站的内容发布到离用户最近的服务器,又可以采用把服务器放在一些所谓的双线机房中,甚至将几种方案结合起来使用。这些都统统归到网络知识中。做为公司的架构师,要对这些知识都有所了解,才有助于在遇到问题时找到最佳答案。

    硬件知识

    了解硬件的极限,是架构师的基本功。我见过一些人,他们的眼中软件硬件都是没有极限的,需要资源就申请,系统性能下降了就买更高级的设备。然而,硬件的性能有很大一部分取决于I/O设备。而这些I/O设备依靠的都是机械物理运动,这种运动是有极限的。因此当资源访问量增大到一定的程度时,这种物理运动将成为瓶颈。比如说,在开发网站的过程中,记录访客的状态是一件很重要的事情,一般来说可以使用HttpSession来记录。而HttpSession的存储问题将是一个很大的挑战,尤其是多机共享Session时,将HttpSession存成文件并通过多机共享或网络备份的方式来解决分布式的问题是常用的方案,然而,架构师必须考虑到这种方案是有I/O极限限制的,很难扩展到超过一定规模的大型网络。同时,架构师应该了解目前最近的硬件发展是否对软件系统会造成一定的影响,比如在多核的条件下是否对软件编程有新的要求,是否会对运行在虚拟机和非虚拟机上的程序有影响等等。

    软件知识

    软件知识所包含的范围就更加广泛了。对于互联网行业来讲,架构师要了解操作系统,数据库,应用服务器等各方面的知识。比如说,如果网站使用的操作系统是 Linux,就要了解这个Linux版本的性能与局限性,比如说最多可以存放的单个文件为多大。有的数据库的数据是以单个文件来存放的,虽然我们很少见到数据库中的数据多到不能再放入一条记录的情况,但是作为架构师,请时刻注意,这种可能性是有的。而且如果你有幸在一家高速成长的互联网企业中,而你所负责的应用又没有经过优化的话,可能你会很快见到这种现象。这种现象的发生可能是由于操作系统不支持大文件的原因,也可能是数据库不支持大文件。不论如何,架构师应该在这种现象发生之前就把一切都准备好。对数据库中表的拆分是架构师应该遇到的另外一个困难。一般来说增加应用服务器比较简单而增加数据库服务器则是比较复杂的问题,如果一个站点由多个数据库支持,架构师需要考虑如何在保证数据一致的情况下,让多个数据库分担压力。有些解决方案是将数据库的读写分开,使得大多数的查询sql不经过核心数据库,而只是访问数据库的副本,但事实上,这种方式也只能维护规模不大的网站。对于大型的网站来说,把业务分散到不同的数据库中,只共享必要的数据,才是合理的提高网站扩展性的解决方案。

    其他知识

    作为系统架构师,可能还需要对分布式系统,负载均衡,网络安全,数据监控等等各方面都有所了解。不仅仅是了解理论知识,也要对相关的产品和业界进展有一定的认识。比如说做负载均衡最好的产品是那种。目前最常用的备份策略是什么,有什么缺点。如何使用缓存,如何做好日志分析等等。

    刚刚谈到的是架构师需要掌握的知识,然而,冰冻三尺非一日之寒。这个过程需要我们慢慢的积累。如果你已经进入到公司进行软件开发,请时刻关注你所开发软件的性能与可扩展性,而不仅仅局限在功能上,时刻想着任何一个简单的问题:我开发的模块如果放在多人并发的环境下会怎样,慢慢的就会有所心得。如果你还是一个在校学生,不要想着自己离架构师这个职位还很遥远。要知道,成为架构师的修炼之路是很长的,甚至可以说是终身的,因此早点进入学习状态,不断修炼自己。在学校期间学好离散数学,数据结构,操作系统,编译原理,体系结构,数据库原理等关键课程,并积极寻找机会到外面实习,增长自己的工作经验。如果有机会去到一些技术主导的公司中工作,就一定不要放弃这种机会,慢慢就会成长起来。最重要的,你会养成关注技术,勤于思考的好习惯。当有一天你发现自己对任何技术难题都可以一眼看到其本质,并能够将其分解为一个个可轻松解决的模块,你会由衷的感觉到知识给你带来的快乐,或许那一天,你已经是一个架构师了。

    展开全文
  • 测试架构师:5 测试策略实战攻略

    千次阅读 2018-08-14 15:38:59
      目录 1 开始 2 初次使用“四步测试策略制定法”  2.1 产品质量等级  2.2 确定项目中各个特性的质量等级  2.3 对项目整体进行风险分析  2.4 确定测试策略的结构... 为每个测试分层确定测试目标  3....

     

     

    目录

    1 开始
    2 初次使用“四步测试策略制定法”
      2.1 产品质量等级
      2.2 确定项目中各个特性的质量等级
      2.3 对项目整体进行风险分析
      2.4 确定测试策略的结构
      2.5 初步确定测试分层
      2.6 回顾
    3 制定总体测试策略
      3.1 分解产品质量目标
        1. 根据质量等级来分解产品的质量目标
        2. 为每个测试分层确定测试目标
      3.2 使用老功能分析法来对特性进行分类
      3.3 基于质量和风险来确定测试深度与测试广度
        1. 使用产品质量评估模型来初步确定测试深度
        2. 考虑用老功能分析来更新测试深度
        3. 基于老功能分析来初步确定测试广度
      3.4 确定测试优先级
      3.5 确定测试的总体框架
      3.6 回顾
    4 制定阶段测试策略
      4.1 测试设计策略
        1. 使用“测试分析设计表”来保证测试设计符合测试策略
        2. 四步测试设计法和测试广度
        3. 测试用例等级 
      4.2 集成测试策略
        1. “俄罗斯方块心”项目的集成开发
        2. 集成测试的对象和测试目标
        3. 入口准则——何时可以开始进行集成测试
        4. 测试用例选择
        5. 出口准则
      4.3 系统测试策略
        1. 系统测试的对象和测试目标
        2. 入口准则——何时可以开展系统测试
        3. 测试用例选择
        4. 测试执行顺序
        5. 出口准则
      4.4 验收测试策略
        1. Alpha测试
        2. Beta测试
        3. 入口准则——何时开始进行验收测试
        4. 出口准则——何时可以退出测试,发布产品
      4.5 回顾 

     

    假设现在有一个研发项目A开始了,我们的软件测试架构师也要投入项目了。此时项目产品的包需求已经基本完成,产品概念已经初步成型,如图1所示。

    图1 研发项目A示意图

    不过此时软件测试架构师对项目的了解还非常有限:

    • 知道项目叫什么名字。
    • 项目大致要做些什么内容。
    • 领导期望项目在什么时候结束。

    1 开始


     返回

    此时,软件测试架构师对项目的了解还非常有限,在制定测试策略之前,收集了解更多的项目信息非常重要:

    • 项目的范围。
    • 人力投入。
    • 历史情况。
    • ……

    2 初次使用“四步测试策略制定法”


     返回

    当我们收集了一些项目信息,对项目有一定的了解后,就开始准备制定测试策略了。这也是我们初次在项目中使用“四步测试策略制定法”,如图2所示。

    图2 对项目使用“四步测试策略制定法”

    2.1 产品质量等级

    产品质量评估模型,只能告诉我们该从哪些角度去评估产品质量,并没有告诉我们,怎样的评估结果可以被认为是好的质量,怎样的结果又是不好的质量。换句话说,我们还缺少一个评价质量的“刻度”,即产品质量等级。

    从最终用户使用的角度,我们将产品质量分为如下4个等级。

    • 第1级完全商用:特性完全满足用户的需求,有少量(或者无)遗留问题,用户使用时无任何限制。
    • 第2级受限商用:特性无法满足用户的某些特定场景,有普通以上的遗留问题,但有规避措施。
    • 第3级测试、演示或小范围试用:特性只能满足用户部分需求,有严重以上的遗留问题,且无有效的规避措施,问题一旦出现就会影响用户的使用,只能用于测试(如Beta)或演示,或者小范围试用。
    • 第4级不能使用:特性无法满足用户需求,存在严重以上的遗留问题,会导致用户基本功能失效,且无规避措施,产品根本无法使用。

    注意:产品质量等级虽然是在项目初期确定的,但定义的是产品在发布时的质量,而不是产品在测试过程中的质量,如图3所示

    图3 定义产品发布时的质量

    2.2 确定项目中各个特性的质量等级

    按照四步测试策略制定法,我们先围绕明确产品质量目标来展开分析

    此时,软件测试架构师需要对本项目中包含的特性,逐一确定它们的“产品质量等级”(表1)。

    需要特别说明的是:

    • 该项活动能够顺利进行的前提是产品的特性已经基本确定完成了。
    • 这项活动不应该仅由软件测试架构师来进行,需要需求工程师、研发经理等研发核心团队共同进行,对不同特性的产品质量等级能够达成一致。

    2.3 对项目整体进行风险分析

    按照四步测试策略制定法,在这个阶段,软件测试架构师需要从项目整体角度进行风险分析。

    此时,我们可以按照7.1节中介绍的“风险评估清单”,来对项目整体进行一次风险评估,并参考“风险应对”来考虑应对措施,增加一些质量保证活动。

    在确定风险应对措施的时候,需要区分这些活动是针对项目整体的,还是针对具体特性的。可以直接记录在产品质量等级表中备忘(表1)。

    表1 产品质量等级表

    2.4 确定测试策略的结构

    按照四步测试策略制定法,接下来我们将围绕产品开发流程来进行分析。

    图4 总分式的测试策略结构

    • 总体测试策略:确定产品质量目标,进行项目整体的风险识别,从产品层面来确定测试重点和测试难点、测试深度和测试广度,是测试策略的总纲。
    • 阶段测试策略:确定测试设计策略和测试执行策略需要达到的质量目标(产品质量目标的分解)以及能够进行这些测试活动的入口条件。
    • 测试执行策略:确定每个版本的测试目标、测试内容和每个版本的入口条件。

    总体测试策略从概念阶段开始,在计划阶段前期完成比较合适。因为这时产品的需求、质量目标和整体形态都已经确定下来,已具备了制定总体测试策略的条件,而且也需要这样一份文档来总领后面的测试活动,让测试团队成员心中有数。

    阶段测试策略在总体测试策略完成后随即展开,保证在开发阶段前期完成。这是因为,阶段测试策略最重要的目的,就是明确各个阶段的输入输出标准。在开发编码之前(或在前期)就把要求说清楚,可以让开发目标更明确,更有利于产品质量的提高。测试也可以根据双方达成的标准,准备接收测试用例、自动化测试环境等。如果阶段测试策略输出得过晚,这些活动可能就会来不及进行或者达不到期望的效果。

    测试执行策略在测试执行阶段,每个版本转测试之前输出即可。测试执行策略除了对阶段测试目标进一步进行分解到每个版本的粒度,还需要根据上一个版本的测试执行情况,对测试策略进行调整。

    图5 各类测试策略之间的关系

    2.5 初步确定测试分层

    按照四步测试策略制定法,接下来我们将进行与测试分层相关的分析。

    对软件测试架构师来说,此时我们可以结合研发流程,来初步确定一个测试分层。假设此时我们采取经典V模型中的测试分层,然后将测试分层和研发流程,以及测试策略的结构放在一张图上,初步将三者的对应关系梳理出来了

    图6 测试分层、研发流程和测试策略结构的对应关系

    2.6 回顾

    们先来总结一下到目前为止,软件测试架构师取得了哪些进展:

    • 明确了特性的质量等级,并且和各个研发核心团队的成员就质量目标达成一致意见。
    • 从项目整体角度进行了风险分析,有了需要做哪些质量保证活动的初步计划。
    • 确定了测试策略的结构为总体测试策略—阶段测试策略—测试执行策略。
    • 初步确定了测试分层,并且梳理出了测试分层、研发流程和测试策略结构的对应关系,初步建立了一个测试的框架。

    通过这次实践,我们发现只使用一次四步测试策略制定法,是无法得到最终的测试策略的。

    首先,这和项目所处的阶段有关。一些和测试策略制定相关的、必要的、重要的信息,只有到项目的某些阶段才会清晰,所以我们需要按照测试策略的结构,在项目的不同阶段多次使用四步测试策略制定法来制定测试策略,如图7所示。

    图7 多次使用四步测试策略制定法制定测试策略

    其次,四步测试策略制定法中的4个步骤之间并不是瀑布式的单向关系,而是全网状的双向关系。图8更为准确地表达了这4个节点之间的关系。

    图8 4个节点间的关系

    例如,产品质量目标变高了,对此我们可能会增加一些测试分层,这使得研发流程也发生变化,也引入了新的风险。

    所以我们在使用四步测试策略制定法时,发现进行到某个步骤进行不下去了,可以将这个步骤停一下,进行下一个步骤,然后再回过头来进行这个没有做完的步骤,这时往往会有新的收获。

    3 制定总体测试策略


     返回

    接下来我们将在之前分析的基础之上,再次使用四步测试策略制定法来制定总体测试策略,如图9所示。

    图9 制定总体测试策略

    3.1 分解产品质量目标

    我们可以对质量等级再进行分解,整体思路如图10所示。

    图10分解质量等级

    1. 根据质量等级来分解产品的质量目标

    我们可以根据之前确定的产品质量等级,来为产品质量评估模型中的项目建立不同的质量标准,从而达到分解产品质量目标的目的。

    我们可以根据项目的实际情况、历史情况和公司整体基线,确定出一个分级的标准,作为产品质量目标的分解项,见表2。

    表2 定量指标分级标准

    注:

    • “不涉及”指该项目可以不予关注;
    • 可以根据项目和产品的实际情况选择部分分析项。

    表3 特性—质量等级表

    软件测试架构师不必对每个特性,都输出一个质量目标分解表,而是在“特性—质量等级”表中加入一个超链接即可。

    2. 为每个测试分层确定测试目标

    接下来我们需要根据各个质量等级的质量目标,再确定每个测试分层需要达到的质量目标。以“完全商用”为例,见表4。

    表4 完全商用示例表

    3.2 使用老功能分析法来对特性进行分类

    在现在这个阶段,开发还没有开始对特性中的功能进行设计,所以我们还无法使用老功能分析法来对每个功能特性进行详细的分析,但是我们已经基本能够知道:

    • 哪些特性是新开发的。
    • 哪些是从老版本上继承而来的。
    • 哪些特性的改动估计会比较大。
    • 从老版本继承而来的特性的历史测试情况。

    这时,软件测试架构师可以根据项目的实际情况,考虑上述几个方面,来将被测对象做一下分类,并对每一类确定一个测试策略。表5是一个例子,供大家参考。

    表5 示例

    3.3 基于质量和风险来确定测试深度与测试广度

    1. 使用产品质量评估模型来初步确定测试深度

    我们使用产品质量评估模型中的测试过程—测试方法项,基于不同的质量要求,来确定测试深度,见表6。

    表6 确定测试深度

    2. 考虑用老功能分析来更新测试深度

    我们再根据前面老功能分析中的测试策略,更新老功能中的测试深度(可以考虑先标记出需要调整的地方),见表7。

    表7 更新老功能中的测试深度

    3. 基于老功能分析来初步确定测试广度

    从产品质量评估模型的角度来说,无论产品的质量要求是高还是低,我们都希望在测试中能够对需求进行100%的覆盖,相应的所有测试广度都应该是100%覆盖。

    但实际上,对一些老特性,特别是那些在新版本中没有改动,并且历史测试情况也不错的特性,我们可以考虑缩小测试范围,少测或者不测。不过毕竟现在我们还处于项目的概念或计划阶段初期,还没有进行详细的老功能分析,但这时我们还是可以初步分析出一些可以缩小测试范围的特性。

    3.4 确定测试优先级

    接下来软件测试架构师可以根据质量目标和分类来确定测试优先级。基本原则是质量等级越高,优先级越高;在相同的质量等级下,全新特性比老特性的优先级高;改动越多的老特性,优先级越高。

    确定测试优先级的一个简单的方法是使用评分表。我们首先对质量目标和分类分别设置一定的分值,见表8和表9。

    表8 质量目标分值表 

    表9 分类分值表

    然后再准备一张优先级的分数范围表(表10)。

    确定的测试优先级,将主要用于测试投入的安排上。我们可以根据优先级的等级,制定出一个测试投入的策略,见表11。

    3.5 确定测试的总体框架

    测试框架可以理解为如何组建测试。

    们将测试框架构建为三层:策略层、活动层和保证层。

    如果把测试整体看成一个“人”:

    • 策略层就像是人的大脑,负责指挥测试该如何进行,确保测试做的是正确的事情;
    • 活动层就像是人的身体,负责具体的执行;
    • 保证层就像是人的五官,保证身体能够顺利地执行任务。

    我们将测试策略和测试活动按照测试框架绘制出来,并按照研发流程和测试分层来组织这些测试活动的先后次序,作为测试的总体框架,如图11所示。

    图11 测试总体框架

    3.6 回顾

    让我们回顾一下,到目前为止我们取得的进展:

    • 分解了产品质量目标。
    • 基于风险对特性进行了分类。
    • 确定了测试深度和广度以及测试优先级,确定了测试投入策略。
    • 确定了测试的总体框架。

    事实上,进行到现在,我们可以认为软件测试架构师完成了总体测试策略的制定。

    总体测试策略最后的输出究竟是什么呢?其实就是两张表和一幅图。

    第一张表,是我们在文中一直模糊地称其为“特性—质量等级”表并不断向其中添加内容的那张表。现在我们终于可以为其正名了——其实它的真名叫“总体测试策略分析表”。

    表12 总体测试策略分析表

    第二张表是测试投入策略表,见表13。

    最后的图就是我们的测试总体框架图,如图12所示。

    图12 测试总体框架

    4 制定阶段测试策略


     返回

    图13 制定阶段测试策略

    软件测试架构师在制定总体测试策略的时候基本处于“单打独斗”的状态,整个测试团队中可能就只有软件测试架构师投入。到了制定阶段测试策略的时候,测试团队中的其他成员才会开始投入,进行测试分析和设计。因此阶段测试策略需要能够向上承接总体测试策略,立马指导测试分析和设计,向下能够指导后面的测试执行。

    4.1 测试设计策略

    在制定总体测试策略的时候,软件测试架构师已经为产品特性确定了测试深度。但测试深度是从测试方法的角度去描述的,我们在测试执行的时候,并不会按照测试方法去测试,而是按照测试用例去测试。也就是说,我们需要按照测试深度来进行测试设计,然后我们再执行这些测试用例,以达到以特定的测试深度来进行测试执行的目的。

    1. 使用“测试分析设计表”来保证测试设计符合测试策略

    “测试分析设计表”是对每个功能或特性进行测试设计的辅助工具,使用测试分析表的好处是:

    • 软件测试架构师可以通过配置“测试分析准备表”来控制测试设计的深度。
    • 测试设计者能够在表中非常方便地记录下测试分析的过程。
    • 评审者很容易看出设计者考虑了哪些地方,没有考虑哪些地方,考虑的深度是否合适。

    “测试分析设计表”由3张表构成:“测试分析准备表”“测试类型分析表”和“功能交互分析表”。

    1)测试分析准备表

    “测试分析准备表”的主要作用是为被测对象配置在测试设计中需要考虑哪些“测试类型”(可以理解为测试方法,包括功能和非功能方面)和“功能交互”(可以理解为需要将哪些功能放在一起考虑,它们是否需要进行“多运行相互作用”和“多运行顺序执行”的测试)。

    图14 示例

    图14是一个示例。以其为例,这样配置的意思是:

    • 被测对象需要从功能、配置、一致性、安全性、性能、压力、稳定性、兼容、升级、备份、易用性方面来考虑测试点。
    • 被测对象需要分别和安全特性、VLAN等功能结合起来考虑测试点。

    软件测试架构师可以通过配置“测试分析准备表”来控制测试深度。

    2)测试类型分析表

    “测试类型分析表”如图15所示。

    图15 测试类型分析表

    其中的“列”为待分析的需求,“行”为测试类型。至于行表头中会有哪些测试类型,这和我们在“测试分析准备表”中对测试类型表的配置有关——我们只对配置了的测试类型进行测试类型分析。

    图16 参考实例

    图17 分析结果汇总表

    3)功能交互分析表

    “功能交互分析表”和“测试类型分析表”类似,如图18所示。

    “行”表头中显示的需要进行功能交互分析的功能,依然和“测试分析准备表”中的“开发特性表”保持一致。而“列”的内容就不是“原始的需求”了,而是测试类型分析结束后,我们识别出的需要再进行功能交互分析的测试点。

    图18 功能交互分析表

    图19 参考示例

    2. 四步测试设计法和测试广度

    通过“测试分析设计表”输出测试点,完成了测试分析活动后,测试设计者就可以使用四步测试设计法来对测试点进行测试设计,输出测试用例了。

    此时,需要软件测试架构师制定一个测试设计中的路径覆盖策略

    前面已经介绍了路径覆盖度评估的基本方法,我们可以参考其中步骤1和步骤2,用总体测试策略中优先级来定义不同的路径覆盖策略,见表14。

    表14 用优先级定义路径覆盖策略

    3. 测试用例等级

    设计好了测试用例之后,建议软件测试架构师再让测试设计者对测试用例分一下级。我习惯将测试用例分为四级,每一级的定义,对应的测试深度和对应的测试分析设计表,见表15。

    表15 测试用例分级

    测试用例分级将会为后面的分层测试、回归测试、验收测试和自动化测试在如何选择用例方面,带来莫大的方便。

    4.2 集成测试策略

    集成测试位于产品研发流程的开发阶段。所谓“集成”,可以理解为不断开发功能并将功能集成到系统中,最后完成整个系统的开发过程。

    1.“俄罗斯方块心”项目的集成开发

    假设用户希望我们开发一款叫“俄罗斯方块心”的产品,如图20所示。

    图20 俄罗斯方块心

    通过分析,开发很快将产品划分为如下几个基本功能,如图21所示。

    图21 基本功能

    并制定了通过4个build来把功能开发完如图22所示。

    图22 功能开发和系统集成计划

    这样,每一个build后,产品的集成形态如图23所示。

    图23 产品的集成形态

    4个build完成后,我们的系统也就完全集成好了。

    “俄罗斯方块心”虽然是个虚拟项目,却能帮我们很好地理解产品的集成开发过程,确定集成开发阶段的测试策略。

    2. 集成测试的对象和测试目标

    让我们再来仔细分析一下“俄罗斯方块心”的集成开发过程:

    开发者按照计划,完成本build计划要集成到系统的功能开发后,需要通过单元测试来测试功能的正确性;测试通过后,开发者将功能集成起来,构造系统(这个过程有时候又叫“联调”)。构成完成之后的测试,就是我们的“集成测试”。

    图24 build2的集成开发过程

    其中单元测试是为了测试“新开发的功能和模块是否符合设计”,是“白盒测试”,使用内部接口进行测试。

    而集成测试相当于是在测试验证“新合入功能能否在系统中被正确地装配起来”,是“黑盒测试”,也是系统级的测试,应该使用系统提供给用户的输入接口来进行测试,使用提供给用户的输出接口来判断接口的正确性。

    “功能能够在系统中被正确装配”隐含了一个前提就是“功能是我们想要的那个功能”。而单元测试只能确认功能的实现是符合设计的,却不能保证功能恰好就是我们想要的。因此,集成测试需要测试的内容包括如下几项

    • 使用黑盒测试的方法来确认新合入的功能是否正确。
    • 验证功能集成后系统功能的正确性。
    • 确认原来的系统功能没有被新合入的功能所破坏。

    3. 入口准则——何时可以开始进行集成测试

    集成测试的入口准则等同于“第一个集成计划中提交的功能能否进行集成测试”。

    • 条件1:第一个集成计划中的功能开发完成,并完成了单元测试。
    • 条件2:第一个集成计划中的功能集成完成,并可测。条件2的重点在于“可测”,即开发需要提供基于用户的输入输出接口,而不能是内部的函数接口,确保测试能够进行系统级的黑盒测试。
    • 条件3:测试团队已经做好了测试准备。
      • 测试用例已经输出,并通过了评审。
      • 测试资源已经到位。
      • 测试环境已经准备好。

    4. 测试用例选择

    明确了测试内容,测试用例的选择就变得容易了

    • 针对功能确认的测试,可以选择相关功能level 1的测试用例。
    • 针对“测试新功能集成”的测试,可以选择相关功能level 2的测试用例和部分level 3的测试用例。
    • 针对“确认原系统”的测试,可以选择相关功能中level 1的测试用例。

    其中“部分level 3的测试用例”是指在集成测试后期,系统已经相对比较成熟和稳定的时候,也可以适当选择一些性能、稳定性和压力方面的测试用例来进行测试,以避免这些“非功能”方面的问题在系统测试阶段密集爆发。

    5. 出口准则

    当我们达到了集成测试阶段的目标后,就可以退出集成测试。

    出口准则包括:

    • 系统需要集成的功能已经全部开放、集成完成。
    • 计划执行的测试用例已经完成。
    • 缺陷分析的结果符合预期。
    • 达到了集成测试阶段的产品质量目标。

    4.3 系统测试策略

    从系统测试开始,产品研发流程进入到测试阶段。

    1. 系统测试的对象和测试目标

    我们可能会有这样的疑问:在集成测试结束的时候,这个心形图案就已经完成了,并且我们也进行了测试,为什么还要再进行系统测试呢?或者说这个问题从测试的角度来看,就是已经在集成测试中执行了的测试用例,在系统测试中还需要再执行一遍吗?集成测试和系统测试的差异主要在哪里?

    做集成测试的时候:

    • 目光是紧盯着新开发的功能的。而且随着功能的不断集成,系统的复杂性开始急剧膨胀,我们很难(或者说没有足够的测试时间,或是说系统还不够稳定)来把和功能相关的所有组合都验证完。
    • 更重要的是,集成测试主要还是针对功能的集成,在集成测试中我们无法(或者说没有足够的测试时间,或是说系统还不够稳定)对被测对象的其他非功能方面的质量来进行测试验证。、

    在系统测试中需要测试的主要内容包括:

    • 从系统角度来验证测试功能的正确性。
    • 从系统角度来验证各种非功能的质量的正确性。

    2. 入口准则——何时可以开展系统测试

    系统测试的入口准则,就是集成测试的出口准则,再加上一条:测试团队已经做好了测试准备,包括测试用例、测试资源和测试环境都已到位。

    3. 测试用例选择

    现在我们来回答本节开头提的问题:我们在集成测试中执行了的测试用例,在系统测试中还需要再执行一遍吗?
    答案是,系统测试和集成测试的测试用例肯定会有相同的部分,但并不是简单地重复一遍,而是存在一定的选择策略。

    • 针对“系统角度的功能测试”:可以选择level1和部分level2的测试用例。
    • 针对“非功能的质量的正确性”:可以选择level3的测试用例和level4的测试用例。

    4. 测试执行顺序

    我们在集成测试中并没有讨论测试执行顺序,是因为集成测试的测试对象很单一,就是“功能”。虽然后面我们提到在集成测试的后期,可以考虑增加一些“非功能方面”的测试,但是总的来说这并不会给测试带来先执行什么再执行什么的困扰。

    软件测试架构师在考虑测试执行顺序的时候,可以基于如下几点:

    • 有些测试方法本来就需要满足一些条件才能进行。例如,满规格测试需要在基本功能正常的情况下才能进行,否则将很难区分问题到底是出在规格上,还是功能上。这就需要我们按照测试方法本身的条件来安排测试执行顺序。例如,先进行稳定测试,再进行压力测试,然后进行恢复测试。
    • 如果有两种测试方法,都能对测试对象进行测试,先进行复杂的,再进行简单的。或者说,尽量先执行复杂的、难的测试用例,再进行简单的测试用例。这样考虑的原因是,希望缺陷能够尽量在测试的前期发现,另外先执行难的测试用例也能保证这些测试用例有充足的测试时间。
    • 可以考虑组合多种测试方法,或者说让测试者想办法把一些测试用例放在一起执行。例如,可以将功能测试的测试用例和满规格的测试用例放在一起进行,在满规格的情况下测试功能。这种测试执行顺序特别适合系统测试中需要重复执行、集成测试中已经执行过的那些测试用例,往往可以发现很多新的问题。

    5. 出口准则

    当我们达到了系统测试阶段的目标后,就可以退出系统测试。

    出口准则包括:

    • 计划执行的测试的用例已经完成。
    • 缺陷分析的结果符合预期。
    • 达到了系统测试阶段的产品质量目标。

    4.4 验收测试策略

    验收测试是产品在发布前的一种测试,它是对用户需求的确认事实上,我们进行验收测试已经不再是为了发现产品的问题,而是为产品能够正常发布建立信心。

    验收测试的对象是需求,需要基于用户场景来测试。

    验收测试包含Alpha测试和Beta测试两种。

    1. Alpha测试

    Alpha测试是由测试人员模拟用户进行的测试。

    1)谁来进行Alpha测试

    理想的Alpha测试人员,应该是不太了解产品实现细节,但是对用户非常了解的人。按照这个标准,市场人员、系统工程师或是技术支持人员都可以是理想的Alpha测试人员,他们可以站在用户的视角,对产品质量再次进行审视。

    让测试组员相互进行交叉验收,似乎是个不错的选择——这确实可以消除“审美疲劳”,发现一些问题,但是交叉验收却很难达到从用户的角度再去审视一次产品的效果。与交叉测试相比,更有效的方法是,测试部专门成立一个“验收测试组”,由测试部中比较有经验、测试能力强,且对行业、对用户都有一定了解的测试人员来担任,让他们来作为产品发布前的最后一道防线,这无疑是最能保证Alpha测试效果的做法。

    2)Alpha测试策略

    Alpha测试不是系统测试的延续,它是产品交付的序曲,它的测试重点应该放在“确认在用户真实的环境下,用户的业务、用户的使用习惯是否能够满足”需求上。模拟用户的真实环境,把自己催眠为用户,能够以用户的思路来看待产品,是Alpha测试不折不扣的难点。

    下面的清单也许可以帮助我们进行Alpha测试分析,找到产品在Alpha测试中需要关注的重点内容:

    • 用户将会如何学习产品?
    • 产品提供的资料(如手册、指南、视频)是否能够对用户提供切实的帮助?
    • 用户会将产品安装部署在怎样的环境中(包括用户会使用到的硬件、操作系统、数据库、浏览器等)。
    • 在用户的环境中能否正确升级?升级对业务的影响是否在用户容忍的范围内?升级对已有功能的影响是否符合用户需求(如升级后不能丢特性)?
    • 产品在用户的环境中能否被正确移除?
    • 产品在用户环境中的上下游设备是什么?在这样的环境中,产品能否正常使用?
    • 用户环境中可能会有哪些业务?哪些业务是我们产品需要关注的,哪些业务是我们产品不需要关注的?对那些我们不需要关注的业务,我们的产品会怎么处理?
    • 用户的环境中可能会有哪些故障?对这些故障,我们的产品会怎么处理?
    • 用户会怎么管理、配置产品?
    • 用户会如何使用产品的日志、告警、审计、报表等和运维相关的功能?

    2. Beta测试

    Beta测试是由用户参加的测试。常见的方式有如下两种:

    • 在产品正式发布之前将产品提前发给用户,收集用户的反馈。
    • 在产品开发完成后,交由用户对产品进行验收。

    第一种方式下的Beta测试的困难之处在于确定测试的时间和参与者。对测试者来说,倒不需要对上面两个问题做出决策,而是分析、复现参与者发现的问题,将问题整理为bug报告,直至确认bug被解决。
    第二种方式下的Beta测试,需要保证产品能够通过用户的验收测试,能够交付给用户使用,这时的测试需要围绕用户的验收方案进行,并结合用户的使用习惯和用户所在的行业特点,做好充分的准备。

    3. 入口准则——何时开始进行验收测试

    验收测试的入口准则,就是系统测试的出口准则再加上:

    • Alpha测试的人员、方案已经选好。
    • Beta测试的用户已经确定。

    4. 出口准则——何时可以退出测试,发布产品

    当我们根据产品质量评估模型,确认产品已经达到总体测试策略中的产品质量目标后,就可以退出测试。

    4.5 回顾

    现在软件测试架构师已经走到了图25中所示的位置

    图25 完成阶段测试策略的制定

    我们还是先来总结一下,到目前为止,软件测试架构师已经确定了哪些内容:

    • 确定了测试设计策略,通过《测试分析设计表》来保证测试团队的测试设计都能符合测试策略,并确定了测试用例的等级。
    • 确定了各个测试阶段的测试策略。

    从2节开始,我们就没有说明当前的活动对应的是四步测试策略制定法中的哪个步骤了,而是在尽量按照四步测试策略制定法的思路来组织文章的内容。
    到目前为止,还没有进行产品测试,这使得我们的测试策略多少还是有点儿“纸上谈兵”的意思。进入产品测试阶段后,测试策略的效果立马就可以通过缺陷分析呈现出来,这时软件测试架构师的工作模式将变为图7-42所示的样子。

    图26 软件测试架构师的工作模式

    展开全文
  • 测试架构师

    2019-08-06 19:07:01
    在测试行业干了有些年了,现在中国带领一个测试架构师团队。回想当年干了一年软件测试后,发现在中国几乎没有什么软件测试的招聘信息,感到未来的迷茫。在迷茫中动摇过,痛苦过,甚至短暂离开过一线测试工作,但一直...
  • 如何成为测试架构师

    千次阅读 2018-06-21 13:50:53
    最近老有人问我如何成为测试架构师, 或者问如何从零开始构建起来分层测试体系. 我都不知道如何回答.首先测试架构师只是个虚名, 本质就是个测试开发工程师. 行业里面其实都没这个正式的名分.要说特别的话, 就是一定是...
  • 我眼中的测试高手—测试架构师

    千次阅读 2017-11-15 10:22:57
    1.概述  既然是写我眼中的测试高手,得先容我作一下自我介绍,让你们...做过以下工作:写代码,软件设计,项目管理,性能测试(数据库性能监测及优化、前端性能测试),自动化测试工程师,设计、执行测试用例、项目部署(数据库
  • 这是因为软件测试是一门基于实践的学科,对软件测试来说,“管理”不可能是“绝对的管理”,软件测试的管理者首先要是产品测试技术专家,这是“做正确的事”的基础,很难想象一个不懂测试技术、不理解
  • 谁能成为软件测试架构师

    千次阅读 2012-05-02 14:02:01
    软件测试架构师不是一种头衔,而是一种角色,更重要的是一种能力—对团队的影响力。软件测试工程师不是在某一天突然成为一个软件架构师的,虽然他可能会在某一天被某某经理宣布为测试架构师。任何一个人成为软件架构...
  • 谁能成为测试架构师

    千次阅读 2012-05-17 13:52:08
    谁能成为测试架构师  软件测试架构师不是一种头衔,而是一种角色,更重要的是一种能力—对团队的影响力。软件测试工程师不是在某一天突然成为一个软件架构师的,虽然他可能会在某一天被某某经理宣布为测试架构师。...
  • 这本书是小编去年阅读的一本书,觉得很不错当时就整理总结了一下,绘制了下图在团队内部进行了分享。 最近又温顾了一下,还是很受启发。...这是团队的小伙伴找到的对于微软测试架构师的认识和理解,也拿...
  • 软件测试架构师

    2008-02-18 16:14:00
    而对于“软件测试架构师”, 众里寻她(他)千百度,那人何在?难以上青天。 软件测试架构师是一个新职位,但确实是一个非常必要的职位,主要有几点:- 根据V模型、广义测试概念等,(静态)测试的越早,发现缺陷...
  • 人人都是测试架构师

    千次阅读 2013-06-24 15:50:44
    然随着软件测试行业的兴起,随着测试职位从业人员的增多,测试架构师,这个光辉的职位也应运而生。 测试架构师,向一座灯塔,指引着我们前进的方向,像隐形的翅膀给我们前进的动力。然而这条伟大的“修仙之路”,是...
  • 再谈测试架构师

    2020-05-10 19:33:40
    之前的博文:《从菜鸟到测试架构师一个测试工程师的成长日记》笔记与思考 一、目标与能力 目标 测什么 怎么测 拿结果 1、测试方案设计 测试的深度和广度是什么 测试的重点和难点是什么 2、技术方案设计 工具...
  • 测试架构师需要做些什么 测试架构师听起来确实一个很酷的名字,至少已经跟上开发的步伐了,那么测试架构师需要做些什么呢,他需要哪些技能? 先请大家浏览下图:我把这幅图简单地归结为: 一个中心,一类产出,两种关系 一...
  • 测试架构师日记第一篇 测试架构师必须具备的第一个能力:“准确的商业理解力。” 最近在51testing看到一篇关于测试架构师介绍的文章,文章中的测试架构师原型来自微软,其描述的工作内容让不少国内的测试同业很是...
  • 测试架构师修炼之道--读后感

    千次阅读 2018-04-27 21:52:18
    为了学习测试技术,研究测试的前世今生,提高自我知识水平,买了比较多的测试类书籍,本书也是其中之一,没想到竟然一口气读完了,总体上感觉本书思路清晰,讲解到位,语言风格朴实,逐步递进式的讲解思路,并附有...
  • 测试 架构师总结:一个中心,一类产出,两种关系 一个中心:保证质量为中心 一类产出:保证自动化回归体系的持续集成 两种关系:与开发和测试人员的关系 工作着眼点:性能,安全性,可测试性,可持续集成 ...
  • 一、测试的本质1、测试其实是发现并解决问题的过程,而其 目标则是让软件产品以尽可能高的质量交付给客户,使软件产品中存在的问题尽可能少、运用风险分析和不同系统功能的测试优先级,来确定测试的关注点,从而替代穷尽...
  • 通往测试架构师之路(1):那些家伙在干什么?

    万次阅读 热门讨论 2007-06-10 17:22:00
    Omomo在公司呆了有几个年头了。在测试技术方面的技能长进了不少,又能享受写代码的乐趣,同事们经常交流对软件测试技术的见解,也在项目中实现一些创新的...他们就是那些在公司内部挂着“测试架构师”头衔的一小撮人。T
1 2 3 4 5 ... 20
收藏数 116,491
精华内容 46,596
关键字:

测试架构师