接口测试考虑事项

在集成测试中首先是确定需要测试模块,集成是将多个模块集合在一起工作,模块与模块之间肯定有工作的接口,你就需要研究一个模块输入输出,研究多个模块的输入输出,构造你如何测试这多个模块输入输出的关系。——-查找各模块的输入输出及关系,编写用例

接口测试主要考虑的问题:

1.各个模块连接集成起来的时候,穿越模块接口的数据会不会丢失; —–确定数据完整

2.各个子功能组合起来,能否达到预期要求的父功能; ——集合后,达到需求目标

3.一个模块的功能是否对另一个模块的功能产生不利影响; ——集成后,不影响相关模块功能

4.全局数据结构是否有问题; ——集成后,保证系统数据的正确性

5.单个模块的误差积累起来,是否会放大,从而达到不可接受的程度。 ——-集成后,确保误差不影响系统功能及性能

Service层接口测试,大致有三种测试类型:接口逻辑测试、出错测试、路径测试

接口逻辑测试,对开发人员输写的JavaDoc进行测试,后根据JavaDoc来编写测试用例(一般情况下JavaDoc需要包含前提条件,业务逻辑,输入参数,输出值的描述),在接口逻辑测试中主要是根据所描述的业务逻辑,进行用例的设计,主要目标是测试在正常输入的情况下能得出正确的结果,测试用例的设计方法跟黑盒测试差不多,主要运用等价类,边界值两种方法。

出错测试,做了接口逻辑测试后,可以正常使用了。为了保证数据的安全,及程序在异常情况的逻辑正确性,因此需要测试出错测试。出错测试主要考虑:空值输入(如当传入一个对象参数时,需进行NULL值的参数)、参数属性的测试(如输入一个未赋值参数)、异常的测试(制造一些异常的测试场景,测试的异常描述是否清晰)

路径测试,经过了上述处理后,单个的接口服务已经得到了保证,但是在业务流中是否满足了业务需求其实还是没有得到保证,路径测试的目的就是设计尽可能少的用例,来保证各种业务场景下数据是安全可操作的。

优测网的手机测试环境搭建

U测环境搭建前,需要保证本地的开发adb环境是搭建好的,即在命令窗口输入adb可以显示以下信息。(adb环境搭建第一篇博客已经介绍过)地址:
http://tech.dev.aixuexi.com/?p=740 有介绍过,成功的标志如下。
图片1
1.进入优测网:
2.登录优测网账号,点击进入云真机-设备分享,点击页面上的使用指南按钮,如图:
图片2
3.进入使用指南页面,如下,按照页面上的操作一步步操作
图片3
4.下载客户端,点击页面上的下载按钮;安装客户端。
图片4
5.安装完成之后,启动UTestClient客户端,输入登录UTest官网的账号。手机连接PC后,打开手机的USB调试模式。客户端命令行提示“手机上报成功”并显示手机基本信息时,连接设备成功。
图片5
6.分享设备在云真机 > 设备分享 > 我的设备中找到正在连接的设备,分享给指定的人或指定的组。
   以上是我们做U测手机测试的环境搭建的步骤,有兴趣的可以按照上面的步骤进行操作。

Fiddler模拟弱网测试

Fiddler模拟弱网

1. Fiddler>Rules>Customize Rules…

1

2.搜索m_SimulateModem, 修改以下参数,并保存

oSession[“request-trickle-delay” ] = “300”;(每上传1KB延迟300ms)

oSession[“response-trickle-delay” ] = “150”;(每下载1KB延迟150ms)

2

3. Save后,之前勾选的Simulate Modem Speeds会被取消勾选,需要重新再勾选回来

3

总结:

千里之行始于足下 !

看有赞测试团队的读后感

看了他们的团队介绍,不由得感叹有赞团队是个很优秀的团队,有很多值得我们学习的地方。
项目流程方面,有赞的测试人员从需求评审开始介入,设计用例,提测用例,用例自动化,到由测试进行发布,全面把关产品质量。而我们的测试多数时间是用来进行功能测试,测完立刻上线,之后用例自动化主要由于鹏进行,很多是上线以后才开始进行。发布阶段,我们是由运维进行发布,并且有些项目的开发到发布测试人员不参与,应该跟有赞一样,由测试人员进行用例编写交给开发自测,这样能提高产品的质量,也能提高开发自己的代码能力。
人员技能方面,有赞测试人员需要具备白盒测试能力、CodeReview能力、业务功能测试,而我们在这方面的能力还有所欠缺,我们也应该提升自己各方面的能力。
我们和他们这样高效的团队之间确实是有差距的。所以我们要吸取对我们有用的经验,提高效率,快速进步。

