ISO/IEC前言

  IS0(国际标准化组织)和IEC(国际电工委员会)是世界性的标准化专门机构。国家成员体(它们都是ISO或IEC的成员国)通过国际组织建立的各个技术委员会参与制定计对特定技术范围的国际标准。ISO和IEC的各技术委员会在共同感兴趣的领域内进行合作。与ISO和IEC有联系的其他官方和非官方国际组织也可参与国际标准的制定工作。 对于信息技术,ISO和IEC建立了一个联合技术委员会,即ISO/IEC JTC1。由联合技术委员会提出的国际标准草案需分发给国家成员体进行表决。发布一项国际标准,至少需要75%的参与表决的国家成员体投标赞成。
  国际标准 ISO/IEC 12119 是由 ISO/IEC JTC1“信息技术”联合技术委员会制定的。
  附录A附录B附录C均提供参考信息。                          

  前言

  本标准等同采用了国际标准ISO/IEC 12119:1994 《信息技术 软件包 质量要求和测试》。
  本标准删去了原国际标准的索引部分,除此之外本标准在技术内容上与国际标准完全一致。
  本标准的附录A、附录B和附录C都是提示的附录。
  本标准由中华人民共和国电子工业部提出。
  本标准由电子工业部标准化研究所归口。
  本标准起草单位:电子工业部标准化研究所。
  本标准主要起草人:冯惠、王宝艾、黄民德、郑人杰。

 

 

中华人民共和国国家标准

GB/T 17544-1998
Idt ISO/IEC 12119:1994

信息技术 软件包 质量要求和测试
Information technology--Software packages Quality requirements testing


1 范围
  
本标准适用于软件包。例如文本处理材序、电子表格、数据库程序、图形软件包、技术或科学函数计算程序以及实用程序。
  它规定了:
  ——软件包要求(质量要求);
  ——针对这些要求,如何对软件包进行测试的细则(测试细则,特别是第三方测试)。
  它只涉及要提供的或安交付的软件包,不涉及它们的产生过程(包括活动和中间产品,如规格说明)。供方的质量体系超出了本标准的范围。
  注:某让匕软件需要附加的要求,如安全要求高的软件。
  本标准期望的用户如下:
  a) 在下述情况下使用本标准的供方:
    1)规定软件包的要求时;
    2)设计描述产品的格式时;
    3)评价他们自己的产品时;
    4)发布符合[ISO/IEC第22号导则]的声明时:
    5)申请合格[ISO/IEC第23号导则]证书或标志时:
  b)希望建立第三方认证模式(国际的、地区的及国家的) [ISO/IEC第16、28和44号导则]的认证机构;
  c)为合格证书或标志而进进测试的测试实验室,测试实验室必须遵循测试指令[ISO/IEC第25号导则];
  d)认可认证机构和测试实验室的认可机构[ISO/IEC第4O和58号导则];
  e)评价测试实验室能力的实验室审核员[ISO/IEC第58号导则];
  f)购买者:
    1)用本标准规定的内容来比较他们的要求;
    2)用现有产品的产品描述中的信息来比较期望的工作任务的要求;
    3)寻求已认证的产品;
    4)此外,检验要求是否被满足。
  g)用户:可以从更好的产品获益。


2 定义


  本标准采用下列定义。源自其他标准的定义列于附录A以便于引用。
2.l 功能 function
  程序中的一个算法的实现,利用该实现,用户或程序可以执行某一工作任务的全部或部分内容。
  注
  1 对于用户人说,功能不一定是能访问的(如数据的自动备份或存储)。
  2 这里功能的概念比GB/T 5271.14(失效、故障、维护和可靠性的描述中)使用的功能概念要窄,但比 GB/T 5271.2(算术和逻辑运算)和 GB/T 5272.15(程序设计语言)中定义的要宽。
2.2需求文档 requirements document
  包含由软件包满足的建议、要求或规则的任何组合的文档。
  注:例子有技术或人类工效标准,来自某一组织(如市场部、技术或用户协会)的需求列表(或模型的需求规格说明),法律或法令。
