基于改进因果图法的CBTC系统车载功能测试方案研究
Ｖｏｌ．２８Ｎｏ．１２
Ｄｅｃ．２０１２
赤峰学院学报（自然科学版）ＪｏｕｒｎａｌｏｆＣｈｉｆｅｎｇＵｎｉｖｅｒｓｉｔｙ（ＮａｔｕｒａｌＳｃｉｅｎｃｅＥｄｉｔｉｏｎ）第２８卷第１２期（上）
２０１２年１２月由于国内经济的不断快速发展，大型城市以及中型城市正逐步的扩建，城市面临着人口不断增加以及城市占地面积扩大的问题［１］．为了保证城市轨道交通能够更加安全、效率地运行，于是各个城市的轨道交通建设放弃选择使用原有的基于轨道电路的列车控制系统（ＴＢＴＣ），而采用最新的列车控
制系统基于通信的列车控制系统（ＣＢＴＣ）［２］
．
在现有的城市轨道交通系统中很多都采用了ＣＢＴＣ系统，但是很多城市地铁都出现过大大小小的事故［３］．在ＣＢＴＣ系统中，车载设备保证着列车的安全行驶，系统功能都需要通过车载设备才能实现
［４］
．因此完成ＣＢＴＣ系统测试中重要的一个环节就
是对列车的车载设备进行调试［５］．
本研究系统根据新一代的ＣＢＴＣ系统设计理
念，利用车载设备的测试软件进行车载设备的测试．通过测试软件，观察车载控制器内的数据变化，对测试参数的具体分析，最后基于工程实践的经验，对ＣＢＴＣ系统测试用例进行设计．1
CBTC 系统概述
在ＣＢＴＣ系统下，车—地双向实时数据的传输采用的是无线通信的手段［６］．列车不再是单一地接收地面传到车载设备的控制信息，列车还需将列车的位置信息和列车的运行信息及时反馈给地面设备［７］．地面设备通过得到的列车信息计算出列车的移动授权（ＭｏｖｉｎｇＡｕｔｈｏｒｉｔｙ下面简称ＭＡ），并且动态更新，将移动授权通过车—地通信网络传输到车
载设备［８］．车载设备根据收到的移动授权信息和当前列车的运行状态，计算出列车的运行速度曲线，控制列车的牵引、制动与运行［９］．2
因果图法简述
ＣＢＴＣ系统下的车载设备将接收的信息来自区域控制器ＺＣ、ＡＴＳ系统、地面信标和计算机连锁ＣＩ，同时需要将处理的信息反馈给各系统，其中的之间的逻辑关系非常复杂［１０］．为了避免输入条件之间的彼此结合导致新的状况出现而带来检查方面的困难，因此如何设计测试用例，可以在测试手段的选取上采用一种形式，满足描述多条件组合，且产生对应多动作．这要求我们对测试用例的设计时采取因果图法．２．１因果图法原理
因果图模型中有两类主要部分的因果图参数和结构，如图１所示：
其中字母Ｂ表示基本事件，即不需探究自身
基于改进因果图法的ＣＢＴＣ系统车载功能测试方案研究
张佳莹，曲
娜，郑伟南，卫昱含
（吉林建筑工程学院
城建学院，吉林长春
１３０１１１）
摘
要：随着ＣＢＴＣ系统被越来越广泛地应用到轨道交通建设中，对其功能上的测试也越来越严
格．本文针对车载设备的测试方法和具体的测试案例进行研究，
选取以因果图法为主体的改进方法对测试进行指导工作，重点研究了因果图法中由因果图转化为判定表的条件遍历算法，并选取了车载ＡＴＰ超速防护的功能为例，对车载设备系统的测试应用中，通过对改进后的因果图法而进行研究．测试结果证明了本研究系统的所提出的测试方案具有实际可行意义，可以将该方案推广起来．
关键词：ＣＢＴＣ系统；功能测试；车载设备；测试方案中图分类号：ＴＰ２７３＋．５
文献标识码：Ａ
文章编号：１６７３－２６０Ｘ（２０１２）１２－００２３－
０３
图１因果图模型
２３－－
工程项目管理系统测试方案
工程项目管理系统测试 方案 标准化管理处编码[BBX968T-XBB8968-NNJ668-MM9N]
工程项目管理系统测试方案 （模块测试阶段） 1.试用人员账号信息
2.人员分工 3.测试项目
4.测试用例（其他分公司按照潍坊公司用例进行，只需要更改项目编号和名称）潍坊公司用例一（分成多个任务的情况） （1）立项 项目编号：07TWF2SB0001 项目名称：潍坊电信昌乐机房改造工程 项目经理：朱汇川 项目类型：设备工程 项目概况：潍坊电信昌乐机房改造工程（介绍项目的情况） 立项时间：2007-08-01
（2）任务分解 01：领料 计划开始时间：2007-08-01 计划结束时间：2007-08-02 任务描述：到电信仓库领取工程用料（可以根据情况自由填写）02：施工 计划开始时间：2007-08-03 计划结束时间：2007-08-08 任务描述：工程施工（可以根据情况自由填写） 03：验收 计划开始时间：2007-08-09 计划结束时间：2007-08-09 任务描述：工程验收（可以根据情况自由填写） （3）计划 领料阶段人力计划：张三 领料阶段材料计划：电力电缆：RVV1-16 20M 甲方提供 电力电缆：RVV1-25 20M 甲方提供 电力电缆：RVV1-35 20M 甲方提供
电力电缆：RVV1-50 20M 甲方提供 交流排：5个单价40元/个自购 光纤跳线：单模一米 20条 20元/条自购领料阶段成本计划：计划材料费：自动生成 计划工作和福利费：自动生成 计划折旧费：100 计划办公费：100 计划差旅费：0 计划车辆使用费：100 计划费用合计：自动生成 施工阶段人力计划：张三、李四 施工阶段材料计划： 施工阶段成本计划：计划材料费：自动生成 计划工作和福利费：自动生成 计划折旧费：100
因果图测试用例
1.引言 等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系、相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（逻辑模型）。 因果图（Cause-Effect Graphing）提供了一个把规格转化为判定表的系统化方法，从该图中可以产生测试数据。其中原因是表示输入条件，结果是对输入执行的一系列计算后得到的输出。 因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。 2.因果图介绍 2.1图例说明 1、4种符号分别表示了规格说明中向4种因果关系。如图2-1所示。 图2-1 因果图关系 2、因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。 3、ci表示原因，通常置于图的左部；ei表示结果，通常在图的右部。ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现。 2.2因果图概念 1、关系（图2-1 因果图关系） ①恒等：若ci是1，则ei也是1；否则ei为0。 ②非：若ci是1，则ei是0；否则ei是1。
③或：若c1或c2或c3是1，则ei是1；否则ei为0。“或”可有任意个输入。 ④与：若c1和c2都是1，则ei为1；否则ei为0。“与”也可有任意个输入。 2、约束 输入状态相互之间还可能存在某些依赖关系，称为约束。例如，某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中，用特定的符号标明这些约束。如图2-2所示。 图2-2因果图约束 .输入条件的约束有以下4类： ①E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。 ②I约束（或）：a、b和c中至少有一个必须是1，即a、b 和c不能同时为0。 ③O约束（唯一）；a和b必须有一个，且仅有1个为1。 ④R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。 B.输出条件约束类型 输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。 2.3因果图法设计测试用例步骤 1、分析待测得系统规格，找出原因与结果 分析软件规格说明描述中，那些是原因(即输入条件或输入条件的等价类)，那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。 2、画出因果图
信息系统项目测试方案
信访局网上信访信息系统项目 系统测试方案 2015年7月 太原新汇科计算机有限公司 Taiyuan New Quick Com puter Co.,LTD 本文档及其所含信息为机密材料 并且由晋中市及所辖各县（市、区）信访局和太原新汇科计算机有限公司共同拥有。 文档中任何部分未经晋中市及所辖各县（市、区）信访局和太原新汇科计算机有限公司书面授权，不得泄露给第三方，也不得以任何手段、任何形式进行复制与传播
目录 1概述 (1) 1.1目标 (1) 1.2假设 (1) 1.3测试范围 (2) 1.4测试方法 (2) 1.5测试步骤 (3) 1.6测试进入准则 (3) 1.7测试结束准则 (4) 2测试地点、人员与环境 (4) 2.1测试的地点和人员 (4) 2.2测试环境 (4) 3组织结构 (5) 3.1组织结构 (5) 3.2职责范围 (5) 4计划任务与时间 (6) 4.1计划任务 (6) 4.2时间表 (7) 4.3安排 (8) 4.4测试更新安排 (13) 5人员的岗位职责 (13) 6缺陷管理 (15) 6.1缺陷管理流程 (15) 6.2缺陷的严重度和修改的优先级（此问题请见测试报告） (18) 7测试报告总结和分析 (20)
1概述 《山西省网上信访信息系统测试方案》（以下简称《测试方案》）是山西省网上信访信息系统编码、单元测试完成后，在进行系统测试之前，针对优化版的业务功能进行功能和集成测试的计划安排。 《测试方案》主要明确系统功能和集成测试的有关规定和原则，其目的是提供系统功能和集成测试所依据和遵循的原则、方法和组织结构。 1.1目标 用户测试阶段应达到并完成以下的主要目的与任务： 目的在于检查优化需求版系统功能能否满足实际业务要求，流程是否符合各级信访机构日常业务程序。 对系统的业务功能进行测试，以验证是否达到了用户设计的业务要求，保证产品能够满足客户的业务需求。（这里的业务需求指的是《山西省网上信访信息系统需求规格说明书》、《山西省网上信访信息系统需求变更》、《山西省网上信访信息系统需求深化》、《山西省网上信访信息系统需求补充》） 对系统存在的业务及功能错误进行纠错，保证系统运行的正确性。 1.2假设 假设有足够容量的服务器资源。 假设有足够的测试工作站设备。 假设人员可以分班轮流，一个实际工作日能够测试多于一个的测试营业日。
测试用例设计方法之因果图法
测试用例设计方法之因果图法 (一)因果图法的来源 大家熟悉的等价类划分法和边界值分析法，都是着重考虑输入条件，但未考虑输入条件之间的联系、相互组合等； 但是，如考虑所输入条件之间的相互组合，会由于组合情况数目相当大，需要大量的测试用例； 因果图法，是一种帮助人们系统地选择一组高效率测试用例的方法。(二)因果图法的特点 考虑输入条件间的组合关系； 考虑输出条件对输入条件的信赖关系，即因果关系； 测试用例发现错误的效率高； 能检查出功能说明中的某些不一致或遗漏； 因果图方法最终生产的就是判定表，它适合于检查程序输入条件和各种组合情况。 (三)因果图法基本步骤 1.分割功能说明书 对于规模比较大的程序来说，由于输入条件的组合数太大，所以很难整体上使用一个因果图。我们可以把它划分为若干部分，然后分别对每个部分使用因果图。例如，测试编译程序时，可以把每个语句作为一个部分。 2.识别出“原因”和“结果”，并加以编号 所谓原因，是指输入条件或输入条件的等价类；而结果则是指输出条件或输出条件的等价类。每个原因或结果都对应于因果图中的一个节点。当原因或结果成立（或出现）时，相应的节点取值为1，否则为0。 例如，有一个饮料自动售货机（处理单价为5角钱）的控制处理软件，它的软件规格说明如下： 若投入5角钱的硬币，按下“橙汁”或“啤酒”的按钮，则相应的饮料就送出来。若投入1元钱的硬币，同样也是按“橙汁”或“啤酒”的按钮，则自动售货机在送出相应饮料的同时退回5角钱的硬币。
分析这一段说明，我们可以列出原因和结果。 原因如下： ?投入1元硬币； ?投入5角硬币； ?按下“橙汁”按钮； ?按下“啤酒”按钮 结果 ?退还5角钱； ?送出“橙汁”饮料； ?送出“啤酒”饮料 3.根据功能说明书中规定的原因和结果之间的关系画出因果图 因果图的基本符号如图1所示： 1.因果图的基本符号 图中左边的节点表示原因，右边的节点表示结果。恒等、非、或、与的含义： ?恒等：若a=1，则b=1；若a=0，则b=0； ?非：若a=1，则b=0，若a=0，则b=1； ?或：若a=1或b=1或c=1，则d=1；若a= b= c=0，则d=0； ?与：若a= b= c=1，则d=1；若a=0或b=0或c=0，则d=0。 画因果图时，原因在左，结果在右，由上而下排列，并根据功能说明书中规定的原因和结果之间的关系，用上述基本符号连接起来。在因果图中还可以引入一些中间节点。
鱼骨图分析法(又名因果图)
鱼骨图Cause & Effect/Fishbone Diagram 第1章概念与来源 鱼骨图又名特性因素图是由日本管理大师石川馨先生所发展出来的，故又名石川图。鱼骨图是一种发现问题“根本原因”的方法，它也可以称之为“因果图”。鱼骨图原本用于质量管理。 问题的特性总是受到一些因素的影响，我们通过头脑风暴找出这些因素，并将它们与特性值一起，按相互关联性整理而成的层次分明、条理清楚，并标出重要因素的图形就叫特性要因图。因其形状如鱼骨，所以又叫鱼骨图（以下称鱼骨图），它是一种透过现象看本质的分析方法，又叫因果分析图。同时，鱼骨图也用在生产中，来形象地表示生产车间的流程。下图为鱼骨图基本结构： 一般可转化为三种类型： A、整理问题型鱼骨图（各要素与特性值间不存在原因关系，而是结构构成关系,对问题进行结构化整理） B、原因型鱼骨图（鱼头在右，特性值通常以“为什么……”来写） C、对策型鱼骨图（鱼头在左，特性值通常以“如何提高/改善……”来写） 第2章应用场景 鱼骨图常用于查找问题的根因时使用，如对于现场客户的需求进行分析整理时可使用该工具分析用户的本质需求。 第3章使用步骤 制作鱼骨图分两个步骤：分析问题原因/结构、绘制鱼骨图。 分析问题原因/结构
A、针对问题点，选择层别方法（如人机料法环测量等）。 B、按头脑风暴分别对各层别类别找出所有可能原因（因素）。 C、将找出的各要素进行归类、整理，明确其从属关系。 D、分析选取重要因素。 E、检查各要素的描述方法，确保语法简明、意思明确。 分析要点： a、确定大要因（大骨）时，现场作业一般从“人机料法环”着手,管理类问题一般从“人事时地物”层别，应视具体情况决定； b、大要因必须用中性词描述（不说明好坏），中、小要因必须使用价值判断（如…不良）； c、脑力激荡时，应尽可能多而全地找出所有可能原因，而不仅限于自己能完全掌控或正在执行的内容。对人的原因，宜从行动而非思想态度面着手分析； d、中要因跟特性值、小要因跟中要因间有直接的原因-问题关系，小要因应分析至可以直接下对策； e、如果某种原因可同时归属于两种或两种以上因素，请以关联性最强者为准（必要时考虑三现主义：即现时到现场看现物，通过相对条件的比较，找出相关性最强的要因归类。） f、选取重要原因时，不要超过7项，且应标识在最未端原因； 绘制鱼骨图 鱼骨图做图过程一般由以下几步组成： 1．由问题的负责人召集与问题有关的人员组成一个工作组(work group)，该组成员必须对问题有一定深度的了解。 2．问题的负责人将拟找出原因的问题写在黑板或白纸右边的一个三角形的框内，并在其尾部引出一条水平直线，该线称为鱼脊。 3．工作组成员在鱼脊上画出与鱼脊成45°角的直线，并在其上标出引起问题的主要原因，这些成45°角的直线称为大骨。 4．对引起问题的原因进一步细化，画出中骨、小骨……，尽可能列出所有原因 5．对鱼骨图进行优化整理。 6．根据鱼骨图进行讨论。完整的鱼骨图如图2所示，由于鱼骨图不以数值来表示，并处理问题，而是通过整理问题与它的原因的层次来标明关系，因此，能很好的描述定性问题。鱼骨图的实施要求工作组负责人(即进行企业诊断的专家)有丰富的指导经验，整个过程负责人尽可能为工作组成员创造友好、平等、宽松的讨论环境，使每个成员的意见都能完全表达，同时保证鱼骨图正确做出，即防止工作组成员将原因、现象、对策互相混淆，并保证鱼骨图层次清晰。负责人不对问题发表任何看法，也不能对工作组成员进行任何诱导。 鱼骨图使用步骤 (1)查找要解决的问题； (2)把问题写在鱼骨的头上； (3)召集同事共同讨论问题出现的可能原因，尽可能多地找出问题； (4)把相同的问题分组，在鱼骨上标出； (5)根据不同问题征求大家的意见，总结出正确的原因；
(完整版)xx项目_集成测试方案和计划
项目编号： XX项目 集成测试方案和计划 V1.0 XX项目组 XX年X月
修订文档历史记录
目录 1引言 (1) 1.1编写目的 (1) 1.2定义 (1) 1.3参考资料 (1) 2测试目标 (1) 3测试范围 (1) 4职责分工 (2) 5测试标准 (2) 5.1启动准则 (2) 5.2结束准则 (3) 5.3暂停和再启动准则 (3) 6测试策略 (3) 6.1集成策略 (3) 6.2缺陷管理 (4) 6.3信息安全策略 (4) 7测试方法 (5) 8测试环境 (5) 8.1软/硬件环境 (5) 8.2环境差异说明 (5) 8.3测试数据准备 (5) 9测试工作安排 (6) 10测试内容及测试案例 (6) 10.1功能测试 (6) 10.2性能测试 (7) 10.3压力测试 (7) 10.4安全测试 (7) 10.5故障和异常测试 (7) 10.6测试用例 (7)
1引言 1.1 编写目的 本文档是“xxx”项目的集成测试方案和计划。文档中对本测试的人员安排、进度安排、测试环境、测试方法及前期准备都进行了详细的说明，旨在对该系统的集成测试有一个总体指导。 文档使用者是本文主要的读者对象,包括项目负责人，集成测试负责人，集成测试设计师、测试人员及本次测试其它相关人员。 1.2 定义 集成测试：集成为一个系统或子系统的组件组的测试。 1.3 参考资料 《xx项目_业务需求说明书.doc》 《xx项目_需求分析说明书.doc》 2测试目标 系统内部各单元模块及子系统之间能够正常的协调运作，系统能够正常满足全部的功能性和非功能性需求。 3测试范围
信息系统项目测试实施方案
信息系统项目测试实施方案
————————————————————————————————作者：————————————————————————————————日期：
信访局网上信访信息系统项目 系统测试方案 2015年7月 太原新汇科计算机有限公司 Taiyuan New Quick Com puter Co.,LTD 本文档及其所含信息为机密材料 并且由晋中市及所辖各县（市、区）信访局和太原新汇科计算机有限公司共同拥有。 文档中任何部分未经晋中市及所辖各县（市、区）信访局和太原新汇科计算机有限公司书面授权，不得泄露给第三方，也不得以任何手段、任何形式进行复制与传播
目录 1概述 (1) 1.1目标 (1) 1.2假设 (1) 1.3测试范围 (2) 1.4测试方法 (2) 1.5测试步骤 (3) 1.6测试进入准则 (3) 1.7测试结束准则 (4) 2测试地点、人员与环境 (4) 2.1测试的地点和人员 (4) 2.2测试环境 (4) 3组织结构 (5) 3.1组织结构 (5) 3.2职责范围 (5) 4计划任务与时间 (6) 4.1计划任务 (6) 4.2时间表 (7) 4.3安排 (8) 4.4测试更新安排 (13) 5人员的岗位职责 (14) 6缺陷管理 (16) 6.1缺陷管理流程 (16) 6.2缺陷的严重度和修改的优先级（此问题请见测试报告） (18) 7测试报告总结和分析 (20)
1概述 《山西省网上信访信息系统测试方案》（以下简称《测试方案》）是山西省网上信访信息系统编码、单元测试完成后，在进行系统测试之前，针对优化版的业务功能进行功能和集成测试的计划安排。 《测试方案》主要明确系统功能和集成测试的有关规定和原则，其目的是提供系统功能和集成测试所依据和遵循的原则、方法和组织结构。 1.1目标 用户测试阶段应达到并完成以下的主要目的与任务： 目的在于检查优化需求版系统功能能否满足实际业务要求，流程是否符合各级信访机构日常业务程序。 对系统的业务功能进行测试，以验证是否达到了用户设计的业务要求，保证产品能够满足客户的业务需求。（这里的业务需求指的是《山西省网上信访信息系统需求规格说明书》、《山西省网上信访信息系统需求变更》、《山西省网上信访信息系统需求深化》、《山西省网上信访信息系统需求补充》） 对系统存在的业务及功能错误进行纠错，保证系统运行的正确性。 1.2假设 假设有足够容量的服务器资源。 假设有足够的测试工作站设备。 假设人员可以分班轮流，一个实际工作日能够测试多于一个的测试营业日。
测试用例设计 自动售货机因果图分析
实验三黑盒测试（二） 一、实验目的 通过本实验，掌握因果图法生成测试用例的步骤。 二、相关内容 利用因果图生成测试用例的基本步骤如下： （1）分析软件规格说明中哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。 （2）分析软件规格说明中的语义，找出原因与结果之间、原因与原因之间对应的关系，根据这些关系画出因果图。 （3）由于语法或环境的限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。 （4）把因果图转换为决策表。 （5）根据决策表中的每一列设计测试用例。 三、实验内容 有一个处理单价为5 角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：若投入5 角钱或1 元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1 元硬币并押下按钮后，饮料不送出来而且1 元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5 角硬币。 编写程序实现之，然后用因果图法对自动售货机设计测试用例并测试之。 要求： 1、编写程序，实现上述自动售货过程。（任选一种自己熟悉的语言，有无界面均可，实现相应的功能即可。） 2、用因果图法设计测试用例。 （1）正确画出因果图。（2）画出决策表。（3）给出测试用例。 提示：可按如下步骤进行： 1）分析这一段说明，列出原因和结果。 2）画出因果图。（所有原因结点列在左边，所有结果点列在右边。可以考虑建立中间结点，表示处理的中间状态。比如，可设如下几种中间状态：该找5 角，可找5 角，按下按钮、钱已付清） 3）画出决策表。 4）给出测试用例。 四、实验报告 实验报告提交内容：源程序清单、因果图、决策表。（测试用例有时间就设计，没有时间可以不设计） 一，因果图；
以中国象棋中走马的测试用例设计为例学习因果图的使用方法
以中国象棋中走马的测试用例设计为例学习因果图的使用方法。 分析中国象棋中走马的实际情况（下面未注明的均指的是对马的说明） 1如果落点在棋盘外，则不移动棋子； 2、如果落点与起点不构成日字型，则不移动棋子； 3、如果落点处有自己方棋子，则不移动棋子； 4、如果在落点方向的邻近交叉点有棋子（绊马腿），则不移动棋子； 5、如果不属于1-4条，且落点处无棋子，则移动棋子； 6、如果不属于1-4条，且落点处为对方棋子（非老将），则移动棋子并除去对方棋子； 7、如果不属于1-4条，且落点处为对方老将，则移动棋子，并提示战胜对方，游戏结束。原因：结果： 1、落点在棋盘上； 2、落点与起点构成日字； 3、落点处为自己方棋子； 4、落点方向的邻近交叉点无棋子； 5、落点处无棋子； 6、洛点处为对方棋子（非老将）； 7、洛点处为对方老将。21、不移动棋子； 22、移动棋子； 23、移动棋子，并除去对方棋子； 24、移动棋子，并提示战胜对方，结束游戏。 L2345678 111110000 2]101I00 3L3101c10 11111100 2200001 2101000 23（.1010] 测试 用例 A3 A8 AR A? R5 B4 RN ur Cl X6 SD PS 考虑结果不能同时发生，所以对其施加唯一约束施加异约束E。 根据因果图建立判定表：（分为两表）0。原因5、6、7不能同时发生，所以对其 添加中间节点11，目的是作为导出结果的进一步原因，简化因果图导出的判定表
注：1、以上判定表中由于表格大小限制没有列出最后所选的测试用例；2、第2表中部分列被合并表示不可能发生的现象；3、通过中间节点将用例的判定表简化为两个小表。减少工 作量。 四、根据判定表写测试用例表（略）
系统测试方案
企业资源过程控制管理系统建设项目 系统测试方案
目录 1.概述 (3) 1.1编写背景 (3) 1.2读者对象 (3) 2.测试方案 (4) 2.1测试模块及部门 (4) 2.2测试数据 (5) 2.3测试策略 (5) 2.4测试人员 (6) 2.5测试计划 (7) 2.6测试跟踪 (8) 2.7测试通过准则 (8) 2.8测试技术支持 (8)
1.概述 1.1编写背景 企业资源过程控制管理系统是采用美国IBM公司的Maximo平台。项目实施按照“统一规划、分布实施”的原则，前期项目经过了现场需求调研、系统设计、系统开发等阶段。本次编写本测试方案的目的是为软件开发项目管理者、项目关键用户、项目最终用户、软件工程师、系统维护人员等，进行单元、联动集成式测试，目的是对大连发电公司管理信息系统在业务流程、模块功能等方面进行熟悉和测试，相关人员在进行系统测试时，对不符合项进行及时提至项目组或项目各组长。项目组将对相关人员在系统测试中发现的问题进行改进和完善。 1.2读者对象 本测试方案的合法读者对象为软件开发项目管理者、项目关键用户、软件工程师、系统使用者。
2.测试方案 2.1测试模块及部门 单元测试：
联动测试： 2.2测试数据 系统生产运行模块的基础数据主要有人员信息数据、权限信息、设备信息数据、标准两票数据以及业务流程中涉及的标准数据。 相关人员在测试中发现基础数据不完善的地方需要及时反映，辅助软件开发方完善基础数据。 2.3测试策略 系统测试分为单元测试、系统联动测试。以下根据不同阶段测试的侧重点不同，分别介绍测试策略： 单元测试 单元测试根据管理信息系统、子系统、模块进行划分，测试最终的功能模块是单独的部门、专业和班次。例如运行操作票管理，从创建票、审批、执行、结束，都在本部门相关人员的配合下完成，与别的部门班组没有交错的业务联系的
测试用例八大设计方法和实例
测试用例设计方法 1等价类划分 1.1 理论知识 等价类划分是一种典型的黑盒测试方法。这一方法完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。 等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭示程序中的错误都是等效的。 等价类合理地假设：某个等价类的代表值，与该等价类的其他值，对于测试来说是等价的。 因此，可以把全部的输入数据划分成若干的等价类，在每一个等价类中取一个数据来进行测试。这样就能以较少的具有代表性的数据进行测试，而取得较好的测试效果。 等价类划分是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法. 1) 分类： 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能. 无效等价类:与有效等价类的定义恰巧相反. 设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性. 2）划分等价类的方法: 下面给出六条确定等价类的原则： ①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类. ②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效
系统测试方案模板
文档编号产品版本密级产品名称：Agileone 共页 Agileone 系统测试方案 拟制：日期：yyyy/mm/dd 审核：日期：yyyy/mm/dd 批准：日期：yyyy/mm/dd
修订记录 日期修订版本描述作者
目录 1概述 (1) 2被测对象 (5) 3应测试的特性 (5) 4不被测试的特性 (6) 5测试模型 (6) 5.1测试组网图/结构关系图.................................................................. 错误！未定义书签。 5.2测试原理/策略 (6) 5.3 操作流程 (7) 6测试需求 (7) 6.1 环境需求 (7) 6.2 被测对象需求 (7) 6.3 测试工具需求 (7) 6.4 测试代码需求 (7) 6.5 测试数据需求 (7) 7测试设计 (8) 7.1 测试工具设计 (8) 7.2 测试代码设计 (8) 7.3 测试用例设计 (8) 7.4 测试规程设计 (9)
Agileone系统测试方案 关键词：Agileone，系统测试，需求，设计 摘要：本文档是Agileone的系统测试方案文档，主要描述Agileone系统需要测试的特性、测试的方法、测试环境的规划、测试工具的选择，测试用例的设计方法，从而对整个测试活动进行规划和控制。 缩略语清单： 参考资料清单： 名称作者编号发布日期出版单位 51test工作室2012-05-03 51test工作室AgileoneV1.1软件需求规 格说明书 于莉莉2012-06-12 51test工作室AgileoneV1.1系统测试所 计划
基于改进因果图法的CBTC系统车载功能测试方案研究
Ｖｏｌ．２８Ｎｏ．１２ Ｄｅｃ．２０１２ 赤峰学院学报（自然科学版）ＪｏｕｒｎａｌｏｆＣｈｉｆｅｎｇＵｎｉｖｅｒｓｉｔｙ（ＮａｔｕｒａｌＳｃｉｅｎｃｅＥｄｉｔｉｏｎ）第２８卷第１２期（上） ２０１２年１２月由于国内经济的不断快速发展，大型城市以及中型城市正逐步的扩建，城市面临着人口不断增加以及城市占地面积扩大的问题［１］．为了保证城市轨道交通能够更加安全、效率地运行，于是各个城市的轨道交通建设放弃选择使用原有的基于轨道电路的列车控制系统（ＴＢＴＣ），而采用最新的列车控 制系统基于通信的列车控制系统（ＣＢＴＣ）［２］ ． 在现有的城市轨道交通系统中很多都采用了ＣＢＴＣ系统，但是很多城市地铁都出现过大大小小的事故［３］．在ＣＢＴＣ系统中，车载设备保证着列车的安全行驶，系统功能都需要通过车载设备才能实现 ［４］ ．因此完成ＣＢＴＣ系统测试中重要的一个环节就 是对列车的车载设备进行调试［５］． 本研究系统根据新一代的ＣＢＴＣ系统设计理 念，利用车载设备的测试软件进行车载设备的测试．通过测试软件，观察车载控制器内的数据变化，对测试参数的具体分析，最后基于工程实践的经验，对ＣＢＴＣ系统测试用例进行设计．1 CBTC 系统概述 在ＣＢＴＣ系统下，车—地双向实时数据的传输采用的是无线通信的手段［６］．列车不再是单一地接收地面传到车载设备的控制信息，列车还需将列车的位置信息和列车的运行信息及时反馈给地面设备［７］．地面设备通过得到的列车信息计算出列车的移动授权（ＭｏｖｉｎｇＡｕｔｈｏｒｉｔｙ下面简称ＭＡ），并且动态更新，将移动授权通过车—地通信网络传输到车 载设备［８］．车载设备根据收到的移动授权信息和当前列车的运行状态，计算出列车的运行速度曲线，控制列车的牵引、制动与运行［９］．2 因果图法简述 ＣＢＴＣ系统下的车载设备将接收的信息来自区域控制器ＺＣ、ＡＴＳ系统、地面信标和计算机连锁ＣＩ，同时需要将处理的信息反馈给各系统，其中的之间的逻辑关系非常复杂［１０］．为了避免输入条件之间的彼此结合导致新的状况出现而带来检查方面的困难，因此如何设计测试用例，可以在测试手段的选取上采用一种形式，满足描述多条件组合，且产生对应多动作．这要求我们对测试用例的设计时采取因果图法．２．１因果图法原理 因果图模型中有两类主要部分的因果图参数和结构，如图１所示： 其中字母Ｂ表示基本事件，即不需探究自身 基于改进因果图法的ＣＢＴＣ系统车载功能测试方案研究 张佳莹，曲 娜，郑伟南，卫昱含 （吉林建筑工程学院 城建学院，吉林长春 １３０１１１） 摘 要：随着ＣＢＴＣ系统被越来越广泛地应用到轨道交通建设中，对其功能上的测试也越来越严 格．本文针对车载设备的测试方法和具体的测试案例进行研究， 选取以因果图法为主体的改进方法对测试进行指导工作，重点研究了因果图法中由因果图转化为判定表的条件遍历算法，并选取了车载ＡＴＰ超速防护的功能为例，对车载设备系统的测试应用中，通过对改进后的因果图法而进行研究．测试结果证明了本研究系统的所提出的测试方案具有实际可行意义，可以将该方案推广起来． 关键词：ＣＢＴＣ系统；功能测试；车载设备；测试方案中图分类号：ＴＰ２７３＋．５ 文献标识码：Ａ 文章编号：１６７３－２６０Ｘ（２０１２）１２－００２３－ ０３ 图１因果图模型 ２３－－
XX项目系统测试方案模板
XX 系统测试方案 日期： yyyy/mm/dd 日期： yyyy/mm/dd 日期： yyyy/mm/dd 拟制 审核 批准
修订记录
目录 1概述 (5) 2被测对象 (5) 3应测试的特性 (5) 4不被测试的特性 (8) 5测试模型 (8) 5.1测试组网图/结构关系图 (8) 5.2测试原理 /策略 (8) 5.3操作流程 (9) 6测试需求 (9) 6.1环境需求 (9) 6.2被测对象需求 (9) 6.3测试工具需求 (9) 6.4测试代码需求 (9) 6.5测试数据需求 (9) 7测试设计 (10) 7.1 测试工具设计 (10) 7.2测试代码设计 (10) 7.3测试用例设计 (10) 7.4测试规程设计 (10)
XX版本系统测试方案 关键词：SugarCRM测试方案、测试组网图、测试用例 摘要：依据《》，针对SugarCRM产品的XX模块、XX模块进行测试方案设计，输出产品系统测试子项以及测试方法的说明，旨在指导测试用例设计工作。 缩略语清单：
1概述 本文档是XX版本XX特性的系统测试方案，明确了……，详细描述了……，定义了… …，主要阅读对象为……，旨在……。 2被测对象 SugarCRM产品XX版本的XX模块、XX模块、XX模块…… 3应测试的特性 罗列出需要进行测试的内容，包括功能测试及其它测试类型，每种测试类型都测试哪些内容也罗列一下。 1、功能测试： 2、GUI测试： (1)控件、提示信息、颜色、窗口布局是否遵循统一的风格和标准 (2)人机交互是否人性化 (3)颜色是否使用恰当，是否遵循了一致的原则 (4)控件风格以及控件布局是否统一规范 4不被测试的特性 罗列出无需测试的内容或者因条件不具备可以不进行测试的内容
测试用例设计—自动售货机因果图分析
命题 有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1 元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。分析 根据该命题，我们可以分析出，自动售货机的业务中一共存在5个条件和5个结果，分别是：条件： 1.售货机有零钱找 2.投入1元硬币 3.投入5角硬币 4.押下橙汁按钮 5.押下啤酒按钮 结果： 1.售货机〖零钱找完〗灯亮???当售货机中没有零钱的时候就有亮红灯 2.退还1元硬币当投入1元，而且售货机中没有零钱可找的时候 3.退还5角硬币????????????当投入1元，而且售货机中有零钱可找的时候 4.送出橙汁饮料 5.送出啤酒饮料 因果图－画条件和结果 因果图－画简单关系 在画完空白的条件和结果之后，我们可以将题目中最直接和简单的因果条件标出 1、条件“有零钱”和结果“红灯亮”是一个“非”的关系，当“有零钱”的时候，红灯是不亮的，而当售货机中“没有零钱”的时候，红灯必须要亮的。 2、条件“投1元”和条件“投5角”是一个“E”的关系，这两个动作不可能同时发生，即同时投入1元钱和5角钱（不能同时为真）；但是我们允许即“不投入1元钱”也“不投入5角钱”（可以同时为假）。 3、条件“选啤酒”和条件“选橙汁”是一个“E”的关系，这两个动作不可能同时发生，即同时“选择啤酒”和“选择橙汁”（不能同时为真）；但是我们允许即“不选择啤酒”也“不选择橙汁”（可以同时为假）。 4、条件“选啤酒”和条件“选橙汁”对于程序处理过程是等价的，即二者无论是价格还是系统的处理方法都是相同的，因此这两个条件可以合并为一个中间节点。而且这两个条件之间使用“或”的关系。 5、注意，条件“投1元”和条件“投5角”不是等价关系，表面上看，他们都是“钱”，好像差不多，但是对于程序的处理过程确实完全不同的，“投5角”后完全不用判断当前售货机中是否有零钱（因为题目中规定所有的商品都是5角钱），而“投1元”就不行了。 因果图－送出商品 现在我们从结果的角度考虑，要想“出啤酒”或者“出橙汁”，从现实买卖中分析必须要有什么先决条件呢？是的，就是“你的钱要付清”，而且你一定要选择了“啤酒”或者“橙汁”才行。而在上面的已有因果图中，我们无法找到“钱付清”的因素，因此这时候我们可以试着再加一个中间节点，就叫“钱付清”吧。 要想获得选中的商品，则条件“钱付清”和条件“选啤酒/选橙汁”必须要同时成立，因此是“与”的关系。 因果图－应该找零钱 根据题意，当投入1元钱，而且又选中了某一种商品的时候，系统是需要找零钱的。而现有条件和结果中并没有涉及到“应该找零钱”这种情况，因此我们还需要增加一个中间节点“应该找零钱”。
项目测试方案模板
文件状态：[ ] 草稿[√] 正式发布[ ] 正在修改 XX项目测试方案 方案编号： 版本号： 原作者： 建立日期： 说明：方案版本维护表，用于测试方案版本的维护，A：增加，M：修改
目录 1.概述 (3) 2.适用对象和范围 (3) 3.术语、名词定义 (3) 3.1.系统测试 (3) 3.2.功能测试 (3) 3.3.接口测试 (4) 3.4.压力测试 (4) 3.5.性能测试 (4) 3.6.安全测试 (4) 3.7.可靠性测试 (4) 4.测试参考文档和测试提交文档 (5) 4.1.测试参考文档 (5) 4.2.测试提交文档 (5) 5.测试资源 (5) 5.1.人力资源 (5) 5.2.测试环境 (6) 5.3.测试工具 (6) 6.确认测试 (7) 6.1.新增或修改内容验证 (7) 6.2.用户反馈问题确认 (7) 7.通过测试的标准 (7) 8.测试策略 (7) 8.1.功能测试 (7) 8.2.数据交换测试 (8) 8.3.用户界面测试 (8) 界面规范性测试 (8) 兼容性测试 (9) 8.4.性能测试 (9) 8.5.压力测试 (10) 8.6.容量测试 (10) 8.7.安全性和访问控制测试 (11) 9.需求跟踪矩阵 (12)
1.概述 为了提高检测出错误的几率，使测试能有计划地、有条不紊地进行，就必须要编制测试相关文件。而标准化的测试文件就如同一种通用的参照体系，可达到便于交流的目的。文件中所规定的内容可以作为对测试过程完备性的对照检查表，故采用这些文件将会提高测试过程的每个阶段的能见度，极大地提高测试工作的可管理性。 2.适用对象和范围 主要针对对象为软件管理人员、软件开发人员和软件测试人员。 3.术语、名词定义 3.1. 系统测试 系统测试是通过与系统的需求规格作比较，发现软件与系统需求规格不相符合或与之矛盾的地方。它将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来，在实际运行（使用）环境下，对计算机系统进行的测试。 3.2. 功能测试 黑盒测试是基于系统需求规格，在不知道系统或组件的内部结构的情况下进行的测试。通常又将黑盒测试叫做：基于规格的测试、输入输出测试、功能测试或数据驱动测试。是基于用户观点出发的测试。主要是验证功能是否符合需求，包括原定功能的检验、是否有冗余功能、遗漏功能。
最新因果图分析法实例讲解复习课程
因果图分析法： 前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑 输入条件之间的联系, 相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（逻辑模型）。 因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。 因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或 称原因），右结点表示输出状态（或称结果）。 ci 表示原因，通常置于图的左部；ei 表示结果，通常在图的右部。ci 和ei 均可取值 0或1，0表示某状态不出现，1表示某状态出现。 4种符号分别表示了规格说明中向4种因果关系。如上图所示。 ①恒等：若ci 是1，则ei 也是1；否则ei 为0。 ②非：若ci 是1，则ei 是0；否则ei 是1。 ③或：若c1或c2或c3是1，则ei 是1；否则ei 为0。“或”可有任意个输入。 ④与：若c1和c2都是1，则ei 为1；否则ei 为0。“与”也可有任意个输入。 因果图概念--约束 输入状态相互之间还可能存在某些依赖关系，称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。 A.输入条件的约束有以下4类： ① E 约束（异）：a 和b 中至多有一个可能为1，即a 和b 不能同时为1。 ② I 约束（或）：a 、b 和c 中至少有一个必须是1，即 a 、b 和c 不能同时为0。 ③ O 约束（唯一）；a 和b 必须有一个，且仅有1个为1。 ④R 约束（要求）：a 是1时，b 必须是1，即不可能a 是1时b 是0。 B.输出条件约束类型 （d ）与
科技项目相关测试验收方案
项目测试验收方案1.1验收流程 在验收阶段，平台系统所有应用系统将按照用户和我公司都认可的《系统需求分析》，组织验收小组，进行功能和性能的验收测试。从系统的实用性、稳定性、可维护性、灵活性、可操作性、和安全性及系统文档、代码、规范及注释说明等方面组织全面验收。验收测试安排分为系统初验和系统终验。 1.2初验 经过系统内部试运行，我公司对内部试运行期间发现的问题改正后，提出系统初验书面申请。验收标准将按照“需求说明书”和双方认可的有关系统设计文档所提的要求进行。 用户在收到我公司验收申请后，尽快组织系统初验。初验前我公司提供全部的工程文档和安装测试报告，并提供初验测试文档，在用户认可后进行初验测试，初验通过后，系统进入正式试运行期。我公司应解决试运行期间所反映出的问题，若系统达不到合同规定要求，试运行期将继续顺延，直到系统完善，但试运行期最长不得超过三个月。 1.3试运行 初验合格后，经用户同意，系统进入试运行阶段，试运行周期不超过三个月。在试运行期间，我公司按用户要求提供培训和技术支持，保证用户能够正确理解和使用系统；我公司对试运行中出现
的任何问题及用户提出的修改意见将及时做出响应，并提交解决方案，在用户确认后实施。试运行期间如出现重大故障，则试运行期从故障排除之日起重新计算。 1.4终验标准 正式试运行期结束后，如系统无功能缺陷，能够正常运行，在具备终验条件下进行系统终验，由我公司提出终验书面申请，用户在收到我公司验收申请后，尽快组织系统终验。成立项目全面验收小组，由用户、我公司以及外部专家等组成，对项目进行全面验收。系统终验前，我公司提交终验测试标准和终验测试计划，内容包括：测试对象及应达到的测试指标、测试方法和测试条件、测试资料和数据，并以图表说明每一测试对象或过程的功能输入输出测试进度。 1.5终验内容 1) 系统实用性：项目验收最关键的指标，检查系统是否符合当前业务的需要，特别是业务流的整体性和数据流的一致性，并前瞻性提供未来业务接口。 2) 系统稳定性：硬件环境的稳定性、软件运行异常处理和正常运行情况。 3) 系统可维护性：含网络系统管理与维护、服务器系统平台管理与维护、操作系统管理与维护、应用系统软件管理与维护、数据库管理与维护以及数据库备份、应用系统备份，灾难事件处理与解决实施方案等。
工程项目管理系统测试方案
工程项目管理系统测试方案 （模块测试阶段） 1.试用人员账号信息 2.人员分工 3.测试项目 4.测试用例（其他分公司按照潍坊公司用例进行，只需要更改项目编号和名 称） 4.1潍坊公司用例一（分成多个任务的情况） （1）立项 项目编号：07TWF2SB0001 项目名称：潍坊电信昌乐机房改造工程
项目经理：朱汇川 项目类型：设备工程 项目概况：潍坊电信昌乐机房改造工程（介绍项目的情况） 立项时间：2007-08-01 （2）任务分解 01：领料 计划开始时间：2007-08-01 计划结束时间：2007-08-02 任务描述：到电信仓库领取工程用料（可以根据情况自由填写）02：施工 计划开始时间：2007-08-03 计划结束时间：2007-08-08 任务描述：工程施工（可以根据情况自由填写） 03：验收 计划开始时间：2007-08-09 计划结束时间：2007-08-09 任务描述：工程验收（可以根据情况自由填写） （3）计划 领料阶段人力计划：张三 领料阶段材料计划：电力电缆：RVV1-16 20M 甲方提供 电力电缆：RVV1-25 20M 甲方提供 电力电缆：RVV1-35 20M 甲方提供 电力电缆：RVV1-50 20M 甲方提供 交流排：5个单价40元/个自购 光纤跳线：单模一米 20条 20元/条自购领料阶段成本计划：计划材料费：自动生成 计划工作和福利费：自动生成 计划折旧费：100 计划办公费：100 计划差旅费：0 计划车辆使用费：100 计划费用合计：自动生成 施工阶段人力计划：张三、李四
施工阶段材料计划： 施工阶段成本计划：计划材料费：自动生成 计划工作和福利费：自动生成 计划折旧费：100 计划办公费：100 计划差旅费：0 计划车辆使用费：100 计划费用合计：自动生成 验收阶段人力计划：李四 验收阶段材料计划： 验收阶段成本计划：计划材料费：自动生成 计划工作和福利费：自动生成 计划折旧费：100 计划办公费：100 计划差旅费：0 计划车辆使用费：100 计划费用合计：自动生成 （4）质量指标： 随便选取10个指标 （5）安全指标： 随便选取10个指标 （6）工程费 选用定额：TX1-002施工测量（光缆）数量：1 TX4-034 敷设管道光缆（108芯以下）数量： 结算标准：根据公司实际情况填写 （7）提交申请： 在确认以上输入无误后（如有问题可以进行相应修改），可以提交申请，注意提交后不允许修改。 提交申请，指定审批人，为了便于测试，流程调整按钮，指定田洪超为审批人员。然后提交申请到下一步。 （8）立项审批：