6.2 测试策略&缺陷优先级

优先级的确定可以使测试任务更有目的的开展,
测试策略:为开展测试工作做的计谋和策略,

1.时间不够 只能测两个 将放弃优先级最低的模块
2.回归测试策略
影响性分析来决定回归测试的范围=
=代码影响性分析=因为开发改代码的时候,他会知道,可能因为改了这批代码,可能要影响到的功能

不愿提供怎么办
遇到过 测试人员 对质量要求非常高 市场用户对软件要求高 质量是最后底线 守好底线 公司才会更好的发展 产品才是硬核的实力
开发代码写的好 但质量意识可能不足 项目是整个团队的事情,
万一真出了问题,临近上线还得加班改加班测,所有的工作提前做好,项目顺利完成,
隐性需求 加权计算 自己设置 eg:10个隐性算1%
测试需求/(显性+隐形)开发需求*100=测试需求覆盖率(%)
冒烟测试:正式测试前进行,目的跑通程序主流程
敏捷所解决的问题:
给到测试的版本质量高
开发慢慢懂业务
开发质量意识提高,懂测试的重要性
坏处:
开发不懂其他功能,会出bug

流程:开发自测 见识到了 自己深深体会开发自测到的好处
越早修复缺陷成本越低

w模型:v&v validation(确认) and verification(检查)
需求分析是,带着开发或者测试去了解

客户-PM 需求文档-开发和测试 对需求进行讲解 开发 测试点
提测 冒烟 发现缺陷 禅道 开发修改 缺陷验证 回归测试

测试基础
测试目的:
发现软件缺陷
证明软件存在缺陷
缺陷预防(把缺陷降低到到一定程度,而不是彻底消灭)
最少用例,时间、人力找到错误和缺陷(2080)
回归测试:针对老功能
介绍cookie和session区别

