随着计算机技术的发展，人们越来越希望能运用IT技术为业务运营带来便利和指导。例如通过对生产环境的数据进行分析整合得出业务趋势以预测发展方向或者某项作业完成时间，也可能是通过对已有数据进行一定规则的计算，得到某种统计报告，为业务运营提供可视化和数据化的报告。似乎这样的描述很符合大数据或者BI的范畴，个人这两年陆续做过两个非常类似的和数据相关的项目，我把其统称为数据处理类项目。这类项目也包含数据处理之后的可视化，例如生成统计数据，图标，或者仪表盘等等，所以我想是否也可以称其为可视化项目？但是我所经历过的这两个项目算不上大数据项目，数据量还达不到，所以我们暂且就叫数据处理可视化产品吧。
1.数据处理可视化产品的特点
1)数据源来自真实的生产系统
第一个这类项目是帮助某矿业客户计算其矿上某类设备的使用率，可用率，某段时间内的物理位置分布，车辆状态统计等等。客户期望根据该可视化产品能将矿上的几千辆车辆的历史工作状态进行可视化以辅助设备采购、调度及维修运营工作的开展。属于辅助决策自动化的范畴。这个产品的数据来自某类安装在车辆上的物联网传感器，而且这些数据都是真实的矿上作业时车辆生成的真实数据。
第二个项目是一个内部计算敏捷交付团队的交付效能的产品。根据团队的持续集成，持续部署生成的数据，通过一定的算法处理，得出类似某段时间周期内团队的部署次数，变更的平均前置时间，变更失败率，失败部署的修复时间等等。得到这些指标可以衡量一个团队在交付的过程中的健康程度，帮助团队自身实现交付效能的关注和检测以实现持续改进。
2)简单的数据ETL
不管是来自三方sensor的原始数据还是来自于持续集成平台的原始数据，团队都需要根据业务需求将数据进行简单的抽取和转换。例如将不具备结构的原始数据整合为可读性强的结构化的数据源存储于数据库中。我所做过的两个项目ETL都非常简单，要么直接读取并存储入库，要么就是提取所需信息进行结构化存储。没有复杂的数据清洗，或者转换过程。如下为之前某一项目的数据库示例：
3)包含业务规则的算法处理
两个项目的产品都会对原始数据进行一定业务规则的算法类处理。例如采矿项目，需要根据车辆的物理位置，引擎状态，行进速度等不同车辆属性的不同取值进行该各个业务指标的计算和统计。第二个交付效能的产品也需要根据团队的commit，deployment的状态时间进行统计计算。如下为统计团队交付效能4 key metrics的业务规则：
4)API层对计算结果的封装处理
原始数据 根据业务 规则进行算法计算后，得到的统计数据一般是比较细粒度的，例如某一个轮班周期里某一辆车在矿区内装填炸药的总时间、行进总时间、维修总时间，但产品级的需求通常是某一个月或者某半年矿上3000辆车总的维修时间，总的使用率等。那么产品需要设计相应的API层对业务算法计算出来的基础值进行二次整合封装。这样的做法是方便返回给前端具有某种业务意义的统计数据以方便其展示。
5)统计结果可视化
为了服务业务将计算结果以图标或者仪表盘的方式进行展示和呈现是非常必要的，以达到一目了然，清晰可得的目的。这种图标的展示方式更多是一种类似整个报告的感觉，业务人员或者管理层能清晰地指导某项指标的结果以方便其做决策。如下是之前项目的可视化示例：
2.数据处理可视化产品的测试点
根据上面对这类产品的描述，一句话概括就是把不具备直接业务价值的生产数据进行处理以得到清晰直接的有业务价值的统计数据。简单点说就是数据处理，变废为宝，指导业务运营和生产配置。我们可以 根据数据在各个缓解的处理加工进行相应的测试。如下是之前项目的数据流程图和相应的测试点：
数据类产品，一定有非常清晰的数据处理流程，在每个处理的节点都是我们质量保障需要关注的点。例如：如果你的产品需要关注实时性，那数据源的持续性、完整性、正确性就需要在数据源头进行核实。我之前的项目有个需求是根据矿场上车辆的数据信息在运用里展示出车辆当前的实时位置，如果数据源不连续，不准确，那用户得到的位置信息一定是错误的。
既然是数据处理类产品，算法计算的正确性和健壮性也是需要关注的。往上走便是API借口层面的逻辑处理和计算、前端数据展示呈现的测试。
3.测试的难点
1）测试数据不具备场景性
如上我们看到的生产数据，虽然是结构化的，但是时间是Unix timestamp类型的，车辆的位置虽然有经纬度，但是我们很难在看到数据的同时非常直接知道此时车辆在哪里。即数据可读性不强，每条数据是某一时刻的数据，所以可操作性较弱。
例如为了测试某辆车在不同区域停留的时长统计和在区域之间行进的时长统计是正确的，我们可能需要有这么一个场景数据，刚好这个数据的这辆车，在矿上的不同区域（炸药区、维修中心、爆破区、跨矿区等等）停留的数据，同时为了让这个场景接近真实的生产环境，我们会希望在不同区间之间的往返行进时间是合理的。最简单的方式是，我们矿上有这么一辆车根据测试场景去使用，得到完整的使用数据，然后将这样的数据喂给算法进行统计计算以验证算法。通常交付团队是得不到这样的支持的。
2）测试数据的生成
如上所说，我们会看到数据的场景化特别重要，满足测试目的才行。为了生成满足测试目的的数据，测试团队需要自己生成测试数据。之前在项目上我主要运用了python pandas和Excel进行数据生成。
第一步，根据测试目的，梳理测试用例生成scenario sheet
第二步，根据每个用例的数据要求整理车辆状态变更的数据生成case sheet，一个case一个sheet
第三步，运用python pandas对 Excel的操作方法生成数据
第四步，将生成的具有业务场景的mock数据写入数据库
在度量交付效能的项目上，算法测试的时候选择直接使用静态文件进行数据生成，挑战的点依然是为了测试build的不同状态，编译部署的不同方式，需要梳理出测试的最小集。生成最小的测试数据集以覆盖尽可能多的测试场景。这中间需要测试人员对需求和算饭进行分析，设计以得到这样一个最小集。
3）期望结果不直观
测试场景有了，数据也有了，那某一批测试数据喂给算法计算得到什么样的值才是期望值呢？算法测试相比其他类型的测试，明显不一样的点是，你需要对期望值进行提前计算。就像会计一样，你需要自己去计算，才知道别人（算法）算得是否正确。
像我之前做过的两个数据处理类运用，计算过程都和时间有关联，例如时间点A到时间点B车辆在装炸药，例如团队在时间点A对某一次的部署失败了，在时间点B重新部署成功了。测试人员需要自己根据 ‘ 场景-> mock 测试数据 -> 计算期望值‘这条线上来回看。比较容易出错的点是，mock数据的时候时间弄错了，复制粘贴的unix timestamp错了导致计算出来的期望值和预先设计的场景不一致。但基础算法的测试，没法去自动化，否则变成了和开发一样去写一套QA自认为的算法，你又怎么保证自己的算法没问题呢？
4）客户验收算法困难
算法类故事卡的验收相比业务流程，应用界面的验收也是更难的。通常情况下，一些应用的功能，我们只用直接展示相应的功能，客户即可知道该功能是否和预期一致。但是算法的正确性，演示是比较困难的。我当时的做法是，把自己的测试过程，包括场景设计、数据准备、算法输出都跟客户过一遍。再到界面上去直观的展示计算结果。是相比其他应用类测试验收更费时费力的，而且整个过程需要PO跟上你的测试思路。
