《软件工程毕业设计（论文）-Automatic_Functional_Testing在SAP系统中的应用.doc》由会员分享，可在线阅读，更多相关《软件工程毕业设计（论文）-Automatic_Functional_Testing在SAP系统中的应用.doc（25页珍藏版）》请在三一文库上搜索。
1、装订线Automatic Functional Testing在SAP系统中的应用毕业设计（论文）报告纸同济大学学士学位论文Automatic Functional Testing在SAP系统中的应用本科生：学 号：导 师：专 业：软件工程Tongji UniversityPaper for Bachelor DegreeImplementation of Automatic Functional Testing in SAP SystemCandidate : Zhou JunweiAdvisor : Du QingfengMajor : Software EngineeringMay 20
2、04【摘要】 在当今软件开发中，软件测试已经越来越被人们所重视。它直接影响着软件整个生命周期。但是软件也出现了越来越庞大、复杂和灵活等新的趋势，这就给测试带来一系列新的问题。对于软件的复杂，灵活，软件测试正采用自动化测试来逐步取代软件手工测试，这样可以节省大量人力、物力和时间。本文主要讨论对当今大型软件进行自动化功能测试时的一些问题，并据此对测试过程的各个方面如创建测试计划，设计测试案例，录制、优化和执行脚本，如何确认和报告缺陷等都作了一些改进，并通过实例表明了该过程的有效性。【关键字】 自动化测试，功能测试，SAP(System Application Product)【外文摘要】 In s
3、oftware development today, software testing as a field has become more and more important. It has influence on the whole lifecycle of software. However, as the software is becoming larger, more complex and more agile, which has brought a series of new problems. Automated testing is more and more tak
4、ing the place of manual testing, which can help to save lots of human and material resource and valuable test cycle. The paper focuses on how to do the automated testing on large scale software, and showed a whole process of automated testing, including test plan setup, test case design, test script
5、s creation, optimization and execution, test report confirmation and test defects reporting, based on a example to prove the effectiveness of this process.【Key Words】 Automated Testing，Functional Testing, SAP(System Application Product)目 录第一章 概述51.1 简介51.2 SAP简介5第二章 功能性测试的一般流程分析62.1 软件测试概要描述62.2 基于功
6、能性增强流程62.3 对大型软件测试遇到的问题8第三章 对测试工具的选择的重要性10第四章 对SAP进行功能性回归测试114.1 项目简介114.2 需求分析114.3 创建测试案例134.4 录制和优化脚本164.5 完成最终报表194.6 做好脚本的配置管理214.7 建立培训机制和脚本维护21总结与展望23致谢24参考文献25第一章 概述1.1 简介随着计算机在越来越多的领域中发挥着重要的作用和计算机各种技术的发展，当今软件的发展也出现了新的趋势：越来越庞大、复杂和灵活，例如大多ERP(Enterprise Resource Planning企业资源计划)软件诸如：SAP都将人力资源、后
7、勤管理、销售分销、财务管理和控制都包含在应用范围之内，其各个应用模块之间的通讯和联系越来越紧密，相互共享和交换的数据也越来越多，图形用户界面也随之繁多而复杂。另外，为适应市场的迅速变化，大多ERP软件都具有相当的灵活性和二次开发性。软件的这种变化趋势使软件测试越来越重要，但同时也对其提出了严峻的挑战。软件测试在软件生命周期中占据重要的地位，事实上，对于软件来讲，不论采用什么技术和什么方法，软件中仍然会有错。采用新的语言、先进的开发方式、完善的开发过程，可以减少错误的引入，但是不可能完全杜绝软件中的错误，这些引入的错误需要测试来找出，软件中的错误密度也需要测试来进行估计。测试是所有工程学科的基本
8、组成单元，是软件开发的重要部分。1.2 SAP介绍SAP是全球领先的商务软件解决方案提供商。SAP解决方案可以满足各种规模公司的需要从小型到中型及跨国企业。借助SAPNetWeaver开放集成与应用平台来降低复杂性和总体拥有成本并鼓励企业变革创新，mySAP商务套装软件正帮助全球的企业改善客户关系、增强合作伙伴协作，并提高供应链与业务运行效率。SAP的超过25款行业解决方案为各种不同行业（从航空到公共设施）的核心运营提供着强有力的支持。目前，全球有120多个国家的超过22,600个用户运行着76,100多套SAP软件。SAP在全球50多个国家设有子公司，并在多家交易所上市，包括法兰克福证券交易
9、所和NYSE，交易代码为“SAP”。第二章 功能性测试的一般流程分析2.1 软件测试概要描述软件测试的方法主要有两种：黑盒测试和白盒测试。一般在进行结构性测试时，使用白盒测试较多。白盒测试需要全面了解程序内部逻辑结构、对所有逻辑路径进行测试。测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。在功能性测试时，大都采用黑盒测试。黑盒测试不需要了解程序的内部结构，只针对软件界面和软件的功能进行测试。黑盒测试只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。它不需要知道软件如何运行，为什么会
10、这样，只知道程序做什么。对于SAP系统，每个月都要进行更新，如果使用白盒测试，要测试人员不光要懂SAP系统，甚至要读懂源代码。对于每个月SAP的大量测试任务来说，将要花费大量的人力、物力，再者社会上这种人才缺乏，实现的可能性不大。所以采用功能性回归测试，这样测试人员只需要懂简单的SAP知识和测试技术就可以了。由于每个月都要测试同样的功能，为了节省人力，时间，把要测试的功能编成脚本，实现自动化。一般的功能性测试流程：需求分析 - 测试案例 - 测试案例执行 - 测试结果。2.2 基于功能性增强流程测试管理者根据功能性测试的一般流程，提出了有计划、可持续改进，功能性增强的测试过程：（图1） 1)
11、分析测试流程, 准备分析文档和最终报表。确认客户的需求并准确的传达给测试人员。目的是要从建立文档转移到建立工程，重点不是编写而是计划。其格式可有测试组自己来定义，但内容上应包括范围、时间和成本方面的内容，由于不确定的因素较多，通常需要将时间和成本要略大于实际的估计值。还要制定一个合理的测试目标。测试员、管理部门都要知道和同意这个目标。软件测试员的目标应该是：找出软件缺陷，尽可能早一些，保证起得到修复，并在正确的时机结束测试。测试员不能仅满足于找出缺陷，却忽略了要确保其得到修复这个目的。但当测试组没有足够的时间、软件不算真正的缺陷、修复的风险大大或不值得去修复时，就不需要修复软件缺陷。测试组往往
12、希望“通过测试的软件产品是没有问题的产品”，因为如果不能找到错误，客户就会迟早找到它们。但实际上对于测试人员来说不可能真正达到而只能尽量地接近这个目标，这个度往往是：当时间或资金不够用的时候，就完成了测试。2) 测试案例测试案例主要包括：确定案例执行前所需要的测试环境和先决条件；确定所要测试的目标；确定对输入数据的要求和期望的输出。设计测试案例时要注意：努力提高重用率，尽量减少执行、调试和结果分析的工作量；加强测试案例的独立性、并精确地文档化等来加强其可维护性。好的测试案例可以极大提高测试的效率。目前的软件是比较复杂的，客户端服务器、浏览器服务器、数据通信、巨大的关系数据库技术的利用以及规模庞
13、大，所有这一切都造成软件的复杂性提高，以至于没有一定基础的人不可能全面地掌握它。软件本身的复杂性和相互之间频繁的联系使软件的出错概率提高，也使测试的难度提高，给测试人员的素质提出更高的要求。分析测试流程, 准备分析文档和最终报表测试案例测试脚本StartEnd测试案例编写人员测试脚本编写人员测试脚本工程师分析文档详细测试案例脚本最终报表脚本优化 图1：功能性测试流程另外，测试案例应该尽可能精简而又能达到测试目标。如果测试案例包含了很多测试步骤，就会使测试案例的复杂度大大增加，从而增加测试案例的可维护性和理解性。3) 测试脚本 录制脚本前，测试员必须对测试工具能够进行非常熟练的操作，否则会大大增
14、加编辑测试脚本的成本。录制脚本之前应该进行相应的配置，按照测试案例录制测试脚本，否则可能会给脚本的优化、执行带来很大的麻烦，甚至要重新进行录制。对于大型软件，其业务流程的复杂，数据依赖很多，所以要对其进行参数化。因此要有一份文件详细描述：什么值需要参数化，如何对全局的、过程的参数命名、传递和联系。优化脚本时可以安排两个人一组来共同做好分支和循环，对对象属性的取舍和设置，设置检查点和输出，以使脚本能按照测试案例的要求适应各种情况。4) 对于测试结果缺陷的判断由于使用了测试脚本，所以不可避免有一些错误是由测试脚本引起的，需要有经验的测试工程师加以区分。在报告软件缺陷时，测试员要：A. 尽快报告软件
15、缺陷。软件测试员发现一个问题后往往满足于发现了问题，而把已发现的问题简单处理后放在一旁。尽快报告能使问题早点被解决，从而使中断了的测试在同一测试周期内能被继续下去，可以使测试发现更多有意义的问题，缩短整个测试周期。B. 在软件缺陷的描述上要简短、易懂，有一个统一的格式，还要给出再现这个缺陷的条件或步骤，并对软件缺陷划分其重要性和优先级。一个报告仅描述一个问题，因为这样缺陷便于跟踪和解决。C. 在报告软件缺陷时不做评价。测试员虽然也可能猜测到问题出现在哪里，但测试员这么做肯定是低效的，评价不应是测试员的责任。D. 补充完善软件缺陷报告。测试员发现并记录了大量软件缺陷之后，要继续监视其修复的全过程
16、，确保软件缺陷得以修复并最终解决，尽量缩短软件缺陷的生命周期。2.3 对大型软件测试遇到的问题软件功能测试是用来验证软件是否具有满足用户需求的的功能，在软件测试的各个阶段，尤其是确认测试阶段功能测试都相当重要。在软件发布后的每次改动或升级后，也都需要对其进行回归行功能测试以保证起原有功能无误。测试技术主要使用动态黑盒测试技术。目前对软件测试方法主要有手工测试和自动化测试。自动化测试与手工测试相比有着明显的优点，自动化测试一般更准确、更精确，具有更快的速度和更高的效率，而且测试工具不会疲劳，因此是测试技术未来的发展趋势。现在很多测试就在用自动化测试技术。为了达到更好的测试效果和节约测试成本，对软
17、件的测试一般由独立的测试组进行，但这对于大型软件的测试却非常困难。因为测试组应该熟悉至少要理解被测试的软件，组内最好有一些熟悉此软件的专家参与或作为顾问，但大型软件却给人们认识、了解和使用等提出了许多困难，测试组若不经过有效的培训很难能熟悉它，熟悉此软件的专家成了社会上的稀缺人才。而且自动化测试在某些方面还不成熟，不能完全代替手工测试，因此在对大型软件进行自动化测试时往往会出现许多困难，如：1) 制定测试案例困难。有限的人力、时间内，测试组不可能发现软件中的所有问题，软件测试员就必须在选择测试案例时就从广度和深度上权衡。这就要求对被测试软件很熟悉，否则难以制定出有效的测试案例。2) 缺陷难以确
18、认。软件经常变更，而目前自动化工具灵活性不足，智能化程序不高，其脚本难以及时适应变更，这可能导致自动化失败或造成潜在的问题。由于不熟悉被测试软件，测试员难以把这写脚本问题同缺陷区分开来。另外，如果测试员对自动化测试工具不熟悉也会影响测试员的判断力。3) 脚本的变更管理和配置管理。由于自动化脚本很多都很大，往往是包含有许多文件和子文件夹的文件，而且脚本经常要被改动，而每次改动往往会影响多个文件或文件夹，因此一般的版本控制软件不适合管理它们，这常常导致测试员所用的脚本不是最新或不一致的情况，以致测试效果低下。4) 与技术相关的问题所有这写问题都会导致测试员士气低下、主动性降低、工作效率低下。本文将
19、针对测试案例制定困难、缺陷难以确认、配置管理等问题提出一个功能测试流程，并在SAP系统的功能测试中加以应用。第三章 对测试工具的选择的重要性在测试中，对于测试工具的选择也是很重要的。好的测试工具可以很好地帮助测试人员完成工作，实现测试自动化。测试工具选择过程的最终目的是要证明一个工具能使测试者在自己的公司里对测试进行自动化。在选择过程中，对测试工具可能有一大堆的需求。有些需求与测试者现在具有且希望用测试工具来解决或至少是减轻的测试问题有关。其他需求还包括限制工具选择的技术和非技术原因。首先需要明确这些对工具的需求，以便有评估候选工具的依据。当然还要考虑到效益和风险，即值不值得使用测试工具，因为
20、编写和维护测试脚本需要大量的工作量，对于长远来说是有价值的，但是对于短期的测试是没有多大的价值。至于风险，由于使用了测试工具，缺陷的发现数量肯定比手工测试发现缺陷的数量要少，这或多或少地影响了测试的最终结果。现在市面上比较好的测试工具往往都不是免费的，需要购买License，这无形中又增加了投资，所以测试组要综合考虑以上因素，做出正确的决定，选择既价廉又实用的测试工具。普通的测试工具能够进行录制，但是对于像SAP这样复杂的系统，普通测试工具不能满足要求，比如，要在一个表中输入某一项，由于输入这项的位置时常发生变化（包括列数和行数），普通测试工具无法捕捉，甚至无法识别这个表。Win runner
21、 虽然能实现以上功能，但是它在实际应用中对于SAP的Table Tree Control对象的操作有误。而QTP 6.0能满足以上的要求，它拥有专门针对SAP系统测试的插件。在比较了各种测试软件后，发现QTP 6.0能满足测试的需要，所以QTP6.0是最佳的选择。第四章 QTP 6.0在SAP系统回归测试中的应用4.1 项目简介E2E (End to End)是SAP模块之一，在每次更新或升级SAP系统后都要对齐进行回归性功能测试。测试工具使用Mercury Interactive 公司的Quick Test Professional for SAP 6.0。E2E主要包括整个业务的流程：报价
22、(Quote)，合同(Contract)，合同组(group contract)，开发票(Invoice)，缩短售后服务(Short life of items)，重新开发票(Re-Invoice) 和信用卡付帐(Credit)。还包括象收货(delivery interface)等相关系统。这是最基本的一个流程，从对客户报价到签合同，开票，交货和收钱一系列过程。对于SAP系统，每个月都会进行更新，对于每次更新都要进行大量的测试，包括新添加的功能和原来的功能。E2E就是其中之一，每个月更新后测试其是否能按正常流程工作，能不能得出期望的结果。至于E2E的缺陷范围也很广，不光是编程错误，还包括报价
23、和合同能否一一对应，开票能否成功，税和总价是否都正确，交货与收钱能否正确地反应，对于售后服务缩短的操作能否实现等等。在分析需求时，这些缺陷都要加以一一说明并验证。由于SAP的复杂性，测试人员不可能对其完整的了解，所以在测试的各个阶段，都需要专家的参与。4.2 测试需求需求分析由于现在对软件测试的概念有所转变，不再是简单的测试。还包括对文档的评审。文档很重要，它关系到测试的最终效果和测试缺陷的发现。对文档进行评审时，应包括对所要测试的功能点的评审，使其尽量能覆盖所要测试的所有功能点。要找出测试的功能点，就要列出所有要测试的功能项，凡是没有出现在这个清单里的功能项都排除在测试的范围之外。需求分析必
24、须要把客户要求准确地理解。对于E2E，必须了解其基本业务流程，也可以叫做“这个过程到底在干什么”。只有在了解的基础上，整理写成文档。文档中应包括： 根据需求确定测试目标 根据需求分成不同的测试案例 定义每个测试案例的动作 定义每个测试案例所使用的数据分析还必须对测试的资源要求，文档、测试工具、脚本、等的存放位置，哪些要测试或不要测试（含理由），测试阶段，测试策略，测试员的任务分配，测试进度的安排和培训计划等，为测试组提供了方向。同时也应确定最终的测试报告，测试报告是反映给客户的测试结果。所以使用的是Excel形式，而且要经过客户的认同才行。Scenario Iterations Always
25、create 2 or more quotes and link to a group contract Situations/VariationsSpecific Data to UseStep Variations Reprice contract (ZCRP) Renewal contract (ZCRN) Create F/L & Quote Header Create Data Structure Set the portfolio ID to “S” for System Support Make sure 2 or more documents are created for e
26、ach variation, for Group Contract functionality. Billing Process invoice Amendments Short life 2 items on 1 contract within Group Contract in middle of settlement period Credit Request & Credit Memo Process Credit Request/Credit Memo Invoice next settlement period Renewal/Workflow Use contracts crea
27、ted and process through Workflow as standard renewal. Workflow is to create a standard system support renewal quote (that is, a blue renewal quote).表1：测试案例由表1可见，将这个流程分成五个测试案例，并确定每个测试案例所应该做的动作。表2：需求分析(不在自动化测试范围内的部分)Out-of-scope StepRemarks Create high level functional location An existing CLE will be
28、 used, not possible to create new high-level FL when running scripts every time. Create equipment via ASTRO Activities in AMP by transaction ZAMP Corresponding transaction codes will be used to replace the activities in ZAMP. Verify pricing, tax, and discounts Manually Check Scan customer PO a Manua
29、lly Check Check customer doc images and printouts Manually Check Check DOR and EI Manually Check Check interface and SCA Manually Check Check workflow and validate quote created from workflow Manually Check对于测试工具来说，其对于测试结果只能进行简单的比较，所以有很多对于测试结果的确认需要人工参与，表2列出了哪些人工去确认或者有些不在测试范围之内的部分。4.3 创建测试案例根据需求分析，需要
30、编写测试案例。简单地说就是把客户的商业描述变成测试员能看懂的描述。所以测试案例必须包括在SAP中，对于每一个步骤的变量使用的结果、所产生的结果、确定哪些数据属于全局、哪些属于本地表中并定义变量名。在定义数据的引用关系时，要符合规约： 对于每一个步骤的输入数据，都要在本地或者从全局表里进行引用。 所有输出数据，都先输出到本地，然后在全局表里进行引用。 对于多个动作需要使用的数据或者在每次测试时都要改变的数据，都要放在全局表里，并从全局表引用并加以使用。 为了方便测试报告产生，建立一个全局输出表。 对于输出的数据，必须在变量名上表明是从哪个步输出的，以便于跟踪。图2：数据引用关系在编写测试案例时，
31、应写清所处的屏幕状态，步骤，输入数据，输出数据。对于一些可选的步骤（也就是，可能会出现，可能不会出现的步骤）用绿色加以标注。图3所示的是在整个测试过程中，全局预输入变量，命名都以 GL_IN_XXXXXXX(Description)。对于日期更要加以注明，由于在SAP系统中对于时间的检查非常严格，关系到合同是否能生成等等。图3：全局输入数据表3 所示Amendments的详细测试案例。它所执行的任务是缩短售后服务。在测试案例中每个步骤要写得尽量详细，这样能确保测试人员不会因为误操作而导致测试假失败。 表3：详细测试案例Step No.ScreenDescriptionInputOutput00
32、0SAP Easy Access1. Transaction code set VA422. Click Enter010Change Contract: Initial Screen1. Enter corresponding data2. Click EnterGL_OUT_016_Contract_01020Information1. Click Enter030Change Renewal/Limited Auth *: Overview1. Select item 202. Menu Extras Technical objects3. Output functional locat
33、ion and equipment field.4. Click BackGL_OUT_024_Function_Location_01GL_OUT_024_Equipment_01040Change Renewal/Limited Auth *: Overview1. Select item 302. Menu Extras Technical objects3. Output functional location and equipment field.4. Click BackGL_OUT_024_Function_Location_02GL_OUT_024_Equipment_020
34、50Change Renewal/Limited Auth *: Overview1. Select item 20 and 302. Menu Edit Fast change of Contract Data060Fast Change - contract data1. Enter corresponding data2. Click CopyIN_Reason_for_Canc1GL_IN_Request_Canc_dateGL_IN_Receipt_date070Process cancellation data1. Click Enter080Warning1. Click Ent
35、er090Process cancellation data2. Click Enter100Warning2. Click Enter110Change Renewal/Limited Auth *: Overview1. Click Save120Document Lines: Display Messages1. Click Enter130Create Contract: Initial Screen1. Output document number2. Click BackGL_OUT_024_Changed_Contract图4：Global Output表的组成（部分）对于Glo
36、bal Output表（图4)，完全是为了方便声称最终的测试报表。对于这个表的构成，也应该有相应的说明。表中的数据是从每一步所产生的输出中引用过来，并说明其验证条件。4.4 录制和优化脚本由于测试案例对每个步骤的描述非常详细，所以使录制脚本变得非常方便。一般在录制中只要注意以下几个问题，就可以顺利录制脚本： 每次录制前，检查QTP6.0是否设置正确。对SAP的Master Data做检查，使其不出现诸如某些联系人或某些物品不存在的现象。 录制时应做到认真，仔细。 对于录制中系统出现的默认值，应加以清除，并重新输入。如果默认值等于要重新输入的值，也要重新输入。如果某些地方应为空，要加以清空，如果
37、本来为空，也要按Del键，确保QTP能重复该动作。 测试人员录制脚本应一次录制尽量完成对整个流程的录制，不能隔天录制，会造成数据丢失。由于SAP业务流程比较复杂，创建的脚本不可能直接执行（比如有些数据只能执行一次），必须要进行修改和优化。主要是在脚本中添加各种分支和循环结构，将可能出现的步骤设置可选，修改脚本中对象的参数等。修改和优化脚本应主要由有经验的测试员来进行，因为这会涉及到大量的细节。如由于SAP的改变，其GUI的窗口、组件等在标题、名称、位置或行、列值都可能发生变化，因而要清楚如何取舍某些属性，如何认定属性的类型（如强制性的或是可选性的），否则会产生各种问题。图6是一段循环9次的脚本
38、，功能是读取9个不同的物品的Equipment号。图5：优化后的脚本（部分）如图5 Active Screen显示在录制脚本的时候，屏幕的标题是 Change New/Amendment Quote 40248085: Overview但是在下次运行时，报价（Quote）就不是40248085，所以运行脚本时会显示Object cant identify. 对于上述情况，需要对找到该属性，把40248085替换成0-9*8，这样就可以匹配8个字符，这8个字符都是由0-9数字组成的（如图6）。对于一些可能出现的步骤，只要把该步骤变为Optional Step 即可。图6：脚本优化范例对上述测试过
39、程的每一步都作了详细的规定，使得测试员在组织测试时很方便地执行脚本，顺利地进行测试。例如：对于如何确认和报告SAP问题，要求测试员一旦发现问题，立即暂停脚本的执行，并先根据自己经验来排除脚本问题，对于是否是SAP缺陷，必要时送交SAP专家来尽快确定。若是需要报告的SAP问题，测试员要停下脚本的执行，按照统一的格式写出缺陷报告并立即汇报，包括统一的命名、对问题的简单描述、重现步骤或条件和出现问题时的GUI 界面。最后跟踪并确保问题得以解决。图7 所示的是在SAP测试中，缺陷的确认和报告机制。除了得到SAP专家确认的缺陷外，还有很多假缺陷，它们产生的原因大都由于：1. 测试环境导致假失败2. 应用
40、程序改变导致假失败3. 测试错误导致假失败4. 重复失败5. 测试缺陷导致假成功为了预防上述可能发生的情况，需要测试人员非常熟悉测试工具，并做出正确的判断，必要时，可以请教SAP专家。图7：缺陷确认报告机制对于测试缺陷的跟踪，需要测试员每天对所上报的缺陷进行跟踪确认，直到缺陷被修复。4.5 完成最终测试报表把脚本Global Output表输出的结果填入Report 中，即生成测试报告。在测试中遇到任何问题，在SAP专家的帮助下，进行确认并报告。表4 是一份最终报表的范例。表4：最终报表范例Case purpose: The purpose of this case is to test bl
41、ue contract, end-to-end process.Running Environment:NT1Master data used in this scenario:Color Legend:Auto Filling/Check135050457Auto Filling/CheckManual Check by CSSCH5355AManual Check by CSSCManual Check by HPSA3336A, A3499A, A3581A, A3660AManual Check by HPSB3919EA, B3919EA#AGL, B3920EA, B3920EA#
42、ABAC1064GX, C2477SZTest Result:Output ResultInterval 1 Master DataMid Level Functional Location:ML-B-0101-0010Interval 2 QuoteLow Level Functional Location 1:LL-B-0101-0010Quote 1:40248605Low Level Functional Location 2:LL2B-0101-0010Quote 2:40248606Group Contract:60025063Verify channel relationship
43、 has been copied:OKVerify equipment is linked to quote items:OKVerify sales metric code is set to N:OKVerify portfolio ID is S:OKPrint quotationOKCheck PDF symbol in AMPOKCheck PDF files created are viewableOKCheck pricing, tax and discountsOKCheck printoutOKInterval 3 ContractContract 1 (copied fro
44、m quote1)50361767Contract 2 (copied from quote2)50361768Validate billing plan copied from quote:OKVerify channal relationship has been copied:OKValidate AMP link:OKVerify sales metric code is set to N:OKPrint contractOKCheck document flowOKCheck PDF symbol in AMPOKCheck PDF files created are viewableOKTest scanning customer PO and PDF image in AMPOKCheck pricing, tax and discountsOKCheck pri