代码阅读记录

代码学习碎碎念

20200309 周一

这里记录我对自动化工作的一些思考或者阅读代码的总结，期待能有所提高。

今天阅读了一小部分立保通的代码，到点击报价步骤，加上上次登录、读取数据两部分，已经涉及不少知识。excel的读取，目录的结构安排，页面元素的组织模式，元素的各种识别封装，窗口的切换，句柄的使用等，都可以单独拎出来写一些。写的人确实水平比我高多了，起码换了我，写不了这么多，用时还很长。

这里立个flag，每天阅读一个小功能，写下思考或知识点。

20200505 周二

学习了httrunner有一段时间了，到目前为止掌握的东西还是很少，源码也没开始看。跟着作者一步步实施，学习几个知识点：

1、使用charles抓包，去掉无关的接口。导出需要的接口信息，为.har文件，然后将文件转换为json或yml文件。
2、使用 httprunner 命令，驱动文件进行接口测试，此时的文件未做任何优化。查看测试完成后的web报告。
3、配置 verify: False 变量，当charles运行时也能进行抓包。
4、提取公共变量，如账号、密码以及其他经常使用到的变量，在 config 处进行配置，其他地方需要引用的格式：$变量名
5、用例分层，作者以登录幕布，创建文档为例，首先提取了登录步骤涉及到的api，单独创建一个文件，然后在testcase中，引用了 login_submit.yml 文件，使得用例代码机构更加清晰，容易维护。

接口学习的进度缓慢，没有一个明确的目标以及清晰的执行计划。这样要到何年何月才学习完，难道要全部学完才去面试吗？

不要给自己太多问号，目前的首要任务就是定一个短期计划，也许三天，试一下。

20200507 周四

今晚将 login.yml 与 create_doc.yml 两个案例合并一起跑。主要对 create_doc.yml 进行优化，提取了 base_url，设置了一个通用的参数：menber_id。跟着视频，逐步查找经常出现的参数，并提取出来，使用正则表达式来寻找参数，然后将代码中的具体数值都用参数替换，最终也能运行成功。以前查看报告时，所有步骤都是按顺序依次排列，这次两个案例合并一起执行，报告查看时，login.yml 与 create_doc.yml 案例各自的模块的案例都归并到一起，可读性比之前强，容易区分。

20200508 周五

今晚计划偏差，看了20分钟左右，学到另外一个知识点。当两个案例A,B，A中有变量，需要传递到B中继续使用，要使用export关键字。在B案例的config中，export导出要使用的变量。还有另外一种做法，在B的案例中，使用variables关键字，
variables:
变量:$变量名
使用上面的格式引用变量，就可以在B用例中继续使用A中已定义的变量

20200509 周六

进一步分离了用例，创建文档和创建标题。昨天将两个混合在了一起，且原始代码将创建标题的每个字符都拆开了进行请求，使得不必要的代码有点多，这次将标题合并。昨晚导出变量的学习，有一个重要的点漏了，就是A中必须使用export关键字导出变量，B用例中才可以引用，且引用关键是varibles，varibles放在name关键字下面。
创建标题，set_doc_title.yml作为一个新的用例，引用了create_doc.yml的变量，也提取了title变量，与login.yml,create_doc.yml合并起来一起跑。接下来创建的用例是创建内容，并未实现，到时需要将内容数据化，用数据驱动，执行用例。

20200510 周日

接昨天的学习，今日完成三种不同的数据驱动方式：

  1. 以行方式，将数据放在代码中，列表类型，被调用的用例中，用variables关键字指明了变量，若是赋值，则作为默认值使用。testsuites中调用用例，将数据放在代码中直接传给用例，这样做的好处是直观，一眼就知道数据是哪些，适用于数据较少的情况。
  2. 创建了一个data目录，再创建.csv文件存放数据。使用csv文件时，需要注意数据的书写格式。按照excel中的数据，头一行是列名，在csv文件中，列名之间用英文逗号隔开，第二行写数据，与列相对应，也用逗号隔开且逗号前后不能有空格，对空格敏感。在运行用例前进行调用，格式 ${P(文件的路径，可使用相对路径)},httprunner使用P()方法来调用csv文件。
  3. 在debugtalk.py中创建 类似 get_data() 函数，然后返回数据。在执行用例前使用
    ${get_accounts()} 方式进行调用，注意 get_accounts() 方法中的数据格式与用例需要的数据格式相匹配。

以上是httprunner的数据驱动执行方式，学习完这个阶段的接口测试，作者还介绍了性能测试与接口测试结合，打造了一个测试平台，将两者融合，根据业务场景需要灵活执行不同的测试类型。这一点正是我想做到的，但目标的内容有所不同。测试平台主要是用于功能、web ui 方面的测试，但可以通过Web方式管理数据，环境，修改数据，存储数据，查看报告等内容，这是后面的发展趋势了。多努力找找相关知识，搭建一个，尽量尝试。

