目录
引言
作为一名测试人员，经常会遇到领导的提问：测试结果如何，版本可以发布了吗？此时我们是如何衡量软件是否达到了发布标准，对测试的结果是否有信心呢？
举个栗子：
一个大型系统由多个子系统构成，不同的子系统分配给不同的开发者及测试人员。通常情况下，一个系统的解决方案会影响其他系统，当经过无数次迭代后，系统不断地发生变化，你需要以某种方式得知它什么时候发生了变化，变化是什么以及在哪里发生的，影响的范围有多大。如果你对于这些一无所知，这将使你很难计划你的测试范围，也很难相信测试结果。
试想一下，如果没有制定权威的准则，你怎么知道是否达到了发布标准？还有，你怎么知道一个初级测试人员执行测试用例，并告诉他是否通过了呢？本文讨论的核心就是：测试准则的制定标准。
测试准则
测试准则的问题简单来讲，就是为测试实施寻求一个标准。世界上没有完美的准则，再权威的测试准则也只是在与定义的系统一致时才有效。在定义权威的测试准则时，需要从以下几个方面来考虑。
用户需求
我们设计的产品要满足用户的需求，这是实现要考虑的测试准则，一切以用户为最初的出发点去看待问题。我们在测试时，模拟用户真实的部署环境，参考用户的行为习惯，模拟用户的数据等编写测试用例，将用户需求与测试结果进行一致性对比，以此来判定测试是否满足通过准则。
遗留问题
在实际项目中，由于受到版本周期影响，不是要等到所有bug归零时，才操作版本的部署。遗留的问题在不影响主流程的前提下，可以和开发及产品沟通，择期修复，或者制定其他解决方案。
标准及规定
这里的标准或规定指的是基础标准，如数学预算，国家条例等规定。我们测试的软件需要符合这些基本标准或规定，例如：软件计算结果1+1=3，则判定是产品的错误。
类比产品
同一类产品中，相似的功能点行为一致。例如：windows系统中习惯性使用CTRL+C表示复制，CTRL+V表示粘贴，换到linux系统中，则不是这样，定义的差异性会造成使用的冲突。
历史数据
相同功能未发生变化时，新版本的发布不应影响历史版本的数据，这个问题经常在回归测试时需要考虑到。对于客户端，在测试旧数据的同时，还要加上版本的覆盖安装测试。
UI一致
要遵循整体性UI一致的原则，例如一个公司的产品颜色基调定位蓝色，其下子系统软件颜色基调也都统一为蓝色。
文档一致
文档一致也就是通常说的文档测试，设计的产品要与需求文档、产品合同、规范和广告等描述一致，否则就会产生矛盾。还有一点需要注意：对于某些细节性的处理，也许连设计文档都不曾包括，而是在开发团队与需求人员（或直接客户）的口头、会议交流中确定了某些做法。这些约定，一旦没有知会我们测试团队，那么我们的测试就会走弯路甚至出错。所以作为测试团队，我们应该尽可能要求参与项目调研分析阶段的各项讨论和会议，并且要把这些口头约定的内容用文字记录下来（比如邮件，发给各与会方），从而形成我们的测试依据文档。
300
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
