软件测试工程师面试题

1.几分钟介绍一下自己

2.为什么选择测试这行？
因为其具有挑战性和成就感，找一些系统隐藏的逻辑漏洞的时候，自己就非常的开心。并且测试需要细心和耐心，自己可以很快的分析bug的来源。

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

4.一个测试工程师应该具备哪些素质和技能？
掌握基本的测试基础理论
本着找出软件存在的问题的态度进行测试，不要以挑刺的形象出现
可熟练阅读需求规格说明书等文档
以用户的观点看问题
有强烈的质量意识
细心和责任心
良好的有效的沟通方式(与开发人员及客户)
具有以往的测试经验能够及时准确的判断出高危险区在何处

5.请描述下你公司的测试流程？
需求分析讨论-确定测试策略-设计测试用例-测试用例评审-beta测试-uat测试-测试报告

6.你是测试组长，您是怎样管理团队的？
我会对成员的思想做一个较为全面的了解，分析项目的形势，当前的状况，未来的发展方向、目标，让每个成员都参与到项目的讨论中；人员的分配要合理，要能适应岗位的要求，明确其应有的岗位职责，根据能力高低来分配工作，对实位的奖惩要符合其岗位的重要程度；制定公司的规章制度，并严格执行，领导的激励也不可缺少。

7.你工作中的沟通对象一般都是哪些人？
(1).产品、开发、UI/UE设计
(2).市场、运维、运营
(3).领导、下属

8.您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？
做过web测试，小程序测试，H5页面测试，后台测试，接口测试。最擅长接口测试，自己给公司的业务流程写过一套自动化框架，用于回归业务流程。

9.软件生命周期概念是什么？
需求分析 —》可行性分析 —》概要设计 —》详细设计 —》编码实现 —》调试和测试 —》软件验收与应用 —》维护升级 —》废弃

10.软件测试分类
1.按照开发阶段划分软件测试：单元测试、集成测试、系统测试、验收测试。
2.按照测试实施组织划分软件测试：开发方测试、用户测试(alpha测试，Beta测试)、第三方测试。
3.按照测试技术划分：白盒测试、灰盒测试、黑盒测试。
软件测试方法和技术的分类与软件开发过程相关联，它贯穿了整个软件生命周期。

11.测试的目的是什么？
测试的目的是找出软件产品中的错误，使软件尽可能的符合用户的要求。当然软件测试是不可能找出全部错误的。
1.发现:被测对象与用户需求之间的差异
2.增加:用户对被测对象的质量信息
3.获取被测对象信息,为决策提供依据
4.为软件质量的可持续运行提供保障
5.预防Bug,降低风险

12.软件测试原则是什么？

1. 所有的软件测试都应追溯到用户需求。
2. 应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。
3. 完全测试是不可能的，测试需要终止。
4. 测试无法显示软件潜在的缺陷。
5. 充分注意测试中的群集现象。
6. 程序员应避免检查自己的程序。
7. 尽量避免测试的随意性

13.软件测试的流程是什么？

• 需求调查：全面了解系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等。根据系统概况进行项目所需的人员、时间和工作量估计以及项目报价，制定初步的项目计划。
• 测试准备：组织测试团队、培训、建立测试和管理环境等。
• 测试设计：按照测试要求进行每个测试项的测试设计，包括测试用例的设计和测试脚本的开发等。
• 测试实施：按照测试计划实施测试。
• 测试评估：根据测试的结果，出具测试评估报告。

14.测试分为哪几个阶段？
一般来说分为5个阶段：单元测试、集成测试、确认测试、系统测试、验收测试

15.了解 bug 处理流程吗？

bug分级;优先级（高中低）、严重程度（高中低）
bug分类：UI、系统、接口
bug状态：新建、待修改、待验证、已验证、遗留、关闭

16.一条bug记录包含哪些内容？
1.测试工程师、开发人员、bug日期
2.bug标题, bug正文, bug附件
3.bug优先级、bug严重等级
4.bug所属模块
5.bug状态(新建、已修复、已验证、遗留等)
6.bug处理记录

17.常见的测试用例设计方法
等价类
边界值
判定表
场景法
错误推测法

18.白盒和黑盒的区别，你是怎么运用的？

• 黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。利用其检查功能是否符合需求说明书，能够正常使用。
• 白盒测试：已知产品的内部工作过程，可以进行测试证明每种内部操作是否符合设计规格要求，所有内部成分是否经过检查利用其检查程序模块的内部逻辑走向，主要覆盖程序内的逻辑。