20200511 周一

完善了下一步操作，在标题下面，写入了两行内容。在代码中，将实现创建标题后面的代码一并复制到 create_text.yml 文件中，然后再一步步删去不必要的请求。发现有一些是图片，有一些则是记录 log，这些多余的请求删去，可以加快整体的请求效率。

这里遇到了一个问题，在上一个用例 set_doc_title.yml 中，它使用了 create_doc.yml 中导出的变量 document_id ，在 create_text.yml 仍然要继续使用，按照set_doc_title.yml 中的用法，我也它里面 export 出 document_id，在 create_text.yml 中用 variables 引用了变量，但这个方法行不通，variables 在用例中进行声明，是它的作用域只是局部，create_text.yml 中有好多步骤使用到 document_id，所以它在 create_text.yml 中必须声明为全局变量。有一点需要确定的是，set_doc_title.yml 必须导出变量，create_text.yml 才能够使用。于是查询了 httprrunner 的使用手册，找到一个关键字 extract，其中有个说明是 extract 的变量是作用于全局，但并没有具体说明怎么操作，只是给了一个简单的例子。根据 export 的写法，然后既然是用于全局，且必须在请求的结果中提取变量，create_text.yml 的上一个用例是 set_doc_title.yml，于是在这个用例之后使用 extract ，如

teststeps:
-    name: set document title
     testcase: testcases/set_doc_title.yml
     # 这里要使用 document_id 变量的前提，set_doc_title.yml 的 config 中要 exoport 导出相关变量
     # extract 提取变量，这里是全局使用
     extract:
         - document_id

以上面方式声明全局变量，执行 create_text.yml 成功，说明该方法有效，便进行逐个替换。

20200514 周四

12号与14号在力扣上刷了两道题，一道是查找内容，复习了 grep、awk、sed 几个重要的命令。第二道题是匹配有效的电话号码，主要使用 grep 配合正则表达式，使用了两个参数 -E 和 -P 进行解题，其中 -E 参数的执行效率居然快的离谱，几乎没花什么时间，系统显示的是 0ms，虽然消耗内容比 -P 多了0.1MB，但这点开销可忽略不计。网上找了挺多，还是没能找到 -E 与 -P 的执行之间到底有什么差别。

13号，跟着思寒进一步写了点企业微信接口的代码。一开始根据企业微信的文档,以创建部门为例，设定了代码的目录机构，根目录是 test_wework_api ,然后下面依次创建几个不同功能的包：api 对给定的接口获取请求；data 存放驱动的数据；testcase 所有的测试用例都放在这个目录下；Utils 存放一些公共的方法，比如将数据统一转换为 json 格式。

这次联系主要是以创建部门为案例，创建、获取、更新、删除部门等，都有不同的接口与之对应，还有给部门增加不同的人员。部门接口有两个重要的参数

  • corpid = "wwcd0be06e5dd4dfcb"
  • contact_secret = "X-2HlpWySBJX2-62G8GQh0p0i_bVbgE0H5KEp92k1R0"

通过这两个参数构造 url 发送请求，而响应的消息中也包含了一个重要的参数 token，这是进行下一步操作的关键。

20200517 周日

继续完善了企业微信接口测试。把数据格式化成json格式提到了api目录下，创建了一个基础接口文件：BaseApi，BaseApi 创建了方法 verbose()，接受参数 json_object，将接收到的对象转换为 json 格式。而在 Department 类中，继承了 BaseApi，从而可以直接调用 verbose，将数据装换成 json 格式，获取部门列表信息就完成了。

20200518 周一

今天依样画葫芦，完成了企业微信删除部门接口测试。调用的接口与获取部门列表、增加部门基本一致，而参数就只有两个：access_token=ACCESS_TOKEN与id=ID。通过文档还注意到，删除部门存在约束，不能删除根部门；不能删除含有子部门、成员的部门，因此只能通过前面增加部门测试后，继续调用删除测试验证delete接口。

delete接口构造起来相对简单，问题主要还是出在单元测试上，一个是细节问题，一些关键词拼写错误，且校验"errcode"时，是校验数字0而不是字符“0”。起初运行测试时，结果经常报错：api forbidden，hint...接口被禁止，我还以为 contact_secret 这个关键参数过期了，重新获取后再执行也是一样。搜索百度，并未找到答案。然后回到企业微信的API进行查找，发现了一个权限描述，API编辑通讯录：可通过API接口读取及编辑企业微信通讯录。这个不就是与我的报错原因很吻合吗，于是打开权限，再次执行 delete 测试，断言成功。但除了断言 "errcode" 和 "errmsg"，因前面创建部门时可带上参数 id 指定部门号，于是修改了 create() 方法，指定 id 创建部门，在测试 delete 时，指定删除部门后，仍要获取部门列表，再次检验已删除的部门 id 是否还存在列表中。多花了几个步骤再进行检验。

