测试面试可能会遇到的问题

面试可能问到的问题 1
一、工具类问题 一
你有了解过那些自动化工具？
答：selenium、jmeter、RobotFramework、appium、QTP、loadrunner 等

请问了解过 selenium2.0 吗？
答：Selenium 是一个开源的 Web 功能测试工具。
Selenium 优点：

1. 测试案例整合非常的方便，是一款开源工具；
2. 使用灵活、简单，写出来的测试案例非常简洁、也易于维护；
3. Selenium RC 支持多种语言编写测试案例，应用范围很广。

Selenium 组件分为：
Selenium Core：支持 DHTML（数据驱动测试），他是 Selenium IDE 和 Selenium RC 的引擎。

Selenium ID：基于 firefox 的插件，支持脚本录制。 Selenium Remote Control （RC）：支持多种平台和浏览器，并且可以用多种语言编写测试用例。

Selenium Grid：在不同的环境时运行多个测试任务，极大的加快 web 应用的功能测试。

二、请问有用过 jmeter 吗？
Apache JMeter 是 Apache 组织开发的基于 Java 的压力测试工具。用于对软件做压力测试，它最 初被设计用于 Web 应用测试，后来扩展到其他测试领域。它可以用于测试静态和动态资源，
例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器等等。
JMeter 可以用于 对服务器、网络或对象，模拟巨大的负载，测试来自不同压力类别下它们的强度和分析整体性能。另外 JMeter 能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter 允许使用正则表达式创建断言。
Apache JMeter 可以用于对静态的和动态的资源（文件、Servlet、Perl 脚本 java 对象、数据库和 查询、FTP 服务器等等）的性能进行测试。它可以用于对服务器、网络或对象模拟繁重的负载来测 试它们强度或分析不同压力类型下的整体性能。你可以使用它做性能的图形分析或在大并发负载下测试你的服务器、脚本、对象。
JMeter 的作用
1.能够对 HTTP 和 FTP 服务器进行压力和性能测试，也可以对任何数据库进行统一的测试（通 过 JDBC）.
2.完全的可一致性和 100%的纯 java。
3.完全 Swing 和轻量组件支持包（预编译的 JAR 使用 javax.swing.）。
4.完全多线程，框架允许通过多个线程并发取样和通过单独的线程组对不同的功能同事取样。
5.精心的 GUI 设计允许快速操作和更精确的计时。
6.缓存和离线分析、回放测试结果。

JMeter 的高可扩展性
1.可链接的取样器允许无限制的测试能力。
2.各种负载统计表和可链接的计时器可供选择。
3.数据分析和可视化插件提供了很好的可扩展性以及个性化。
4.具有提供动态输入到测试的功能（包括 Javascript）
5.支持脚本编程的取样器（在 1.9.2 及以上版本支持 Beanshell）。

在设计阶段，JMeter 能够充当 HTTP PROXY（代理）来记录 IE/NETSCAPE 的 HTTP 请求，也可以 记录 apache 等 WebServer 的 log 文件来重现 HTTP 浏览。当这些 HTTP 客户端请求被记录以后，测 试运行时可以方便的设置重复次数和并发度（线程数）来产生巨大的流量。JMeter 还提供可视化组件以及报表工具把服务器在不同不同压力下的性能展现出来。 相比其他 HTTP 测试工具，JMeter 最主要的特点在于扩展性强。JMeter 能够自动扫描其 lib/ext 字目录下，jar 文件中的插件，并且将其装载到内存，让用户通过不同的菜单调用。
三、LR 工具的原理是什么？
1.VuGen 发生器：捕捉用户的业务量，并最终将其录制成一个脚本：
（1）选择相应的一种协议；
（2）在客户端模拟用户使用过程中的业务流程，并卢志成一个脚本；
（3）编辑脚本和设置 Run-Time Settings 项；
（4）编译脚本生成一个没有错误的可运行的脚本。
2.控制器（Controller）:
（1）设计场景，包括手动场景设计和目标场景设计两种方式；
（2）场景监控，可以实时监控脚本的运行的情况。可以通过添加计数器来监控 Windows 资源、 应用服务器和数据库使用情况。场景设计的目的是设计出一个最接近用户实际使用的场景，场景设 计越接近用户使用的实际情况，测试出来的数据就越接近真实值。场景设计也设计很多技巧，如 IP 欺骗、负载均衡等一些手段。
3.负载发生器（Load Generators）：模拟用户对服务器提交请求。 通常，在性能测试过程中会将控制器和负载发生器分开，即控制器使用一台独立的机器（原因 是进行脚本编辑时会产生大量的参数化文件，而这些参数化文件会占用系统资源，在这就是运行时 会产生大量的日志文件，最主要的是因为在模拟成百上千的虚拟用户进行性能测试时，每个虚拟用 户都是需要消耗系统资源的，如果虚拟的并发用户过多，会导致测试机出现瓶颈）当使用多台负载 发生器时，一定要保证负载均衡（指在进行性能而是过程中，保证每台负载发生器均匀地对服务器 进行施压）。
4.分析器（Analysis）：主要用户对测试结果进行分析。它可以提供很多报告的形式，包括 XML,word 等。
四、LR 怎么设计集合点和检查点？
集合点：系统压力最大的情况是：所有用户都集合到系统瓶颈的某个点上进行操作，从脚本的 角度讲，这个点就是执行脚本的某一条或一段语句。 集合点函数：1r_rendezvous（“together1”）；
集合点添加方法：菜单 Insert | Rendezvous
集合点经常和事务结合起来使用，常放在事务的前面 - 集合点只能插入到脚本中 Action 部分 - 在 controller 模块中的 Scenario-> Rendezvous 中可以定义集合点策略

检查点：
检查点的功能主要验证某个界面上是否存在指定的 Text 或 Image 等对象，在使用 LoadRunner 测试 Web 应用时，可以检查压力较大时 Web 服务器能否返回正常的页面。 LR 中检查点有两种：文字和图片。可以用以下函数实现： web_find()、web_reg_find()、和 web_image_check()。
步骤：定位要检查的页面->入文字检查点->设定与检查点有关的选项 Vuser | Run-time Settings | Preferences->查看检查点是否通过

五、LR 中的结果分析器会显示哪些分析？哪些数据？
1.监控 Windows 系统资源
2.每秒 HTTP 相应次数（HTTP Responses per second 图）
3.虚拟用户图 正在运行的虚拟用户、虚拟用户概要图、集合点图
4.事务图事务综述图、事务平均响应时间图、每秒通过事务数图、事务响应时间与负载分析图、事务相应时间图、事务响应时间分布图
5.Web 资源图 点击率图、吞吐率图、每秒连接数图
6.网页细分图 页面分解总图、下载时间细分、组件细分、下载时间细分图、第一次缓冲时间细分
7.页面分解总图
8.下载时间细分、组件细分、下载时间细分图、第一次缓冲时间细分图、页面组件 细分图、页面组件细分、页面下载时间细分图、页面下载时间细分、第一次缓冲时间细分图、已下 载组件大小图

