用来投标的软件性能测试报告, 整改之后的复测该怎么计算? 这可不单单只是预算方面的问题, 它更是项目交付过程中的关键节点。结论是非常明确的: 复测所需的费用可不是简单地进行打折处理, 而是要依据“回归范围”以及“责任归属”来重新进行核定的。大多数的招标方默认在初测不合格之后的复测费用是由供应商来承担成本的, 但是如果涉及到需求出现变更或者是第三方环境因素的话, 那么就可以主张额外进行计费了。
回归测试范围决定工作量基数
项目刚开始的时候, 常常会碰到“一次通过率”这个陷阱。要是因为代码存在缺陷, 使得性能指标没有达到标准, 在进入整改阶段以后,再次测试必须涵盖所有受到影响的模块以及相关联的接口, 而不是仅仅针对报错的地方。这种全面的回归就意味着测试用例执行的数量可能会达到初次测试的80%以上。在这个时候, 再次测试应该按照正式项目的比例来计费, 一般情况下不会低于初次测试费用的60%-70%。与之相反, 要是仅仅修复单个并非核心的Bug, 并且不会对整体架构造成影响, 那么双方能够进行协商, 按照人天单价来结算零星的测试工时, 在这种情形之下, 费用是极其低的, 甚至有可能由服务商免费赠送, 以此来维护客户关系。
责任界定影响报价策略核心
定价的前提是要弄清楚“谁的问题”, 要是性能瓶颈是因为架构设计存在缺陷或者服务器资源不够充足, 这属于乙方的技术责任, 进行整改复测应当被当作履行约定的补救措施, 原则上是免费的, 可是, 如果甲方在中途调整了并发用户数的预期、增添了新的功能模块或者更改了数据库配置, 从而使得原来的测试基线失去效力, 那么这就属于需求变更, 在此种情形下, 复测需要按照新增的工作量重新给出报价, 这里面涵盖环境搭建、数据构造以及执行成本。在投标这个阶段的时候, 一定要在合同里清晰明确地写明那“变更触发复测收费”的条款, 以此来防止在后期出现扯皮的情况。
实操建议：建立分级响应机制
针对复测需求, 提议采用标准化应对流程。先是出具差异分析报告, 对整改前后的指标变化以及影响范围予以量化；接着明确归责, 将技术债与需求变更区分开来；随后依据这些提交复测报价单。对于长期合作客户, 能够提供“限额内免费复测”的服务包致使成为投标加分项, 既实现风险控制又增强竞争力。要记住, 清晰的边界划分相较于低价承诺更能够获取甲方信任, 保障项目在合规的状况下顺利验收。
