测试通过!为何线上还有很多BUG?实践中的质量控制

质量控制

  大多数测试人员认为测试工作是发现bug,虽然这是测试的主要任务,但其实测试最重要的任务是质量控制,而发现bug和验证bug只是质量控制的一个重要环节而已。

  我想很多测试人员都经历过这样的场景,就是测试环境全部都能测试通过,但正式上线之后就会有各种各样的bug,到底是哪里出了问题呢?

  在测试工作中,常见的问题原因分为以下几类:

  ●不同版本的数据兼容

  这是最常见的问题,一般新版本的迭代不仅仅是代码层面的,还有数据库的改动,而对于线上原有的数据来说改动了数据库有可能会受到影响。

  举个例子:

  如果数据库增加了一个字段,那么新数据肯定会通过新的程序给这个字段赋值,而原有的数据这个字段往往是空的,这时读取该数据就会发生问题。

  当然这只是一个最简单的情况,这种情况在测试环境可以用历史数据进行测试从而发现该问题。但往往还有更多复杂的情况,有时候是需要手动造数据库的数据来模拟数据兼容的问题。这个就是测试比较容易忽视,也最容易发生问题的一个点。

  ●测试环境和正式环境的不同

  测试环境和正式环境的不同也是一种经常发生的事情,

  不同分2种情况:

  硬件方面的,一般正式环境的服务器都比测试环境来的好,所以硬件上不太可能一致,虽然这个差异影响比较小,但也不排除会影响程序的运行。

  软件方面的,包括程序语言的版本,服务器系统的版本,甚至服务器的权限控制都会影响到程序的运行。

  如果说不同版本的数据兼容问题可以在测试环境预判并测试,那这种情况可能只能做到提醒开发和运维人员了,硬件方面没办法,软件方面尽量做到一致,以减少测试环境和正式环境的差异,让正式环境上的程序跑的更加稳定。

  ●服务器的配置

  这个不同于上面说的程序语言版本,而是在代码层面的配置:

  配置文件,包括代码的相对路径,某个功能的开关,又或者是服务器ip的配置等等。而这些都是相对于测试环境配置的,如果发布的时候将配置文件覆盖也会导致正式环境出问题。

  服务器上配置的crontab脚本,很多程序是需要通过crontab脚本定时执行,而crontab又是需要在服务器上配置的,自动配置不方便控制及维护。所以大多数还是需要人为去配置的,这个配置如果漏了或者配置错也会导致出问题。

  以上3点只是常见的,事实上可能会遇到更奇葩和不可思议的问题,

  例如

  ●正式环境多台服务器有一台服务器代码未更新,导致问题时隐时现。

  ●数据库的主备数据不一致,当切换主备数据库后会出问题。

  之类的问题很多,所以在最开始就讲要了解网络的架构(点击看原文),每一个中间的环节都有可能出问题,而不仅仅是代码这一个环节。

  所以好的测试不能只把目光放在代码层面的测试,而是要从更高的视角去看整个项目在上线发布的时候存在的各种风险。有些可以通过测试而发现出来,而更多的还是要提醒开发和运维人员去规避这些上线的风险,我想这才是好的测试人员应该做到的事情。

  看到这里是不是会发现,一部分原来认为是测试人员背的锅,其实并没有那么地委屈。因为宽以待人严于律己,作为优秀测试人员的你,可以做得更多更好!

时间: 2024-10-29 14:17:57

测试通过!为何线上还有很多BUG?实践中的质量控制的相关文章

测试通过!为何线上还有很多BUG?

质量控制 大多数测试人员认为测试工作是发现bug,虽然这是测试的主要任务,但其实测试最重要的任务是质量控制,而发现bug和验证bug只是质量控制的一个重要环节而已. 我想很多测试人员都经历过这样的场景,就是测试环境全部都能测试通过,但正式上线之后就会有各种各样的bug,到底是哪里出了问题呢? 在测试工作中,常见的问题原因分为以下几类: 不同版本的数据兼容 这是最常见的问题,一般新版本的迭代不仅仅是代码层面的,还有数据库的改动,而对于线上原有的数据来说改动了数据库有可能会受到影响. 举个例子: 如

安卓热修复,android打补丁,不用发版本就能实时的解决一些线上版本的bug

背景 当一个App发布之后,突然发现了一个严重bug需要进行紧急修复,这时候公司各方就会忙得焦头烂额:重新打包App.测试. 向各个应用市场和渠道换包.提示用户升级.用户下载.覆盖安装.有时候仅仅是为了修改了一行代码, 也要付出巨大的成本进行换包和重新发布. 这时候就提出一个问题:有没有办法以补丁的方式动态修复紧急Bug, 不再需要重新发布App,不再需要用户重新下载,覆盖安装? 搜索发现有这3种方式可以实现(至于其他的方式,暂不清楚) 1.dexposed     github https:/

