Spring Boot 算是目前 Java 领域最火的技术栈了，松哥年初出版的 《Spring Boot + Vue 全栈开发实战》迄今为止已经加印了 8 次，Spring Boot 的受欢迎程度可见一斑。经常有人问松哥有没有推荐的 Spring Boot 学习资料？当然有！买松哥书就对了，哈哈。除了书呢？当然就是开源项目了，今天松哥整理了几个优质 Spring Boot 开源项目给大家参考，希望能够帮助到正在学习 Spring Boot 的小伙伴！小伙伴简历中不知道写什么项目的或者项目没有亮点的，我只能帮你们到这了！
 
微人事
 
star 数 11.8k
项目地址：https://github.com/lenve/vhr
 
微人事是一个前后端分离的人力资源管理系统，项目采用 SpringBoot + Vue 开发。项目打通了前后端，并且提供了非常详尽的文档，从 Spring Boot 接口设计到前端 Vue 的开发思路，作者全部都记录在项目的 wiki 中，是不可多得的 Java 全栈学习资料。
 
项目效果图:
 
 
项目部分文档截图：
 
 
Cloud-Platform
 
star 数 8k
项目地址：https://gitee.com/geek_qi/cloud-platform
 
Cloud-Platform 是国内首个基于 Spring Cloud 微服务化开发平台，具有统一授权、认证后台管理系统，其中包含具备用户管理、资源权限管理、网关 API 管理等多个模块，支持多业务系统并行开发，可以作为后端服务的开发脚手架。代码简洁，架构清晰，适合学习和直接项目中使用。 核心技术采用 Spring Boot 2.1.2 以及 Spring Cloud (Greenwich.RELEASE) 相关核心组件，采用 Nacos 注册和配置中心，集成流量卫兵 Sentinel，前端采用vue-element-admin 组件。
 
项目演示：
 
 
spring-boot-pay
 
star 数 2931
项目地址：https://gitee.com/52itstyle/spring-boot-pay
 
这是一个支付案例，提供了包括支付宝、微信、银联在内的详细支付代码案例，对于有支付需求的小伙伴来说，这个项目再合适不过了。
 
项目效果图：
 
 
V 部落
 
star 数 3.7k
项目地址：https://github.com/lenve/VBlog
 
V部落是一个多用户博客管理平台，采用 Vue + SpringBoot + ElementUI 开发。这个项目最大的优势是简单，属于功能完整但是又非常简单的那种，非常非常适合初学者。
 
项目效果图：
 
 
springboot-plus
 
star 数 2546
项目地址：https://gitee.com/xiandafu/springboot-plus
 
一个基于 SpringBoot 2 的管理后台系统,包含了用户管理，组织机构管理，角色管理，功能点管理，菜单管理，权限分配，数据权限分配，代码生成等功能 相比其他开源的后台系统，SpringBoot-Plus 具有一定的复杂度。系统基于 Spring Boot2.1 技术，前端采用了Layui2.4。数据库以 MySQL/Oracle/Postgres/SQLServer 为实例，理论上是跨数据库平台。
 
项目效果图：
 
 
spring-boot-seckill
 
star 数 3.7k
项目地址：https://gitee.com/52itstyle/spring-boot-seckill
 
从 0 到 1 构建分布式秒杀系统，脱离案例讲架构都是耍流氓，SpringBoot 开发案例从 0 到 1 构建分布式秒杀系统，项目案例基本成型，逐步完善中。
 
 
litemall
 
star 数 6436
项目地址：https://github.com/linlinjava/litemall
 
一个商城项目，包括 Spring Boot 后端 + Vue 管理员前端 + 微信小程序用户前端 + Vue用户移动端，功能包括、分类列表、分类详情、品牌列表、品牌详情、新品首发、人气推荐、优惠券列表、优惠券选择、团购（团购业务有待完善）、搜索、商品详情、商品评价、商品分享、购物车、下单、订单列表、订单详情、地址、收藏、足迹、意见反馈以及客服；管理平台功能包括会员管理、商城管理、商品管理、推广管理、系统管理、配置管理、统计报表等。
 
项目效果图：
 
 
jeeSpringCloud
 
star 数：3.9k
项目地址：https://gitee.com/JeeHuangBingGui/jeeSpringCloud
 
基于 SpringBoot2.0 的后台权限管理系统界面简洁美观敏捷开发系统架构。核心技术采用Spring、MyBatis、Shiro 没有任何其它重度依赖。 互联网云快速开发框架,微服务分布式代码生成的敏捷开发系统架构。项目代码简洁,注释丰富,上手容易,还同时集中分布式、微服务,同时包含许多基础模块和监控、服务模块。模块包括:定时任务调度、服务器监控、平台监控、平台设置、开发平台、单点登录、Redis 分布式高速缓存、会员、营销、在线用户、日志、在线人数、访问次数、调用次数、直接集群、接口文档、生成模块、代码实例、安装视频、教程文档 代码生成(单表、主附表、树表、列表和表单、redis 高速缓存对接代码、图表统计、地图统计、vue.js )、dubbo、springCloud、SpringBoot、mybatis、spring、springmvc。
 
 
美人鱼
 
star 数 3499
项目地址： https://gitee.com/mumu-osc/NiceFish
 
听名字就知道这是个不错的项目，事实上确实不赖。NiceFish（美人鱼） 是一个系列项目，目标是示范前后端分离的开发模式:前端浏览器、移动端、Electron 环境中的各种开发模式；后端有两个版本：SpringBoot 版本和 SpringCloud 版本，前端有 Angular 、React 以及 Electron 等版本。
 
项目效果图：
 
 
bootshiro
 
star 数 1370
项目地址： https://gitee.com/tomsun28/bootshiro
 
bootshiro 是基于 Spring Boot + Shiro + JWT 的真正 RESTful URL 资源无状态认证权限管理系统的后端,前端 usthe 。区别于一般项目，该项目提供页面可配置式的、动态的 RESTful api 安全管理支持，并且实现数据传输动态秘钥加密，jwt 过期刷新，用户操作监控等，加固应用安全。
 
