QA

业务压测设计的心得

很久没更新博客了,原因是……本地有notebook整理资料,processon云工作文档,还有本地导图,各种文档,说实话维护不过来了,应该有一种方式,无感知的积累知识、心得、工作,而不是博客这样刻意去发布。说说正题压测吧   压测方案:如果你没做过压测,可能想的是jmeter、代码脚本开发、各种日志数据排查、压力点分析、统计报告等等……这些都是执行的事,实际上更多还是对业务、服务的调研,结合测试技术、开发技术,综合考虑的一个能发现性能问题的低成本的可执行方案。压测业务链:一般是从某种业务场景开始,分析业务走向,确定链路。确定业务走向后,就可以确定涉及哪些服务,调用方式,

TongDao

TongDao: 1801-测试已严重依赖脚本

16年至17年上半年做app测试时,主要的测试方法是 界面手工:app和Web可视化操作 抓包工具:fiddler抓包自动替换和script脚本 SQL脚本:查询脚本和procedure脚本 日志分析:Linux远程日志,tail和grep命令 17年下半年至18年上半年做服务测试时,主要的测试方法是 apama脚本:简化指令及自动用例的EPL脚本 apama终端:命令行连接apama容器,发送用例事件 Java脚本:对SDK业务请求和数据库查询进行封装,快速执行测试步骤和用例封装 接口调用:swagger业务接口请求 SQL脚本:吃老本写复杂业务和procedure,这次多了很多逻辑处理小进步 日志分析:Linux多了correlator日志,命令多了less 抓包工具:还是fiddler抓包,主要是复用批量请求和修改 已经半年没操作界面测试了,

QA

HLD: 设计评审的CTO简评笔录

总的标准:文档要完全看得明白,不过于依赖讲解 主流程实为业务图,并且没有说明任务类型,是一次性的,还是定时的 主流程环节里的清洗库,没有说明数据库在哪 该文档依赖讲解人,不合格,不能独立阅读理解 同步顺序没有明确先后的顺序 步骤时序图,本质上却是在表达流程图的内容,可以看做是核心流程的流程图 实时监控应说明在主程序之外的,其中异常分支与人工处理之间缺少衔接说明 缺失的合约品种同步,没有说明类型,是一次性的,还是定时的 业务目标没有具体分解到单机的性能目标 Context并行关系没有说明,单机量级没有说明上限 因子计算之前的Context任务控制步骤没有写出来 context到控制,再到因子计算,应该有实例数据量的匹配关系 context消费任务量的方式没有说明,是一次性全处理,还是逐步消费 优化类设计方案,

QA

接口测试:初级接口测试的自定义

今天朋友问起接口测试, *** 10:56:44 AT 我想问你下接口测试都主要测试什么 看哪些东西 回答时顺带回顾总结了一下。 名词:初级接口测试 类型:接口功能测试 范围: 功能实现 业务正确 开发规范 内容: 功能实现,验证前端和服务端接口调试正确 业务正确,验证前端参数正确,服务端处理正确,交互合理 看界面业务发起的请求值是否符合业务 比如筛选某个状态数据,请求时传的状态值正确 服务端返回的数据符合请求的业务 比如返回都是该状态的数据 开发规范,验证服务端的接口设计符合技术部规范 方法命名, 参数命名, 返回的数据格式,

Fiddler

Fiddler工具:解决iOS升级后的https请求抓包和转发

最近遇到iOS测试机抓包麻烦的问题,最初刚用上HTTPS时,用fiddler证书安装解决抓包。随着iOS升级,发现抓不到加密包了。甚至测个小需求还无法转发环境,得找开发打不同环境包。昨晚下班路上念念不忘,本着技术没有解决不了问题的精神,上午来抽空搞定,以下为简单的思路 一、抓包问题: 安装证书 略 https抓包:iOS9.3是可以直接抓到 握手请求和加密请求,但iOS10.3证书机制略有变化,所以需要手动到设置其它里,手动信任一下即可。 二、转发问题: 具体的实施太琐碎了,这里简单说一下思路,和主要技巧 分析https:先http请求443进行握手验证,通过后再进行业务https加密请求 请求剥离:那么对443请求不做转发,

QA

性能优化:事务的批量数据获取主键处理的调优

