编写BUG报告有诀窍？Toulmin模型来帮忙

前不久，桓哥的分享PPT中提到了Toulmin论证模型，并在其中提到了这么一句话“尝试建议：用Toulmin模型指导编写BUG报告（特别是容易被忽略限定部分，即BUG隔离）”。

恰逢我在整理合作方离岸方案中，涉及到统一BUG提交模板，来规范各合作方的BUG输出，并且减少其在不同项目间切换时提交BUG的学习成本。

于是想着能否将Toulmin论证模型应用到BUG编写报告中，其作用主要包括：

1、强调限定部分、及其准确性

2、通过加强限定部分，简短bug描述步骤

首先，我先调研了下目前BUG报告的现状，看看合作方（其实不仅限于合作方）提交的BUG是否有二义性、前提条件限定不完整等情况。

举几个栗子

【例子1】BUG复现步骤过长、存在多余的操作步骤；

看完这个BUG，我相信大家跟我一样，都存在这样的疑惑“前两个步骤是多余的吗？是不是后两个步骤就可以复现BUG了呢？”

【例子2】BUG描述不够全面、准确，不同的现象决定了BUG的严重程度和修改优先级；

“是否只有微信推送位置发起导航才会crash，还是所有导航都会crash？”不同的现象BUG严重程度不同、BUG修复的优先级也不同。

【例子3】BUG描述不完整，不方便开发快速定位问题

“灰屏是否只是一瞬间的现象，即灰屏后是否屏幕能正常点亮，如果是，那么只是过程页面没有控制，开发可以快速定位”、“还是一直灰屏，无法启动，这就需要开发进一步深入排查了”针对这两个问题，前者若项目紧张可以暂时延期解决，而后者则是必须要优先修改的严重BUG。

相信分析这些BUG的每一个人，跟我一样感同身受，这些BUG输出，从步骤、前提条件、结论等方面都存在一些问题，需要改进，以便辅助开发快速复现、定位问题、减少不必要的沟通成本，尤其是在合作方离岸后。

通过上述的分析，我们可以确定“强调BUG的限定部分、缩短BUG的复现步骤”是必要的，因此接下来将调研Toulmin论证模型的含义：

苏格拉底曾说道“假如我们对东西的大小有分歧，我们可以通过测量，很快停止分歧”，“假如我们要想决定哪个重、哪个轻，我可以通过称重来解决”。但是对于那些“使我们意见不合”、“使我们无法达成一致意见”同时又无方法“衡量”的事物，我们又该通过怎样的方式取得满意的仲裁？逻辑学就是为了满足当时思想争论的需要而产生。

当分析和评估公民在日常生活中遇到的各种论证和推理时，逻辑作为工具该如何发挥其有效的作用？英国哲学家Toulmin通过类比法学模型，构造了一种由六个要素构成的模型，以期寻找与人的决策相适应的、工作的逻辑，后来的学者称之为“Toulmin模型”。Toulmin的论证模型具有六个要素，分别是主张claim、予料data、保证warrant、支援backing、限定词qualifier和反驳rebuttal等。其中，前三个元素属于基本要素，在每个论证中都会出现，构成论证的基本架构。剩下的要素并不要求在所有论证中都出现，因此称为补充要素。论证的基本架构和补充要素一起构成论证的扩展模式或完整模式。

接下来就六个元素分别进行简单的介绍：

1、主张claim

• Toulmin在《论证的使用》中这样描述：假定我们做出一个断定，我们应当保证该断定必然包含某种主张。如果这个主张受到挑战，我们必须能使之成立，即使该主张是一个好的或者合理的。
• 主张的一个特点是具有可争议性，因为其总是会受到挑战，而主张提出者必须在主张受到挑战时为其进行辩护。

2、予料data

• 假设我们提出的主张受到了挑战，我们必须能够确定它、展示其是无可非议的，为回答这个问题所提供的事实就是予料。
• 例如我们提出“白云不是红色的”是基于“事实上白云是白色的”。
• 根据例子可知，予料是当主张遇到挑战时我们所依据的事实，予料是这样一种东西，它们不再需要进一步的理由，它们是我们关于世界的知识不可或缺、最低限度的前提。
• 学者们对于予料的争议更多的是集中在术语的翻译上，武宏志在论文《论证的图尔敏模式——兼评国内若干论著的误释》中，依据Toulmin原著的解释，对目前学界存在的一些翻译提出了不同的看法，认为很多都存在问题，例如有些学者将data译为“数据”，则出现外延过窄的问题，因为很多的前提都不是数据。也有学者将data译为“语料”，武宏志认为这种译法不够贴切，因为“语料”是一个语言学概念。他指出切合原意的译名应是“资料”或“予料”（有些学者认为这个翻译学术味略浓）。因为data在拉丁文中是datum，是一种复数形式，该词原本的涵义是所有进行研究或者推理时最初依据的信息或者材料。data可以来源于历史事件或当代事实、统计汇编或经典文献，也可以作为一个保证主张观点确立的由一般陈述句构成的证据，例如证人证言或其他“事实”。因此本文采取武宏志的翻译，将data译为“予料”。

3、保证warrant

