信息技术信息技术软件包质量要求和测试.docx
《信息技术信息技术软件包质量要求和测试.docx》由会员分享，可在线阅读，更多相关《信息技术信息技术软件包质量要求和测试.docx（26页珍藏版）》请在冰豆网上搜索。
信息技术信息技术软件包质量要求和测试
（信息技术）信息技术软件包质量要求和测试
ISO／IEC前言
IS0（国际标准化组织）和IEC（国际电工委员会）是世界性的标准化专门机构。
国家成员体（它们均是ISO或IEC的成员国）通过国际组织建立的各个技术委员会参和制定计对特定技术范围的国际标准。
ISO和IEC的各技术委员会于共同感兴趣的领域内进行合作。
和ISO和IEC有联系的其他官方和非官方国际组织也可参和国际标准的制定工作。
对于信息技术，ISO和IEC建立了壹个联合技术委员会，即ISO／IECJTC1。
由联合技术委员会提出的国际标准草案需分发给国家成员体进行表决。
发布壹项国际标准，至少需要75％的参和表决的国家成员体投标赞成。
国际标准ISO／IEC12119是由ISO／IECJTC1“信息技术”联合技术委员会制定的。
附录A、附录B和附录C均提供参考信息。
前言
本标准等同采用了国际标准ISO／IEC12119：
1994《信息技术软件包质量要求和测试》。
本标准删去了原国际标准的索引部分，除此之外本标准于技术内容上和国际标准完全壹致。
本标准的附录A、附录B和附录C均是提示的附录。
本标准由中华人民共和国电子工业部提出。
本标准由电子工业部标准化研究所归口。
本标准起草单位：
电子工业部标准化研究所。
本标准主要起草人：
冯惠、王宝艾、黄民德、郑人杰。
中华人民共和国国家标准
GB/T17544－1998
IdtISO/IEC12119:
1994
信息技术软件包质量要求和测试
Informationtechnology--SoftwarepackagesQualityrequirementstesting
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／T5271.14（失效、故障、维护和可靠性的描述中）使用的功能概念要窄，但比GB／T5271.2（算术和逻辑运算）和GB／T5272.15（程序设计语言）中定义的要宽。
2．2需求文档requirementsdocument
包含由软件包满足的建议、要求或规则的任何组合的文档。
注：
例子有技术或人类工效标准，来自某壹组织（如市场部、技术或用户协会）的需求列表（或模型的需求规格说明），法律或法令。
2．3产品描述productdescription
陈述软件包性质的文档，其主要目的是帮助潜于的购买者于购买前对产品进行适用性评价。
注：
该术语比GB／T5271.2O中的术语“系统描述”更具体。
产品描述的目的包括ISO9127中“覆盖信息”的目的。
产品描述不是规格说明，但它可用于不同的用途。
2．4用户文档userdocumentation
以打印的或非打印形式得到的文档的完整集合，用户文档的提供有利于产品的应用且且是产品的必备部分。
2．5包文档packagedocumentation
产品描述和用户文档。
2．6测试用例testcase
测试者使用的文档化的细则，其规定如何对某项功能或功能组合进行测试。
测试用例包括下列内容的详细信息：
——测试日标：
——要测试的功能；
——测试环境和其他条件（配置细节和准备工作）；
——测试数据；
——过程；
——系统的预期行为。
2．7维护maintenance
是系统维护的壹部分（见A5.2），其涉及软件包的修改。
3质量要求
3．1到3．3包含
——每个软件包要有产品描述和用户文档的要求；
——产品描述的要求，尤其应包含规定信息，且且其所有要求的内容是可测试的、正确的；
——用户文档的要求；
——包含于软件包中的程序要求和数据要求。
注
1关于用户文档、程序和数据的要求包含许多壹般要求（独立于产品描述中的约定），但不包括用户希望的所有性质。
2某些性质，例如，用户文档和程序消息的“时期解件”和“易于浏览”，按用户的观点这些性质是被公认的。
然而；由于这些性质难于清晰地测试且结果难于再现，使得这些性质目前仅作为建议来规定。
33.1到3.3中的要求按GB/T16260中出现的特性次序来安排。
如果壹个软件包遵循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）要求的知识
应规定应用该产品所要求的专门知识。
例如：
——技术领域的知识：
——操作系统的知识；
——经过专门培训可获得的知识；
——除了已写入产品描述中以外的其他语言知识。
应说明用户文裆和用户界面（括出错信息和可视数据）所使用的所有自然语言，软件包本身和该产品描述中所涉及的所有其他产品的有关内容均应加以说明。
注：
这种要求超出了ISO9127：
1988的6.1.7的规定，于那里，关于所用的语言规定是可选的。
C）适应用户的需要
如果产品能被用户作适应性修改，则应标识这种修改的工具和修改工具的使用的条件。
例如：
——参数的改变；
——计算的算法改变；
——功能键的分配。
d）防止侵权行为
如果防止侵权的技术保护可能有碍于软件的使用，则应说明这种保护，例如：
——防止拷贝的技术保护；
——程序设置的使用截止日期；
——相互约定的付费拷贝。
e）使用效率和用户满意度。
产品描述能够包括关于使用效率和用户满意度的数据。
注：
这样的数据时遵循ISO9241－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.1d）中论及。
3.2.4易理解性
用户文档对于正常执行其工作任务的壹般用户宜是易理解的，例如，通过使用适当的术语、图形表示，详细的解释以及引出有用的信息源来表现。
3.2.5易浏览性
用户文档宜易于浏览，以使相互关系明确。
每个文档应有目录表和索引表。
如果文档未提供印刷本，则应指明打印过程。
3.3程序和数据
3.3.1功能性
a）安装
如用安装能由用户来完成，则按照安装手册中的信息应能成功安装。
产品描述中指出的每种所要求的系统对于程序的安装应是充分的。
安装之后，程序能否运行应是可鉴别的。
例如，使用提供的测试用例或通过相应信息的自检。
b）功能表现
用户文档中提到的所有功能应是可执行的。
程序应按照用户文档中的给定形式，于规定的边界值范围内使用相应的设施、性质和数据执行其功能。
注：
由于于产品描述中涉及的所有功能也应出当下用户文档中，这些功能更应是可执行的。
C）正确性
程序和数据应和产品描述及用户文档中的全部说明相对应。
为完成工作任务，程序功能应以正确的方式执行。
特别是，程序和数据应符合产品描述所引用的任壹需求文档中的全部需求。
d）壹致性
程序和数据其本身不能自相矛盾，且且同产品描述和用户文档不能相互矛盾。
每个术语应处处具有相同的含义。
由用户先例的程序操作控制和程序行为（例如，消息，屏幕输入格式和打印报表）宜有壹致的结构。
3.3.2可靠性
系统（包括硬件、要求的软件及属于该产品的程序）不应陷入用户无法控制的状态，既不应崩溃也不应丢失数据。
即使于下列情况下也应满足上述要求：
——使用的容量到达规定的极限；
——企图使用的容量超出规定的极限；
——由产品描述中列出的其他程序或用户造成的错误输入；
——用户文档中明确规定的非法指令。
只是那些不能用任何程序捕获的硬中断和操作系统中断（例如，系统操作复位用的键或组合键）不于此范围之内。
当程序认为输入错误或输入未经定义时，应视为不允许的输入，不加处理。
3.3.3易用性
关于易用性，根据本标准的规定，鼓励研究ISO9241系列标准最新版本应用的可能性。
注：
特别是宜考虑ISO9241系列的第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关于人类工效评价的指南包含于ISO9241－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／IEC25号导则］。
测试记录应包括：
——测试计划或包含测试用例（每个测试用例说明它的目标，见2．6）的测试规格说明；
——和测试用例关联的所有结果，包括于测试期间出现的所有失败；
——测试中涉及的人员身份。
4.4测试方案
测试的对象和结果（如测试记录中记录的）应于测试方案中汇总。
测试方案应具有如下结构：
l产品标识；
2用于测试的计算机系统（硬件、软件以及它们的配置）：
3使用的文档（及其标识）：
4产品描述、用户文档、程序和数据的测试结果；
5和要求不符的清单；
6针对建议的要求不符的清单，或者是不循建议要求的清单，或者针对建议要求产品未作符合性测试的说明；
7测试结束日期。
测试方案的第4章（测试结果）应包括相应于3.1到4.2每个标题的说明。
另外，针对建议要求的符合性产品未作测试的说明，测试方案的第6章可提供观察到的不符合建议要求的清单。
测试方案的标识（测试实验室、产品标识、测试方案的日期）和面页总数应出当下测试方案的每页上。
测试方案应包括：
——仅和测试项关联的测试结果有效性的说明；
——未经测试实验室书面批准，不得复制方案（完整复制除外）的说明［ISO／IEC25号导则］。
测试方案宜遵循ISO／IEC25号导则有关测试方案的规定。
4.5跟踪测试
当某壹产品已经测试过，再测试时（注意考虑先前的测试）
——文档功能和数据中所有的改变部分均应测试，就像该产品是壹新产品壹样；
——受改变部分影响的或受要求的系统中的改变影响（根据测试者的专门知识）的所有来改变部分均应测试，就像该产品是壹新产品壹样；
——所有的其他部分应至少按样本进行测试。
附录A
（提示的附录）
源自其他标准的定义
为了便于引用，本标准中使用的而于其他标准中定义的壹些术语定义列出如下。
这些标准出版时，所示的版本是有效的，宜用或考虑源自它们的定义。
A1壹般术语
A1.1软件software
信息处理系统的所有或部分程序、规程、规则和任何关联的文档的集合。
［GB／T5271．l，不包括注］
A1.2软件包softwarepackage
提供给若干用户的完整的且文件化的程序集合以用于类属应用或功能。
［GB／T5271．2O，不包括注］
A1.3系统软件systemsoftware
独立于应用的且支持应用软件运行的软件。
［GB/T5271.1］
A1.4实用例行程序utilityroutine：
实用程序utilityprogram
对计算机用户和服务人员提供壹股的经常需要的服务的例行程序［计算机程序］。
［GB／T5271．7，不包括例子]。
A1.5功能单元functionalunit
具有完成规定目标能力的硬件实体、软件实体或二者结合的实体。
[GB/5271．1]
A1.6（计算机）程序（computer）program
符合特定程序设计语言规则的，且且由声明和语句或指令组成的以解决确定功能、任务或问题所需的语法单元。
［GB／T
升级会员 