怎么理解测试

软件测试其实包括测试（Testing）和检验（Checking）两部分，我们通常所理解的测试可能仅仅是检验。不论是自动化测试也好，还是手工执行测试用例也好，只要是基于预先设定的可断言的脚本来执行用例，都属于检验范畴。

对测试开发工程师的认识

从名字来看，可以理解为既要懂测试，也要懂开发。事实上，确实如此。

对与单元测试、代码评审、代码重构，它们可以保证产品代码的质量。但国内大部分公司都是由开发人员负责。确实，自己写的代码自己更加了解，让旁人为其写测试代码，费时费力，性价比太低。

《Google软件测试之道》中描述，它是⼀个融合开发⾓⾊和质量意识于一身的角色，兼具开发人员的技能和测试人员的思维。他们会参与单元测试代码编写、业务代码评审、业务代码重构、测试工具开发、测试平台开发、框架开发。

总的来说，测试开发工程师的定位就是保障产品的质量和提高测试的效率

测试工具：现在很多的系统都是使用微服务架构，对这类系统，更多的可能是一些 mock 和 fake 工具，当然，根据各自业务的不同，可能需要不同的一些其他工具。其他很多都是利用现有的工具，如 posman、jmeter 等。

测试平台：多是一种自动化测试平台，一般都是基于测试框架来管理项目、管理测试用例、展示测试结果等等这么一些功能，可以根据业务测试需求来开发。

测试框架：框架是整个自动化组件结构的集合。这也是一个指导原则，如果遵循该指导原则，可以形成易于维护和增强的结构。测试框架应独立于应用程序，并且应易于使用，修改或扩展。

性能测试：一些性能指标，性能测试方法，分析性能瓶颈，还有一些工具或框架的使用，如 jmeter、loadrunner、locust 等。

自动化测试：实现自动化测试的解决方案（单元、接口、UI），工具或框架的认知和使用。

测试用例

把软件测试行为做一个科学化的组织和归纳，用来指导测试行为。

一般需求入基线后，测试人员开始介入项目，对需求进行分析，并根据自己对需求的理解设计出详细的测试用例。这样在测试执行时，按照设计好的过程去执行，避免由于人为的原因使测试不全面。

在设计测试用例的过程中，测试人员也可以根据自己的理解，对需求提出不同的看法，或者发现需求中某些功能描述得不够详细或者有歧义，提早发现问题，降低项目风险。

1. 测试用例设计的方法分类

从测试方法上可以分为黑盒测试、白盒测试、灰盒测试。

1.1. 黑盒测试

程序的内部逻辑实现对测试人员是透明的。测试人员只需要根据需求文档来决定程序应该做什么事情，会产生什么样的结果。测试人员对需求中的每个点进行覆盖测试。

目前流行的黑盒测试设计方法有：

Ø 等价类划分

多用于多用于输入框，等价类：一般可分为有效等价类和无效等价类。

在这里插入图片描述

Ø 边界值分析

一般边界值分析是因为程序开发循环体时的取数可能会因为<,<=搞错。
如1~100，1和100为上点，0和101为离点。

Ø 因果图法

因果图法比较适合输条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。

在这里插入图片描述

Ø 场景法

在这里插入图片描述

5，正交表法
应用场景：多用于下拉框如（地区）在一个界面中有多个控件，每个控件有多个取值，控件之间可以相互组合，不可能（也没有必要）为每一种组合编写一条用例，如何使用最少最优的组合进行测试。

在这里插入图片描述

1.2. 白盒测试

属于代码级的测试。测试人员不仅要了解程序要做什么，还要了解程序是如何实现的，根据实现方法设计测试用例。测试人员需要对代码进行覆盖测试。由于现在的程序分支、循环都很多，所以完全覆盖代码是不可能的，现在比较常用的设计方法有：

Ø 语句覆盖

Ø 分支覆盖

Ø 条件覆盖

Ø 条件组合覆盖

Ø 基本路径覆盖

Ø 循环覆盖

1.3. 灰盒测试

