一、输入类清单
第三方账号申请清单
- 分享类：友盟社会化android组件集成的准备工作
- 支付类：支付市场分析报告
- 渠道信息：
- 放置在svn上，路径和命名为
{项目名}/03.Product/Document/账号信息/APP开发相关平台账号申请.xlsx - 渠道号要求以字母开头，不允许出现字母或者数字之外的其它字符，所以
360→sanliuling、360→qihoo360
产品原型检视清单
- 所有的页面必须有相应的英文
- 必须包含一个单独的页面叫“原型修改历史”，用来记录页面增加、删除、修改的重要信息。
- 每个输入框，应该明确值的合理范围，以及前端异常提示文本
- 应该提供相应的测试数据
视觉设计检视清单
- 除了主题色之外，常规页面设计必须Android视觉样式设计规范，
- 非常规页面请必须清晰的标注图。
- 对于网络加载页，同时要设计出如下状态的页面样式：
- 本地无网络；
- 服务端无返回；
- 服务端提示参数出错；
- 数据为空；
- 正常数据。
- 在项目一开始就应该提供 对话框（Dialog） 和弹出框（PopupWindow）的统一样式设计
- 应用图标提供如下尺寸：
mipmap-hdpi 57*57
mipmap-mdpi 80*80
mipmap-xdpi 108*108
mipmap-xxdpi 120*120
mipmap-xxxdpi 512*512
接口检视清单
- 接口输入输出的数据 要么为json，要么为文件流。
- json返回数据必须包含如下的字段，而且0表示成功
{"respCode":0,"respDesc":"成功"}
- 同样的respCode，只能表达同一个含义。
- 返回的json串中不允许使用数字作为key，不允许存在名字会变动的key，比如取近三年的数据，结果出现了2014、2015、2016这些key值。
- 接口应该明确每个值的合理范围，以及前端异常提示文本是否由后台提供。
- 极光推送别名统一为：appuser{id}，比如
appuser12345
Bug检视清单
- 必须发布在禅道测试Bug里面，口头bug不保证修复。
- UI bug单独列成一项，如果跟美观度有关，请由视觉提交bug。
- 模块bug根据提测邮件分配给邮件发送人员。
额外任务检视清单
- 必须发布在禅道项目任务里面，口头任务不保证完成。
二、输出类清单
代码检视清单：
- 检视逻辑：
- 主体逻辑是否有恰当的注释，让别人秒懂；
- 每个类的功能分割是否合理，是否遵循同样的逻辑，是否符合MECE
- 检视类：
- 内部元素的结构顺序是否符合以下顺序：
- 常量；
- 变量：静态优先；
- 方法：静态优先；公开优先；
- 检视方法：
- 以动词开头；
- 符合一巴掌原则；
- 方法是否有注释，标明 输入、输出；
- 其它：
- todo标签使用是否规范；
- 所有的字符串必须放在strings.xml里的。
Apk检视清单
- 如无特殊说明，以下功能为默认项：
- App更新，一般应该放在“个人中心”模块一起完成。
bug修复检视清单
- 针对reopen的bug，在修复后应该和Leader进行确认，再修改其禅道状态。
App上线检视清单
适用于：最后一个提测验证包。
- 确认采用的服务端地址是否符合要求；
- 确认第三方的debug功能是否关闭，比如jpush、环信等；
- 确认VersionCode和VersionName是否符合要求
# VersionCode的格式为 发布当天的yyyyMMDD+自增长的两位数
VERSION_CODE=2016032102
# VersionName的格式为 大版本.小版本，由产品经理确定
VERSION_NAME=0.1
提测邮件检视清单（废弃，采用禅道来管理）
- 收件人为：测试人员
shennianwei@freetek.cc和yaona@freeTek.cc。 - 抄送人为：
dev@freetek.cc和prod@freetek.cc - 附件中apk命名为
{APP名称}{版本号}_{渠道}_{编包日期}_build{代码在git/svn中的版本号}或者参考软件版本命名规范 - 标题为：
项目名称-Android-提测（{提测范围简要说明}） - 内容参考如下：
提测产物
- 附件“xxx.apk”，用于正常测试。
- 附件“xxx.apk”，用于更新测试，请放置在服务端。
本次开发内容
- 登录模块：25个自测用例中，通过22个，阻塞3个（阻塞原因：视觉未提供）
- 我的模块：51个自测用例中，通过31个，阻塞20个（阻塞原因：接口未提供）
- 首页模块：修复20个bug
