[开发测试]《测试相关》

测试工作流程-理论

不管是自研产品或其他产品，测试人员都要参加需求评审的会议。一方面，便于了解需求进而更好地开展之后的测试工作；另一方面，测试人员往往是从用户角度考虑居多，更加能够从用户的角度提出符合实际的建议

1 需求评审

首先要通过需求评审

2 制定测试计划

待需求最终确定下来后，则可以开始制定测试计划，确定测试目标、测试范围、测试方法、测试策略、资源安排、风险评估等。

3 制定测试用例

待测试计划拟定好后，可开始进行用例设计。一般先使用思维导图工具整理大概框架，再使用测试用例管理工具（如testlink）按功能模块、使用场景进行设计。

4 测试用例评审

因为一个人的思想是有局限性的，待用例设计好后，最好项目组的所有人员（产品经理、研发人员、测试人员）都参与用例评审，以便查漏补缺，尽可能使用例覆盖更全面。

5 冒烟测试（开发要自测，并且测试也要测）

待研发人员提交版本后，测试人员便可以进行冒烟测试（当然，冒烟测试的用例要提前选好）。

6 一轮测试

待冒烟测试通过，则可以开始执行第一轮的测试。发现的bug使用缺陷管理工具（如jira/redmine/禅道等）记录下来

7 N轮测试

如果有必要，则进行第二轮、第三轮、第N轮的测试。

8 回归测试

待研发人员把本次需修复的bug都修复完成后（并不一定是所有bug都需要修复，有些推迟的、有些被判定为不是bug的、有些影响不大的都可以暂时不修复），即可进行回归测试。主要是验证缺陷是否真的修复，是否会影响现有系统的使用。

9 撰写文档

之后就可以开始撰写测试报告、用户手册等相关文档。测试报告要能反映本次测试的目标、范围、对象、执行过程即结论和风险分析。

移动APP测试流程

UI测试

检查UI图片，icon，文字，布局等UI元素与效果图是否一致。

功能测试

检验功能是否符合需求，涉及到UI层，接口，数据，服务端，代码逻辑等。

健壮性测试

检验产品在出现异常时的处理机制。同时需要检验出现这些异常场景，或者是比较极限的情况的时候会否出现crash、anr的情况。一般只要有处理就不会出现问题。需要注意一些极限和异常场景，还有中断和弱网的测试。

适配

检验产品的兼容性，不同的硬件设备，分辨率，操作系统，屏幕尺寸，手机型号等。安卓这一块儿是不太好做的，国内的定制系统太多了，一般方法都是针对主流机型进行测试。

稳定性测试

这里通常使用的是monkey进行测试。主要手段还是通过伪随机事件流，进行大量的点击，滑动等操作，主要是用来检测产品中隐藏的crash、anr的缺陷。

性能测试

客户端性能：主要监测，客户端运行时设备的CPU，GPU，流量，耗电量，响应时间等数据。进行数据分析，针对客户端对产品进行优化，从而提升产品的竞争力。这里是可以检查出内存泄漏的哦。在深入的发掘可以分析客户端的性能瓶颈，甚至定位出影响客户端性能的代码。这一块儿作为APP的专项测试，实际上可以做的东西有很多，也值得大家去发掘去做。只是国内大部分中小型的公司还没有重视起来，都还属于走过场的形式，笔者也没有特别深入的去做，也就不讲了。
服务端性能：主要监测，I/O，吞吐量，并发，压力，负载等数据。针对测试结果进行分析，寻找性能瓶颈，完成对性能的优化。主要目的是检查服务端的稳定性，能否达到预期目标，完成预期任务。这一块儿笔者还没有接触就不深谈了哈。

回归测试

回归测试，主要是针对开发修复的缺陷进行测试。评估改动的影响范围，有目标有针对性的进行测试。其实还需要对老版本的功能、数据等进行回归。不得不说黑盒就是麻烦，每一次改动，无论巨细，无论影响范围都必须要做这个。

上线测试

在发布上线之后，要在生产环境上进行最后一轮的系统测试。一般是把前面所有做过的东西全部在做一次。

测试的分类以及测试之间的关系
在测试过程中我们遇见了各种各样的测试方法，但是我们都不知道他们之间的关系是怎样的，甚至也不知道如何使用，下面是我对各个测试之间关系的理解。

测试级别：单元测试、集成测试、接口测试、系统测试、验收测试
测试方法：黑盒测试、白盒测试、灰盒测试
测试方式：动态测试、静态测试
测试类型：功能测试、性能测试、兼容性测试、安全测试、UI测试等
测试自动化程度：人工测试、自动化测试
功能测试类型包括：单元测试、整合（集成）测试、系统测试、健全性测试、冒烟测试、接口测试、回归测试、Beta /验收测试
非功能测试类型包括：界面（UI）性能测试（负载测试、压力测试）、容量测试、安全测试、兼容性容性测试、安装测试、恢复测试、可靠性测试、可用性测试、符合性测试、本地化测试、稳定性（Monkey）测试、A/B测试

单元测试->集成测试->系统测试->验收测试

体现了测试由小到大、又内至外、循序渐进的测试过程和分而治之的思想。单元测试和集成测试由设计人员和程序员完成，系统测试由软件测试小组根据上面的三个基本步骤完成，验收测试由用户完成

单元测试

单元测试 粒度最小，属于功能测试，一般由开发小组采用白盒测试方法来测试，主要测试单元是否符合“设计”。（使用白盒测试的方法来进行单元测试（功能测试中的一种））

集成测试

集成测试 界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既验证“设计”，又验证“需求”。 主要用来测试模块与模块之间的接口，同时还要测试一些主要业务功能。集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它最简单的形式是：把两个已经测试过的单元组合成一个组件，测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合为程序的更大部分。方法是测试片段的组合，并最终扩展成进程，将模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有
集成测试进程。

系统测试

系统测试粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。在经过以上各阶段测试确认之后，把系统完整地模拟客户环境来进行的测试。系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方，从而提出更加完善的方案.

