其他分享
首页 > 其他分享> > 准入标准、测试通过标准、上线标准

准入标准、测试通过标准、上线标准

作者:互联网

曾经,在星球「软件测试圈」,问了4个问题:

1. 你所在公司,是否有研发自测环节 ?

2. 这个自测范围和内容谁提供 ?每个提测版本,研发都自测哪些内容 ?

3. 测试准入标准是什么 ?自测未通过的,如何处理 ?

4. 测试通过标准(上线标准)

此文阐述,一些参考做法:

**001 研发自测 **

一般来说,都是需要「研发自测」的,甚至有些项目,研发自测完,就可以直接上线,不需要测试同学的参与 。
那么自测内容,谁提供呢?提供哪些内容 ?测试会根据自己的任务将对应的需求拆解功能点,然后输出冒烟测试的测试点,放在confluence平台(此处平台,很多,比如 TAPD / xmind文件也行 / Excel放在svn也行,方式不重要,团队内部协商即可),这个文档作为研发自测范围和自测内容(至于这个文档是否需要经过评审?最好评审一下,跟开发、产品碰一碰),测试的功能点可以写粒度也是比较大的点。每一个提测版本,研发人员负责自测自己开发的功能点即可,保证主流程没有问题(基础的业务联调,那是必须的,否则,冒烟都通过不了) 。

补充,
实际跟N多测试同学沟通后,很多公司,是没有研发自测的,导致的结果就是,一个版本,提交了上百个Bug,非常恐怖 。
对于,一个版本,总共就几个Bug的同学,是无法理解的 。

提测版本质量烂、Bug多,效率低,且累,而且经常加班 。
写Bug要时间、录Bug要时间、改Bug要时间、验Bug要时间、重复写Bug要时间 ...

002 测试准入标准

1. 手动执行冒烟测试用例,且都测试通过(打包时,自动执行新业务的接口自动化测试,以及已有业务的自动化接口测试,通过后,准入 。)

2. 转测资料齐全

3. 部署资料正确

4. SVN和Git的代码提交记录正常有效

5. 上次的问题修复率达到要求

自测没通过的咋办 ?版本打回,邮件通知全团队,待提交新版本再测试,上线时间,顺延 。实际情况是,提测延期,上线时间,定死,咋办 ?

1. 加班,赶工 。

2. 实在搞不定的,参考下面的“通过标准”,最后的做法 。

003 测试通过标准

注:如下这段,来自妹纸“紫芸”,在「软件测试圈」的主题 。近期上线的某个项目并未达到测试组管理规范设定的通过标准,但因市场等各种原因,算妥协发布了正式版。对于这类项目的报告出具等很费心,因为遗留问题实在太多,不出具报告对自己不利,出具报告有违背起初设定的通过标准。 什么才是测试通过标准?以往常有听过领导问:“这个项目怎么就是测试通过了?”也常有开发问:“项目怎么才算通过测试?” 一系列的疑问,最好的解决方式是什么?重新审视了测试通过标准,感觉本身有缺陷:太过完美,看似可量化,站在不同角色看,实则无法很好量化,如何优化测试通过标准?当前功能测试方面使用的部分通过标准:

1、测试方案/用例覆盖程度:95%以上;

2、测试输出结果与预期输出之间的符合率:95%以上;

3、测试方案/用例的执行程度:100%;

4、缺陷处理情况:缺陷等级非常重要、重要(P0、P1)需全部关闭,一般、建议性缺陷<10%。开发和测试有争议的缺陷需要经项目小组讨论后决定是否需要修改(拉上产品经理、项目经理、业务方),若经讨论后确认可以忽略不改或因其他原因要在以后的版本中实现,则本次测试可以认为通过(这里非常重要:遗留的问题,一定要跟团队讨论,确定可遗留到下个版本,而且要在测试报告中,注明已知问题 & 风险)。

End 。

最近,很多同学,咨询此类疑惑,希望此文的内容梳理,对你有参考作用 。

标签:版本,测试通过,标准,准入,测试,自测,Bug
来源: https://blog.51cto.com/idotest/3036437