第8讲 人人乐项目

第8讲 人人乐项目




一、如何分析需求

1、显性需求：明确说明的，公布的信息
如：要求做一个聊天功能  包含：发语音  视频 图片

2、隐形需求：客户说只要质量好，价格无所谓  ==》物美价廉
例子：需求：添加用户功能，填写信息后点击提交，提交成功，【连续点击二次，创建两条数据】

3、特殊需求：计算公式

4、关联需求：注册  登录两个功能是有关联的


二、需求的特性
1）完整性: 功能的实现和设计信息齐全
2）正确性：真实的反应用户意图
3）精确性：需求对每一项功能的描述必须可理解、充分、包括必要的信息
4）可行性：可通过公司的开发或者测试的前期验证
5）必要性：需求文档中无多余成分，每一个需求都是必要的
6）无二义性：需求中的功能或者业务解释具有唯一性，不要前面
这么说，后面又是不同解释
7）可验性：可以通过验证、模拟，实际能满足用户

任务：
1、阅读和深入理解人人乐项目相关需求
2、用xmind思维导图对业务需求进行提炼（示例在下一页）
3、进行项目串讲（项目串讲要求如下：） ==》用文档梳理两个模块的流程
a.首先自我介绍
b.讲解的业务模块有哪些?
c.具体模块业务拆分
d.项目串讲的时间控制在30分钟以内为宜
4、根据人人乐需求文档编写测试用例 20条



测试报告相关

1、每天编写多少调用了？
每人每天编写用例：80-100左右
1）看情况不忙的时候，写的多一点
2）如果需求比较复杂，写得少一点，可能30-40左右
3）如果会议比较多，写的少一点

2、每天用力的执行数？
1）没人每天大概能执行100多条左右
2）具体看情况，主体功能不堵塞的话，执行的多一点
3）环境也会影响执行的效率
4）会议多也会影响进度

3、每小时执行用例
场景比较简单的话一般30-40条，场景比较复杂可能20条那样

4、你认为什么样的用例是一条优质的用例（怎么保证用例的覆盖率）
1）对需求了解透彻，找出隐性的、特殊的、相关联的需求 用xmind思维导图梳理出来
2）用等价类、边界值等测试方法设计测试用例
3）用例标题简单明了，与步骤和预期相呼应，
4）用例进行多次评审，保证用例质量
4）不光是考虑功能测试，还要考虑兼容性、可靠性、可移植性等多个维度

5、你们公司用例评审只需要一次嘛？
看情况，有时候用例评审需要多次，一般改动比较多可能回多次评审
，改动少就增删改，然后进行保存

6、测试计划
需求评审后编写测试计划（一般是领导 骨干  你）假设1个月上线==》22天
需求分析：      3天
编写测试计划：  1天
搭建环境：      1天
编写用例：      7天
执行用例：      9天（测试时间和复测时间，就是改bug）
编写测试报告：  1天

7、测试计划包括哪些内容？
测试目的：为了下一次编写报告做参考
测试背景：
测试范围：当前迭代的需求
测试约束：测试准入 测试准出
面试题1：什么时候测试人员可以介入测试（测试准入）
1）所有相关文档已输出（需求文档  开发文档 单元测试文档 测试用例文档 测试计划等等）
2）开发代码已编写完成，并完成自测，也符合需求文档规定的功能
3）测试用例文档已通过评审
4）运维已部署好测试环境
5）冒烟测试通过

面试题2：什么时候测试准出（什么时候测试完了？）
1）本次迭代的功能均已实现，且符合需求规定的功能
2）所有的用例都执行，且达标
3）所有的bug 致命  严重  一般 都已修复，且通过验证，都已ok
4）相关测试小结文档，冒烟测试报告，bug统计报告，用例统计报告已输出
5）输出测试总结报告发给领导确认

测试任务进度：人员安排  投入哪些人力，每个阶段时间安排
资源：软件资源linux  mysql5.7  centos7 java    和硬件  win10 win7
风险评估：当前迭代的版本可能会影响到那一块的
输出文档：测试计划  测试用例  测试小结 bug文档  测试报告



8、项目组团队
项目经理        1
产品经理        1
开发        16
测试        4
运维        1
ui      1


9、测试报告
测试范围：当前迭代的需求
测试目的：为了下一次编写报告做参考
测试人员：人员安排
测试时间：测试耗时   人天
测试环境：pc  app
测试策略：测试方法  功能测试 接口测试  自动化测试 兼容性测试 易用性测试 性能测试  安全测试
测试用例：编写了多少条用例，成功了多少  失败了多少  成功率
缺陷情况：发现了多少个bug，主要集中在哪里 bug 等级  解决了多少，还剩多少 遗留情况
风险评估：测试完后可能存在哪些风险
输出文档：测试计划  用例文档  bug清单 等等
测试结论：是否通过





10、风险评估

1）测试时间不足
解决方案：动员测试人员完成测试任务，必要时应给予物质奖励

2）版本控制
解决方案：严格控制版本，bug版本为单位进行提交，在测试过程中及bug确认阶段
禁止提交代码

3）新员工入职测试任务可能有风险
解决方案：组织一些会议进行业务和技能培训

4）需求不断变更
解决方案：
建议将需求变更文档化，对没有文档的需求变更，需要找负责人确认

测试差不多测试完了，改动比较大，站在测试角度说明变更的功能对现有功能影响程度
如果大，建议下一个版本规划，如果还是要这样做，版本需要延期下，
如果改动比较小，可以接受，但是需要写在文档中



11、什么是测试策略？常见的测试策略有哪些？执行测试 用什么方法？
测试策略描述测试工程的总体方法和目标。

测试策略的制定主要包含三个方面的内容：
1）确定测试过程要适用的测试技术和工具
2）（制定测试启动、停止、完成标准
3）进行风险分析和应对方案 常见的16种测试策略有：
功能测试，性能测试，压力测试， 容量测试，安全性测试，可用性测试，
安装测试，异常测试，健壮性测试，文档测试，
网络测试，稳定性测试。


12、测试方案、测试计划、测试策略与测试用例之间的区别？

测试方案：
测试工具的设计和选择，测试用例的设计方法，测试代码的设计方案。
测试方案需要在测试计划的指导下进行，测试计划提出“做什么”，而测试方案明确 “如何做“。
一个行动方案，一个偏执行。

测试计划：
1）对测试全过程的组织、资源、原则等进行规定和约束
2）并制定测试全过程各个阶段的任务分配以及时间进度安排
3）并提出对各项任务的评估，风险分析和管理需求
4）围绕管理层的一次活动

测试策略：
侧重需求分析，评估风险，定义测试范围，
确定测试方法，制定测试启动、 停止、完成标准和条件。


测试用例：
根据测试计划，制定完成测试任务的具体测试步骤。