验收测试

验收测试与系统测试相似，主要区别是测试人员不同，验收测试由用户执行。

黑盒测试与白盒测试

黑盒测试

方法：等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验分析法、功能图法、场景法、状态迁移图法、流程分析法

白盒测试

基于代码的测试，通过程序代码或者通过开发工具找出软件的缺陷。白盒测试总体上分为静态测试和动态测试两大类。
白盒测试方法：代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖、程序变异

冒烟测试、回归测试、单元测试和集成测试之间的关系

• 单元测试：由开发人员自测，指定并测试一个类的单一方法合约的一点。这应该具有非常狭窄且定义明确的范围。对外部世界的复杂依赖关系和交互行为是存根或嘲笑的。
• 集成测试：开发人员自测，测试多个子系统之间的正确互操作。从两类之间的测试集成，到与生产环境的测试集成，整个过程都有。
• 冒烟测试（也称为健全性检查）：开发和测试都要测一种简单的集成测试，我们只检查被测系统被调用时，它会正常返回并且不会崩溃。
  冒烟测试与电子设备都类似，在首次通电时会为电路加电（如果冒烟，那就很糟糕！），而且显然是水暖管道，管道系统实际上是由烟雾填充的，然后进行目视检查。如果有任何冒烟，则表明系统泄漏。
• 回归测试：修复错误后编写的测试。它确保不会再次发生此特定的错误。全名是“非回归测试”。也可以是在更改应用程序之前进行的测试，以确保应用程序提供相同的结果。
  为此，我将添加：
• 验收测试：测试功能或用例是否正确实现。它类似于集成测试，但侧重于提供的用例，而不是所涉及的组件。
• 系统测试：将系统测试为黑匣子。在测试过程中，通常会嘲笑或打断对其他系统的依赖关系（否则，它更像是一个集成测试）。
• 飞行前检查：在类似于生产的环境中重复进行的测试，以减轻“在我的机器上构建”综合症。通常，这是通过在类似生产的环境中进行验收或冒烟测试来实现的。

接口测试

参考资料：
https://zhuanlan.zhihu.com/p/66740776
postman：https://www.cnblogs.com/laoluoits/p/12784933.html
接口测试与抓包：https://zhuanlan.zhihu.com/p/334645791
接口测试与性能测试：https://zhuanlan.zhihu.com/p/315004066
接口测试的流程：https://www.zhihu.com/question/57553476

接口测试的概念

接口测试概念以及作用：测试系统组件间接口的一种测试；接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系。

所谓接口测试就是通过测试不同情况下的入参与之相应的出参信息来判断接口是否符合或满足相应的功能性、安全性要求。接口测试没有页面，它是通过接口规范文档上的调用地址、请求参数，拼接报文，然后发送请求，检查返回结果，所以它只需测入参和出参就行了。

接口测试与抓包

参考资料：https://zhuanlan.zhihu.com/p/116753393
抓包（packet capture）就是将网络传输发送与接收的数据包进行截获、重发、编辑、转存等操作，也用来检查网络安全。抓包也经常被用来进行数据截取等。
抓包工具是拦截查看网络数据包内容的软件。通过对抓获的数据包进行分析，可以得到有用的信息。流行的抓包工具有很多，比较出名的有wireshark、sniffer、httpwatch、iptool、fiddler等。

一般做接口测试的时候需要有接口文档来提供做接口测试所需要的输入输出参数，如果没有的话就需要使用抓包工具来获取接口信息。

为什么要做接口测试？

大家都知道，接口其实就是前端页面或APP等调用与后端做交互用的，所以好多人都会问，我功能测试都测好了，为什么还要测接口呢？OK，在回答这个问题之前，先举个栗子：

比如测试用户注册功能，规定用户名为6~18个字符，包含字母（区分大小写）、数字、下划线。首先功能测试时肯定会对用户名规则进行测试时，比如输入20个字符、输入特殊字符等，但这些可能只是在前端做了校验，后端可能没做校验，如果有人通过抓包绕过前端校验直接发送到后端怎么办呢？试想一下，如果用户名和密码未在后端做校验，而有人又绕过前端校验的话，那用户名和密码不就可以随便输了吗？如果是登录可能会通过SQL注入等手段来随意登录，甚至可以获取管理员权限，那这样不是很恐怖？

所以，接口测试的必要性就体现出来了：
①、可以发现很多在页面上操作发现不了的bug
②、检查系统的异常处理能力
③、检查系统的安全性、稳定性
④、前端随便变，接口测好了，后端不用变

由于如今的系统复杂度不断上升，传统的测试方法成本急剧增加且测试效率大幅下降，所以就要做接口测试。同时，接口测试相对容易实现自动化持续集成，且相对UI自动化也比较稳定，可以减少人工回归测试人力成本与时间，缩短测试周期，支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。现在很多系统前后端架构是分离的，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前面实在太容易），需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。前后端传输、日志打印等信息是否**传输也是需要验证的，特别是涉及到用户的隐私信息，如身份证，银行卡等。

什么是接口？

接口一般来说有两种，一种是程序内部的接口，一种是系统对外的接口。
系统对外的接口：比如你要从别的网站或服务器上获取资源或信息，别人肯定不会把数据库共享给你，他只能给你提供一个他们写好的方法来获取数据，你引用他提供的接口就能使用他写好的方法，从而达到数据共享的目的，比如说咱们用的app、网址这些它在进行数据处理的时候都是通过接口来进行调用的。

程序内部的接口：方法与方法之间，模块与模块之间的交互，程序内部抛出的接口，比如bbs系统，有登录模块、发帖模块等等，那你要发帖就必须先登录，要发帖就得登录，那么这两个模块就得有交互，它就会抛出一个接口，供内部系统进行调用。

常见接口

1、webService接口：是走soap协议通过http传输，请求报文和返回报文都是xml格式的，我们在测试的时候都用通过工具才能进行调用，测试。可以使用的工具有SoapUI、jmeter、loadrunner等；
2、http api接口：是走http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get和post等方法，这也是最常用的两种请求方式。可以使用的工具有postman、RESTClient、jmeter、loadrunner等；

