测试相关-面试高频

测试面试相关

面试

测试的具体场景功能测试

具体的测试工具Jmeter Postman selenium pytest

怎么看待测试的潜力与挑战

软件测试是正在快速发展，充满挑战的领域。
尽管现在许多自动化测试软件的出现使得传统手工测试的方式被代替，但自动化测试工具的开发、安全测试、测试建模、精准测试、性能测试、可靠性测试等专项测试中仍然需要大量具有专业技能与专业素养的测试人员
随着云计算、物联网、大数据的发展，传统的测试技术可能不再适用，测试人员也因此面临着挑战，需要深入了解新场景并针对不同场景尝试新的测试方法，同时敏捷测试、Devops的出现也显示了软件测试的潜力。

测试的相关流程

需求测试->概要设计测试->详细设计测试->单元测试->集成测试->系统测试->验收测试来自W模型

测试项目具体工作：搭建测试环境撰写测试用例执行测试用例写测试报告提交BUG表单跟踪bug修改情况

测试的关键是如何选择测试用例。一个覆盖完全的测试用例可以测试出程序是否正确运行，是否有bug等等，是最重要的。

测试设计人员主要负责设计测试用例以及设计测试过程。

软件测试的目的：发现软件缺陷，尽可能早的找出软件缺陷，并且确保缺陷得到修复。

☆测试和开发需要怎么结合才能使软件的质量得到更好的保障

按照w模型的方式进行结合，实现测试和开发同步进行，测试伴随着整个软件开发周期，测试对象包括程序、需求、设计等，有利于尽早地全面的发现问题，大大减少开发成本，提高开发效率。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度
v模型是将测试放在了开发的后半部分，仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证，因此需求阶段的缺陷很可能一直到后期的验收测试才被发现。

w模型的缺点：1. 开发过程中无文档产生，w模型无法用；2 需求和设计测试的要求高，实践困难

在这里插入图片描述

☆测试用例的方法

测试用例（ Test Case ）是为测试设计的数据，由测试输入数据和与之对应的预期输出结构两部分组成

等价类(着重考虑输入条件)

在这里插入图片描述

边界值(着重考虑输入条件)

既可以用于黑盒测试，也可以用于白盒测试

如果需求规定了取值范围：[4，12]，边界值取：4，12，3，13，5；

边界测试法:上点(边界上的点)，内点(边界内的点)，离点(离边界最近的点)
如果需求规定了取值的个数比如4件商品5折，边界值取：3，4，5；

场景设计法

以实际的应用场景来设计，只关心流程是否走通。针对系统的业务流程来进行测试

基本流：很顺利的操作了一遍系统的流程，不存在错误操作（实例图的打大黑线，很顺利）
备选流：不顺利的操作系统，过程中存在错误的操作（实例图中的彩色线，备选流存在重新回到基本流的情况，也存在直接结束用例的情况）

(52条消息) 用例设计方法——场景法[模拟用户使用场景]_好好测的博客-CSDN博客

在这里插入图片描述

判别表

分析多种输入条件组合的情况下，系统执行不同动作的工具

(52条消息) 如何使用判定表法编写测试用例_和小白说掰掰的博客-CSDN博客_根据判定表写测试用例

因果图

用于描述输入与输入、输入与输出之间存在的依赖关系；

输入与输出之间的关系有：恒等、与、或、非；

输入与输入之间的关系有：异、或、唯一、要求；

在这里插入图片描述

根据软件需求文档中列出的功能，考虑各种可能的场景，给定一个输入，对应一个期望的输出。不仅要考虑正常的情况，也要各种异常的情况。

☆测试常用的方法

在这里插入图片描述

黑盒测试(功能测试): 测试人员在不了解软件内部原理和机制的情况下进行的测试，检查程序功能是否按照规格说明书的规定正常使用。主要为了发现以下错误：是否有不正确或遗漏了的功能？在接口输入能否正确地接受？性能上是否能够满足要求？是否有初始化或终止性错误？

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

白盒测试(结构测试):测试人员在了解软件内部原理和流程的情况下进行的有针对性的测试，按照程序内部逻辑测试程序，检验程序中每条通路是否按预定要求正确工作。主要为了发现以下错误：对程序模块的所有独立的执行路径至少测试一次；所有的逻辑判定，取“真”与取“假”的两种情况都能至少测试一次；在循环的边界和运行界限内执行循环体；测试内部数据结构的有效性等