19.列举几个黑盒测试方法：
等价类/边界值、决策表、状态转换图、决策树和正交测试法

20.没有产品说明书和需求文档地情况下能够进行黑盒测试吗？
这个问题是测试工程师经常遇到的问题，根源就是软件开发文档管理不规范，对变更的管理方法就更不合理了。实际上没有任何文档的时候，测试人员是能够进行黑盒测试的，这种测试方式我们可以称之为探索测试，具体做法就是测试工程师根据自己的专业技能、领域知识等不断的深入了解测试对象、理解软件功能，进而发现缺陷。
在这种做法基本上把软件当成了产品说明书，测试过程中要和开发人员不断的进行交流。尤其在作项目的时候，进度压力比较大，可以作为加急测试方案。最大的风险是不知道有些特性是否被遗漏。

21.列举几个白盒测试方法：
语句、分支、条件、判定/条件、MC/DC、路径和控制流覆盖

22.如何对模块接口进行白盒测试？
模块接口测试重点检查进出模块的数据是否正确。
主要检查的内容包括以下几个方面：
模块的实际输入与定义的输入是否一致，包括检查参数个数、类型、顺序等。
模块中对于非内部／局部变量是否合理使用。
使用其他模块时，是否检查该模块的可用性和处理结果。
使用外部资源时，是否检查了可用性并及时释放资源，这些资源包括内存、文件、硬盘、端口等。

23.平常用什么工具测接口的
接口测试工具很多，首先postman
其次用jmeter

24.平常你是怎么测试接口的？

• 通过性验证：
  首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。
• 参数组合：
  现在有一个操作商品的接口，有个字段type，传1的时候代表修改商品，商品id、商品名称、价格有一个是必传的，type传2的时候是删除商品，
  商品id是必传的，这样的，就要测参数组合了，type传1的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。
• 接口安全：
  1、绕过验证，比如说购买了一个商品，它的价格是300元，那我在提交订单时候，我把这个商品的价格改成3元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？
  2、绕过身份授权，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功
  3、参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，加密规则是否容易破解。
  4、密码安全规则，密码的复杂程度校验
• 异常验证：
  所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是10的，传11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。
• 性能测试：
  接口并发情况，如上面提到的：一个账号，同时（大于2个请求）对最后一个商品下单，或不同账号，对最后一个商品下单
  接口响应时间，响应时间太长了，肯定需要优化，一般都是毫秒级别

25.POST和GET的区别？
本质上没有区别，是HTTP协议中的两种发送请求的方法，HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。

1、传送方式：get通过地址栏传输，post通过报文传输。
2、传送长度：get参数有长度限制（受限于url长度），而post无限制
3、GET和POST还有一个重大区别，简单的说：
GET产生一个TCP数据包；POST产生两个TCP数据包

26.cookie和session的区别
（1）cookie数据存放在客户的浏览器上，session数据放在服务器上
（2）cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session
（3）session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面应当使用cookie
（4）单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie
（5）可以将登陆信息等重要信息存放为session；其他信息需要保存，可以放在cookie

27.请求接口中常见的返回状态码
1xx – 信息提示（表示临时的响应。客户端在收到常规响应之前，准备接收一个或多个1xx响应）
2xx – 成功（表明服务器成功地接受了客户端请求）
3xx – 重定向（客户端浏览器必须采取更多操作来实现请求。例如，浏览器可能不得不请求服务器上的不同的页面，或通过代理服务器重复该请求）
4xx – 客户端错误（发送错误，客户端有问题。例如，客户端请求不存在的页面，客户端未提供有效的身份证验证信息）
5xx – 服务器错误（服务器由于遇到错误而不能完成该请求）
常见的有
（1）200 OK - [GET]：服务器成功返回用户请求的数据
（2）201 CREATED - [POST/PUT/PATCH]：用户新建或修改数据成功
（3）202 Aceepted - []：表示一个请求已经进入后台排队（异步任务）
（4）204 NO CONTENT - [DELETE]：用户删除数据成功
（5）400 INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作
（6）401 Unauthorized -[] ：表示用户没有权限（令牌、用户名、密码错误）
（7）403 Forbidden -[] ：表示用户得到授权（与401错误相对），但是访问被禁止
（8）404 NOT FOUND -[]：用户发出的请求针对得到是不存在的记录，服务器没有进行操作，该操作是幂等的
（9）406 Not Acceptable - [GET]：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）。
（10）410 Gone -[GET]：用户请求的资源被永久删除，且不会再得到的。
（11）422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误。
（12）500 INTERNAL SERVER ERROR - [*]：服务器发生错误，用户将无法判断发出的请求是否成功。