2.3 产品描述 product description
  陈述软件包性质的文档,其主要目的是帮助潜在的购买者在购买前对产品进行适用性评价。
  注:该术语比 GB/T 5271.2O中的术语“系统描述”更具体。产品描述的目的包括ISO 9127中“覆盖信息”的目的。
  产品描述不是规格说明,但它可用于不同的用途。
2.4 用户文档 user documentation
  以打印的或非打印形式得到的文档的完整集合,用户文档的提供有利于产品的应用并且是产品的必备部分。
2.5 包文档 package documentation
  产品描述和用户文档。
2.6 测试用例 test case
  测试者使用的文档化的细则,其规定如何对某项功能或功能组合进行测试。测试用例包括下列内容的详细信息:
  ——测试日标:
  ——要测试的功能;
  ——测试环境和其他条件(配置细节和准备工作);
  ——测试数据;
  ——过程;
  ——系统的预期行为。
2.7 维护 maintenance
  是系统维护的一部分(见A5.2),其涉及软件包的修改。

3 质量要求

  3.1 到3.3包含
  ——每个软件包要有产品描述和用户文档的要求;
  ——产品描述的要求,尤其应包含规定信息,并且其所有要求的内容是可测试的、正确的;
  ——用户文档的要求;
  ——包含在软件包中的程序要求和数据要求。
  注
  1 关于用户文档、程序和数据的要求包含许多一般要求(独立于产品描述中的约定),但不包括用户希望的所有性质。
  2 某些性质,例如,用户文档和程序消息的“时期解件”和“易于浏览”,按用户的观点这些性质是被公认的。然而;由于这些性质难于清晰地测试且结果难于再现,使得这些性质目前仅作为建议来规定。
  3 3.1 到3.3中的要求按GB/T 16260中出现的特性次序来安排。
  如果一个软件包遵循3.1到3.3中所有的要求,则该软件包符合本标准。建议是可选的(通过使用“宜”这个词来表示)。
  注4:要证明一个产品对3.1到3.3中的要求的符合性可能是困难的或不可能的。但是,根据ISO/IEC第2号导则,为得合格证书,按照第4章来测试(包括文档的评审)被认为是足够了,并且不需要形式证明。
3.1 产品描述
  每个软件包应有一个产品描述。
  产品描述定义产品。产品描述是产品软件包文档的一部分,它提供关于用户文档、程序以及数据(如果有的话)的信息。
  产品描述的主要目的是:
  ——帮助用户或潜在的购买者作出产品是否适用于他们的评价。从这一意义说,产品描述也是销售信息;
  ——作为测试的基础(见第4章)。
  对产品感兴趣人们可获得产品描述。
3.1.1 内容的一般要求
  产品描述宜是充分可理解的、完整的并且易于浏览,以帮助潜在的购买者在购买该产品前评价产品对他们自己的适用性。
  产品描述应避免不一致,每个术语在任何地方都应有相同的意义。
  产品描述的说明应是可测试的并且是正确的。
  注:如果有外部需求文档(见 3.1.2e),本条要求引用外部需求文档中的说明。
  下列3.l.2到3.1.8规定产品描述应包合或它包含的内容,它也可包含产品的附加说明。
