近期测试过程中发现一些问题：测试范围界定不准确，导致漏测。
案例一：
近期团队接手另一个团队的一个项目，为了方便管理，将该项目从一个应用迁移到另外一个应用中：其中牵扯到代码迁移、数据库迁移、zk等中间件迁移等。另外要求对外暴露的接口地址保持不变。
在测试工作前，通过沟通知道本次测试的范围即：
1、对迁移后代码的整体流程验证：
新增---》生成订单---》签约---》签约产品调用 ---》解约
2、对迁移后数据进行验证：
a、新增、删除 功能附带的数据同步
b、签约、解约 数据变更
c、签约产品调用的流逝推送
3、对迁移后对外接口进行验证
问题一：
生成订单需要校验信息，测试环境无法调用真实接口获取数据（缺少mock）,为了测试能进行下去，开发同事把校验这一块的代码注释掉了，写死了部分数据。因为沟通过程中没有对这一块说明，导致测试完成没有将 校验代码放开，导致生产环境校验不生效，入库数据错误
问题二：
项目对外接口要经过其他平台对外暴露，而这个平台在测试环境经常出问题；在测试对外接口时，四个接口有三个接口能正常调用。一个接口调用时一直返回异常，通过对日志的查看，没有走到迁移后的应用中，我认为是接口配置问题，这类问题以前也经常发生。我仅仅按照以往的经验判断它没问题，仅仅和开发说明了问题，没有得到开发的反馈，也没有死盯这个问题，导致上到生产环境也是异常的。后续排查发现该接口代码被注释掉了，平台无法调用到该接口。
案例二：
开发同事对现有功能进行优化，改动部分sql，在沟通过程中没有明确影响范围，也没有拿到改动的sql。
在测试过程中仅仅依靠经验去找到了涉及改动sql表的两个相关功能，仅仅进行了数据查询验证，没有进行深层次验证，导致生产环境定时任务执行失败。
这两个案例中最主要的原因是，开发、测试沟通不充分。测试范围界定不准确，导致漏测。目前想到的解决方案就是通过增加流程，去避免这类问题：
创建共享文档，在沟通过程中将信息留存，并根据表头记录相关测试范围
