为了确保医药，保险，银行和其他行业中信息产品的质量以及其他测试方法，使用基于风险的测试非常重要。 为了进行验证，选择了要创建的软件中风险最高的区域。 这使我们能够预料不利的情况并成功实现客户的业务目标。
在本文中，我们将说明SimbirSoft如何处理风险（以Internet采集系统和其他项目为例），以及我们在客户项目中使用了哪些风险评估和管理方法。
项目开始时的风险
首先，我们以银行业发展中的实践为例。
客户的建议：针对个人，选择银行的网络版本。
我们确定的风险：与移动客户银行相反，由于网络版本对个人的需求较低，可能会导致受众减少。
我们的论点是：根据用户对手机和网络版本的评论和分布情况，对用户的偏好进行统计。
结论：对于个人而言，移动版本更方便，因为手机始终在手边。 操作快速，授权系统使您能够访问所有便捷的服务。 在这种情况下，快速访问有限的一组最受欢迎的功能非常重要。
对于法人实体，提供的功能的完整性，上载，打印和处理大量信息的能力非常重要。 为此，Web版本更加方便。
我们的解决方案：专注于个人的移动客户银行。
在项目开始之初，正确选择测试策略很重要。 让我们看一下为什么它很重要以及如何选择它的示例。
测试策略必须符合业务目标
迟早，所有公司都需要组织测试过程，并了解建立其策略是软件开发的重要阶段。 有时-通过自己的痛苦经历。 低估测试和策略选择在大型项目开发中的作用尤其危险。 应根据业务目标和项目的具体情况选择测试过程，否则在一个月或一年内都不会产生积极的结果。
例如，考虑为一家银行测试移动和Web应用程序。 在项目开始时，我们根据要求不高的细节选择了策略。 我们使用清单来减少测试时间并支持测试基础。 随着功能的增长，除了获取，短信授权和通知，更复杂的系统之外，清单也不再能够满足其任务。 随着时间的流逝，越来越多的质量检查专家加入了该团队，有必要传递信息并协调他们的行动。 随着产品的复杂化，任何变化都可能影响相关功能，即回归的风险增加。 回归测试自动化的需求正在酝酿之中，因此我们转向了测试用例。
结论：根据项目，具体细节或开发阶段，测试策略会有所变化。
必须为项目目标选择策略，以确保获得最佳质量的产品。 她回答了将测试“什么”，“在哪里”和“何时”的问题。 根据策略，您随时都可以知道自己现在处于什么位置以及将来将要到达的位置。
一个业务目标可能是在生产阶段确保客户数据以及软件本身的安全性。 安全性从开发过程开始，一直持续到测试阶段。
例如，在其中一个项目中，我们为开发和测试创建了安全的环境，部署了可满足所有要求并帮助保护数据的基础架构。 我们要求每位质量检查专家使用经过认证的令牌和基于名称的闪存驱动器，以访问测试基础结构。 因此，我们确保了该项目在软件安全性方面的业务目标，并对客户和用户数据保密。
由于采用了测试策略，因此可以将重点放在特定项目的真正重要方面。 合乎逻辑的是，发布移动游戏或复杂的银行CRM系统需要使用不同的测试方法。
银行测试策略
在我们的实践中，我们SimbirSoft使用了全部开发方法，但是灵活的技术始终是我们的首要任务。 即使在由于多种原因无法使用它们的情况下，团队也会采用最佳做法并将其应用于日常工作中。 测试成为整个过程不可或缺的一部分，并融合到整个工作流程中。 在这种情况下，它不仅对产品质量负责，甚至对整个工作过程的质量负责。
我们使用什么技术：
- 灵活计划和准备内部发布；
- 用户故事准备；
- 举行集会；
- 进行回顾。
测试策略可以在具有复杂业务逻辑的项目中充分发挥作用。 例如，用于银行信息支持的软件，互联网获取系统的构建，自动交易平台。 在此类项目中，应用适当的测试策略非常重要，因为某些错误的代价可能会导致实际损失，并严重影响公司的声誉。
此外，可能还会增加测试的主要目标-缺陷搜索和符合性的软件验证。 例如，对于银行来说，快速实施中央银行的新要求非常重要。 这意味着将以关键任务所需的质量进行及时的测试添加到主要目标中。
最近，在一个银行项目中，我们面临着联邦法律的变化-增值税率从18％提高到20％。 为了适应法规的变化，做了很多前期工作，因为变化不仅涉及形式，界面的替换，还涉及几种计算公式逻辑的更改。 必须确保在许多平台上正确显示。 此外，在延期付款功能中，有必要考虑过渡期，税率分别为18％和20％。
现在，我们将更详细地讨论我们如何制定策略以及为什么我们经常选择基于风险的测试。
基于风险的测试的优点
为特定目的选择了几种测试策略：
在使用具有复杂业务逻辑的项目的情况下，有必要在测试所基于的系统设计中确定严格的要求。 合适的工具是基于需求的测试。
一种基于需求的策略是基于风险的测试。 此外，系统功能中最容易遭受风险的部分将首先进行测试。 风险是系统故障可能造成的负面后果。 结果是存在机会和消极两部分的风险。
有两种类型的风险：
1.产品风险它可以被管理和不受管理。 在上面的示例中，我们面临着可控的风险：快速增长和功能复杂性，这增加了回归的可能性。 在这里，我们通过拥有易于理解的测试基础和后续的自动化解决了该问题。 我们无法影响的风险是对外部系统的依赖及其在集成过程中的失败。 在这里，我们将采取措施来减少它们对我们系统的影响。 例如，使用备份，处理例外情况，为用户显示警告。
2.项目风险例如，在一个项目中，我们面临着这样一个事实，即客户以前没有与分布式团队合作，因此使用的工作流程不符合要求并造成了其他沟通问题：缺乏理解，任务重复，互斥任务的执行等。 我们同意重组和改进流程-修改了工作流程，介绍了所有团队成员，举行了集会，演示和回顾。 结果，工作朝着正确的方向发展。
基于风险的方法使您可以在短时间内组合一定数量的风险，以高优先级测试风险，并进一步为客户提供有关测试程度的度量标准，以显示计划和完成的案例数量以及缺陷数量。
在项目上实施基于风险的方法分为四个阶段：
风险识别 -在此阶段，您需要识别风险并获取它们的列表。
风险评估 -在这里我们分析列表并按优先级对其进行分类。
降低风险 -在此阶段，我们确定测试风险的深度。
风险管理 -在这里，我们决定如何继续与他们合作并经历它们，确定新的风险。
一组利益相关者在集思广益会议期间识别并评估了风险。 团队应包括业务分析人员或来自客户，开发人员，经理或项目经理，架构师，质量保证专家的系统知识载体。 我们有信息安全专家，直接与当前系统合作的员工以及致力于确定和评估风险的流程的业务分析师。
以测试Internet获取系统为例，考虑基于风险的方法。
应对风险（以互联网获取系统为例）
我们挑出以下要求：
D1。每秒提供1000个同时连接到系统的连接。
D2。 交易安全。
D3。 只有进行交易的人员才能访问交易。
D4。 提供并支持SET（安全电子交易）标准。
作为产品风险，我们可以区分：
RP1。 同时连接导致系统崩溃。
RP2。 在事务期间使用SQL注入。
RP3。 更改URL中的参数时，可以访问其他人的事务。
RP4。 交易时与银行的连接断开时，数据丢失。
RP5。 提供SET（安全电子交易）系统时使用无效证书。
作为组织风险：
RO1。 由于无法访问外部系统，导致开发系统的崩溃。
RO2。 存在无法在测试环境中检测到的难以复制的案例。
因此，每个风险在逻辑上都遵循系统中的要求，但不仅限于此。 风险补充了需求，并确定了在使用系统时可能出现的其他情况。
可以根据项目目标和系统要求来降低或补偿风险。 公认风险已由测试用例至少覆盖一次：
1.对于每种产品风险，准备一组测试用例RP1-RP4，条件是每个需求和每种风险都应至少包含一个测试用例。 根据测试的目的，将测试用例集扩展到一定的详细程度。
2.针对每种组织风险，准备
了一系列活动，可以减少风险对正在开发的产品的影响。
风险评估与管理技术
有几种评估和管理风险的方法：轻量级方法（PRAM，PRISMA）和更正式的方法（FMEA，FTA）。
利用FMEA模型，项目团队可以识别系统中所有可能发生会导致产品质量下降的系统故障或错误的所有流程，组件，模块。 在头脑风暴期间，系统的风险由三个指标确定：严重性，优先级，可能性。 然后针对每个风险计算风险优先级编号，并根据指标确定测试深度。
使用FTA模型，可以分阶段确定可能导致系统业务流程出现缺陷的所有原因。 分析从最高到最低。 FMEA和FTA之间的区别在于，第一种方法侧重于系统的功能，第二种方法侧重于业务流程。
除了这些正式和繁重的方法外，还有更灵活和非正式的方法。 例如，PRAM（务实分析和风险管理）和PRISMA（产品风险管理）方法。 他们成功且轻松地将基于风险和需求的策略相结合。 基本上，这些方法使用需求规范作为输入，但是利益相关者也可以参与其中。
轻量级风险分析方法与正式方法非常相似。 他们专注于技术或商业风险，权衡风险发生的可能性和影响该可能性的因素。
但是，这些方法使用的仅有两个因素是风险的可能性及其影响。 此外，这些方法使用简化的定性判断和量表进行决策。
我们的团队使用灵活的轻量级方法，并使PRAM和PRISMA方法适应其目标。
我们如何进行基于风险的测试
例如，在一个项目中，我们确定可能起作用的项目和产品风险。 为此，分析人员，开发人员和质量检查人员（团队中的一名代表）参与了分析。
产品形成风险表。 他们确定了风险发生的可能性及其对系统的五点评估。 在表1中，影响最大的是5，影响最小的是。 同样对于概率1-高概率，5-低概率。
我们如何继续应对产品风险
此外，对于每个产品，产品的风险范围都可以通过测试案例进行追踪。
我们选择以下检查：
TC1。 通过与系统的1000多个连接进行负载检查
TC2。 通过1000个系统连接进行负载测试
TC3。 在事务期间输入SQL注入
TC4。 通过替换其他数据，在成功事务页面上输入SQL注入
TC5。 在进行交易时，将XSS（跨站点脚本）脚本输入到可用字段中以进行输入
TC6。 模拟交易过程中断开的Internet连接
TC7。 在验证步骤中退出交易会话
TC8。 交易期间验证过期的证书
因此，优先级检查是TC2，TC4，TC5。
TC6和TC8的影响很大，但可能性较小，因此检查它们的优先级较低，但是也需要检查。
TC7不适用于任何要求，但会将测试扩展为否定情况，这可以在系统稳定运行的情况下实现。
我们如何继续应对项目风险
我们还确定针对项目风险的措施，通过这些措施，我们可以分配其他措施和决策。
风险“ RO2。 如果存在无法在测试环境中检测到的难以复制的案例，您可以采取以下措施：
- 与所有外部系统一起，准备一个尽可能接近实际应用环境的预生产摊位；
- 编写通过所有相邻系统并提供交易验证的端到端测试脚本；
- 完成所有优先级检查后，根据系统的基本要求和脚本使用错误猜测技术，以“系统黑客”的身份进行其他检查。
应急预案
如果产品或项目风险之一起作用，制定一项行动计划很重要。 有时可以节省设置项目的备份系统的时间。 并非总是可以将风险降低到最低水平，但是应该至少可以降低其后果。 我们的文章
“圣诞节故事”就是关于这个主题的：风险如何发挥作用，风险的可能性趋于零。
例如，我们必须完全消除交易期间的数据丢失，但要考虑所有情况下的工作量。 因此，您需要具有处理此类情况的方法。 安全性的一种选择是开发更详细的日志记录。 如果在事务过程中出现问题，这将提供对先前操作的永久回滚点。
结论
基于风险的测试使您可以用测试用例覆盖最危险的区域，从而减少其影响和被触发的可能性。 对于具有复杂业务逻辑和高错误成本的系统，这是最成功的策略。 该解决方案适用于银行部门，保险公司，医疗档案的复杂内部CRM系统。 通过基于风险的方法，我们还可以处理项目风险，从而改善了测试和项目管理的总体流程。