项目效果图：
 
 
open-capacity-platform
 
star 数 2643
项目地址：https://gitee.com/owenwangwen/open-capacity-platform
 
open-capacity-platform 微服务能力开放平台，简称 ocp ，是基于 layui + springcloud 的企业级微服务框架(用户权限管理，配置中心管理，应用管理，…)，其核心的设计目标是分离前后端，快速开发部署，学习简单，功能强大，提供快速接入核心接口能力，其目标是帮助企业搭建一套类似百度能力开放平台的框架。
 
项目效果图：
 
 
悟空 CRM
 
star 数 650
项目地址：https://gitee.com/wukongcrm/72crm-java
 
悟空 CRM 是基于 jfinal + vue + ElementUI 的前后端分离 CRM 系统。
 
老实说，jfinal 了解下就行了，没必要认真研究，Vue + ElementUI 的组合可以认真学习下、前后端交互的方式可以认真学习下。
 
 
paascloud-master
 
star 数 5168
项目地址：https://github.com/paascloud/paascloud-master
 
paascloud-master 核心技术为 SpringCloud + Vue 两个全家桶实现，采取了取自开源用于开源的目标，所以能用开源绝不用收费框架，整体技术栈只有阿里云短信服务是收费的，都是目前 java 前瞻性的框架，可以为中小企业解决微服务架构难题，可以帮助企业快速建站。由于服务器成本较高，尽量降低开发成本的原则，本项目由 10 个后端项目和 3 个前端项目共同组成。真正实现了基于 RBAC、jwt 和 oauth2 的无状态统一权限认证的解决方案，实现了异常和日志的统一管理，实现了 MQ 落地保证 100% 到达的解决方案。
 
项目效果图：
 
 
总结
 
他山之石，可以攻玉。当我们学会了很多知识点之后，需要一个项目来将这些知识点融会贯通，这些开源项目就是很好的资料。现在前后端分离开发方式日渐火热，松哥也强烈建议大家有空学习下这种开发方式。虽然我们身为 Java 工程师，可是也不能固步自封，看看前端单页面应用怎么构建，看看前端工程化是怎么回事，这些都有助于我们开发出更加合理好用的后端接口。好了，十五个开源项目，助力大家在全栈的路上更进一步！