d = self.department.list("")
        dele = False
        for d in d["department"]:
            if d["id"] != 6:
                dele = True
        return dele == True

20200520 周三

今天把力扣shell题库最后一道题，转置文件完成了。昨天采用双层循环未能解答出来，最后的 print 无论放在里层还是其他地方，输出都符合要求。没有办法，看了一下
别人的解题思路，原来我一直对 awk 的用法理解错误。它并不是按列读取，而是按行读取，然后根据空格分离，形成一个个字段。而输出 print $1，虽然看起来像是按列读取了
文件的第一列，实际上还是按行读取，把行内容分解，输出第一个字段，然后再去读取第二行，第二行会覆盖第一行的内容，再分解，再读取第一个字段，直到所有行都被执行完。

第一个用法我用对了，但解题思路方向错了。真正的用法是，首先，遍历 NF,在第一行中遇到第一个字段，就存储到一个数组中，若非第一行，就把读取的字段都和前面的数组一起拼接，再次赋值给数组。当遍历完 NF 时，就会得到 NF 个数组。后面再写一个循环遍历 NF，输出每个数组中的内容，使用的是 print ，它会对不在同个数组中的内容进行换行，从而实现输出要求。

一道题，可以了解到 awk 的很多中用法，而且这道题还不止一种解法。采用 sed 命令进行处理应该也是可行，后面再试验。

下午完善了自己分享的两篇文章《自动化测试-连接oracle数据库》和《自动化测试-发送邮件》，进一步了解数据连接和发送邮件的具体用法。

  • oracle数据库

首先，账号、密码、ip、端口这些参数都要使用正确，不然连接不上，什么都不用做。然后创建连接池，连接数据库，根据具体的使用场景，创建一个游标，
以便根据结果获取不同的内容。python 自定义连接数据库已封装了挺多实用的方法，根据所需拿来使用就好。数据操作完了，就要关闭连接池和数据库。

  • 发送邮件

发送邮件有几个因素需要注意，

  1. 一些关键参数要设置正确：用户名，密码，发件人邮箱，收件人邮箱，服务器地址等。
  2. 测试报告的一些因素要设置：邮件Title、主题、内容、From、To等因素。
  3. 邮件内容格式、编码，若是添加附件，则附件的编码、文本格式等都要设置正确。
  4. 发送邮件主要使用的库或模块：smtplib、MIMEText、MIMEMultipart

20200523 周六

今日进一步完善了18号的企业微信测试内容，增加发送消息接口，并完成了发送消息接口测试。另外调整了一下目录结构，增加了两个目录：it/,主要存放业务类的测试，ut/，
存放对通用函数的测试，比如将内容转化为 json 格式，或用 jsonpath 解析接口返回的内容。新增的两个目录，让整体的结构更加清晰。

昨天看文章时，学到一个做事的方法，就是先初步设计整体的框架，然后从最简单的环节开始设计，先跑通一个模式，再慢慢往里面添加内容。这样的设计方法，与这次学习企业微信接口测试的方法很相似，最初新建了项目 test_wework_api/，在下面就先确认了两个子目录: api/ 和 testcases/ 。选择从创建部门开始做起，于是就先设置4个为实现具体
内容的方法，list(),create(),delete(),update()，搭建了一个最简单的接口框架。然后开始构造接口，从 list() 获取部门列表开始，查询企业微信 API 文档后得知，任何
请求都需要首先获得 token 才可以发起请求，而获取 token 是每个接口第一个必须做的步骤，于是在 api/ 下面建立了 wework/ 目录,专门用于获取 token。

由以上步骤思考到，其实一个复杂的框架都是从简单的地方开始搭建起来，根据需求，需要什么内容就去创建哪些内容，把一个简单的流程先跑通，证明这个模式可行，然后再扩展
场景，依样画葫芦的添加内容。当内容增加多了，为了使得整体结构更加清晰，往后的维护变得容易，就要开始考虑一些额外的工作。比如调整目录，将接口api,数据 data,测试用例，通用函数，测试报告等等模块都划分好。接口测试内容增加多了，各种调用可能就会变得混杂，这是就要提前考虑适时进行重构，提取通用的部分做成一个公共方法，或是使用
PO 模式设计原则指导测试。最近的学习都在尝试从整体上思考布局是否合理，在脑子将目录机构抽象出来，再抽出模块，联系各个模块的关系，然后进入模块中，抽出类和各个函数，忽略具体的实现细节，想想他们实现了什么内容，与其它函数有什么关系，这样一来对整个项目清晰了很多。

posted @ 2020-05-24 00:40  chenzy01  阅读(5)  评论(0)    收藏  举报