• 即使给出了予料，我们可能发现依旧会被进一步追问另一类问题“你如何从前提到达结论？”假设我们遭遇这个新颖的挑战，所应做的不是必须给出更多的予料，因为相同的质疑会马上被提出来，而是“应该给出不同的命题：规则，规律，推理允许或者你会用来代替增加的信息的术语”。这里Toulmin所提到的命题在Toulmin模型中被称为“保证warrant”。
• 例如，我们提出一个主张“Harry是英国人。”针对这个主张，对方可能提出质疑：“你凭什么这么说呢？”为了消除质疑，我们给出“Harry出生在百慕达群岛”这一事实，即予料。但是只补充这样一个事实无法说明主张和这一予料之间的关系，因此对方继续问到“为什么你会得到这样的结论呢？”，然后我们进一步给出“因为在百慕达群岛出生的人，就是英国人。”依据这个例子可知，保证为所给出的予料能够成为主张的根据提供担保。
• 另外，在一个论证中，予料是不可或缺的，如果缺少予料，那么将不能称之为论证。而如果没有对主张和予料之间的关系提出质疑，保证则无须明示，不用出现在论证中。

4、支援backing

• 支援是对保证支援性的陈述。
• 如果继续上述Toulmin提到的例子，反对者可以在我们给出保证后，对保证本身产生质疑“为何在百慕达群岛出生的人就是英国人？”针对这一质疑，我们需要做的是提出一个支援保证的、力度更强的命题：“因为在英国的制定法中，就殖民地出生者的国籍有明文规定。”这种强化保证权威性的支援性陈述即支援。
• Toulmin指出，模型中的支援是专门用于支持保证的。支援既可以是一个单一的事实，也可以是一个由主张和予料组成的完整的论证。

5、限定词qualifier

• 在某些论证中，根据提供的予料，保证可以担保从予料“必然地”得出主张，即毫无疑问地接受。而在另一些论证中，保证却只能担保从予料对主张的支持是需要条件的，或者是存在例外情况的，又或者是有所限定。因此，就需要通过一些模态词，如“大概”、“可能”等来修正主张，从而达到使人信服的目的。因此，仅仅是简单的明确论证对予料、保证和主张是不充分的，可能还需要给我们通过保证授予从予料跳跃至主张一些明确的参考。简言之，我们需要在论证模型中放入限定词。
• 在Toulmin论证模型中，主张、予料和保证是论证的基本要素，而限定词则属于补充要素，并非在每一个论证中都必然地出现。

6、反驳rebuttal

• 在Toulmin论证模型中设置限定词这一元素，可以在即使无法由给定的予料再加上保证的担保获得主张的情况下，通过对主张的修正或限定，依旧可以达到让人信服的论证目的。但是，随着反驳元素的引入，无法再实现从予料，经由保证这一“桥梁”跳跃至主张。这种具有“阻碍”性质、能够使上述从予料到主张的步骤变得不合法从而必须被舍弃的陈述，被称为例外情况或者反驳。
• 反驳说明，保证所展示的权威不具有普遍合法性，存在着应当被弃置一旁的可能。

举个栗子

以主张“明天晚上我们的队伍会赢”为例，应用到Toulmin模型中的基本要素（予料、保证、主张）如下：

再继续应用到Toulmin模型的补充要素（支援、反驳、限定词）如下：

了解完Toulmin论证模型，最后，我们尝试在BUG报告中引入该模型，以如下BUG为例：

根据Toulmin模型分析如下：

• 主张：本BUG强调的内容，即“导航出现crash”
• 予料：个人理解可以将需求、原有功能作为予料，即产品支持微信推送位置、发起导航、导航发起支持2种位置来源：底图抓取位置、微信推送位置
• 保证：测试的环境、配置等，即测试环境、测试版本等信息
• 支援：支持保证的，即验证测试环境，如通过LOG抓取、抓包等方式
• 反驳：是回答“是不是所有发起导航的情况下都会crash？”即不是所有发起导航的情况都会crash
• 限定：对反驳的回答是否，就有了限定，即仅限微信推送的位置发起的导航

因此而得到的模型如下图：

根据以上模型的分析，我们可以得出：仅限微信推送的位置，发起导航，才会出现crash，因此我们可以补充我们的bug复现前提：“在xx测试环境、xx测试版本上，导航后台服务正常的前提下，仅限微信推送的位置（不包括底图抓取的位置）发起的导航，才会出现crash。

参考桓哥的PPT资料，并且跟桓哥探讨后，汇总了Toulmin论证模型和BUG报告各字段之间的关联关系，如下图：

此外，在Toulmin论证模型应用到BUG分析过程中还应该注意：

• 除了主张，每个元素都可能出现多个——所以在分析过程中，要尽量挖掘完备条件；
• 对于BUG定位，反复找反驳能帮助找到最小复现条件——多次反驳、不断缩小复现步骤；
• 予料是触发手段，直接原因；
• BUG报告中不能简单的写予料和主张，没有环境配置、版本和反驳，尤其是不必现的问题；
• 利用Toulmin论证模型进行思考，不断的寻找反驳，是有助于找到BUG的必现条件；
• 好的BUG报告应该符合这样的逻辑结构，尤其是保证、和限定部分；

由此而输出的清晰的bug描述，不仅可以帮助开发快速定位问题，还可以因此减少开发要求测试不断复现的时间成本和沟通成本，一举两得。

PS：除非有明显的逻辑错误，否则这种类型的分析一般没有绝对的对错之分，纯属探讨，欢迎大家拍砖~~

附上参考资料：http://xueshu.baidu.com/s?wd=paperuri%3A%28d200e1cd2387092d8689d6e1cc03937c%29&filter=sc_long_sign&tn=SE_xueshusource_2kduw22v&sc_vurl=http%3A%2F%2Fwww.docin.com%2Fp-1096032823.html&ie=utf-8&sc_us=17461898992983330318