大多数测试人员认为测试工作是发现bug，虽然这是测试的主要任务，但其实测试最重要的任务是质量控制，而发现bug和验证bug只是质量控制的一个重要环节而已。
我想很多测试人员都经历过这样的场景，就是测试环境全部都能测试通过，但正式上线之后就会有各种各样的bug，到底是哪里出了问题呢？
在测试工作中，常见的问题原因分为以下几类：
-
不同版本的数据兼容
这是最常见的问题，一般新版本的迭代不仅仅是代码层面的，还有数据库的改动，而对于线上原有的数据来说改动了数据库有可能会受到影响。
举个例子：
如果数据库增加了一个字段，那么新数据肯定会通过新的程序给这个字段赋值，而原有的数据这个字段往往是空的，这时读取该数据就会发生问题。
当然这只是一个最简单的情况，这种情况在测试环境可以用历史数据进行测试从而发现该问题。但往往还有更多复杂的情况，有时候是需要手动造数据库的数据来模拟数据兼容的问题。这个就是测试比较容易忽视，也最容易发生问题的一个点。
-
测试环境和正式环境的不同
测试环境和正式环境的不同也是一种经常发生的事情，
不同分2种情况：
-
硬件方面的，一般正式环境的服务器都比测试环境来的好，所以硬件上不太可能一致，虽然这个差异影响比较小，但也不排除会影响程序的运行。
-
软件方面的，包括程序语言的版本，服务器系统的版本，甚至服务器的权限控制都会影响到程序的运行。
如果说不同版本的数据兼容问题可以在测试环境预判并测试，那这种情况可能只能做到提醒开发和运维人员了，硬件方面没办法，软件方面尽量做到一致，以减少测试环境和正式环境的差异，让正式环境上的程序跑的更加稳定。
-
服务器的配置
这个不同于上面说的程序语言版本，而是在代码层面的配置：
-
配置文件，包括代码的相对路径，某个功能的开关，又或者是服务器ip的配置等等。而这些都是相对于测试环境配置的，如果发布的时候将配置文件覆盖也会导致正式环境出问题。
-
服务器上配置的crontab脚本，很多程序是需要通过crontab脚本定时执行，而crontab又是需要在服务器上配置的，自动配置不方便控制及维护。所以大多数还是需要人为去配置的，这个配置如果漏了或者配置错也会导致出问题。
以上3点只是常见的，事实上可能会遇到更奇葩和不可思议的问题，
例如
-
正式环境多台服务器有一台服务器代码未更新，导致问题时隐时现。
-
数据库的主备数据不一致，当切换主备数据库后会出问题。
所以好的测试不能只把目光放在代码层面的测试，而是要从更高的视角去看整个项目在上线发布的时候存在的各种风险。有些可以通过测试而发现出来，而更多的还是要提醒开发和运维人员去规避这些上线的风险，我想这才是好的测试人员应该做到的事情。