28.如何分析一个bug是前端还是后端的
这种情况很容易判断，先抓包看请求报文，对着接口文档，看请求报文有没问题，有问题就是前端发的数据不对。
请求报文没问题，那就看返回报文，返回的数据不对，那就是后端开发的问题咯

29.压力测试和负载测试的区别
负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。
压力测试是在高负载情况下对系统的稳定性进行测试。是在高负载（大数据量、大量并发用户等）下的测试，观察系统在峰值使用情况下的表现，从而发现系统的功能隐患。
负载测试：多用户，用户数渐增，持续同时发同一业务请求，产出最大TPS；
压力测试：多用户，资源使用饱和，持续同时发同一业务请求，产出系统瓶颈或使用极限。

30.当开发人员说不是BUG时，你如何应付？
开发人员说不是BUG，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动。3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的一句是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来，跟开发经理和测试经理进行确认，如果要修改就改，如果不要修改就不改。其实有些真的不是BUG，我也只是建议的方式写进测试文档中，如果开发人员不修改也没有大问题。如果不是BUG的话，一定要坚持自己的立场，让问题得到最后的确认。

31.开发没时间修复，如何推进bug的修复
和开发说明该问题的严重性，会怎样影响产品的正常使用，如何还是坚持不改，就上报领导，让领导辅助推进；
确认问题的严重程度，如果影响不大，不是非要改的bug，并且修复风险比较大，和领导商量后，如果认为暂时可以不用修复，也可以不修复。

32.文档测试主要包含什么内容？
在国内软件开发管理中，文档管理几乎是最弱的一项，因而在测试工作中特别容易忽略文档测试也就不足为奇了。要想给用户提供完整的产品，文档测试是必不可少的。文档测试一般注重下面几个方面：
　　文档的完整性：主要是测试文档内容的全面性与完整性，从总体上把握文档的质量。例如用户手册应该包括软件的所有功能模块
　　描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度。例如用户手册基本完整后，我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度
　　易理解性：主要是检查文档对关键、重要的操作有无图文说明，文字、图表是否易于理解。对于关键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明了
　　文档中提供操作的实例：这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是否丰富，提供的实例描述是否详细。只有简单的图文说明，而无实例的用户手册看起来就像是软件界面的简单拷贝，对于用户来说，实际上没有什么帮助
印刷与包装质量：主要是检查软件文档的商品化程度。有些用户手册是简单打印、装订而成，过于粗糙，不易于用户保存。优秀的文档例如用户手册和技术白皮书，应提供商品化包装，并且印刷精美

33.安全性测试都包含哪些内容？
1,用户访问认证
2.传输数据加密
3.安全防护策略:如安全日志、入侵检测、隔离防护、漏洞扫描
4.数据备份与恢复
5.防病毒系统
6.SQL注入、JS注入

34.什么是自动化测试
自动化测试是一种使用自动化工具编写和执行测试人员测试脚本和案例的技术。
自动化测试的主要目标是减少手动运行的测试用例数量，而不是完全取消手动测试。

35.什么时候自动化测试？什么时候不自动化测试？

• 在以下情况下首选自动化
  • 重复性任务
  • 使用多个数据集进行测试
  • 回归测试用例
  • 通常，决定基于ROI（投资回报率）
• 人们不应该在以下情况下自动化
  • 当受测试的应用程序频繁更改时
  • 一次测试案例
  • 临时 - 随机测试

36.请描述一下自动化测试流程？
1.编写自动化测试计划
2.设计自动化测试用例
3.编写自动化测试框架和脚本
4.调试并维护脚本
5.无人值守测试
6.后期脚本维护（添加用例、开发更新版本）

37.常用的测试工具有哪些
1.网络调试工具：Fiddler
2.页面调试工具：Chrome Inspector firebug
3.WEB自动化工具：QTP、Selenium
4.移动端工具：ADB,Monkey, MonkeyRunner
5.移动端自动化框架：Appium 、Robotium 、Android、selendroid
6.平台知识：windows、mac、android、Linux
7.服务端压力工具：Loadrunner、JMter
8.接口测试工具：postman
9.数据库工具：mysql/mongodb 可视化工具
10.BUG管理平台：Gitlab、禅道、Jira

