你的方案逻辑自洽吗？

国庆前最后一个周末，和 Thoughtworks 资深质量专家刘冉老师、itest 测试平台创始人老牛老师，以及星球的两位合伙人 CC、CKL 一起做了一期直播分享，聊了关于业内前沿质量大会能为测试带来什么相关的话题。期间聊到一个 topic 时 CC 问我什么是逻辑自洽，由于时间关系当时简单的举了一个例子描述了下。会后我想了想，逻辑自洽其实在工作中，特别是对于软件测试这种技术性要求比较强的岗位来说，其实是很重要的一个特质。

这篇文章，我想聊聊我对逻辑自洽这个词的理解，以及它对我们工作的影响。

如何理解逻辑自洽？

逻辑自洽，原指语言学上的一个原则，即一个理论在语言本身的描述上是不矛盾的，通过分析思辨发现没有任何矛盾，达到自我完备。逻辑自洽有如下 3 个特征：

1. 可以首尾呼应；

2. 可以说服自己；

3. 可以说服别人；

简单来说就是你的描述是可以通过分析思辨实践来证明的。举个例子：

大家对高中时的数学考试应该都还有印象，数学试卷的大题基本都是证明题，即给出一定条件和描述，让你证明某个结论正确与否或者求得一个正确的结论。这就是一个很典型的逻辑自洽案例。

逻辑自洽对工作的影响

对测试同学来说，大家工作中应该都需要进行需求评审、方案评审和用例评审。逻辑自洽在其中发挥了重要的作用。

需求评审时，我们需要通过 prd 以及产品的描述，来判断需求是否存在漏洞，各种交互跳转是否符合逻辑和用户操作习惯。

方案评审时，我们需要评估方案实现方式的可行性，难易程度，是否存在遗漏和不足之处。

用例评审时，开发同学也会针对我们编写的用例进行分析思考，判断用例的步骤和验证目标是否和技术实现一致。

当然还有个典型的例子，就是提 bug 记录 bug。我们在记录 bug 时需要说明对应的模块场景，做了什么操作，输入数据以及结果是什么，和预期结果的差别是什么。

这些场景，其实内在都具有完备自洽的逻辑。

你的测试方案逻辑自洽吗？

对测试同学来说，工作中遇到一些独立项目，一般是需要写测试方案的。这里我会以一个测试方案的 demo 来举例说明，如何写一个逻辑自洽的测试方案。

一般来说一个完整的测试方案需要包含如下几点要素：

项目背景：说明这个项目的背景（阐述来龙去脉，为什么做这个项目）；

项目目的：说明这个项目要解决什么问题（背景是原因，目的是要解决的问题）；

项目范围：说明这个项目涉及的范围（明确具体的范围边界，一般从业务和技术 2 个角度划分边界）；

项目指标：说明这个项目不同阶段要达成的目标（明确项目指标，这里可以将每个阶段完成和交付的指标都明确）；

测试策略：针对本项目进行分析后，从哪些角度来进行测试验证；

阶段进度：说明整个测试阶段要做的工作，由谁负责谁配合，当前的进度，预期完成时间等；

风险分析：罗列本项目执行过程中可能存在的风险以及应对方案；

交付清单：说明本项目测试各阶段的交付物和验收标准；

术语约定：针对项目中一些容易引起歧义的术语进行说明和约定；

总结：测试方案逻辑自洽，即说明在什么背景下遇到什么问题，需要什么人在什么时间通过什么动作解决什么问题。其中每个环节都需要具备可行性，且整个链路从头至尾都要有关系依赖和约束。