【原创】某项目的功能自动化测试计划

[align=center]DRP自动化测试计划[/align]

一、   测试前要求

本部分为对程序的要求，以下只是近期录制过程中发现的一些问题总结，更多的将在以后补充。1）  测试环境要求测试服务器和开发服务器分开，尽量避免在回放过程中由于替换组件而重新启动IIS服务器。最好能有一台机器作为服务器供自动化测试使用。2）  Robot使用内部对象名识别对象，不受对象位置的改变影响，所以要求被测试程序确定按钮名称后不要再随意修改，按钮名称也最好有意义，这样便于脚本的维护。比如：

[align=center][/align]PushButton Click, "Type=PushButton;HTMLId=btDelete"表示单击页面上的删除按钮，对象类型为button，要进行的操作为Delete；PushButton Click, "Type=PushButton;HTMLId=btModify"表示单击页面上的修改按钮，对象类型为button，要进行的操作为Modify；PushButton Click, "Type=PushButton;HTMLId=btSave"表示单击页面上的保存按钮，对象类型为button，要进行的操作为Save；PushButton Click, "Type=PushButton;HTMLId=btSavePrint"表示单击页面上的保存并打印按钮，对象类型为button，要进行的操作为SavePrint；PushButton Click, "Type=PushButton;HTMLId=btExit"表示单击页面上的退出按钮，对象类型为button，要进行的操作为Exit；3）  弹出的msgbox标题和按钮按统一规范，标题和提示信息按实际场景指定，在脚本提交后不要再修改提示之类msgbox的窗体名称及按钮。比如：

    

   由于Robot在识别Msgbox时只识别Caption和Button对象，对其中的提示不会识别。这时可能人工的加入验证点来验证提示性的文字，比如：“请选择客户！”等文字，因此要求在程序中编写此类提示中请按照规范要求做到提示准确，另外使用的标点符号请统一用全角或者统一用半角；程序界面上显示的文字也需要规范，在回放过程中不再对界面是否规范进行验证。Msgbox的标题请在录制脚本前固定下来，不要在脚本录制后再改Msgbox等的标题。4）  各种弹出的窗体尽量给予与所操作内容相符的名称

[align=center][/align] 每个参照窗口最好能够标识所要选择的对象名称，比如上图中最好在窗体标题中加入“客户参照”，窗体的名称应该在录制脚本前固定下来，因为后期如果修改脚本工作量较大。5）  界面上的按钮除“刷新”、“清除（空）”外，单击都需有相应的事件发生，如果无事件发生最好置灰；6）  单据的项目若为系统自动带入的则该控件要么全部置灰，要么全部不置灰，比如单据号；7）  下拉参照的项目如果有编号一般编号在前，名称在后；可以单选或全选的项目要么在备选项中增加一项“全部”，要么增加一项空白项；比如：

[align=center][/align]以上“仓库”下拉框显示是规范的。8）  页面上的按钮文字应该根据其功能进行统一规范，比如上图，相同的两个功能在同一界面上却各有两种名称。9）  有关页面中带表格数据的问题，如图：

[align=center][/align]Robot在录制包含表格的页面时记录的是表格的行号和列号，因此要求如果同类的表格比较多在编程时最好统一以上数据的顺序，在修改程序时最好不要修改文字在表格中的显示顺序。10）              弹出界面能在一页显示下的尽量少带滚动条；

[align=center][/align]11）              有关菜单的显示：a、  能在同一页显示的最好在同一页显示，而不要分为多页（菜单中最好不要同时出现上翻和下翻）。b、  能在不同分辨率显示器上显示正常，不被遮挡。12）              Tab键安排顺序：能够在程序中使用Tab键，并且按照从上到下，从左到右的顺序；日期的输入使用Tab键时能够分别转到年月日。

二、   测试思路

以下是我对这次自动化测试的一些具体的想法和做法，其中涉及robot的技术问题已经能够实现，并会最大化地应用在本次测试中。脚本回放过程中可能由于程序错误或脚本问题导致测试不能继续进行或以下流程不能继续进行时进行按钮的测试或进行数据准备。流程的测试暂时选择标准的采购流程，此流程涉及到了采购和库存模块，为此准备的基础数据如果时间充分的可以继续进行其他流程的测试。使用robot建立好基础档案，这部分脚本共享用于后续的按钮测试和流程测试。按钮的测试尽量带入数据测试，应该能够覆盖到所有可见按钮。按钮测试的覆盖率在未录入数据的情况下达到100％，在录入数据情况下由于情况较多，覆盖率可能大大下降，但尽可能模拟用户数据来进行按钮测试。在流程测试中尽可能地减少按钮的测试以保证缩减每个版本的流程测试周期。在保证主流程脚本回放通过的基础上适当改变流程，以提高流程测试覆盖率。细节：使用robot自动建立的基础档案和机构，然后登录此机构。系统级别的参数依据测试服务器，机构级别的参数按照标准业务流程设置。新的机构中再建立此机构的基础档案信息供流程测试用，基础档案的建立只是基于能够保证流程正常进行即可。为了提高资源的利用，由robot自动生成档案的脚本可以被其他测试人员调用以减轻配置、档案建立等的工作。基本档案保存于Excel文件中，可以根据自己的需要更改其中的值。脚本回放过程中所有录入参数从Excel文件中获取。各种参数也可保存于Excel文件中可用于判断流程的走向。脚本回放中为了保证测试路径运行顺畅不对其中未涉及的部分进行操作，比如：采购业务流程中录入采购申请单后不再做修改和删除的测试，直接进入采购申请汇总并生成订单，要进行这些测试另编写脚本进行测试。1、  准备基础档案用于后面的流程测试；2、  各种单据均准备数张单据：单据日期各不同，供验证查询的正确性；单据的内容除必需项外其他搭配录入以验证单据在被其他单据引用时带入信息的正确性。3、  对于整个流程操作中有多分支的，比如：审核同意和拒绝，在填制单据时生成两张单据，一张审核通过，一张不通过，先走全部通过的流程，然后再走不通过的流程。最后到都生成等价的单据验证无误后再继续下一步。

