昌平石家庄网站建设,网站建设营销话术,asp.net 建立网站吗,广州网站建设哪家公司基于风险的测试风险是指负面或不希望发生的后果或事件发生的可能性。当引起客户、用户、参与者或干系人对产品质量或项目成功的信心减弱的问题可能发生时#xff0c;风险就存在。当潜在问题主要影响的是产品质量时#xff0c;它们被称为质量风险、产品风险或产品质量风险。而… 基于风险的测试风险是指负面或不希望发生的后果或事件发生的可能性。当引起客户、用户、参与者或干系人对产品质量或项目成功的信心减弱的问题可能发生时风险就存在。当潜在问题主要影响的是产品质量时它们被称为质量风险、产品风险或产品质量风险。而当潜在问题主要影响的是项目成功时它们则被称为项目风险或计划风险。在基于风险的测试中在干系人参与的产品质量风险分析的过程中对质量风险进行识别和评估。测试团队设计、实施和执行测试来缓解质量风险。质量包括影响客户、用户和干系人满意度的全部功能、行为、特征和属性。因此质量风险是产品可能存在质量问题的情况。系统质量风险的例子包括报告中的错误计算与准确度相关的功能风险用户输入响应慢与效率和响应时间相关的非功能风险界面和字段难以理解与易用性和易理解性相关的非功能风险。当测试找出了缺陷时通过让他人意识到这些缺陷并在发布前有机会处理这些缺陷测试缓解了质量风险。当测试不再发现缺陷时通过确保在测试条件下系统可以正常运作测试也缓解了质量风险。基于风险的测试使用产品质量风险来选择测试条件为这些条件分配测试工作并为生成的测试用例设定优先级。基于风险的测试有各种各样的技术这些技术在采集的文档的类型和级别以及运用的形式方面大相径庭。基于风险的测试明确指出的或隐含的目的就是用测试来降低整体的质量风险水平具体而言是把风险水平降低到可接受的范围。基于风险的测试包含四个主要活动1、风险识别2、风险评估3、风险缓解4、风险管理要想取得最佳的效果风险识别和评估小组应包括所有项目和产品干系人的代表不过有时项目的实际情况导致某些干系人代理其它干系人。例如在大众市场的软件开发中可能抽样一小部分潜在客户要求他们帮助识别潜在的严重影响他们使用软件的缺陷在这个例子中抽样的小部分潜在客户就是作为所有最终客户群的代理人。由于测试人员在产品质量风险和失效方面的专长他们应该积极参与风险识别和评估过程一、风险识别干系人可通过下列的一项或多项技术来识别风险1、专家咨2、独立评估3、使用风险模版4、项目回顾5、风险研讨会6、头脑风暴7、检查表8、参考过去的经验对参与风险识别的干系人的抽样越广泛风险识别过程就越有可能识别出越多的严重产品质量风险。风险识别通常会产生一些副产品例如识别出并非产品质量风险的问题。例子包括有关产品或项目的一般疑问或问题或参考的文档如需求和设计说明中的问题。质量风险识别的另一副产品是识别出项目风险不过项目风险并不是基于风险的测试关注的焦点。然而项目风险管理对于包括基于风险测试在内的所有测试方法都是很重要的二、风险评估识别了风险后就开始风险评估即研究识别出的这些风险。具体而言风险评估包括对每个风险进行分类确定风险发生的概率和影响。风险评估还可能涉及评价或分配每个风险的其它属性如风险责任人。风险的分类就是将每个风险划分到适当的类型中例如性能、可靠性、功能性等等。有些组织使用 ISO9126ISO 9126 标准正在被 ISO 25000 标准所取代的质量特征进行分类但大多数组织采用的都是其它的分类方案。风险分类时使用的检查表通常与风险识别使用的相同。有通用的质量风险检查表许多企业都根据自己的需要定制这些检查表。如果使用检查表作为风险识别的基础在风险识别时通常就进行了风险的分类。确定风险的级别通常包括评估每条风险发生的可能性以及发生之后的影响。发生的可能性是指被测系统存在潜在问题的概率。换句话说可能性是对技术风险的级别的评估。影响产品和项目风险发生的可能性的因素包括1、技术和团队的复杂性2、业务分析师、设计师和程序员的人员和培训问题3、团队内部的冲突4、与供应商的合同问题5、异地工作的团队队员6、旧方法与新方法对立7、工具和技术8、管理或技术领导不力9、时间、资源、预算和管理压力10、缺乏前期的质量保证活动11、高变更率 早期的高缺陷率12、 接口和集成问题风险发生的影响是指风险发生对用户、客户或其它干系人的影响的严重程度。换句话说影响来自于业务风险。影响项目和产品风险的影响程度的因素包括1、使用受影响的特性的频率2、该特性对于实现业务目标的关键程度3、声誉的损害 商业损失4、潜在的财务、生态、社会损失或法律责任5、民事或刑事法律制裁6、吊销执照7、缺乏合理的变通8、明显的失效导致负面声誉9、安全性风险的级别既可定性也可定量地评估。如果确定了可能性和影响的量化数据可以将这两个值相乘计算出定量的风险优先级数值。不过通常风险的级别只能通过定性的方式确认。也就是说我们可以将可能性形容成很高、高、中、低或很低但无法用精确的百分比表达出来同样地我们可以将影响形容成很高、高、中、低或很低但也不能完整或精确地表达财务上的影响。不应该认为定性的方法比定量的方法差实际上如果风险级别的定量评估使用不当的话会误导干系人对风险程度的理解和管理。风险级别的定性评估通常通过乘法或加法相结合得到一个风险总分。这个风险总分可能被称为风险优先数但确切来说它应是定性的、有序的相对评级。另外除非风险分析基于广泛的、有效统计的风险数据风险分析应该更多基于干系人对于可能性和影响的主观感知。通常项目经理、编程人员、用户、业务分析师、架构师和测试人员的感知各不相同因此针对各项风险的风险级别可能有不同的意见。风险分析过程应包括达成共识或者即使在最糟的情况下也要有确立都同意的风险级别的方式如通过管理层下达命令或通过取该风险级别的平均值中间值或众数值。此外还应检查风险级别的分布情况确保风险的评分对于测试排序、优先级设定和分工能起到实际的指导作用。否则将无法使用风险级别来指导风险缓解活动。三、风险缓解基于风险的测试从质量风险分析识别和评估产品质量风险开始。质量风险分析是主测试计划和其它测试计划的基础。正如计划中所述测试的设计、实施和执行是为了覆盖风险。开发和执行测试的工作量与风险的级别成一定比例也就是说风险的级别越高使用的测试技术就越细致如结对测试风险的级别越低使用的测试技术就越不细致如等价类划分或有时限的探索性测试。此外开发和执行测试的优先级也是依据风险级别而设定。有些安全规范如 FAA DO-178B/ED 12B,IEC 61508规定了基于风险级别的测试技术和覆盖率。另外风险的级别还应影响到一些决策例如使用项目工作产品包括测试的评审、独立的级别、测试人员的经验水平、确认测试再测试和回归测试的程度。在项目开展期间测试团队仍应对改变质量风险集和或已知质量风险的风险级别的补充信息保持了 解。应该定期调整质量风险分析至少在项目的主要里程碑到来时进行这种调整以此来指导对测试的调整。调整包括识别新风险重新评估现有风险的级别和评价风险缓解活动的有效性。例如如果在需求阶段基于需求规格说明进行了一次风险识别和评估那么当设计规格说明定案后就应对已有的需求规格风险重新进行评价。再如如果在测试中发现某个组件包含的缺陷要远比预期的缺陷数多则可得出在此区域缺陷的可能性比预期的要高的结论并将风险的可能性和整体风险级别上调根据调整结果就应增加该组件测试的工作量。在测试执行开始之前也可以缓解产品质量风险。例如如果在风险识别时发现了需求的问题项目组就可以通过实施全面的需求规格说明评审来缓解这一风险。这样做可以降低风险的级别可能意味着缓解残余质量风险所需的测试数目减少。四、生命周期中的风险管理理想情况下在整个生命周期期间都在进行风险管理。如果组织有测试方针文档和或测试策略文档这些文档中应当描述测试中管理产品风险和项目风险的一般过程以及风险管理怎样集成到测试的各个阶段中并使其发挥作用。一个成熟的组织风险意识应遍及整个项目组在这样的组织中风险管理并非仅仅发生在测试中而是发生在各个方面。重要的风险不仅在特定测试级别的前期就得到处理而且在早期的测试级别中也得到了处理。例如如果性能被识别为一个关键质量风险区域性能测试在系统测试的前期就会开始进行而且在单元测试和集成测试时也会运行性能测试。成熟的组织不仅识别风险还识别风险的来源和风险一旦发生将带来的后果。对于那些确实发生的风险使用根本原因分析来深入理解风险的来源和实施过程改进防范于未然。风险缓解贯穿于整个软件开发生命周期。风险分析获得了充足的信息考虑到了相关的工作活动、系统行为分析、基于成本的风险评估、产品风险分析、最终用户风险分析和责任风险分析。当测试团队参与并对整个程序范围的风险分析产生影响的情况下风险分析超越了测试的范畴。大多数基于风险的测试方法还包括用风险级别来对测试进行排序和优先级设定的技术以此确保测试执行时尽早覆盖最多的重要区域发现最多的重要缺陷。某些情况下所有的高级别风险的测试都是在较低级别风险测试之前进行的且测试的运行严格按照风险排序通常称为“深度优先” 其它情况下测试优先级根据抽样方法来制定。抽样方法就是选择一个测试样本该测试样本可以覆盖到所有已识别的风险。用风险覆盖率评估选出的测试样本确保每条风险至少被覆盖到一次通常称为“广度优先” 。无论基于风险的测试是深度优先还是广度优先分配给测试的时间都有可能不足。基于风险的测试使得测试人员能以剩余风险级别的方式向管理层报告当前测试状态让管理层决定是否要增加测试时间或将剩余的风险转移给用户客户、服务技术支持人员和或运营人员。在测试执行期间最先进的基于风险的测试技术并不一定是最正式或重量级的技术让项目参与人、项目和产品经理、高层行政管理人员和项目干系人根据剩余风险级别监督和控制软件开发生命周期包括做出是否发布的决策。这就要求测试经理在汇报有关风险的测试结果时要确保所有干系人都能理解。
