期货交易所系统招标项目投标书

期货交易所系统招标项目投标书内容摘要：

本验证提示信息位置、格式、内容与需求的一致性。 增加、删除、保存等操作提交 核心业务逻辑 检查核心业务处理实现是否正确，验证系统对每个逻辑分支或可能的输入、输出项都做了友好的异常处理。 功能类型 测试方法 /工具 举例 1 高频度发生业务处理 使用 Robot录制脚本或编写应用程序定制发生条件和发生时点，验证当前时点发生交易的处理是否正确。 连续交易撮合 2 核心业务处理 先采用模块测试测试策略，然后采用联合测试策略；其中，场景数据通过编写脚本自动生成或通过进行数据移植来获取。 功能正确性校验，采用工具对照和库表比对结合的策略。 结算 3 高频度参数变更处理 使用 Robot录制脚本或编写应用程序对系统参数进行计划性调整，验证定制交易在当前时点的处理是否正确。 保证金率调整 4 实时统计发布 编写应用程序实时对库中数据进行动态汇总统计，验证 当前信息发布是否就是当前时点的信息。 行情发布 5 周期长的业务处理 使用 Robot录制脚本定制交易发生时点，验证交易的持续进行及历史数据保存。 持仓 6 大数据量业务限时处理 编写程序自动生成大批量场景数据，使用Robot录制脚本定制交易发生计划，并对交易发生状态进行实时统计和分析。 撮合 期货交易所系统招标项目投标书 股份有限公司 9 模块间或子系统间 检查模块间和子系统间功能执行的连贯性、正确性。 功能类型 测试方法 /工具 举例 1 业务逻辑依赖不紧密的功能 采取并行推进的测试方法。 这种方法即可以单项验证各业务功能的正确性，又可以加快整体 测试进度。 交易权限认证、交易查询、模板创建、会员管理 2 业务逻辑依赖紧密的功能 在每轮测试过程中，将采取顺序推进的测试方法，以便有效验证模块间的接口逻辑和数据传递的正确性。 上游模块的输出是下游模块的输入，例如：报单、撮合、结算、交割等功能 3 业务状态一致性 在第一阶段和第二阶段均需根据业务规则定义使用 Robot测试工具验证每个业务时点业务状态的一致性。 交易员终端发生交易，交易系统进行处理，信息通过行情服务发布给会员，三者信息一致 4 网络通讯 编写应用程序或使用 Robot录制脚本测试本地、局 域网、广域网等节点间的信息传输是否正常发生，验证信息是否存在丢失或延迟。 如服务端对不同类型报文的接收、处理和发送情况。 会员远程指令 文档测试 检查文档的正确性、完备性、可理解性。 功能类型 测试方法 /工具 举例 1 联机帮助文档或用户手册 手工检查帮助文档或手册是否有索引和搜索功能，可以方便、快捷地查找所需信息。 系统帮助文档 2 指南和向导 手工依次执行验证是否可以引导用户一步一步完成任务。 系统操作指南 3 安装、设置指南 手工依次执行验证是否可以根据指导步骤完成安装和设置后，系统能够正常运行。 服务器系统运行监测到系统资源达到临界值或受到攻击时发送的警告 4 示例及模版 手工检查示例和模板的样式、内容等与需求是否一致。 合约模版，价格模版，保证金率模版等 5 错误提示信息 通过场景运行，逐一核对错误提示信息的样式、内容等与需求是否一致。 熔断、报单录入失败等 6 用于演示的图像和声音 用于演示或加在的图片和声音文件是否能正常加载展示 页面图片 7 授权 /注册登记表及用户许可协议 验证安装软件版本间的兼容性 安装软件版本 8 软件的包装、广告宣传材料 软件包装 软件的包装、广告宣传材 料 期货交易所系统招标项目投标书 股份有限公司 10 非功能测试方法 针对交易所系统实时性、可用性、安全性要求较高等特点，在非功能测试方面，主要利用 IBM Rational 系列测试工具，以及采用编写测试程序等方法，分别模拟系统的实际运行、各种可能的非法操作、外部攻击等。 测试必须在与生产环境基本具备可比性的环境下进行，并设计多轮迭代，以便可保证测试采样的真实性、可靠性。 非功能类型 测试类型 测试方法 /工具 安全性 网络消息洪流测试 （ 1）手工或编写应用程序发起敌意会话，验证系统对敌意攻击的处理能力； （ 2）手工、编写应用程序、使用 Robot工具 使用同一 IP进行重复请求，验证系统对多连接请求的处理机制； （ 3）编写模拟程序或使用 Robot工具测试操作系统、组件、配置文件或外部端口访问操作系统、组件的控制和安全审计机制。 多连接请求测试 核心业务组件访问安全测试 基于操作系统的安全控制和审计测试 业务管理系统安全访问测试 交易管理终端身份验证测试 可用性 应用功能测试 （ 1）可用性测试必须保证一段时间的连续运行，通过编写应用程序增大压力测试的幅度，可以适当缩短连续测试时间； （ 2）进行可用性测试一定要选取有代表性的测试 用例脚本，以便能覆盖系统的主要功能和业务流程组合； （ 3）必要时，可采取人为干预的方式使某些系统组件运行失效，以验证系统故障恢复能力和组件运行的独立性。 链接测试 表单测试 性能 客户端测试 （ 1）性能测试时必须保证系统一段时间的连续运行，按照交易所系统的业务特征，至少一轮测试保证连续 1天的运行时间； （ 2）利用 IBM Rational Robot 测试工具录制测试脚本，必要时编写测试程序模拟交易员终端发送报单报文，实现自动并发测试； （ 3）为验证系统可能存在性能问题的关键点，必要时需要开发商 协助在应用中增加 log，输出时间记录信息。 期货交易所系统招标项目投标书 股份有限公司 11 测试用例技术 用例技术说明 测试用例指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。 内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。 测试用例的设计和编制是软件测试活动中最重要的。 测试用例是测试工作的指导，是软件测试的必须遵守的准则。 在 最初测试 时，一般测试 用例 是 考虑不周全 的 ， 需要 随着测试的进行和软件版本更新， 逐步深入、 日趋完善。 针对交易所系统这样的交易 的测试 ，较好的 做法是把测试数据和测试脚本从测试用例中划分出来。 测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的 实施 方案。 对测试用例描述的详细和复杂程度有时难以明确要求。 测试需要在给定的资源、时间条件下尽可能达成目标，我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行，测试用例的详细程度根据需要确定： 对核心的复杂流程和算法，测试用例必须明细到每一步可能的分支；对系统中各个功能模块都需要的通用测试用例，可以提炼通用的测试要素，制定详细的测试用例，而不需在每个用例中重复，以节省编写时间和执行时间，提高用例的复用性。 如：日期校验、金额合法性检查、输 入字段合法性检查等。 测试用例设计方法 分析方法 分析步骤 1 等价类划分 首先，进行分类：将输入域按照具有相同特征或类似功能进行分类；然后进行抽象：在每个子类中抽象出相同特型并用实例来表征这个特性。 2 边界值分析法 首先确定输入域，定义输入边界值；然后确定输出域，定义输出边界值。 3 越界值分析法 首先根据边界分析的结果域确定越界值；然后对越界值进行等价类划分。 4 因果图法 首先，根据业务功能说明书中的输入输出条件分析出等价类，将每个输入输出赋予一个标志符；其次，将对应的输入输出之间，输入与 输出之间的关系联系起来，并将其中不可能的组合情况标注成约束条件或者限制条件，形成因果图；然后，将因果图转化成判定图；最后，将判定表中的第一行作为场景划分要素，每一列可以作为依据进期货交易所系统招标项目投标书 股份有限公司 12 行测试用例设计。 5 判定表驱动分析方法 因果图可以生成判定表，但是也可以直接使用判定表。 判定表（ Decision Table）是列举和分析复合逻辑条件下多个路径的工具。 主要是通过一个二维表格一目了然的将负责的逻辑结构和多种条件组合的情况表达出来。 6 错误推测法 列举程序中所有可能出现的错误和容易发现错误的地方，对它们进行分析 提取场景划分要素。 7 功能图法 使用功能图形式化的表示程序的功能说明，并机械的生成功能图的测试用例。 8 缺值假定法 首先根据因果图法提取出流程进行中的关系数据正确性的关键要素；然后，对这些关键要素进行分析组合，这些组合要素可以直接作为依据进行测试用例设计。 9 动态黑盒测试 首先进行通过测试：确认软件至少能做什么，而不考验其能力。 然后进行失败测试：纯粹为了破坏软件而设计和执行的测试案例，也称为迫使出错测试。 蓄意攻击软件的薄弱环节。 测试用例 应用 （ 1） 指 导测试的实施 在实施测试时测试用例作为测试的 准则 和指导 ， 测试执行 人员一定要按照用例严格按 测试 项目和测试步骤逐一实施测试 ， 并 将 测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。 根据测试用例的测试等级， 每一轮迭代 测试 哪 些用例在设计用例时都已作明确规定， 测试执行 时测试人员不能随意作变动。 （ 2） 规划测试数据的准备 在我们的实践中测试数据是与测试用例分离的。 按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。 尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。 除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。 （ 3） 编写测试脚本的 设计规格说明书 为提高测试效率，软件测试 应 大力发展自动测试。 自动测试的中心任务是编写测试脚本。 如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。 期货交易所系统招标项目投标书 股份有限公司 13 （ 4） 评估测试结果的度量基准 完成测试实施后需要对测试结果进行评估，并且编制测试报告。 判断软件测试是否完成、衡量测试质量需要一些量化的 指标。 例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。 以前统计基准是软件模块或功能点，显得过于粗糙。 采用测试用例作度量基准更加准确、有效。 （ 5） 分析缺陷的标准 通 过收集缺陷，对比测试用例和缺陷数据库，分析确 认 是漏测还是缺陷复现。 漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步 保障 软件质量。 而已有相应测试用例，则反映测试实施或变更处理 过程中 存在问题。 （ 6） 测试用例的评审 测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。 测试用例在设计编制过程中要组织同级互查。 完成编制后应组织专家评审，需获得通过才可以使用。 评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。 （ 7） 测试用例的修改更新 测试用例在形成文档后也还需要不断完善。 主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。 一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。 软件的版本升级更新，测试用例版本一般也应随之编制升级更新。 测试用例管理 运用测试用例还需配备测试用例管理软件。 它的主要功能有三个：第一、能将测试用例文档的关键内容，如编号、名称等自动导入管理数据库，形成与测试期货交易所系统招标项目投标书 股份有限公司 14 用例文档完全对 应的记录；第二、可供测试实施时及时输入测试情况；第三、最终实现自动生成测试结果文档，包含各测试度量值 、 测试覆盖表和测试通过或不通过的测试用例清单列表。 有了管理软件，测试人员无论是编写每日的测试工作日志、还是出软件测试报告，都会变得轻而易举。 建议使用 IBM Rational TestManager 管理测试用例。 测试工具应用 工具应用需求 （ 1） 功能测试需求：能够进行 windows 环境下的功能测试，包括：  能够实现自动化的功能 /回归测试；  能够实现大批量数据驱动情况的自动化功能测试；  测试脚本要易学易用，便于维护。 （ 2） 压 力测试需求：能够进行各种负载环境下的压力测试，包括：  测试不同负载时的系统响应时间；  测试不同负载时的系统吞吐量；  测试工具要具备提供大数据量交易事务的能力。 （ 3） 测试管理需求：能够完成从测试计划、测试设计、测试实施、测试执行到测试结果分析、测试报告的自动生成整个测试生命周期的管理，包括：  能够完成基于目标的测试用例的层次化的分类管理和组织管理，批量地执行一组测试用例，从而可以有效地进行自动化的回归测试；  能够完成对自动执行测试用例和手工执行的测试用例的管理；  能够根据实际测试执行的情况，自动的生成各种测 试分析报告。 功能测试自动化。