类和接口级的测试。介于黑盒测试和白盒测试之间，既关心程序输出的正确性，也关心程序的内部逻辑，但这个逻辑不是代码级的。举例来说，对类或者接口进行测试，不关心代码的实现，只关心每个方法和属性在执行过程中是否正确，这就属于灰盒测试。

测试用例的评审和变更
1.测试用例本身的描述是否清晰；

2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；

3.是否针对需求文档，测试用例是否覆盖了所有的软件需求；

4.是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。
6，测试用例的变更
测试用例并非一成不变。如果软件修改之后发生变化，或者需求发生变更，那么测试用例便不再满足当前版本软件的测试需求，由此需要进行修改和变更操作。

自动贩售机：如果顾客付款了但是没有拿到商品。哪个环节出了问题

硬件方面，软件问题、Sql容错机制(容错机制指的是某种系统控制在一定范围内的一种允许或包容犯错情况的发生，主要用于工程设计中。当然，容错不等于无限度宽容，更不等于可以胡来。)

一个纸水杯的测试用例设计

需求：一个带有广告图案的花纸杯。查看需求说明书。

可从功能性、性能性、易用性、稳定性、安全性……方面进行测试

功能性：

水杯的特性：

1、杯子的容量：能装多少升水，少量、半杯、满杯。

2、杯子的形状eg：圆形、上口大、下口小。

3、杯子的材料：纸杯。

4、杯子的耐温度：装冷水、冰水、热水。

5、杯子是否会漏水。

6、用杯子装水，看是否能喝到

广告的图案：

1、广告图案是否容易剥落。

2、广告图案是否合法。

3、广告图案遇水是否是否会掉落。

性能性：

1、盛冷水和热水时分别盛多少水杯能够承受。

易用性：

1、杯子是否方便饮用。

2、装热水时杯子是否烫手。

3、杯子是否有防滑措施。

稳定性：

1、装入液态多久后会漏水。

2、杯子从不同高度落下的损毁程度。

安全性：

1、杯子有没有毒或细菌。

2、杯子装入热水是否会变形或有异味。

3、装入不同液体，是否发生化学反应。eg：啤酒、可乐、咖啡等饮料。

可移植性：

1、杯子再不同的地方、温度等环境下是否都可以正常使用。

破坏测试：

1、检查水杯最大抗挤压和拉扯承受力。
2、检查水杯被破坏后，是否会造成使用者伤害。
用户手册：

1、用户手册是否对杯子的用法、限制、使用条件等做了详细的说明。

测试用例设计书写规范

冒烟测试模糊测试

什么项目适合自动化

①需求稳定，不会频繁变更

自动化测试最大的挑战就是需求的变化，而自动化脚本本身就需要修改、扩展、debug，去适应新的功能，如果投入产出比太低，那么自动化测试也失去了其价值和意义；

折中的做法是选择相对稳定的模块和功能进行自动化测试，变动较大、需求变更较频繁的部分用手工测试；

②多平台运行，组合遍历型、大量的重复任务

测试数据、测试用例、自动化脚本的重用性和移植性较强，降低成本，提高效率和价值；

③软件维护周期长，有生命力

自动化测试的需求稳定性要求、自动化框架的设计、脚本开发与调试均需要时间，这其实也是一个软件开发过程，如果项目周期较短，没有足够的时间去支持这一过程，那自动化测试也就不需要了；

④被测系统开发较为规范，可测试性强

主要出于这几点考虑：被测试系统的架构差异、测试技术和工具的适应性、测试人员的能力能否设计开发出适应差异的自动化测试框架；

4、常见的自动化测试工具简介

UFT（Unified Functional Testing）

即原来的QTP（Quick Test Professional Software）与ST（Service Test）合并而来，由HP公司开发，是一个企业级的商业自动化测试工具，提供了强大易用的录制回放功能，

同时兼容对象识别模式与图像识别模式，支持B/S和C/S两种架构的软件测试；

Robot Framework

一款基于python语言编写的自动化测试框架工具，具备良好的扩展性，支持关键字驱动，支持多种类型的客户端和接口，可进行分布式测试；

