面试八股文-测试理论

测试理论

白盒测试

白盒测试也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，

常见的白盒测试的方法有：语句覆盖，条件覆盖，判定覆盖，条件组合覆盖，基本路径覆盖等等。

优点：可以检测代码的每条分支和路径；可以揭示隐藏在代码中的错误；对代码的测试比较彻底。

缺点：耗费比较大；不能检测到代码中遗漏的逻辑；不能直接验证需求的正确性

黑盒测试

黑盒测试也称功能测试或数据驱动测试，它不看代码内部的逻辑，只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

常见方法有等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。

优点：容易实施，不需要关注内部实现；贴近用户需求。

缺点：覆盖率比较低，因为不知道内部逻辑

性能测试的指标

响应时间： 用户发出请求到服务器处理完成请求返回给客户端的这段时间
吞吐量：衡量系统的业务处理能力。TPS:每秒事务数。QPS:每秒请求数
资源利用率： cpu、内存、网络、磁盘读写io。一般资源的利用率不高于70%-80%,如果某项高于这个值，则可能是性能瓶颈
错误率：系统在负载情况下，失败请求的概率。错误率=（失败请求数/总请求数）*100。和功能测试的错误相区别，在性能测试中，所谓的错误一般是指由系统超时引起的错误，而不是指功能错误。不同的系统错误容错率不同。普通的业务系统，错误率不超过万分之一就可以了，有的大型系统，亿分之一。

并发用户数和在线用户数的区别

• 在线用户数：用户同时在一定时间段的在线数量
• 并发用户数：某一时刻同时向服务器发送请求的用户数
• （在线用户只要在线就好了，并发用户计算的是和服务器有交流的用户，一般比例5%-20%）

单元测试

• 单元测试是对软件组成单元进行测试，其目的是检验软件基本组成单位的正确性，测试的对象是软件设计的最小单位：函数、或者类。
• 项目中的测试类就是测试接口类的，属于单元测试，一般由开发人员测试。

集成测试

• 集成测试也称综合测试、组装测试、联合测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。其主要目的是检查软件单位之间的接口是否正确，集成测试的对象是已经经过单元测试的模块。

系统测试

系统测试是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符合系统说明书的地方，主要包括功能测试、界面测试、可靠性测试、易用性测试、性能测试。 功能测试主要针对包括功能可用性、功能实现程度（功能流程&业务流程、数据处理&业务数据处理）方面测试。在集成测试之后。

集成测试和系统测试之间的比较：

• 测试内容：集成测试是测试各个单元模块之间的接口，系统测试是测试整个系统的功能和性能；
• 测试角度：集成测试偏重于技术的角度进行测试，系统测试是偏重于业务的角度进行测试。

验收测试

• 也称交付测试，是针对用户需求、业务流程进行的正式的测试，以确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统。

• 验收测试包括alpha测试和beta测试，alpha测试是由开发者进行的软件测试，beta测试是由用户在脱离开发环境下进行的软件测试。

QPS（每秒查询率）

• QPS：每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准

  用来衡量服务器的机器性能。

TPS

• TPS：Transactions PerSecond（每秒传输的事物处理个数），即服务器每秒处理的事务数。TPS包括一条消息入和一条消息出，加上一次用户数据库访问。
• 是软件测试结果的测量单位。

测试生命周期

测试周期是指从测试项目计划建立到BUG提交的整个测试过程。

包括软件项目测试计划，测试需求分析，测试用例设计，测试用例执行，BUG提交五个阶段。 软件测试周期并行与软件生命周期，存在于软件生命周期的各个阶段。

软件生命周期

软件生命周期是指软件的产生直到报废的生命周期。

包括问题的定义及规划，需求分析，软件设计（概要，详细），软件编码，软件测试（单元测试，集成测试，系统测试，验收测试），运行维护

测试用例的组成元素

用例编号

用例标题

功能模块名称

前置条件

输入数据

操作步骤

预期结果

优先级

执行结果

编写人

执行人

其他补充项

BUG描述、评级

对bug的描述尽量简短但要求清晰，对bug出现的条件进行详细的描述，包括输入的测试用例、使用的环境、有没有和其他软件同时运行，以及需要写清bug出现的位置，帮助开发更好定位。

按照用户体验（bug是否很严重的影响用户体验）、影响系统的程度进行评级。

一条bug记录的组成
（1）bug内容

（2）bug发现时间

（3）测试条件（系统配置信息、环境、软件版本、浏览器版本…）

（4）预期结果和实际结果的对比，相关的分析

（5）如何重现这个bug的步骤

（6）这个bug的严重性（会多大程度的影响系统或用户使用）

（7）bug发生的位置

Web和app测试的区别

