智能建筑信息系统解决方案
招标编号：****
投标单位名称：****
授权代表：****
投标日期：****
第1章XX软件的独特优点
XX软件公司专注于项目管理的实施、普及与提升，从而积累了深厚的项目管理实战经验。尤其在软件过程能力构建上，XX软件已建立健全符合国际标准IS09000、CMM及CMMI质量管理体系。此体系于2003年8月经由QAI权威机构进行了CMM咨询服务并成功达到三级认证。
2004年，XX软件公司携手IBM在国内开创了首个基于Rational/SDP的测试服务中心及区域间协同开发平台。该平台获得了IBM的官方授权，专注于软件测试工作，凭借IBM Rational的先进技术——成熟的Rational/SDP解决方案和全面的自动化测试工具，辅以Rational统一过程(RUP)的管理体系，我们实现了对软件测试全生命周期的精细管理，确保了全方位的质量控制，并为客户提供了多元化的测试服务方案。
作为国内领先的项目管理服务供应商，XX软件公司独树一帜地融合了国际前沿的项目管理理念、CMM（能力成熟度模型）以及Rational/SDP（软件开发过程）的优势，致力于确保项目的顺利实施与成功完成。
XX软件公司荣幸地投身于'期货交易所系统'验收测试项目的投标竞争，我们深信，我们的解决方案全面契合期货交易所对该项目的需求与标准。同时，XX软件公司期待借此良机，与期货交易所携手开启长远的策略性合作关系，共创繁荣，协同进步。
本投标方案旨在响应《期货交易所系统招标项目需求书》的指导，依托XX软件公司长期在金融及其它行业的深厚测试积淀，凭借其先进的项目管理理念、尖端的测试技术和高效工具，致力于为期货交易所系统的验收测试项目提供卓越的、高质量的服务。
第2章创新技术方案
2.1交易所系统的特性探讨
作为期货交易所的核心组成部分，交易所系统需全面支撑包括金融期货衍生品在内的各类交易、结算及管理职能。
为了执行对交易所系统的验收测试，我们将详尽概述系统的两大关键特性：业务特性和系统特性。
2.1.1特性分析
期货交易的主要特性体现在以下几个方面： 1. 合约标准化：所有交易均基于标准化合约进行，确保了交易的标准化程度。 2. 交易集中化：所有的买卖双方在交易所这一共同平台上进行交易，降低了信息不对称和交易风险。 3. 结算统一化：交易所负责所有交易的清算和结算，保证了流程的规范化和效率。 4. 保证金制度化：交易过程中实施严格的保证金制度，增强了交易的安全性和市场的稳定性。
交易所系统，致力于遵循期货交易法则，其核心目标在于实现各类期货功能。其关键业务特性表现为：
·交易的复杂程度高，要求容错能力强；
期货交易的核心环节即风险管理，它贯穿交易过程的始终。
●针对交易产生的大量数据进行处理。
2.1.2特性的详细描述
(1)性能
为了满足期货交易的极高实时性需求，交易所系统的性能标准远超常规，它必须具备卓越的系统容量承载力、强大的处理能力和迅捷的响应时间。
(2)可靠性
期货交易的业务流程具备较高的复杂性，涵盖了广泛的交易规则、风险管理、结算与交割环节。理想的业务系统应能满足业务运作的需求，并具备高效应对异常情况的能力，尤其是要确保系统的稳定运行，避免发生系统崩溃或服务中断。任何此类故障都可能引发巨额资金的盈亏波动，对交易所的声誉造成无法弥补的损害。
(3)安全性
确保期货交易的顺利运行，业务系统的安全稳定扮演着至关重要的角色。系统漏洞、外来威胁与病毒入侵等因素均可能对系统构成严峻考验。若交易所系统的安全性能未能达标，将可能导致会员客户对交易的信任度受损。系统的安全性需遵循全面防护、主动防御、多层保护、易用性和可扩展性等核心原则，且在各层面均需实施严格的安防措施。
2.2详细测试项目
本项目的涵盖内容包括期货交易所系统的多个关键组件：交易系统、交易控制员终端、交易所管理、结算系统、会员客户管理系统、会员服务体系以及风险监控系统。此次验收测试的目标在于验证这些子系统的功能完整性和性能指标是否符合预设目标。
交易所系统主要支持的交易与管理产品涵盖了金融衍生品种类，其中包括股票指数、期权以及复合指令等金融工具。
测试涵盖的主要内容有：权限管理、订单操作、报价机制、合同处理、交易撮合、市场行情、交易执行，以及合约查询、价格监控、保证金比率分析、风险熔断规则、产品信息、市场动态、结算流程、资金管理、系统参数和押品相关事务的监督与查询管理。
性能测试涵盖的方面主要包括系统容量评估、接入能力检验、交易处理系统的效能分析以及业务管理系统的处理性能测评。
测试范畴涵盖交易系统及业务管理系统的可用性与安全性评估。
交易所系统的全面测试着重于期货交易所系统与会员系统之间，通过标准化报文进行交易数据的交互与通信。测试流程明确排除了与任何第三方系统的接口验证。评估范畴涵盖C/S架构（客户端/服务器）以及B/S架构（浏览器/服务器）的系统组件。
2.3测试策略
通过对交易所系统业务特性和架构特点的深入剖析，我们已经确立了相应的测试策略。在正式启动测试之前，我们将对这一总体策略进行详尽的分解，以确保其精准地引领整个测试流程。
(1)迭代化测试
作为核心业务系统的交易所系统，为了确保全面的测试并防范关联性错误，我们采用分阶段深入的测试策略。每个阶段需规划多轮细致的测试进程。因此，针对每个测试阶段，必须预先制定明确的迭代测试计划，包括设定每一轮的具体目标与达成标准。在每轮迭代测试正式启动前，我们将根据项目实际进展动态调整各轮测试目标。
(2)顺序推进、并行测试
针对那些业务逻辑相互独立的功能，如交易权限认证、交易查询、模板创建及会员管理等，我们计划采用并行测试策略。这种方法旨在分别验证各个业务功能的准确性，同时提升测试流程的总体效率。
针对模块间存在高度业务逻辑关联的功能，如报单、撮合、结算与交割等，其特性在于上游模块的输出直接作为下游模块的输入。在每次测试迭代中，我们将采用逐个模块依次验证的策略，以确保各环节接口逻辑和数据传输的精确无误。
(3)手工与自动化测试相结合
为了确保系统的全面检验，我们计划通过Robot自动化执行关键测试用例，直接从数据源导入订单数据，随后将其推送至交易所系统，借此验证交易系统及结算系统的交易功能是否实现无误。
(4)综合运用各种测试技术
测试流程应用黑盒测试策略，所有相关的数据输入、检索与验证均通过系统的功能界面操作实现。
通过对业务需求和业务功能说明书的深入剖析，运用用例场景分析方法，明确测试用例的核心流程（基本流）与可能变通路径（备选流）。
测试场景设计时需要尽量考虑打破常规的业务规则，考虑各种可能的业务组合，验证系统的容错性；
在构建测试用例的过程中，应灵活运用等价类划分、因果图分析、判定表设计、边界值策略以及正交试验设计等多种方法进行系统性的规划与设计。
2.4标准化测试流程
2.4.1测试流程
提交由用户所界定的被测系统业务需求与详细功能规格说明书
用户需提交经过开发商系统测试并通过的可执行的被测系统。
验收测试所需的业务规则配置已确定。
2.4.2完成测试标准
测试用例设计经过同行评审和用户认可；
所有业务需求得以完整涵盖；测试用例执行率达到百分之百的成功率。
验收测试报告得到用户签字确认。
2.4.3验收标准
|
项目 |
建议 |
|
缺陷清除率 |
全部缺陷清除率大于95％。 |
|
一二级缺陷 |
一二级缺陷全部清除零缺陷反弹点至少出现在最后一轮测试前 |
|
需求的覆盖率 |
100％覆盖业务需求 |
|
缺陷密度 |
每个功能点发现的一二级缺陷密度小于4个 |
|
最后一轮测试 |
无一级缺陷，二级缺陷占比小于10％ |
2.5高效测试策略与创新技术
2.5.1高效的功能测试策略
2.5.1.1用户界面测试
以下为优秀用户界面的关键特性：遵循标准与规范，呈现直观易懂的交互设计，注重一致性体验，赋予灵活适应性，追求舒适的操作感受，确保准确性，强调其实用性和功能性。
|
|
功能类型 |
测试方法／工具 |
举例 |
|
1 |
进入方式检查 |
手工测试验证菜单方式、快捷方式、地址方式等 |
客户成交明细表查询 |
|
2 |
页面链接检查 |
手工测试或使用Robot录制GUI脚本验证每一个链接是否都有对应的页面，并且页面之间切换正确。 |
行情发布 |
|
3 |
相关性检查 |
手工测试或使用Robot录制GUI脚本验证删除／增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。 |
增加／删除价格绑定模版 |
|
4 |
按钮功能检查 |
手工测试或使用Robot录制GUI脚本验证update、cancel、delete、save等功能是否正确。 |
合约自动创建模版 |
|
5 |
字符串长度检查 |
手工测试或使用Robot录制GUI脚本验证输入超出需求所说明的字符串长度的内容，看系统是否检查字符串长度，会不会出错。 |
报单录入 |
|
6 |
字符类型检查 |
手工测试或使用Robot录制GUI脚本验证在应该输入指定类型的内容的地方输入其他类型的内容，看系统是否检查字符类型，是否报错。 |
报价录入 |
|
7 |
标点符号检查 |
手工测试或使用Robot录制GUI脚本验证输入内容包括各种标点符号，特别是空格、各种引号、回车键，看系统处理是否正确。 |
手工增加合约 |
|
8 |
中文字符处理 |
手工测试或使用Robot录制GUI脚本验证在可以输入中文的系统输入中文，看会否出现乱码或出错。 |
交易员登陆、报单查询、行情发布等 |
|
9 |
检查带出信息的完整性 |
手工测试在查看信息和update信息时，查看所填写的信息是不是全部带出，带出信息和添加的是否一致。 |
新建合约 |
|
10 |
信息重复 |
手工测试在一些需要命名且名字应该唯一的信息输入重复的名字或ID，看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否做出正确处理。 |
会员注册 |
|
11 |
检查删除功能 |
手工测试或使用Robot录制GUI脚本验证在一些可以一次删除多个信息的地方，不选择任何信息，按“delete”，看系统如何处理，会否出错；然后选择一个和多个信息，进行删除，看是否正确处理。 |
委托单删除 |
|
12 |
检查添加和修改是否一致 |
手工测试或使用Robot录制GUI脚本验证检查添加和修改信息的要求是否一致，例如添加要求必填的项，修改也应该必填；添加规定为整型的项，修改也必须为整型。 |
委托单增加和修改 |
|
13 |
检查修改重名 |
手工测试或使用Robot录制GUI脚本验证修改时把不能重名的项改为已存在的内容，看会否处理，报错。同时，也要注意，会不会报和自己重名的错。 |
委托单修改 |
|
14 |
重复提交表单 |
手工测试或使用Robot录制GUI脚本验证一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。 |
新建委托单 |
|
15 |
检查多次使用back键的情况 |
手工测试验证在有back的地方，back，回到原来页面，再back，重复多次，看会否出错。 |
会员合约查询 |
|
|
功能类型 |
测试方法／工具 |
举例 |
|
16 |
search检查 |
手工测试或使用Robot录制GUI脚本验证在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确。如果可以输入多个search条件，可以同时添加合理和不合理的条件，看系统处理是否正确。 |
成交查询、资金查询等 |
|
17 |
输入信息位置 |
手工测试注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方。 |
增加产品 |
|
18 |
上传下载文件检查 |
手工测试验证上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。 |
帮助文件下载 |
|
19 |
必填项检查 |
手工测试应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加＊。 |
手工增加合约 |
|
20 |
快捷键检查 |
手工测试是否支持常用快捷键，如Ctrl＋CCtrl＋VBackspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。 |
进入方式、页面输入等 |
|
21 |
回车键检查 |
手工测试在输入结束后直接按回车键，看系统处理如何，会否报错。 |
页面输入或按钮输入 |
|
22 |
提示信息检查 |
手工测试或使用Robot录制GUI脚本验证提示信息位置、格式、内容与需求的一致性。 |
增加、删除、保存等操作提交 |
2.5.1.2核心业务逻辑
评估核心业务处理的实现准确性，确认系统针对所有可能的逻辑分支及输入、输出情况均进行了有效的异常管理，确保友好用户交互。
|
|
功能类型 |
测试方法／工具 |
举例 |
|
1 |
高频度发生业务处理 |
使用Robot录制脚本或编写应用程序定制发生条件和发生时点，验证当前时点发生交易的处理是否正确。 |
连续交易撮合 |
|
2 |
核心业务处理 |
先采用模块测试测试策略，然后采用联合测试策略：其中，场景数据通过编写脚本自动生成或通过进行数据移植来获取。功能正确性校验，采用工具对照和库表比对结合的策略。 |
结算 |
|
3 |
高频度参数变更处理 |
使用Robot录制脚本或编写应用程序对系统参数进行计划性调整，验证定制交易在当前时点的处理是否正确。 |
保证金率调整 |
|
4 |
实时统计发布 |
编写应用程序实时对库中数据进行动态汇总统计，验证当前信息发布是否就是当前时点的信息。 |
行情发布 |
|
5 |
周期长的业务处理 |
使用Robot录制脚本定制交易发生时点，验证交易的持续进行及历史数据保存。 |
持仓 |
|
6 |
大数据量业务限时处理 |
编写程序自动生成大批量场景数据，使用Robot录制脚本定制交易发生计划，并对交易发生状态进行实时统计和分析。 |
撮合 |
2.5.1.3模块间或子系统间
评估各模块及子系统间功能执行的连贯性和准确性。
|
|
功能类型 |
测试方法／工具 |
举例 |
|
1 |
业务逻辑依赖不紧密的功能 |
采取并行推进的测试方法。这种方法即可以单项验证各业务功能的正确性，又可以加快整体测试进度。 |
交易权限认证、交易查询、模板创建、会员管理 |
|
2 |
业务逻辑依赖紧密的功能 |
在每轮测试过程中，将采取顺序推进的测试方法，以便有效验证模块间的接口逻辑和数据传递的正确性。 |
上游模块的输出是下游模块的输入，例如：报单、撮合、结算、交割等功能 |
|
3 |
业务状态一致性 |
在第一阶段和第二阶段均需根据业务规则定义使用Robot测试工具验证每个业务时点业务状态的一致性。 |
交易员终端发生交易，交易系统进行处理，信息通过行情服务发布给会员，三者信息一致 |
|
4 |
网络通讯 |
编写应用程序或使用Robot录制脚本测试本地、局域网、广域网等节点间的信息传输是否正常发生，验证信息是否存在丢失或延迟。如服务端对不同类型报文的接收、处理和发送情况。 |
会员远程指令 |
2.5.1.4文档测试
检查文档的正确性、完备性、可理解性。
|
|
功能类型 |
测试方法／工具 |
举例 |
|
1 |
联机帮助文档或用户手册 |
手工检查帮助文档或手册是否有索引和搜索功能，可以方便、快捷地查找所需信息。 |
系统帮助文档 |
|
2 |
指南和向导 |
手工依次执行验证是否可以引导用户一步一步完成任务。 |
系统操作指南 |
|
3 |
安装、设置指南 |
手工依次执行验证是否可以根据指导步骤完成安装和设置后，系统能够正常运行。 |
服务器系统运行监测到系统资源达到临界值或受到攻击时发送的警告 |
|
4 |
示例及模版 |
手工检查示例和模板的样式、内容等与需求是否一致。 |
合约模版，价格模版，保证金率模版等 |
|
5 |
错误提示信息 |
通过场景运行，逐一核对错误提示信息的样式、内容等与需求是否一致。 |
熔断、报单录入失败等 |
|
6 |
用于演示的图像和声音 |
用于演示或加在的图片和声音文件是否能正常加载展示 |
页面图片 |
|
7 |
授权／注册登记表及用户许可协议 |
验证安装软件版本间的兼容性 |
安装软件版本 |
|
8 |
软件的包装、广告宣传材料 |
软件包装 |
软件的包装、广告宣传材料 |
2.5.2高效非功能性评估策略
针对交易所系统对实时性、可用性和安全性等高标准的需求，在非功能性测试阶段，我们主要借助IBM Rational系列的测试工具，并通过编写定制化的测试脚本，对系统的实际运行、潜在非法操作及外部威胁等场景进行模拟。所有测试均需在与生产环境具有高度可比性的环境中实施，并采用多轮迭代的方式，以确保测试样本的真实性和可靠性。
|
非功能类型 |
测试类型 |
测试方法／工具 |
|
安全性 |
网络消息洪流测试 |
（1）手工或编写应用程序发起敌意会话，验证系统对敌意攻击的处理能力；（2）手工、编写应用程序、使用Robot工具使用同一IP进行重复请求，验证系统对多连接请求的处理机制：（3）编写模拟程序或使用Robot工具测试操作系统、组件、配置文件或外部端口访问操作系统、组件的控制和安全审计机制。 |
|
多连接请求测试 |
||
|
核心业务组件访问安全测试 |
||
|
基于操作系统的安全控制和审计测试 |
||
|
业务管理系统安全访问测试 |
||
|
交易管理终端身份验证测试 |
||
|
可用性 |
应用功能测试 |
（1）可用性测试必须保证一段时间的连续运行，通过编写应用程序增大压力测试的幅度，可以适当缩短连续测试时间：（2）进行可用性测试一定要选取有代表性的测试用例脚本，以便能覆盖系统的主要功能和业务流程组合：（3）必要时，可采取人为干预的方式使某些系统组件运行失效，以验证系统故障恢复能力和组件运行的独立性。 |
|
链接测试 |
||
|
表单测试 |
||
|
性能 |
客户端测试 |
（1）性能测试时必须保证系统一段时间的连续运行，按照交易所系统的业务特征，至少一轮测试保证连续1天的运行时间：（2）利用IBMRationalRobot测试工具录制测试脚本，必要时编写测试程序模拟交易员终端发送报单报文，实现自动并发测试：（3）为验证系统可能存在性能问题的关键点，必要时需要开发商协助在应用中增加log，输出时间记录信息。 |
2.5.3高效测试方法
2.5.3.1用例技术说明
测试用例是对特定软件产品的详细测试描述，它涵盖了测试设计的各项要素，包括但不限于：明确的测试目标、设定的测试环境条件、预设的输入数据样本、详细的测试执行步骤、预期的测试结果以及可能使用的测试脚本。
设计与编排测试用例在软件测试环节中占据核心地位。作为测试实践的导向和强制遵循的标准，测试用例在初始阶段往往不够详尽。然而，随着测试进程的推进及软件版本的迭代更新，它们会逐渐深化并趋向完善。
对于交易所系统的交易测试，一种优化策略是将测试数据和测试脚本独立于测试案例。测试案例主要聚焦于软件产品的功能特性、业务规则以及业务流程的执行方案设计。
测试目标的设定应在规划阶段明确，兼顾资源和时间限制。测试策略应围绕目标展开，测试用例的详细程度将根据实际需求灵活调整。
测试用例应详尽涵盖核心流程与算法的所有潜在分支，特别是针对系统各功能模块，提倡提炼通用的测试元素。为此，我们将制定一套详细的测试用例，避免在每个独立案例中重复常规验证，如日期的有效性、金额的合规性以及输入字段的合法性检查，以此优化编写效率，提升用例的复用价值。
2.5.3.2测试用例设计方法
|
|
分析方法 |
分析步骤 |
|
1 |
等价类划分 |
首先，进行分类：将输入域按照具有相同特征或类似功能进行分类：然后进行抽象：在每个子类中抽象出相同特型并用实例来表征这个特性。 |
|
2 |
边界值分析法 |
首先确定输入域，定义输入边界值：然后确定输出域，定义输出边界值。 |
|
3 |
越界值分析法 |
首先根据边界分析的结果域确定越界值：然后对越界值进行等价类划分。 |
|
4 |
因果图法 |
首先，根据业务功能说明书中的输入输出条件分析出等价类，将每个输入输出赋予一个标志符：其次，将对应的输入输出之间，输入与输出之间的关系联系起来，并将其中不可能的组合情况标注成约束条件或者限制条件，形成因果图：然后，将因果图转化成判定图：最后，将判定表中的第一行作为场景划分要素，每一列可以作为依据进 |
|
|
|
行测试用例设计。 |
|
5 |
判定表驱动分析方法 |
因果图可以生成判定表，但是也可以直接使用判定表。判定表（DecisionTable）是列举和分析复合逻辑条件下多个路径的工具。主要是通过一个二维表格一目了然的将负责的逻辑结构和多种条件组合的情况表达出来。 |
|
6 |
错误推测法 |
列举程序中所有可能出现的错误和容易发现错误的地方，对它们进行分析提取场景划分要素。 |
|
7 |
功能图法 |
使用功能图形式化的表示程序的功能说明，并机械的生成功能图的测试用例。 |
|
8 |
缺值假定法 |
首先根据因果图法提取出流程进行中的关系数据正确性的关键要素：然后，对这些关键要素进行分析组合，这些组合要素可以直接作为依据进行测试用例设计。 |
|
9 |
动态黑盒测试 |
首先进行通过测试
|
京公网安备 11010802045440号