导读：实现经济效益关键是让业务部门和IT部门的负责人共同努力，不仅合理地设计业务应用和流程，还要使核心IT基础设施和运营合理化。本文介绍如何降低IT架构的成本和复杂性。 
 关键词：IT架构 业务部门 IT部门 IT架构成本 
 在经济低迷期间，企业都在寻找一切机会削减成本。IT是总支出中的一个重要部分——在某些行业中占5%，甚至更多，但它对收入和利润的直接贡献却往往难以评估。因此，许多首席执行官和首席财务官迫切要求压缩其首席信息官的预算，这一点在人们的预料之中。 
 但是，要找到大幅度节约的机会并不容易。许多首席信息官已经花费了数年时间降低运营、采购和外部服务方面的成本。他们已经采取了许多措施，包括整合数据中心和服务台、将服务器虚拟化而不是购买更昂贵的新服务器、让采购流程更加合理化、推迟升级并将服务外包给更廉价的海外提供商，等等。 
 然而，如果企业以更广阔的视角审视他们将IT架构作为一个整体进行管理的方法，那么，继续大幅削减成本和提高效率的可能性还是存在的。实现这些经济效益的关键是让业务部门和IT部门的负责人共同努力，不仅合理地设计业务应用和流程，还要使核心IT基础设施和运营合理化。例如，在一家大型消费品企业，业务部门与IT部门进行了合作，共同在各业务部门之间合并、整合了各自为政的IT系统，并使其合理化，结果，使得IT队伍的规模（应用管理领域下降达50%）和备件库存均大幅下降，提高了与供应商进行折扣谈判的砝码，并使新的IT项目得以更快完成。 
 IT架构的复杂性 
 企业的IT基础架构是对其业务运营（流程和功能）、业务应用和为其提供支持的数据库以及运行应用的设备和服务的正式描述。完整的IT架构分为6个层次(图表 1)。在最理想的情况下，企业可以将其编辑汇编成一个手册——一本蓝皮书——详细描述6个层次的运行，以及管理整体架构所涉及的流程、角色和责任。这一汇编文件还应提供指导设备升级和增加设备的规划和规则。 
  
 多数企业都有一个IT架构，但是，极少有企业对其进行控制。而架构会有机地增长，结果，常常导致系统重复建设、数据激增而且不一致以及作为权宜之计的临时性整合。使事情更为复杂的是，在多数大型企业里，甚至在部门内部的，受短期业务要求和需要驱动的IT项目与按长期规划实施的IT项目一样多。这一运营现实对于应用软件以及其支持的业务流程来说尤其明显。设计和部署这种软件的目的通常是满足一个部门或业务单位的需求，相对而言，很少考虑该软件对整个企业IT架构的影响。 
 公司一级或部门层级的首席信息官对于像服务器、存储系统以及相关的基础软件等IT基础设施的核心组件通常有很大的控制权。但是，建立在IT基础设施之上的各种业务应用、流程和业务模式通常反映的是业务部门和职能部门领导的要求，他们更多地关注自己的需求而不是整体IT效率——这可以理解。但是，在一个全球性的企业中，这样的情况通常会导致产生难以驾驭的异构IT环境，在这种环境中，为应付具体的近期需求而配置的不兼容（通常还互相重复）的硬件、应用程序和流程，在企业的各个角落一年年滋生膨胀。 
 例如，我们最近在一家大型金融公司发现了7个不同的支付系统，这些系统上运行着20个定制的应用，它们多数承担着像薪酬支付、付税和支付供应商等同样的职能。为了满足其主要需求，该公司逐步创建了许多系统和应用，结果形成了一个复杂、低效且昂贵的运营环境。IT架构团队对许多正在实施的IT项目几乎没有多少影响力，因此，其中只有少部分项目完全符合公司的标准和指导方针。 
 类似的低效在各个行业的企业的IT运营中都存在。为这些拼凑而成的系统的开发、支持和维护，需要耗费多得多的时间和资金显著增加，从而牺牲了预算、新IT能力和业务创新。在大企业中，消除这些重复和低效状况可以将IT支出减少数千万乃至数亿美元，同时，可提高IT运营的质量，改善依靠其运营业务的人的满意度。然而，单靠首席信息官无法降低这些成本，业务负责人也必须支持并参与这一转变。 
 降低成本和复杂性：一体化的架构方法 
 当前的全球经济危机创造了绝佳的机会，使企业可以通过改变企业IT架构来大幅度削减IT成本。实现这一目标所需要的是定义明确的IT规划，以及获得最适当和高效的系统、应用和流程的机构范围的指导方针。制定和实施这些指导方针可帮助企业创建一致且标准化的基础设施，并最大限度地减少不必要的复杂性、重复和成本（图表2）。 
  
 正是由于这个原因，首席执行官必须让由整个企业的业务部门和IT部门的负责人组成的团队，参与对架构进行彻底的审查和变革的计划。我们发现，一个专注于一系列成本削减手段的分阶段的联合方法所发现并实现的节约，可以远远超过只涉及IT部门的项目所产生的节约。事实上，采取这一做法的企业还可以建立更灵活高效的架构，帮助他们在低迷期结束时繁荣发展。 
 要创建高效的IT架构，业务负责人和首席信息官必须联合评估作为现有架构基础的业务要求和流程，然后探寻更高效的替代方法；若没有高度的协作，即使拥有最出色的架构设计，企业也可能不遵循。据我们的经验，恰当的出发点是组建一个高层次的业务-IT联合工作组，来提供跨部门的治理和问责制。该团队的主要职责是审查现有的IT架构并为新项目确定基线，定义适当的流程，以确保系统和项目符合理想的架构，并发现近期、中期和长期的成本节约和效率改进的机会。该团队应包括所有主要利益相关团体，每个利益相关方的代表的级别要足够高，能够代表该团体做出战略决策。 
 为了尽可能减少业务中断并最大限度地提高获益，我们建议采用三阶段的方法，从较容易的变革开始，并逐步向着更重大变革的方向努力（图表3）。仔细划分阶段，这更有可能让企业以适当的节奏建立内部协作，获得早期收益，以便为后续举措提供资金，并避免大家一哄而上的“高调”方法的巨大风险：例如，过度的前期投资、内部的反对，或整个系统的故障或失败。 
  
 第1阶段：立即清理 
 在第一阶段，该团队的任务是确定明确的目标，并通过成本削减赢得迅速的成功，从而为更大的举措积蓄动力。据我们的经验，在此阶段，有3个手段颇为重要。 
 软件许可证的合理化分配。编制详细的许可证目录应该可以找出闲置、使用不足、甚至错误的许可。当业务部门经理参与审核时，首席信息官可以决定真正需要多少许可证，撤销不必要的许可，然后，通过整合许可证数量去谈判争取更大的折扣。 
 取消不合规的项目。对正在进行的项目在多大程度上能够同时为业务部门和IT战略提供支持进行评估，找出需要继续支持、修改或终止的候选项目。在平常时，这类评审通常会凸显出业务负责人认为足够重要以至于可以作为架构规则的例外的项目。现在，例外的标准应该设置得比以往高得多。该团队可以将项目总共分为4组：（1）具有较高业务价值并为IT战略提供直接支持的项目需要继续进行；（2）具有较高业务价值但是不符合IT战略的项目应该加以改造；（3）符合IT战略但是几乎没有业务价值的项目应当暂缓；（4）业务价值低又不合规的项目必须取消。 
 取消很少或从未使用过的应用。需要取消的候选项目包括在过去的一年中很少或从未使用的业务应用。取消这些应用可能需要不同的方法：根据使用情况和需求，某些可能会被立即取消，另外一些由更新的应用取代，还有一些则逐步淘汰。 
 例如，一家电信运营商最近发现，违反其IT架构指导方针的情况大幅增多，因为有些业务部门经理——他们没有因为不遵守指导方针而受到直接影响，因此遵不遵守就无所谓——要求IT要迅速支持新业务举措。这些违规行为通常会让IT运营更加复杂，进而增加了长期成本。 
 该公司决定在任何IT项目开始时或者一个新的应用发布时，就注意防范可能出现的IT架构违规情况。新方法涉及评估包括可能导致的额外成本在内的违规总体影响，这一方法使得公司能够迅速支持新业务要求，但同时又要求对新业务要求所产生的违规情形在下一阶段加以纠正。因此，该公司可以在决定实施项目之前，评估权衡每一种情形下的业务和IT成本收益的得失。 
 第2阶段：降低复杂性 
 在第二阶段，该团队应专注于降低整个IT架构的复杂性。这项更为艰巨的任务对于扭转定制系统、应用和流程的随意扩张，以及开始更彻底地遵循理想架构至关重要。该阶段的主要目标是，决定现有IT配置中的不同部分是否真正必需，而不是努力优化它们。通常，该团队将会发现利用更为简单的现成系统以及重新使用现有组件足以支持业务要求。企业在这一阶段可利用多种手段。 
 实施开箱即用的常规解决方案。太多的项目将定制作为首选，而不是末选。企业不可能让所有的业务部门都马上接受标准的完全非定制的应用。但是，由于资源有限，该团队应要求在大多数情况下都使用开箱即用的解决方案，只有在绝对必要的情况下，才允许定制以满足法律要求或者提供真有意义的竞争优势。财务会计、人力资源以及采购等职能通常不与其他企业直接竞争，它们是这一阶段实现节约的首选领域。组织思维和组织行为很难改变，但是，许多IT项目失败的原因就是过度的定制，因此，结束定制可以让企业大大提高效率和效果。 
 鼓励重用。太多企业花费宝贵的IT资源进行重复建设。认真审查现有的项目组合，可能会发现有许多机会可以重新使用现有解决方案，并建立一个共同的服务和解决方案库。这一转变的一个重要组成部分就是转向面向服务的架构(SOA)，它从所需要的业务能力以及统一的访问和互动方式的角度描述一个系统。 
 整合数据库并开发集成的数据模式。随着企业的扩大，它们会为在线销售、客户关系管理以及计费等目的增加新的数据库和应用，以便为业务部门和职能部门提供支持，而这些部门的需求实际上并不需要不同的数据库。事实上，非集成数据库会大大增加成本并导致低效的流程、重复的开发、产品上市时间延长、业务错误以及错失良机。 
 实现技术标准化。在许多企业，由于编程语言、操作系统和集成工具等技术非常多样化，就容易产生严重低效的情形。仔细审查可以发现冗余的版本、无支持的技术以及非标准工具，这些都应让位于数量更少、更加标准的系统。成本节约来自于更简单的统一采购，以及更低的支持和维护开销。 
 降低界面复杂性。IT员工会将多达30%的开发时间用于使所有界面运行起来的应用，这在很大程度上是由于定制的应用有着许多点对点的界面。像企业服务总线（ESB）等标准化界面可大大减轻系统集成的负担，并最大限度地减少应对局部变化的琐事。该团队应首先识别并集中精力处理那些推动多数工作的关键界面。 
 整合功能类似的系统。同一企业中的不同业务部门常常会有不同版本的必备系统，例如，支付系统和互联网应用。从企业层面上整合这些系统可实现大量节约，并让流程更简单、更高效。 
 首席信息官和业务负责人在面对每一个机会时必须对业务部门的短期便利与整个企业的短期及长期成本和复杂性之间的得失进行严格审查和仔细权衡。面对这种现实并不容易，但是，当下的经济危机应该创造了一种紧迫感。这些削减成本的机会中有些需要投资，而每一项投资都需要有一个靠谱的商业理由。 
 例如，在一家零售银行，旨在降低架构复杂性的综合评估，在多数领域发现了重大的成本节约机会。一个由业务和IT高管组成的团队帮助公司发现，有50多项未使用的应用可以撤销、有150项重复的应用可以整合，还有400项应用可以与一个数据集成平台连接。 
 这些变革中大多需要近期投资。有几项做法，例如，撤销或整合较大的冗余应用，需要相当大的投资。并非所有整合方案都能提供积极的回报。最重要的是，该团队坚持让项目负责人提供各个项目的商业理由。总的来说，这一努力已走上轨道，将提供超过50%的投资回报，把产品上市时间缩短至少30%，并带来其他的组织收益，包括业务和IT部门之间更好的协调。 
 第3阶段：业务创新 
 企业在危机时期必须考虑转变自己，甚至彻底改造自己。在对企业运营以及产品或服务的上市方式实施重大变革的过程中，IT可发挥核心作用。架构变革的第三个、也是最艰巨的阶段，就是要实施这些大胆的变革。随着企业将目光放远到低迷之后的时期，它们应考虑以更激进的方式改变其IT架构，从而推动或支持战略创新和全新的增长领域。以下两个手段颇为重要。 
 更大的灵活性、更快的产品上市时间以及更高效而有力的业务流程，将会让企业走出低迷。 
 评估替代性的运营模式。多数企业都拥有全球业务，但是，开发支持企业战略的真正的全球IT运营模式的企业却不多。对IT价值链进行综合审查，应该能够确定每项基本业务能力所需要的采购、协调、整合、治理以及IT支持水平。这种审查可形成一个更有效的新的IT规划和架构模式。 
 例如，风险管理以及风险最小化在低迷时期尤为重要，而它在很大程度上取决于能否从整个企业获得适当的数据以支持及时的决策。业务和IT负责人必须共同努力，来设计数据管理模式，从而推动最有效的由数据驱动的决策过程。 
 塑造未来。业务负责人应该与IT部门紧密合作，探索如何对能够支持新工作方式的众多新兴技术进行投资。例如，利用互联网与客户和供应商共同创造产品、雇员之间的在线协作以及数据驱动的管理等。新工具和流程可以加速产品开发的全球化、在衰退的市场环境中找到利基市场，并提高生产率。 
 采用这种更雄心勃勃的方法进行架构变革的触发因素各不相同。在一家制造企业，其原因是一场收购。该公司刚刚收购了另一家国际企业，使整个实体规模跻身业内前5位，雇员超过2万名，年收入超过130亿美元。该公司领导探讨如何利用增强后的地位来获利，结果却认识到，他们无法凭借两个依赖陈旧信息系统的不同运营模式来取得成功。 
 该公司在为销售和分销、供应链、产品生命周期管理以及售后服务制定了新的集成的全球运营模式后，通过精简的IT架构实施了这一模式，产生了巨大的影响。除了许多其他收益之外，该公司将特别买进报价所需的时间降低了90%，将生产定制产品的时间缩短了80%。 
 一家全国性石油公司的管理层希望将其转变为世界顶级的石油天然气企业之一，因而启动了架构转型。该公司的IT系统无法支持这一增长。太多的系统是根据局部的需求而定制的。几乎没有多少业务流程符合公司的标准。不同业务部门之间的数据并不一致，这使得跨部门的协作颇为困难。IT运行也很少达到行业最佳实践水平。 
 IT和业务负责人在获得最高管理层的明确授权后，专注于需要改革架构的核心业务目标。根据新计划，IT将支持世界级的流程，通过提供更好的数据推动全企业范围的决策，帮助公司加深对客户的更深入的认识，并对其财务、管理和物流状况提供准确的最新观点。该公司正在开发一个统一的信息系统，以便将所有事业部联系起来，并更加严格地审核新IT项目请求。IT对财务、人力资源和销售等关键职能发挥着更大的控制作用。 
 经济低迷为IT和业务负责人提供了通过协作降低成本，以及重塑IT架构实现竞争优势的重要机会。当企业只盯着IT部门寻找节约机会时，成果常常颇为有限。IT-业务联合团队可以获得更丰富的成果。 
 让IT和业务负责人携手合作，还可以帮助IT部门创造实现业务增长的新方式。更出色的灵活性、更快的上市时间以及更高效而有力的业务流程，将会让企业走出低迷。有些企业将当前的困难视为机会，不仅可以借此控制成本，而且可以重新定位以便在经济开始好转时即实现更快的增长；对这些企业来说，改造IT架构属于最有价值的举措之一。

  软件测试工程师，和开发工程师相比起来，虽然前期可能不会太深，但是涉及的面还是比较广的。前期面试实习生或者一年左右的岗位，问的也主要是一些基础性的问题比较多。涉及的知识主要有MySQL数据库的使用、Linux操作系统的使用、软件测试框架性的问题，测试环境搭建问题、当然还有一些自动化测试和性能测试的问题。测试工程师的面试题，基本上都是大同小异的，面试的核心主要在于框架模块（一到两年工作经验）
 。今天这篇帖子主要讲解之前面试自己面试过程中或者周围人面试过程中经常被问到且比较经典的面试题，一家之言，如有异议或者有想问的问题，可以在评论区留言，看到后将在第一时间内回复!
 
 