六、QTP 原理
QTP 是基于 GUI 界面的自动化测试工具，用户系统的功能测试 QTP 录制的是鼠标和键盘的消息。QTP 录制回放是基于 windows 操作系统的消息机制。QTP 在 录制时监听应用程序的消息，监听到之后吧消息放到容器里，而另外的监听程序则从容器中取出容 器中的消息，并调用对用的 API 处理函数。QTP 截取的是用户对应用程序的操作，即录制的消息。 对于 C/S 应用程序，在回放时 QTP 根据对象的句柄（handle）和脚本内容，调用 API 函数老队员 B/S 应用程序，早回访时基于 DOM（documentob ject model）来解析。 具体来说：
1.QTP 的原理 测试对象是 QTP 在测试或组件中创建的用于表示应用程序中实际对象的对象，并且 QuickTest 在对象库中存储有关该对象的信息，包括对象的属性、操作等。录制的时候，QTP 将操作过的所有 对象都记录下来，保存在对象库 object repository 中，记录的形式是一个逻辑名加上若干识别属性。 因此，一个完整的脚本测试应该包括两部分：一个是测试脚本的代码，一个是对象库。
2.QTP 识别对象的原理 QTP 里的对象有两个概念，一个是 test Object（T0），一个是 Runtime Object（R0） T0:就是仓库文件里定义的仓库对象
R0:是被测试软件的实际对象 QTP 识别对象，一般是要求先在对象仓库文件里定义仓库对象，里面存有实际对象的特征属性 的值，然后在运行到时候，QTP 会根据脚本了的对象名，在对象仓库里找到对应的对象，接着根据 对象的特征属性描述在被测试阮经理搜索找到相匹配的实际对象，最后就可以实际对象进行操作 了。仓库对象
T0 一般在建制/编写脚本时加入仓库文件，它不仅可以在建制编写时进行修改，也可 以在运行过程中动态修改，以匹配实际对象。 比如：和 T0\R0 相关的几个函数 GetT0Proerty()： 取得仓库对象的某个属性的值 GetT0Proerties()：取得仓库对象的所有属性的值 SetT0Proerty()：
设置仓库对象的某个属性的值 GetR0Proerty()：取得实际对象的某个属性的值 QTP 的录制原理：根据用户在应用程序界面上的操作，QTP 采用 Object Identification Tools 工具 对被操作的对象进行识别，采用反编译原理看其属于哪个插件类，从而进一步识别其属于什么控件 类，然后 QTP 把对应的控件类实例化一个对象，并把获取的应用程序的一部分属性值（足以识别对 象）赋给新建的对象，并添加到对象库里即 T0 对象，而把用户对对象的操作添加到脚本里面。 QTP 的回放原理：QTP 根据脚本中记录下来的对象操作的顺序进行回放。QTP 从脚本中读取到 该对象，并根据对象的层次和名称到对象库中相同名称的测试库对象，在测试库找到相应的对象， 获得对象的属性，根据对象库中对象的属性，在运行的应用程序中进行匹配，寻找运行时对象，找 到后根据脚本中记录的对该对象执行的动作和参数值。

七、QTP 是用什么的语言、LR 工具是用的什么语言

QTP 使用 vbscript 语言进行测试脚本开发、LR 使用 C 语言或 java 语言进行脚本开发。

二、测试流程类问题 一
说一下性能测试的流程

性能需求分析—性能测试计划—测试环境搭建—测试工具选择—测试执行—测试结果分析— 软硬件配置与调优
1.性能需求分析 性能需求分析是整个性能测试工作开展的基础，如果你连性能的需求都没弄清楚，后面的性能 测试工具就无从谈起了。
这一阶段，性能测试人员需要与需求人员（客户）、领导及项目相关的人员进行沟通，同时收 集各种项目资料，对系统进行分析，确认测试意图。当然，还需要客户对性能的态度。 测试需求分析解读的主要任务是确定测试策略和测试范围。策略主要根据软件类型以及用户对 系统的性能的需求来定，测试范围则主要分析系统的功能模块进行调研与分析。最终确认明确的需求。

2.性能测试计划 确定明确的需求之后，我们要做的工作就是知道性能测试计划。对性能测试过程中所需要的工作制定与规划。 测试计划的大体内容： 项目的简单描述，本次性能测试的需求与目的，性能需求分析的结果是什么。测试环境的准备，需要什么样的软硬件配置，网络状况登录。测试数据的准备，对于某些性能测试时需要实现 准备测试数据的。 测试的策略，前面进行需求分析的目的是制定测试策略性能测试，也就是设计符合需求的测试场景，需要对系统的哪些业务模块进行测试，如何进行？需要设计哪些场景以及设计这些场景的目的。最好会明确一下人员配备，比如需要开发、DBA、因为部人员的参与协助，性能测试的时间安排
3.测试环境搭建 测试环境搭建，分硬件环境与软件环境，硬件环境主要是向上级审批硬件配备，在某些大型性能测试，可能需要公司购置或租用硬件设备来进行。或者是将原有设置进行调配与软件环境的搭建 对于开发人员来说应该毫无压力，比如场景的三大环境，微软的 windows + IIS+SQL server 2005+.NET 平台、windows/linux+tomcat/weblogic+mysql+java、linux+apache+mysql+PHP 等环境。当然身为性能测试人员，不仅也需要会搭建软件平台，更需要对每个平台中的部分有比较深入的了解。因为性能 测试的分析并不是死盯着系统应用那一层。中间件、数据库、系统、硬件都有可能成为系统的瓶颈。

4.测试工具选择 其实走到这一步才需要引入性能测试工具，我们在日常的工作中往往是先选定好测试工具然后 再分析需求，指定计划进行测试。这样我们在做性能需求分析的时候往往会考虑所选的工具是否能 实现，无法实现可能就放弃这个需求或改变这个需求。这样以某一个工具为基础点做出的性能测试 结果可能是不准确的。 工具的引入分为自行开发与引入市面上的现有工具。市面上的现有工具有分为收费与开源免费，各有各的优缺点。我们要做的市对需求进行分析，从成本，购买成本，开发成本，现有开源工 具的二次开发成本，人员学习使用成本以及时间成本等。 在这里再强调一点，不是只有压力测试工具属于性能工具，在性能测试过程中所用到的工具都 属于性能工具，如测试数据生成工具，性能监控工具等。
5.测试的执行 测试的执行应该是很大范围的一块内容。也就是我在上一届中性能测试架构所提到的内容。用 户行为生成——>压力产生器——>用户代理——>测试调度——>系统监控等。 我们所选择的工具如何来实现我们的需求，这个性能测试工程师对引入的有足够的了解。对协议的了解，可能需要编程的能力等。其实好多新手对性能的学习也是从某一工具的使用开始的。
6.测试结果的分析 这里再重复一次，测试工具只是提供多种不同的数据揭示和呈现方法而已。工具本身并不能帮 我们进行性能结果的分析。 对于性能测试结果的分析，这个需要性能测试工程师对整个北侧环境的各种软硬件都要有深入的了解。当然，在这个过程中我们往往需要各个岗位人员的协助，开发人员、DBA、运维等。致力成为一位资深的性能测试工程师要走的路还很长
7.软件硬件配置调整与优化 说的简单点这个环境属于系统调优阶段。这一项不是一个必须的环境。这个要看你本次性能测 试的需求目的。如果只是为了验证系统的能力的话。在分析完测试结果后就可以出性能测试报告了。
6 对于我们测试人员来说，我们对一个系统进行功能测试的目的是验证系统功能十分是符合需求 并可用的，但发现了缺陷之后是需要对缺陷进行跟踪和修复的，并不是把发现的缺陷写在报告了就 完事的。当然，功能缺陷与性能缺陷存在着本质的缺陷。如果在性能测试过程中发现不满足需求的 缺陷，进行调优是一个不可缺少的过程。 如果要对系统进行调优的话，测试执行、结果分析、系统调优将会形成一个循环持续的过程。 直到满足客户的需求为止。 案例：（需背） 比如我最近做的性能测试，整个过程就是先根据需求和项目目的编写测试用例，再设计出测试 方案，方案中设定并发用户数是进行 300 个用户的并发测试，查询商品列表的时间为 100ms，提交 购买申请的页面相应时间是 200ms，单台服务器的吞吐量是 2000，压力测试的事务的成功率是 100%，稳定性测试的事物成功率要达到 99%，cpu 和内存的使用在 80%以下，通过设置不同的场景， 先进行单测网络，查看网速，带宽是否达到性能要求，在进行基础架构的测试，查看基础架构的性 能是否达到要求，最后进行了为期三天的稳定性测试，选择典型的功能模块进行测试，测试的场景 是混合场景，模拟真实的用户环境，还做了以下破坏性测试，是把服务器停了两台，再看相应时间， TPS，事物成功率，CPU 和内存的使用情况还是在 80%以下，服务器的 CPU 为 32 核，内存是 64G， 硬盘是 5T 网络配置为 1000M。 在设置不同场景的时候需要编辑脚本，脚本我们是分功能模块来录制的，录制了报案、立案、 初审、调查、理算和财务六个脚本，录制选择的协议是 http/html，把脚本放到 jmeter 里面，然后 进行筛选，把不需要的脚本进行修改，然后修改对应的参数，对下单、初审、复审、查看产品、搜 索、提交、驳回的按键设置成参数，实现参数化，最后执行脚本，在线程组中对录制的脚本进行测 试，然后进行场景测试。 1.在场景中添加不同场景添加 300 个用户，没 15 秒添加 20 个用户，运行完以后再结果分析器中查 看结果是否符合预期结果。 2.在场景中在 300 的基础上每次增加 100 个用户，每 15 秒中添加 20 个用户，并在结果分析器中查 看运行结果直到性能不满足实际性能要求。 3.在场景中在 300 的基础上每次增加 100 个用户，每 15 秒中添加 20 个用户，并在结果分析器中查 看运行结果直到系统崩溃。 调优方面，在监听器中查看运行的各项指标，例如图形结果、查看结果树、用表格查看结果、 监视器结果、聚合报告等，如果出现问题需要从几点进行分析，可能与负载均衡器的分配，也可能 是需要用缓存框架，因为硬盘读写执行比较慢，可能与代码的运算和优化有关系，linux 执行 netstat-at 检测端口查看网络连接数少的话是否限制连接数。查看通道显示字节是否拥堵（正常几百万字节， 拥堵几万字节）接受能力不行。时间慢可以使用缓存（基础数据，访问频率高，不经常更新的数据 进行缓存），查看相应 CPU 是否波动，内存是否是否合理，线程是否过多，换 CPU 或代码调优， 可以使用线程池。 最后进行为期 3 天的稳定性测试，使用登录，提交，查看案件，保单号，退出登录等多个场景 使用 300 用户进行测试，最后查看各项指标是否都在预期的性能指标内。稳定性在 tps，响应时间， 并发用户，内存使用率达标的情况下，主要关注 tps 取消是否无波动，cpu 内存使用平稳无大波动， 成功率在 99%以上。

