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

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

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

然后去了解如何将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.验收职责:从提交验收邮件开始,到上线后完成复测才算完成工作

M11:2017年自动化python搞起

拖了很久没更新博客了,因为忙?因为懒?因为没料可说?还是要坚持将自己的测试心得写出来,持续更新。

所以不再追求形式,用手机快速更新,养成习惯先,否则都荒废了还谈什么博客内容规划…

1.近来两个月最大的收获是掌握了fiddler的autoresponse的URL和body的正则过滤。
用过配置,能够对于特定的app.api请求可以做到精确控制自动返回值,对于测试一些很难构造的内容帮助很大。这种方法也能够用于过滤后自动断点。
遗憾的是目前还没找到runcomplete的快捷键,每次用命令行的/g或go按钮或runcomplete,感觉还是low,效率低,不直接。

2.再一个收获是能够将Jmeter使用起来,能够根据测试内容来区分开fiddler和Jmeter的使用特点,针对性发挥各自的擅长领域,让专业的软件做专业的内容。

3.现在的用例编写虽然还不能细化到无脑执行,但是覆盖率已经很不错了,每个大项目执行半个月下来,能够感觉到用例的作用和重要性。没有它可以直接预测到会有大量漏测。业务还需要提高,达到极致覆盖

4.数据库已经到了一阶段的瓶颈,再次提高需要一个契机,寻找自己的方向和技术运用场景。目前能够拿起大量的SQL函数使用,精确的写出复杂多表的业务。case,if,left,round,concat,Max用的多

5.python代码已经开始用工作时间去实施了,先从订单接口监控开始,实现实时监控和异常邮件,后续再优化代码结构,实现复用扩展和更完善的监控报告。这要感谢前期的辛苦培养,测试组员能够承担起大部分测试项目,人员调配能够灵活适应。

今年的目标就是玩python

Jootun M08:周末正常休息即是幸福的测试生活

### 【 0. 前言 – 关于博客更新 】

“””
有三个月没更新博客了,因为累懒了,一到周末就想发呆放空。每天除了睡觉就是工作,或者工作的路上,每天与家人的交流QQ聊几句,深夜回家说几句话。看起来很苦逼,也没多少钱,但依然干得津津有味…
“””

### 【 1. 测试 – 关于流程变化 】

“””
1.1 需求用例与测试流程的选择
测试组大多数时间都没有空闲,一直在执行测试。但空闲下来时,就要优先安排组员,获取更新需求文档,学习需求,对于版本迭代项目要进行用例设计,测试报告统计代码调试,以备随时开展测试,随时进行报告。
如果来不及学习需求,也没有用例,提测的小项目相对来说测试效率会低很多,测试出bug的前端后端顺序也会乱,导致代码反复修复。对此,还要不断培训组员,提高全局观,处理提测任务时,要先从技术分层入手,每层再运用测试理论进行分解测试,否则后端没测完,前端也是被动反复修改。
另外来不及学习需求,但提测项目为资金业务,就由我亲自测试,提测后直接冒烟功能流程,然后开始接口测试,检查数据库,然后是事务干扰校验,事务并发,接口并发,最后才是界面UI交互。至于UI展示,也许时间紧最后没测,会交给产品验收。

1.2 运维bug的介入和管理
当这个要求最初提给我时,心情是郁闷的,我只想静静地享受测试和技术,不想跟客服运营市场人员交流。但本着愿意解决任何测试任务的精神,开始了天天解决客服运营们反馈的用户意见。
随着时间流逝,渐渐地也喜欢上这个环节。你可以了解自己所测试的产品真正到了用户手里会出哪些你没测到的问题,可以完善自己的测试视野与用例设计。并且对于产品的功能优先级也有更具体的认识。在分析复测修复这些问题的同时,还能接触很多测试任务范围外的代码。

