本发明涉及一种测试设计平台。
背景技术：
目前，市场上出现的测试设计平台，大都结构复杂，实现起来比较麻烦，同时测试效率低下，不能满足现在不断增加的测试需求。
技术实现要素：
鉴于现有技术中存在的上述问题，本发明的主要目的在于解决现有技术的缺陷，本发明提供一种使用方便且效率高的测试设计平台。
本发明提供了一种测试设计平台，包括用户界面分析模块、业务分析模块、案例生成模块，其中：
所述用户界面分析模块用于对用户界面进行要素的分析和提取，将数据单独管理并赋予相应的剧本角色，建立通过业务分析产生的测试点、测试案例、测试数据之间的关联关系，自动生成具有中间码形式的自动化测试案例，同时，也可以用于手工案例的设计，并精确生成数据需求和测试点；
所述业务分析模块用于通过测试业务情景的录入，实现对测试场景的支持；
所述案例生成模块用于通过在自动化执行时通过代码生成机制自动转化为自动化工具识别的脚本语言，并在测试结束后自动生成带有截图的标准测试报告与缺陷报告，测试报告支持多种格式。
可选的，所述多种格式包括doc、pdf以及html格式。
本发明具有以下优点和有益效果：本发明提供一种测试设计平台，该测试设计平台支持以可视化的方式对业务流进行描述，从而形成对于金融产品内在业务时序的完整准备的表达，在此基础上，按照拓扑理论生成无循环、有循环、流程反例等节点序列；同时该测试设计平台把测试案例置于交易链的内在联系之中，通过交易流分析描述交易间内在的时序关系，并且将其表达为描述抽象拓扑结构的交易流图或工作流图，从而实现交易流程的完备覆盖基准，并以此为基础自动生成流程级案例；另外，该测试设计平台对于需要多角色协同工作流，测试设计平台支持岗位切换与回退机制，从而以完全同样的机理在抽象层面直接支持工作流案例的分析和设计。
具体实施方式
下面将参照具体实施例对本发明作进一步的说明。
本发明实施例的一种测试设计平台，包括用户界面分析模块、业务分析模块、案例生成模块，其中：所述用户界面分析模块用于对用户界面进行要素的分析和提取，将数据单独管理并赋予相应的剧本角色，建立通过业务分析产生的测试点、测试案例、测试数据之间的关联关系，自动生成具有中间码形式的自动化测试案例，同时，也可以用于手工案例的设计，并精确生成数据需求和测试点；所述业务分析模块用于通过测试业务情景的录入，实现对测试场景的支持；所述案例生成模块用于通过在自动化执行时通过代码生成机制自动转化为自动化工具识别的脚本语言，并在测试结束后自动生成带有截图的标准测试报告与缺陷报告，测试报告支持多种格式。
本发明提供的测试设计平台可准确细致地描述被测系统，形成关于系统的知识容器。通过对用户界面(UI)进行要素的分析和提取，将数据单独管理并赋予相应的剧本角色，建立通过业务分析产生的测试点、测试案例、测试数据之间的关联关系，自动生成具有中间码形式的自动化测试案例(.in文件)，同时，也可以用于手工案例的设计，并精确生成数据需求和测试点；同时把测试案例置于交易链的内在联系之中，通过业务流分析描述交易间内在的时序关系，并且将其表达为描述抽象拓扑结构的D型图(业务流图或工作流图)，从而实现业务流程的完备覆盖基准，并以此为基础自动生成流程级案例；测试设计平台支持以可视化的方式对交易流进行描述，从而形成对于金融产品内在业务时序的完整准备的表达，在此基础上，按照拓扑理论生成无循环、有循环、流程反例等节点序列；测试设计平台支持单一业务流的可视化定位，把流程级测试点表达为D型图的某一路径。对于需要多角色协同工作流，测试设计平台支持岗位切换与回退机制，从而以完全同样的机理在抽象层面直接支持工作流案例的分析和设计；测试设计平台准确细致地描述被测系统，形成关于系统的知识容器。通过对用户界面(UI)进行要素的分析和提取，将数据单独管理并赋予相应的剧本角色，建立通过业务分析产生的测试点、测试案例、测试数据之间的关联关系，自动生成具有中间码形式的自动化测试案例(.in文件)，同时，也可以用于手工案例的设计，并精确生成数据需求和测试点。
测试设计平台是一种能够反复、批量生成测试案例的完整体系，包括UI分析、对象模型、测试数据管理、案例自动生成、运行控制等机制。。通过业务流分析描述交易间内在的时序关系，并且将其表达为描述抽象拓扑结构的D型图(业务流图或工作流图)，从而实现业务流程的完备覆盖基准，并以此为基础自动生成流程级案例。测试设计平台的呈现典型的三层架构，其业务逻辑通过一系列专用的部件实现：测试设计平台支持以可视化的方式对业务流进行描述，从而形成对于金融产品内在业务时序的完整准备的表达，在此基础上，按照拓扑理论生成无循环、有循环、流程反例等节点序列；测试设计平台支持单一业务流的可视化定位，把流程级测试点表达为D型图的某一路径。对于需要多角色协同工作流，测试设计平台支持岗位切换与回退机制，从而以完全同样的机理在抽象层面直接支持工作流案例的分析和设计；测试设计平台准确细致地描述被测系统，形成关于系统的知识容器。通过对用户界面(UI)进行要素的分析和提取，将数据单独管理并赋予相应的剧本角色，建立通过业务分析产生的测试点、测试案例、测试数据之间的关联关系，自动生成具有中间码形式的自动化测试案例(.in文件)，同时，也可以用于手工案例的设计，并精确生成数据需求和测试点；通过测试平台的业务分析功能模块，通过测试业务情景的录入，实现对测试场景的支持；平台通过对用户界面(UI)进行要素的分析和提取，或者通过报文格式进行字段提取，将数据单独管理并赋予相应的剧本角色，建立通过业务分析产生的测试点、测试案例、测试数据之间的关联关系，自动生成无代码的自动化测试案例(.in文件)，.in文件既可由测试人员手工执行测试，也可以通过自动化执行测试。降低自动化测试对代码的依赖性；在自动化执行时通过代码生成机制自动转化为自动化工具识别的脚本语言，并在测试结束后自动生成带有截图的标准测试报告与缺陷报告，测试报告支持多种格式如doc、pdf、html，提高工作效率，使测试人员的工作重点，从编写大量的测试报告中解脱出来，转移到对缺陷的跟踪和分析。
自动化测试免代码技术的采用，使得测试案例生产过程更加高效；通过将测试用例定义为明文表达的中间码(.in)，测试执行平台可以根据数据表和交易模版批量自动生成测试用例，并且动态地用.in中间码来产生自动化测试工具脚本以及检查点。另外，测试执行平台可以支持SQL检查点，通过SQL语句直接验证数据库中的结果；代码生成技术是在数据驱动和关键字驱动不足以解决工作过程中遇到麻烦的情况下，提出的一种自动化技术新的实现方式，所谓代码生成是指在测试用例自动化运行前，通过程序生成适应自动化测试工具适用脚本的自动化技术，其好处在于能够尽量减少在测试脚本的维护中改动自动化工具源代码，而且使用中间脚本能够减少自动化工程师对自动化工具的依赖程度，并且中间脚本可以适应多种自动化工具，可以生成多种自动化工具都能够识别的测试脚本，对自动化实施提供了更多的选择机会；提供多级生成机制，实现测试用例的自动生成和免脚本维护。多级生成机制是功能测试框架的重要组成部分。多级生成机制的顶端是业务表述层，测试点就位于这个层面；在剧本层之下是对象模型层，完成测试所需的各种角色和基础数据就表达在对象模型中；在业务表述层之下是剧本层，剧本是测试点与基础数据(它表现为对象的属性)之间的纽带，在以某种方式完成了对象分派后，测试剧本可以根据剧本模版自动生成；在对象模型层之下的是抽象数据层，这里包含了一组测试数据表，分别对于不同的交易(或虚拟交易)，其中的所有数据都来自于对对象模型的引用(reference)，这些引用是由测试剧本决定的；在抽象数据层之下则是用例表述层，此时，对象模型中的基础数据配置完毕，通过用例生成器可以从数据表和模版中生成可以执行的测试用例；在用例表述层之下则是测试脚本层，它是根据测试用例动态生产的脚本。这六个层面构成了逐级生成的关系，通过分析和转换工具，业务分析生成测试剧本，测试设计生成要素模型和对象模型；在此基础上，建立抽象数据层，然后从抽象数据层出发自动生成基础模版和用例文本，再从用例文本生成测试脚本。
以上六个层次中，业务表述层、对象模型层、剧本层、抽象数据层都保持在抽象层面，用例表达层和测试脚本层则含有来自于基础数据的具体的测试数据，其中测试脚本层完全是动态生成的。在适用性调整发生时，用例表达层可以(部分或全部)重新生成。由此实现了对业务的抽象表达，其表达的形式是一系列配有剧本和对象模型的测试点，并在这一表达的基础上形成了用例生成机制，可以反复地根据不同的基础数据和测试意图生成测试用例。
在测试的具体执行阶段，由于测试的范围包含核心系统的多个金融产品，每个金融产品源于其内在的业务逻辑要求，会对测试案例的运行顺序产生时序性的要求(例如：存款产品开户之后才可以存入资金，然后才能够办理支取等)，甚至某些产品(情景)的测试点与现实世界的具体日期有密切的相关性，需要特意安排某些特定的具体日期(例如：闰年的2月29日)或特定的时间间隔(例如：定期存款的不同存期)，这就要求核心系统的日期和换日批量等事件要给予准确的支持；而多个产品并行时，每个产品的时间要求各不相同，会对特定的资源(系统日期、测试机构等)产生特定的需要，测试环境由于其本身固有的局限性，不可能对于每个产品的要求给予完全独立的响应，必须从总体上予以统筹安排协调；因此，必须在测试设计阶段对所有测试案例的具体执行顺序予以完整明确的规划，保证在满足总体测试计划的前提下实现对各产品具体时间点的完整覆盖，避免测试遗漏。
另外，每个测试项目在测试执行阶段，对于具体的可用时间窗口会有明确的计划限定，如何在规定的时间内即要完成测试，还要覆盖规划的时间点，而且要做到测试执行任务的均衡，除了要满足上文编制时间规划外，还要结合测试人员具体的执行效率来分配测试资源(机构、柜员、设备等)以完成测试执行任务，这就需要在时间规划的基础上，根据每个时间点所包括的案例数量和投入资源来进行均衡分派，最终形成以业务时间点为基础的、以测试任务(案例数量)为表现的完整运行规划。
运行规划是测试实施前的最后一项规划，它的目的是将测试案例分给不同人员、不同运行机器，运行规划的好坏，直接影响测试过程中，每一台机器每一个人员的使用效率。一个好的运行规划，是要将每一条业务流程，合理、平均分配给执行者，并且还要考虑整体项目的时间规划、外系统配合、日终跑批等多项因素。
本发明提供的测试设计平台提供数据需求模板，能够根据测试的数据需求，实现多组数据结合一个测试脚本构成多个测试用例的框架模式，但我们无需管理和维护这些数据表格。该模式和一个脚本对应一个数据表格的管理模式显然不同，哪种情况下，维护这些表格将会变得非常困难。特别是面对测试各阶段不同数据的要求，如产品变更初始阶段以使用交易创建为主，到UAT阶段必须使用生产系统脱敏数据为主的模式，期间选择好符合测试意图的测试数据并分配到每一个案例对应的表格，将是非常困难的工作！
考虑到系统功能测试过程中需要大量的测试数据，因此需要一种高效的方法能够生产大量的测试数据，为功能测试提供支持。根据数据表中的数据，捷科测试平台支持测试数据的自动化生产，并且根据提取的需要参加执行的案例来形成统一的数据需求，数据需求匹配案例设计对数据的描述，并自动结合完成测试案例的现场脚本化。
在运行规划中，建立对应的业务交易例如：冻结、解冻、开户、销户，以确保测试数据的重用；在数据表中确定测试案例的调用顺序。通过以上两点，满足测试执行过程中，测试数据的可复用性。
本发明提供的测试设计平台通过数据表支持测试数据的生产，运行规划支持测试数据的调用顺序。从生产系统引用的测试数据，由于考虑到对用户的业务数据的安全性，需要进行真实数据的脱敏工作。敏感信息保护主要考虑以下两个方面：
1)如何保证数据应用过程中不泄露敏感信息；
2)如何更有利于数据的应用。
数据脱敏工作需要达到满足数据安全的原则要求并能更好的实现这两方面的平衡。脱敏信息主要包括：客户身份验证信息、密码相关信息、账号和卡号信息等。而脱敏的方式，需要根据数据的安全级别进行定义，采用全脱敏还是半脱敏。
本发明提供的测试设计平台中的数据表相当于测试数据资源池，在测试数据资源池中的数据，带有剧本角色属性，可确定测试案例的归属和业务场景的确认信息。因此，在测试执行的时候，能够准确的定位被哪个测试案例调用，且满足那个业务场景。
测试执行过程中的数据调度管理。将数据与脚本分离并定义数据角色，以数据池作为数据的管理和容器，清晰的反应测试执行过程数据的使用情况。这样在测试执行过程避免了当数据损坏的时候，可以根据数据角色重新配置数据，保证测试自动化的顺利执行，提高测试执行效率，因此我们只维护需要变更的数据，而不是对应于每个脚本实现的数据项，而且表格的选取和维护是在数据管理人员根据数据需求描述创建或选取完成的，具体采用何种手段取决于业务系统数据库的开发程度及软件实现所处的阶段。
数据规划是在实施之前非常重要的规划之一，它规划的好坏，直接影响测试执行效率，并且一个良好的数据规划，不仅要考虑本次执行，而且还要考虑随后的回归需要考虑的数据更换问题。传统的数据管理，是通过外部表格，使用自动化工具的数据驱动传递给测试脚本，这样做效率底下，数据与案例之间没有依存关系和逻辑关系，在数据更换的时候，相当于重新填写一遍，使得每次自动化运行的时候，数据填写均是一个耗费人力和时间的工作。捷科采用的数据管理是要针对界面中的要素所处的地位分类管理，考虑要素使用的数据中存在的内在逻辑，把需要多次更换的数据通过不同的业务视图直接展现在数据需求中，通过映射关系映射到每个情景的每个案例中，这样做的好处是：在第一次规划数据时会将所有案例按照泳道的概念(业务流程)进行规划，不用逐点规划，节省了第一次数据规划的时间；在后期的更换数据过程中，由于需要变更的数据已经提炼出来，只需要通过提取的数据需求视图更换少部分数据便能够达到更换所有测试案例的测试数据，其比传统的数据管理提高几倍甚至几十倍效率。
对于测试数据管理可以划分为测试数据的生产管理和测试执行过程中的数据管理。测试数据的生产管理：考虑到系统功能测试过程中需要大量的测试数据，因此需要一种高效的方法能够生产大量的测试数据，为功能测试提供支持。因此，在测试过程，捷科测试团队能够根据功能测试的数据需求，进行真实数据的脱密工作和测试数据自动化生产。保证了自动化功能测试的顺利进行，提高了测试执行的效率。测试执行过程中的数据管理：捷科公司将数据与脚本分离并定义数据角色，以数据池作为数据的管理和容器，清晰的反应测试执行过程数据的使用情况。这样在测试执行过程避免了当数据损坏的时候，可以根据数据角色重新配置数据，保证测试自动化的顺利执行，提高测试执行效率。
测试数据的准备
主要有2种：在系统中找数据或利用技术手段通过正规渠道制作数据。
1)在系统中找数据，优势在于利用系统原有数据，查找的速度比较快，能够比较快速的交付一批数据供测试使用；缺点在于数据查找的逻辑可能考虑不周，数据的某些属性或状态不符合测试案例的要求，在执行测试案例(尤其是自动化案例)，由于数据问题产生的错误较多时，对执行效率(尤其是自动化执行效率)损失较严重；
2)利用技术手段通过正规渠道制作数据，优势在于利用正规渠道制作出来的数据对于案例的数据要求是完全满足的，在案例的执行过程中，没有特殊原因不会因为数据问题产生错误，缺点是造成测试准备时间较长，可能导致执行周期延长。
多数情况下，自动化测试项目采用的是第二点做法，利用自动化测试工具，经过正规渠道制作自动化数据服务脚本，通过自动化执行，产生测试数据，再通过有效的数据组织，将数据配置在测试案例上面，实现测试案例的数据匹配并执行测试案例。在数据库结构较为简单，数据状态能够通过SQL语句实时更新，也有采用直接配置Select语句在案例中来准备数据，，案例执行完毕再通过SQL语句更新数据状态，实现案例的自动化执行，数据状态的复原。
测试数据的组织
测试数据的组织是非常有意义的工作，它处理的好坏不仅关系到测试数据因使用量多少引起的测试成本，而且关系到测试数据是否可以重复利用，影响测试数据的使用率。捷科在测试数据组织的方面采用以下几种方法：
1)从业务逻辑方面考虑(排交易链)：根据业务逻辑，将多个案例排列起来，使用同一组数据执行，以便达到节省数据的目的；
2)从数据管理方面考虑(排泳道)：根据泳道进行数据管理，不同泳道使用不同的数据，以便达到数据共享导致的数据混乱；
3)从数据重用方面考虑(自回归)：根据业务逻辑，将案例尽可能串在一起形成案例连，利用其中关联的业务逻辑，用后案例恢复前案例的数据状态，以便在整条案例连执行完成后，测试数据恢复到初始或者类似初始状态，供下一次使用；
4)从数据配置方面考虑多视图多角度配置：采用多视图多角度多因素考虑，数据快速配置到案例中，采用生成自动化测试脚本的方法完成最终自动化案例的产生。在脚本方面，捷科自动化测试框架并不维护脚本，而是维护交易模板和数据表，通过配置不同的测试数据实现自动化脚本的批量自动生成；
5)自动化测试过程中，数据的组织分为案例内和案例间的数据共享。案例内的数据共享类似局部变量，案例间的数据共享类似全局变量，而且案例间的数据共享是永久性的，不会因为一次测试案例执中断后而消失，下次继续执行时，数据仍然有效，确保了不同时间点案例执行的继承性、连续性；
6)自动化测试产生的输出数据，除了供后续案例使用外，还有一些属于案例执行状态或结果的数据，此类数据保存在本地文件系统或数据库中，供后续的生成测试报告和测试进度、缺陷统计使用。
数据服务
采用自动化手段来提供测试服务，将大大缩短测试准备阶段的时间，尤其是在大规模测试的准备阶段尤为有效，因此，通常由技术组或者单独的数据组来提供自动化测试数据服务，并按照规范的流程以确保提供测试数据的规范性和有效性。
最后应说明的是：以上所述的各实施例仅用于说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述实施例所记载的技术方案进行修改，或者对其中部分或全部技术特征进行等同替换；而这些修改或替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。