标签：
今天，遇到了这样一个问题。这个问题成功的经历了第一轮测试、第二轮测试并成功发布带到线上。
这次测试的内容是一个活动页面，需求的情景是从app内访问链接并进入到这个活动页面，伴随着自动登陆（不需要用户输入用户名和密码，对app的用户登录状态进行获取并进行自动登录）。
只有第一次访问活动页面时会返回50x，之后再进入活动页面都不会再返回50x，一切正常。
因为每天的测试工作要大量的切换hosts，所以很容易出现由于浏览器或app缓存所导致的问题。一般通过刷新、清理缓存能够解决的问题，我们大多数情况认为是环境导致的，不属于开发的代码问题。恰恰是这样的想法，配合上这个问题逻辑上也只会出现一次的隐蔽性，导致了我之后都没能再发现这个问题。
想要发现这样的bug，首先要对接口返回的数据非常敏感。我们必须通过Fiddler进行抓包，发现这个出问题的接口，并把这个接口返回的数据给开发看，让开发找到对应的后台代码，也就是对问题的出处进行确认。只有这样，才能通过黑盒测试的方法发现问题的所在。如果不通过配合Fiddler进行实时抓包跟踪的黑盒测试，我们很难由表及里的发现这个问题。换而言之，想要发现这个问题，从单纯的黑盒测试上来讲，只有两种办法：
1. 大量的用户试验；
2. 就是我们说的，通过配合Fiddler进行实时抓包，绝不放过任何一个返回数据可疑的接口（你必须足够有经验，足够敏感。并且每一次操作前最好都要清空Fiddler，以保证抓到的数据你不会以为是你操作之前或操作之外的行为产生的而忽略掉）。总之，很难发现！你必须实时的盯着整个测试流程中所有接口返回的数据，并对返回值是否正常做出判断。一旦发现问题，必须换新环境进行重现，否则还是会由于在当前环境无法重现而当成环境问题并加以忽视。
而如果是开发对代码有足够的单元测试，这个问题应该是不难捕捉到的！可见单元测试的重要性。
想要避免这种问题的发生，有两种办法，一种是知道代码逻辑的情况（单元测试应该能够发现这个问题）。另一种就是从表及里（黑盒测试的手段）发现这个问题。由于问题很隐蔽，在一台机器上很难重现问题，所以必须拥有多个可供测试的终端配合发现问题（至少三台）。以后一旦发现返回50x的问题，一定要加以重视，记录问题出现的环节和对应的重现步骤。在上线确认前，要弄到至少三台可供测试的终端并设置wifi代理连接测试环境，分别在各个终端对问题进行重现，如果三个终端都重现问题，就可以确定问题存在，通过稳定的重现步骤，在问题出现的环节抓包获取到出问题的接口，把接口以及接口的返回数据给开发看，让开发找到对应出错的后台代码逻辑。
标签：
原文地址：http://www.cnblogs.com/LanTianYou/p/5392303.html
