作为一枚小小test leader，评估测试工作量和功能拆分为小测试点是必备技能。小小的总结一下。
在实际项目中，拿到一个需求，首先就会拆分成小的story，再根据经验估计工作量。你以为这样就完事了??首先就会有一个问题，经验准确与否？经验的参考值从何而来？该方法其实主要是在同类项目中类比得到可参考的数据，或者项目本身的复杂度不高，经验估算出来的值偏差就不会很大。
也有的说根据功能点以及功能点涉及到的逻辑估算大概需要的测试时间。这个是估算的比较准确的方法。但是需要对功能点的拆分比较熟练准确和对需求的理解深入无误。
根据以上的方法，得出三个最可能，最乐观和最悲观的值，粗鲁就计算出了测试执行时间。再加上需求澄清、项目相关会议、测试回归和bug验证、其余临时的任务这几个时间，得出测试的总时间。
在之前的项目中，我经常使用的是计算总的工作量，比如拆分成几块story之后总的测试时间评估为40天，然而我有三个人测试，平均即为12人天。但是这种方法是非常有风险的。因为这样的人天数是被平均算出来的，但如果我实际需要的测试时间大于12天就会导致我测不完。正确的做法应该是计算个人人天数。另外为了更精确，应该拆分成阶段来计算。比如设计阶段，执行阶段。按照阶段来做评估和跟踪。
跟时间评估准确度相关的一点是功能点拆分成测试点细细的评估，跟上面的粗评就不是一个级别的了。根据工作分解结构（WBS）的方法：目标→任务→工作→活动
第一：将需求功能点分解出来，可以分成大类或者大模块，在大类下面再分子模块或者子功能点。
第二：针对每一个功能点和子模块，从不同的维度去分析分解场景：UI,交互，业务逻辑，异常，数据检查，性能，安全等等。
第三：每一个功能点基于每一个维度的场景去分解成测试点。
此时再去估算每一个测试点的工作量之后算出总和，或者如果测试点的复杂度都相当，则直接估算一个测试点的工作量，乘于测试点的个数就得出总的工作量了。