一、技术类

测试业务类

1.请问测试开发需要哪些知识，需要具备什么能力

软件测试基础理论知识，如黑盒测试、白盒测试等；
编程语言基础，如 C/C++、java、python 等；
自动化测试工具，如 Selenium、Appium、Robotium 等；
计算机基础知识，如数据库、Linux、计算机网络等； 测试框架，如 JUnit 等。
需要具备的能力： 业务分析能力，分析整体业务流程、分析被测业务数据、分析被测系统架构、分析被测业务模块、分析测试所需资源、分析测试完成目标；
缺陷洞察能力，一般缺陷的发现能力、隐性问题的发现能力、发现连带问题的能力、发现问题隐患的能力、尽早发现问题的能力、发现问题根源的能力；
团队协作能力，合理进行人员分工、协助组员解决问题、配合完成测试任务、配合开发重现缺陷、督促项目整体进度、出现问题勇于承担； 专业技术能力，掌握测试基础知识、掌握计算机知识、熟练运用测试工具；
逻辑思考能力，判断逻辑的正确性、对可行性逻辑分析、站在客观角度思考；
问题解决能力，技术上的问题、工作中的问题、沟通问题； 沟通表达能力，和技术人员、产品人员、上下级的沟通；
宏观把控能力，有效控制测试时间、有效控制测试成本、有效制定测试计划、有效进行风险 评估、有效控制测试方向。

2.你觉得软件测试的核心竞争力是什么

测试人员的核心竞争力在于提早发现问题，并能够发现别人无法发现的问题。

①早发现问题：问题发现的越早，解决的成本越低。如果一个需求在还未实现的时候就能发现需求的漏洞，那么这种问题的价值是最高的。

②发现别人无法发现的问题：所有人都能发现的问题，你发现了，那就证明你是可以被替代的。别人发现不了，而你可以发现，那么你就是无法被替代。

3.给你一个网站，你如何测试

①首先，查找需求说明、网站设计等相关文档，分析测试需求。
②制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试
③设计测试用例
    功能性测试
        链接测试：链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回；
        提交功能的测试；
        多媒体元素是否可以正确加载和显示；
        多语言支持是否能够正确显示选择的语言等。
    界面测试
        页面是否风格统一，美观
        页面布局是否合理，重点内容和热点内容是否突出
        控件是否正常使用
        对于必须但未安装的控件，是否提供自动下载并安装的功能
        文字检查
    性能测试
        压力测试；负载测试；强度测试
    数据库测试
        具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。
    安全性测试
        基本的登录功能的检查
        是否存在溢出错误，导致系统崩溃或者权限泄露
        相关开发语言的常见安全性问题检查，例如SQL注入等
        如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持
    兼容性测试
        浏览器的兼容性；
        操作系统的兼容性；
        软件平台的兼容性；
        数据库的兼容性
④开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。
⑤定期评审，对测试进行评估和总结，调整测试的内容。

4.如何测试一个纸杯

功能度：用水杯装水看漏不漏；水能不能被喝到
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

5.你认为做好测试计划工作的关键是什么

1. 明确测试的目标，增强测试计划的实用性；
2. 软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确。坚持“5W”规则，明确内容与过程： “5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）；
3. 采用评审和更新机制，保证测试计划满足实际需求。测试计划完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
4. 分别创建测试计划、测试详细规格与测试用例，应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

6.请说出这些测试最好由那些人员完成，测试的是什么

代码、函数级测试一般由白盒测试人员完成，他们针对每段代码或函数进行正确性检验，检查其是否正确的实现了规定的功能。
模块、组件级测试主要依据是程序结构设计测试模块间的集成和调用关系，一般由测试人员完成。
系统测试在于模块测试与单元测试的基础上进行测试。了解系统功能与性能，根据测试用例进行全面的测试。

7.您以往的工作中是否曾开展过测试用例的评审工作?如果有，请描述测试用例评审的过程和评审的内容

    评审计划->预审->评审;
    评审内容主要是测试用例对软件需求的覆盖程度，对于相关边界是否考虑，是否针对复杂流程准备多套测试数据，是否有专门针对非功能性需求的测试

8.需求测试的注意事项有哪些

