辞职，考公

直接看后端服务的日志比较快吧，如果有 Cat 之类的，直接能看到响应时间，请求，响应这些信息的。

参数类型应该错了，你看下接口的参数定义里，这个参数的类型应该是个自定义的 DTO 之类的。你应该填写的是对应 DTO 的包路径。
比如 public Response addApi(AddApiRequest request) 这个接口，那你参数的类型应该是 AddApiRequest 的包路径：com.xxx.api.dto.request.AddApiRequest

结果啥时候出？

狄仁杰

质量才是目标，技术只是工具，这两年眼看着很多人舍本逐末，希望能沉下心来思考和解决实际问题的人越来越多，少点面向 KPI 编程的产物吧~

都这么多回复的，没看到一个赞同的，有点失望。
我觉得 magicyang 说的都是实话，也是事实，这有啥好争论的。
这年头咋那么多人实话都听不进去了，还在那自欺欺人，没用的，逃避不了的~

你这是面试被问了吗？

难道当测试不香吗？同样的技术水平，测试不比开发拿的多？

oookkk，辛苦了，感谢~

20 年的木有了吗？

那你赚了，等于变相绿了别人的老婆？

如果你不会一心二用 + 左右互搏的话，那应该是让你加班的意思。毕竟绝大多数人都是单核的吧~

建议看下你施压机的网络是不是被打满了

如果你想不用 usb 连接进行 monkey 测试，Android 的话建议可以使用 adb conncet 进行连接。iOS 暂时不知道方案~

如果是用了 master-slave 模式施压的，那可能是你 master 的网络带宽被打满了，导致施压上不去。
然后你增加线程数的时候，CPU 没有上去，tps 有增长吗？根据你的描述看，并没有看到有 CPU 密集型的操作，CUP 不高也正常。

你用的是单机施压还是使用了 master-slave 模式进行施压？

感觉要么是你施压机有问题，要么是 service 有性能问题，这 TPS 波动也太大了吧。。

我理解接口测试只是种手段，现在接口的参数类型、是否必填这种，直接注解就搞定了，我觉得测试的意义不大。
我觉得主要还是通过接口测试的方式，来保证接口对业务处理的正确性、健壮性等~

我觉得比较合理的实现方式是抽奖前按照配置的概率先生成个奖池，奖池的大小需要根据概率的精度来设置。
比如 1 等奖 1%，二等奖 9%，三等奖 30%，四等奖 60%
那就生成个大小 100 的奖池，其中一二三四等奖分别是 1，9，30，60 个，奖池内奖品的顺序混淆下，然后每次抽奖从奖池中取一个就行，取完之后将数据逻辑删除，1 个奖池抽完再生成奖池就行。
这样实现的话，你可以通过查看 db 中的数据和将 1 个完整的奖池抽空来测试实际的概率是否与配置的概率一致。

首先要看开发如何实现的，如果是根据配置的概率进行伪随机，那就直接打回吧，这概率是不可控的。

培训课程文案的既视感。。。

当然是可以啊，你按自己的需求包一层，暴露个接口出来就行了。

有区别的，代码实现考虑的不仅仅是业务逻辑的实现，还有一些技术层面需要考虑的点，比如调用 service 的顺序、数据一致性、如何加锁等等等等。我个人的理解是，PRD 什么的，与实际的实现可能会出现出入，而且同样的需求，可能不同的人理解会有误差。但是代码不会。
有能力的话，两手抓，我觉得还是更有优势。

主要是等价类的划分，不同的 QA、通过不同的维度、思考方式、划分粒度，划分出来的等价类也不同。怎么样的划分算是准确的，没有量化的指标去衡量的话，总会有主观的因素在里面。