系统测试[程序化老手]

       系统测试是整合之后对交易系统整体进行测试。系统测试包含下面的几个测试流程：

       图形用户界面（GUI）测试确保系统的人机交互界面可以让用户（如负责监控交易活动的工作人员）完成其工作吗。通常GUI测试需要保证屏幕上出现的所有按钮都与适当的功能相连，一切都与开发过程得瑟设计阶段所制定的说明相符。

       易用性和性能测试与GUI测试在很大程度上是类似的，不过并不限于测试图形用户界面，它还包括测试某个功能的速度之类的内容。例如，系统处理“关闭系统”这个请求需要多长时间，从风险管理的角度来看这个时间是否可以接受，等等。

       压力测试是高频交易系统测试的一个关键部分。压力测试要记录并且量化假设中的极端事件对系统表现造成的冲击。例如，如果某只证券在非常短的时间里下跌了10%，系统将会作何反应如果交易所因为不可抗力而关闭，系统无法平仓怎么办？还有其他哪些最坏的情形？它们又将如何影响系统的表现以及后来的盈亏？

       安全性测试是测试过程中另外一个必不可少，但有经常被人们忽视的环节。安全性测试的目的是找出可能存在的安全漏洞，并且提供软件解决方案来修补漏洞，或者创建一个漏洞检测机制，建立漏洞出现时应急处理措施。高频交易系统很容易受到来自互联网的安全威胁，一些恶意用户可能会为了窃取交易资金而试图劫持帐号、密码等其他机密信息。然而，我们也不能低估机构内部的安全威胁，心怀不轨的员工或者满腹怨恨的工作人员可以通过不正当的方法进入交易系统，由此造成巨大破坏。所有这些可能性都须进行测试并予以考虑。

       可扩展性测试是指测试系统的容量。在不显著影响系统性能的情况下，系统能够同时处理多少只证券并能取得盈利？这个问题答案看是无关紧要，但事实情况绝非如此。在系统中每添加一只证券，都要求分配计算机资源和网络带宽。在同一台机器上同时处理大量证券可能会显著降低计算机性能，从而打乱了报价和交易信号，并且影响到交易盈亏。具体最多能处理多少只证券取决于每个交易平台的性能，以及可用的计算能力。

       可靠性测试确定的是系统出现故障的概率。可靠性测试旨在回答如下问题：系统会在何种情况下出现故障？我们预期这些情况多久发生一次？导致故障的情况可能包括系统意外崩溃、内存不足而至关机，以及其他各种使得系统停止运作的事件等。任何一个设计良好的高频交易系统的故障率都不应该超过万分之一。

       恢复测试指的是不利事件下，不论是不可抗力还是系统崩溃，恢复步骤文档，帮助我们完整的重建系统，并且在预定的时间之内重新运行的能力。恢复测试还要在系统意外中止的情况下保持数据的完整性。恢复测试应当包括如下场景：如果程序正在运行时计算机系统突然重启，重启之后程序应该保有有效数据。类似的，如果网线意外被拔出有重新插入，程序应当继续正常运行。