1.3 日常测试用例与执行
当线上bug的每日处理与测试项目执行,搞得精疲力尽时,公司又提出新的挑战,要每日检查线上核心功能,也就是每天要执行日常测试…
过程的心情是反复的,既要完成测试设计,也要安抚组员,调整心态接纳任务,并保持乐观的心态坚持工作。
最终完成了流程设计,并顺利让每个组员都能独立完成该项工作。

1.4 测试汇报制度的实施
当你觉得自己的工作已经饱满了,迎来了新的挑战,你要对所有项目进行进度管理,你要对这些项目测试情况进行每日汇报,你要对所有线上和日常bug进行每日汇报和持续跟踪…
工作日志的周报也改成了日报…
每个新任务前,你会怀疑无法完成,但你耐心下来发动思考,去完成它,就会获得成长,
所有的任务又再次完成,并对测试组成员进行了更合理的分配,消化了所有新任务。
其中线上bug的跟踪管理的流程设计,让人受益匪浅,感谢技术总监秋天提出的任务。

“””
### 【 2. 数据库 – 复杂SQL语句的实施 】
“””
数据库查询select是测试必备的基本功之一,不管你是做功能测试,还是接口测试,做手工还是自动化,做app测试,还是金融测试…

最简单的是单表查询,条件组合,排序,随着测试积累和业务接触,单表查询的效率和复用性已经无法满足了。开始嵌套,多表关联,多层子查询,甚至为了跟踪数据,优化SQL里的条件,分析关键条件,尽量做到修改一个条件,追踪所有数据,甚至为了维护方便,用起了局部变量…

SQL语句真是丰富,这样还只是初级合格,接下来又接触了SQL效率测试,检查接口的SQL查询效率,慢查询,索引,还有定时任务的测试。为了检查效率,在测试数据库实施了SQL过程,批量造随机数据,并对SQL过程设计了参数,能够简单的传参调用回收脏数据。

在了解更多代码后,编写复杂的多表update语句,控制测试数据的前进后退,随时改回初始状态,随时还原,对于并发测试,事务校验检查,事务并发的测试效率非常有帮助。

任何的改进,都是为了偷懒和快速,随着大量SQL的编写执行,SQL客户端的快捷键设计,与SQL语句归档管理也在不断演变。目标是接到任何测试任务,都是快速定位对应SQL代码文件,执行任何业务SQL,都能快速注释反注释各种条件,快速执行单句,多句,部分SQL,快速建立多个状态演变的查询结果报表。

然而当我看到DBA这个词时,我知道自己还远远不够,需要学的东西还有很多。
“””

### 【 3. 接口与代码 -redis,memcache,dubbo,MQ,zookeeper】
“””
多次的关键资金项目测试,让我获得更多机会了解接口的设计,并发设计,事务一致性,消息队列…当你明白了它们是什么后,测试也变得容易起来。
在测试分成时,天天和开发探讨防并发设计方案,随着各个方案的缺陷分析,最终方案的确立,受益匪浅。
照理说,我已经把这几个单词一一提及,但就写到这里吧。
“””
### 【 4. 结尾感言 】
“””
断了3个月的个人博客,再次恢复更新,并希望自己能坚持下去,对工作,对技术,对自我进行总结和分享。在此也提一下有幸结识的技术达人们,没有先后,随意顺序。
感谢鹤哥每次都耐心讲解技术架构的原理,
感谢杜每次都认真的讲解代码愿意跟我探讨,
感谢周扬让我看到电容测试的谨慎态度,
感谢天枢每次都认真的解释业务的代码流程,
感谢牛魔王每次都很认真对待测试反馈,
感谢太子每次都能不厌其烦地查代码解决问题,
感谢秋天总能在大角度上不断推动测试制度完善,
感谢苏总不断开拓测试组的工作范围和视野,
感谢胡总和宪宇对测试组的宽容支持,
感谢客服部辛苦反馈问题填补测试漏洞,
感谢51那几位测试同学分享如此多的鲜闻,
感谢51商老师开启了我的测试人生,
感谢51姜老师的代码框架启蒙,
感谢51梁老师的项目测试启蒙,
感谢51刘老师的数据库基础启蒙,
“””
能在而立之年,入行从事爱好的工作,真幸福!