二、说一下自动化测试的流程？ 1.制定测试计划 在展开自动化测试之前，最后做个测试计划，明确测试对象、测试目的、测试的项目内容、测 试的方法、测试的进度要求，并确保测试所需的人力、硬件、数据等资源都准备充分。制定好测试 计划后，下发给用例设计者。 2.分析测试需求 用例设计根据测试计划和需求说明书，分析测试需求，设计测试需求树，以便用例设计时能够 覆盖所有的需求点。一般来讲，基于 Web 功能测试需要覆盖以下几个方面：
（1）页面链接测试，确保各个链接正常；

（2）页面空间测试，确保各个控件可靠；
（3）页面功能测试，确保各项操作正常；
（4）数据处理测试，确保数据显示准确、处理精确可靠；
（5）模块业务逻辑测试，确保各个业务流程畅通。

3.设计测试用例 通过分析测试需求，设计出能够覆盖所有需求点的测试用例，形成专门的测试用例文档。由于 不是所有的测试用例都能用自动化来执行，所以需要将能够执行自动化测试的用例汇总成自动化测 试用例。必要时，要讲登录系统的用户、密码、产品、客户等参数信息独立出来行测试数据，便于 脚本开发。

4.搭建测试环境 自动化测试人员在用例设计工作开展的同时即可着手搭建测试环境。因为自动化测试的脚本编 写需要录制页面空间，添加对象。测试环境的搭建，包括被测系统的部署、测试硬件的调用、测试 工具的安装盒设置、网络环境的布置等。

5.编写测试脚本 Robot framework+selenium 是自动化框架，可以通过关键字 xpath，css 等进行驱动的功能测试， 以 robot framework+selenium 为核心的自动化框架优点在于：适用性好，脚本简单易懂，可以引入 断言等形式以便验证组件是否按预期运行。可以打印日志，容易维护，拓展性比较强，可以做 UI 自动化，接口自动化，而且 framework+selenium+Appium 是 android 自动化框架等，并且， framework+selenium 封装后的脚本，维护和查看编写，修改都方便容易，提高了自动化测试收益。 针对我们的理财系统项目，我们使用 framework+selenium 工具来实现自动化的测试，对系统 中需要大量重复操作的模块和重要的业务流程模块编写脚本。

1.首先，搭建 framework+selenium 环境，导入对应的驱动库，例如 selenium 库，appium 库等，根 据需要，找到对应关键词的驱动地址，例如 xpath、css 等。

2.脚本编写完成之后，接下来我们要对测试脚本进行封装，增加脚本的灵活性。
（1）把测试脚本封装，根据自动化的用例去执行相应测试。
（2）执行之后的结果可以在日志或结果里面进行查看和修改。
（3）robot framework 里面可以把参数或者出入的值变为参数化，优点类似于 jmeter， 可以吧一些值变为参数进行传输。
（4）在 robot framework 里面，对注册和登录脚本的相关文本输入框，以及对购买脚本 的产品金额的输入框进行参数化。参数的内容选取导入的表格的“输入内容”里设 计好的数据。
（5）可以插入自定义监控点，让 robot framework 检查一下在程序的某个特定位置或对 话框中是否出现了需要的文字，验证脚本执行的结果和预期是否一致，次数需要配 合 if…else…语句来判断检查点是否通过，如果检测的通过，那么“预期结果”列输 入“通 过”，否则输入“不通过”。另外，测试报告里面会显示指定的内容，会打印 到日志中。
（6）在脚本的最后，将数据表到处到指定的位置。方便我们去查看表格中用例执行的 结果。分析测试结果，记录测试问题。修改问题。 脚本编写好了之后，需要反复执行，不断调试，直到运行正常为止。脚本的编写和命名要符合 管理规范，以便同意管理和维护。
6.分析测试结果、记录测试问题 应该及时分析自动化测试结果，建议测试人员每天抽出一定跟踪测试 BUG ，测试记录的 bug 要记录到缺陷管理工具中去，以便定期跟踪处理。开发人员修复后，需要对此 问题执行回归测试，就是要重复执行一次该问题对应的脚本，执行通过则关闭，否则继续修改。如 果问题的修改方案与客户达成一致，但与原来的需求有所偏离，那么在回归测试前，还需要对脚本 进行必要的修改和调试。
三、说一下接口测试
接口测试主要测试接口返回的数据是否正确，主要检查返回的接口是否和接口文档中定义 的一样，还有要检查返回的数据是否和数据库中的保存一致，也就是查看信息是否存在以及各项信息是否正确。 当初我所做的接口测试的步骤是：

1.分析出测试需求，并拿到开发提供的接口说明文档，从接口说明文档中整理出接口测试案例， 里面要包括详细的入参和出参数据，和开发一起对接口测试案例进行评审。
2.结合开发库，准备接口测试案例中的入参数据和出参数据。
3.当时所用到的工具是 Jmeter，使用的协议是 HTTP 请求协议，Jmeter 工具不单只用于做性能测试的，它在实现对各种接口的调用方面已经做的比较成熟，因此直接使用 Jmeter 工具来做接口 测试也极其方便，首先打开 Jmeter 添加线程组：在“测试计划”上点击鼠标右键——>添加 threads （Users）——>线程组，添加测试场景设置组件，设置为 1 个“线程组”，以及设定“循环次数”。 然后添加“HTTP Cookie 管理器”，添加“HTTP 请求默认值”组件，在“HTTP 请求默认值”组件配 置页面，填写被测的域名和端口，在“线程组”里添加“HTTP 请求”的 Sampler 在 HTTP 请求设置 页面。录入保单号接口的详细信息，包括它请求路径。对应的请求方法，所用到的方法是 post 以 及随请求一起发送的参数列表。设置检查点：在被测接口对应的“HTTP 请求”上，添加“响应断 言”添加监听器方便查看到运行后的结果。当前的报文是 xml 格式，使用 xslt 方法，如编号是 numberAP4567890，金额 mony30000，读取出来的节点名值 AP4567890，30000。
四、说一下测试的流程
1.需求分析阶段：只要就是对业务的学习，分析需求点。
2.测试计划阶段：测试组长就要根据 SOW 开始编写《测试计划》，其中包括人员，软件硬件 资源，测试点，集成顺序，进度安排和风险识别等内容。
3.测试设计阶段：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据 《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测试 方案》编写完成后也需要进行评审。
4.测试方案阶段：主要是对测试用例和规程的设计。测试用例是根据《测试方案》来编写的， 通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解，这时开始编写用例才能保证用 例的可执行和对需求的覆盖，测试用例需要包括测试项，用例级别，预置条件，测试步骤和预期结 果，其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆 盖了测试需求点，这样才能保证客户需求不遗漏，同意，测试用例也需要评审。
5.测试执行阶段：执行测试用例，及时提交有质量的 Bug 和测试日报。
6.跟踪 BUG 7.提交测试报告等相关文档

