android+测试基础

来源:互联网 发布:六角碎片游戏源码 编辑:程序博客网 时间:2024/06/06 04:13


测试教程
1: 测试理论 : 测试流程 测试计划 测试 用例 测试报告
2:功能测试
3: bug系统的使用
4: 性能测试
5: 自动化测试
6: 持续集成
7: 数据库 增 删 改查 多表关联 子查询 复合函数
8: 网络爬出
9: 测试环境搭建
10: liunx 系统的使用





业务流程

企业里开发流程和测试流程是同步的

测试流程:瀑布式测试和敏捷式测试

开发流程:瀑布式开发和敏捷式开发

瀑布式的基本概念:就是在老板提出需求以后,产品吧所有原型图做出来以后,同时需求通过,这个时候一个基本的版本就已经出来的,接下来UI会把效果图做出来,再开会审核一遍,审核完成以后合格,开发开始开发,如果不合格UI继续修改,直到合格为止。在开发的同时我们开始写自己的测试用例,,当人家开发完成我们就可以根据测试用例去测试: 最后上线

好处 :

1: bug 比较少,重大bug不可能发生,比如奔溃,因为留给开发的时间比较充足,开发基本会自测这些bug都测试出来

2.开发出来的产品质量高,体现在效果和用户体验好,代码封装比较好,一般反人类设计都不会出现,

3.开发和测试对产品的业务逻辑逻辑的比较透彻

缺点:

1: 开发时间长,企业承受不了代码,成本高,效益低
2: 对市场需求的灵敏度反应不够,反应太慢
所以企业抛弃瀑布式开发采用敏捷式开发:

现在企业一般采用的都是敏捷式开发: 因为效率高,时间短,对市场的反应比较快:一般情况下都是通过版本迭代的方式进行开发,不断的完善我们的产品,这样企业风险比较小,

一般情况下: 产品首先在第一版会出个1.0 版本: 只要有基本的功能,能够使用就可以, 当第一版本上线以后再开始迭代,基本上每隔一周或者几天就要迭代一次,这就是敏捷式开发,所以我们只能敏捷式测试:

在敏捷式开发的时候我们测试需要: 首先把新增的功能系统性的测试一般,保证我们新增的功能没有任何问题,除了对保证新增的功能没有任何问题以后,我们需要进行回归测试,使用的测试流程就是瀑布式;以保证我们的产品不会在新增功能的时候把以前功能改错了.

但是如果产品已经迭代了很久,我们进行回归测试可能需要大量的时间进行回归测试,有可能开发开发了3天,测试需要的时间比三天还长,因为我们除了测试新增的功能以外,还需要对以前的功能进行系统性的测试, 这个时间我们就可以通过我们的自动化来提高我们的效率:

比如: 在开发完成1.0 以后,在开发进行版本迭代的时候,这段我们空闲下来的,我们可以把以前的1.0的功能点写成脚本,当1.1版本发布出来以后,我们只需要对新增的功能进行功能测试,以前的老功能直接和我们同步进行自动化测试,自动化测试覆盖不到的我们在进行手动测试, 所以我们写自动化脚本的目的就是为了在进行功能测试的时候为我们的功能测试提高效率:


测试分类:
1: 黑盒测试
2: 灰盒测试
3: 白盒测试
1: 黑盒测试: 基本上就是对界面和功能点进行测试,再深一点的黑盒测试一般情况下都会通过抓包巩固去抓包.比如Fiddler 抓包, 看看提交的数据与接口文档要去的是不是一致,返回的数据和就接口文档要求的是不是一致,还会去查看数据库的数据,比如用户名里面,密码是不是加密过以后保存起来的,比如列表展示的数据与数据库里面的数据是不是一致,

所以一般黑盒测试至少测试三方面:

1: UI效果图实现没有,逻辑交互对不对,功能点是不是实现了
2 Fillder或者 charles抓包 看看提交的数据是不是符合要求: 比如: 登陆,密码是不是加密了,列表的展示的时候,列表的展示的数据与抓包返回的数据是不是一致


2: 灰盒测试:
介于白盒测试和黑盒测试之间:
灰盒测试不像白盒那样详细、完整,但又比黑盒测试更关注程序的内部逻辑,常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。
灰盒不仅注意表现现象还要注意程序内需的业务逻辑,但是灰盒测试不像白盒测试那样直接看代码,而且根据我们的经验猜测来判断内存的业务逻辑是不是与我们的预期一致:
比如: 上拉加载下啦刷新功能的测试:
如果是黑盒测试: 我们只需要看下拉的时候数据刷新了说就没问题,上拉的时候数据加载了就没问题