有赞测试团队–读后感

看了有赞测试团队的分享内容,了解到了团队与团队之间的差别;

1.团队把所有精力都投资在接口自动化层面,有效的减少了ui层面的工作量
youzan1
2.项目周期中,测试人员较早介入
3.测试用例开发人员辅助添加,开发人员应该是最了解业务逻辑及代码逻辑的,会相对容易挖掘出一些隐藏的业务逻辑、或者异常场景;
4.前期的自动化接口测试,有效保证了项目的提测质量,大大缩减冒烟测试,ui层功能测试时间
5.线上监控开发、安全扫描、性能测试能够有效的测出有些手工测试无法达到的测试场景
6.持续集成平台实现了可流程化配置业务应用发布顺序并与测试自动化相结合的工作流,同时提供自动运行及外部触发的运行模式
youzan2
7.测试质量报告及风险评估,可以起到在迭代中加强对某部分功能的关注

《有赞.测试团队介绍》读后感

读完《有赞测试团队介绍》有了一点小感想,之前一直做黑盒测试,公司需要的时候会做一些性能和自动化,还未曾接触过白盒测试。现在测试开发职位也越来越多了,之前也一直苦于没有这样的机会,如今部门日益壮大,测试开发还是很有必要的。希望以后我们的日常工作也能像有赞一样。白盒测试能力、CodeReview能力或许现在我们还不具备,但是我们可以跟部门一块成长,总有一天会越来越成熟。

虽然暂时不能达到有赞的水平,但是我们可以一点点实现,首先做好第一步也就是有赞的2.1,然后在效仿后面的,相信会有很大的改善,让我们一起努力吧!

具体项目测试:

有赞的项目分为标准需求项目、技术重构项目、优化项目、缺陷修复项目。有限的测试资源通过不同策略支持着绝大部分业务产品的测试工作。
第一、对于标准需求项目或者跨多个业务的项目,一定会有测试投入,并且会有一位PTM来协调测试工作。PTM需要确保所有需求点都拆分到各个业务测试同学手里,跟踪相关测试同学按时提交标准测试方案。当测试方案汇总后,PTM需要评估后续测试过程中,测试人员如何投入。即哪些业务的功能测试PTM可顺带执行掉,哪些确实需要对应业务线测试同学来完成,以避免一个项目投入过多测试同学。
第二、技术重构改造项目,这种一般是单应用或者极少应用改造,但不改变业务使用规则。这类项目测试同学只要设计测试方案并完成测试用例落地即可,用例的执行由开发自行完成。测试同学要做的就是对新系统进行自动化覆盖。如有需要,测试会在上线前做质量check。
第三、对于小型项目,如果开发的自测场景与测试同学的测试场景基本一致,那开发自行搞定即可;或者测试同学把需要特别关注的或者风险点给开发同学简单介绍。对于有差异的,测试同学把差异点向开发同学描述清楚即可。
有赞测试同学拿到具体需求后,按照有赞测试对需求分析和测试方案统一要求,完成相关工作。

                                                   有赞.项目协作图

 

 

有赞测试团队读后感想

下边这张图,从需求评审到代码编写再到提测后的测试结束上线,这个来看是相对很完整的一个开发测试流程,从开发阶段到上线阶段,测试人员是不断在跟进,其实这么来做能在提测时解决掉大部分的bug,可以大幅度减轻测试人员在页面功能方面的测试压力,这个是很值得学习的。也能充分深入了解需求,更深入的挖掘潜在的bug,提升产品交付的质量。
1
在文章中也提到了自动化部分,有赞测试团队采用金字塔分层比例的方式来分配自动化涉及部分,从他们的比例来看,和人们所认识的的金字塔有相似有区别,区别在于最底层的单元测试是由开发来做,这个也有好处,开发自身开发的代码,自身最了解,但是也有弊端,自己开发的代码,发现问题也是比较难的。再说接口测试部分,有赞团队90%的精力都在接口层部分,而且还是分接口的上层和底层,这样在开发做完单元测试的基础上,来实现接口测试或接口测试的自动化方式来检测代码的入参以及返回是否是按照预定的要求来返回的。这样就会发现在接口层出现的一些数据传输之间的问题。那么到做UI测试时候大部分就只停留在处理页面一些显而易见的问题了。
2
3
现阶段我们处于一个基本的功能测试以及少部分的页面功能自动化的实现阶段,在后期一定需要改善这种工作模式,接口的测试加入到测试部分,自动化部分能更深入到接口层,更深入的发现更多的问题,更有效的提升测试效率和质量。