五、怎么用在 Linux 环境下搭建环境
1.安装 jdk。 可以选择 zip，rpm，tar.gz 中文件进行安装，
命令如下： rpm：rpm -ivh jdk 包名 tar.gz：tar -zxvf jdk 包名 exe：yum install 包名

2.安装完成之后进行配置环境变量。
1.输入 cd /etc，进入到 /etc 目录，输入 cat profile 查看 profile 文件的内容。可以看到没有配置 jdk 的环境。
2.先找到 jdk 安装的目录，进入到 use/java 下，输入 ls 查看是否有安装的 jdk 的文件夹。进行配 置完成后，按住 esc 保证文件不处于编辑状态。输入：wq（保存并退出）。
3.输入 source profile（可以使配置在不重启的情况下就立即生效）输入 cat profile 进行检验是 否有效。输入 javac -version 和 java -version 查看 jdk 版本信息。
3.安装 tomcat。
1.进入有 tomcat 的文件的文件夹下，进行解压。 解压命令：zip : unzip jdk 包名

2.解压完成后，进入 conf 目录下，修改 server.xml 里面的 3 个端口 8080（服务器启动端口）8005 （关闭服务器端口）8009（重定向端口）修改 0~65535 中的任何一个没有被占用的端口。
3.在进入到目录下对 shutdown.sh（关闭）startup.sh（启动）catalina.sh（记录日志）这 3 个文 件进行设置可执行（x）权限输入 chmod+x startup.sh shutdown,sh catalina.sh（与顺序无关）然后输 入 11 就可以看到文件的详细信息，然后可以看到权限。输入 sh startuo.sh 或者./startup.sh 启动 tomcat。如果启动很忙就删除 tomcat 目录下的 webapps 目录下的所有文件，启动就会快一些。启动成功后，在浏览器输入 http://ip:端口就会出现 tomcat 的页面。如找不到页面试着加上 index,isp 看看。

六、安全性测试怎么测？ 软件软件安全一般分为两个层次，即应用程序级别的安全性和操作系统级别的安全性。

应用程序级别的安全性，包括对数据或业务功能的访问，在于其的安全性情况下，作者只能访问应用程 序的特定功能、有限的数据等。操作系统级别的安全性是确保只有具备系统平台访问权限的用户才 能访问，包括对系统的登录或远程访问。

应用层语言的安全，包括两个发层面：
1.是应用程序本身的安全性。一般来说，应用程序的安全问题主要是有软件漏洞导致的，这些漏洞可以是设计上的缺陷或是编程上的问题，甚至是开发人 员预留的后门。
2.是应用程序的数据安全，包括数据存储安全和数据传输安全两个方面。 目前主要的安全测试方法有1.静态的代码安全测试：主要通过对源代码进行安全扫描，根据程序中数据量、控制流。语义等信息对其特有软件安全规则库进行匹配，从而找出代码中潜在的安全漏洞。静态的源代码安全测试是非常有用的方法，它可以在编码阶段找出所有可能存在安全风险的代码，这样开发人员可以在早期解决潜在的安全问题，静态代码测试比较适用于早期的代码开发阶段，而不是测试阶段。 2.动态的渗透测试：渗透测试也是常用的安全测试方法。是使用自动化工具或者人工的方法模 拟黑客的输入，对应用系统进行攻击性测试，从中找出运行时刻所存在的安全漏洞。这种测试的特 点就是真实有效，一般找出来的问题都是正确的，也是较为严重的。单渗透测试一个致命的缺点是 模拟的测试数据只能达到有限的测试点，覆盖率很低。
3.程序数据扫描。一个有高安全性需求的软件，在运行过程中数据是不能遭到破坏的，否则就 会导致缓冲器一处类型的攻击。数据扫描的手段通常是进行内存测试，内存测去试可以发现许多诸 如缓冲区溢出之类的漏洞，而这类漏洞使用除此之外的测试手段都难以发现。例如，对软件运行时 的内存信息进行扫描，看是否存在一些导致隐患的信息，当然这需要专门的工具来进行验证，手工 做是比较困难的。 一般常见的软件安全性缺陷和漏洞主要有：
（1）缓冲区溢出 缓冲区溢出已成为软件安全的头号公敌，许多实际中的安全问题都与它有关。造成缓冲区溢出 问题通常有以下两种原因。 1.设计空间的转换规则的校验问题。即缺乏对可测数据的校验，导致非法数据没有在外部输入 层被检查出来并丢弃。非法数据进入接口层和实现层后，由于它拆除了接口层和实现层的对应测试 空间或设计空间的范围，从而引起溢出。 2.局部测试空间和设计空间不足。当合法数据进入后，由于程序实现层内对应的测试空间或设 计空间不足，导致程序处理时出现溢出。 （2）加密弱点 1.使用不安全的加密算法。加密算法强度不够，一些加密算法甚至可以用穷举法破解。 2.加密数据时密码是否有伪随机算法产生的，产生伪随机数的方法是否存在缺陷，使密码很容易被破解。3.身份验证算法存在缺陷。 4 客户机和服务器始终未同步，给攻击者足够的时间来破解密码或修改数据。 5.未对加密数据进行签名，导致攻击者可以篡改数据。所以对于加密进行测试时，必须针对 这些可能存在的加密弱点进行测试。
（3）错误处理 一般情况下，错误处理都会返回一些信息给用户，返回的出错信息可能会被恶意用户利用来进 行攻击，恶意用户能够通过分析返回的错误信息直到下一步要如何做才能使攻击成功。如果错误处 理时调用了一些不该有的功能，那么错误处理的过程将被利用。错误处理属于异常空间内的处理问 题，异常空间内的处理要尽量简单，使用这条原则来设计可以避免这个问题。但错误处理往往牵涉 到易用性方面的问题，如果错误处理的提示信息过于简单，用户可能会一头雾水，不知道下一步该 怎么操作。所以，在考虑错误处理的安全性的同时，需要和易用性一起进行权衡。
（4）权限过大 如果赋予多大的权限，就可能导致只有普通用户权限的恶意用户利用过大的权限做出危害安全 的操作。例如没有对能操作的内容做出限制，就可能导致用户可以访问超出规定范围的其他资源。 进行安全性测试时必须测试应用程序是否使用了过大的权限，重点要分析在各种情况下应该有 的 权限，然后检查实际中是否超出了给定的权限。权限过大问题本质上属于设计空间过大问题，所以 在设计时要控制好设计空间，避免设计空间过大造成权限过大的问题

3.文档类问题 一
测试计划和测试报告应该怎么写？
答：测试报告要写出所有人员安排和测试情况，其中包括产品在研发阶段发现的问题，和所有测试时间，以及影响范围和建议，最后给出项目总结
1.测试计划内容包括：

1.简介产品简介—测试目的—测试范围
2.测试参考文档和测试提交文档 测试参考文档—测试提交文档
3.测试进度 4.测试资源 人力资源—测试环境—测试工具
5.问题严重性及优先级描述 严重级别定义—优先级定义—跟踪及测试版本
6.测试风险 时间资源—人力资源—测试版本—需求变更—其他
7.测试策略 数据库测试—功能测试——用户界面测试—性能评测—兼容性测试—安全性测试

2.测试报告内容包括：
1.首页
2.引言编写目的—项目背景—系统简介—术语和缩略语—参考资料
3.测试概要 测试方法和工具—测试范围（用例设计）—测试环境与配置
4.测试结果与缺陷分析

