（一）项目总结
一、项目简介
IVR_维权预约服务，意在解决客户、维权小二、呼入小二三者之间的沟通上存在问题，呼入小二解答不了客户的问题，客户又不能直接跟维权小二直接沟通，维权小二还得查看呼入小二解答的内容解释等等，沟通不能有效。
IVR_维权预约服务，只需要客服来电预约，自助语音直接给客服反馈，维权小二即会在承诺时间内回拨，减少了呼入小二的接起量。
二、做的好的方面
（一）业务梳理，与开发UC同步进行
1. 根据PRD整理业务，主要是整理可以预约的条件。优势：在前期可以跟开发一同确认需求，及大致的修改方案。
2. TC设计与开发UC同步。优势：UC评审时能较早发现开发编码逻辑上的问题，本次项目业务判断逻辑比较复杂，后期也跟开发做了业务逻辑判断的代码review。
（二）测试策略
1. 充分利用测试人员对业务的熟悉，江春对退款业务、玲玲对电话关联售后业务相对比较熟悉，第一轮测试选择熟悉的业务进行测试。优势：第一轮就能发现业务流程上存在的问题，前期解决减少后期修改需求的风险。
2. 交叉测试，后期测试主要使用交叉测试的方式进行。优势：能避免因为个人的测试习惯、测试疲劳等原因遗漏了测试场景，发现更多的问题。
3. 集成测试，与IVR集成测试。先后台测试，后集成测试，可以快速确认问题存在的部分，减少排查的时间。
4. 业务方及项目组成员共同测试，IVR集成后，业务方与项目组其他成员也加入到测试中（其实包括PD等），注重在语音内容方面进行把关，提高会员体验，同时也减少测试人员的繁重的测试任务。
三、碰到的问题
问题一：在测试过程中接口改动较频繁，测试用例需要反复执行
解决方法：一旦涉及到接口改动，及时通知各方，特别是IVR那边及测试人员，及时通知各方人员，减少重复工作
建议：约定接口之前，因与多方沟通，避免后期的改动，特别是跟IVR那边的约定。第一次接口变更是对业务理解不一致造成的，前期沟通完全可以减少这次变更，且属于大变动。
四、思考及疑问
1. 项目紧急怎么办？项目流程能省吗？
五、项目中沉淀
1. 了解了退款历史动作双写的原理：首先是退款任务，其次是对action_id进行group，只有在group里面的action_id才会被双写。
2. IVR跟CRM联调：IVR跟CRM就是根据接口进行交互，IVR的测试是根据绑定IP可是实现绑定CRM哪个环境，后期IVR测试部分比较容易入手。
（二）个人对项目的理解
维权预约服务是第一个从头到尾跟下来的项目，对于本项目存在的一些优劣谈谈我的想法。
第一，本项目的优点：快速响应、高效沟通。从MRP到发布共花了两周时间，项目人员从一开始就能进入状态，了解本次项目存在的意义，对于之后的工作有驱动作用。快速响应体现在业务方提出新需求，项目组成员能快速回应，作出较合理的解决方案。高效沟通体现在测试过程中从业务方、PD到开发测试之间沟通无障碍，测试中遇到业务问题可以直接询问业务方及PD，能最大程度满足业务方的需求。
第二，本项目的劣势：无规划、无统一需求、新手。无规划主要体现在产品规划、技术架构上：前期投入较少，产品没有从一个整体的方面进行规划，只是侧重于当前要解决的问题上，使得产品产出为部分的效果，也导致技术架构上只有一部分，才会有后期需求优化时，推翻之前的接口约定，重写接口的事情发现。所以前期的产品规划很重要，产品规划不是仅仅站在当前需求的角度去做，而是要高于需求，需要站在行业的高度思考（这仅仅是我的想法，产品规划肯定不止这些需要考虑的地方）。技术架构，本次项目没做架构设计，主要是时间紧迫，开发同学没做技术方案。无统一需求主要体现在业务方不一致，商家跟消费者的需求会不一致，而在设计上来说属于同一个业务，肯定是一致处理，所以经常会有改了消费者不改商家，改商家不改消费者的需求，测试同学需要回归的点太多，不能从实现上区分，给测试造成一定的困扰。新人，据我所知PD是第一次写PRD等，而担任测试的我也是第一次从头到尾跟一个项目，在经验方面会缺少很多，一些隐性问题可能会评估不到。
作为测试新人，在本次项目中学习了项目流程，虽然不是非常规范。对以后的工作有了很大的参考经验，比如测试工作评估的能力（多维度：开发量跟测试量的比例、测试涉及其他系统的联调等），比如TC的设计等等。