3.1.2 标识和批示
  a)产品描述的标识
  产品描述应且有唯一的文档标识。它可以有不同于产品描述的命名,例如,“功能描述”、“产品信息”“产品清单”
  b) 产品的标识
  产品描述应标识产品。产品标识应至少有产品名字和版本号或日期。如果在产品描述中提及两个或多个派生版本,则每个版本应至少有产品名、派生版本名和版本号或日期。
  c)供方
  产品描述应至少包含一个供方的名字和地址。
  注:名字和地址不必打印;有供方的公章即可。
  d)工作任务
  产品描述应标识期望的产品能完成工作任务。
  e)符合需求文档
  产品描述可以引用产品应符合的需求文档的内容。在这种情况下应标识相关的编辑版本。
  f)要求的系统
  应标识将产品投入使用所要求的系统(硬件、软件及其配置)包括制造厂商名和所有部件的类型标识符,例如;
  ——包括协处理器的处理单元;
  ——主存规格;
  ——外存的类型和规格;
  ——扩展卡;
  ——输入和输出设备;
  ——网络环境;
  ——系统软件和其他软件。
  对于不同的工作任务、不同的边界值或不同的效率要求,可以规定不同的要求系统。
  如果先前特定的硬件或软件产品已经标识,则语句“(如果兼容,或任何其他……)”可以出现在产品描述中。如果产品的先前版本已经标识,则语句“如果兼容,或升级的版本”可以出现在产品描述中。语句“自版本X至少到版本Y”可以出现在产品描述中,而“自版本X”不能出现在产品描中。
  注:由于版本X+3的出现,语句“自版本X”将变得不正确,因为对于版本X+3,软件包操作将会失败。
  g)与其他产品的接口
  如果产品描述引用了其他产品接口,则应对所引用的接口或产品进行标识。
  h)要交付项
  应对要提供的产品的每个物理部件进行标识,特别是所有打印的文档和所有的数据媒体。
  应说明提供的程序形式如源程序、目标模块,或加载模块。
  注:媒体格式(如磁盘格式)个必指明,因为可能的格式集合是由要求的系统决定的(见 3.1.2f))。
  i)安装
  应说明产品安装是否能由用户来完成。
  j)支持
  应说明是否提供对产品操作的支持。
  k)维护
  应说明是否提供维护。如果提供维护,应说明具体包括什么。
3.1.3 功能说明
  a)功能概述
  产品描述应概述产品的用户可调用功能、需要的数据、所提供的设施。
  对每个所论及的功能(尤其是选项和变量)是否是下列内容的一部分应清晰地说明:
  ——产品功能的;
  ——在产品描述中完整描述的产品扩展功能的;
  ——在产品描述中所引用的产品扩展功能的;
  ——无保证的补充功能的。
  注:个必论及每个用户可调用功能,不必给出功能如何调用的每个细节。
  b)边界值
  如果由于产品特定的边界值致使产品的使用受限,则应提供这些边界值。例如:
  ——最小或最大值;
  ——键的长度;
  ——文卷中的记录的最大数日;
  ——检索准则的最大数目;
  ——最小样本大小。
  当不可能提供固定的边界值时(例如,边界值取决于应用问题的类型或输入数据时),则应说明这些限制,可以提供允许的值组合,更具体的信息写入用户文档。
  C)安全
  如果提供的话,产品描述中应包含有关防止对程序或数据非授权的无意访问或蓄意访问的手段。
3.1.4 可靠性说明
  产品描述应包含数据存储规程的信息。
  注:例如,只要说明使用操作系统进行备份就可以了。
  应描述保证产品的功能能力的附加性质。例如:
  ——检验输入的合理性;
  ——防止由于用户的错误而产生的严重后果;
  ——出错恢复
3.1.5 易用性说明
  a)用户界面
  应命名用户界面的类型,例如:命令行、菜单、窗口、功能键及帮助功能。
  b)要求的知识
  应规定应用该产品所要求的专门知识。例如:
  ——技术领域的知识:
  ——操作系统的知识;
  ——经过专门培训可获得的知识;
  ——除了已写入产品描述中以外的其他语言知识。
  应说明用户文裆和用户界面(括出错信息和可视数据)所使用的所有自然语言,软件包本身和该产品描述中所涉及的所有其他产品的有关内容都应加以说明。
  注:这种要求超出了ISO 9127:1988的6.1.7的规定,在那里,关于所用的语言规定是可选的。
  C)适应用户的需要
  如果产品能被用户作适应性修改,则应标识这种修改的工具和修改工具的使用的条件。例如:
  ——参数的改变;
  ——计算的算法改变;
  ——功能键的分配。
  d)防止侵权行为
  如果防止侵权的技术保护可能有碍于软件的使用,则应说明这种保护,例如:
  ——防止拷贝的技术保护;
  ——程序设置的使用截止日期;
  ——相互约定的付费拷贝。
  e)使用效率和用户满意度。
  产品描述可以包括关于使用效率和用户满意度的数据。
  注:这样的数据时遵循ISO 9241-11的指南。
