前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >腾讯TMQ沙龙|移动互联网APP应用的服务端测试方案和实践

腾讯TMQ沙龙|移动互联网APP应用的服务端测试方案和实践

作者头像
腾讯移动品质中心TMQ
发布2018-02-06 14:42:15
9620
发布2018-02-06 14:42:15
举报

移动互联网APP应用的服务端测试方案和实践

活动时间:2016年9月8日 QQ群视频交流

活动介绍:TMQ在线沙龙第八期分享

本次分享的主题是介绍移动互联网APP应用的服务端测试方案和实践相关的知识。

共有106位测试小伙伴报名参加活动,在线观看视频人数60人~想知道活动分享了啥吗?往下看吧!

活动嘉宾

嘉宾简介

崔杰,腾讯高级测试工程师,负责过腾讯地图和路宝产品测试,目前主要负责地图后台服务的相关测试工作。有多年服务端测试实践和测试开发经验。

分享主题

  • 服务端测试概念
  • APP下的服务端测试
  • 常见测试类型
  • 测试方案概述
  • 测试实践简述
  • 总结和展望

问答环节

1、提问:如何不仅仅停留于业务层面的测试,如何做到关注开发的设计和实现 答:其实这个问题,与我们提出的“测试左移”是相关的,传统的测试仅仅停留在业务层面。将传统的编码之后再测试,调整为让测试参与到coderewiew,设计阶段,甚至是需求分析阶段。这个时候我们各团队之间不应该解耦,反而是应该增加团队之间的耦合度。从需求评审一直到软件运行维护,测试团队参与其中。 首先.从开发那里拿到详细设计文档,既是对项目的学习,也是对文档rewiew。 其次.要提升自己的代码能力,可以先梳理出代码模块数量,模块功能,以及模块之间的调用关系,形成完整的函数库,这个对后面的迭代回归帮助非常大。比如开发修改了哪里,我只需要将这个相关的模块回归就可以了,不需要全量回归。 最后.如果可以从开发那里拿到开发的自测用例,这个也是体现出你的重点测试工作。因为没有谁比开发更清楚代码的修改和实现。 2、提问:项目时间比较紧的情况下,客户端和服务端同时提测,甚至客户端比服务端早提测。客户端和服务端怎样协作测试呢? 答:这个适合进行分层测试,需要明确前后端的接口规范和使用场景,在一方不具备可测条件时,完全可以考虑先通过mock的方式,对另一端开展测试。当然,项目整理完成后的联调验收测试也是必不可少的。 3、提问:性能测试的做法 答:性能测试过程大体分为以下几个步骤: a. 需求确认: 明确被测对象、部署环境以及QPS预期等; b. 测前准备: 测试工具、测试数据、监控工具的准备; c. 测试执行: 发送压力、收集数据、发现和定位缺陷 d. 缺陷跟踪: 跟踪缺陷、回归验证 e. 测试反馈: 整理测试数据、输出结果 4、问题: 是分支开发好还是主干开发好?之前说的是分支开发模式,feature、fix都是开分支来进行,导致最后合并冲突的时候需要处理的冲突量很多。有考虑过主干开发的实践么? 答:两种开发模式各有利弊:主干开发管理简单、迭代速度有优势,不足是出现问题会影响其它功能;分支开发模式适合同时开发多个功能,减少功能开发过程中相互之间影响,不过代码merge过程可能代价较大。 在持续集成中是鼓励“小步快跑”的主干开发进行快速迭代的,但对产品需求稳定、代码质量、自动化手段都有着比较高的要求。 5、提问:能否解释一下测试左移? 答:我们要理解什么是“测试左移”就需要首先明白整个软件的生命周期,“测试左移”就是基于软件生命周期提出的新的测试思路,简单来说就是提前介入软件生命周期,把测试由被动变为主动。一般的软件生命周期分为三个时期,软件定义->软件开发->软件维护,这三个时期又可以分为具体的八个阶段:问题定义->可行性研究(可行性研究报告)->需求分析(软件需求规格说明书)->概要设计->详细设计->编码和单元测试->综合测试->运行维护,从这八个阶段来看,我们传统的测试思路就是测试阶段被动跟在编码之后,这样的做法存在一些不足,测试成本会比较高,比如沟通成本、时间成本、bug修复成本,漏测风险增加,而新的测试思路“测试左移”,就让tester尽早进入项目,参与到项目的每个环节,比如提前到设计阶段,需求分析阶段,这样的好处是,tester能够充分了解项目的背景,更早的选择测试方案,预留出更充足的测试时间,并且在项目推进的过程中从测试角度提出一些建设性的意见,将一些潜在的风险提前排除。项目风险降低,漏测率降低,bug修复成本降低。同样套用治水理念来解释这个测试伴随项目推进的理念,即“测试左移”理念,测试如治水,宜疏不宜堵。 6、问题:性能测试是怎么做到自动化的?每次迭代的时候,数据准备都是一样的吗,测试脚本也一样吗?只是传入不同的参数,用什么工具呢? 能多介绍一些吗? 答:性能测试自动化主要包括几个环节,1、批量测试数据的准备,量级应该是数万,至少是数千条,2、测试工具选择(现成的性能测试工具配置/个性化的性能测试脚本开发),3、服务器资源消耗监控/统计/分析,4、测试报告产出。性能自动化就是将这几个环节无缝衔接起来,其中批量测试数据准备,这个有线上服务那么直接摘取线上服务日志,这样与实际贴合,测试结果更准确。自己构造测试数据,也要数据的多样性,忌测试数据的单一性。 每次迭代测试数据可以使用之前的。测试工具配置和测试脚本都需要一样,这样才能对被测服务修改的前后做对比。 如果只是传入参数的不一致,那么我建议使用jmeter。其中有一个配置元件->CSV Data Set Config通过csv文件将大量的参数按照格式写到csv文件中即可,具体操作可以找度娘。 有关性能工具,市面上存在很多,五花八门。但是我们主要是用jmeter,apache的ab工具,还有就是自己开发的自动化测试平台(自己动手丰衣足食)。工具不在多,在于能完成任务即可。 7、提问:shell脚本是否可以用python编写的脚本来替代 答:从实现功能的角度来看,python脚本替换shell脚本是完全没问题的。 从使用场景来看,各有不同的适用场合,shell是一种“胶水”语言,特别适合用于系统命令调用、文件管理等,python则是一种编程语言,更适用于需要自己“编”制逻辑的地方。 8、刚刚提到更多的工作交给开发来进行,测试的话从哪个层次介入呢,服务端已经有比较多的关于验证数据、功能正确性的了,代码层的是否需要测试人员提供案例呢。 答:建议从两个方便着手,一方面通过自动化不断提高测试能力和测试效率,逐渐尝试将一些稳定、高效的测试手段推荐到开发流程中;另一方面加强沟通努力提高开发同学的质量意识,作为项目团队的共同成员,产品质量和每人都是息息相关的。代码层的测试特别是单元测试一般来说前期投入是比较大的,长期收效才比较明显,从业界来看:大多数意见认为单元测试应该由开发者负责编写,优秀的开发者往往已经有比较完善的单元测试规范,但实际能做到的还不是很多。我个人认为,在业务功能以及基本保证的情况下,测试同学可以主动提供代码层测试的一些案例的。 9、接口的数据都是自己造的,还是调用之前的接口产生? 答:两种数据都有:复用的接口数据主要用于回归测试和基本功能的验证;新功能验证和异常、边界值测试大多需要自己构造接口数据; 10、mock在接口测试中应该怎么用。mock测试桩的搭建,怎么做? 答:mock主要是在我们测试过程中用来模拟那些未完成、不容易构造或者比较复杂的对象。在我们的产品测试中涉及到的场景:Mock服务端数据方便客户端测试、被测服务多模块间存在接口依赖,而被依赖模块在功能或性能还不完善时需要进行mock。针对http协议接口可以考虑使用fiddler等工具进行mock测试,对于一些服务内部模块的接口我们一般会针对性编写mock测试工具。

主办方 腾讯移动品质中心TMQ 介绍

腾讯移动品质中心-Tencent Mobile Quality Center 它是腾讯最早专注在移动APP测试的团队,在十余年的时间内承担了近十款业界领先产品测试工作,近七年的android及iOS自动化测试项目经验,为腾讯向移动转型提供了多项质量方案和关键专利。想知道腾讯多款亿级APP的品质秘密么?欢迎关注腾讯移动品质中心TMQ公众号,这里有TMQ专家团给您带来的移动测试技术精华。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2016-09-09,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾讯移动品质中心TMQ 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
持续集成
CODING 持续集成(CODING Continuous Integration,CODING-CI)全面兼容 Jenkins 的持续集成服务,支持 Java、Python、NodeJS 等所有主流语言,并且支持 Docker 镜像的构建。图形化编排,高配集群多 Job 并行构建全面提速您的构建任务。支持主流的 Git 代码仓库,包括 CODING 代码托管、GitHub、GitLab 等。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档