前端和后端

在说接口测试之前，我们先来搞清楚这两个概念，前端和后端。

前端是什么呢，对于web端来说，咱们使用的网页，打开的网站，这都是前端，这些都是html、css写的；对于app端来说呢，它就是咱们用的app，android或者object-C（开发ios上的app）开发的，它的作用就是显示页面，让我们看到漂亮的页面，以及做一些简单的校验，比如说非空校验，咱们在页面上操作的时候，这些业务逻辑、功能，比如说你购物，发微博这些功能是由后端来实现的，后端去控制你购物的时候扣你的余额，发微博发到哪个账号下面，那前端和后端是怎么交互的呢，就是通过接口。

前面说的你可能不好理解，你只需记住：前端负责貌美如花，后端负责挣钱养家。

接口测试怎么测？

1）、通用接口用例设计
①、通过性验证：首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。
②、参数组合：现在有一个操作商品的接口，有个字段type，传1的时候代表修改商品，商品id、商品名称、价格有一个是必传的，type传2的时候是删除商品，商品id 是必传的，这样的，就要测参数组合了，type传1的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。
③、接口安全：

1、绕过验证，比如说购买了一个商品，它的价格是300元，那我在提交订单时候，我把这个商品的价格改成3元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？
2、绕过身份授权，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功
3、参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，加密规则是否容易破解。
4、密码安全规则，密码的复杂程度校验
④、异常验证：
所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是10的，传11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。

2）、根据业务逻辑来设计用例

根据业务逻辑来设计的话，就是根据自己系统的业务来设计用例，这个每个公司的业务不一样，就得具体的看自己公司的业务了，其实这也和功能测试设计用例是一样的。
举个例子，拿bbs来说，bbs的需求是这样的：
1、登录失败5次，就需要等待15分钟之后再登录
2、新注册的用户需要过了实习期才能发帖
3、删除帖子扣除积分
4、…
像这样的你就要把这些测试点列出来，然后再去造数据测试对应的测试点。

用什么工具测？

一般情况下，由于我们项目前后调用主要是基于http协议的接口，所以测试接口时主要是通过工具或代码模拟http请求的发送和接收。

接口测试的工具很多，比如 postman、RESTClient、jmeter、loadrunner、SoapUI等，本人首推的测试工具是postman和jmeter，

性能测试

参考资料：http://www.51testing.com/html/68/n-3723568.html
性能测试：https://www.zhihu.com/search?type=content&q=%E6%80%A7%E8%83%BD%E6%B5%8B%E8%AF%95
性能测试常用工具：https://zhuanlan.zhihu.com/p/98612628
性能测试七大类

性能测试：性能测试是为了描述测试对象与性能相关的特征并对其进行评价而实施和执行的一类测试。 它主要通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项指标进行测试。 通常把性能测试、负载测试、压力测试等统称为性能测试。

性能测试常用工具

参考资料：https://www.jianshu.com/p/11c2c8462f81
App测试工具：http://www.51testing.com/html/77/n-4476477.html?nomobile=1

1. Jmeter

自认为Jmeter是最有名负载测试圈的开源工具.Apache 自己描述Jmeter是一款专用于通过负载测试来衡量性能的java应用程序。
JMeter的创建是对应于LoadRunner的开源工具，所以你会巨恶恶的他们有一些相似之处。这是一个便捷的客户端，使用右键驱动即可。有点奇怪，但是性能强大。性能负载测试的所有特征都可以在JMeter上使用。
这些特征包括：
可以测试一个主机的技术性能，如java对象，web页面的http/HTTs， soap， Rest服务，FTP，数据库等
友好的IDE， 能够记录，debug你的性能测试
JMeter3.1中groovy是一个默认语言
最受欢迎的性能测试工具之一
虽然是最受欢迎的但是也有一些缺点
例如，Jmeter无法测试一个大的分布式系统，尤其是你已经创建了一堆的机器，他们之家相互通信。在执行大型JMeter测试时，还存在许多编排问题。
所以也有一个开源工具: BlazeMeter可以帮助你

2. Taurus

Taurus的强大在于可以让你把测试写成YAML文件,你可以在一个十行的文本上写一段成熟的脚本.这个脚本能够在yaml文件或者json文件中表达测试的内容.YAML文件就是一个易懂的,可编辑的方式给你在文本上描述一个测试.这是一个大的跨越,从以前繁重的特定的记录和脚本从逃脱.
特点
允许团队中更多的人进行性能测试,由于脚本在易读的YAML文件中写的,所以代码review会更容易.
更容易集成到CI/CD中
提供了Jmeter selenium等上的抽象层

3. Locust

Locust是一个容易使用,分布式的用户负载测试工具, 它可以进行网站和应用的负载测试.它还能指出系统可以承受的并发用户数量.如果您熟悉“负载生成器”一词，那么Locust会使用“ swarm”一词，因为您可以指出一群蝗虫在您的网站上施加负载。你可以定义每一个Locust实例的行为,你可以检测每一个swarm的实时行为.
特性:
使用Python创建测试脚本
很容易增加用户数量
nice web界面
可扩展
接口测试也可以

4. Fiddler with BlackWidow and Watcher

Fiddler可以做很多事情,最多的是英语抓包
Fiddler是一个免费的开源工具,用于检测,操纵和再用HTTP请求.也可以测试网页,还有很多扩展工具搭配使用.
Fiddler特性:
web应用的故障排除
安全测试
性能评估
调试来自于其他计算机和设备的web流量
Fiddler早就被程序员广泛使用,很多人使用它去检测http 请求.
Todd DeCapua 建议使用Fiddler和Watcher ,BlackWidow 来快速创建性能测试解决方案
Watcher is a security add-in for Fiddler which will enable you to get some security results quickly. BlackWidow is a web crawler that gives you the functionality to point it towards a web address and then be able to drill down on results.
Watcher是一个Fiddler的安全插件,可以保证你很快得到安全结果.BlackWidow是一个Web爬网程序，它为您提供了将其指向网址的功能，然后可以深入查询结果。对于一个初次接触性能测试的人,使用这三个工具也能搭建一个系统进行性能测试
具体可以查看: PerfGuild Online Conference

