软件测试流程

产研测需求评审

三方统一明确需求设计合理性、逻辑合理性、迭代优先级；

设计评审

3.2项目测试流程
   

测试环境的搭建（文档/代码/数据/测试工具都需要标明）也是重点，最后要设定好准入（提测标准-冒烟测试）准出（上线标准）的标准。

设计用例：熟悉需求，设计测试点，编写测试用例；先设计业务用例再对单功能模块用例进行细分。这里详细的设计用例的方法我就不再重复提，先前的测试基础博客里有说。

用例执行：按优先级执行，按顺序执行；二者均可，具体看项目情况安排

缺陷管理：提交缺陷的时候需要确保用例执行失败时的唯一性和可复现性，在提交的时候一定要注明（优先级/版本号/状态）；缺陷验证的时候需要根据不同的版本号进行标记，验证不通过时需要重新打开让研发清楚状态，严重或者存在歧义要及时通知项目经理和产品经理；

缺陷关闭就是在验证通过后标明版本号关闭即可。

测试报告输出：主要是输出缺陷记录的结果以及测试计划里的时间安排是否如期等，各个公司的报告格式不一定相同，按各自的来即可。

需求排期

排期策略：

• 测试排期依据研发总工时1/2～1/3为基调；
• 考虑需求复杂程度，前端样式改动或者改动链路较短，可适当缩短排期；后端改动或者修改改动链路较长可适当增加排期；
• 考虑业务风险程度较高，可适当增加排期；
• 测试人力紧张，留buffer以保证测试质量；
• 预备方案planB

编写case

case设计关键点

• 熟悉本次需求；
• 熟悉其他系统和本次需求的关联；
• 熟悉开发设计文档和实现逻辑；
• 熟悉数据库设计文档和数据存储；
• 熟悉项目架构，发现隐藏需求；

case设计方法

原则：最少测试用例覆盖最全面

• 等价类划分法

1. 有效等价类[5,18]
2. 无效等价类<5 and >18

• 边界值法

1. 上点5/18
2. 内点10
3. 离点4/19

• 因果图法

1. not
2. and
3. or

• 场景法

1. 优先设计业务用例
2. 再设计单功能模块用例

case内容

用例编号	用例标题	测试环境	优先级	预置条件	操作步骤	预期结果	实际结果

测试类型

• 功能测试
• UI测试
• 兼容性测试
• 弱网测试
• 性能测试
• 安全性测试
• 易用性测试

测试环境搭建

文档/代码/数据/测试工具都需要标明

case评审

• qa、pm、rd三方同会
• 和rd确认核心逻辑全面覆盖
• 确认是否有旧版本需要回归测试

准入准出机制

• 准入标准，即提测标准：冒烟测试用例通过，验收人为测试人员，通过率可以酌情而定，超过80%的通过率则提测通过，否则打回；
• 冒烟测试用例会维护并分享给开发人员，提测前，开发人员内部自测下，提高沟通效率；
• 制定提测标准的目的是为了约束开发工作能按时交付，如果测试的周期较短，开发提测质量较差，导致修复阻塞性问题花费较长，这样会影响版本按时上线。出于质量的考虑，项目会顺延上线，每个环节都是螺丝钉，环环相扣，不能顾此失彼；
• 准出标准，即符合上线的标准，一般参考点有两个：测试报告、业务验收。

1. 测试报告：例如通过率超过95%才能符合上线，遗留缺陷登记P3的数量，是否影响业务功能；
2. 业务验收：介入越早越好，可以分批验收；

rd联调+提测

引入测试左移思维	提供冒烟测试case，核心业务场景 建立打回机制，定义准入标准：通过率>80%
测试数据准备	服务端造数据	数据库造数据 后端写死本地数据
	客户端造数据	APP端利用charles--mock

执行case 

• 定位bug

• 偶现bug/无法复现

• 漏侧bug

• 开发不认可bug

https://blog.csdn.net/2302_82334306/article/details/139983973?spm=1001.2014.3001.5502https://blog.csdn.net/2302_82334306/article/details/139983973?spm=1001.2014.3001.5502

提交bug

前提：同开发有效沟通，认同后jira记录bug

测试时间被开发压缩，如何保证测试质量

一、需求变更导致，向上回报风险情况

二、内部原因导致，分以下解决方案

✅测试前

向上回报风险情况

增加测试人员+加班

✅评审case期间--划分测试重点

优先级高的功能(涉及金融功能/核心业务流程/用户使用频率)模块分配有经验的人测试

优先级低的功能模块安排新手测试+后续测试安排有经验同学对该部分模块进行冒烟测试

✅联调后--尽可能提前介入

提前准备测试数据

接口测试

✅测试期间

产研测站会无沟通障碍

高优bug周知TL

✅上线后--加强风险管理，同步测试报告汇报风险点，加强线上回归测试

pre环境

探索性测试(ET测试)

• 发版前进行ET测试--此环节相当于模拟用户随机探索使用APP

• 主要围绕新版本的功能来探索

• 使用过程中行为交互/体验不友好/被QA惯性思维漏测的bug等大部分都能被发现

pm验收
qa	主流程回归测试 新功能回归测试
UI走查	尽可能不影响排期上线/优先级较低

上线前策略

确定上线策略

        上线顺序：多系统依赖关系决定上线顺序；

        修复数据策略：设置开关以防新功能上线后出现bug，将开关打开走老流程；

        数据库修改；

        配置线上环境数据：

        上线申请邮件：

生产验证，一般是在发布后，使用测试账号在生产进行可测试性验证。生产的发布比较复杂，包括代码的发布、配置变更、DB变更、运维操作、网络层通信等，每个环节的疏忽或误操作，都会影响到本次发布。

上线策略

提交测试报告    

测试报告
风险评估
兼容机型	IOS：iPhoneX、iPhone11、iPhone12 Android：OPPO、vivo、华为、小米(Android4大机型)
系统兼容覆盖	IOS版本(10~14.6) Android版本(9.0~11.0)
测试方法	冒烟测试、集成测试、接口测试、ET测试、回归测试、兼容性测试
bug总数	bug总数：n个（ios:x个、android：y个、serve：z个、产品：n个）
bug列表	提取jira链接
bug根因分析

上线后策略

线上人工巡检	高优功能模块/页面

线上bug应对策略

• 原因

        线上环境数据的复杂度是测试环境不能比拟的

        业务操作的不可控性

        实际场景的复杂性

• 预防

        灰度测试：设置开关控制/白名单控制

        监控线上数据：一键回滚机制

• 应对

        影响范围比较小的bug先修复，后等待下一版本迭代

        影响范围比较大的bug/无法明确问题引入原因时，回滚旧版本的方式来规避

• 复盘分析

        需求规格不明确，导致测试用例编写过于粗略

        需求规格变更，导致测试用例未及时更行

        测试用例覆盖不全面，导致场景漏测

        测试环境测试数据受限，导致缺陷漏侧

        rd修复bug引入新bug

项目复盘

遗留问题清单

问题解决机制

持续更新中-----