是否使用了公司的模板、文档内容是否符合规范、所有的需求是分级是否清晰适当、所有的需求是否具有一致性、需求是否可行（即，该需求组合有解决方案）、需求可否用己知的约束来实现、需求是否足够（即，可以把它送到一个规范的开发组织，并有一个生产出所需要产品的合理的可能性）、所有的其它需求是交叉引用是否正确、用户描述是否清楚、是否用客户的语言来描述需求、每个需求描述是否清楚没有岐义，可以移交给一个独立的组去实现时也能理解、是否所有的需求都是可验证的、是否每条需求都具有独立性，即使发生了变化也不会影响其它需求、性能指标是否明确、非功能性需求是否得到充分表现、是否完整列出适用的标准或协议、标准和协议之间是否存在冲突。

9.软件的安全性应从哪几个方面去测试

安全测试：检查产品是否符合安全需求及产品质量标准的过程。安全测试通常是站在开发者的角度来提供解决方案的，以发现程序的安全隐患为目标。主要测试客户端、服务器及应用、数据库和网络传输的相关漏洞等。如应用相关的的认证、授权、管理接口、程序逻辑、输入验证等 。比如：
用户认证安全的测试要考虑问题： 明确区分系统中不同用户权限 、系统中会不会出现用户冲突 、系统会不会因用户的权限的改变造成混乱 、用户登陆密码是否是可见、可复制 、是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）、用户退出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统 、系统网络安全的测试要考虑问题 、测试采取的防护措施是否正确装配好，有关系统的补丁是否打上 、模拟非授权攻击，看防护系统是否坚固 、采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一下，现在最常用的是 NBSI 系列和 IPhacker IP ） 、采用各种木马检查工具检查系统木马情况 、采用各种防外挂工具检查系统各组程序的外挂漏洞
数据库安全考虑问题： 系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）、系统数据的完整性（我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整，对于这个系统的功能实现有了障碍） 、系统数据可管理性 、系统数据的独立性 、系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）

10.什么是测试用例 什么是测试脚本 两者的关系是什么

为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。
测试脚本是为了进行自动化测试而编写的脚本
测试脚本的编写必须对应相应的测试用例

11.在windows下保存一个文本文件时会弹出保存对话框，如果为文件名建立测试用例，等价类应该怎样划分

单字节，如A；双字节， AA、我我；特殊字符 /‘。‘；、=-等；保留字，如com；文件格式为8.3格式的；文件名格式为非8.3格式的；/,\,*等九个特殊字符。

12.什么是兼容性测试？请举例说明如何利用兼容性测试列表进行测试

主要验证软件产品在不同版本之间的兼容性。包括向下兼容和交错兼容，向下兼容是测试软件新版本保留它早期版本功能的情况，交错兼容是验证共同存在的两个相关但不相同的产品之间的兼容性

13.测试设计如何保证需求覆盖率

全面测试需求分析、从业务与技术角度设计用例，不仅仅要考虑到当前需求的可行性、发散性思考与之相关的需求点。同时其他流程也要遵循相关行业与业务规范等等。

14.一般缺陷都有哪些类型

需求、数据、逻辑、性能、功能、安全、兼容、变更、易用等。

15.测试计划有哪些内容

产品测试背景、测试资源分配、测试策略、风险应对措施、测试方法、测试工具、测试周期、测试参考资料

16.如何应对需求变更

（1）测试人员需要非常精通需求，了解每个需求变更背后的原因

（2）通过计算需求变更产生的收益与成本来提供合理建议

（3）测试设计时从粗到细，防止需求变更导致的大量返工

（4）抽离通用的功能用例库

17.对于不可重现的缺陷如何处理

不可忽视，及时记录当前的操作步骤与测试数据，并截取相关的日志片断以提供证据。同时可以与其他成员分享此缺陷，建议大家集思广益，在测试过程中有意重现。如果产品即将上线，同时分析出该缺陷对产品用户的影响程度现。若仍无法重现，可以暂时挂起，同时记录进缺陷库，后续跟踪。

18.移动端测试要点（app、小程序、公众号、移动WEB）

功能（界面、与通常功能）、性能（耗电量、流量、资源占用）、安全（启动、退出、自动更新、手动更新、应用内外跳转、权限控制）、硬件相关设计（传感器、手机访问权限、不同机型兼容测试）、软件环境相关设计（网络环境切换、应用外切换）

19.针对微信的聊天窗口设计测试用例

