提高测试可靠性是为了让我们的测试值得信任。
以前都在讲软件的健壮性、可靠性，好像都在对开发质量提出要求。今天，为了证明自己的工作是值得信任的，提高测试的可靠性势在必行。
提高测试的可靠性，传统做法有哪些呢？测试用例评审、交叉测试、测试复盘总结、线上问题跟踪学习，此外就是绩效考核的手段。以往任职的公司，基本都是通过这些方式确保测试尽量不漏测，好像方法也不少哈，但也是一样免不了有漏测的问题。
代码有编码规范，那测试有没有用例编写规范呢和执行规范呢？就我多年的经验，除了格式上的要求，就是笼统地规定必须100%覆盖到所有功能点。
那请问怎样才能做到100%覆盖所有功能点呢？这是每一个测试都希望达到的极致目标啊。
如果没有清晰的思路，在编写用例的时候容易乱，乱就容易漏。那怎样才能确保自己的测试用例是最可靠的呢？在以往编写测试用例时，我一般都是按照UI-》功能点-》流程（-》性能-》安全，如果有要求的话）这样的顺序进行的。具体到编写某一个大分类的方案时，我会先把测试点一个个先罗列出来，检查有无遗漏。然后再补上操作步骤、测试数据和期望结果等内容。这样做的好处，首先从繁琐的操作步骤中抽离出来，从大局的角度去思考会更全面。其次，不管后来的执行步骤和测试数据是否有重复，你只需要聚焦到你的测试点和期望的输出数据能够对应上就可以。
再到执行的时候呢，需要记录每一条用例每一次的执行结果，确保每条用例不被遗漏。此外，需要根据自己的行业知识和对这个产品的理解，做一些用例之外的测试，这个比较依赖执行人员的经验和责任心。有时就是这样，用例编写和用例评审的时候没有想到的思路，在执行测试的时候就迸发出火花了，可能是对产品有了更深的理解，也可能就是灵光一现，也有可能大家都考虑不全面。