测试经验测试流程总结

一直想写一篇测试流程总结文章&＃xff0c;在北京做测试工作3年之久&＃xff0c;大大小小也接触了10几个项目了&＃xff0c;简单总结下测试工作中的流程&＃xff0c;大多为测试环节的优化部分&＃xff0c;作为经验总结。

一、测试过程之需求分析

　　测试介入阶段大多从需求分析开始&＃xff0c;需求分析阶段是整个软件生命周期最关键的一环&＃xff0c;产品、研发、测试三方对产品需求理解应做到一致&＃xff0c;所以需求评审会尤其重要&＃xff0c;至少2轮以上。

　　需求分析优化点&＃xff1a;

• 　需求文档是否为完整版&＃xff0c;本次测试范围先确定出来&＃xff0c;优先分析
• 　阅读需求文档将不明确、不理解需求做批注标记
•    利用思维导图Xmind工具&＃xff0c;将需求文档功能模块大概画出来&＃xff0c;需求评审可做参考
•    阅读需求文档第一遍&＃xff0c;应仔细通读一遍&＃xff0c;提前准备需求评审问题单&＃xff0c;做到有准备的评审
•    对于新增需求&＃xff0c;应尽可能关注对已实现功能的影响范围、关联性等
•    需求文档存在很多不确定需求&＃xff0c;测试应注意风险&＃xff0c;及时与产品沟通&＃xff0c;确定最新需求文档&＃xff0c;避免测试阶段增加沟通成本

　　以上几点仅供参考&＃xff0c;需求文档还包含&＃xff08;需求文档规格书、产品原型图、详细设计说明书等&＃xff09;&＃xff0c;建议测试人员做到专业&＃xff0c;在每个环节都严格把控&＃xff0c;保证项目整体的质量

二、测试过程之测试计划、测试方案

　　测试计划大多为测试组长编写&＃xff0c;主要包含测试目标、测试资源、测试策略、测试需求&＃xff08;功能、性能、接口&＃xff09;、测试进度计划&＃xff0c;根据项目总体排期表&＃xff0c;制定出测试排期与人员安排计划。

　　测试方案为具体实施的方案&＃xff0c;主要包含测试需求细化、测试组网图设计、自动化测试设计、测试数据和测试脚本、测试用例设计等&＃xff0c;项目测试负责人编写即可。

三、测试过程之测试用例编写

　　测试需求评审通过、测试计划、方案制定好后&＃xff0c;便可进行测试用例编写工作了&＃xff0c;可根据详细需求文档、Xmind思维导图、产品原型图、研发详细设计文档进行用例编写&＃xff0c;通常按照系统功能模块划分编写范围。

　　测试用例优化点&＃xff1a;

•    测试用例结构设计&＃xff0c;请参考另外一篇文档 https://www.cnblogs.com/xjx767361314/p/9516654.html 清晰的结构方便后期用例的维护
•    测试用例编写规范&＃xff0c;每个公司的大概都有自己的规范&＃xff0c;包含用例基础信息的描述、用例执行信息的编写、用例的生命周期等&＃xff0c;建议按照规范编写&＃xff0c;便于其他人执行与维护
•    测试用例评审流程&＃xff0c;测试用例评审切不要走马观花&＃xff0c;尽量让研发与产品给出专业建议&＃xff0c;可分为线上与线下评审&＃xff0c;建议进行线下评审&＃xff0c;与研发、产品可直接交流沟通&＃xff0c;做到功能无遗漏、无疑问的一份测试用例
•    测试用例维护&＃xff0c;评审后的用例、需求文档更新、研发实现方式改变等因素&＃xff0c;我们需要定期维护测试用例&＃xff0c;建议增加测试用例维护日志记录

四、测试过程之缺陷管理

　　缺陷的管理每个公司都有自己的管理平台&＃xff0c;合理的管理缺陷、分析缺陷不仅可以提高产品质量还可以提高工作效率。

　　缺陷管理优化&＃xff1a;

