测试人如何进行工作量评估？
测试策略的选择、测试范围（新功能覆盖面、旧功能影响面，决定测试用例数量）、测试深度、测试广度(专项测试/性能测试/安全测试等）、质量要求(比如是否允许携功能之外的缺陷上线)、用例执行等都会对测试工作量评估产生干扰，因此精确评估工作量难度着实不小
工作量评估：人日、里程碑、提测、冒烟测试、任务拆分
人日
比如项目是一个前端开发、一个后端开发参与开发，他们同时开发，前端开发开发工时2日，后端开发开发工时3日，前后端联调2人日，这样整体开发工作量是3+2+2*2=9人日。（ps：一个工作日一般表示8h）
里程碑
表示项目过程中的重要时间节点，比如提测时间、测试完成时间、发布时间等
冒烟测试
冒烟测试主要是指测试产品的核心功能模块(也可以称为产品功能主流程能否跑通)是否可用。
附：https://www.zhihu.com/zvideo/1324145829833891840
提测
开发的新功能通过冒烟测试，提交给测试进入功能测试阶段。
任务拆分
一个需求通常需要多个开发协作完成，如何将需求中涉及的开发模块分给不同的开发人员，这就需要将需求细化到更小的功能模块。
介绍几种常见的需求类型下应该重点结合哪些因素评估工作量。
新产品需求
新项目几乎是从0到1的做起的，测试同学无法借助于已有的测试沉淀（自动化用例、checklist用例等），所以测试广度、用例执行、环境准备与测试和测试数据准备是重要因素。
产品功能迭代需求
对于已有的产品进行产品迭代时，测试范围（新旧功能）、测试数据准备、测试执行是重要因素，产品迭代项目可以依赖测试沉淀，所以测试范围的评估会决定测试工作量。
技改需求
技改需求一般是开发针对某些性能较差的服务做的优化，这样的需求要保证新的代码改动即不能变动旧功能又不引入新缺陷，所以这块的测试成本更多的是消耗在测试执行上。
项目环境迁移需求
这类项目重点考虑测试范围、环境准备与测试因素，需要确定在新环境上要覆盖的测试点，可以依托已有的测试沉淀进行有效的回测。
测试工作量的评估是一个随着测试经验不断积累来优化的过程，以上只是我根据自己以往的测试经验形成的方法论，当然，不同的项目不同的团队工作量评估的方法可能有比较大的差别，更重要的是在不同的项目中不断的思考总结和积累经验以形成自己的一套方法论。
排期
测试工作量的评估往往服务于项目整体的排期，而在做项目的过程，往往会遇到一下两种排期方式：正排、倒排。
对于正排项目，一般比较轻松，测试就根据评估好的工作量时间走就行；
对于倒排的项目，由于首先确定了发布时间，向前推大家的工作时间，所以往往会压缩各方时间，正常评估出来的测试工作量就无法适用了。但是对于倒排项目的建议是，对测试用例分优先级，重点保障核心功能。
最后我想给大家一些建议，不管项目是正排还是倒排，还是要预留一些buffer以应对出现的“意外”工作内容。