静态测试：不用运行程序的测试，包括代码检查、静态结构分析、代码覆盖率度量、文档测试等等

动态测试：需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等

逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：

1.语句覆盖每条语句至少执行一次。

2.判定覆盖每个判断的取真分支和取假分支至少经历一次。

3.条件覆盖每个判定的每个条件路径覆盖一定包含判定覆盖应取到各种可能的值。

4.判定/条件覆盖同时满足判定覆盖条件覆盖。使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。

5.条件组合覆盖每个判定中各条件的每一种组合至少一次。真真假真真假假假

6.路径覆盖使程序中每一条可能的路径至少执行一次。路径覆盖一定包含判定覆盖

接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。

测试内容：

数据流测试按照程序中的变量定义和使用的位置来选择程序的测试路径

单元测试是以模块为单位进行的单一模块的测试，检查代码结构逻辑通常情况是白盒的.能发现约**80%**的软件缺陷（因为缺陷放大理论，在单元测试阶段发现的bug会在系统测试阶段被放大，放大倍数完全符合80/20理论)

iOS单元测试框架：

集成测试是把各个子模块通过接口组成系统进行测试

非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求一次全部组装起来所要的系统，然后进行整体测试。
增量：测一个模块，就连接一个模块。
三明治集成：综合了自顶向下(深度和广度，需要开发桩模块)和自底向上(非渐增，需要开发驱动模块)两种集成方法的优点，因此也属于基于功能分解集成。就是在各个子树上真正进行大爆炸集成。

系统测试：是基于系统整体需求说明书的黑盒类测试，验证系统是否满足了需求规格的定义，需要同行评审(发现小规模工作产品的错误)。包括：功能、性能、可靠性、安全性测试

验收测试：相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收

正式验收

非正式验收：

Alpha测试：是由用户、测试人员、开发人员共同参与的在**开发者的场所(模拟实际操作环境)**来进行的，在一个受控的环境中进行。
Beta测试：由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终软件。

回归测试：在产生新的版本后重新测试先前的测试用例以保证修改的正确性。

软件状态：

压力测试是性能测试的一种，长时间或超大负荷(吞吐量)的运行测试软件，比如多客户端同时并发操作以考验服务器的性能。确定在什么负载下系统性能处于失效状态，并以此来获得系统能提供的最大服务级别的测试

负载测试：满足最终确定性能指标的情况下，系统所能承受的最大负载量的测试

性能测试的一个基本指标是目标软件对系统内存和**CPU(疲软强度)(响应时间，吞吐量，cpu使用量)**的占用。一个优秀的软件需要持续地对内存和CPU占用进行优化。

冒烟测试是在版本转测试之前,先选择一部分基础的测试用例进行验证，确保全流程没有严重、阻塞性的问题。

稳定性测试主要是监测软件长时间运行是否会出现异常，比如崩溃、死锁、内存泄漏等问题。

兼容性测试则是测试软件在不同环境下的兼容性，比如在不同版本的浏览器、系统、USB摄像头

易用性测试主要是检查软件中是否存在不方便用户使用的问题，主要侧重软件的用户体验。比如操作太繁琐、功能掩藏的太深、界面展现不方便用户使用等。

自动化测试的意义与工作内容

意义：对程序的新版本自动执行回归测试；执行手工测试困难或者不可能实现的测试，如压力测试；能够更好的利用资源，节省时间和人力

工作内容：首先评估项目是否能使用自动化测试，指定测试计划，搭建自动化测试框架，设计测试用例，执行测试，评估。

自动化测试和手动测试的优点缺点

手动测试: 缺点:1.重复的手动测试，代价高；2.依赖于测试人员的能力。
优点:1.可以依据测试人员的经验和对错误的猜测能力；测试人员有逻辑推理能力和是非判断能力。
自动化测试:
优点:1.减少时间和成本，提高资源利用率。2.能够测试手动测试无法进行测试的板块3.测试具有重复性、一致性和复用性。4.能够增加软件信任度。
缺点:1.非常依赖测试质量。2.不能覆盖所有的测试类型，还需要手动测试。3.测试自动化不能提高有效性，还有可能制约软件开发。4.工具本身不具备想象力。在一定程度上是可以减少工作量，但在代码编译阶段还是需要人为操作。