5. nGrinder

nGrinder在github上被称为是针对企业级的性能测试解决方案,容易进行负载测试,提供了一个平台去创建,执行,监督的工具.
特征
-使用Jython去写脚本,使用多个代理对JVM创建压力
-扩展测试通过Jar包和py文件
允许您监视绩效代理的状态

6. The Grinder

The Grinder i是一个Java负载测试框架.它提供给我们一个容易运行 和创建的分布式测试解决方案,使用许多负载注射器机器.
特征:
你可以进行任意有JAVA API的负载测试.
一个好的交互界面
自动处理客户端的连结和cookie管理

7. Gatling

Gatling是一个基于Scala, Akka and Netty创建的负载测试工具.允许你测试和评估应用的点到点性能
特征:
有一个简单的DSL
容易扩展
如果你
如果您喜欢Scala及其带来的好处，那么这就是您的负载测试工具。
-有一个脚本记录器

8. K6

我一直没有停过k6 直到要写这个文章. 但是GIthub上的数量有 2,893 我不得不看一看.
k6是一个以开发人员为中心的开源负载测试工具，用于测试后端基础架构的性能。
k6 is also Modern load testing tools built with Go and JavaScript so it integrates well into most developers workflow.
K6也是一个机遇Go语言和JS’的负载测试工具.所以它集成到了多数的开发流程中.
特征:
干净的脚本API
提供分布式的和云的执行
rest API框架

一、准备工作
1、系统基础功能验证
性能测试在什么阶段适合实施？切入点很重要！一般而言，只有在系统基础功能测试验证完成、系统趋于稳定的情况下，才会进行性能测试，否则性能测试是无意义的。
2、测试团队组建
根据该项目的具体情况，组建一个几人的性能测试team，其中DBA是必不可少的，然后需要一至几名系统开发人员（对应前端、后台等），还有性能测试设计和分析人员、脚本开发
和执行人员；在正式开始工作之前，应该对脚本开发和执行人员进行一些培训，或者应该由具有相关经验的人员担任。
3、工具的选择
综合系统设计、工具成本、测试团队的技能来考虑，选择合适的测试工具，最起码应该满足一下几点：
①支持对web（这里以web系统为例）系统的性能测试，支持http和https协议；
②工具运行在Windows平台上；
③支持对webserver、前端、数据库的性能计数器进行监控；
4、预先的业务场景分析
为了对系统性能建立直观上的认识和分析，应对系统较重要和常用的业务场景模块进行分析，针对性的进行分析，以对接下来的测试计划设计进行准备。
二、测试计划
测试计划阶段最重要的是分析用户场景，确定系统性能目标。
1、性能测试领域分析
根据对项目背景，业务的了解，确定本次性能测试要解决的问题点；是测试系统能否满足实际运行时的需要，还是目前的系统在哪些方面制约系统性能的表现，或者，哪些系统因素导致
系统无法跟上业务发展？确定测试领域，然后具体问题具体分析。
2、用户场景剖析和业务建模
根据对系统业务、用户活跃时间、访问频率、场景交互等各方面的分析，整理一个业务场景表，当然其中最好对用户操作场景、步骤进行详细的描述，为测试脚本开发提供依据。
3、确定性能目标
前面已经确定了本次性能测试的应用领域，接下来就是针对具体的领域关注点，确定性能目标（指标）；其中需要和其他业务部门进行沟通协商，以及结合当前系统的响应时间等数据，确定
最终我们需要达到的响应时间和系统资源使用率等目标；比如：
①登录请求到登录成功的页面响应时间不能超过2秒；
②报表审核提交的页面响应时间不能超过5秒；
③文件的上传、下载页面响应时间不超过8秒；
④服务器的CPU平均使用率小于70%，内存使用率小于75%；
⑤各个业务系统的响应时间和服务器资源使用情况在不同测试环境下，各指标随负载变化的情况等；
4、制定测试计划的实施时间
预设本次性能测试各子模块的起止时间，产出，参与人员等等。
三、测试脚本设计与开发
性能测试中，测试脚本设计与开发占据了很大的时间比重。
1、测试环境设计
本次性能测试的目标是需要验证系统在实际运行环境中的性能外，还需要考虑到不同的硬件配置是否会是制约系统性能的重要因素！因此在测试环境中，需要部署多个不同的测试环境，
在不同的硬件配置上检查应用系统的性能，并对不同配置下系统的测试结果进行分析，得出最优结果（最适合当前系统的配置）。
这里所说的配置大概是如下几类：
①数据库服务器
②应用服务器
③负载模拟器
④软件运行环境，平台
测试环境测试数据，可以根据系统的运行预期来确定，比如需要测试的业务场景，数据多久执行一次备份转移，该业务场景涉及哪些表，每次操作数据怎样写入，写入几条，需要多少的
测试数据来使得测试环境的数据保持一致性等等。
可以在首次测试数据生成时，将其导出到本地保存，在每次测试开始前导入数据，保持一致性。
2、测试场景设计
通过和业务部门沟通以及以往用户操作习惯，确定用户操作习惯模式，以及不同的场景用户数量，操作次数，确定测试指标，以及性能监控等。
3、测试用例设计
确认测试场景后，在系统已有的操作描述上，进一步完善为可映射为脚本的测试用例描述，用例大概内容如下：
用例编号：查询表单_xxx_x1（命名以业务操作场景为主，简洁易懂即可）
用例条件：用户已登录、具有对应权限等。。。
操作步骤：
①进入对应页面。。。。。。
②查询相关数据。。。。。。
③勾选导出数据。。。。。。
④修改上传数据。。。。。。
PS：这里的操作步骤只是个例子，具体以系统业务场景描述；
4、脚本和辅助工具的开发及使用
按照用例描述，可利用工具进行录制，然后在录制的脚本中进行修改；比如参数化、关联、检查点等等，最后的结果使得测试脚本可用，能达到测试要求即可；
PS：个人而言，建议尽量自己写脚本来实现业务操作场景，这样对个人技能提升较大；一句话：能写就绝不录制！！！
四、测试执行与管理
在这个阶段，只需要按照之前已经设计好的业务场景、环境和测试用例脚本，部署环境，执行测试并记录结果即可。
1、建立测试环境
按照之前已经设计好的测试环境，部署对应的环境，由运维或开发人员进行部署，检查，并仔细调整，同时保持测试环境的干净和稳定，不受外来因素影响。
2、执行测试脚本
这一点比较简单，在已部署好的测试环境中，按照业务场景和编号，按顺序执行我们已经设计好的测试脚本。
3、测试结果记录
根据测试采用的工具不同，结果的记录也有不同的形式；现在大多的性能测试工具都提供比较完整的界面图形化的测试结果，当然，对于服务器的资源使用等情况，可以利用一些计数器或
第三方监控工具来对其进行记录，执行完测试后，对结果进行整理分析。
五、测试分析
1、测试环境的系统性能分析
根据我们之前记录得到的测试结果（图表、曲线等），经过计算，与预定的性能指标进行对比，确定是否达到了我们需要的结果；如未达到，查看具体的瓶颈点，然后根据瓶颈点的具体数据，
进行具体情况具体分析（影响性能的因素很多，这一点，可以根据经验和数据表现来判断分析）。
2、硬件设备对系统性能表现的影响分析
由于之前设计了几个不同的测试环境，故可以根据不同测试环境的硬件资源使用状况图进行分析，确定瓶颈是再数据库服务器、应用服务器抑或其他方面，然后针对性的进行优化等操作。
3、其他影响因素分析
影响系统性能的因素很多，可以从用户能感受到的场景分析，哪里比较慢，哪里速度尚可，这里可以根据2\5\8原则对其进行分析；
至于其他诸如网络带宽、操作动作、存储池、线程实现、服务器处理机制等一系列的影响因素，具体问题具体分析，这里就不一一表述了。
4、测试中发现的问题
在性能测试执行过程中，可能会发现某些功能上的不足或存在的缺陷，以及需要优化的地方，这也是执行多次测试的优点。

