概念
测试的流程
一、评审阶段
1.1 需求的评审
一般在需求的评审阶段中,参与者至少会有产品经理、开发、测试。对测试而言,在需求评审中,最需要做两件事情。
- 理解需求:在需求评审阶段就搞懂需求是什么。
- 提出疑问:因为产品的需求也不一定合理,我们要带着怀疑的态度参与到需求的评审当中。对于新人来说,参与需求评审也是一个熟悉业务的好机会。
需求评审阶段,我们需要关注以下相关问题。
- 交付目标:改需求面向的人群是谁?是外部用户、供应商?还是公司内部商务、运营、客服使用。
- 交付计划:需求的上线计划,验收计划,是否灰度,以及测试工作量的评估。
- 业务流程:本次是新增的功能或流程,还是原来业务上新增的节点或者逻辑。
补充知识,灰度:
所谓“灰度测试”,就是在某项产品或应用正式发布前,选择特定人群试用,逐步扩大其使用者的数量,以便机试发现和纠正其中的问题。灰度测试步骤:
- 定义目标,对什么产品进行灰度
- 选定策略:用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
- 筛选用户:用户特征、用户数量、用户常用功能、用户范围等
- 部署系统:部署新系统、部署用户行为分析系统、设定分流规则、运营数据分析、分流规则微调
- 发布总结:用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表
- 产品完善
- 新一轮灰度发布或完整发布
1.2 设计评审
设计评审:开发人员在听完需求评审后,先编好开发设计文档,根据项目的大小是否需要进行设计评审,对于比较大的项目,会和产品、测试进行设计的评审。作为测试而言,设计参与评审一是为了加深需求的理解,二是理解开发的设计,也要注意开发的设计是否合理。
在设计评审中,测试一般需要关注以下相关的问题(不一定全面,可能会存在相关差异)。
- 流程设计图:开发设计的流程图是否能达到产品需求的流程?
- 数据库表设计:是否新增表?是否需要分库分表?如何保证唯一性?表字段默认值?是否需要添加索引?
- 接口:接口层面分为本系统和上下游系统。本系统:新增接口的调用方是谁?原有接口修改后是否影响上下游业务?上下游系统:调用其他系统接口或者被其他系统调用的接口,是否有对接?需要评估是否对接口负载有影响?一般核心域的核心接口,在有新增入参的情况下,也会根据线上情况进行不同入参下的性能测试,评估接口QPS是否能达到预期,防止上线后出现性能问题。
- 组件变更:是否有配置变更,配置的默认值是否合理?是否有环境变量变更?相关组件是否有变更?
- 灰度:是否有开关?灰度方案是什么?是根据用户灰度还是?
- 回滚:如果出现问题,回滚方案是什么?回滚时相关域的回滚顺序是怎么样的?
1.3 用例评审
1.3.1 功能用例评审
功能用例评审:测试人员在编写好用例后,可以通过邮件的形式将发送给对应开发和产品,查看用例场景是否有遗漏。一般开发和产品不怎么看这个邮件的话,就可以抽了十多分钟,拉上会议,进行一个当面的用例评审。
如果是新入职的新人,一般是编写好用例后,先发送邮件给产品、开发,抄送给本组的测试同事,然后再拉上产品、开发进行一个当面的沟通。
1.3.2 联调用例评审
联调用例评审:如果需求涉及到多个系统的话,一般是需要进行一个联调用例评审。评审前一般是会先确定好本次需求的主测试,然后主测会编写好联调文档。
联调用例评审会上会有以下几件事需要做:
宣讲用例:主测宣讲联调的用例,各系统的测试查看是否有场景遗漏,并进行补充。
确定分工:相关基础数据的准备交给对应系统。确定是否有本次需求系统无需变更,但是要协助联调的系统,确定跟进人。
问题记录:对于联调评审中无法确定的问题,进行记录,后续跟进解决。
二、测试阶段
2.1 冒烟测试
冒烟测试:在开发提测后,就进入测试阶段。首先进行冒烟测试,冒烟测试一般需要注意相关问题:
- 静态代码扫描:进行静态代码扫描,是否有blocker、critical的代码。
- 代码编译 & 服务部署:测试分支进行开发代码编译和部署,查看是否能编译和部署成功。且部署成功后,一般会查看环境中服务的日志,查看有无明显的报错日志。
- 冒烟测试用例:首先执行冒烟的自动化Case,然后根据自己设计的冒烟阶段的用例,执行用例并测试。
关于静态代码扫描、代码编译等,需要看所在公司对于相关测试平台的建设。例如我现在所在的公司,就是可以创建一个流水线,其中可以配置下面这些功能:代码编译、单元测试、单元测试覆盖率、静态代码检查、项目打包,镜像烘焙、部署、系统测试(自动化代码执行)。所以一般开发提测后,就是执行一下对应的流水线,查看代码是否能编译通过,静态代码扫描是否有问题,原先的自动化Case中的冒烟Case是否能通过等。
在冒烟测试过程中,我们需要有以下记录:
- 用例上传及执行:上传冒烟测试用例,并在执行用例后,记录为用例已执行。
- BUG记录:如果冒烟Case不通过,提冒烟Bug给开发。
- 工时记录:记录冒烟测试阶段的使用工时。
- 补充冒烟自动化Case:如果是接口域,根据情况看是否需要补充冒烟的自动化AT,有则补充自动化AT,分组设置为冒烟。
2.2 功能测试
功能测试:在冒烟测试通过后,进行到功能测试。功能测试与冒烟测试的不同在于,冒烟测试只是先将主流程走了一遍,而功能测试需要考虑常规情况和异常情况下的所有情况。在功能测试阶段需要注意以下问题:
-
前置准备:准备好基础的测试数据,相关变更需要在测试环境中执行等。
-
用例执行:根据用例设计执行功能测试部分的用例。一般而言,在功能测试阶段,需要调用外部系统服务的话,采用Mock的方式,Mock外部系统的返回,除去Mock外部系统的正常返回,还要Mock超时,抛出异常等异常情况。
-
预期结果:测试用例执行的结果是否符合预期结果。
-
前置准备:准备好基础的测试数据,相关变更需要在测试环境中执行等。
-
用例执行:根据用例设计执行功能测试部分的用例。一般而言,在功能测试阶段,需要调用外部系统服务的话,采用Mock的方式,Mock外部系统的返回,除去Mock外部系统的正常返回,还要Mock超时,抛出异常等异常情况。
-
预期结果:测试用例执行的结果是否符合预期结果。
在功能测试过程中,我们需要有以下记录:
- 用例上传及执行:上传功能测试用例,并在执行用例后,记录为用例已执行。
- BUG记录:如果功能Case不通过,提功能测试阶段Bug给开发。
- 工时记录:记录功能测试阶段的使用工时。
- 补充自动化Case:补充本次需求的自动化Case。
- 功能测试报告:发送功能测试报告,内容包括是否通过?遗留问题及风险点。
2.3 联调测试
联调测试:一般只有当需求涉及到多个系统的变更的时候,才需要进行联调测试。而联调测试一般就是各系统将各自的服务部署再Staging联调环境中后,模拟生产一样,按照联调用例走一趟实际的流程。
在联调测试中,需要关注以下的点:
- 真实数据:联调的数据要是真实的数据,一定不能Mock数据!!!。而且不要直接修改数据库、Redis中的数据
- 核心流程回归:对于原有的核心的流程,也要做到一定程度的回归,防止对原有流程有影响。
- 联调日报:主测需要通过邮件的形式汇报整体联调的进度,以及联调进度的风险、联调发现的问题等。
2.4 回归测试
回归测试:在测试分支进行完功能测试后,在发布上线前,开发合并代码到dev、master分支后,分别进行一次回归测试。回归测试一般需要注意相关问题:
- 回归时间:一般而言,当有一个域需要在明天发布,会在确定今天这个域没有发布、或这个域今天需要发布上线的需要已经上线后,才让开发合并代码到dev分支或者master分支,待合并代码后再进行回归。
- 静态代码扫描:代码依次合并到dev、master分支后,进行静态代码扫描,确保没有blocker、critical。
- SDK升级:本域服务和依赖的外部服务需要升级为正式版,不使用SNAPSHOT版。
- 全量AT回归:针对接口域,会进行全量接口自动化AT的回归,确保自动化Case没有失败的情况下才会进行下一步。
在回归测试过程中,我们需要有以下记录:
- 用例上传及执行:上传回归测试用例,并在执行用例后,记录为用例已执行。
- BUG记录:如果回归时Case不通过,提回归测试阶段Bug给开发。
- 工时记录:记录回归测试阶段的使用工时。
三、发布上线(预发布->生产)
预发布环境连接的是真实生产的数据库,所以回归测试完成后,一般会先发布到预发布环境。待开发、产品验收无问题后,才会发布到生产环境。在这个过程中,需要注意以下几方面。
- 依赖变更:确定相关组件、配置、环境变量是否做了变更。在很多情况下,有些DB变更需要提前做,因为可能有的DB变更需要长达几个小时,如果等到要发布的时候,才想到要变更,可能今天就发布不了了。
- 验收:一般而言,是先发布到预发布环境,待产品、开发验收无问题,才会进行生产发布。如果有问题,重新修改代码再推预发布再验收。生产发布完成后,产品也需要再进行一遍验收。
- 发布顺序:检查发布域的版本号是否为正式版,且要按照顺序发布。发布系统可以做到模块关联,设置某一个域发布完成之后,另一个域才能发布。
发布时间间隔:根据域的重要性不同,生产服务器机器数量也不同,所以发布的时候会设置批次。而每个批次的发布之间,最好进行一定时间的间隔。 - 日志监控:在生产发布的过程中,需要通过日志系统查看有无异常日志,如果出现预期外的异常日志,需要和开发沟通后判断是否需要回滚。
- 告警监控:通过发布系统查看是否有本域告警和上下游告警,如果有,也需要找开发确认是否有影响,再决定是否回滚。
- 回滚:如果出现核心流程的告警,或者不能确定的告警和异常情况下,一般会先直接进行回滚操作。需要注意的是,需要注意回滚的顺序。如果由于回滚前,造成相关异常数据,在回滚后,还需要进行异常数据的处理。
参考链接:https://blog.csdn.net/qq_37688023/article/details/115047532
测试用例怎么编写,用例包括哪几部分的内容
编写测试用例的方向主要从以下三个部分展开:
-
常规思考:
罗列功能点,对每一项功能都做以下正常验证和异常验证。 -
理论角度:
从测试理论角度来思考设计测试用例,熟知的测试用例设计方法有:
- 观察法
- 等价类、边界值
- 判定表、因果图
- 流程图、场景法
- 错误推导法等
- 经验积累:
不断学习、熟悉产品、积累常见的测试用例,例如在一个登录的测试中,需要记住常用的测试用例。
测试用例(格式)一般会包括:
用例编号、测试项、测试标题、用例属性、重要级别、预置条件、测试输入、操作步骤、预期结果、实际结果
bug记录
bug标题、详细描述(含步骤)、项目模块、严重程度、优先级、bug类型、bug状态、提交人、提交日期、附加信息、解决人、解决日期、解决方式、解决用时。
bug的严重程度分为:
- Blocker(有妨碍的): 即系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。
- Critical(紧要的):即影响系统功能或操作,主要功能存在严重缺陷,但不会影响到系统稳定性。
- Major(严重的):即界面、性能缺陷、兼容性。
- Minor/Trivial(次要的/不严重的):即易用性及建议性问题。
优先级划分:
1.Immediate(立刻)
2. Urgent(紧要、优先)
3. High(高度重视)
4. Normal(正常)
5. Low(稍缓)
测试方法和分类
一、从是否关心软件内部结构和具体实现的角度划分
- 白盒测试,关注结构
- 黑盒测试,关注功能
- 灰盒测试
①白盒测试:
- 白盒测试是能够清楚的了解程序结构和处理过程,检查所有的结构及路径是否都是正确的。
- 白盒测试方法有:代码检查法、路径覆盖、逻辑覆盖和条件覆盖等方法。
②黑盒测试:
- 看不到程序内部结构的测试,只能通过检查判断是否按需求说明的正常实现了。
- 黑盒测试方法有:等价类划分法(有效等价类、无效等价类)、边界值分析法、错误推测法、因果图法等。
二、从事构执行程序的角度
- 静态测试
- 动态测试
三、从软件开发的过程
- 单元测试
- 集成测试
- 确认测试
- 系统测试
- 验收测试
非功能性测试方法有哪些
- 安全性:
测试系统遭受内部和外部来源的攻击,是否能正常运行。
杯子有没有毒或细菌。
- 可靠性:
在没有故障的情况下连续执行指定功能的程度。
纸杯用了很多次,都不会坏。
- 易用性:
用户通过与系统的交互可以轻松学习,操作,准备输入和输出。
纸杯用法是否简单,步骤是否难懂。
- 兼容性:
在不同的环境中,是否还可用。
纸杯在夏天和冬天是不是可用。
- 效率:
可以处理的容量,数量和相应时间的程度。
纸杯一次能装多少水。
- 压力测试:
能处理请求的 数量/容量/并发数 极限,引发系统软件的奔溃。
给纸杯不断加压,看达到多少压力,纸杯会穿透。
回归测试
回归测试就是把之前测试过的用例,再重新测一遍,主要分为两类:用例回归、错误回归。
- 用例回归:过一段时间以后再回头对以前使用的用例再重新进行测试。
- 错误回归:在新版本中,对以前版本中出现并修复的缺陷进行再次验证,并以缺陷为核心,对相关修改的部分进行测试。
性能测试指标
包括资源指标、系统指标。
- 资源指标有:CPU、内存、IO、带宽、吞吐量;
- 系统指标:并发用户数、相应时间、事务成功率、超时错误率。
自动化测试缺陷
- 一旦项目发生变化,测试用例就需要改进,工作量大
- 验证的范围有限,操作更加复杂,比如说简单的一个验证验证码,如果是人工识别很快就可以输入,但是自动化测试中会增添很多困难。那么这个时候速度也不如人工。
- 不稳定。
- 可靠性不强。
- 成本与收益。
自动化测试的时候是不是需要连接数据库做数据校验
- UI自动化不需要
- 接口测试会需要
敏捷测试
敏捷测试是测试的一种。
遵循的原则有:
- 强调从用户的角度出发,从用户的角度来测试系统;
- 重点关注持续迭代地测试新开发的功能,而不再强调传统测试过程中严格的测试阶段;
- 尽早开始而此时,一旦系统某个层面可测,就尽快开始模块层面的单元测试,同时随着测试的深入,持续进行回归测试保证之前测试过内容的正确性。
敏捷测试和普通测试的区别:
- 开发与测试并行,项目整体时间较快
- 传统测试强调计划性;敏捷测试强调测试的速度和适应性,不断调整以适应需求的变化。
- 传统测试强调阶段性、流程规范性;敏捷测试强调持续的测试、持续的质量反馈,模糊了阶段性。
持续集成
持续集成的概念是指,频繁的将代码集成到主干。
它的好处主要有两个:
- 快速发现错误,每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易。
- 防止分支大幅偏离主干。如果不是经常集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成。
持续集成的目的,就是让产品快速迭代,同时提高质量。核心举措是,代码集成到主干之前,必须通过自动话测试,只要有一个测试用例失败,就不能集成。
其他持续的知识补充
持续交付
频繁的更新软件版本,交付给质量审核团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。
持续交付可以看作持续集成的下一步。它强调的是,不管怎么更新,软件是随时随地可以交付的。持续部署
持续部署(continuous deployment)是持续交付的下一步,指的是代码通过评审以后,自动部署到生产环境。
持续部署的目标是,代码在任何时刻都是可部署的,可以进入生产阶段。
如何保证测试开发的质量
- 充分理解需求,并将需求转换成测试点,测试点评审无误之后,转换成测试用例,尽量提高测试用例场景覆盖度
- 测试过程遵循实事求是原则,严格按测试用例执行,除测试用例之外,还需要进行随机测试
- 同时严格遵循测试准入准出条件,当bug修复率达到一定程度时才允许入库和上线
怎样才是一个好的测试用例
必须具备以下三个特征
-
整体完备性:
是一个完备的整体,是有效测试用例组成的集合,能够完全覆盖测试需求。 -
等价类划分的准确性:
指的是对于每个等价类都能保证只要其中一个输入测试通过,其他输入也一定测试通过。 -
等价类集合的完备性:
需要保证所有可能的边界值和边界条件都已经正确识别。
场景题
测试从哪几方面考虑
-
功能性:
- 罗列功能,对每个功能点进行黑盒或者白盒测试。
-
安全性:
测试系统遭受内部和外部来源的攻击,是否能正常运行。- sql 注入
- XSS 攻击
-
可靠性:
在没有故障的情况下连续执行指定功能的程度。 -
易用性:
用户通过与系统的交互可以轻松学习,操作,准备输入和输出。- 快捷键
-
兼容性:
在不同的环境中,是否还可用。- 不同操作系统,IOS、安卓还是Windows、Linux
-
效率:
可以处理的容量,数量和相应时间的程度。- 运行速度
-
压力测试:
能处理请求的 数量/容量/并发数 极限,引发系统软件的奔溃。- 最大并发量
- 在最大压力下的运行速度
公司内一直在使用的测试系统(B/S架构)突然不能访问了,需要你进行排查并恢复,说出你的检查方法?
-
检查网址是否有误,如果网络地址无误,换一个网站访问一下,看看是不是自己的网站出了问题。
-
检查是不是“防火墙”程序出错、错误的代理设置导致无法上网?暂时关闭电脑的防火墙,取消一切代理,再试一下网络是否恢复;
-
在 cmd 中使用 ipconfig ,查看 ip地址、子网掩码、默认网关地址。
-
ping 本机回环 127.0.0.1,如果ping不通,那么是自己电脑的 TCP/IP 协议出错,需要重新安装。ping 本机ip,ping不通,则网卡出现问题。ping 服务器ip,ping不通则检查服务器。
-
测试FTP是否正常可以登录,不能登录的直接问空间商那是空间商的问题直接联系他们。
-
空间赠送的三级域名是否能够访问网站打开网站(空间都赠送三级域名),如果也不能访问应该是空间问题。
-
在cmd中 ping 自己的域名,如果看不到IP或IP地址与你的主机地址不符,则说明域名解析有误,是域名的问题得重新解析域名。
测试中发现一个Bug, 但是开发认为这不是一个bug,你应该怎么解决?
先将问题提交到缺陷管理库里面进行备案。然后获取判断的依据和标准:
- 根据需求说明书、产品说明、设计文档等,确认实际结果是否与计划有不一致的地方,提供缺陷是否确认的直接依据;
- 如果没有文档依据,可以根据类似软件的一般特性来说明是否存在不一致的地方,来确认是否是缺陷;
- 根据用户的一般使用习惯,来确认是否是缺陷;
- 与设计人员、开发人员和客户代表等相关人员探讨,确认是否是缺陷;
合理的论述,向测试经理说明自己的判断的理由,注意客观、严谨,不参杂个人情绪。等待测试经理做出最终决定,如果仍然存在争议,可以通过公司政策所提供的渠道,向上级反映,并有上级做出决定。
设计一个登录的测试用例
- 功能测试:正确输入、为空输入、字符类型校验、长度校验、密码是否加密显示、大写提示、跳转页面是否成功、登出后用另一个账号登录
- UI:界面布局合理、风格统一、界面文字简洁好理解、没有错别字
- 性能测试:打开登录页面需要几秒、点击登录跳转首页需要几秒、多次点击、多人点击
- 安全性:用户名和密码是否加密发送给服务器、错误登录的次数限制(防止暴力破解)、一台机器登录多个用户、一个用户多方登录、检查元素能否看到密码
- 兼容性测试:不同浏览器、不同的平台(Windows、Mac)、移动设备能否工作
- 易用性:输入框可否tab键切换、回车能否登录等
App兼容性怎么测,App的接口测试怎么测
- 系统兼容(ios,安卓)、机型兼容(iphtone、华为、小米、三星、vivo、oppo)、分辨率兼容、软件本身向前向后兼容。
- 接口测试:获取接口文档,使用fiddler抓包工具获取接口的请求方式、url、请求参数、返回参数、然后使用postman、jmeter进行测试。
Web 端测试和 App 端测试有何不同
-
系统结构方面
- Web 项目,b/s结构,基于浏览器的;web测试只要更新了服务端,客户端就会同步更新;
- App项目,c/s结构,必须要有客户端;App修改了服务端,则客户端用户所有核心版本都需要进行回归测试一遍。
-
兼容方面
- Web项目:a. 浏览器(火狐、谷歌、IE等)b. 操作系统(Windows7、Windows10、Linux等)
- App项目:a. 设备系统: iOS(ipad、iphone)、Android(三星、华为、联想等) 、Windows(Win7、Win8)、OSX(Mac)b. 手机设备可根据 手机型号、分辨率不同
-
性能方面
- web项目 需监测 响应时间、CPU、Memory
- app项目 除了监测 响应时间、CPU、Memory外,还需监测流量、电量等
-
相对于 Wed 项目,APP有专项测试
- 干扰测试:中断,来电,短信,关机,重启等
- 弱网络测试(模拟2g、3g、4g,wifi网络状态以及丢包情况);网络切换测试(网络断开后重连、3g切换到4g/wifi 等)
- 安装、更新、卸载
- 安装:需考虑安装时的中断、弱网、安装后删除安装文件等情况
- 卸载:需考虑 卸载后是否删除 App 相关的文件
- 更新:分强制更新、非强制更新、增量包更新、断点续传、弱网状态下更新
- 界面操作:关于手机端测试,需注意手势,横竖屏切换,多点触控,前后台切换
- 安全测试:安装包是否可反编译代码、安装包是否签名、权限设置,例如访问通讯录等
- 边界测试:可用存储空间少、没有SD卡/双SD卡、飞行模式、系统时间有误、第三方依赖(QQ、微信登录)等
- 权限测试:设置某个 App 是否可以获取该权限,例如是否可访问通讯录、相册、照相机等
给你一个网站,你如何测试?
- 首先,查找需求说明、网站设计等相关文档,分析测试需求
制定测试计划,确定测试范围和测试策略,一般包括以下几个部分:功能性测试;界面测试;性能测试;数据库测试;安全性测试;兼容性测试
- 设计测试用例
功能性测试包括:
- 链接测试。链接是否正确跳转,是否存在空页面和无效页面,是否有不正确的出错信息返回。
- 提交功能的测试。
- 多媒体元素是否可以正确加载和显示。
- 多语言支持是否能够正确显示选择的语言等。
界面测试包括:
- 页面是否风格统一,美观
- 页面布局是否合理,重点内容和热点内容是否突出
- 控件是否正常使用
- 对于必须但未安装的控件,是否提供自动下载并安装的功能
- 文字检查
性能测试包括:
- 压力测试;负载测试;强度测试
数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性,对数据的存取操作,数据内容的验证等方面。
- 安全性测试:
基本的登录功能的检查
是否存在溢出错误,导致系统崩溃或者权限泄露
相关开发语言的常见安全性问题检查,例如SQL注入等
如果需要高级的安全性测试,确定获得专业安全公司的帮助,外包测试,或者获取支持
-
兼容性测试:
-
浏览器的兼容性
-
操作系统的兼容性
-
软件平台的兼容性
-
数据库的兼容性
- 记录测试结果并评审
开展测试,并记录缺陷。合理的安排调整测试进度,提前获取测试所需的资源,建立管理体系(例如,需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容)。
定期评审,对测试进行评估和总结,调整测试的内容。
怎么测试一个水杯?
- 安全性:
测试系统遭受内部和外部来源的攻击,是否能正常运行。
杯子有没有毒或细菌。
- 可靠性:
在没有故障的情况下连续执行指定功能的程度。
纸杯用了很多次,都不会坏。
- 易用性:
用户通过与系统的交互可以轻松学习,操作,准备输入和输出。
纸杯用法是否简单,步骤是否难懂。
- 兼容性:
在不同的环境中,是否还可用。
纸杯在夏天和冬天是不是可用。
- 效率:
可以处理的容量,数量和相应时间的程度。
纸杯一次能装多少水。
- 压力测试:
能处理请求的 数量/容量/并发数 极限,引发系统软件的奔溃。
给纸杯不断加压,看达到多少压力,纸杯会穿透。
有验证码的功能,怎么做性能测试
- 将验证码暂时屏蔽,完成性能测试后,再恢复
- 使用万能的验证码
- 使用脚本进行解析
微信发红包的测试用例
功能测试
- 红包最多可以输入的金额;
- 红包一次性可以发送的最大个数;
- 在输入红包的钱数和个数时只能输入数字;
- 当余额不足时,红包发送失败;
- 发送的红包自己是否可以领取;
- 发送的红包别人是否可以领取;
- 红包超过24小时是否可以领取;
- 红包超时未领取,是否退回原账户;
- 是否可以自己选择支付方式;
- 红包描述可以输入的最大字符;
- 余额不足时,是否可以切换支付方式;
UI界面测试
- 输入界面是否清晰可见;
- 红包界面颜色搭配是否美观;
- 输入金额界面是否有错别字;
性能测试
- 发红包成功后的跳转时间;
- 红包超时未领取后的退款时间;
- 网速较差时,发红包的时间;
安全测试
- 红包发送成功后,微信是否会收到通知;
- 红包发送失败,余额不会产生变化;
弱网测试
- 弱网下是否可以发送红包;
- 弱网下发送红包的时间;
易用性测试
- 是否可以选择默认支付方式;
- 余额不足时,是否可以切换支付方式;
- 是否支持密码支付和指纹支付;
对登录功能进行测试用例的编写
一、了解需求
1、登录界面是弹窗式的,还是直接卸载网页里面的?
2、账号长度和密码强度?(多少位、大小写敏感、特殊字符混搭等)
3、界面美观是否右要求?(即是否要进行UI测试)…
4、应用在手机上测试还是在电脑上
二、设计测试用例
功能性测试:
- 输入正确的账号密码,点击提交,验证是否能正确通过(正确输入)
- 输入错误的账号或者密码,验证登录是否会失败,并且提示响应的错误信息(错误校验)
- 登录成功后能否跳转到正确的页面
- 账号密码中有特殊字符(空格),是否做了过滤
- 记住账号的功能
- 登录失败之后,不能记住密码
- 密码是否加密显示
- 验证码辨识难度问题,考虑色盲使用者,刷新和换一个按钮是否可用
- 注册、忘记密码、登出按钮是否正确跳转页面
- 输入密码大写提示
- 密码非空检查
界面测试:
- 布局是否合理,按钮是否对齐
- textbox 和按钮长宽是否符合要求
- 界面风格是否统一
- 界面文字简洁易懂,没有错别字
性能测试:
- 打开登录界面,需要几秒
- 其他页面跳转的跳转时间
安全性测试:
- 登录后的Cookie是否是httponly(降低被盗风险)
- 账号密码是否通过加密方式发送给服务器
- 账号密码输入要防止 SQL 注入和 XSS 攻击
- 错误登录次数限制,防止暴力破解
- 是否支持多用户在同一机器上登录
- 是否支持一个用户在多台机器上登录
可用性测试:
- 是否有快捷键,例如tab和回车
兼容性测试:
- 不同浏览器是否能正常工作
- 不同操作系统下是否能正常工作,如 Linux 和 Windows
- 不同移动设备下是否能正常工作,如 Android 和 IOS
- 不同分辨率
淘宝上搜索商品的用例设计
功能测试:
- 输入可查到结果的正常关键字,检索到的内容、链接准确性
- 输入不可查的关键字,有无错误信息提示
- 输入一些特殊的内容,如空字符、特殊字符等,可引入等价类划分的方法
- 测试返回结果的排序:价格、销量、评价、综合
- 当返回结果庞大的时候,限制第一页的输出量
- 多选项筛选:关键字、销量、评价、综合
- 是否支持模糊搜索,通配符查询
- 网速慢的情况下的搜索
- 搜索为空的情况
- 未登录情况和登录情况下的搜索
性能测试:
- 在不同开发用户数的压力下的表现(评价指标、响应时间)
- 极限能承载多少用户量同时正常使用
- 常规压力下能保持多久持续稳定运行
- 有无内存泄露现象
易用性测试:
- 交互界面是否方便使用
- 查询结果的未知按规则列示方便定位,显示字体、字号、色彩便于识别等等
- 搜索条件的空间风格设计、位置摆放是否醒目、有无快捷查询方式等人性化设计
兼容性测试:
- Windows/Linux/Unix 等各类操作系统下及各版本下的应用
- IE/火狐/谷歌/360/QQ等各类浏览器下及各版本、各显示器分辨率条件下的应用
- SQL/ORACLE/MySQL 等各类数据库存储下的兼容性测试
- 简体中文、繁体中文、英文等各类语言的兼容性测试
- iphone/ipad/安卓 等各类移动应用产品下的兼容性测试
- 与相关监控程序的兼容性测试,如输入法、杀毒、监控、防火墙等工具的同时使用
安全测试:
- 被删除、加密、授权的数据,不允许被SQL注入等攻击方式查出,是否有安全控制设计
- 录入一些数据库查询的保留字符,如单引号、%等,造成查询SQL拼接出来的语句产生漏洞
- 通过白盒测试技术,检查一下在程序设计上是否存在安全方面的隐患
- 对涉及安全、法律禁止的内容是否进行了相关的过滤和控制
工具
2021年软件测试工具大全(自动化、接口、性能、安全、测试管理)
Selenium —— UI自动化工具
原理:
Selenium是通过模仿浏览器行为,selenium会通过打开一个浏览器,然后执行我们实现设置好的操作事件,从而实现数据获取。
流程:
- 创建并且发送给浏览器的驱动;
- 驱动中包含一个HTTP Server,用于接收http请求;
- HTTP Server根据请求操控浏览器执行步骤;
- 浏览器将步骤执行结果返回给HTTP Server;
- HTTP Server将结果返回给Selenium脚本。
优点:
- Selenium 能解决 web 自动化测试问题
- Selenium 容易学
- Selenium 资料丰富
- Selenium 方便迁移和扩展
- Selenium 方便团队协作
- Selenium 免费开源
缺点
- 截图、录制、回溯不方便
- 没有流量拦截
- 没有 mock
- 在反爬中会被识别,当然其他工具也是。
Postman —— 接口测试手动工具
原理:
通过postman给服务器发送请求,服务器处理完成后,传回给postman,postman显示处理结果。
功能:
- 测试常见类型的接口请求;
- 批量执行接口请求;
- 生成调试报告等。
优点:
- 门槛低,上手快
- 跨平台
- 免费,开源
缺点:
- 不支持封装公共函数
- 不能操作文件
Jmeter —— 性能测试手动工具
功能:可以对系统做压力和性能测试,同样也可以对数据库进行测试(基于JDBC)
优点:
- 免费开源
- 安装方便
- 拓展方便,可以编写自己的测试
- 可以集成 Selenium 进行自动化测试
缺点:
- 使用Jmeter无法验证JS程序,也无法验证页面,所以需要手工去验证
- Jmeter的断言功能不是很强大
- Jmeter脚本的维护需要保存为本地文件,而每个脚本文件只能保存一个测试用例,不利于脚本的维护。
Linux 命令
查看系统日志
1. 查看内存使用情况
打开syslog日志文件,可以使用箭头向下滚动一行。
less /var/log/syslog
会输出syslog文件的末尾几行。
tail -f /var/log/syslog
Linux 定时任务 —— crontab
使用如下命令编辑当前定时任务、列出当前定时任务、删除工作表
crontab [-u username] //省略用户表表示操作当前用户的crontab
-e (编辑工作表)
-l (列出工作表里的命令)
-r (删除工作作)
使用 crontab -e 进入当前用户的工作表编辑,界面是VIM界面。每一行是一条定时任务的命令。
命令的构成未 时间+动作,时间有分、时、日、月、周五种,操作符有
- *取值范围内的所有数字
- /每过多少个数字
- x-y 从x到y
- ,散列数字
实例:
apt换源
记录软件源的文件为 /etc/apt/sources.list
,打开该文件,进行编辑即可。
ip配置怎么改,在哪个文件
改 ip 配置的命令为 ifconfig 命令。配置文件位于/etc/sysconfig/network-scripts
。
CPU占用率满了,怎么排查问题?
- 使用top命令,找到CPU占用过高的进程
- 使用
ps -mp pid -o THREAD,tid,time | sort -rn
进程中占用CPU过高的线程 - 使用 echo ‘obase=16;[线程id]’ | bc或者printf “%x\n” [线程id] 将线程ID转为16进制格式
- 使用
jstack pid |grep tid -A 30 [线程id的16进制]
打印线程的堆栈信息。
如何查找home目录下某个日志文件的错误信息?
cat -n test.log | grep ‘error’ 查询日志中含有某个关键字的信息,显示出行号
find 命令找出文件
查找当前目录下.phtml文件中,最近30分钟内修改过的文件。
find ./ -name '*.phtml' -type f -mmin -30
查找当前目录下.phtml文件中,最近30分钟内修改过的文件,的详细情况
find . -name ‘*.phtml‘ -type f -mmin -30 -ls
查找当前目录下,最近1天内修改过的常规文件。
find . -type f -mtime -1
查找当前目录下,最近1天前(2天内)修改过的常规文件。
find . -type f -mtime +1
grep 命令查找文件和文件内容
grep -c ‘要查找的内容’ 查找的文件
找test文件中含有内容hyzx的行数
grep -c hyzx ./test
sed 查找和替换文件中的字符串
sed -i 's/Search_String/Replacement_String/g' Input_File
- sed:这是一个 Linux 命令。
- -i:这是 sed 命令的一个选项,它有什么作用?默认情况下,sed 打印结果到标准输出。当你使用 sed 添加这个选项时,那么它会在适当的位置修改文件。当你添加一个后缀(比如,-i.bak)时,就会创建原始文件的备份。
- s:字母 s 是一个替换命令。
- Search_String:搜索一个给定的字符串或正则表达式。
- Replacement_String:替换的字符串。
- g:全局替换标志。默认情况下,sed 命令替换每一行第一次出现的模式,它不会替换行中的其他的匹配结果。但是,提供了该替换标志时,所有匹配都将被替换。
- /:分界符。
- Input_File:要执行操作的文件名。
top 命令有哪些显示
ubuntu显示top命令为: