这两年我们一直在探索和推动一些提升整体交付效率的事情，比方说测试左移做到深入了解需求，参与技术方案设计评审，进行接口测试，进行code diff精准评估测试范围；测试右移关注线上问题、进行需求上线后的效果分析。合理进行测试任务拆解和排期也是整体交付周期中至关重要的环节。大家都知道影响测试排期的长短的因素大概有以下几个方面：测试同学的效率、业务的复杂度、提测质量、开发同学修复bug的速度等等。今天跟大家分享一下，在整个项目过程中如何合理地做出测试任务拆解与排期（常规需求，排除倒排期项目）。 在进行测试排期过程中，明确一个标准“测试时间为开发时间不大于 1/2”进行合理排期；举个例子：“RD总耗时”+“FE总耗时”为100h时，在QA进行排期时“QA总耗时” 要小于等于50h。这是一个目标，如果比50h少，就更好了；当然质量仍然是第一位的，不能一味地追求人效比而忽略了质量。 在此，我们需要强调的是，一定要有一份统一的耗时计算规则，例如以下各个角色耗时统计规则：（1） 进行需求分析，明确需求中的改动点，确定功能模块，整理疑问点，在测试方案设计之前把需求中的疑问点清零，以及评估风险点（特别是依赖外部门或者第三方公司合作）。（2） 进行技术方案评审，了解需求点的实现，小项目没有技术方案评审时，需要跟开发沟通了解需求点的实现，主要包括但是不限于涉及的工程、外部依赖、前后端接口以及字段、技术实现的手段。 测试任务拆解排期需要基于测试方案、耗时颗粒度等多种因素进行考虑。（1）测试任务拆解和排期要基于测试方案，这里主要考虑是否需要不同的测试方案：接口测试、兼容性测试、集测、性能测试等，做到尽量减少重复的验证点并且尽量把核心场景覆盖全面。- 接口测试：需要考虑哪些功能点以接口测试的形式覆盖；
- 集中测试：需要考虑哪些功能点需要组织各业务进行集中测试，避免功能点遗漏；
- 沙箱环境测试：需要考虑哪些功能点必须要在沙箱验证，有些功能点已经在线下测试通过了是不是就不需要在沙箱环境重复测试了。
（2）耗时颗粒度，细到小时维度，颗粒度越小，纠错或者是补救的成本越低，排期时间也更准确；- 测试数据准备成本，如果在排期前可以考虑到，需要把测试数据准备的耗时，考虑进去；
- 测试方式学习成本，例如：如果本次需要进行性能测试，没有进行过性能测试，需要把学习成本考虑进去。
（2）记录偏差，待项目结束后进行复盘，让以后自己的排期更精准；（3）如遇到风险，及时将风险抛出，如果有补救措施可以进行补救，没有补救措施，进行风险周知。 结合任务执行过程中，实际与计划之间的偏差进行分析归类，看在后续项目中如何规避，并形成结论便于日后进一步复盘改进效果。测试方案的偏差导致测试任务执行时整体都有变化，主要体现在以下几个方面：（1）接口测试无法使用apitest平台编写断言，编写sql语句占据了接口测试的大部分时间；（2）接口测试返回字段比较多，在前两天进行接口测试时，人工一一比对接口返回与SQL执行结果，比较耗时，通过结合功能测试来把控；（3）由于整体是在沙箱环境测试，所以沙箱环境拆解的任务就去掉了；（4）“企业微信通知”任务未执行，因为在测试目标管理时直接测试了，没有单独去测试“企业微信通知”；（5）“不同角色展示”任务未执行，因为通过接口返回即可把控展示内容，不需要通过功能测试再去测试一遍。（1）任务拆解排期前，需要简单实践测试方案可行性；（2）任务拆解时，针对运营类需求 - 查询相关功能，接口测试投入比例要相对减少；可以结合功能测试来进行；（4）任务拆解时，功能相对独立，可以单独拆解成任务；包含流程时，将测试的场景流程拆解成任务； 做好任务拆解不仅有利于我们精准输出测试排期，更是提升整体交付效率的重要一环。测试耗时并不是越长越好，也不是越短越好，同时兼顾测试耗时和测试质量做适合的测试投入才是我们最终的目的。怎么兼顾测试耗时和测试质量 ，就需要大家多多积累不同测试类型的测试方案和测试经验。想了解更多转转公司的技术实践，点击关注下方的公众号吧！