测试时间压缩有感

在测试过程中，对于测试进度的反馈，我们会说测完了，然后准备上线。如果测完了，还遗留了问题，我们会根据遗留问题评估是否能够上线。

但有时候测完了，也没有什么遗留问题（比如一些倒排的项目），但是感觉测的不是很充分，该怎么评估呢。

最近遇到测试时间压缩，需要赶一赶工。然后通常会记一个风险：测试时间压缩。除了记个这样的风险，我还很想告诉大家哪里不充分，牺牲的这部分质量大家能不能接受，但是我又很难进行量化和描述。

说到测试不充分，但测试活动什么时候真正充分过了呢。穷尽的测试是做不到的，谁都无法保证测试过后就没有bug，项目也不会等到没有bug才上线。项目管理里面有个成本-质量-时间三角：一味的追求质量会使成本和时间增加；不追加资源或者牺牲质量，就无法压缩时间。关键是平衡点是什么，怎么取舍。
不同业务特性、复杂度和风险的不同，对质量的要求可能不同，比如造波音、做基站对质量的要求就要比一般软件系统高。测试在评估测试是否充分指的是达到了当前软件要求的质量。业务的质量要求是怎样的，这里可能是有缺失的。

开发、产品经常会觉得：这个是测试测过的。为啥会有问题。可能他们认为的质量目标是90分，但是测试完成时达到的质量水平只有70分。测试策略是有弹性的，一个项目有3天的测法也有3周的测法。一个测试同学A测一个项目只测主要功能可能要3天可能质量水平70分，另一个同学测得全面一点要5天可以质量水平80分。哪一种更合适？多花的2天有木有价值？说清楚这个是不是就容易争取测试时间以及评估出时间压缩的风险，因为在互联网公司迭代比较快，项目排期普遍紧张，时间问题是比较敏感的。

最后，是不是大家都清楚什么是充分的测试，并能够评估出目前测试状态和预期质量目标差距是什么，并计入风险。如果相关方认可当前测试水平以及接受这样的风险，就算线上出现此类问题，也应该理解为质量把控符合预期。现在很多时候为了进度加班加点牺牲了质量，最后看到线上问题很多觉得测试工作做的不好，有种多做多错的悲凉。

原文地址：https://www.cnblogs.com/opama/p/11218990.html