3.1.6 效率说明
  产品描述可以包含产品的时间行为的数据,诸如在指定条件下(例如系统配置和负载分布)关于给定功能的响应时间和吞吐率。
3.1.7 可维护性说明
  产品描述可包含可维护性说明。
3.1.8 可移植性说明
  产品描述可包含可移植性说明。

3.2 用户文档
3.2.l 完整性
  用户文档应包含产品使用所需信息。在产品描述中说明的所有功能以及在程序中用户可调用的所有功能,都应在用户文档中加以完整地描述。
  用户文档中应再次说明产品描述中给出的所有边界值。
  如果安装能由用户来完成,则用户文档应包括安装手册,该手册应包含所有必要的信息(见3.3.la))。安装手册宜说明一次安装的最小文卷和最大文卷。
  如果维护能由用户来完成,则用户文档应包括程序维护手册,该手册应包含各种有关该软件维护所需要的信息。
3.2.2 正确性
  用户文档中所有信息应是正确的,不能有歧义和错误的表达。
3.2.3 一致性
  则户文档自身内容或相互之间以及与产品描述之间都不应相互矛盾。每个术语的含义宜处处保持一致。
  注:程序和数据的一致性在3.3.1 d)中论及。
3.2.4 易理解性
  用户文档对于正常执行其工作任务的一般用户宜是易理解的,例如,通过使用适当的术语、图形表示,详细的解释以及引出有用的信息源来表现。
3.2.5 易浏览性
  用户文档宜易于浏览,以使相互关系明确。
  每个文档应有目录表和索引表。
  如果文档未提供印刷本,则应指明打印过程。
3.3 程序和数据
3.3.1功能性
  a)安装
  如用安装能由用户来完成,则按照安装手册中的信息应能成功安装。产品描述中指出的每种所要求的系统对于程序的安装应是充分的。
  安装之后,程序能否运行应是可鉴别的。例如,使用提供的测试用例或通过相应信息的自检。
  b)功能表现
  用户文档中提到的所有功能应是可执行的。程序应按照用户文档中的给定形式,在规定的边界值范围内使用相应的设施、性质和数据执行其功能。
  注:由于在产品描述中涉及的所有功能也应出现在用户文档中,这些功能更应是可执行的。
  C)正确性
  程序和数据应与产品描述及用户文档中的全部说明相对应。为完成工作任务,程序功能应以正确的方式执行。特别是,程序和数据应符合产品描述所引用的任一需求文档中的全部需求。
  d)一致性
  程序和数据其本身不能自相矛盾,并且同产品描述和用户文档不能相互矛盾。每个术语应处处具有相同的含义。
  由用户先例的程序操作控制和程序行为(例如,消息,屏幕输入格式和打印报表)宜有一致的结构。
3.3.2 可靠性
  系统(包括硬件、要求的软件及属于该产品的程序)不应陷入用户无法控制的状态,既不应崩溃也不应丢失数据。
  即使在下列情况下也应满足上述要求:
  ——使用的容量到达规定的极限;
  ——企图使用的容量超出规定的极限;
  ——由产品描述中列出的其他程序或用户造成的错误输入;
  ——用户文档中明确规定的非法指令。
  只是那些不能用任何程序捕获的硬中断和操作系统中断(例如,系统操作复位用的键或组合键)不在此范围之内。
  当程序认为输入错误或输入未经定义时,应视为不允许的输入,不加处理。
