不会设计测试用例，头疼

[Orenoid]

现在需要给项目里的一个功能写测试代码，这个功能会执行一个比较复杂的流程，输入一批数据后进行一个统计，最后算出几个数字，现在我需要校验这个统计逻辑是否正确。
首先我在测试用例里会把这个流程也执行一遍，拿到它的计算结果（记为 A ）。而我的疑问是，我要怎么去校验这个结果的正确性，我目前有两个思路：

1. 因为测试用的数据源都是我写死的，我可以根据相应业务逻辑单独算一遍，算出正确结果（记为 B ），然后直接拿 A 、B 去比对，但是这样好像会导致测试用例的可读性和可维护性很差，因为结果 B 被我写死在测试用例里了。
2. 或者在测试用例里，模拟这个业务流程重写一遍统计的逻辑，通过代码算出结果 C，然后再对比 A 、C，但这样大概率还是会按照原代码去实现，似乎又达不到测试的目的。

请教下哪个比较合理，或者是否有更好的设计思路。

[lewis89]

DIP

[renmu123]

我倾向于 2，可能你刚写完代码测试没什么问题，但是十个月后谁也不知道哪里会被改动，导致结果错误。可以每次测试的时候取一定数量的随机数计算对比 a 和 c，也可以将一些边界值以 1 的方法进行测试

[xuhai951753]

一般都是方案 1 吧。。多设置几组测试数据。然后提高测试行覆盖和分支覆盖就好了。
可读性的话参考下 bdd 那种框架。

[zqz19941106]

都做 测试不怕多测

[chenluo0429]

在我看来测试用例主要还是检测在相关代码修改之后，功能是否还能满足原设计，确定算法写的没问题，最开始的测试用例都是直接相关的逻辑生成的。
如果一定要验证新写的功能，那就只能额外去设计数据了。

[balabalaguguji]

我最近才做了一个测试用例的视频教程： https://www.bilibili.com/video/BV1nh411974p?p=8
如果你的是 http 接口的话，很适合，可以看下

[hardwork]

1 和 2 都行吧，看哪个成本小，正确率高。
用 2 你要保证自己程序的正确性。。
用例设计还是老理论，边界值，归类法这些。