测试出口的方法论

inoran

因为工作上的某些事情，突然心血来潮在测试出口的制定上写一些自己的见解，望大家能够参与讨论，不断补充各自的经验

测试何时停止，一般的，有如下几种方法来确定
1） 测试因为期限到了而停止，这期限可能是计划中随意定的，也或者是与客户的相关协议写明的。这种停止很显然是令人沮丧的，对质量来说也是冒很大风险的。
2） 经费用完了，这同样很糟糕。但是没钱了，那只能停工。
3）所有的用例都运行过了，通过了，或者通过了预定百分比的测试用例也可能会结束。如果确认已经运行了适当的用力，并且确信那些没有运行用例不是那么重要，那么，结束测试也是不错的选择。但是，请时刻问自己一个问题，“我们运行过的用例足够稳定了么，他们是否包含了所有我们需要测试的功能；剩下的用例是否从来未被执行过，他们到底有多重要” （有些公司的出口准则运用某几种方法的组合，我会在后面介绍）
4） 达到了确定的覆盖率后测试停止，无论这种覆盖率是基于功能的还是基于代码的，这种测量法都不错。但是，还是多问自己一个问题“是否还有可能出现bug的地方没测过”
5） 当bug率和严重性降到某个特定点后，（这种趋势表大家应该都见过吧）测试停止。别把大家放假的那段时间也放进你的图标
6） 达到某种度量，例如软件在一定负载下正常运行3个月不产生问题，测试可以停止。这种度量很好，因为用户的需要已经被翻译成了产品的目标，当产品能够达到这种客观目标时，用户自然就会满意了

举例：
今天跟一个朋友聊到测试出口，他给出了他们公司很好的实例，他们的出口准则结合了方法3和方法5，
即：需求功能全部实现，95%以上的defect全部修复，遗留的5%的defect中没有high的defect， 没有功能上的defect。
当然，每家公司的具体数值可能都不尽相同，那么这些数字又从何而来呢。
这里，我试图运用我自己的经验和理解来阐述这些数字产生的步骤：
1）在需求分析阶段，我们应根据产品功能说明书来理解用户的期望是什么，他们需要一个c/s还是b/s系统，产品的主要目标用户群是什么。基于用户的需求，我们的开发小组才能确定详细的设计方案，包括技术，架构，性能要求。因此一份详细的产品功能说明书是确定那些数字的第一步，决不能是拍脑袋定的。
2） 基于产品功能说明书，测试组能够基于产品功能特性，建立相应的测试矩阵（包括，功能，测试平台，测试优先级/重要级别）来确定矩阵中每个单元格的权重
说到这里，我们已经有了一个比较科学的方法论，再加上具体客户的需求，那么总测试出口和各个功能的测试出口就不难得出了。
PS:来自另一位intel同事的补充，有些企业规定遗留的未解决的轻量级的bug需要得到客户的允许，产品才能release。
如果我表达的不清楚，请各位feel free的提问 -    -