• 首先是web和app的区别：web是b/s架构的，基于浏览器；app是c/s架构的，必须要有客户端。Web测试中只要更新了服务器，客户端就会同步更新，保证每个用户用的客户端一样；app就不能保证完全一致，因为app客户端需要用户主动更新，如果app测试中修改了服务器，就意味着客户端用户使用的所有核心版本都要进行回归测试
• 性能方面：web主要看响应速度；app还看电量、流量、CPU、内存…
• 兼容方面：web基于浏览器，主要看电脑硬件、电脑系统；app依赖于手机或平板，关注的系统主要是安卓和ios，还要关心分辨率、屏幕尺寸
• App比web测试多一些专项测试：弱网测试，安装、卸载、更新，界面操作、触摸手势等

以百度搜索为例，设计测试方案

功能测试：

• 输入搜索信息，点击搜索按钮是否能获取搜索结果，跳到结果界面；

• 搜索结果界面弹出的信息是不是符合我输入的信息

• 没有输入信息，按搜索看会有什么结果

• 对输入框能输入的最大字符数进行边界测试，（假设限制是30个字符），那么分别输入20，30，31个字符的文本进行测试，测试超出输入限制会出现的结果

• 测试输入敏感词时的搜索结果

• 输入不同国家语言的搜索结果

• 查询不到搜索结果的情况显示的结果

• 从搜索结果界面返回的按钮能不能正常返回

• 点击百度的标签能不能跳到相关的热搜界面

• 测试百度的图片搜索能不能正常使用

• 图片拖曳和上传的功能是否均能实现，粘贴图片网址能不能用

• 如果粘贴的图片网址不存在是否能给出正确的提示反馈

• 输入特别大的图会发生什么现象

性能测试：

• 测试搜索时的响应时间能否符合需求

• 网速慢的条件下还能不能正常搜索

• 多用户同时访问，或者一个时间点访问量突然增大的情况，对这些特殊情况进行模拟，测试还能不能进行正常搜索

易用性测试：

• 使用操作是否简单，是不是输入查询信息之后点击搜索按钮就行了；

• 在输入框输入搜索词的过程中下拉框能否弹出相关的联想搜索（你可能要搜）

• 输入框有没有保存最近搜索的信息的记录

• 除了点击搜索按钮进行搜索，测试按回车进行检索的功能

兼容性测试：

多种系统下的多种不同的浏览器下是否能正常显示、正常使用；

在不同的手机浏览器中打开是否能正常显示、正常使用；

各种语言平台下是否都能正常使用

安全性测试：

能不能防止搜索时对数据库的恶意攻击的情况，如SQL注入

UI：

界面设计是否简介，是否符合用户审美

图标能不能正常显示，界面有无错别字

测试用例：上传文件

界面测试：

• 上传文件的按钮文字是否正确
• 上传后正确&错误提示的文字是否正确
• 说明性文字是否正确

文件名称测试：

• 上传的文件各为中文
• 上传的文件名称为英文
• 上传的文件名称中含有特殊字符
• 上传的文件名称为数字
• 上传的文件名为中文、英文、数字等组合名称
• 长传的文件名中含有空格

文件格式测试：

• 上传的文件名称长度超出限定范围
• 上传文件的格式为图片(Jpg， jpeg， png）
• 上传文件的格式为txt文本
• 上传文件的格式为word (后缀名为doc，docx)
• 上传文件的格式为视频
• 传文件的格式为音频
• 上传文件的格式为excel （后缀名为xls，xlsx）
• 上传文件的格式为ppt
• 上传文件为可执行的exe文件
• 上传文件的格式为压缩文件(.rar，.zip)
• 上传文件的格式为bat文件
• 上传文件的格式为jsp文件
• 上传文件的格式为iso镜像文件

文件大小测试：

• 上传文件的数量为1个
• 上传文件的数里为限制个数N个
• 上传文件的数量为限制个数N-1个
• 上传文件的数量为限制个数N+1个
• 上传文件的大小为0kb
• 上传文件的大小为2G以上的超大文件(超过限制大小)

其他测试：

• 上传文件方式，可以从目录中选择
• 上传的文件可以拖拽上传
• 上传的文件可以手动输入地址上传
• 手动输入正确的文件路径
• 手动输入错误(不存在)的文件路径
• 上传一个正在打开中的文件
• 文件上传成功后，上传后的文件名和文件内容是否正确显示
• 删除上传成功的文件，再次提交上传

性能测试：

• 上传文件时时网速很慢(限速)
• 上传文件过程中断网
• 上传过程中服务器突然停止工作

测试用例：微信扫码点餐

如何测试网站的高并发性

• jemeter多线程

• 测试多用户同时访问，访问量的缓慢增加/迅速增加。。。

• 大量相同类型访问，大量不同类型的访问

• 服务器角度，能够承受多大的压力（？），客户端角度，数据能否成功得到需要的信息，响应时间怎么样

• 实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息

• 一方面保证数据不丢失、一方面保证性能

测试一个前端页面，button按钮不好使，原因，不获取源码的前提下，如何解决（提示接口测试）

• 因为这是个前端界面，可以按F12打开开发者工具，在network里按钮点击时请求有没有发出去，看状态码，有没有生成新文件之类的，确定是不是连接的问题。
• postman模拟发包过去测试也行。