三、   需要准备的基础档案（各个流程都要用到的）

基础档案的准备是流程测试的基础，在录制修改这部分脚本时工作量较大，但同时这部分的脚本利用率可能是最高的。系统统参数、业务参数设置a、  系统级系统参数为系统预置，不可更改b、  系统级业务参数为系统预置，不可更改c、  默认业务参数设置为新建立机构提供参数。基本档案a、  商品档案b、  客户档案c、  供应商档案d、  人员档案e、  地区档案f、   银行帐号g、  统计机构h、  付款方式机构建立a、  机构建立参数使用标准流程参数b、  （总部）商品类别选择、(分公司)地区选择

四、   测试环境准备

环境准备：

[align=center][/align]

五、   基础档案准备过程

这里暂时先写出大概的流程，具体的顺序将以新版本为主进行完善。后台管理：设置系统参数、业务参数——>增加商品大类（商品类别）——>设置商品属性——>商品品牌——>商品颜色——>自定义属性——>全局属性——>9001——>计量单位——>增加商品档案——>数据授权（授予商品大类权限）——>增加总部（参数设置）——>商品类别选择——>增加成功——>增加人员类别——>增加客户类别——>增加地区档案——>增加统计机构——>付款方式——>基础档案下发——>下发成功注意：供应商是否统一管理，如果统一管理则业务处理系统不起作用。 业务处理系统：商品档案启用——>增加部门——>授予部门权限和商品类别权限——>增加人员——> 增加操作员并授予功能权限和数据权限——>增加客户档案——>增加审核岗位——>增加运输方式——>供应商档案启用

六、   标准采购流程

[align=center][/align]以下为此流程简单描述：1、录入采购申请单验证点：制单人为当前操作员；申请人可以为空，部门在选择申请人时自动带入；增加表体项目，商品参照商品档案目录，录入数量；日期使用当前日期。数目：40张，数量递增。最小1，最大40。2、采购申请汇总查询条件，录入要汇总单据的筛选条件。3、修改草稿筛选出要修改的单据选择供应商保存数目：10张，汇总条件为单张汇总，多张汇总。获取一张生成的采购订单编号待验证是否真正生成，获取生成变量存放于文件中。生成多张采购订单（供审核和弃审）。4、修改采购订单查询条件：单号为修改草稿时自动生成的单号，从文件中获取，验证点：验证草稿修改后是否自动生成了采购订单。5、录入采购订单验证点：录入采购订单，获取生成单据号，到采购订单中查询是否存在。生成多上张采购订单（供审核和弃审）6、初审采购订单部分通过，部分拒绝。7、采购订单入库验证点：验证所有已审核订单是否能查询到，未审核不能查询到。验证点：不选择仓库不能保存选择仓库后单击保存，保存入库单。8、确认采购入库单验证点：是否只有已经采购入库的才可列出。验证点：是否列示了上一步生成的单据，数据来源是否未“采购订单生成”9、应付款明细表验证点：确认了的采购入库单是否能够在应付款明细表中列出，并且金额相符。10、修改采购订单验证点：查询出审核拒绝的单据修改采购订单修改完毕保存验证点：列表中此单据状态为拒绝已修改11复审采购订单验证点：只能列示审核状态为“拒绝已修改”的单据审核单据【继续走入库流程从7—9】12直接录入采购入库单

七、   时间及计划

主要工作量在脚本录制和修改以及在回放中的完善过程中，在修改过程中需要调用的基本函数。由于本次测试任务较紧，另脚本的录制需在测试进入联调阶段才能进行，脚本的修改和维护比录制的时间更要长一点，加之录制过程中不可测的情况可能会导致脚本重新录入或脚本维护工作量增加而收效欠佳。11月18日至12月1日边编写自动化测试用例数据边进行脚本录制。至12月16日基本完成流程测试脚本。期间如果应用效果比较好适当增加其他流程或模块的脚本录制。

八、   自动化测试用例编写

编写要求：1、符合特定场景，能够容易被robot识别；                    2、为了后续流程的进行，前面需要的单据由最终的要求迭代算出，能够容易被robot识别的单据可以适当多一些，不容易被识别的尽量少或只录一条。编写格式：使用Excel文件，用来存放程序中的参数供robot调用，测试结果也可以写回。另存放要录入的单据，在使用过程中robot调用。具体形式在产品进入联调时确定。Excel文件将形成模板，每个调用脚本的人员的可以使用自己的参数。

九、   测试总结

由于robot对B/S结构产品识别不如C/S产品，所以在录制过程中边录制边总结，另沿用C/S产品中一些可用的经验并在此基础上增加一些比较实用的ROBOT函数库文件。在本次测试中尝试使用数据驱动方法。                                              wyingquan                                          2003年11月9日