为了规范测试工作、减少开发与测试之前的沟通成本、保证项目进度、提高软件质量，测试人员有必要参考这份软件测试工作规范。
1.1. 编码规范
软件程序开发需要遵守编码规范，一是可以减少代码的维护成本，提高开发工作效率；二是有利于开发工作的延续、传承，减小项目风险。
1.1.1. 合理的注释量
好的代码应该是自描述的，让人费解的地方加上注释。
1.1.2. 规范的命名格式
规范很多，要让别人和一个月的自己看得懂。
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. 环境管理
分权
生产环境对开发和测试只开放查询权限。（需要修改权限时需要经过一定的机制来控制记录，一般只在调试程序时开放修改权限）；
测试环境对开发只开放查询权限。（需要修改权限时要经过确认， 一般只在调试程序时开放修改权限）；
开发环境对测试人员只开放查询权限；
以上三个环境，都由专人负责升级、维护。
定期比对
取生产环境数据库作为标准，对比测试环境。
提取差异部分（表结构、过程、触发器等）进行分析。若差异部分不是计划内的升级版本所致，则应该删除。这样在下一个计划版本升版后，下下个计划版本没有在测试环境上升版前，测试环境和生产环境就实现了结构上的一致了。
开发环境，同样与生产环境对比，差异部分先去除最近一次要发布生产的脚本影响，再将剩下的，在开发组内部沟通确认，将没有人负责的删除。这样，可得到相对统一的环境。
由于开发环境，一般只有一个，所以在多个版本并行开发过程中，数据库管理是相对比较混乱的。在这种情况下，尽量保证测试环境与生产环境的数据库结构的统一。对保证发布质量有较大意义。
1.3.2.6. 冒烟测试
冒烟测试出现的场景有两个，一个是在内部提测时；一个是在生产环境上线时。
冒烟测试通过验证主要功能是否已经实现，有利于粗略的验证提测物是否具有可测性、上线部署后的系统有无重大问题。
1.3.3. 缺陷处理
1.3.3.1. 修复时间
缺陷处理应该有一定的时效性。
优先级
说明
1-紧急
必须在一个工作日内修复
2-较高
必须在三个工作日内修复
3-一般
必须在五个工作日内修复
4-不急
有时间再修复
1.4.1. 评审
1.4.1.1. 需求评审
对于产品需求的评估可以分为三个维度：
价值认同 - 对用户有没有价值，投入产出比怎样；
需求质量 - 需求是否易于理解，细节有没有说清楚，逻辑是否成立；
技术可行性 - 能不能做，成本多大规模，有多大风险。
1.4.1.2. 设计方案评审
由开发团队自行组织，从流程上，必须要进行的。
1.4.1.3. 用例评审
参与方：产品、测试、开发和项目负责人；
目的：
1） 减少测试人员执行阶段做无效工作；
2） 避免三方的需求理解不一致；
3） 每个测试人员的质量标准与项目要求标准达成一致。
1.4.2. 交叉测试 1.交叉测试
每一个测试人员有自己思维的局限性，一种思维测试过之后，软件会对这种测试思维产生抗性，很难再发现新的问题，通过交叉测试，可以把新的测试思维带进来，测试出未发现的bug。防止测试人员工作粗心导致漏测。
2. 执行监督
首先达成共识，在共同监督执行的基础上，并安排专人主持监督工作。
3. 优化改进
该文档罗列，定义了一系列的软件测试规范，主要目的还是为了保证项目进度、提高软件质量。在该方案执行的过程中，我们本着简洁、高效的原则，不断优化改进，以期拿出最适用药聚汇的软件测试工作规范。
3.1. 测试演进
3.2. 缺陷预防
1） 需求阶段测试开始进入项目；
2） 进行单元测试-代码静态分析；
3） 持续集成-每日构建、自动反馈。