首先，了解完成业务需求后，转化为测试需求，最终的测试需求一定是跟项目组评审通过的。
开始设计：
冒烟用例：实现最简单的聊天功能（语音、文字形式）
功能业务：
纯文字聊天
语音聊天
表情
组合发送聊天
特殊字符及组合
发送文件
查看聊天记录
截屏功能
视频聊天
实时语音聊天
不同版本间的切换功能
客户化场景分解
异常场景分解

兼容性测试用例：
一般在业务需求中会定义好
在测试需求中可以分解好对应的机型与系统版本，求得最优最小组合，用于兼容性测试的用例。

安全测试用例
性能测试用例
（一般都有独立的测试方案）

回归测试用例：
抽取用例库中的核心用例组合成回归用例 。

20.登录页面测试用例设计方法

具体需求： 有一个登陆页面， （假如上面有2个textbox， 一个提交按钮。 请针对这个页面设计30个以上的testcase。）
此题的考察目的：面试者是否熟悉各种测试方法，是否有丰富的Web测试经验， 是否了解Web开发，以及设计Test case的能力。

首先，你要了解用户的需求，比如这个登录界面应该是弹出窗口式的，还是直接在网页里面。对用户名的长度，和密码的强度（就是是不是必须多少位，大小写，特殊字符混搭）等。还有比如用户对界面的美观是不是有特殊的要求？（即是否要进行UI测试）。剩下的就是设计用例了 ，等价类，边界值等等。

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

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

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

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

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

兼容性测试（Compatibility Test）
　　1.主流的浏览器下能否显示正常已经功能正常（IE，6，7，8，9， Firefox， Chrome， Safari，等）
　　2.不同的平台是否能正常工作，比如Windows， Mac
　　3.移动设备上是否正常工作，比如Iphone， Andriod
　　4.不同的分辨率

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

软件辅助性测试 （Accessibility test）
　　软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能
　　1. 高对比度下能否显示正常 （视力不好的人使用）

21.对搜索和查询设计测试用例

22.给日期格式设计测试用例

23.对输入框设计测试用例

24.对数字输入框设计测试用例

25.对密码输入框设计测试用例

26.对 上传图片/上传文件 浏览/选择按钮 设计测试用例

27.对数据导入设计测试用例

28.对文件的导出或下载（考虑文件名是否有乱码内容）设计测试用例

29.对分页功能设计测试用例

30.对 全选 功能测试测试用例

31.对删除功能设计测试用例

32.对保存功能设计用例

33.对修改功能设计用例

34.对 添加 功能设计用例

35.对邮箱格式设计测试用例

36.对身份证号码设计测试用例

37.对电话号码设计用例

38.对手机号设计测试用例

39.对邮政编码设计用例

40.对注册功能设计用例

41.登录功能

42.ip地址

43.你们之前做的接口自动化测试是什么测试方案？

之前测试团队中优先搭建的框架是UI自动化测试框架，使用框架SELENIUM+TESTNG+ANT+JAVA+SVN+JENKINS ，接口测试一直是单接口的手工测试。而UI自动化测试也是为了解决回归测试与兼容性测试的重复问题。

技能类

1.请你说一说 PC 网络故障，以及如何排除障碍

(1)首先是排除接触故障，即确保你的网线是可以正常使用的。然后禁用网卡后再启用，排除偶然故障。打开网络和共享中心窗口，单击窗口左上侧“更改适配器设置”右击其中的“本地连接“或”无线网络连接”，单击快捷菜单中的“禁用”命令，即可禁用所选网络。接下来重启网络，只需右击后单击启用即可。
(2)使用 ipconfig 查看计算机的上网参数
1、单击“开始|所有程序|附件|命令提示符“，打开命令提示符窗口 2、输入 ipconfig，按 Enter 确认，可以看到机器的配置信息，输入 ipconfig/all,可以看到 IP地址和网卡物理地址等相关网络详细信息。
(3)使用 ping 命令测试网络的连通性，定位故障范围在命令提示符窗口中输入”ping 127.0.0.1“，数据显示本机分别发送和接受了 4 个数据包， 丢包率为零，可以判断本机网络协议工作正常，如显示”请求超时“，则表明本机网卡的安装或 TCP/IP 协议有问题，接下来就应该检查网卡和 TCP/IP协议，卸载后重装即可。
(4)ping 本机 IP 在确认 27.0.0.1 地址能被 ping 通的情况下，继续使用 ping 命令测试本机的 IP 地址能否被 ping 通，如不能，说明本机的网卡驱动程序不正确，或者网卡与网线之间连接有故障，也有可能是本地的路由表面收到了破坏，此时应检查本机网卡的状态是否为已连接，网络参数是否设置正确，如果正确可是不能 ping 通，就应该重新安装网卡驱动程序。丢失率为零，可以判断网卡安装配置没有问题，工作正常。
(5)ping 网关网关地址能被 ping 通的话，表明本机网络连接以及正常，如果命令不成功，可能是网关设备自身存在问题，也可能是本机上网参数设置有误，检查网络参数。

