互联网公司的软件测试工程师们都在干什么?

如题所述

互联网和传统行业的不一样,变更多,迭代快,测试工程师们能大噶说一下吗?还有,怎么样才能提高自己的价值呢? 精彩答案: 会员jijiting: 抛砖引玉,了解皮毛而已。 测试要做的是,检测和监控产品的质量,提高测试效率,优化测试流程,改善评测办法,为产品的改进和上线提供保障。 测试工程师大概在做: 1、功能测试:包括和开发、产品确认产品需求,做测试计划,设计测试用例,做测试用例评审,做冒烟测试或者准入测试,执行测试用例,多轮迭代测试,一直跟踪到上线之后的回测,以及看下用户的反馈,确认测试过程中有没有遗漏(算作是KPI的一部分)。在这个过程中,可以反思自己的疏漏,完善测试的流程,完善测试的检查点,增加各种类似的测试,思考可以自动化的部分并实现。 2、自动化测试:对界面、接口或者后台进行自动化的测试,在测试的前期可以保障基本功能的正常,在测试中期可以保障开发的修改没有对产品质量引起严重问题,在测试的后期可以做上线前的回归测试,上线之后可以作为日常的监控。自动化的测试在不同平台、不同操作系统、不同浏览器下使用不同的工具,采用不同的框架,所以在没有这些的时候需要调研目前行业内比较流行的解决方案,寻找到适合自己产品的方法来解决问题。之后开始设计测试用例,并进行实现。产品的改进过程中需要进行维护,保证随时都可以通过。 3、性能测试:测试产品的性能,在多大的压力下可以满足当前预期的用户请求。需要使用各种压力工具,做压力文件,安排与线上一致的测试机器或者精简后的环境进行测试,对测试出来的数据进行分析,确认现有的系统是否存在问题。貌似环境部署可能是个问题,所以公司里面会有大牛做一些自动部署的工具,甚至会开发出一些独立的平台来完成多台机器的部署工作,可以节省很多的时间。测试出来的数据跟产品以及开发人员确认,也可能会找到一些方案来解决。 4、测试开发:相对来说开发的工作比一般测试工作要多一些。开发一些自动化的测试的平台,比如一些评测系统,供人工评测试用;设计一些测试框架,来满足日常自动化以及性能测试的需要。制定持续集成测试的平台和方案并且实现,结合自动化的测试实现人工测试之前的自动化测试实现,对开发的代码进行监控,跟踪并尽量帮开发改进产品质量等等。这块我比较白,还在仰视阶段。接受其他测试人员的需求,开发合适的工具来提升整体测试效率,改进测试方法。 5、测试工具以及测试理念的推进。测试在大多数人看来还是比开发要差一些的,测试工具还可以,能够直接快速的反映出测试人员的价值,但是更多的功能测试、性能测试还需要跟开发去沟通,让他们意识到测试的重要性,但是最重要的还是要提升测试自己的工作能力,尝试影响开发人员并且和开发人员一起,最终提升产品的质量。 6、测试人员还是要多学习吧。要是觉得测试是个人都可以做的就别来趟这个浑水了。 会员 姜雷: 我当时是做实习生,实习生的时间比较自由,也没有具体的产品、KPI捆绑,所以我做的主要是没有具体产品关联的长线项目。比如说自动测试平台的搭建,测试自动化辅助工具的开发,原有测试脚本的集成、改写、自动化等工作(比较杂,有些随性,我甚至写过单元测试——这个应该是dev做的)。还有就是一些具体的模块覆盖率的提高、测试自动化的探索。 具体到身边的入职同事们,工作就比较杂了。忙起来的时候,是黑盒、白盒;自动化、手动的都要做。项目上线之前的功能、性能、压力测试等都是必要做的,由于目前国内互联网发展较快,项目改进迭代的压力很大,所以有的时候感觉身边的同事都被项目纠缠得忙——这就是为什么上下一心都觉得自动化很重要。 当然,还有些人专门做测试工具的开发和测试流程改进的探索,我当时所在的部门也开发了很不错的自动化测试工具——这应该是我接触过的最接近开发的测试开发人员了。 我实习的组测试人员比较主动,去做了一些项目敏捷化的探索,还主导了项目的敏捷化,但是开发人员那边跟进得并不是很积极——我个人认为这个应是开发人员主导的,而且整个团队都参与进来,各个人员的角色需要有交叉——可惜我在实习期间没有体验到这些,这个在形成了一定的规模的国内公司估计很难改变。我实习结束的时候,有些组在流程上已经非常敏捷、自动化了,但是毕竟是上线的产品,自动化的初期肯定有一定的阵痛,估计现在应该好多了。 另外,谈谈我个人的一些感受,如果专门做测试的话,我觉得最大的问题就是成就感的问题。你做的似乎永远只能是内部使用的东东,永远不会成为呈现在用户面前的产品(gtest等测试框架产品除外)。当一个项目上线以后,你得到的relief多一些,但是成就感相对少一些。 我只是从实习生的角度谈的。
温馨提示:答案为网友推荐,仅供参考
第1个回答  2020-12-10