1.测试执行情况与记录：测试组织—测试时间—测试版本
2.覆盖分析：需求覆盖——测试覆盖
3.缺陷的统计与分析：缺陷汇总—缺陷分析—残留缺陷与未解决问题
5.测试结论与建议

1.测试结论：
1.测试执行是否充分（可以增加对安全性、可靠性、可维护性和功能性描述）
2.对测试风险的控制措施和呈现
3.测试目标是否完成
4.测试是否通过
5.是否可以进入下一阶段项目目标 ，建议
6.附录
二、没有需求文档怎么测试系统
第一步：手机数据： 阅读文档—检查系统的体系结构—执行程序—询问开发者—询问项目经理

第二步：将资料转化为系统需求： 1.确定系统拥有多少角色（业务），他们负责什么样的工资； 2.确定系统管理员的工作内容，系统管理员一般对系统进行初始设置，角色定义，业务流定义等重 要操作； 3.确定系统的数据流动，包括系统的内部模块间数据流动（可结合系统角色图）和系统间的数据流 动接口，在这些地方一般都比较容易出现问题。 4.确定公共部分需要测试的需求。系统中有一些部分为很多角色所共同拥有并且不涉及业务流程。 将这部分内容整理，一般来说这些内容只会设计界面和普通功能的测试，如定义系统界面风格。 5.确定系统的使用情况。系统有多少用户，稳定运行要求至少多少时间，什么时候会出现系统使用 高峰期，高峰期的特点。系统对未来几年内的用户和数据增长是否提供足够的可扩展空间。 6.系统的安全确定。系统运行的环境要求什么样的安全级别，有什么具体要求。如：访客是否能访 问到只要用户才能访问的功能；一个角色是否越权访问他不能不能访问的角色。系统是否存在没有 指向的连接页面作为后面（这个比较难）等等。 7.使用该系统的用户可能的硬件、软件环境，比如机器类型，操作系统，常用软件等。 8.其他系统要求确定的需求。 做完这些工作后，然后就可以开始设计测试用例了。虽然仍然存在不知道的情况，单基本可以确定 它没有表现在系统的可视范围内。

三、测试用例应该怎么写？
1.确定测试用例的目的。如果不了解为何要写这个用例，那你达到的目的就是按需求或者按任 务来完成而已，这样的用例是否适用还有待于商榷，只有了解这个功能的来源，为什么要做这样的 功能，希望最后的结果是什么，这些通通考虑清楚了，就不会为了完成任务而去编写“普通”的测 试用例，而是一份优秀合格的测试用例。这样会大大提高工资效率及审核打回的次数。
2.测试用户所包含的内容：最基本最简单的测试用例应该包含四项内容，即描述、预置条件、 操作步骤、预期结果。一般为更好的管理及维护测试用例，我们会增加测试用例的编号及功能。 1.测试用例的描述项，一般人在写的时候根本不去关心着到底有何用，有的甚至为空，更有甚 者把需求中的几个字之间复制过来，不管是否通顺与否都放在那里认为就可以了，预支条件可以说 是一个总结语，

即你要明白这个用例是要验证什么的，因为一个功能有很多用例，你不可能每个描 述都是一样的，那样还不如不要描述。

2.预支条件项，任何一个事务都有奇缘，有始有终才是一个完整的过程，预置条件也可以说是 一个基础，基础打好了，一切才能顺利动工。预支条件是为操作步骤五福的，当然有些可能说不需 要预置条件，其实任何用例都是有预置条件的，我们说没有预置条件只是隐藏了本身的特点而已。
简单来说，发送一条命令测试用例，前期不需要预置条件，但其隐藏的就是有号，且通信正常，还 要有 MONEY 用来发送短信；但实际中我们并不需要这些预置条件，因为这是本身特点决定的。
3.操作步骤是非常重要的一环，与预期结果是等同的地位。测试用例设计是否高效，由预置条 件及操作步骤决定，在操作步骤中，按正常步骤来测试，好像都不会出问题，但真正出问题的就是 你想不到的，不是按常理规则出牌的才会发现真正有价值的缺陷，所以在设计测试用例时，不要嫌麻烦，认为那一项就好了，别的都应该能检测到，认为写某一项是不必要的，多余的，其实这些想 法都是错误的，问题就往往出现在你认为这无关功能上。 设计操作步骤还依赖于测试经验是否丰富，有些经验丰富的人员设计的测试用例往往会出乎意料，也就是在测试阶段最容易发现问题的用例。比如很简单的一个编辑功能，要求其内容不能重复， 一般人在写用例的时候都在编辑中去修改成别的名字，二有经验的测试人员会直接编辑一下而不改变内容，一般的程序员是不会考虑到此问题，如果说出现提示错误一般都是程序逻辑问题。
4.预期结果，此项是验证缩写用例是结果如何，所以如果没有预期结果，在测试时则无任何可 参照的，预期结果与操作步骤的关系相当大，一般来说，不同的操作步骤能生成不同的预期结果， 因此在测试测试用例的时候，尽可能的考虑不同的操作步骤，食肉会产生同一个结果，所以有时在 设定测试用例的时候，根据结果来推断操作步骤，这也应该是设计用例时的一种参照方法。在测试 时，预期结果直接导致测试是否通过。等价类、边界值、错误推测发、场景法等这些测试方法就不 说了，这都是每个测试人员必须都会的。
四、测试实战问题 一、
搜索框，要怎么测试？
答：一般测试功能常用的测试方法，有边界值、场景法、等价类等，比如：
1.不输入任何字符，点击搜索按钮，一般搜索出网站所有的信息。
2.一般搜索输入框中的有文章显示，当鼠标点击时，文章消失。
3.输入全角/半角中文字符（一个字符、超长字符、已经信息字符）。
4.输入全角/半角英文字符（一个字符、超长字符、已经信息字符）。
5.输入全角/半角特殊字符~！@#$%^&*()_+|{}<>?.，:’[]=-（注意单引号经常会发现 bug）
6.输入全角/半角中英文空格
7.输入 html 语言
8.输入特殊字符串 NULL、null、空格的转义字符；；
；；；；； ；；
二、文本框怎么测
1.输入正常的字母或数字。
2.输入重复值，程序应给出错误提示。
3.输入值长度验证，当输入值长度小于或大于规定长度时均应有程序给出错误提示。
4.输入默认值，空白，空格。
5.输入特殊字符集，例如 NUL 及\n 等。
6.输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示。
7.输入不符合格式的数据，检查程序是否正常校验。
8.若只允许输入字符，尝试输入数字，反之，尝试输入字母。
9.利用复制，粘贴等操作强制输入程序不允许的输入数据。
10.必填项未输入，程序应给出错误提示。
11.字段唯一性校验（不是所有字段都做此项校验，视实际项目情况而定）

三、如何测试一张 A4 纸
1.纸张的质地，是否为纸张。
2.纸张的品质，是草木、皮革。
3.纸张的类别，是否为白纸。
4.纸张的功能，能否书写，图画等。
5.纸张的兼容性，水笔、油画、铅笔是都能正常书写。
6.纸张的扩展性，折叠、拉伸。
7.纸张的安全性，纸张的生产工艺是否安全，纸张有无有毒性物质。
8.纸张的结构
9.纸张的性质，对各种笔的吸油性是否够快。

四、怎么测试登录模块？
1.功能测试（function test）
1.什么都不输入，点击提交按钮，看提示信息。
2.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。
3.输入错误的用户名或密码，验证登录会失败，并且提示相应的错误信息。
4.登录成功后能否跳转到正确的页面。 12
5.用户名和密码，如果太短或者太长，应该怎么处理。
6.用户名和密码中有特殊字符（比如空格），和其他非英文的情况。
7.记住用户名的功能。 8.登录失败后，不能记录密码的功能。
9.用户名和密码前后有空格的处理。
10.密码能否加密显示（星号原点等）。
11.牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者）， 刷新或换一个按钮是否好用。
12.登录页面中的注册、忘记密码，登出用另一账号登录等连接是否正确。
13.输入密码的时候，大写键盘开启的时候要有提示信息。