2.请你说一说你知道的自动化测试框架

1、模块化测试框架
模块化测试脚本框架（TEST MODulARITY FRAMEWORK）需要创建小而独立的可以描述的模块、 片断以及待测应用程序的脚本。这些树状结构的小脚本组合起来，就能组成能用于特定的测试用例的脚本。在五种框架中，模块化框架是最容易掌握和使用的。在一个组件上方建立一个抽象层使其在余下的应用中隐藏起来，这是众所周知的编程技巧。这样应用同组件中的修改隔离开来， 提供了程序设计的模块化特性。模块化测试脚本框架使用这一抽象或者封装的原理来提高自动测 试组合的可维护性和可升级性。
2、测试库框架
测试库框架（Test Library Architecture）与模块化测试脚本框架很类似，并且具有同样的优点。不同的是测试库框架把待测应用程序分解为过程和函数而不是脚本。这个框架需要创建描述模块、片断以及待测应用程序的功能库文件。
3、关键字驱动或表驱动的测试框架
对于一个独立于应用的自动化框架，关键字驱动（KEYWORD DRIVEN）I9LJJ 试和表驱动（TABLE DRIVEN）测试是可以互换的术语。这个框架需要开发数据表和关键字。这些数据表和关键字独立于执行它们的测试自动化工具，并可以用来“驱动＂待测应用程序和数据的测试脚本代码，关键宇驱动测试看上去与手工测试用例很类似。在一个关键字驱动测试中，把待测应用程序的功能和每个测试的执行步骤一起写到一个表中。这个测试框架可以通过很少的代码来产生大量的测试用例。同样的代码在用数据表来产生各个测试用例的同时被复用。
4、数据驱动测试框架
数据驱动（DATA DRIVEN），LJ 试是一个框架。在这里测试的输入和输出数据是从数据文件中读取（数据池，ODBC 源，CSV 文件，EXCEL 文件，ADO 对象等）并且通过捕获工具生成或者手工生成的代码脚本被载入到变量中。在这个框架中，变量不仅被用来存放输入值还被用来存放输出的验证值。整个程序中，测试脚本来读取数值文件，记载测试状态和信息。这类似于表驱动测试，在表驱动测试中，它的测试用例是包含在数据文件而不是在脚本中，对于数据而言，脚本仅仅是一个“驱动器”，或者是一个传送机构。然而，数据驱动测试不同于表驱动测试，尽管导航数据并不包含在表结构中。在数据驱动测试中，数据文件中只包含测试数据。这个框架意图减少需要执行所有测试用例所需要的总的测试脚本数。数据驱动需要很少的代码来产生大量的测试用例，这与表驱动极其类似。
5、混合测试自动化（Hybrid Test Automation）框架
最普遍的执行框架是上面介绍的所有技术的一个结合，取其长处，弥补其不足。这个混合测试框架是由大部分框架随着时间并经过若干项目演化而来的。

3.性能测试时随着并发用户的增加，系统CPU使用率也在逐渐增加，同时存在排队现象，如何分析结果

可能硬件存在瓶颈，可以通过增加CPU或磁盘，同时进行修改WINDOWS系统对于TCP连接数的限制。

4.在搜索引擎中输入汉字就可以解析到对应的域名，请问如何用LoadRunner进行测试

