赞
踩
1.需求评审前,提前进行需求熟悉阶段,逐一分析需求点,做好准备,相关需求疑问点列好清单,带着问题去参会。
2.产品宣讲时期,就算过程有问题,不要试探打断产品的宣讲,一是节约时间,二是不礼貌,等产品将一个模块宣讲完毕,开始带着你的问题,开始你的表演,分析给项目成员听,并提出改进建议。
3.当需求有问题确认需要修正,或需进一步跟业务确认再做定夺的,做好标记,并提醒产品,做好会议记录。
4.开发是个直男~一旦进入技术凯旋,那非得争的明明白白的,所以宣讲时期如果开发进入技术凯旋,在适当时期提醒产品,进行控场,有效的控制时间,接着宣讲其他模块业务流。
5.需求评审完后,项目群推送需求评审会议记录点,周知各位目前的版本的疑问点以及修改点,并提醒产品进行下次需求确认会议时间或者用例评审,这个会议也可以由测试主持。
6.如果实在受到时间管控,需求评审会议中依旧存在不清楚的逻辑或者需求,那么就需要在用例评审时细化到自己负责的每个模块的每个功能,尤其要确认业务上的关联场景,并做好记录在用例评审会上提出由产品确认。
项目中测试计划,作为测试我们该如何做?
首先企业项目开展,整体测试计划是由版本测试负责人去进行整体的测试计划布局,将版本拆分细化到每个指定的测试人员,这里涉及到人力时间成本以及项目进度风险管控
再来说说那么我们初级测试有必要写这个测试计划吗?答案是肯定的,因为你将来可能也会当上测试负责人等相关职位
1.例如项目第一版本开发清单如下
2.测试计划制订如下
3.总结
具体内容基本就是围绕测试范围、人员、时间、测试策略、测试人员分工、测试轮次、测试风险等重要内容
三、提测期间,开发测试必做的一些事
首先回顾一下产品的四个阶段:①需求评审,②用例评审,③开发阶段,④测试阶段,⑤上线阶段
提测的定义:提测代表产品按照需求文档的开发以及实现,由开发阶段已经进入的测试阶段
提测前后必须要做的几件事
1.单元测试
单元测试具体包含哪些方面:https://jingyan.baidu.com/article/0a52e3f4710535bf63ed7263.html
2.联调测试
将自己负责的部分功能与其他人员负责的功能相关联模块,进行端到端的联调(这是很有必要做的一件事情,当开发拒绝你的时候,你一定要说服他,因为个人负责的模块做的再完美是没用的,产品是一个整体的体验过程)
端对端联调测试的作用:整体性的验证业务链的接口数据问题、UI问题、体验性问题、兼容性问题等
另外一个小窍门,在联调阶段也可以叫开发到测试环境进行联调,可以验证环境是可以正常跑通,避免提测后出现环境问题
3.冒烟测试
开发拿着测试人员在提测前已经写好的主流程测试用例,进行验证每天case是否通过(冒烟测试用例一般都是功能主干流程测试case,如果冒烟测试用例不通过可以直接将转测的版本打回开发,让他二次开发解决相关问题,知道冒烟用例通过为止)
4.需求改动及时确认修正
任何项目在提测前,肯定会有很多的需求改动,因为需求宣讲时只是在我们脑海里构思,而开发提测阶段此时在实际实现或者联调测试阶段,都可以发现架构设计、功能业务需求不合理等相关问题
此时就要及时的拉上产品、架构师等相关人员仔细确认,有改动的需求点及时修改需求文档,周知到大家,改动的点,需要严格执行上面的三个测试阶段,通过方可提测
5.开发已经准备好完善的接口文档
项目测试周期宽松的情况,可以提前做接口测试工作,此时必须要有一份完善的接口文档
6.开发已经清楚罗列提测版本、范围、以及相关风险事项清单
这点主要是对我们的项目相关人员负责,清晰的知会PM、PRD、测试提测范围,将工作做到极致
1.在提测阶段,我们为什么严格开发去这么做?
提前发现问题进行解决问题、不要等到测试阶段才发现该问题,节约人力成本,提高转测质量,赢得测试的尊重,团队人员关系更加融洽
当你们碰到那种提测版本,主流程跑不通,页面打开错乱,此时作为测试人员的你,相信那天的心情都不会好了,反而还对开发有一定的心里成见
2.流程是人定的,约定三章后,就要严格执行
流程完毕不去严格执行,只是一个摆设,所以作为测试的我们有义务在周例会进行宣导、善意的提醒开发去严格执行,如果有个别同事几次出现嘴上说执行,但是实际每次提测质量还是很差,可以先找开发经理反应情况。
去期待陌生,去拥抱惊喜。
下面这些是我的收集和整理,这些资料,对于【软件测试】的朋友来说应该是最全面的仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你
我的学习群:644956177 群里有技术大牛一起交流分享~
关注【程序媛木子】微信公众号里海量资源免费获取,
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。