测试的最后一公里

    我想测试的最后一公里，应该是release或者上线之后短时间内或者客户在验收测试中没有发现严重的质量问题和blocker issue，比如软件崩溃，block error，性能太差，安全问题等。

    从原文作者的例子来看，开发和测试都很苦逼啊，赶进度狂加班好不容易熬到release准备回家睡觉，半路上一个夺命call：刚上线就被发现问题了，速速滚回来调查原因！如果最终确认真的属于质量问题，简直欲哭无泪，哪怕之前再辛苦，在老板眼里印象最深的却是：你干什么吃的？

    这就像参加奥运会的运动员一样，辛辛苦苦4年，就看你最后比赛的几分钟怎么样，要是发挥好了你好我好大家好，要是一个不小心失误了，平时再努力再有实力又怎样。关键时刻一锤子买卖！

    回到测试，所有人都知道，测试不可能穷尽，每一个release的产品肯定还有Bug，原因多种多样，比如：

    1，客户的真实环境和测试环境不一致。客户的环境用什么配置，装了什么软件，如何搭建的环境，都可能引起一些问题（兼容性居多吧），测试不可能完全和客户环境一致，就极有可能发现不了这些问题。

    2，客户数据库引发的问题。测试的数据库数据简单，往往有些问题只在客户数据库上能够重现。我之前工作的CS产品，客户报的Bug很多都需要restore客户数据库去调查原因。为了避免这样的问题，可以在release之前在部分客户数据库上运行回归测试。

    3，硬件问题。你的软件在不同的硬件设备上使用可能有不同的behavior，但是往往研发团队里不可能拥有所有的硬件也不可能在所有可能使用的硬件上测试。这里众测或者beta测试是个不错的选择。

    4，性能和大并发问题。在测试中性能和大并发是可以模拟的，但是毕竟模拟的环境和真实使用的环境还是有不一致，往往在实际中去检验再获得提高。比如淘宝的双十一一年比一年好。

    5，真的是漏测！！！business欠缺没考虑到；长期测试形成盲点；或者老虎打盹疏忽了！有种情况是，有时你半年后测试你半年前测过的东西，居然还能发现bug。这个时候想当时为什么没发现这个问题？挺郁闷的吧。当然，这种情况要尽力避免，但常在河边走哪有不湿鞋，我相信做测试的同学都有这样的经历吧。

    还可能有其他原因，总之，release或者上线之后肯定有Bug毋庸置疑，但是不能有严重的质量问题，否则必然倒在最后一公里功亏一篑！那如何破这最后一公里？

    1，开发质量要高。都说这是根本原因，可是测试管不了开发质量，所以这点就算了，靠不住。

    2，TP review。让一起做的开发review，经验丰富的QA review，尽可能覆盖所有有效测试范围。

    3，Cross testing in test team。如果时间允许的话。不管是Agile还是瀑布模式，往往测试时间挤压得很有限，交叉测试都不会做。

    4，Bug Bash。如果时间允许的话。在回归测试前或者中，来场大范围的Bug bash效果会不错，对QA和测试团队也是一种高强度的磨练。

    5，Regression范围精准的划定。一方面要考虑时间成本人力成本，一方面要保证质量，所以自动化最适合回归测试了。

    6，不同的测试团队层层把关。这得舍得砸钱才行。我之前公司的团队除了测试还有一个release team会再把关一次；而现在的公司，传说中从build开始，有各种的VT（verification testing）团队，每个VT做一遍下来，到release出现严重blocker的几率肯定也会下降。

    Bug就是开发的梦魇也是测试心中永远的痛，只祈祷在每次的最后一公里能够顺利就好！