01测试需求分析的对象
产品需求文档，原型图，技术文档
需求分析，分析方法/工具，结果
流程图转化为思维导图
买电脑的分析结果
测试类型：功能，性能，兼容性，安全，其他
考虑一个功能测试，都要考虑如上类型
测试功能的时候，需求和原型中没有给出的逻辑，需要测试用发散思维进行思考
性能测试：多人同时参加，多人同时登陆
兼容性测试:浏览器，手机和PC
02功能测试需求分析
了解需求范围-明确目标用户-分析功能步骤-挖掘隐藏需求
需求范围：需求是什么，都涉及到哪些功能模块。
明确目标用户：需求的目标用户是谁，不同的用户角色，功能和权限是否一样。
匿名用户/云课堂用户
分析功能步骤的方法
1、列出所有可测试的功能点
2、对每个功能点分层分析--用思维导图
3、功能点之间会有哪些耦合关系？
4、有哪些可能的异常流程？ 网路环境（网络中断，切换，丢包延迟），服务器资源，系统环境，异常中断操作
挖掘隐藏需求
1、了解需求整体架构
2、熟悉所有实现的细节
3、代入用户角色，实际场景中推测
测试用例可以重复执行，和作为历史参考。
测试用例设计方法
1.等价类 如邮件地址长度。 有效等价类，无效等价类。
2.因果图
3.场景分析法
测试用例编写原则
1.预期唯一
2.描述清晰
3.可执行
4.优先级
5.易维护。
用例不仅自己看，也会给别人看。
你写的用例，其他人能否执行？
测试用例优先级
二八定律
P1P2P3
根据功能和影响
P1 核心功能、主干流程，正常流程
P2一般功能，异常流程，分支流程
P3 易用性、界面文案，视觉表现
测试用例管理
为什么需要管理?
一、
因为用例是会被多次执行的
1.不同阶段同一用例会被反复执行
2.不同测试人员，执行不同的测试用例
二、用例支持更新
1）需要变更2）新增测试点
三、多人协作
1、同步测试用例
2、同步测试结果
用什么管理？
1.word-单条
2.Excel-多条
testlink
qualitycenter
测试计划
产品需求确认后，测试需求分析完成后就可以做测试计划
测试计划内容
测试范围 明确需要测哪些模块和测试类型如兼容性能测试（依据测试需求分析的结果）
测试策略 功能测试，兼容性测试（浏览器，手机）性能测试（对哪些模块性能测试），接口测试，安全性测试
资源安排 人力资源，测试环境（测试服环境，终端测试环境），测试工具（bug管理工具，用例管理工具）
进度安排 什么时候测，测多久 项目里程碑（开发节点，提测节点，上线节点）评估因素（业务复杂度，测试复杂度，
产品质量要求，人员数量能力）进度安排（评估工作量，分配人力，预估时间）输出文档（测试计划，测试用例，
bug数据，测试报告）
发布标准 测试工作完成标准（完成所有测试类型，没有影响用户使用的bug，bug少于一定数量），产品发布标准
（产品需求都已完成，交互视觉完成走查，遗留bug经过风险评估，使用说明文档完备）。
风险预防 有哪些风险，如何预防。测试范围风险（测试遗漏，需求变更）测试进度风险（工作量预估不准确，耦合任何延迟，
测试人员变动）产品质量风险（代码质量，测试人员能力）
测试计划的作用：指导测试过程，协调项目安排，提高测试效率，提高测试质量
做测试计划需要有丰富项目经验的人才能做。
测试流程
冒烟测试
一般建议1-2个小时完成冒烟测试。
注意冒烟用例不是P1P2，而是其中的部分用例
新需求测试
回归测试
回归测试确保已有功能不出问题
应该选择那些出错比较大的用例
每天也要发测试日报同步进度
Bug管理
Bug管理工具readmine
好的标题 文字少，提供的信息多
质量报告
测试时间，测试的功能模块
质量报告一般需要半天-1天
Bug按照严重程度，模块，所有者分布，按照时间分布图
持续集成及自动化接口情况