精华内容
下载资源
问答
  • 一个完整的测试计划模板
    万次阅读 多人点赞
    2019-04-12 15:55:20

    引言

    编写目的

    编号确定项目描述
    1确定测试范围确定被测项目中功能模块,子功能模块等需要测试的范围。
    2确定测试需求确定每个功能结果定义,确定此功能是否存在缺陷。
    3确定测试策略确定对项目做哪些测试。如:功能测试,性能测试等。
    4确定测试方法确定对每个策略是用哪些方法。如:边界值,等价类等。
    5确定测试工具如: 功能测试使用Seleium,性能测试使用Jmeter等。
    6确定测试资源测试需要的设备,服务器、参与测试的人员、测试任务的分工,测试工作的进度。
    7确定测试交付文档确定测试工作中生成哪些文档,可提交文档有哪些。

    测试项目

    项目名称: 某某系统
    使用背景: // 用户 协会分会负责人、期刊客户
    开发者: 中文集团 测试版本 2.0
    项目简介:
            学术专著出版平台” 定位是一家图书产品联合创建、销售、返利的平台;平台联合各专业协会、学会、出版社等机构,组织大批专家人才建立“专家指导委员会”,为图书进行策划、上报、审校、出版、运营等服务;主要业务情景是:策划人寻求参编人,共同创建图书及销售,参编人支付参编图书的预购款,该笔资金作为公司运营图书的成本,等待图书出版后,让消费者以个人名片或链接的形式进行购买图书,参编人员不仅可以通过图书评职称、扩大知名度、传播学术价值,另外让参编人通过销售,实现“0”元出书并且获得额外收入;策划人在发展参编和策划人同时,获得相应奖励。

    测试目的

    编号目的
    1软件测试是为了发现错误而执行程序的过程。
    2测试是为了证明程序有错,而不是证明程序无错。
    3一个好的测试用例在于它发现至今未发现的错误。
    4一个成功的测试是发现了至今未发现的错误的测试。

    文档受众

    编号人员原因
    1产品设计人员明确说明测试范围,方法,工作周期信息。
    2产品研发人员明确说明测试范围,方法,工作周期信息。
    3产品测试人员明确说明测试范围,方法,任务分工,预计完成时间。
    4备注此为内部开发文档,不做外部参考。

    测试参考文档

    编号文档名称作用
    1需求文档确定项目功能模块,功能运行结果。
    2技术文档确定项目中使用开发语言,数据库数据限制。
    3项目模型文档初步了解项目页面内容,方便编写用例。

    测试提交文档

    编号文档名称作用
    1测试计划明确说明测试范围,方法,工作周期信息。
    2测试用例明确说明测试工作的细节测试工作。
    3缺陷报告明确说明项目中的缺陷描述,与修复情况。
    4测试报告明确说明测试结果,测试模块,缺陷分布情况等等信息。

    术语定义

    项目术语

    缩写、术语解释

    测试专业术语

    软件测试类型
    单元测试开发者编写的一小段代码,检验被测代码的一个很小的、很明确的功能是否正确。
    集成测试开发者编写的多个段代码单元,组合到一起形成集成测试,检查多个单元组合功能是否正确。
    冒烟测试针对产品的基本功能进行测试。
    功能测试又称正确性测试,它检查软件的功能是否符合规格说明。
    可靠性测试对服务器施加一定压力,测试服务器是否可以长期稳定运行。
    压力测试对服务器施加一定压力后进行功能测试,测试服务器在一定压力下是够可以正常计算。
    负载测试对服务器施加压力,测试服务器可以容纳多少人访问,多少人访问后出现BUG。
    易用性测试主要从使用的合理性和方便性等角度对软件系统进行检查。用户来测.主观。
    兼容测试测试Web页面是否支持所有浏览器,访问后页面所有功能无异常。
    安全测试服务器数据安全性,用户数据安全性,用户操作安全性,用户财产安全性、公司财产安全性。
    数据完整性测试对数据及数据库能否正常运行访问的测试。
    回归测试开发修改后的BUG在测试一遍。

    缺陷优先级

    缺陷的优先级
    P0严重级别比较高的,影响测试进行或者系统无法继续操作,立即修复,1天。
    P1基本功能没有实现,对系统操作有影响,2-3天。
    P2一般性功能,页面缺陷,4-5天。
    P3准备在下一轮测试前修改完毕,准备在下一版本中修改。

    严重程度定义

    缺陷的严重程度
    S0数据丢失,数据计算错误、数据传递错误、对数据库造成破坏,造成操作系统或其他支撑系统崩溃、非正常关闭和非正常死机。
    S1应用系统崩溃、非正常关闭和无响应,但没有造成数据丢失。系统的主要功能不能正确实现或不完整。
    S2规定的非主要功能没有实现或不完整、影响系统的运行;设计不合理造成性能低下。
    S3不影响业务运行的功能问题。
    S4软件设计和功能实现等不完全合理之处提出建议。

    用例优先级定义

    用例优先级
    P0确保系统基本功能及主要功能的测试用例
    P1确保系统功能的完善方面的测试用例
    P2关于用户体验,输入输出的验证;较少使用或辅助功能的测试用例。

    测试策略

    单元测试

    单元测试
    测试目标开发者编写的一小段代码,检验被测代码的一个很小的、很明确的功能是否正确。
    测试范围测试整个项目中的每一行代码进行测试。
    完成标准代码的一个很小的、很明确的功能都正确。
    需考虑的特殊事项//
    使用工具Java + TestNG + eclipse + 程序相关依赖Jar 包。

    集成测试

    集成测试
    测试目标开发者编写的多个段代码单元,组合到一起形成集成测试,检查多个单元组合功能是否正确。
    测试范围开发者编写的多个段代码单元,组合到一起形成的集合。
    完成标准多个单元组合功能正确。
    需考虑的特殊事项//
    使用工具java + TestNG + eclipse + 程序相关依赖Jar 包。

    冒烟测试

    冒烟测试
    测试目标版本是否值得系统测试。
    测试范围1、返测上一版本提交的测试报告。
    2、测试系统的基本功能。
    完成标准基本功能通过,并继续测试。
    需考虑的特殊事项此阶段不超过1天。

    功能测试

    功能测试
    测试目标确保测试计划中所列出的测试范围,保证其功能正常。
    测试范围1、按照测试计划所规定的测试范围。
    2、利用有效的和无效的数据来执行各个用例、用例流或功能
    3、以核实以下内容:
    1)在使用有效数据时得到预期的结果。
    2)在使用无效数据时显示相应的错误消息或警告消息。
    完成标准按照测试计划的测试通过标准,完成测试。
    需考虑的特殊事项确定或说明那些将对功能测试的实施和执行造成影响的事项或因素。(内部的或外部的)
    使用工具Seleium + python + 火狐

    易用性测试

    易用性测试
    测试目标模拟真实用户,无经验用户,测试系统的易用性。
    测试范围前台
    完成标准成功地核实出前台各个网页符合可接受易用性标准。
    需考虑的特殊事项

    兼容测试

    兼容测试
    测试目标测试Web页面是否支持所有浏览器,访问后页面所有功能无异常。
    测试范围前台页面
    完成标准使用多个不同浏览器访问后界面无异常即为通过。
    需考虑的特殊事项浏览器版本;浏览器类型是否都测到。

    可靠性测试

    可靠性测试
    测试目标使用LR模拟真实用户对服务器施加一定压力。
    测试范围项目服务器。
    完成标准持续运行特定时间不出现问题。
    需考虑的特殊事项测试机是否满足需求。

    压力测试

    压力测试
    测试目标使用LR模拟真实用户对服务器施加压力。
    测试范围项目服务器。
    完成标准直到服务器卡死。获得服务器资源,最大与链接数等数据。
    需考虑的特殊事项测试机是否满足需求。
    使用工具Jmeter + fiddler + 火狐

    负载测试

    负载测试
    测试目标使用LR模拟真实用户对服务器施加一定压力,对服务器进行主要功能测试。
    测试范围项目服务器&前台界面。
    完成标准对服务器施加一定压力后前台功能正常,访问时间3-8之内。
    需考虑的特殊事项测试机是否满足需求。
    使用工具Jmeter + fiddler + 火狐

    数据完整性测试

    数据和数据库完整性测试
    测试目标确保数据库设计完整性。
    测试范围数据库及表结构。
    完成标准数据库约束、完整性等设置达到需求标准。
    需考虑的特殊事项数据遭到破坏,易恢复性。

    回归测试

    回归测试
    测试目标确保BUG修复的完整性。
    测试范围项目中出BUG 的部分。
    完成标准项目中出现的BUG完成修复,并将缺陷保存下来。
    需考虑的特殊事项出BUG的功能和BUG相关的功能都需要回测。

    功能测试范围

    模块功能应用策略备注

    测试规则

    进入准则

    编号测试策略进入准则
    1单元测试项目编码阶段,开发人员每编写完一个单元时进入测试。
    2集成测试项目编码阶段,开发人员每编写完多个单元时进入测试。
    3功能测试项目系统测试阶段,开发人员根据需求开发完成时,进入测试。
    4易用测试功能测试完成后进入测试。
    5兼容测试
    6可靠测试功能测试完成后进入测试。
    7压力测试
    8负载测试
    9数据完整性性能测试完成后进入测试。
    10回归测试提交的缺陷报告修改后。

    暂停/退出准则

    编号暂停标准
    1软件系统在进行单元、集成、确认、系统、安装、验收测试时,发现缺陷达到一定数量或出现重大错误导致无法测试时,暂停测试返回开发。
    2发生其他未知因素需要暂停时,测试应随之暂停,并备份暂停点数据。

    退出标准
    1|软件系统通过验收测试,并已得出验收测试结论,退出测试。

    测试资源

    硬件资源

    编号CPU内存硬盘系统软件
    12.54+100+Win7Jmeter,seleium,AppScan

    人力资源

    编号角色人员具体职责
    1确认需求明确需求
    2定制测试计划决定测试策略,人员分工,测试周期等。
    3准备测试环境测试工作开始前准备工作。
    4执行测试工作编写用例,执行用例,提交缺陷报告,回测等。
    5编写测试报告编写项目的测试结果。

    测试工作进度

    编号任务范围人员时间
    1确认需求2019-12-10 - 2019-12-15 = 5 天
    2定制测试计划
    3准备测试环境
    4单元测试
    5集成测试
    6冒烟测试
    功能测试
    兼容测试
    易用性测试
    7可靠性测试
    压力测试
    负载测试
    8安全测试
    9数据完整性测试
    10回归测试
    11编写测试报告

    系统风险

    系统风险

    1. 计划的测试时间,不能满足测试组的要求,主要是功能冻结后的系统测试的时间可能不够。
    2. 测试资源的及时到位(设备和人员)。
    3. 需求不明确可能导致开发的产品与目标不一致。
    4. 测试人员对测试工具的使用熟悉程序不够;
    5. 被测试产品存在重大错误,以至于测试无法继续,需要开发组进行额外的调试和修改才能继续;
    6. 硬件、软件或网络环境出现故障等。

    应急措施

    1. 如果上述潜在的可能事件发生,则通过适当加班来保证计划的按时完成。
    2. 如果是由于被测试产品存在重大错误而严重影响测试进度,则考虑按照测试暂停标准来暂停该测试。
    3. 如遇到功能需求不明确,需要沟通协商解决。
    4. 人员不足,则加班、或者进行不同组人员调动,按照测试进度完成测试任务。
      测试的完成标准

    单元测试完成标准

    • 按照单元测试计划完成了所有规定单元的测试
    • 达到了测试计划中关于单元测试所规定的覆盖率的要求
    • 软件单元功能与设计一致
    • 在单元测试中发现的错误已经得到修改,各级缺陷修复率达到标准

    集成测试完成标准

    • 按照集成构件计划及增量集成策略完成了整个系统的集成测试
    • 达到了测试计划中关于集成测试所规定的覆盖率的要求
    • 被测试的集成工作版本每千行代码必须发现至少2个错误(不含优化级别错误)
    • 集成工作版本满足设计定义的各项功能、性能要求
    • 在集成测试中发现的错误已经得到修改,各级缺陷修复率达到标准

    功能/易用测试完成标准

    • 功能测试用例设计已经通过评审
    • 按照功能测试计划完成了功能测试
    • 达到了功能测试计划中关于功能测试所规定的覆盖率的要求
    • 系统达到详细设计定义的各项功能,性能
    • 在功能测试中发现的错误已经得到修改,各级缺陷修复率达到标准
    • 兼容测试完成标准
    • 兼容测试用例设计已经通过评审
    • 按照兼容测试计划完成了兼容测试
    • 达到了兼容测试计划中关于兼容测试所规定的浏览器的要求
    • 在兼容测试中发现的错误已经得到修改,各级缺陷修复率达到标准

    系统测试完成标准

    • 系统测试用例设计已经通过评审
    • 按照系统测试计划完成了系统测试
    • 达到了测试计划中关于系统测试所规定的覆盖率的要求
    • 被测试的系统每千行代码必须发现至少1个错误(不含五级错误)
    • 系统满足需求规格说明书的要求
    • 在系统测试中发现的错误已经得到修改,各级缺陷修复率达到标准

    验收测试完成标准

    • 软件需求分析说明书中定义的所有功能已全部实现,性能指标全部达到要求。
    • 在验收测试中发现的错误已经得到修改,各级缺陷修复率达到标准
    • 所有测试项没有残余紧急、严重级别错误。
    • 需求分析文档、设计文档和编码实现一致。
    • 验收测试工件齐全(测试计划、测试用例、测试日志、测试通知单、测试分析)

    可靠/压力/负载测试完成标准

    • 性能测试用例设计已经通过评审
    • 按照性能测试计划完成了性能测试
    • 达到了性能测试计划中关于性能测试所规定要求
    • 在性能测试中不通过的用例已经得到修改,性能达到预计标准

    缺陷修复率标准

    • 紧急、严重级别错误修复率应达到100%
    • 普通级别错误修复率应达到95%以上
    • 优化级别错误修复率应达到60%以上
    • 注:项目紧急时,普通级别错误修复率达60%以上;优化级别错误修复率达20%即可。

    覆盖率标准

    • 测试用例执行覆盖率应达到100%(功能测试用例均以执行)
    • 测试需求执行覆盖率应达到100%(业务测试用例均以执行)
    更多相关内容
  • 软件测试计划

    2018-02-01 16:48:58
    测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外,清晰的文档结构能使任何一个读者在浏览计划的前面几页后,就能对项目有一个...
  • 测试计划

    千次阅读 2020-08-05 15:13:14
    一、 测试计划的定义与原则 1. 测试计划的定义 IEEE 829-1983 测试计划的定义及目的 一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了 测试项、被测特征、测试任务、人员安排以及任何偶发...

    一、 测试计划的定义与原则

    1. 测试计划的定义

    • IEEE 829-1983 测试计划的定义及目的
      • 一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了 测试项、被测特征、测试任务、人员安排以及任何偶发事件的风险。
      • 软件测试计划是指导测试过程的纲领性文档。计划可以统一认识,可以规划过 程。
      • 测试计划包含了产品概述、测试区域/测试范围(测试项)、 测试目标(被测 特征)、测试优先级、测试配置/测试资源<硬件、软件、人力、技术等>、测 试周期、进度安排(测试任务、人员安排)、 测试策略、测试方法/途径、测 试交流、风险分析、测试标准、需交付文档等内容。

    2. 测试计划进入与退出准则、责任人

    在这里插入图片描述

    3. 测试计划的编写原则

    • 为了做好软件测试计划,需要注意以下几个方面
      • 1、明确测试的目标,增强测试计划的实用性。
      • 2、坚持“5W”规则,明确内容与过程。
        • What(做什么)
        • Why(为什么做)
        • When(何时做)
        • Where(在哪里)
        • How(如何做)
      • 3、采用评审和更新机制,保证测试计划满足实践需求
        • 测试计划创建完毕后必须提交给由项目经理、开发经理、测试经理、市场 经理等组成的评审委员会审阅。
      • 4、测试计划中不要包含详细的测试技术指标、测试步骤和测试用例。
        • 测试计划和测试详细规格、测试用例之间是战略和战术的关系。

    4. 测试计划的主要工作

    • 确定测试资源
    • 工作量估算、里程碑和进度安排
    • 风险分析
    • 制定测试策略
    • 编写计划书

    二、确定测试资源

    1. 测试资源的分类

    在这里插入图片描述

    2. 测试资源的规划

    软件测试项目所需的人员和要求在各个阶段是不同的。

    • 在初期,测试组长首先要介入进去,参与需求评审、确定测试需求和测试范围、 制定测试策略和测试计划等。
    • 在测试前期,需要一些比较资深的测试设计人员、测试脚本或测试工具开发人 员参与或负责软件测试需求的制定和分解、设计测试用例、开发测试脚本等工 作。
    • 在测试中期,主要是测试的执行,测试人员的数量取决于测试自动化实现的程 度。如果测试自动化程度高,人力的投入则不需要明显的增加:如果测试自动 化程度低,对执行测试的人员要求就比较多了。
    • 在测试后期,资深的测试人员可以抽出部分时间去做新项目的准备工作。

    三、工作量估算、里程碑和进度安排

    1. 测试工作量估计

    1.1 怎么确定测试工作量

    测试的工作量是根据测试范围、测试任务和开发阶段来确定的。

    • 团队工作效率越低,测试工作量越大。
    • 测试的质量要求越高,测试的工作量越大。
    • 不同的开发阶段的测试工作量的差异也较大。新产品第一个版本的测试的工作 量要大一些,若后续版本功能增加加多,则后续版本测试量变大。
    • 编程质量越低,测试的工作量越大。
    • 程序复杂度越高,测试的工作量越大。
    • 之前测试的缺陷多且分布很广,测试工作量大。
    • 风险越多,等级越高,测试工作量越大。
    • 自动化程度越低,测试工作量越高。但是在很多情况下,测试自动化并不能大 幅度降低工作量,因为测试脚本开发的工作量很大。

    1.2 任务细分

    工作分解结构表方法

    • 列出本项目需要完成的各项任务。
    • 对每个任务进一步细分,可进行多层次细分,直到不能细分为止。
    • 根据任务的层次给任务进行编号。

    案例
    在这里插入图片描述

    1.3 测试工作量估算

    案例

    • 考虑回归测试(如 2-3 轮)
      • W= Wo+WoRl+WoR2+Wo*R3
        • W 为总工作量,Wo 为一轮测试的工作量。
        • 在代码质量相对较低的情况下,假定 Rl、R2、R3 的值分别为 80%、 60%、40%,若一轮功能测试的工作量是 100 个人日,则总的测试工 作量为 280 个人日。
        • 如果代码质量高,一般只需要进行两轮的回归测试,Rl、R2 值也降 为 60%、30%,则总的测试工作量为 190 个人日,工作量减少了 32% 以上。

    2. 测试里程碑和进度安排

    2.1 里程碑

    • 一般一个里程碑标志着上一个阶段结束、下一个阶段开始,也就是定义当前阶段完
      成的标准(Entry Criteria)和下一个新阶段启动的条件或前提(Entry Criteria)。

    2.2 里程碑的特点

    • 里程碑具有很强的时序性,可以有层次(分为父里程碑、子里程碑等)。
    • 不同类型的项目,里程碑可能不同。
    • 不同规模项目的里程碑,其数量的多少不一样,里程碑可以合并或分解。

    2.3 软件测试中常见的里程碑

    测试计划签发、测试用例签发、自动测试脚本完成、功能测试完成、性能测试完成 等。

    2.4 进度安排

    进度安排就是确定里程碑的起止点。
    案例
    在这里插入图片描述

    四、 测试风险分析与管理

    对软件测试中的风险进行管理,基本内容有:风险识别、风险评估和风险控制。

    1. 风险识别

    • 建立风险项目检查表,将测试范围、测试过程中的风险识别出来,按风险内容进行 逐项检查、逐个确认,确定哪些是可避免的风险,哪些是不可避免的,对可避免的 风险要尽量采取措施去避免。

    案例
    在这里插入图片描述

    2. 风险评估

    从成本、进度及性能三个方面对风险进行评估,通过评估可以确定这些风险的特点或可 能带来的危害,根据风险发生的概率和带来的影响确定风险的优先级。

    3. 风险控制

    • 制定风险管理计划和风险应急处理方案,来降低风险和消除风险。
    • 对风险的处理还要制定一些应急的、有效的处理方案。
    • 做计划时,估算资源、时间、预算等要留有余地,不要用到 100%。
    • 制定文档标准,并建立一种机制,保证文档及时产生。对所有工作多进行互相审查, 及时发现问题。
    • 案例
      在这里插入图片描述

    五、 制定测试策略

    1. 什么是测试策略

    • 描述当前测试项目的目标和所采用的测试方法;
    • 描述在规定的时间内哪些测试内容要完成,软件产品的特性或质量在哪些方面得到 确认;
    • 描述测试不同阶段(单元测试、集成测试、系统测试)的测试对象、范围和方法;
    • 描述每个阶段内所要进行的测试类型(功能测试、性能测试、压力测试等)。

    2. 案例

    分阶段的测试策略

    • 严格执行代码复查,保证在早期就发现问题,而非在代码发布之后。
    • 利用单元测试和集成测试,尽早地发现更多的问题,并准备好自动化测试的 BVT (Build Verification Test,软件包验证测试)。
      • BVT 是开发人员检入自己的代码,项目组编译生成当天的版本后进行的 测试,主要目的是验证最新的软件版本在功能上是否完整,主要的软件特 性是否正确实现。冒烟测试通过后,就可以进行更大规模的测试了。
      • BVT 优点是时间短,缺点是覆盖率很低。BVT 测试也称“冒烟测试”。
    • 不能忽略安全性测试、可用性测试、配置测试和数据完整性测试。
    • 在功能性测试、安全性测试、配置测试中可进行一些探索性测试。
    • 制定更为详细的 UAT(用户验收测试)测试计划,将其与测试脚本和培训材 料一起提供给用户,以帮助用户快速提高并完成任务。

    六、编写测试计划书

    • 测试计划是一个过程,不仅仅是“测试计划书”这样一个文档,测试计划会随着情 况变化不断进行调整,以便于优化资源和进度安排,减少风险,提高测试效率,并 及时修改“测试计划书”。
    • 测试计划书的内容也可以按集成测试、系统测试、验收测试等阶段去组织。
    • 为每一个阶段制定一个计划书,还可以为每个测试任务,目的(安全性测试、性能 测试、可靠性测试等)制定特别的计划书。
    • 对于一些重要的项目,会形成一系列的计划书,如测试范围,风险分析报告、测试 标准工作计划、资源和培训计划、风险管理计划、测试实施计划、质量保证计划等。
    展开全文
  • 编写本测试计划的目的是为整个测试阶段的管理工作和技术工作提供指南;同时确定测试的内容和范围,为评价系统提供依据;此外还帮助用户安排测试活动,说明对设备器材和机构人员的资源需求;说明测试结果的评价指标。...
  • 为了验证图书管理系统的图书管理模块能否正常实现,以图书管理系统作为测试对象,展开系统测试。 2.背景 图书管理系统包括图书录入、图书修改、图书删除、图书查询等九个子系统,用于管理图书馆日常运作的整个过程...
                               《图书管理系统》
    

    一、简介
    1.目的
    为了验证图书管理系统的图书管理模块能否正常实现,以图书管理系统作为测试对象,展开系统测试。
    2.背景
    图书管理系统包括图书录入、图书修改、图书删除、图书查询等九个子系统,用于管理图书馆日常运作的整个过程。各子系统所处理的业务前后衔接,数据共享。
    在这里插入图片描述

    3.范围
    1.图书管理模块

    二、测试需求
    1.数据库测试;
    2.功能性测试;
    3.性能测试;

    三、测试风险
    1.质量需求或产品的特性理解不准确,造成测试范围分析的误差,结果某些地方始
    终测试不到或验证的标准不对。
    2.测试用例没有得到百分之百的执行,如有些测试用例被有意或无意的遗漏。
    3.需求的临时或突然变化,导致设计的修改和代码的重写,测试时间不够。
    4.测试用例设计不到位,忽视了一些边界条件、深层次的逻辑、用户场景等。
    5.测试环境,一般不可能和实际运行环境完全一致,造成测试结果的误差。
    6.有些缺陷出现频率不是百分之百,不容易被发现;如果代码质量差,软件缺陷很
    多,被漏检的缺陷可能性就大。
    前面三种风险是可以避免的,而 4~6 的四种风险是不能避免的,可以降到最低。最后
    一种回归测试风险是可以避免,但出于时间或成本的考虑,一般也是存在的。
    针对上述软件测试的风险,有一些有效的测试风险控制方法,如:
    测试环境不对可以通过事先列出要检查的所有条目,在测试环境设置好后,由其他人员53
    按已列出条目逐条检查。
    有些测试风险可能带来的后果非常严重,能否将它转化为其他一些不会引起严重后果的
    低风险。如产品发布前夕,在某个不是很重要的新功能上发现一个严重的缺陷,如果修正这
    个缺陷,很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大,对
    策是去掉那个新功能,转移这种风险。
    有些风险不可避免,就设法降低风险,如“程序中未发现的缺陷”这种风险总是存在,
    我们就要通过提高测试用例的覆盖率(如达到 99.9%)来降低这种风险。
    为了避免、转移或降低风险,事先要做好风险管理计划和控制风险的策略,并对风险的
    处理还要制订一些应急的、有效的处理方案。

    四、测试策略
    1.数据和数据库完整性测试
    数据库和数据库进程应作为<项目名称>中的子系统来进行测试。在测试这些子系统时,
    不应将测试对象的用户界面用做数据的接口。对于数据库管理系统(DBMS),还需要进行
    深入的研究,以确定可以支持以下测试的工具和方法。数据库测试如表 2-2 所示。
    表 2-2 数据库测试说明

    发布文章的话表格不能直接复制到上面(下边那些有的, 都是带表格的是表格里的数据),想要带有表格的标准格式就下载一下我发布过的资源,软件测试——图书管理系统的测试计划书吧

    在这里插入图片描述

    测试目标
    确保数据库访问方法和进程正常运行,数据不会遭到损坏。
    方法
     调用各个数据库访问方法和进程,并在其中填充有效的和无效
    的数据或对数据的请求。
     检查数据库,确保数据已按预期的方式填充,并且所有数据库
    事件都按正常方式出现:或者检查所返回的数据,确保为正当
    的理由检索到了正确的数据:
    完成标准 所有的数据库访问方法和进程都按照设计的方式运行,数据没有遭
    到损坏。

    需考虑的特殊事项
     测试可能需要 DBMS 开发环境或驱动程序以便在数据库中直
    接输入或修改数据、
     进程应该以手工方式调用。
     应使用小型或最小的数据库(其中的记录数很有限)来使所有
    无法接受的事件具有更大的可见性。

    2.功能测试
    测试对象的功能测试应该侧重于可以被直接追踪到用例或业务功能和业务规则的所有
    测试需求。这些测试的目标在于核实能否正确地接受、处理和检索数据以及业务规则是否正
    确实施。这种类型的测试基于黑盒方法,即通过图形图书管理界面与应用程序交互并分
    析输出结果来验证应用程序及其内部进程。表 2-3 列出的是每个应用程序推荐的测试方法概
    要。
    表 2-3 功能测试说明表

    测试目标 确保测试对象的功能正常,其中包括数据添加、修改、删除和查询。
    方法 利用有效的和无效的数据来执行各个用例、用例流或功能,以核实
    以下内容:
     在使用有效数据时得到预期的结果。
     在使用无效数据时显示相应的错误消息或警告消息。
     各业务规则都得到了正确的应用。
    完成标准
     所计划的测试已全部执行。
     所发现的缺陷已全部解决。
    需考虑的特殊事项
    确定或说明那些将对功能测试的实施和执行造成影响的事项或因素
    (内部的或外部的)。

    3.性能评价
    性能评价是一种性能测试,它对响应时间、事务处理速率和其他与时间相关的需求进行
    评测和评估。性能评价的目标是核实性能需求是否都已满足。实施和执行性能评价的目的是
    将测试对象的性能为当做条件(如工作量或硬件配置)的一种函数来进行评价和微调。性能
    测试如表 2-6 所示。
    注:以下事务均指“逻辑业务事务”。这种事务被定义为将由系统的某个主角通过使用
    测试对象来执行的特定用例,例如,添加或修改某个合同。
    表 2-6 性能测试说明表

    测试目标
    核实所指定的事务或业务功能在以下情况下的性能行为:
     正常的预期工作量。
     预期的最繁重工作量。

    方法
    使用为功能或业务周期测试制定的测试过程。
    通过修改数据文件来增加事务数量,或通过修改脚本来增加每项事
    务的迭代次数。
    脚本应该在一台计算机上运行(最好是以单个用户、单个事务为基
    准),并在多台客户机(虚拟的或实际的客户机,请参见下面的“需
    考虑的特殊事项”)上重复。

    完成标准  单个事务或单个用户:在每个事务所预期或要求的时间范围内
    成功地完成测试脚本,没有发生任何故障。
     多个事务或多个用户:在可接受的时间范围内成功地完成测试
    脚本,没有发生任何故障。
    需考虑的特殊事项
    综合的性能测试还包括在服务器上添加后台工作量。
    可采用多种方法来执行此操作,其中包括:
    直接将“事务强行分配到”服务器上,这通常以“结构化查询
    语言”(SQL)调用的形式来实现。
    通过创建“虚拟的”用户负载来模拟许多个(通常为数百个)56
    客户机。此负载可通过“远程终端仿真”(Remote Terminal Emulation)
    工具来实现。此技术还可用于在网络中加载“流量”。
    使用多台实际客户机(每台客户机都运行测试脚本)在系统上
    添加负载。
    性能测试应该在专用的计算机上或在专用的机时内执行,以便
    实现完全的控制和精确的评测。
    性能测试所用的数据库应该是与实际大小相同或等比例缩放的
    数据库。

    五、测试工具
    此项目将使用表 2-14 所示的工具。
    注:可以视情况删除或添加项目。
    表 2-14 测试工具
    工具 厂商 版本

    测试管理 Quality Center HP
    10.0

    功能性测试
    QTP
    HP
    12.0

    性能测试
    LoadRunner
    HP
    12.0

    六、资源
    1.人力资源
    表 2-15 列出了在此项目的人员配备方面所做的各种假定。
    表 2-15 人力资源说明表

    人力资源
    角色
    推荐的最少资源 具体职责或注释

    测试组长
    1 负责拟订软件项目的测试计划和方案,提供
    测试技术指导,组织测试资源,安排测试计
    划实施,提交测试分析报告,总结整个测试
    活动。

    测试设计员 1 参与制订测试计划,生成测试模型,在面向
    对象的设计系统中确定并定义测试类的操
    作、属性和关联关系。
    确定测试用例,指导测试实施,参与测试评
    估和测试分析报告的编写。
    测试员
    1 执行实施测试,填写测试记录,记录结果和
    缺陷。

    2.系统资源
    表 2-16 列出了测试项目所需的系统资源。
    此时并不完全了解测试系统的具体元素。建议让系统模拟生产环境,并在适当的情况下
    减小访问量和数据库大小。

    表 2-16 系统资源说明表

    系统资源
    服务器名 172.16.112.177
    数据库名 sa
    客户端测试 PC 172.16.112.177

    七、测试进度和里程碑
    1.项目测试进度
    以下测试工作任务的起止时间为:
    ① 图书录入功能
    ② 图书修改功能
    ③ 图书删除功能
    ④ 图书查询功能

    2.测试里程碑
    对<项目名称>的测试应包括上面各节所述的各项测试的测试活动。应该为这些测试确
    定单独的项目里程碑,如表 2-17 所示,以通知项目的状态和成果。
    表 2-17 测试里程碑说明表
    里程碑任务 工作量 开始日期 结束日期
    图书录入功能
    图书修改功能
    图书删除功能
    图书查询功能

    八、可交付工件
    这部分内容列出了将要创建的各种文档、工具和报告,及其创建人员、交付对象和交付时间。例如,测试计划说明书、测试用例或测试脚本、开发的测试工具、测试日志、缺陷报
    告、测试分析报告、测试总结等。
    (1)概述
    ① 测试目的
    提供一个对项目软件进行测试的总体安排和进度计划,确定现有项目的信息和应测试的
    软件标明推荐的测试需求(高层次)和可采用的测试策略,并对这些策略加以说明确定所需
    的资源,并对测试的工作量进行估计,列出测试项目的可交付元素。
    ② 测试范围
    描述测试的各个阶段,例如,单元测试、集成测试或系统测试,并说明本计划所针对的
    测试类型(如功能测试或性能测试)。简要地列出测试对象中将接受测试或将不接受测试的
    些特性和功能。
    如果在编写此文档的过程中做出的某些假设可能会影响测试设计、开发或实施,则列出
    所有这些假设。列出可能会影响测试设计、开发或实施的所有风险或意外事件。列出可能会
    影响测试设计、开发或实施的所有约束。
    ③ 限制条件
    a. 设备所用到的设备类型、数量和预定使用时间。
    b. 软件列出将被用来支持本项测试过程而本身又并不是被测软件的组成部分的软件,
    如测试驱动程序、测试监控程序、仿真程序、桩模块等。
    c. 列出在测试工作期间预期可由用户和开发任务组提供的工作人员的人数。技术水平
    及有关的预备知识,包括一些特殊要求,如倒班操作和数据输入人员。
    ④ 参考文档
    列出制作此测试计划所依据的文档,例如,需求规约、设计规约,概要或详细设计、业
    务流程、数据流程等。列出要用到的参考资料。
    (2)测试摘要
    ① 测试目标
    ② 资源和工具
    a. 资源
    项目使用的资源,及其主要职责、知识或技能。
    b. 工具
    列出测试所使用的测试工具或自主开发的测试软件,说明运用这些工具或开发软件测试
    对象的何种特性。
    ③ 送测要求
    ④ 测试种类
    (3)测试风险
    (4)暂停标准和再启动要求
    (5)测试任务和进度
    列出要测试中的每一项测试内容,例如:
    模块功能测试;
    接口正确性测试;
    数据文件存取的测试;
    运行时间的测试;
    设计约束和极限的测试等。
    并针对每项测试内容给出测试条件,如:
    所用到的设备、数量和预定使用时间;
    给出对这项测试的进度安排,包括进行测试的日期和工作内容(如熟悉环境、培训、准
    备输入数据等)。
    (6)测试提交物
    ① 测试计划
    ② 测试用例
    ③ 缺陷记录
    ④ 测试总结

    展开全文
  • 测试开发之测试计划

    千次阅读 2021-07-25 05:58:09
    一、 测试计划的定义与原则1 测试计划的定义IEEE 829-1983 测试计划的定义及目的 一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排以及任何偶发事件的...

    一、 测试计划的定义与原则

    1 测试计划的定义

    IEEE 829-1983 测试计划的定义及目的

     一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排以及任何偶发事件的风险。

     软件测试计划是指导测试过程的纲领性文档。计划可以统一认识,可以规划过程。

     测试计划包含了产品概述、测试区域/测试范围(测试项)、 测试目标(被测特征)、测试优先级、测试配置/测试资源、测试周期、进度安排(测试任务、人员安排)、 测试策略、测试方法/途径、测试交流、风险分析、测试标准、需交付文档等内容。

    2 测试计划进入与 退出 准则、 责任人

    d978b8adecae855ddd0c5986e68f6d96.png

    3 测试计划的编写原则

     为了做好软件测试计划,需要注意以下几个方面

    1、明确测试的目标,增强测试计划的实用性。

    2、坚持“5W”规则,明确内容与过程。

     What(做什么)

     Why(为什么做)

     When(何时做)

     Where(在哪里)

     How(如何做)

    3、采用评审和更新机制,保证测试计划满足实践需求

    测试计划创建完毕后必须提交给由项目经理、开发经理、测试经理、市场经理等组成的评审委员会审阅。

    4、测试计划中不要包含详细的测试技术指标、测试步骤和测试用例。

    测试计划和测试详细规格、测试用例之间是战略和战术的关系。

    4 测试计划的主要工作

     确定测试资源

     工作量估算、里程碑和进度安排

     风险分析

     制定测试策略

     编写计划书

    二、 确定测试资源

    1 测试资源的分类

    04749219f08c247ad229e7c0cf3d3338.png

    2 测试资源的规划

    软件测试项目所需的人员和要求在各个阶段是不同的。

     在初期,测试组长首先要介入进去,参与需求评审、确定测试需求和测试范围、制定测试策略和测试计划等。

     在测试前期,需要一些比较资深的测试设计人员、测试脚本或测试工具开发人员参与或负责软件测试需求的制定和分解、设计测试用例、开发测试脚本等工作。

     在测试中期,主要是测试的执行,测试人员的数量取决于测试自动化实现的程度。如果测试自动化程度高,人力的投入则不需要明显的增加:如果测试自动化程度低,对执行测试的人员要求就比较多了。

     在测试后期,资深的测试人员可以抽出部分时间去做新项目的准备工作。

    三、 工作量估算、里程碑和进度安排

    1 测试工作量估计

    1.1 怎么确定测试工作量

     测试的工作量是根据测试范围、测试任务和开发阶段来确定的。

     团队工作效率越低,测试工作量越大。

     测试的质量要求越高,测试的工作量越大。

     不同的开发阶段的测试工作量的差异也较大。新产品第一个版本的测试的工作量要大一些,若后续版本功能增加加多,则后续版本测试量变大。

     编程质量越低,测试的工作量越大。

     程序复杂度越高,测试的工作量越大。

     之前测试的缺陷多且分布很广,测试工作量大。

     风险越多,等级越高,测试工作量越大。

     自动化程度越低,测试工作量越高。但是在很多情况下,测试自动化并不能大幅度降低工作量,因为测试脚本开发的工作量很大。

    1.2 任务细分

    工作分解结构表方法

     列出本项目需要完成的各项任务。

     对每个任务进一步细分,可进行多层次细分,直到不能细分为止。

     根据任务的层次给任务进行编号。

    案例

    1.3 测试工作量估算

    案例

     考虑回归测试(如 2-3 轮)

     W= Wo+WoRl+WoR2+Wo*R3

     W 为总工作量,Wo 为一轮测试的工作量。

     在代码质量相对较低的情况下,假定 Rl、R2、R3 的值分别为 80%、60%、40%,若一轮功能测试的工作量是 100 个人日,则总的测试工作量为 280 个人日。

     如果代码质量高,一般只需要进行两轮的回归测试,Rl、R2 值也降为 60%、30%,则总的测试工作量为 190 个人日,工作量减少了 32%以上。

    2 测试里程碑和进度安排

    2.1 里程碑

     一般一个里程碑标志着上一个阶段结束、下一个阶段开始,也就是定义当前阶段完成的标准(Entry Criteria)和下一个新阶段启动的条件或前提(Entry Criteria)。

    2.2 里程碑的特点

     里程碑具有很强的时序性,可以有层次(分为父里程碑、子里程碑等)。

     不同类型的项目,里程碑可能不同。

     不同规模项目的里程碑,其数量的多少不一样,里程碑可以合并或分解。

    2.3 软件测试中常见的里程碑

     测试计划签发、测试用例签发、自动测试脚本完成、功能测试完成、性能测试完成

    等。

    2.4 进度安排

     进度安排就是确定里程碑的起止点。

     案例

    5c74898fb685c2261f457f2e90c0f0d0.png

    四、 测试风险分析与管理

    对软件测试中的风险进行管理,基本内容有:风险识别、风险评估和风险控制。

    1 风险识别

     建立风险项目检查表,将测试范围、测试过程中的风险识别出来,按风险内容进行

    逐项检查、逐个确认,确定哪些是可避免的风险,哪些是不可避免的,对可避免的

    风险要尽量采取措施去避免。

    案例

    2 风险评估

    从成本、进度及性能三个方面对风险进行评估,通过评估可以确定这些风险的特点或可

    能带来的危害,根据风险发生的概率和带来的影响确定风险的优先级。

    3 风险控制

     制定风险管理计划和风险应急处理方案,来降低风险和消除风险。

     对风险的处理还要制定一些应急的、有效的处理方案。

     做计划时,估算资源、时间、预算等要留有余地,不要用到 100%。

     制定文档标准,并建立一种机制,保证文档及时产生。对所有工作多进行互相审查,

    及时发现问题。

    案例

    五、 制定测试策略

    1 什么是测试策略

     描述当前测试项目的目标和所采用的测试方法;

     描述在规定的时间内哪些测试内容要完成,软件产品的特性或质量在哪些方面得到

    确认;

     描述测试不同阶段(单元测试、集成测试、系统测试)的测试对象、范围和方法;

     描述每个阶段内所要进行的测试类型(功能测试、性能测试、压力测试等)。

    2 案例

     分阶段的测试策略

     严格执行代码复查,保证在早期就发现问题,而非在代码发布之后。

     利用单元测试和集成测试,尽早地发现更多的问题,并准备好自动化测试的

    BVT (Build Verification Test,软件包验证测试)。

     BVT 是开发人员检入自己的代码,项目组编译生成当天的版本后进行的

    测试,主要目的是验证最新的软件版本在功能上是否完整,主要的软件特

    性是否正确实现。冒烟测试通过后,就可以进行更大规模的测试了。

     BVT 优点是时间短,缺点是覆盖率很低。BVT 测试也称“冒烟测试”。

     不能忽略安全性测试、可用性测试、配置测试和数据完整性测试。

     在功能性测试、安全性测试、配置测试中可进行一些探索性测试。

     制定更为详细的 UAT(用户验收测试)测试计划,将其与测试脚本和培训材

    料一起提供给用户,以帮助用户快速提高并完成任务。

    六、 编写测试计划书

     测试计划是一个过程,不仅仅是“测试计划书”这样一个文档,测试计划会随着情

    况变化不断进行调整,以便于优化资源和进度安排,减少风险,提高测试效率,并

    及时修改“测试计划书”。

     测试计划书的内容也可以按集成测试、系统测试、验收测试等阶段去组织。

     为每一个阶段制定一个计划书,还可以为每个测试任务,目的(安全性测试、性能

    测试、可靠性测试等)制定特别的计划书。

     对于一些重要的项目,会形成一系列的计划书,如测试范围,风险分析报告、测试

    标准工作计划、资源和培训计划、风险管理计划、测试实施计划、质量保证计划等。

    展开全文
  • 说明:该篇博客是博主一字一码编写的,实属不易,请尊重原创,谢谢大家...一、测试计划的定义与原则 1.测试计划的定义 IEEE 829-1983 测试计划的定义及目的 √      一个叙述了预定的测试...
  • 测试方案/测试计划/测试报告

    千次阅读 2021-03-25 16:45:04
    测试方案和测试计划,测试报告几乎都是每个测试人员都必须掌握的。但有时经常搞混,特别是测试方案和测试计划。 测试方案和测试计划的区别 方案和计划英文翻译都叫“plan”,但具体的区别: 什么是测试计划?  ...
  • 测试计划模板-软件测试报告如何写

    千次阅读 2021-08-02 10:05:09
    2、测试概要:用表格的形式列出每一项测试的标识符及其测试内容,并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别,说明作出这种改变的原因。3、测试结果及发现:把本项测试中实际得到的动态输出...
  • 如何编写一份高质量的测试计划

    千次阅读 热门讨论 2021-05-17 15:01:54
    一、为何要编写测试计划? 1.1 编写测试计划的目的    编写测试计划是测试过程中非常有必要的高效手段,测试计划不仅仅能够带来效率的提升,更能从基础上保证测试质量,编写测试计划主要会有以下益处: (1)...
  • 软件测试计划范例

    热门讨论 2012-02-22 16:02:36
    软件测试计划的一个范例,用于软件测试计划阶段
  • 每个项目都应该有测试部门,测试就应该有测试计划,但应该先知道测试计划内容都应该有哪些,该怎么写?(本人初步认为内容应该有以下几点,下面的测试计划是一个简单的例子) 1. 概述 1.1 编写目的 1.2 项目背景 ...
  • 1小时轻松掌握测试计划编写

    千人学习 2019-09-25 15:47:01
    课程目录介绍 01_测试计划学习内容介绍 02_测试计划包含主要内容 03_云闪付项目的介绍 04_测试计划的目的和范围 05_测试计划的任务分配和进度安排 06_测试计划的测试策略 07_测试计划的风险分析 08_测试计划的验收...
  • 软件测试计划模板

    万次阅读 多人点赞 2017-12-22 16:06:53
    软件测试计划 第1章 引言 1.1目的 简述本计划的目的,旨在说明各种测试阶段任务、人员分配和时间安排、工作规范等。 测 试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使...
  • 软件测试管理—如何写好软件测试计划

    万次阅读 多人点赞 2018-06-16 20:59:19
    如何写好软件测试计划书 软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。 详细的测试计划可以帮助测试项目组之外的人...
  • 软件测试计划的主要内容

    千次阅读 2021-04-02 10:13:12
    每个公司的测试计划都不尽相同,但每个测试计划包含的主要内容又只有这几点,那我们一起研究一下测试计划的主要内容有哪些? 二、测试计划概念 测试计划(Testing plan)的定义: 描述了要进行的测试活动的范围...
  • 测试计划如何编写

    万次阅读 多人点赞 2018-03-27 20:42:11
    作为一个想成为leader(不论是整个测试部门还是小项目组的leader)的人,测试计划编写是必备技能。言归正传,直入主题。测试计划具体包含的内容包括以下:1、概述 1.1 项目标识项目编号项目名称项目类别■新建类 □...
  • 面试的时候,很多小伙伴都被面试官问过这个问题“测试计划和测试方案有什么区别”? 到底有什么区别呢?我们先好好了解下这两个文档。 一、测试计划 1、测试计划是什么 测试计划是组织管理层面的文件,从组织...
  • 系统测试计划

    千次阅读 2018-12-07 17:26:39
    系统测试是针对软件产品系统进行的测试(黑盒测试) ... 系统测试计划:完成系统测试计划。软件产品的需求规格确定后编写。 系统测试设计:完成系统方案。软件概要设计文档确定后编写。 系统测试实现...
  • 简单分享测试计划和测试报告,欢迎指导
  • 软件测试 | 测试计划包含什么内容

    千次阅读 2021-03-25 20:02:23
    测试计划每个公司都不一样,但是总有一些是相同的,那就是测试的人员时间安排。要知道包含什么内容,只需要明确计划的目的,即做什么,谁来做,多长时间做完。 测试计划主要包括:测试目标、测试对象、测试范围、...
  • 测试计划编写

    千次阅读 2020-06-03 18:56:13
    测试计划的目的 软件测试计划包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。 借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确...
  • 测试计划模板

    万次阅读 2018-03-12 16:53:12
    1、硬件配置:2、软件系统配置:包括系统软件和应用软件三、测试组组成及人力资源要求1、本项目的测试人员姓名及分工,指定测试负责人。2、需要配合的相关部门和人员四、测试的内容及步骤1、技...
  • 测试计划实例

    千次阅读 2019-04-08 18:33:00
    测试计划实例 xx系统 测试计划 文件版本:V1.0 目 录 1 引言. 1 1.1 编写目的. 1 1.2 预期读者. 1 1.3 参考资料. 1 1.4 项目概述. 1 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 458,897
精华内容 183,558
关键字:

测试计划