软件测试工程师的工作内容?

如题所述

以下是作为一名测试工程师的日常工作:阶段:编写测试计划,测试用例、测试缺陷报告,并执行测试用例,搭建Windows测试环境,熟练使用Bugzilla提交软件缺陷报告
至于为什么嘛,当然要一步步来的,要有计划才能执行啊,大概是这样吧
^_^
使用测试技术及工具:白盒测试和黑盒测试
Loadrunner、Winrunner
能够运用边界值、等价类划分法、因果图、状态图、大纲法等测试方法设计高效测试用例
软件测试工作总体流程图:
详细测试步骤:
1.
书写测试计划
2.
审核测试计划,未通过返回第一步
3.
书写测试用例;
4.
审核测试用例,未通过返回第三步
5.
测试人员按照测试用例逐项进行测试活动,并且将测试结果填写在测试报告上;(测试报告必须覆盖所有测试用例)
6.
测试过程中发现bug,将bug填写在bugzilla上发给集成部经理;(bug状态NEW)
7.
集成部经理接到bugzilla发过来的bug
7.1
对于明显的并且可以立刻解决的bug,将bug发给开发人员;(bug状态ASSIGNED);
7.2
对于不是bug的提交,集成部经理通知测试设计人员和测试人员,对相应文档进行修改;
(bug状态RESOLVED,决定设置为INVALID);
7.3
对于目前无法修改的,将这个bug放到下一轮次进行修改;(bug状态RESOLVED,决定设置为REMIND)
8.
开发人员接到发过来的bug立刻修改;(bug状态RESOLVED,决定设置为FIXED)
9.
测试人员接到bugzilla发过来的错误更改信息,应该逐项复测,填写新的测试报告(测试报告必须覆盖上一次中所有REOPENED的测试用例);
10.
如果复测有问题返回第六步(bug状态REOPENED)
11.
否则关闭这项BUG(bug状态CLOSED)
12.
本轮测试中测试用例中有95%一次性通过测试,结束测试任务;
13.
本轮测试中发现的错误有98%经过修改并且通过再次测试(即bug状态CLOSED),返回第五步进行新的一轮测试;
14.
测试任务结束后书写测试总结报告;
15.
正规测试结束进入非正规测试,首先是ALPHA测试,请公司里其他非技术人员以用户角色使用系统。发现bug通知测试人员,测试人员以正规流程处理bug事件;
16.
然后是BETA测试,请用户代表进行测试。发现bug通知测试人员,测试人员以正规流程处理bug事件。
温馨提示:答案为网友推荐,仅供参考
第1个回答  2010-06-05
1. 引言

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

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

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

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

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

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

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

2. 测试大戏开演

时间: 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

工作场景:

下班

画外音:

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

3. 测试大戏背后的故事

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

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

测试的变化性

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

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

确处理的工作挑战。

多任务同时处理

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

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

及时交流

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

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

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

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

客户才是万能的!)。

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

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

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

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

效)。

4. 结束语

有人说,测试很枯燥,而且“一点技术含量都没有”。也有人说,软件测试大有前途!现在中国确的不是软

件编程大师,而是软件测试大师。这些观点孰是孰非,您请自己琢磨。不过既然从事了测试行业,还是将它

做好为上!本回答被提问者采纳