这次项目优先测底层服务,在第一轮完成数据正确性,数据兼容,服务兼容后,第二轮完成业务测试后,进行并发简单试压测试,分析耗时单个业务在31秒,完全无法上线用。 分析业务过程耗时后,发现有大量的循环单次insert,其中一块用去了29秒多。找开发讨论后,最后确定尝试改底层来实现更快速的实现方法,当然过程中不断否定几种思路。 顺带知道了JDBC这回事,以前一直测没明确概念,这次顺带都了解了一遍。 简单的说就是循环insert为了更好获取主键传递给下一层数据insert,而这样处理无法避免大量insert的业务性能很差很差,解决就是批量获取一次批量insert的所有主键。已有的底层编写是不支持的,开发也坚持这个意见认为无法优化。最终坚持弄明白下,还是找到了方法。

ADB

ADB: Android性能测试

作者:Art_Collector 转载:简书 - Android性能测试 重排:AT 原文内的二次引用 那些年我们用过的显示性能指标 Android客户端性能优化(魅族工程师) 这一次,我优化了37%的内存 Android性能测试之fps获取 Android应用性能测试之CPU和内存占用 android如何查看cpu的占用率和内存泄漏 如何解决CPU使用率过高问题 ADB Shell Commands Android应用性能测试 强烈推荐转载-Android 性能测试 Android 性能测试实践(四) 流量 测试维度 CPU占用率 内存使用

QA

用例设计: 我所理解的测试覆盖层次

覆盖需求: 覆盖需求明文的测试点,还要覆盖需求暗含的测试点。 覆盖业务: 尽管本版改动没涉及,但代码写了什么你并非完全清楚,那么你需要整理并长期演进一套核心业务体系的测试点,由于版本迭代快,所以更多是从业务角度去积累。 如果从系统角度去积累这套用例,也不是不行,只能练练手。因为你会发现,老要去改它以适应每个版本的功能变动。 覆盖技术: app测试就是点点点,但它背后代表了app代码功能和逻辑,手机系统提供的接口处理,service的api接口传返,数据库的增删改查,还有服务器架构的请求负载转发…… 技术的深入并非覆盖更全,而是节省用例和资源。 如果你的功能用例做到科学理论角度的100%覆盖,那么所有问题都会暴露,但是你写不出也执行不到……那就提高技术吧。

SoftWare

Excel: 函数公式自动生成测试报告

核心函数是 counta countif countifs 框架是 用例层:将执行区的用例加入统计字段,比如模块和类型。 配置层:设置各个测试用例字段用到的参数值,比如模块类型优先级的构成,供用例层调用参数值;构造函数对用例进行统计,行成原始数据。这些原始数据将被报告层调用。 报告层:调用配置层的原始数据,通过模板设计与数据调用,自动形成实时版的格式化测试报告。 以上用框架思想玩个文字游戏,来描述怎么用excel设计自动生成的测试报告,哈!

QA

工作心态: 测试的成长与苛刻的任务

测试得快是很容易的,测试得好也不难,但测试得又快又好就很难了。 测试总是面临非常有限的资源,需求很多模糊的,开发提交的晚,开发对业务理解偏差,测试用例考虑不全等等…… 等你完成测试后,可能心生抱怨,测试任务怎么这么苛刻。甚至你想责备一句,谁来做他也做不好…… 建议你这时调整心态,把公司的任务当成挑战,不要去关注是否公平,而是去思考如何改进自己的测试流程和测试技术,更好地完成测试任务。 即使最终你没有完美完成,但每一次任务你都会得到提高。 当时间流逝,等你要离开时,你回首在这的经厉,不再是抱怨和不满,而是成长与感激。 这也正是面试时,为什么求职者对上家公司的抱怨可以看作求职者能力心态不足的一个判断。从上文就可以推导验证这个判断逻辑。 首发于脉脉,为同一作者。

QA

测试流程: 测试快速入门,培训大纲草案

《AT自编:测试快速培训大纲草案》 测试培训目标: 1. 分担主测试人员的测试工作量 2. 尝试为公司培训新人 3. 测试分工协作,实践自己对测试的理解 测试培训计划: 1. 培训:在入职后一周内完成大纲讲解 2. 上手:半个月内执行初级测试任务 3. 产出:融入团队坚持半年测试,形成职业素养 软件开发流程与角色: 1. 提问并了解受训人员对软件开发角色的认识水平 2. 讲解:需求 > 产品 > 设计 > 开发 > 测试 > 运营 测试素养:

QA

测试流程: 快速测试与敏捷测试