Selenium

应用于web的自动化测试工具，支持多平台、多浏览器、多语言来实现自动化，优点如下：

①开源、免费；

②多浏览器支持：chrome、Firefox、IE、Edge等；

③多平台支持：Linux、Windows、MAC；

④多语言支持：java、python、Ruby、C#、JavaScript、C++；

⑤对web界面有良好的支持；

⑥简单（API简单）、灵活（开发语言驱动）；

⑦支持分布式测试用例执行；

5、做UI自动化测试，需要什么技能

①前端相关技术
HTML、XML、JavaScript、TCP/IP协议等

②一门编程语言

就像前面说的，selenium支持多种语言，根据个人情况以及项目的开发语言酌情选择；

③合适的工具选型

比如selenium，比如UTF等；

④需求分析

项目类型，特质，生命周期，是否适合开展自动化测试等；

W模型和V模型

这里写图片描述

V模型的优缺点：

1、优点：包含了底层测试（单元测试）和高层测试（系统测试）；

　　　　清楚的标识了开发和测试的各个阶段；

　　　　自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。
2、缺点：自上而下的顺序导致了，测试工作在编码之后，就导致错误不能及时的进行修改；

　　实际工作中，需求经常变化，导致v模型步骤，反复执行，返工量很大，灵活度较低。
　改良：每个步骤都可以进行小的迭代工作。

W模型的优缺点：

优点：

　　开发伴随着整个开发周期，需求和设计同样要测试；
　　更早的介入测试，可以发现初期的缺陷，修复成本低；
　　分阶段工作，方便项目整体管理。
缺点：

　　开发和测试依然是线性的关系，需求的变更和调整，依然不方便；
　　如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高！

H模型的优点：
　　>开发的H模型揭示了软件测试除测试执行外，还有很多工作；
　　>软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；
　　>软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；
　　>软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。

H模型的缺点：
　　>管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制；
　　>技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；
　　>测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难；
　　>对于整个项目组的人员要求非常高：在很好的规范制度下，大家都能高效的工作，否则容易混乱。例如：你分了一个小的迭代，但是因为人员技能不足，使得无法有效完成，那么整个项目就会受到很大的干扰。

v模型适用于中小企业；

　　w模型适用于中大型企业（因为人员要求高）；

　　h模型人员要求非常高，很少有公司使用

微信换头像，测试用例

1、点击头像可以放大观看

2、查看头像是否支持放大，缩小

3，刚创建账号时是否显示默认头像

4，查看头像之后点击其它区域自动退出

5，头像支持的图片格式，图片大小

6，支持相机拍摄的图片和从网上下载的图片

7，选择完图片后是否有一个定框

8，选择相片—从手机相册获取

9，选择相片—用照相机拍照

10，头像显示的是方形还是圆形

11，选择图片范围时图片是否支持放大／缩小

12，选择好图片区域后保存，头像是否居中显示，还是只显示选择图片区域的某个角落

13，保存完图片后是否会有提示更换头像成功

14，修改头像后去app其它模块时是否马上刷新显示最新的头像

15，进入更换头像界面时可以取消更换头像

16，选择从相册选取图片还是从照相机时都能取消，返回到修改头像界面

17，头像是否支持本地缓存，断开网络之后是否还能显示头像

18，网络异常时，修改头像失败，会有提示

19，更换头像后，测试好友是否能及时看到更改的头像

20，不同网速下更换头像，是否都能更换成功

微信发红包抢红包功能，设计测试用例

微信发红包从功能、性能、安全、兼容性、界面、易用性进行测试。

功能测试

输入金额

在红包钱数，和红包个数的输入框中只能输入数字；

红包里最多和最少可以输入的钱数；

当红包钱数超过最大范围是不是有对应的提示；

红包的金额里的小数位数是否有限制；

如果直接输入小数点，那么小数点之前应该有个0；

输入钱数为0，"塞钱进红包"按钮不能点击。

红包个数

超过最大拼手气红包的个数是否有提醒；

拼手气红包最多可以发多少个红包；

