敏捷测试-测试流程调整

在刚听到敏捷测试的时候做过一定的了解。但是实际项目中并没有碰到过，就一直没有系统的理解和调整过。前段时间接手一个使用敏捷开发的项目，从产品设计到第一版上线的时间只有2个月的时间。这让原有的测试流程饱受打击。如何快速的面对敏捷制定符合自己的测试流程，更好的服务于项目成为团队的首要任务。


      通过思考与讨论，对原有的测试流程做出了调整：
一. 测试产出调整：测试计划，测试点，测试报告。


     1. 测试计划：修改原有word文档输出，直接使用甘特图展示测试计划（同步与开发计划）


      2.测试点：之前测试文档主要是依据测试用例，但是在敏捷测试总没有足够的时间让我们来完善测试用例，那么采用脑图对测试点进行整理级管理作为测试依据


      3.测试报告：之前的测试报告一般都是一个完整的报告，但是在敏捷测试中我个人认为：仅使用邮件统计相关测试过程级结果就可以了，不需要长篇的编写测试报告（避免一些不必要的形式主义）


二. 提测流程调整：开发节奏，提测节点


      1.其实这个主要是争对开发节奏的调整，其实在敏捷测试的概念是针对敏捷开发而来的。只有快速的开发节奏才能进行快速的测试节奏。模块式开发是常用的敏捷开发模式，那么作为测试我们需要做的的就是模块化测试。


      2。将产品（项目，需求）拆分成不同提测段，全部提测完成后进行集成测试。


三. 测试流程调整：原型讨论，测试点整理，数据库测试，代码测试，功能测试，集成测试，系统测试


      1.原型讨论：


         在原型设计过程中测试就参与进来，从测试的角度对原型的各个流程分支及异常情况进行整理。这样做是出于两个：在最前期尽可能发现逻辑及设计的缺陷，足够了解原型所能表达或不能表达的更深层次的需求。


      2.测试点整理：


         其实在原型讨论的过程中就可以将大部分的测试点整理完成，至于测试点的整理方式就不多做介绍。主要说明一下需要额外整理的：1.系统结构，对系统结构上进行整理，主要目的是能够对全局有一定的了解，能够系统的对项目就像管理与测试点的分析。2.系统规范，这个需要参考产品及UI的设计规范，对命名，交互，处理流程，字段属性进行罗列，保证在测试过程中能够下意识的找到这些非功能但是足够影响体验的问题。


      3.数据库测试：


          主要分作两部分：1.数据库逻辑测试，主要是对业务与表格进行对比分析，判断表格是否能够满足业务需求。中间表的删除及更新机制。2.数据库表测试，主要是争对字段，索引。字段需要考虑包含：是否唯一主键，命名，长度，类型（小数位数，时间格式，中文，特殊字符，乱码），是否支持为空，重复数据，是否包含索引等


      4.代码测试：


           说到这里可能在部分公司就无法进行了，主要是有两方面的考虑：1.个人能力无法达到，2.涉及岗位权限限制，无法拿到代码权限。


           在这里需要说明的就是万事还是可以去争取一下的，可以从三点进行说服：1.研发可以对非业务及机密代码进行加密封装（泄密问题）；2.对测试仅提供代码获取的权限，单元测试另起目录（影响研发代码）；3.第三人的介入可以督促研发同学对自己的代码规范及注释规范，保障代码的可阅读性。（如有充足时间可以协助产品UI走查页面，当然如果还有性能相关的需求基本上也可以开始了）


       5.功能测试：


            项目开始提测后就需要分别对提测模块进行测试了，对于跨模块的问题可以先记录后面在集成测试中进行验证。同时需要对测试点进行需改补充，保证测试点的可用性。


       6.集成测试：


            全部提测完成后就进入了不断的回归当中，主要关注点在模块间的数量，逻辑，操作等。


        7.系统测试：


            在不断的修复与回归过程中，缺陷也会稳定下来，排除已知不用修复及延期修复的问题外没有问题了，就可以进行下部分的测试。模拟正式环境（有条件可以直接使用正式环境）对项目的进行覆盖性测试，确保产品具备可移植性。


以上相关流程并不适合于所有团队，还是需要更具不同团队的人力及项目环境进行不同程度上的调整，才能够保证团队能够高效的运行。建议阅读到此处的人有想法进行团队及项目管理的，可以系统的对PMP  进行学习。个人认位还是有一定帮助的。
————————————————
版权声明：本文为CSDN博主「--龙」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_33668011/article/details/83575138