2.界面测试（UI Test）
1.布局是否合理，
2 个 testbox 和一个按钮是否对齐。
.testbox 和按钮的长度，高度是否符合要求。
3.界面的设计风格是否与 UI 的设计风格统一。
4.界面中的文字简洁易懂，没有错别字。

3.性能测试（performance test）
1.打开登录界面，需要几秒。
2.输入正确的用户名和密码后，登录成功跳转到新页面，不超过 5 秒。

4.安全性测试（Security test）
1.登录成功后生成的 Cookie，是否是 httponly（否则容易被脚本盗取）。
2.用户名和密码是否通过加密的方式，发送给 Web 服务器。
3.用户名和密码的验证，应该是用服务器端验证，而不是单单是在客户端用 javascript 验证。
4.用户名和密码的输入框，应该屏蔽 SQL 注入攻击。
5.用户名和密码的输入框，应该禁止输入脚本（防止 XSS 攻击）。
6.错误登录的次数限制（防止暴力破解）。
7.考虑是否支持多用户在同一机器上登录。
8.考虑一用户在多台机器上登录。

5.可用性测试（Usability Test）
1.是否可以全用键盘操作，是否有快捷键。
2.输入用户名，密码后按回车，是否可以登录。
3.输入框能否可以以 Tab 键切换。

6.兼容性测试（Compatibility Test）
1.主流的浏览器下能否显示正常且功能正常。
2.不同的平台能否正常工作，比如 Windows,Mac。
3.移动设备上能否正常工作，比如 Iphone，Andriod。
4.不同的分辨率。

7.本地化测试（Localization Test）
1.不同语言环境下，页面的显示是否正确。

五、APP 应该怎么测试？ 答：APP 要考虑的因此比较多。
（1）功能测试 每项开发的新功能都需要进行测试。App 测试中功能测试时一个重要方面。测试人员应该要进 行手动测试和后期的自动化测试维护。刚开始测试时，测试员必须把 app 当中“黑盒”一样进行手 动测试，看看提供的功能是否正确并入设计的一样正常运作。除了经典软件测试，像点击按钮、提 交订单看看会发生什么，测试员还必须执行更多功能的 app 测试。 除了整个手动测试过程，测试自动化对移动 app 也很重要。每个代码编号或新功能都可能影响 现存功能及它们的状态。通常手动回归测试时间不够，所以测试员不得不找一个工具去进行自动化，回归测试。限制市面上有很多自动化测试工具，有商业的也有开源的，面向各个不同平台，如 Andriod，iPhone，WindowsPhone7，BlackBerry 以及 Webapp。根据开发策略和结构，品质管理测试 专家需要找出最合适他们环境的自动化工具。
（2）客户端性能测试 一个 App 做的好不好，不仅仅只反应在功能。被测的 app 在中低端机上的性能表现也狠重要。 比如：一个很好玩的游戏或应用，只能在高端机上流畅运行，在中低端上卡的不行，也不会取得好 的口碑。关于 App 的性能测试，一般比较关注的参数有：CPU，内存，耗电量，流量，FPS。同时也需要 关注一下 App 的安装耗时和启动耗时。
（3）适配兼容测试 App 在经过功能测试后，也需要对其进行适配兼容测试需要检查的项主要有以下几点： 1.在不同品牌的机型上的安装、拉起、点击和卸载是否正常。 2.在不同的操作系统上的安装、拉起、点击和卸载是否正常。 我们在实际测试中，常常会遇到一些问题，比如在操作系统上： 1.app 安装不上。2.app 无法拉起。3.app 拉起后无响应或拉起后黑屏、花屏。4.app 无法顺利卸 载。
（4）安全测试 App 在上线前都需要做详细的安全测试。安全测试主要是为了检测应用是否容易被外界破解。 是否存在被恶意代码注入的风险。上线后外挂的风险高不高等。
（5）服务器性能测试 服务器性能测试，主要包含单机容量测试和 24 小时稳定性测试。单机容量测试，可以检测到 单机服务器在 90%的响应时间和成功率都达标的前提下，能够承载多少用户量。使用特点 app 模型 压测 24 小时，服务器无重启，内存无泄漏，并且各事物成功率达标。

六、测试过程中兼容性问题怎么测试？

1.什么是兼容性测试 很多人都知道兼容性测试，但是却很少能准确理解兼容性测试，大多都只会想到浏览器的兼容， 知己兼容性还有其他内容，包括 web 兼容和 app 兼容。 兼容测试（Compatibility Test Suite）官方简称 CTS，指对所设计程序与硬件、软件之间的兼容性 测试。一般来说，兼容性指能同时容纳多个方面，在计算机术语上兼容是指几个硬件之间、几个软 件之间或是软硬件之间的相互配合程度。 按照我的理解，我认为兼容性测试时指测试软件在特点的硬件平台上、不同的应用软件之间、 不同的操作系统平台上、不同的网络等环境中是否能够很友好的运行的测试。 2.兼容性测试分类 兼容性测试目前我关注的包括 web 兼容性测试和 APP 兼容性测试。 兼容性测试包括： 1.浏览器兼容测试：测试程序在不同浏览器上是否可以正常运行，功能能否正常使用。 2.屏幕尺寸和分辨率兼容测试：测试程序在不同分辨率下能否正常显示。 3.操作系统兼容测试：测试程序在不同操作系统下面能否正常运行，功能能否正常使用，显示 是否正确等。 4.不同设备型号兼容测试：针对于 APP，限制移动设备型号五花八门，主要测试 APP 在主流设 备上能否正常运行，会不会出现崩溃的现象。 3.兼容性测试方法 Web 端和 APP 端的兼容性测试，有两种方法： 一种是人工测试即全手工测试兼容，另外一种是借助第三方兼容性测试工具。人工测试工作量 大，而且覆盖不全，第三方测试工作虽说工作量小，但是在主功能和主流程测试的时候没有侧重点， 很难发现一些隐藏的问题。要说这两种方法哪一种更换，我个人认为没有最好，我觉得这两种方法 适当的结合才是最好的兼容性测试方法。
4.如何进行兼容性测试
（1）Web 兼容性测试 首先开展扔测试，测试工程师测试主流浏览器和常用操作系统测试主流程和主界面，看看主流 程和主界面是否有问题，如果存在问题，那么记录下 bug 情况，以及浏览器型号和版本，以及操作 系统，准确定位 bug 产生的原因，提交 bug，告知开发人员修改。所有的主流设备都需要进行测试， 只关注主流程和主界面，毕竟每个系统主流程和主界面不是很多，所以这个工作量还是可以承受的。 其次借助第三方测试工具，目前我觉得比较好用的第三方 Web 测试工具有 IEtester（离线）、 SuperPreview（离线）和 Browsershots:browsershots:. org（在线），一款可以测试 IE 的兼容，一款 可以测试主流浏览器的兼容，包括谷歌、火狐、Opera 等等。借助第三方测试工具，找到 bug 产生 的为主，分析测试结果，告知程序员跳转。

（2）APP 兼容性测试 APP 的兼容性测试和 Web 测试类似，首先开展人工测试，测试工程师借助测试设备对主流程和 主功能，主界面进行测试。收集所有的能收集到的不同型号的测试设备测试主流程和主界面，看看 主流程和主界面是否有问题，如果存在问题，综合考虑设备的使用率等因素，看看是否需要调整， 如果需要，那么记录下 bug 情况以及测试设备的型号和操作系统，准确定位 bug 产生的原因，提交 bug，告知开发人员修改。 其次借助第三方测试工具，对于 APP 的兼容性测试，我推荐的是百度众测平台和云测平台，我 经常使用的市云测平台，这两款测试工具里面包含了安卓和 iOs 的测试。测试很齐全，包括功能测 试、深度兼容测试、性能测试、网络环境测试、还可以模拟海量用户测试，还可以导入自己编写的 测试用例进行功能测试，里面还包括测试专家的测试，当然了找专家是要花钱的。基本进行兼容性 测试是不需要花钱的，测试工程师吧打包好的 apk 或者 IPA 文件，上传到测试平台没选择需要测试 的设备型号，开始任务即可，等待一段时间，在等待的时间你是不需要盯着的，你可以做其他的工 作。测试完成后会生成一份测试报告，可以查看错误页面和错误日志，如果需要调整，那么提交 bug，告知程序员修改即可。
.兼容性测试的作用 兼容性测试时软件测试过程必不可少的一个过程，没有兼容测试的测试时不完整的测试。兼容 性测试的存在是有一定作用的。

