这年轻人

铁子，不说了，我创业去了，自己当领导，妈蛋

希望领导早点看到，好歹也是加了好多次得班做出来得，不用可太难受

嗯嗯，是的，感觉你们这个用自动化就太省事了

你是懂领导得

可能公司还是更需要我们手动点点点吧，苦涩

嗯呢，我觉得还是有点用的吧，起码前期投入了一部分时间，项目也跑起来了

雀氏，我当时说可以节约一点回归的时间；然后后期是可以尝试替换手动接口测试，开发单测可以，感觉还是能省时间的

我们根据客户提供的信息，在指定设备上，还是复现不出来；好在沟通之后，客户还是同意了，先上线，不知道大佬有没有好的方案，针对于这类问题的解决方式

情况是在弱网情况下，就一个列表页面加载不出来，正常网络没啥问题，反正后面反馈给项目经理，项目经理跟客户进行了沟通，还是上线了；但是我想的是，万一遇到客户不讲理，就说一定要解决，有没有好的预案来专门处理

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

嗯嗯。了解了

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

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

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

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

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

谢谢推荐

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

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

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

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

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

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

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