建立测试计划，确定测试标准和测试范围
设计典型场景的测试用例，覆盖常用业务流程和不常用的业务流程等
根据测试用例，开发自动测试脚本和场景：
录制测试脚本：新建一个脚本（Web/HTML协议）；点击录制按钮，在弹出的对话框的URL中输入”about:blank”；在打开的浏览器中进行正常操作流程后，结束录制；调试脚本并保存，可能要注意到字符集的关联。
设置测试场景：针对性能设置测试场景，主要判断在正常情况下，系统的平均事务响应时间是否达标；针对压力负载设置测试场景，主要判断在长时间处于满负荷或者超出系统承载能力的条件下，系统是否会崩溃；执行测试，获取测试结果，分析测试结果

5.一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压，有什么区别

300个用户在一个客户端上，会占用客户机更多的资源，而影响测试的结果。线程之间可能发生干扰，而产生一些异常。
300个用户在一个客户端上，需要更大的带宽。
IP地址的问题，可能需要使用IP Spoof来绕过服务器对于单一IP地址最大连接数的限制。
所有用户在一个客户端上，不必考虑分布式管理的问题；而用户分布在不同的客户端上，需要考虑使用控制器来整体调配不同客户机上的用户。同时，还需要给予相应的权限配置和防火墙设置。

6.常见的Web服务器有哪些，应用服务器和Web服务器的区别

Linux平台下常用的服务器有Apache、Nginx、Tomcat等，Windows平台下常用的服务器是微软公司的IIS。

应用服务器通过各种协议把商业逻辑提供给客户端应用程序。而Web服务器主要是处理向浏览器发送的HTML提供给用户用来浏览。

7.如果自动化测试过程中报错信息是：元素未找到 ，你要怎么解决？或者说你的排查问题的步骤是怎样的？

这是SELENIUM中比较常见的一种错误提示了，NoSuchElementException: Message: no such element
排查过程中可以根据以往经验迅速判断出最可能的原因 ，然后依次排查。通常情况下有以下原因：
--要获取的element自身的代码写错，如id是否动态，但写为固定了，或是其他属性拼写有误，属于代码错误
--element嵌套在iframe里,当前窗口自然无法点击，需要切换到iframe里再去查找element
--element实际并未加载完成,调试时可设置一个等待时间（常见于网络不稳定的情况）
--要获取的element是不可见或是被覆盖了,需要用enter代替clickdriver.find_element来查找
--element可见的屏幕中,要设置代码执行滚动条操作定位到要获取的元素位置，对于web端页面常见，可以封装成通用方法

8.如何区分前端和后端Bug

9.谈谈线程与进程

可参考https://blog.csdn.net/guo_qingxia/article/details/112766187

进程是资源分配的最小单位，线程是CPU调度的最小单位。

进程是一个具有一定独立功能的程序在一个数据集上的一次动态执行的过程，是操作系统进行资源分配和调度的一个独立单位，是应用程序运行的载体。进程是一种抽象的概念，从来没有统一的标准定义。进程一般由程序，数据集合和进程控制块三部分组成。程序用于描述进程要完成的功能，是控制进程执行的指令集；数据集合是程序在执行时所需要的数据和工作区；程序控制块包含进程的描述信息和控制信息是进程存在的唯一标志。

线程是程序执行中一个单一的顺序控制流程，是程序执行流的最小单元，是处理器调度和分派的基本单位。一个进程可以有一个或多个线程，各个线程之间共享程序的内存空间(也就是所在进程的内存空间)。一个标准的线程由线程ID，当前指令指针PC，寄存器和堆栈组成。而进程由内存空间(代码，数据，进程空间，打开的文件)和一个或多个线程组成。

进程与线程的区别：

1. 线程是程序执行的最小单位，而进程是操作系统分配资源的最小单位；

2. 一个进程由一个或多个线程组成，线程是一个进程中代码的不同执行路线

3. 进程之间相互独立，但同一进程下的各个线程之间共享程序的内存空间(包括代码段，数据集，堆等)及一些进程级的资源(如打开文件和信

号等)，某进程内的线程在其他进程不可见；

4. 调度和切换：线程上下文切换比进程上下文切换要快得多

另一种有意思的类比：

