期货交易所系统招标项目投标书 (2).doc

期货交易所系统招标项目投标书 期货交易所系统 招标项目投标书项目名称：交易所系统验收测试有限公司二零零六年六月 山东中创软件工程股份有限公司 山东我公司软件工程股份有限公司山东我公司软件工程股份有限公司山东我公司软期货交易所系统招标项目投标书目 录第1章 xx软件的优势1第2章 技术解决方案32.1 交易所系统特征分析32.1.1 业务特征32.1.2 系统特征32.2 测试内容42.3 测试策略42.4 测试标准62.4.1 测试进入准则62.4.2 测试完成准则62.4.3 验收测试通过标准62.5 测试方法与技术62.5.1 功能测试方法62.5.2 非功能测试方法102.5.3 测试用例技术102.5.4 测试工具应用142.6 关键点测试设计162.6.1 登陆、权限控制162.6.2 报单172.6.3 连续交易撮合182.6.4 集合竞价202.6.5 结算202.6.6 行情发布及通讯服务212.6.7 性能测试222.6.8 可用性测试242.6.9 安全性测试242.7 测试结果分析292.7.1 需求覆盖率分析292.7.2 缺陷趋势分析302.7.3 验收测试报告30第3章 项目实施方案323.1 我公司质量管理体系323.2 项目实施方法论323.3 项目总体目标333.4 项目实施范围343.5 测试流程及实施步骤343.5.1 测试策划363.5.2 测试设计383.5.3 测试实施393.5.4 测试评估413.6 组织架构和角色423.6.1 组织架构423.6.2 角色定义与职责423.7 项目总体计划433.7.1 进度安排433.7.2 项目交付物443.8 项目跟踪与管理453.8.1 项目周会453.8.2 数据收集与分析453.8.3 里程碑评审463.9 资源使用计划463.9.1 人员管理方法463.9.2 人员配置473.9.3 工具及硬件资源473.10 风险管理473.10.1 风险管理流程483.10.2 监控机制493.10.3 风险建议493.11 沟通管理503.11.1 沟通流程503.11.2 沟通计划513.12 配置管理523.12.1 配置管理内容523.12.2 配置管理步骤523.12.3 配置管理工具533.13 变更管理543.13.1 变更提出及批准543.13.2 变更实施543.14 质量控制553.14.1 质量检查项553.14.2 质量检查执行方法563.14.3 过程评审56第4章 面向管理的测试统计574.1 缺陷管理574.1.1 缺陷跟踪管理工具584.1.2 测试过程中的约定594.1.3 缺陷管理流程604.1.4 缺陷的分类614.2 测试过程的统计展示614.2.1 缺陷管理统计614.2.2 缺陷状态跟踪统计644.2.3 缺陷修正情况统计654.3 测试结果汇总展示664.3.1 对工作产品汇总统计664.3.2 对测试人员工作汇总统计674.3.3 对开发人员工作汇总统计674.3.4 对项目的综合分析68第5章 xx软件最佳实践经验715.1 网络拓扑图715.2 体系架构715.3 业务特点725.4 测试目标755.5 功能测试765.5.1 测试策略765.5.2 测试方法775.5.3 测试实施775.5.4 测试结果785.6 非功能测试785.6.1 测试重点785.6.2 实现模式785.6.3 测试过程795.7 测试工具795.8 项目管理795.8.1 与用户的密切合作是成功的前题795.8.2 建立有效、规范的软件测试管理体系805.8.3 建立良好的团队合作氛围815.9 强强合作，强势服务能力81第6章 报价方案82vxx有限公司 期货交易所系统招标项目投标书第1章 xx软件的优势xx软件公司一直致力于项目管理的开展、推广和完善工作，积累了丰富的项目管理经验。在软件过程能力方面，xx软件形成了符合iso9000、cmm、cmmi要求的质量控制体系，并于2003年8月通过qai组织的cmm咨询和3级评估。2004年xx软件公司与ibm合作建立国内首家基于rational/sdp的测试中心和跨区域的协作开发平台，建有ibm授权的软件测试中心。借助ibm rational/sdp成熟的技术, 使用ibm rational提供的全套软件自动化测试工具，并以rup的方法论为管理指导，实现对整个软件测试生命周期的管理，全方位的软件质量验证，为客户提供多种测试类型的服务。xx软件公司是目前国内唯一一家将国际先进的项目管理思想、cmm、rational/sdp三者有效融合到一起来保证项目成功的服务提供商。xx软件公司十分荣幸能够有机会参与 “期货交易所系统”验收测试项目的竞标，并深信我们提供的解决方案完全满足期货交易所对于“期货交易所系统”验收测试项目的需求和要求。同时，xx软件公司也希望以此次“期货交易所系统”验收测试项目为起点，与期货交易所建立一种长期的战略合作伙伴关系，共同发展、共同成长。本方案书是依据期货交易所系统招标项目需求书文件的要求考虑完成的，其核心目标是融合xx软件公司在金融业及其他行业十几年的测试经验的基础上，以xx软件公司先进的项目管理理念、测试技术和测试工具，为期货交易所系统验收测试项目提供最为高效、优质的测试服务。第2章 技术解决方案2.1 交易所系统特征分析交易所系统作为期货交易所的核心业务系统，需要全面支持以金融期货衍生品为主的期货交易所的交易、结算和管理。为了提供对交易所系统进行的验收测试服务，我们有必要对整个系统的特征进行概要分析，主要包括业务特征和系统特征两方面内容。2.1.1 业务特征期货交易采取集中市场交易，交易参与者的交易对手方都是交易所，采用标准化合约作为交易的对象，其基本特征包括：合约标准化、交易集中化、结算统一化、保证金制度化。作为遵循期货交易规则的交易所系统而言，其核心要求就是实现各项期货功能，相关的主要业务特征包括：l 交易的复杂程度高，要求容错能力强；l 风险控制是期货交易的核心，并且贯穿于整个交易的全过程；l 针对交易产生的大量数据进行处理。 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 测试完成准则测试用例设计经过同行评审和用户认可；业务需求100%覆盖；测试用例100%得到成功执行；验收测试报告得到用户签字确认。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，重复多次，看会否出错。会员合约查询16search检查手工测试或使用robot录制gui脚本验证在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确。如果可以输入多个search条件，可以同时添加合理和不合理的条件，看系统处理是否正确。成交查询、资金查询等17输入信息位置手工测试注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方。增加产品18上传下载文件检查手工测试验证上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。帮助文件下载19必填项检查手工测试应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*。手工增加合约20快捷键检查手工测试是否支持常用快捷键，如ctrl+c ctrl+v backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。进入方式、页面输入等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）利用 ibm rational robot测试工具录制测试脚本，必要时编写测试程序模拟交易员终端发送报单报文，实现自动并发测试；（3）为验证系统可能存在性能问题的关键点，必要时需要开发商协助在应用中增加log，输出时间记录信息。2.5.3 测试用例技术2.5.3.1 用例技术说明测试用例指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则。在最初测试时，一般测试用例是考虑不周全的，需要随着测试的进行和软件版本更新，逐步深入、日趋完善。针对交易所系统这样的交易的测试，较好的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的实施方案。对测试用例描述的详细和复杂程度有时难以明确要求。测试需要在给定的资源、时间条件下尽可能达成目标，我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行，测试用例的详细程度根据需要确定：对核心的复杂流程和算法，测试用例必须明细到每一步可能的分支；对系统中各个功能模块都需要的通用测试用例，可以提炼通用的测试要素，制定详细的测试用例，而不需在每个用例中重复，以节省编写时间和执行时间，提高用例的复用性。如：日期校验、金额合法性检查、输入字段合法性检查等。2.5.3.2 测试用例设计方法分析方法分析步骤1等价类划分首先，进行分类：将输入域按照具有相同特征或类似功能进行分类；然后进行抽象：在每个子类中抽象出相同特型并用实例来表征这个特性。2边界值分析法首先确定输入域，定义输入边界值；然后确定输出域，定义输出边界值。3越界值分析法首先根据边界分析的结果域确定越界值；然后对越界值进行等价类划分。4因果图法首先，根据业务功能说明书中的输入输出条件分析出等价类，将每个输入输出赋予一个标志符；其次，将对应的输入输出之间，输入与输出之间的关系联系起来，并将其中不可能的组合情况标注成约束条件或者限制条件，形成因果图；然后，将因果图转化成判定图；最后，将判定表中的第一行作为场景划分要素，每一列可以作为依据进行测试用例设计。5判定表驱动分析方法因果图可以生成判定表，但是也可以直接使用判定表。判定表（decisiontable）是列举和分析复合逻辑条件下多个路径的工具。主要是通过一个二维表格一目了然的将负责的逻辑结构和多种条件组合的情况表达出来。6错误推测法列举程序中所有可能出现的错误和容易发现错误的地方，对它们进行分析提取场景划分要素。7功能图法使用功能图形式化的表示程序的功能说明，并机械的生成功能图的测试用例。8缺值假定法首先根据因果图法提取出流程进行中的关系数据正确性的关键要素；然后，对这些关键要素进行分析组合，这些组合要素可以直接作为依据进行测试用例设计。9动态黑盒测试首先进行通过测试：确认软件至少能做什么，而不考验其能力。然后进行失败测试：纯粹为了破坏软件而设计和执行的测试案例，也称为迫使出错测试。蓄意攻击软件的薄弱环节。2.5.3.3 测试用例应用（1） 指导测试的实施在实施测试时测试用例作为测试的准则和指导，测试执行人员一定要按照用例严格按测试项目和测试步骤逐一实施测试，并将测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。根据测试用例的测试等级，每一轮迭代测试哪些用例在设计用例时都已作明确规定，测试执行时测试人员不能随意作变动。（2） 规划测试数据的准备在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。（3） 编写测试脚本的设计规格说明书为提高测试效率，软件测试应大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。（4） 评估测试结果的度量基准完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的指标。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。（5） 分析缺陷的标准通过收集缺陷，对比测试用例和缺陷数据库，分析确认是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步保障软件质量。而已有相应测试用例，则反映测试实施或变更处理过程中存在问题。（6） 测试用例的评审测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。（7） 测试用例的修改更新测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例版本一般也应随之编制升级更新。2.5.3.4 测试用例管理运用测试用例还需配备测试用例管理软件。它的主要功能有三个：第一、能将测试用例文档的关键内容，如编号、名称等自动导入管理数据库，形成与测试用例文档完全对应的记录；第二、可供测试实施时及时输入测试情况；第三、最终实现自动生成测试结果文档，包含各测试度量值、测试覆盖表和测试通过或不通过的测试用例清单列表。有了管理软件，测试人员无论是编写每日的测试工作日志、还是出软件测试报告，都会变得轻而易举。建议使用ibm rational testmanager管理测试用例。2.5.4 测试工具应用2.5.4.1 工具应用需求（1） 功能测试需求：能够进行windows环境下的功能测试，包括：l 能够实现自动化的功能/回归测试；l 能够实现大批量数据驱动情况的自动化功能测试；l 测试脚本要易学易用，便于维护。（2） 压力测试需求：能够进行各种负载环境下的压力测试，包括：l 测试不同负载时的系统响应时间；l 测试不同负载时的系统吞吐量；l 测试工具要具备提供大数据量交易事务的能力。（3） 测试管理需求：能够完成从测试计划、测试设计、测试实施、测试执行到测试结果分析、测试报告的自动生成整个测试生命周期的管理，包括：l 能够完成基于目标的测试用例的层次化的分类管理和组织管理，批量地执行一组测试用例，从而可以有效地进行自动化的回归测试；l 能够完成对自动执行测试用例和手工执行的测试用例的管理；l 能够根据实际测试执行的情况，自动的生成各种测试分析报告。2.5.4.2 功能测试自动化方案针对交易所系统的自动化功能测试，主要围绕windows图形界面、字符终端和browser界面进行测试进行。客户端可以为java,vc、vb、pb、delphi等编制的软件、各种字符终端软件或者运行浏览器microsoft explorer和netscape，通过自动录制形成测试脚本实现自动化的功能/回归测试。本节结合功能测试方法学以及的交易所测试项目的实际情况，提出了功能测试的基本步骤。（1）明确功能测试需求功能测试应该侧重于可以被直接追踪到用例或业务功能和业务规则的所有测试需求。这些测试的目标在于核实能否正确地接受、处理和检索数据以及业务规则是否正确实施。这种类型的测试基于黑盒方法，即通过图形用户界面 (gui) 与应用程序交互并分析输出结果来验证应用程序及其内部进程。（2）利用testmanager制定功能测试计划和测试用例基于系统的需求，利用testmanager可以帮助制定测试计划和测试用例。测试计划应明确测试目标、所需完成测试用例、测试里程碑和主要评测手段、所需资源和提交结果。测试用例应明确每个测试用例的测试输入、执行条件和期望结果。（3）利用robot录制测试脚本 基于测试计划和测试用例，利用robot录制测试脚本。在脚本的录制过程中应充分考虑到脚本的重用性和可维护性。灵活的组织和利用测试脚本，是成功实现软件的自动化功能测试的关键。（4）利用数据池（datapool）技术实现测试数据变化 利用testmanager的数据池（datapool）功能按需求自动形成测试数据，实现大批量数据驱动的软件功能测试和测试流程中数据的前后相关性。（5）利用testmanager执行测试用例 按照测试计划的要求，组织测试用例并和录制形成的测试脚本关联，形成便于回归测试的各种测试套件。之后，执行各种测试套件或相关测试用例。并监视测试执行情况，分析测试执行结果，改进测试用例。（6）评估测试报告 testmanager会自动记录功能测试的结果并生成各种类型的测试报告，测试人员可以通过这些测试数据来生成各种测试报告和测试结果。2.5.4.3 性能测试方案（1） 明确性能测试需求在进行性能测试之前，需要根据系统的性能需求明确描述性能测试的目标。（2）确定系统的负载模型性能测试的关键是模拟系统的真实负载。为此，我们通过如下手段获得系统的负载模型：从最终使用人员获得操作情况，如经常进行的业务类型、业务操作的频率；根据系统日志，可以获得每日所进行的各种业务类型和业务量；通过和系统测试人员、操作人员、系统架构师充分沟通和配合，形成如下的系统负载模型：基于transactor建立基于目标的负载模型；基于senario模拟不同的业务操作流程的负载模型；基于selector模拟人的随机操作或选择的行为的负载模型；基于synchronize point和delay等协调不同脚本或不同的业务操作间的执行顺序，建立基于时间表的负载模型；基于event和event dependence，建立基于事件触发确定脚本执行顺序的负载模型。（3）用robot录制测试脚本利用robot录制负载模型中列出的各种业务，自动生成测试脚本。（4） 利用数据池（datapool）技术实现测试数据变化利用testmanager的数据池（datapool）功能按需求自动形成测试数据，并且不用编写任何代码就能实现在测试执行时不同用户使用不同的数据访问系统，保证性能测试的真实性。（5） 利用testmanager创建测试执行计划测试执行计划是基于录制形成的测试脚本，模拟各种业务，实现负载模型的过程。（6） 测试执行testmanager可以根据指定的总用户数自动调整每个角色的用户，并可以监视执行情况。（7） 评估测试报告testmanager会自动记录性能测试的结果并生成各种类型的测试报告，测试人员可以通过这些测试数据来分析系统的性能瓶颈所在。2.6 关键点测试设计2.6.1 登陆、权限控制根据系统需求，会员、交易员、操作员等多种角色均可登录访问系统。针对多种角色，设置不同角色组，并对登录者进行操作角色设置，以保证系统的安全性和保密性。（1）用例设计要求至少应包括两个不同的权限角色组、两个以上操作角色及多个登录者；权限角色组权限不同，但允许有相重部分；同一操作角色可属于一个或多个权限角色组；根据登录者身份不同，进行操作角色的提定；包括相关功能新增、修改、删除操作。据用例设计，操作相应的功能模块，建立相关的权限角色组、操作角色及登录者。（2）分别以建立的登录者登录系统，验证是否能够正常登录，验证其所属操作角色是否与用例相符，验证其权限是否与操作角色所属的权限角色组权限相一致。验证登录者退出系统时是否能够正常执行，且退出后不再具有任何访问权限。（3）修改某一权限角色组权限，验证对应的操作角色权限功能是否同时得到修改，修改内容是否一致。（4）修改某一操作角色权限，验证其对应的登录者权限是否同时得到修改，修改内容是否一致。（5）删除某一权限角色组，验证与其相关的操作角色对应权限是否正确处理。（6）删除某一操作角色，验证与其相关的登录者是对应权限否正确处理。（7）利用工具验证多登录者并发登录系统时是否会产生权限错乱，如权限增加或减少、登录者操作角色错乱等；利用工具验证多登录者并发退出系统时，是否存在退出不成功现象。2.6.2 报单根据系统需求，报单即普通委托，其成交与否受价格相关、时间相关、成交量相关等执行条件的约束，并可设置相关的触发条件（止损）；报单成交后，将会对结算系统产生影响。（1）用例设计：要求充分考虑以下各种条件要求及相关的组合，确保设计用例覆盖所有的业务分支，与实际业务情况相符。a) 根据期货交易规则，确定委托条件所有可能的组合，用例设计时要求覆盖所有的组合；b) 对每一合约要求多张对应的报单，并包含净持仓会员综合持仓会员、开仓平仓平今仓、投机保值等各类属性的组合；c) 对每一报单对应的合约价格，要求包含正常价、达到涨停板价格、超过涨停板价格、低于最小变动价位等多种情况，并考虑金额边界值情况（零值、负值、最大值等）；d) 对于每一报单对应的成交量，要求包含正常数量、超过会员仓位限制、超过合约仓位限制等多种情况 ，并考虑数量边界值情况（零值、负值、带小数位数值等）；e) 考虑报单的增加、修改、撤销、挂起、激活等操作。（2）报单录入：按测试用例设计，进行报单录入。主要验证申报数量及申报价格的有效性，及录入后数据的正确性。（3）报单修改：按测试用例，对报单可修改属性进行修改，验证修改后数据正确性；验证对报单非可修改属性进行修改时，是否是取消现有报单并输入新报单，而非直接修改原报单。验证减少报单数量时，委托时间戳不变；验证增加报单数量及改变价格时，整个报单会是到新的时间戳。（4）报单撤销：验证是否可以对委托簿中所存的报单进行删除，删除是否正确；验证交易所在交易停顿或熔断器熔断时，是否可以进行报单取消，操作是否正确；验证已成交报单不可撤销；验证报单撤销后不再参与交易行为；验证报单撤销后会通知会员终端。（5）报单挂起：验证委托簿中的报单可以执行挂起指令，且执行结果正确；验证已挂起的报单不再参与撮合，所冻结的资金和持仓被释放；验证交易所在交易停顿或熔断器熔断时，是否可以进行报单挂起，操作是否正确。（6）报单激活：验证已挂起的报单可以执行激活指令，验证激活时是否重新进行合法性验证，是否能识别出不合法报单；验证未挂起报单不需要执行激活指令。2.6.3 连续交易撮合根据系统需求，在连续交易阶段，每输入一笔报单，交易系统根据价格优先时间优先的原则，立即判断它是否成交；存在全部成交、分成几笔成交、部分成交、完全不成交多种情况；未成交的剩余申报在申报库以价格优先时间优先的原则排队等候。（1）用例设计：要求充分考虑以下各种条件要求及相关的组合，确保设计用例覆盖所有的业务分支，与实际业务情况相符。a) 根据价格优先时间优先的原则，设计用例应包含成交价相同但时间不同的情况。b) 系统成交价确定原则为中间价原则，即取买入价（bp）、卖出价（sp）、前一成交价（cp）三者之中间的价格，设计用例时，涉及的报单中合约价格应覆盖bpspcp、bpcpsp、cpbpsp三种情况。c) 分析满足撮合成交价但交易数量有差异情况，设计用例覆盖全部成交、分成几笔成交、部分成交、完全不成交多种情况。d) 分析不满足撮合成交价，但存在交易数量情况，设计用例进入申报库排队等候。e) 考虑撮合不成功条件：如撤销报单、出现涨跌停析、会员保证金不足、会员被注销或暂停、交易数量超过持仓限额等异常情况。（2）按测试用例设计要求，进行报单录入，并根据每一报单设计目的，进行相关验证。a） 验证第一笔交易成交时，是否取上日结算价作为前一成交价，取值是否正确。b） 验证两笔报单同时满足成交价时，是否按时间优先的原则进行成交数量分配。c） 验证分成几笔成交时，每笔成交数量之和是否与报单交易数量相符。d） 验证部分成交时，剩余交易数量是否正确，未能成交的剩余申报是否进入申报库.e） 验证完全不成交时，剩余交易数量是否与申报单交易数量相符，该申报单是否进入申报库。f） 验证完全成交、分几笔成交、部分成交时，是否通知会员，通知信息是否正确。2.6.4 集合竞价根据系统需求，集合竞价包括集合竞价报单、集合竞价价格平衡、集合竞价撮合三个子状态，每一子状态均遵循最大成交量、最小剩余量、剩余量多空方反转、中间价原则；合约在不同状态下具有不同的报单行为。（1）用例设计：要求充分考虑以下各种条件要求及相关的组合，确保设计用例覆盖所有的业务分支，与实际业务情况相符。a) 测试用例设计时，设计的相关报单应满足各项成交原则要求，即覆盖最大成交量原则、最小剩余量原则、剩余量多空方反转原则及中间价原则。b) 考虑在集合竞价报单状态中，插入、修改、撤销、挂起、激活限价报单和止损单时，对产生理论集合价的影响。c) 考虑在集合竞价价格平衡状态中，插入、激活限价报单时，对产生理论集合价的影响。（2）验证合约进入集合竞价状态时，是否自动进入集合竞价报单子状态，并根据测试用例设计要求进行报单录入；验证根据某一成交原则（如最大成交量原则），系统产生的理论集合价是否正确。a） 在集合竞价报单状态时，验证是否能够对相关限价报单和止损单进行插入、修改、撤销、挂起及激活操作；进行相应操作时，是否对产生的理论集合价产生影响；当产生影响时，验证新的理论集合价是否正确。b） 在集合竞价价格平衡状态时，验证是否能够对相关限价报单和止损单进行插入、激活操作；验证进行相应操作时，是否对产生的理论集合价产生影响；当产生影响时，验证新的理论集合价是否正确；验证在该状态下，是否拒绝报单修改、撤销及挂起操作。c） 在集合竞价撮合状态时，验证是否拒绝报单和止损单的任何操作。2.6.5 结算根据系统需求，会员管理、客户管理、合约管理、资金管理、保证金管理、报单管理及撮合等均对系统结算产生影响，并且结算结果也会对相关的功能模块产生新的影响。（1）用例设计：要求考虑到结算涉及业务的多面性及对业务影响的多面性，用例设计时，需要从数据源头（例合约、会员、客户等）；同时考虑结算在其他功能完成后进行的业务特点，可以以其他功能模块组织的测试用例为依据，组织进行结算时所需的各项数据。（2）根据实际情况需要及各相关功能模块用例组织要求，重新整理相关测试用例，注重相关功能之间的业务关联性。并进行相关用例的录入操作。（3）根据系统相关运算规则或其他要求，对录入的数据进行计算，得出正确的结算数据。（4）在执行进结算操作前，对结算价等相关参数进行验证，确认结算价取值正确。（5）手工执行进行结算业务，验证结算功能是否能够正常进行，验证结算结果与用例中计算结果相一致。（6）结算业务完成后，验证与会员相关数据能够正确反馈。2.6.6 行情发布及通讯服务根据系统需求，系统存在对话、私有、广播三种通讯模式；通过对话通讯模式完成会员端主动发起的通讯请求，如报单、查询等；通过私有通讯模式完成交易所端主动向特定会员发出的信息，如成交回报等；通过广播通讯模式完成交易所端主动向市场中所有会员发出相同信息，如市场公告、行情等。（1）用例设计：要求能够覆盖对话、私有、广播三种通讯模式涉及的相关业务，如报单、查询、成交回报、市场公告、行情等。针对某一会员，考虑三种通讯模式同时存在的情况。交易所端用例准备还应包括行情发布主题及行情发布主题信息的管理。（2）根据用例设计情况，由会员执行报单查询操作，验证会员端主动发起通讯请求时，系统处理正常，同时验证返回的报单信息完整、正确。（3）模拟报单成交业务，验证某一报单成交时，由交易所端主动向特定会员发出信息时，系统处理正常，验证所发目标会员与报单所属会员相一致，验证成交信息完整、正确。（4）验证由交易所端主动向所有会员发出相同信息时，系统处理正常，验证所有会员收到信息相同，验证所发送信息的完整性及正确性。（5）验证在网络发生故障时，如网络断开时，是否能够直接断开连接；网络重新连接时，验证私有模式和广播模式是否从上次断开连接的地方继续接收。（6）验证交易所系统主动发出强制退出报文时，是否能够执行断开连接操作，会员端是否能够继续执行通讯操作。（7）验证交易所端增加发布主题后，能够正常显示；验证增加发布主题后，能够增加相应的发布主题信息，且显示正确；验证发布主题信息修改后，能够及时正确地在显示页面得到显示；验证发布主题删除后，其下对应的发布主题信息是否同时删除或不再显示。2.6.7 性能测试（1） 制定性能测试计划，要求至少迭代测试4次，至少1次不间断运行24小时。 （2） 配置测试环境，要求实际测试时用户提供与生产环境类似的性能测试环境。（3） 利用robot录制新建客户、注销客户、修改客户信息等功能，自动运行脚本，使系统客户数量逐步增长。同时验证随着客户数的增长，交易系统在具有一定客户量的前提下各种处理能力，从而验证系统能支持的最大客户数。（4） 分析交易系统在新增加一个接入点时所需要的资源，包