第8讲 测试报告相关

第8讲  测试报告相关
一、测试数据
1、每人每天大概写的用例数：70-100条
1）看情况不忙的情况下写的多一点
2）如果需求比较复杂，写的比较多一点  30-40
3）如果会议比较多的话写的比较
2、每天用例执行数
1）每人每天大概执行用例数：80-100多点
2）具体看情况，主体功能堵塞的话执行比较少
3）环境也会影响测试进度
4）会议多也会影响进度
3、每小时执行用例数
场景比较简单的话一般执行20-30条
，场景复杂可能执行10几条
4、总共写了多少条用例？
不太清楚，也没统计，要我说的话我可能记得上一个版本（1个月一版本）400多条
5、你认为什么样的用例是一条优质的用例？
1）用例的标题简单明了，不要重复
2）测试数据放在测试步骤中，数据不要重复
3）不要写成bug用例
4）标题和步骤 预期结果相呼应
5）测试用例不能有判断语句
6）运用用例设计方法等价类，边界值
6、你们公司用例评审只需要一次吗？
看情况，有时候用例评审需要多次，改的多需要多次
第一次评审后，测试人员需要对评审的用例进行增删改
第二次评审：增删改的用例
7、测试计划
需求评审后需要编写测试计划（测试经理  测试骨干 你）
一个月一个版本：项目的周期  22天
需求分析：3
测试计划：1
搭建环境：1
编写用例：7
执行用例：9
编写测试报告：1
8、测试计划包含哪些内容？
测试目的：为了给下一次报告提供依据
测试背景：什么情况下产生
测试范围：需求文档，规定了迭代哪些功能
测试约束：
测试准入：
1）所有相关文档都已输出（需求文档 开发文档 用例文档 测试计划）
2）开发编写的代码已完成且通过了单元测试，研发的功能符合需求文档
3）测试用例已通过评审
4）环境搭建好了，代码也已部署到测试环境
5）冒烟测试通过
测试准出：
1）本次更新的功能均已实现，符合需求规定的功能
2）所有的用例全部100%执行
3）所有提交的bug（致命 严重 一般 ）全部都要解决，且已验证通过和关闭
4）相关小结的文档，冒烟测试报告 bug统计报告 用例执行报告已输出
5）输出测试总结报告且通过相关领导确认
人力资源：那些人参与
软件硬件资源：工具（svn mysql xmind tomcat）  配置：电脑配置
任务进度：人员安排 投入多少人力 ，需要多少时间
风险评估：测试完后评估哪些风险
输出文档：测试计划  用例文档 测试点 小结报告 总结报告
9、你们公司上线时0bug吗？
当然不是，偶尔有几个建议性的bug没有解决，有遗留情况
一般怎么去管控这些遗留bug？
1）明确遗留bug发现的时间 版本
2）明确遗留bug后期解决的时间
3）是哪个领导确定同意遗留的
4）明确需要在那个版本解决
10、项目组有多少人？
25个人
测试：4
开发：16
产品经理 2
项目经理 1
运维 1
ui 1
测试总结报告
测试范围：需求文档，规定了迭代哪些功能
测试人员：人员安排 投入多少人力
测试时间：耗时人/天
测试环境：web  app
测试策略：安全测试 性能测试 功能测试 接口自动化测试 ui自动化测试 兼容性测试 易用性测试
黑盒  白盒
测试资源：软件 和硬件资源
测试用例：编写了多少 执行了多少 失败多少 通过多少 通过率
缺陷情况：发现多少bug  bug等级 主要集中在哪里 bug分析 解决多少 遗留多少
风险评估：当前版本可能存在的风险
输出文档：测试计划 用例文档 测试点 需求文档 bug文档
11、什么是测试策略？常见的测试策略有哪些？执行测试 用什么方法？
测试策略描述测试工程的总体方法和目标。
测试策略的制定主要包含三个方面的内容：
1）确定测试过程要适用的测试技术和工具
2）（制定测试启动、停止、完成标准
3）进行风险分析和应对方案 常见的16种测试策略有：
功能测试，性能测试，压力测试， 容量测试，安全性测试，可用性测试，
安装测试，异常测试，健壮性测试，文档测试，
网络测试，稳定性测试。
12、测试方案、测试计划、测试策略与测试用例之间的区别？
测试方案：
测试工具的设计和选择，测试用例的设计方法，测试代码的设计方案。
测试方案需要在测试计划的指导下进行，测试计划提出“做什么”，而测试方案明确 “如何做“。
一个行动方案，一个偏执行。
测试计划：
1）对测试全过程的组织、资源、原则等进行规定和约束
2）并制定测试全过程各个阶段的任务分配以及时间进度安排
3）并提出对各项任务的评估，风险分析和管理需求
4）围绕管理层的一次活动
测试策略：
侧重需求分析，评估风险，定义测试范围，
确定测试方法，制定测试启动、 停止、完成标准和条件。
测试用例：
根据测试计划，制定完成测试任务的具体测试步骤。
13、风险评估
1）测试时间不足
解决方案：动员测试人员完成测试任务，必要时应给予物质奖励
2）版本控制
解决方案：严格控制版本，bug版本为单位进行提交，在测试过程中及bug确认阶段
禁止提交代码
3）新员工入职测试任务可能有风险
解决方案：组织一些会议进行业务和技能培训
4）需求不断变更
解决方案：
建议将需求变更文档化，对没有文档的需求变更，需要找负责人确认
测试差不多测试完了，改动比较大，站在测试角度说明变更的功能对现有功能影响程度
如果大，建议下一个版本规划，如果还是要这样做，版本需要延期下，
如果改动比较小，可以接受，但是需要写在文档中