为了规范测试工作、减少开发与测试之前的沟通成本、保证项目进度、提高软件质量，测试组起草了这份软件测试工作规范。
1.1. 编码规范软件程序开发需要遵守编码规范，一是可以减少代码的维护成本，提高开发工作效率；二是有利于开发工作的延续、传承，减小项目风险。
1.1.1. 合理的注释量好的代码应该是自描述的，让人费解的地方加上注释。
1.1.2. 规范的命名格式规范很多，要让别人和一个月的自己看得懂。词穷的话参考CODELF:
#%E8%8D%AF%E8%81%9A%E6%B1%87
1.2. 测试与测试结果 1.2.1. 单元测试与报告单元测试一定要做。深入理解“ test driven development”思想，有条件的话，先写测试代码，后写开发代码。综合使用各种覆盖方法，例如：路径、函数、条件、语句，Code Coverage确保高于80%。
统一提供单元测试报告。
1.2.2. 集成测试与报告集成测试也一定要做。测试工作要覆盖所有模块和接口。
统一提供集成测试报告。
1.2.3. 系统测试单元和集成通过后，项目提测并进入系统测试阶段。
系统测试范围依据项目不同可分为功能和非功能测试。
1.2.3.1. 模式依照Alpha1-到Alpha1n的模式。
提测版本1冒烟测试通过后即进入第一轮测试（记做Alpha1），执行全用例。测试和开发，不断提交和修复BUG，直至用例执行完成；
开发修复完所有缺陷，打包发布版本2；
提测版本2冒烟测试通过后即进入第二轮测试（记做Alpha2），验证缺陷，执行部分用例。测试和开发，不断提交和修复BUG，直至用例执行完成；
开发修复完所有缺陷，打包发布版本3；
提测版本3冒烟测试通过后即进入第三轮测试（记做Alpha3），验证缺陷，执行部分用例。测试和开发，不断提交和修复BUG，直至用例执行完成；
……
如此，循环往复，直至缺陷收敛，达到测试退出标准，系统测试完成。
出具系统测试报告。
1.2.3.2. 进入标准1） 需求说明书规定的功能均已实现；
2） 主要流程可以走通。
3） 界面上的功能均已实现，符合设计文档规定的功能。
1.2.3.3. 暂停标准1） 一级错误数大于1、二级错误数大于2；
2） 软件项目需暂停以进行调整时。
1.2.3.4. 退出标准1） 按照测试计划完成了系统测试；
2） 达到了测试计划中关于系统测试所规定的覆盖率要求；
3） 在系统测试中发现的错误已经得到修改，各缺陷修复率达到要求。
1.3. 工作流程 1.3.1. 需求与变更 1.3.1.1. 需求定义需求确定后以文档和原型方式提供给测试方。应包含术语解释，功能描述，精确的数据限制等等。
对开发和测试人员开展统一培训。
1.3.1.2. 基线《产品需求文档》确认、稳定后，应建立基线，它是进一步开发、测试的基础。当基线形成后，项目负责软件配置管理的人需要通知相关人员基线已经形成，并且哪儿可以找到这基线了的版本。这个过程可被认为内部的发布。至于对外的正式发布，更是应当从基线了的版本中发布。
1.3.1.3. 变更管理软件工程过程中变更无法避免，这种变更必须严格加以控制和管理，保持修改信息，并把精确、清晰的信息传递到软件工程过程的下一步骤。软件变更管理包括建立控制点和建立报告与审查制度。
变更管理的主要任务包括：
1、 分析变更的必要性和合理性，确定是否实施变更；
2、 记录变更信息，填写变更控制单；
3、 修改相应的软件配置项（基线），确立新的版本；
4、 评审后发布新版本。
1.3.2. 项目提测 1.3.2.1. 提测时间项目提测时间应安排在开发完成，已通过单元和集成测试之后。开发人员有时间，应过一遍冒烟测试用例，以提高冒烟测试通过的成功率。
1.3.2.2. 提测交付物《单元测试报告》
《集成测试报告》
《测试环境搭建部署手册》
“部署程序包”
“数据库初始化脚本”
1.3.2.3. 版本控制1） 开发团队制定并遵循一定的软件系统版本命名格式，例如：
“软件系统的版本号由3部分构成，即主版本号+次版本号+修改号。主版本号1位，只有当系统在结构和功能上有重大突破改进后才发生变化；次版本号有2位；修改号8位，采用提交时的日期，当系统进行任何修改后，包括数据库结构发生变化，修改号都要随之改变。例如：Ver3.31.19990317”；
2） 各子系统的版本号独立；
3）软件系统，产生新的版本后，老版本的软件系统是否继续保存，取决于以下条件：
a、老版本的系统如果有客户还在使用，在客户升级以前，必须继续保存。
b、老版本的系统已经没有客户使用了，并且新版本的系统已经把老系统的文档完整地升级过来，这样可以删除或覆盖老版本的系统资源。
c、对于要删除或覆盖的老版本系统，可以统一备份起来。
1.3.2.4. 提测间隔项目第一次提测后，后续提测应该安排在软件测试工作一轮完成后，并且已尽力修复完大部分缺陷之后。
在系统测试期间严重杜绝一个版本只为了修复一个缺陷。
1.3.2.5. 测试环境 1.3.2.5.1. 环境分类为了保证工作质量、优化工作流程，软件环境最少应该有以下三套：
开发环境：开发部门开发、调试、集成软件使用。
系统测试环境：测试部门系统测试使用。
生产环境：用户使用，运维部门管理。
为了进一步提高用户体验、提高缺陷修复效率，根据条件也可以增设以下两套环境：
Beta环境：系统测试通过后，Beta测试使用，运维部门管理。
线上镜像环境：紧急复现、调试、解决线上问题。
1.3.2.5.2. 环境管理分权
生产环境对开发和测试只开放查询权限。（需要修改权限时需要经过一定的机制来控制记录，一般只在调试程序时开放修改权限）；
测试环境对开发只开放查询权限。（需要修改权限时要经过确认， 一般只在调试程序时开放修改权限）；
开发环境对测试人员只开放查询权限；
以上三个环境，都由专人负责升级、维护。
定期比对
取生产环境数据库作为标准，对比测试环境。