测试规范/要素

1.测试的核心：

首先是沟通，高效沟通协作，提前思考容易影响进度&质量问题的风险点，提前暴露问题。沟通、评估并推进相关事宜，避免问题后置暴露在测试阶段

2.测试流程中测试需要明确的地方

2.1 需求评审

• 优先级
• 需求背景
• 改动范围
• 原型逻辑描述是否合理
• 需求逻辑是否闭环
• 测试节点（测试需要哪方面测试）
• 测试环境
• 测试数据
• 测试方法

2.2 UI设计/技术评审设计阶段

• 设计思路是否满足需求
• 设计内容是否有遗漏
• 关注实现方式（底层数据库结构，数据源影响）
• 评估改动设计影响
• 明确阶段范围
• 交互方/依赖方 实现方式
• 上线方案

2.3 排期阶段

排期需注意的两个问题

① 排期是否合理   ②后续若不能按照排期稳步前进，是否有备选方案

排期输出时需考虑的维度（整体排期测试多方面考虑，省的回来压缩测试时间背锅！）

• 是否根据项目优先级合理安排排期资源
• 是否根据研发时间提供 串行 / 并行 等较合理的排期
• 是否提前安排接口测试介入的排期
• 研发是否安排联调排期（三方与后端，后端与前端）
• 前端是否安排与客户端联调
• 方案是否存在变更/未确定的地方（若未全面落地但又着急开发，要留一些意外时间）
• 是否安排UI验收测试时间（可与测试并行）
• 是否安排产品验收测试时间（测试之后）
• 是否安排客户现场验收时间
• 确认项目上线时间

 2.4 测试用例编写、评审

测试用例编写的三要点：逻辑清晰、描述准确、场景覆盖率向100%无限贴近

测试需输出的用例（我这里针对功能测试）

• 冒烟测试用例（高优先级测试用例，提供给开发提测前自测）
• 接口测试用例（前后端联调前测试介入测试，看项目是否需要提供）
• 功能测试用例（评审前需附在会议链接，在评审会上针对这些用例达到需求统一）

测试用例编写需要注意的地方

（1）确认需求文档和UI图已更新为最新版本（会有产品开发私下沟通未同步测试的情况）

（2）思考测试用例逻辑描述是否合理

（3）测试用例场景覆盖，正向 / 反向 / 异常 

（4）用户体验用例，提示信息是否丰富（原型的提示可能并不充分，可从用户角度多考虑发现）

（5）回归场景用例（迭代项目会有重合/相关联的业务，这些交集部分也要回测）

（6）数据源用例（每个数据源也要进行校验，数据落库和定时同步，落库逻辑和同步逻辑按照项目标准写用例，放在冒烟用例里）

......（欢迎补充）

测试用例评审需要注意的地方

（1）与产品、研发确认测试点统一，不明确地方一起沟通

（2）每讲过一个功能问产品研发是否有需补充的测试点（防止有些测试逻辑漏掉，也提醒相关人员认真听讲，毕竟过了就是大家认可的，测试的时候有意见就是bug了~）

（3）正向完整用例和优先级较高的反向用例/异常用例 cue一下产品研发，达成意见统一（一些高优先级的反向和异常的场景，研发可能没考虑到，cue一下他们可以给时间补充，也是推动项目进度）

（4）如果用例有产品研发测试不统一且改动较大，影响延期，则要通知上级领导安排解决方式，并分析此次问题产生原因（尽量在开完会商量解决方案）

（5）用例评审会议纪要，记录待确认点和已确认点（会议结束后整理到公司会议评审记录里，附上修改前和修改后的用例，以做留痕！并群里附上链接和艾特相关人员）

2.5 代码开发阶段

代码开发阶段为研发角色活动，此阶段异常需测试知悉：

• 需求/技术方案是否存在变更（若需求变更需同步到测试，技术方案变更需同步测试和更新方案）
• 是否有提测延期风险（有提测风险可能会压缩测试周期，测试尽量前置识别抛出风险）

2.6 代码评审阶段

目前我没有参与过代码评审阶段 (ㄒoㄒ)~~

2.8 接口测试阶段

看公司需求，一般接口测试要在开发联调前，提前暴露问题，也有大部分公司做自动化接口测试，只需写好用例即可，这里没有细分（后续补充）

2.7 冒烟测试阶段

冒烟测试是项目提测前验证基本功能是否实现，流程是否无阻塞走通

测试需要关注的维度：

• 冒烟测试用例开发已自测通过（留痕发邮件）
• 冒烟测试用例测试执行完毕，全部通过，无阻塞流程方冒烟通过
• 冒烟测试用例未全部通过，阻塞流程，则打回（附上未通过部分，留痕邮件打回）

2.8 功能测试阶段

功能测试即开启了大规模的测试工作，在此期间要不厌其烦的反复测试

功能测试阶段核心把控的思想：

• 明确需求无变更
• 代码分支正确对应版本迭代，每次出包升级都为出包路径（防止开发私自本地打包升级）
• 测试环境维护（测试环境尽量测试维护，不要让开发乱玩）
• 测试需求无冲突（大项目可能，非一人测试，测试人员测试相交处，需提前规范好）
• 测试环境无冲突（可能多个项目用一个服务器环境，提前协商好，防止环境冲突）
• 测试数据高效使用，先测试无数据/少数据的场景，再依次增加业务场景数据（有些测试数据可能依赖第三方，返回增删比较麻烦，也会影响在别人眼里的专业度） 
• 测试中所有异常抛出（只要是需要确认的问题，都抛出由相关人员确认，可每日下班前总结群里统一反馈并艾特相关人员，测试只是测试，测试不做决定！！！）
• 探索型测试，发现前期未识别出来的影响功能点
• 测试进度报告、风险（相关于第三方的项目，每日在大群里反馈测试进度，bug处理情况，风险点）

2.9 回归测试阶段

迭代分支最后合到master分支上后，统一回归测试，避免跟线上代码有冲突

3.

未完待续，我先下班咯~