3.3.3 易用性
  关于易用性,根据本标准的规定,鼓励研究 ISO 9241系列标准最新版本应用的可能性。
  注:特别是宜考虑ISO 9241系列的第10部分和第13部分。
  a)易理解性
  程序的问题、消息和结果应是易理解的,例如:
  ——通过选择适当的术语:
  ——通过图形表示;
  ——通过提供背景信息:
  ——通过帮助功能的解释。
  出错消息应提供解释相应差错产生原因和纠正的详细信息(例如通过引用用户文档的条文)。
  b)易浏览性
  如果有多种媒体,则每种数据媒体应具有产品标识、可辨别编号或文本。
  对于使用程序进行工作的用户,总能找到哪个功能正在被执行是可能的。
  程序宜以易观察易读的形式向用户提供信息。通过对信息的适当编码和分组对用户提供指导,必要时,程序可向用户发出警报。
  源程序的消息应如此设计,即用户通过类型容易区分它们。例如:
  ——确认;
  ——程序询问;
  ——警告:
  ——出错消息。
  屏幕输入格式,报表和其他输入、输出宜设计清晰和易于浏览。一般包括:
  ——字母数字字段左对齐:
  ——数字字段右对齐;
  ——在表中,小数点或逗号要排在同一垂直线上;
  ——字段界限是可识别的;
  ——哪些字段的使用是受限的,哪些字段是可识别的:
  ——标识输入失败后要立即在屏幕输入格式中加亮;
  ——通过一个可视或可听的信号来引起用户注意屏幕内容的改变。
  c) 可操作性
  具有严惩后果的功能执行应是可逆的,或者程序应给出该后果的明显警告并且在执行该命令前要求确认。特别是数据的删除和重写,以及中断一个过长的处理操作,这种动作往往有严重后果。
  如果文档文本编制是以对话形式提供。用户应直接访问该文本的子条文,例如通过目录表显示的选择和按关键字检索功能来实现。
3.3.4 效率
  应遵循产品描述中的效率说明。
3.3.5 可维护性
  应遵循产品描述中的可维护性说明。
3.3.6 可移植性
  应进循产品描述中的可移植性说明。
4 测试细则

  4.1到4.5的细则规定如何按照质量要求来测试产品。包括根据所有符合性产品要求的性质测试和按照产品描述约定的性质测试。包括通过文档的检查测试和程序及数据的黑盒测试。
  这些细则描述了功能测试(黑盒测试),不包括结构测试,因为结构测试需要得到源代码。
  产品仅在它要求的系统中被测试。对于计算机工作时的人类工效评价,本标准不作考虑。
  注
  1 这些细则上要是根据某些认证模式,针对第三方测试(见第1章C)项)。在生产过程中,这种测试比使用结构测试可能经济且更有效。
  2 第4章不包含关于软件包的要求(所有这些要求包含在第3章中)。一个软件包不按第4章进行测试可能是符合的,但是这样的测试无法发现个符合性的存在。
  3 当产品描述确定了要求的系统时,基于该要求的系统上的产品的任何不符合性被作为该产品的个符合性处理。
  4 认证模式可对照建议选项来进行测试。
  5 关于人类工效评价的指南包含在 ISO 9241-11中。
4.1 测试预要求
4.1.1 产品项的现场要求
  对于要测试的软件包所有要交付的项(见3.1.2h)以及产品描述(见 3.1.2e)中已标识的需求文档都应提供到测试现场。
4.1.2 对系统组成部分的现场要求
  对于软件包的测试,在产品描述中已指明要求的所有计算机系统的组成部分应提供到测试现场。
4.l.3 培训
  如果在产品描述中提到培训,则测试者应有机会使用培训材料和培训大纲。
4.2 测试活动
  产品描述、用户文档、程序和任何要交付的数据都作为软件包的组成部分,并且
  ——应按第3章中的要求进行符合性测试,且
  ——它按第3章中的建议进行符合性测试。
  测试对象应源于并包括第3章中所有要求(完整性、一致性等)。
  如果在产品描述中涉及到其他产品,只需针对该产品的产品描述中提出的要求对这些产品进行测试。
  如果测试者作出下述判断时,则对产品描述中的细节,用户文档中的细节,功能中的细节和产品的数据中的细节不需要测试:
  ——这些细节对已指明的工作任务的影响可忽略;
  这些不作测试的细节应在测试记录和测试报告中说明。对它们不作测试的理由应在测试记录中作录。
