前一篇文章中列出了在app开发过程中，产品需求、开发、测试中的种种问题，基于已有的工作经验和对软件开发过程的理解，提出部分问题解决策略
1. 迅速跟进项目变更
移动互联网的需求变更频率远远超过了传统项目和普通的互联网项目，尤其是在创业阶段，大家都是在摸索中和不断的试错中前进，同时市场又没有给你太长的学习时间，无法在竞争中凸起，就会成为分母，每天都会在各种媒体上看到失败的移动互联网项目和创始人的失败总结。
旧的方法无法适应现在的情况，那就必须要适应变化，要以更加积极的态度来应对项目的变更，分析变更对已完成内容的影响，更新计划和进度，在新的情况下继续开展工作。
2. 加强用例评审力度，敏捷的进行用例评审
一次进行大量的测试用例评审太过于耗费时间，而且作为会议时长来说，控制在0.5-1小时是比较好的。这样针对测试用例的评审应该做如下安排：
1. 在测试用例提交评审之前，需要先确认测试用例没有不确认的需求点，且已经跟产品和设计达成了一致。
2. 在测试用例提交项目组评审之前，优先在测试组内进行同行评审，确定没有遗漏的测试点
3. 针对测试用例的评审，要尽量和开发的进度结合进行，在功能的开发进行之前或者刚刚开始时就进行相关用例的评审，评审时需要相应的开发人员参与
4. 用例评审由测试设计人员进行讲解，优先讲解对业务的理解，然后针对业务的理解进行相应的测试场景设计
5. 测试用例的设计先完成思维导图相关版本，以此进行思路的引导和评审的讲解，让与会人员能够快速跟进测试设计的思路，评审确认无问题后再进行excel版本的编写
6. 针对测试用例评审中出现的问题，尽量在会议中确定解决。如果无法在会议中确认的，需要尽快落实并更新用例设计，在下一次评审时提前说明上一次评审中的问题。
3. 加强产品、设计和开发相关知识储备，以专业的水平来提高测试的水平
互联网特别是移动互联网时代，产品和设计交互的地位更加凸显。作为测试人员，除了有开发的知识储备之外、还要了解产品和设计相关的知识，以便在需求评审和设计评审时在测试方面提出更加专业的疑问，从测试设计方面进行多方面的考虑。
4. 进行专项测试相关的测试分析和测试设计
针对安装、卸载、升级、弱网、声音、电量、流量等进行相关的专项测试分析和测试设计，进行专项测试
5. 尽早让产品和设计进行产品确认
在测试版本发布之后就要求产品和设计人员进行相关确认，主要是针对页面UI和基本功能的使用确认，此项工作可以和第一轮测试同步进行。