发送的红包个数超过最大范围是不是有提示。

红包描述
在红包描述里是否可以输入汉字，英文，符号，表情，纯数字，汉字英语符号；

是否可以输入它们的混合搭配；

红包描述里许多能有多少个字符 10个；

红包描述金额，红包个数框里是否支持复制粘贴操作；

红包描述里的表情可以删除。

支付

余额不足时，红包发送失败；

余额不足时，会不会自动匹配支付方式；

支付时可以密码支付也可以指纹支付；

可不可以自己选择支付方式。

发红包

可以按返回键，取消发红包；

支付成功后，退回聊天界面；

是否可以连续多次发红包；

发完红包不能撤回。

抢红包

没抢之前不能看到金额；

发送的红包别人是否可以领取；

用户是否可以多次抢一个红包；

发的红包自己可不可以领取 2人，多人；

24小时内没有领取的红包是否可以退回到原来的账户；

超过24小时没有领取的红包，是否还可以领取；

断网时，无法抢红包。

记录

在发红包界面能否看到以前的收发红包的记录；

红包记录里的信息与实际收发红包记录是否匹配；

发红包金额和收到的红包金额应该匹配。

性能测试

不同网速时抢红包，发红包的时间；

发红包和收红包成功后的页面跳转时间；

收发红包的耗电量；

所占内存大小。

兼容性

iOS和安卓等不同操作系统间操作；

电脑端是否可以抢微信红包；

不同微信版本之间操作；

不同屏幕分辨率。

界面测试

布局是否合理，testbox和按钮是否整齐；

testbox和按钮的长度，高度是否复合要求；

界面的设计风格是否与UI的设计风格统一；

界面中的文字简洁易懂，没有错别字。

安全测试

微信号异地登录，是否会有提醒；

红包被领取以后，发送人的金额会减少，领取人金额会增加；

发送红包失败，余额和银行卡里的钱数不会少；

红包发送成功，是否会收到微信支付的通知。

易用性测试

红包描述，可以通过语音输入；

支付方式可以为指纹支付也可以为密码支付。

cpu占用率异常高，如何测试找到根源

CPU占用率过高一般有两种主要原因，一是硬件的原因，二是软件的原因。硬件的问题好排查，也好解决。硬件主要是如电脑配置太低或太老，然后又同时打开过多的软件导致的。硬件导致CPU占用率过高的情况比较少，主要是因为电脑配置的不合理或配置过低过旧导致的问题，如果是这种情况导致的，最好升级处理器或者换电脑从根本上解决问题。
软件导致CPU占用率过高的情况比较多。要涉及到的是系统问题，比如系统过于臃肿，开启过多程序以及电脑中病毒木马等等都会产生CPU使用率过高，而导致电脑速度慢。解决办法主要是围绕系统优化，优化开机启动项、尽量避免开启太多程序等等方面来进行避免或解决。

1、木马与病毒：有很多的蠕虫病毒，一直都在恶意循环活动，感染各类系统文件，大量占用CPU资源，这种情况就很容易出现CPU使用率过高。杀毒的话建议在安全模式下进行，因为这样查杀比较彻底。同时我们需要经常查看有无异常启动的项。经常性更新升级杀毒软件和防火墙，加强防毒意识，掌握正确的防杀毒知识。
2、运行大型程序、游戏之类：有时候CPU运行率高是一些大型程序导致的，比如占CPU高的大型游戏，这种CPU占用率过高一般由三种情况造成的：第一种是编写的程序不符合导致CPU运行率飚高，这种较少发生，因为一般情况下游戏发布前都会进行测试；第二种情况是游戏与显卡驱动兼容性导致的问题，一般可以通过更新新的显卡驱动来解决；第三种就是电脑的硬件配置满足不了游戏的需求，这种情况下如要继续游戏只能升级电脑配置。

3、磁盘碎片过多：电脑在使用过程中会经常对数据或软件进行复制、移动、安装、卸载等，日积月累，这些操作会在硬盘中形成大大小小的文件碎片，一个文件可能存在硬盘相差很远的扇区中，这样会导致在查找文件或打开程序时速度会变慢，CPU的占用率过高。我们要经常清理系统垃圾，在清理完成之后对磁盘进行碎片整理操作来避免这种情况。

