我对测试团队的理解

我对测试团队的理解

在技术团队中,大概至少也会包括两部分,对这种两部分的团队,一部分是研发团队,那么另一部分就会是测试团队。就我个人经验而言,测试团队会稍微小一点,但扮演的角色非常重要。但是不同的公司读测试团队的期望和定义不同,鄙人认为这才是导致了不同公司的测试团队的产出差异的最关键因素。那么首先测试是什么呢,或者说怎么定义测试团队会比较好呢?下面的部分我们会进行详细说明。 测试团队的目标:尽量提前发现bug,尽可能避免开发过程中引入新的bug,保证线上系统的稳定。 实现上面这个目标,一般我们会有两种做法。 功能性的测试,人工测试:对新功能的人工测试,就是通过真机安装,测试亲自体验产品的过程,观察在各种操作下,产品的表现是否符合产品设计的预期,如果符合就没有问题。因为产品功能是一个逐渐累加的过程,每次验证的话都会侧重在新功能上,所以对产品的其他功能不太能覆盖,所以如果引起了其他模块的问题,能不能靠人工测试发现,就比较看脸了。这个过程,主要的侧重点在功能的验证上。如果产品为安卓平台的话,可能还需要做不同机型不同版本的测试验证,这个过程往往也会产生大量的工作。人工测试的弊端在于,效率比较低,但对于客户端测试,除了这种方式,并没有太好的方法了,所以为了发现问题,测试要非常辛苦的尽可能多的操作,以期能发现更多的问题。 后端系统的回归测试:一般情况,对于前后端协作的产品,当然现在绝大部分产品都是这种类型的。同样的,每次功能都会包含后端的新feature。后端系统如果某个接口出问题了,运气不好就会直接引起系统的闪退。如果团队开发流程不是太规范的话,这个问题如果带到线上的话,会直接导致事故的产生。所以,后端系统的回归测试很重要,这个职责可以不放在QA这边,但是这个测试系统应该是测试团队提供。所以测试团队也是要写代码的,并且写得代码也不少,要提供尽可能全的测试用例,覆盖尽可能多的业务接口。这样,每一次上线,通过这个项目的保证,可以大大减少偶然引入的bug而导致系统出问题的可能,可以让测试更专注于新功能的验证,而不必担心其他任何地方会不会出问题而坐立不安😂。这一部分的工作一般会和jenkins集成起来。jenkins是另外一个主角,和项目管理工具和git同样重要,在提高团队协作效率方面也很重要。关于jenkins,我们后面会专门开文章讲解一下。自动化测试的体验影响到研发自己测试需要的时间,所以尽可能好的体验,会提高整个团队的开发效率哟。 压力测试: 对于业务中的核心接口,例如电商系统中的商品详情和商品列表页,登陆接口,加购物车,或者秒杀活动的接口,这些接口都非常核心,承载着系统中的绝大部分流量。所以,在上线前,对这些接口的性能评估也显得尤其重要,对于一个完善的业务系统而言,这是一个非常重要的环节。压力测试框架,开源的框架应该也有不少了,具体的我还没有了解过,会在后面的文章中做一个补充。在压力测试的过程中,需要观察系统的每一部分,例如观察数据库,还有观察代码及,看一下在系统所能承受的最高qps下,业务的瓶颈处在什么地方。以后如果需要提升系统瓶颈,可以从这个地方入手。一般情况,问题可能会出现在系统后面的数据库层面,也可能和代码机器相关,需要试对具体情况的分析而定。压力测试的机器,和线上机器应该做一个折算比例,应为线上机器一般和测试机器的配置不同,折算的比例*测试机的QPS,应该就是线上系统的QPS。可以用这个作为线上系统的一个性能评估参数,来指导以后业务的开展。压力测试,也可以自动化,做得方便易用,让研发可以自己测试,从而保证开发效率。 关于测试,根据我工作三年的经验,想到的就这么多了,关于jenkins 和 压力测试框架,我也只是用过,并没有研究过或者尝试过亲力亲为搞一套出来,所以目前没有太多经验,等以后有时间自己搞起来了,会补上相关的文章。有任何意见,欢迎留言交流。

后端系统上线流程

后端系统上线流程