兼容性测试

参考资料：https://zhuanlan.zhihu.com/p/78106223
兼容测试(Compatibility Test Suite )简称CTS， 指对所设计程序与硬件、软件之间的兼容性的测试。分为浏览器兼容测试 和分辨率兼容测试两类。
一、什么是兼容性测试？
很多人都知道兼容性测试，但是却很少能准确理解兼容性测试，大多都只会想到浏览器的兼容；实际兼容性还有其他内容，包括web 兼容和APP 兼容；那么下面咱们先说说什么是兼容性测试：
兼容测试（Compatibility Test Suite ）官方简称CTS ，指对所设计程序与硬件、软件之间的兼容性的测试。一般来说，兼容性指能同时容纳多个方面，在计算机术语上兼容是指几个硬件之间、几个软件之间或是软硬件之间的相互配合程度。
按照我的理解，我认为兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能够很友好的运行的测试。
二、兼容性测试分类
兼容性测试目前我关注的包括web 兼容性测试和APP 兼容性测试；
兼容测试包括：
（1）浏览器兼容测试：测试程序在不同浏览器上是否可以正常运行，功能能否正常使用；
（2）屏幕尺寸和分辨率兼容测试：测试程序在不同分辨率下能否正常显示；
（3）操作系统兼容测试：测试程序在不同的操作系统下面能否正常运行，功能能否正常使用，显示是否正确等；
（4）不同设备型号兼容测试：针对于APP，现在移动设备型号五花八门，主要测试APP 在主流设备上能否正常运行，会不会出现崩溃的现象。
三、兼容性测试方法
Web 端和APP 端的兼容性测试，有两种方法：一种是人工测试即全手工测试兼容；另外一种是借助第三方兼容性测试工具；
人工测试工作量大，而且覆盖不全；第三方测试工作虽说工作量小，但是在主功能和主流程测试的时候没有侧重点，很难发现一些隐藏的问题；要说这两种方法哪一种更好，我个人认为没有最好，我觉得这两种方法适当的结合才是最好的兼容性测试方法；
四、如何进行兼容性测试
测试工具：https://www.sohu.com/a/348960678_185201
（1）Web 兼容性测试
首先开展人工测试，测试工程师测试主流浏览器和常用操作系统测试主流程和主界面，看看主流程和主界面是否有问题，如果存在问题，那么记录下bug 情况，以及浏览器型号和版本，以及操作系统，准确定位bug 产生的原因，提交bug，告知开发人员修改。所有的主流设备都需要进行测试，只关注主流程和主界面，毕竟每个系统主流程和主界面不是很多，所以这个工作量还是可以承受的。
其次借助第三方测试工具，目前我觉得比较好用的第三方Web 测试工具有IEtester（离线）、SuperPreview（离线）和Browsershots：Check Browser Compatibility, Cross Platform Browser Test（在线），一款可以测试IE的兼容，一款可以测试主流浏览器的兼容，包括谷歌、火狐、Opera 等等。借助第三方测试工具，找到bug 产生的位置，分析测试结果，告知程序员调整。
（2）APP 兼容性测试
APP 的兼容性测试和Web 测试类似，首先开展人工测试，测试工程师借助测试设备对主流程和主功能，主界面进行测试；收集所有的能收集到的不同型号的测试设备测试主流程和主界面，看看主流程和主界面是否有问题，如果存在问题，综合考虑设备的使用率等因素，看看是否需要调整，如果需要，那么记录下bug 情况以及测试设备的型号和操作系统，准确定位bug 产生的原因，提交bug，告知开发人员修改。
其次借助第三方测试工具，对于APP 的兼容性测试，我推荐的是百度众测平台和云测平台，我经常使用的是云测平台，这两款测试工具里面包含了安卓和iOS 的测试；测试很齐全，包括功能测试、深度兼容测试、性能测试、网络环境测试，还可以模拟海量用户测试，还可以导入自己编写的测试用例进行功能测试，里面还包括测试专家的测试，当然了找专家是要花钱滴。基本进行兼容性测试是不需要花钱的；测试工程师把打包好的apk 或者IPA 文件，上传到测试平台，选择需要测试的设备型号，开始任务即可；等待一段时间，在等待的时间你是不需要盯着的，你可以做其他的工作。测试完成后会生成一份测试报告，可以查看错误页面和错误日志，如果需要调整，那么提交bug，告知程序员修改即可。
五、兼容性测试的作用
兼容性测试是软件测试过程必不可少的一个过程，没有兼容测试的测试是不完整的测试，兼容性测试的存在是有一定作用的。我个人觉得最少有以下几点：
兼容性测试能够进一步提高产品的质量，提高用户体验；
兼容性测试能使软件与尽可能多的其他软件“和平共处”，尽可能达到平台无关性；
兼容性测试能尽可能的保证软件存在的价值，它是衡量一个软件质量的重要指标；
兼容性测试能使软件产品的市场更广阔；

