求问，业务代码如何快速测试？

• 資深大佬 : Yiki888

  码一下 等大佬解决

• 資深大佬 : PerFectTime

  同想知道

  复杂的业务流程只能上去点点点，没啥好的办法

• 主 資深大佬 : oaking

  @PerFectTime 但是点点点太费时间了，并且有时都懒得去点点点，导致 bug 多多

• 資深大佬 : PerFectTime

  @oaking #3 是啊，而且上去点的话不一定能测到所有情况，蛋疼

• 資深大佬 : Chinsung

  最近刚好有研究，mock 加代码覆盖率呗。
  我们公司现在上的方案是 mockito+mock-server+cobertura 。

• 資深大佬 : AAASUKA

  招几个 30k~50k 的测开

• 資深大佬 : maichael

  1. 测试左移，通过单元测试覆盖大部分测试用例
  2. 在架构设计上把可测性设计考虑进去，通过提供测试接口之类的方式降低自动化测试脚本编写的难度和工作量，提高整体测试的闭环程度
  3. 集成测试模块化，降低模块之间集成测试的耦合性；通常来说版本更新只会涉及到部分模块，通过模块化将人力和精力聚焦在有变动的模块上，提高整体效率和减少工作量

  反正就是能用自动化脚本替代的测试尽可能用自动化脚本替代，然后开发要从架构上考虑方便测试脚本接入。然后划分好测试边界，能提前测的提前测，没必要再测一遍的功能尽量不测。

• 主 資深大佬 : oaking

  @maichael 首先感谢你的建议，在 架构比较 不利于设计的情况 ，有什么测试 的 好方法

• 資深大佬 : tmackan

  质量不只是测试的，也是开发和产品的。
  有些代码就是 shit 山。。。

• 資深大佬 : wsseo

  单元测试+点点点

• 主 資深大佬 : oaking

  @tmackan 所以就想着开发在做 开发测试的时候可以覆盖 80%，但是发现 系统自己进行测试时耗时耗力，全靠点点，需求多时间短，测试吐槽 bug 多。

• 資深大佬 : JYii

  @tmackan 说起 shit，一开始我还对我造成的 shit 山愧疚，然而无穷尽的需求变更后，爱咋地咋地

• 資深大佬 : tmackan

  @oaking 不写单测的情况下，你是否对业务整体有清晰的理解，并且自己有对程序健壮性，边界，异常等有提前的处理判断?自己是否有主干的测试流程，这是对开发最基本的要求。你可以不写单测，但是程序起码得跑通吧？

• 資深大佬 : tmackan

  @JYii 是的 重构耗时耗力，软件特别容易烂尾