让我们从最甜蜜的地方开始，并给出测试实践中的示例。
想象一下一个准备启动的在线商店。 没什么好麻烦的。 营销人员制定了促销策略，用专门的Internet资源撰写了文章，并支付了广告费用。 管理层预计每周多达300笔采购。 经过第一周，经理记录了53笔付款。 商店管理很生气...
项目经理在寻找原因：缺乏可用性的想法？ 不适当的流量？ 还有什么吗 我们开始理解，研究了数据分析系统。 原来，有247人到达了结帐处，只有53人付款。
分析表明，其余的由于电子邮件地址而无法购买！
订单的测试已交给新手专家。 他竭尽全力，在“名称”，“电子邮件”，“电话”字段中输入了所有可能和不可能的选择，这些选择使他成为了在线生成器。 一周后，发现并修复了所有错误。 已发布。 但是在所考虑的选项中，没有一个电子邮件地址的@后少于8个字符。
因此，邮件@ mail.ru和@ ya.ru（及类似邮件）的快乐所有者无法输入他们的邮件，并离开了网站而没有购物。 店主收到不到60万卢布，整个广告预算都花光了，在线商店本身也收到了很多负面评论。
您认为这是一个孤立的案例吗？ 接下来是客户的另一个恐怖故事。
在人们对无现金支付产生普遍兴趣之后，贷款公司决定采用一种新的资金转移方式-将资金转移到借款人的银行卡上。 我们在经理的个人帐户中实施了适当的表格，在用于输入卡数据的字段中测试了各种错误选项，对其进行了修复并开始工作。 一个月后，管理层收到的信息是，已经获得批准的潜在借款人中有24％直到年底才申请贷款。 怎么了 他们提供的银行卡号为18位，而不是已质押和测试的16位。系统或管理者都无法注册这种卡，客户一无所有。
该试点项目在该市的3个办公室中实施。 三个办事处的平均每月贷款额为340。结果：该组织损失了至少61.2万卢布。 收入。
这些仅是几个示例，在这些示例中，综合数据可能会对项目造成严重损失。 许多测试人员输入合成数据以测试各种项目-从移动应用程序到软件。 在这种情况下，测试人员自己想出测试情况，试图预测用户行为。
但是，他们经常看到用户不是多维的，就像戴着3D眼镜的电影院那样，而是粗略的，好像孩子在相册上画了一个小男人一样。
这导致测试仪无法涵盖所有可能的测试情况，并且无法处理大量数据。 而且，尽管可以很好地进行测试，但是不能保证当真实用户（通常是不合逻辑甚至不可预测）开始与产品进行交互时，系统不会崩溃。
今天，我们将讨论在测试过程中应优先选择哪些数据：合成或真实。
我们会用术语来理解
每次进行测试时，我们都会决定要使用的测试数据。 它们的来源可能是：
- 在测试台上生产数据库的副本。
- 当前可以使用的第三方客户端系统数据库。
- 测试数据生成器。
- 手动创建测试数据。
前两个来源为我们提供了真实的测试数据。 它们是由用户或系统通过现有流程创建的。
例如，当我们加入一个为一家制造公司开发Web产品的项目时，我们可以使用现有1C数据库的副本进行测试，该数据库已经收集并处理了有关运营和客户的所有数据，已有数年的历史了。 使用用于生成和显示已完成订单的报告的模块，我们以所需的格式从1C获取信息，并使用真实的测试数据。
我们将第3点和第4点的来源称为“综合测试数据”（此类术语可以在国外测试中找到，但在俄语段中很少使用）。 我们出于开发和测试目的自行创建此类数据。
例如，我们收到了一个新的电子交易平台的订单，该州的州和市政组织根据44项联邦法律进行了采购。 在这里，遵循非常严格的信息保护规则，因此团队无法访问真实数据。 测试的唯一出路是从头开始创建一整套测试数据。 甚至是仅用于测试的物理数字签名。
在我们的实践中，很少使用一种类型的数据，通常我们根据任务使用它们的组合。
为了检查制造公司在同一系统中的限制和例外，我们还使用了综合数据。 在他们的帮助下，我们检查了其中一个订单中是否没有产品的报告行为。 在电子交易平台上，我们将综合数据与真实参考书OKPD2和OKVED2结合在一起。
综合数据功能
在某些情况下，合成数据根本无法被放弃！ 让我们看看可以在测试人员的武器库中使用哪些任务：
1.简化和标准化
通常，真实数据是同类数据数组：想象一下，成千上万具有一组属性的个人，不同类型的法人实体，标准操作以及许多其他类型的实体已在系统中注册。 那么，如果您可以将它们组合成组并为每个组指定一个“代表”，那为什么还要花几个小时来测试相同的输入呢？
在去年的一个项目中，客户决定在下一个版本发布之前加强测试人员团队，为此我们的专家团队参与其中。 该产品包含具有许多字段的修改后的注册表。 我们布置了30分钟的测试表格，花了大约相同的时间。 同时，还发现另一位测试人员已经对此表格进行了7个小时的测试。 怎么了 他只是决定根据员工列表中12名员工的真实数据进行测试，而没有考虑到一位员工的测试涵盖了每个注册个人资料都相同的所有属性。
利润： 6小时30分钟，仅一次测试。
2.组合和测试范围
尽管实际数据通常很多，但它们可能不包含许多可能的情况。 为了保证输入数据的各种组合的系统可操作性，我们必须自己生成它们。
让我们回到前面的示例。 由于某种原因，新版本中的注册表格已完成。 根据企业文化规范，客户团队决定强制使用中间名。 结果，该州的所有外国专家突然有了一个父亲-伊万（有人说要写伊万诺维奇直到他们修好它）。 这种情况很有趣，但是如果您在测试中没有考虑一些“愿望清单”或客户的参数，那么如果这些人在您的费用/评论中没有考虑到您，就不要感到冒犯。
3.自动化
在自动化测试中，综合数据是必不可少的。 数据中即使看似微不足道的更改也会影响整套测试运行的操作。
来自银行业的一个例子在这里将是说明性的。 为了检查应用程序是否正确地在其生成的文档中记录了银行帐号，我们花费了120个人/小时编写自动测试。 无法访问数据库，因为帐号是在自动测试中指示的。 测试显示出极好的结果，我们准备在报告中从自动化中获得180％+的投资回报率。 但是一周后，数据库更新了，帐号也随之更改。 所有自动测试以及我们的自动化工作均安全完成。 修改自动测试后，最终的投资回报率降至106％。 同样取得成功，我们可以立即开始动手进行测试。
4.改善可管理性
使用综合数据，我们知道（在最坏的情况下，我们假设）对系统期望什么样的响应。 如果对功能进行了更改，我们将了解对相同数据的响应将如何变化。 或者我们可以调整数据以获得所需的结果。
在其中一个项目中，我们的团队开始使用来自客户交易对手数据库的真实数据进行测试。 该数据库已经过积极地完善，但当时却非常粗心。 我们花了很多时间试图了解错误的位置，功能或数据库中的错误。 该解决方案很简单，可以构成一个综合数据库，该数据库虽然更短了，但功能更充分，信息更丰富。 此功能的测试以12人/小时的速度完成。
那有什么缺点呢？
合成数据似乎无所不能。 就是这样，直到您遇到人为因素。 人们有意创建合成数据，这是他们的主要缺点。 我们实际上无法考虑所有可能的情况和输入因素的组合（而且没有人可以消除不可抗力）。 而这里仍然是真实数据的优势。
处理真实数据的好处
我们在处理真实数据时看到什么优势？ 我们的经验有4个证明：
1.处理大量信息
系统的实际运行为我们提供了数百万次的运行。 重复数以千计的用户的同时工作，否则任何专家团队都将无法自动生成数据。
证明：我们创建了一个综合的小型数据库，在我们看来，它满足了客户现有基础的所有条件。 在综合基础上，一切工作都很好，但是一旦您在实际基础上运行测试，一切都会下降。 底线：如果您无法考虑真实数据样本的所有细微差别，请不要浪费时间来生成合成数据。
2.使用多种数据格式
文本，声音，视频，图像，可执行文件，存档-无法预测用户决定上传到表单字段的内容。 有关可接受格式的提示可能会被忽略，并且开发团队可能不会实施禁止下载的规定。 结果，测试了所需的方案。 例如，在声音下载字段中，确实有可能下载mp3文件，而下载可执行文件不会损害系统。 实际数据可帮助我们跟踪异常。
证明：我们测试了用户个人资料中的照片上传字段。 我们尝试了数据库中最常见的图形格式，以及一些视频和文本文件。 综合编译加载完美。 在实际使用中，事实证明，任何下载声音文件的尝试都会导致错误。 整个注册表单崩溃，无法替换文件。 即使页面刷新也没有保存。
3.用户行为的不可预测性
尽管许多质量检查专家成功地创建和分析了特殊情况，但老实说-我们永远无法准确预测一个人的行为方式和周围的因素。 而且，您可以在操作时从关闭Internet开始，然后以程序代码和内部文件开始操作。
证明：在我们公司，员工每年都要进行认证，除其他外，他们会通过特殊的问卷评估他们的技能。 估算与主管达成一致，并根据这些估算来计算专家的职等（级别）。 在发布之前，该模块已经过全面测试，所有工作都像时钟一样。 但是有一次，在保存结果时，对系统进行了ddos攻击，结果仅保存了部分数据，随后的尝试仅保存了重复的错误。 没有真实的情况，我们就不可能找到如此严重的错误。
4.系统更新
了解系统在升级过程中的行为，潜在的风险是什么，哪些可能不会“起飞”，这一点非常重要。 在1C之类的程序中，目录和链接数量众多，更新的问题尤其严重。 在这里，最好的选择是拥有生产版本的新副本，在其上测试更新，然后才发布。
证明：这种情况很普遍。 保理服务领域的项目。 数据丢失和失真的严重性是压倒性的，任何怀疑由系统复制的数据的相关性都可能使整个办公室停滞不前。 在这里，我们的特殊功能歪曲地将下一个更新立即发布到产品，而没有捕获构建的最后10个版本。
他们于上午11点固定在18-00推出，由于版本未完成和不理解，公司部门的工作被完全冻结了2个小时。 管理者无法处理当前合同并注册新合同。
从那时起，我们一直致力于三个展台的工作：- 发展。 这里进行了改进，无政府状态和违法行为仍在继续，这称为异常测试。 质量检查工程师主要处理合成数据，很少注入真实数据。
- 预发行。 当所有改进都得到实施和测试时，它们将进入此分支。 带有销售的版本也已在此处初步推出。 因此，我们在有条件的战斗条件下测试新功能的更新和操作。
- 生产。 这是最终用户可以使用的系统的有效版本。
那么什么数据以及何时工作呢？
我们使用真实数据和合成数据分享我们工作的3个见解：
1.请记住，数据类型的选择取决于测试的目标和阶段。 因此，开发新系统时，我们只能使用综合数据。 为了涵盖输入条件的各种组合，最常见的是，我们转向它们。 但是，复制一些与用户行为有关的棘手异常将需要真实日志。 同样适用于使用公认的目录和注册表。
2.不要忘记使用测试数据来优化您的工作。 在可能的情况下，使用生成器，创建主要实体的通用寄存器，及时保存和使用系统备份，并在适当的时间进行部署。 这样，为下一个项目做准备将不会为您带来忧郁和沮丧，而是工作的一个阶段。
3.不要偏向固体合成物，但不要专注于真实数据。 使用组合的方法来测试数据，以免丢失错误，节省时间并在工作中显示最大的结果。
尽管合成技术的发展前景广阔，而且科学家在合成数据中看到了人工智能的新希望，但合成材料并不是测试的灵丹妙药。 这只是生成测试数据的另一种方法，可以帮助您解决问题，并可能导致新问题。 知道真实/合成数据的优点和缺点，以及在正确的时间应用它们的能力，可以保护您免受损失，停机或法律诉讼的影响。 希望今天我们能帮助您变得更加安全。 还是不行
让我们讨论一下。 在评论中告诉我们有关您使用综合和真实测试数据的案例。 让我们看看我们中间还有谁：现实主义者还是合成主义者？ ;）
维多利亚·索科维科娃（Victoria Sokovikova）。
质量实验室测试分析师