从某种程度上讲，测试用例的设计是有边界的，这个边界不是测试用例数量的限制，而是人的思维模式达到边界。当测试用例几乎达到上限的时候，又如何进一步保证产品质量呢？
其实，有时候100个测试用例和200个测试用例相比，不一定能直接证明200个测试用例执行后产品的质量就一定要好于100个测试（因为200个测试用例有可能忽略了某定特点的场景）。另外，有些Bug是设计缺陷，并且只有在性能测试时或者特定的情况下才能发现。而这些问题在项目的后期发现基本是无解或者只能选择work around来牵强的修复。所以测试用例并不是一劳永逸的，而更多的设计缺陷需要在更早期被发现。而这些隐藏的风险很多情况下只有开发自己心里清楚，如果他选择隐瞒将来就可能是个大雷。而测试的质量保障大部分都是在产品的开发中后期。就像比萨斜塔，在一栋建筑快结束的时候发现他是斜的，后期是很难修复的。
既然测试用例已经快接近极限的时候，那就只能通过其他的方式来改进。很多同学提到了需求规范、文档规范、流程规范以及必须有测试计划、测试策略等。我个人觉得这些确实在流程上帮助了产品的质量，但是在“提高“二字上并没有发挥出更大的作用。而在质量进一步提高的措施我个人认为在于：评审（Review）。在项目的各个关键节点上加入评审，能够在软件开发流程的整体上降低风险，比如：需求评审、整体架构评审、代码评审甚至是测试用例评审。俗话说三个臭皮匠顶一个诸葛亮，众人拾柴火焰高也就是这个道理。以下是我根据多年的经验总结的软件开发测试流程体系，在每个关键的节点上都加上了评审，避免思维的局限性。在实际的项目运营中也取得了非常好的效果，特别是代码设计和架构的评审，在设计初期就能杜绝一些潜在的风险。
原文链接：https://blog.csdn.net/paischool/article/details/90259923