大家好，我是测试奇谭的作者风风。
本周，在一次测试任务中，我发现了一个业务的细节点，并产生一些思考，打算分享出来，同各位同行一起思考，一起成长。
老规矩，先说问题：
问题
（因涉及公司业务隐私，部分场景已打码或已替换）
测试场景：
大家都知道去超市购买东西，收银机会打印购物小票。我测的场景是，打印购物小票后，收银机会将购物小票保存为pdf，并上传给后台服务器。
因为功能简单，测试很顺利，基本没遇到阻塞性问题。但我发现，当网络不好的情况下，上传小票pdf的请求会一直重试（间隔60s）。
重试有毛病吗？
按正常思维和逻辑，没毛病。网络恢复后，小票pdf还是会被推送到服务器。
但，如果你站在用户的角度去思考——假设超市一整天都没有网，该有多少条待推送的小票pdf？
随着一次次销售，一次次小票pdf的累加，会给前端收银机带来IO压力（频繁写日志）；并且，60s的重试机制，很容易在某个点达到高并发，给后端接口带来压力。
这就结束了？
在之前的文章中，风风有提到过一点：当你找到问题原因后，合理地提出解决问题的建议，才是你关注的重点，而不是因为找到问题原因而沾沾自喜，迷失于他人的赞许中。(原文：重温黑盒、白盒与灰盒测试方法)
因此，当你站在用户的角度，发现该问题之后，你能否再想到一些解决方案呢？
比如：
将失败的推送任务保存在本地，当网络恢复时，逐个推送（减少收银机IO操作，并且不影响收银业务）；
重试时间设置为指数增加模式（减少对接口的压力）；
……
站在用户角度发现问题，提出解决方案，这是作为一名测试该思考的，并且应当给产品方、业务方提出合理建议，再认真落实解决闭环。
这就是我们常说的主人翁意识、全局意识。
再举一个实际的例子。
有次，我去一家大型超市购物，买了两袋火锅底料，但是在收银台结账的时候，我突然想起几天前刚在网上买过火锅底料，只是忘记取货了。于是，我告诉收银员，这两袋火锅底料我不想要。
由于收银员已经扫了火锅底料的商品条码，要删除商品，他需要找轮值的收银组长，在组长授权（收银机上认证）后，他才能在收银机上完成删除操作。
当时，我就特别纳闷，就删除个商品，要这么麻烦吗。
直到后来，我测试过收银系统，并同收银系统的产品交流后，才明白这个操作的必要性——不仅需要授权，还得上报收银员操作行为。
因为，
在大型超市，大部分店损不是因为外贼，而是因为内鬼。内鬼收银员同家人串通好，让家人拿10件商品来结账，如果没有授权操作，内鬼收银员可以将商品改成1件，收1件的钱，让家人拿走10件。
注意，这不是虚构，这是真实案例！
如果我们没有站在用户的角度去思考，便很难理解删除商品为什么还需要授权。
当我们站在用户的角度去思考，或者换个角度思考，之前自以为的不合理，其实有存在的意义。
01 测试思维进阶的方法有很多，站在用户角度思考是之一；
02 发现问题后，不要忘记思考解决问题的办法，并落实闭环。
