可以以业务流程写

从没听说过用例必须 “闭环” 的。我甚至不知道啥叫用例的闭环。

理论上是针对当前模块进行用例覆盖，然后上下游数据、逻辑正确性有检测
不要求要闭环 ！ 如果一个业务流涉及几十个模块 你负责一个模块去闭环不是扯淡吗

用例闭环就是一个功能完整的测试用例，就是从数据的开始到数据的结束，走完一整个流程。

按你闭环的定义，就是走完一整个流程。

但是从单个功能来说，每个测试用例待测功能之前或者之后流程可能是相似或者一致的，并没有必要每个都闭环走一遍，浪费时间不说，也没有什么意义。

如果你对数据处理的一致性不确定（或者要保证某些流程），可以专门针对数据完整生命周期来做测试。这个功能哪类数据会导致后续流程处理有问题，单独分析和设计对应用例。

无脑闭环，在我看来并不可取，效率低下、成本高、测试质量也可能不符合预期。

主要看数据涉及到的上下游流程中是否按业务逻辑一致

第一次听到说用例要闭环这个概念。

我觉得你们开发想表达的，是缺少联通起来的完整业务流程测试吧？只是用词可能不大准确。

今日用例评审，开发提出问题，我的用例没有形成闭环

不具备专业测试技能者难免会提出些古怪问题。

可以有两种回应。

1. 用专业的知识悉心教导，让其明白自身的不足；
2. 要求提出者打个样，看评审能否通过；

就是 end to end, 端到端测试吗？

如果你只是为了其中的一个环节的改动，而且改动很小，对数据结构不产生变化，那么只需要对你的上下游做个对比测试就可以了，比如修改前后的报文对比；如果是改动比较大，对数据结构有影响，可能就需要做完整的端到端回归测试。

我现在想的跟你差不多，我觉得功能用例没写是因为一开始每个人的模块都划分好了，我们只需要对当前模块进行用例覆盖就行。而且我们也写接口测试用例，不同模块之前的数据流向在接口测试时会测到，所以今天开发提出这个问题，我争论了很久。

是的，首先明显的一点就是用例冗余，很多步骤都重复了。对于你说的 “数据完整生命周期”，我们在接口测试时会做，然后我想请教一下，这种情况，还需要单独的写么？

我们这边业务流程很长，很多功能可能都会执行相同的步骤，感觉这样写，很冗余啊。前辈会有这样的感觉么？

这个数据的流向以及逻辑正确性，我们会在接口测试的时候做

对，是这个意思，就是每个开发分配任务是按照功能业务去分配的，他就想着我们写一套完整的针对这个功能业务的测试用例

这个要看具体情况吧。

如果流程不算复杂，但很重要，可以有少量用例去过一遍全流程，看是否能完全走通。这有点类似于单测和集成测试的区别，每个模块单独测试都没问题，但连在一起可能就会出问题。

如果流程很复杂很长，那就基于这次的改动范围设定好起点和终点的，只走一遍改动范围涉及的流程。

这么说可能比较抽象，你可以分享下你们的完整流程以及本次改动涉及的模块情况不？这样可以给到更有效的意见。

如果是一个数据流的，建议根据业务需求测试一下。
举个例子吧，比如我们下发控制一个设备，当我们在前端做了点击了下发的按钮，有的后端会直接返回一个成功的提示，实际到了设备那里呢，未必就真的操作成功了，所以整个流程串起来，你才能知道这个业务链条是否真的成功，有效。

下一步应该是用例抓手

流程的话不是很复杂，简要描述一下，在其他模块我们会捕捉客户的访问情况，然后在客户模块有一个访客模块，用来展示访客列表及新访客的红点数。但是其他模块的访问情况不仅仅会走到访客这里，还会走到客户的动态，客户的活跃时段等等。数据流向为一到多，就相当于多个模块之前都有关联。

评审不就是找问题，找不足嘛，当时也给他解释了很久。他就始终站在开发的角度，我开发这个功能，能不能对这个功能有一个全流程的用例。所以这才来问问，各位前辈的意见，看怎么做最好，让大家都服气。

闭环，是一条数据从头到尾吧，可能没描述清楚，这种问清楚不就好了

实际上我们在写测试用例的时候，如果是每个模块都对上下游进行了关联验证，那么各个模块的用例执行完之后，本身是可以形成闭环的。
最多再根据业务流程设计几个完整的流程测试用例就可以覆盖了。

最近也在回看设计测试用例的知识，设计的时候尽量从各个角度上考虑。产品 PRD 功能的覆盖、数据流转、新老接口等等吧，随着经验的增加形成自己的常用测试点列表。推荐看看《饿了么质量体系搭建实战》中的第二章，希望对你有帮助吧。

一、闭环用例，换个词，联调用例，就能沟通了。开发应该想表达的是，需要把模块串起来测吧，你是不是缺少了这样的模块之间的联调用例。
二、覆盖黄金链路，从头到尾，这个也要有的。如果你只是模块测试，不需要写；如果你是主测试，就必须加上。

