您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试管理 > 其他 > 正文

围绕效率提升做的事情

发表于:2018-01-28 作者:杨晓慧 来源:软件质量报道 点击数:


大部分的研发经理心中,进度是第一位的,其次是成本,最后是质量,当然人员队伍最好稳定。天下武功,唯快不破:进度 > 成本 > 质量 > 人。
围绕效率提升,测试可以做什么?你脑海里跳出来的,应该是“自动化”或者“敏捷”吧,没错,自动化和敏捷都可以帮助提升研发效率,但是并不是只要做了都有这个作用。
下面来看看测试支持效率提升的不同段位。
一段:提升测试效率。
提升测试的效率,最有效的手段是制定测试策略。对,你没有看错,是测试策略而不是自动化!

测试策略提升测试效率的逻辑是:减少不必要的测试,重要的问题早发现早解决。测试策略的基础是风险评估,首先从失效概率、失效影响这两个维度,区分高、中、低风险的特性。
1.失效概率是发生错误的可能性,评分一般是依据:同类特性的历史表现,设计中需要考虑的要素多寡,需求变更的频繁程度,是否采用新方法等(影响失效概率的因素参见本节的注释)。
2.失效影响是错误发生造成的影响,评分的一般是参考:错误失效对主要业务流程的影响范围,给研发团队以及客户带来的直接经济损失,修复成本,信誉影响等。
这两个风险维度的评分虽然有一些参考维度,但主要是依赖经验。
风险评估完成后,根据每个测试内容的风险评分,确定测试的时间和强度(测试强度通常是用千行代码用例数来衡量)。原则上高风险的内容要尽可能早测试,低风险的内容在计划安排上灵活性可以大一些。高风险的内容要多测试,比如考虑多种测试设计方法同时使用,安排探索式测试等。测试的过程中,需要持续的分析缺陷数据、指标数据,以确定风险是降低还是升高了,如果发现风险升高,甚至已经成为会阻碍产品发布的问题,则必须进行例外报告,调整开发和测试策略。
提升测试的效率,基于需求的测试也是有效手段之一。基于需求进行测试设计的目的,是减少不必要的参数组合和虚构的应用场景的测试用例。当然,只基于需求进行测试,往往不那么让人放心,因为总会有意外的情况发生,一般还需要再基于经验、基于错误猜测或者基于在线应用采集的应用场景进行一些补充。对于特别重要的测试内容,可能还需要基于设计进行更高强度的测试
那么,为什么不是自动化?大多数时候,我们是将原本手工执行的功能和DFX测试自动化执行,这种情况下自动化测试更多的是服务于质量,其目的是发现新特性对老特性产生的,不为人知的影响。如果新特性每次发布,都导致老特性发生意外的变化,进而导致测试不得不在每个版本都全面测试老特性,那么这种自动化就是提升测试效率的。不过,这种情况比较少见,而且,如果真的发生这种情况,一定是产品架构设计出了问题,优化架构比实现自动化测试的优先级要高。
二段:提升开发效率,测试不再局限于测试活动本身。
测试帮助提升研发效率,最有效的手段是自动化和工具化,这两个手段是实现TDD和缺陷快速定位的关键措施。

TDD的作用,是用测试用例的形式表述需求或设计目标,从而确保codeing过程中,始终在做正确的事,在向主干中加入各种分支处理逻辑、或者进行各种修改时,不会破坏已经正确的功能,让开发可以放心的修改缺陷或者重构代码。在TDD实施中,测试的主要价值是提供趁手的工具,这个工具不仅要能够驱动测试用例执行,还要让开发很方便的构建测试用例及其执行所需的条件。我们有些团队在TDD实施的早期,把TDD用例编写和调试的工作也交给测试完成,这种方式无法让开发及时验证自己的每一次改动,做不到及时的质量反馈,也起不到TDD宣称的那些作用,不建议采用。
缺陷快速定位为什么要拿出来讲呢?因为,我们曾经统计过开发的工作量,在实现阶段,大概有1/3~1/2的开发工作量是耗费在缺陷的确认、重现、定位、修改、验证,如果能加快这个过程,则开发效率会有大幅提升。
通过缺陷辅助定位工具,可以提高这部分工作的效率。在一个用例执行不通过的时候,工具自动采集缺陷定位所需的信息,如:系统产生的日志和其他过程与结果记录,产生变化的数据库记录,此用例执行覆盖到的代码。通过这些信息,可以在无需重现、无需跟踪执行的情况下定位大部分的问题。当然,要实现这个目的,仅仅有工具是不够的,还需要产品做一些日志上的增强,例如在函数的入口和出口记录函数的输入、输出参数。缺陷修改完成后,再用自动化用例进行验证,就能够对开发的缺陷定位产生积极影响。
很多团队中,开发会把测试提交的缺陷集中在某个时间去修改,也是为了压缩处理缺陷的时间,但是这样会导致质量风险在开发后期集中爆发,是不值得借鉴的方式。
提升代码质量,除了TDD和缺陷定位,还可以在环境准备、测试结果采集上,使用工具和自动化提升效率。 
三段:提升版本发布效率,测试服务于研发整体而不是某个环节的效率提升。
测试帮助提升版本发布的效率,主要方法是自动化和CI(持续集成)、持续交付。

