今天，遇到了这样一个问题。这个问题经历了两轮测试并没有被发现。
背景
这次测试的内容是一个活动页面，需求的情景是从app内访问链接并进入到这个活动页面，伴随着自动登陆（不需要用户输入用户名和密码，对app的用户登录状态进行获取并进行自动登录）。
问题
只有第一次访问活动页面时会返回50x，之后再进入活动页面都不会再返回50x，一切正常。
没能发现问题的原因
因为每天的测试工作要大量的切换hosts，所以很容易出现由于浏览器或app缓存所导致的问题。一般通过刷新、清理缓存能够解决的问题，我们大多数情况认为是环境导致的，不属于开发的代码问题。恰恰是这样的想法，配合上这个问题逻辑上也只会出现一次的隐蔽性，导致了之后都没能再发现这个问题。归根结底，是由于测试用例的设计没有贯穿整个测试需求流程逻辑的始终。
反思
想要发现这样的bug，首先要对接口返回的数据非常敏感。如果不通过配合Fiddler进行实时抓包跟踪的黑盒测试，我们很难由表及里的发现这个问题。换而言之，想要发现这个问题，从单纯的黑盒测试上来讲，有两种办法：
1. 大量的用户试验；（无针对性，盲目不可取）
2. 保证测试流程的始终性和测试用例设计的完整性。（有针对性，可取）
总结
想要避免这种问题的发生，排除知道代码逻辑的情况（单元测试能够发现的问题），另一种就是从表及里（黑盒测试的手段）发现这个问题。
由于问题很隐蔽，我们必须从逻辑上下手，那就是保证测试流程的始终性和测试用例设计的完整性。以“登陆”为始，以“退出登录”为终——所有的测试用例必须由始至终进行设计，才算完整。如果不保持流程的始终性和完整性，我们很难发现两端衔接处存在的问题（比如涉及到自动登陆的问题，第一次访问失败，但登陆状态可能将被记住，第二次访问将一切正常，所以如果用例设计不包括登陆操作和退出登录操作的话，将很难发现这个自动登陆上存在的问题）。如果用例只在排除了始端和终端外的中端部分进行测试，测试结果将很容易建立在已经存在的bug的基础上。