linux shell读取时间变量命名的日志文件

#! /bin/sh

dirMon=`date +%Y%m`
logDay=`date +%Y%m%d`
logPath=/data/testapp/log/order/${dirMon}/order${logDay}
echo $logPath
tail -200f $logPath

执行这个sh文件查特定目录下的特定时间名log文件,

比如这个jlogn.sh,写完后软连接到/usr/bin/jlogn

rm -f /usr/bin/jlogn
ln -s -f /data/testapp/install/jlogn.sh /usr/bin/jlogn

登录服务器后直接打jlogn就可以查看最新日志了

SVN更新失败,路径乱码,以及提示被锁的解决

问题:在于团队文档协作时,出现过异常操作,导致svn无法本地更新。

分析:报错源在于冲突时本地写了一条待处理queue队列和一条lock锁

解决:

1.下载sqlite3随便存个目录,path添加一下

2.项目svn目录的.svn下有个wc.db,执行sqlite3 wc.db,进sql命令行模式

3.删除队列记录:select * from work_queue;就是队列记录,里面就有刚才失败有关的那条,delete from work_queue;就行了(强迫症要精确删的话,加条件)

4.删除锁记录:select * from wc_lock;delete from wc_lock

5.再次更新,一切搞定

Python logging 日志重复记录的原因是handler被重复叠加了

1.使用if not _logger.handlers来控制是否操作addHandler,
假如已有handler,就不需要再次添加了

2.实现方法还有很多,最笨的就是用不同的object来写不同的日志,但这样一旦需要维护时,成本会很高

3.还有一种是 一直在传递main启动脚本时创建的logging Object到class里使用
但是这样写class就感觉很怪了,这个class被某个参数给拖住的感觉

殊途同归,它的最终切入点就是搞定记录日志时,handler不会被重复加入

_logger = logging.getLogger(‘Order’)
# print(‘创建_logger时的handlers:[{}]’.format(_logger.handlers))

if not _logger.handlers:
_logger.setLevel(logging.INFO)
_formatter = logging.Formatter(‘%(asctime)s %(name)s/%(levelname)s %(lineno)d: %(message)s’, datefmt=’%m-%d %H:%M:%S’)

_fhDay = logging.FileHandler(filename=_logDay, encoding=”utf-8″)
_fhDay.setLevel(logging.INFO)
_fhDay.setFormatter(_formatter)

_fhAll = logging.FileHandler(filename=_logAll, encoding=”utf-8″)
_fhAll.setLevel(logging.INFO)
_fhAll.setFormatter(_formatter)

_logger.addHandler(_fhDay)
_logger.addHandler(_fhAll)

# print(‘返回_logger时的handlers:[{}]’.format(_logger.handlers))

订单自动化:远程输入jlog看到日志,这一刻心情真好

监控隔三差五写一小时,经历半个多月,终于完成了订单自动化

远程登录ssh
1. 路由转发设置
2. 旧电脑改造为centos

python自动化脚本
3. 部署python3.6环境
4. 部署项目
5. 使用cron调度
6. 重构代码适配cron运行方式

查看日志
7. 编写shell脚本快捷命令
8. 用过jlog命令可以快速查看运行日志

远程登录后,jlog看到自动化在默默地跑,心情好!

CentOS7搭python3.6流水账

01 安装CentOS7 mini

ifconfig # 查看网卡信息
service network restart # 重启网卡
vi /etc/resolv.conf # 修改DNS
vi /etc/hosts # 修改hosts 至少保留127 localhost配置
vi /etc/sysconfig/network # 修改网关

HOSTNAME=centos
GATEWAY=192.168.1.1
NETWORKING=yes
vi /etc/sysconfig/network-scripts/ifcfg-eth0 # 修改网卡设置
BOOTPROTO=static # 静态static 动态dhcp
ONBOOT=yes # 开机启动
IPADDR=192.168.1.2 # 静态IP地址
NETMASK=255.255.255.0 # 子网掩码

yum -y update # 更新

02 配置SSH终端

yum -y install openssh* # 安装SSH
service sshd start # 启动SSH
chkconfig sshd on # 开机启动SSH
路由设置端口转发,定义外网端口号,指向内网IP的22端口,实现远程ssh

03 安装依赖组件

yum install gcc zlib* wget openssl-devel bzip2-devel expat-devel gdbm-devel readline-devel sqlite-devel # make依赖gcc,其它用于pip

04 安装Python3.6

vi /usr/bin/yum # 第一行改为老版本号
wget https://www.python.org/ftp/python/3.6.0/Python-3.6.o.tgz # 下载源码安装包
tar xvf Python-3.6.0.tgz # 解压缩
cd Python-3.6.0 # 进解压后的目录
./configure –enable-optimizations # 预编译
make -j8 # 编译
make altinstall # 安装

05 配置Python

自己写了初始化脚本jset.sh
其中就有两句是建立python3.6和pip3.6的软连接
pip install requests # post请求模块
pip install apscheduler # 调度模块,其实这个已经不用了,装着玩

06 同步项目代码

启动项目

