《移动App测试实战》之全网详细归纳总结

本文介绍了《移动App测试实战》一书的内容概要,涵盖产品功能测试、自动化测试、性能测试、专项测试、辅助测试方法、质量管理流程、发布过程中的质量度量和推动,以及测试团队的角色和挑战。作者强调了测试开发的重要性,并推荐关注公众号获取更多资源。
摘要由CSDN通过智能技术生成

😄作者简介: 小曾同学.com,一个致力于测试开发的博主⛽️,主要职责:测试开发、CI/CD
如果文章知识点有错误的地方,还请大家指正,让我们一起学习,一起进步。
😊 座右铭:不想当开发的测试,不是一个好测试✌️。
如果感觉博主的文章还不错的话,还请点赞、收藏哦!👍

在这里插入图片描述

阅读本章你将快速了解到《移动App测试实战》这本书的全部内容。

书籍简介

这本书由三位作者:邱鹏、陈吉、潘晓明共同完成,这本书出版于2015年7月,总共有九章内容,接下来小编就用自己的话术以及小编日常的工作总结给小伙伴们分享书中的所有的内容。

第一章 产品功能测试概述

主要介绍了功能测试中的一些实践,包括测试用例的设计和评审,以及测试进度的管理。但是对于中小型企业测试流程来说,可能直接省略测试评审工作。一般情况下我们拿到需求后,开始编写测试用例,而编写测试用例的方式多种多样,可以是Excel、文档、思维导图,在设计逻辑比较强的测试产品时,思维导图有利于梳理测试步骤及测试逻辑,但是在一般情况下,公司对这块的要求不是很强烈,按照公司以往的测试用例编写即可。另一方面,在编写测试用例时,需要考虑的场景比较多,当一个人编写测试用例时,可能会忽略一些细节,所以,文中提到的方式是多个人写测试用例,然后大家查漏补缺,这不失为一个好方法。

第二章 功能测试自动化

介绍了自动化的方法,包括使用 Jmeter 工具做自动化,以及 APP UI层面的自动化,简要的叙述了 Android 和 IOS
中的自动化技术方案。 针对 Android UI 自动化,简单介绍了 UI Automator ViewerAndroid JUnit测试、Instrumentation 测试框架等; 针对 IOS UI 自动化简单的介绍了 Automation
的使用步骤、脚本录制,及Appium框架。在移动APP UI测试中,Appium
是当前比较主流的测试框架,支持跨平台,支持原生和混合开发、支持真机和模拟器。所以本章节可以总结为,作为测试人员需要掌握JMeter接口、Appium
UI自动化测试框架。

第三章 性能测试

介绍了性能测试的方法,包括 Web 前端的性能,为了介绍这部分的性能问题,也介绍 HTTP 协议相关的知识,和抓包工具(Wireshark),还有性能相关的特性,这一块主要介绍了两个方面:

  • HTTP传输过程中的数据压缩,
  • 客户端的缓存,还有web端性能分析工具

具体的内容可以参考这篇文章 http://t.csdnimg.cn/WN2sm
另外在这部分还详细介绍了 Android 和 iOS 性能工具,以及后台服务的性能测试。比如压测、测试数据的收集、产品的主要性能指标、还有关于响应时间的理解等等,做性能测试的小伙伴这块可以详细看下。

相对于功能测试给出一个通过与否的结论,性能测试是一个开放性的问题,需要去探索给出尽量准确的数据来给业务部门提供有价值的参考信息。

第四章 专项测试

重点介绍了几个针对 App 的测试方法,包括兼容性测试,流量测试、电量测试、弱网测试、稳定性测试,安全测试和环境相关测试,有兴趣的可以单独一一学习。

第五章 辅助测试方法

什么是辅助测试??

就是并不直接针对某个功能,而是用横向的维度来分析一些代码和实现中可能出现的共性问题。在这块书中主要介绍了代码静态扫描,代码覆盖率分析、接口 Mock 方法和 AOP 测试方法,这些是测试方法中非常有效的补充,我们称之为辅助测试方法。因为有些方法在现在看来可能还需要进一步研究,有兴趣的小伙伴可以自行查阅。

第六章 发布过程中的质量管理

这部分主要讲述了从测试完成到全量提供给用户使用的过程中涉及的一些环节,以及对应的质量控制和提升的一些实践。提到了持续集成,常用的工具是 Jenkins,对于Jenkins 的使用可以参考小编的这篇文章:Jenkins系列文章;同时也提供了自动化打包及发布环节,详细讲述了原因以及注意事项,针对不同的产品,可能环节还不太一样,所以小伙伴可以参考下流程,毕竟发布过程中的质量管理是很有必要也是不可缺少的。

第七章 质量的度量和推动