我个人觉得最少有以下几点： 1.兼容性测试能够进一步提高产品的质量，提供用户体验。 2.兼容性测试能使软件与其他软件“和平共处”，尽可能达到平台无关性。 3.兼容性测试能尽可能保证软件存在的价值，他是衡量一个软件质量的重要指标。 4.兼容性测试能使软件产品的市场更广阔。

七、怎么测试高并发？ 答：一般我们都是使用 Jmeter 测试高并发，Jmeter 测试高并发的步骤是： 右键添加一个线程组——设置并发线程数，循环次数——右键线程组，添加一个逻辑控制器： 事务控制器——右键事务控制器，添加一个 http 请求——设置 http 请求地址——右键添加查看结 果树和聚合报告——点击运行，通过聚合报告查看测试结果。

八、测试承载量大于两万，应该怎么测试？ 使用测试工具，可以不断的追加用户，观察系统的峰值。测出系统最大承载量。

九、不可重现的 bug 怎么处理？ 发现缺陷就要在缺陷管理工具记录，如果不能浮现，就要缺陷里面明确标记一下。首先检查一 下是否是自己的错误操作或者其他外在因素引起的，其次查找一下系统日志，看是否有报错记录， 最后尝试复现问题，如果不能，这个缺陷保留，后续观察，如果再次出现可以及时解决。

十、什么原因造成的 bug？ 需求逻辑错误，产品逻辑复杂，需求量比较大，相关人员对产品不够熟悉，需求不够明确，人 员变动，沟通不良，产品周期短，工作强度大，需求变更频繁，管理不当，工作任务分配严重不平 衡，开发人员技能不达标等等这些都有可能会造成 bug。

十一、实名认证怎么测试？
16 实名一般都是需要争取的身份证号和名字对于，还有手机号。一般是你要有个真实的身份证号 码和名字数据库，才能匹配上去实名制对接公安身份信息验证渠道。

十二、Get 和 post 有什么不同？
Get 是向服务器发索取数据的一种请求，而 Post 是向服务器提交数据的一种请求。
Get 方式安全性低，post 方式较安全。但是 post 方式执行效率要比 get 方式差一些。

十三、遇到 bug 开发认为的非 bug 如何处理？
1.确认 bug 是否是由于自己的错误操作或者其他的外部原因引起的。 2.去找对应的需求文档，查看是否有明确标注改功能或者逻辑等。 3.如果有明确标注，把需求文档截图附件到 BUG 里面。 4.如果需求文档没有明确标注，找开发和需求工程师产品经理确认，看如何处理，如果产品说可以 按照开发的逻辑设计，需要让产品补全文档，发给相关人员，然后把 bug 关闭，备注需要修改。 5.如果需求确认要修改，依然让产品补全需求文档，发出来，并通知开发修改。

十四、性能的指标有哪些，如何设置性能场景？ 1.相应时间 2.最大并发用户数 3.吞吐量 4.性能计数器 性能计数器是描述服务器或操作系统的一些数据指标。例如对 Windows 系统来说，使用内存是， 进程时间等都是常见的计数器。5.思考时间 6.TPS，每秒钟系统能够处理的交易或者事务的梳理。它是衡量系统 处理能力的重要指标。 7.HPS 点击率：HPS，每秒钟用户向 WEB 服务器提交的 HTTP 请求数。这个指标是 WEB 应用特有的 一个指标，WEB 应用时“请求—响应”模式，用户发出一次申请，服务器就要处理一次，所以点击 时 WEB 应用能够处理的交易的最小单位。 8.CPU 使用情况 9.消耗资源数据 十五、

常用的 Linux 命令是什么？ 要能说出：系统常用的，例如：创建文件目录、删除文件目录、复制剪切、查看进程、结束进 程、查看文件日志等。 常用指令 系统管理命令 find 在文件系统中搜索某文件 free 查看内存 more、less 分页显示文本文件内容 top 动态显示当前好烦资源最多的进行信息 head、tail 显示文件头、尾内容 ps 显示瞬间进程状态 ps -aux tail -f 查看实时日志 ifconfig 查看网络情况 cp 复制 ping 测试网络连通 mv 移动 kill 结束进程 rm -rf 删除 mkdir 建文件夹 打包压缩相关命令 tar：打包压缩 -c 归档文件 -x 压缩文件 -z gzip 压缩文件 -j bzip2 压缩文件 -v 显示压缩或解压缩过程 -f 使用档名 例：tar -cvf /home/abc.tar /home/abc 只打包，不压缩 tar -zcvf /home/abc.tar.gz /home/abc 打包，并用 gzip 压缩 tar -jcvf /home/abc.tar.bz2 /home/abc 打包，并用 bzip2 压缩 当然，如果想解压缩，就直接替换上面的命令 tar -cvf / tar -zcvf / tar -jcvf 中的“c”换成“x” 就可以了。
17 常用的 linux 文件权限： （444 r–r--r–）、（600 rw-------）、（644 rw-r–r--）、（666 rw-rw-rw-）、 （700 rwx------）、（744 rwxr–r--）、（755 rwxr-xr-x）、（777 rwxrwxrwx） 从左至右，1-3 位字母代表文件所有者的权限，4-6 位字母代表同组用户的权限，7-9 代表其他 用户的权限。而具体的权限是由数字来表示的，读取的权限等于 4，用 r 表示；写入的权限等于 2， 用 w 表示；执行的权限等于 1，用 x 表示。 通过 4、2、1 的组合，得到以下几种权限：0（没有权限）；4（读取权限）；5（4+1|读取+执 行）；6（4+2|读取+写入）；7（4+2+1|读取+写入+执行）。 以 755 为例：1-3 位 7 等于 4+2+1，rwx 所有者具有读取、写入、执行权限；4-6 位 5 等于 4+1+0， r-x，同组用户具有读取、执行权限但没有写入权限；7-9 位 5，同上也是 r-x，其他用户具有读取、 执行权限但没有写入权限。

十六、什么是 HTTP\TCP\UDP 协议？
HTTP 超文本传输协议（HTTP，HyperText Transfer Protocol）是互联网上应用最为广泛的一种网 络协议。所有的 www 文件都必须遵守这个标准。设计 HTTP 最初的目的是为了提供一种发布和接 收 HTML 页面的方法。
TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的 传输层通信协议在简化的计算机网络 OSI 模型中，它完成第四层传输层所指定的功能，用户数据报协议（UDP）是同一层内另一个重要的传输协议。在因特网协议族（Internet protocol suite）中，TCP 层是位于 IP 层之上，应用层之下的中间层。不同主机的应用层直接经常需要可靠的、像管道一样 的连接，但是 IP 层不提供这样的流机制，而是他提供不可靠的包交换。 UDP 是 User Datagram Protocol 的简称，中文名是用户数据报协议，是 OSI（Open System Interconnection，开放式系统互联）参考模型中一种物理按键的传输层协议，提供面向事务的简单 不可靠信息传送服务，UDP 协议全称是用户数据报协议，在网络中它与 TCP 协议一样用于处理数据 包，是一种无连接的协议。在 OSI 模型中，在第四层——传输层，处于 IP 协议的上一层。UDP 有不 提供数据包分组、组装和不能对数据包进行排序的缺点，也就是说，当报文发送之后，是无法得知 其是否安全完整到达的。

十七、请求无法响应可能是什么原因？
响应码分为五种类型，由它们的第一位数字表示：

1xx：信息，请求收到，继续处理。
2xx：成功，行为被成功地接受、理解和采纳。
3xx：重定向，为了完成请求，必须进一步执行的动作。
4xx：客户端错误，请求包含语法错误或者请求无法实现。
5xx：服务器错误，服务器不能实现一种明显无效的请求。

下表显示每个响应码及其含义：