Jootun M04:一轮不断的变更,拖着你不断的冲刺

夏天来了,天天上班堵在路上的心情,就像测试一样,变动的需求在不停地堆积,进度就这么堵着,你还只能一脚一脚地跟着,不停地加班加班,从以往上线前加三天,变成了三天又三天……

这次ios做了底层的框架的改动,涉及所有的对外请求,于是就测了所有页面的请求,修复了一个bug,请求成功就意味着新的框架成功了吗?两周后测联系方式正则时,发现加号请求全部失败,折腾了服务端好一阵,最后才找到原因,是ios客户端的加密组件换了,导致请求参数的密钥不一致而请求失败。

凡事皆有两面性,于是对于接口的参数加密和转码这块,我也跟着摸了一遍,对于后续琢磨做接口并发和压力就更清晰了。并发和压力这款,除了线程和结果外,还有就是编写测试数据的接口请求,后来也向总监请教了并发、性能、压力、代码效率、SQL事务锁的区别。app自动化准备放在一边,先从python多线程和接口自动化开始,在这个基础上形成性能和压力的测试思路。

上一期甚觉遗憾的web测试和F12短板,在这一期没有太多运用,测后台时,顺手练了练,仅仅是熟悉了,Network的XHR数据、Throttling构造网速,Resources的cookies清除,Sources的JS断点和修改,Console的js定位和变量打印,Dom元素的检查定位,但离得心应手,游刃有余还差得远了,远不如fiddler用的老练。

带了一位测试新人,从需求、用例、产品业务框架、产品技术框架、测试Bug管理进行了培养,提前灌输了一些数据库、接口的概念,成长很快,新人一个月后已经完全理解这些了。难能可贵的是心态,能够耐心完成测试工作,并且能够应对工作压力。今后也是一位测试好手。

我所理解的测试覆盖的三个层次

  1. 覆盖需求:覆盖需求明文的测试点,还要覆盖需求暗含的测试点,这考验的是业务理解能力。
  2. 覆盖业务:尽管本版改动没涉及,但代码写了什么你并非完全清楚,那么你需要整理并长期演进一套核心业务体系的测试点,由于版本迭代快,所以更多是从业务角度去积累。如果从系统角度去积累这套用例,也不是不行,只能练练手。因为你会发现,老要去改它以适应每个版本的功能变动。这考验的是测试文档的整理能力。
  3. 覆盖技术:app测试就是点点点,但它背后代表了app代码功能和逻辑,手机系统提供的接口处理,service的api接口传返,数据库的增删改查,还有服务器架构的请求负载转发……技术的深入并非覆盖更全,而是节省用例和资源。如果你的功能用例做到科学理论角度的100%覆盖,那么所有问题都会暴露,但是你写不出也执行不到……那就提高技术吧。

Jootun M03:用例已经预见结局……

这是忙碌的一个月,资金业务的改动,随着版本迭代而出,同时开发人员变动,导致接口开发滞后,在资金数据库和APP接口的测试上,花费了大量的精力,而且都是临时的变动任务,无用例打最重要的战斗……

最后赢下了战斗,但输了常规的项目迭代测试,安卓和iOS都漏了一些bug,非需求版本内的bug,而是历史bug。总的来说,用例的积累不足,早已可以预见这次漏bug。

其中一个问题是开发满足产品,重写了全局手势,所有页面的返回都要检查,没有用例积累,也没有整理过app的全部业务路径,最终有3个页面的返回丢失了头部导航按钮……

安卓新写的功能的列表代码,将提示语和按钮放入列表的第一项来处理,导致列表的第一项点击后,对象错误,闪退,有2个地方没测出此bug,在上线前发现……再一个安卓的QQ登录更新了接口组件,安卓开发花了3天没搞定,登录失败。上线前加班搞定……

