移动互联网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、刚刚提到更多的工作交给开发来进行，测试的话从哪个层次介入呢，服务端已经有比较多的关于验证数据、功能正确性的了，代码层的是否需要测试人员提供案例呢。 答：建议从两个方便着手，一方面通过自动化不断提高测试能力和测试效率，逐渐尝试将一些稳定、高效的测试手段推荐到开发流程中；另一方面加强沟通努力提高开发同学的质量意识，作为项目团队的共同成员，产品质量和每人都是息息相关的。代码层的测试特别是单元测试一般来说前期投入是比较大的，长期收效才比较明显，从业界来看：大多数意见认为单元测试应该由开发者负责编写，优秀的开发者往往已经有比较完善的单元测试规范，但实际能做到的还不是很多。我个人认为，在业务功能以及基本保证的情况下，测试同学可以主动提供代码层测试的一些案例的。