• 计算机的核心是CPU，它承担了所有的计算任务。它就像一座工厂，时刻在运行。
• 假定工厂的电力有限，一次只能供给一个车间使用。也就是说，一个车间开工的时候，其他车间都必须停工。背后的含义就是，单个CPU一次只能运行一个任务。
• 进程就好比工厂的车间，它代表CPU所能处理的单个任务。任一时刻，CPU总是运行一个进程，其他进程处于非运行状态。
• 一个车间里，可以有很多工人。他们协同完成一个任务。线程就好比车间里的工人。一个进程可以包括多个线程。
• 车间的空间是工人们共享的，比如许多房间是每个工人都可以进出的。这象征一个进程的内存空间是共享的，每个线程都可以使用这些共享内存。
• 可是，每间房间的大小不同，有些房间最多只能容纳一个人，比如厕所。里面有人的时候，其他人就不能进去了。这代表一个线程使用某些共享内存时，其他线程必须等它结束，才能使用这一块内存。
• 一个防止他人进入的简单方法，就是门口加一把锁。先到的人锁上门，后到的人看到上锁，就在门口排队，等锁打开再进去。这就叫"互斥锁"（Mutual exclusion，缩写 Mutex），防止多个线程同时读写某一块内存区域。
• 这时的解决方法，就是在门口挂n把钥匙。进去的人就取一把钥匙，出来时再把钥匙挂回原处。后到的人发现钥匙架空了，就知道必须在门口排队等着了。这种做法叫做"信号量"（Semaphore），用来保证多个线程不会互相冲突。

操作系统的设计，因此可以归结为三点：

（1）以多进程形式，允许多个任务同时运行；

（2）以多线程形式，允许单个任务分成不同的部分运行；

（3）提供协调机制，一方面防止进程之间和线程之间产生冲突，另一方面允许进程之间和线程之间共享资源。

或者：

做个简单的比喻：进程=火车，线程=车厢

• 线程在进程下行进（单纯的车厢无法运行）
• 一个进程可以包含多个线程（一辆火车可以有多个车厢）
• 不同进程间数据很难共享（一辆火车上的乘客很难换到另外一辆火车，比如站点换乘）
• 同一进程下不同线程间数据很易共享（A车厢换到B车厢很容易）
• 进程要比线程消耗更多的计算机资源（采用多列火车相比多个车厢更耗资源）
• 进程间不会相互影响，一个线程挂掉将导致整个进程挂掉（一列火车不会影响到另外一列火车，但是如果一列火车上中间的一节车厢着火了，将影响到所有车厢）
• 进程可以拓展到多机，进程最多适合多核（不同火车可以开在多个轨道上，同一火车的车厢不能在行进的不同的轨道上）
• 进程使用的内存地址可以上锁，即一个线程使用某些共享内存时，其他线程必须等它结束，才能使用这一块内存。（比如火车上的洗手间）－"互斥锁"
• 进程使用的内存地址可以限定使用量（比如火车上的餐厅，最多只允许多少人进入，如果满了需要在门口等，等有人出来了才能进去）－“信号量”

10.堆（heap）和栈（stack）的区别

数据结构中的堆和栈栈：

堆是满足父子节点大小（比如大根堆中规定父节点的值要比子节点大）关系的一种完全二叉树。由于是完全二叉树，可以用数组来实现，用节点编号来访问和操作节点，简化程序，提升效率。而其大小关系则为我们查询堆中极值提供了常数级别的时间复杂度，又由二叉树的性质，插入和删除则为对数级别时间复杂度。这就好像地位不同的人在排队，排在最前面的一定是地位最高的人，所以堆是优先队列（Priority Queue）实现的基础。利用这一特性，可以加速某些需要频繁取队列中极值的算法比如 A* 算法等。

栈则是一种相当简单的结构。就像是只有一个口的深深的文件桶，先进去的文件会被压在下面（push），而且我们每次只能取到最上面的文件（pop），体现了其先进后出（FILO）的特性。虽然栈操作简单，但也有如单调栈等在栈内保持一定数据特性的变种。

操作系统中的堆和栈：

堆区（heap）——般由程序员分配释放， 若程序员不释放，程序结束时可能由OS回收 。

操作系统中的堆和栈都是指内存空间，不同的是堆为按需申请、动态分配，例如 C 中的 malloc 函数和 C++ 中的 new 操作（当然 C++ 的 new 不仅仅是申请内存这么简单）。内存中的空闲空间并不是连续的，而是不同程序占用了不同的一块一块的内存，即使是同一个程序也可能占用了不同地方的多块内存。操作系统中则会对这些空间进行统一的管理，在应用程序提出申请时，就会从堆中按照一定算法找出一块可用内存，标记占用空间等信息之后返回其起始地址给程序。在程序结束之前，操作系统不会删除已经申请的内存，而是要靠程序主动提出释放的请求（free、delete），如果使用后忘记释放，就会造成所谓的内存泄漏问题。因此堆基本上可以理解为当前可以使用的空闲内存，但是其申请和释放都要程序员自己写代码管理。