☆测试工具

分析测试点使用xmind、
编写测试用例使用Excel、
提交缺陷使用禅道jira，tapd，
数据库使用navicat连接mysql、oracle，
linux使用xhsell连接，
自动化测试工具使用python+selenium(Web)+uinttest（单元测试框架）, appium
接口测试使用jmeter、postman，
性能测试使用jmeter、loadrunner。

LoadRunner-负载压力测试，预测系统性能。编辑测试脚本、执行测试、分析测试结果
JMeter+Badboy：基于JAVA的压力测试工具，Badboy用来进行脚本的录制
功能测试：通过自动录制、检测和回放用户的应用操作。将输出记录同预先给定的记录比较。
功能测试： QTP(quicktest professional):自动测试工具
白盒测试：C++ TEST（做C和C++的白盒测试）、JUnit（Java白盒测试）

单元测试工具：PureCoverage、Purify、Quantify
缺陷管理工具：Mantis、BugFree、QC、TD
用例管理工具：TestLink、QC
测试辅助工具：SVN

postman接口测试设置断言

(55条消息) Postman接口测试如何设置断言_墨石测试攻略的博客-CSDN博客_postman设置断言

接口测试经常遇到的bug和问题，如下：

（1）传入参数处理不当，导致程序crash；

（2）类型溢出，导致数据读出和写入不一致；

（3）因对象权限未进行校验，可以访问其他用户敏感信息；

（4）状态处理不当，导致逻辑出现错乱；

（5）逻辑校验不完善，可利用漏洞获取非正当利益等

断言：postman在发送请求后，需要对返回的结果做判断，验证是否符合预期。

1.在test页标签中选择接口，断言编写

2.点击【Send】在响应栏中查看结果，预期=实际：PASS；预期≠实际：FAIL

常用的断言：响应状态码；响应中是否含有指定字符串；设置、获取环境变量/全局变量的值；验证响应结果返回的时间是否在指定范围；对返回的结果做Json字段检查

tests["Status code is 200"] = responseCode.code == 200;
tests["Body matches string "] =responseBody.has("string_you_want_to_search ")
pm.environment.get("variable_key");//获取环境变量
pm.test("Response time is less than 200ms", function () {pm.expect(pm.response.responseTime).to.be.below(200);
});//响应结果返回的时间是否在指定范围
pm.test("Your test name", function () {//对返回的结果做Json字段检查var jsonData = pm.response.json();pm.expect(jsonData.value).to.eql(100);
});

tests获取cookie

tests[“cookie_uid”] = postman.getResponseCookie(“uid”).value

如何写测试用例

1、测试人员尽早介入，理解需求，这个是基础
2、根据经验，参考类似需求的测试用例，然后还需要看类似需求的bug情况
3、测试用例方法：清楚输入、输出的各种可能性，以及各种输入的之间的关联关系，理解清楚需求的执行逻辑，通过等价类、边界值、判定表等方法找出大部分用例
4、场景设计：根据自己的经验分析遗漏的测试场景

5、总结类似功能点的测试点，写出质量高的测试用例

微信聊天测试点

主要功能就是发送消息和接收别人发过来的消息

消息的分类：纯文字，图片，文件，表情，语音、视频，文字+表情

聊天的特殊功能：@符号，撤回功能，加好友功能，消息重发，发红包，转账，发送位置信息、发送名片、群聊等功能

(56条消息) 测试微信聊天功能_SmileLily0202的博客-CSDN博客

微信支付

在这里插入图片描述

IP地址测试用例

0.0.0.0~255.255.255.255

在这里插入图片描述

边界值分析补充

0~255的数字范围可以进行边界值分析法进行补充测试用例：-1,0,1,100,254,255,256

ATM取钱功能测试用例

（1）银行卡有效的识别，是否消磁，芯片是否损坏

（2）输入密码是否正确（密码字符串为0-9阿拉伯数字，长度为6）

（3）三次输入错误之后是否锁卡，吞卡

（4）取钱金额是否超过当日单笔最大

（5）取钱的金额是否超过账户已有金额

（6）取钱的单笔金额，额度是否合法（50或100为单位的金额）

