概述
1、测试不可能发现所有的bug，制定测试策略可以帮助我们更好的把控各个测试阶段，利用现有资源尽可能进行充分测试
2、过多的投入测试资源会增加公司成本，通过测试策略可合理分配人力资源，使测试人员发挥各自优势，提高测试效率，更好的把控测试风险，确保产品发布时的质量可控、可评估。
项目背景
与搜驴公司合作实现共享单车推广与运营
共享电单车：车辆由小币代工，设备由中瑞提供，然后由五菱组装。
软件由中瑞提供主要包括：共享小程序（用户端）、经销云（商家端）、政府监管平台（政府端）
产品质量目标
BUG检出率、BUG的NG率、BUG延期率、缺陷有效性
接口响应时间
测试类型
冒烟测试
测试目标：提测的模块主流程可以走通，无阻碍测试的严重bug
测试范围：提测模块
测试工具：禅道、系统
开始节点：功能已开发完成
结束标准：冒烟测试用例均执行通过
若有严重问题，提测版本不合格，不进行系统测试
若没有严重问题，进行系统测试
功能测试
测试目标：确保测试的功能正常
测试范围：覆盖所有需求
测试重点与难点
重点
地图找车
定位的准确性
地图拖拽，放大缩小
大头针锁定范围内无车辆
车辆低电量无法骑行不在地图中显示
车辆已被损坏不在地图中显示
车辆骑行中不在地图中显示
车辆未加装设备不在地图中显示
扫码开锁
蓝牙
蓝牙未开启
蓝牙未授权
蓝牙连接失败
蓝牙配对成功后断开（没电），再次连接
解锁车辆时，车辆不在运营区、车辆没电
扫码后提示
未实名
是否有未支付订单
是否有进行中订单
两个人同时解锁一辆车
已解锁车辆再次扫码
骑车过程的定位持续性
手机断电、信号差
超出运营区2min，需要实现 【远程控车-断电】
倒计时、费用计算展示，延时现象
还车
还车时车辆不在运营区
不在停车区
在边界还车
手机与车距离过远
订单金额计算
不同车型不同计算规则
免费期内还车
非免费期内还车
起步价内还车
还车时不在运营区（调度费）
还车时不在停车点（调度费）
授权认证
授权
第一次打开小程序
已授权用户删除小程序后打开需重新授权
手机未授权位置无法访问小程序
手机已授权位置未开启定位无法访问小程序
认证
新注册用户跳转到实名认证页面
已注册未实名认证用户跳转到实名认证页面
已注册已实名认证用户跳转到首页
难点
地图找车
要结合真实的设备去测试，需要批量造很多数据
测试优先级(原因)
授权登录-找车-扫码骑行-还车支付-个人中心
测试环境
硬件
ios系统，XX版本
Android系统，XX版本
测试工具
禅道
任务管理
BUG管理
测试用例管理
用例执行管理
chales
检查接口是否存在多次调用
检查接口响应时间是否符合标准
缺陷定位与分析
开始节点：冒烟测试通过后
结束标准：用例均执行通过且非延期缺陷均修改完成并验证通过
性能测试
测试目标：与产品、项目经理、客户讨论后制定
测试范围：确定需要进行性能测试的接口
开始节点：功能测试执行通过
结束标准：优化后的接口性能达到最初指定的目标
UI测试
测试目标：核实各个窗口风格（包括颜色、字体、提示信息、图标、title等）都与需求保持一致
测试范围：所有页面，例如：菜单、页面背景、字体颜色、按钮名称
开始节点：界面开发完成
结束标准：UI符合可接受标准
易用性测试
测试目标：检查系统是否符合用户界面的友好性、易操作性，而且符合用户操作习惯。
测试范围：所有页面有交互的功能
开始节点：界面开发完成
结束标准：交互符合可接受标准
安全测试
测试目标：隐私信息加密，用户执行操作其有权限的功能，可以抵挡非法攻击
测试范围：执行安全用例库中的用例
测试工具
禅道：执行安全测试用例
appscan：对系统进行扫描，识别安全问题
开始节点：接口开发完成
结束标准：已发现的安全问题均解决完成并验证通过
兼容性测试
测试目标：核实系统在不同软件和硬件配置中运行稳定
测试范围：不同的手机机型、不同的微信版本、不同的操作系统版本
开始节点：功能冒烟测试通过
结束标准：非延期缺陷均修改完成并验证通过
测试人员与职责
董学芳：功能测试（地图找车、扫码骑行）、兼容性测试、UI测试、易用性测试
赵圣菊：功能测试（个人中心）、兼容性测试、UI测试、易用性测试、安全测试
人在数科院办公，与项目成员沟通不方便，分配其需求比较明确的功能，执行安全库中的测试用例
张晓童：功能测试（登录授权、首页、账号注销）、兼容性测试、UI测试、易用性测试
任哲：功能测试（还车支付、故障上报、临时锁车）、兼容性测试、UI测试、易用性测试
有较多支付相关测试经验
各阶段测试策略
需求阶段
全员理解需求文档，提出疑问点，记录评审问题台账
测试设计阶段
拆分各自负责模块的测试点，测试组内评审、项目组内评审
组内出一份测试用例编写规范/模板，保证用例编写统一性
测试执行阶段
功能提测前需要进行冒烟测试，测试通过后才可以进行系统测试
在XX号前保证演示的基本功能可以正常使用，允许存在不影响基本功能的bug
Release测试阶段交叉测试，确保项目质量
组织公司员工进行众测，减小测试遗漏
风险分析
风险1、参与人员分布各个职场，可能会存在信息遗留问题
应对策略：项目问题建议在项目群内沟通，尽量避免线下沟通，线下沟通的问题由本项目测试负责人周知其他测试成员
风险2、指令下发依赖真实设备测试，若系统测试开始前未协调到设备可能会耽误测试进度
应对策略：若系统测试开始前未协调到设备可先进行接口测试，根据接口返回响应值判断指令是否下发成功
风险3、测试时间紧跟开发完成时间，如果存在延期提交测试，则可能会导致项目延期
应对策略：及时获取开发的提测时间并调整测试时间安排，适当加班追赶进度。若延期提测时间较长，已预知项目无法按时上线时，及时告知PMO及项目经理
风险4、真实使用场景下设备状况、网络情况较为复杂，存在测试遗漏的风险
应对策略：1）测试点完成后进行测试组内、项目组内评审，尽可能覆盖能想到的场景 2）小程序上线后建议先试运行一段时间
风险5、由于项目时间较为紧张，且测试机型有限，可能对ios和安卓端的主流机型测试不足。
应对策略：在项目测试过程中保证覆盖到ios、Android系统，在时间允许情况下，尽量覆盖当下主流机型，若实机机型有限，可使用Testin真机调试