工作这两年,一直是后端,经历过两家公司。我也从没有经验,到积累了一点经验。后端系统的上线,如果出现bug的话,影响会比较大。上线上出事故的,在程序员的行业中已经屡见不鲜了,甚至有过一些很严重的事故,并且,不止小公司有,一些大公司也会出现这样的事故。当然整体来讲,大公司出现问题的概率要远小于小公司,因为大公司因为业务规模较大,用户量大,所以上线流程控制非常严格,每个环节都尽可能的降低出问题的可能,所以整体来看,是不太容易出问题的。就算出问题,也不太容易将问题带到线上去。当然这样做的代价是,上线效率非常低,上线时间成本和沟通成本也较高,但和上线引起的损失相比,大公司一般会选择较低的事故概率。 而小公司,业务较小,更多的追求业务的发展,对事故的容忍度会更高,所以小公司一般都会采取更加高效的方式,当然这也意味着他们面临更高的风险。 下面简单讲一个比较完善的上线流程 代码测试,主要是研发自己测试,这个因研发的程度而异。 让 QA 测试要上线功能,确保上线之后功能符合预期,功能性验证 跑所有功能的单元测试,也叫回归测试,每个功能或者接口应该由自己的测试用例 上一个线上的机器,观察核心的监控,看有没有报错,指标验证,观察机器的QPS是否有变化,下降或者提高 代码的全量上线 继续观察系统监控 下面我们具体分析一下,为什么一个完整的流程会比较耗费时间。 代码测试, 研发自己测试代码,这个需要测试环境比较完备,要尽可能保证数据量。 QA进行功能验证,QA需要知道功能点。在一些公司,1、2也可能完全由研发负责,这样可以提高一些开发效率。因为研发最了解自己开发的功能,所以测试起来应该也能更好的抓住测试点。1和2都很依赖测试环境。要保证代码部署方便,测试环境的稳定。在可以保证研发素质的前提下,最好给予研发较多的权限,这样会比较方便,防止每一次测试调试代码都需要权限申请,这个非常麻烦,极其影响开发效率。 单元测试。这个是最重要,但是往往被忽略的一个环节。我认为在所有的流程中,这个才是减少问题的关键。如果这个环节做的好,那么程序上线可能引起事故的可能就会降低很多。这个是QE可以做的最有价值的工作。就是给尽可能多的业务接口写测试用例,让每一次上线的代码只有在通过这些测试之后才能上线,这样可以拦截下来很大一批低级错误,从而保证线上业务的稳定性。有必要设计一个单独的测试项目,专门负责这样的测试,和功能开发同步,或者尽可能和功能开发保证同步,把一些核心接口都包含进去,这样对不管是业务稳定还是以后项目的维护都很有帮助。举一个例子:新浪在升级php7的时候,仅仅用了几天时间,这就是因为他们的测试非常全,能对整个升级过程有把握,在很短的时间内覆盖系统的绝大部分功能,验证功能的正确性。 经过了前面几个过程,应该说绝大部分错误都会被拒之门外,但是有一些问题,可能需要监控配合,并且观察一段时间,一般是一个小时左右。如果你对接口性能降低了,那么你通过系统延迟的监控就可以看出明显的变化。所以,这个步骤虽然很少会遇到问题,但是也非常重要,尤其是你的修改可能影响系统性能的时候,这一项的执行就会变得更加重要。 如果上面的监控没有什么问题,那么上线吧。 上线后观察。上线之后,请继续观察监控,持续一个小时左右。虽然我们经理了一个完整的流程,已经可以避免很多问题了,但是难免还会有漏网之鱼,保持对线上系统的敬畏之心,是工程师的一种基本态度。 上面这几个核心过程的时间消耗。我们做一个简单的说明…

Read More Read More

Git 协作流程

Git 协作流程