（7）atm机子没钱了

（8）交易时断电、断网等

（9）从用户体验上来看检查界面文字是否提示正确布局美观，每一步的语音提示是否正确

(55条消息) ATM机取款问题之场景法设计测试用例_一醉南柯的博客-CSDN博客_atm取款测试用例

设计一个朋友圈点赞的测试用例

功能测试：点赞是否能成功，取消点赞是否能成功；

界面测试：点赞按钮大小、颜色是否符合要求；

接口测试：验证点赞后是否能收到提示信息；

性能测试：点赞后是否在规定时间显示结果，是否在规定时间在朋友手机上进行提示，多人点赞后能否按时显示；

兼容性测试：验证不同平台是否能点赞成功

微信登录界面设计测试用例

一、功能测试
登录正常类、异常类
登录成功后能否能否跳转到正确的页面

注册正常类、异常类

密码是否非明文显示显示，使用星号圆点等符号代替，大写键盘开启的时候要有提示信息。
有验证码时，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色、刷新或换一个按钮是否好用

用户名和密码记录功能，登录失败不记录，登录成功弹出是否记录的提示框

多种登录方式：账户名密码、手机号验证码、扫码
什么都不输入，点击提交按钮，检查提示信息。

输入框提示内容是否与需求文档一致
二、界面测试
1.布局是否合理，按钮是否整齐。
3. 界面的设计风格是否与UI的设计风格统一。
4. 界面中的文字简洁易懂，没有错别字。
三、性能测试
1.打开登录页面，需要的时间是否在需求要求的时间内。
2.输入正确的用户名和密码后，检查登录成功跳转到新页面的时间是否在需求要求的时间内。
3.模拟大量用户同时登陆，检查一定压力下能否正常登陆跳转。
四、安全性测试
1.登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)。
2.用户名和密码是否通过加密的方式，发送给Web服务器。
3.用户名和密码的验证，应该是用服务器端验证，而不能单单是在客户端用javascript 验证。
4.用户名和密码的输入框，应该屏蔽SQL注入攻击。
5.用户名和密码的的输入框，应该禁止输入脚本（防止XSS攻击）。
6.防止暴力破解，检测是否有错误登陆的次数限制。
7. 是否支持多用户在同一机器上登录。
8. 同一用户能否在多台机器上登录。
五、兼容性测试
1.不同移动平台或PC环境下下能否显示正常且功能正常
2.同种平台下不同微信版本下能否显示正常且功能正常。
3.不同的分辨率下显示是否正常。
六**、本地化测试**

不同语言环境下，页面的显示是否正确。

对系统写出测试用例

一个系统，多个摄像头，抓拍车牌，识别车牌，上传网上，网上展示

功能：1.每个摄像头都能抓拍车牌；2.每个摄像头抓拍到的车牌能正常交给系统处理；3.系统能够正确识别车牌；4.系统能够将识别出的车牌上传；5.上传至网络的车牌能够正常展示出来；

一、功能测试
1.使用正常的车牌，保持车牌静止，检查每个摄像头是否能抓拍车牌；
2.使用类似非车牌的写有字的纸板，检查每个摄像头是否抓拍；
3.使用正常的车牌，保持车牌较高速移动，检查每个摄像头是否能抓拍车牌；
4.在多种情况下检查每个摄像头抓拍到的车牌能否正常交给系统处理，如临时断电、断网后能否正常将数据交给系统；
5.使用抓拍到的正常的车牌，交由系统处理，检查系统能否识别车牌；
6.使用非车牌的其他图片，交由系统处理，检查系统能否识别；
7.在多种情况下检查系统能否将正常识别出的车牌进行上传，如临时断电、断网后未上传数据是否能继续上传；
8.构造非车牌的其他内容的数据，检查系统能否将异常内容进行上传；
9.检查上传至网络的车牌能否正常展示出来；
10.上传非车牌的其他内容的数据，检查能否正常显示出来。
二、性能测试
1.同时向一个摄像头展示多个静止的车牌，检查摄像头能否抓拍到多个车牌；
2.同时向一个摄像头展示多个较高速运动的车牌，检查摄像头能否抓拍到多个车牌；
3.抓拍后，检查系统识别车牌的时间是否在需求要求的时间内；
4.模拟大量抓拍照片同时交由系统处理，检查一定压力下系统能否正常识别车牌；
5.模拟大量车牌同时上传，检查一定压力下能否上传成功。
三、安全性测试
1.检查是否能够通过给车牌加装饰物等方法，使摄像头无法抓拍或抓拍后系统无法正常识别车牌。