接口测试都做了数据流向和边界测试了，正常跑几个主要流程就行了啊。

写用例不是都针对当前模块吗，串流程我们一般是有专门的时间和用例去回归

前辈，你觉得我把接口的用例兼容到功能用例里面可行么，也就类似有评论说的，针对该业务完整的数据流单独做一个功能用例编写，这样开发到时候看到这一块，应该也不会说啥了吧。

谢谢推荐

嗯嗯，我最近也在思考，针对业务完整流程的功能测试用例是不是也需要写一下，因为我习惯在接口测试的时候，通过接口对某一个业务走完全流程，包含数据的流向，落地到数据库，业务逻辑等

前辈，你的意思是说你们会写两份用例么，一份是单独的功能模块的，一份是整个流程的么？那人员是怎么安排的呢，是单独安排一个人去做，还是说，你们做完单模块之后去做。

这个时候，这个你画个数据流向流程图用例就可应付了
http://testerhome.com/topics/33072

1、开发说的 “用例封闭” 可能不太好理解，但意思测试人员都应明白。
2、从测试的全面性来看来，分开两类用例：一类是单点功能测试用例，二类是站在用户角度的场景用例，这种场景用例是用户完成其业务带来价值的场景，是非常重要的，一般是多个功能点串联起来的用例。而这背后涉及的数据流程向，正是开发人员提到的数据流程到多个模块，一旦有变更，那么所影响到数据是否受影响了，需要全面验证，以达到更改影响封闭（这就是开发人员表达的 ‘用例封闭’ 吧）
3、关于用户场景业务流与数据流，建议分开写用例，业务流象用户一样观察。数据流用软件设计的视角检查生成的文件，数据库等

不用开发交怎么写用例，，，每个用例都有前置条件，预期结果，每个小点完整 j 就 OK 的啊，业务流程可以单独规划一些。

听起来有点像埋点，有多个数据入口，最终数据汇聚到少数几个出口进行查看。

然后你和开发争论的 “用例没闭环” ，具体你的用例大概是怎样的，开发期望补充的用例是怎样的？

有固定的主流程回归用例，一般就测完了自己跑一下

感觉像用户场景模拟，大致写一下，自己整体回归的时候走一遍

今天跟我们公司大佬沟通了一下，后面计划我们把不同模块有关联的用例，抽离出来，单独形成一个完整的业务流程用例，这样到时候我们回归和开发自测都可以用到。后面我私下跟开发也沟通了一下，他们想要的就是这种，完整的业务流程用例。那个业务用到的就是埋点，跟你讲的一样。埋点是在其他模块写的用例，展示的地方也有很多，我写的客户模块就包含。当时我对我写的客户模块进行评审，开发就说流程不完整。

前辈说到的第三点中提到数据流和业务流，我可不可以这样理解呢，业务流就是评论中有提到模拟客户业务场景，而数据流其实更多体现在接口之间的交互，数据的传递，这个我觉得在接口测试的时候做会不会更好呢。

1、前辈说到的第三点中提到数据流和业务流，我可不可以这样理解呢，业务流就是评论中有提到模拟客户业务场景
--是的
2、数据流其实更多体现在接口之间的交互，数据的传递，这个我觉得在接口测试的时候做会不会更好呢。
--如果有接口专项测试人员 可覆盖到，是可以。如果没有，从用户场景流程出发，把用户在执行场景流程时产生的数据，数据的流入流出搞清楚也是很有必要有。例如：我们现在用的腾讯在线多人协同文档，假定有 A，B，C 3 人同时修改同一文件，保存后数据保存在什么地方呢，如何处理冲突的呢？什么机制刷新到同一文件中的呢？等等

开发想表达的，应该是少了一些串起来的业务流程用例,你的用例如果都只是单功能的，这只相当于只有单接口测试，你还得有基于业务场景的测试呀。功能测试也一个道理，为了用例的复用，可以把单功能用例，组合为业务场景用例

这就是把单功能用例转为业务场景用例

重要数据流向的我们都是分在涉及到的重点模块中找人专门测试闭环，或者整理到冒烟中，其余的就是看主要是哪个模块就分到哪个模块中去测，如果是重要的，那重复测试也不造成浪费，因为本身就可以形成交叉测试了

看你们集成策略，我们一般是单模块做完再一起做。

分场景测试用例和功能测试用例，场景测试用例就是给开发自测或者冒烟的，这就是闭环测试用例了。

确实，其实后面我们也会交叉测，按照这种方式只是提前交叉了，也挺好。

嗯嗯。了解了

我后面也是这样打算得，把单模块中有关联的用例组合在一起，形成一个完整的业务场景用例

在功能模块中做原子能力的验证，在业务场景中做串联的验证。彼此不矛盾。

itest work 你可以试试， 截图就是 itest work

下游模块的功能测试用例 需要上游模块产出的数据或状态做为前置条件 用例中直接作为用例的前提条件出现好了

自动化不是应该追求低耦合性吗，如果是联调测试那就按联调测试去考虑用例