APP测试工具大全

参考资料：https://zhuanlan.zhihu.com/p/291952363

一、APP 自动化测试工具

Appium
官网：http://appium.io/
GitHub 地址：https://github.com/appium/appium
介绍：
Appium 是一个开源的、跨平台的自动化测试工具。支持自动化 iOS，Android 和 Windows 桌面平台上的原生、移动 Web 和混合应用。 开发者可以使用 WebDriver 兼容的任何语言编写测试脚本，如 Java，OC，JS，PHP，Python，Ruby，C#，Clojure 和 Perl 语言。是做 UI 自动化测试必须要掌握的工具之一。
Airtest
官网：http://airtest.netease.com/
介绍：
Airtest 是网易游戏推出的一个 UI 自动化测试工具，适用于游戏和应用，支持的平台为 Windows，Android 和 iOS。Airtest 提供了跨平台的 API，包括安装应用、模拟输入、断言等。 基于图像识别技术定位 UI 元素，你无需嵌入任何代码即可进行自动化测试。 并且测试脚本运行后可以自动生成详细的 HTML 测试报告。
uiautomator2 （python）
GitHub 地址：https://github.com/openatx/uiautomator2
介绍：
uiautomator2 是一个可以使用 Python 对 Android 设备进行 UI 自动化的库。其底层基于 Google uiautomator，Google 提供的 uiautomator 库可以获取屏幕上任意一个 APP 的任意一个控件属性，并对其进行任意操作。

二、APP 稳定性测试工具

Monkey
地址： https://developer.android.google.cn/studio/test/monkey
介绍：
Monkey 是一个在模拟器或设备上运行的程序，可生成伪随机用户事件（例如点击、轻触或手势）流以及很多系统级事件。使用 Monkey 以随机且可重复的方式对正在开发的应用进行压力测试。
MonkeyRunner
地址：https://developer.android.google.cn/studio/test/monkeyrunner
介绍：
monkeyrunner 工具提供了一个 API，用于编写可从 Android 代码外部控制 Android 设备或模拟器的程序。使用 monkeyrunner，可以编写一个 Python 程序去安装 Android 应用或测试软件包，运行它，向其发送按键，截取其界面的屏幕截图，并将屏幕截图存储到工作站中。monkeyrunner 工具主要用于在功能/框架级测试应用和设备以及运行单元测试套件，但也可以自由地将其用于其他目的。
Maxim
GitHub 地址：https://github.com/zhangzhao4444/Maxim
介绍：
Maxim 是基于 monkey 做的二次开发，相较原生 monkey，相对智能。除了保留原生 monkey 已有的功能外，可深度遍历控件，可自定义黑白名单，可设定执行时长，增加防睡眠/防假死机制、防跳出/防误点状态栏及下拉状态栏等。
UICrawler
GitHub 地址：https://github.com/lgxqf/UICrawler
介绍：
基于 Appium 的 App UI 遍历 & Monkey 工具，支持 Android 和 iOS 移动 App，或 H5 或微信等应用。v2.3 版已支持 Appium 1.16.0, Java-client 7.3.0。

三、APP 性能测试工具

GT
官网： https://gt.qq.com/
介绍：
腾讯开源的 APP 的随身调测平台，支持 iOS 和 Android。直接运行在手机上，可对 APP 进行快速的性能测试(CPU、内存、流量、电量、帧率/流畅度等等)、开发日志的查看、Crash 日志查看、网络数据包的抓取、APP 内部参数的调试、真机代码耗时统计等。
Perfdog
官网： https://perfdog.qq.com/
介绍：
腾讯游戏部门开发的移动全平台 iOS/Android 性能测试、分析工具平台。手机无需 ROOT/越狱，手机硬件、游戏及应用 APP 也无需做任何修改，极简化即插即用。
PerfDog 支持 iOS 和 Android，支持移动平台所有应用程序（游戏、APP 应用、浏览器、小程序、小游戏、H5、后台系统进程等）、Android 模拟器、云真机等性能测试。PC 上 PerfDog 可多开，单 PC 可同时测试多台手机。目前免费体验，谁用谁香。
SoloPi
GitHub 地址：https://github.com/alipay/SoloPi
介绍：
SoloPi 是一个无线化、非侵入式的 Android 自动化工具。除了公测版的录制回放、性能测试、一机多控三项主要功能之外，SoloPi 还提供了数据 Mock，性能加压、网络模拟、智能 Monkey 等功能，能为测试开发人员节省宝贵时间。

四、APP 弱网测试&抓包工具