对杯子写出测试用例

1.界面测试：是否美观； 2.功能测试：能否装水，能否喝水，会不会漏水； 3.安全测试：水、瓶子是否含有有毒物质； 4.易用性：喝水是否方便，有无防滑设计，是否烫手； 5.兼容测试：能否装其他液体，酒精果汁汽油等； 6.压力测试：放24小时是否泄漏

如果用户点击微博的关注图标但是app上面没有反应，应该怎么排查这个问题

网络代理抓包分析请求定位问题

1.在Eclipse Devices窗口，选中app对应的包名，然后点击debug图标（绿色的小虫子），然后切换到Debug视图。 2.切换视图之后，可以看到debug下，app的线程列表。 3.对于mn线程（第一个线程），选中，并将其挂起Suspend。 4.然后我们就可以看到，Suspend之后，mn线程卡住的位置。

做测试的过程中，假如前端和后端吵起来了都在踢皮球觉得对方该改代码

1.找开发经理 2.谁改动量小谁改（基于安全性、性能、可测试性、可维护性讨论敲定一个解决方案，做到开发环境方便开发，线上环境少配置少依赖、少出错机会） 3.第三视角看对错

软件质量的六个特征

a.功能特征：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。
b.可靠特征：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。
c.易用特征：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性
d.效率特征：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。
e.可维护特征：与进行指定的修改所需的努力有关的一组属性。
f.可移植特征：与软件从一个环境转移到另一个环境的能力有关的一组属性。

当前工作中涉及的测试问题(测试流程和测试性能)

按照测试流程来说，开发没有进行自测，未达到提测标准就进行提测，后期全靠测试人员兜底，对项目整体质量影响比较大，

测试性能来说，一般压到一定数量，在未达到指标之前出现报错，需要开发人员优先解决报错优化代码，直到达到性能指标/没有给出具体标准

你做过压力测试吗？怎么做

压力测试：对系统进行极限压力测试，比如多客户端同时并发操作以考验服务器的性能，再比如借助自动化测试工具对客户端某个功能进行长时间的拷机测试

1）确定性能需求（秒杀或者支付，多客户端同时并发操作以考验服务器的性能）（2）制定压测计划（3）设计压测场景（4）搭建压测环境（5）编写压测脚本（6）执行压测用例（7）观察性能结果并分析（8）输出测试报告

app性能测试的指标

1、内存：内存消耗测试节点的设计目标是为了让应用不占用过多的系统资源，且及时释放内存，保障整个系统的稳定性。内存测试中存在很多测试子项，清单如下： ●空闲状态下的应用内存消耗； ●中等规格状态下的应用内存消耗； ●满规格状态下的应用内存消耗； ●应用内存峰值； ●应用内存泄露； ●应用是否常驻内存； ●压力测试后的内存使用。

2、CPU：中央处理器—运算核心和控制核心

3、流量：应用首次启动流量提示，应用后台连续运行2小时的流量值，应用高负荷运行流量峰值。

4、电量： ●测试手机安装目标APK前后待机功耗无明显差异； ●常见使用场景中能够正常进入待机，待机电流在正常范围内； ●长时间连续使用应用无异常耗电现象。

5、启动速度：●首次启动–应用首次启动所花费的时间；●非首次启动–应用非首次启动所花费的时间； ●应用界面切换–应用界面内切换所花费的时间。

6、滑动速度、界面切换速度

7、与服务器交互的网络速度

机器学习去进行自动化测试，如何监控异常流量（脉冲），如何和正常流量作区分

让自动化测试变得更加智能，在自动化测试过程中，当测试功能模块越来越多，没有太多的时间去全部覆盖，我们可以采用归纳学习的方式，基于自动化测试的执行结果或者手工测试执行的结果为数据输入，然后基于一定的模型（例如：以通过率和模块的重要率计算的平均值）得出测试推荐模块，或者当要执行一个功能模块时，基于历史数据和模型（bug出现的错误相关性，功能相关性等）计算出与该功能模块相关性最大模块，并推荐测试。

