測試准入標准、測試通過標准、上線標准
- 2022-04-22 17:30:00
- IDO老徐 原創
- 13520
接著上篇，压缩测试时间 ？
看這篇之前，建議先看，
“ 优秀的业务测试工程师 ” 应该是这样的 。
曾經，在星球「軟件測試圈」，問了4個問題：
1、你所在公司，是否有研发自测环节 ？
2、这个自测范围和内容谁提供 ？每个提测版本，研发都自测哪些内容 ？
3、测试准入标准是什么 ？自测未通过的，如何处理 ？
4、測試通過標准（上線標准）
此文，分享一些参考做法 ，
001 研发自测
一般來說，都是需要「研發自測」的，
甚至有些項目，研發自測完，就可以直接上線，不需要测试同学的参与 。
那麽「開發自測內容」，誰提供呢？提供哪些内容 ？
测试工程师，会根据自己的任务将对应的需求拆解功能点，然后输出冒烟测试的测试点（也可以是测试用例中的 P0/P1 Case），放在confluence平台（此处平台，很多，比如 TAPD / xmind文件也行 / Excel放在svn也行，方式不重要，团队内部协商即可），
這個文檔作爲研發自測範圍和自測內容（至于這個文檔是否需要經過評審？最好評審一下，跟開發、産品碰一碰），
測試的功能點可以寫粒度也是比較大的點。
每一个提测版本，研发人员自测自己开发的功能点即可，保证主流程没有问题（基础的业务联调，那是必须的，否则，冒烟都通过不了） 。
補充，
實際跟N多測試同學溝通後，很多公司，是沒有研發自測的，導致的結果就是，一個版本，提交了上百個BUG，非常恐怖 。
对于，一个版本，总共就几个Bug的同学，是无法理解的 。
提测版本质量烂、Bug多，效率低，且累，而且经常加班 。
写Bug要时间、录Bug要时间、改Bug要时间、验Bug要时间、重复写Bug要时间 ...
002 测试准入标准
1、手動執行冒煙測試用例，且都測試通過（打包时，自动执行新业务的接口自动化测试，以及已有业务的自动化接口测试，通过后，准入 。）
2、轉測資料齊全
3、部署資料正確
4、SVN/Git（現在基本上沒有SVN了）的代碼提交記錄正常有效
5、上次的問題修複率達到要求
參考文章：提測模板（測試申請單）
自测没通过的咋办 ？
版本打回，郵件通知全團隊，
待提交新版本再測試，上線時間，順延 。
如果，提测延期，上线时间，定死，咋办 ？
1. 加班，赶工 。
2. 实在搞不定的，参考下面的“通过标准”，最后的做法 。
003 测试通过标准
注：如下这段，来自妹纸“紫芸”，在「軟件測試圈」的主题 。
近期上線的某個項目並未達到測試組管理規範設定的通過標准，但因市場等各種原因，算妥協發布了正式版。
對于這類項目的報告出具等很費心，因爲遺留問題實在太多，不出具報告對自己不利，出具報告有違背起初設定的通過標准。
什么才是测试通过标准？以往常有听过领导问：“这个项目怎么就是测试通过了？”也常有开发问：“项目怎么才算通过测试？” 一系列的疑问，最好的解决方式是什么？
重新審視了測試通過標准，感覺本身有缺陷：太過完美，看似可量化，站在不同角色看，實則無法很好量化，如何優化測試通過標准？
當前功能測試方面使用的部分通過標准：
1、測試方案/用例覆蓋程度：95%以上；
2、測試輸出結果與預期輸出之間的符合率：95%以上；
3、測試方案/用例的執行程度：100%；
4、缺陷處理情況：缺陷等級非常重要、重要（P0、P1）需全部關閉，一般、建議性缺陷<10%。開發和測試有爭議的缺陷需要經項目小組討論後決定是否需要修改（拉上産品經理、項目經理、業務方），若經討論後確認可以忽略不改或因其他原因要在以後的版本中實現，則本次測試可以認爲通過（這裏非常重要：遗留的问题，一定要跟团队讨论，确定可遗留到下个版本，而且要在测试报告中，注明已知问题 & 风险）。
參考文章：聊聊「测试报告」(附 模板下载)
End 。
每天，很多同學，咨詢此類疑惑，
希望此文的内容梳理，对你有参考作用 。
先写这些 ，如果你遇到了啥有意思的具体问题，来「軟件測試圈」提問 ，我都会解答的 。
IDO老徐
全网同名，个人IP公衆號
日更10年，每天 1 分钟、解决 1 个问题
職場、副業、輕創業、寫作、個人IP
公衆號、視頻號、小红书、知乎
長按/掃碼，關注IDO老徐
關注回複 401 送你「十年原創资料包」
| 聯系人： | IDO老徐 |
|---|---|
| Email： | 957863300@qq.com |
| QQ： | 957863300 |
| 微信： | 957863300 |
| 微博： | isTester |
| 網址： | idoxu.com |
| 地址： | 中国 · 广东 · 深圳 |
來源備注：老徐博客