1、软件测试的流程是什么？
   分析：每当HR问一个问题的时候我们都可以用1~2s的时间去想HR想要从这个问题中获取什么信息，这点搞清楚之后再去回答就很好回答了。如果有工作经验，直接按照公司流程回答即可，如果是刚转行或者刚实习，那按标准回答即可，文中回答仅供参考；
   回答： 项目经理或者PD把项目需求文档提前下发给相关的研发人员，研发人员抽出一定的时间记录文档内需求不明确或者遗漏的点为后面的评审做准备；在需求评审会议上，各研发人员提出自己的疑问并解决，需求评审最终通过之后会出一份最终的需求规格说明书；（需求评审阶段）
     需求规格说明书评审通过后，开发经理开始编写开发计划，测试经理开始编写测试计划，计划评审通过后开发人员开始进行程序的开发，测试人员开始测试用例的编写，等程序的第一个版本出来后，开发人员进行第二个版本的迭代，这时测试人员对程序进行测试并记录追踪管理缺陷，直到程序迭代完毕。（产品研发阶段）
     程序迭代完毕并修复大部分缺陷后，测试人员开始进行工作的总结，并最终输出一份测试报告书，记录此次的测试工作共，程序存在的相关问题。（产品发布阶段）
 
2、测试用例主要有哪些元素？
   分析：每个公司因为使用的模板不一样，所以测试用例的内容也是不尽相同的，所以回答时只需要回答出基本的元素即可；
   回答： 测试用例主要元素有：ID、标题、模块、预置条件、操作步骤、预期结果、实际结果、是否通过、BugID等；
 