QNET
官网：https://wetest.qq.com/product/qnet
介绍：
QNET 是腾讯 wetest 服务平台推出了一款 App 弱网测试工具，该工具无需 ROOT 手机，无需连接数据线，以独立 app 的方式，为用户提供给快捷、可靠、功能完善的弱网络模拟服务(2G 网络、极差网络、连续丢包、正常网络、4G 网络、100% 丢包等)。另外 QNET 还支持 TCP/UDP 网络协议抓包。
Fiddler
官网： https://www.telerik.com/fiddler
介绍：
Fiddler 是一款大家熟知且功能强大的抓包工具。通过设置代理，能够记录客户端与服务器端所有 http(s)通讯。可以针对捕获到的请求进行分析、设置断点、篡改请求及返回数据，还可以设置网络丢包和延时进行弱网络模拟等等。
Charles
官网： https://www.charlesproxy.com/
介绍：
Charles 是 HTTP 代理/ HTTP 监视器/反向代理，可以查看其计算机与 Internet 之间的所有 HTTP 和 SSL / HTTPS 通信。可对截取的请求及响应进行分析、支持修改请求参数、支持弱网络模拟。

五、APP 兼容性测试工具

TestIn
官网：https://www.testin.cn/
介绍：
Testin 是国内较早涉足云测试领域的平台之一。终端种类及数量都比较全面。提供远程真机测试、标准/深度/遍历兼容测试、自动化测试、测试专家驻场等。支持 Android 与 iOS 系统。但目前仅少部分服务为免费，绝大多数服务为收费项目。
腾讯优测
官网： https://utest.21kunpeng.com/home
介绍：
腾讯旗下的云测试服务平台，拥有超过 3000 台真机实验室，覆盖市面 99% 主流机型。拥有十年终端测试服务经验，提供兼容性测试、自动化测试、云真机、设备分享等多种服务方式。
百度 MTC
官网： http://mtc.baidu.com/
介绍：
百度 MTC 是百度开放平台旗下的移动云测试中心。提供超过 1500 款热门机型。提供的测试服务种类有兼容性测试、性能测试、功能测试。并且提供了脚本录制工具，类似 Testin。
百度 MTC 的服务目前主要为收费服务。
阿里 MQC
官网：https://www.aliyun.com/product/mqc
介绍：
阿里 MQC 是阿里巴巴旗下的移动测试平台。提供大量热门机型，支持 Android 及 iOS 系统。提供兼容性测试、功能测试、性能测试以及稳定性测试。

六、APP 安全测试工具

OWASP ZAP
官网：https://owasp.org/www-project-zap/
介绍：
OWASP ZAP 是目前最流行的免费 APP 移动安全测试工具，由全球数百个志愿者管理维护。该工具支持多种脚本语言类型，易安装，可以在 APP 的开发和测试阶段自动查找安全漏洞。
Drozer
GitHub 地址： https://github.com/FSecureLABS/drozer
介绍：
Drozer 是一个由 MWR 安全团队维护开源的软件，该软件是针对 Android 平台的安全审计和攻击框架。安全人员可通过 drozer 自身提供的一些 module 完成一些基础的安全测试功能，同时也可以根据需求实现自己的 module，甚至可以在利用 drozer 提供的框架实现一些自动化审计功能。
MobSF
GitHub 地址： https://github.com/MobSF/Mobile-Security-Framework-MobSF
介绍：
MobSF 是一款自动化移动 App 安全测试工具，适用于 iOS 和 Android，可熟练执行动态、静态分析和 Web API 测试。可用于对 Android 和 iOS 应用进行快速安全分析。
QARK
GitHub 地址： https://github.com/linkedin/qark
介绍：
QARK 是一个静态代码分析工具，旨在识别基于 Java 的 Android 应用程序的潜在安全漏洞和关注点。QARK 还试图提供动态生成的 ADB（Android 调试桥）命令，以帮助验证其检测到的潜在漏洞。它甚至可以动态地创建一个定制的测试应用程序，以即用 APK 的形式，确定潜在问题。

总结

通过上边的简单了解，我们知道测试是根据不同的分类方式叫的名字不一样，即它们根据分类方式的不同叫的名字也不同，最终的目的就是为了保证产品的质量。

简化整个测试流程：开发在开发过程中就进行自测（单元测试和集成测试）->开发完成，测试提交冒烟用例，开发进行冒烟测试->开发冒烟通过，测试接手测试（也要测一下冒烟用例，以防开发测错）进行一轮测试（就是上边提到的各种测试，测试根据自己的测试策略选择自己认为好的测试方法等等）->有必要进行N轮测试（对上一轮的bug进行重点回归）->回归测试（对前边提出的bug再测一遍确保不会出错）->没有问题，发布线上->验收测试

参考资料

新版提测单使用指导文档：https://yuque.antfin.com/docs/share/5f0af22d-db9c-47c4-8ffe-c476b2c2170e?#
测试流程：https://www.yuque.com/qiqi07070/notes/pira6s?language=en-us
测试之间的关系：https://blog.csdn.net/jackjones_008/article/details/45025759
单元测试，集成测试，系统测试，验收测试
https://blog.csdn.net/slforeverlove/article/details/47027943

实际测试工作流程

实习期间，根据自己做的项目，了解了测试的整个流程，下面是自己在工作中操作之后总结的工作流程（实践总结）

项目迭代一次的整个流程

迭代：一个迭代一般是两周，一个迭代一般是完成本次的需求；如果又有新的需求，就要进行第二次迭代，全部的流程就要全部再走一遍
排期：安排每天要完成哪些任务
需求是根据用户需求可能一直在增加，第一次的需求需要一次迭代来完成，再有新的需求需要再进行一次迭代（也就是上边的整个过程再来一遍）

测试人员工作流程

需求评审

发起人：PD
参加人员：PD、运营、测试、开发、设计
让所有人都明确需求的背景和目的
提前确认和统一产品需求实现的过程和方法
让参与者明确的知道工作的内容和交付的时间
让研发和测试评估产品的开发周期、让产品经理做决定

设计测试计划