《有赞.测试团队介绍》读后感想

何为质量把控?如何进行有效且高效的质量把控?在读这篇文章之前,我对测试的认识还停留在简单的理论认识阶段,了解了有赞测试团队的工作后,对测试组的工作目标有了更加清晰的认识。这个团队对质量把控做到了业内领先的地步。

先来看看他们的项目协作图(与我们团队相关的协作工作日常可以做个比较)

15029627816175

先说协作,他们有“提测用例”,用来检查提测质量,约束研发的产品质量;再说流程,他们有“测试评审”,对测试用例的设计进行检查和规范(他们已经积累了很多规范),将测试这个事情提高到一定高度。此图中没有画出来,但有赞和我们一样,测试组一样会参与需求评审。

再说自动化测试,最打动我的就是这块,此前也看到很多关于自动化测试的理论文章,但没有看到哪一家真的可以落地到这么好的,在实施层面,有赞在自动化测试这块做的很不错。下面是有赞.自动化分布图:

2

这个金字塔下面还有一层,是mock测试,这图没有列出来。

让测试来负责发布,而不再是运维来发布,我觉得这个在当下来说,是非常正确的,符合质量把控原则。这并不是否认运维同事的工作,而是运维同事搭建好自动化发布平台后,有测试组来操作和管理发布。关于他们的发布系统,也有一个亮点,就是合并分支发布。这对“单项目”高频发布的发布系统来说,是个必然的产物,但也是非常有用的产物。

前面都是理论,但工欲善其事必先利其器,没有好用的工具,想的再美好也是瞎掰。有赞在各个环节上,都自研了很多有用的系统,不得不说他们的测试研发团队很强大。

数据,对于质量把控来说,犹如眼睛一般重要。没有数据汇总,没有数据分析,质量把控就会成为盲人过河一般只能摸索前进。这块也是和工具一样的重要。

1505283244927

最后,附上原文链接:有赞.测试团队介绍

有赞测试分享读后感

认清差距,方能追赶

通过有赞测试团队的分享,我深受鼓舞,指明了我们测试组未来的发展方向,让我知道一个测试团队可以做到这么强大。下面我简单分析一下我的看法

1.有赞是一个纯粹的互联网企业,在开发、技术方便很重视,这一点,从测试人员质量就可以看的出来,需要具备白盒测试能力、CodeReview能力、业务功能测试的测试工程师,而且必须是BAT团队出来的。这点我想我们是可以看得出差距的。可是这种人员的差距怎么缩小呢?假设,我们有两种方法:1.统一招BAT团队的资深测试工程师,2.选团队最优测试工程师给整个团队业余时间培训,公司给与支持,然后培养成具备这种能力的工程师。那么我想,第二种方法是最优解,培训成本较低、人力成本低,现有测试人员业务熟练。可以快速介入测试。

2.对于测试日常工作分配,我觉得可以学习有赞团队,将项目细分成标准需求项目、技术重构项目、优化项目、缺陷修复项目。第一、对于标准需求项目或者跨多个业务的项目,一定会有测试投入;第二、技术重构改造项目,这种一般是单应用或者极少应用改造,但不改变业务使用规则。这类项目测试同学只要通过doclever设计测试用例即可,用例的执行由开发自行完成。测试同学要做的就是对新系统进行自动化覆盖。如有需要,测试会在上线前做质量check。 第三、对于线上反馈、缺陷修复项目,如如果开发的自测场景与测试同学的测试场景基本一致,那开发自行搞定即可;或者测试同学把需要特别关注的或者风险点给开发同学简单介绍。对于有差异的,测试同学把差异点向开发同学描述清楚即可。

