readme.txt

向好的自动化脚本效果而努力：
一套好的自动化测试脚本达到的效果是：回归测试的时候执行完这套脚本之后得到的信心可以相当于人肉手工回归测试后得到的信心。此外要考虑稳定性（脚本稳定运行是第一要求，不能因为除软件缺陷和变更之外的因素而脆弱的被打破）、可维护性（脚本要能跟的上快速迭代，即上线之日就是新脚本发布之日，这更要求在脚本组织、底层封装上有经验）

****************************************公共部分***********************************************

场景：
... 角色：夜8楼主
... 角色功能需求： 商品不足？
... 想要达到的目的：能取消夜8订单

文件说明：
1.将 自定义库 TestLibrary.py 放到python目录 .\python2.7\Lib\site-packages 下 ；
2.将 test目录，导入到robot中；

test中目录结构说明：
1. 测试项目：存放我们项目测试相关的用例、业务关键字、业务资源；
2. 练习项目：存放一些练习用的模板，及一些新方法新模块的练习记录；

资源及关键字归类：
1.原则上 资源及关键字依据现有 业务模块的菜单划分及操作功能分布，进行类聚；
2.目的：方便功能关键字的查找，和统一维护；

参考：如何编写优秀的用例，http://www.51testing.com/html/73/n-854373.html

****************************************API用例部分***********************************************

API测试项目（目前分为四层）：
1.第一层(报文资源层)，用于记录，和解析接口报文，进行参数化；
2.第二层(基础关键字层)，与资源层进行一一对应，对资源进行封装，简单的进行返回报文处理，和基础业务处理，
  一般只处理对应的一个接口或者业务关系紧密的几个报文；
3.第三层(标准用例或者业务关键字层)
  标准用例层：使用第二层关键字进行业务组合，完成一定的业务流程验证，用例简单直观，有较多的冗余和说明，主要用例新业务的开发；
  业务关键字层：将一段被多次使用的业务流程片段进行有效的组合，避免冗余；
4.第四层(高级用例层)：更多的调用业务关键字，避免冗余，方便快捷的进行分支用例的开发；



3线分离说明：
1. 目的 ：为了可以在同一台测试服务器上同时运行3条或以上的测试进程，并且金额和库存不会相互影响；
2. 3线分离依据：以云店为基准，暂时分为，直营校园店(APIZYYW)、直营办公区店(APIZYBL)、加盟办公区店(APIJMYW)
4. 第4线(APIZYHH)，运行 直营便利店 、直营校园店 交错混合的业务线，如 调拨单；同时用于分离直营校园店用例；
    特征：使用第四线支付账号，使用B类商品，库存会影响两个不同的店

用例：
1. 用例命名，同一个suite中用例不能重名；
2. 业务关键字用例，使用业务关键字来源打头，如：8dol_、YD_、YDapp_  ，YDapp_微仓退货单_库长完结退货单_已完结
3. 数据查询、修改等操作类关键字，使用 sql_ 打头，如：sql_查询加盟总仓完结后佣金ByOrgId；
4. 进行数据验证的用例，使用 “验证_” 打头，如：验证_完结微仓退货单后_加盟总仓账户余额及返点正确；

API业务关键字层命名规范：
1."K_*"  业务关键字名称开头；
2."S_*"  Suite中业务关键字名称开头，此类关键字，仅本suite有效；
2.“_” 以下划线分隔并描述关键字中的主体业务，如：


关键字命名：
内部调用关键字：只在当前资源文件内部被调用的的关键字，该关键字一般在被调用关键字之后，关键字命名前加“_”，如 ：_8dol获取夜8_预生成订单信息_data


关于资源API中变量的识别：
${P_*} 以P开头的变量，都是来源于配置文件的变量；
${S_*} 以S开头的变量，都是用来用例间传值的suite级别的变量；


****************************************APP用例部分***********************************************
APP测试项目（目前分为三层）：
1.资源_业务资源 * 用于存放对应的平台项目业务资源，在考虑到完全按照页面去记录资源，
形成的资源文件会比较多，目前规范方式按照主体层及主体页子层来记录（如：首页、首页_超市、首页_隔日达）；
2.资源_基础关键字 * 用于存放对应的平台项目业务关键字，在考虑到用例层的兼容性，
各平台在业务关键字层输出的关键字要一致（名称、参数、功能要相同）；
3.用例： 包含app终端测试用例和API接口测试用例
用于我们编写的用例，用例会考虑多端（android、IOS、微信、内嵌H5）的兼容性，
只需要修改调用端资源，就可以切换用例测试对象；

APP编写规范
1.资源层定义规则：资源层命名的规则是：8dol_页面_子页面_操作
资源层下面则主要是定位页面的变量，基本是name,id
资源层也可以写一些基本，常用的关键字，主要目的是为了方便复用
2.业务关键字层定义规则：（关键字命名规则，参数定义规则）
业务关键字层命名的规则是：8dol_页面_子页面，原则上与资源层一一对应
关键字描写的则主要是关于页面的一些业务关键字，方便写测试用例的时候调用
业务关键字层一般情况不要定义变量
所有的业务关键字统一加载在一个资源中，方便用例层调用（例：8dol_业务关键字）
3.用例层定义规则：用例层命名的规则：用例的主要名称
用例层下面的case可以有多 个，但每个case最好不是一个独立的个体，而是可以串联执行
suite > test case
4.配置资源定义规则：配置层的变量是关于手机配置，一些公用的变量 (例：android配置)
5.公共方法定义规则：公共方法层关键字则主要是一些所有的app都通用的方法（例：页面加载，滑动页面）