平安科技面试题部分
1、什么是敏捷模型和瀑布模型？
2、为什么要使用jenkins/使用jenkins的好处?
3、说说你对持续集成的理解？
WPS面试问题
惯常先进行自我介绍，介绍完之后根据我的介绍内容问我，在接口测试时有遇到什么问题吗？如何解决？再问对所在实习公司有没有不满的地方？为什么不在实习公司转正？给你一张A4白纸，你如何测试它？评价你最好的一个朋友。然后最后一个问题是有什么问题想了解的。
下面对平安科技所问的问题进行一个了解、梳理和介绍，并不是我面试时的回答哈。自行了解，然后总结提炼，面试时有被问到的话，能全部回答完整固然最好，但不能完整回答上也没关系，了解一下有个印象，不至于只会回答不知道￣□￣｜｜
1、什么是瀑布模型、什么是敏捷开发？
瀑布模型
1970年WinSTon Royce提出了著名的"瀑布模型"，将软件生命周期划分为制定计划、需求分析、概要设计，详细设计、程序编写、软件测试和运行维护等基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
瀑布模型严格定义了各阶段的输入输出，如果某一阶段没有达到要求的输出，将不会进行下一阶段。
瀑布模型的特点：
各阶段划分很明确，便于项目经理对进度的把控，但是缺乏灵活性。
适用于需求很明确的项目，因此对于客户需求的变化很难适应。
以文档作为驱动，每一阶段都需要输出相应的文档，作为每一阶段审核的标准，因此极大地增加了工作量。
强调了每个阶段的严格性，只有前一阶段通过审核才能进入下一阶段的设计。开发前期良好的需求说明，是最终系统正确性和完整性的保证。
由于开发模型是线性的，早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
用户只有等到末期才能见到开发成果。
由瀑布模型引入敏捷开发
敏捷开发是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重作为软件开发中人的作用。
什么是敏捷开发？
敏捷开发的核心是迭代
其特点是：
1.个人和交互重于流程和工具
2.有效的软件重于全面的文档
3.客户合作重于合同谈判
4.因时制宜重于按步就班
5.敏捷开发的优势？
以客户满意度为主。客户会看到产品设计的每一步并在此基础上做出反馈，这时候你需要迅速的做出调整
拥抱变化。客户最关心的是设计出的软件能够满足其需求，因此这就需要开发人员清楚客户要得到什么就要迅速实现什么。这样软件的每个子项目都会根据需求进行调整，并不会对其它子项目产生不好的影响
频繁交付。从几周到几个月应该交付更新，时间越短越好。及时交付客户维系好的客户关系，并根据客户反馈的信息，并作出相应的调整。
面对面的交流。由于领域的区别，客户只是业务了解，而软件开发人员只对软件熟悉，这就可能导致沟通之间出现理解偏差，因为常常在一起工作显得很必然。
参考从瀑布模型到敏捷开发
2、为什么要使用jenkins/使用jenkins的好处?
发布的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量。
3、说说你对持续集成的理解？
持续集成指的是，频繁地(一天多次)将代码集成到主干。它的目的是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。
根据持续集成的设计，代码从提交到生产，整个过程有以下几步。
1. 提交
流程的第一步，是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交(commit)。
2. 测试(第一轮)
代码仓库对commit操作配置了钩子(hook)，只要提交代码或者合并进主干，就会跑自动化测试。
测试有好几种。
单元测试：针对函数或模块的测试
集成测试：针对整体产品的某个功能的测试，又称功能测试
端对端测试：从用户界面直达数据库的全链路测试
第一轮至少要跑单元测试。
3. 构建
通过第一轮测试，代码就可以合并进主干，就算可以交付了。
交付后，就先进行构建(build)，再进入第二轮测试。所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源(样式表、JS脚本、图片)等等。
常用的构建工具如下。
List item
Jenkins
Travis
Codeship
Strider
Jenkins和Strider是开源软件，Travis和Codeship对于开源项目可以免费使用。它们都会将构建和测试，在一次运行中执行完成。
4. 测试(第二轮)
构建完成，就要进行第二轮测试。如果第一轮已经涵盖了所有测试内容，第二轮可以省略，当然，这时构建步骤也要移到第一轮测试前面。
第二轮是全面测试，单元测试和集成测试都会跑，有条件的话，也要做端对端测试。所有测试以自动化为主，少数无法自动化的测试用例，就要人工跑。
需要强调的是，新版本的每一个更新点都必须测试到。如果测试的覆盖率不高，进入后面的部署阶段后，很可能会出现严重的问题。
5. 部署
通过了第二轮测试，当前代码就是一个可以直接部署的版本(artifact)。将这个版本的所有文件打包( tar filename.tar * )存档，发到生产服务器。
生产服务器将打包文件，解包成本地的一个目录，再将运行路径的符号链接(symlink)指向这个目录，然后重新启动应用。这方面的部署工具有Ansible，Chef，Puppet等。
6. 回滚
一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接，指向上一个版本的目录。
