以下为我的一些思考，不全面，后续会逐渐完善；
测试工作量取决于
1、系统复杂度
当复杂度越高，测试工作量越大；
2、系统开发质量
当系统质量越不好，测试工作量越大，而且影响非常大且容易被忽略，前期也不容易被评估出来；
3、研发修复bug质量
当研发修复bug质量越不好，测试工作量越大；
一、复杂度取决于
1、数据入口
1）当存在两个端同时采集，如PC和移动端均采集数据，需考虑数据同步，包括前后端规则一致，校验一致
规则一致：如某个系统要求移动端与PC端规则一致；如果规则很多，移动端未完全遵守，此时测试起来bug多，与需求人员沟通多，导致测试时间增加；
校验一致：如必填，长度，特殊字符等两端校验需要一致；此问题比较细节，但如果采集需要的字段多，而设计未完全遵守两端一致，测试比较细致的时候，非常容易产生bug，导致测试时间增加；
2）数据入口个数
软件的本质是数据，如果数据入口个数多，则容易产生bug，反之则不会有大问题；
数据入口主要包括新增、导入、功能操作后生成数据等；
2、业务规则/计算复杂度
业务规则复杂：主要影响在理解方面，可能影响的时间包括：编制测试用例、与需求/开发讨论的时间等；
计算复杂：同业务规则复杂情况；
3、操作复杂
操作复杂指理解不困难但是操作麻烦的功能，如新增页面必填字段多，或流程繁琐必须一步一步走等；
这样每测试一个功能点或复测一个bug，时间可能会成倍延长；
4、功能个数
功能个数越多，测试工作量越大；
二、当系统开发质量不好时，现象与影响：
1）bug数量多；测试时间和回归时间明显变长；
2）bug阻塞情况明显；即bug被修复后，相关功能或数据的bug才能随之暴露，导致回归bug时间明显被延长，极端情况可能导致回归测试为原来的3倍时间（举例如回归时间预期2天，那么可能被延长到3/4/6天，即1.5倍/2倍/3倍）；
3）不复现问题多；复现以及寻找必现路径需要花费大量时间，且不复现问题过多，容易引发对系统质量的不放心；
三、当研发修复bug不好时，现象与影响：
4）bug激活多；如导致本来需要回归1轮，变为需要回归2轮，回归时间变长；
5）bug修复时引发其他问题；导致系统质量不稳定，bug修复时影响相关模块，此时会导致之前好用的功能突然不好用，之前关闭的bug被激活，更恐怖的是影响到完全不相干的功能，尤其是引发系统流程、基本功能等致命问题；
6）bug修复关闭后又被激活；bug关闭后一般不会再进行回归，此种情况一般是无意间发现，容易影响对系统质量的信心；
7）bug修复时间慢；影响回归测试进度；