笔者所在项目经历了一个月开发周期，该项目有5名开发人员，1名项目经理，1名测试人员，涵盖OA系统8个模块，在短短1个月中进行了5次发布。
现进行模块测试策略分类归纳。
已有模块
配置项优化
对于已有模块的配置项优化，开发的主要工作是在流程后台和系统模块配置模块中配置对应的适应各单位用户的流程。
测试的策略在于流程测试，理论上配置不改动代码不会影响原功能，于是在流程测试过程中顺便完成了回归测试。
在大家都认为没有问题的信息模块，测试过程中却发现审批不通过时会报错。
测试流程的主体思路是覆盖正向流程和反向流程，在测试过程中尤其要注意反向流程，包括审批不通过时流程流转到原审批节点，以及在原审批节点再次编辑并提交发起流程的场景。
总结1：后期遇到这种任务紧测试资源少的情况，对存配置的模块简单测正反向流程即可。
功能优化
对于已有模块的功能优化，涉及到新增字段、新增菜单、新增流程，开发人员需要增加界面、增加数据表字段，需要进行常规功能测试。
设计测试用例是必要的，虽然没有时间写测试计划但是在大脑中已形成了测试计划，知道测试重点、怎么测试，对功能有疑点的及时找了开发确认，但是开发并没有引起重视。
回归测试阶段与项目经理沟通中，该界面被指出与所要求的不符，进行了又一轮修改。
在开发工期紧张的情况下，开发不一定会去把所有疑点确认，测试人员应该再找到项目经理一起确认，避免后期开发出的功能不符合需求的情况，减少后期修改带来更多的时间和成本代价。
整体测试过程中，由于有设计的测试用例做指导，基本覆盖住了正常和异常的业务场景，主流、分支流的流程测试，四种场景流程均进行了测试，保证了发布功能的质量。
总结2：功能测试需要以设计的测试用例为指导。在开发工期紧张的情况下，测试人员有必要将功能歧义点和开发、项目经理一起进行确认，减少测试的功能南辕北辙的错误发生。
新增模块
新增管理模块
对于会议室管理、供应商管理、工作联络函、生产任务管理这些新模块，涉及到新增模块、新增流程，开发人员需要搭建界面、写接口文档、设计创建数据库，需要进行常规功能测试。
在这一测试过程中，项目团队在创建初期，测试流程不规范，口头提测，于是加强了测试流程宣贯和流程规范工作，这一过程中要力争得到上级项目经理的支持。
首先让开发人员送测时提供送测单，在测试前沟通好送测影响范围和测试重点，避免测试工作偏颇影响进度影响上线。
具体实施过程中只有会议模块进行了测试用例编写，迫于上线压力测试时间压缩，使得在上线前测试工作仅完成了92.31%，发布后出现了遗漏问题。
会议有6个子模块，开发的送测代码质量不高，测试时间只有2天，要避免这种情况必须靠加班赶工，但是当时没有与项目经理沟通是否能延迟时间。
遇到这种情况需要跟开发、项目经理沟通，线上发布前告知项目经理可能存在的风险。即便后期出现了问题，项目经理也心里有数，不会过多责怪。
总结3：时间紧的情况多与项目沟通，协调资源。
无测试用例
对于新模块，没有设计测试用例，第1个模块仅一个菜单，1条流程分支，两个流程节点，第2个模块2个菜单，4条流程分支，每条流程分支有2个流程节点。
开发人员讲解了测试重点，有可能产生问题的地方，这些也是开发人员清楚的地方。
测试策略是以需求文档为准校验页面字段和审批流程，以流程为主线校验业务逻辑。
总结4：迫于上线压力未准备测试点情况下，找开发沟通测试重点、可能存在的问题处，做到有的放矢。
市场千变万化，产品需要迅速推向市场，并在用户使用过程中去做小范围优化，项目成员需要适应这种变化，最近裁员风波不断，测试人员也需适应并拥抱变化，加强自身的战斗力，以使自己经手的项目质量经得起用户和市场的考验！
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