如何监控异常流量 1、抓包 tcpdump -i eth0 -w server.cap 对包文件使用第三方工具如：wireshark做分析 2、iftop yum install iftop 3、iptraf yum install iptraf –y 或 yum install iptraf-ng -y 启动命令ifptraf-ng

web测试和app测试的不同点

系统架构方面： web项目，一般都是b/s架构， app项目，则是c/s的，必须要有客户端，
性能方面: web页面主要会关注响应时间而app则还需要关心流量、电量、CPU、GPU、Memory这些。
兼容方面： web是基于浏览器的， app测试则要看分辨率，屏幕尺寸，还要看设备系统，测试安装、更新、卸载，安装时的中断、弱网、安装后删除安装文件。如网络、适配性。

测试网络协议

1、一致性测试：检测协议实现本身与协议规范的符合程度

2、互操作性测试：基于某一协议检测不同协议实现间互操作互通信的能力

3、性能测试：检测协议实现的性能指标，如数据传输速度，连接时间，执行速度，吞吐量，并发度，

4、健壮性测试：检测协议是现在各种恶劣环境下运行的能力，比如注入干扰报文，通信故障，信道被切断

开放性问答

如果开发不认可这个bug？

1.从自身入手：

再次验证所提的 bug 确实是 bug，确保自身对需求的理解无误；
检查bug的描述是否会产生歧义；
检查是否是环境或数据的问题，在开发处无法复现。

2.与开发人员确认：

了解开发为什么不认可，需求不明确？

接收到的需求是否一致？或者理解错误？

与开发讨论，讲清楚你的理由（对事不对人），该问题可能对用户造成的影响。

3.找权威仲裁：

如果与开发讨论后依然无法解除争议，这种争议问题一般集中在需求有歧义不明确、或用户体验的地方（数据问题、逻辑问题一般不会有争议）。

可以先找产品经理确认，产品经理对用户的使用和期望是最了解的，也就会清楚 bug 可能对用户造成的影响。

产品经理通过对影响的确认评估是否需要修改。如果你对此依然有疑虑，应该表明你的观点，由产品经理或项目经理决定。

怎么给bug做优先级？

优先级的定义依赖于严重程度，在大多数情况下，严重程度越严重，那bug的优先级越高。

1、Blocker（崩溃）：

阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等

（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）

严重花屏
内存泄漏
用户数据丢失或破坏
系统崩溃/死机/冻结
模块无法启动或异常退出
严重的数值计算错误
功能设计与需求严重不符
其它导致无法测试的错误, 如服务器500错误
2、Critical（严重）：

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等

（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）

功能未实现
功能错误
系统刷新错误
数据通讯错误
轻微的数值计算错误
影响功能及界面的错误字或拼写错误
安全性问题
3、Major（一般）：

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等

(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度)

操作界面错误（包括数据窗口内列名定义、含义是否一致）
边界条件下错误
提示信息错误（包括未给出信息、信息提示错误等）
长时间操作无进度提示
系统未优化（性能问题）
光标跳转设置不好，鼠标（光标）定位错误
兼容性问题
4、Minor（次要）：

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等

（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

界面格式等不规范
辅助说明描述不清楚
操作时未给用户提示
可输入区域和只读区域没有明显的区分标志
个别不影响产品理解的错别字
文字排列不整齐等一些小问题
bug的优先级：

1.Immediate
即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。

Urgent
即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。
High
即“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。
Normal
即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。
Low即”低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。

测试

在这里插入图片描述

测试

测试类型

负载测试：压力相对较大的测试（数量或时间），测试系统在一种或者几种极限条件下的相应能力

2.压力测试：关心的是软件系统本身

3.基准测试：增加一个新的模块就要进行打开、关闭新模块

4.稳定性测试:长时间运行看系统会不会有问题

5.并发测试：涉及服务器容量以及多进程协调同步问题

问答

请设计稳定且低成本的全自动化方案，获得一台手机的启动时长。

手机的启动时长带给用户的最直观的性能体验

手工测试：掐秒表，可是比较麻烦，也可能存在误差；

利用工具：手机启动小助手，获取启动时长；

