TA的每日心情 | 擦汗 5 小时前 |
---|
签到天数: 1047 天 连续签到: 5 天 [LV.10]测试总司令
|
软件测试人员在测试不同的阶段做不同的事的,总的分为以下几个阶段:
1.项目开始之初,也可以是一次迭代开始之初
这个时候每天都是以熟悉本次项目或本次迭代功能模块需求为主。
方式:一般就是看文档,有时就是看一天文档,或参加不同的评审会,根据不同人理解需求方式的不同,我喜欢用XMIND梳理测试点需求,我不管做什么事都喜欢用笔去整理一番。
这时阶段主要是理解需求,分析功能模块的业务流程,尽可能将测试点梳理得更细,在梳理过程中如果遇到不理解,或需要做的需求与以前的需求逻辑不符时,可以先找产品经理讨论,并确定,方式可以是当面讨论,也可以以邮件的方式确定,推荐以邮件的方式确定。
在这个阶段与团队配合的事情:如果项目流程完善的团队,这时一般会由产品经理开始组织需求评审,也可以用通俗的话讲就是过需求,以前公司是由SE组织需求评审,然后开发人员组织评审Story,目前公司是由开发人员组织过,由于不同人组织关注的重点不同。
2.项目中前期
这时阶段软件测试人员主是写文档。
因为前期已经将需求的范围和测试点整理OK 了,那这个时候基本就是输出这些东西为主,输出的文档测试人员称之为测试用例。
方式:一般是用excel写,有可能一连会写上几天的测试用例,我一般一天可以写二百多条测试用例左右。
如果测试用例写完之后,这个时候测试人员会组织测试用例评审,可以用正式的会议形式组织,也可以以邮件的形式发给开发和产品评审,如果是以邮件的形式,那一定要跟踪,因为大部分开发人员都不喜欢看邮件,所以可以用即时通讯提醒开发人员和产品经理去评审测试用例。
这个阶段开发人员一般都在编码,也是非常忙的时候。
测试用例并不是一定要用excel写,像我们现在项目测试用例大部分都是用XMIND写,我现在也习惯了用这种方式写,用XMIND写更能发散测试人员的思维。
发现现在很多公司都不喜欢写测试用例,觉得太花费时间了,也可能是由于项目紧的原因,但我觉得测试用例在执行测试之前一定去有这样一个过程,虽然花费时间,但是在执行测试时只需要根据前面梳理的测试点去执行就OK了,同时不容易造成漏测,就算公司不要求,我在测试之前,一定会做这样的事,无论项目时间是否紧迫,这也算是成为习惯了。
3.项目中期
这个阶段是软件测试人员最辛苦的阶段,那就是测试执行阶段。
方式:根据测试类型的不同,执行测试也有所不同
以前做功能测试时,那天天就是前端页面测试软件的功能,界面以及软件体验性测试,现在做接口测试,执行阶段就是天天通过工具调用各种接口,测试各类接口传值、取参、返回等等测试点。
这个阶段不仅要测试,还有一件非常重要的事情那就是提交bug。
在缺陷管理工具上编写BUG,和开发人员讨论BUG,复现BUG,跟踪BUG的处理流程。这个时期需要做的事情很多,不断地测试,不断地与开人员沟通,复现BUG。
测试到了后期就对前期提交的BUG,进行回归测试。
软件测试人员不仅要有发现BUG的能力,也需要有分析BUG,定位BUG的能力。
定位BUG可以通过查询数据库、后台日志或者查看源代码等不同的方式去分析和定位。
4.项目后期
这个阶段测试人员主要做的事有写测试报告和总结。
执行测试完成之后,测试人员需要对本次测试下一个结论,到底是测试通过还是不通过,这时软件测试人员需要给测试结论,但不能就简单的一句话给开发说本次项目测试通过了,可以上线,或者说本次项目测试不通过,BUG还有很多,软件质量有风险。
现在所有事情都讲究依据,那么软件测试也需要,测试人员需要给项目其它成员提供测试结果的依据。
测试报告中一般包括测试用例的执行情况、从各种维度分析缺陷、遗留缺陷等方面分析测试情况。
一般项目测试完之后,软件测试人员可以利用项目间隔总结项目,一般是输出业务需求为主,方便其他测试人员查阅。
以上就是在不同阶段软件测试人员大致所做的事情,但这些不是绝对的,希望能给一定的帮助。
|
|