3、软件测试有什么策略和阶段？
   分析：软件测试的策略就是测试将按照什么样的思路和方式进行如采用什么技术，什么步骤等。
   回答 ：软件测试的策略主要有：动态测试和静态测试、白盒测试和黑盒测试。测试阶段按照研发顺序分别是：单元测试、集成测试、系统测试，有些公司还会有验收测试；（单元测试开发在调试代码时就完成，集成测试也是，但是有时测试人员也需要进行集成测试；测试人员平时主要的工作就是系统测试，验收测试是有客户参与进行的测试）；
 
4、黑盒测试和白盒测试是什么？二者有什么区别？
   分析：黑盒测试和白盒测试的概念百度百科上面都有，这里不再做太多介绍。黑盒测试和白盒测试的区别：https://www.cnblogs.com/i16i1007/p/6624072.html记得
   回答： 黑盒测试主要是在程序界面进行测试，通过设定某种场景检验程序在这种场景下是否给出了正确的反应，验证程序正确实现了需求规格说明书中的需求，而白盒测试主要是针对程序内部结构，对程序代码进行代码走查等，但是白盒测试的成本会比较大，当程序有多个路径时，可能会产生较多的遗漏；
 
5、软件测试有什么类型？
   回答： 常见的软件测试类型有:功能测试、性能测试、兼容性测试、可靠性测试、安全性测试、压力测试、负载测试等；
 
6、测试用例是什么？有什么作用？
   回答：测试用例就是设计一个特定场景，让软件在这种场景下运行，检验程序是否给出正确的反应，以此验证软件是否正确实现了客户需求。
   作用：1、避免盲目测试并提高测试效率；在软件版本更新之后只需修正少部分用例即可开展测试工作，降低工作强度，缩短测试周期；
          2、可以分清哪些是测试重点，测试用例是测试工作的见证，能知道测试了哪些功能，没测哪些模块；
          3、测试用例是量化测试工作的方法之一；
 
7、你平时是怎么设计测试用例的？
   分析：这个问题的点主要考察是否掌握测试用例设计方法，在回答之后，HR可能会继续追问某种设计方法的概念或者实例，这时举例说明即可；如：等价类划分法就是把程序的输入域划分成等价类，从每个部分中选取少数代表性数据当做测试数据。
   回答：设计测试用例一般都会使用到等价类、边界值、场景/流程法、因果图还有错误推测法；
 
8、软件缺陷的定义是什么？
   分析：什么样的问题才是一个缺陷，需要从客户需求出发；
   回答：1、软件未实现需求规格说明书中的要求；
         2、出现需求规格说明书中指明不应该出现的错误；
         3、软件未实现需求文档中虽未明确提及但应该实现的功能；（如：账密加密）
         4、软件出现难以理解、不易使用或者运行速度慢等问题都可以认为是软件缺陷；
 
9、缺陷中应该包含什么元素？严重等级一般有哪些？
   分析：这个问题和上面测试用例一样，每个公司的要求可能都会不一样；
   回答：主要元素有：标题、BugID、复现步骤、实际结果、预期结果、截图、日志等；软件缺陷等级一般有四种，致命（程序奔溃）、严重（金额计算错误、数据出错）、一般（不影响使用但是会造成一定的麻烦）、优化（字体字号不统一）
 
10、给你一个杯子，你会怎么测试？
   分析：给你一个杯子，给你一个电梯，这种问题在前期的面试中是经常遇到也是非常经典的一道面试题，这里给出一个链接，回答时从外观、功能、性能等各个角度说起，再结合自己的一些话就可以了。
   回答：经典测试用例，一个水杯的测试https://blog.csdn.net/ganhongxia/article/details/6025416
 
