|
|
知识路径： > 软件评测知识 > 软件测试过程模型 > 软件测试过程与管理 >
|
被考次数：2次
被考频率：低频率
总体答错率：31%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：50个
|
|
|
|
|
|
|
|
|
为了满足评价结果的可重复性、可再现性、公正性及客观性，评价者应立足于一个组织。该组织为使其活动达到充分的质量要求提供所有必要保证。为满足这一需求，评价组织可以按照ISO/IEC 17025中规定的要求建立质量管理体系。
|
|
|
|
|
|
|
|
|
|
|
|
③阐述最初的评价需求，并与评价者协商，确定实际的评价需求，这些评价需求宜遵守相关的法规和标准；
|
|
|
|
|
|
|
|
⑥必要时向评价者提供对用于开发和操作使用软件产品的计算机和其他设备；
|
|
|
|
|
|
⑧必要时确保及时提供软件、产品说明书和部件，包括文档及其他资料；
|
|
|
|
|
|
|
|
|
|
①检查请求者对要评价执行的软件产品是否有充分合法的权利；
|
|
|
|
②按规定对请求者提供信息保密承诺，包括评价的软件、评价记录和评价报告；
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
评价需求确立的目的是描述评价目标。这些目标关系到软件产品的预期用途和相关风险。可能要从几种不同软件用户的角度出发，如软件的需方、供方、开发者、操作者或维护者。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
进行评价需求分析时，要考虑供评价的产品的应用领域和用途，还要考虑一些关键问题，如安全、保密安全、经济或环境方面的问题，以及适用的法律和规章制度。
|
|
|
|
在请求者的需求中，请求者应表明评价覆盖范围。同时评价者应保证评价是非常严格的，足以提供软件产品质量方面的真实证据。因此，请求者与评价者应对评价需求达成一致，作为继续评价过程的前提条件。
|
|
|
|
|
|
①评价需求应包含对评价产品应用领域的描述，以及产品用途的描述。
|
|
|
|
②评价需求应由GB/T 16260中定义为“质量特性”的一系列质量需求组成，还可能用到一些子特性。
|
|
|
|
③评价需求中的每项需求，都应提供要评价软件及部件的规格说明信息。
|
|
|
|
|
|
①评价需求应作为请求者与评价者联合评审的结果而予以承认；
|
|
|
|
|
|
|
|
|
|
规定评价规格说明的目的是定义评价范围，定义供评价产品及各种部件执行的测量。评价规格说明应详细到以此能确保评价的可重复性和可再现性。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
①以此定义评价的范围，即标识出哪些作为软件一部分的部件，以及便于了解而接触软件的情况；
|
|
|
|
②将供评价的产品部件的标识交给评价者，以便评价者了解其结构，并弄清提供的信息及如何访问产品部件。
|
|
|
|
产品说明资料应包含为评价而实际提交的产品部件清单、有关产品结构的基本原理和与产品有关的文档清单。对列在清单中的每个部件和与产品有关的文档，应提供下列信息：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
评价者应检查产品描述是否与上述提及的需求一致。评价者还应分析提供的原理及部件的说明，以便标识在评价需求中确定的各部件间的关系。
|
|
|
|
|
|
评价者应把评价需求分配给产品本身和产品描述中标识的各种部件，使评价需求被分解为数个子特性。对供测试的不同部件，分解的结果也是不同的。然后，测试者应规定旨在对产品和所选部件的特性、子特性及属性进行评估的测量。测试规格说明书应明确对下列几项进行说明：
|
|
|
|
①用于度量软件或一组标识的部件的形式化的规格说明，以及评价报告中测量结果的表现形式的说明；
|
|
|
|
②引用的产品部件中规定将要验证的软件需求，以及引用验证这些需求的规程的说明；
|
|
|
|
③在软件需求文档中被遗漏的，或需要更详细解释的软件产品的需求规格说明，以及用来验证这一需求的规程的说明。
|
|
|
|
对上述这些声明，应引用要测量或验证的部件的性质和所用的形式。
|
|
|
|
|
|
|
|
评价者应按照评价需求检查列在产品描述中的部件是否提供了评价执行的所有必要信息。评价者还应验证规定的测量和验证是否充分满足了评价需求所表示的评价目标。
|
|
|
|
|
|
|
|
|
|
②评价执行所需的信息，在产品说明中列出的软件部件及其他相关文档之间的相互引用；
|
|
|
|
③要执行的测量和验证的规格说明，以及对要评价的产品部件的引用；
|
|
|
|
④测量和验证的规格说明与评价需求之间，与引用标准或对所列的每个测量或验证的理由之间的映射。
|
|
|
|
|
|
评价规格说明应作为请求者和测试者之间联合评审的结果予以认可。
|
|
|
|
评价规格说明应包含在评价报告和评价记录中。此外，对评价需求的任何修改均应在评价记录中予以报告。
|
|
|
|
|
|
|
|
评价设计应把评价者使用的测量规程编成文档，以便评价执行规格说明中规定的测量。评价者应制定评价计划来描述执行指定的评价时所需的资源和执行各种动作时对这些资源的分配。
|
|
|
|
评价计划应详细到能确保用一种令人满意的方式执行这些动作。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
把规定的测量或验证与要评价的各种产品部件的形式组合起来，以便把对部件实施的测量或验证的详细方法编成文档。
|
|
|
|
评价者应分析评价规格说明中规定的有关测量或验证的技术约束条件。这些约束条件可能包括：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
对评价规格说明中规定的每种测量或验证，评价者都应把有关的评价方法编成文档。
|
|
|
|
当描述的评价方法是基于使用软件工具的时候，应在评价计划中标识该工具。这种标识应至少包括工具的名称、版本标识和它的来源（如：供方）。
|
|
|
|
对评价的产品执行程序时，也应说明运行环境以及实际工作中可用的条款。
|
|
|
|
|
|
每个基本评价方法都计划应用在供评价的各个软件部件上。也会出现将不同的基本评价方法用于同一个软件部件的情况。
|
|
|
|
应对评价计划草案进行评审，以避免评价者的重复劳动，减少错误风险和降低计划的评价者的工作量。
|
|
|
|
|
|
评价者应安排计划动作的进度，评价者应考虑人员、软件工具、计算机等资源的可用性。
|
|
|
|
评价者应就软件及部件的交付进度与请求者达成一致。应规定软件部件的交付介质、形式以及拷贝数量。
|
|
|
|
应标识评价过程中满足的需求。当请求者不是软件产品的开发者时，应标识评价者和开发者之间的关系。特别是应规定开发者需要的支持。这种支持包括培训、非正式的讨论或办公场所。
|
|
|
|
必要时，对开发和运行场所的访问也应与所需资源一起规定。
|
|
|
|
|
|
评价计划应由两部分组成：评价方法文档和评价者采取评价动作的时间表。
|
|
|
|
评价计划中某些评价方法的文档可能包括对评价者个人材料的引用。在这种情况下，评价者应能判断该方法与相应评价规格说明元素的针对性，以及在应用该方法时，其自身的能力。
|
|
|
|
|
|
评价计划应作为请求者和评价者之间联合评审的结果而予以认可。
|
|
|
|
评价计划应包含在评价记录中。评价方法的文档，对方法的引用，以及对要应用该评价方法的产品部件的标识都应在评价报告中体现。
|
|
|
|
|
|
|
|
评价执行目的是根据评价需求，按照评价规格说明中的规定和评价计划，从对软件产品的测量和验证中获得结果，执行这些动作将完成评价报告和评价记录的草稿。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
此外，评价者还可以管理在评价者的承诺之外执行的评价动作；
|
|
|
|
|
|
|
|
评价请求者应根据评价计划中定义的进度向评价者交付软件部件和与软件相关的文档。
|
|
|
|
评价者应登记全部软件部件和软件的相关文档。在证实了软件的规模和复杂程度之后，应使用正式的配置管理。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
除非请求者有另外的许可，否则，评价者将保守全部产品部件和相关文档的秘密。
|
|
|
|
|
|
评价执行动作通常是测量产品和它的部件，以获得并解释中间数据，以便将产生的结果记入测试报告。中间数据的种类多种多样，例如，为测试产生的数字、图形、图表、部件的摘录或形式化模型。
|
|
|
|
对中间数据的保密应与原来对部件和文档的保密方法一样。此外，评价者应尽力防止这些数据被意外或恶意地修改。特别是当中间数据量非常大并且非常复杂时，应使用正式的配置管理来保持中间评价结果与评价产品之间的一致性。
|
|
|
|
评价者应把所有中间数据记入评价记录，以便依据它们进行解释。如同在评价计划中规定的那样，在解释过程中所作的决定也应被记入评价记录。
|
|
|
|
|
|
评价执行动作需要使用软件工具来收集原始数据，或解释中间数据。
|
|
|
|
当使用工具来评价执行动作时，应在评价报告中记录对工具的引用。该引用应由工具的标识、工具的供方和工具的版本信息组成。
|
|
|
|
对所用工具的更详细的引用信息应记录在评价记录中，包括工具配置的详细信息和为得到相同的中间结果而重复评价动作所需的任何相关信息。
|
|
|
|
评价者应尽最大努力保证工具按照所期望的方式进行工作。评价者应保留在评价过程中承诺合法使用工具的记录。
|
|
|
|
|
|
有时，不能在评价者假定的场所评价执行动作。如，开发者的工作地点或软件产品的运行现场。
|
|
|
|
这时，评价者应控制所有执行的评价动作。特别是，应避免任何使评价结果无效的情况发生。
|
|
|
|
评价者应尽最大努力保证评价结果和中间结果的保密性。
|
|
|
|
|
|
当评价计划要求评价产品的可执行程序时，应精确记录评价的配置和评价的环境。
|
|
|
|
|
|
|
|
在评价执行过程中会产生中间评价结果和最终评价结果。为达到最大的客观性，每个评价动作应由不同的评价执行动作的评价者来检查。
|
|
|
|
应评审全部评价结果，其目的取决于所考虑的评价动作的实质。应至少有一个不直接涉及评价动作的人员参加评审。评审报告应包括在评价记录中。
|
|
|
|
一旦评审通过，应像评价规格说明中规定的那样，把评价结果记入评价报告中。此外，当评价计划也是这样规定时，某些中间结果或解释决定也应记入评价报告。
|
|
|
|
|
|
|
|
评价结论的目的包括评价报告的评审和评价数据的处理。
|
|
|
|
|
|
评价报告的草稿应交付评价的请求者。应组织评价者和请求者之间的联合评审。请求者应有机会对评价报告提出意见。之后，应把该评价报告交给请求者。
|
|
|
|
|
|
将评价报告正式交付给请求者之后，评价者应处理与评价有关的数据。
|
|
|
|
|
|
①供评价的文档应归还给请求者，或者存档一个规定的期限，或者以安全的方式销毁；
|
|
|
|
|
|
③所有其他数据应存档一个规定的期限或以安全的方式销毁。
|
|
|
|
当某些数据的规定存档期限到期时，应将其再次保存一个规定的期限或以安全的方式销毁。
|
|
|
|
只要请求者明确表示同意，评价者就可以使用中间评价结果，以便研究评价技术和软件的度量。
|
|
|
