实用的测试流程梳理总结（质量保障）

废话不多说，简明扼要的列出我认为测试最重要的几点：

1. 测试思维：

优秀的测试思维对case设计的好坏起决定作用，case的好坏对测试效率和测试质量起决定作用，所以测试思维非常重要。

我主要用结构性思维，怀疑一切的思维。

 

2. 准备工作：

1）需求掌握：

根据产品需求评审会的讲解，以及各个文档的内容对整个项目有个完整的理解，完整的理解对后面测试过程中快速定位问题助益较大。

测试左移要求理解需求的时候（评估需求的质量，分析需求的合理性以及完整性，可以会上提出）

（注意！我说的是完整的理解，不是看一遍就完了，判断是否真正理解需求的方法：自己像产品一样讲一遍，如果能够说清楚所有的模块、功能点和必要的流程，自己提不出解决不了的问题点就算差不多了）

（及时跟进群里产品的修改和开发的进度，需求很少能一拍既定，及时跟进变动才能设计case不出错，尤其是测试开发实际做的范围）

PS：需求评审测试如何做

1. 确保产品讲清了需求的产生背景，需求要实现的效果，业务逻辑，用户交互

2. 根据需求内容明确测试范围；确定本次需求需要保证的内容，可能影响的原有业务，是否需要其他业务的支持等等

3. 问清进度和排期

4. 解决了自己评审前总结的问题（评审前需要自己走一遍流程）

5. 需求的合理性非常重要，会上一定要对需求的复杂度做评估，复杂度必须和收益成正比关系，否则在开发和测试过程中就会浪费大量时间而没有任何意义

 

 

 

 

 

2）评估测试时间和测试方案设计：

包括但不限于设计case时间、测试时间、修改bug时间、系统间联调配合时间、回归测试时间等，除去联调时间的不定性，原则上测试预估时间是开发时间的2/3，结合测试策略设计来评估时间

测试策略设计，包括测试阶段（单元，接口，系统功能，回归，联调，线上验证等步骤），测试范围（功能，性能，安全性，兼容性等看导图），测试工具（根据阶段和范围定，包括自动化，覆盖率的确定）

3）设计case：（开发设计阶段）

根据测试思维设计测试点，目的是为了尽量覆盖全面。

我的case设计思路分三个层次：

• 需求分析层面的测试点：

功能元素测试点

（页面元素和功能，接口，数据库，性能等基础，会用到基本测试方法，比如边界值，等价类划分，自己总结的公共case库，根据文案的名词和状态分析）

业务逻辑测试点（正常场景、异常场景，用场景分析流确定基本流和备选流，看经验，根据产品文案的动词分析，总结公共场景点）

• 开发实现层面的测试点：

思考开发怎么代码实现这个功能上，实现过程中就有业务上可能关注不到的点，比如日期是怎么实现的，具体是用什么定时，定时的细节就很重要了，接口等触发条件，也建议提测后review开发代码补充没想到的测试点（项目第一次的时候必须了解整个项目的整体架构和实现技术，才能从技术和代码层面根据经验发现问题）

也就是说其实写case是写两遍的，第一遍是从需求角度写那时开发还没有给出具体的实现方案，第二次是从实现角度再详细补充修改case的过程，第二遍非常重要，一定要多问开发逻辑的实现，并且将问好的逻辑自己文字表述一遍表述完都没问题了再填case，往往表述中就会发现很多细节问题

• 回归层面的测试点：

以代码模块为方向，涉及相关会影响到的地方回归

以业务线场景为方向，涉及相关会影响到的地方回归

每次必回归核心case

（这些回归case必须每次及时补充到自动化里，才能避免手工重复劳动）

当测试时间不充足的时候，case设计和执行也优先考虑重要的功能点和业务逻辑点

最后别忘了将自己记录的bug预防体系里的经验bug、原有线上的同类型的问题bug补充到case里

将case场景组合后可能会导致非常多的冗余，就要结合开发实现逻辑把这些冗余的case去掉，留下高效case，节约测试时间，写的时候一定要写全，但是写完一定要有筛选过程，留下测试真正应该执行的case

 

4）准备数据：

不是只简单写写测试用例就行，所有sql，测试数据，验证点，全部都准备好，测试执行的时候才能做到最快速和高效，所以不要以为开发开发阶段测试有多闲，这段时间正是需要准备充足的时间，很重要，体现能力的时候

 

5）准备环境：

一般需要测试自己申请机器，自己部署，控制分支和版本

7）开发提测后和其沟通测试点非常重要：

开发会将他认为测试的重点和你说下，看你有没有注意到，这些重点一般也是测试思维里从开发实现角度分析的测试点，很重要

 

3. 测试过程：（根据测试方案设计测试）

0）代码静态检查，代码覆盖率

1）每个case的验证点一定要验全了，包括数据库，接口返回值，页面展示的每一个字段，不只是验证标志性点，这点非常重要

2）bug要描述的非常清晰，图文并茂，不给开发造成疑惑

3）开发修改完bug解决问题后，一定要问清逻辑改成什么样了，不要光猜浪费时间，根据修改的逻辑完善了case再测试，不能瞎急一定要紧张中有序，才能减少上线问题，严谨冷静分析最重要

3）常规测试至少两轮，最后回归测试一轮，这点也非常重要

4）测试资源充足的情况下（测试人员不止一人），一定要交叉测试，可以放在第二轮

5）每天同步测试进度，测试bug和问题情况，风险情况，以备领导询问，或及时向领导汇报

6）分析bug的能力一定要提高，最好是从代码层定位问题，不能一卡住就直接抛给开发，学会自己分析解决，才能高效

7）回归测试或者验证bug的时候，一定要看开发提交的代码变更，避免因为修改导致新的隐藏bug没有发现

 

 

4. 结测标准：

最后一次回归测试不会出现p0-p2的bug，并且bug是收敛的

每次测试完成合并代码进行核心功能回归的时候都重新写一遍主case，自动化和以后别的需求回归次部分的时候都要用到

及时更新自动化case，保证手工部分、自动化部分，覆盖率达到70、80%

 

5. 上线后工作：

不断跟踪线上情况，及时发现问题，预警

复盘：总结测试过程的不足和缺陷以及项目问题，及时完善，补充做提高效率的事，补充自己的公共case库，补充bug预防体系，分析测试质量