一、ECMS组测试流程试用背景
1.面对公司不断扩大的市场及客户群体, 不同需求和问题随之增加, 如何快速稳定处理这些业务,并提供高质量的版本, 故版
本控制尤为重要;
2.根据测试工作现状，以及公司内对测试及版本工作的重视与期望，需要提高测试人员或称交付人员的工作能力，对人力进行
统一调配。
作为版本控制的重要成员,测试组起到最后把关的重要作用,对测试流程必须通过规范化来提高测试团队的把控能力, 改变原有测试流程的混乱状态, 从而提高测试团队的效率, 输出高质量的升级版本;
3.以ECMS项目组为首个试验田进行试行,再向功能设计中心及其他团队进行推行, 进而在整个公司推广;
二、工作流程
1.测试流程:
需求分析-->建单-->需求评审-->开发-->代码审核-->测试环境更新-->测试-->版本发布-->现场反馈
a. 需求分析/BUG/自产功能(完善类). --从客户或项目经理或产品经理获取需求(包括紧急程度,版本升级时间), 或测试过程
中发现Bug, 或者在过程中提出完善性建议, 整理成需求文档, 文档名称规范:项目来源+日期+需求文档.doc 或EXCEL, 并统一放在专用目录; 形成需求文档后,再与项目经理或客户确认;
b. 建单: 根据需求分析文档, 在事务建单系统, 录入需求/BUG, 关联对应的版本; 获取唯一事务编号,作为测试计划的任务
单号, 录入月度计划；也作为测试用例场景大类编号;
建单规范：
✧功能说明及菜单路径
✧测试要点及相关的操作说明
✧修改涉及的文件列表
c. 需求评审: 项目经理或需求交接人对建单的需求再次确定；并更新测试计划；
d. 在开发人员进行开发期间，测试人员根据测试计划及需求文档，编写测试用例；
e. 测试环境更新 --安排人员负责代码和脚本等管控，由配置管理员更新代码脚本，更新测试环境，备份等；集中统一管理，
避免环境代码混乱；
f. 测试 --测试人员根据任务单号和测试用例、需求文档进行测试，测试人员需要写出测试要点，同时完善测试用例和操作手
册等文档，各个功能测完后，需要进行系统测试，发版本前需要进行回归测试，保证测试质量；
g. 版本发布-- 由配置管理员统一管理版本，打包代码脚本外，还需根据现场需要提供升级清单、功能列表，测试报告、操作
手册，配置手册等；并作好每次版本备份和记录，以便检索和还原等；
H. 追踪现场升级反馈; -- 配置人员跟现场人确认升级是否成功，若出现问题，追踪升级失败原因，反馈问题
3.人员安排;
现阶段其他测试人员安排到中价协项目，仅我和程燕暂时可处理ＥＣＭＳ标准版的工作，程燕手头仍有其他需求在跟进；
4.测试策略.
a. 第一轮功能测试，按需求文档测试，完善测试用例、操作手册，输出问题追踪记录；
b. 第二轮功能测试。
在开发更新问题后，根据测试用例执行二次测试，含系统测试，更新测试用例、操作手册、问题追踪记
录；
c. 第三轮测试回归测试。
版本发布前时行回归测试；
d. 版本更新用户环境。
需要根据测试报告进行α测试β测试，保证输出最后高质量版本；w
附：
性能测试根据需要进行性能测试等
测试工具：LoadRunner、QTP
5.结果输入
➢高质量版本，归入版本库；
➢测试报告、操作手册、配置手册、功能清单、问题追踪等，并归入文档库；
组织成员互相培训学习，结合工作过程中实例进行培训，对培训人员起到知识技能的总结加强效果，对被培训者起到有针对性学习，可以更加容易理解；
（1）测试人员在开发提交之前提交测试报告、操作手册；
（2）涉及配置的任务单需要编写配置手册；如菜单等配置；
（3）测试人员对现场提交的版本质量直接负责；
四、代码审核
代码审核参考代码审核要求章节。
在代码审核实施过程中，根据审核中发现的其他问题，审核人员补充完善其他审核规则。
未在文档中标明的审核规则，暂不实行扣分。
五、文档管理
建立文档库，规范管理产品的相关文档，包括需求设计、测试案例、增量说明列表、操作手册和部署文档等。
六、版本管理
产品化的版本管理从产品版本、增量、小版本和UR着手，划分为开发库，产品库、本地库和文档库，严格将版本管控起来。
开发库由研发项目组维护，产品库由版本管理员维护，本地库由本地维护人员维护。
版本管理的目的一是采用补丁方式解决bug和各现场提出的个性化需求，通过补丁发布现场确保针对性发布，降低风险；二是统一版本，确保各现场版本可以降低风险向同一个方向演进。
七、技能、业务培训
测试组根据部门人员能力情况，以及测试人员负责的产品，定期安排技能、工具和业务流程的培训等。
技能和工具的培训时间安排每周1次，根据测试组人员的工作时间进行调配。
学习内容将汇总测试组内人员的期望学习意愿统一安排。
每次培训结束后希望测试人员能够有所收获。
八、建议：代码提交要求
文件要从vss取最新的来改，若用旧文件来覆盖要扣分
文件提交压缩包要用代码全路径，程序代码和脚本分别打包。
程序包名的格式为：Ur号（姓名_年月日）版本，例如：1111(caikeduo_20160918)_V1.rar。
脚本包的格式为：Ur号（姓名_年月日）版本.sql，例如1111(caikeduo_20160918)_V1.sql.rar
如果提交后，又要修改（比如测试不通过），第二次提交的时候，包里仅仅需要提交这次更改过的文件，不用提交没变更的文件，且包的命名要加上patch1，比如：1111- patch1 (caikeduo_20160918)V1，如果第二次修改就加patch2，以此类推。
文件提交之前需要和VSS上的文件做比对，看自己的文件是否是最新的，自己增加的代码是否正确。