因为大量的资金业务投诉,导致上个版本的资金流程产品设计失败,仅仅存活半个月就要改掉了。紧急调整,后台、接口、APP相关设计全改,在紧急的项目迭代测试期间,加入了大任务。而且市场已经把新版上线期宣传出去,任务增加一倍,工期不变,赞!个中滋味,全化为个人的成长……

从入职以来,所有测过的项目和迭代都让人沮丧,不是技术,不是氛围,更不是个人的战斗力,而是大量费劲精力开发并测试上线的功能,很多不会存活过2个小版本的周期,也就是1个月,甚至有些功能开发测试完,下个版本立刻弃用……对此我一直在思考去理解,从项目的角度去俯视整个团队的工作。

个人的悲哀对于团队无足轻重,然而公司的投入产出却如此短见,尽管你无需操心公司的财力,但总觉得莫名其妙。

也许再过半年我才能理解,为何要这样反复无规划。

另外值得高兴的是,自己对数据库和接口的测试成长了很多,不足是web项目测试过手的越来越少,对F12的理解停滞不前,借着后台测试,向开发请教了JS定位和代码检查,以及数据返回的查看。

GMD gesture control : 将手势对单个app的无效修改为default时,程序崩溃的Logcat

——— beginning of main

06-13 23:28:21.042 819 24706 D NetlinkSocketObserver: NeighborEvent{elapsedMs=3647330183, 192.168.137.1, [488AD21337DB], RTM_NEWNEIGH, NUD_STALE}

06-13 23:28:25.168 3566 3566 D AndroidRuntime: Shutting down VM

——— beginning of crash

06-13 23:28:25.181 3566 3566 E AndroidRuntime: FATAL EXCEPTION: main

06-13 23:28:25.181 3566 3566 E AndroidRuntime: Process: com.goodmooddroid.gesturecontrol, PID: 3566

06-13 23:28:25.181 3566 3566 E AndroidRuntime: java.lang.NullPointerException: Attempt to invoke virtual method ‘com.gmd.gc.launch.LaunchTypeEnum com.gmd.gc.launch.Launch.getType()’ on a null object reference

06-13 23:28:25.181 3566 3566 E AndroidRuntime: at com.gmd.gc.gesture.CustomGesture.setPerAppAction(CustomGesture.java:1069)

06-13 23:28:25.181 3566 3566 E AndroidRuntime: at com.gmd.gc.gesture.ui.PerAppGestureActionFragment$1$1.onAddLaunchResult(PerAppGestureActionFragment.java:122)

06-13 23:28:25.181 3566 3566 E AndroidRuntime: at com.gmd.gc.launch.AddLaunchDialogFragment.onAddLaunchResult(AddLaunchDialogFragment.java:158)

06-13 23:28:25.181 3566 3566 E AndroidRuntime: at com.gmd.gc.launch.AddLaunchArrayAdapter.onItemClick(AddLaunchArrayAdapter.java:80)

06-13 23:28:25.181 3566 3566 E AndroidRuntime: at com.gmd.gc.launch.AddLaunchDialogFragment$1.onItemClick(AddLaunchDialogFragment.java:124)

06-13 23:28:25.181 3566 3566 E AndroidRuntime: at android.widget.AdapterView.performItemClick(AdapterView.java:310)

06-13 23:28:25.181 3566 3566 E AndroidRuntime: at android.widget.AbsListView.performItemClick(AbsListView.java:1145)

06-13 23:28:25.181 3566 3566 E AndroidRuntime: at android.widget.AbsListView$PerformClick.run(AbsListView.java:3066)

06-13 23:28:25.181 3566 3566 E AndroidRuntime: at android.widget.AbsListView$3.run(AbsListView.java:3903)

06-13 23:28:25.181 3566 3566 E AndroidRuntime: at android.os.Handler.handleCallback(Handler.java:739)

