MIE测试流程与规范V1.1.docVIP

MIE测试流程与规范 V1.1 版本 负责人 日期 备注 V1.0 朱勇 2014-9-10 撰写初稿 V1.1 朱勇 2014-9-11 产品、开发评审修改稿 * 红色标记的段落是依照评审意见修改的部分 目录 一，敏捷测试流程 3 二，测试各阶段描述 4 三，版本提测要求 5 四，Bug状态流转与处理 6 五，Bug提交模板 8 六，BUG严重级别定义 10 七，Bug提交规范 11 一，敏捷测试流程 二，测试各阶段描述 测试参与需求评审： 测试须参加各个版本的需求评审，并提出意见； 测试用例设计： 按照需求设计测试用例，在版本提测前需准备好测试用例；并且需要筛选出一份自测用例给开发； 测试用例评审： 测试用例可先测试组内评审，然后再找需求所对应的产品、开发评审（可以组织会议或邮件或面对面评审，根据版本紧急程度和需求大小而定）； 迭代测试： 开发完成一个小迭代功能（保证可测性），可以立即提测到测试，让测试尽早介入，好将问题提前暴露出来； 集成测试： 集成测试要覆盖测试新版本所有用例，之前版本的用例进行有损覆盖； 集成测试阶段还需要考虑到机型适配、多语言等测试； 集成测试还需要考虑到网络（2G、3G、WIFI），弱网络模拟，国外网络环境模拟； 稳定性测试： 稳定性测试可以和集成测试同时开始，可以采用每天晚上自动执行Monkey测试； 性能测试： 性能测试需要在版本比较稳定（异常闪退比较少）、遗留严重Bug比较少的情况下开始，主要测试：内存、速度、流量、耗电等（具体的根据版本确定）； 回归测试： 回归测试首先验证已解决的bug，然后要围绕修改点做一定时间的Free Test； 上线前测试： 上线前测试指系统切换到正式环境发布前的测试，主要做一些核心功能验证、升级测试等； 上线后测试： 版本发布后，做上线后测试，主要验证正式版本的下载、升级、统计等； 本地化测试： 需要建立本地用户粉丝群，协助测试本地网络环境（访问速度）、语言翻译、拉取的运营内容（A - Issue Type（缺陷类别）: Client Bug、CMS Bug、Server Bug、Others - Summary（标题）: 简洁完整，能通过标题看出这个bug是什么问题； - Environment（测试环境）: 测试环境/前提条件，具体有：机型、Android OS版本、分辨率、网络等； - Steps（测试步骤）: 描述具体的测试步骤； - Expected Result（期望结果）: 期望结果； - Actual Result（实际结果）: 实际测试结果； - Components（功能模块）： 根据具体的项目划分不同的功能模块； - Reproduce（重现规律）： 必然重现、随机重现、很难重现； - Priority（严重程度）： 致命、严重、一般、提示、建议； - Baseline（版本基线）： 对应产品规划的版本号，例如APP Center1.0、APP Center1.1； - Version（当前测试版本号）： 这里的Version就直接使用提测包的名字，例如：GameCenter1.1_130这部分命名规则需产品定义）； - Solve Version（修复版本号）： Solve Version是指该bug需要在这个版本号的提测包上回归验证； - Period（发现阶段）： 迭代测试、集成测试、上线前测试、上线后测试、用户反馈、开发自测； - Assignee（当前处理人）： 对应的开发接口人（Client、CMS、Server）； - Test Method（测试方法）： 手工测试、自动化测试、性能测试； - Attachment（附件）： Bug相关的Log、截图、或网络抓包； - Comment（评论）： 在Bug状态流转时，可以在评论中附上相应的原因； 六，BUG严重级别定义 致命： 1. 操作导致死机、系统崩溃、数据丢失的； 2. 重点/基本功能完全丧失，导致无法使用或闭环操作的，包括阻碍测试的进行，大部分测试用例无法执行 3. 安全系数高的用户信息泄漏（账号密码、私密信息）； 4. 无法正常安装、启动、覆盖升级 严重： 1. 提测模块部分功能丧失，没实现； 2. 复现概率高，操作步骤简单的程序crash或anr 3. 涉及用户数据错误和丢失、数据不能被储存、更新错误； 4. 明显的程序性能问题（程序操作卡、内存泄漏）； 5. 很容易就能操作出来的明显UI问题，如：影响界面美观或用户操作； 6. 用户重点关注的功能，如下载APP； 一般、提示和建议： 一般：普