灰盒测试的时候,我们除了关注黑盒测试那两点意外,还会通过fiddler去抓包数据,看看提交的对不对,返回的数据对不对,比如一般有个page 和一个控制item个数的参数,看看item个数的参数每次是不是固定的,下拉刷新的时候 page 是不是为 1,返回的item 是不是 20 个, 上啦加载的时候看看page 是不是在变大,这样设计接口的目的就是为了减少并发,和吞吐量,不至于返回的数据太多,如果每次都返回,就会太浪费用户流量,而且还会占用服务器带宽,用户体验也不好

3: 白盒测试:
白盒测试又俗称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试

白盒测试需要测试结构和类:

比如: 上拉加载下拉刷新代码业务逻辑是不是复杂了,看看登陆的接口提交的数据密码有没有进行md5加密,别的数据有没有加密方式加密一下



软件生命周期:

1: 问题的定义及规划

此阶段是软件开发方与需求方共同讨论,主要确定软件的开发目标及其可行性。

其实在公司里面这个角色的扮演者老板,比如老板有对市场的需求,那老板就是开发方,市场用户就是需求方,在一般的公司里,问题的定义及规则就是老板出需求,找开发,测试,设计,产品,后台来讨论老板的构思是不是符合市场需求,同时这个产品技术能不能实现


2:需求分析:

在确定软件开发可行的情况下,对软件需要实现的各个功能进行详细分析

在企业里面,这个阶段就是确定软件主要有哪些功能点,以及功能点的业务流程具体这么走,到这里产品的原型图 基本就出来啦.

3: 软件设计
此阶段主要根据需求分析的结果,对整个软件系统进行设计,如系统框架设计,数据库设计等等。软件设计一般分为总体设计和详细设计。
在公司里面一般情况下对应的是UI设计,以及架构师对框架的搭建,以及数据库表的设计

4: 程序编码]

这里就是开发进行代码的开发


5: 软件测试

在软件设计完成后要经过严密的测试,以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。

对单元测试理解:

如果你是功能测试做黑盒的,单元测试就是一个模块一个模块的测试,最后把所有以的模块加一块就叫做集成测试,最后系统性的测试一次,叫系统测试

灰盒测试也是一样的,但是如果你同时写自动化脚本的,我们可以把每一个模块写错一个单元测试,这也个也叫单元测试,将单元测试加入到测试套件里面,这个测试叫做集成测试,最后所有的都加入进来叫系统测试,

白盒测试: 除了对功能点进行测试以外,还要对类进行单元测试,这个也叫单元测试


6:运行维护

在企业里面其实就是进行版本迭代,不停的进行维护


bug 生命周期:

首先知道bug的管理工具有 禅道,jair,bugfree 这都是bug管理工具:

创建bug ------------ 修改bug ------ 验证bug =--------- 关闭bug 这就是最基本的生命周期

在提bug的时候会遇到如下问题:面试长问:

bug可以改成 --- 已修改-------

不予解决: 意思就是开发不给解决bug,这个时候你这么办?
首先找开发去沟通,看看是啥原因造成的不予解决,看看有没有可能尽量沟通一下,态度好点把bug解决掉,如果开发还是不解决,有测试经理找测试经理,如果没有测试经理,找项目经理,将问题反映给项目经理.

开发说bug延期处理你改这么办?

首先确定这个bug是什么类型的,如果是自己项目的里面的bug,而且还影响主要功能的使用,绝对不可能延期,如果是第三方原因造成的bug,比如分享每个平台是不一样的,这样的bug是可以延期处理的,但是所有延期的bug,必须通知项目经理,只有项目经理同意延期,才能延期,不然是不能延期的.


开发说这个bug是外部原因造成的:

比如环信发送消息不能及时收到,这个时候一定要通知项目经理,是需要更新技术框架,
还是能接受这个东西
bug 分类:

分为三类: 致命缺陷,严重缺陷,一般缺陷

致命缺陷: 造成系统程序奔溃,死机,系统悬挂,数据丢失,以及主要功能完全丧失都属于致命缺陷

严重缺陷: 只功能或者特征没有实现,只有功能丧失,或者由于别的功能不能使用,而造成主要流程走不通的

一般缺陷: 这样的缺陷虽然不影响系统的正常使用,但是没有很好的实现功能,没有达到预期的效果。eg:次要功能丧失,提示信息不太正确,或者用户界面太差,操作时间长等。


一个按钮点击没反应,如何判断是前端bug还是后端bug:

首先一般我们采用灰色或者白盒测试,灰盒测试主要通过 fiddler 抓包,当点击按钮那一刻,通过fiddler看看有没有进行网络请求

,如果没有进行网络请求说明是前端bug,有可能是前端没有调用网络请求的方法,

如果进行了网络请求,但是没有返回数据,那就是后台bug

,如果进行了网络请求,而且数据也正确返回,那就是前端bug,