对于产品的质量不仅仅是测试的工作,同时也应该是所有部门协作的任务。在做质量时为了更好的改进质量,一般从多个维度来推动:

  • 质量数据的维度
    • 全局统计数据
      • 比如本次提测总共有多少检出bug、修复了多少、遗留bug数是多少等,可以让大家看到一个整体的缺陷情况。
      • 按bug类型来统计
      • 按模块和系统分布情况来统计
      • 按模块缺陷详细统计(严重程度、自测可发现和新引入)
      • 针对一些重点模块或者项目做更深入的分析
      • 基于开发工作量的缺陷统计
      • crash rate数据
        • 区分不同平台,比如:iOS和Android
          介绍了质量的度量和推动方法。包括我们常用的一些质量分析的维护,QA的角色和所做的工作,并专门讨论跨团队的质量推动。

针对上述统计的不同维度的质量分析,需要告诉研发leader,需要他们leader去推动,这样后续的工作才好执行。可以开“站日会议”,这样每天都可以更新进度,还有质量周会,有什么问题可以在周会上提出。一定要大胆提出。

对于QA角色内容这块,本书也提出了一些建议

  • 跟踪研发流程落地情况
  • 测试内部流程执行的情况
  • 组织新版本内测活动
  • 版本缺陷分析
  • 质量推动活动
  • 线上发现的问题的管理
    • QA关注的不只是研发阶段的质量问题,同时也关注运营阶段的质量,更多的是外部用户反馈回来的问题
      • 制定流程规范:包括重大事故管理流程及线上问题处理流程等。
      • 流程跟踪和实施推动:用户反馈及其他渠道反馈等重大问题录入事故管理系统并跟踪推动解决,督促开展事故分析会,对应的责任方需要发出问题根源报告,避免重复发生。
      • 所有问题通过系统或表格记录,每月进行汇总分析,评估系统运营质量情况,也是测试漏测率数据的一个来源。

我们一定要记住质量不是测出来的,一定要督促研发自测。

本章节对于对质量的认知以及 QA 所要做的事情,有了一个明确的定义,值得深思。同时也分享了设计走查,产品走查,但是一般情况下针对小型公司这环节可能就会被省略。

第八章 发布之后的质量管理

介绍了一些发布之后的质量工作,也就是我们经常说的工作闭环,包括继续进行一些模块之间的交叉测试,发现一些之前没有发现的问题。(交叉验证的好处如下)

  • 某个人对一个功能测试久了,很多东西就会觉得习以为常,另外每个人有自己思维的盲点,很多路径考虑不到,测试用例评审也只能帮到一部分。
  • 对于个人的提升也有瓶颈,接触的东西会比较单一,包括技术和业务方面
  • 对所分配的模块通常都会设计用例进行比较系统的测试,反而少了一些探索性的测试
  • 团队成员间对功能模块互相了解不够,遇到边界的问题容易遗漏,也不利于团队的工作轮换和备份机制。

另外,介绍了互联网产品的一些常见的监控维度。重点介绍了适合测试团建开展的接口方面的自动化监控的时间做法。

  • 面向用户的端到端的监控:比较贴近用户
  • 产品中的埋点监控:更细粒度的监控产品质量
    • 后台埋点
    • 网页埋点
    • App埋点
    • 基础运维监控
  • 接口自动化监控等等
  • 相关告警

最后,讨论了关于外部用户问题反馈的收集和跟进的一些常见的做法。

第九章 关于软件测试和测试团队

介绍作者对于软件测试、软件人员以及团队的看法的思考。其中提到了企业希望招聘到什么样的测试人员,大概有三类:

  • 有良好测试开发能力的人:通过测试技术和工具提升整个团队的测试深度和效率是一个持续追求的目标,所有有良好的测试开发能力的人一直都是很紧缺的。良好的代码功底,而且需要有一定的测试思维,最好是有测试平台和工具的开发经验。
  • 资深的业务测试人员,有丰富的业务测试经验、测试设计能力和质量推动能力很好人。测试设计是一项很重要的能力,需要长期的训练和有意识的培养,而且大部分缺陷的发现也非常依赖测试设计的全面性和深度。还需要业务测试人员有全局观察和分析的能力,持续地推动质量而不只是发现bug,所有也需要U对研发流程非常了解,并且有很好的沟通协调和推动能力。
  • 测试团队leader。一个好的测试团队Leader需要有良好的技术功底,还需要有良好的规划能力,能够系统性地考虑团队面临的问题、需要提升的方向和达成的节奏,另外,还需要有非常好的对于人的洞察力,以及沟通和协调能力。

可关注公众号【小曾的IT之旅】回复关键词“测试实战”即可获取。

  • 23
    点赞
  • 30
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小曾同学.com

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值