11、测试报告里面包含什么内容？
   分析：测试报告，是测试工作结束后测试部门输出的一份测试结果，但每个公司的测试报告内容都会有些差别。有些公司的测试报告是有测试部门的负责人一人编写，或者是由每个测试工程师输出自己对应模块的测试报告再由测试组长整合成一份完整的测试报告；
   回答：测试报告内容一般有：编写目的、系统简介、测试环境、测试方法和工具、测试执行结果与记录、缺陷汇总、遗留缺陷跟踪、测试用例执行情况、测试结论与建议等；
 
12、如果在测试过程中发现了BUG，可是开发不承认这是Bug，你会怎么办？
   分析：HR问这个问题主要还是想知道你平时是如何处理与同事之间的关系。开发和测试是两个即对立又统一的两个岗位，所以开发和测试之间关系的处理也是HR面试过程中需要考虑的一个点。当然，HR问这个问题也表名该公司有氛围不是很好的风险。
   回答：首先还是应该回归到客户需求上面，确认这个问题到底属不属于一个缺陷，如果确实是则要和开发同事解释清楚；如果开发还是坚持自己想法的话，则询问同事或者测试组长的意见，讨论这个问题到底属不属于缺陷问题，如果大家都觉得是则需要和开发解释清楚。
 
13、你们公司的需求评审是怎么进行的？
   分析：需求评审，就是对客户需求，软件各个模块之间模糊的点进行审查，排除不理解或者没有考虑到的点。
   回答：需求评审，在一些分工比较明确的公司，都是由PD（产品设计师）负责，需求确认好后再下发到开发和测试部门；分工不怎么明确的公司可能就是开发测试产品等大家坐在一起共同探讨；评审形式一般分为线上和线下两种方式，负责人一般会提前把需求文档下发到大家手上供大家整理各自的疑惑点，为后续的评审会议做准备。
 