软件测试工程师:软件企业中的质量管理

第2个回答  2021-09-10
找bug,找bug,找bug,和开发对战,和开发对战,和开发对战。
回归主题,软件测试这个岗位吧,现在很火,转行的人也很多,也有不少人有疑问,这个岗位到底是干什么的,为什么会有这个岗位。如果想要了解的话,最简单的办法就是,上企业招聘网站上,去看岗位JD,上面一般都会有介绍岗位工作内容,以及你需要掌握的技术是什么。
简单来说呢,这个岗位的存在就是来找bug的,一款软件,不可能开发出来之后就能直接交付,里面肯定是有不尽人意的地方,比如一款游戏软件,为什么要经常更新,为什么会有补丁,假如这个软件经常闪退,经常卡,经常这了那了的,你还会玩这个游戏吗?
所以在软件开发伊始,测试工程师就要不断去找bug,看看有没有什么问题,以保证软件质量、正确和安全。测试工程师就等于是软件的质检员了。所以基本上每天的工作就是在找bug,找到之后,告诉开发人员,但是软件嘛,毕竟是开发的“亲儿子”,免不了会“对战”。
所以,测试工程师是在做什么呢,核心就是找bug。
第3个回答  2016-07-22

    引言

    软件测试成为最近 IT 行业的“香饽饽”,引得很多人对软件测试跃跃欲试。可是软件测试的门槛并不低,

    对于没有软件测试经验的新人而言,如何尽快转入测试工作中去呢?

    了解软件测试都做些什么,具体过程是怎么进行的,可以有助于对软件测试进行初步了解,尽快进入测试工

    作角色。但是关于软件测试的工作流程,各种现有书籍和文章往往都描述的非常复杂,充斥着不少测试术语

    ,使测试初学者望而生畏。

    现在让我们换一种角度看看典型的软件测试是如何进行的,暂且把软件测试过程看作一场大戏,主角就是测

    试工程师,按照时间顺序记录软件测试工程师一天的工作场景(假设正常工作时间 9:00 到 18:00 )。

      测试大戏开演

    时间:

    9:00

    工作场景:

    启动工作计算机,查看收到的电子信件。

    画外音:

    查看收到的电子邮件(哇塞,这么多电子邮件!),理解当天的测试工作的内容和要求。

    测试工程师至少配置两台计算机:其中一台是日常工作用,例如,收发电子邮件等。另外还有一台软件测试

    用的计算机。

    时间:

    9:10

    工作场景:

    回复电子邮件。

    画外音:

    回复电子邮件。如果对于安排的测试任务和要求存在任何疑问,请在回复电子邮件时列举出来。如果任务明

    确,回信中可以简单的说明理解测试任务了,按照测试任务要求进行测试。(正好今天有一封电子邮件分配

    了测试任务 A ,而且任务明确,测试文档等完整。)

    电子邮件有不同的优先级,任务非常紧迫的电子邮件应该优先处理,尽快回复。(面对多封邮件保持镇定,

    分清哪些邮件需要马上回复)

    并非全部的电子邮件都需要回复(抄送给自己的邮件和一般通告等不需要回复)

    时间:

    9:25

    工作场景:

    启动用于测试的计算机

    根据测试要求配置操作系统、安装要测试的软件

    根据测试用例执行测试任务 A 。

    画外音:

    测试一般需要按照测试指导文档和测试用例进行。(软件测试可不是盲目的乱测一气的呀!)

    很多软件的测试要求在一个“干净”的计算机上测试(提示:干静的计算机是仅安装了操作系统,没有安装

    其他应用程序的计算机)。

    在进行正式测试前,需要阅读测试文档,明确测试任务(这些测试文档你找到了吗?是最新的测试文档吗?

    )。

    时间: 11:00

    工作场景:

    执行软件测试,书写软件测试 Bug 报告

    画外音:

    按照测试要求,尽量多找出软件的 Bug 。(什么破软件,能找出这么多 Bug ! 反过来想,软件如果没有

    Bug ,我们测试工程师不就失业了吗!)

    根据发现的软件 Bug ,按照客户要求写出每个 Bug 的报告(要书写明白,否则客户事后会要求你重写,很

    费时间,也影响公司的测试质量,是否很没有面子?)

    时间:

    11:30

    工作场景:

    报告测试执行中的遇到了问题

    画外音:

    如果测试用例的步骤不明确或者测试的软件不能成功安装,无法进行下面的测试,应该及时向测试负责人报

    告,等待答复后进行测试。(重大问题,切莫瞒报,也别主观想当然地猜测!)

    如果某些测试步骤不明确,但是可以暂时跳过,请向测试负责人报告,并且继续进行下面的测试。(灵活处

    理,合理利用时间,时间就是金钱!)

    时间:

    12:00

    工作场景:

    查收和回复新邮件,新邮件又来了一个新的测试任务 B ,而且要求紧急处理。

    暂停测试任务 A ,进行测试任务 B 。

    画外音:

    测试过程中,要主要定时查看是否有新邮件,特别是那些要求非常紧急的任务。(重要任务一定要优先处理

    ,否则就是工作失职)

    如果新任务比较紧急,应该中断当前的测试,接着执行新任务。(为什么计划总是没有变化快,可是现实就

    是这样。)

    时间: 12:30

    工作场景:

    午餐、休息

    画外音:

    阳光、午餐、休息,美!(禁止在办公室玩任何电子游戏,办公室不是娱乐场所!)

    时间:13:30

    工作场景:

    查收和回复新邮件

    画外音:

    真幸运,没有其他新任务。

    继续上午的任务 B 。

    时间:14:30

    工作场景:

    完成新任务 B ,向测试负责人提交任务 B 的测试结果

    画外音:

    完成任何任务后,需要向测试负责人发送任务完成的电子邮件。(这一点很重要的,否则你做的工作再多,

    测试负责人也不一定很清楚)

    提交任务的电子邮件中,应该写明任务是否全部完成,存在什么问题,测试结果存放在什么计算机的哪个目

    录中。(想象测试负责人需要你提交哪些内容,最好在一封信中交待明白,完整,清楚,条理分明)

    时间:

    14:40

    工作场景:

    发送测试任务 A 不能按期完成的电子邮件

    画外音:

    由于执行了新测试任务 B ,使得测试任务 A 不能按时完成,应该及早向测试负责人发送电子邮件。(如果

    你不主动说无法按时完成任务 A ,测试负责人就默认为你能够按时完成。而如果到了完成任务的最后期限

    ,而你突然向测试负责人说任务还没有完成,那么我可以很负责任地告诉你:测试负责人将会很生气,后果

    很严重!)

    得到测试负责人的答复后,继续执行测试任务 A 。

    如果客户要求必须当天完成测试任务 A ,可能要做好加班准备(苦恼 … )。或者请测试负责人将一部分

    任务分解给其他测试人员执行(呵呵,谢谢兄弟们拉我一把 ... )。

    时间:14:50

    工作场景:

    继续执行测试任务 A 。

    画外音:

    寻找软件 Bug (这是主要任务之一)

    书写 Bug 测试报告(这也是主要任务之一)

    时间:

    15:30

    工作场景:

    查收和回复新邮件

    画外音:

    没有新电子邮件,呵呵!(最不喜欢在测试工作中,经常有邮件来骚扰!)

    继续执行测试任务 A 。

    时间:

    17:00

    工作场景:

    参加测试小组内部会议

    画外音:

    经常在测试过程中,测试小组内部会召开短暂的会议。(交流很重要的,倾听和发言一个都不能少)

    会议内容一般是测试过程中遇到的问题,以及可能的解决办法,也包括测试进度是否与测试计划保持一致。

    时间:

    17:30

    工作场景:

    发送当天任务完成情况的电子邮件

    画外音:

    当天任务完成情况的报告应该在下班前尽早发送给测试负责人,以便得到及时回复。

    总结当天测试任务完成的情况(全部完成还是部分完成)

    测试遇到的需要测试负责人或者问题客户帮助解决的问题(遇到问题一定要反映,不要什么问题都自己扛!



    给出当天处理 Bug 的数量、类型和存放位置(确保测试负责人能很容易的找到这些测试结果吗?)

    时间:17:45

    工作场景:

    整理当天的测试文档,

    做好备份

    个人总结

    画外音:

    备份当天的测试结果(有备无患!)

    总结测试遇到的问题和学习的新知识(好好学习,天天向上!)

    准备第二天的测试任务(未雨绸缪)

    时间: 18:00

    工作场景:

    下班

    画外音:

    如果不需要加班,按时回家,爽!

     测试大戏背后的故事

    上面的测试场景描述基本上反映了软件测试工程师的工作情形,但是由于测试工作的复杂性、琐碎性、变化

    性,实际测试过程将是不断变化的。

    测试的变化性

    对于软件本地化等外包测试,测试过程和测试要求因不同客户而异,即使相同客户的不同项目,也会有些变

    化。另外,测试所用的测试计划、测试用例、测试 Build 版本经常变化。这是对测试工程师需要面对和正

    确处理的工作挑战。

    多任务同时处理

    软件测试工程师在一天的工作时间里,可能需要做多件事情(例如,测试负责人可能中间会安排新的任务)

    ,正常测试过程经常被中断,对此需要有相应的心理准备。

    及时交流

    测试过程很少是一帆风顺的,特别是不熟悉的新软件,或者测试用例没有表达清楚。这时除了自己学习和思

    考,还需要向测试组的其他同事请教。如果问题仍然没有解决,请及时向测试负责人反映情况,寻求帮助(

    提示:测试负责人积累了软件测试经验,一般问题都可以搞定,但是测试负责人也不是万能的,他们也有很

    多不能解决的问题,但是他们有“杀手锏” — 向客户的测试负责人寻求帮助,由于源语言是客户开发的,

    客户才是万能的!)。

    电子邮件是主要的交流方式

    测试过程不要一味地在测试计算机上做下去,要经常在日常工作用计算机查看和回复电子邮件,以免耽误了

    更重要的任务。除了电子邮件之外,也可以打电话和即时网络交流工具( MSN 等),或者面对面与同事交

    流(提示:对于复杂的问题,与其来回发送多封电子邮件还说不明白,还不如打个电话或者面对面交谈更有

    效)。


第4个回答  2019-08-08
注意bug啊,如何发现,如何解决等都是测试要做的事情,对于这些细节源码时代就有一个总结,里面的内容还是很详细的。
相似回答