精华内容
下载资源
问答
  • 质量保证QA与质量控制QC

    千次阅读 2019-07-17 21:34:45
    作者:郑文强 ...不管是工作过程还是培训过程中,或者面试或找工作过程中,经常会看到质量控制QC和质量保证QA两个词汇,甚至不少人或组织会将质量保证QA代指测试。本文将基于ISO 9000相关术语的...

    作者:郑文强

    时间:2019年7月15日

     

    关键词:质量管理QM(Quality Management)、质量保证QA(Quality Assurance)、质量控制QC(Quality Control)

     

    不管是工作过程还是培训过程中,或者面试或找工作过程中,经常会看到质量控制QC和质量保证QA两个词汇,甚至不少人或组织会将质量保证QA代指测试。本文将基于ISO 9000相关术语的定义,从测试角度来谈谈我对它们的理解。首先给出ISO 9000的定义:

    1、质量管理QM指的是在组织质量方面提供指导和控制的协同活动。针对质量的指导和控制通常包括建立质量方针和质量目标、质量计划、质量控制QC、质量保证QA和质量改进。[ISO 9000]

    2、质量保证QA属于质量管理的组成部分,其提供了达到质量要求的可信程度。[ISO 9000][GBT 11457]

    3、质量控制QC属于质量管理的一部分,其关注在为达到质量要求而采取的技术和活动。[ISO 9000][GBT 11457]

     

    根据上面的定义,可以看出质量管理QM是一个更大的概念,可以将质量保证QA和质量控制QC联系在一起,它们都属于质量管理QM的一部分。

     

    质量保证QA关注在软件产品生成的整个过程,主要验证软件产品开发过程中相关实施过程的完整性、一致性和有效性,确保开发活动和测试活动等遵循正确的过程,为软件产品达到合适的质量级别提供信心。为了实现过程的可重用性和持续改进,组织往往会把过程进行标准化,例如:定义子过程、过程的里程碑点、过程的阶段输入和输出、每个时间点需要完成的工作等。软件产品随着生命周期不断增加和成型,想要修复其在早期引入的缺陷,时间和成本都将成倍增加。而质量保证QA的基本假设是过程质量决定了软件产品质量。当过程正确开展时,确保过程的每个阶段得到了良好的遵循,每个阶段引入的缺陷尽量在本阶段得到发现和修复,最大程度的实现缺陷的阶段遏制能力。同时,在当前阶段发现和修复的缺陷,有助于后续阶段的缺陷预防。另外,通过根本原因分析等技术消除在软件工作产品中引入缺陷的根本原因,或者在适当时候开展回顾会议以总结经验和教训,都有助于过程改进,从而可以在将来更好的实现质量保证。

     

    质量控制QC关注在过程中生成的工作产品,其主要目的是检查工作产品是否达到预期要求。从测试的角度,测试过程是整个软件开发生命周期的一部分,而质量保证QA涉及整个过程的正确执行,因此质量保证QA可以支持正确的测试活动。为了帮助实现软件工作产品质量的不断提高,测试可以采用各种不同的测试策略、测试技术、测试类型、测试活动等,例如:自动化测试与手工测试、黑盒测试技术与白盒测试技术、功能测试与非功能测试、测试设计与测试执行等,以尽早发现被测对象与预期结果之间的不一致,并以缺陷报告方式提交,通过开发人员的定位和修复问题,测试人员的再测试和回归测试,逐步实现工作产品质量的提高。

     

    质量保证QA监督的是软件产品实施的全过程(也包括质量保证QC的过程),因此QA往往会是组织层面的岗位定义。而属于质量控制QC的测试团队,往往会在项目层面的得到定义。质量保证QA与质量控制QC既相互关联,又关注重点不同。为了实现软件项目在时间、成本、范围和质量要求下交付满足客户要求的软件产品,需要质量保证QA和质量控制QC两个团队的相互配合和支持。

    展开全文
  • 质量保证大纲.pdf

    2020-04-02 16:41:33
    质量工作原则 应贯彻“装备研制、质量第一”的方针,坚持装备先进性与可 坚持技术进度与质量协调并进的原则。 质量目标 产品性能达到战术技术指标,质量特性满足作战使用要求的可靠 95%,一次性通过 产品实现...
  • 软件质量保证测试

    千次阅读 2019-01-06 17:25:32
    1.软件是计算机程序、规程以及可能的相关文档和运行计算机系统需要的数据。包含4个部分,即计算机程序、规程、文档和软件系统运行所必需的数据。软件与硬件完全不同的特征:1、软件是...软件质量保证(Software Qual...

    1.软件是计算机程序、规程以及可能的相关文档和运行计算机系统需要的数据。包含4个部分,即计算机程序、规程、文档和软件系统运行所必需的数据。软件与硬件完全不同的特征:1、软件是开发产生的,而不是用传统方法制造。2、软件不会像硬件一样有磨损。3、很多软件不能通过已有构件组装,只能自己定义。4、软件可以无限复制。

    2.软件质量保证定义及包含内容P12:(1)

    软件质量保证(Software Quality Assurance,SQA)是应用于整个软件过程的保护性活动。软件质量保证包括质量管理方法、有效地的软件工程技术(方法、工具)、在整个软件过程中采用的正式技术复审、多成次的测试策略、对软件文档及其修改的控制、保证软件遵从软件开发标准的规程以及度量、报告机制。

    1. 软件质量是:系统、部件或者过程满足规定需求的程度。系统、部件或者过程满足顾客或者用户需要或期望的程度。该定义相对客观,强调了产品(或服务)和客户/社会需求的一致性。从以下几个方面考虑软件质量:软件结构方面,功能与性能方面,开发标准与文档方面
    2. 全面质量管理通常都包括以下4个步骤:

    第1步是指一个连续的过程改进系统,其目标在于开发一个看的见的、可重复的和可度量的软件过程。第二步将检查影响过程的其它因素,并优化这些因素对过程的影响。前面两个步骤关注的是过程,第3步关注软件产品的用户,它是通过检查用户使用产品的方式,而导致产品本身的改进和潜在地改进产品的生产过程。第4步将管理者的注意从当前的产品上移开并拓宽。

    1. 软件测试是使用人工或自动手段来运行或测定某个系统的过程,检验是否满足规定的需求,或者弄清预期结果与实际结果之间的差别。
    2. 软件测试方法:1)静态方法和动态方法2)黑盒白盒灰盒3)需求、单元、集成、压力,性能、回归、安装、配置,安全性测试
    3. 软件质量控制是一组由开发组织使用的程序和方法,使用它可在规定的资金投入和时间限制的条件下,提供满足客户质量要求的软件产品并持续不断地改善开发过程和开发组织本身,以提高来生产高质量软件产品的能力。基本方法:PDCA质量控制法目标问题度量法(通过确定软件质量目标并且连续监视这些目标是否达到来控制软件质量的一种方法)(具体做法:1)对一个项目的各个方面(产品、过程、资源规定具体的目标,这些表达应非常明确)2)对每一个目标要引出一系列能反映出这个目标是否达到要求的问题,并要求对这些问题进行回答。这些问题的回答有助于使目标定量化3)将回答这些问题的答案映射到对软件质量等级的度量上,根据度量得出软件目标是否达到的结论,或确认哪些做好了,哪些仍需改善4)收集数据,但要为收集和分析数据做出计划)和风险管理法(识别和控制软件开发中对成功地达到目标危害最大的那些因素的一个系统性方法)(具体做法:1)根据经验识别项目要素的有关风险2)评估风险发生的概率和发生的代价3)按发生概率和代价划分风险等级并排序4)在项目限定条件下选择控制风险的技术,并制定计划5)执行计划并监控进程6)持续评估风险状态,并采取正确的措施)(SEI总结的5个步骤:风险识别、风险分析、风险计划、风险控制、风险跟踪)
    4. 风险控制方法:风险避免,通过变更计划消除风险的触发条件,如采用成熟技术、增加资源、减少软件范围等。风险弱化,降低风险发生的概率,如简化流程、更多测试、开发原型系统等。风险承担,制定应急方案,随机应变。风险转移,将风险发生的结果连同应对权利转移给有承受能力的第三方。

     

     

    1. 软件质量保证(SQA)是建立一套有计划、有系统的方法向管理层保证拟定出的标准、步骤、实践、方法能够正确地被所有项目采用。SQA(软件质量保证)是CMM(软件能力成熟度)2级中的一个重要关键过程区域,它是贯穿于整个软件过程的第三方独立审查活动,在CMM的过程中充当重要角色;软件质量保证的目标是以独立审查的方式监控软件生产任务的执行,给开发人员和管理层提供反映产品质量的信息和数据,辅助软件工程组得到高质量的软件产品,主要工作包括以下3个方面:1)通过监控软件的开发过程来保证产品的质量2)保证生产出的软件和软件开发过程符合相应的标准与规程3)保证软件产品、软件过程中存在的不符合问题得到处理,必要时将问题反映给高级管理者。目的是向管理者提供对软件过程进行全面监控的手段,包括评审和审计软件产品和活动,验证它们是否符合相应的规程和标准,同时给项目管理者提供这些评审和审计的结果。
    2. 软件过程成熟度模型CMM:是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。包括5个等级,共计18个过程域,52个目标,300多个关键实践。实施CMM是改进软件质量的有效方法:控制软件生产过程、提高软件生产者组织性和软件生产者个人能力的有效合理的方法(初始级可重复级已定义级已管理级优化级
    3. 质量保证模型:McCall模型Boehm模型FURPS模型ISO9126
    4. 缺陷排除效率(1)缺陷排除效率(DRE),E=软件交付给最终用户之前所发现的错取数,D=软件交付之后所发现的缺陷数       公式DRE=E/(E+D)
    5. 软件过程度量常见问题①度量得太多、太频繁②度量得太少、太迟③度量了不正确的事物或属性④度量的定义不精确⑤收集了数据却没有利用⑥错误地解释度量数据⑦自动化工具欠缺
    6. 软件配置管理(SCM)是一种标识、组织、控制修改的技术,贯穿在整个软件生命周期中建立和维护项目产品的完整性。SCM 活动的目标软件配置管理的各项工作是有计划进行的。被选择的项目产品得到识别,控制并且可以被相关人员获取。已识别出的项目产品的更改得到控制。使相关组别和个人及时了解软件基准的状态和内容。
    7. 配置审计:制定项目的配置计划、对配置项进行标识、对配置项进行版本控制、对配置项进行变更控制、定期进行配置审计、向相关人员报告配置的状态。
    8. 软件可靠性:在规定的条件下,在规定的时间内,软件不引起系统失效的概率,该概率是系统输入和系统使用的函数,也是软件中存在的错误的函数,系统输入将确定是否会遇到已存在的错误(如果错误存在);在规定的时间周期内,在所述条件下,程序执行所要求的功能的能力。
    9. 异常。偏离期望的状态(或期望值)的任何情形都可称为异常.缺陷。不符合使用要求或与技术规格说明不一致的任何状态常称为缺陷。差错:计算的、观测的或测量的值与真实的、规定的或理论上正确的值或条件之间的差别。一个不正确的步骤、过程或数据定义。一个不正确的结果。一次产生不正确的结果的人的活动。故障。在一个计算机程序中出现的不正确的步骤、过程或数据定义常称为故障。上述“差错”中的第二项属于故障。失效。一个程序运行的外部结果与软件产品的要求出现不一致时称为失效。软件失效证明了软件中存在着故障。
    10. 软件可靠性模型:指为预计或估算软件的可靠性所建立的可靠性框图和数学模型。评价准则:①模型拟合性:模型拟合度是指模型估计出的失效数据与实际失效数据的吻合程度。②模型的预计有效性:模型的拟合性是从历史角度来反映模型评估的有效性,模型的预计有效性是从预测的角度反应模型评估的有效性,用序列似然度检验来比较模型在预计有效性方面的优劣③模型偏差④模型的偏差趋势⑤模型噪声:是指模型本身给模型预测引入噪声的程度。
    11. 提高软件可靠性的方法和技术:建立以可靠性为核心的质量标准、选择开发方法、软件重用、使用开发管理工具、加强测试、容错设计。
    12. 软件评审:评审是一些用于开发过程早期检查和纠正缺陷的有效方法,他们可以用来检查未成形执行代码的文档的缺陷用评审发现缺陷的成本与用测试相比较是相当低的,但是作为缺陷检测技术评审也不能完全代替代码的运行测试。
    13. 为什么进行软件评审:提高项目地生产率、改善软件的质量、在评估过程中使用使开发团队的其他成员更熟悉产品和开发过程、通过评审标志着软件开发的一个阶段的完成、生产更容易维护的软件。
    14. 评审的方法:特别检查:不正式的评审方法,通常应用与平常的小组合作;轮查:作者作简要介绍,但不参与评审,评审者独立进行评审,并记录发现的结果,准备报告;走查:是一种非正式的评审方法,但作者占主导地位,描述产品的情况;让评审者了解产品,并合理做出评审;团队评审:是有计划和结构化的,非常接近于正式的评审技术

    检视:比团队评审更严格,是最系统化、最严密的评审方法

    1. 软件评审内容①管理评审:是最高管理者未评价管理体系的适宜性、充分性、有效性所进行的活动②技术评审:是一种同行审查技术,主要特点是由一组评审者按照规范的步骤对软件需求、设计、代码或其他技术文档进行仔细的检查,以找出和消除其中的缺陷③文档评审:尽早发现问题,并及时采取措施予以解决,确保文档的内容准确④过程评审:对软件开发过程的评审。
    2. 软件评审会议流程(1)①准备评审会议:评审组长发出评审通知,并且将待评审的相关资料发送给参加会议的评委②召开评审会议③跟踪和分析评审结果:评审会议的重要输出是缺陷列表,需要修改和加工
    3. 全面质量管理是一种由顾客的需要和期望驱动的管理哲学,是以质量为中心,建立在全员参与基础上的一种管理方法,其目的在于长期获得顾客满意、组织成员和社会的利益。包括:强烈关注顾客,精确度量,坚持不断的改进,向员工授权,改进组织中每项工作的质量
    4. ISO9000和全面质量管理的异同点:相同:①两者的理论管理和统计理论基础一致,都认为产品质量形成于产品全过程,要求质量体系贯穿于质量形成的全过程;实现方法都是PDCA质量环运行模式;都要求对质量实施系统化的管理,都强调一把手对质量的管理。③两者的最终目的一致,都是为了提高产品产量,满足顾客的需要,都强调任何一个过程都是可以不断改进和完善的。

    不同:①两者的期间目标不一致,全面质量管理为了改变现状,作业只限于一次,目标实现后管理活动就结束②两者的工作中心不同,全面质量管理以人为中心,ISO9000以标准为中心③两者的执行标准及检查方式不同。全面质量管理的标准是企业结合其自身特点制定的自我约束的管理体制,检查方主要是企业内部人员,检查方法是考核和评价。ISO9000标准是国际公认的质量管理体系标准,强调的是由公正的第三方对质量体系进行认证并接受认证机构的监督和检查。

    20.6\管理的特征:以顾客为关注焦点,通过提高顾客满意度和降低资源成本来促使组织的业绩提升,注重数据和事实,使管理成为基于数字的科学,以项目为驱动,实现对产品和流程的突破性质量改进,有预见地积极管理,无边界合作,追求完美并容忍失误,强调骨干队伍的建设,遵循DMAIC的改进方法;优点:提升企业管理的能力,节约企业运营成本,增加顾客价值,改进服务水平,形成积极向上的企业文化

    20.

    21.质量功能展开QFD是指在制造过程中,用系统配置需求和特征关系的方法将顾客需求转变成“质量特性”并展开质量设计,最终得到满足质量要求的产品

    22.软件度量是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化的过程;加以理解评估控制和改善

    22.软件测试的目的:为了保证软件质量、提高软件可靠性的重要手段,在软件开发中起着不可代替的作用,其关键和核心是测试数据生成。

    23.软件测试原则:①在整个开发过程中要尽早地和不断地进行软件测试②在开始测试时不应默认程序中不存在错误③在设计测试用例时要给出测试的预期结果④测试工作应避免由系统开发人员或开发机构本身来承担⑤对合理的和不合理的输入数据都要进行测试⑥重点测试错误群集的程序区段⑦除检查程序功能是否完备外还要检查程序功能是否有多余⑧用穷举测试是不可能的⑨长期完整地保留所有的测试用例和测试文件,直到该软件产品被废弃为止

    24.几种集成测试实施方案的比较:非增量式集成测试模式是先分散测试,然后集中起来再一次完成集成测试,自顶向下测试的主要优点在于它可以自然地做到逐步求精能让测试看到系统的架构。自顶向上的优点在于由于驱动模块儿模拟了索赔共调用参数,即便数据流并未构成有像的环状图生成测试数据也没有困难,三明治集成测试,采用自顶向下自顶向上结合的方式,并采取持续集成的策略,有助于尽早发现缺陷也有利于提高工作效率;核心系统先行集成测试能保证一些重要功能和服务的实现,对于快速开发很有效果,一般来讲,在集成测试中采用自顶向下和自顶向上集成测试方案在软件项目集成过程中极为常见。

    24.软件缺陷产生的原因:程序编写错误,编写程序未按照规定,软件越来越复杂,开发人员的态度,沟通上的问题,需求变更太过频繁,进度上的压力,管理上的失误

    21.软件缺陷的特征:①缺陷的发生都是有原因的:缺陷产生的原因是客观存在的②缺陷的重现性:一个缺陷不能重现就无法进行修复。③缺陷的积累性、放大性:软件缺陷发现的越晚,要改正的缺陷所做的工作就越多,所需的成本就越高④缺陷的修复可能又引进新的缺陷:在修复完一个缺陷的时候要仔细检查这个修复会不会带来新的问题,

    22.缺陷分析指标:①缺陷发现率②缺陷潜伏期③软件缺陷密度④缺陷清除率③缺陷密度=软件缺陷数量/代码行或功能点的数量④F为描述软件规模用的功能点,D1为软件开发过程中发现的所有软件缺陷数,D2为软件分布后发现的软件缺陷数,D为发现的总软件缺陷数,由此可得到D=D1+D2的关系:质量(每个功能点的缺陷数)=D2/F

    软件缺陷注入率=D/F;软件清除率=D1/D

    24.集成测试过程①计划阶段:完成集成测试计划,制定集成测试策略②设计实现阶段,建立集成测试环境,完成集成测试设计和开发③执行评估阶段:执行集成测试用例,记录和评估测试结果。

    25.测试文档的撰写①提高易读性:产品易用性大多与软件文档有关②提高可靠性:可靠性是指软件稳定和坚固的程度③降低支持费用:客户发现问题比早在产品开发期发现并修复的费用要高10-100倍,其原因是用户有麻烦或者遇到意外情况就会请示公司的帮助

    26.调试方法:①蛮力法:进行内存映像,激活运行时的跟踪,在程序中到处插入write语句②回溯法:该方法是小程序经常使用并能奏效的常用调试方法,从发现症状的地方开始手工的反向跟踪源代码,直到发现错误原因③原因排除法:这种方法是通过演绎和归纳,以及二分法来实现的,该方法对和错误相关的数据进行分析,并寻找潜在的原因

    27.测试过程

    代码会审:代码会审是由一组人通过阅读讨论和争议过程进行静态分析的过程

    单元测试:单元测试集中在软件设计的最小单位模块上通过测试发现实现该模块的实际功能与定义该模块儿的功能明确不符的情况以及编写的错误

    集成测试:集成测试将模块按照设计要求组装起来同时进行测试主要目标在于发现与接口相关的问题

    验收测试:验收测试的目的是向用户表明系统能够像预定那样工作

    1. 软件6个主要特征:功能性可靠性易使用性可维护护性可移植性
    2. 软件项目追踪和控制正式的技术复审;软件质量保证;软件配置管理;文档的准备和产生可复用管理;测试;风险管理
    展开全文
  • 方案:软件质量保证

    千次阅读 2018-08-06 16:08:26
    软件质量保证 测试计划 编者说明:  要想系统性地完成一件事,首先要做好计划,测试工作是十分重要的,因此测试计划也是十分必要的。该文档适用于集成测试、系统测试、验收测试的计划制订,并不适用于...

    软件质量保证

    测试计划

    编者说明:

        要想系统性地完成一件事,首先要做好计划,测试工作是十分重要的,因此测试计划也是十分必要的。该文档适用于集成测试、系统测试、验收测试的计划制订,并不适用于单元测试计划。

    第1章    引言

    1.1   综述

    1.2   参考文献

    序号

    名称

    文件标识/版本

    出版单位

    出版日期

     

     

     

     

     

    第2章    测试项

    2.1   测试项

    测试项名称

    测试项标识

    介质特性

    变换要求

    相关引用材料

     

     

     

     

     

    2.2   不测试的软件项

    软件项名称

    软件项标识

    未测试原因

    相关引用材料

     

     

     

     

    第3章    被测试的特性

    特性或组合名称

    测试设计说明编号

     

     

    第4章    不被测试的特性

    特性或组合名称

    测试设计说明编号

     

     

    第5章    方法

    5.1   <方法名称>

    5.2   <方法名称>

    第6章    项通过准则

    第7章    暂停标准和再启动要求

    7.1   暂停标准

    7.2   再启动要求

    第8章    应提供的测试文档

    文档名称

    标识符

     

     

    第9章    测试任务

    序号

    任务

    前期任务

    特殊技能

    责任人

    工作量(天)

    完成日期

     

     

     

     

     

     

     

    第10章  环境要求

    10.1 硬件

    10.2 软件

    10.3 安全性

    10.4 工具

    10.5 文档

    第11章  职责

    11.1 测试组

    11.2 开发组

    11.3 ……

    第12章  人员和培训要求

    12.1 人员

    12.1.1      测试组

    12.2 培训

    第13章  进度

    13.1 进度

    序号

    测试任务名称

    工作量

    开始日期

    完成日期

     

     

     

     

     

    13.2 测试资源使用期限

    第14章  风险和应急

     

     

    测试日志

    编者说明:

        测试都有一个结果,而这些结果对于软件质量保证活动来说是十分重要的,因此应该将这些结果有序地记录下来,这就是测试日志模板所要解决的问题。

    第1章    描述

    1.1   测试项

    序号

    测试项名称

    标识符

    版本

    相关传递报告

     

     

     

     

     

    1.2   测试的环境

    1.2.1        硬件

    1.2.2        软件

    第2章    活动和事件条目

    2.1   <日期>

    时间

    活动描述

    事件

     

     

     

    2.2   <日期>

     

     

    测试设计说明

    编者说明:

        如果说测试计划是对测试的活动、人员进行安排,那么测试设计则是对测试方法、测试技术的说明。

    第1章    被测试的特性

    1.1   单项特性

    1.2   组合特性

    1.3   引用文档

    第2章    方法详述

    2.1   方法描述

    2.2   测试评价标准

    2.3   测试用例选择原则

    2.4   测试用例的共同属性和依赖关系

     

     

    测试用例说明

    编者说明:

        测试计划解决的是怎么安排测试活动,测试设计说明是怎么测试,那么测试用例说明就是测试什么,也就是列出具体的测试项目,以使得测试有目的、有计划。

    第1章    测试项

    1.1   测试项名称

    测试项名称

    标识符

    说明

     

     

     

    1.2   引用文档

    编号

    文档名称

    章节名

     

     

     

    第2章    输入说明

    序号

    名称

    类型

    允许误差

    输入方式

     

     

     

     

     

     

    第3章    输出说明

    序号

    名称

    类型

    允许误差

    输出方式

     

     

     

     

     

     

    第4章    环境要求

    4.1   硬件

    4.2   软件

    4.3   其它

    第5章    特殊的规程要求

    第6章    用例间的依赖关系

    6.1   所依赖的用例

    序号

    用例名称或标识

     

     

    6.2   依赖关系的性质

     

     

    集成测试计划(ISO标准)

    编者说明:

        前面的测试计划模板是一个通用性的,也可以是用于制定所有测试活动的计划,而本模块则是用来指导编写集成测试计划的。

    1.引言

    1.1编写目的

            [说明编写这份测试计划目的,指出预期的读者。]

    1.2背景

    a.      待开发系统的名称;

    b.     列出本项目的任务提出者、开发者、用户。

    1.3定义

            [列出本文件中用到的专门术语的定义和外文首字母组词的原词组。]

    1.4参考资料

            [列出有关的参考资料。]

    2.计划

    2.1系统说明

    [提供一份图表,并逐项说明被测系统的功能、输入、输出等质量指标,作为叙述测试计划的提纲。]

    2.2测试内容

    [列出集成测试和确认测试中的每一项测试内容的名称标识符、这些测试的进度安排以及这些测试的内容和目的。]

    2.3测试1(标识符)

            [给出这项测试内容的参与单位及被测试的部位。]

    2.3.1进度安排

                [给出对这项测试的进度安排,包括进行测试的日期和工作内容。]

    2.3.2条件

        [陈述本项测试工作对资源的要求。包括:]

    a.      硬件

    b.     软件

    c.      人员

    2.3.3测试资料

        [列出本项测试所需的资料。]

    2.3.4测试培训

    [说明或引用资料说明为被测系统的使用提供培训的计划。规定培训的内容、受训的人员及从事培训的工作人员。]

    2.4测试2(标识符)

    [用与本测试计划2。3条相类似的方式说明用于另一项及其后各项测试内容的测试工作计划。]

       [……]

    3.测试设计说明

    3.1测试1(标识符)

            [说明对第一项测试内容的测试设计考虑。]

    3.1.1控制

        [说明本测试的控制方式。]

    3.1.2输入

        [说明本项测试中所使用的输入数据及选择这些输入数据的策略。]

    3.1.3输出

        [说明预期的输出数据。]

    3.1.4过程

        [说明完成此项测试的一个个步骤和控制命令。]

    3.2测试2(标识符)

    [用与本测试计划3。1条相类似的方式说明第2项及其后各项测试工作的设计考虑。]

        [……]

    4.评价准则

    4.1范围

            [说明所选择的测试用例能够检查的范围及其局限性。]

    4.2数据整理

    [陈述为了把测试数据加工成便于评价的适当形式,使得测试结果可以同已知结果进行比较而要用到的转换处理技术;如果是用自动方式整理数据,还要说明为进行处理而要用到的硬件、软件资源。]

    4.3尺度

    [说明用来判断测试工作是否能通过的评价尺度,如合理和输出结果的类型、测试输出结果与预期输出之间的容许偏离范围、允许中断或停机的最大数。]

     

     

    软件集成测试工作流程指南

    编者说明:

        严格地说,该文档不属于文档模板,它只是一个工作指南。要想更好地完成集成测试工作,你就需要为团队制定一个工作指南。你可以根据该文档,结合实际进行修改。

    1. 简介

    1.1 目的

    本文详细阐述了集成测试流程,指导项目开发人员如何开展软件集成测试。

    1.2 范围

    此指南可运用于使用RUP 的任一软件项目的集成测试。

    1.3 参考文件

    Software Test Process

    Rational Unified Process

    1.4 定义与缩写

    RUP:统一开发过程

    SIT:软件集成测试

    SEPG:软件工程过程小组

    SQA:软件质量保证

    2. 集成测试指南

    2.1 简介

    集成测试的目的是确保各单元组合在一起后能够按既定意图协作运行,并确保增量的行为正确。它所测试的内容包括单元间的接口以及集成后的功能。使用黑盒测试方法测试集成的功能。并且对以前的集成进行回归测试。

    2.2 单元测试工作内容及其流程

    活动

    输入工件

    输出工件

    参与角色和职责

    制定集成测试计划

    设计模型

    集成构建计划

    集成测试计划

    测试设计员负责制定集成测试计划

    设计集成测试

     

    集成测试计划

    设计模型

    集成测试用例

    测试过程

    测试设计员负责设计集成测试用例和测试过程。

    实施集成测试

     

    集成测试用例

    测试过程

    工作版本

    测试脚本(可选)

    测试过程(更新)

    测试设计员负责编制测试脚本(可选),更新测试过程。

    驱动程序或稳定桩

    设计员负责设计驱动程序和桩,实施员负责实施驱动程序和桩。

    执行集成测试

    测试脚本(可选)

    工作版本

    测试结果

    测试员负责执行测试并记录测试结果

    评估集成测试

    集成测试计划

    测试结果

    测试评估摘要

    测试设计员负责会同集成员、编码员、设计员等有关人员(具体化)评估此次测试,并生成测试评估摘要。

    2.3 集成测试需求获取

    集成测试需求所确定的是对某一集成工作版本的测试的内容,即测试的具体对象。集成测试需求主要来源于设计模型(Design Model )和集成构件计划(Integration Build Plan )。

    集成测试着重于集成版本的外部接口的行为。因此,测试需求须具有可观测、可测评性。

    1.集成工作版本应分析其类协作与消息序列,从而找出该工作版本的外部接口。

    2.由集成工作版本的外部接口确定集成测试用例。

    3.测试用例应覆盖工作版本每一外部接口的所有消息流序列。

    注意:一个外部接口和测试用例的关系是多对多,部分集成工作版本的测试需求可映射到系统测试需求,因此对这些集成测试用例可采用重用系统测试用例技术。

    2.4 集成测试工作机制

    软件集成测试工作由产品评测部担任。需要项目组相关角色配合完成。如图示:

    软件评测部:

    角色

    职责

    测试设计员

    负责制定集成测试计划、设计集成测试、实施集成测试、评估集成测试。

    测试员

    执行集成测试,记录测试结果。

    软件项目组:

    角色

    职责

    实施员

    负责实施类(包括驱动程序和桩),并对其进行单元测试。根据集成测试发现的缺陷提出变更申请。

    配置管理员

    负责对测试工件进行配置管理。

    设计员

    负责设计测试驱动程序和桩。根据集成测试发现的缺陷提出变更申请。

    集成测试工作内容及其流程工作流程:

     

    Desinger:开发设计模型

    Integrator:制定集成计划

    Implementer :实施类,进行单元测试

    Test Designer :制定集成测试计划,设计集成测试用例、测试过程、测试脚本

    Tester :执行集成测试,生成测试日志

     

    Designer & Implementer :提出变更请求

     

    变更流程

    Test Designer :评估集成测试,生成评估摘要

     

    缺陷

     

     
     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    2.5 集成测试产生的工件清单

    1、软件集成测试计划

    2、集成测试用例

    3、测试过程

    4、测试脚本

    5、测试日志

    6、测试评估摘要

     

     

    软件系统测试工作指南

    编者说明:

        这是一个系统测试的工作指南。你可以根据该文档,结合实际进行修改。

    1. 简介

    1.1 目的

    本文详细阐述了系统测试的类型以及各个类型的基本测试方法,指导项目开发人员进行软件系统测试。

    1.2 范围

    本文适用于使用RUP 的所有软件项目的系统测试工作。

    1.3 文档结构

    第一部分:简介,介绍软件系统测试指南的目的,本指南的适用范围,以及在本文档中使用的术语的解释。

    第二部分:描述系统测试指南。包括系统测试流程、系统测试需求的获取、系统测试侧策略选择、系统测试技术和方法等。

    第三部分:列出本指南使用的参考文献。

    1.4 词汇表

    系统测试(System Testing):系统测试是通过与系统的需求规格作比较,发现软件与系统需求规格不相符合或与之矛盾的地方。它将通过确认测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来,在实际运行(使用)环境下,对计算机系统进行的测试。

    黑盒测试(Black-Box Testing):黑盒测试是基于系统需求规格,在不知道系统或组件的内部结构的情况下进行的测试。通常又将黑盒测试叫做:基于规格的测试(Specification-Based Testing )、输入输出测试(Input/Output Testing )、功能测试(Functional Testing )。

    2. 系统测试指南

    2.1 系统测试过程

    活动名称

    输入工件

    输出工件

    参与角色

    制定系统测试计划

    软件需求工件

    软件项目计划

    系统测试计划

    测试设计员

    设计系统测试

     

    系统测试计划

    软件需求工件

    系统测试用例

    系统测试过程

     

    测试设计员

    实施系统测试

     

    系统测试计划

    工作版本

    系统测试脚本

    测试设计员

    执行系统测试

    系统测试计划

    系统测试用例

    系统测试过程

    系统测试脚本

    测试结果

    测试员

    评估系统测试

    测试结果

    测试分析报告

    变更请求

    测试设计员

    相关组

        2.2 系统测试需求获取

    系统测试需求所确定的是测试的内容,即测试的具体对象。系统测试需求主要来源于需求工件集,它可能是一个需求规格说明书,或是由前景、用例、用例模型、词汇表、补充规约组成的一个集合。

    在分析测试需求时,可应用以下几条一般规则:

    1. 测试需求必须是可观测、可测评的行为。如果不能观测或测评的测试需求,就无法对其进行评估,以确定需求是否已经满足。
    2. 在每个用例或系统的补充需求与测试需求之间不存在一对一的关系。用例通常具有多个测试需求;有些补充需求将派生一个或多个测试需求,而其他补充需求(如市场需求或包装需求)将不派生任何测试需求。
    3. 在需求规格说明书中每一个功能描述将派生一个或多个测试需求,性能描述、安全性描述等也将派生出一个或多个测试需求。

    1. 功能性测试需求

    功能性测试需求来自于测试对象的功能性说明。每个用例至少会派生一个测试需求。对于每个用例事件流,测试需求的详细列表至少会包括一个测试需求。对于需求规格说明书中的功能描述,将至少派生一个测试需求。

    2. 性能测试需求

    性能测试需求来自于测试对象的指定性能行为。性能通常被描述为对响应时间和资源使用率的某种评测。性能需要在各种条件下进行评测,这些条件包括:

    1)不同的工作量和/或系统条件

    2)不同的用例/功能

    3)不同的配置

    4)性能需求在补充规格或需求规格说明书中的性能描述部分中说明。

    对包括以下内容的语句要特别注意:

    1)时间语句,如响应时间或定时情况

    2)指出在规定时间内必须出现的事件数或用例数的语句

    3)将某一项性能的行为与另一项性能的行为进行比较的语句

    4)将某一配置下的应用程序行为与另一配置下的应用程序行为进行比较的语句

    5)一段时间内的操作可靠性(平均故障时间或 MTTF )

    6)配置或约束

    应该为规格中反映以上信息的每个语句生成至少一个测试需求。

    3. 其它测试需求

    其它测试需求包括配置测试、安全性测试、容量测试、强度测试、故障恢复测试、负载测试等测试需求可以从非功能性需求中发现与其对应的描述。每一个描述信息可以生成至少一个测试需求。

    2.3 系统测试策略

    测试策略用于说明某项特定测试工作的一般方法和目标。系统测试策略主要针对系统测试需求确定测试类型及如何实施测试的方法和技术。

    一个好的测试策略应该包括要实施的测试类型和测试的目标、所采用的技术、用于评估测试结果和测试是否完成的标准、对测试策略所述的测试工作存在影响的特殊事项等内容。

    2.3.1 系统测试类型和目标

    确定系统测试策略首先应清楚地说明所实施系统测试的类型和测试的目标。清楚地说明这些信息有助于尽量避免混淆和误解(尤其是由于有些类型测试看起来非常类似,如强度测试和容量测试)。测试目标应该表明执行测试的原因。

    系统测试的测试类型一般包括:功能测试(Functional Testing)、性能测试(Performance Testing)负载测试(Load Testing)、强度测试(Stress Testing)、容量测试(Volume Testing)、安全性测试(Security Testing)、配置测试(Configuration Testing)、故障恢复测试(Recovery Testing)、安装测试(Installation Testing)、文档测试(Documentation Testing)、用户界面测试(GUI Testing)等等。

    其中,功能测试、配置测试、安装测试等在一般情况下是必需的。而其它的测试类型则需要根据软件项目的具体要求进行裁剪。

    2.3.2 采用的测试技术

    系统测试主要采用黑盒测试技术设计测试用例来确认软件满足需求规格说明书的要求。

    2.4 系统测试的工作机制

    1)项目组为每一个软件项目成立测试组,确定测试经理(通常由测试设计员担任)一名,测试设计员和测试员若干。

    角色

    职责

    测试设计员

    制定系统测试计划、设计系统测试、实施系统测试以及评估系统测试

    测试员

    执行系统测试

    2)项目组需要提供系统测试需要的输入,建立测试环境,以及对测试工件进行配置管理。

    角色

    职责

    系统分析员

    生成需求工件集,管理需求。为测试设计员提供测试需求。

    配置管理员

    对测试工件进行配置管理

     

     

     

     

     

     

     

     

     

    软件需求说明书

    测试需求

    测试需求

    测试需求

    测试用例

    测试用例

    测试用例

    测试过程

    测试过程

    测试过程

    测试过程

    测试过程

    测试分析报告

     

     

     

     

     

     

     

     

    系统分析员

    测试设计员

    测试设计员

    测试设计员

    测试设计员

    测试员

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    2.5 系统测试产生的工件清单

    1)软件系统测试计划

    2)系统测试用例

    3)系统测试过程

    4)测试脚本(可选)

    5)测试结果

    6)测试分析报告

     

     

    测试分析报告(GB标准)

    编者说明:

        测试完成后,将会形成一些测试日志,对于每个测试用例也有了一个反馈的结果,那么从这个数据中看出问题、找到问题以及寻找解决问题的方法,那就是测试分析报告所要完成的事了。

    1.引言

      1.1 编写目的

        [说明这份测试分析报告的具体编写目的,指出预期的阅读范围。]

      1.2 背景

        [说明:]

        [ a. 被测试软件系统的名称;]

    [ b. 该软件的任务提出者、开发者、用户及安装此软件的计算中心,指出测试环境与实际运行环境之间可能存在的差异以及这些差异对测试结果的影响。]

      1.3 定义

        [列出本文件中用到的专问术语的定义和外文首字母组词的原词组。]

      1.4 参考资料

        [列出要用到的参考资料,如:]

        [ a. 本项目的经核准的计划任务书或合同、上级机关的批文;]

            [ b. 属于本项目的其他已发表的文件;]

      [ c. 本文件中各处引用的文件、资料,包括所要用到的软件开发标准。]

    [列出这些文件的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。]

    2.测试概要

        [用表格的形式列出每一项测试的标识符及其测试内容,并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别,说明作出这种改变的原因。]

    3.测试结果及发现

       3.1  测试1(标识符)

    [把本项测试中实际得到的动态输出(包括内部生成数据输出)结果同对于动态输出的要求进行比较,陈述其中的各项发现。]

      3.2 测试2(标识符)

        [用类似本报告 3.1 条的方式给出第 2项及其后各项测试内容的测试结果和发现。]

    4.对软件功能的结论

    4.1功能1(标识符)

        4.1.1 能力

    [简述该项功能,说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。]

        4.1.2 限制

    [说明测试数据值的范围(包括动态数据和静态数据),列出就这项功能而言,测试期间在该软件中查出的缺陷、局限性。]

      4.2 功能2(标识符)

        [用类似本报告4.l的方式给出第2项及其后各项功能的测试结论。]

       ......

    5 分析摘要

    5.1 能力

    [陈述经测试证实了的本软件的能力。如果所进行的测试是为了验证一项或几项特定性能要求的实现,应提供这方面的测试结果与要求之间的比较,并确定测试环境与实际运行环境之间可能存在的差异对能力的测试所带来的影响。]

    5.2 缺陷和限制

    [陈述经测试证实的软件缺陷和限制,说明每项缺陷和限制对软件性能的影响,并说明全部测得的性能缺陷的累积影响和总影响。]

      5.3 建议

        [对每项缺陷提出改进建议,如:]

        [ a. 各项修改可采用的修改方法;]

        [ b. 各项修改的紧迫程度;]

        [ c. 各项修改预计的工作量;]

        [ d. 各项修改的负责人。]

    5.4 评价

            [说明该项软件的开发是否已达到预定目标,能否交付使用。]

    6 测试资源消耗

    [总结测试工作的资源消耗数据,如工作人员的水平级别数量、机时消耗等。]

     

     

    测试规程说明

    编者说明:

        软件测试就像生产线上的产品测试一样,需要专业的技能与工作方法,而测试规程则是确保每次测试动作高度统一。

    第1章    目的

    1.1   一般目的

    1.2   执行的测试用例

        序号

    测试用例名称或标识符

     

     

    第2章    特殊要求

    2.1   前继规程

        序号

    前继规程的名称或标识符

     

     

        2.2   专门技能

    2.3   特殊环境

    2.4   其它

    第3章    规程步骤

    3.1   日志

    3.2   准备

    3.3   启动

    3.4   处理

    3.5   度量

    3.6   暂停

    3.7   再启动

    3.8   停止

    3.9   清除

    3.10 应急

     

     

    计算机软件测试文件编制规范

    编者说明:

        测试是一个复杂、系统化的工作,也是一个内容广泛的课题,其间将产生大量的文档。本文档就是一个指导所有这些文档编写的规范。你可以根据自己的实际,对其修改,以适用于你的开发团队。

    1.引言

    1.1 目的和作用

    本规范规定一组软件测试文件。测试是软件生存周期中一个独立的、关键的阶段,也是保证软件质量的重要手段。为了提高检测出错误的几率,使测试能有计划地、有条不紊地进行地进行,就必须要编制测试文件。而标准化的测试文件就如同一种通用的参照体系,可达到便于交流的目的。文件中所规定的内容可以作为对测试过程完备性的对照检查表,故采用这些文件将会提高测试过程的每个阶段的能见度,极大地提高测试工作的可管理性。

    1.2 适用对象及范围

    本规范是为软件管理人员、软件开发人员和软件维护人员、软件质量保证人员、审计人员、客户及用户制定的。

    本规范用于描述一组测试文件,这些测试文件描述测试行为。本规范定义每一种基本文件的目的、格式和内容。所描述的文件着重于动态测试过程,但有些文件仍适用其它种类的测试活动。

    本规范可应用于数字计算机上运行的软件。它的应用范围不受软件大小、复杂度或重要性的限制,本规范既适用于初始开发的软件测试文件编制,也适用于其后的软件产品更新版本的测试文件编制。

    本规范并不要求采用特定的测试方法学、技术及设备或工具。对文件控制、配置管理或质量保证既不指明也不强制特定的方法学。根据所用的方法学,可能需要增加别的文件(如“质量保证计划”)。

    本规范既适用于纸张上的文件,也适用于其它媒体上的文件。如果电子文件编制系统不具有安全的批准注册机制,则批准签字的文件必须使用纸张。

    2.引用标准

    GB/T 11457 软件工程术语

    GB 8566 计算机软件开发规范

    GB 8567 计算机软件产品开发文件编制指南

    3.定义

    本章定义本规范中使用的关键术语。

    3.1 设计层 design level

    软件项的设计分解(如系统、子系统、程序或模块)。

    3.2 通过准则 pass criteria

    判断一个软件项或软件特性的测试是否通过的判别依据。

    3.3 软件特性 software feature

    软件项的显著特性。(如功能、性能或可移植性等)。

    3.4 软件项 software item

    源代码、目标代码、作业控制代码、控制数据或这些项的集合。

    3.5 测试项 test item

    作为测试对象的软件项。

    4.概述

    4.1 主要内容

    本规范确定了各个测试文件的格式和内容,所提出的文件类型包括测试计划、测试说明和测试报告。

    测试计划描述测试活动的范围、方法、资源和进度。它规定被测试的项、被测试的特性、应完成的测试任务、担任各项工作的人员职责及与本计划有关的风险等。

    测试说明包括三类文件:

    (1)测试设计说明:详细描述测试方法,规定该设计及其有关测试所包括的特性,还规定完成测试所需的测试用例和测试规程,并规定特性的通过准则。

    (2)测试用例说明:列出用于输入的具体值以及预期的输出结果,并规定在使用具体测试用例时,对测试规程的各种限制。将测试用例与测试设计分开,可以使它们用于多个设计并能在其它情形下重复使用。

    (3)测试规程说明:规定对于运行系统和执行指定的测试用例来实现有关测试设计所要求的所有步骤。

    测试报告包括四类文件:

    (1)测试项传递报告:指明在开发组和测试组独立工作的情况下或者在希望正式开始测试的情况下为进行测试而被传递的测试项。

    (2)测试日志:测试组用于记录测试执行过程中发生的情况。

    (3)测试事件报告:描述在测试执行期间发生并需进一步调查的一切事件。

    (4)测试7总结报告:总结与测试设计说明有关的测试活动。

    这些文件同其它文件在编制方面的关系以及同测试过程的对应关系如图1所示。

    4.2 实施灵活性

    在GB 8567中,涉及软件测试的文件有“测试计划”及“测试分析报告”。本规范中的八个测试文件是上述二个文件的补充和细化,这样可使文件的书定更具体、更有参照性,其中测试计划可细化为本规范的测试计划、测试设计说明、测试用例说明及测试规程说明,测试分析报告可细化为本规范的测试项传递报告、测试日志、测试事件报告及测试总结报告。

    使用本规范的每个单位,要规定测试阶段所应有的特定文件,并在测试计划中规定测试完成后所能提交的全部文件。对于不同的设计层或不同规模的软件,所选文件的种类也可有所不同。

    在所提供的每个标准文件中,每一章的内容对于具体的应用和特定的测试阶段可以有所增减。不仅可以调整内容,还可以在基本文件集中增加另外的文件。任何一个文件都可以增加新的内容,并且某章若无可写的内容,则可不写,但须保留该章的编号。使用本规范的每个单位应该补充规定对内容的要求和约定,以便反映自己在测试、文件控制、配置管理和质量保证方面所用的特定方法、设备和工具。

    附录A(参考件)中,将叙述文件编制实施及使用指南。

    4.3 总体要求

    以下将叙述各个测试文件的书写格式及内容。对于每一个文件而言各章应按指定的次序排列,补充的章可以放在最后或放在“批准”一章的前面(如果该文件最后一章是“批准”的话)。如果某章的部分或全部内容在另一文件中,则应在相应的内容位置上列出所引用的材料,引用的材料必须附在该文件后面或交给文件的使用者。

    5.内容要求

    5.1 测试计划

    测试计划结构如下图所示。

     

     
     

    1 测试计划名称

    2 引言

    3 测试项

    4 被测试的特性

    5 不被测试的特性

    6 方法

    7 项通过准则

    8 暂停标准和再启动要求

    9 应提供的测试文件

    10 测试任务

    11 环境要求

    12 职责

    13 人员和训练要求

    14 进度

    15 风险和应急

    16 批准

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    下面给出每一章的详细内容:

    5.1.1 测试计划名称(本计划的第1章)

    为本测试计划取现代战争专用的名称。

    5.1.2 引言(本计划的第2章)

    归纳所要求测试的软件项和软件特性,可以包括系统目标、背景、范围及引用材料等。

    在最高层测试计划中,如果存在下述文件,则需要引用它们:项目计划、质量保证计划、有关的政策、有关的标准等。

    5.1.3 测试项(本计划的第3章)

    描述被测试的对象,包括其版本、修订级别,并指出在测试开始之前对逻辑或物理变换的要求。

    5.1.4 被测试的特性(本计划的第4章)

    指明所有要被测试的软件特性及其组合,指明每个特性或特性组合有关的测试设计说明。

    5.1.5 不被测试的特性(本计划的第5章)

    指出不被测试的所有特性和特性的有意义的组合及其理由。

    5.1.6 方法(本计划的第6章)

    描述测试的总体方法,规定测试指定特性组志需的主要活动、、技术和工具,应详尽地描述方法,以便列出主要的测试任务,并估计执行各项任务所需的时间。规定所希望的电低程度的测试彻底性,指明用于判断测试彻底性的技术(如:检查哪些语句至少执行过一次)。指出对测试的主要限制,例如:测试项可用性、测试资源的可用性和测试截止期限等。

    5.1.7 项通过准则(本计划的第7章)

    规定各测试项通过测试的标准。

    5.1.8 暂停标准和再启动要求(本计划第8章)

    规定用于暂停全部或部分与本计划有关的测试项的测试活动的标准。规定当测试再启动时必须重复的测试活动。

    5.1.9 应提供的测试文件(本计划的第9章)

    规定测试完成后所应递交的文件,这些文件可以是前述八个文件的全部或者部分。

    5.1.10 测试任务(本计划的第10章)

    指明执行测试所需的任务集合,指出任务音的一切依赖关系和所需的一切特殊技能。

    5.1.11 环境要求(本计划的第11章)

    规定测试环境所必备的和希望的的性质。包括:硬件、通信和系统软件的物理特征、使用方式以及任何其它支撑测试所需的软件或设备,指出所需的特殊测试工具及其它测试要求(如出版物或办公场地等)。指出测试组目前还不能得到的所有要求的来源。

    5.1.12 职责(本计划的第12章)

    指出负责管理、设计、准备、执行、监督、检查和仲裁的小组。另外指出负责提供

    5.1.3 中指出的测试项和在5.1.11中指出的环境要求的小组。

    这些小组可以包括开发人员、测试人员、操作员、用户代表、数据管理员和质量保证人员。

    5.1.13 人员和训练要求(本计划的第13章)

    指明测试人员应有的水平以及为掌握必要技能可供选择的训练科目。

    5.1.14 进度(本计划的第14章)

    包括在软件项目进度中规定的测试里程碑以及所有测试项传递时间。

    定义所需的新的测试里程碑,估计完成每项测试任务所需的时间,为每项测试任务和测试里程碑规定进度,对每项测试资源规定使用期限。

    5.1.15 风险和应急(本计划的第15章)

    预测测试计划中的风险,规定对各种风险的应急措施(如:延期传递的测试项可能需要加夜班来赶上规定的进度。)

    5.1.16 批准(本计划的第16章)

    规定本计划必须由哪些人(姓名和职务)审批。为签名和填写日期留出位置。

    5.2 测试设计说明

    测试设计说明如下图所示。

    1 测试设计说明名称

    2 被测试的特性

    3 方法详述

    4 测试用例名称

    5 特性通过准则

    下面给出本说明每一章的详细内容。

    5.2.1 测试设计说明名称(本说明第1章)

    给每一个测试设计说明取一个专用名称。如果存在的话,也可引用有关的测试计划中给出的名称。

    5.2.2 被测试的特性(本说明的第2章)

    规定测试项,描述作为本设计测试目标的特性和特性的组合,其它特性可以论及,但不必测试。

    5.2.3 方法详述(本说明的第3章)

    将测试计划中规定的方法进行细化,包括要用的具体测试技术,规定分析测试结果的方法(如比较程序或人工观察)。

    规定为选择测试用例提供合理依据的一切分析结果。例如:可以说明容错的条例(如:区别有效输入和无效输入的条件)。

    归纳所有测试用例的共同属性,可以包括输入约束条件,共享环境的要求,对共享的特殊规程的要求及任何共享的测试用例间的依赖关系。

    5.2.4 测试例名称(本说明的第4章)

    列出与本设计有关的每一测试用例的名称和简要说明。某个特定的测试用例可能在多个测试设计说明中出现,列出与本测试设计说明有关的规程及其简要说明。

    5.2.5 特性通过准则(本说明的第5章)

    规定用于判别特性和特性组合是否通过测试的准。

    5.3 测试用例说明

    测试用例说明结构如下图所示。

    1 测试用例说明名称

    2 测试项

    3 输入说明

    4 输出说明

    5 环境要求

    6 特殊的规程说明

    7 用例间的依赖关系

    由于测试用例可能被由多个小组长期使用的多个测试设计说明引用,所以在测试用例说明中必须包含足够具体的信息以便重复使用。

    下面给出本说明每一章的详细内容。

    5.3.1 测试用例说明名称(本说明的第1章)

    给本测试用例说明取一个专用名称

    5.3.2 测试项(本说明的第2章)

    规定并简要说明本测试用例所要涉及的项和特性、对于每一项、可考虑引用以下文件:需求说明书、设计说明书、用户手册、操作手册。

    5.3.3 输入说明(本说明的第3章)

    规定执行测试用例所需的各个输入。有些输入可以用值(允许适当的误差)来规定。而另一些输入,如常数表或事务文件可以用名来规定。规定所有合适的数据库、文件、终端信息、内存常驻区域和由操作系统传送的值。规定各输入间所需的所有关系(如时序关系等)。

    5.3.4 输出说明(本说明的第4章)

    规定测试项的所有输出和特性(如:响应时间)。提供各个输出或特性的正确值(在适当的误差范围内)。

    5.3.5 环境要求(本说明的第5章)

    5.3.5.1 硬件

    规定执行本测试用例所需的硬件特征和配置(如:80字符×24行的显示终端)。

    5.3.5.2 软件

    规定执行本测试用例所需的系统软件和应用软件。系统软件可以包括操作系统、编译程序、模拟程序和测试工具等。

    5.3.5.3 其它

    说明所有其它的要求,如特种设施要求或经过专门训练的人员等。

    5.3.6 特殊的规程要求(本说明的第6章)

    描述对执行本测试用例的测试规程的一切特殊限制。这些限制可以包括特定的准备、操作人员干预、确定特殊的输出和清除过程。

    5.3.7 用例间的依赖关系(本说明的第7章)

    列出必须在本测试用例之前执行的测试用例名称,归纳依赖性质。

    5.4 测试规程说明

    测试规程说明结构如下图表示

    1 测试规程说明名称

    2 目的

    3 特殊要求

    4 规程步骤

    下面给出本说明每一章的详细内容。

    5.4.1 测试规程说明名称(本说明的第1章)

    给每个测试规程说明取一个专用名称,给出对有关测试设计说明的引用。

    5.4.2 目的(本说明的第2章)

    描述本规程的目的。如果本规程执行测试用例,则引用各有关的测试用例说明。

    5.4.3 特殊要求(本说明的第3章)

    指出执行本规程所需的所有特殊要求,包括作为先决条件的规程、专门技能要求和特殊环境要求。

    5.4.4 规程步骤(本说明的第4章)

    5.4.4.1 日志

    说明用来记录测试的执行结果、观察到的事件和其它与测试有关事件(见5.6条测试日志和5.7条测试事件报告)的所有特殊方法或格式。

    5.4.4.2 准备

    描述新任务执行规程所必需的动作序列。

    5.4.4.3 启动

    描述开始执行规程所必需的动作。

    5.4.4.4 处理

    描述在规程执行过程中所必需的动作。

    5.4.4.5 度量

    描述如何进行测试度量(如描述如何用网络模拟程序来充其量远程终端的响应时间)。

    5.4.4.6 暂停

    描述因发生意外事件暂停测试所必需的动作。

    5.4.4.7 再启动

    规定所有再拨动点和在启动点上重新启动规程所必需的动作。

    5.4.4.8 停止

    描述正常停止执行时所必需的动作。

    5.4.4.9 清除

    描述恢复环境所必需的动作。

    5.4.4.10 应急

    描述处理执行过程中可能发生的异常事件所必需的动作。

    5.5 测试项传递报告

    测试项传递报告结构如下图所示。

    1 传递报告名称

    2 传递项

    3 位置

    4 状态

    5 批准

    下面给出本报告每一章的详细内容。

    5.5.1 传递报告名称(本报告的第1章)

    为本测试项传递报告取一个专用名称。

    5.5.2 传递项(本报告的第2章)

    规定被传递的项及其版本/修订级别。提供与传递项有关的项文件和测试计划的相关信息,指出对该传递项负责的人员。

    5.5.3 位置(本报告的第3章)

    规定传递项的位置及其所在媒体。

    5.5.4 状态(本报告的第4章)

    描述被传递的测试项的状态,包括其与项文件、这些项的以往传递以及测试计划的差别。列出希望由被传递项解决的事件报告。

    5.5.5 批准(本报告的第5章)

    规定本传递报告必须由哪些人(姓名和职务)审批,并为签名和日期留出位置。

    5.6 测试日志

    测试日志结构如下图所示。

    1 测试日志名称

    2 描述

    3 活动和事件条目

     

     下面给出本报告每一章的详细内容。

    5.6.1 测试日志名称(本日志的第1章)

    为本测试日志取一专用的名称。

    5.6.2 描述(本日志的第2章)

    除了在日志条目中特别注明的以外,用于日志中所有条目的信息都包括在本章中。应该考虑有以下信息:

    (1)规定被测试项及其版本/修订级别。如果存在的话,引用各项的传递报告。

    (2)规定完成测试的环境属性,包括设备说明、所用的硬件、所用的系统软件及可用存储容量等可用资源。

    5.6.3 活动和事件条目(本日志的第3章)

    对每个事件(包括事件的开始和结束),记录发生的日期和时间,并说明记录者。应考虑以下各项信息。

    5.6.3.1 执行描述

    记录所执行的测试规程的名称,并引用该测试规程说明。记录执行时在场人员,包括:测试者、操作员和观察员,还要说明每个人的作用。

    5.6.3.2 测试结果

    对每次执行,记录人工可观察到的结果(如:产生的错误信息、异常中止和对操作员动作的请求等),还要记录所有输出的位置(如磁带号码),记录测试的执行是否成功。

    5.6.3.3 环境信息

    记录本条目的的一切特殊的环境条件。

    5.6.3.4 意外事件

    记录意外事件及其发生前后的情况(如请求显示总计,屏幕显示正常,但响应时间似乎异常长,重复执行时响应时间也同样过长)。记录无法开始执行测试或无法结束测试的周围环境(如电源故障或系统软件问题)。

    5.6.3.5 事件报告名称

    每产生一个测试事件报告时,记录其名称。

    5.7 测试事件报告

    测试事件报告结构如下图所示。

    1 测试事件报告名称

    2 摘要

    3 事件描述

    4 影响

     

     下面给出本报告每一章的详细内容。

    5.7.1 测试事件报告名称(本报告的第1章)

    为本测试事件报告取一个专用名称。

    5.7.2 摘要(本报告的第2章)

    简述事件,指出有关测试项及其版本/修订级别。引用有关的测试规程说明、测试用例说明及测试日志。

    5.7.3 事件描述(本报告的第3章)

    对事件进行描述。该描述应包括以下各项:

    输入

    预期结果

    实际结果

    异常现象

    日期和时间

    规程步骤

    环境

    重复执行的意图

    测试者

    观察者

    该描述应该包括有助于确定事件发生原因及改正其中错误的有关浩劫及观察。例如,描述可能对此事件有影响的所有测试用例执行情况,描述与已公布的测试规程之间的一切差异等。

    5.7.4 影响(本报告的第4章)

    在所知道的范围内指出本事件对测试计划、测试设计说明、测试规程说明或测试用例说明所产生的影响。

    5.8 测试总结报告

    规定本报告必须由哪些人(姓名和职务)审批,并为签名和日期留出位置。

     

     

    单元测试报告

    编者说明:

        单元测试是每一个开发人员都必须去做的事,它将采用白盒方法来进行,为了跟踪单元测试的效果,对开发人员进行督促,对于一些重要的模块进行测试是很必要的。该表格就是用来让开发人员填写单元测试的结果的文档。

    填表日期:                                   编号:

    开发项目名称

     

    开发项目编号

     

    第一责任人

     

    单元名称

     

    责任人

     

    单元所属子系统

     

    开发周期

     

    代码测试检查:

     代码测试内容

    测试人员

                测试结果

         备注

      路径测试

     

     

     

      声明测试

     

     

     

      循环测试

     

     

     

      边界测试

     

     

     

      接口测试

     

     

     

      界面测试

     

     

     

      数据确认测试

     

     

     

      代码走查

     

     

     

    功能测试:

    序号

         功能名称

        操作方法

      结果

     建议

    测试人员

    备注

     

     

     

     

     

     

     

     测试结论

     

      责任人

     

    项目第一责任人

     

       审核

     

    项目组

     

    测试组

     

    总工办

     

    总工程师

     

                                 

     

     

    五、其它类模块开发说明(ISO标准)

    编程说明:

        该文档将与模块开发卷宗结合使用,卷宗是对整个系统进行整理,而模块开发说明则是对具体的模块进行说明,其作用于归档阶段。

    1.标题

    [系统名称和标识符]

    [模块名称和标识符]

    [程序编制员签名]

    [卷宗的修改文本序号]

    [修改完成日期]

    [卷宗序号]

    [编排日期]

    2.模块开发情况表

    3.功能说明

        [扼要说明本模块的功能,主要是输入、要求的处理、输出。可以从系统设计说明书中摘录。同时列出在需求说明书中对这些功能的说明的章、条、款。]

    4.设计说明

        [说明本模块的设计考虑]

    5.硬件部分的设计结果

    1)  经项目组调试通过的硬件成品1件

    2)设计文件:

    《原理图》

    《PCB图》

    《BOM清单》

    《可编程器件及烧录进制文件》

    《必要测试点波形图或硬件指标评细说明》

    《原理详细说明》

    《与系统内其他部分接口软硬件详细说明》

       这些文件可以附件的形式列后。

    6.软件的设计结果

        [要给出所产生的本模块的第一份无语法错的源代码清单以及已通过全部测试的当前有效的源程序代码。]

    7.测试说明

        [说明直接要经过本模块的每一项测试,包括这些测试各自的标识符和编号、进行这些测试的目的、所用的配置和输入、预期的输出及实际的输出。]

    8.复审的结论

        [把实际测试的结果,同需求说明书、系统设计说明书中规定的要求进行比较和给出结论。]

     

    展开全文
  • 软件质量保证

    千次阅读 2018-08-31 10:14:13
     测试都一个结果,而这些结果对于软件质量保证活动来说是十分重要的,因此应该将这些结果有序地记录下来,这就是测试日志模板所要解决的问题。 第1章 描述 1.1 测试项 序号 测试项...

    测试计划

    编者说明:

        要想系统性地完成一件事,首先要做好计划,测试工作是十分重要的,因此测试计划也是十分必要的。该文档适用于集成测试、系统测试、验收测试的计划制订,并不适用于单元测试计划。

    第1章 引言

    1.1 综述

    1.2 参考文献

    序号

    名称

    文件标识/版本

    出版单位

    出版日期

     

     

     

     

     

    第2章 测试项

    2.1 测试项

    测试项名称

    测试项标识

    介质特性

    变换要求

    相关引用材料

     

     

     

     

     

    2.2 不测试的软件项

    软件项名称

    软件项标识

    未测试原因

    相关引用材料

     

     

     

     

    第3章 被测试的特性

    特性或组合名称

    测试设计说明编号

     

     

    第4章 不被测试的特性

    特性或组合名称

    测试设计说明编号

     

     

    第5章 方法

    5.1 <方法名称>

    5.2 <方法名称>

    第6章 项通过准则

    第7章 暂停标准和再启动要求

    7.1 暂停标准

    7.2 再启动要求

    第8章 应提供的测试文档

    文档名称

    标识符

     

     

    第9章 测试任务

    序号

    任务

    前期任务

    特殊技能

    责任人

    工作量(天)

    完成日期

     

     

     

     

     

     

     

    第10章 环境要求

    10.1 硬件

    10.2 软件

    10.3 安全性

    10.4 工具

    10.5 文档

    第11章 职责

    11.1 测试组

    11.2 开发组

    11.3 ……

    第12章 人员和培训要求

    12.1 人员

    12.1.1 测试组

    12.2 培训

    第13章 进度

    13.1 进度

    序号

    测试任务名称

    工作量

    开始日期

    完成日期

     

     

     

     

     

    13.2 测试资源使用期限

    第14章 风险和应急

     

     

    测试日志

    编者说明:

        测试都有一个结果,而这些结果对于软件质量保证活动来说是十分重要的,因此应该将这些结果有序地记录下来,这就是测试日志模板所要解决的问题。

    第1章 描述

    1.1 测试项

    序号

    测试项名称

    标识符

    版本

    相关传递报告

     

     

     

     

     

    1.2 测试的环境

    1.2.1 硬件

    1.2.2 软件

    第2章 活动和事件条目

    2.1 <日期>

    时间

    活动描述

    事件

     

     

     

    2.2 <日期>

     

     

    测试设计说明

    编者说明:

        如果说测试计划是对测试的活动、人员进行安排,那么测试设计则是对测试方法、测试技术的说明。

    第1章 被测试的特性

    1.1 单项特性

    1.2 组合特性

    1.3 引用文档

    第2章 方法详述

    2.1 方法描述

    2.2 测试评价标准

    2.3 测试用例选择原则

    2.4 测试用例的共同属性和依赖关系

     

     

    测试用例说明

    编者说明:

        测试计划解决的是怎么安排测试活动,测试设计说明是怎么测试,那么测试用例说明就是测试什么,也就是列出具体的测试项目,以使得测试有目的、有计划。

    第1章 测试项

    1.1 测试项名称

    测试项名称

    标识符

    说明

     

     

     

    1.2 引用文档

    编号

    文档名称

    章节名

     

     

     

    第2章 输入说明

    序号

    名称

    类型

    允许误差

    输入方式

     

     

     

     

     

     

    第3章 输出说明

    序号

    名称

    类型

    允许误差

    输出方式

     

     

     

     

     

     

    第4章 环境要求

    4.1 硬件

    4.2 软件

    4.3 其它

    第5章 特殊的规程要求

    第6章 用例间的依赖关系

    6.1 所依赖的用例

    序号

    用例名称或标识

     

     

    6.2 依赖关系的性质

     

     

    集成测试计划(ISO标准)

    编者说明:

        前面的测试计划模板是一个通用性的,也可以是用于制定所有测试活动的计划,而本模块则是用来指导编写集成测试计划的。

    1.引言

    1.1编写目的

            [说明编写这份测试计划目的,指出预期的读者。]

    1.2背景

    a. 待开发系统的名称;

    b. 列出本项目的任务提出者、开发者、用户。

    1.3定义

            [列出本文件中用到的专门术语的定义和外文首字母组词的原词组。]

    1.4参考资料

            [列出有关的参考资料。]

    2.计划

    2.1系统说明

    [提供一份图表,并逐项说明被测系统的功能、输入、输出等质量指标,作为叙述测试计划的提纲。]

    2.2测试内容

    [列出集成测试和确认测试中的每一项测试内容的名称标识符、这些测试的进度安排以及这些测试的内容和目的。]

    2.3测试1(标识符)

            [给出这项测试内容的参与单位及被测试的部位。]

    2.3.1进度安排

                [给出对这项测试的进度安排,包括进行测试的日期和工作内容。]

    2.3.2条件

        [陈述本项测试工作对资源的要求。包括:]

    a. 硬件

    b. 软件

    c. 人员

    2.3.3测试资料

        [列出本项测试所需的资料。]

    2.3.4测试培训

    [说明或引用资料说明为被测系统的使用提供培训的计划。规定培训的内容、受训的人员及从事培训的工作人员。]

    2.4测试2(标识符)

    [用与本测试计划2。3条相类似的方式说明用于另一项及其后各项测试内容的测试工作计划。]

       [……]

    3.测试设计说明

    3.1测试1(标识符)

            [说明对第一项测试内容的测试设计考虑。]

    3.1.1控制

        [说明本测试的控制方式。]

    3.1.2输入

        [说明本项测试中所使用的输入数据及选择这些输入数据的策略。]

    3.1.3输出

        [说明预期的输出数据。]

    3.1.4过程

        [说明完成此项测试的一个个步骤和控制命令。]

    3.2测试2(标识符)

    [用与本测试计划3。1条相类似的方式说明第2项及其后各项测试工作的设计考虑。]

        [……]

    4.评价准则

    4.1范围

            [说明所选择的测试用例能够检查的范围及其局限性。]

    4.2数据整理

    [陈述为了把测试数据加工成便于评价的适当形式,使得测试结果可以同已知结果进行比较而要用到的转换处理技术;如果是用自动方式整理数据,还要说明为进行处理而要用到的硬件、软件资源。]

    4.3尺度

    [说明用来判断测试工作是否能通过的评价尺度,如合理和输出结果的类型、测试输出结果与预期输出之间的容许偏离范围、允许中断或停机的最大数。]

     

     

    软件集成测试工作流程指南

    编者说明:

        严格地说,该文档不属于文档模板,它只是一个工作指南。要想更好地完成集成测试工作,你就需要为团队制定一个工作指南。你可以根据该文档,结合实际进行修改。

    1. 简介

    1.1 目的

    本文详细阐述了集成测试流程,指导项目开发人员如何开展软件集成测试。

    1.2 范围

    此指南可运用于使用RUP 的任一软件项目的集成测试。

    1.3 参考文件

    Software Test Process

    Rational Unified Process

    1.4 定义与缩写

    RUP:统一开发过程

    SIT:软件集成测试

    SEPG:软件工程过程小组

    SQA:软件质量保证

    2. 集成测试指南

    2.1 简介

    集成测试的目的是确保各单元组合在一起后能够按既定意图协作运行,并确保增量的行为正确。它所测试的内容包括单元间的接口以及集成后的功能。使用黑盒测试方法测试集成的功能。并且对以前的集成进行回归测试。

    2.2 单元测试工作内容及其流程

    活动

    输入工件

    输出工件

    参与角色和职责

    制定集成测试计划

    设计模型

    集成构建计划

    集成测试计划

    测试设计员负责制定集成测试计划

    设计集成测试

     

    集成测试计划

    设计模型

    集成测试用例

    测试过程

    测试设计员负责设计集成测试用例和测试过程。

    实施集成测试

     

    集成测试用例

    测试过程

    工作版本

    测试脚本(可选)

    测试过程(更新)

    测试设计员负责编制测试脚本(可选),更新测试过程。

    驱动程序或稳定桩

    设计员负责设计驱动程序和桩,实施员负责实施驱动程序和桩。

    执行集成测试

    测试脚本(可选)

    工作版本

    测试结果

    测试员负责执行测试并记录测试结果

    评估集成测试

    集成测试计划

    测试结果

    测试评估摘要

    测试设计员负责会同集成员、编码员、设计员等有关人员(具体化)评估此次测试,并生成测试评估摘要。

    2.3 集成测试需求获取

    集成测试需求所确定的是对某一集成工作版本的测试的内容,即测试的具体对象。集成测试需求主要来源于设计模型(Design Model )和集成构件计划(Integration Build Plan )。

    集成测试着重于集成版本的外部接口的行为。因此,测试需求须具有可观测、可测评性。

    1.集成工作版本应分析其类协作与消息序列,从而找出该工作版本的外部接口。

    2.由集成工作版本的外部接口确定集成测试用例。

    3.测试用例应覆盖工作版本每一外部接口的所有消息流序列。

    注意:一个外部接口和测试用例的关系是多对多,部分集成工作版本的测试需求可映射到系统测试需求,因此对这些集成测试用例可采用重用系统测试用例技术。

    2.4 集成测试工作机制

    软件集成测试工作由产品评测部担任。需要项目组相关角色配合完成。如图示:

    软件评测部:

    角色

    职责

    测试设计员

    负责制定集成测试计划、设计集成测试、实施集成测试、评估集成测试。

    测试员

    执行集成测试,记录测试结果。

    软件项目组:

    角色

    职责

    实施员

    负责实施类(包括驱动程序和桩),并对其进行单元测试。根据集成测试发现的缺陷提出变更申请。

    配置管理员

    负责对测试工件进行配置管理。

    设计员

    负责设计测试驱动程序和桩。根据集成测试发现的缺陷提出变更申请。

    集成测试工作内容及其流程工作流程:

    2.5 集成测试产生的工件清单

    1、软件集成测试计划

    2、集成测试用例

    3、测试过程

    4、测试脚本

    5、测试日志

    6、测试评估摘要

     

     

    软件系统测试工作指南

    编者说明:

        这是一个系统测试的工作指南。你可以根据该文档,结合实际进行修改。

    1. 简介

    1.1 目的

    本文详细阐述了系统测试的类型以及各个类型的基本测试方法,指导项目开发人员进行软件系统测试。

    1.2 范围

    本文适用于使用RUP 的所有软件项目的系统测试工作。

    1.3 文档结构

    第一部分:简介,介绍软件系统测试指南的目的,本指南的适用范围,以及在本文档中使用的术语的解释。

    第二部分:描述系统测试指南。包括系统测试流程、系统测试需求的获取、系统测试侧策略选择、系统测试技术和方法等。

    第三部分:列出本指南使用的参考文献。

    1.4 词汇表

    系统测试(System Testing):系统测试是通过与系统的需求规格作比较,发现软件与系统需求规格不相符合或与之矛盾的地方。它将通过确认测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来,在实际运行(使用)环境下,对计算机系统进行的测试。

    黑盒测试(Black-Box Testing):黑盒测试是基于系统需求规格,在不知道系统或组件的内部结构的情况下进行的测试。通常又将黑盒测试叫做:基于规格的测试(Specification-Based Testing )、输入输出测试(Input/Output Testing )、功能测试(Functional Testing )。

    2. 系统测试指南

    2.1 系统测试过程

    活动名称

    输入工件

    输出工件

    参与角色

    制定系统测试计划

    软件需求工件

    软件项目计划

    系统测试计划

    测试设计员

    设计系统测试

     

    系统测试计划

    软件需求工件

    系统测试用例

    系统测试过程

     

    测试设计员

    实施系统测试

     

    系统测试计划

    工作版本

    系统测试脚本

    测试设计员

    执行系统测试

    系统测试计划

    系统测试用例

    系统测试过程

    系统测试脚本

    测试结果

    测试员

    评估系统测试

    测试结果 

    测试分析报告

    变更请求

    测试设计员

    相关组

        2.2 系统测试需求获取

    系统测试需求所确定的是测试的内容,即测试的具体对象。系统测试需求主要来源于需求工件集,它可能是一个需求规格说明书,或是由前景、用例、用例模型、词汇表、补充规约组成的一个集合。

    在分析测试需求时,可应用以下几条一般规则:

    测试需求必须是可观测、可测评的行为。如果不能观测或测评的测试需求,就无法对其进行评估,以确定需求是否已经满足。

    在每个用例或系统的补充需求与测试需求之间不存在一对一的关系。用例通常具有多个测试需求;有些补充需求将派生一个或多个测试需求,而其他补充需求(如市场需求或包装需求)将不派生任何测试需求。

    在需求规格说明书中每一个功能描述将派生一个或多个测试需求,性能描述、安全性描述等也将派生出一个或多个测试需求。

    1. 功能性测试需求

    功能性测试需求来自于测试对象的功能性说明。每个用例至少会派生一个测试需求。对于每个用例事件流,测试需求的详细列表至少会包括一个测试需求。对于需求规格说明书中的功能描述,将至少派生一个测试需求。

    2. 性能测试需求

    性能测试需求来自于测试对象的指定性能行为。性能通常被描述为对响应时间和资源使用率的某种评测。性能需要在各种条件下进行评测,这些条件包括:

    1)不同的工作量和/或系统条件

    2)不同的用例/功能

    3)不同的配置

    4)性能需求在补充规格或需求规格说明书中的性能描述部分中说明。

    对包括以下内容的语句要特别注意:

    1)时间语句,如响应时间或定时情况

    2)指出在规定时间内必须出现的事件数或用例数的语句

    3)将某一项性能的行为与另一项性能的行为进行比较的语句

    4)将某一配置下的应用程序行为与另一配置下的应用程序行为进行比较的语句

    5)一段时间内的操作可靠性(平均故障时间或 MTTF )

    6)配置或约束

    应该为规格中反映以上信息的每个语句生成至少一个测试需求。

    3. 其它测试需求

    其它测试需求包括配置测试、安全性测试、容量测试、强度测试、故障恢复测试、负载测试等测试需求可以从非功能性需求中发现与其对应的描述。每一个描述信息可以生成至少一个测试需求。

    2.3 系统测试策略

    测试策略用于说明某项特定测试工作的一般方法和目标。系统测试策略主要针对系统测试需求确定测试类型及如何实施测试的方法和技术。

    一个好的测试策略应该包括要实施的测试类型和测试的目标、所采用的技术、用于评估测试结果和测试是否完成的标准、对测试策略所述的测试工作存在影响的特殊事项等内容。

    2.3.1 系统测试类型和目标

    确定系统测试策略首先应清楚地说明所实施系统测试的类型和测试的目标。清楚地说明这些信息有助于尽量避免混淆和误解(尤其是由于有些类型测试看起来非常类似,如强度测试和容量测试)。测试目标应该表明执行测试的原因。

    系统测试的测试类型一般包括:功能测试(Functional Testing)、性能测试(Performance Testing)负载测试(Load Testing)、强度测试(Stress Testing)、容量测试(Volume Testing)、安全性测试(Security Testing)、配置测试(Configuration Testing)、故障恢复测试(Recovery Testing)、安装测试(Installation Testing)、文档测试(Documentation Testing)、用户界面测试(GUI Testing)等等。

    其中,功能测试、配置测试、安装测试等在一般情况下是必需的。而其它的测试类型则需要根据软件项目的具体要求进行裁剪。

    2.3.2 采用的测试技术

    系统测试主要采用黑盒测试技术设计测试用例来确认软件满足需求规格说明书的要求。

    2.4 系统测试的工作机制

    1)项目组为每一个软件项目成立测试组,确定测试经理(通常由测试设计员担任)一名,测试设计员和测试员若干。

    角色

    职责

    测试设计员

    制定系统测试计划、设计系统测试、实施系统测试以及评估系统测试

    测试员

    执行系统测试

    2)项目组需要提供系统测试需要的输入,建立测试环境,以及对测试工件进行配置管理。

    角色

    职责

    系统分析员

    生成需求工件集,管理需求。为测试设计员提供测试需求。

    配置管理员

    对测试工件进行配置管理

     

    2.5 系统测试产生的工件清单

    1)软件系统测试计划

    2)系统测试用例

    3)系统测试过程

    4)测试脚本(可选)

    5)测试结果

    6)测试分析报告

     

     

    测试分析报告(GB标准)

    编者说明:

        测试完成后,将会形成一些测试日志,对于每个测试用例也有了一个反馈的结果,那么从这个数据中看出问题、找到问题以及寻找解决问题的方法,那就是测试分析报告所要完成的事了。

    1.引言 

      1.1 编写目的 

        [说明这份测试分析报告的具体编写目的,指出预期的阅读范围。]

      1.2 背景 

        [说明:]

        [ a. 被测试软件系统的名称;]

    [ b. 该软件的任务提出者、开发者、用户及安装此软件的计算中心,指出测试环境与实际运行环境之间可能存在的差异以及这些差异对测试结果的影响。]

      1.3 定义

        [列出本文件中用到的专问术语的定义和外文首字母组词的原词组。]

      1.4 参考资料 

        [列出要用到的参考资料,如:]

        [ a. 本项目的经核准的计划任务书或合同、上级机关的批文;]

            [ b. 属于本项目的其他已发表的文件;]

      [ c. 本文件中各处引用的文件、资料,包括所要用到的软件开发标准。]

    [列出这些文件的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。]

    2.测试概要

        [用表格的形式列出每一项测试的标识符及其测试内容,并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别,说明作出这种改变的原因。]

    3.测试结果及发现

       3.1  测试1(标识符)

    [把本项测试中实际得到的动态输出(包括内部生成数据输出)结果同对于动态输出的要求进行比较,陈述其中的各项发现。]

      3.2 测试2(标识符)

        [用类似本报告 3.1 条的方式给出第 2项及其后各项测试内容的测试结果和发现。]

    4.对软件功能的结论 

    4.1功能1(标识符)

        4.1.1 能力

    [简述该项功能,说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。]

        4.1.2 限制

    [说明测试数据值的范围(包括动态数据和静态数据),列出就这项功能而言,测试期间在该软件中查出的缺陷、局限性。]

      4.2 功能2(标识符) 

        [用类似本报告4.l的方式给出第2项及其后各项功能的测试结论。]

       ......

    5 分析摘要 

    5.1 能力

    [陈述经测试证实了的本软件的能力。如果所进行的测试是为了验证一项或几项特定性能要求的实现,应提供这方面的测试结果与要求之间的比较,并确定测试环境与实际运行环境之间可能存在的差异对能力的测试所带来的影响。]

    5.2 缺陷和限制

    [陈述经测试证实的软件缺陷和限制,说明每项缺陷和限制对软件性能的影响,并说明全部测得的性能缺陷的累积影响和总影响。]

      5.3 建议

        [对每项缺陷提出改进建议,如:]

        [ a. 各项修改可采用的修改方法;]

        [ b. 各项修改的紧迫程度;]

        [ c. 各项修改预计的工作量;]

        [ d. 各项修改的负责人。]

    5.4 评价 

            [说明该项软件的开发是否已达到预定目标,能否交付使用。]

    6 测试资源消耗 

    [总结测试工作的资源消耗数据,如工作人员的水平级别数量、机时消耗等。]

     

     

    测试规程说明

    编者说明:

        软件测试就像生产线上的产品测试一样,需要专业的技能与工作方法,而测试规程则是确保每次测试动作高度统一。

    第1章 目的

    1.1 一般目的

    1.2 执行的测试用例

        序号

    测试用例名称或标识符

     

     

    第2章 特殊要求

    2.1 前继规程

        序号

    前继规程的名称或标识符

     

     

        2.2 专门技能

    2.3 特殊环境

    2.4 其它

    第3章 规程步骤

    3.1 日志

    3.2 准备

    3.3 启动

    3.4 处理

    3.5 度量

    3.6 暂停

    3.7 再启动

    3.8 停止

    3.9 清除

    3.10 应急

     

     

    计算机软件测试文件编制规范

    编者说明:

        测试是一个复杂、系统化的工作,也是一个内容广泛的课题,其间将产生大量的文档。本文档就是一个指导所有这些文档编写的规范。你可以根据自己的实际,对其修改,以适用于你的开发团队。

    1.引言

    1.1 目的和作用

    本规范规定一组软件测试文件。测试是软件生存周期中一个独立的、关键的阶段,也是保证软件质量的重要手段。为了提高检测出错误的几率,使测试能有计划地、有条不紊地进行地进行,就必须要编制测试文件。而标准化的测试文件就如同一种通用的参照体系,可达到便于交流的目的。文件中所规定的内容可以作为对测试过程完备性的对照检查表,故采用这些文件将会提高测试过程的每个阶段的能见度,极大地提高测试工作的可管理性。 

    1.2 适用对象及范围

    本规范是为软件管理人员、软件开发人员和软件维护人员、软件质量保证人员、审计人员、客户及用户制定的。 

    本规范用于描述一组测试文件,这些测试文件描述测试行为。本规范定义每一种基本文件的目的、格式和内容。所描述的文件着重于动态测试过程,但有些文件仍适用其它种类的测试活动。 

    本规范可应用于数字计算机上运行的软件。它的应用范围不受软件大小、复杂度或重要性的限制,本规范既适用于初始开发的软件测试文件编制,也适用于其后的软件产品更新版本的测试文件编制。 

    本规范并不要求采用特定的测试方法学、技术及设备或工具。对文件控制、配置管理或质量保证既不指明也不强制特定的方法学。根据所用的方法学,可能需要增加别的文件(如“质量保证计划”)。 

    本规范既适用于纸张上的文件,也适用于其它媒体上的文件。如果电子文件编制系统不具有安全的批准注册机制,则批准签字的文件必须使用纸张。 

    2.引用标准

    GB/T 11457 软件工程术语

    GB 8566 计算机软件开发规范

    GB 8567 计算机软件产品开发文件编制指南

    3.定义

    本章定义本规范中使用的关键术语。 

    3.1 设计层 design level

    软件项的设计分解(如系统、子系统、程序或模块)。 

    3.2 通过准则 pass criteria

    判断一个软件项或软件特性的测试是否通过的判别依据。 

    3.3 软件特性 software feature

    软件项的显著特性。(如功能、性能或可移植性等)。 

    3.4 软件项 software item

    源代码、目标代码、作业控制代码、控制数据或这些项的集合。 

    3.5 测试项 test item

    作为测试对象的软件项。 

    4.概述

    4.1 主要内容

    本规范确定了各个测试文件的格式和内容,所提出的文件类型包括测试计划、测试说明和测试报告。 

    测试计划描述测试活动的范围、方法、资源和进度。它规定被测试的项、被测试的特性、应完成的测试任务、担任各项工作的人员职责及与本计划有关的风险等。 

    测试说明包括三类文件: 

    1)测试设计说明:详细描述测试方法,规定该设计及其有关测试所包括的特性,还规定完成测试所需的测试用例和测试规程,并规定特性的通过准则。

    2)测试用例说明:列出用于输入的具体值以及预期的输出结果,并规定在使用具体测试用例时,对测试规程的各种限制。将测试用例与测试设计分开,可以使它们用于多个设计并能在其它情形下重复使用。

    3)测试规程说明:规定对于运行系统和执行指定的测试用例来实现有关测试设计所要求的所有步骤。

    测试报告包括四类文件: 

    1)测试项传递报告:指明在开发组和测试组独立工作的情况下或者在希望正式开始测试的情况下为进行测试而被传递的测试项。

    2)测试日志:测试组用于记录测试执行过程中发生的情况。

    3)测试事件报告:描述在测试执行期间发生并需进一步调查的一切事件。

    4)测试7总结报告:总结与测试设计说明有关的测试活动。

    这些文件同其它文件在编制方面的关系以及同测试过程的对应关系如图1所示。

    4.2 实施灵活性

    GB 8567中,涉及软件测试的文件有“测试计划”及“测试分析报告”。本规范中的八个测试文件是上述二个文件的补充和细化,这样可使文件的书定更具体、更有参照性,其中测试计划可细化为本规范的测试计划、测试设计说明、测试用例说明及测试规程说明,测试分析报告可细化为本规范的测试项传递报告、测试日志、测试事件报告及测试总结报告。

    使用本规范的每个单位,要规定测试阶段所应有的特定文件,并在测试计划中规定测试完成后所能提交的全部文件。对于不同的设计层或不同规模的软件,所选文件的种类也可有所不同。 

    在所提供的每个标准文件中,每一章的内容对于具体的应用和特定的测试阶段可以有所增减。不仅可以调整内容,还可以在基本文件集中增加另外的文件。任何一个文件都可以增加新的内容,并且某章若无可写的内容,则可不写,但须保留该章的编号。使用本规范的每个单位应该补充规定对内容的要求和约定,以便反映自己在测试、文件控制、配置管理和质量保证方面所用的特定方法、设备和工具。 

    附录A(参考件)中,将叙述文件编制实施及使用指南。

    4.3 总体要求

    以下将叙述各个测试文件的书写格式及内容。对于每一个文件而言各章应按指定的次序排列,补充的章可以放在最后或放在“批准”一章的前面(如果该文件最后一章是“批准”的话)。如果某章的部分或全部内容在另一文件中,则应在相应的内容位置上列出所引用的材料,引用的材料必须附在该文件后面或交给文件的使用者。 

    5.内容要求

    5.1 测试计划

    测试计划结构如下图所示。 

     

    下面给出每一章的详细内容: 

    5.1.1 测试计划名称(本计划的第1章)

    为本测试计划取现代战争专用的名称。 

    5.1.2 引言(本计划的第2章)

    归纳所要求测试的软件项和软件特性,可以包括系统目标、背景、范围及引用材料等。 

    在最高层测试计划中,如果存在下述文件,则需要引用它们:项目计划、质量保证计划、有关的政策、有关的标准等。 

    5.1.3 测试项(本计划的第3章)

    描述被测试的对象,包括其版本、修订级别,并指出在测试开始之前对逻辑或物理变换的要求。 

    5.1.4 被测试的特性(本计划的第4章)

    指明所有要被测试的软件特性及其组合,指明每个特性或特性组合有关的测试设计说明。 

    5.1.5 不被测试的特性(本计划的第5章)

    指出不被测试的所有特性和特性的有意义的组合及其理由。 

    5.1.6 方法(本计划的第6章)

    描述测试的总体方法,规定测试指定特性组志需的主要活动、、技术和工具,应详尽地描述方法,以便列出主要的测试任务,并估计执行各项任务所需的时间。规定所希望的电低程度的测试彻底性,指明用于判断测试彻底性的技术(如:检查哪些语句至少执行过一次)。指出对测试的主要限制,例如:测试项可用性、测试资源的可用性和测试截止期限等。 

    5.1.7 项通过准则(本计划的第7章)

    规定各测试项通过测试的标准。 

    5.1.8 暂停标准和再启动要求(本计划第8章)

    规定用于暂停全部或部分与本计划有关的测试项的测试活动的标准。规定当测试再启动时必须重复的测试活动。 

    5.1.9 应提供的测试文件(本计划的第9章)

    规定测试完成后所应递交的文件,这些文件可以是前述八个文件的全部或者部分。 

    5.1.10 测试任务(本计划的第10章)

    指明执行测试所需的任务集合,指出任务音的一切依赖关系和所需的一切特殊技能。 

    5.1.11 环境要求(本计划的第11章)

    规定测试环境所必备的和希望的的性质。包括:硬件、通信和系统软件的物理特征、使用方式以及任何其它支撑测试所需的软件或设备,指出所需的特殊测试工具及其它测试要求(如出版物或办公场地等)。指出测试组目前还不能得到的所有要求的来源。 

    5.1.12 职责(本计划的第12章)

    指出负责管理、设计、准备、执行、监督、检查和仲裁的小组。另外指出负责提供

    5.1.3 中指出的测试项和在5.1.11中指出的环境要求的小组。

    这些小组可以包括开发人员、测试人员、操作员、用户代表、数据管理员和质量保证人员。 

    5.1.13 人员和训练要求(本计划的第13章)

    指明测试人员应有的水平以及为掌握必要技能可供选择的训练科目。 

    5.1.14 进度(本计划的第14章)

    包括在软件项目进度中规定的测试里程碑以及所有测试项传递时间。 

    定义所需的新的测试里程碑,估计完成每项测试任务所需的时间,为每项测试任务和测试里程碑规定进度,对每项测试资源规定使用期限。 

    5.1.15 风险和应急(本计划的第15章)

    预测测试计划中的风险,规定对各种风险的应急措施(如:延期传递的测试项可能需要加夜班来赶上规定的进度。) 

    5.1.16 批准(本计划的第16章)

    规定本计划必须由哪些人(姓名和职务)审批。为签名和填写日期留出位置。 

    5.2 测试设计说明

    测试设计说明如下图所示。 

    1 测试设计说明名称

    2 被测试的特性

    3 方法详述

    4 测试用例名称

    5 特性通过准则

    下面给出本说明每一章的详细内容。 

    5.2.1 测试设计说明名称(本说明第1章)

    给每一个测试设计说明取一个专用名称。如果存在的话,也可引用有关的测试计划中给出的名称。 

    5.2.2 被测试的特性(本说明的第2章)

    规定测试项,描述作为本设计测试目标的特性和特性的组合,其它特性可以论及,但不必测试。 

    5.2.3 方法详述(本说明的第3章)

    将测试计划中规定的方法进行细化,包括要用的具体测试技术,规定分析测试结果的方法(如比较程序或人工观察)。 

    规定为选择测试用例提供合理依据的一切分析结果。例如:可以说明容错的条例(如:区别有效输入和无效输入的条件)。 

    归纳所有测试用例的共同属性,可以包括输入约束条件,共享环境的要求,对共享的特殊规程的要求及任何共享的测试用例间的依赖关系。 

    5.2.4 测试例名称(本说明的第4章)

    列出与本设计有关的每一测试用例的名称和简要说明。某个特定的测试用例可能在多个测试设计说明中出现,列出与本测试设计说明有关的规程及其简要说明。 

    5.2.5 特性通过准则(本说明的第5章)

    规定用于判别特性和特性组合是否通过测试的准。

    5.3 测试用例说明

    测试用例说明结构如下图所示。 

    1 测试用例说明名称

    2 测试项

    3 输入说明

    4 输出说明

    5 环境要求

    6 特殊的规程说明

    7 用例间的依赖关系

    由于测试用例可能被由多个小组长期使用的多个测试设计说明引用,所以在测试用例说明中必须包含足够具体的信息以便重复使用。 

    下面给出本说明每一章的详细内容。 

    5.3.1 测试用例说明名称(本说明的第1章)

    给本测试用例说明取一个专用名称 

    5.3.2 测试项(本说明的第2章)

    规定并简要说明本测试用例所要涉及的项和特性、对于每一项、可考虑引用以下文件:需求说明书、设计说明书、用户手册、操作手册。 

    5.3.3 输入说明(本说明的第3章)

    规定执行测试用例所需的各个输入。有些输入可以用值(允许适当的误差)来规定。而另一些输入,如常数表或事务文件可以用名来规定。规定所有合适的数据库、文件、终端信息、内存常驻区域和由操作系统传送的值。规定各输入间所需的所有关系(如时序关系等)。 

    5.3.4 输出说明(本说明的第4章)

    规定测试项的所有输出和特性(如:响应时间)。提供各个输出或特性的正确值(在适当的误差范围内)。 

    5.3.5 环境要求(本说明的第5章)

    5.3.5.1 硬件

    规定执行本测试用例所需的硬件特征和配置(如:80字符×24行的显示终端)。

    5.3.5.2 软件

    规定执行本测试用例所需的系统软件和应用软件。系统软件可以包括操作系统、编译程序、模拟程序和测试工具等。 

    5.3.5.3 其它

    说明所有其它的要求,如特种设施要求或经过专门训练的人员等。 

    5.3.6 特殊的规程要求(本说明的第6章)

    描述对执行本测试用例的测试规程的一切特殊限制。这些限制可以包括特定的准备、操作人员干预、确定特殊的输出和清除过程。 

    5.3.7 用例间的依赖关系(本说明的第7章)

    列出必须在本测试用例之前执行的测试用例名称,归纳依赖性质。 

    5.4 测试规程说明

    测试规程说明结构如下图表示 

    1 测试规程说明名称

    2 目的

    3 特殊要求

    4 规程步骤

    下面给出本说明每一章的详细内容。 

    5.4.1 测试规程说明名称(本说明的第1章)

    给每个测试规程说明取一个专用名称,给出对有关测试设计说明的引用。 

    5.4.2 目的(本说明的第2章)

    描述本规程的目的。如果本规程执行测试用例,则引用各有关的测试用例说明。 

    5.4.3 特殊要求(本说明的第3章)

    指出执行本规程所需的所有特殊要求,包括作为先决条件的规程、专门技能要求和特殊环境要求。 

    5.4.4 规程步骤(本说明的第4章)

    5.4.4.1 日志

    说明用来记录测试的执行结果、观察到的事件和其它与测试有关事件(见5.6条测试日志和5.7条测试事件报告)的所有特殊方法或格式。

    5.4.4.2 准备

    描述新任务执行规程所必需的动作序列。 

    5.4.4.3 启动

    描述开始执行规程所必需的动作。 

    5.4.4.4 处理

    描述在规程执行过程中所必需的动作。 

    5.4.4.5 度量

    描述如何进行测试度量(如描述如何用网络模拟程序来充其量远程终端的响应时间)。 

    5.4.4.6 暂停

    描述因发生意外事件暂停测试所必需的动作。 

    5.4.4.7 再启动

    规定所有再拨动点和在启动点上重新启动规程所必需的动作。 

    5.4.4.8 停止

    描述正常停止执行时所必需的动作。 

    5.4.4.9 清除

    描述恢复环境所必需的动作。 

    5.4.4.10 应急

    描述处理执行过程中可能发生的异常事件所必需的动作。 

    5.5 测试项传递报告

    测试项传递报告结构如下图所示。 

    1 传递报告名称

    2 传递项

    3 位置

    4 状态

    5 批准

    下面给出本报告每一章的详细内容。 

    5.5.1 传递报告名称(本报告的第1章)

    为本测试项传递报告取一个专用名称。 

    5.5.2 传递项(本报告的第2章)

    规定被传递的项及其版本/修订级别。提供与传递项有关的项文件和测试计划的相关信息,指出对该传递项负责的人员。

    5.5.3 位置(本报告的第3章)

    规定传递项的位置及其所在媒体。 

    5.5.4 状态(本报告的第4章)

    描述被传递的测试项的状态,包括其与项文件、这些项的以往传递以及测试计划的差别。列出希望由被传递项解决的事件报告。 

    5.5.5 批准(本报告的第5章)

    规定本传递报告必须由哪些人(姓名和职务)审批,并为签名和日期留出位置。 

    5.6 测试日志

    测试日志结构如下图所示。 

    1 测试日志名称

    2 描述

    3 活动和事件条目

     

     下面给出本报告每一章的详细内容。 

    5.6.1 测试日志名称(本日志的第1章)

    为本测试日志取一专用的名称。 

    5.6.2 描述(本日志的第2章)

    除了在日志条目中特别注明的以外,用于日志中所有条目的信息都包括在本章中。应该考虑有以下信息: 

    1)规定被测试项及其版本/修订级别。如果存在的话,引用各项的传递报告。

    2)规定完成测试的环境属性,包括设备说明、所用的硬件、所用的系统软件及可用存储容量等可用资源。

    5.6.3 活动和事件条目(本日志的第3章)

    对每个事件(包括事件的开始和结束),记录发生的日期和时间,并说明记录者。应考虑以下各项信息。 

    5.6.3.1 执行描述

    记录所执行的测试规程的名称,并引用该测试规程说明。记录执行时在场人员,包括:测试者、操作员和观察员,还要说明每个人的作用。 

    5.6.3.2 测试结果

    对每次执行,记录人工可观察到的结果(如:产生的错误信息、异常中止和对操作员动作的请求等),还要记录所有输出的位置(如磁带号码),记录测试的执行是否成功。 

    5.6.3.3 环境信息

    记录本条目的的一切特殊的环境条件。 

    5.6.3.4 意外事件

    记录意外事件及其发生前后的情况(如请求显示总计,屏幕显示正常,但响应时间似乎异常长,重复执行时响应时间也同样过长)。记录无法开始执行测试或无法结束测试的周围环境(如电源故障或系统软件问题)。 

    5.6.3.5 事件报告名称

    每产生一个测试事件报告时,记录其名称。 

    5.7 测试事件报告

    测试事件报告结构如下图所示。 

    1 测试事件报告名称

    2 摘要

    3 事件描述

    4 影响

     

     下面给出本报告每一章的详细内容。 

    5.7.1 测试事件报告名称(本报告的第1章)

    为本测试事件报告取一个专用名称。 

    5.7.2 摘要(本报告的第2章)

    简述事件,指出有关测试项及其版本/修订级别。引用有关的测试规程说明、测试用例说明及测试日志。

    5.7.3 事件描述(本报告的第3章)

    对事件进行描述。该描述应包括以下各项: 

    输入 

    预期结果 

    实际结果 

    异常现象 

    日期和时间 

    规程步骤 

    环境 

    重复执行的意图 

    测试者 

    观察者 

    该描述应该包括有助于确定事件发生原因及改正其中错误的有关浩劫及观察。例如,描述可能对此事件有影响的所有测试用例执行情况,描述与已公布的测试规程之间的一切差异等。 

    5.7.4 影响(本报告的第4章)

    在所知道的范围内指出本事件对测试计划、测试设计说明、测试规程说明或测试用例说明所产生的影响。 

    5.8 测试总结报告

    规定本报告必须由哪些人(姓名和职务)审批,并为签名和日期留出位置。 

     

     

    单元测试报告

    编者说明:

        单元测试是每一个开发人员都必须去做的事,它将采用白盒方法来进行,为了跟踪单元测试的效果,对开发人员进行督促,对于一些重要的模块进行测试是很必要的。该表格就是用来让开发人员填写单元测试的结果的文档。

    填表日期:                                   编号:

    开发项目名称

     

    开发项目编号

     

    第一责任人

     

    单元名称

     

    责任人

     

    单元所属子系统

     

    开发周期

     

    代码测试检查:

     代码测试内容

    测试人员

                测试结果

         备注

      路径测试

     

     

     

      声明测试

     

     

     

      循环测试

     

     

     

      边界测试

     

     

     

      接口测试

     

     

     

      界面测试

     

     

     

      数据确认测试

     

     

     

      代码走查

     

     

     

    功能测试:

    序号

         功能名称 

        操作方法

      结果

     建议

    测试人员

    备注

     

     

     

     

     

     

     

     测试结论

     

      责任人

     

    项目第一责任人

     

       审核

     

    项目组

     

    测试组

     

    总工办

     

    总工程师

     

     

     

    五、其它类模块开发说明(ISO标准)

    编程说明:

        该文档将与模块开发卷宗结合使用,卷宗是对整个系统进行整理,而模块开发说明则是对具体的模块进行说明,其作用于归档阶段。

    1.标题

    [系统名称和标识符]

    [模块名称和标识符]

    [程序编制员签名]

    [卷宗的修改文本序号]

    [修改完成日期]

    [卷宗序号]

    [编排日期]

    2.模块开发情况表

    3.功能说明

        [扼要说明本模块的功能,主要是输入、要求的处理、输出。可以从系统设计说明书中摘录。同时列出在需求说明书中对这些功能的说明的章、条、款。]

    4.设计说明

        [说明本模块的设计考虑]

    5.硬件部分的设计结果

    1) 经项目组调试通过的硬件成品1件

    2)设计文件:

    《原理图》

    《PCB图》

    《BOM清单》

    《可编程器件及烧录进制文件》

    《必要测试点波形图或硬件指标评细说明》

    《原理详细说明》

    《与系统内其他部分接口软硬件详细说明》

       这些文件可以附件的形式列后。

    6.软件的设计结果

        [要给出所产生的本模块的第一份无语法错的源代码清单以及已通过全部测试的当前有效的源程序代码。]

    7.测试说明

        [说明直接要经过本模块的每一项测试,包括这些测试各自的标识符和编号、进行这些测试的目的、所用的配置和输入、预期的输出及实际的输出。]

    8.复审的结论

        [把实际测试的结果,同需求说明书、系统设计说明书中规定的要求进行比较和给出结论。]

     

    展开全文
  • PMP 质量保证与质量控制的区别

    千次阅读 2020-12-01 15:43:05
    质量保证与质量控制的区别质量保证QA -执行QA常见的工作或活动:质量控制QC-监控QC常见的工作或活动: 质量保证QA -执行 实施质量保证(Quality Assurance),简称QA。QA是审计质量要求和质量控制测量结果,确保...
  • 和朋友谈到软件质量工作时,经常会提及到软件质量控制、质量保证和质量管理。我想对于这三者,很多人也就仅仅是知道而已,多少人认真的思考过这三者的区别? 其实质量控制、质量保证、质量管理代表软件质量工作...
  • 质量保证和质量控制的区别

    千次阅读 2015-04-17 15:01:22
    质量保证和质量控制的区别     在软件项目中,不少技术人员经常混用QA(Quality Assurance 质量保证)和QC(Quality Control 质量控制)这两个术语;甚至一些实施培训的专业公司(Baidu和Oristand)也混淆了这两...
  • 实施质量保证和控制质量的区别

    千次阅读 2015-09-30 09:46:59
    实施质量保证属于执行过程组,而控制质量属于监控过程组。 活动 实施质量保证是审计质量要求和质量控制测量结果;执行项目质量管理计划中所定义的一系列的行动和过程,属于一致性工作的范畴;关注的是与质量活动...
  • 实施质量保证-执行过程组

    千次阅读 2018-12-10 11:52:09
    实施质量保证是审计质量要求和质量控制测量结果,确保采用合理的质量标准和操作性定义的过程。 本过程的主要作用是,促进质量过程改进。 实施质量保证  输出  变更请求  项目管理计划更新  项目文件更新  组织...
  • 软件测试与质量保证习题

    千次阅读 2020-06-20 12:15:02
    软件测试与质量保证习题软件测试与质量保证习题绪论软件测试基础软件测试策略黑盒测试与测试用例设计白盒测试软件测试过程软件质量保证 软件测试与质量保证习题 绪论 为什么学习软件质量保证与测试课程? 软件测试...
  • 软件质量保证管理办法

    千次阅读 2015-02-28 23:21:56
    本文档的目的是为特定产品、项目或合同的质保工作提供指导,帮助项目组其他成员了解质量保证要素,明确质量保证活动,确定质量保证范围。本文档将规定项目质量管理员的职责和权利,资源要求,活动安排,进度,要求...
  • 质量保证属于执行过程组的,关注的是过程,是质量活动相关的政策、制度、流程、规范等。 质量控制是监控过程组的,关注的是产品,是产品的质量问题、质量缺陷,发现并给予消除。 质量管理是关于质量的一切管理活动,...
  • 一文读懂质量保证和质量控制

    千次阅读 2015-08-17 18:29:59
    质量保证和质量控制常常被混淆,尤其是没有经历过严肃项目管理过程洗礼的,经常把QA角色叫成测试的就是把二者混为一谈。以前也听过QA常常不忿产品经理及工程师把他们称为测试工程师,我们是高大上的质量保证好不好,...
  • 计算机软件质量保证计划示例

    千次阅读 2017-07-03 11:02:00
    计划名CADCSC软件质量保证计划  项目名中国控制系统CAD工程化软件系统  项目委托单位  代表签名年月日  项目承办单位  代表签名年月日  1引言  1.1目的  本计划的目的在于对所开发的CADCSC软件规定各种必要...
  • 慕课软件质量保证与测试(习题集)

    万次阅读 多人点赞 2020-05-09 17:08:53
    习题汇总0 总目录1 绪论1.1 软件质量保证与测试的产生与发展1.2 软件缺陷,软件错误,软件故障1.3 软件质量保证与测试的意义,原则和挑战1.4 单元测试1.5 课后作业2 软件测试策略2.1 软件测试的模型,过程和生命周期2.2 ...
  • 考纲 目录:...     软件质量保证与测试技术复习提纲 1.3  1.5   2.1 2.3 2.5 2.6   3.3(3.3.1 扩展) 3.4 3.7.3 FSM 状态图 状态表   5.1 5.7.1 5.7.2   8.1.1 ...
  • 软件测试与质量保证-软件测试部分练习题 1单选(2分) 软件测试用例主要由输入数据和_________两部分组成。 A.预期输出结果2.00/2.00 B.测试计划 C.以往测试记录分析 D.测试规则 2单选(2分) 与设计测试用例无关的...
  • Forward: 软件测试与质量保证

    千次阅读 2014-08-11 00:42:23
    软件测试与质量保证 王韧 (上海交通大学软件学院, 上海201205) 摘要:随着计算机应用越来越广泛与深入,软件也越来越复杂,人们已清楚的认识到软件产品和其它工业产品一样,未经测试、试验是不能作为产品推向市场...
  • 软件测试和质量保证的关系

    万次阅读 2014-07-31 15:16:07
    软件测试在软件生命周期中占据重要的地位,在传统的瀑布模型中,软件测试仅处于编码之后、运行维护阶段之前,是软件产品交付用户使用之前软件质量保证的最后手段。这是一种误导,软件生命周期每一阶段中都应包含测试...
  • 软件测试与质量保证的区别

    千次阅读 2019-11-15 18:02:26
    质量保证:预防缺陷的策略,关注过程的管理和控制; 不用目标: 质量保证 通过监控软件开发过程来保证产品质量; 保证软件和开发过程符合相应标准与规范; 保证软件产品、软件过程中存在的问题得到处理,同时满足...
  • 慕课金陵科技学院.软件质量保证与测试.第十章.软件测试组织和管理.课后作业0 目录10 软件测试组织和管理10.5 课后作业10.5.1 ...软件质量保证与测试人员需要的的基本素质( ) A、计算机专业技能 B、测试专业技能 ...
  • 软件质量保证工具 lint使用简介

    千次阅读 2005-07-17 12:42:00
    软件质量保证工具 lint使用简介 发信人: SLEEPCAT(☆当猪爱上饲养员☆), 信区: Embedded. 本篇人气: 77 标 题: lint使用简介 发信站: 南京大学小百合站 (Thu Nov 6 10:27:08 2003) LINT工具是一种软件质量保证工具,...
  • 软件质量保证与测试.第五章.软件测试过程.课后作业0 目录5 软件测试过程5.7 课后作业5.7.1 课堂重点5.7.2 测试与作业6 下一章 0 目录 5 软件测试过程 5.7 课后作业 5.7.1 课堂重点 5.7.2 测试与作业 习题5 1(1分)...
  • 软件质量保证与测试.第四章.白盒测试.课后作业0 目录4 白盒测试4.10 课后作业4.10.1 课堂重点4.10.2 测试与作业5 下一章 0 目录 4 白盒测试 4.10 课后作业 4.10.1 课堂重点 4.10.2 测试与作业 习题四 1(1分)下列不...
  • CMM中的软件质量保证实施准则

    千次阅读 2006-06-07 12:39:00
    确立工作目标 SQA(Software Quality Assurance,软件质量保证)是CMM的一个关键过程域,CMM的每个关键过程域几乎都涉及软件质量的验证,它在软件开发过程中起着非常重要的作用。在CMM中,软件质量保证的目标是为管理...
  • 让我们区分质量保证与测试

    千次阅读 2013-08-07 12:42:33
    拿测试来说,我们单元测试、集成测试、系统测试、回归测试、冒烟测试,等等。我们缘何塑造如此多的概念来“为难”自己呢?答案可以用我从@李智勇SZ老师那学到的“概念越纯粹表示思辨深度越深”这句话加以解释,而...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 105,746
精华内容 42,298
关键字:

属于质量保证的有