14、MySQL的常用命令有哪些？
   分析：数据库知识，是测试工程师必备的一个基本技能，在面试过程中也是经常会遇到的一个考点。对于刚入行的测试，对数据库知识的要求不会太高，只要求能掌握基本的增删改查语句即可。关于数据库的知识，在后续的时间里，也会慢慢的整理出来，供大家学习、参考。
   回答：这里只给出几个标准的语法结构：
         增：insert into 表名（列名） values （数据）;
     如：在stu表中插入id为001，姓名为张三的学生，(insert into Stu（stu_id，stu_name） values （001,‘张三’）;）
         删：delete from 表名 where 指定数据;
     如：在stu表中删除id为001，姓名为张三的学生:(detele from Stu where stu_id=‘001’ and stu_name = ‘张三’;）
         改：update 表名 set 改变项 where 指定数据;
     如：在stu表中修改id为001的学生姓名为“张三”:(update Stu set stu_name = ‘张三’ where stu_id=‘001’ ;）
         查：select （查询项） from 表名 where 指定条件;
     如：在stu表中查询id为001，姓名为“张三”的学生信息:(select * from Stu where stu_name = ‘张三’ and stu_id=‘001’ ;）
 
15、Linux下的一些常用命令是什么？
   分析：Linux系统，也是软件测试工程师必须要掌握的一项基本的技能，由于Linux具有运行稳定等很多优点，软件的服务器大多部署在Linux系统上，搭建测试环境也是测试工程师需要掌握的。关于Linux的知识，在后续的时间里，也会慢慢的整理出来，供大家学习、参考。由于Linux下很多命令都是常用的，所以这里不给出答案。
 
16、你未来的职业规划是什么？
   分析：职业规划问题，是所有面试中最常问的问题，问的人可能是HR、部门主管、经理、甚至是董事长。同一个问题，问的人不同，想要获取的信息也肯定是不一样的。HR更多的想看你在公司的稳定性；技术主管可能更想知道你是否真的喜欢测试这个岗位，后期是否会主动学习型新的技能等；而经理更多的是看你的职业规划符不符合公司的发展方向；软件测试工程师的发展方向主要有：测试开发、产品经理、测试转开发、测试大牛、讲师等岗位；
   回答：HR：如果是HR问的话，多从稳定性的角度回答，如：家人、朋友都在公司附近，或者喜欢贵公司的文化氛围等；
         技术：回答之前可以先简单介绍一下自己为什么选择软件测试这个职业，以及自己对这个职业的看法，最后再回答自己的职业发展方向即可；
         经理or董事长：这个回答回答起来的话还是比较难把握的，因为在面试时，面试者往往对公司的发展方向不是非常了解，所以在回答时可以再带一句，“具体的发展方向，还需要公司的发展方向去调整”。这样回答就会保险一些。
 
17、还有什么想要问我的吗？
   分析：这个问题在每个面试的尾声都会被问到，直接说没有，会让HR觉得你不关心这个岗位，问的多了又会显得面试之前没有做好充分的准备。所以问题一般控制在两到三个比较好。
   回答：1、公司的研发团队目前是什么规模？开发、测试分别有多少人？
         2、公司的业务方向是什么？
         3、如果我入职之后，我的工作职责是什么？
 
18、为什么想要离职？
   分析：这个问题主要是想要了解你的近况，以及上一家公司是什么原因导致你离职，。在大部分情况下，HR都会理解你，但是在回答问题时千万不能太过于实诚，有些面试者一上来就在抱怨上一家公司如何压榨公司员工等，没有一家公司愿意接受这样的面试者，HR并不能完全感受你所遭遇到的，所以还是请控制好自己的负面情绪。

目录
 
一、问题预测
 
 
让简单介绍下自己（每次面试开场）
 
 
让说下自己会的内容
 
 
看了哪些书籍（有问到）
 
 
了解过哪些技术博客/论坛（有问到）
 
 
是否了解软件测试需要掌握哪些知识（问到类似问题）
 
 
之前面试过，觉得自己需要补充哪些？做了哪些行动？
 
 
为什么做测试,觉得自己做测试有哪些优势？（有问到）
 
 
知道哪些Bug系统
 
 
9.测试用例的基本要素是?
 
二、介绍一下公司项目
 
三、技能方面
 
1、 数据库方面常识
 
2、 linux操作
 
3、缺陷方面（有问到）
 
4、用例部分
 
5、软件测试流程
 
6、网络相关
 
7、测试工具
 
8、其他概念问题
 
四、你还有什么想问的吗（必答）
 
五、简历模板
 
一、问题预测
 
让简单介绍下自己（这个不用说了每次面试开场）
 
你好，我叫xx，来自xx，毕业于xx。目前有两年的功能测试经验。最近的一份工作是xx公司，主要参与app系统测试，负责xxapp,一款类似抖音的短视频app功能测试，负责过的功能模块有拍摄、上传、搜索、推荐引擎等。主要运用边界值，等价类，错误推测等常见黑盒测试方法。
 
让说下自己会的内容
 
我熟悉软件测试基础理论和测试流程，测试方法等，有app测试、web测试、接口测试经验。熟悉数据库增删改查操作，熟悉使用测试管理工具。
 
看了哪些书籍（有问到）
 
软件测试，软件测试的艺术、软件测试实用教程，在我负责短视频的推荐引擎测试期间看完了项亮的《推荐系统实战》主要是推荐系统的评测部分。
 
了解过哪些技术博客/论坛（有问到）
 
51testing论坛，CSDN一些博客（面试经验：面试中会问具体哪些博客），和公众号（搜狗测试、软件测试资源分享）
 
是否了解软件测试需要掌握哪些知识（有问到类似问题）
 
软件测试基础知识，流程，测试用例方法，数据库相关知识，抓包分析，接口测试、测试工具、性能测试等。
 
之前面试过，觉得自己需要补充哪些？做了哪些行动？
 
很多公司对性能测试和自动化测试工具有要求，由于之前的工作主要涉及的是功能测试，所以这方面的知识储备不够。不过最近我在学习这方面的知识，希望以后在工作中能深入学习。
 
为什么做测试,觉得自己做测试有哪些优势？（有问到）
 
我觉得我个人的性格比较适合做测试。我比较细心耐心，考虑事情比较全面，这样对于我在设计测试用例时很有帮助，而且我能够很好的与人协调沟通，当我们测试和开发发生沟通上的矛盾时我也能很好的解决，我平常喜欢刷微博、知乎看热门评论，喜欢考究大众心理，这有助于我站在用户角度设计测试点。
 
知道哪些Bug系统
 
禅道/bugzila等
 
9.测试用例的基本要素是?
 
版本号，功能模块，优先级别，前置条件，步骤，预期结果，实际结果等。
 
二、介绍一下公司项目
 
xxapp，是一款集短视频、游戏、直播、社交互动于一体的内容娱乐APP。公司大约一个月发布一个较大的版本，需求数20几个-40几个不等(用例数xx+)，每个版本包括的需求www\wap、后台以及客户端的需求。项目分客户端版本负责人、后台版本负责人、H5版本负责人等，负责人牵头及落实整个测试流程。我当过的角色有H5活动负责人、推荐引擎版本负责人、客户端和后台系统测试人员。负责过的模块用例数大概是500左右。
 
三、技能方面
 
1、数据库方面常识
 
l关系型数据库：把复杂的数据结构归结为简单的二元关系（即二维表格形式），通过SQL结构化查询语句存储数据
 
典型产品：
 
Mysql：互联网领域、大中小型网站，游戏公司，电商平台等等。体积小、速度快、成本低、开放源代码
 
Oracle：传统大企业、大公司、政府、金融、证券等。安全性、成本高、
 
l非关系型数据库：非关系型数据库也被成为NoSQL数据库，NOSQL的本意是“Not Olnly SQL”。NOSQL为了高性能、高并发而生
 
其他分类
 
1）键值（Key-Value）存储数据库：主要是使用一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。简单、易部署、高并发
 
典型：Redis、Memcached
 
2）列存储（Column-oriented）数据库：应对分布式存储的海量数据。如果我们有一个Person类，我们通常会一起查询他们的姓名和年龄，而不是薪资。这种情况下，姓名和年龄就会被放入一个列族中，而薪资则在另外一个列族中。
 
典型：Hbase
 
3）面向文档数据库：数据存储的最小单位是文档
 
典型：Mongodb、Hive
 
Mongodb一个介于关系型数据库和非关系型数据库之间的产品。高性能、易部署、易使用，存储数据非常方便。
 
Hive可以用来进行统计查询，HBase可以用来进行实时查询
 
一些增删改查笔试题准备
 
（另起一篇）
 
2、linux操作
 
linux搭建测试环境，比如web系统服务搭建。
 
一些常见命令准备
 
（另起一篇）
 
3、缺陷方面（有问到）
 
描述一个你印象最深刻的bug
 
在做上传视频的测试时，发现华为荣耀V10上传手机自带相机专业模式录制的视频会闪退。而ios上传同个视频提示合成失败。
 
我将手机自带相机录制的专业模式和普通模式录制的同样时长的视频发到电脑上，用格式工厂软件查看视频的不同之处，之后发现视频编码是不同的。
 
我继续网上查阅了视频编码方面的知识，发现mp4视频有几种编码，而继续测试验证发现我们的app上传的视频只支持mp4视频中的H.264编码格式。于是提交了视频上传不支持非H.264格式的视频。并补充完善了相关用例。
 
（因为在公司没有查日志权限，所以其实应该先查日志）
 
4、用例部分
 
现场让你设计个用例，比如水杯、凳子怎么测试？
 
首先说明的是，遇到这样的测试题目，首先应该反问面试官，需求是什么样的，比如是测什么样的杯子。
 
因为设计测试用例的规则应该是根据需求分析文档设计用例，客户需求什么，就测试什么。
 
但是在没有需求分析文档的前提下，来设计测试用例，可以考查一个测试人员的基本功，比如考虑问题是否全面，设计测试用例的方法是否合理等。
 
一般是根据自己的日常经验和测试的思维来设计测试用例。在设计测试用例时一般从以下几个方面进行分析：功能测试，性能测试，界面测试，安全性测试，兼容性测试，可用性测试，可靠性测试，本地化/国际化测试。
 
例子（另起一篇）
 
5、软件测试流程
 
公司严格规范测试流程和测试文档，首先是参与需求评审，编写测试计划、测试方案、测试用例，进行测试方案及用例的测试组内部评审，外部评审。
 
提取部分一级用例提交研发自测，研发自测通过后开开始执行一轮系统测试。
 
测试过程中发现并提交、跟踪问题。
 
问题修复后进行回归测试。
 
一轮测试完成后对修复包进行冒烟测试，测试通过则进行二轮测试。
 
二轮测试完成后会进行需求交叉测试。
 
完成测试编写系统测试报告提交验收测试。验收测试通过输出验收测试报告。
 
6、网络相关
 
网络协议，如TCP/UDP的区别？（https://www.cnblogs.com/steven520213/p/8005258.html）
 
1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
 
2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
 
3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
 
UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
 
4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
 
5、TCP首部开销20字节;UDP的首部开销小，只有8个字节
 
6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道
 
三次握手与四次挥手
 
三次握手通俗版：
 
第一次握手：客户端要和服务端进行通信，首先要告知服务端一声，遂发出一个SYN=1的连接请求信号,”服务端哥哥，我想给你说说话”。
 
第二次握手：当服务端接收到客户端的连接请求，此时要给客户端一个确认信息，”我知道了（ACK）,我这边已经准备好了，你现在能连吗（SYN）”。
 
第三次握手：当客户端收到了服务端的确认连接信息后，要礼貌的告知一下服务端，“好的，咱们开始联通吧（ACK）”。
 
到此整个建立连接的过程已经结束，接下来就是双方你一句我一句甚至同时交流传递信息的过程了。
 
四次挥手断开连接通俗版：
 
第一次挥手：双方交流的差不多了，此时客户端也已经结尾了，接下来要断开通信连接，所以告诉服务端“我说完了（FIN）”，此时自身形成等待结束连接的状态。
 
第二次挥手：服务端知道客户端已经没话说了，服务端此时还有两句话要给客户端说“我知道你说完了（ACK），我再说两句&*…%￥”…
 
第三次挥手：此时客户端洗耳恭听继续处于等待结束的状态，服务器端也说完了，自身此时处于等待关闭连接的状态，并对告诉客户端，“我说完了，咱们断了吧（FIN）”。
 
第四次挥手：客户端收知道服务端也说完了，也要告诉服务端一声（ACK），因为连接和断开要双方都按下关闭操作才能断开，客户端同时又为自己定义一个定时器，因为不知道刚才说的这句话能不能准确到达服务端（网络不稳定或者其他因素引起的网络原因）。
 
所以默认时间定为两个通信的最大时间之和，超出这个时间就默认服务器端已经接收到了自己的确认信息，此时客户端就关闭自身连接，服务器端一旦接收到客户端发来的确定通知就立刻关闭服务器端的连接。
 
到此为止双方整个通信过程就此终结。
 
这里要声明一下：断开链接不一定就是客户端，谁都可以先发起断开指令，另外客户端和服务端是没有固定标准的，谁先发起请求谁就是客户端。
 
三次握手阐述：
 
在第一次消息发送中，A随机选取一个序列号作为自己的初始序号发送给B；
 
第二次消息B使用ack对A的数据包进行确认，因为已经收到了序列号为x的数据包，准备接收序列号为x+1的包，所以ack=x+1，同时B告诉A自己的初始序列号，就是seq=y；
 
第三条消息A告诉B收到了B的确认消息并准备建立连接，A自己此条消息的序列号是x+1，所以seq=x+1，而ack=y+1是表示A正准备接收B序列号为y+1的数据包。
 
四次挥手阐述：
 
由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，
 
收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。
 
首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭，上图描述的即是如此。
 （1）第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
 （2）第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
 （3）第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
 （4）第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
 
7、测试工具
 
测试工具，无非这几类：
 
自动化测试工具 (如QTP)
 
性能测试工具 (如loadrunner)
 
测试管理类 （如jira）
 
安全测试工具
 
渗透测试工具
 
8、其他概念问题
 
Beta测试与Alpha测试有什么区别
 
1、Alpha测试
 
Alpha测试是由用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。开发者坐在用户旁边，这是在开发者受控的环境下进行的测试。由开发者随时记录下错误情况和使用中的问题。
 
2、Beta测试
 
Beta测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，这是在开发者无法控制的环境下进行的测试。由用户记录下遇到的所有问题，定期向开发者报告。beta测试是一模拟真实的使用环境从而发现缺陷的一种测试
 
3、验收测试
 
验收测试是以用户为主的测试，软件开发和QA人员也应该参加，测试一般在用户所在地进行，由用户验证软件产品是否满足了所有的需求的一系列的验收测试工作。
 
仅限于做项目的公司，部门内部测试稳定后，根据合同中需求由发包商进行验收测试。验收测试的目的是为了以发现”未实现的需求”为目的，以评估”适合使用”为目标，该类测试的不是以发现缺陷为主要目的。
 
区别：两者的主要区别是测试的场所不同。
 
Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。
 
而beta测试的环境是不受开发方控制的,谁也不知道用户如何折磨软件,用户数量相对比较多,时间不集中。
 
一般地,alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。如果产品通过了beta测试,那么就可以正式发行了。
 
Alpha测试在系统开发接近完成时对应用系统的测试；测试后仍然会有少量的设计变更。这种测试一般由最终用户或其它人员完成，不能由程序或测试员完成。
 
Beta测试 当开发和测试根本完成时所做的测试，最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其它人员完成，不能由程序员或测试员完成。
 
四、你还有什么想问的吗（必答）
 
我非常希望能够加入公司，所以想请问您觉得我还有哪些地方比较不足，能否给一些建议？以及是否有复试时间呢？
 
五、简历模板
 
可在公众号《软件测试er》回复‘简历模板’获取
 文章首发于公众号
 
关于我准备后的面试经历、面试题汇总、面试结果
 
有兴趣请继续关注~