测试基本知识
1、请你分别介绍一下单元测试、集成测试、系统测试、验收测试、回归测试：
（1）单元测试：完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。
（2）集成测试：通过测试发现与模块接口有关的问题。目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构，应当避免一次性的集成（除非软件规模很小），而采用增量集成。
自顶向下集成：模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。
自底向上集成：从原子模块开始来进行构造和测试，因为模块是自底向上集成的，进行时要求所有隶属于某个给顶层次的模块总是存在的，也不再有使用稳定测试桩的必要。
（3）系统测试：是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。
（4）回归测试：回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。根据修复好了的缺陷再重新进行测试。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。
（5）验收测试：验收测试是指系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。验收测试包括测试和测试。
测试：是由用户在开发者的场所来进行的，在一个受控的环境中进行。
测试：由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件。
2、请你回答一下单元测试、集成测试、系统测试、验收测试、回归测试这几步中最重要的是哪一步
这些测试步骤分别在软件开发的不同阶段对软件进行测试，我认为对软件完整功能进行测试的系统测试很重要，因为此时单元测试和集成测试已完成，能够对软件所有功能进行功能测试，能够覆盖系统所有联合的部件，是针对整个产品系统进行的测试，能够验证系统是否满足了需求规格的定义，因此我认为系统测试很重要。
3、请回答集成测试和系统测试的区别，以及它们的应用场景主要是什么？
区别：
（1）计划和用例编制的先后顺序：从V模型来讲，在需求阶段就要制定系统测试计划和用例，HLD的时候做集成测试计划和用例，有些公司的具体实践不一样，但是顺序肯定是先做系统测试计划用例，再做集成。
（2）用例的粒度：系统测试用例相对很接近用户接受测试用例，集成测试用例比系统测试用例更详细，而且对于接口部分要重点写，毕竟要集成各个模块或者子系统。
（3）执行测试的顺序：先执行集成测试，待集成测试出的问题修复之后，再做系统测试。
应用场景：
（1）集成测试：完成单元测试后，各模块联调测试；集中在各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的正确性验证等等；可以是整个产品的集成测试，也可以是大模块的集成测试；集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。集成测试对测试人员的编写脚本能力要求比较高。测试方法一般选用黑盒测试和白盒测试相结合。
（2）系统测试：针对整个产品的全面测试，既包含各模块的验证性测试（验证前两个阶段测试的正确性）和功能性（产品提交个用户的功能）测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。系统测试测试软件《需求规格说明书》中提到的功能是否有遗漏，是否正确的实现。做系统测试要严格按照《需求规格说明书》，以它为标准。测试方法一般都使用黑盒测试法。
4、请说一说黑盒与白盒的测试方法
黑盒测试：
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，因此不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
常用的黑盒测试方法有：等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。
白盒测试：
白盒测试也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但仍然有可能存在错误。因为：穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序；穷举路径测试不可能检查出程序因为遗漏路径而出错；穷举路径测试发现不了一些与数据相关的错误。
白盒测试需要遵循的原则有：
（1）保证一个模块中的所有独立路径至少被测试一次；
（2）所有逻辑值均需要测试真（true）和假（false）；两种情况；
（3）检查程序的内部数据结构，保证其结构的有效性；
（4）在上下边界及可操作范围内运行所有循环。
常用白盒测试方法：
静态测试：不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。
动态测试：需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。
白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：
（1）语句覆盖每条语句至少执行一次。
（2）判定覆盖每个判定的每个分支至少执行一次。
（3）条件覆盖每个判定的每个条件应取到各种可能的值。
（4）判定/条件覆盖同时满足判定覆盖条件覆盖。
（5）条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
（6）路径覆盖使程序中每一条可能的路径至少执行一次。
5、请说一下手动测试与自动化测试的优缺点
手工测试缺点：
（1）重复的手工回归测试，代价昂贵、容易出错。
（2）依赖于软件测试人员的能力。
手工测试优点：
（1）测试人员具有经验和对错误的猜测能力。
（2）测试人员具有审美能力和心理体验。
（3）测试人员具有是非判断和逻辑推理能力。
自动化测试的优点：
（1）对程序的回归测试更方便。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。
（2）可以运行更多更繁琐的测试。自动化的一个明显的好处是可以在较少的时间内运行更多的测试。
（3）可以执行一些手工测试困难或不可能进行的测试。比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。
（4）更好地利用资源。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。
（5）测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。
（6）测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。
（7）增加软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。
自动化测试的缺点：
（1）不能取代手工测试
（2）手工测试比自动测试发现的缺陷更多
（3）对测试质量的依赖性极大
（4）测试自动化不能提高有效性
（5）测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受到限制，从而制约软件的开发。
（6）工具本身并无想像力
6、你觉得自动化测试有什么意义，都需要做些什么
自动化测试的意义在于
（1）可以对程序的新版本自动执行回归测试
（2）可以执行手工测试困难或者不可能实现的测试，如压力测试，并发测试，
（3）能够更好的利用资源，节省时间和人力
执行自动化测试之前首先判断这个项目是不是和推广自动化测试，然后对项目做需求分析，指定测试计划，搭建自动化测试框架，设计测试用例，执行测试，评估
7、请你回答一下测试的相关流程是什么？
测试最规范的过程如下
需求测试->概要设计测试->详细设计测试->单元测试->集成测试->系统测试->验收测试
8、请你说一下如何写测试用例
（1）测试人员尽早介入，彻底理解清楚需求，这个是写好测试用例的基础
（2）如果以前有类似的需求，可以参考类似需求的测试用例，然后还需要看类似需求的bug情况
（3）清楚输入、输出的各种可能性，以及各种输入的之间的关联关系，理解清楚需求的执行逻辑，通过等价类、边界值、判定表等方法找出大部分用例
（4）找到需求相关的一些特性，补充测试用例
（5）根据自己的经验分析遗漏的测试场景
（6）多总结类似功能点的测试点，才能够写出质量越来越高的测试用例
（7）书写格式一定要清晰
9、请问你觉得测试项目具体工作是什么？
搭建测试环境——撰写测试用例——执行测试用例——写测试计划，测试报告——测试，并提交BUG表单——跟踪bug修改情况——执行自动化测试，编写脚本，执行，分析，报告——进行性能测试，压力测试等其他测试，执行，分析，调优，报告
10、请你说一说测试用例的边界
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
常见的边界值：
（1）对16-bit 的整数而言 32767 和 -32768 是边界
（2）屏幕上光标在最左上、最右下位置
（3）报表的第一行和最后一行
（4）数组元素的第一个和最后一个
（5）循环的第 0 次、第 1 次和倒数第 2 次、最后一次
11、请你说一下软件质量的六个特征
按照软件质量国家标准GB-T8566--2001G，软件质量可以用下列特征来评价：
（1）功能特征：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。
（2）可靠特征：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。
（3）易用特征：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。
（4）效率特征：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。
（5）可维护特征：与进行指定的修改所需的努力有关的一组属性。
（6）可移植特征：与软件从一个环境转移到另一个环境的能力有关的一组属性。
12、请你说一下设计测试用例的方法
黑盒测试：
（1）等价类划分
等价类划分是将系统的输入域划分为若干部分，然后从每个部分选取少量代表性数据进行测试。等价类可以划分为有效等价类和无效等价类，设计测试用例的时候要考虑这两种等价类。
（2）边界值分析法
边界值分析法是对等价类划分的一种补充，因为大多数错误都在输入输出的边界上。边界值分析就是假定大多数错误出现在输入条件的边界上，如果边界附件取值不会导致程序出错，那么其他取值出错的可能性也就很小。
边界值分析法是通过优先选择不同等价类间的边界值覆盖有效等价类和无效等价类来更有效的进行测试，因此该方法要和等价类划分法结合使用。
（3）正交试验法
正交是从大量的试验点中挑选出适量的、有代表性的点。正交试验设计是研究多因素多水平的一种设计方法，他是一种基于正交表的高效率、快速、经济的试验设计方法。
（4）状态迁移法
状态迁移法是对一个状态在给定的条件内能够产生需要的状态变化，有没有出现不可达的状态和非法的状态，状态迁移法是设计足够的用例达到对系统状态的覆盖、状态、条件组合、状态迁移路径的覆盖。
（5）流程分析法
流程分析法主要针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计，这是从白盒测试中路径覆盖分析法借鉴过来的一种很重要的方法。
（6）输入域测试法
输入域测试法是针对输入会有各种各样的输入值的一个测试，他主要考虑 极端测试、中间范围测试，特殊值测试 。
（7）输出域分析法
输出域分析法是对输出域进行等价类和边界值分析，确定是要覆盖的输出域样点，反推得到应该输入的输入值，从而构造出测试用例，他的目的是为了达到输出域的等价类和边界值覆盖。
（8）判定表分析法
判定表是分析和表达多种输入条件下系统执行不同动作的工具，他可以把复杂的逻辑关系和多种条件组合的情况表达的即具体又明确；
（9）因果图法
因果图是用于描述系统输入输出之间的因果关系、约束关系。因果图的绘制过程是对被测系统的外部特征的建模过程，根据输入输出间的因果图可以得到判定表，从而规划出测试用例。
（10）错误猜测法
错误猜测法主要是针对系统对于错误操作时对于操作的处理法的猜测法，从而设计测试用例
（11）异常分析法
异常分析法是针对系统有可能存在的异常操作，软硬件缺陷引起的故障进行分析，分析发生错误时系统对于错误的处理能力和恢复能力依此设计测试用例。
白盒测试：
白盒测试也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但仍然有可能存在错误。因为：穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序；穷举路径测试不可能检查出程序因为遗漏路径而出错；穷举路径测试发现不了一些与数据相关的错误。
白盒测试需要遵循的原则有：
（1）保证一个模块中的所有独立路径至少被测试一次；
（2）所有逻辑值均需要测试真（true）和假（false）；两种情况；
（3）检查程序的内部数据结构，保证其结构的有效性；
（4）在上下边界及可操作范围内运行所有循环。
常用白盒测试方法：
静态测试：不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。
动态测试：需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。
白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：
（1）语句覆盖每条语句至少执行一次。
（2）判定覆盖每个判定的每个分支至少执行一次。
（3）条件覆盖每个判定的每个条件应取到各种可能的值。
（4）判定/条件覆盖同时满足判定覆盖条件覆盖。
（5）条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
（6）路径覆盖使程序中每一条可能的路径至少执行一次。
13、请你说一下app性能测试的指标
（1）内存：内存消耗测试节点的设计目标是为了让应用不占用过多的系统资源，且及时释放内存，保障整个系统的稳定性。当然关于内存测试，在这里我们需要引入几个概念：空闲状态、中等规格、满规格。
空闲状态指打开应用后，点击home键让应用后台运行，此时应用处于的状态叫做空闲；中等规格和满规格指的是对应用的操作时间的间隔长短不一，中等规格时间较长，满规格时间较短。
内存测试中存在很多测试子项，清单如下：
l 空闲状态下的应用内存消耗；
l 中等规格状态下的应用内存消耗；
l 满规格状态下的应用内存消耗；
l 应用内存峰值；
l 应用内存泄露；
l 应用是否常驻内存；
l 压力测试后的内存使用。
（2）CPU：
使用Android提供的view plaincopy在CODE上查看代码片派生到我的代码片
adbshell dumpsys CPUinfo |grep packagename >/address/CPU.txt来获取；
使用top命令view plaincopy在CODE上查看代码片派生到我的代码片
adbshell top |grep packagename>/address/CPU.txt来获取。
（3）流量：
网络流量测试是针对大部分应用而言的，可能还有部分应用会关注网速、弱网之类的测试。
流量测试包括以下测试项：
l 应用首次启动流量提示；
l 应用后台连续运行2小时的流量值；
l 应用高负荷运行的流量峰值。
（4）电量：
l 测试手机安装目标APK前后待机功耗无明显差异；
l 常见使用场景中能够正常进入待机，待机电流在正常范围内；
l 长时间连续使用应用无异常耗电现象。
（5）启动速度：
l 第一类：首次启动--应用首次启动所花费的时间；
l 第二类：非首次启动--应用非首次启动所花费的时间；
l 第三类：应用界面切换--应用界面内切换所花费的时间。
（6）滑动速度、界面切换速度
（7）与服务器交互的网络速度
14、请你说一说bug的周期，以及描述一下不同类别的bug
（1）New:（新的）
当某个“bug”被第一次发现的时候，测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New。
（2）Assigned（已指派的）
当一个bug被指认为New之后，将其反馈给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”。
（3）Open（打开的）
一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”。
（4）Fixed（已修复的）
当开发人员进行处理（并认为已经解决）之后，他就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组。
（5）Pending Reset（待在测试的）
当bug被返还到测试组后，我们将bug的状态设置为Pending Reset。
（6）Reset(再测试)
测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset”。
（7）Closed（已关闭的）
如果测试人员经过再次测试之后确认bug 已经被解决之后，就将bug的状态设置为“Closed”。
（8）Reopen（再次打开的）
如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen”
（9）Pending Reject（拒绝中）
如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态设置为“Pending Reject”
（10）Rejected(被拒绝的)
测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”。
（11）Postponed（延期）
有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed”。
不同类别的bug：
l Bug类型
l 代码错误
l 界面优化
l 设计缺陷
l 配置相关
l 安装部署
l 安全相关
l 性能问题
l 标准规范
l 测试脚本
l 其他
15、请你说一说web测试和app测试的不同点
（1）系统架构方面：
l web项目，一般都是b/s架构，基于浏览器的
l app项目，则是c/s的，必须要有客户端，用户需要安装客户端。
web测试只要更新了服务器端，客户端就会同步会更新。App项目则需要客户端和服务器都更新。
（2）性能方面:
l web页面主要会关注响应时间
l 而app则还需要关心流量、电量、CPU、GPU、Memory这些。
l 它们服务端的性能没区别，都是一台服务器。
（3）兼容方面：
l web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容
l app测试则要看分辨率，屏幕尺寸，还要看设备系统。
l web测试是基于浏览器的所以不必考虑安装卸载。
l 而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件 。
l 此外APP还有一些专项测试：如网络、适配性。
16、请问你了解什么测试方法
等价类划分，边界值分析，错误推测，因果图法，逻辑覆盖法，程序插桩技术，基本路径法，符号测试，错误驱动测试
17、请问黑盒测试和白盒测试有哪些方法
l 黑盒测试方法有等价类划分，边界值分析，错误推测，因果图法
l 白盒测试方法有逻辑覆盖法，程序插桩技术，基本路径法，符号测试，错误驱动测试
18、请问你怎么看待测试，知道哪些测试的类型，有用过哪些测试方法？
l 测试是软件开发中不可或缺的一环，测试通过经济，高效的方法，捕捉软件中的错误，从而达到保重软件内在质量的目的。
l 测试分为功能测试和非功能测试，非功能测试又可以分为性能测试、压力测试、容量测试、健壮性测试、安全性测试、可靠性测试、恢复性测试、备份测试、协议测试、兼容性测试、可用性测试、配置测试、GUI测试。
l 测试方法用过等价划分法、边值分析法、错误推测法、因果图法。
19、请问你怎么测试网络协议
协议测试包括四种类型的测试
（1）一致性测试：检测协议实现本身与协议规范的符合程度
（2）、互操作性测试：基于某一协议检测不同协议实现间互操作互通信的能力
（3）性能测试：检测协议实现的性能指标，比如数据传输速度，连接时间，执行速度，吞吐量，并发度，
（4）健壮性测试：检测协议是现在各种恶劣环境下运行的能力，比如注入干扰报文，通信故障，信道被切断
20、请你说一说简单用户界面登陆过程都需要做哪些分析
（1）功能测试
l 输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。
l 输入错误的用户名或者密码,验证登录会失败，并且提示相应的错误信息。
l 登录成功后能否能否跳转到正确的页面
l 用户名和密码，如果太短或者太长，应该怎么处理
l 用户名和密码，中有特殊字符（比如空格），和其他非英文的情况
l 记住用户名的功能
l 登陆失败后，不能记录密码的功能
l 用户名和密码前后有空格的处理
l 密码是否非明文显示显示，使用星号圆点等符号代替。
l 牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使 用者），刷新或换一个按钮是否好用
l 登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确
l 输入密码的时候，大写键盘开启的时候要有提示信息。
l 什么都不输入，点击提交按钮，检查提示信息。
（2）界面测试
l 布局是否合理，testbox和按钮是否整齐。
l testbox和按钮的长度，高度是否复合要求。
l 界面的设计风格是否与UI的设计风格统一。
l 界面中的文字简洁易懂，没有错别字。
（3）性能测试
l 打开登录页面，需要的时间是否在需求要求的时间内。
l 输入正确的用户名和密码后，检查登录成功跳转到新页面的时间是否在需求要求的时间内。
l 模拟大量用户同时登陆，检查一定压力下能否正常登陆跳转。
（4）安全性测试
l 登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)。
l 用户名和密码是否通过加密的方式，发送给Web服务器。
l 用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript 验证。
l 用户名和密码的输入框，应该屏蔽SQL注入攻击。
l 用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）。
l 防止暴力破解，检测是否有错误登陆的次数限制。
l 是否支持多用户在同一机器上登录。
l 同一用户能否在多台机器上登录。
（5）可用性测试
l 是否可以全用键盘操作，是否有快捷键。
l 输入用户名，密码后按回车，是否可以登陆。
l 输入框能否可以以Tab键切换。
（6）兼容性测试
l 不同浏览器下能否显示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。
l 同种浏览器不同版本下能否显示正常且功能正常。
l 不同的平台是否能正常工作，比如Windows, Mac。
l 移动设备上是否正常工作，比如Iphone, Andriod。
l 不同的分辨率下显示是否正常。
（7）本地化测试
l 不同语言环境下，页面的显示是否正确。
22、请对这个系统做出测试用例：一个系统，多个摄像头，抓拍车牌，识别车牌，上传网上，网上展示
功能：
1.每个摄像头都能抓拍车牌；
2.每个摄像头抓拍到的车牌能正常交给系统处理；
3.系统能够正确识别车牌；
4.系统能够将识别出的车牌上传；
5.上传至网络的车牌能够正常展示出来；
一、功能测试
1.使用正常的车牌，保持车牌静止，检查每个摄像头是否能抓拍车牌；
2.使用类似非车牌的写有字的纸板，检查每个摄像头是否抓拍；
3.使用正常的车牌，保持车牌较高速移动，检查每个摄像头是否能抓拍车牌；
4.在多种情况下检查每个摄像头抓拍到的车牌能否正常交给系统处理，如临时断电、断网后能否正常将数据交给系统；
5.使用抓拍到的正常的车牌，交由系统处理，检查系统能否识别车牌；
6.使用非车牌的其他图片，交由系统处理，检查系统能否识别；
7.在多种情况下检查系统能否将正常识别出的车牌进行上传，如临时断电、断网后未上传数据是否能继续上传；
8.构造非车牌的其他内容的数据，检查系统能否将异常内容进行上传；
9.检查上传至网络的车牌能否正常展示出来；
10.上传非车牌的其他内容的数据，检查能否正常显示出来。
二、性能测试
1.同时向一个摄像头展示多个静止的车牌，检查摄像头能否抓拍到多个车牌；
2.同时向一个摄像头展示多个较高速运动的车牌，检查摄像头能否抓拍到多个车牌；
3.抓拍后，检查系统识别车牌的时间是否在需求要求的时间内；
4.模拟大量抓拍照片同时交由系统处理，检查一定压力下系统能否正常识别车牌；
5.模拟大量车牌同时上传，检查一定压力下能否上传成功。
三、安全性测试
1.检查是否能够通过给车牌加装饰物等方法，使摄像头无法抓拍或抓拍后系统无法正常识别车牌。
23、请你对吃鸡游戏进行压力测试
一.首先明确需要测试压力的内容:
1.游戏服务器硬件
a.硬盘I/o
b.内存
c.CPU
2.网络压力
a.长连接
a1.最大连接数
a2.流量(内网、外网、进、出)
b.长连接短周期(类似Http的TCP应用，这个比较特殊的一个需求，专门针对LoginAgent)
b1.每秒建立的连接数
b2.实际处理能力
3.数据库
a.每秒事务数
b.每秒锁等待数
c.平均延时(ms)
d.CPU暂用
4.多线程的最优线程数
a.数据库执行的多线程
b.多连接处理
二.Windows Server环境测试方式
1.服务器性能监测
使用Server自带的性能监测器设置各个进程的监测参数。Window的这个自动工具做的相当强大。大家自己摸一摸基本就会用了。每个参数都由详细的说明。
2.案例设计注意
a.对于数据库的性能测试上，现在由于所有的游戏服务器构架在DB前面都有一个实现DB缓冲功能的进程，以减少数据库频繁的读写操作。所以其实数据库的读是一个轻量级的数量；而数据库的写操作是一个周期性能过程。案例设计一定要能够驱动这种周期性能过程。比如我们游戏的战斗，导致游戏玩家数据的改变，或驱动所有在线玩家数据的周期性存储。
b.选择具有代表性，并且最频繁的游戏操作。用于进行最高用户在线的各种性能指标采集。如，开枪、道具拾取、道具使用、移动、聊天
c.聊天性能测试
广播聊天是最为考验游戏信息发送能力的功能。通过进行全局广播的压力测试。我们可以获取服务器进程发送信息到客户端的最高承载量。进而可以对我们的各种广播功能进行一个预估和频率限制。
d.同屏玩家的移动测试
移动+广播。这两种信息，基本是网络游戏流量的70-80%左右。同屏玩家数量，将会增加各种数据的广播需求，非常影响游戏性能。所以同屏的移动测试也是广播测试的一个必要环节。需要根据实际结果进行适当的优化。
e.大量玩家同时登录测试
玩家登录时，有大量的信息需要进行分配和初始化；同时也有大量的数据需要下传客户端。服务器需要进行大量的TCP连接建立。所以是一个比较关键的过程。这个测试案例是一个比较特殊，但是运营是肯定会碰到的案例。
f.由于线程池处理事务，随着事务的时耗，存在一个最优线程数的问题。过多的线程反而会降低服务器效率
3.细节问题
a.进行测试需要仔细思考客户端性能影响服务器最后表现的可能性。比如
a1.模拟客户端的性能无法有效处理服务器返回信息,可能就导致服务器发送的信息缓存在服务器系统缓存，从而表现出服务器内存不断增加。表现为服务器发送能力不足，其实可能根本就是客户端的性能问题
a2.客户端性能问题，导致发起的请求数过少，从而导致单位时间内服务器处理的请求过少。表现为服务器性能不足，其实根本就是客户端的请求能力不足。
b.网络带宽导致最后表现不足
b1.确认服务器的各个网卡，以及相互的带宽。不然可能因为相互带宽，导致服务器对于客户端请求的处理延时。表现为服务器卡机
b2.客户端模拟多个玩家，比如1000个玩家。而客户端的网卡或者客户端与服务器之间的中转服务器带宽过小，导致服务器数据发送不出，内存不断增加。表现为服务器发送能力不足，其实是中间带宽问题。
c.debug i/o导致服务器性能下降
c1.进行性能测试，一定要取消debug用的同步的i/o.比如我们服务器的debuginternalLog.同步i/o是非常影响性能的，特别在压力测试下可能导致每秒上千上万甚至几十万次的执行。一处的文件写入操作就可以导致几十万次的处理能力变成几千次的处理能力。
c2.客户端避免进行阻塞操作导致模拟多用户性能下降，导致服务器表现性能下降
d.流量需要区分内网网
内、外网流量在游戏正式运行时是完全分开的。价格也是完全不同的。一个千M的外网是一个无法想象的运营成本，而kmbps/s现在已经是一个可以接受的代价。游戏进程需要进行不同网卡的配置和绑定。确定内外网流量。
24、请你根据微信登录界面设计测试用例
一、功能测试
1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。
2.输入错误的用户名或者密码,验证登录会失败，并且提示相应的错误信息。
3.登录成功后能否能否跳转到正确的页面
4.检查能否选择不同登录方式进行登录，如使用手机号登录、使用微信号登录或扫码登录。
5.记住用户名的功能
6.登陆失败后，不能记录密码的功能
7.密码是否非明文显示显示，使用星号圆点等符号代替。
8.有验证码时，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色、刷新或换一个按钮是否好用
9.登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确
10.输入密码的时候，大写键盘开启的时候要有提示信息。
11.什么都不输入，点击提交按钮，检查提示信息。
二、界面测试
1.布局是否合理，testbox和按钮是否整齐。
2.testbox和按钮的长度，高度是否复合要求。
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. 不同语言环境下，页面的显示是否正确。
25、请你对朋友圈点赞功能进行测试
1.是否可以正常点赞和取消；
2.点赞的人是否在可见分组里；
3.点赞状态是否能即时更新显示；
4.点赞状态，共同好友是否可见；
6.性能检测，网速快慢对其影响；
7.点赞显示的是否正确，一行几个；
8.点赞是否按时间进行排序，头像对应的是否正确；
9.是否能在消息列表中显示点赞人的昵称、5.不同手机，系统显示界面如何；
备注；
10.可扩展性测试，点赞后是否能发表评论；
11.是否在未登录时可查看被点赞的信息。
26、如果做一个杯子的检测，你如何测试
1.功能
（1）水倒水杯容量的一半
（2）水倒规定的安全线
（4）水杯容量刻度与其他水杯一致
（5）盖子拧紧水倒不出来
（6）烫手验证
2.性能
（1）使用最大次数或时间
（2）掉地上不易损坏
（3）盖子拧到什么程度水倒不出来
（4）保温时间长
（5）杯子的耐热性
（6）杯子的耐寒性
（7）长时间放置水不会漏
（8）杯子上放置重物达到什么程度杯子会被损坏
3.界面
（1）外观完整、美观
（2）大小与设计一样（高、宽、容量、直径）
（3）拿着舒服
（4）材质与设计一样
（5）杯子上的图案掉落
（6）图案遇水溶解
4.安全
（1）杯子使用的材质毒或细菌的验证
（2）高温材质释放毒性
（3）低温材质释放毒性
5.易用性
（1）倒水方便
（2）喝水方便
（3）携带方便
（4）使用简单，容易操作
（5）防滑措施
6.兼容性
（1）杯子能够容纳果汁、白水、酒精、汽油等。
7.震动测试
（1）杯子加包装（有填充物），六面震动，检查产品是否能应对铁路/公路/航空运输。
8.可移植性
（1）杯子在不同地方、温度环境下都可以正常使用。
27、如何对一个页面进行测试
1、UI测试：页面布局、页面样式检查、控件长度是否够长；显示时，是否会被截断；支持的快捷键，Tab键切换焦点顺序正确性等。
2、功能测试：页面上各类控件的测试范围，测试点。结合控件的实际作用来补充检查点： 比如， 密码框是否*显示， 输入是否做trim处理等。
3、安全测试：输入特殊字符，sql注入，脚本注入测试。后台验证测试，对于较重要的表单 ，绕过js检验后台是否验证；数据传输是否加密处理，比如， 直接请求转发，地址栏直接显示发送字符串？
4、兼容性测试
5、性能测试
28、如何对水壶进行测试
（同快手对水杯的测试）
1.功能
（1）水倒水壶容量的一半
（2）水倒规定的安全线
（4）水壶容量刻度与其他水壶一致
（5）盖子拧紧水倒不出来
（6）烫手验证
2.性能
（1）使用最大次数或时间
（2）掉地上不易损坏
（3）盖子拧到什么程度水倒不出来
（4）保温时间长
（5）壶的耐热性
（6）壶的耐寒性
（7）长时间放置水不会漏
（8）壶上放置重物达到什么程度壶会被损坏
3.界面
（1）外观完整、美观
（2）大小与设计一样（高、宽、容量、直径）
（3）拿着舒服
（4）材质与设计一样
（5）壶上的图案掉落
（6）图案遇水溶解
4.安全
（1）壶使用的材质毒或细菌的验证
（2）高温材质释放毒性
（3）低温材质释放毒性
5.易用性
（1）倒水方便
（2）喝水方便
（3）携带方便
（4）使用简单，容易操作
（5）防滑措施
6.兼容性
（1）壶能够容纳果汁、白水、酒精、汽油等。
7.震动测试
（1）壶加包装（有填充物），六面震动，检查产品是否能应对铁路/公路/航空运输。
8.可移植性
（1）壶在不同地方、温度环境下都可以正常使用。
29、如何对淘宝搜索框进行测试
一, 功能测试
1. 输入关键字，查看: 返回结果是否准确，返回的文本长度需限制
1.1输入可查到结果的正常关键字、词、语句，检索到的内容、链接正确性；
1.2输入不可查到结果的关键字、词、语句；
1.3输入一些特殊的内容，如空、特殊符、标点符、极限值等，可引入等价类划分的方法等；
2. 结果显示：标题，卖家，销售量，单行/多行，是否有图片
3. 结果排序：价格 销量 评价 综合
4.返回结果庞大时，限制第一页的现实量，需支持翻页
5. 多选项搜索：关键字 品牌 产地 价格区间 是否天猫 是否全国购
6. 是否支持模糊搜索，支持通配符的查询
7, 网速慢的情况下的搜索
8. 搜索结果为空的情况
9. 未登录情况和登录情况下的搜索（登录情况下 存储用户搜索的关键字/搜索习惯）
二.性能测试：
1压力测试：在不同发用户数压力下的表现（评价指标如响应时间等）
2负载测试：看极限能承载多大的用户量同时正常使用
3稳定性测试：常规压力下能保持多久持续稳定运行
4内存测试：有无内存泄漏现象
5大数据量测试：如模拟从庞大的海量数据中搜索结果、或搜索出海量的结果后列示出来，看表现如何等等。
三. 易用性：交互界面的设计是否便于、易于使用
1依据不同的查询结果会有相关的人性化提示，查不到时告知？查到时统计条数并告知？有疑似输入条件错误时提示可能正确的输入项等等处理；
2查询出的结果罗列有序，如按点击率或其他排序规则，确保每次查询出的结果位置按规则列示方便定位，显示字体、字号、色彩便于识别等等；
3标题查询、全文检索、模糊查询、容错查询、多关键字组织查询（空格间格开）等实用的检索方式是否正常？
4输入搜索条件的控件风格设计、位置摆放是否醒目便于使用者注意到，有否快照等快捷查看方式等人性化设计？
四. 兼容性
1WINDOWS/LINUX/UNIX等各类操作系统下及各版本条件下的应用
2IE/FIREFOX/GOOGLE/360/QQ等各类浏览器下及各版本条件下、各种显示分辨率条件下的应用
3SQL/ORACLE/DB2/MYSQL等各类数据库存储情况下的兼容性测试
4简体中文、繁体中文、英文等各类语种软件平台下的兼容性测试
5IPHONE/IPAD、安卓等各类移动应用平台下的兼容性测试
6与各相关的监控程序的兼容性测试，如输入法、杀毒、监控、防火墙等工具同时使用
五. 安全性
1被删除、加密、授权的数据，不允许被SQL注入等攻击方式查出来的，是否有安全控制设计；
2录入一些数据库查询的保留字符，如单引号、%等等，造成查询SQL拼接出的语句产生漏洞，如可以查出所有数据等等，这方面要有一些黑客攻击的思想并引入一些工具和技术，如爬网等。
3通过白盒测试技术，检查一下在程序设计上是否存在安全方面的隐患；
4对涉及国家安全、法律禁止的内容是否进行了相关的过滤和控制；
30、如何对一瓶矿泉水进行测试
界面测试:查看外观是否美观
功能度：查看水瓶漏不漏；瓶中水能不能被喝到
安全性：瓶子的材质有没有毒或细菌
可靠性：从不同高度落下的损坏程度
可移植性：再不同的地方、温度等环境下是否都可以正常使用
兼容性：是否能够容纳果汁、白水、酒精、汽油等
易用性：是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对的用法、限制、使用条件等有详细描述
疲劳测试：将盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
跌落测试:测试在何种高度跌落会破坏水瓶
31、如何测试登陆界面
一、功能测试
1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。
2.输入错误的用户名或者密码,验证登录会失败，并且提示相应的错误信息。
3.登录成功后能否能否跳转到正确的页面
4.用户名和密码，如果太短或者太长，应该怎么处理
5.用户名和密码，中有特殊字符（比如空格），和其他非英文的情况
6.记住用户名的功能
7.登陆失败后，不能记录密码的功能
8.用户名和密码前后有空格的处理
9.密码是否非明文显示显示，使用星号圆点等符号代替。
10.牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使 用者），刷新或换一个按钮是否好用
11.登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确
12.输入密码的时候，大写键盘开启的时候要有提示信息。
13.什么都不输入，点击提交按钮，检查提示信息。
二、界面测试
1.布局是否合理，testbox和按钮是否整齐。
2.testbox和按钮的长度，高度是否复合要求。
3. 界面的设计风格是否与UI的设计风格统一。
4. 界面中的文字简洁易懂，没有错别字。
三、性能测试
1.打开登录页面，需要的时间是否在需求要求的时间内。
2.输入正确的用户名和密码后，检查登录成功跳转到新页面的时间是否在需求要求的时间内。
3.模拟大量用户同时登陆，检查一定压力下能否正常登陆跳转。
四、安全性测试
1.登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)。
2.用户名和密码是否通过加密的方式，发送给Web服务器。
3.用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript 验证。
4.用户名和密码的输入框，应该屏蔽SQL注入攻击。
5.用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）。
6.防止暴力破解，检测是否有错误登陆的次数限制。
7. 是否支持多用户在同一机器上登录。
8. 同一用户能否在多台机器上登录。
五、可用性测试
1. 是否可以全用键盘操作，是否有快捷键。
2. 输入用户名，密码后按回车，是否可以登陆。
3. 输入框能否可以以Tab键切换。
六、兼容性测试
1.不同浏览器下能否显示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。
2.同种浏览器不同版本下能否显示正常且功能正常。
2.不同的平台是否能正常工作，比如Windows, Mac。
3.移动设备上是否正常工作，比如Iphone, Andriod。
4.不同的分辨率下显示是否正常。
七、本地化测试
1. 不同语言环境下，页面的显示是否正确。
32、请你来说一下购物车的测试用例
界面测试
• 界面布局、排版是否合理；文字是否显示清晰；不同卖家的商品是否区分明显。
2.功能测试
未登录时：
• 将商品加入购物车，页面跳转到登录页面，登录成功后购物车数量增加；
• 点击购物车菜单，页面跳转到登录页面。
登录后：
• 所有链接是否跳转正确；
• 商品是否可以成功加入购物车；
• 购物车商品总数是否有限制；
• 商品总数是否正确；
• 全选功能是否好用；
• 删除功能是否好用；
• 填写委托单功能是否好用；
• 委托单中填写的价格是否正确显示；
• 价格总计是否正确；
• 商品文字太长时是否显示完整；
• 店铺名字太长时是否显示完整；
• 创新券商品是否打标；
• 购物车中下架的商品是否有特殊标识；
• 新加入购物车商品排序（添加购物车中存在店铺的商品和购物车中不存在店铺的商品）；
• 是否支持TAB、ENTER等快捷键；
• 商品删除后商品总数是否减少；
• 购物车结算功能是否好用。
3.兼容性测试
• 不同浏览器测试。
4.易用性测试
• 删除功能是否有提示；是否有回到顶部的功能；商品过多时结算按钮是否可以浮动显示。
5.性能测试
• 压力测试；并发测试。
33、你写的测试程序是怎么样的，你写过前端、后端程序吗？
开发测试驱动程序一般分为4步：
1，指出需要的新特性。可以记录下来，然后为其编写一个测试。
2，编写特性的概要代码，这样程序就可以运行而没有任何语法等方面的错误，但是测试会失败。看到测试失败是很重要的，这样就能确定测试可以失败。如果测试代码中出现了错误，那么就有可能出现任何情况，测试都会成功，这样等于没测试任何东西。再强调一遍：在试图测试成功之前，先要看到它失败。
3，为特性的概要编写虚设代码，能满足测试要求就行。不用准确的实现功能，只要保证测试可以通过即可。这样一来就可以保证在开发的时候总是通过测试了，（除了第一次测试的时候）甚至在最初实现功能时亦是如此。
4，现在重写（或者重构）代码，这样它就会做自己应该做的事，从而保证测试一直成功。
在编码完成时，应该保证代码处于健康状态--不要遗留下任何测试失败。
写过前段程序。
34、请问你有没有写过测试脚本，怎么写的？
然后，撰写测试桩与驱动，白盒测试保证代码逻辑中循环和分支都能够走到，黑盒测试保证函数和首先，代码走查结合动态单步跟踪以及观察日志与文件输出，网络、CPU状态。
功能脚本接口正确，输入输出符合设计预期。
对于异常处理，特别是变量的检查需要特别关注，变量在使用前都需要进行检查，是否为空？或者为0？对于文件名和路径必须检查，确认文件是否存在，路径是否可达之后再进行后续操作。
另外，需要考虑所依赖的其他功能脚本以及二进制工具，这些功能性单元应该如何使用，调用后的返回会有哪些情况，对于正常和异常结果，脚本是否能够捕捉到并且作出正确的判断。
35、请问你有没有写过web测试，怎么写的？
Web测试主要从下面几个大方向考虑
功能测试，主要做链接测试，表单测试，cookies测试，设计语言测试等
性能测试，考虑连接速度测试，以及负载测试，例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？还有压力测试
可用性测试，比如导航测试，图形测试，内容测试，整体界面测试等
兼容性测试，市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
安全性测试，
（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
36、请问测试路由器怎么测，用命令行还是界面？
可以采用lperf这个命令，
Lperf是一个网络性能测试工具，可以测量最大tcp和udp带宽，具有多种参数和特性，可以记录带宽，延迟抖动，数据包丢失，通过这些信息可以发现网络问题，检查网络质量，定位网络瓶颈。
iperf的使用非常简单，测试的原理是在wan口连接一台PC机，在LAN口连接一台PC，两边分别运行iperf服务端和客户端模式，用来测量LAN->WAN和WAN->LAN性能。具体命令如下：
服务端：iperf -s -w 1m
客户端：iperf -c
<server ip> -w 1m -t 20 -P 10
含义是TCP wndowsize 为1MByte，测试时间是20s，线程是10。
37、请你回答一下如何测试手机开机键？
功能测试：
按下开机键，屏幕能否亮起
性能测试：
按下开机键，屏幕能否在规定时间内亮起
压力测试
连续多次按下开机键，观察屏幕是否能一直亮起，到多久时间失灵
健壮性测试
给定一个中了病毒的手机或者是淘汰许久的老机子，安歇开机键观察屏幕能否亮起
可靠性测试
连续按下开机键有限次数，比如1万次，记录屏幕未亮起的次数
可用性测试
开机键按下费不费力，开机键的形状设计是否贴合手指，开机键的位置设计是否方便
38、请问你遇到过哪些印象深刻的bug，接口测试出现bug的原因有哪些？
面试官询问遇到过哪些印象深刻的bug，其实它并不关心你描述的这个bug是否真的有价值，或有多曲折离奇？他只是：了解你平时工作中的测试能力
所以，这就要求的你平时工作中遇到bug时试着自己去定位，定位bug的过程远比你的单纯的执行测试用例有“价值”（自我技能提高的价值），在定位bug的过程中你需要掌握和运用更多知识。
另外，建议你平时养成总结的好习惯，发现的bug，开发解决了，最好问问他原因以及解决的方法，这样再遇到类似问题时，自己也可以试着定位解决。遇到难解决的bug，也可以把最终的解决过程记录下来。（这不是就有素材了）
所以，建议你平时可以主动要求去分享一些自己工作中用到或学习的技术。或者多去参加集体活动，加强自己的表达能力。From:虫师
接口测试常见的bug有以下几个:
特殊值处理不当导致程序异常退出或者崩溃
类型边界溢出，导致数据独处和写入不一致
取值边界外未返回正确的错误信息
权限未处理，可以访问其他用户的信息
逻辑校验不完善，可以利用漏洞获取非正当利益
状态处理不当，导致逻辑出现错误
数组类型item个数为0或者item重复时程序异常退出
39、你在做项目中有做过压力测试吗，怎么做
1、首先对要测试的系统进行分析，明确需要对那一部分做压力测试，比如秒杀，支付
2、如何对这些测试点进行施压
第一种方式可以通过写脚本产生压力机器人对服务器进行发包收报操作
第二点借助一些压力测试工具比如Jmeter,LoadRunner
3、如何对这些测试点进行正确的施压
需要用压力测试工具或者其他方法录制脚本，模拟用户的操作
4、对测试点设计多大的压力比较合适？
需要明确压力测试限制的数量，即用户并发量
5、测试结束后如何通过这些数据来定位性能问题
通过测试可以得到吞吐量，平均响应时间等数据，这个数据的背后是整个后台处理逻辑综合作用的结果，这时候就可以先关注系统的CPU，内存，然后对比吞吐量，平均响应时间达到瓶颈时这些数据的情况，然后就能确认性能问题是系统的哪一块造成的
40、请问你在项目中关于功能测试和接口测试是怎么做的
功能测试：
首先制定测试计划，然后进行测试设计，将在测试计划阶段指定的测试活动分解，进而细化，为若干个可执行程序的子测试过程，然后执行测试，按照测试计划使用测试用例对待测项目进行逐一的，详细的排查分析评估，最后对测试结果进行统计和分析，
接口测试：
什么是接口（API）
API全称Application Programming Interface，这里面我们其实不用去关注AP，只需要I上就可以。一个API就是一个Interface。我们无时不刻不在使用interfaces。我们乘坐电梯里面的按钮是一个interface。我们开车一个踩油门它也是一个interface。我们计算机操作系统也是有很多的接口。(这是目前个人找到比较好理解的一段解释)
接口就是一个位于复杂系统之上并且能简化你的任务，它就像一个中间人让你不需要了解详细的所有细节。那我们今天要讲的Web API就是这么一类东西。像谷歌搜索系统，它提供了搜索接口，简化了你的搜索任务。再像用户登录页面，我们只需要调用我们的登录接口，我们就可以达到登录系统的目的。
现在市面上有非常多种风格的Web API，目前最流行的是也容易访问的一种风格是REST或者叫RESTful 风格的API。从现在开始，以下我提到的所有API都是指RESTful风格的API。
什么是接口测试和为什么要做接口测试
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
现在很多系统前后端架构是分离的，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端太容易了），需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。
如今系统越来越复杂，传统的靠前端测试已经大大降低了效率，而且现在我们都推崇测试前移，希望测试能更早的介入测试，那接口测试就是一种及早介入的方式。例如传统测试，你是不是得等前后端都完成你才能进行测试，才能进行自动化代码编写。而如果是接口测试，只需要前后端定义好接口，那这时自动化就可以介入编写接口自动化测试代码，手工测试只需要后端代码完成就可以介入测试后端逻辑而不用等待前端工作完成。
接口测试的策略
接口测试也是属于功能测试，所以跟我们以往的功能测试流程并没有太大区别，测试流程依旧是：1.测试接口文档（需求文档） 2.根据接口文档编写测试用例（用例编写完全可以按照以往规则来编写，例如等价类划分，边界值等设计方法）3. 执行测试，查看不同的参数请求，接口的返回的数据是否达到预期。
41、请问你有用过什么测试工具吗，用过哪些？
自动化测试工具用过selenium和appium
性能测试工具有用过Jmeter
42、请你设计一个微信朋友圈点赞的测试用例
功能测试：
点赞某条朋友圈，验证是否成功
接口测试：
点赞朋友圈，验证朋友能否收到提示信息
性能测试
点赞朋友圈，是否在规定时间显示结果，是否在规定时间在朋友手机上进行提示
兼容性测试
在不同的终端比如ipad,手机上点赞朋友圈，验证是否成功
43、请问如果用户点击微博的关注图标但是app上面没有反应，应该怎么排查这个问题
首先1.在Eclipse Devices窗口，选中app对应的包名，然后点击debug图标（绿色的小虫子），然后切换到Debug视图。
2.切换视图之后，可以看到debug下，app的线程列表。
3.对于main线程（第一个线程），选中，并将其挂起Suspend。
4.然后我们就可以看到，Suspend之后，main线程卡住的位置。
44、在做测试的过程中，假如前端和后端吵起来了都在踢皮球觉得对方该改代码，你怎么办？
此时就应该找技术领导拍板或leader们基于安全性、性能、可测试性、可维护性讨论敲定一个解决方案，做到开发环境方便开发，线上环境少配置
少依赖、少出错机会。
45、如果广东用户头条app刷不出东西了，你应该怎么排查问题
1、检查网络连接是否稳定，更换网络尝试
2、更新头条版本尝试
3、清除app缓存，应用数据
46、请你说一下能不能用机器学习去进行自动化测试，如何监控异常流量，如果是脉冲呢，如何和正常流量作区分
如何用机器学习去进行自动化测试，就是让自动化测试变得更加智能，在自动化测试过程中，当测试功能模块越来越多，没有太多的时间去全部覆盖，我们可以采用归纳学习的方式，基于自动化测试的执行结果或者手工测试执行的结果为数据输入，然后基于一定的模型（例如：以通过率和模块的重要率计算的平均值）得出测试推荐模块，或者当要执行一个功能模块时，基于历史数据和模型（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
47、请问如何对登录界面进行测试
黑盒测试方法
输入正确用户名和密码，验证是否登陆成功
输入正确的用户名和错误的密码，验证是否登陆失败并且提示信息正确
输入未注册的用户名和任意的密码，验证是否登陆失败并且提示信息正确
用户名和密码都为空，验证是否登陆失败并且提示信息正确
用户名和密码两者之一为空
若启用了验证码，输入正确的用户名密码验证码是否能登陆成功
输入正确用户名和密码，错误的验证码，能否登陆成功并且提示信息正确
用户名和密码是否大小写敏感
页面上的密码框是否加密显示
后台系统第一次创建的用户重新登录时是否提示修改密码
忘记用户名和忘记密码的功能是否可用
前段功能是否根据要求限制用户名和密码的长度
点击验证码图片是否可以更换验证码，更换后的验证码是否可用
刷新页面是否会刷新验证码
如果验证码具有时效性，分别验证时效内和时效外验证码的有效性
用户登录成功但是会话超时后是否重定向到用户登录界面
不同级别的用户登录系统后的权限是否正确
页面默认定位焦点是否定位到用户名输入框中
快捷键tab和回车键是否可以正常使用
非功能性需求，从安全，性能，兼容三个方面
安全：
用户密码后台存储是否加密
用户密码在网络传输过程中是否加密
密码是否具有有效期，密码有效期到期后是否提示修改密码
不登陆的时候直接在浏览框中输入登录界面后的url地址，是否会重新定位到登陆界面
密码输入框是否不支持复制粘贴
页面密码输入框中输入的密码是否可以在页面源码模式下被查看
用户名和密码输入框中输入xss跨站脚本攻击字符串验证系统的行为是否被篡改
连续多次登陆失败后系统是否会阻止用户后续的尝试
统一用户在同一终端的多种不同浏览器上登陆，验证登录功能的互斥性是否符合设计预期
同一用户先后在不同终端的浏览器上登陆用户名和密码输入框中输入典型的sql注入攻击字符串验证系统的返回页面
，验证登陆是否有互斥性
性能测试：
单用户登陆的响应界面是否符合预期
单用户登陆时后台请求数量是否过多
高并发场景下用户登录的响应界面是否符合预期
高并发场景下服务端的监控指标是否符合预期
高集合点并发场景下是否存在资源死锁和不合理的资源等待
长时间大量用户连续登录和登出，服务器端是否存在内存泄漏
兼容性测试：
不同浏览器下验证登陆功能的页面显示和功能正确性
相同浏览器的不同版本下验证登陆功能的页面显示和功能正确性
不同终端的不同浏览器下验证登陆功能的页面显示和功能正确性
不同分辨率下……
补充：弱网测试
网络切换和网络延迟时登陆界面是否正常
是否支持第三方登陆
是否可记住密码，记住的密码是否加密
47、请你说一说当前工作中涉及的测试问题(测试流程和测试性能)
在测试性能中，时常会出现脚本回访卡住的问题，原因有以下几种：
1、 runtimesetting 中的continue error没有勾选
2、录制的脚本中存在冗余的代码部分，需要对脚本进行优化，去除冗余的部分（优化脚本）
例如：在用FireFox录制脚本时，脚本中会产生一个叫
”Url ","Referer=", ENDITEM,”这样的代码（该代码出现的问题不止一处，在查找时一定要注意。），这是因为采用firefox浏览器录制时产生的压缩文件，在脚本回放时卡住的原因正是因为这个（建议：能采用IE录制尽量用IE浏览器）
解决办法：注释掉或者删除掉该段代码即可， 关联问题：在用loadrunner自带对比工具对比脚本后 找到需要关联的动态值。在关联后回放脚本时报错HTTP-status code 417（exception failed）错误时，产生的原因如下：
1、脚本中还存在没有关联或者关联失败的动态值，利用lr自带对比工具仔细对比
2、脚本中的动态值被做了加密策略，仔细查看脚本中动态值的部分，看看动态值是否被做了安全策略（随机生成或者打乱动态值顺序、在动态值中加入了特殊符号），由于在tree-response中的动态值是未被加密的状态，在client向server发送请求时，client的动态值发给服务器，这时服务器的动态值已经被做了参数化，所以服务器不认准client向服务器发送的动态值。
解决办法：去掉动态值的安全策略即可（JVM参数）
48、请你测试一下游戏中英雄的技能
测试的设计都是通用的，首先功能测试看功能有没有实现，然后再对性能、压力、容量、健壮性、安全性、可靠性、恢复性、备份、协议、兼容性、可用性、配置、GUI这些非功能测试去思考。具体答案这里不再赘述
49、请你回答一下性能测试有哪些指标，对一个登录功能做性能测试，有哪些指标，怎么测出可同时处理的最大请求数量
性能测试常用指标：
从外部看，主要有
1、吞吐量：每秒钟系统能够处理的请求数，任务数
2、响应时间：服务处理一个请求或一个任务的耗时
3、错误率：一批请求中结果出错的请求所占比例
从服务器的角度看，性能测试关注CPU，内存，服务器负载，网络，磁盘IO
对登录功能做性能测试
单用户登陆的响应界面是否符合预期
单用户登陆时后台请求数量是否过多
高并发场景下用户登录的响应界面是否符合预期
高并发场景下服务端的监控指标是否符合预期
高集合点并发场景下是否存在资源死锁和不合理的资源等待
长时间大量用户连续登录和登出，服务器端是否存在内存泄漏
怎么测出可同时处理的最大请求数量
可以采用性能测试工具(WeTest服务器性能)，该工具是腾讯wetest团队出品，使用起来很简单方便，但测试功能相当强大，能提供10w+以上的并发量，定位性能拐点，测出服务器模型最大并发
50、请问你有没有做过什么单元测试，怎么进行单元测试，对一个没有参数没有返回值但可能对全局变量有影响的怎么进行单元测试
如何进行单元测试：
１、创建单元测试，该工具可以对任何类、接口、结构等实体中的字段、属性、构造函数、方法等进行单元测试。创建单元测试大致可以分为两类：
整体测试，整体测试是在类名称上右击鼠标，在下拉菜单中点击创建单元测试选项。这样就可以为整个类创建单元测试了，这时他会为整个类可以被测试的内容全部添加测试方法。开发人员直接在这些自动生成的测试方法中添加单元测试代码就可以了。
单独测试，如果只想单独对某个方法、属性、字段进行测试，则可以将鼠标焦点放在这个待测试的项目名称之上，然后点击鼠标右键，在右键菜单中选择创建单元测试选项。这样就可以单独为某个方法创建单元测试了。
运行单元测试
查看测试结果
编写单元测试代码
测试没有参数的函数，它可能还有别的输入，例如全局变量，成员变量，或调用子函数获得的输入（这个要使用工具才能做到），只要函数需读取的，都应该设定初始值，如果完全没有，没有输入也是一种输入，照样测试就是了。同样道理，输出也不仅仅是返回值，没有返回值还可能修改了全局变量什么的，这些也是要判断的输出。
51、请问你有没有做过压力测试
在软件工程中，压力测试是对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。例如测试一个Web 站点在大量的负荷下，何时系考察公司：网易
统的响应会退化或失败。网络游戏中也常用到这个词汇。
52、对于有系统大量并发访问，你会如何做测试，有什么建议
如何做高并发系统的测试，一般而言，整体的测试策略是：先针对部分系统进行性能测试及压力测试，得到各部分的峰值处理性能，再模拟整体流程测试，重点测试整体业务流程以及业务预期负荷，着重测试以下几点：
1、不同省份，不同运营商CDN节点性能，可采用典型压力测试方案
2、核心机房BGP网络带宽，此部分重点在于测试各运行商的BGP网络可靠性，实际速率，一般采用smokeping,lxChariot等工具
3、各类硬件设备性能，一般采用专业的网络设备测试工具
4、各类服务器并发性能，分布式处理能力，可采用压力测试方案工具
5、业务系统性能，采用业务系统压力测试方案
6、数据库处理性能，这部分需要结合业务系统进行测试，以获取核心业务场景下的数据库的TPS/QPS，
7、如果有支付功能，需要进行支付渠道接口及分流测试，此部分相对而言可能是最大的瓶颈所在，此外还涉及备份方案，容灾方案，业务降级方案的测试。