38.说明jmeter的工作原理？
jmeter就像一群将请求发送到目标服务器的用户一样。它收集来自目标服务器的响应以及其他统计数据，这些统计数据通过图形或表格显示应用程序或服务器的性能。

39.Jenkins的工作流程?

1. 开发人员提交代码到Git版本仓库；
2. Jenkins人工/定时触发项目构建；
3. Jenkins拉取代码、代码编码、打包镜像、推送到镜像仓库；
4. Jenkins在主机发布

40.登陆的时候，所有信息输入正确，点击登陆按钮没反应,可能原因有哪些？
1、浏览器兼容性问题；
2、网速太慢；
3、系统卡顿；
4、代码处理逻辑问题，没有做页面跳转或错误提示；

41.一个搜索的输入框，你会怎样进行测试
大范围：功能性、兼容性、稳定性、性能、安全、接口、线上监控、自动化
小范围：功能性、兼容性、安全
关于功能性测试
常规可输入的内容，数字、英文、中文、特殊符号、转义符等
非常规有一定含义的，HTML标签、CSS、js代码、URL等
输入内容的边界值，空字符、超长文本（边界值+1、-1）
关于兼容性测试
根据产品的用户分布，手机品牌、分辨率、topN的机型
根据产品在不同浏览器上的占有率，选择主要浏览器测试
兼容性主要关注的问题，页面渲染，页面布局等，借助firebug调试
关于稳定性测试
在某一压力下，搜索结果能正常返回
多次查询，返回的内容相对稳定。后台数据可能有波动，但是几分钟几秒钟内查询结果应该一致
关于性能测试
QPS，query per second，每秒钟能处理的请求数
从点击到页面全部加载，页面耗时情况（耗时与页面大小，资源数量有关）
关于安全性测试
JS注入 ——如在查询输入框中输入JS代码
SQL注入——搜索框输入SQL语句
做一些破坏
关于接口测试
查询接口正确性验证：使用postman等工具单发一些查询请求，查看返回内容
查询接口对异常数据的容错情况：查询乱七八糟的查询词，是否会返回无结果
查询接口在非浏览器情况下的处理情况：
a.查询接口很容意被高级用户拿到，他们会频发地去抓取页面。
b.页面会对查询做一些限制，如有些字符无法输入，但是通过接口会绕过页面的限制
关于自动化测试
基于selenium工具进行UI自动化测试，例行回归验证，提高效率
Android端可以使用appium+UIautomantor
关于线上监控
保证线上服务质量，建立实时监控。可以及时发现异常，减少对用户的影响

42.淘宝双十一凌晨服务挂了十分钟，工程师抢修之后，马上上线，又挂了，请问有哪些原因会造成这个情况？
服务器内存不够、服务器超出负载、并发量太大、遇到恶意攻击。

43.对杯子进行测试用例设计
界面测试:
查看杯子外观是否漂亮
功能性：
1 用水杯装水看漏不漏，水能不能被喝到
2 杯子是否能够容纳果汁、白水、酒精、汽油
可靠性（包括安全方面）：
杯子有没有毒或细菌，杯子从不同高度落下的损坏程度
易用性：
是否有防滑措施、是否方便饮用、杯子是否烫手、
效率（性能、压力方面）：
是否容易损坏，测试杯子抗破碎强度。
维护：
破损后，有没有修补措施
可移植性（包含兼容性）：
测试杯子在不同的地方、温度等环境下的使用情况

44.那如果你这边测试和开发那边测试结果不一致，怎么办？
1、先确认测试环境的代码是不是和开发那边的是一致的，因为有可能是开发没把代码提交到服务器，我们现在测试的版本还不是最新的；
2、如果测试环境的代码和开发的是一致的，就用fidder抓个包，看看问题是在前台还是后台，如果服务器返回的数据有问题，就把响应的服务器的日志取下来发给开发定位。

45.产品在上线后用户发现bug，这时测试人员应做哪些工作？
测试人员复现问题后，提交问题单进行跟踪；
评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
总结经验，分析问题发生的原因，避免下次出现同样问题。

46.在项目中发现哪些典型bug？什么原因导致的？
注册信息中的错误提示信息：如手机信息栏应填入11位有效电话号码，但提示信息却为“13位电话号码”，这是因开发人员粗心大意造成的。