自动化测试：将手机和计算机建立连接；通过计算机向连接的手机发送指令，运行手机中的屏幕录制应用，对手机运行待测试应用时的屏幕开始录制；测试人员操作计算机端，发送相应的控制指令给手机端，运行手机端的待测试应用，进行测试；测试结束后，如果测试人员发出测试停止指令，则屏幕录制应用停止录制屏幕，并将录制的视频发送给计算机；系统启动的完成时间（当前时间）减去初始时间，即为我们手机启动过程的时间。

进阶：在电脑端给手机端发送重启动命令；设计自动化脚本获取多次启动时间计算平均值

请尽量多的列举有哪些可能的原因，会导致一个应用的用户帐号无法登录。

未注册；用户名错误；用户密码错误；输入用户名或者密码时加入了空格；换了不同电脑或手机需验证；登录失败次数过多，导致用户账号被锁定，需一定时间解锁；超过登录时限，浏览器中的cookie被自动清理了，需重新登录；

请从用户体验的视角尽量多的列举Android与iOS系统的差异。

相同：屏幕触摸、点击、滑动等操作扁平化、通知中心、分屏多任务、系统权限、指纹识别

流畅性：Android系统采用虚拟机的运行机制，需要消耗更多系统资源，使用一段时间后容易出现卡顿(可能因为JAVA开发语言的关系，iOS的则为Objective-C)，桌面灵敏性不如ios系统；ios系统则很少出现卡顿现象，使用流畅，各类通知推送功能准时送达

操作界面：Android可以根据自己的喜好来设置，更加多样化；ios系统界面单一。

省电情况：Android会占用更多的资源来支撑系统运行，导致了它会比较费电；ios系统更加省电。

后台执行程序的角度，IOS系统基本不需要清理后台。IOS有独特的任务管理机制，当程序不在前台运行时，除了GPS，音频播放服务和VOIP服务以外，其他的应用都是会被系统挂起的，从技术上说，挂起并代表不执行，只是数据驻留在内存上而已。

系统更新，如果IOS出了新版本，搭载其系统的苹果机都能及时进行升级。而Android出了新版本，普通用户是享受不到的，因为它不能自动更新到新版本。

安全的角度来说，IOS系统更安全。

兼容性：安卓系统的开源特性，导至该系统平台上开发的软件门槛限制就比较低，因此软件更加多样化，对于用户来说，兼容性更好

隐私性：Android系统开放权限广阔，每下载安装的APP都想获取你手机的所有功能和权限，App几乎可读取本地所有文件；iOS端App无法读取本地除图片和视频外的其他文件

应用市场：Android应用市场多，无需付费，审核宽松且时间短；iOS应用市场只有App Store，每年99或299美元，审核严格且时间长

虚拟商品购买和提成规成：Android无限制，不抽成；iOS限制较多且抽成30%

价格，IOS是苹果公司的专利，价格相对来说毕竟高昂，Android是谷歌公司的，但是是免费开源的，许多公司都有各自特色的API，产品种类更多，价格相对来说比较低，性价比高。

请设计稳定且低成本的全自动化方案，将一本纸质书籍存储为电子版txt格式。

自己设计：1.将纸质书籍进行拍照（拍照人手不抖，照片质量高且清晰）

2、将照片按照顺序导入电脑

3、选择照片处理软件，对图片进行批量化处理（调节对比度和锐化，保证文字清晰），如picasa

4.OCR文字处理软件：将图片中的文字识别出来，如PDF OCR

5、将第4步识别的文字保存为txt

6、修改少量识别错误的文字

1。去除书钉、书胶、绑书绳等无关材料，将纸质书籍拆解成一页页，以便于下一步扫描；

2。将上一步处理过的散装书籍放入扫描机，扫描机自动化扫描每一页，并将图片传到电脑，当扫描机监测所有页面已完成扫描，发送FIN信息给电脑；

3。电脑接收到图片，自动OCR文本转换，并将文本存储为txt格式。当电脑接收到扫描机的FIN信息，将txt保存。

开发模型与测试模型

瀑布模型：将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段的过程。
原型模型：开发人员快速地构造整个系统或者系统的一部分以理解或澄清问题。不适宜大规模软件的开发
螺旋模型：将开发活动和风险管理结合起来，以减小风险。
喷泉模型：开发过程模型以用户需求为动力，以对象为驱动，适合于面向对象的开发方法。