git 是什么 git 是一个分布式的版本控制工具。为啥叫分布式的呢,通常来讲,版本控制系统都有一个共同的仓库,称之为远端仓库,有些控制软件例如svn会依赖这个远端仓库,如果你和这个仓库无法连接,比如你在一个没有网络的环境,或者你断网了,你就无法进行版本控制了,这个叫做集中式的,代表就是svn。而我们的git 是分布式的,好处就在于,虽然你没有网络,你无法访问远端的仓库,但是你仍然可以在本地进行版本控制。等你到一个有网络的环境之后,你可以把你的本地修改,同步到远端,这样就保证了你无论在何种情况下,都可以让git帮助你进行版本控制了。 我们再简单解释下版本控制这个词。如果你不是开发人员,你对这个可能不太熟悉,这也无可厚非。因为git开发出来就是为了给代码做版本控制的。但是,后面人们发现,用git 做文档的版本控制也是很方便的。所以现在,git已经不仅仅是开发人员的利器了,好多产品也会用版本控制工具来进行文档的编写。具体git如何方便文档的编写,我们下面就来举个例子。 假设你在一个团队中,你们小组有3个人,你们共同负责一个文档的编写。A负责TA部分,B负责TB部分的编写,C负责TC部分的编写,另外还要完成目录的编写。在一个没有版本控制的工作流程中,A完成了Ta,B完成了Tb,C完成了Tc,还有不知谁完成了目录部分。最后要汇总的时候,需要把A,B,C三人的文档收集起来,汇总成一个完整的文档。在这个过程中,加上这个小组的领导,想看一些每一部分的完成情况,只能联系具体的某一个人,让他们汇报一下完成情况。这样貌似也没有问题,事情也可以顺利进行下去,文档最终会顺利完成。好了,这是没有git的传统的写作模式下,我们的工作情景。 下面我们看一个利用git进行版本控制的工作情景。 首先,如果们熟练使用git,我们可以首先为我们的项目创建一个仓库,然后A、B、C三人都clone我们的仓库。然后在这个仓库上开始自己的开发。为了互相不影响,A,B,C三人会建立自己的分支,BA,BB,BC,在自己的分支上独立开发。在开发过程中,团队中的每个人都可以了解其他人的完成程度。并且在三个人都完成了自己的部分之后,可以很容易的将这三部分合并起来。完全不用找每一个人,让他把文档传给你,不再需要这些额外的沟通,和额外的合并工作,同时,文档的合并也会非常简单,就算有两个人同时修改了目录部分,合并起来也不会太复杂,比我们人工去维护文档会简单很多。我们只需要借用git的合并功能,git会很聪明的帮我们合并好,绝对可靠,高效。 用git开发,还会将你开发过程中的每一步都记录下来。如果你在最终版本中找到一个bug,顺着git的提交记录,你可以很清楚的知道这个bug 的由来,是谁引入的,这些都清晰可见。用git之后,一切都是透明的,如果有一个稳定的远端仓库,那么你的文档也很安全,就算你本地的文档丢了,你也可以不太费劲的将文档再clone下来。 所以,当我们在一个团队中工作时,一旦需要一些文档上的协作时,用git可以很大程度上提高我们的协作效率。 使用git进行版本控制 关于git 的入门教程,网络上已经有很多版本了,并且有一些也相当不错,这里我就不再重复造轮子了,在我的博客中,我不会从0写git如何入门,但是我会将一些我认为比较有用但是不为大家所熟知的关键的用法。 这里我先简单讲一下我学习git的历程。我对git的了解也是从0开始的,虽然我是计算机专业,但是在学校学习的过程中,并没有哪个老师向我们提起git过,更不会有人教过我们相关的什么。相反,我是从同学那里了解到linux,然后了解到git的。 首先当然是查资料,各种入门教程,都可以看一下。 其次就是实践了。可以注册一个git的平台账号。当然可以选github,但是给入门用户,我推荐coding.net 。这个是国内的,访2问速度比较好,并且创建私人仓库是免费的,这样可以方便我们实践学习。…

Read More Read More

SQL语句入门(Mysql)

SQL语句入门(Mysql)

一、理论知识 本文主要介绍一下mysql 的简单应用。首先介绍一些sql的基本语法,然后创建一个示例数据库,设计了一个学校系统的数据库,创建了数据表。第三部分以这个数据库为基础,示例了一些sql的简单查询语法。 一、install mysql-server download mysql-server https://cdn.mysql.com//Downloads/MySQLInstaller/mysql-installer-community-5.7.17.0.msi start your mysql-server , connect to your mysql server. 二、mysql关键字和基本的命令. mysql数据类型 int…

Read More Read More

工作这两年

