一、基础部分
01. 为什么要在一个团队中开展软件测试工作？
在团队中开展软件测试工作，是因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。
软件质量的好坏直接影响消费者的利益，所以优秀的软件一定要经过测试后，才能上市。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。
02. 您是否了解以往所工作的企业的软件测试过程？如果了解，请试述在这个过程中都有哪些工作要做？分别由哪些不同的角色来完成这些工作？
需求分析——需求评审——测试方案——测试计划——测试设计（测试用例编写，测试数据准备）——测试执行（接口测试，单元测试，集成测试，系统测试，回归测试）
——测试bug提交——测试bug跟踪——测试报告（阶段性报告，总结性报告）——关闭测试；
03. 您是否了解以往所工作的企业的软件开发过程？如果了解，请试述一个完整的开发过程需要完成哪些工作？分别由哪些不同的角色来完成这些工作？（对于软件测试部分，可以简述）
1 开发流程
▪ 需求分析
▪ 概要设计
▪ 详细设计
▪ 编码
▪ 测试
▪ 软件交付
▪ 验收
▪ 维护
2 软件维护
3 软件升级
04. 您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？
05. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）
负载测试(Load testing)，通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。
在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。
负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征。
例如，响应时间、事务处理速率和其他与时间相关的方面。
06. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。
白盒测试：
总体上分为静态方法和动态方法两大类。
静态：关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。
动态：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
集成测试：
执行阶段
1)时间安排 单元测试已经完成后就可以开始执行集成测试了
2)输入 需求规格说明书 概要设计 集成测试计划 集成高度设计 集成测试例 集成测试规程 集成测试代码(如果有)
集成测试脚本 集成测试工具 详细设计 代码 单元测试报告
3)入口条件 单元测试阶段已经通过基线化评审
4)活动步骤 执行集成测试用例 回归集成测试用例 撰写集成测试报告
5)输出 集成测试报告
6)出口条件 集成测试报告通过集成测试阶段基线评审
验收测试：
验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
07. 测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？
08. 您认为做好测试计划工作的关键是什么？
09. 您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
10. 您认为做好测试用例设计工作的关键是什么？
11. 请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程。
12. 您以往的工作中是否曾开展过测试用例的评审工作？如果有，请描述测试用例评审的过程和评审的内容。
13. 您以往是否曾经从事过性能测试工作？如果有，请尽可能的详细描述您以往的性能测试工作的完整过程。
14. 您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
15. 您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？
16.在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
17.您以往所从事的软件测试工作中，是否使用了一些工具来进行软件缺陷（Bug）的管理？如果有，请结合该工具描述软件缺陷（Bug）跟踪管理的流程。
18.您以往是否曾今从事过单元测试和集成测试？如果有，请谈一下这些工作的实际开展情况。
19.您如何看待软件过程改进？在您曾经工作过的企业中，是否有一些需要改进的东西呢？您期望的理想的测试人员的工作环境是怎样的？
20.您以往工作的企业中，是否开展了软件配置管理工作？您能否描述一下这项工作的开展情况和您对这项工作的认识？
21.您是否熟悉一些主流的软件工程方法论和思想，如RUP、CMM、CMMI、XP，PSP，TSP。如果熟悉，您是否可以谈一下对这些方法论和思想的认识？
22、在您以往的测试工作中,最让您感到不满意或者不堪回首的事情是什么?您是如何来对待这些事情的？
23、在即将完成这次笔试前,您是否愿意谈一些自己在以往的学习和工作中获得的工作经经验和心得体会?(可以包括软件测试、过程改进、软件开发或者与此无关的其他方面)
http://www.doc88.com/p-070194919290.html
https://wenku.baidu.com/view/f8d59cfcf705cc1755270902.html
测试主管面试题
1、为什么要划分软件的缺陷等级,如果可以,您来划分,遵循什么原则
--致命错误（致命的错误，造成系统崩溃、死机，或造成数据丢失、主要功能完全丧失等。）
--严重错误（指功能模块或特性没有实现，主要功能部分丧失）
--一般错误（不太严重的错误，如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。）
--轻微错误（一些小问题如有个别错别字、文字排版不整齐等，对功能几乎没有影响，软件产品仍可使用。）
2、软件生命周期
1 简介
2 阶段
2.1 问题的定义及规划
2.2 需求分析
2.3 软件设计
2.4 程序编码
2.5 软件测试
2.6 运行维护
3 周期模型
3.1 瀑布模型
3.2 迭代式模型
3.3 快速原型模型
3.4 螺旋模型 ）
3、没有任何文档,怎样开展测试工作、如何管理测试工作?
1、没有需求文档，找别的文档；
需求文档可能由于时间原因暂时无法获取，那就尽量的去获取其他的文档吧，比如开发的一些设计文档---概要设计、功能设计、详细设计等等。
如果开发连这些文档都没有，那么可以去网上查询同类产品的一些规格说明书，幸运的话，也许能down到别人类似产品的一些需求说明。这些材料虽然
不是自己产品的需求说明，但是因为是同类产品，功能方面也总会有8、9分类似，所以研究别人的产品，自然也就会对自己产品有了几分
把握
2、模块定位和划分；
如果开发有详细的设计文档，那么就按照开发的设计，将产品按照功能模块迅速简捷的先进行模块划分。如果没有开发文档，那就要跟开发沟通， 让他们
简单介绍一下产品的功能模块并自己试用后对产品进行模块划分。模块划分后，组内分工合作，进行探索性测试同时不断完善测试计划和测试需求，因为
前期概要的了解产品绝对不可能一次到位的对各个模块划分准确的。
3、测试方法
如果没有需求文档，测试用例的编写肯定没有参照。所以测试过程中测试用例的设计不可能非常详细，在有了1、2的调研、 研究产品的基础后，可以设
计一些简单的场景测试、流程测试用例，按照这些用例测试的过程中，必然会发现各种各样的问题，同时对产品也会不断熟悉。测试用例 的编写可以放
在一个轮次的测试完成后进行补充编写，然后在以后的测试过程中不断完善。 由于没有需求文档的情况下，想要先详细的设计出测试用例再进行测试
由于没有需求文档的情况下，想要先详细的设计出测试用例再进行测试是不太现实的，只能 简单的进行用例设计后，确定大概的测试方向，然后在测试过程
中不断完善测试用例才行。
这种先测试后完善测试用例的方式必须 是针对一个周期较长且需要做回归测试的项目，如果一个项目周期很短，且完成后不需要进行回归，那么这种方法并
不是太理想，因为用例完成了却利用率不高，只 能作为后期参考,以及对后来新人的一个培训和积累公共测试用例的途径（不过对于项目本身来说，用处不太
大咯），从公司和项目角度来说，实际投入成本是增大了而这些投入的产出又比较小。
项目进度
测试进度：前期分析，执行测试，用例补充，执行测试，用例补充 结束测试
4、您在以往的测试工作中都曾经具体从事过哪些工作?其中最擅长哪部分工作?（简约回答）
1、在以往的测试工作中，从事过部署测试环境，组装过电脑；
2、测试过Windows系统下的软件，Linux系统下的软件，安卓和iOS系统下的APP以及web和数据库方面的测试；
3、测试过程涵盖功能测试，自动化测试，性能测试；
4、当过测试主管
最擅长于功能和性能测试以及测试主管工作，正在不断提高自动化测试技能
5、您认为测试用例由测试员写,还是主管写?
功能测试用例一般由测试人员来写，接口和性能测试用例由主管来写。用例编写完后都是需要先测试组内部评审，再与开发人员以及产品部一起评审
6、请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别；
这些测试的范围正好是逐步递增的关系，但是测试的人员角色是不同的
黑盒测试、白盒测试、单元测试：开发人员分在不同的开发阶段要做的事情
黑盒测试、集成测试、系统测试：测试人员在测试周期内级层做的工作，当然也可以参与单元测试中去，比如接口测试；
验收测试：一般是在用户方做的工作
7、您在从事性能测试工作时,是否使用过一些测试工具?如果有,请试述该工具的工作原理。
jmeter的工作原理：建立一个线程池，多线程运行取样器产生大量负载，在运行过程中通过断言来验证结果的正确性，通过监听器来记录测试结果。
如果取样器中有参数化需求，可以通过配置元件或者前置处理器来完成；
如果取样器中有关联需求，可以通过后置处理器来完成；
如果要模拟负载场景，比如模拟多少用户，运动多长时间，可以通过线程组完成；
如果要模拟并发场景，可以通过定时器来完成；
如果要控制业务的执行逻辑，比如登录只运行一次，可以通过控制器来完成；
8、您以往是否曾经从事过性能测试工作?如果有,请尽可能的详细描述您以往的性能测试工作的完整过程。
https://www.cnblogs.com/imyalost/p/6854479.html性能测试：一个完整的性能测试过程
一、准备工作
1、系统基础功能验证
性能测试在什么阶段适合实施？切入点很重要！一般而言，只有在系统基础功能测试验证完成、系统趋于稳定的情况下，才会进行性能测试，否则性能测试是无意义的。
2、测试团队组建（测试人员确定）
根据该项目的具体情况，组建一个几人的性能测试team，其中DBA是必不可少的，然后需要一至几名系统开发人员（对应前端、后台等），还有性能测试设计和分析
人员、脚本开发和执行人员；在正式开始工作之前，应该对脚本开发和执行人员进行一些培训，或者应该由具有相关经验的人员担任。
3、工具的选择
综合系统设计、工具成本、测试团队的技能来考虑，选择合适的测试工具，最起码应该满足以下几点：
①支持对web（这里以web系统为例）系统的性能测试，支持http和https协议；
②工具运行在Windows平台上；
③支持对webserver、前端、数据库的性能计数器进行监控；
4、预先的业务场景分析
为了对系统性能建立直观上的认识和分析，应对系统较重要和常用的业务场景模块进行分析，针对性的进行分析，以对接下来的测试计划设计进行准备。
二、测试计划
测试计划阶段最重要的是分析用户场景，确定系统性能目标。
1、性能测试领域分析
根据对项目背景，业务的了解，确定本次性能测试要解决的问题点；是测试系统能否满足实际运行时的需要，还是目前的系统在哪些方面制约系统性能的表现，或者
哪些系统因素导致系统无法跟上业务发展？确定测试领域，然后具体问题具体分析。
2、用户场景剖析和业务建模
根据对系统业务、用户活跃时间、访问频率、场景交互等各方面的分析，整理一个业务场景表，当然其中最好对用户操作场景、步骤进行详细的描述，为测试脚本开
发提供依据。
3、确定性能目标
前面已经确定了本次性能测试的应用领域，接下来就是针对具体的领域关注点，确定性能目标（指标）；其中需要和其他业务部门进行沟通协商，以及结合当前系统
的响应时间等数据，确定最终我们需要达到的响应时间和系统资源使用率等目标；比如：
①登录请求到登录成功的页面响应时间不能超过2秒；
②报表审核提交的页面响应时间不能超过5秒；
③文件的上传、下载页面响应时间不超过8秒；
④服务器的CPU平均使用率小于70%，内存使用率小于75%；
⑤各个业务系统的响应时间和服务器资源使用情况在不同测试环境下，各指标随负载变化的情况等；
4、制定测试计划的实施时间
预设本次性能测试各子模块的起止时间，产出，参与人员等等。
三、测试脚本设计与开发
性能测试中，测试脚本设计与开发占据了很大的时间比重。
1、测试环境设计
本次性能测试的目标是需要验证系统在实际运行环境中的性能外，还需要考虑到不同的硬件配置是否会是制约系统性能的重要因素！因此在测试环境中，需要部署多个不同的测试环境，
在不同的硬件配置上检查应用系统的性能，并对不同配置下系统的测试结果进行分析，得出最优结果（最适合当前系统的配置）。
这里所说的配置大概是如下几类：
①数据库服务器
②应用服务器
③负载模拟器
④软件运行环境，平台
测试环境测试数据，可以根据系统的运行预期来确定，比如需要测试的业务场景，数据多久执行一次备份转移，该业务场景涉及哪些表，每次操作数据怎样写入，写入几条，需要多少的
测试数据来使得测试环境的数据保持一致性等等。
可以在首次测试数据生成时，将其导出到本地保存，在每次测试开始前导入数据，保持一致性。
2、测试场景设计
通过和业务部门沟通以及以往用户操作习惯，确定用户操作习惯模式，以及不同的场景用户数量，操作次数，确定测试指标，以及性能监控等。
3、测试用例设计
确认测试场景后，在系统已有的操作描述上，进一步完善为可映射为脚本的测试用例描述，用例大概内容如下：
用例编号：查询表单_xxx_x1（命名以业务操作场景为主，简洁易懂即可）
用例条件：用户已登录、具有对应权限等。。。
操作步骤：
①进入对应页面。。。。。。
②查询相关数据。。。。。。
③勾选导出数据。。。。。。
④修改上传数据。。。。。。
PS：这里的操作步骤只是个例子，具体以系统业务场景描述；
4、脚本和辅助工具的开发及使用
按照用例描述，可利用工具进行录制，然后在录制的脚本中进行修改；比如参数化、关联、检查点等等，最后的结果使得测试脚本可用，能达到测试要求即可；
PS：个人而言，建议尽量自己写脚本来实现业务操作场景，这样对个人技能提升较大；一句话：能写就绝不录制！！！
四、测试执行与管理
在这个阶段，只需要按照之前已经设计好的业务场景、环境和测试用例脚本，部署环境，执行测试并记录结果即可。
1、建立测试环境
按照之前已经设计好的测试环境，部署对应的环境，由运维或开发人员进行部署，检查，并仔细调整，同时保持测试环境的干净和稳定，不受外来因素影响。
2、执行测试脚本
这一点比较简单，在已部署好的测试环境中，按照业务场景和编号，按顺序执行我们已经设计好的测试脚本。
3、测试结果记录
根据测试采用的工具不同，结果的记录也有不同的形式；现在大多的性能测试工具都提供比较完整的界面图形化的测试结果，当然，对于服务器的资源使用等情
况，可以利用一些计数器或
第三方监控工具来对其进行记录，执行完测试后，对结果进行整理分析。
五、测试分析
1、测试环境的系统性能分析
根据我们之前记录得到的测试结果（图表、曲线等），经过计算，与预定的性能指标进行对比，确定是否达到了我们需要的结果；如未达到，查看具体的瓶颈
点，然后根据瓶颈点的具体数据，
进行具体情况具体分析（影响性能的因素很多，这一点，可以根据经验和数据表现来判断分析）。
2、硬件设备对系统性能表现的影响分析
由于之前设计了几个不同的测试环境，故可以根据不同测试环境的硬件资源使用状况图进行分析，确定瓶颈是再数据库服务器、应用服务器抑或其他方面，然
后针对性的进行优化等操作。
3、其他影响因素分析
影响系统性能的因素很多，可以从用户能感受到的场景分析，哪里比较慢，哪里速度尚可，这里可以根据258原则对其进行分析；
至于其他诸如网络带宽、操作动作、存储池、线程实现、服务器处理机制等一系列的影响因素，具体问题具体分析，这里就不一一表述了。
4、测试中发现的问题
在性能测试执行过程中，可能会发现某些功能上的不足或存在的缺陷，以及需要优化的地方，这也是执行多次测试的优点。
9、请阐述性能测试loadrunner的关联、参数化、集合点、事务含义。
很久以前了解过loadrunner，我的理解如下：
关联：关联是确定要捕获的数据；
参数化：在脚本中用参数取代常量值
集合点：用于模拟多用户并发操作的一种技术手段
事物：引入事务是为了度量响应时间
10、您以前工作时的测试流程是什么
11、一台计算机的IP是192.168.10.71子网掩码255.255.255.0与192.168.10.201是同一局域
比如子网掩码：11111111.11111111.11111111.10000000（255.255.255.128）
其中IP地址左边与子网掩码“1”的部分对应的都是网络号。网络号部分必须是“1”
11111111.11111111.1111111.11000000（255.255.255.192）这是另一个子网掩码，子网掩码的作用就是看有多少个“1”，而且规定必须是连续的。这个“1”
并不是真实的值。
如果：一台计算机的IP是192.168.10.71，子网掩码255.255.255.128与 192.168.10.201是否是同一局域网，分析过程
那么不在一个局域网
子网掩码11111111.11111111.11111111.10000000（255.255.255.128）
ip地址：最后8位是 71=01000111,
201=11001001
最后8为最左边的1位一个是“0”，一个是“1”，值不同，网络号不同，所以不是一个局域网
12、进程,线程的定义及区别
定义：
进程：是程序运行的实例，是系统进行资源分配和调度的一个独立单位，它包括独立的地址空间，资源以及1个或多个线程。
线程：可以看成是轻量级的进程，是CPU调度和分派的基本单位。
区别：
1.调度 ：从上面的定义可以看出一个是调度和分派的基本单位，一个是拥有资源的基本单位
2.共享地址空间，资源：进程拥有各自独立的地址空间，资源，所以共享复杂，需要用IPC，同步简单； 线程共享所属进程的资源，共享简单，但同步复杂，要通过加锁等措施。
3.占用内存，cpu: 进程占用内存多，切换复杂，CPU利用率低； 线程占用内存少，切换简单，CPU利用率高。
4.相互影响： 进程间不会相互影响； 一个线程挂掉会导致整个进程挂掉。
15、4,4,10,10算24,加减乘除都可以.
（10×10－4）/4＝96/4=24
sql：
SQL Server中，如果目标表存在：
insert into 目标表 select * from 原表;
SQL Server中,，如果目标表不存在：
select * into 目标表 from 原表;
SELECT * FROM server ORDER BY serverID desc(降序)
SELECT * FROM server ORDER BY serverID asc(升序)默认升序
https://zhidao.baidu.com/question/208011646.html
软件测试 在三角形计算中,要求三角型的三个边长：A、B 和C.当三边不可能构成三角形时提示错误
要求：
分别用“白盒法”和“黑盒法”进行测试.
要求：（1）画出程序的流程图
（2）给出测试用例
（3）对程序进行测试,包括输入/输出,测试结果
（4）保留测试结论
（5）给出测试结论
将以上“要求”整理成一份测试报告（格式参照所给范文撰写）并打印,电子稿发到我邮箱,纸质的16周星期五第5节课交,过期没有成绩.
提示：
白盒测试：用例 路径 循环都要写
黑盒测试：边界值 等价类
测试用例中要写出预期结果
报告中写出实际结果
统计通过的用例比例
写出结论
在三角形计算中,要求三角型的三个边长：A、B 和C.当三边不可能构成三角形时提示错误,可构成三角形时计算三角形周长.若是等腰三角形打印“等腰三角形”,若
是等边三角形,则提示“等边三角形”.题目没有发完,
一、等价类划分：三角形三条边A、B、C的数据类型不同
二、边界值分析：由于三角形的边长可以是正整数或正小数,所以就不对长度进行测试,那么边界值分析就不用了
三、因果图法：三角形的三条边数据输入组合
我们看一下三角形的流程图：
我们再分析一下三角形的等价类：
有效等价类：
输入3个正整数或正小数：
1、两数之和大于第三数,如A0) (3)
(A+B>C) (4)
(B+C>A) (5)
(C+A>B) (6) (A
参考：
https://www.cnblogs.com/zjd2626/p/6692350.html