栈区（stack）——由编译器自动分配释放 ，存放函数的参数值，局部变量的值等。其操作方式类似于数据结构中的栈。

操作系统的栈则是程序运行时自动拥有的一小块内存，大小在编译期时由编译器参数决定，用于局部变量的存放或者函数调用栈的保存。在 C 中如果声明一个局部变量（例如 int a），它存放的地方就在栈中，而当这个局部变量离开其作用域之后，所占用的内存则会被自动释放，因此在 C 中局部变量也叫自动变量。栈的另一个作用则是保存函数调用栈，这时和数据结构的栈就有关系了。在函数调用过程中，常常会多层甚至递归调用。每一个函数调用都有各自的局部变量值和返回值，每一次函数调用其实是先将当前函数的状态压栈，然后在栈顶开辟新空间用于保存新的函数状态，接下来才是函数执行。当函数执行完毕之后，栈先进后出的特性使得后调用的函数先返回，这样可以保证返回值的有序传递，也保证函数现场可以按顺序恢复。操作系统的栈在内存中高地址向低地址增长，也即低地址为栈顶，高地址为栈底。这就导致了栈的空间有限制，一旦局部变量申请过多（例如开个超大数组），或者函数调用太深（例如递归太多次），那么就会导致栈溢出（Stack Overflow），操作系统这时候就会直接把你的程序杀掉。

二、非技术类

还有些房间，可以同时容纳n个人，比如厨房。也就是说，如果人数大于n，多出来的人只能在外面等着。这好比某些内存区域，只能供给固定数目的线程使用。

1.你在测试中发现了一个bug，但是开发认为这不是一个bug，你应该怎样解决

①首先，将问题提交到缺陷管理库里面进行备案。
②然后，要获取判断的依据和标准：
    根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
    如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
    根据用户的一般使用习惯，来确认是否是缺陷；
    与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
③合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
   等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。

开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，三方商量确定好后再看要不要改；二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。

2.遇到压缩测试时间的问题怎么处理

问题背景如：临时紧急需求、常规需求、经常性压缩时间、客户压缩时间、因自身漏洞导致压缩时间等等
回答时需要应景：排列工作优先级、重新分解当前工作、改变测试策略、团队内分工、外部求助等

3.你的测试职业发展目标是什么

测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经验，不断的更新自己改正自己，做好测试任务。

4.简述你在以前的工作中做过哪些事情，比较熟悉什么

我过去的主要工作是系统测试和自动化测试。在系统测试中，主要是对BOSS系统的业务逻辑功能，以及软交换系统的Class 5特性进行测试。性能测试中，主要是进行的压力测试，在各个不同数量请求的情况下，获取系统响应时间以及系统资源消耗情况。自动化测试主要是通过自己写脚本以及一些第三方工具的结合来测试软交换的特性测试。
在测试中，我感觉对用户需求的完全准确的理解非常重要。另外，就是对BUG的管理，要以需求为依据，并不是所有BUG均需要修改。
测试工作需要耐心和细致，因为在新版本中，虽然多数原来发现的BUG得到了修复，但原来正确的功能也可能变得不正确。因此要注重迭代测试和回归测试。

5.简述过往你最熟悉的一个项目的业务逻辑

面试频率较高的一个题目，面试前充分准备，挑选简历中的项目，开放式问题，主要考察候选人的逻辑思维，理解能力及表达沟通能力。

6.在最近的一个项目中你发现了哪些印象深刻的缺陷

可以挑选简历中项目的缺陷来说明，可以选择不易发现或是不易重现的缺陷，要有针对性。

7.一个合格的软件测试工程师需要具备哪些品质

开放性问题，比如：专注、细心、强烈的责任感、质量意识、积极进取、乐观主动、目标导向、有计划等等。

8.描述一个过往让自己最有压力的一个项目或经历

考察点：抗压能力、责任感、是否积极主动为工作做出贡献