Local EPUB Text
测试交易系统
推出包含程序错误或漏洞的系统的成本可能很大。因此，在模型被广泛推出来之前，对系统进行全面测试至关重要。测试包括以下几个阶段：
·数据集测试；
·单元测试；
·整合测试；
·系统测试；
·回归测试（回测）；
·自动化测试。
数据集测试
数据集测试是指测试数据的有效性，无论是在回测中使用的历史数据，还是从数据流提供者获得的实时数据。数据测试的目的是确保系统能够减少数据中的不良影响以及数据失真，并确保运行时分析工作能够顺利进行，交易信号能够正常生成。
数据集测试是建立在这样一个前提之上的，即为某个特定的安全性而接收的所有数据都应该落在整个时间段内都一致的统计分布区域里。当以不同频率进行抽样时，数据还应显示出一致的分布特性。例如，美元/加元的1分钟数据，应与过去一年的1分钟历史数据的分布一致。本质上，数据集测试应该允许数据分布随时间而变化，但是所观察到的变化不应该是剧烈的，除非它们是由大规模的市场中断引起的。
测试数据的一种方法是基于自相关的一致性测试。操作如下：
1.以给定的频率（如以10秒为间隔）对数据集进行抽样。
2.对30～1000个观测值的移动窗口进行自相关估计。
3.将获得的自相关映射到分布中，确定异常值，并检查其原因。对分布属性进行分析可以进一步回答下列问题：
·在过去一个月、一个季度或一年中，分布属性是否发生变化？
·这些变化是由于代码的版本或者在生产过程中添加或删除程序造成的吗？
应在不同的抽样频率下重复测试，以确保不会发生系统性偏差。
单元测试
单元测试用于验证系统的每个单独的软件组件是否正常工作。将应用程序的可测试部分称为单元，单元定义的范围包括用于最低级功能或方法的代码或者用于中级的功能模块。例如，交易后分析引擎的等待时间测量组件。从头开始测试小模块中的代码，能够确保整合过程中所发生的任何错误在早期被捕获，从而避免昂贵的系统在后期阶段发生崩溃。
整合测试
单元测试之后就是整合测试。顾名思义，整合测试是对代码组件互操作性的测试；当系统从模块化组件建立到其完成状态时，该测试被应用于越来越大的代码聚合。再次测试模块化互操作性，可以确保任何代码缺陷都能够被及早捕获和修复。
系统测试
系统测试是对整个系统的后整合测试。系统测试包含了几个测试过程，具体描述如下：
图形用户界面（GUI）测试，确保系统的人机接口能够使用户（如负责监控交易活动的人员）执行其任务。GUI测试通常确保屏幕上显示的所有按钮和显示器都能按照设计阶段开发的规范和正确的功能相连接。
可用性和性能测试，本质上与GUI测试类似，但不限于GUI，并且还可能包括特定功能的速度等问题。例如，系统处理“系统关机”请求需要多长时间？从风险管理的角度来看，这个时间是否可以接受？
压力测试，是高频交易系统测试的关键组成部分。压力测试过程试图记录并量化极端假设情景对系统性能的影响。例如，如果某个特定证券的价格在很短的时间内下降10%，系统将如何反应？如果不可抗力导致交易所关闭，致使系统持有头寸，该怎么处理？如果其他最糟糕的情况呢，它们如何影响系统的性能和后续的损益？
安全测试，是测试过程中另一个不可或缺的组成部分，但它经常被忽略。安全测试旨在识别可能的安全漏洞，并提供克服违规行为的软件解决方案，或者在发生违规事件时创建违规检测机制和应急计划。高频交易系统可能容易受到来自互联网的安全威胁，不法用户可能会试图盗取账号、密码及其他机密信息，企图窃取交易资金。但是，组织内的威胁也不应被低估，一旦恶意员工或心怀不满的工人以不当的途径进入交易系统，可能对系统造成巨大的破坏，造成巨大的损失。我们必须对所有这些可能性进行测试和考虑。
可扩展性测试，是指对系统的容量进行测试。在不会产生重大的损益影响下，系统可以同时处理多少只证券？这个问题的答案可能看起来微不足道，但实际情况却并非如此。在系统中添加的每个安全措施都需要对计算机电源和网络带宽进行分配。在同一台机器上同时处理大量证券可能会显著降低系统性能，导致报价、交易信号及损益异常变动。可允许的最大证券交易量是根据每个交易平台的特征来确定的，如系统可用的计算能力。
可靠性测试，是用来确定系统故障的概率。可靠性测试试图回答以下问题：系统在什么情况下会发生故障？我们预计这些情况多久发生一次？故障情况可能包括意外的系统崩溃，由于内存空间不足导致的关机，以及导致系统停止运行的其他事件。任何精心设计的高频交易系统的故障率不应超过0.01%（即保证系统正常运行99.99%的时间）。
恢复测试，是指在不利的情况下，无论是不可抗力还是系统崩溃，这个记录恢复程序可以确保系统的完整性得到恢复，并在预先设定的时间内运行。恢复测试还能确保在系统意外终止的情况下，维护数据的完整性。恢复测试应包括以下场景：当应用程序正在运行而计算机系统突然重新启动时，应用程序应该在重新启动时具有有效数据。类似地，如果网络电缆被意外被拔下，然后插回，应用程序应该能够正常运行。
用例测试
用例测试是指根据在系统开发设计阶段期间所定义的系统性能指标体系对系统进行测试的过程。在用例测试中，专门的测试人员遵循系统使用步骤，记录所观察到的行为和应该发生的行为之间的差异。用例测试确保系统在其预定的参数内运行。
用例测试通常由专业软件测试人员执行，而不是编程人员。测试人员的部署很重要，原因有以下几个：
·测试人员经过培训，可以记录给定情景与系统模块实际性能之间的差异。
·测试人员没有参与代码开发，并且对发现的错误是公正的。
·测试人员的劳动成本远低于程序员的劳动成本，从而为组织节省成本。测试人员报告的差异或“漏洞”通常分为三个层次：严重、中度和无关紧要。严重的错误会严重影响预期的系统性能，并需要以最高优先级进行处理；中度的错误是比较大的问题，需要解决关键功能中的错误；无关紧要的错误更多是外观类的，可能直到编码器的行列发生报错，才需要解决。
总结
高频交易系统执行是一个耗时过程，而且报错的成本非常昂贵。外包系统的非关键组件可能是一个审慎的策略。然而，测试是根据为软件开发建立的最佳执行而进行的最重要活动。
章末问题
1.高频交易系统的开发包括哪些阶段？高频交易执行包括哪些阶段？
2.什么是回测？回测有哪些特点？
3.假设在市场价格为125.14时，回测系统以125.13的价格提交限价买单。在什么市场价格水平时，研究人员才能假设限价订单被执行？
4.假设一个系统在回测中的夏普比率为12，这个系统需要进行多少次纸上模拟交易测试才能确定其性能？
5.数据测试中可以采用哪些方法？
6.什么是用例测试？为什么它有价值？