cookie:登录问题 本地服务器文件 服务器文件 匹配上就能成功登录 保存在本地
session:

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
集成测试计划 版本:V1.3 文 档 编 号 保 密 等 级 作 者 最后修改日期 审 核 人 最后审批日期 批 准 人 最后批准日期 修订记录 日期 版本 修订说明 修订人 目 录 1 简介 3 1.1 目的 3 1.2 背景 3 1.3 范围 3 1.4 参考文档 3 2 测试约束 3 2.1 测试进出条件 3 2.1.1 进入条件 3 2.1.2 退出条件 3 2.2 测试通过和失败准则 3 2.2.1 通过准则: 3 2.2.2 失败准则: 4 2.3 测试启动/结束/暂停/再启动准则 4 2.3.1 测试启动准则 4 2.3.2 测试结束准则 4 2.3.3 测试暂停/再启动准则 4 3 测试需求 4 4 测试风险 5 5 集成策略 5 6 测试策略 5 6.1 策略描述 5 6.2 测试类型 5 6.2.1 功能测试 5 6.2.2 接口测试 6 6.2.3 容错测试 6 6.2.4 回归测试 6 6.3 测试轮数 7 7 测试资源 7 7.1 人力需求 7 7.2 测试环境 8 7.3 测试工具 8 8 测试进度 8 9 本阶段量化计划 9 10 交付物 9 简介 目的 【描述集成测试计划的编写目的及本次集成测试的主要目的。】 如,编写目的:本文档用于描述XXX开发项目集成测试所要遵循的规范以及确定测试方法、测试环境、测试用例的编写和测试整体进度的计划安排、人力资源安排等。 测试目的:集成测试的目的是测试组成XXX系统的各子模块间的接口及功能实现等。 背景 【描述项目或产品的背景。】 范围 【描述集成测试在项目的整体范围。如,需要集成的各功能模块的描述。】 参考文档 【描述本次集成测试所需要参考的文档。】 测试约束 【描述本次集成测试所要遵循的准则及条件约束等。】 测试进出条件 进入条件 【描述集成测试测试依据和满足该阶段测试进入的条件和约束。】 退出条件 【描述满足该阶段测试退出的条件,要根据 《项目量化管理计划》中第3节的内容来制定退出条件,例如 致命和严重级别的缺陷清除率达到 100%,致命和严重的缺陷修复率达到100%,一般缺陷的修复率达到99%并且遗留缺陷数小于5个;同时参考《测试过程》中的相关描述,并要求系统测试每轮发现的缺陷数量呈收敛趋势。】 测试通过和失败准则 通过准则: 【描述集成测试每一轮测试通过的条件。】 如,每轮测试所有用例全部执行完毕,且没有出现致命性错误,回归测试或执行新增测试用例时不再出现问题,则测试工作通过; 失败准则: 【描述集成测试某轮次测试失败的条件。】 如,每轮测试所有用例全部执行完毕,没有出现致命性错误,回归测试或执行新增测试用例时不再出现问题,且回归测试的周期不少于X天,回归测试执行的测试用例数比例不低于XX%,则测试工作通过。 测试启动/结束/暂停/再启动准则 测试启动准则 【描述集成测试执行启动的约束准则。】 如, 配置管理员提交给测试组每次build的正确版本及集成的模块清单。 测试环境通过检验之后。 测试结束准则 【描述集成测试执行结束的约束准则。】 如,测试案例全部执行完毕,测试结果证明系统符合需求,遗留的问题满足测试退出条件且在质量标准允许范围内,即可结束测试测试暂停/再启动准则 【描述集成测试执行过程中出现的特殊情况的约束准则。】 如,被测模块出现某个致命性错误。测试案例无法继续执行,测试工作需暂停,如果非关联模块可以进行测试则执行非关联模块的测试;当这些问题得到解决后重新启动该模块的测试工作。 测试需求 【根据系统集成构建计划,列举每次集成的新版本产生新的测试需求功能点,包括接口的测试需求。】 需求ID 模块 子模块 待测试功能需求点 优先级 模块一 子模块1 功能点1 功能点2 … 功能点N 子模块2 … 子模块N 测试风险 【此处描述测试任务可能遇到的风险,以及规避的方法】 风险 编号 风险描述 风险发生可能性 (高、中、低) 风险的影响程度 (高、中、低) 责任人 规避方法 集成策略 【描述集成的方法、集成的顺序和集成的环境。详细的集成环境见《环境配置清单-集成环境》 集成顺序一般有:深度优先、自下而上、自上而下等; 深度优先:即关键(主控路径上的)业务流程涉及到的模块先集成到一起,然后再集成辅助业务模块; 自下而上:即已实现的较底层的功能优先集成,然后逐层上升,形成整个系统; 自上而下:即事先存在一个稳定的架构,不断地向下细化,最后实现所有具体的功能细节; 集成顺序的选择可以是不同集成顺序的综合。 】 集成计划 【说明项目周期内计划执行的集成活动的时间安排】 集成次号 集成目标 被集成对象 计划集成时间 包含的接口 测试策略测试策略提供了对以上测试对象实施测试的方法。上一节“测试需求”中说明了将要测试哪些对象,而本节则要说明如何对这些测试对象进行测试。】 【对每一个工作版本将进行以下三种类型的测试:A、接口测试测试接口调用。B、功能测试测试工作版本应该实现的功能。C、回归测试,在新版本中执行以前集成版本的测试用例脚本。】 策略描述 【此处描述根据项目的具体特征所确定的集成测试策略(如:测试可行性分析,测试技术方法确定,测试类型选择以及集成的方案环境描述等】 测试类型 【此处描述集成测试选择的测试类型,一般建议有如下四种:】 功能测试 测试目标: 确保已经集成的工作版本的正确性,能够实现该集成版本应该具有的功能的正确性以及完整性。 技术: 重用为系统功能测试设计的部分测试用例,部分测试过程。生成测试脚本,实现测试自动化。 完成标准: 所计划的测试全部执行、 对以前版本的接口完成了回归测试、 所发现的高优先级缺陷和高等级的缺陷已完全解决。 需考虑的特殊事项: 开发人员应该保证每个后续的集成版本的基本界面元素都未改变。 考虑测试脚本的重用性以及自动化测试测试方法描述 【此处描述一个特定的测试类型在项目测试活动中如何具体的执行。】 接口测试 测试目标: 确保“测试需求”中对应的所有工作版本的内部单元组合到一起后能够按照设计的意图协作运行,接口的调用正确。 技术: 重用为系统测试准备的测试用例、 分析测试用例对接口的覆盖情况,对没有覆盖的接口设计足够的测试用例,以覆盖所有的调用接口。 为每个测试用例制定测试过程,生成测试脚本。以实现测试的自动化。 完成标准: 所计划的测试全部执行、 对以前版本的接口完成了回归测试、 所发现的高优先级缺陷和高等级的缺陷已完全解决。 需考虑的特殊事项: 开发人员应该保证每个后续的集成版本的基本界面元素都未改变。 考虑测试脚本的重用性以及自动化测试测试方法描述 【此处描述一个特定的测试类型在项目测试活动中如何具体的执行。】 容错测试 测试目标: 验证异常错误流程能顺利执行,并有易懂的提示信息 技术: 包含在上述功能和接口的测试用例设计中 完成标准: 对每一个非法的操作显示相应的错误信息或警告信息。 需考虑的特殊事项: 测试方法描述 【此处描述一个特定的测试类型在项目测试活动中如何具体的执行。】 回归测试 测试目标: 确保前一个集成的版本并未因为新版本的增量集成而带来缺陷。 技术: 在新的集成版本中使用前一个集成版本的自动化测试脚本执行自动化测试。 完成标准: 前一个集成版本的所用测试用例已全部执行。 所发现的缺陷已全部解决。 需考虑的特殊事项: 开发人员应该保证每个后续的集成版本的基本界面元素都未改变。 考虑测试脚本的重用性以及自动化测试测试方法描述 【此处描述一个特定的测试类型在项目测试活动中如何具体的执行。】 测试轮数 【根据集成计划确定的集成次数,计划整个产品开发周期内集成测试的次数】 测试资源 人力需求 【列出此项目的测试人员配备方面的需求。】  角色 人员 具体职责 测试经理 进行管理监督。 职责:          提供技术指导          获取适当的资源          提供管理报告 测试设计员   确定测试用例、确定测试用例的优先级并实施测试用例。 职责: 生成测试计划 生成测试模型 评估测试工作的有效性 测试员 执行测试。 职责: 执行测试 记录结果 从错误中恢复 记录变更请求 测试系统管理员 确保测试环境和资产得到管理和维护。 职责:管理测试系统    分配和管理角色对测试系统的访问权 数据库管理员 确保测试数据(数据库)环境和资产得到管理和维护。 职责:  管理测试数据(数据库)   测试环境 【列出了测试项目所需的系统资源。 】 资源 名称/类型 硬件和网路环境 数据库服务器 - 网络或子网 - 服务器名称 - 数据库名称 用户端测试 PC 包括特殊的配置需求 测试数据存储库 \\JJJ\Test\Data - 网络或子网 内部局域网 - 服务器名称 \\JJJ 测试开发 PC \\03824-1,\\02194-2,\\02336。 软件环境 DBMS 中间件 AppServer 浏览器 其它 测试工具 【本次测试将使用的工具】 用途 工具 厂商/自产 版本 测试管理 测试执行 缺陷报告 测试进度  【根据集成测试的轮次,分解测试工作,计算工作量(N:人数,M:工作日)。每一轮次任务均包括上轮次的回归验证工作】 编号 任务 工作量(人日) 开始日期 结束日期 制定测试计划 N*M 设计测试用例 执行测试(第一轮) 执行测试(第二轮) … 执行测试(第N轮) 最后一轮回归测试测试进行评估 合计工作量 交付物 【描述集成测试需要交付的工作产品】 交付物名称 责任人 参与者 交付日期 测试计划 测试用例 测试脚本 测试报告 。。。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值