4、电脑启动项太多：电脑的启动项过多是造成CPU占用过高的原因之一，因为在电脑的启动后系统就自动运行了很多应用程序，导致占用了大量的系统资源，所以我们首先需要减少电脑不必要的启动项。我们可以通过管家类的软件来管理系统启动项，也可以通过msconfig命令打开系统配置程序来管理系统的启动项。

5、优化系统服务项：在操作系统中，很多系统服务默认是开启的，但有些非常重要必须运行，但有些并不重要，比如我们电脑没有打印机、无线网络等，那么完全可以关闭打印机功能以及无线网络系统服务等，这样也可以节约系统资源，给CPU节省更多资源。

当机器慢下来的时候，首先我们想到的当然是任务管理器了，看看到底是哪个程序占了较高的比例，如果是某个大程序那还可以原谅，在关闭该程序后只要CPU正常了那就没问题；如果不是，那你就要看看是什么程序了，比如浏览器占用了很高的CPU，那么就要升级该软件或者干脆用别的同类软件代替，有时软件和系统会有点不兼容导致CPU使用率飙升，这种时候我们可以选择WINDOWS的兼容选项。

微博评论测试

评论中图片不显示的原因

测试朋友圈点赞（功能、兼容性）

app加载慢为什么（从七层网络角度)

测试用例设计使用的方法，接口测试使用方法

京东购物车测试用例设计

如何测试小程序

测试发现bug但开发否认怎模办

如果枪击类游戏中，子弹飞出去了，这时候你断网了，伤害会计算吗？为什么？

有什么测试（功能性测试、安全性测试、压力测试）

给你一个计算器app，怎么测试

如果你刷抖音闪退了，有哪些原因

如何为一个APP的网络通话功能设计测试用例？答：正常情况通话、网络连接差时、多人通话、设备故障时通话。（小姐姐特别好，一边面试一边教我，后来帮我补充了一些，比如说功能测试：电话能否拒接，能否挂断，响铃能否取消，能否设置为震动，我自己一直以为这是产品设计要管的事）

如何对视频播放软件卡顿的原因进行测试？

接口测试中遇到的问题

对即将上线的哇哈哈矿泉水进行测试用例的设计

上海用户反馈没有抖音刷新不出界面

什么是测试用例，编写测试用例的方法，加入刷今日头条时候，发现白屏，可能是什么原因？怎么测试？

如何模拟压力测试/如何模拟弱网环境

打开抖音视频卡顿怎么测试

web测试之功能测试邮件测试

app打开后空白页面，怎么测试出问题

和平精英对枪械测试

1、开发犯低级错误怎么办？

开发首先要规范好编码，出低级错时不要指责，内心指出错误。让他们自己进行测试，反思找出错误。

2、你进行过哪些测试，擅长什么?

我主要从事web测试，搭建环境，对程序进行集成测试、系统测试、回归测试。还有编写测试用例，使用手册，功能测试文档。单元测试：测试的最早期阶段，焦点在于被测软件的最小的组成部分。

集成测试：确保最小单元被（部分）整合后能正常操作的测试执行阶段

系统测试：当应用作为整体运行时的测试执行阶段（测试最终的应用）

回归测试：修改了旧代码后，重新进行测试以确认修改操作没有引入新的错误或导致其他代码产生错误。

验收测试：以用户为主，由用户参加设计测试用例，对程序的功能、性能，以及可移植性、兼容性、可维护性、错误的恢复功能等进行确认。主要运用黑盒测试的方法，对系统主要流程、重要功能进行有效性测试，验证所测试的软件是否满足需求规格说明书列出的要求

3、开发说不是bug怎么办？

将自己的见解告诉开发，不行就把见解和bug提交项目经理决定。

4、你的职业规划?

巩固基础测试知识，提高理解需求能力。学习自动化测试，并且运用。技术到位后学习带领测试团队。最后争取达到测试经理水平。

