某项目组正工作得热火朝天的时候，突然接到一个紧急任务：两天后领导要给客户演示一项新功能，必须要两天内高质量上线。

　　项目组全部成员就开始集中火力全力支撑此紧急任务，除了赶工外，还把原本计划的功能很大部分挪到下一个阶段。

　　最后这种顶着压力上线的任务质量堪忧，甚至可能成为一个恶性循环。

　　相信类似的经历，很多项目组都会遇到，并且在敏捷文化盛行的今日，需求快速变化，快速占领市场几乎是软件行业的家常便饭。

　　而作为软件测试人员来说，如何能够保证紧急任务来临时，避免成为交付的最大的瓶颈是一个较大的考验。测试人员在完成任务的同时更应该去思考如何形成处理这种紧急任务的操作流程。

　　心理准备工作

　　所谓修行先修心，首先我们需要端正态度，平心静气，做好自己的心理建设。站在一个较高的角度去看问题，可能就不会再看到一地鸡毛蒜皮了。

　　接纳计划外的任务

　　任何人都不希望做一些计划外的任务，一般情况下有紧急任务出现都是比较影响业务的。要试着站在对方的角度，以同理心的角度去换位思考。

　　与其焦躁不安，怨天尤人，倒不如主动去接纳这些意料之外的任务，也许事情就会变得更简单。

　　相信没有解决不了的事

　　要相信每个人都是解决问题的专家，当困难和挑战来临时，迎难而上，终会柳暗花明。不管是通过流程还是工具或者适当的外援，终逃脱不了“一物降一物”的法则。

　　应对策略

　　从时间管理四象限法则中可以看到，紧急任务不外乎有两种类型，一种是紧急且重要的事，另一种是紧急但不重要的事，不同的紧急任务处理方式是不一样的，但总体的处理方式是要事第一。

　　对于紧急且重要的事情需要高度关注，优先解决，对于紧急不重要的事情则可以根据情况授权别人做。

　　评估一件事情的重要程度是按照职业价值观来判断的，紧急程度是按照时间底限来确定的。

　　比如你可以根据项目实际情况来定义必须在XX时间内完成的任务为紧急任务，在这之外的为非紧急任务。

　　重要性呢可以针对当前的事务和我们已经设定的目标是否相吻合，吻合度越高就代表越重要，而吻合度如何确定则靠自己的个人价值观以及经验值来确定。

　　对于一个测试负责人来说，一方面需要很清楚的明确紧急和重要的边界，另一方面需要从管理和流程层面全面的来预防和应对紧急任务，建立适合自己项目组的测试策略。

　　以管理促发展

　　测试负责人的主要工作就是在不同的阶段把人、事、物等要素综合考虑和运用，使各方资源发挥合力，让有限的资源产生最好的组合效能。

　　如果效能提上去了，就能预留相对较多的时间给到紧急任务的覆盖。提高效能和质量的有很多不同类型的测试策略，本文主要讨论测试分工的策略。

　　1、基于风险预警的测试分工

　　保证每个测试人员手里应该只有80%饱和度的需求，除非特殊情况不排到100%。

　　首先个人精力有限，一直忙碌的话工作效率不高，也不利于个人身心健康和有效地思考。

　　其次，需求测试的不确定因素较多，一般情况下80%的需求可能已经花费了100%的精力和时间；最后20%的时间预警给紧急任务，以保证接到紧急任务有人可以接手。

　　2、基于AB角的测试分工

　　一个功能最好有两个以上的同学熟悉。

　　功能AB角有很多好处，一方面可以相互评审测试用例，另一方面可以降低对人员的依赖性，当熟悉这一模块的同学请假或者离职时，有备份人员可以快速接手介入测试，避免测试空档期。

　　3、基于人员能力层级的测试分工策略

　　在安排测试需求的时候，需要结合测试人员的个人发展计划和意愿以及个人能力有倾向性地去分配对应的模块，保证每个人至少要有一个最擅长的模块，同时又不能只接触这一个模块的内容。

　　项目组人员在提到某个模块的时候自动关联到对应的测试人员，当有紧急重要的任务来临时，会优先这个测试人员来负责，同时在别的模块有紧急但是不重要的任务的时候，可以协助处理。

　　总之在进行需求分工时不能只顾着将需求安排下去，要了解这个需求是做什么的，然后分析最佳人选，既能确保需求的交付质量和效率，又要能让测试同学有提升。

　　以流程促质效

