从1开始的python

写在前面：

我打算依然延续着积累学习的态度去做一些笔记来汇总平时工作中的学习轨迹。为什么要开这个系列的笔记的坑？主要目的是希望从工作的角度而不是像课堂学习的路线去认识一门脚本语言。其实我也是从'0'开始接触的python，面向百度编程。但是这个‘0’并不是真正意义上的从0开始，因为在此之前，有做过一段时间的开发工作，所以对这类脚本语言的上手速度会快一点，其他并无任何关于python的基础。与常规的教材从语法开始的角度不同，对于我认为脚本语言属于用多了就能熟练的工具，为了使用工具，去给自己提出的必要的需求，从而深入浅出有编写思路的想法再到组织程序语言的语法细节。往往想法比语言来的更重要，因为前者是需要思维方式的训练，一定程度上属于玄学范畴，而后者各种教材和博客都能找到大量的资源。而作为测试，有自己的想法去从不同角度发现问题很重要，而手中的代码脚本属于辅助实现自己想法的利器，从而脱离重复工作节约时间去启发更多的想法，同样很重要。

为什么选择python，我的工作经验并不是很丰富，从这两三年的工作所使用的语言主要还是强类型语言，最近才开始用python然后因为这工具真的是贼好用，当然有些地方会与其他语言存在不同，偶尔遇到了也是踩坑去比较的。好用的是在于，语法简洁，而且需要使用外部逻辑百度到所需内容看看需要import什么东西直接去执行pip下载就好了，而且资料丰富，因此节约了好多搜索成本。还有就是轻量级，对于辅助工具来说，足够轻量是最重要的，对于我们测试而言，面对不同系统很少能做到一个工具能够在不同的系统上进行复用。测试内容有具有特殊性和独立性，似乎手工测试就足够了，但是由于目前我们存在着迭代，很多时候要保证新功能同时兼顾旧功能，那么如果能将历史手工用例通过代码固化成自动化，对于今后提高版本测试的覆盖面还是有帮助的，从长远来看是可以减少手工执行量，并且提高维护效果，不过这对我们这些测试人员也提出了更高的能力要求：第一，如何从测试的角度去归纳和总结测试过程中可以做成自动化的部分。第二，需要付出额外的精力成本去动态维护测试工程，本身系统迭代过程中很可能随着需求变化，测试的功能点也要随之发生变化，随着脚本量的增加修改删除，如何维护测试工程又是一个比较困难的问题。这意味着我们要像开发一样学会重构自己的东西。第三，是否有可能构建本地的轻量级服务，把常用的底层功能集成到一起，这样在对接不同系统测试时，这是我更进一步的思考，也是今后的尝试方向

回到这次记录的本身，因为之前我在公司写了不少脚本，然后分享给同事们参考使用，由于本身属于额外的尝试并且过程中没有及时沟通和留下文档，所以没有编码经验的同事会反馈比较头大。因此所涉及到的常用功能会结合python语法进行分解，还是那句话，脚本语言属于用多了就能熟练的工具。先从需要什么功能入手，再分解细化到语法。

在此之前，还是需要一点最最基本的语法认识的，这就是为啥题目是从1开始的python而不是‘0’：

if elif else 选择

For 循环 while 循环

Class 类的概念

Int float string 等数据类型的概念，虽然是弱类型的语言，但是在执行过程中尤其数据类型转换是需要搞清楚的

上面的基础语法内容就是从1开始的python，接下来是从功能入手有什么就写什么把先，后续结合代码和示例来做分析和理解，主要都是想到的一些常用功能的实现，也借鉴了很多别人写好的东西。值得注意的是，我们不要拘泥于某一细节内容的过分地追究原理，这就本末倒置了，当前的目的是如何快速的用百度到的写好的内容理解后应用到我们自己的项目中去，当前侧重工作上的应用，重复造轮子是没有必要的。有兴趣就平时自己学习

1.编写JSON配置文件，通过代码读取文件进行可能的操作。例如：根据配置文件，选出配置为true的选项，修改统计数据内容

2.基于1.找出有效的配置项，对数据库进行可能的增删改查操作

3.各种操作完成后，输出格式化的文件CSV，方便尽可能的直观地检查内容

4.接口测试中使用发送http请求，验证不同的场景，由于是自己跟自己玩，所以对端服务在本地实现，具体实现方法到时看吧，但是侧重功能还是作为客户端发送不同的请求

越是看不见的后端，越有操作空间，自由变化的程度就越大，看上去上面的几个功能很简单，但是实际针对复杂的情况下，尤其是第二个功能，业务一旦复杂，多张表存在关联关系，那么脚本逻辑可能就会变得极其复杂，对测试来说也是一个不小的挑战，但是编码其实对于任何我们这类从业人员是不可回避的技能，不如好好正视它

前言就这么多，总之这是一些方便身边没有编码经验同事理解我最近写了些啥的功能的一系列笔记，也不是啥教程，所以仅供参考，也是方便我在公司重复使用代码做的记录，好在公司网络还是可以上CSDN的，毕竟写着忘着再去百度搜也是花不少时间的