4.2.1 产品描述
  第3章中的要求的实现应被测试,并且第3章中的建议的实现宜被测试。
4.2.2 用户文档
  第3章中的要求的实现应被测试,并且第3章中的建议的实现宜被测试。
4.2.3 程序和数据
  第3章中的要求的实现应被测试,并且第3章中建议的实现宜被测试。
  程序应在产品描述中提及的所有的计算机系统中进行测试。
  如果存在若干不同的程序变量,每个都应测试。函数亦是如此,按照产品描述和用户文档进行测试,一组变量标识的函数按每个变量进行测试。应使用以产品描述和用户文档为基础构造的测试用例来测试提供的程序和数据。进一步的材料(例如源程序)不必考虑,除非在产品描述或用户文档中作了说明,才需要测试它们。
  测试用例应有规则地系统地来构造。
  注:依确定的方法进行随机测试是许可的。
  如果例子是在用户文档中给出的,则它们应作为测试用例,但测试不应局限于这些例子。可以使出软件包供应方提供的测试用例,但测试不应局限于这些测试用例。
  a)安装
  如果按照产品描述,用户能完成安装,则应测试这种安装,即程序是否像安装手册中描述的那样能成功地安装和测试。
  否则应保证被安装程序的硬、软件环境符合于产品描述中说明的计算机系统。

    b)程序执行
  测试用例应覆盖软件描述和用户文档中描述的所有功能,并且考虑有代表性的工作任务的功能组合。应针对所有的边界值(按照产品描述和用户文档)来测试程序,而这些边界值在要求的系统中提供。
  在用户文档中明显地不赞成或声明禁用的输入或命令序列应属于测试范围。
4.3 测试记录
  每个测试记录应包含足够的信息以方便重复测试[ISO/IEC 25号导则]。测试记录应包括:
  ——测试计划或包含测试用例(每个测试用例说明它的目标,见2.6)的测试规格说明;
  ——与测试用例相关的所有结果,包括在测试期间出现的所有失败;
  ——测试中涉及的人员身份。
4.4 测试报告
  测试的对象和结果(如测试记录中记录的)应在测试报告中汇总。测试报告应具有如下结构:
  l 产品标识;
  2 用于测试的计算机系统(硬件、软件以及它们的配置):
  3 使用的文档(及其标识):
  4 产品描述、用户文档、程序和数据的测试结果;
  5 与要求不符的清单;
  6 针对建议的要求不符的清单,或者是不循建议要求的清单,或者针对建议要求产品未作符合性测试的说明;
  7 测试结束日期。
  测试报告的第4章(测试结果)应包括相应于3.1到4.2每个标题的说明。
  另外,针对建议要求的符合性产品未作测试的说明,测试报告的第6章可提供观察到的不符合建议要求的清单。
  测试报告的标识(测试实验室、产品标识、测试报告的日期)和面页总数应出现在测试报告的每页上。
  测试报告应包括:
  ——仅与测试项相关的测试结果有效性的说明;
  ——未经测试实验室书面批准,不得复制报告(完整复制除外)的说明[ISO/IEC 25号导则]。
  测试报告宜遵循 ISO/IEC 25号导则有关测试报告的规定。
4.5 跟踪测试
  当某一产品已经测试过,再测试时(注意考虑先前的测试)
  ——文档功能和数据中所有的改变部分都应测试,就像该产品是一新产品一样;

——受改变部分影响的或受要求的系统中的改变影响(根据测试者的专门知识)的所有来改变部分都应测试,就像该产品是一新产品一样;
  ——所有的其他部分应至少按样本进行测试。

 

 

版权所有!  赛宝软件评测中心