原标题《林应:James Bach 的 Rapid Test 培训总结》 AT重新排版 首先感谢阿里巴巴邀请James大神在北京办公室组织了Rapid Test的培训。 本来报名的目的只是想和兄弟部门的同事找机会一起交流交流,对测试本身并没有抱太大的期望。结果课程开始之后,只能说不服不行。另外,哥活生生的被大神当作了教学道具… 虽然James大神脱离项目一线专注培训很多年了,而且也没有互联网项目经验,但是一上来就抓住了问题的本质,项目需求不清楚,进度紧张,资源有限,这都是当年项目情况活生生的写照啊!所谓的Rapid Test就是针对这些问题的。为什么这里不说敏捷Agile?因为这里只谈测试,而且谈的是普遍真理,不管你用Agile还是瀑布流,测试都必须解决的一些共性问题。 培训过程就不具体描述了,这里就谈几点总结

QA

用例设计: 轻视而不写测试文档的后果,走入一片测试陷阱。

记得在学习项目快速入手时,有个步骤叫项目调研,包含了开发阶段,技术和业务优先级,其中技术优先级又涉及了开发人员是老员工还是新员工,开发时,模块是否是重新开发的。这次自以为是,忽略了这个问题,导致后面测试不断给自己挖坑。不由感叹:测试流程上,越是靠前的步骤,即便是一句话的事情,你没有去做,都是有很大隐患的。 那天技术部开会,突然分配给一个测试任务: 是PC的网页产品,而且又是一个开发了多次的老功能,心里不免放松了。 拿到需求看了一下: 首先需求是半成品,只描述了部分的修改,其它需求和设计稿都在开发过程中不断临时追加。给人感觉很随意,而且大多都是提示文字的整体改动,多两个选框…… 其次开发是老员工,对这块功能也是非常熟的…… 最后PC端确实并不受重视 于是我采用了最快速的策略 第一天看完需求稿和设计稿,

QA

性能优化: web前端性能优化概述 by罗少木

本文作者:罗少木 测试技术:测试开发工程师 编者:AT 备注:原文排版略作调整,文字与层级关系无改动。 正文开始==== 前端性能优化方式分:页面级、代码级 1、页面级性能优化的考虑点:   首先、考虑页面数据的来源,是否有来源第三方资源造成性能问题。   其次、定位是由于第三方资源还是本地资源导致性能问题。   最后、可以以下几种方式进行前端性能优化。   1、减少http请求数。     这是众多前端性能优化比较常用的方式之一,解决方案如下所示:     1、简化页面:从设计实现层面简化页面。       如百度页面简洁,减少资源的使用是最直接的。     2、缓存技术:

MySQL

QA: 数据库测试概述:功能、安全与性能测试 by罗少木

原文作者:罗少木 测试技术:测试开发工程师 编者:AT 备注:原文顺序为1性能2功能3安全,个人将之改为1功能2安全3性能,文字内容无修改 =正文开始= 数据库测试: 1、从功能的角度分析数据库测试:   1.1、界面功能在进行操作时,数据库后台的多张表数据会发生变化,需要测试人员去后台查询数据的正确性。     注:尤其是数据库表中非界面可见的字段,比如注册时间字段,由后台代码自动生成数据填入格,这些字段需要测试人员构造各种情况进行模拟检查是否正确   1.2、后台数据库的存储过程、触发器的测试,检查sql语句内部逻辑是否都正确   1.3、数据库约束测试:外键约束、

QA

测试流程: 新手入行对测试流程的实战理解

对于测试入手 刚开始测,面临问题有三个。测试范围,优先级,业务操作不熟。 对于业务熟练,只能自己勤快,多操作产品。熟悉是很快的,但是面对陌生枯燥的东西,最难的不是脑子够不够用的问题,而是要先克服瞌睡,提高自己的兴趣和专注度。一周后你感觉已经很熟悉这个产品了,然而随后的几周里,仍会陆续发现一些你遗漏的地方…… 测试优先级是容易忽略的问题。假如给你2天时间包括学习需求,编写用例,测试执行,bug报告,bug追踪,类似这样时间不够的情况很常见。那么你就需要考虑到验收时再去修复严重bug的风险,以及开发在等待bug去修复的闲暇。他们不让你闲着,你也尽量不要让他们闲着,自然就要优先测复杂的核心的改动,尽量测试与修复更高效地协作,提高团队效率,缩短周期。时间就是金钱,