5、什么测试用例才是合格?

能覆盖到所有测试点

6、缺陷测试报告组成？

缺陷编号、缺陷标题、缺陷描述、缺陷优先程度、缺陷所属模块、缺陷所属版本、缺陷所属开发人员、输入数据、输出结果、缺陷分析等。

C/S模式，使用交替方法确认是client还是server端问题。

7、测试用例包括哪些？

用例编号、测试项描述、操作步骤、输入、预期结果、实际结果、测试人、测试时间、备注

8、软件评审的人员和目的

人员：客户、项目经理、开发人员、测试人员目的：查看软件是否还存在问题。是否在不同平台正常运行，是否有和客户理解不一致的地方，是否有改进的地方

9、什么是软件测试？目的?

使用人工或自动化手段运行程序，为了发现软件的错误而执行检验的一个过程目的：以最少的人力、物力、时间找到软件中的缺陷并修改，从而回避风险。

10、兼容测试

检查软件在不同软件、硬件平台是否可以正常运行。即软件的可移植性。主要查看在不同操作系统、浏览器、数据库、不同版本是否正常运行

11、为什么进行软件测试？

没经过测试的软件无法保证质量，好比iso质量认证一样。测试中发现问题，即时提交开发改进，在软件发布时保证软件质量。

12、软件测试类型有哪些？区别与联系？

常见：功能测试、性能测试、界面测试。

功能测试：占比最大，也叫黑盒测试（不看代码）。进行动态测试时，需要测试软件功能，不需要测试软件内部结构和处理过程。

技术方法有：等价类划分法、边界值分析、错误推测、因果图和综合策略。

性能测试：通过自动化测试工具模拟多种正常、异常、峰值条件，对系统各项性能指标测试。

负载测试、压力测试属于此。负载测试：确定各项工作负载下的系统性能，目标是负载主键增加时，系统各项性能指标变化；压力测试：通过系统的瓶颈，获得系统能提供的最大服务级别。

界面测试：界面好坏决定用户对软件第一印象。合理的界面带来轻松愉悦感受，失败界面有挫败感，让强大的功能付诸东流。

区别：功能测试关注软件功能，每个功能可能存在的问题。性能测试软件多用户并发的稳定性和强壮性。界面测试关注用户体验和易用性。

13、好的测试用例关键？

白盒测试：较少的用例覆盖尽可能多的内部程序逻辑结果。

黑盒测试：较少的用例覆盖模块输出和输入接口。用最少用例在合理时间内发现最多的问题。

对可行和不可行的都要考虑：（1）输入（2）详细操作步骤（3）预期输出（4）实际输出

14、黑盒、白盒、单元、集成、系统、验收测试的区别与联系？

黑盒：已知功能设计规格，测试每个功能是否符合要求。白盒：已知内部工作过程，测试每种内部操作符合设计规格。黑盒意味着测试在软件的接口处进行，把测试对象看做一个黑盒子，不考虑程序内部逻辑结构和内部特性，仅看需求说明书检查功能是否符合需求。黑盒-》功能测试（或者数据驱动测试）

15、软件开发过程与角色分工？

测试配合开发等进行需求分析和讨论，根据需求说明书制定《项目测试计划》，编写测试用例，建立测试环境。测试负责新产品测试，原有产品的升级测试，负责软件问题解决过程跟踪，软件开发文档、开发工作的规范化，管理开发部门的产品文档，制作用户手册、操作手册，产品上限测试，监督软件开发过程执行，提高软件质量。

16、软件开发过程与角色分工？

开发与测试开会讨论需求。需求分析人员写出需求分析说明，三部门讨论可行性。给出详细设计说明书，开发编码，给出系统流程图。测试根据此，给出bug统计。

17、不同测试类型的联系与区别？

功能、性能、可靠性、安全性、负载测试，压力、安装/卸载、启动/停止、兼容、互联测试，文档、回归、可使用性、容量测试

18、测试计划工作包括？

