zentao、测试报告相关

第6讲 禅道（zentao）
1、开源项目管理软件、专注研发项目管理, 内置需求管理、任务管理、bug管理、
缺陷管理、用例管理、计划发布 等功能、实现了软件的完整生命周期管理
2、安装
1）自己建一个文件夹chandao
2）搭建好了之后登录时，点击取消（不要确定）
3、bug管理工具
禅道：项目、用例和bug管理工具
JIRA
Bugzilla
Mantis
QC
4、bug管理流程【重点】
提单  ==》测试人员发现，并且把bug提交到禅道
仲裁  ==》在项目中有话语权的人
bug流程是怎么样的？
详细版：多名测试人员发现bug，提交到bug管理工具禅道，请测试经理规范审核，测试经理审核这个bug与之前是否重复了或者不是bug，如果时bug，指派给开发经理，开发经理指派给对应的开发，开发人员根据bug的优先级进行修复，开发如果发现不是bug指回给测试，优先级越高，bug越严重，开发修复好后指派给测试经理，测试经理根据bug对应人指派给测试，测试人员进行回归测试，如果有问题继续提交，如果没有问题关闭bug
简单版：测试发现问题提交给对应开发，开发发现不是bug，给回测试人员，如果是bug会根据bug优先级进行修复，修复好给回测试人员，测试人员进行回归测试，如果还有问题继续提交，如果没有关闭bug
5、bug有哪些等级
高中低 或者 是L1 L2 L3 L4 （致命 严重 一般 建议）
1级：致命错误、系统崩溃、死机、死循环、支付功能金钱受损失
例子：微信支付功能，输入10元，支付了20元
2级：次主体功能受损失
例子：支付功能输入密码时输入1次没反应，非要输入3次才支付成功，前后台数据不一致
3级：涉及到其他功能的正常使用
例子：返回键失灵，按钮点击失灵
4级：建议性bug
例子：颜色不一致，字体不一致
6、一条完整的bug应该包含哪些信息？
bug编号 ==》bug id
bug标题 ==》简单明了，是什么就是什么
bug等级 ==》（致命 严重 一般 建议）
bug的优先级  ==》高中低（1，2，3）
bug的重现步骤 ==》详细描述发现bug的步骤（包括测试数据）
bug的所属模块 ==》负责的模块
bug的附件      ==》截图或录视屏
bug的预期结果 ==》和需求保持一致
bug的实际结果 ==》测试结果
bug的所属版本 ==》v1.1
bug的创建人   ==》测试人
bug指派给谁   ==》对应开发
7、bug的状态（bug的生命周期）有哪些？
1）New:（新的）==》bug被发现
2）Assigned（已指派的） ==》开发人员接受此bug
3）Open（打开的）==》开发人员正在修复此bug
4）Fixed（已修复的）==》bug已经被修复完成
5）Pending Reset（待测试）==》按bug优先级进行测试
6）Reset（测试） ==》测试人员进行测试
7）Closed(关闭)==》bug已被修复
8）reopen(再打开) ==》测试时发现bug依然存在则重新打开

面试1：你提的问题开发不认可怎么办？
1）首先确定下这个bug是不是因为自己误操作导致，或者是环境导致的
2）然后看下需求有没有变更，开发和产品知道，测试不清楚
3）如果确实是bug，重现给开发看下，截图和录屏发给开发，并且站在用户角度和开发沟通清楚，bug确实不合理
4）如果还是不接受这个bug，就向产品经理和相关领导确认这个bug是否需要修改
面试2：偶现bug怎么处理
1）发现bug先截图，尽可能复现当时的场景，找到bug的规律
2）如果复现不了，先去看下后台日志，如果看到报错信息叫开发过来看下
3）如果验证过几次还是没有复现，先把这个问题反馈给领导，继续跟踪bug
面试3：你怎么去定位问题呢？（怎么区分是前端还是后端的bug呢？）
1）如果是前端样式和字体 颜色 布局问题则是前端问题
2）用抓包工具或者f12去定位问题，如果是请求参数有问题则是前端问题
3）如果是返回数据有问题，则是后端接口问题或者是数据库有问题
4）去服务器后台查看日志
面试4：你们是一家的bug流程是怎么样的？
详细版：多名测试人员发现bug，提交到bug管理工具禅道，请测试经理规范审核，测试经理审核这个bug与之前是否重复了或者不是bug，如果时bug，指派给开发经理，开发经理指派给对应的开发，开发人员根据bug的优先级进行修复，开发如果发现不是bug指回给测试，优先级越高，bug越严重，开发修复好后指派给测试经理，测试经理根据bug对应人指派给测试，测试人员进行回归测试，如果有问题继续提交，如果没有问题关闭bug
简单版：测试发现问题提交给对应开发，开发发现不是bug，给回测试人员，如果是bug会根据bug优先级进行修复，修复好给回测试人员，测试人员进行回归测试，如果还有问题继续提交，如果没有关闭bug
面试题5：你们bug一般包括哪些信息？
bug编号 ==》bug id
bug标题 ==》简单明了，是什么就是什么
bug等级 ==》（致命 严重 一般 建议）
bug的优先级  ==》高中低（1，2，3）
bug的重现步骤 ==》详细描述发现bug的步骤（包括测试数据）
bug的所属模块 ==》负责的模块
bug的附件      ==》截图或录视屏
bug的预期结果 ==》和需求保持一致
bug的实际结果 ==》测试结果
bug的所属版本 ==》v1.1
bug的创建人   ==》测试人
bug指派给谁   ==》对应开发

第8讲  人人乐项目实战
一、如何分析需求
1、显性需求：明确说的、公布的信息
比如：要求做一个聊天功能，包括 可以发语音，视频 图片等等
2、隐形需求：未说明，需要从中挖掘出来
例子：客户说只要产品质量好，价格无所谓  ==》客户的意思是物美价廉
例子：软件==》一个支付功能，输入正确的密码，点击确定按钮，支付成功
我们操作快速连续点击几次，看是否有多次支付的现象
3、特殊需求：计算方式，订单配送==》计算物流费用
4、关联需求：注册模块和登录模块
二、需求的特性：
1、完整性: 功能的实现和设计信息齐全
2、正确性：真实的反应用户意图
3、精确性：需求对每一项功能的描述必须可理解、充分、包括必要的信息
4、可行性：可通过公司的开发或者测试的前期验证
5、必要性：需求文档中无多余成分，每一个需求都是必要的
6、无二义性：需求中的功能或者业务解释具有唯一性，不要前面 这么说，后面又是不同解释
7、可验性：可以通过验证、模拟，实际能满足用户
三、从测试人员的角度看，在一个公司里，一个需求从出现到被澄清的过程？
1、需求来源：客户（公司会有专门的业务（需求人员）、产品 相关人员对需求进行跟进）
2、需求串讲（相关的开发和测试以及其他相关联的部门人员参 加会议,澄清会议由产品经理主讲需求相关的内容）
3、需求划分到每个人手里（按模块、按需求的内容进行划分）
4、各自需求负责人对各自需求进行阅读、梳理、分析（找出需求的缺陷、不明确的地方后续在需求会议中进行澄清）
5、直到需求澄清，后续工作围绕该需求进行开展


第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）需求不断变更
解决方案：
建议将需求变更文档化，对没有文档的需求变更，需要找负责人确认
测试差不多测试完了，若改动比较大，站在测试角度说明变更的功能对现有功能影响程度，如果影响大，建议下一个版本规划，如果还是要这样做，版本需要延期；如果改动比较小，可以接受，但是需要写在文档中