#2 对原测试⽤例的疑问和改进

### 1. book_id重复 在测试商家添加书籍接口（`fe/test/test_add_book.py`）时进行多次测试，每次测试的都是book.db中id最小的两种书。但如果这样测试，每次都会因book_id重复而返回错误，起不到测试效果。 改进：在每次获取图书信息时给图书ID加上一个通过随机生成的后缀，保证每次测试使用的图书IDd不一样。 ### 2. 负载生成过程中store_id与book_id不匹配 在`fe/bench/workload.py`中生成新订单的函数`get_new_order()`函数中，首先在所有店铺中随机选择一个store_id，然后在所有书籍中随机选择一个book_id作为新的订单。但问题在于，这样选择的书籍不一定在选择的店铺中，这会导致生成的订单无效，不能生成有效的负载 改进：选择book_id时，不在所有书籍中随机选择，而只在对应店铺中的书籍中随机选择 ### 3. 吞吐率测试和计算方式错误 起初使用原测试用例进行吞吐量测试时，发现线程数与吞吐量呈线性关系，增加线程数至5万后本地测试得到的吞吐量有170万，这显然是不合理的。 查看其测试和计算方式后发现吞吐率测试过程中存在以下较明显的错误： 1. `run_get()`函数中，new_order_i变量记录了累计的订单总数，并将该变量作为参数传入`update_stat()`函数更新吞吐量，但在`update_stat()`中却将该参数作为两次更新间隔中的订单数量，这导致吞吐量被错误地增加了很多 2. 测试没有使用多线程方式发起请求，但`update_stat()`函数中直接将订单数作为线程数输出 3. `run_get()`函数中，对更新状态的条件判断是： ```python if self.new_order_i % 100 or self.new_order_i == len(self.new_order_request) ``` 即原本希望每100个订单对状态进行一次更新，但实际上是每100个订单只有1次不更新，正确写法应该是： ```python if self.new_order_i % 100 == 0 or self.new_order_i == len(self.new_order_request) ``` 改进：鉴于原测试存在较多不合理之处，为了测试并发场景下的吞吐率，我们在原测试负载生成的基础上编写了一段测试代码，即fe/tps/testTps.py，测试结果由日志和折线图方式呈现 以上修改后对应的文件可在pull request中查看