Practice_Service validation and testing 服务验证和测试实践

返回ITIL4理论与实践整体知识体系中文版发布文件汇总

服务验证和测试实践涉及减少新的或更改的产品和服务引入运行环境的风险和不确定性。实践通过规划执行此操作并执行适当的测试。 系统越大越复杂，则需要进行的测试越多。但是，由于时间和成本的限制，即使是较小的简单系统也无法进行详尽的测试。因此，选择测试的内容很重要。定义范围和验证的级别以及进行测试时的关键注意事项是： ●生产或服务必须满足的商定要求 ●影响以及偏离议定要求的可能性。 理解背景中的可能性和影响偏差的要求有助于对测试的重要领域有一个明智的了解。 该实践充满了对正在测试的服务的质量的信心。这与说它是完美的不同。通过测试可以赢得信心，以证明服务将按要求运行，符合要求并且没有重大缺陷。 2.1.1服务验证 服务验证在生产和服务生命周期（概念和设计）的早期阶段执行。它着重于确认拟议的服务设计满足商定的服务要求，并着眼于为下一阶段（开发，部署和发布）建立客户或用户体验旅程。然后，将通过测试生产和服务组件，产品和服务来验证这些准则。 验证遵循服务要求的结构，通常涵盖功用，功效，体验，可管理性和合规性。其他要求也可能包括在内。 服务验证确保服务验收标准的定义，验证和文档，并告知范围和测试活动的重点。 2.1.2测试中 基于通过服务验证识别的准则，开发并实施了测试策略和测试计划。 测试策略定义了一种总体测试方法。测试策略可以应用于环境，平台，服务集或单个产品或服务。测试涵盖的生产和服务生命周期阶段在组织内开发的产品和服务与从供应商获得的产品和服务之间可能有所不同。 架构管理，软件开发和管理，项目管理和基础设施和平台管理的更改对服务验证和测试实践产生了很大的影响。敏捷方法，IT基础设施的数字化，面向服务的架构以及软件开发和管理的自动化给服务验证和测试实践带来了新的挑战和机遇。为了满足当今的需求，服务验证和测试应该更快，更灵活并且不断发展。仅当实践与上述实践以及其他实践（包括发布管理，部署管理，事件和问题管理实践）紧密集成在一起时，才有可能。 有效的验证和测试基于测试人员，开发人员和操作团队之间紧密的协作，以及增强的工具和自动化方法。 另一个重要趋势是将验证和测试范围扩展到产品和服务的技术范围之外，包括用户体验和感知。 传统上，服务测试是根据基于需求规范定义的先验知识，通过检查有关软件应如何工作的期望来确认与明确要求相关的期望的行为。今天，测试还涉及探索和发现有关意外情况的信息，例如生产风险和有关以下方面的变量： ●软件 ●软件解决方案的想法 ●制品从想法中创建 ●用户体验和用户接口设计 ●模型和线框 ●架构和代码设计 ●码 ●工具 ●流程。 2.2术语和概念 2.2.1基于风险的测试 基于风险的测试是测试行业中的通用术语。通常，人们将基于风险的测试理解为平均测试（尤其是探索性测试），该测试由与所测试功能和生产组件相关的不同类型的生产风险构成和驱动。专注于风险是有益的，因为它突出了服务可能如何失败。然后可以对此进行调查，以发现有关该软件及其质量的信息。 通常在软件测试中，人们关注测试的类型。测试类型的示例包括职能型，回归，性能或绩效，安全，可用性，跨浏览器，可访问性，端到端和集成测试。这些类型的测试关注于不同类型的风险。例如，职能型测试着重于职能型风险，而回归测试则着重于软件回归的风险。 尽管他们倾向于考虑10到15种测试类型，但许多团队在测试策略中仅包括5到8种测试类型。因此，由于存在影响服务的生产风险的类型很多，而很少与某种类型的测试相关联，因此将重点放在基于风险的测试上非常重要。 2.2.1.1发现风险 识别生产风险的服务验证和测试实践活动与确认风险已得到有效解决的活动一样重要和有价值。 在生产的早期阶段进行的服务验证和测试活动生命周期输出有关生产风险，变量，未知数等的信息。相反，在生产生命周期的后期阶段进行的测试活动会发现问题以及有关服务实际情况的其他信息，然后组织可以响应这些信息。即使服务是运行的，组织也应继续发现有关风险，变量和未知数的信息。该反馈仍在继续，但会导致更长的反馈循环返回到想法，用户故事和设计。 例如，在软件开发中，敏捷用户故事制品和客户或用户体验旅程制品很少关注生产风险。这些制品中的文本通常与有关软件功能或互连性的一般期望有关。在定义客户或用户体验旅程时，识别与用户故事相关的风险非常重要。 识别后，应捕获风险。思维导图是用于此目的的常用工具，因为它们创建了一个风险映射，该映射易于访问，轻巧，易读，并可以在整个生产生命周期服务设计活动以及以后的阶段进行探索性测试中使用。 识别不同种类的生产风险可能很困难，但是有一些方法可以构造客户或用户体验旅程并测试理性分析KT法成功的机会，例如： ●在整体级别上考虑测试的对象，然后仔细地进行测试，包括有形和无形的制品。积极考虑生产，服务或组件： ●潜在目的 ●属性 ●各种用户 ●集成零件 ●架构 ●等等 ●探索每个方面的变量。 ●识别并讨论与变量有关的生产风险。可以确定的风险示例包括： ●可达性风险 ●可用性的风险 ●魅力/喜好风险 ●兼容性风险 ●环境集成风险 ●职能型的风险 ●界面风险 ●本地化风险 ●可维护性风险 ●可观察性风险 ●性能或绩效的风险 ●携带风险 ●可靠性风险 ●响应风险 ●可扩展性风险 ●安全风险 ●稳定性风险 ●可测试性风险 ●可用性风险。 ●评估风险，并决定是否要花费更多的时间和精力来减轻或测试它。有关此主题的更多信息，请参考风险管理实践指南。 ●如果存在重大风险，请创建一个风险映射。风险映射是面向服务设计人员和开发人员的制品。它们还有助于阻止测试章程，该章程涉及通过测试特定领域中的特定风险来构造探索性测试。 Theservicevalidationandtestingpracticeinvolvesreducingtherisksanduncertaintiesthatneworchangedproductsandservicesintroducetotheliveenvironment.Thepracticedoesthisbyplanningandperformingappropriatetests. Thelargerandmorecomplexasystemis,themoretestingisrequired.However,exhaustivetesting,evenofsmaller,simplesystems,istypicallyimpossibleduetotimeandcostconstraints.Therefore,choosingwhattotestisimportant.Thekeyconsiderationswhendefiningthescopeandlevelofvalidationandtestingarethe: ●agreedrequirementsthataproductorservicemustmeet ●impactandlikelihoodofdeviationsfromtheagreedrequirements. Understandingtherequirementsinthecontextofthelikelihoodandimpactofdeviationsfacilitatesaninformedperspectiveoftheimportantareastotest. Thispracticeisaboutbeingconfidentinthequalityofservicebeingtested.Thisisnotthesameassayingthatitisflawless.Confidenceisearnedthroughtestinginordertodemonstratethattheservicewillperformasrequired,meetstherequirements,andhasnosignificantdefects. 2.1.1Servicevalidation Servicevalidationisperformedintheearlierstagesoftheproductandservicelifecycle(ideationanddesign).Itisfocusedonconfirmingthattheproposedservicedesignmeetsagreedservicerequirementsandonestablishingacceptancecriteriaforthenextstages(development,deployment,andrelease).Thesecriteriawillthenbeverifiedbytestingtheproductandservicecomponents,products,andservices. Validationfollowsthestructureofservicerequirementsandusuallycoversutility,warranty,experience,manageability,andcompliance.Otherrequirementsmayalsobeincluded. Servicevalidationensuresthedefinition,verification,anddocumentationofserviceacceptancecriteriaandinformsthescopeandfocusoftestingactivities. 2.1.2Testing Basedonthecriteriaidentifiedthroughservicevalidation,teststrategiesandtestplansaredevelopedandimplemented. Ateststrategydefinesanoverallapproachtotesting.Teststrategiescanapplytoenvironments,platforms,setsofservices,orindividualproductsorservices.Theproductandservicelifecyclestagesthatarecoveredbytestingmaydifferbetweenproductsandservicesdevelopedwithintheorganizationandthoseobtainedfromasupplier. Theservicevalidationandtestingpracticehasbeengreatlyimpactedbychangesinthearchitecturemanagement,softwaredevelopmentandmanagement,projectmanagement,andinfrastructureandplatformmanagementpractices.Agilemethods,thedigitizationofITinfrastructure,service-orientedarchitecture,andtheautomationofsoftwaredevelopmentandmanagementhaveintroducednewchallengesandopportunitiestotheservicevalidationandtestingpractice.Tomeettoday’srequirements,servicevalidationandtestingshouldbefaster,moreflexible,andcontinuallyevolving.Thisisonlypossibleifthepracticeiscloselyintegratedwiththepracticesmentionedaboveandothers,includingthereleasemanagement,deploymentmanagement,incident,andproblemmanagementpractices. Effectivevalidationandtestingarebasedonclosecollaborationbetweentesters,developers,andoperationsteams,alongsideenhancedtoolingandautomationapproaches. Anotherimportanttrendisexpandingvalidationandtestingbeyondthetechnicalaspectsofproductsandservicestoincludeuserexperienceandperception. Traditionally,servicetestingwastheactofconfirmingexpectationsrelatingtoexplicitrequirementsbycheckingtheexpectationsonhowthesoftwareshouldorshouldnotwork,basedonpriorknowledgethatisdefinedthroughrequirementspecifications.Today,testingalsoinvolvesexploringanduncoveringinformationaboutunexpectedthings,suchasproductrisksandvariablesregarding: ●software ●ideasforsoftwaresolutions ●artefactscreatedfromtheideas ●userexperienceanduserinterfacedesigns ●modelsandwireframes ●architectureandcodedesigns ●code ●tooling ●processes. 2.2TERMSANDCONCEPTS 2.2.1Risk-basedtesting Risk-basedtestingisacommontermwithinthetestingindustry.Typically,peopleunderstandrisk-basedtestingtomeantesting(particularlyexplorativetesting)thatisstructuredanddrivenbydifferenttypesofproductrisksrelatingtothefeaturesandproductcomponentsthatarebeingtested. Thefocusingonriskisbeneficialbecauseithighlightshowtheservicemightfail.Thiscanthenbeinvestigatedtouncoverinformationaboutthesoftwareanditsquality. Commonlywithinsoftwaretesting,peoplefocusontypesoftesting.Examplesoftypesoftestingincludefunctional,regression,performance,security,usability,cross-browser,accessibility,endtoend,andintegrationtesting.Thesetypesoftestingfocusondifferenttypesofrisk.Forexample,functionaltestingfocusesonfunctionalrisksandregressiontestingfocusesontherisksofthesoftwareregressing. Althoughtheytendtoconsidertentofifteentypesoftesting,manyteamsonlyincludebetweenfiveandeighttypesoftestingintheirteststrategies.Becauseofthis,andbecausetherearemanytypesofproductrisksaffectingservicesthatarerarelyassociatedwithatypeoftesting,afocusonrisk-basedtestingisimportant. 2.2.1.1DiscoveringRisks Servicevalidationandtestingpracticeactivitiesthatidentifyproductrisksareasimportantandvaluableasactivitiesthatconfirmthatriskshavebeeneffectivelyaddressed. Servicevalidationandtestingactivitiesthatareconductedintheearlystagesoftheproductlifecycleoutputinformationaboutproductrisks,variables,unknowns,andsoon.Contrastingly,testingactivitiesthatareconductedinthelaterstagesoftheproductlifecycleuncoverproblemsandotherinformationabouttheactualsoftheservice,towhichtheorganizationcanthenrespond.Evenwhenservicesareoperational,organizationsshouldcontinuetouncoverinformationaboutrisks,variables,andunknowns.Thatfeedbackcontinues,butstemslongerfeedbackloopsbackintotheideas,userstories,anddesigns. Forexample,insoftwaredevelopment,itisextremelyrareforagileuserstoryartefactsandacceptancecriteriaartefactstofocusonproductrisks.Thetextwithintheseartefactsusuallyrelatestogeneralexpectationsregardingfunctionalityortheinterconnectivityofthesoftware.Itisimportanttoidentifyrisksrelatingtotheuserstoryasacceptancecriteriaarebeingdefined. Afteridentification,risksshouldbecaptured.Mindmapsareacommontoolforthisbecausetheycreateariskmapthatisaccessible,lightweight,readable,andreadytobeusedthroughouttheproductlifecycleservicedesignactivitiesandexplorativetestingatthelaterstages. Identifyingdifferentkindsofproductriskscanbedifficult,buttherearewaystostructureacceptancecriteriaandtestingactivitiesthatimprovethechancesofsuccess,suchas: ●Considertheobjectoftestingonaholisticlevel,thengranularly,includingthetangibleandintangibleartefacts.Activelyconsidertheproduct’s,service’s,orcomponent’s: ●potentialpurposes ●properties ●kindsofusers ●integratedparts ●architecture ●etc. ●Explorethevariablesofeachofthoseaspects. ●Identifyanddiscussproductrisksrelatingtothevariables.Examplesofrisksthatcouldbeidentifiedinclude: ●accessibilityrisks ●availabilityrisks ●charisma/likeabilityrisks ●compatibilityrisks ●environmentintegrationrisks ●functionalrisks ●interfacerisks ●localizationrisks ●maintainabilityrisks ●observabilityrisks ●performancerisks ●portabilityrisks ●reliabilityrisks ●responsivenessrisks ●scalabilityrisks ●securityrisks ●stabilityrisks ●testabilityrisks ●usabilityrisks. ●Assesstherisksanddecidewhethertoinvestfurthertimeandeffortinmitigatingortestingit.Formoreinformationonthistopic,refertotheriskmanagementpracticeguide. ●Forsignificantrisks,createariskmap.Riskmapsareartefactsforservicedesignersanddevelopers.Theyalsohelptostemthetestcharters,whichinvolvesstructuringexploratorytestingbytestingforspecificrisksinspecificareas.