借问一下，大家业务代码都是怎么测试的？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2006 天前的主题，其中的信息可能已经有所发展或是发生改变。

看到前面一贴，/t/570669 大家主要谈的是单元测试，tdd bdd 这些方式。

对于业务逻辑，代码本身没问题，测试不会出错。对于业务逻辑上可能出的漏洞，大家都是怎么测试的？纯人肉吗？

测试

代码

借问

逻辑

19 条回复 • 2019-06-05 17:28:50 +08:00

dilu

2019-06-05 08:48:02 +08:00

按照主流程走一遍，保证 80%的几率不会出现问题就行了，剩下的就是测试工程师按照用例一步步走下去了

顺便一提不是说会有 20%的记录会出现 bug

而是 20%的记录会出现跟产品预期不符，例如字体错位，兼容性，服务器抽风，脏数据等等

还有一点就是，写代码千万不能只看技术，从用户角度出发，哪怕我不会用你的功能，这本身就是个 BUG

所以 0BUG 是不存在的

wobushizhangsan

2019-06-05 08:58:56 +08:00 via Android

开发完直接上线

qce7

2019-06-05 09:01:48 +08:00

业务不变一般没 bug，如果要改业务，谁提的需求谁测试

Lax

2019-06-05 09:03:50 +08:00

除了单元测试，还有功能测试和集成测试。

shuang

2019-06-05 09:04:15 +08:00

是的，业务代码纯人肉。重点需求有测试用例，不过也是很粗粒度的偏流程验证的。
也想过自动化之类的，不过觉得成本太高
看楼下有没有什么好的建议

turi

2019-06-05 09:09:32 +08:00

mark
现在也是测试人员测试

iConnect

2019-06-05 09:09:42 +08:00 via Android

业务代码的测试一点都不简单，如果涉及到事务的完整性，脏数据，数据量级，时间维度的触发不同业务的场景流程，更加复杂。
这也是为什么大厂要用灰度发布的原因，一方面是探测用户需求，一方面也是控制可以出现的故障范围。

trustlife

2019-06-05 10:12:49 +08:00

业务逻辑系统，如零几年的中科软保险系统，用到现在依然还是会存在缺陷。前期的测试案例编写非常重要。代码修改评审可以减少问题产生，当然缺陷肯定是无法消除的，

KasuganoSoras

2019-06-05 10:17:06 +08:00

开个测试环境，发个链接给朋友，来来来你帮我 XJB 点一下测试看看，有啥 bug 告诉我，等会下班请你吃饭

mlxy123123

2019-06-05 10:20:54 +08:00

你们说的「业务逻辑」具体是指？
为什么业务逻辑的测试需要单独讨论？

TommyLemon

2019-06-05 10:53:47 +08:00

很多 bug 都是改出来的，原本已经没 bug 了（至少不会有容易复现的 bug ），
改了后没有经过严谨地验证，很容易出现新 bug 或引发原本不会发生的旧 bug。

单元测试是个好东西，只要完整编写用例，覆盖足够多的排列组合情况，
后续每改动一次代码就跑一次完整的测试用例，bug 就很容易暴露出来。

但问题是单元测试代码工作量太大了，而且改了业务代码，还得同步修改测试代码。
现在用 APIJSONAuto 自动化接口测试，不用写任何代码，点几下按钮就行了

自动化接口管理工具，自动生成代码、自动静态检查、自动化回归测试、自动生成文档与注释等。
* 自动生成接口文档，清晰可读永远最新
* 自动校验与格式化，支持高亮和收展
* 自动生成各种语言代码，一键下载
* 自动管理与测试接口用例，一键共享
* 自动给请求 JSON 加注释，一键切换
* 自动保存历史请求记录，一键恢复

代码已开源，可以点 Star 支持下哦 ^_^
https://github.com/TommyLemon/APIJSONAuto/