目录
质量测试框架的概述：
质量测试框架是一个为测试人员提供指导、工具和技术的系统，用于确保软件满足预定的质量标准和用户需求。它涵盖了测试计划、测试用例设计、测试执行、结果分析和测试报告等多个方面。
质量测试框架相关术语：
外部性质的质量测度 quality measure on external property
外部性质的 QM QM on external property
在特定条件下使用时,系统或软件产品使其行为能满足系统(包括软件)的明确和隐含需要程度的测度。
注:在测试和运行期间,通过执行系统或软件产品来测量、验证和/或确认行为的属性。
示例:在测试期间发现的失效数是一种与存在于计算机系统中的故障数有关的软件质量外部测度。这两种测度不一定是相同的,因为测试不能发现所有的故障;并且在不同的情况下,某一故障会导致明显不同的失效。
内部性质的质量测度 quality measure on internal property
内部性质的 QM QM on internal property
在指定条件下使用时,软件产品的静态属性满足明确和隐含需要程度的测度。
注1:静态属性包括那些与软件架构、结构及其组件,数据结构及其格式、屏幕上图形显示的结构和外观以及用户或服务接收者的菜单有关的属性。
注2:静态属性可通过评审、审查、模拟和/或自动化工具来验证。
注3:内部性质的质量测度通常与可在需求中规定或从需求中派生的静态性质和属性的质量需求相关。
示例:在走查中发现的复杂度和故障的数量、严重程度以及失效频率,是从软件产品自身取得的软件内部质量测度。
系统与软件产品质量 system and software produet quality
系统和/或软件在规定条件下使用时满足明确和隐含需要的能力。
注:产品质量模型是指GB/T25000.10中定义的系统与软件产品质量模型。
质量测试框架的构成及特性：
质量测试参考模型：
质量测量参考模型描述了质量模型和由QME构建QM 之间的关系,见下图。该关系构成了系统与软件产品质量、使用质量和数据质量测量的参考模型。
系统、软件产品或数据的质量是满足各利益相关方明确和隐含需要的程度并提供量值。用户对质量的需要包括在特定使用周境中的系统质量需求。本标准通过质量模型表示这些明确和隐含的需要，质量模型将质量分为一组特性,特性在某种情况下被进一步分解为子特性。质量性质通过应用测量方法进行测量。测量方法是一种逻辑操作序列,用于量化规定标度的属性。一个应用测量方法的结果被称作一个 QME。
QM 是通过将测量函数应用于一组 QME 构建的。测量函数是用于组合 QME 的算法。一个应用测量函数的结果被称作一个 QM。因此,QM 可量化质量特性和子特性。一个质量特性和子特性可用多个 QM 进行测量。
质量的生存周期的QM：
下图描述质量生存周期为一组协同关系的QM,可用于在整个生存周期详细规定质量需求,并通过测量验证和确认所需质量的实现程度来评价质量。整个生存周期包含系统与软件产品以及数据的开发、运行和维护。从用户和/或利益相关方的角度出发,质量生存周期由三层组成:使用层,运行层和实现层。质量需求和目标实体在不同的层中相互确认和/或验证。用户和/或利益相关方对于包括系统、软件产品和数据在内的任一目标实体的质量需要,可被引出并转换为使用质量的需求,然后转换为使用外部性质的质量需求(例如行为)和使用内部性质的质量需求(例如静态属性)。同时,可根据需求设计目标实体。通过执行和迭代质量生存周期提升和改善质量。
QM 包括使用质量的QM、外部性质的QM 和内部性质的QM。在使用周境中对利益相关方的影响可通过使用质量的 QM 进行测量。外部性质的 QM 是行为属性的测度,内部性质的 QM 被用于测量软件和/或系统的技术或结构属性。目标实体的质量性质包括外部质量性质和内部质量性质。当软件和/或系统处于运行状态时,内部质量性质会影响外部质量性质,而软件和/或系统在某一使用周境中的结果或后果受外部质量性质影响。
测量结果的应用：
测量结果可根据质量需求进行解释,包括系统与软件产品质量需求、使用质量需求和数据质量需求。质量需求是通过质量模型和 QM 来定义的。在 GB/T 25000.30 中分别提供了关于质量模型之间的关系和质量需求之间的关系的详细信息。
测量结果为质量评价提供了依据。需要严格的测量实现在系统之间、软件产品之间和数据之间进行可靠的比较。此外,还需要将测量结果与标准值进行比较。测量程序宜以足够的精度测量他们声称要测量的质量特性(或子特性)。质量评价要求宜分配给与其相关的适当组件,以便能够定义用于评价质量的每个适当的 QM。宜为选定的单个测度确定判定准则。宜根据评价计划将选定的 QM 应用于评价对象,从而得出测量标度值。GB/T 25000.40提供了软件质量规格说明和评价的通用要求。
常见的质量测试框架有哪些？
XCTest：为Swift开发者量身定制的单元测试框架，支持iOS、macOS、watchOS和tvOS平台。
Selenium：广泛使用的开源自动化测试框架，支持多种浏览器和操作系统。
JUnit：Java编程语言中最常用的单元测试框架之一。
TestNG：Java编程语言的测试框架，支持参数化测试、数据驱动测试等高级功能。
TDD（测试驱动开发, Test-Driven Development）：强调在编写具体功能代码之前先编写测试用例，通过红绿重构的循环确保代码质量。
DDT（数据驱动测试, Data-Driven Testing）：以数据来驱动测试逻辑，将测试数据与测试逻辑分离，便于处理大量输入输出的情况。
Pytest：在Python领域特别流行，是一个灵活且强大的单元测试框架，同时也支持简单的集成测试。它支持参数化测试、插件系统等高级功能。
Appium：适用于移动应用的自动化测试框架，支持iOS和Android平台，能够使用WebDriver协议进行跨平台测试。
Cucumber：BDD框架，支持多种编程语言，通过Gherkin语言编写人类可读的测试场景，便于非技术团队成员参与。
Mocha / Jest：在JavaScript领域广泛使用的测试框架，Mocha是一个灵活的基础框架，而Jest则由Facebook开发，集成了断言库、测试覆盖率报告等更多特性。
质量测试框架在使用的过程中通常遇到的问题有哪些？
质量测试框架在实际应用中可能会遇到一系列挑战和问题，这些问题跨越了技术、策略和管理等多个层面，以下是一些常见的问题及其简述：
依赖管理问题：单元测试可能依赖于外部服务或组件，这些依赖项可能不稳定、不可用或难以在测试环境中重现，导致测试失败或难以实施。解决方法包括使用模拟（mocking）和存根（stubbing）技术，或者设置隔离的测试环境。
测试覆盖率不足：确保测试覆盖到代码的所有关键部分是一大挑战。目标是达到一个合理的覆盖率（如80%），但这需要精心设计测试用例，并可能需要工具来测量代码覆盖率。
私有方法测试：尽管最佳实践通常建议仅测试公有接口，但在某些情况下可能需要验证私有方法的行为。这可以通过反射等技术间接实现，但过度测试私有方法可能导致维护负担增加。
测试颗粒度过大或过小：测试应足够细粒度以精确定位问题，但又不能过于琐碎，导致测试维护成本过高。平衡测试的大小和复杂度是关键。
测试执行速度慢：大量或复杂的测试套件可能会消耗很长时间运行，影响开发效率。并行测试、优化测试代码、减少不必要的测试数据可以提升测试速度。
测试稳定性问题：不稳定的测试（如因环境变化或随机失败）会降低团队对测试结果的信任度。使用mocks、固定测试数据和适当的测试隔离可以提高稳定性。
测试环境配置：准备和维护一个与生产环境相似的测试环境可能很困难，尤其是资源受限或配置复杂的情况下。提前规划和持续监控测试环境是必要的。
测试数据管理：生成或获取代表性的测试数据，同时保护生产数据的隐私和安全，是一项挑战。
自动化测试框架的配置和维护：自动化测试框架如Selenium、TestNG等的配置可能复杂，且容易出错，需要专业知识来设置和维护。
跨平台/跨浏览器兼容性问题：特别是在Web应用测试中，确保应用在不同浏览器和操作系统上的表现一致是个难题。
测试结果报告与分析：清晰、准确地报告测试结果，并从中分析出有价值的反馈信息，对于改进产品质量至关重要，但不恰当的报告机制可能导致信息丢失或误解。
测试技术不熟练或不足：
问题描述：测试团队的测试技术和知识水平不够，可能导致测试效果不佳。
解决方案：加强测试人员的培训和学习，提升测试技术和知识水平。
缺乏有效的缺陷管理和跟踪机制：
问题描述：在测试过程中，会发现各种缺陷，如果缺乏有效的缺陷管理和跟踪机制，将导致缺陷无法及时修复和验证。
解决方案：建立一个完善的缺陷管理和跟踪机制。可以使用缺陷管理工具来记录和跟踪缺陷，确保缺陷的提交、分配、修复和验证过程的可追踪性。同时，需要对缺陷进行优先级和严重性的评估，确保缺陷修复的及时性和有效性。
测试用例设计不合理：
问题描述：测试用例是测试活动的核心，如果测试用例设计不合理，将无法覆盖系统的各个功能和场景，从而无法有效发现潜在的问题。
解决方案：通过分析需求和系统架构，设计出全面、有效的测试用例。可以采用不同的测试方法，如黑盒测试、白盒测试、灰盒测试等，结合各种测试技术来设计测试用例。
测试计划不完善：
问题描述：测试计划是测试活动的指导文档，如果测试计划不完善，将导致测试活动无法有序进行。
解决方案：编写一个全面、详细的测试计划，包括测试目标、测试范围、测试资源、测试进度、测试方法和技术等。同时，需要考虑到项目的特定需求和约束条件，并与项目团队共同制定测试计划。
237
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
