在过去的六年中，我一直在从事进行和支持临床试验的应用程序的开发和验收测试。 各种规模和复杂性的应用程序，大数据，大量的可视化和视图，数据仓库，ETL等 该产品供医生，临床试验管理人员以及参与研究控制和监视的人员使用。
对于直接影响患者的生命和健康的应用，需要正式的验收测试过程。 验收测试结果以及其他文档包将提交给FDA（美国食品和药物管理局）审核。 FDA授权将该应用程序用作监视和进行临床试验的工具。 我的团队总共开发，测试了30多个应用程序，并将其发送给生产。 在本文中，我将简要讨论验收测试和用于它的工具的改进。
注意：我并不假装是终极真理，并且完全理解我写的大部分都是“上尉船长”独白。 但我希望所描述的内容对于入门级人员和在日常工作中遇到此问题的团队都有用，或者至少可以让那些拥有更简单流程的人感到高兴。
美国食品药品管理局
临床试验是在临床研究中进行的实验或观察。 这类针对人类参与者的前瞻性生物医学或行为研究旨在回答有关生物医学或行为干预的特定问题，包括新疗法（例如新型疫苗，药物，饮食选择，饮食补充剂和医疗器械）以及需要进一步研究的已知干预措施和比较。 临床试验产生有关安全性和有效性的数据。 维基百科
换句话说，为了使头痛药到达布莱顿海滩某处的药房，该药要经历3个阶段的人体试验，在此过程中，应确定片剂中应包含多少活性物质，其安全性和是否可以治愈头痛。
就我们的工作而言，FDA是什么？它如何影响开发过程和发布周期？
美国食品药品管理局（FDA或USFDA）是美国卫生与公共服务部的联邦机构，是美国联邦行政部门之一。 FDA负责通过控制和监督食品安全，烟草制品，膳食补充剂，处方药和非处方药（药物），疫苗，生物制药，输血，医疗器械，电磁辐射来保护和促进公众健康。发射设备（ERED），化妆品，动物食品和饲料以及兽药。 维基百科
实际上，FDA实际上并不涉及开发过程本身，我们按照通常的SCRUM（老实说，它不是SCRUM进行工作-他们说现在将这种过程称为“修改后的SCRUM”是很流行的），冲刺发布周期。 从交付给最终用户的角度来看，我们不会在每个冲刺结束时（甚至在三个冲刺结束时，甚至在十个冲刺中，如果时间表涉及15个冲刺），都无法交付生产。 ，我们有瀑布式的方法。
在我们的案例中，测试被分为两个独立的部分，它们具有不同的时间表，不同的估计和不同的过程。 第一部分是常规的开发中测试，测试人员是开发团队不可或缺的一部分，并在开发过程中完成sprint。 第二部分是相关活动的实际验收测试和维护（必要时）。 该过程是根据V＆V方法构建的：输入的用户和功能要求，测试脚本和输出的支持文档包。
发布周期取决于项目范围，发布通常不是迭代的。 发布后，应用程序可以长时间保持不变，发布之间的间隔可能从几个月到一年甚至更长不等。
V＆V
什么是V＆V，这如何影响验收流程。
“在软件项目管理，软件测试和软件工程中，验证和确认（V＆V）是检查软件系统是否符合规格以及是否满足预期目的的过程。 它也可以称为软件质量控制。 作为软件开发生命周期的一部分，通常由软件测试人员负责。 简而言之，软件验证是：“假设我们应该构建X，我们的软件是否能够实现其目标而没有任何错误或漏洞？”另一方面，软件验证是：“我们应该构建X吗？ X是否符合高级要求？» Wikipedia
换句话说：
验证：我们做的产品对吗？
验证：我们在生产正确的产品吗？
这意味着我们必须以必要和足够的完整性来测试功能和用户规范。 对我们来说，第一个V变成技术验收测试（SIT），第二个V变成对UAT的支持，其中：
需求覆盖率的可视化在“可跟踪性矩阵”（Excel或Word中的常规表，我将在后面进行介绍）中进行，从而可以从需求到测试进行跟踪，反之亦然。 在使用电子文档管理的情况下，矩阵是自动构建的，测试链接到与测试一起存储的需求（总和= HP ALM，当然不会混淆）。 如果需求没有被涵盖并且不会被涵盖，我们证明为什么我们不涵盖它。
什么时候不需要覆盖范围？
例如，CFR第11部分（
FDA电子记录和电子签名规则 ）包含许多已经在Microsoft中涵盖的要求，因此，如果我们使用Windows AD进行身份验证，则无需再次满足这些要求。
最终，验收测试的实质归结为测试产品是否符合要求以及产品符合性要求。
的角色
大量的角色参与了该过程，参与软件开发的每个人都以一种或另一种形式熟悉该角色：开发人员（初级，中级，高级，主管），单元测试员，SIT测试员，技术产品负责人，业务产品所有者，Scrum主管，项目经理，业务分析师，技术主管，SIT测试主管，UAT测试主管，全球质量控制，支持，部署工程师等。
我们特有的角色-
全球质量控制 。 这是客户方的人员，负责在开发和验收期间遵守并满足流程要求-客户方的软件生命周期和各种标准操作程序（SOP），并进一步提供文件包用于外部审核。
验收文件
在产品发布的范围内，我们创建了一个文档包，其中包含大量嵌套级别，包括与如何测试产品，为何以这种方式进行测试（而不是在其他方面进行测试）有关的文档，以及具体在测试范围内的文档什么不是：
验证计划和团队名册 -PM负责文档的创建和批准。 该文档通常包括系统描述，开发和测试的工件列表，验证策略，角色和职责列表。
测试策略 -不属于特定应用程序但存在于产品分支或测试分支的文档。 例如，我们如何确定测试的哪一部分将是自动化的，我们计划将其用于自动化的方式，我们计划如何进行手动测试，计划使用检查清单，测试脚本，或者两者都使用否则 我们计划如何决定是否执行性能/负载/容量测试； 和类似的事情。
测试计划 -UAT和SIT团队共有的
测试计划 ，包括对测试对象，可能的限制，环境要求，时间，测试套件等的简短描述。
测试套件 -由功能区域，测试类型或任何其他特征组成的一组测试或清单。
可追溯性矩阵 -包含从需求到测试的跟踪的矩阵。 跟踪需求作为覆盖范围的证据是该过程的重要部分。 使用任何需求的标识符，您可以找到测试该需求的特定步骤，并为特定版本的应用程序（或该需求所在的每个版本）提供给审阅者证据（屏幕快照，文件等）。正式涵盖）。 因此，链接，链接并再次将测试链接到需求（任务），即使您不需要这样做，也可以在此基础上获得预期的结果，因为这将简化您的生活。 如果由于使用不同的非集成工具而无法实现，则可以始终在任务/测试中留下注释，或者创建矩阵（上面提到的Excel），或者创建包含三个表的原始数据库。
PDS-产品设计规范，技术主管或系统架构师负责文档的创建。 实际上，它是高级和低级体系结构文档（HLA和LLA）的组合。
FRS和
URS或
BRS-功能和用户要求。 通常，有两个单独的文档，但有时会有包含两个规范的业务需求规范。
缺陷日志 -正式SIT期间在应用程序和/或需求中标识的错误的日志。
次要问题日志 -测试脚本中次要更改的日志（打字错误，剩余需求或多余需求，任何错误）。
测试摘要报告 -有关测试阶段结果的报告，包括以下内容：
- 有关用于测试的内部版本的信息（包括内部版本号和部署日期以及有关部署原因的信息），测试周期数和测试脚本结果（通过/失败）。
- SOP差异的描述。
- 有理由的未解决缺陷清单。
- 缺陷日志或缺陷日志本身的链接。
- 次要问题日志的链接或日志本身。
- 有关部署到生产环境的建议。
部署计划 -用于部署到生产的文档，其中包含对回滚的描述。
验证摘要报告 -验证计划的结束文件。
文件批准
任何文档批准过程都可以分为三个阶段：
让我们看一个测试套件的例子。
为了编写测试脚本并将其组合到测试套件中，我们使用了在客户端认可的标准模板。
测试套件段落：
- 项目和应用程序的名称。
- 发布版本。
- 套件的名称和唯一标识符。
- 描述（我们要测试什么以及我们使用哪种测试类型）。
- 测试脚本。
- 批准人名单。
反过来，每个测试包括：
- 测试脚本的名称和唯一标识符。
- 说明。
- 前提条件。
- 后置条件。
- 可追溯性参考。
- 执行指令（例如，如何屏蔽敏感数据的指令）。
- 步骤（过程，预期结果和观察结果）。
- 测试脚本结果。
- 测试人员。
- 审稿人
测试的正常生命周期类似于瀑布，看起来像这样：
- 写作
需求分析。 测试设计技术的定义和应用，以最充分地覆盖功能。 编写步骤。 - 在开发环境中进行试运行
在此阶段，我们尝试查找应用程序如何满足需求，并找到大多数可能的错误，包括需求错误。 - 负责人审查（SIT团队负责人）
文体和逻辑的审查。 - 在坐姿环境中进行试跑
在此阶段，将捕获与安装，环境和环境配置相关的错误（默认情况下，我们假定SIT环境完全或几乎完全重复PROD）。 成功完成此阶段意味着所部署的版本是稳定的，并且该发行版可以被视为候选版本。 - 客户评论（全球质量控制）
全球质量控制会验证是否满足要求，并且书面测试是否符合公司的SOP。 - 批准（全球质量控制，技术订单，业务订单）。
- 在SIT环境上正式执行测试脚本（发布候选版本）
在批准执行测试（第6页）并在SIT环境下成功完成空运行（第4页）之后，将在结果正式确定的情况下在SIT环境上正式执行测试。 如果在试运行阶段发现的错误不是正式的，并且类似于开发过程中那样简单地输入到Jira中，则将为正式执行中发现的每个错误创建单独的缺陷表，该缺陷表将包含在输出文档中产品包装。 - 测试脚本执行审查（SIT团队负责人）。
与第3点相同。 - 客户评论（全球质量控制）
全局质量控制检查填写结果的正确性和完整性，可能的错误以及证据的存在（例如，屏幕截图）。 重要的一点是，Global QC负责向外部审核（由FDA或客户提供）提供一揽子文件。
处理个人数据
鉴于研究是使用双盲*方法进行的，因此我们遇到的问题较小。 但是必须更改医生，公司名称，研究协议编号等数据。 从正式的角度来看，如果我们无法清除敏感数据，则必须在屏幕截图上屏蔽它们，但这是一个相当标准且可以理解的情况。
*双盲-将患者随机分为两组，一组接受研究药物，另一组接受安慰剂或经证实有效的药物。 同时，医生和患者都不知道患者被分配到哪个组。 这消除了医生的偏见和安慰剂作用。 在处理个人数据的情况下，这意味着在大多数情况下，无法基于数据库中存储的或用户可访问的数据来识别患者的身份。但这是我们问题中最少的事实，并不意味着它不会带来麻烦。 这是我们在项目中获得的一些收益（不踩两次）：
可能很有趣（当时不适合我们）：“地球”
在其中一个应用程序中，不仅要创建哇效果，我们确实需要制作一个交互式地球仪，您可以用鼠标旋转它，昼/夜切换等等。 在全球范围内，地址上都有标记，这些标记根据值和这些值所属的范围进行着色（一种颜色编码）。 在演示环境上对数据库进行匿名处理后，在演示之前两个小时，由于使用了匿名脚本，我们没有邮递区号，这会带来所有后果。
道德：演示前两个小时不要触摸数据。
故事二：“关于匿名化”
背景：数据是从大量来源中收集的，数据属于不同的域，但通过标识符互连。
故事：将数据上传到数据库并进行匿名处理，然后再用于测试目的。 事实证明，并非从所有必要来源下载数据。 然后他们加载了缺少的部分。 无法将数据的第二部分（尚未匿名）与已经匿名的第一部分联系起来。 结果，SIT环境的工作被推迟了两个星期，部署和支持团队对此进行了更正。
道德：匿名化之前，您应确保数据库包含应包含的所有内容，并事先考虑匿名化和混淆机制的适用性。
电子与纸上工作流程的实践
从人工工作的角度来看，电子工作流程在某种程度上简化了沟通以及审查和通过过程，但实际上在准备测试和执行时间上并没有取得任何成功。 下面列出了基于HP ALM的示例的电子工作流程与纸张的优缺点。
好处：
- 易于支持。
- 减少手工工作。
- 所有团队成员随时可以访问特定测试的当前状态
- 变化的历史。
- 处决的历史。
- 您可以跟踪完成测试所需的时间。
- 易于计划将来的运行。
- 很难使用错误版本的测试脚本。
- 电子签名。
缺点（专门针对HP ALM）：
- 脚本格式化需要大量时间。
- 工具本身存在周期性问题。
- 不是最好的拼写检查器。
- 界面不便。
- 编写和复查测试所花费的时间实际上与Word中的测试相同。
- 费用。
与文书工作和手动签名有关的真实故事：“发行前的噩梦”
一天晚上，我写了450次：“图中点的颜色与要求中所述的颜色相对应。 姓，名，日期”并签名-仅因为我们在黑白打印机上打印，并且图形上点的颜色很重要。
道德：手段的选择应与目标相一致。
另一个故事：“重是好的，重是可靠的。”©
纸张工作流程与纸张有关（谁会怀疑纸张）。 与最大应用程序相距甚远的一个阶段的验收测试阶段可能约为5公斤纸。
从上面的故事（以及许多未讲的故事）中可以得出结论：尽管有电子工作流程列出的和未列出的弊端-如果可以选择，那么即使HP ALM（不再是HP）也一定要选择电子的。
自动化技术
大量的可视化无法稳定地实现应用程序的自动化，因此，作为初始方法的一部分，我们将自己局限于单元测试（包括数据库方面的测试）和API测试，而没有任何尝试走向E2E的尝试。
我们如何以及为什么至少要实现部分自动化？
首要任务是向我们自己解释，在某些情况下，我们确实会节省时间。 是的，这是可以理解的：不是每个人都相信自动化，并且自动化的使用常常不能证明自己是正确的-因为以错误的方式使用自动化，不是在那里使用，也不是为了这样做，但这是一个单独讨论的主题，比“自动化必须有!!!”少一点，但仍然很多。
第二件事是向客户解释，他将获得时间，并且从正式的角度来看，时间将是足够可靠和可以接受的。 行业受到控制，这是有原因的。
第三，主要：确定算法，通过该算法，我们可以有意识地对测试特定应用程序或应用程序的一部分进行自动化决策，并获得自动化的同意。 这很重要，因为很明显，自动化过程的控制不得少于手动测试脚本所描述的过程。
在向我们自己和客户解释并证明了前两点的合理性之后，我们编写了一个测试策略，要求业务分析人员在需求中添加其他字段，并根据可以形成一组答案的答案形成一系列问题。用于自动化。
在我们的案例中的问题清单：
- 在这种特殊情况下是否可以自动化测试？
- 它是稳定的*成分吗？
- 我们需要多久执行一次此组件的测试脚本？
- 它是一项关键业务功能吗？
- 自动化测试有多难？
*稳定=一段时间未更改组件，并且不计划在下一发行版中更改组件。
**根据业务分析师添加到需求中的字段的值来填充。
通常，决策过程如下：
- 在输入时，我们有FRS的要求。
我们创建设计矩阵，其中每行是FRS要求，而列是：
- 团队给出问题的答案，并根据收到的数据确定是否值得对全部或部分特定需求/一组需求进行自动化测试。
- 客户检查提议的解决方案并批准最终版本。
- 在批准设计矩阵后，将编写自动测试。 用于自动测试的脚本以Gherkin表示法编写，并经过类似于手动测试的审查（全局质量控制，技术负责人，企业所有者）。 步骤定义，页面对象等均根据拉取请求进行审核，包括由客户方面的技术专家进行审核。 自动测试结果和生成的报告在全球质量控制方面进行审核和批准。
从实施之日起的两年内，我们切换到了与数据仓库中数据的下载，配置和显示相关的两个应用程序的验收测试的部分自动化，并且在不久的将来，我们计划继续在其他应用程序上使用组合方法如果可能，为客户开发产品。
结论
总之，我想指出的是，正式的验收测试并不是吓人或没用的，因为业内很多人都认为这很可怕。 它可以充分利用场景测试方法来促进对未来版本的测试，确定必要和足够水平的软件质量，并最终使客户满意。 如果不是让客户省心的话，那么在外包开发中什么是重要的呢？