项目测试工作说明 PPT课件

1 项目测试工作说明 2 项目测试流程 项目立项 制订测试计划 软件开发设计文档 软件需求文档 测试用例设计 单元测试 集成测试 系统测试 测试执行 撰写测试报告 测试结果整理分析 研发经理审查 递交报告 系统达不到上线要求 测试退出 符合上线要求 3 项目现状 需求不清晰 由于客户对信息化系统接触较少 无法提供详细明确的业务需求 致使我们的需求人员对用户的需求无法进行鉴别 综合和建模 清除用户需求的模糊性 歧义性和不一致性 分析系统的数据要求 为原始问题及目标软件建立逻辑模型 软件设计不充分 依据需求文档 开发要将实际业务需求转化为软件功能需求 并出具详细的软件规格说明书 目前开发只提供差异化文档并未出具详细的软件功能设计说明文档 对功能实现没有一个完整开发业务逻辑说明功能实现不到位 可能由于开发周短或者公司缺乏技术底蕴或者使用某种框架技术的限制无法将功能做到完全满足功能需求 包括隐含的 或者易操作和人性化方面做的不足系统代码较脆弱 由于代码设计没有考虑周全以及缺乏异常处理机制 经常遇到报黄页 或者页面缓存太过严重等问题经常出现系统优化不彻底 随着项目的越来越多 一些老问题一直没有修改 一些功能需要重构一直没有重构 用户业务差异化太大 同一个业务不同的客户不同的功能需求 我们的系统配置项越来越多 4 如何做好我们的测试工作 我是一个业务专家 对目前的系统业务要熟练掌握 这个功能是干什么的 该功能有什么样的业务关联 这个操作会引发系统怎样的影响 这个功能有几种配置 每个配置都是基于什么样的功能场景 为什么有这样的功能操作逻辑 它的优势是什么 等等我是一个客户 我的角色就是一个客户 我要体验系统是不是很人性化 功能实现是不是符合我的要求 界面是不是一看就知道我得到了什么信息 如何去操作 一些重要操作是不是有提醒功能避免误操作或者提下一步操作提示 我是一个逻辑缜密的人 这个功能实现关联多个功能 他们是否能够协调正常工作 这个业务流程有多少个环节每个环节是否能够读取正确的数据 业务功能变更对前后关联的业务影响有多大 我是一个优化专家 功能实现是不是存在可以优化的地方 功能实现是否有漏洞存在影响用户的正常使用 功能实现是否存在不足可以 那些功能是冗余无用的 哪些功能尚未使用 我是一个追究思源的人 为什么功能这样实现 它的业务需求是什么 它的功能目标是什么 在一个什么样的业务场景下进行使用 它的使用对象是那些人 业务关联都那些人 5 测试计划 俗话说 凡事预则立 不预则废 不论做什么事 事先有准备 就能得到成功 不然就会失败 项目测试在实施前就要制订测试计划 测试计划Testingplan 描述了要进行的测试活动的范围 方法 资源和进度的文档 它确定测试项 被测特性 测试任务 谁执行任务 各种可能的风险 测试计划可以有效预防计划的风险 保障计划的顺利实施 测试计划编写6要素1 Why 为什么要进行这些测试 编写目的 2 What 测试哪些方面 不同阶段的工作内容 测试范围 测试目标 质量目标 3 When 测试不同阶段的起止时间 测试进度 4 Where 相应文档 缺陷的存放位置 测试环境等 参考文档 测试交付文档 软件资源 硬件资源 5 Who 项目有关人员组成 安排哪些测试人员进行测试 人力资源 6 How 如何去做 使用哪些测试工具以及测试方法进行测试 测试技术 测试策略 风险和约束 测试退出标准 6 测试执行 测试执行的内容包括功能测试 集成测试 系统测试 回归测试 功能测试 即某一单个功能的测试 功能测试的要点如下 功能实现满足用户需求 功能实现与需求及设计相一致 功能最优化 操作便捷不复杂 界面友好好理解 信息提示温馨易懂 功能健壮性 如格式校验 异常处理机制 缓存机制 必填项校验 功能权限 数据权限 操作权限 功能关联 输入数据来源 输入数据去向 功能操作逻辑 增删改查的操作顺序和操作条件 集成测试 多个功能融合在一起进行的测试 一般用于业务流程测试和业务关联测试 上一个功能的输出结果是否可以作为本次功能的输入上一个功能的输入结果是否可以作为本次功能操作可操作数据项之一最后一个功能的输出结果是否影响了上一个或上上一个功能的操作系统测试 系统的全部功能整合在一起进行的测试 其目的 校验功能的正确性 业务流程操作的正确性 数据流转的正确性 7 功能测试交付文档 功能测试交付单是测试人员对某一个功能测试完毕之后需要交付的一个文档 该文档描述了测试人员测试一个功能的全部过程 如业务了解度 测试点 业务逻辑 业务关联性 业务的待优化建议等内容 功能描述 对被测试功能进行概括介绍 功能操作逻辑 通过操作逻辑图反映该功能的增删改查及其他操作功能的顺序及操作条件功能关联业务 说明被测试功能相关联的业务功能测试结果 详细描述被测试功能的测试功能点及测试结果关联业务测试结果 详细描述被测试功能关联业务关联的正确性功能优化建议 对功能实现提出优化建议编写该文档的优势 规范测试人员的测试工作从文档中检测测试人员的测试是否完整将测试人员忽略的测试点找出来保证测试覆盖度的最大化检测测试人员对该功能的认知度 8 功能测试过程中我们应该做的 在功能测试过程中我们会遇到很多问题 如需求不明确 开发实现功能与需求或设计不相符等等 那么我们该如何解决呢 需求不明确 首先我们要找到需求人员了解该业务需求 其次要求需求人员在需求文档中补充该需求的详细内容或者要求需求人员通过邮件的形式告知测试以及开发人员该需求的详细内容功能实现与需求设计不一致 首先找到功能实现的开发人员确认不一致的原因 如果是经上面领导确认过的则需要找到项目负责人进行证实 并发送邮件进行告知变更原因及变更结果 如果是开发人员私自变更 可拒绝测试并通过发邮件告知项目负责人 隐含功能开发测试理解有误差 有些隐含功能开发实现与测试理解不一致 则可通过与开发人员沟通 若双方坚持已见且无认可的妥协方案 同需求及项目负责人进行协商 将最终的方案通过邮件进行告知功能优化 由于设计方案欠缺考虑导致实现的功能有许多的隐患问题 如操作不简便 页面不美观 没有达到引导客户操作的功效 提示信息不友好或者看不懂等 测试人员要给予优化的建议 特殊操作缺乏提示 如删除前的确认框提示 不可回退操作的确认提示 或者隐含生成其他记录的提示等更能体现我们系统的人性化功能交换测试 我们每个人都有自己的优势 是别人无法比拟的 有的人注重逻辑 有的人注重细节 有的人倾向于界面 一个功能的完整的测试不是一个人能完成的 功能交换测试能够最大程度的提高测试质量和测试覆盖度 9 功能测试过程中我们必须要注意的 一个系统有很多业务功能要进行测试 一个系统的功能也不是由一个人来完成测试工作的 因此 一个系统功能的测试由多个人进行分工完成的 在这样的情况下 有些测试人员可能只会测试自己负责的功能 不会关注别人测试的功能 这种测试态度是不正确的 测试人员和开发人员不一样 只知道自己负责开发的业务即可 熟悉系统业务是测试人员的基本技能 不是局部而是全部 一个测试人员具备了掌握全系统的业务你才可以做到 1 新功能设计上可以评估设计是否考虑周全2 清晰的知道哪些关联业务需要测试3 在新功能设计上给予指导性的建议4 你有资格成为一个业务专家5 提高测试覆盖度确保测试质量6 在整体业务把握的基础上提升测试思维的高度和测试意识7 分析定位系统Bug是什么原因造成的8 系统变更带来的影响和风险评估9 培养缜密的逻辑思维 做到举一反三 化整为零 聚零为整10 从软件业务领悟实际业务 实际业务转化软件业务 10 缺陷跟踪管理流程 发现缺陷 确认缺陷 提交缺陷 分析缺陷 测试主管 测试人员 提交缺陷 后续修改 修改缺陷 缺陷存档 项目经理 分配缺陷 开发人员 验证缺陷 测试人员 关闭缺陷 验证通过 验证不通过 后续缺陷修改 11 缺陷跟踪我们应该做的 缺陷跟踪是缺陷发现 提交 分配 修正 校验这样的一个过程 缺陷跟踪可以衡量一个测试人员的测试力度 也是保证软件质量一个重要环节 通过缺陷管理可以反应开发的质量 为软件上线提供依据 缺陷跟踪过程中我们应该做的如下 发现缺陷 能够定位缺陷的级别 缺陷修改的缓重轻急发现缺陷 能够分析缺陷产生的原因 方便开发修改缺陷定位问题所在发现缺陷 缺陷描述要简洁易懂 尽量不要给开发或他人造成误解或者不解提交缺陷 要分类汇总生成缺陷反馈文档提交缺陷 将缺陷反馈文档放置指定位置并通过邮件告知测试主管或测试负责人缺陷确认 通过缺陷描述确认该缺陷是否为真正的缺陷缺陷确认 要通过缺陷描述操作系统重现缺陷进行确认缺陷确认 确认该缺陷的级别 轻重缓解是否得当缺陷验证 确认开发修复缺陷是否正确缺陷验证 确认开发修复缺陷的同时是否产生了新的缺陷缺陷验证 验证通过的缺陷要及时修改缺陷的状态 必要时添加验证备注说明缺陷验证 将验证不通过的缺陷进行缺陷状态的修改 并通过邮件方式告知开发人员进行修改 并监督直至验证通过将未修复延期修复的缺陷进行整理一个单独的文档进行存放并通过邮件告知相关人员 12 缺陷跟踪我们必须要注意的 发现了缺陷 开发不认可 或者开发通过非正常手段来解决问题等等情况我们如何来应对来减缓测试和开发的这种敌对状态和通过什么样的方式来解决问题 开发不认可这是个缺陷 我们可以给开发讲为什么是缺陷 有什么样的严重后患来证明就是个缺陷 如果开发还是不认可 我们可上诉至测试主管和项目经理进行最后的确认 如果是缺陷开发必须进行修改 如果认为不是缺陷或者可延期修改 必须在缺陷反馈文档增加备注说明 并通过邮件的方式告知相关人员开发通过非正常手段修复缺陷 开发不是修改代码修复缺陷 而是隐藏代码掩盖了缺陷的重现操作等非正常手段间接修复缺陷 我们将此情况上诉至测试主管和项目经理 通过协调给予最终的解决方案 通过邮件方式将解决方案告知相关人按照方案开发进行修改 测试进行校验 并在缺陷修复备注给予说明开发迟迟不修改缺陷 对于已经确认并要修改的缺陷 开发迟迟不予修改 则测试人员需要时时询问缺陷修复的时间 如果时间拖的过久需要项目经理以邮件的方式进行告知缺陷修复的具体时间或近期不能修复的原因 开发修复缺陷出现后遗症 开发修复缺陷可能会引发新的缺陷的产生 因此要求我们在校验缺陷的同时 必须校验相关功能的其他操作是否正常 延期缺陷的追踪 有些缺陷被延期 可能由于相关方面的原因无暇顾及这些遗留缺陷而将缺陷一而再再而三的搁置最终不了了之 因此要定期的追踪项目经理遗留缺陷的修复工作 13 缺陷反馈文档 缺陷追踪管理有两种方式 通过缺陷管理工具进行管理 另外是通过缺陷文档进行管理 无论是缺陷管理工具还是缺陷文档 缺陷基本信息包括如下 缺陷位置 描述缺陷所在的功能模块菜单页面项目名称 缺陷出现的项目名称项目版本 缺陷出现在的项目的哪个版本当中缺陷标题 概括描述功能缺陷缺陷描述 描述缺陷产生的操作步骤导致的实际系统反应与期望结果不一致缺陷级别 缺陷的严重程度 改善性 一般 严重 致命 缺陷优先级 缺陷处理轻慢缓急度 有空改改 正常处理 高度重视 立即解决 提交时间 缺陷提交时间缺陷状态 已提交 已分配 待验证 已关闭 无效提交人 发现并条件缺陷的测试人员修改人 修复缺陷的开发人员修改时间 缺陷修复时间验证人 验证缺陷的人验证时间 验证缺陷的时间备注 填写缺陷从提交到验证过程中的重要说明 14 缺陷级别定义 改善性缺陷 由问题提出人对测试对象的改进意见或测试人员提出的建议 质疑 一般缺陷 次要功能没有完全实现但不影响使用 如提示信息不太准确 或用户界面差 操作时间长 模块功能部分失效等 打印内容 格式错误 删除操作未给出提示 数据库表中有过多的空字段等严重缺陷 系统的主要功能部分丧失 数据不能保存 系统的次要功能完全丧失 问题局限在本模块 导致模块功能失效或异常退出 如致命的错误声明 程序接口错误 数据库的表 业务规则 缺省值未加完整性等约束条件致命缺陷 造成系统或应用程序崩溃 死机 系统挂起 或造成数据丢失 主要功能完全丧失 导致本模块以及相关模块异常等问题 如代码错误 死循环 数据库发生死锁 与数据库连接错误或数据通讯错误 未考虑异常操作 功能错误等 15 项目需求变更流程 客户变更需求 内部变更需求 需求变更分析 变更影响分析 不变更说明书 需求变更会议讨论 变更解决方案 变更执行 变更存档 需求变更说明书 影响较大 影响较小 不变更 需求变更设计说明书 编码 测试 16 项目需求变更我们应该做的 项目变更是项目开发过程中经常遇到的不可控制的一种项目变动 项目变更管理的目的是以一种对于项目影响最小的方式改变现状 作为测试人员在需求变更阶段如何去做呢 了解需求变更的功能差异 被变更功能的现有功能是什么样子 和变更要求的差异化有多大 做到心中有数 为变更后的测试做好铺垫分析差异化对系统的影响范围 被变更功能按照变更需求变更后 相关联的业务是否能正常使用 需要修改多少关联业务 数据库的老数据如何去处理 给予变更建议方案 对于系统测试是最熟悉的 系统变更的风险和影响范围是最清楚的 所以测试有资格有义务去提供变更的解决方案 以最小的代价来满足变更需求 评估开发给予的解决方案是否可行 测试代表用户 客户的需求实现首先要得到测试人员的认可 如果解决方案不可行要给予不可行可通过邮件将不可行的理由告知测试主管和项目经理 准备测试方案应对变更测试 设计测试方案 确定测试的范围和测试功能点 将测试范围最大化 测试覆盖率最大化变更测试需缺陷追踪 同项目功能测试缺陷追踪 17 项目需求变更我们