• 接口bug：传的字段值为空，但是开发没给默认值导致接收不到。
• 数据用fiddler可以抓包拦截篡改数据。
• 弱网环境下订单可以重复提交。
• 验证码可以重复使用。
• 跑性能测试的时候，当前账号下的订单跑到别的账户上去了每次重新登陆都提示重设支付密码，而且设置的密码不能和上次相同。
• 在未登录的情况下添加商品到购物车跳转到登录页面，登录成功后购物车数量不会增加。
• 第一次提现申请未审核，再继续第二次提现申请无法成功。
• 前台发布数据，后台通过审核并且成功加入数据列表，前台搜索失败。

47.列举几个你常用的linux 命令
clear:清除屏幕
curl web请求
cd：切换目录
如：切换到D盘 cd D:
cd … ： 返回上一级目录
如：现在在c:\list\tcp
命令： cd…
结果是：退到 c:\list
ls-l ：查看所有文件的详细信息
Is-a：列出当前目录下所有文件
touch：创建文件
如：创建mook 文件夹 touch mook
mkdir：创建目录
echo：创建带有内容的文件
如：echo"hello mook">mookhello
内容是：hello mook
文件名是：mookhello
cat：查看文件内容
如：查看mookhello文件里面的内容
命令：cat mookhello
结果是hello mook
cp：拷贝
如：拷贝mookhello的文件重置名为mook2
命令：cp mookhello mook2
再执行查看：ls-l
结果是：出现mook2 的文件夹
cat mook2的内容是否与mookhello 的相同
mv：移动或重命名
如：mook2 重命名为mook3；
命令：mv mook2 mook3
rm-f：强制删除
如：删除 mook 文件；
命令： rm-f mook
rm-f 不能删除有文件的目录；只能使用 rm-r：递归删除
如：
rm-r：递归删除
如：删除 mooktest 目录
命令：rm-r mooktest
wc：统计文本中行数、字词、字符数
如：wc mookhello
结果：
1行 2字词 11个字符
cat mookhello
grep：在文本文件中查找某个字符串
如：grep mook mookhello
tree：显示目录结构
In：创建软链
如：ln -s mookhello mook2
结果：
more, less：分页显示文本内容
head, tail：显示文件头尾内容

48.查询所有学生的数学成绩，显示学生姓名name, 分数， 由高到低

SELECT a.name, b.score
FROM student a, grade b
WHERE a.id = b.id
AND kemu = '数学'
ORDER BY score
DESC

49.统计每个学生的总成绩,显示字段：姓名，总成绩

SELECT a.name, sum(b.score) as sum_score
FROM student a, grade b
WHERE a.id = b.id
GROUP BY name
DESC

50.什么是MongoDB?他的优势是什么？
是一个文档数据库，可提供高性能，高可用性和易扩展性。

• 自动分片。
• 丰富的查询功能。
• 快速的即时更新。
• 复制以及高可扩展性。
• 任何属性都可以建立索引。

51.什么是敏捷开发，和传统开发比较的优势和劣势？
敏捷开发是在上个世纪90年代，传统开发方式不能够满足现实开发的需要，对传统方式进行总结，对成功失败的开发案例进行研究后，得到的一种不同于传统方式的开发流程，主要的特点是迭代式进行，这种方式把一个软件开发过程分成了若干个小的迭代过程，每一迭代完成一部分功能，每一次迭代过程的工作内容按照功能的重要程度不同而排列，首先完成重要的，同时也是风险比较大的功能，而后是次重要的，依此类推，同时在每次迭代中，都要进行分析、设计、开发、测试，因为分成了一个个小过程，一步步的逼近目标，所以，可以使得产品的用户能够逐渐得明白自己的真实需求从而能够提出真正的需求，而开发团队也可以根据更正后的需求进行下一次迭代的设计。

• 优势
  敏捷开发的高适应性，以人为本的特性，和轻量型的开发方法即以测试为驱动取代了以文档为驱动，这三个主要的特点，也就是敏捷开发相对与传统开发方式的主要有点。因为他更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。
• 劣势
  与传统开发方式相比，敏捷开发的最主要的劣势在于敏捷开发欢迎新的需求，而在每次新的需求产生时都可能引起整个系统的大幅度的修改。因为开发者在开发上一个版本的时候，完全没有考虑以后的优化将要如何进行。这样的开发方式实际的软件开发过程中，并不一定总是有效的。
  而另一个方面，敏捷开发因为缺乏很多在敏捷开发中被认为“不重要”的文档，这样在一个大型项目比如一个操作系统开发的时候，由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交接的过程中出现很大的困难。