优化类问题： 一、高并发/性能调优/架构 关于性能需要熟悉的三个指标为：并发用户、相应时间、TPS（每秒事物处理个数）。 比如：单台服务器配置为 32 核 CPU，64G 内存，JVM 内存 6G，性能测试结果：平均响应时间为 200ms， 并发用户为 300 个，TPS 为 1500.为了满足未来发展的需要，系统的生产环境需要配备多台服务器， 如：4 台。 我发表一下对性能调优的一些看法，我觉得需要从以下几个方面着手做： 1.通讯1.首先说一下通讯，通讯层面需要采取异步线程通讯模式，比如 socket nio 异步线程通讯模式， 此模式有负责接收消息的线程，有负责处理消息的线程，流水线模式分工协作。常使用的模式 Tomcat6.0 版本以后对 8080 端口的通讯监，在听就是采用的 socket nio 异步模式。2.还需要提一下另外一种使用场景，在通讯层面采用队列（比如 activemq）或者缓存 （redis）。例如处理秒杀场景，并发量大，先将所有请求接收放入队列或者缓存，然后从队列或者 缓存中获取部分请求处理，处理完一部分再获取一部分处理，直到秒杀结束（即库存不足）。如果 秒杀结束，队列中还有消息未处理，那么将这些消息全部返回客户端，返回商品已售完。

2.应用集群部署 应用的集群部署，我们项目是采用 ngnix 做反向代理，将用户请求分法到集群环境中的不同服 务器，降低了单个服务器的压力，起到负载均衡的作用，同时，他带来了很多其他好处，比如：增 加系统的并发处理能力，可以处理更多的用户请求；防止出现因谋呔服务器宕机而导致业务中断的 单点故障，因为某台服务器出现故障时，ngnix 反向代理会做到自动隔离该服务器，不再请求转发 到宕机的服务器；可做到热部署，在上线过程中选择部分服务器重启，保证业务不间断进行。

3.缓存缓存，我们项目采用 redis 做缓存服务器，将查询多修改少的数据放入缓存（比如：产品列表 啊），页面显示产品列表时直接从缓存中获取，无需通过数据查询，减少 IO 操作，大大提高了查 询的速度，同时也减轻了对数据库的压力。

4.资源动静分离 资源动静分离，项目里面如果存在大量的 js、css、html 图片等静态资源，需要将这些静态资源 单 独 部 署 到 服 务 器 （ 比 如 ： 阿 里 的 CDN ） ， 然 后 通 过 远 程 连 接 地 址 （ 比 如 ： http://192.168.2.1:8080/picture/dog.jpg）访问，可提高页面加载速度，同时减轻应用服务器的压力。

5.数据库集群（OraceRac） 数据库集群部署，可防止数据库访问应用的单点故障，减轻数据库访问压力，我们公司 dba 工 程师户将 oracle 部署为集群的 rac 模式，用到两台服务器安装数据库，两台服务器的数据库存储在 同一块共享磁盘。

6.SOA 服务优化 Soa 服务优化，公司采用了 dubbo 分布式框架，系统之家的接口调用通过 dubbo，比如我们项 目调用财务系统的支付接口，该接口就是由财务系统将地址发布到 dubbo，然后我们写 http 客户端 去调用 dubbo，有 dubbo 将请求转发财务系统。

二、数据库优化 关于数据库优化需要从三个方面考虑：

1.数据存储分区 2.表索引 3.SQL 语句优化 1.数据存储分区：我们的财险系统，购买保险的用户来自不同的地区，考录到保单数量可能接近上 亿条，单纯的位表建立索引不能满足性能的需要，因此保单表按省份做了列表分区，使不同省的保 单存储到不同的数据分区，当查询数据加上省份条件是，只会检索对应分区的数据，大大缩小了数 据检索的范围，从而提高查询性能。【备注：每个项目组按照自己项目的实际分区情况举例说明】。 分区还有：范围分区（比如按照日期字段来建立分区，一个季度或者一个月的数据划分为一个区） 散列分区（不指定分区条件，oracle 自动将数据平均分配）符合分区（比如：做了分区和，每个分 区里面再次做分区）。 2.表索引，为表建立好分区以后，在分区里面添加索引，进一步提高数据的查询速度，我们项目里 用到的所有比如（客户信息表 姓名建立 btree 索引、身份证号建立唯一索引、客户编号建立主键， 主键自带唯一索引）（产品表 产品列表建立位图索引（经常用到的表关联条件建立索引）【备注： 按照自己项目建立索引的实际情况举例说明】。 索引之所以会提高查询速度，我大概介绍一下它的原理，索引有一套独立的系统表存储数据与 rowid 的对应关系（如书本的目录），比如 btree 索引，它是一个树形结构图，有根节点、分支节点、叶 子节点、根节点只有一个，分支节点数量不固定有 oracle 合理分配，分支节点存储数据的范围，最 终的分支节点下面有叶子节点，叶子节点负载存储具体的值和 rowid。比如：根节点存储大于 50 和 小于 50 两个范围，两个分支节点，大于 50 的分支节点存储 50-60、60-70、大于 100 等区段，每个 区段都有对应的叶子节点，比如大于 100 的区段下面的叶子节点存储 100、101、102 和对应的 rowid 等具体数据 100、101、102 的值即为表中建立索引的列（比如：num）的值，当编写 sql 语句 wherenum=101 时，救护通过检索索引表，查询到叶子节点上存储的 rowid，然后根据 rowid 查询对应的 数据，避免了对数据表的全部扫描。

当然，索引也不是越多越好，索引适合建立在经常作为条件的列（即 where 后作为条件的列，包括 关联条件）、以及 order by 的列。如果对于增删改性能要求特别高而查询要求的表就不建议建立索 引了，因为索引会降低增删改的效率。

3.SQL 语句优化 1.对查询进行优化，要避免全表扫描，首先应考虑在 where 及 order by 设计的列上建立索引。

2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引起放弃使用索引二进行全表扫 描。

3.最后不要给数据库留 NULL，尽可能的使用 NOT NULL 填充数据库，备注、描述、评论之类的可以 设置 BULL，其他的，最好不要使用 NULL。 不要以为 NULL 就不需要空间，比如：char（100）型，在字段建立时，空间就固定了，不管是否插 入值（NULL 也包含在内），都是要占用 100 个字符的空间的，如果是 varchar 这样的变长字段，null 不占用空间。可以在 num 上设置默认值 0，确保表中 num 列没有 null 值。

4.应尽量避免在 where 子句中使用！=或<>操作符，否则引擎将放弃使用索引而进行全表扫描

5.应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导 致引擎放弃使用索引而进行全表扫描。

6.in 和 not in 也要慎用，否则会导致全表扫描，对于连续的数字，能用 between 就不要用 in 了，很 多时候用 exists 代替 in 是一个号的选择。

7.如果在 where 子句中使用参数，也会导致全表扫描。因为 SQL 只有在运行时才会解析局部变量， 但优化程序不能将访问计划的选择推迟到运行时，它必须在编译时进行选择。然而，如果在编译时 建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。

8.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。

9.应尽量避免在 where 子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描， 除非建立函数索引。

10.不要在 where 子句中的“=”左边进行函数、算数运算或其他表达式运算，否则系统将可能无法 正确使用索引。

11.Update 语句，如果只更改 1、2 个字段，不要 Update 全部字段，否则频繁调用会引起明显的性 能消耗，同时带来大量日志。

12.对于多张大数据量（这里几百条就算大了）的表 JOIN，要先分页再 JOIN，否则逻辑读会很高， 性能很差。

13.索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 是有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而 定。一个表的索引书最好不要超过 6 个，若太多则应考虑一些不常使用的列上建的索引是否有必要。

14.尽量使用数字型字段，若致函数值信息的字段尽量不要涉及为字符型，这会降低查询和连接的 性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而 对于数字型而言只需要比较一次就够了。

15.尽可能的使用 varvhar/nvarchar 代替 char/nchar，因为首先变长字段存储空间小，可以节省存储 空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。

16.任何地方都不要使用 select * from t，具体的字段列表代替“*”，不要返回用不到的任何字段。. 17.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。