提取差异部分（表结构、过程、触发器等）进行分析。若差异部分不是计划内的升级版本所致，则应该删除。这样在下一个计划版本升版后，下下个计划版本没有在测试环境上升版前，测试环境和生产环境就实现了结构上的一致了。
开发环境，同样与生产环境对比，差异部分先去除最近一次要发布生产的脚本影响，再将剩下的，在开发组内部沟通确认，将没有人负责的删除。这样，可得到相对统一的环境。
由于开发环境，一般只有一个，所以在多个版本并行开发过程中，数据库管理是相对比较混乱的。在这种情况下，尽量保证测试环境与生产环境的数据库结构的统一。对保证发布质量有较大意义。
1.3.2.6. 冒烟测试冒烟测试出现的场景有两个，一个是在内部提测时；一个是在生产环境上线时。
冒烟测试通过验证主要功能是否已经实现，有利于粗略的验证提测物是否具有可测性、上线部署后的系统有无重大问题。
1.3.3. 缺陷处理 1.3.3.1. 修复时间缺陷处理应该有一定的时效性。
优先级
说明
1-紧急
必须在一个工作日内修复
2-较高
必须在三个工作日内修复
3-一般
必须在五个工作日内修复
4-不急
有时间再修复
1.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、防止测试人员工作粗心导致漏测。
2. 执行监督首先达成共识，在共同监督执行的基础上，并安排专人主持监督工作。
3. 优化改进该文档罗列，定义了一系列的软件测试规范，主要目的还是为了保证项目进度、提高软件质量。在该方案执行的过程中，我们本着简洁、高效的原则，不断优化改进，以期拿出最适用药聚汇的软件测试工作规范。
3.1. 测试演进
3.2. 缺陷预防
1） 需求阶段测试开始进入项目；
2） 进行单元测试-代码静态分析；
3） 持续集成-每日构建、自动反馈。