性能测试之线上引流测试--让性能测试更真实更丰富

为什么要做引流测试 目前为止大部分的测试是在测试环境下,通过模拟用户的行为来对系统进行验证,包括功能以及性能.在这个过程中,你可能会遇到以下问题: 用户访问行为比较复杂,模拟很难和用户行为一致,模拟不够真实; 线下模拟场景有限,会出现业务覆盖不全的情况.引流测试就是为了解决以上问题,通过把线上的真实流量复制到线下环境,解决测试环境模拟不够真实,或覆盖不够全面的问题. 引流的做法 目前不少公司对引流测试进行了实践,主要有以下4种引流方式: 以上几种办法各有利弊,有的是需要自己开发相应的工具来支持.

使用tcpcopy复制线上流量进行测试

使用tcpcopy复制线上流量进行测试 online server 线上服务所在机器 10.136.11.4 部署tcpcopy sudo /usr/local/tcpcopy/sbin/tcpcopy -x ONLINE_PORT@ONLINE_SERVER_MAC_ADDR-10.136.11.5:TEST_PORT@TEST_SERVER_MAC_ADDR -s 10.136.11.3 -o eth4 -i eth4 -c 10.136.100.x -d -l ./tcpcopy.log

轻松排查线上Node内存泄漏问题

I. 三种比较典型的内存泄漏 一. 闭包引用导致的泄漏 这段代码已经在很多讲解内存泄漏的地方引用了,非常经典,所以拿出来作为第一个例子,以下是泄漏代码: 'use strict'; const express = require('express'); const app = express(); //以下是产生泄漏的代码 let theThing = null; let replaceThing = function () { let leak = theThing; let unused =

(转)HBase工程师线上工作经验总结----HBase常见问题及分析

阅读本文可以带着下面问题:1.HBase遇到问题,可以从几方面解决问题?2.HBase个别请求为什么很慢?你认为是什么原因?3.客户端读写请求为什么大量出错?该从哪方面来分析?4.大量服务端exception,一般原因是什么?5.系统越来越慢的原因是什么?6.Hbase数据写进去,为什么会没有了,可能的原因是什么?7. regionserver发生abort,遇到最多是什么情况?8.从哪些方面可以判断HBase集群是否健康?9.为了加强HBase的安全性,你会采取哪些措施?在Tcon分布式系统测

HBase工程师线上工作经验总结----HBase常见问题及分析

阅读本文可以带着下面问题:1.HBase遇到问题,可以从几方面解决问题?2.HBase个别请求为什么很慢?你认为是什么原因?3.客户端读写请求为什么大量出错?该从哪方面来分析?4.大量服务端exception,一般原因是什么?5.系统越来越慢的原因是什么?6.Hbase数据写进去,为什么会没有了,可能的原因是什么?7. regionserver发生abort,遇到最多是什么情况?8.从哪些方面可以判断HBase集群是否健康?9.为了加强HBase的安全性,你会采取哪些措施? 在Tcon分布式系统

对线上系统维护工作的总结与思考

背景描述:目前在一家网站公司工作,2015年初研发中心部门改革,小组重组,被分配到了网站平台的维护组.下面内容是对近期维护工作的一个总结: 个人感受:以前也在老东家的团队也做线上系统的维护和新产品的研发,由于大家的认真负责,Leader的管理也很到位,线上的系统很少有bug反馈,不管是UI上迭代,还是系统逻辑的升级都很顺畅. 目前负责的平台运行了3年多,可能由于当时逻辑设计问题,也可能是执行问题,发现近期反馈的问题多是逻辑问题,在此对这些问题的原因不做探讨和深究,只是想讲讲面对线上问题的维护工作

我的物联网项目(七)前期线上事故

一 MQTT连接数报警 项目上线一个月左右,投放出去的摇摇车数量大概在200量左右,平均每天在线数(听说有些商家精打细算,有小孩需要坐车了才插电,平时都不插电,还有些干脆一直仍在角落懒的管)也就维持在100左右,当时在阿里云购买的MQTT配置是连接数上限2000(MQTT是按连接数购买的),像目前的摇摇车投放数用当时的配置绰绰有余了,连续一个月以来,都是正常化(现在想来,当初的推广策略不成熟,每天投放的摇摇车数量也是要么一天3,4台,要么连续好几天才推广3,4台),所以问题并没有暴露出来,不过出