以下为我的一些思考,不全面,后续会逐渐完善;
测试工作量取决于
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修复时间慢;影响回归测试进度;