2. 这个自测范围和内容谁提供 ?每个提测版本,研发都自测哪些内容 ?3. 测试准入标准是什么 ?自测未通过的,如何处理 ?
一般来说,都是需要「研发自测」的,甚至有些项目,研发自测完,就可以直接上线,不需要测试同学的参与 。
测试会根据自己的任务将对应的需求拆解功能点,然后输出冒烟测试的测试点,放在confluence平台(此处平台,很多,比如 TAPD / xmind文件也行 / Excel放在svn也行,方式不重要,团队内部协商即可),这个文档作为研发自测范围和自测内容(至于这个文档是否需要经过评审?最好评审一下,跟开发、产品碰一碰),测试的功能点可以写粒度也是比较大的点。
每一个提测版本,研发人员负责自测自己开发的功能点即可,保证主流程没有问题(基础的业务联调,那是必须的,否则,冒烟都通过不了) 。实际跟N多测试同学沟通后,很多公司,是没有研发自测的,导致的结果就是,一个版本,提交了上百个Bug,非常恐怖 。对于,一个版本,总共就几个Bug的同学,是无法理解的 。
提测版本质量烂、Bug多,效率低,且累,而且经常加班 。写Bug要时间、录Bug要时间、改Bug要时间、验Bug要时间、重复写Bug要时间 ...
1. 手动执行冒烟测试用例,且都测试通过(打包时,自动执行新业务的接口自动化测试,以及已有业务的自动化接口测试,通过后,准入 。)
版本打回,邮件通知全团队,待提交新版本再测试,上线时间,顺延 。
2. 实在搞不定的,参考下面的“通过标准”,最后的做法 。
注:如下这段,来自妹纸“紫芸”,在「软件测试圈」的主题 。
近期上线的某个项目并未达到测试组管理规范设定的通过标准,但因市场等各种原因,算妥协发布了正式版。
对于这类项目的报告出具等很费心,因为遗留问题实在太多,不出具报告对自己不利,出具报告有违背起初设定的通过标准。
什么才是测试通过标准?以往常有听过领导问:“这个项目怎么就是测试通过了?”也常有开发问:“项目怎么才算通过测试?”
一系列的疑问,最好的解决方式是什么?
重新审视了测试通过标准,感觉本身有缺陷:太过完美,看似可量化,站在不同角色看,实则无法很好量化,如何优化测试通过标准?
2、测试输出结果与预期输出之间的符合率:95%以上; 4、缺陷处理情况:缺陷等级非常重要、重要(P0、P1)需全部关闭,一般、建议性缺陷<10%。开发和测试有争议的缺陷需要经项目小组讨论后决定是否需要修改(拉上产品经理、项目经理、业务方),若经讨论后确认可以忽略不改或因其他原因要在以后的版本中实现,则本次测试可以认为通过(这里非常重要:遗留的问题,一定要跟团队讨论,确定可遗留到下个版本,而且要在测试报告中,注明已知问题 & 风险)。
End 。
最近,很多同学,咨询此类疑惑,希望此文的内容梳理,对你有参考作用 。
注:此文内容,摘自「软件测试圈」
004 最后
全年365天,每天24小时。其实,老徐都没闲着。
每天都在星球「软件测试圈」,解答测试从业者遇到的各类问题 。解答问题,是一个双向成长的过程 。
如果你也有问题 ,进星球,提问、讨论、交流 。
注:如果支付不了,无法加入的,微信957863300找老徐 。