工作这两年

我的大学 本科期间,沉迷于War3,经常逃课去打游戏,学习成绩一般,能勉强过关的那种。大二接触linux,之后就再也没有丢开过,花了很多时间去折腾。从桌面开始,从fedora到ubuntu,arch,再到ubuntu。在这方面花了不少时间。了解了linux之后,觉着linux的命令行才是真正的命令行,linux桌面才是真正的桌面,虽然很不稳定,经常被我搞崩溃无法解决又重新装系统,并且时不时还会遇到各种奇怪的问题,但当时觉着也没什么,遇到什么问题,就去找那个问题,直到解决问题。 比如,有时候我折腾了一晚上,就是为了让我的linux系统可以识别我的U盘。有时候会忍不住更新下显卡驱动,然后重新登录发现进不去桌面了,当时不太会,干脆重装,于是又来一遍。总之,各种各样的问题,花了好多时间,但那时候的我,好像并不觉得烦,一遍一遍得重复,似乎还有不少乐趣。事实证明,我那一遍遍的重复也是有点用的,慢慢得,经过多次折腾之后,我对linux也慢慢了解了,重装系统的次数也越来越少。折腾了一段时间只有,我逐渐意识到桌面其实也就那么回事,无非就是一堆配置文件,你知道如何配置了之后,它也就不再神秘。真正需要我花费心思的地方,是在写数据结构,学算法上,于是将更多的精力放在了写cpp上。其实,第一次认识linux就是从cpp开始的。那时候我还不知道linux这个东西,当同学在实验室给我展示了一个linux下的hello world 程序之后,我发现写一个cpp竟然也可以不用建工程,写一个文件就可以了,和vc6.0 给我的印象完全不同,相比之下,vc6.0 显得那么冗余臃肿。在linux上竟然如此简洁,给我的那种惊喜,在那个瞬间就将我的兴趣俘获了。之后,写cpp基本都会切换到我的linux系统上去,并且会看电影也会切换到linxu上,用vlc看,好像vlc播放的电影画质更好!!!大学期间的算法和数据结构,基本都是在linux写的。大四的实习,宣布着我程序员职业生涯的开始。刚开始的工作,就给我分到了后端组。发现学校里的学习还是帮了我不少。 码农生涯的开始 短暂的实习结束,从天津来到北京,进入H公司,下面简称H。同样是做后端,除了没怎么用过PHP,但对服务器和mysql这些东西我基本都是熟悉的,所以进入状态也很快,大概过了一周,我就可以熟练的写业务代码了。在框架中编写代码,有一个缺点就是大部分代码都是模仿,所以并不难。也没有什么挑战。后面,需要做运营后台。和接口不同的是,这里要求界面,需要用web前端相关的。被迫要写一些前端页面相关的东西,刚开始做的那段时间,有一些界面,确实是不小的挑战,然后就是各种补,各种查,各种加班,磕磕绊绊搞出来的东西,一来长得其丑无比,二来烂的就像一坨..,三来写法落后的一逼,但是那时候我们团队没有人擅长,我做出来的东西,我也觉着不太行,就勉强可以用,当时大家的心思都在集中在客户端,后台的东西,差不多能用就可以了,大家也表示可以理解。后面,有反馈,说整个页面刷新极大的影响运营效率,我才学会了ajax局部更新数据,将一些要紧的地方更新了下。慢慢的,我也跟着了解着,学习着前端。几乎同时,我还负责了我们推送系统的构建。当时邻居团队的项目已经有了,直接送给了我们,因为是python做的。我之前懂一点,于是这个项目就给我了。但其实我的当时的python水平就比helloworld高一点。代码都有了,看不懂查查不就懂了。就这样,我接手了我们的push系统。这个项目,为我们的产品服务了大概18个月,18个月里,和这个项目相关的bug出过很多,其中有些是我的锅,有些不是我的锅。18个月里,代码也改了好多,从最初接手,到最终的稳定版本,除了骨架,已经没有太多的相似之处。 记得刚去H上班的第一天,到7点了,是公司的正常下班时间。然而我发现旁边的人几乎没有动身回家的意思,然后我满脸疑惑的问了下我的上司,上司这样对我说:”我们这里是7点下班,有事可以先回家,没事可以再呆一会儿!”.然后我就乖乖的和他们一起出去吃晚饭了,吃完晚饭,大概到9点,开始有人走了,我也跟着走了。那时候,我刚来北京,新中关购物中心和丹棱街对我来说还是完全新鲜的。下班后,经过丹棱街去往公交车站的路上,看到中钢国际的大厦,和microsoft的大楼,感觉北京确实好。期待着几年后的自己,感觉以后的日子充满希望。 在H的第一年,大家都很有拼劲,那时候最是辛苦,但是谁也不觉着累,虽然我加了很多班,但是技术上也学会了很多,好多以前不熟练的东西,已经可以很熟练了。 第二年,事情的发展就慢慢偏离大家的预期了,显示我们的带头大哥CR,离开我们团队了,没有任何通知的走了。没过几天,就来了一个新的上司W。后面又是频繁的人员变动,又有几个老同志们离开了,越来越多的新面孔。新来的上司也不太适合大部分人的胃口,团队合作并不是太理想。并且团队的组织结构也变得厉害,这个我们伴随着一起成长的团队,越来越让那些老同志们觉得陌生。在16年的互联网合并浪潮中,最终ML也未能幸免被MG吞了的命运。我最明显的感受是,又有好多人离开了,新办公室,又多了好多新面孔。 这一年的业务进展和我的技术一样,可以用同样的二字形容—缓慢。 其实技术方面的挑战,真没什么。最大的挑战我觉着就是事情太多,虽然都没什么技术含量,但是事情多呀,多到让你没有周末,周末在家里也不能安宁,一会又有问题,在群里@你,你就不能不看。那时候的周末,应该只比工作日好一点,唯一的好处就是可以在家办公。就这样过了大概2年。7月中旬,决定辞职,8月离职。 换工作 辞职之后,便开始找工作,开始陆续面试。当时有几个热心的猎头,一直在给我热心的推荐工作机会,我也比较配合的去面试了,然后面试结果惨不忍睹,众多的机会无一命中,东笨西波半个月之后,我尴尬的保持了失业状态。并且每一次面试失败,都会加重我对自己的怀疑,连续失败了半个月,我的压力已经达到了我能忍受的极限,所以我决定休息半个月,这样我就不会因为压力太大而崩溃了,😁😁😆机智的我。在我休息的半个月内,我开始整理自己的这里那个年学过的东西,开始搞自己的blog,于是有了下面那张知识体系图。还有了我的第一个blog。同时,我还开始刷我的leetcode了,通过半个月的努力,我刷了一些题,准备了一些面试题。在休息了半个月之后,我又开始找工作了,这时候再也没有猎头给我推荐了,并且那段失败的面试经历让我隐隐的觉到,猎头的推荐动机和我的目标还是有些不一致的,所以我不再怎么配合给我推荐工作的猎头了,我开始自己找工作了。我在100offer上注册了我的信息,然后开始了新的尝试。这次就完全不一样了,似乎是我半个月的努力起了作用,我的第一个面试,我的表现还不错,第一天就拿到了offer,并且待遇还不错,完全没有打压我待遇的意思。然后我试了后面的,又陆续拿到了其他的offer,待遇也还不错。悬了将近一个月的心终于放下来了,在面完了约好的面试之后,之后的几天基本上在犹豫自己该选哪个机会—决定并拒绝别人其实也挺困难的。 新工作 在犹豫了很久之后,我选择了最先给我offer的公司。当时觉着,这里比较符合我的预期,我希望能找一家不那么忙的公司,可以给我较多自由时间的工作,这样我可以有时间自己学习,有更多的时间完善自己的知识体系,我的技能还需要继续完善,还需要继续学习。有了H公司的经理之后,就再也不太想去创业公司了,因为事情太多了,容易成为一个纯输出,职场初期还行,但是不能一直这样,时间久了,自己的成长容易受到限制,毕竟技能的成长,需要自己投入学习,投入时间。入职之后,发现这边完全符合我的预期,项目上不会那么火急火燎的上线,做东西也不会那么随意,至少要有设计方案,方案通过之后才会开始做,对我来说,都是很宝贵的学习机会。管理方式上,也比较自由,做事为主,😁,快乐的成长中…😁…