参考链接：http://www.51testing.com/html/44/n-4473944.html
实际工作中，需求文档（PRD）会被分成多个stroy（一个story一个文档），需求平台中一个项目下边的的多个文档是多个story。
编写人员：测试
需求评审后由测试编写，主要内容为：测试范围、测试策略、测试资源、测试进度、测试风险评估。
测试范围，顾名思义，测试范围描述的是被测对象以及主要的测试内容，测试范围中需要明确“测什么”和“不测什么”。
测试策略，测试策略简单来讲就是需要明确“先测什么后测什么”和“如何来测（采用什么方法）”这两个问题。
测试策略要回答的问题有：1、判断需要测试什么 2、判断用什么方法测试 3、提高测试有效性和效率 4、设法让测试工作融入到整个研发过程中。因此测试策略是根据被测对象的特点制定出来的包含测试范围、测试方法、测试工作活动分配的一系列操作指南。
测试策略的方法和技术繁多，根据不同的角度也有不同的分类方法，比较常见的有根据是否关注程序内部结构进行分类、根据是否执行测试进行分类、针对不同测试目的进行分类等。这里我们换一个角度，根据前面提到的要解决的问题总结一下测试策略。
一、需要测试什么
即确定测试范围，通常来说测试范围评定会考虑两方面。第一是从产品需求出发，测试范围要覆盖产品需求。第二是从系统实现出发，因为系统可能不仅仅实现了新的需求，还可能对原有系统产生了数据模型变更、底层基础服务的方法变更等，测试范围要评估这些变更所影响到的功能从而进行覆盖，如原有数据兼容、原有功能回归等。
二、用什么方法测试
这里涉及到多种不同的测试方法，根据不同测试对象和测试目的来选择。比如单元测试和接口测试对手工测试中无法覆盖场景的补充，用户验收测试来确认产品与客户需求一致等。
三、测试有效性和效率
为了让测试更有效，测试用例的有效性必不可少，而测试用例的各种设计方法就是为了让用例更有效。而用户验收测试，则是为了确认“do right things”，也是测试有效性的一方面。测试数据构造工具及其他测试工具平台则是为了提高测试效率。
四、测试工作融入研发过程
前面提到要在项目周期内合理分配测试工作，即把测试工作贯穿到整个研发过程中去。在这方面的策略选择有各种静态扫描工具、单元测试、接口测试、代码review、推动开发自测等形式。
测试资源，包括测试人员和测试环境，这两类资源都是有限的，测试计划的目的就是，保证在有限资源下的产出最大化，所以测试资源就是需要明确“谁来测”和“在哪里测”这两个问题。
测试进度，测试进度主要描述各类测试的开始时间，所需工作量，预计完成时间，并以此为依据来建议最终产品的上线发布时间。
测试风险预估，预估整个测试过程中可能存在的潜在风险，以及当这些风险发生时的应对策略，通常需求变更、开发延期、发现重大缺陷和人员变动是引入项目测试风险的主要原因

设计测试用例

编写人员：测试
根据prd编写测试用例、冒烟测试用例
编写冒烟测试用例（看项目大小而定，如果项目改造比较大，或者是新项目，建议编写，用例评审时提供给相关开发人员，冒烟测试用例通过后，正式提测），冒烟通过后，接受测试
项目中测试同学需要给研发同学提供冒烟测试用例，且和前端同学达成一致，冒烟测试用例要求总用例的10%
测试用例一般包含内容：用例标题、分级（P1-P3）、前置条件（在该条件下发生）、执行步骤（操作步骤）、预期结果

测试用例评审

发起人：测试
参加人员：PD、运营、测试、开发
时间在原定提测时间前1-2天，根据项目大小和时间决定是否需要该环节
输出：用例评审会议纪要、修改版测试用例、冒烟测试用例(给开发)

提测预演（冒烟测试）

发起人：开发
参加人员：PD、运营、测试、开发
ps：组织人员（正常来说是开发人员组织，但是他们一般忽略掉；测试人员可根据实际情况，要求进行提测预演，也就是让开发人员进行一下冒烟测试，大家一起看一下，保障提测质量）
规范：按照测试用例评审的冒烟测试用例由开发进行预演，若冒烟测试用例均通过，则测试接受测试，否则打回并发邮件说明冒烟测试不通过并预计下次提测时间
输出：冒烟测试结果邮件（通过与否都需要发邮件，并给出预计发布时间点、风险）
提测后第一时间投入测试，若预演未通过，要告知风险

测试阶段

• 冒烟测试通过后，测试人员根据编写的测试计划、测试用例进行相应的测试

• 通过的用例在缺陷平台上相应的位置打上通过；bug也要在缺陷平台上提交给相应的开发人员进行管理

• 缺陷处理规范
  开发修复缺陷后，需补充该缺陷的原因及修复方案，便于测试进行验证。（所有fixed的bug需要写注释）
  缺陷修复后，需选择对应的系统owner或者该模板负责人进行CR，否则不允许关闭缺陷。（研发）
  缺陷修复后，需进行对应的缺陷修复验证。（测试同学）
  缺陷验证通过，关闭缺陷前需对该缺陷对应的缺陷类型及缺陷原因进行归类。（测试同学）
  缺陷验证不通过，可将该缺陷reopen后继续提交开发处理。（测试同学）

回归测试

开发人员修改了提交的bug之后，重新测试之前的测试以保证修改的正确性
发布预演（功能验收（可多轮））
发起人：测试
参加人员：PD、运营、测试、开发
组织：测试提前预定会议室，发会议邀约给相关人员
会议记录：预演过程中，要记录会议摘要，哪些bug需要修复后上线，哪些bug后期再迭代（pd+运营评估）

发布计划

编写人员：测试
参与人员：测试、开发
目的：编写测试计划，测试人员明确本次测试的重点和回归重点，开发人员明确发布应用和发布顺利，避免漏发、发布顺序搞错等原因造成线上bug，从而代码回退。

正式发布

跟踪发布情况，可要求开发在群里同步发布节奏，发布完成后，第一时间线上验证（发布后，@pd+运营，他们可同时进行线上验收）
线上验证