Practice_Service validation and testing 服务验证和测试实践
本帖最后由 FYIRH 于 2022-8-10 17:26 编辑返回 ITIL 4理论与实践整体知识体系中文版发布文件汇总
需要下载最新翻译版本请关注微信公众号：ITILXF，并回复“验证和测试”即可。
服务验证和测试实践涉及减少新的或更改的产品和服务引入运行环境的风险和不确定性。实践通过规划执行此操作并执行适当的测试。
系统越大越复杂，则需要进行的测试越多。但是，由于时间和成本的限制，即使是较小的简单系统也无法进行详尽的测试。因此，选择测试的内容很重要。定义范围和验证的级别以及进行测试时的关键注意事项是：
● 生产或服务必须满足的商定要求
● 影响以及偏离议定要求的可能性。
理解背景中的可能性和影响偏差的要求有助于对测试的重要领域有一个明智的了解。
该实践充满了对正在测试的服务的质量的信心。这与说它是完美的不同。通过测试可以赢得信心，以证明服务将按要求运行，符合要求并且没有重大缺陷。
2.1.1 服务验证
服务验证在生产和服务生命周期（概念和设计）的早期阶段执行。它着重于确认拟议的服务设计满足商定的服务要求，并着眼于为下一阶段（开发，部署和发布）建立客户或用户体验旅程。然后，将通过测试生产和服务组件，产品和服务来验证这些准则。
验证遵循服务要求的结构，通常涵盖功用，功效，体验，可管理性和合规性。其他要求也可能包括在内。
服务验证确保服务验收标准的定义，验证和文档，并告知范围和测试活动的重点。
2.1.2 测试中
基于通过服务验证识别的准则，开发并实施了测试策略和测试计划。
测试策略定义了一种总体测试方法。测试策略可以应用于环境，平台，服务集或单个产品或服务。测试涵盖的生产和服务生命周期阶段在组织内开发的产品和服务与从供应商获得的产品和服务之间可能有所不同。
架构管理，软件开发和管理，项目管理和基础设施和平台管理的更改对服务验证和测试实践产生了很大的影响。敏捷方法，IT基础设施的数字化，面向服务的架构以及软件开发和管理的自动化给服务验证和测试实践带来了新的挑战和机遇。为了满足当今的需求，服务验证和测试应该更快，更灵活并且不断发展。仅当实践与上述实践以及其他实践（包括发布管理，部署管理，事件和问题管理实践）紧密集成在一起时，才有可能。
有效的验证和测试基于测试人员，开发人员和操作团队之间紧密的协作，以及增强的工具和自动化方法。
另一个重要趋势是将验证和测试范围扩展到产品和服务的技术范围之外，包括用户体验和感知。
传统上，服务测试是根据基于需求规范定义的先验知识，通过检查有关软件应如何工作的期望来确认与明确要求相关的期望的行为。今天，测试还涉及探索和发现有关意外情况的信息，例如生产风险和有关以下方面的变量：
● 软件
● 软件解决方案的想法
● 制品从想法中创建
● 用户体验和用户接口设计
● 模型和线框
● 架构和代码设计
● 码
● 工具
● 流程。
2.2 术语和概念
2.2.1 基于风险的测试
基于风险的测试是测试行业中的通用术语。通常，人们将基于风险的测试理解为平均测试（尤其是探索性测试），该测试由与所测试功能和生产组件相关的不同类型的生产风险构成和驱动。专注于风险是有益的，因为它突出了服务可能如何失败。然后可以对此进行调查，以发现有关该软件及其质量的信息。
通常在软件测试中，人们关注测试的类型。测试类型的示例包括职能型，回归，性能或绩效，安全，可用性，跨浏览器，可访问性，端到端和集成测试。这些类型的测试关注于不同类型的风险。例如，职能型测试着重于职能型风险，而回归测试则着重于软件回归的风险。
尽管他们倾向于考虑10到15种测试类型，但许多团队在测试策略中仅包括5到8种测试类型。因此，由于存在影响服务的生产风险的类型很多，而很少与某种类型的测试相关联，因此将重点放在基于风险的测试上非常重要。
2.2.1.1 发现风险
识别生产风险的服务验证和测试实践活动与确认风险已得到有效解决的活动一样重要和有价值。
在生产的早期阶段进行的服务验证和测试活动生命周期输出有关生产风险，变量，未知数等的信息。相反，在生产生命周期的后期阶段进行的测试活动会发现问题以及有关服务实际情况的其他信息，然后组织可以响应这些信息。即使服务是运行的，组织也应继续发现有关风险，变量和未知数的信息。该反馈仍在继续，但会导致更长的反馈循环返回到想法，用户故事和设计。
例如，在软件开发中，敏捷用户故事制品和客户或用户体验旅程制品很少关注生产风险。这些制品中的文本通常与有关软件功能或互连性的一般期望有关。在定义客户或用户体验旅程时，识别与用户故事相关的风险非常重要。
识别后，应捕获风险。思维导图是用于此目的的常用工具，因为它们创建了一个风险映射，该映射易于访问，轻巧，易读，并可以在整个生产生命周期服务设计活动以及以后的阶段进行探索性测试中使用。
识别不同种类的生产风险可能很困难，但是有一些方法可以构造客户或用户体验旅程并测试理性分析KT法成功的机会，例如：
● 在整体级别上考虑测试的对象，然后仔细地进行测试，包括有形和无形的制品。积极考虑生产，服务或组件：
● 潜在目的
● 属性
● 各种用户
● 集成零件
● 架构
● 等等
● 探索每个方面的变量。
● 识别并讨论与变量有关的生产风险。可以确定的风险示例包括：
● 可达性风险
● 可用性的风险
● 魅力/喜好风险
● 兼容性风险
● 环境集成风险
● 职能型的风险
● 界面风险
● 本地化风险
● 可维护性风险
● 可观察性风险
● 性能或绩效的风险
● 携带风险
● 可靠性风险
● 响应风险
● 可扩展性风险
● 安全风险
● 稳定性风险
● 可测试性风险
● 可用性风险。
● 评估风险，并决定是否要花费更多的时间和精力来减轻或测试它。有关此主题的更多信息，请参考风险管理实践指南。
● 如果存在重大风险，请创建一个风险映射。风险映射是面向服务设计人员和开发人员的制品。它们还有助于阻止测试章程，该章程涉及通过测试特定领域中的特定风险来构造探索性测试。
The service validation and testing practice involves reducing the risks and uncertainties that new or changed products and services introduce to the live environment. The practice does this by planning and performing appropriate tests.
The larger and more complex a system is, the more testing is required. However, exhaustive testing, even of smaller, simple systems, is typically impossible due to time and cost constraints. Therefore, choosing what to test is important. The key considerations when defining the scope and level of validation and testing are the:
● agreed requirements that a product or service must meet
● impact and likelihood of deviations from the agreed requirements.
Understanding the requirements in the context of the likelihood and impact of deviations facilitates an informed perspective of the important areas to test.
This practice is about being confident in the quality of service being tested. This is not the same as saying that it is flawless. Confidence is earned through testing in order to demonstrate that the service will perform as required, meets the requirements, and has no significant defects.
2.1.1 Service validation
Service validation is performed in the earlier stages of the product and service lifecycle (ideation and design). It is focused on confirming that the proposed service design meets agreed service requirements and on establishing acceptance criteria for the next stages (development, deployment, and release). These criteria will then be verified by testing the product and service components, products, and services.
Validation follows the structure of service requirements and usually covers utility, warranty, experience, manageability, and compliance. Other requirements may also be included.
Service validation ensures the definition, verification, and documentation of service acceptance criteria and informs the scope and focus of testing activities.
2.1.2 Testing
Based on the criteria identified through service validation, test strategies and test plans are developed and implemented.
A test strategy defines an overall approach to testing. Test strategies can apply to environments, platforms, sets of services, or individual products or services. The product and service lifecycle stages that are covered by testing may differ between products and services developed within the organization and those obtained from a supplier.
The service validation and testing practice has been greatly impacted by changes in the architecture management, software development and management, project management, and infrastructure and platform management practices. Agile methods, the digitization of IT infrastructure, service-oriented architecture, and the automation of software development and management have introduced new challenges and opportunities to the service validation and testing practice. To meet today’s requirements, service validation and testing should be faster, more flexible, and continually evolving. This is only possible if the practice is closely integrated with the practices mentioned above and others, including the release management, deployment management, incident, and problem management practices.
Effective validation and testing are based on close collaboration between testers, developers, and operations teams, alongside enhanced tooling and automation approaches.
Another important trend is expanding validation and testing beyond the technical aspects of products and services to include user experience and perception.
Traditionally, service testing was the act of confirming expectations relating to explicit requirements by checking the expectations on how the software should or should not work, based on prior knowledge that is defined through requirement specifications. Today, testing also involves exploring and uncovering information about unexpected things, such as product risks and variables regarding:
● software
● ideas for software solutions
● artefacts created from the ideas
● user experience and user interface designs
● models and wireframes
● architecture and code designs
● code
● tooling
● processes.
2.2 TERMS AND CONCEPTS
2.2.1 Risk-based testing
Risk-based testing is a common term within the testing industry. Typically, people understand risk- based testing to mean testing (particularly explorative testing) that is structured and driven by different types of product risks relating to the features and product components that are being tested.
The focusing on risk is beneficial because it highlights how the service might fail. This can then be investigated to uncover information about the software and its quality.
Commonly within software testing, people focus on types of testing. Examples of types of testing include functional, regression, performance, security, usability, cross-browser, accessibility, end to end, and integration testing. These types of testing focus on different types of risk. For example, functional testing focuses on functional risks and regression testing focuses on the risks of the software regressing.
Although they tend to consider ten to fifteen types of testing, many teams only include between five and eight types of testing in their test strategies. Because of this, and because there are many types of product risks affecting services that are rarely associated with a type of testing, a focus on risk-based testing is important.
2.2.1.1 Discovering Risks
Service validation and testing practice activities that identify product risks are as important and valuable as activities that confirm that risks have been effectively addressed.
Service validation and testing activities that are conducted in the early stages of the product lifecycle output information about product risks, variables, unknowns, and so on. Contrastingly, testing activities that are conducted in the later stages of the product lifecycle uncover problems and other information about the actuals of the service, to which the organization can then respond. Even when services are operational, organizations should continue to uncover information about risks, variables, and unknowns. That feedback continues, but stems longer feedback loops back into the ideas, user stories, and designs.
For example, in software development, it is extremely rare for agile user story artefacts and acceptance criteria artefacts to focus on product risks. The text within these artefacts usually relates to general expectations regarding functionality or the interconnectivity of the software. It is important to identify risks relating to the user story as acceptance criteria are being defined.
After identification, risks should be captured. Mind maps are a common tool for this because they create a risk map that is accessible, lightweight, readable, and ready to be used throughout the product lifecycle service design activities and explorative testing at the later stages.
Identifying different kinds of product risks can be difficult, but there are ways to structure acceptance criteria and testing activities that improve the chances of success, such as:
● Consider the object of testing on a holistic level, then granularly, including the tangible and intangible artefacts. Actively consider the product’s, service’s, or component’s:
● potential purposes
● properties
● kinds of users
● integrated parts
● architecture
● etc.
● Explore the variables of each of those aspects.
● Identify and discuss product risks relating to the variables. Examples of risks that could be identified include:
● accessibility risks
● availability risks
● charisma/likeability risks
● compatibility risks
● environment integration risks
● functional risks
● interface risks
● localization risks
● maintainability risks
● observability risks
● performance risks
● portability risks
● reliability risks
● responsiveness risks
● scalability risks
● security risks
● stability risks
● testability risks
● usability risks.
● Assess the risks and decide whether to invest further time and effort in mitigating or testing it. For more information on this topic, refer to the risk management practice guide.
● For significant risks, create a risk map. Risk maps are artefacts for service designers and developers. They also help to stem the test charters, which involves structuring exploratory testing by testing for specific risks in specific areas.
这个不全啊，能重发一下吗？
页:
[1]