作为一个测试人员，报告相关人员影响系统的功能和威胁系统性能的问题是我们工作中的任务。
可能你常会遇到领导拦着问你：我们测试结果如何，还有故障吗？版本可以发布了吗？
但是如果你作为测试人员不知道系统的边界呢？如果你把测试结果的信心只是建立在应该一小部分测试的内容上，该怎么办？如果你不知道系统/解决方案如何或何时更改了怎么办？如果你缺乏这种控制，你怎么能说你对测试结果有信心呢？
其实这些问题与我们产品的可测性相关。如果我们获取知识的平台不稳定，我们怎么能够确保所学的东西是正确的呢？
举例说明
一个系统由许多子系统组成，解决方案由许多不同的参与者更新，一些人手动执行，一些人通过持续部署执行。
更大的解决方案经常改变，端到端测试人员有时需要花费相当多的时间来执行测试。通常情况下，他们开始一个测试，在此期间解决方案被更新或更改为新的组件或子系统。在测试的结果中很难得到任何确定性。
当你测试一个系统并记录测试结果时，你需要能够以多种引用该系统。
如果系统不断地发生变化，你需要以某种方式知道它什么时候发生了变化，变化是什么以及在哪里发生的。
如果你不知道哪里发生了什么变化，这将使你更难计划你的测试范围，也很难相信测试的结果。
识别系统
识别系统的一种方法是首先识别系统由什么组成，考虑系统的边界和包括什么、是否应该将环境配置作为系统的一部分……
世上没有完美的准则。你只能在一定程度上定义系统。当你定义系统的部分或组件时，你就能获得相应的测试准则（也可以叫“神谕“）。
但是，试想一下，如果没有权威的准则，你怎么测试呢？或者说你怎么指导一个初级测试人员运行测试用例，并告诉他是否通过了呢？本文讨论的核心就是：测试人员的信心来源——权威的测试准则。
测试准则
其实测试准则的问题简单来讲，就是“一致性”问题。期望结果与实际结果是否一致的问题。
我们已经说过：世界上没有完美的准则。权威的测试准则只在局部有效，即只能与我们定义的系统相一致才有效。那么，我们在定义权威的测试准则时，需要考虑哪些方面呢？
用户需求一致性
我们设计的产品要符合用户需求，因此满足用户需求是我们首要考虑的测试准则。模拟用户真实的部署环境、参考用户的行为习惯、模拟用户的数据等制定测试用例，将用户需求与测试结果进行一致性对比，从而判定测试是否通过。
可比产品一致性
在可比产品中，类似的功能行为一致。这通常在对标中经常出现。比如，windows系统我们习惯性使用ctrl+c表示复制，ctrl+v表示粘贴。若是在linux系统中定义ctrl+v表示复制，ctrl+c表示粘贴，则会造成许多习惯性使用冲突。
历史产品一致性
现在的行为与过去的行为一致。可能有的人会对此提出异议：如果我得产品功能发生变更，这一准则是否毫无意义或者起了反作用。在这里，我们说的是，如果相同的功能未发生变化的时候，需要与历史产品保持一致。这经常出现在回归测试中。
形象一致性
这一点很少被提及，或者说很容易被忽略。但对于大公司来说，这一准则又潜在影响着其公司发布的产品。例如，阿里巴巴集团旗下产品设计喜欢用橙黄色，这与其最初产品定调是相一致的。
声明一致性
这里的声明包括：文档、规范或广告等。产品行为需要与声明不一致，否则将会产生矛盾。声明一致性常用于我们的文档测试。
标准或规定一致性
这里的标准或规定指的是基础标准，如数学运算规则、数学运算结果，或国家安全法例条文等规定。我们设计的产品不能违反这些基本标准或规定，例如：如果计算结果2+2=5，我们则能快速判定产品出现了错误。
目的一致性
产品功能与表面表现一致性。例如，某个应用下拉框或输入框我们选择或输入“A”，但产品内部功能并没有接收到或正确传递这一选项，则属于目的一致性。
以上所述，只是制定测试准则的一部分要求或思考。或许，你还有更好的建议呢？欢迎讨论。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