　　无论何时何地，需求只有在保障质量的情况下才能上线，所以，无论任务是否紧急都要尽最大可能去进行测试覆盖，尽大可能去暴露风险。对于紧急任务呢，会受限于资源和时间，所以需要综观全局制定一个合理的流程。

　　1、任务评审

　　紧急任务发起人员组织研发、测试、版本等相关人员进行评审：

　　任务发起人说明此次任务的背景，预期目标；

　　开发人员阐述修改方案，影响范围；

　　测试负责人根据评审的情况可以判断出这个任务是属于紧急重要还是紧急非重要的任务，以例采取合适的测试策；

　　相关模块的测试专家根据评审内容，评估大概的测试要点。

　　2、工作量评估

　　测试负责人或者测试专家根据评审内容来评估任务的测试难度，并且根据以往的测试经验来估算出当前的测试功能点数需要多久时间才能测试完成。

　　拿我们项目组来举例：

　　大概可能涉及到X个场景，涉及Y个测试省份，最后评估出最乐观的测试时长A：X*Y*0.5天，最悲观的测试时长为X*Y*1.5天；最可能时长为:X*Y*0.8; 所以按照三点估算法最可能测试时长为(X*Y*0.87)/50 (天)。

　　对于一些特别简单的或者比较特殊的情况，可以根据实际情况来进行调整。

　　3、工作分工

　　测试负责人要根据目前测试人员剩余资源情况来进行分工。

　　首先要了解当前大家手上的需求和进度，评估当前可额外支撑的任务数，按照测试任务的轻重缓急，尽最大努力完成测试任务。

　　在时间不足的情况下，我们应该对测试任务按照优先级来划分，重要紧急的任务先完成，且对于每个任务，优先测试主要功能，次要功能优先级放低，优先测试的功能需要与产品开发确认。

　　紧急重要和紧急非重要任务可以采取8:2时间投入，具体可以参考下面的测试策略。

　　（1）80%投入紧急重要的任务

　　如果是紧急重要的任务，从目前可以额外支撑的任务的测试人员里面选择对该模块相对最熟悉的人员来测试。

　　前面我们讲到一个模块都有AB角，所以至少会有两个人对这个任务比较熟悉，原则上如果管理得当的话，是可以抽出一个人来进行此类紧急重要的任务来进行测试，如果由于特殊情况没有一人可以分身，则可以考虑把熟悉该模块的人手中的相对不重要且不紧急的任务分给其他人员来帮忙，从而腾出时间来进行紧急任务的测试。

　　或者由较熟悉的同学带着不熟悉的同学测，关键的地方把控下即可。

　　（2）20%时间投入紧急非重要的任务

　　对于紧急非重要的任务，则分两种情况：

　　如果测试资源足够，则按照正常的分工进行即可。

　　如果测试资源不足，则可以根据测试任务的简单复杂程度来区分，测试人员评估后场景较简单，且开发自测和测试人员验收场景基本上无区别外，则可以考虑直接开发自测而无需再流转到测试人员。

　　如果评估后仍然需要有测试人员跟进，则可以考虑增加外援，比如自动化测试人员、需求方、用户，或者是通过版本灰度方式等来进行。

　　（3）巧用工具

　　如果公司完备的CI/CD流程，有较完善的敏捷开发流程，那基本上处理紧急任务就非常的轻松了，通过自动化测试加上版本的灰度等功能可以实现在风险最低的情况下来保障质量。

　　当然大多数公司的CI/CD还未达到理想的情况，但是一般都会具备最核心功能的自动化测试，这个时候，如果紧急任务涉及的面较广，则可以采用自动化+手工的方式来联合进行测试。

　　另外，还可以采用灰度发版的方式，一部分用户直接在线上进行试用和验收，无问题后直接拉齐全部用户。

　　4、如有困难，及时向上反馈

　　如果在这个过程中有任务的困难自己无法推动解决，请一定及时的向上反馈。

　　总结

　　确定紧急和重要的边界，对紧急重要的任务优先关注，对紧急非重要的任务可以申请援助，投入度可参照8:2。

　　测试负责人要从管理和流程方面制定合适的测试策略来应对紧急测试流程。

　　测试任务紧急来不及写用例的情况下，一定要列测试点并进行review，避免无序测试、思路混乱、丢三落四。

　　如果只有一个测试环境，则需要确认当前的紧急任务部署会不会影响到正常排期的任务，如果影响的任务较多，则建议走灰度进行测试。

　　紧急任务上线前回归测试建议采用自动化，如果任务过程中有突发情况第一时间抛出问题。

作者：余冬菊   

来源：http://www.51testing.com/html/21/n-5002321.html