Bug分析：对不懂的技术，不能轻易被忽悠

举一个简单的例子。

需求：需要优秀的前端大大做一个简单的上传图片功能，支持本地文件上传、图片url上传。

这个需求看着挺简单的，不管对开发还是测试，但是却在提测之后引发了一个问题。QA在进行功能测试的时候，使用了一个网易云存储的nos图片url，上传一张图片（这张图片曾经被开发上传过，这一点很关键，后面再说），却提示上传失败了，多次尝试后仍然如簇。因此，QA建了一个bug分配给对应开发，附上了测试环境、执行步骤、图片链接等。

开发很快地响应了这个问题，并呼唤了QA过去，当面上传了这张图片，可却奇迹般地成功了，开发拒绝承认这是一个bug，留下QA一脸茫然。回到座位后，作为一个执着的QA妹子，怎么可能轻易地放过这个问题， 当然等不死心地再尝试一把。果然，还是失败了。可是为什么会出现开发那边成功，QA这边会失败的情况呢？百思不得其解。后来分析可能会是环境的原因，便跟开发确认了他在测试时使用的环境、系统地址等等信息，终于发现了一个不一样的点： 开发在测试时使用的系统链接是HTTPS协议,QA在测试时使用的系统链接是HTTP协议。

告知开发后，开发反馈说，可能是由于跨域问题导致的，在HTTP协议下请求了HTTPS协议的图片，所以失败。看起来好像挺有道理的。

既然是由于协议问题导致的，那针对不同协议下的系统和不同协议下的图片都应做一下测试，下面是测试结果。

测试结果很明显地看出，在HTTPS协议下上传HTTP协议、HTTPS协议的图片都成功了，按照开发的说法，如果是跨域问题的话，上传HTTP协议的图片应该失败。找开发询问原因，开发解释说有可能是因为HTTPS是一个安全的协议，但是具体的机制他也不清楚。听到这里，QA觉得这不应该是靠谱的解释。之前对跨域并了解，但既然开发解释说是跨域问题，那便去了解下什么是跨域。

说到跨域，在此前应该先了解下同源策略。

同源策略，是一种约定，它是浏览器最核心也最基本的安全功能，用于隔离潜在恶意文件的关键的安全机制。浏览器的同源策略，出于防范跨站脚本的攻击，禁止客户端脚本（如 JavaScript）对不同域的服务进行跨站调用（通常指使用XMLHttpRequest请求）。

跨域，是指由于浏览器同源策略的限制，无法共享不同域名的资源。协议、域名和端口都相同的页面，具有相同的源。只要网站的协议名protocol、 主机host、 端口号port这三个中的任意一个不同，网站间的数据请求与传输便构成了跨域调用，会受到同源策略的限制。下面举几个简单的例子，更好地理解跨域。

1、 http://www.123.com/index.html      调用  http://www.123.com/server.php    （非跨域）

2、http://www.123.com/index.html      调用  http://www.456.com/server.php    （主域名不同:123/456，跨域）

3、 http://abc.123.com/index.html      调用  http://def.123.com/server.php    （子域名不同:abc/def，跨域）

4、http://www.123.com:8080/index.html   调用  http://www.123.com:8081/server.php （端口不同:8080/8081，跨域）

5、http://www.123.com/index.html      调用  https://www.123.com/server.php   （协议不同:http/https，跨域）

了解跨域之后，应该可以推翻之前开发的解释了。如果在HTTP协议的系统下，请求了HTTPS协议的图片，是由于跨域问题导致的，那其他情况按理不应该都成功。 确认不是开发陈述的原因后，告知开发，开发同学继续排查问题根源。

后面通过跟网易云NOS的开发人员沟通，确认是他们那边的图片缓存机制问题。相同图片第一次请求会被缓存，再一次访问时不会再发请求，即使是在不同协议下访问图片，都被被认为是相同请求，而这个处理机制NOS那边兼容不够好，开发先前已经在HTTPS协议的系统下请求过HTTPS图片，QA在HTTP协议的系统下再次访问该图片时会请求失败。NOS那边无法立即处理这种情况，但是 既然已经知道了问题的根源，我们的开发也可以暂时做好兼容方案，解决了该问题。

通过这个例子，我们应该有所感触：当面对我们并不熟知的领域时， 我们测试人员应该始终秉持着一种怀疑的态度，不要无条件相信技术同学对于问题的技术解答，可以质疑并且及时更新对相关技术的了解，这样不仅可以帮助自己提升，不会轻易被开发忽悠，也可以帮助开发同学更好地定位解决问题。