是对工作内容的有效组织和规划，保证测试工作有效展开。包括测试目标，测试范围定义，测试方法选择，测试进度里程碑，测试资源管理和配置。测试目标最重要，因为他是软件测试的最终达到结果

19、性能测试工具，原理、实际应用LoadRunner

能够录制测试的操作步骤，对其模拟出多个用户播放出来。

（1）visural user genertor：创建脚本，选择协议，录制操作，编辑操作
（2）中央控制器 controller：调度虚拟用户。创建场景，选择脚本，建立虚拟用户，设计shedual，设置ip spoofer
（3）运行脚本，分析shedual
（4）分析测试结果

20、兼容性

平台兼容、网络兼容、数据库兼容、数据格式兼容。

缺陷等级分类

(1) 最高级–导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等
(2) 紧急—事件非常重要,并且需要马上给予关注
(3) 高级—事件是重要的,并且应该在紧急的事件处理之后尽快得到解决
(4) 中级—事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决
(5) 低级—事件不重要,可以在时间和资源允许的情况下再解决

21、缺陷生命周期

新建bug–提交bug–确认bug–分配bug–修复bug–验证bug–关闭bug

22、测试结束标准

1）一二级缺陷数目达到项目质量管理目标要求，测试暂停返回开发
2）项目出现重大估算和进度偏差，需要暂停或者终止
3）新需求变更大，需修改测试计划和测试用例再进行
4）开发暂停，测试也暂停，备份暂停时的数据
5）所有功能、性能测试用例100%进行

23、测试生命周期

需求测试计划制定和评审–测试用例编写–测试用例执行–bug管理–测试报告输出

24、自我介绍

套路

1）很高兴获得面试机会……想证明我是合适的人选……想获得您的认可……
2）反问面试官：您看我继续介绍项目还是您提问关心的问题？

25、项目介绍

先整体再局部介绍，项目五大维度：

规模（代码规模、需求规模、用例规模、工作量、进度、质量、成本），测试流程，角色与职责，项目中自己角色，自己的特色（做得好的、遇到的困难、做得差的），最后是心得体会。

26、数据库问题

数据库增删改查（insert、delete、update、select）；

表结构增删改查（create、drop、alter、describe）；

存储过程；触发器等

27、Linux系统

常见50个命令（find、-name、type、perm、user、group、ctime、atime）

熟悉vi、熟悉linux搭建测试环境。LAMP环境搭建。

28、缺陷相关

缺陷跟踪流程（流程基本要素）、整体流程（会话）、缺陷单的20个属性、属性的意义、如何描述好缺陷单、缺陷单的5C原则、缺陷重现步骤。你认为最经典的bug

29、用例相关

用例格式要素、用例设计工程方法论、方法要求如何利用。如何评审用例，从那些维度评审，设计好用例需要那些只是结构

30、软件测试流程

熟悉产品/项目–需求评审–测试需求–测试计划–测试方案–测试用例–预测试，第一轮正式测试–第二轮回归测试–第三轮测试，测试报告–总结–测试指南

31、网络相关

基本网络知识（重点TCP/IP协议）网络通信模型，以及一整个网络传输协议家族，为互联网的基础通信架构，提供了点对点的链接机制，将数据应该如何封装、定址、传输、路由以及在目的地如何接收，都加以标准化。

1、应用层：应用程序之间相互沟通的层
2、传输层：提供了数据传输，应用程序之间的通信服务
3、网络互联层：负责提供基本的数据封包传送功能，让每一块数据包都能够到达目的主机
4、网络接口层：接收数据，并进行传输

32、测试工具

性能测试工具：LoadRunner，Jmeter

自动化测试工具：Selenium

测试管理工具：禅道或者Jira

如何去测试指定软件？

技巧：从质量模型、测试工具、测试方法、测试流程、探索式测试，宏观解决，再微观讲解用例设计

33、你还有什么想要问的吗？

满意情况：先表示感谢，问如果有下一轮面试，什么时候，做什么准备；

一般般情况：感谢，对自己表现不太满意，能否给我一些建议；

很糟糕：感谢，认识到不足，希望给建议

