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

[liudaqi]

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

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

[dilu]

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

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

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

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

所以 0BUG 是不存在的

[wobushizhangsan]

开发完直接上线

[qce7]

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

[Lax]

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

[shuang]

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

[turi]

mark
现在也是测试人员测试

[iConnect]

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

[trustlife]

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

[KasuganoSoras]

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

[mlxy123123]

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

[TommyLemon]

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

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

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



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

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

[fdko]

目前来说只能测试组同事尽量覆盖性地进行测试了。业务逻辑的随机性非常高，很难做到 100%全覆盖。就算测试组能全覆盖，也有可能测不出来低几率的 bug。所以，只能在开发的时候，尽量解耦，模组化，单元测试做好，并且辅助测试组编写用例。

[linvaux]

刚才看到了差不多的帖子，人家说是 目测的，你可以参考下😂

[qq976739120]

九章算法的的业务代码超过 90%的测试覆盖率....是真的牛逼 😂

[LowBi]

没有测试人员的，只能自己写自己测了

[jiangbingo]

考虑下 SC 层级的测试，robotframework 框架搭建业务场景，实现 feature 验证和回归测试。

[crohn]

测试人员按照用例跑，目前只找到这个办法，自动化测试成本高、复用性低，稳定项目可以尝试

[pythonee]

不知道大厂为什么能保持 80%开发人员，测试人员仅 10%的
业务也实现自动化测试不成

[yzkcy]

术业有专攻，测业务逻辑方面的漏洞的话，最好上线前让公司的安全团队过一遍。