06-13 23:28:25.181 3566 3566 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:95)

06-13 23:28:25.181 3566 3566 E AndroidRuntime: at android.os.Looper.loop(Looper.java:148)

06-13 23:28:25.181 3566 3566 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:5417)

06-13 23:28:25.181 3566 3566 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)

06-13 23:28:25.181 3566 3566 E AndroidRuntime: at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)

06-13 23:28:25.181 3566 3566 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)

06-13 23:28:25.181 3566 3566 E AndroidRuntime: at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:117)

——— beginning of system

06-13 23:28:25.188 819 1280 W ActivityManager: Force finishing activity com.goodmooddroid.gesturecontrol/com.gmd.gc.view.GestureActivity

06-13 23:28:25.290 32329 5593 D DropBoxEntryAddedChimeraService: User is not opted-in to Usage & Diagnostics.

06-13 23:28:25.300 819 6861 I OpenGLRenderer: Initialized EGL, version 1.4

06-13 23:28:25.403 819 828 I art : Background partial concurrent mark sweep GC freed 58535(2MB) AllocSpace objects, 2(40KB) LOS objects, 22% free, 54MB/70MB, paused 1.998ms total 194.744ms

06-13 23:28:25.722 819 836 W ActivityManager: Activity pause timeout for ActivityRecord{7487738 u0 com.goodmooddroid.gesturecontrol/com.gmd.gc.view.GestureActivity t4387 f}

06-13 23:28:25.734 819 567 W ActivityManager: Bad activity token: android.os.BinderProxy@5183f2b

06-13 23:28:25.734 819 567 W ActivityManager: java.lang.ClassCastException: android.os.BinderProxy cannot be cast to com.android.server.am.ActivityRecord$Token

06-13 23:28:25.734 819 567 W ActivityManager: at com.android.server.am.ActivityRecord.forTokenLocked(ActivityRecord.java:424)

06-13 23:28:25.734 819 567 W ActivityManager: at com.android.server.am.ActivityRecord.isInStackLocked(ActivityRecord.java:1121)

06-13 23:28:25.734 819 567 W ActivityManager: at com.android.server.am.ActivityManagerService.getActivityOptions(ActivityManagerService.java:11104)

06-13 23:28:25.734 819 567 W ActivityManager: at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:1734)

06-13 23:28:25.734 819 567 W ActivityManager: at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:2483)

06-13 23:28:25.734 819 567 W ActivityManager: at android.os.Binder.execTransact(Binder.java:453)

06-13 23:28:26.287 12149 24853 D MSF.C.NetConnTag: netRecv ssoSeq:-1060493467 uin:*1999 cmd:-316037937 -1060493142

06-13 23:28:26.296 26509 26551 D Q.msg.TroopMsgProxy: insertToList MessageRecord=friendUin:2181senderuin:6031,istroop:1,msgType:-1000,time:1465831706,shmsgseq:207246

06-13 23:28:28.834 12149 12228 D MSF.C.NetConnTag: pa ok: 61375

06-13 23:28:28.834 12149 12228 D MSF.C.NetConnTag: netSend ssoSeq:61375 uin:*1999 cmd:-2080616503 61600

06-13 23:28:28.919 12149 24853 D MSF.C.NetConnTag: netRecv ssoSeq:61375 uin:*1999 cmd:-2080616503 66036

通过excel的函数,简单构造一个自动生成测试报告的框架

1.核心函数是 counta countif countifs
2.框架是
  用例层:将执行区的用例加入统计字段,比如模块和类型。
配置层:设置各个测试用例字段用到的参数值,比如模块类型优先级的构成,供用例层调用参数值;构造函数对用例进行统计,行成原始数据。这些原始数据将被报告层调用。
报告层:调用配置层的原始数据,通过模板设计与数据调用,自动形成实时版的格式化测试报告。
3.以上用框架思想玩个文字游戏,来描述怎么用excel设计自动生成的测试报告,哈!