测试用例设计模板本模板不包含专项测试的部分内容（比如流量、耗电量等测试），只针对功能需求本身进行设计。
- 资源（图片）加载逻辑测试，包含弱网加载逻辑、延迟加载逻辑的测试；
- 按钮测试，包含三态（点击前、点击时、点击后）的样式、跳转、具体实现效果的测试；
- UI弱网、网络异常（断网+恢复网络）客户端处理逻辑（包括请求超时处理逻辑）的测试；
- 页面上的文案、颜色、内容（写死的）方面的测试；
- 动态数据（接口返回的数据）在页面上的回显逻辑检查（正常情况、容错情况）的测试；
- 输入框类（焦点出现和消失的逻辑、弹出键盘遮罩页面的处理逻辑、容错数据提交的处理逻辑、数据输入的动态校验）的测试；
- 刷新逻辑（包含上拉、下拉等方式的手动刷新和页面自动刷新逻辑）的测试；
- 请求延迟返回（包括断网、弱网情况下的）加载中的页面loading动效检查；
- 弹层的出现与消失逻辑；
- 具体需求功能逻辑交互流程测试。
回到顶部自动化设计思路既然有模板就有自动化实现的方法，例如：前九点可以提取出不变的成分名称，第十点可以通过制定需求交互文档的标准模板从而规范化产品人员和交互设计人员的输入，方便实现测试用例的自动提取与生成。
我们的输入可以确定为：
- 按钮类UI的名称列表；
- 输入框类UI的名称列表；
- 图片、资源的名称列表；
- 涉及网络请求的UI的名称列表；
- 页面固定视觉走查（样式、颜色、文案）列表；
- 接口回显数据名称列表；
- 所有的刷新位置列表；
- 所有的loading动效出现的触发条件列表；
- 按标准模板（需求和交互内容清晰的按点列举，能够根据文档通过脚本工具自动提取生成测试用例）书写的需求文档、交互文档。 根据上面归纳的思路我们可以编写程序来实现自动化生成软件测试用例，通过在实际的工作环境下不断完善上面的模板，将避免一些人为的、经验差异造成的在测试用例设计上的疏漏。我们可以从规范以上确定的输入方面入手，从标准化的输入中获取我们想要得到的信息列表并自动化萃取和生成软件测试用例。 回到顶部覆盖安装测试另外：每次app发版之前都要对android端进行覆盖安装测试。在已经安装旧版本包（最近三个版本的线上包）的情况下，下载并安装新包进行覆盖安装，对基本功能和改动功能进行回归测试。发版之前禁止任何形式的数据库结构变动。
移动 App 构建管理的大体流程，我们可以借鉴后端服务的做法，即：通过代码变更，触发自动的持续集成。集成过程基本遵循：拉取代码、静态检查、编译构建、自动化测试，以及打包分发的标准过程。