3.对于测试流程,如果是现在功能测试为主,那现在的测试流程相对之前,还算比较完整合理,但是提测质量不高,所以我们也需要在接口完成时介入编写接口自动化用例,但是有赞团队所说的:“需求分析后,需要输出对象生命周期图、业务时序图、用例图、待确认的问题、风险点清单。并就相关问题、风险与产品、开发进行多次沟通,直到问题得到明确答复。”对于敏捷开发,那启动开发的时间其实很紧急,没有那么多时间去评审风险和业务缺陷,流出更多是时间去写自动化用例兼其他测试项目的功能测试。

4.对于提测分支冲突问题,我们也可以学习有赞团队的搭载公交车发布模式,每一个服务都可以拉出一个test测试分支,所有开发提测时都把自己代码合并到test分支,以后解决bug也要同步自己分支,如果没问题了,可以把自己分支合并master,可以独立上线。

5.对于测试,分为三部分,第一部分是单元测试,这部分属于白盒测试,介于测试代码能力不足,这部分可以由开发自测;第二部分为接口自动化测试,这部分属于灰盒测试,测试会通过开发在doclever写的接口文档编写接口自动化,可以由测试介入进行接口集成测试;第三部分为UI自动化测试,由robotframework实现,同时做手动UI测试,验证功能展示效果和一些边界测试,测试完成后,验收通过上预发布测试,测试通过,上线上正式环境后通过UI自动化测试实现业务全覆盖。

6.对于压力测试,介于对服务器的要求高,所以我们最后通过第三方压测平台实现,如果后期资源到位,可以使用压测工具在测试环境实现。

7.对于线上环境监控,主要又运维来做好,比如宕机监控、服务挂点监控,sql超时监控等等。

好了,罗马不是一天建成的,我们只要重视了,并且有推进,就一定会有成绩,虽然我能力自愧不如,但是我愿意去学习,和测试组一同成长。

 

jenkins的一些其他必要设置(三)

接上次的继续聊…
这次说说jenkins的一些配置
1、先说系统管理中的系统设置
1
点击系统管理后,显示页面,在此页面中可配置需要的JDK、Maven、git等基本信息
2
配置JDK有两种方式:第一种、选择电脑本身已安装的jdk路径
17
第二种、可选择自动安装
3
在git插件安装好后,在此页面会有git配置栏
4
2、接着来配置一个在构建之后自动化发送邮件的基础设置
5
此处设置jenkins地址以及发送邮件人的邮箱
6
点击高级按钮,页面展开,填写以上必要的信息。可使用下边的邮箱验证来进行邮箱是否是通的
7
在具体的项目中,增加构建步骤中选择邮件设置(该选项也是在安装了对应的插件才显示的)
Project Recipient list 一栏填写被发送人的邮箱名称
8
点击advanced Settings出现高级设置
9
添加一项Recipient list后点击高级
10
在此填写相关人员的邮箱名称,以及发送邮件的标题和内容和相应的执行结果页面,点击应用保存生效,此时在giant项目执行之后,就会发送相应的邮件来通知相关人员,此次构建是否成功
3、Configure Global Security设置一项
11
选择随机选取,或者可以指定端口,默认是禁用,这会导致一个问题,随后来解释…
保存后
4、进行管理节点的设置
我们在日常工作中,所看到的晋中、秦皇岛…机器,这这就体现为节点设置,我们现在新建一个节点
进入管理节点后,点击左侧新建节点
12
输入对应的节点名称,选择第一项,点击OK 如果有需要可选择第二项来进行复制
13
填入远程工作目录,启动方法选择…java web start,这个选择项呢是在Configure Global Security设置中选择了指定端口或者随机端口才会出现的,这个有什么作用呢,接着看…
点保存之后,双击该节点
14
此处有两种方式来使用该节点
第一种,复制截图中下边的命令到指定的.bat文件中,可启用该节点(可用于windows或者linux)
15
第二种,点击Launch下载该节点的slave-agent.jnlp文件到指定的地方,启用(适用于windows系统)
16
这两方式都可以指定使用该节点的项目在指定的机器来运行项目。
下次再会…