Python requests 编程实施API自动化 首战心得

1. 自我管理
测试大多时候,总有很多活,比如项目任务,运维任务,加急任务等等,所以如果你能在工作时间写代码就是种幸福了,再次就是加班时间来练代码,最不济的是要在家练。为什么在家练代码最次?因为自我管理太难了。
7天假期实际投入写代码的时间,还不如1天上班通过加班练的时间…

2. 代码规划
没有一蹴而就的代码框架,第一次写完过程,它仅仅实现了基本流。除此之外呢?比如各种异常设计,方法扩展,参数控制,测试扩展…都很弱。而且随着拆分过程封装方法,再不断调试了所有异常,自己还慢慢发现第一版所谓的90%完成度,从后面回看当时,其实最多只有20%这样的完成度。那么一个自动化计划,如何从初版的20%进化到100%呢?通过主动地思考代码的未来场景,不断提高目标,降低完成度。

3. python语言
入行时就憧憬着写python的一天,真的到来时,却是对自己的折磨。不断去克服痛苦和阻塞,查资料实践,不断改进各种逻辑写法,各种代码报错的调试,class调用关系,import的结构,管理变量。对于不健壮的用法,要查很多来鉴别选择另一种更有效的写法。但当你喜欢一件事时,痛苦和困难只是你前进的台阶

4. 开发自测
相比起测别人的代码,自测也很能提高自己的测试思维。自测时,你可以高效预判,直接一针见血让它崩,让它实际业务不走预设的逻辑。很多bug都是,在变量创建赋值的生命过程里,你在不恰当的时机问了个它当时不懂的问题,它萌比了…

5. 框架调度
框架和调度的实现方法有很多,不断分层的架构,通过不同方式来配置参数,扩展case和任务调度。代码运行的方法也非常多,脚本,后台进程,服务,远程指令控制…一开始的想法离最终的使用场景是有距离的,随着成功越来越接近生产,考虑的问题越来越具体。比如实际的case是怎么产生的,是人工配置编写,还是某种场景生成的特定格式文件?扩展时兼容原始case文档,还是要人工编写适配代码的约定规范?这些决定了你的架构设计,调度设计,扩展维护…

6. 自动化思想
自动化经典的一句话是这么说的,将手工操作步骤,写成注释,再编写代码,这就是自动化。而实际上整体实施时,手工操作是需要提炼共性规律,断言本身的正确性,考虑代码成本,运行方式,扩展方式,case特性…实际实施中,自动化会不断具体化,最终形成自己的思路。有什么是不能自动化的?只有值不值得。

7. 心态调整
写代码时,会碰到很多意见。挑战自己,不要抗拒,做不到可以学,别说不行。再一个虽然眼前伸手可见各种成熟框架可以直接用,但个人感觉,还是自己按本意演进,设计一遍后再去研究现有框架比较好。

自动化框架实施过程的心得

写完一个过程,改起来头大;

然后意识到要写成方法,变量及方法名的规划,打乱流程重构,便于拆出并封装类;

然后去了解如何将python脚本的服务化,并对最基础的方法优化,一个方法只做好一件事;

把业务往上抽离,最后分析测试case的共性与实际扩充时的文档特征,对整个框架进行调度设计……

入职一年远离自动化,但坚持技术学习并未真正远离,因为在业务测试和技术架构认识的积累,才能清楚整个自动化框架需要怎么设计

还有很多知识要学以致用

17年伊始,给域名续费2年,继续给自己更新博客的压力

域名在name续了2年,
同时在老薛主机研究了下怎么开ssh
准备安装python3.6,拿来练习运行api自动化脚本
过程写法真是一锤子买卖,完全写完后就再也不想去调试优化它了,等着对象化改造

测试培训大纲:给产品助理做验收测试用的新手简单培训

1.入口:验收邮件的解读
a.确定所验收的项目
b.找到对应的需求和设计稿
c.确定环境:www/cc/215/214
d.确定产品:pc/wap/安卓app/苹果app/微信wap/boss/om

2.标准:验收测试的范围
a.需求功能、UI和文案实现正确
b.常用功能和跳转正常
c.用户体验自然,不含糊无歧义操作便捷

3.执行:验收测试的技巧
a.输入范围:数字字母符号表情这类的等价(内容类型长度)和边界输入
b.业务测试:以数据结果为准
c.测试效率:测试中尽量将问题记录,书面统一提交

4.执行:验收bug的管理:
a.提交渠道:视验收规模,选择口头、群消息、email回复或oschina平台
b.bug跟踪:尽量做到自己所提bug有自己的记录,便于跟踪修复回归
c.bug类型:简单区分下客户端bug和服务端bug
d.bug优先级:应该有产品角度的严重级别,而非测试角度的级别

5.出口:产品验收报告与上线流程
a.验收报告:以邮件回复为准
b.邮件内容:必须包含验收的结论
c.上线流程:测试通过 > 验收通过 > 上线单签字 > 部署上线 > 上线复测
d.验收职责:从提交验收邮件开始,到上线后完成复测才算完成工作