• 　BUG创建最好能与研发人员意见达成一致&＃xff0c;在提交缺陷系统&＃xff0c;如遇歧义与项目经理或产品人员进行确认&＃xff0c;保证意见一致
•    BUG规范&＃xff0c;如命名、描述信息、版本信息、严重程度、缺陷类型、附件&＃xff08;图片、文件&＃xff09;、留言&＃xff0c;尽量做到简单直接描述一个缺陷
  
•    BUG跟踪&＃xff0c;一个缺陷的生命周期分为几个状态&＃xff0c;还可能变更修复人、验证人等信息&＃xff0c;及时跟踪并做好缺陷留言&＃xff0c;以免遗漏
•    BUG定位能力提升&＃xff0c;测试人员尽可能的发现问题&＃xff0c;并试着去定位问题&＃xff0c;总结问题&＃xff0c;不仅可以提升自身技能还可以让研发高看一眼
•    BUG分析&＃xff0c;一个项目结束&＃xff0c;缺陷分析是必不可少的&＃xff0c;包含BUG严重等级分布图、版本与BUG数量趋势图、模块BUG占比图、缺陷类型图等&＃xff0c;可以从多个角度分析缺陷的产生原因并如何去减少缺陷的产生数量
•    版本控制&＃xff0c;建议测试人员自己做版本控制&＃xff0c;提测版本、提测脚本、提测范围等走邮件流程&＃xff0c;保证缺陷与版本的对应关系&＃xff0c;以免混乱

　　以上几点仅供参考&＃xff0c;根据统计分析缺陷大多出现在研发自测不过关、需求文档不明确、设计不合理等方面&＃xff0c;所以我们制定出研发自测用例集、增加单元测试、主动召开需求评审会等&＃xff0c;在提测之前规避缺陷的发生。

五、测试过程之风险控制

　　测试作为项目质量的最后一道关&＃xff0c;可谓责任重大&＃xff0c;所以超前的风险意识是必不可少的&＃xff0c;避免成为千年背锅侠。

　　风险注意点&＃xff1a;

• 　测试需求确认后&＃xff0c;尽可能拿到项目排期&＃xff0c;明确提测时间点、提测范围、上线时间点等&＃xff0c;如遇变更及时调整
•    需求、设计中途变更&＃xff0c;为了工期压缩研发时间与测试时间&＃xff0c;此时风险很高&＃xff0c;研发代码质量差频发&＃xff0c;测试耗时耗力
•    提测时间点推迟&＃xff0c;应提前和项目经理沟通&＃xff0c;增加测试人力或延长测试时间&＃xff0c;保证测试的质量
•    研发不进行冒烟测试&＃xff0c;提测阶段发现问题&＃xff0c;重新发布版本&＃xff0c;浪费时间&＃xff0c;应与项目经理沟通&＃xff0c;保证冒烟测试的通过才可以提测&＃xff0c;测试可提供冒烟测试用例
•    研发人员技术参差不齐&＃xff0c;应先测试新人研发的模块或研发质量差的模块&＃xff0c;争取更多的修复缺陷时间
•    测试环境变更&＃xff0c;有些项目需要特定的环境&＃xff0c;测试环境与生产环境存在差异&＃xff0c;导致上线后问题频发
•    测试人员技术水平不同&＃xff0c;特别外包新进人员&＃xff0c;对于质量的把控与产品理解不到位&＃xff0c;造成测试标准的误差

六、测试过程之测试总结

　　一个项目测试结束&＃xff0c;笔者比较主张进行测试总结&＃xff0c;涉及测试环境信息、测试数据备份、测试项目总结、测试范围列表、BUG整体的分析与统计、测试报告等。

• 　提高项目的完整性&＃xff0c;无论维护人员还是测试人员&＃xff0c;都可以一目了然了解项目情况
• 　为测试类似项目积累经验&＃xff0c;包括测试方法、测试数据、测试工具的复用&＃xff0c;减少测试风险提高测试效率

 

备注&＃xff1a;项目文档管理工具SVN、测试管理工具禅道