标签：投资 经验总结 数据集 帮助 展示 传统 固定 mic 复杂
根据IDC全球半年度大数据和分析支出指南的最新预测，到2022年全球大数据和业务分析解决方案的收入将达到2600亿美元。在大数据和业务分析解决方案上投资增长最快的行业包括银行（复合年增长率13.3%）、医疗、保险、证券和投资服务、电信，每个行业复合年增长率都是12.8%。由此可见，大数据类项目在未来的地位将会越发重要，而作为QA，在大数据项目急速扩张的大背景下，也将迎来新的机遇和挑战。
大数据项目与传统交付项目的不同之处在于其关注的重点为数据、算法而不再是用户操作逻辑、页面展示等，整个项目将围绕数据质量和算法结果耗费大量精力。
项目涉及到大量各种格式的数据，如图像、平面文件、音频等，其结构和格式不尽相同。与传统的交付类项目相比，大数据项目的数据量可能会大得多。其数据特点是3 V – Volume，Velocity and Variety：
大数据项目中的测试通常与数据测试，算法测试以及功能测试有关。明确大数据项目中测试关键点将有助于项目的成功交付。
大数据项目中数据流转是至关重要的一部分，从不同的数据源系统流入至运算操作系统再流出至数据展示系统的过程中都要保障数据质量。
数据质量包括数据的完整性、准确性、一致性、及时性。
在多数数据系统中数据以下图的模式进行流转，关注数据流转过程中数据的质量也是QA所面临的一项重要挑战：
1.数据从数据源流入到我们所构建的大数据系统
数据从不同的数据源流入大数据系统，一般数据源包括：其他数据系统、CSV或EXCEL等文件、传感器、扫描仪、日志等等。在从数据源流入大数据系统前需进行数据清理，以确保得到正确的、需要的数据。在数据量极大的情况下，可能会引入Hadoop（或类似的框架）。无论引入何种框架，都需数据从数据源中以高质量的形式导入至我们所构建的大数据系统中。为验证此步的数据流转，需要掌握SQL、Hadoop命令等，这就对QA提出了新的要求。
除此之外，在大数据项目的测试中，由于数据量非常庞大，若非特意进行性能测试，通常只需选取有代表性的少量测试数据集进行测试，以避免每次测试流程都耗费过多时间。所谓有代表性，即这些数据能覆盖全部的主要计算逻辑和大部分的边界场景。
2.在大数据系统中进行运算
数据进入系统后，会对数据进一步处理，在处理数据中可能会用到Hive，Python等。作为QA还需掌握以上技能，以便开发脚本来提取和处理数据来进行测试。
大数据系统中对数据的处理会包括逻辑处理和算法挖掘两种。前者更偏向于业务处理，后者更偏向于数据挖掘或机器学习的算法。例如，假设某系统是对未来三天的天气进行预测，其用于进行模型训练的数据包括天气、温度、日期、城市等，在开发系统时，开发人员首先将全部数据按照城市进行分组，然后将不同城市的数据输入到机器学习算法中进行预测。在该系统中“按城市进行分组”即为逻辑处理，“用机器学习算法进行预测”即为算法挖掘。这是一个简化的例子，通常应用程序会更加复杂，在该系统中对于逻辑处理部分可按照传统测试方法进行测试，对于算法挖掘部分则需重点关注输入至算法的数据的正确性以及输出结果的各项指标表现。
然后将处理后的数据存储在数据仓库中。在将数据存储在数据仓库中之后，可再次对其进行验证，以确保它与经过数据系统运算后生成的数据一致。
3.数据结果展示
通常最后一步会将数据暴露给业务人员或下游使用者，通过可视化或者数据接口的形式进行输出，以便产生业务价值。可能会使用商业智能工具，或者由业务人员使用R、Python等语言进行数据分析，因此有必要对该输出结果进行验证。若通过Web页面将数据以可视化图表的形式展露给客户，就需要对Web页面进行测试，若通过Report的形式报告给客户，就必须对生成的Report进行测试。此步除了验证数据的准确性、完整性外，可能还需要验证数据的及时性。比如直播墙需要对数据统计结果进行实时展示，业务报表可能需要当天或当周进行展示，需满足系统有不同的时限要求。
根据项目的不同，以上的架构可能会有细节上的不同，下面以实际项目为例进行简单的介绍。
例如，在某智慧物流项目中，需对物流订单进行路径规划，将全部的物流订单（包括接货订单和送货订单）分配给各个货车司机，根据订单的接货地址和送货地址以及订单的时间要求对每个货车司机的订单进行路径规划。优化的目标是在限制时间内从发货人手中收取全部货物并将货物全部送收货人手里，且尽可能使路径总和最小化。其系统结构按照数据流转可以大致按以下方式划分：
根据数据在系统中的流转从左至右来看，测试注意点包括以下几方面：
对于算法结果的验证是数据类项目中遇到另一个挑战，在这里我按照以往的项目经验总结了“三、二、一”：三个已践行，二个待实现，一个贯穿始终。
1.确保每步逻辑正确
1) 在敏捷实践中对于需求的拆分和追踪是以Story的形式进行的，数据项目中尤其要确认好每一个Story的输入数据样式、输出数据样式来确保在开发过程中各个Story之间可以顺利衔接，在辅以Kick Off和Desk Check等敏捷实践，确保Dev、BA、QA对于需求的理解一致。
2) 算法部分一般是调用外部的包直接实现的，一般假设这部分的实现逻辑没有问题，故重点需关注输入至算法的数据。
2.向用户或者业务人员展示结果
1) 若在进行探索研究阶段就已经输出完整的数据处理逻辑和算法处理过程，且其结果得到验证，项目内容主要是对该研究结果进行工程实现，则需保障工程实现过程中的质量。该情况下，保障质量的方法是把工程实现系统和在探索研究阶段输出的结果进行对比，这也是在帮助客户进行工程实现时较为常用的一种方法。
2) 算法有固定的输出结果，比如数据分析类项目中需要统计某类订单的数量，可以采用构建测试数据和预期输出数据，判断系统输出结果是否与预期相同的方法。
3) 没有研究阶段的输出结果，也没有固定的输出，比如智慧物流系统里路径规划，我们采取的方案是将结果展示给货司机，让他们去实际按照路线送货，由真正的用户来判断是否是其想要的结果。类似于这种结果无法由开发团队直接判断的，需尽早且持续的将结果展示给用户或相关业务人员，请其对算法结果进行反馈。
3.不同数据集多次验证。
设计不同的数据集进行验证，验证算法在不同数据下的表现，探究算法的边界。比如上文中提到的智慧物流项目可能适用于上海的场景，不一定适用于北京的场景，因为该算法用于训练的历史数据多为上海地区数据。
1.以最终目标为依据
比如智慧物流，最终的目标是降低成本、提高收入。所以算法本身的指标，比如灵敏度，召回率都不是最终的计算，甚至路程都不是最终的目标。可以设定一个f（x）=总收入-总成本，目标为总成本最低。再比如滴滴的推荐算法，加了一个滴滴司机提供的反馈信息，这个信息只包括一条“你会不会把这个app推荐给朋友”。该推荐算法的目标为提高司机的满意度以推广软件，即为司机将算法推荐给朋友的数量。
2.线上迭代验证
模型的验证指标，比如召回率，灵敏度等，作为一个指标放到线上去做验证。对于上线的模型选取部分测试数据对其进行迭代验证，在不满足指标的情况下发出告警。该情况可能是由于随着时间的推移，用于训练的历史数据已经不再适应新的情形导致，需要算法工程师重新对其进行评估。
真实数据对于系统的验证非常重要，人为构造的数据无论是在分布形态还是异常场景覆盖上都比不上真实的生产数据。测试数据分布不同于真实数据时，可能会导致算法在测试阶段表现良好，而在进入到生产系统后表现欠佳。在测试数据构造困难的情况下，由于测试数据对异常场景的覆盖不足，在进入生产系统引入真实数据后，甚至有可能会导致算法实效或系统崩溃等严重后果。
而实际项目中，获取可用于测试的真实数据，往往也是一大挑战。
目前在网上能找到的跟大数据项目测试相关的文章有限，便结合经历过的项目进行了以上的总结。若有同样在大数据项目中担任QA角色的同学，欢迎一起来交流讨论。
标签：投资 经验总结 数据集 帮助 展示 传统 固定 mic 复杂
原文地址：https://www.cnblogs.com/iwangwei/p/10408748.html