如果进行了网络请求,返回数据不对,那就是后台bug


你测试的时候需要哪些文档或者资料:?

首先测试需要的资料: 需求文档,接口文档,产品原型图,UI效果图,开发规范文档

需求文档: 看看需求是什么,首先弄清楚我们的产品需求
接口文档: 用来测试接口是不是正常使用,需要用到
产品原型图: 主要看清楚业务逻辑,以及有哪些功能点
UI效果图: 具体我的产品长什么样子

测试分类:
功能测试,兼容测试,性能测试,安全测试,自动化测试(主要是写脚本,为自己做功能测试提高效率)
功能测试:web端和移动端: 黑盒: 灰盒,白盒
兼容测试:
web端兼容测试: IE 浏览器从 6 - 12 版本进行测试,每个是不是对能用
火狐浏览器 从 36 测试到 54 版本看看能不能使用
谷歌浏览器从 46 测试到 最新版本的浏览器
除此之外各种浏览器的测试,比如 360 百度 猎豹 搜狗,等各种能见到的浏览器都需要测试一遍

移动端兼容测试:
android 端:华为,vivo,oppo,小米,三星,一家,等友盟排行比较高的手机都进行测试,比如加起来使用率能达到90的手机都测试一下
Android 手机系统从 4.0 测试到 最新的8.0 手机
ios 端手机 : 从 4s 直接测试到 8x手机
ios系统从 : 6 测试到 11

性能测试:
测试工具 jmeter,loadrunner
1: 对接口进行压力测试,主要目的是为了模拟并发,模拟一个多人同时访问服务器的场景,提前把这种问题解决掉,测试的目的就是为了进行性能调优
2: 对web页面进行压力测试
3: 对场景进行压力测试,页面加接口组成的逻辑叫做场景
安全测试:
一般使用第三方工具进行扫描,看看接口有没有漏洞,sql语句能不能注入进去
自动化测试:
1: web端测试
python + selenium + 单元测试 + 断言 + 测试套件 + 自动化测试报告
2: 移动端测试

python + appium + 单元测试+ 断言 + 测试套件 + 自动化测试报告

3: 接口自动化

python + request + 单元测试+ 断言 + 测试套件 + 自动化测试报告
测试环境有三种:
测试环境(内网环境):版本稳定以后的测试叫α测试,英文是Alpha testing。又称Alpha测试.
预生产环境:(给测试用例的线上环境,模拟的真正的生产环境):β测试,英文是Beta testing。又称Beta测试,用户验收测试UAT)。
生产环境: (给用户使用的环境):β测试,英文是Beta testing。又称Beta测试,用户验收测试UAT)。

冒烟测试:
在开发完成开发以后,将版本给测试以后,测试随机去测试用例的百分之2 到百分之3,如果测试通过,就继续测试,如果全部不通过,打回去重做

测试方法: 主要是用来写测试用例的时候使用的
1: 边界值 :
边界条件测试是环绕边界值的测试。通常意味着测试软件各功能是否能正确处理最大值,最小值或者所设计软件能够处理的最长的字符串等等。
eg:比如有一个输入框: 规定输入的内容的长度是 10 位,不能大于10位, 这个输入框的边界值就是 9 和 11
输入9位有效数据,
输入11位有效数据看看
2: 等价类:
有效等价类:
比如规定: 用户名只能是中文,并且长度小于10
输入中文并且小于10 的就是有效等价类
张三 是有效等价类
aaaa 无效等价类
无效等价类:
比如规定: 用户名只能是中文,并且长度小于10
输入中文并且小于10 的就是有效等价类

张三 是有效等价类
aaaa 无效等价类
3.错误推测法:根据经验去推断错误

4: 因果图法:将几个输入条件组合起来,产生新情况,就叫做因果图
比如: 固定用户名长度10,并且只能是中文,密码长度6,并且只能是英文,
配合无效等价类使用:
输入 长度大于10,并且不是中文,密码大于6,并且是中文的
5.判定表组成法:
6.正交试验设计:
就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法,目的是用最少的测试用例达到最高的测试覆盖率。
7.场景法:各种逻辑的组合就是场景

公司一天产品先基本都是双配:
两个产品 , 两个测试,两个安卓,两个ios,两个web,两个后台
首先测试的是接口:在后台写完接口以后,前端还没有开发的到时候,把接口测试完,主要的工具就是postman,jmeter,主要看提交的数据对的时候,返回的数据是不是和 接口要求的一致,接口逻辑对不对
测试完成接口:一般用来写测试用例或者写自动化脚本
当开发将该版本开发完成以后,开始对新增功能进行测试,同时用脚本跑老功能
当功能测试做完以后就开始做兼容测试,
兼容完了以后就开始做性能测试,最后做安全测试



























原创粉丝点击