对低效率测试方式的一些疑问

[wephone]

最近一直开发类似积分体系，用户等级任务体系这样的东西。 到了测试的时候，就会经常遇到例如下面的情况:

1. 测试人员想使用积分抵扣，但这个测试账号没有达到领取积分的标准(或者领积分步骤麻烦)，于是测试人员就粗暴得去数据库，缓存上手动加积分然后进行测试。(感觉这样不经过正常业务流程的直接加数据，有时候会导致一些关联数据的混乱，出现测试环境有很多脏数据对应不上的情况)

2. 测试人员想测试高等级会员的特权等等时，由于等级较高，业务复杂难以短时间内达到(例如网易云的升级需要听几百首歌)，为了不让他们直接操作导致脏数据问题(当然也是因为有些测试并不会操作数据库和缓存)，于是开发人员加多个测试环境的特殊接口，浏览器一访问就加 n 分，直到让他加到那个高等级为止。 我也觉得这样不太好，造成了很多侵入的无用代码，但我不知道怎么做才更好。

3. 客户端在进行调试时，由于客户端程序的 bug 导致的一些问题，需要重头来过，导致客户端调 bug 时屡次让后端给他清数据 /缓存重来一遍。 严重影响后端开发的工作。

想和大家讨论下，这类积分会员体系等，测试需要很大依赖后端数据的业务，真正规范和高效率的测试方式和流程应该是怎样的？

PS：测试手点的，只会一点点技术或者完全不会

[lihongjie0209]

你们系统没有后台管理吗, 哪怕没有测试, 你们运营也需要这些功能吧

[luozic]

开发小工具插件 基于 jmeter，直接整数据库模拟都是法子。

[wephone]

@lihongjie0209 有后台管理，但要测的是用户端的，但用户体系升级业务复杂，测试也需要依赖后端数据

[wephone]

@luozic 感觉还是得有自动化测试的人员好点，不然模拟数据库这些，把后端的开发时间都占了一堆。

[iyaozhen]

大概看了下你可能需要一个能构造各个等级的方法。
这个就直接开个后门接口呗，传入参数直接设置等级，调用的底层方法都是原来的代码结构，不侵入原来的。
或者测试“慢慢”构造（比如听歌可以并发的去请求，也不会很慢）几个特定等级的账号就用哪几个测。
最后一个应该是不合理的，客户端不管啥折腾都不应该出现要请数据库的情况。还有一个开发环境要和测试环境隔离，这样也不会相互掣肘。

实际情况还得具体分析，其实开发的系统可测性也是比较重要

[chinvo]

单元测试做 mock

[chinvo]

系统测试做测试环境，从生产环境脱敏数据拉过来用

[whileFalse]

在管理后台价格功能很难吗

[wephone]

@iyaozhen 是啊 可测性 感觉您的意思应该是做多一套独立的测试系统，让这套系统去完成需要的数据构造

[wephone]

@whileFalse 这个不是加个功能吧，就算后台搞出来那批数据，测试还是得从头升级过一遍才对，而且这个线上环境不需要

[wephone]

@chinvo 感觉对于手点的测试 还是得后端再完成业务的基础上去做多一些 mock 操作的代码了

[chatfeed]

具体到这问题，程序设计上应该可以把积分这个规则做成可配置

[akira]

提供个调整设置用户积分 等级的地方呀，这样的功能运营的时候也是需要用到的啊