34、测试用例编写结构

功能性、界面UI、易用性、安全性、兼容性

35、STAR法则

S（situation）：项目属于什么类型，周期多长
T（task）：团队分工，你的角色
A（action）：具体实施，自己做了什么
R（result）：最后成果，你的收获

36、如何测试纸杯

功能性：是否漏水；是否喝到水

安全性：有没有细菌可靠性：摔下来的损坏程度

可移植性：不同地方、温湿度使用

兼容性：容纳果汁、啤酒、汽水、汽油等

易用性：是否烫手、防滑、方便饮用水

用户文档：使用手册对用法、限制、使用条件描述

疲劳测试：分别装上水、汽油等24小时，泄露情况

压力测试：用物件不断加压，承受多大的压强

37、软件生命周期各个阶段的测试内容

（1）需求阶段测试：设计整个过程的进行、测试计划的安排、测试用例的设计以及软件的确认要达到那些要求等。
（2）设计阶段测试：包括概要设计和详细设计。在概要设计阶段，测试人员应阐述测试方法和测试评估准则，编写测试计划，组织成立独立的测试小组，安排具有里程碑的测试日程；在详细设计阶段，测试人员要开发或获取确认支持工具，生成功能测试数据和测试用例，以此来检查设计中遗漏的情况、错误的逻辑、模块接口的不匹配、数据结构不合理、错误的I/O假定、用户界面的补充分等。
（3）编码阶段测试：测试需要解决的首要问题是编码是否和设计的一致；其次是系统是否可维护，系统的规格说明是否正确地实现，编码是否按照既有的标准进行。是否有充分的测试计划评价程序，程序是否提供足够的文档资料，程序内部是否有足够的注释等。在测试完成后，要形成下列输出物：编码说明书、程序文档、计算机程序列表、可执行的程序、程序流程图、操作介绍和单元测试结果。
（4）测试阶段：要进行第三方的正确测试，检验所开发的系统是否能按照用户提出要求运行，在测试阶段要使的用户能成功地安装新的应用系统来进行测试。
（5）安装阶段测试：首先要根据系统安装手册制定好安装计划，确定安装流程图，准备好安装文件和程序清单，给出安装测试的预期结果，并对安装过程中的各项可能发生的结果进行说明准备，将程序运行的软硬件要求放入产品说明中。同时要检查时系统用户手册和操作手册，看是否可用。
（6）验收阶段测试：定义用户角色，定义验收标准，编制验收计划，执行验收计划和填写验收结论。

38、get和post的请求

1、url可见性：get，参数url可见；post，url参数不可见
2、数据传输上：get，通过拼接url进行传递参数；post，通过body体传输参数
3、缓存性：get请求是可以缓存的post请求不可以缓存
4、后退页面的反应get请求页面后退时，不产生影响post请求页面后退时，会重新提交请求
5、传输数据的大小get一般传输数据大小不超过2k-4k（根据浏览器不同，限制不一样，但相差不大）post请求传输数据的大小根据php.ini 配置文件设定，也可以无限大。
6、安全性这个也是最不好分析的，原则上post肯定要比get安全，毕竟传输参数时url不可见，但也挡不住部分人闲的没事在那抓包玩。安全性个人觉得是没多大区别的，防君子不防小人就是这个道理。对传递的参数进行加密，其实都一样。

39、alpha测试和beta测试的区别

alpha测试是在用户组织模拟软件系统的运行环境下的一种验收测试，由用户或第三方测试公司进行的测试，模拟各类用户行为对即将面市的软件产品进行测试，试图发现并修改错误beta测试时用户公司组织各方面的典型终端用户在日常工作中实际使用Beta版本，并要求用户报告异常情况，提出批评意见。

区别：主要是测试场所不同，alpha是指把用户请到开发方的场所来测试，beta测试是指在一个或多个用户的场所进行测试；alpha测试的环境是受开发方控制的，用户的数量相对少，时间比较集中，beta测试环境不受开发方控制，用户数量相对多，时间不集中

40、TCP/IP协议的模型和每层的主要协议

从下到上：