@author: penghaibo204
本期导读:本期原创文章为大家推荐一篇安全扫描相关的文章,移动端测试技术也重点关注了安全测试的方法。后端测试技术还是围绕接口测试和压力测试来讨论。本期要重点推荐通用测试技术专栏的精准测试相关的两篇文章,为我们提供了很好的思路。测试杂谈专栏,我们带来两篇测试鸡汤,提醒我们在埋头测试的同时,也要多思考。
原创文章
随着移动互联网的飞速发展,移动端产品满天飞,深入各行各业,移动端安全已经变得跟PC端安全同等重要地位。但由于移动端自身特性,移动端操作系统以及应用程序的安全性做的还不是很成熟。因此,我们在开发移动端App的时候,要尽量多地避免安全漏洞问题。本文主要是从预防的角度出发,介绍一个静态代码扫描工具,在编译阶段来提前发现代码的安全漏洞。
移动端测试技术
自动化测试,从广义上来说,一切通过工具(程序)的方式来代替或者辅助手工测试的行为都可以成为自动化。从狭义上来说,通过编写脚本的方式,模拟手工测试的过程,从而替代人工对系统的功能进行验证。但是随着脚本数量的增加,这种自动化覆盖的方式的弊端也逐渐暴露:执行效率低下,构建成功率低(误报率高),受前端样式变更影响大,外部依赖较多,覆盖能力有限。本文主要介绍了有赞测试团队由原来的黑盒系统级自动化测试向分层自动化测试转变的解决方案。
2)Android APK瘦身之Android Studio Lint (代码审查)
随着项目版本的不断迭代,功能越来越多,很多无效的资源将导致APK变得越来越臃肿。臃肿的APK不仅影响使用,导致下载时间太长,浪费用户的时间,也浪费用户的流量。因此,我们需要对Android APK进行资源瘦身。本文介绍了如何使用Android Lint工具来排查无效的资源,并进行瘦身的思路。
相对其他 Android 性能指标(如内存、CPU、功耗等)而言,显示性能(包括但不仅限于我们常说的“流畅度”)的概念本来就相对复杂。让我们更蛋疼的是,业界对显示测试评估方式也是丰富多样,这无疑更加重了我们对其理解的复杂程度。本文提及四个显示性能指标:FPS,Aggregate frame stats,Jankiness count,SM。然后从三个方面对这几个指标进行了探讨:你是谁——这些指标具体反映了什么问题;你从哪儿来——这些指标数值是怎么得到的;你要到哪儿去——这些指标如何落地来指导优化。
安全测试在移动App的测试过程已经成为必不可少的一个环节。测试人员了解一些安全测试的知识也是必不可少的技能。本文是安卓安全中文站总结的系列安全文章,主要对常见安卓APP客户端漏洞原理进行分析,并给出详细的测试方法。对于安全测试的入门非常有帮助。
虽然iOS系统相比于其他手机操作系统相对安全,但是这个安全并不是绝对的,我一直相信,道高一尺魔高一丈。此文想以实际例子出发,告诉大家,如何去反编译一个app,并且从某个角度来说,iOS没有传说中的“安全”。本文简单的介绍了iOS反编译的方法及展现结果。通过本文,也可以引起我们对iOS app安全的重视。
后端测试技术
1)接口测试理论与实践——PiTest + GT双管齐下,专治各种接口测试
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。因此,在接口测试中我们需要重点关注的是:数据+逻辑。本文结合常用的工具,从理论和实践相结合的方式为我们介绍了接口测试的方法。
Jmeter由于自身框架的局限性,一直被认为不适合用来做大规模并发。但大神们总能利用普通人不了解的特性做出牛逼的事情。本文将从负载测试的角度,描述了做一次流畅的5万用户并发测试需要做的事情。
通用测试技术
在目前的快速迭代开发模式下,测试人员需要不停覆盖不断调整的产品逻辑需求,因此测试用例也越来越庞大了,导致全量测试时间很长,同时发现的问题并不和用例数成正比。以往迭代测试用例更多是功能“点”的覆盖,而不是用户场景“线”、“面”的覆盖。而目前产品经理给出的需求都是增量文档,也就是很难有某个产品的完整需求文档,因此,每次用例更多是功能点的覆盖,比如需求文档里面提到点击某个按钮会有什么变化,那某次用例编写时可能只是简单的覆盖,但这种用例并不完全符合用户实际场景,因此还是可能出现覆盖不完全问题。在这样的问题驱动下,我们必须去思考用例精简和精准测试了。
目前互联网行业基本的开发模型采用的是敏捷开发,其显著特点就是:1.迭代周期短,2.需求经常变更。但是传统的测试模型已经不能满足敏捷的要求了。所以我们必须寻求其他测试方案,使得我们测试工作更加高效,更加便捷,要体现快。本文提出从代码层入手,分析不同版本之间的代码差异,分析出函数的具体功能,记录函数的变更生命周期,建立一套分析函数模型,从而从架构逻辑层了解测试点。
探索式测试探索式测试(Exploratory Testing)是一种自由的软件测试风格,强调测试人员同时展开测试学习、测试设计、测试执行和测试结果评估等活动,以持续优化测试工作。它强调独立测试人员的个人自由和职责,为了持续优化其工作的价值,将测试相关学习、测试设计、测试执行和测试结果分析作为相互支持的活动,在整个项目过程中并行的执行。本文首先介绍了整个探索式测试的体系,然后指导读者如何去具体结合项目进行实践。
4)创业公司如何成功实施持续交付?一个10年测试老兵的经验谈
正如Kurt Bittner说的那样,如果敏捷仅仅是个开始的话,那持续交付则是高潮!现代企业要求软件开发过程保持最大的工作效率,传统的瀑布式开发早已跌入历史洪流,甚至敏捷宣言也已超过10年的历史,软件开发在经历了敏捷开发、持续集成后,正逐步迈入到持续交付的时代。持续交付是持续集成的延伸,强调以自动化、可视化的手段更快的将产品交付到客户手中。持续交付的一个重要衡量指标就是从代码提交直到客户能使用这个功能所花费的时间,通过实行持续交付,这个时间往往可以从原先的几天、几周缩短到几分钟。本文以实际项目为例,与大家一起探讨了实施持续交付的解决方案。
测试杂谈
经常有人在测试论坛上会问这种问题:测试到底要会点什么?每每听到这样的问题,总有一种莫名的感觉涌上心头。如果你真的不知道学啥,请尝试着去解决公司中存在的各种问题,各种痛点。当你用你现有的能力解决不了的时候,你就知道你要学点啥了。当然,如果你连公司存在的问题都发现不了,那你学啥也都没意义了。
测试的核心能力有两个:对需求的理解和把握和对产品失效规律的把握。--我们对需求进行分析,得到产品的测试范围,并确定我们的测试目标(验收标准);结合设计,得到产品的测试重点、测试难点,测试深度和广度。同时我们还需要结合我们对产品失效规律的把握,基于风险来进行测试。我们所有的测试,要"测什么","怎么测",都是围绕上面来进行的,作者认为这才是最核心的测试技术--定好测试策略。总结的非常好,给作者点赞!
网友评论