问题1 ：有啥反驳的好理由不？
【新系统】页面是否有必要做接口测试？
【领导】：咱们业务依赖文件导入数据，没有必要性不强；
【我】：啊？？！！！前期工作白干，我认为还有有必要的；
问题2：救救孩子，想破脑袋了
大家怎么保证最终接口测试数据的准确性，跟什么比对呢？生产数据嘛？
对照组是？
从功能完整性看，接口为页面提供数据，接口测试可保障页面功能完整；
在前后端分离开发模式下，有助于提高开发效率和减少集成问题；
当页面出现问题时方便定位是前端还是后端的故障；
在多平台页面应用中，对兼容性和功能扩展也有重要意义。
感谢回复，可能还是仅考虑了业务层面的，没有从一个大的整体去细究；
问题一：
- 页面本身的测试分为：页面展示检查、默认数据验证和页面上关联控件的逻辑验证。因此页面本身不需要做接口测试。页面上按钮、链接等触发功能是调用接口，这些可以做接口测试。
- 如果业务是文件导入，那么就直接验证导入到页面上的结果就可以了。
注意：任何业务哪怕是做了接口测试，依然需要进行黑盒和E2E的验证，因此如果可以直接用黑盒效率会比较高。
问题二：
在做测试设计的时候就应该知道expected result，测试的结果就是实际结果和expected result进行对比。如果是老系统或者黑盒系统，无法了解详细的业务逻辑，那么可以找生产数据进行对比，但是产生数据的收入数据依然需要了解。
黑盒测试确实很效率会高，但回归测试时花费时间较长，有点重复性工作了；还是希望接口测试能提高些效率和部分重复工作
都是了解业务逻辑的，不太能确保expected result都是对滴，能和生产数据对比肯定是最棒的哈哈哈哈
产生数据的收入数据是指？没太理解呢
好想了解下别人公司自动化的要求哈哈哈哈，做个小小的对比 
不同的发版方式对回归测试的要求是不一样的，这是一个测试管理问题，对于测试用例编写的结构和测试执行计划中测试用例的选取有关系。
例如：周发布，回归就是本周发布内容相关代码的回归。其实回归量有限，另外可以依赖UI自动化完成。
接口测试和UI测试是一个互补关系，不是排他关系。一个高效的研发体系，UT、接口最好能由开发完成，测试需要关注的是业务测试。
expected result一定要从业务逻辑中整理出来，否则测试用例是不清楚的。
“产生数据的收入数据”：这里笔误了，是输入数据，生产环境是有结果数据的，那么就需要了解产生结果的输入数据。抱歉哈