自动化是CI的基础,而自动化及CI是持续交付的基础。CI对自动化的要求,除了用测试用例进行自动化的产品验证,还包括自动化的编译、打包、部署、环境检查等。
持续交付在一般CI的基础上,通常还需要做到应用场景的自动化验证(通常是基于UI的自动化测试,用于冒烟测试)、常规性能的自动化验证,不同环境的统一部署,以及按不同的策略发布。一般的组织中,持续交付主要还是用于向专门的测试团队交付产品版本。某些互联网公司能够做到将持续交付用于生产环境,这种场景下,除了上述能力,还需要在产品上线初期进行自动化的异常侦测,看护系统和业务的正常运行,此外,还应该有比较可靠的系统和数据回滚机制。在生产环境中,要使这个过程安全的走下来,验证用例最好能比较完整的覆盖基本功能和新增需求,也需要根据历史问题不断完善看护、侦测规则。
发布时对基本功能的覆盖,除了传统的人工编写自动化用例的方式,利用在线运行抓取实际场景是更能让测试适配产品更新节奏的方式。
理想情况下,CI可以做到每天(也可能是每周或者其他的周期)都能够有一个质量过关的版本为上线做好了准备。这是比较理想的情况,我没有见到过真正这样实施的团队,在我们团队中,CI更多的还是在开发过程中,检查程序员的代码质量,起到的是质量门槛的作用。
持续发布是研发整体的工程能力提升,需要的不仅是研发团队的工具开发能力,还需要在过程管理、配置管理,甚至产品架构、质量文化等方面进行匹配。持续发布的实施,有专门的书籍做了详细介绍。 
四段:提升特性交付效率,测试不是依赖工具和自动化,而是依赖分析设计服务于效率提升。
测试帮助提升特性交付的效率,需要做到基于需求的测试,此外,敏捷也可以提升特性的交付效率。
基于需求的测试中,测试帮助研发团队在需求实现方面少一次试错。很多团队认为自己是基于需求进行测试的,但实际上是基于“需求规格说明书”进行测试,后者依赖一份质量优良的文档(标准是,内容完整且正确,研发各个环节都可以完全依据这份文档开展工作,并最终得到正确的特性),但通常这个依赖条件不存在。

 

基于需求测试需要做到:
1.改善需求质量。利用需求内容模型(5W1H)促进需求内容完整性的提升,利用测试对产品、业务的理解,通过静态测试发现需求中的遗漏、矛盾、错误,从而改善需求,即测试设计输入的质量。
2.基于需求测试。根据需求进行单个操作、业务场景和端到端应用场景的测试。并在测试执行时,通过研发测试、邀请客户和需求工程师参与体验和演示等方式,在产品特性半成品上,利用形象的操作过程对抽象的分析进行验证和纠错。
基于需求的测试除了要会使用上述方法,也比较依赖测试工程师的经验,因为实际应用过程中,我们通常都是参照已经成熟的特性,曾经犯过的错误来进行查缺补漏。 
敏捷提升交付效率的基本逻辑是实现按特性开发和交付首先,应对这种小步快跑的方式,测试需要及时实现对少量的新增和修改内容进行测试,在最短的时间内进行质量反馈,这要求测试设计、测试执行(自动化测试),甚至发布、部署都要能够在迭代周期的时间窗内完成。其次,按特性发布可以让客户尽可能快的看到和使用特性,以便更快的进行产品应用层面的质量反馈,因此,如果团队按特性开发了,但是并不能按特性交付,那么对于交付效率的提升还是只完成了一半。
敏捷是建立在研发的质量文化、产品的架构优化、测试的自动化水平之上的研发模式的演进,如果没有这些基础,仅仅依靠模式的改变是无法既提升效率,又维持质量稳定的。 
围绕效率提升,测试可以开展的工作远不止上面提到的这些,也一定还有做到更高段位的团队实践(提升产品交付效率的DevOps),期待……