精华内容
下载资源
问答
  • 软件测试方案

    2010-06-21 23:06:00
    [摘要] 随着软件系统规模和复杂度日益升高,越来越多的...有鉴于此,本文以CraftGS航天项目模型为例,系统地介绍了一套行之有效的软件测试方案,该方案对同类高可靠性软件项目测试工作的开展具有一定的参考意义和...
    [摘要] 随着软件系统规模和复杂度日益升高,越来越多的软件项目明确提出软件的可靠性要求。而涉及高可靠性软件开发的软件企业也越来越意识到,软件测试在这些项目开发过程中绝不是一种辅助性工作,而是从软件质量控制角度保证软件工程过程质量的最有效方法。有鉴于此,本文以CraftGS航天项目模型为例,系统地介绍了一套行之有效的软件测试方案,该方案对同类高可靠性软件项目测试工作的开展具有一定的参考意义和指导作用。 
      [关键词] 高可靠性 软件测试 软件验证技术 软件确认技术 软件测试管理
     1 引言 高可靠性软件泛指一类软件:该类软件运行过程中若出现故障会引发重大灾难性事故或经济损失。通常航天型号软件、银行系统软件、医疗行业软件、通讯行业软件等均属此范畴。目前,越来越多的软件企业涉及高可靠性软件项目,如何保证软件质量成为众多企业面临的一个很重要的课题。这篇文章结合某航天项目地面应用系统模型(本文命名为 CraftGS ),重点讨论如何从软件测试的角度保证此类产品的软件质量。
    2 CraftGS 项目简介
     CraftGS 是一个很经典的卫星地面应用系统模拟项目。它分为 5 个子系统:数据接收子系统 (DAS) 、数据预处理子系统 (DPS) 、运行管理子系统 (OMS) 、数据管理子系统 (DMS) 以及数据产品实现 (DPRS) 子系统。 CraftGS 的总体可靠度要求是 0.95 。各分系统分配到的可靠度指标是如下: 分系统名 可靠度指标 DAS 0.99994 DPS 0.99865 OMS 0.99910 DMS 0.99950 DPRS 0.99502 CraftGS 的业务逻辑是 Data Package 从卫星传入 DAS , DAS 负责解包,将解包后数据传入 OMS 及 DPS , OMS 通过 DAS 传来的数据检测卫星是否正常运行并负责卫星飞行姿态调整; DPS 负责调制 DAS 传来的数据,转换成有意义的逻辑数据。 DPS 处理后的逻辑数据传入 DMS 以及 DPRS 。其中 DMS 负责数据备份、数据查询及数据链路维护等操作; DPRS 负责将 DPS 处理过的逻辑数据分门别类地转换成数据产品,并封装发布。 考虑到项目固有的可靠性安全性要求, CraftGS 系统采用 Java+Unix 技术架构实现。该架构从编程语言级和系统级对软件产品质量做了保证。为了控制软件产品开发过程中的质量,笔者推荐采用如下软件测试方案。
     3 测试方案:软件验证技术 + 软件确认技术 + 软件测试管理
    CraftGS 系统的软件测试方案由三个部分组成,即软件验证技术、软件确认技术和软件测试管理技术。它们内涵及相互之间的关系如下图所示: CraftGS 测试方案 测试技术层面 测试管理层面 软件验证技术 需求规格说明验证 软件测试团队组织管理 设计规格说明验证 代码验证 软件测试计划管理 交付验证 软件确认技术 单元测试 软件缺陷(错误)跟踪管理 集成测试 系统测试 软件测试件管理 交付测试 其中,软件验证技术着眼于排除软件开发文档中的错误。验证活动涉及的文档按开发流程主要涉及需求规格说明、设计规格说明(包括概要设计规格说明、详细设计规格说明、数据库设计规格说明)、编码规格说明、产品交付文档等一系列书面材料。目前验证技术的实施在很大程度上是依靠测试人员手工完成的。验证活动视实际需要有时还会涉及到开发人员和目标客户,需要得到他们必要的理解和支持。
    验证测试采用的主要测试手段有:面对面质询、文档抽查、非正式会议、同行评审等等。 相对于软件验证技术,软件确认技术则主要着眼于排除程序代码中的错误。活动涉及的对象主要是程序部件的代码或软件成品。在实施过程中,常常按被测代码的规模和测试所处的层次将软件确认测试分为四个阶段,即:单元测试(也叫类测试)、集成测试(也叫组装测试)、系统测试和交付测试。确认测试基本上由软件测试人员对照相关开发文档运行程序独立完成的。必要时,也可让设计人员带领测试人员阅读程序代码共同发现其中的错误,(即所谓代码评审会)。有意见认为,在单元测试 ( 或类测试 ) 阶段,应该有软件编码人员参与,这样能减轻测试人员阅读代码障碍。原则上,测试理论不提倡程序作者负责把关自己编写的程序的质量。在实际实施过程中,可视实际情况灵活处理。(如成对编程可能会较好的处理单元测试这个难题,上面提到的代码评审会也是为应对这个难题而想出的一个好办法。),软件确认技术目前已经部分地实现了测试工具的自动化,市面上已有不少自动化工具能在测试人员的辅助下完成相应的测试工作(例如用于 Java 代码单元测试的 Junit 工具,又如用于 GUI 测试的 Rational Visual Test 工具,等等)。 软件验证技术和软件确认技术均属于测试技术层面的东西。然而对于工程质量的保证而言,光靠软件测试技术还远远不够,还需要技术管理层面上的东西。软件测试管理技术的诞生正是为弥补这个不足。按照管理的对象不同,测试管理技术大致涵盖软件测试团队组织管理、软件测试计划管理、软件缺陷(错误)跟踪管理以及软件测试件管理四大部分。下面,笔者将结合 CraftGS 项目对该测试方案做一个详细的诠释。
     4 在 CraftGS 项目中具体应用上述测试方案
    CraftGS 五个分系统的开发过程均在 CraftGS 测试团队的质量控制下有序进行,严格地实施了上述测试方案。经专家评定,各分系统及最后集成后的系统总体均达到了任务书中所分配的可靠性指标。
     4.1 在 CraftGS 项目中应用软件验证技术 CraftGS 项目中应用的软件验证技术主要包括需求规格说明验证、设计规格说明验证、代码验证以及交付验证。以下逐一说明。 需求规格说明验证的主要任务是保证用户的功能需求、业务需求、以及其他的一些需求(如非功能性需求、约束性需求等等)都已经被分配到软件需求规格说明的各需求项中。 设计规格说明验证相对需求规格说明验证而言,稍微复杂些,它包括 3 个部分的内容:即概要设计规格说明验证、详细设计规格说明验证以及数据库设计规格说明验证。其中概要设计规格说明验证的主要任务是确保软件需求规格说明中的需求项全部已经分配到了概要设计规格说明的各软件模块之中并且无多余物,详细设计规格说明验证的主要任务是确保概要设计规格说明中的模块已经全部分配到详细设计规格说明的各软件单元之中并且无多余物,数据库设计规格说明虽然从范畴上讲应该属于详细设计规格说明范畴,但笔者认为因改把它独立出来实施验证活动。(数据库设计和软件设计毕竟有很多不同之处。)数据库设计规格说明验证的重点任务是验证数据库与外部应用程序的接口是否正确、数据操作实现界面是否清晰、数据库整体设计是否合理、数据表设计是否符合 3NF 要求(如违反范式要说明详细理由)以及数据表中的字段(键)和索引的设计是否高效合理等等。完成设计规格说明以后,下一步要做代码验证。 代码验证的内容包括:代码编写规范审查、代码审查和代码静态分析三个部分。代码编写规范审查主要是审核代码排版的格式以及注解的格式是否符合开发团队的相应规范;代码审查的任务主要是验证详细设计中的软件单元是否都已被代码覆盖并正确实现,并且代码中不含冗余物;代码静态分析技术主要任务是检查变量或标号的定义与使用、表达式运算以及程序的流程设计上是否存在缺陷或错误。 做完代码验证以后,软件系统需要依次做单元测试、集成测试和系统测试,这部分内容属软件确认技术范畴,下面有专门的论述。软件系统在做完系统测试后,就面临着交付使用的问题,在系统正式移交给用户之前,还需要做交付验证和交付测试。交付测试技术下文有专门的论述,不赘述,这里主要谈交付验证技术。交付验证包括安装验证和使用验证两部分内容。其中,安装验证的主要任务是保证程序能按照用户手册的提示正确安装到目标机器上,使用验证的主要任务是确保程序能按照用户手册的提示的操作正确完成某项功能或事务处理。这两部分工作通常是由测试人员完成的,用以核实相关安装和使用手册是否正确无误。
    4.2 在 CraftGS 项目中应用软件确认技术 CraftGS 中应用的软件确认技术包括单元测试技术、集成测试技术、系统测试技术和交付测试技术。 其中单元测试的主要任务是验证详细设计规格说明中所划分出来的软件单元是否被程序编制人员用代码形式正确地实现了。这里软件单元可能是某个函数(或称方法)也可能是某个抽象数据类型(如类、数据结构或者模板)。单元测试在实际测试当中也常常被称为类测试(在面向对象的设计中)或白盒测试(白盒的意思是面向代码)。单元测试的工作原理是建构桩模块和驱动模块以驱动被测单元运行,然后,测试人员输入设计好的测试用例,测试被测单元能否按照设计要求处理这些测试用例,对出现异常的测试用例,测试人员应做记载并反馈给软件开发团队。 做完单元测试以后,下一步的工作是对照软件概要设计规格说明,验证各软件单元组装后形成模块能否达到概要设计规格说明中模块的设计目标;在模块级集成工作完成之后,测试人员还应测试各模块组装后形成的用户系统内部存在冲突,各模块能否正常工作。这里,模块可能是指某个软件部件,也可能是指某个或某几个分系统。通常在做集成测试时先是从分系统内部的集成测试开始做起,做完以后再测试各分系统是否能集成为最终要实现的大系统。也有其他做法(如自顶向下集成测试方法、核心系统先做集成测试或每日集成测试等等)。总之,万变不离其宗。集成测试要保证模块的内部正确性以及保证模块能最终集成为大系统。集成测试有时也被称为组装测试(在型号软件中)或灰盒测试(有人认为集成测试介于白盒与黑盒之间)。 做完集成测试以后,下一步工作就是做系统测试。系统测试的主要任务是验证经集成测试后形成的软件系统是否满足软件需求规格说明中的各需求项。这些需求项包括:业务需求、功能需求、非功能性需求(如:性能、可靠性、安全性、系统维护等方面的要求)以及一些约束性需求(如开发标准、编程语言、通讯协议)等等。由于需求项涉及的领域很广泛,这就导致了系统测试中对应的测试门类相当庞杂。如:功能测试、执行路径测试、可靠性测试、压力测试、可恢复性测试、可移植性测试等等。这些测试最显著的特征是在一定环境条件下(如:模拟现场或极端条件),设计各种测试用例,输入并运行完整的软件系统,根据软件系统运行过程中的实际表现,评估软件系统是否符合软件需求项的各类要求。由于这类测试一般不涉及内部代码,因此,也有人把系统测试称做是黑盒测试。 在做完系统测试以后,软件产品就到了交付用户使用这个阶段了。交付过程中的重要一环就是交付测试,交付测试的目标是保证用户对所交付的系统的满意。与前面所讨论的测试不同,交付测试主要的参与者应该是目标客户。客户参与越多越好。交付测试的内容一般包括安装测试、可用性测试、 alpha 测试、 beta 测试等。其中安装测试的主要任务是测试软件系统能否在模拟环境下或实际现场由目标用户顺利完成在目标机器上的安装;可用性测试的主要任务是测试软件系统在完成安装以后能否完成用户的模拟任务或现场任务; alpha 测试采用的形式一般是由一个用户在开发环境下对软件系统进行类似于黑盒的测试,测试的目的是从用户的角度评价软件产品的功能、可使用性、可靠性、性能和支持,尤其注重产品的界面和特色; beta 测试采用的形式一般是先由软件的多个用户在实际使用环境下使用 beta 版软件系统一段时间,然后把使用中出现的各类故障或缺陷反馈给 beta 测试负责人员,再由测试负责人员移交给软件开发者,由开发人员负责修正并完善软件系统。 Beta 测试的目的是确保软件产品交付给全体用户之前能部分或全面地修正其在实际应用中可能出现的各类 BUG 或不足。
    4.3 在 CraftGS 项目中应用软件测试管理技术 一如前文所述,测试技术解决了测试采用的方法和技术问题,然而,对于一个工程而言,还需要相应的测试管理才能保证各项测试活动的有序开展。因此,在 CraftGS 项目中,软件测试管理技术要解决的问题是如何确保软件测试技术(包括软件验证技术和软件确认技术)能在软件项目在软件生命内得到顺利实施,并产生预期的效果。 按照软件测试管理面对的管理对象的差异,软件测试管理技术大致分为软件测试团队组织管理、软件测试计划管理、软件缺陷(错误)跟踪管理以及软件测试件管理四大部分。以下一一诠释: 软件测试团队组织管理通俗地讲就是测试团队应该如何组建。在实际项目开发中,我们常常看到有些单位忽视测试团队存在的意义,当要实施测试时,往往临时找几个程序员充当测试人员;也有些单位尽管认识到了组建测试团队的重要性,但在具体落实的时候往往安排一些毫无开发经验的行业新手去做测试工作,这常常导致测试效率的低下,测试人员对测试工作索然无味。 CraftGS 项目的测试团队首先聘有一名资深的测试领域专家,他具有极为丰富的航天项目软件测试经验,对软件开发过程中常见的缺陷或错误了然于胸,此外,他还具有较好的亲和力和人格魅力。其次, CraftGS 项目测试团队还具有很多具备一技之长的成员,如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚本。另外,测试团队还聘有兼职成员。如验证测试实施过程中,同行评审是最常使用的一种形式,这些同行专家就属于兼职测试团队成员的范畴。至于测试团队里里的测试新手,这部分人可以安排去从事交付验证或黑盒测试之类的工作。 软件测试计划管理通俗地讲就是安排好测试流程。这部分内容具体涵盖软件测试策划、软件测试技术剪裁、测试进度管理、成本管理等几个部分。其中测试策划工作主要是指具体测试活动实施之前做好策划工作,如起草测试大纲以及测试计划;软件测试技术剪裁工作主要是指测试团队应根据软件项目的具体实际剪裁出所要实施的测试技术;测试进度管理工作主要是指排出各项测试的时间进度及人员安排,如有变动时应做相应调整;测试成本管理工作的内容即开列出测试活动中会涉及到的资源需求。 CraftGS 项目测试团队较好地按照上述要求,完成了软件测试计划管理。 软件缺陷(错误)跟踪管理通俗地讲就是确保发现的缺陷(错误)已经被开发团队纠正或处理过并且没有引入新的缺陷(错误)。具体来讲,当测试团队通过各种途径发现了文档或代码中的缺陷或错误以后,并不是交一份测试报告就草草了事,而是在递交报告以后继续督促开发团队及时关闭已知缺陷或错误(当然,如有必要应对这些缺陷、错误做严重程度排序,以便开发团队能视轻重缓急安排处理顺序)。当开发团队关闭了测试报告中的缺陷(错误)以后,测试团队还需验证开发团队在关闭过程中有没有引入新的错误。通常,这个过程称为回归测试。回归测试如发现问题,继续报开发团组,按上述流程循环,直至回归测试最终通过。这部分工作在 CraftGS 项目中是使用自动化的测试管理工具完成的,(市面上可选择的工具有 华创缺陷管理系统 (BMS) 和 Rational ClearQuest 等等 ),这么做非常有效率。 软件测试件管理通俗地讲就是指努力建设好测试团队的财富库并对测试团队成员进行技能培训以帮助他们能使用好这个财富库。这里,财富库是指软件测试件。测试件( Testware ,指测试工作形成的产品)是一个不常见到的词汇,它包括是测试团队在长期实践过程中逐步积累起来的经验教训、测试技巧、测试工具、规格文档以及一些经过少量修改能推广至通用的测试脚本程序。测试件管理工作做得越好,测试团队在实际测试过程中就能越少走弯路,测试团队内部的知识交流和传递就越充分,测试脚本或规格文档的重复开发工作也就能被有效地避免。软件测试件管理工作包括两部分,一是建设,另一个是培训。建设工作大抵是收集各类测试外文档、测试工具、测试脚本,也包括收集整理测试人员的会议发言、总结报告、技术心得等等。培训工作大抵是通过技术讲座、正式或非正式团队会议、印发学习资料等形式进行。 CraftGS 项目组考虑到测试团队的长久发展,较好地完成了测试件管理,测试团队成员的技能水平在较短的时间内都有了非常迅速的进步。
     5 结语:高可靠性软件测试技术需要更多关注 以上笔者结合 CraftGS 项目对从测试技术和测试管理的角度对高可靠性软件测试方案一个略粗浅的探讨。笔者希望此文的发表能对相关软件企业和软件项目实施软件测试技术起一定的参考和指导作用。需要说明的是目前对高可靠性软件如何实施软件测试技术仍是一个颇不成熟的领域,缺少一种体系化的方法。各个企业可能都有一定的经验积累,不妨整理出来,相互借鉴。这里,笔者所做的探讨虽然已经竭尽所能,但却不能保证一定能照搬照抄到所有的高可靠性软件项目的测试之中。希望该领域的学者和技术专家共同努力、不断摸索,逐步完善这一课题。
    参考文献:
    [1] Glenford J.Myers.The Art of Software Testing.NewYork:John wiley Press,1979.127-170.
     [2] Bill Hetzel.The complete Guide to Software Testing.2,NewYork:John Wilely Press,1988.137-190.
    [3] Edward Kit. Software Testing in the Real World. London:Pearson Education,1995.45-88.
     [4] Daniel J.Mosely,Bruce A.posey.Just Enough Software Test Automation..NewYork:Pearson Education,2002.87-91.
     [5] Paul C.Jorgensen. Software Testing -A Craftsman's Approach. 2,Florida:CRC Press,2002.260-296.
    [6] 许胜,支定镛等 . 航天软件工程实施技术指南及范例 . 北京 : 航天 5 院, 2003.

    转载于:https://www.cnblogs.com/eagleking0318/archive/2010/06/21/6521527.html

    展开全文
  • 软件测试方案模板

    2017-08-23 14:40:45
    软件测试方案
  • 软件测试方案模板.doc

    2020-12-25 16:45:39
    软件测试方案模板
  • 软件测试方案模板,可以进行参考哦 软件测试方案模板,可以进行参考哦 软件测试方案模板,可以进行参考哦
  • 软件测试方案设计能力解决方案.ppt
  • 软件测试方案和计划
  • 软件测试方案模板.pdf

    2020-05-30 00:25:01
    XX项目 软件测试方案 编号 XX XX 公司 2017 年 XX 月 XX-软件测试方案 目录 1 文档说明 1 1.1 文档信息 1 1.2 文档控制 1 1.2.1 变更记录 1 1.2.2 审阅记录 1 2 引言 2 2.1 编写目的 2 2.2 读者对象 2 2.3 项目背景 ...
  • 软件测试方案模板范文,千里寻找,只求分享给大家!!!
  • 软件测试方案V.docx

    2020-11-10 22:21:50
    可编辑 技术资料分享 技术资料分享 软件测试方案 文档标识 当前版本 V1.0 当前状态 草稿 发布日期 发布 修改历史 日期 版本 作者 修改内容 评审号 变更控制号 V1.0 WORD WORD 格式 .可编辑 技术资料分享 技术资料...
  • 项目名称中华万年历 软件测试方案 班级 软件?12 日期2014?年?12?月?1?日 1 项目组成员 组长 班级学号 1060612014051 姓名 张亚亭 负责工作 单元测试 小组成员 1?班级学号 1060612014046 姓名 王晓武 负责工作 系统...
  • 软件测试方案 XX项目 测试方案 版本修订记录 版本标识 注 释 作 者 日 期 1.0 初始版本 文档使用对象 姓 名 职 务 审批人员 姓 名 职 务 日 期 目 录 TOC \o \h \z 1文档标识 1 2概要 1 2.1文档用途 1 2.2测试目的 1...
  • 软件测试方案 XX项目 测试方案 版本修订记录 版本标识 注 释 作 者 日 期 1.0 初始版本 文档使用对象 姓 名 职 务 审批人员 姓 名 职 务 日 期 目 录 TOC \o \h \z 1文档标识 1 2概要 1 2.1文档用途 1 2.2测试目的 1...
  • 哈喽,大家好!我是minisummer!首先感谢您的关注!...软件测试方案的作用非常类似于产品设计说明(文档),开发工程师根据产品功能需求和设计说明来编码实现功能,而测试工程师 需要基于产品功能需求和测试

    哈喽,大家好!我是minisummer!首先感谢您的关注!
    今天给大家分享的内容是软件测试方案:测试方案的目的?测试计划与方案的区别?如何制定测试方案?

    7.1测试方案的目的

    软件测试方案的作用非常类似于产品设计说明(文档),开发工程师根据产品功能需求和设计说明来编码实现功能,而测试工程师 需要基于产品功能需求和测试方案来设计和执行测试用例,同时也要参考产品设计说明文档,所以测试方案目的是: 在方向上明确要测什么、怎么测,以及达到什么样质量标准。
    软件测试方案有助于软件项目成员理解和执行测试过程中的各项活动,同时测试方案也有助于测试活动的管理。

    7.2测试计划与方案的区别

    定义不同:
    测试计划是对测试过程的组织、资源、原则等进行规定和约束;而测试方案规则是描述所测软件的测试特性、测试方法、测试用例设计、测试代码设计、测试环境规划以及测试工具设计和选择的一种策略与方法。
    层次不同:
    测试计划是管理层面的,从组织管理的角度规划测试活动,而测试方案是技术层面的,从技术的角度规划测试活动。
    总而言之,测试方案需要在测试计划的指导下进行,测试计划提出“做什么”,而测试方案明确“怎么做”。

    7.3如何制定有效测试方案

    7.3.1测试需求分析

    测试需求分析就是把产品需求和对用户的理解(用户体验)转化、分解成测试功能 点,产品需求是我们测试需求主要输入,但不是全部,我们还需要仔细分析产品设计说明,可以产出更多可测试的功能点(这些功能点往往没有包含在产品需求 中)。
    还要加入对性能、安全、接口和回归测试范围分析。测试需求是确定测试进度计划和资源的主要依据。
    评估风险并确定测试优先级。

    7.3.2测试策略

    一个好的测试策略应该包括下列内容:

    • 实施的测试类型和测试的目标
    • 实施测试的阶段
    • 技术
    • 用于评估测试结果和测试是否完成的评测和标准
    • 对测试策略所述的测试工作存在影响的特殊事项

    7.3.3测试资源

    一般情况下,团队同时有多个项目,测试PM需要根据项目的优先级来确定每个项目的测试资源。
    一般情况下,软件测试资源主要包括:人力和设备机器。

    7.3.4测试进度计划

    根据测试需求和策略,结合项目优先级和测试资源情况,评估测试进度计划,一般情况下,测试资源越充分,测试进度越乐观,但并非绝对,有时候一些软件BUG会阻塞测试进度,这也是项目风险的一部分。

    7.3.5风险管理

    在测试执行开始之前,对可能的风险进行分析和识别很重要,可以提前进行预防和采取应对措施,所以项目过程中,我们需要定期评估测试进度情况,提前进行风险预警。

    7.3.6质量

    质量是指测试项目需要达到的标准,各个公司和项目都会有相应的标准要求,由于质量标准可以是公司内多数项目共识,所以也可以不必在测试方案中列出。对测试项目来说,比较常见的是以测试用例执行率、通过率和未关闭BUG级别/数量来设定质量标准。

    以上内容希望对你有帮助,有被帮助到的朋友欢迎点赞,评论。
    注:转载请注明出处,商用请征得作者本人同意,谢谢!!!

    展开全文
  • 软件测试方案设计 编写 20xx 年 xx 月 xx 日 审核 年 月 日 批准 年 月 日 版本控制 AM 版本 日期 修订者 说明 D 1.0 A 注 A-添加M-修改D-删除 目录 1 概述3 1.1 编写目的3 1.2 读者对象3 1.3 项目背景4 1.4 测试...
  • 实用标准文档 软件测试方案 文档标识 当前版本 V1.0 草稿 当前状态 发布日期 发布 修改历史 日期 版本 作者 修改内容 评审号 变更控制号 V1.0 文案大全 实用标准文档 目录 1 概述 . 4 1.1 软件测试流程实施方案 . 4 ...
  • 软件测试方案v1.0.pdf

    2020-07-28 04:37:21
    软件测试方案 文 档 标 当 前 版 V1.0 识 本 当 前 状 草稿 发布 日 态 发布 期 修改历史 变 日 版 作 评审 修改内容 更 控 制 期 本 者 号 号 V 1.0 第 1 页 共 20 页 目录 第 2 页 共 20 页 第 3 页 共 20 页 1 ...
  • 软件测试方案模板 篇一范文 项目名称测试方案 仅供参考 文档版本控制 概述 软件的错误是不可避免的所以必须经过严格的测试 通过对本软件的测试尽可能的发现软件中的错误借以减 少系统内部各模块的逻辑功能上的缺陷和...
  • XX-软件测试方案 第 PAGE 13页 共17页 XX公司 XX项目 软件测试方案 编号XX XX公司 2017年XX月 目录 TOC \o "1-3" \h \z \u 1 文档说明 1 1.1 文档信息 1 1.2 文档控制 1 1.2.1 变更记录 1 1.2.2 审阅记录 1 2 引言 2...
  • PAGE 第 PAGE 12 页 共 NUMPAGES 12页 系统测试方案 软件测试方案 文档标识 当前版本 V1.0 当前状态 草稿 发布日期 发布 修改历史 日期 版本 作者 修改内容 评审号 变更控制号 V1.0 目录 TOC \o "1-3" \h \z \u 1 ...
  • 软件测试方案有助于软件项目成员理解和执行测试过程中的各项活动,同时测试方案也有助于测试活动的管理 2.测试计划和测试方案的区别 测试方案需要在测试计划的指导下进行,测试计划提出“做什么”,而测试方案明确...

    本文首发于伊洛的个人博客:https://yiluotalk.com,欢迎关注并查看更多内容!!!

    1.测试方案的目的
    • 所以测试方案目的是: 在方向上明确要测什么、怎么测,以及达到什么样质量标准
    • 软件测试方案有助于软件项目成员理解和执行测试过程中的各项活动,同时测试方案也有助于测试活动的管理
    2.测试计划和测试方案的区别
    • 测试方案需要在测试计划的指导下进行,测试计划提出“做什么”,而测试方案明确“怎么做”
    3.如何编写有效的测试方案
    • 测试需求分析
    • 测试策略
    • 测试资源
    • 测试进度计划
    • 风险管理
    • 质量

    4. 测试需求分析
    • 测试需求分析就是把产品需求和对用户的理解(用户体验)转化、分解成测试功能 点,产品需求是我们测试需求主要输入,但不是全部,我们还需要仔细分析产品设计说明,可以产出更多可测试的功能点(这些功能点往往没有包含在产品需求 中)。还要加入对性能、安全、接口和回归测试范围分析。测试需求是确定测试进度计划和资源的主要依据
    • 评估风险并确定测试优先级
    5.测试策略
    • 制定测试策略
    • 测试进度计划
      根据测试需求和策略,结合项目优先级和测试资源情况,评估测试进度计划
    6.测试类型

    测试类型
    功能测试
    界面测试
    安全测试
    数据库测试
    可靠性测试
    集成测试
    兼容性测试
    自动化测试
    性能测试
    回归测试

    …待续

    在这里插入图片描述

    享受每一天,Just Enjoy !

    关注公众号获取更多内容

    展开全文
  • 软件测试方案V1..docx

    2020-06-10 21:25:41
    完美 完美WORD格式 专业知识分享 专业知识分享 软件测试方案 文档标识 当前版本 V1.0 当前状态 草稿 发布日期 发布 修改历史 日期 版本 作者 修改内容 评审号 变更控制号 V1.0 完美 完美 WORD 格式 专业 知识分享 ...
  • 软 件 测 试 方 案 模 板 精品文档 XX 项目 软件测试方案 编号 XX XX 公司 2017 年 XX 月 目录 收集于网络如有侵权请联系管理员删除 精品文档 1 文档说明 1 1.1 文档信息 1 1.2 文档控制 1 1.2.1 变更记录 1 1.2.2 ...
  • 软件测试方案浅析

    2014-11-13 10:45:00
    等等类似关于软件测试方案的问题,往往没有一致的答案。不同的公司往往有自己的测试方案模板,测试工程师的理解也会有所差别。以下是我关于测试方案的理解,希望能够抛砖引玉。 编写测试方案的目的是啥?也许有人会...

    在软件测试过程中,测试方案起到什么样作用? 如何编写测试方案?等等类似关于软件测试方案的问题,往往没有一致的答案。不同的公司往往有自己的测试方案模板,测试工程师的理解也会有所差别。以下是我关于测试方案的理解,希望能够抛砖引玉。

    编写测试方案的目的是啥?也许有人会说:根据产品功能需求(比如PRD)文档,参考产品设计文档,测试工程师就可以理解需求、设计测试用例了,不需要测试方案文档,即使写了测试方案,也主要是把产品需求和设计文档内容copy一下而已。有以上这样的想法,是因为没有真正理解测试方案的作用。其实软件测试方案的作用非常类似于产品设计说明(文档),开发工程师根据产品功能需求和设计说明来编码实现功能,而测试工程师需要基于产品功能需求和测试方案来设计和执行测试用例,同时也要参考产品设计说明文档,所以测试方案目的是: 在方向上明确要测什么、怎么测,以及达到什么样质量标准。 

    如何产出有效的测试方案? 如果只是把产品需求和部分设计说明内容copy一下,给出测试进度计划,这样的测试方案对用例设计和执行意义不大。我想作为方案,至少要包括几个关键因素:范围,时间,资源和质量,而不同行业产品,测试方案应该相应地进行对这几个关键因素进行分解和调整。对于软件测试方案,我想主要应该包括:测试需求分析,测试策略,测试资源,测试计划,项目风险和质量,如果我们能够明确以上这些因素,这样的测试方案就一定能够有效地指导我们测试设计和执行。 

    测试需求分析:测试需求分析就是把产品需求(比如PRD文档)和对用户的理解(用户体验)转化、分解成测试功能点,产品需求是我们测试需求主要输入,但不是全部,我们还需要仔细分析产品设计说明,可以产出更多可测试的功能点(这些功能点往往没有包含在产品需求中)。还要加入对性能、安全、接口和回归测试范围分析。测试需求是确定测试进度计划和资源的主要依据。

    测试数据: 在此简要说明测试数据的形成,如以客户单位具体的业务规则和《XX系统需求分析说明书》,参考《XX系统概要设计说明书》、《XX系统详细设计说明书》和《数据规格说明书》中规定的运行限制,设计测试用例,作为整个XX系统的测试数据。

    测试策略: 测试需求确定后,我们就要思考如何验证测试需求中的功能点,采用什么测试方法:手工、自动化测试和是否需要新方法或工具,比如新功能采用手工测试,部分回归用例使用自动化脚本,用新方法来准备测试数据,采用合适的工具验证复杂的测试结果。确定测试优先级,确认哪些业务功能是最重要,那个是新代码模块,哪些旧模块改动较大,与之相关的功能点要重点测试,测试不可能100%覆盖,但是对于重要、高危的功能必须要全面验证,保证资源投入到当前最高优先级的任务。 

    测试资源:一般情况下,团队同时有多个项目,测试PM需要根据项目的优先级来确定每个项目的测试资源,一般情况下,软件测试资源主要包括:人力和设备机器。 

    测试计划:根据测试需求和策略,结合项目优先级和测试资源情况,评估测试进度计划,一般情况下,测试资源越充分,测试进度越乐观,但并非绝对,有时候一些软件BUG会阻塞测试进度,这也是项目风险的一部分。 

    风险管理:在测试执行开始之前,对可能的风险进行分析和识别很重要,可以提前进行预防和采取应对措施,所以项目过程中,我们需要定期评估测试进度情况,提前进行风险预警。 

    质量:质量是指测试项目需要达到的标准,各个公司和项目都会有相应的标准要求,由于质量标准可以是公司内多数项目共识,所以也可以不必在测试方案中列出。对测试项目来说,比较常见的是以测试用例执行率、通过率和未关闭BUG级别/数量来设定质量标准。 

    测试方案初稿完成后,必须要请项目相关测试、开发和需求方同事评审,澄清对需求和设计的理解,讨论测试方法,往往在测试方案评审中,我们能够对产品需求进行完善,给产品详细设计提供更多输入,使开发同事能够提前完善代码逻辑,而且测试工程师也能够进一步理解需求和设计,从而有助于设计完善测试用例设计,保证测试覆盖率。

     

     

     测试方案包括测试的目的以及测试用例

      测试方案 != 测试用例

      测试方案不属于测试计划

      1、测试方案的设计,是要解决从软件需求、设计需求以及其他需求中提取出来的测试需求,该如何测试的问题。


      测试方案的设计,关键是要提醒在测试对象的分析过程中,最终得出合适的测试点和测试方法。

      2、从过程中来讲,相对于开发过程而言

      |-----》概要设计/详细设计------》编码

      需求-------

      |-----》测试方案设计------》编写用例

      我个人觉得从上面的两个图来看,之前一般情况下,我们只是“需求---》用例”这个过程,与开发过程对比,确实少了一个从高层次对需求的分析,分析问题的过程,总是逐步的分解,“需求--》用例”的过程是不是太快,或者说我们是不是没有把对需求的分析写出来。在实际的工作中,我曾经按模块列出测试功能点,在列测试功能点的时候大家一起分析,讨论,如果一定要从概念上套用的话,那么我们没有把测试方案写出来,是在我们的脑袋里,或者说我们是不自觉地在做这样的事情。以后有机会再去实践吧。

      3、方案的设计

      测试方案设计三步曲

      确定测试范围-----》测试对象深入分析-----》确定测试点/测试方法

      需注意

      A、不能只有结论,还要有分析过程,说明对象的测试方法为何是这样的方法,而不是那种方法。

      B、方案的设计要以理服人,要有理有据的分析。

      C、设计依据不局限与需求,还要参考概要/详细设计等开发文档。

      D、方案的分析结果就是测试点,和测试方法。

     

    第一次在只有需求文档的情况下写测试方案

    现在公司在搞项目管理的规范化,分我配一个新开始的项目开始跟踪。通过项目开发计划,发现需要写一个测试方案,可是目前除了项目的一个总体描述、页面规范、代码规范和需求说明文档外没有任何东西了。这样写东西感觉有些别扭,因为对于系统的功能,只有通过需求文档的描述,对于系统的功能只能完全靠想像了。

    一开始我想着是将全篇的需求文档全部看完,然后再分析功能,写出相应的测试点,看了几个模块后,发现这样效果并不好,因为对于整个系统的功能除了文档外没有任何其他可参照的内容,而且是电子文档不像纸制文件可以一边看一边用笔划着帮助增强记忆。至于看到后面的时候,再看以前已经看过的功能,感觉仍然像是看一个完全新的功能。于是改变了看的方法。按照下面的步骤对测试方案进行整理。

    1.看单个模块的总体介绍

       在看的过程中,通过总体介绍对于模块功能有一个大体上的了解,根据功能的了解在纸上写出大概的功能点,这点感觉很重要,因为这样在看模块功能的具体介绍的过程时,可以看一出与自己理解功能之间的偏差,并进行记录,提交给开发人员对描述进行调整

    2.看单个模块的具体功能的介绍

       看具体功能的时候,需要逐字的查看,如果遇到存在歧义的内容时,使用WORD的审阅功能进行标识,如有必要可对纸制中记录的内容进行修改。

       3.整理单个模块的测试点

       测试点的整理就是根据了解对功能点的整理, 这里对功能点进行了标号,是想对于下一步的测试用例可有一个参照,这样方便用例与功能点的对应,方便查找问题的功能点信息

    4.对于与当前整理相关的已经整理模块的测试进行调整

       如果遇到与已经整理过的模块相关的模块功能整理,内容之间不完善或者存在理解错误时,对以前的功能点进行调整,或者由项目经理人解答后再进行调整。

     

    我在看需求文档时,由于开发人员处于封闭状态,与我没有在同一办公地点,沟通上不上很方便。因此我并不是遇到问题就立即向项目经理询问,这样也很影响他们的工作,毕竟他们工作时也是有思路的,总打断不好。而是进行很详细的记录,在看完一遍文档后,统一进行整理,询问项目经理的程序功能具体情况,这是用邮件的方式来进行的。他们会在文档中写出解答意见,我在需求文档当中再将答复意见一同记录,以便以后查询。

     

    目前就是这些心得了,如果有了新的再补充吧。就到这里啦。

    展开全文
  • 实用标准文档 XX项目 软件测试方案 编号 XX XX 公司 2017 年 XX 月 文案大全 实用标准文档 目录 1 文档说明 . 1 1.1 文档信息 . 1 1.2 文档控制 . 1 1.2.1 变更记录 . 1 1.2.2 审阅记录 . 1 2 引言 2 2.1 编写目的 .
  • 酒店住房管理系统软件测试方案设计 酒店管理系统测试计划 1 引言 1.1 编写目的 软件测试是为了发现程序中的问题本系统技术不很成熟存在不少问题测 试变得非常重要软件测试的过程也是程序运行的过程程序运行需要数据...
  • ? 本资料在 AMT 的文档控制范围之内在得到许可后方可使用 ...软件测试需求分析基本方法 软件测试需求分析技术 软件测试范围分析 软件测试工作量估算 软件测试测试工作分解结构表方法 软件测试资源要求 软件测试风险分析
  • 软件测试方案.pdf

    2020-02-01 17:24:29
    XXXXXX 测试方案 部 门 _ _ 编 写 _ 审 核 _ 批 准 日 期 _
  • 软件测试方案设计

    2020-11-01 10:51:38
    文章目录1、软件框架2、测试方案设计2.1、测试覆盖2.2、功能测试和压力测试2.3、自动化测试2.4、持续集成 1、软件框架 站在软件的角度,一个系统通常可以分为以下四个层次: 应用软件层(app layer)。用户重点自己...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 6,740
精华内容 2,696
关键字:

软件测试方案