1什么是敏捷开发? 

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。谈需求变为功能的过程，这个需要用户体验，站在用户的角度去衡量。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

2如何做需求分析？ 

获取用户需求→分析用户需求→编写需求文档→评审需求文档→管理需求

通过外部用户数据和反馈、竞品分析、市场动态政策、合作伙伴反馈和内部同事、老板沟通、自己使用的产品或其他的产品去获取需求，并将这些需求进行筛选初步过滤后再编写需求文档，在对需求文档进行成本以及收益及其他因素的评审后增添或减少或调整相应的需求。

3怎么理解程序员会写出Bug这种事情，可不可以要求他们做到无Bug交付？怎么衡量Bug的修复时间和项目的上线时间冲突问题？

许多程序员是写不出无BUG的程序的，人人都会犯错。可以在交付项目的时候把最主要的功能实现要求做到精准，并预留相关优先级靠后的BUG修复时间，如果项目完成发现中大BUG可以与交付客户商量并探讨解决方案（优先让程序员加急解决）。

4边界测试，功能测试，冒烟测试，黑盒测试，自动化测试，回归测试，性能测试的含义分别是什么？

边界测试：就是用来探测和验证代码在处理极端的或偏门的情况时会发生什么。

功能测试：功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能

冒烟测试：就是完成一个新版本的开发后，对该版本最基本的功能进行测试，保证基本的功能和流程能走通。

自动化测试：软件测试的自动化，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。

黑盒测试：是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。

回归测试：用例回归和错误回归；用例回归是过一段时间以后再回头对以前使用过的用例在重新进行测试，看看会重新发现问题。错误回归，就是在新版本中，对以前版本中出现并修复的缺陷进行再次验证，并以缺陷为核心，对相关修改的部分进行测试的方法。

性能测试：是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

6怎么样判断Demo是否应该通过? 

Demo：能够展现产品的主要功能，特点，也许是以文字，ppt的方式，也许是一个小模型或者简单的几个界面之类的

进行综合讨论，该DEMO是否已准确且核心说明该产品的核心功能。

7常见BUG管理工具：QC， Bugzilla，BugFree ，EasyBUG，Mantis

8为什么要区分开发，测试，线上三个环境，三个环境之间的区别是什么？

开发环境是程序猿的pc或某专门用于开发的服务器，配置可以比较随意， 
为了开发调试方便，一般打开全部错误报告。   
测试环境一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。  
生产环境就是正式提供对外服务的，一般会关掉错误报告，打开错误日志。 

9什么样的Bug是允许上线的，什么样的Bug是不允许上线的？ 

不常常被执行，性能、兼容性、稳定性BUG允许上线，功能性BUG是不允许上线的。

10Bug的优先级是什么？一般会分成几个级别，分别对应什么含义？

Critical的Bug是最严重的，代表着系统崩溃，完全不可用。这种Bug出现，就是最严重的事故，完全打不开，比如说，网站无法访问，点击出现系统错误，直接跳转到404页面。

要注意的就是，Bug的严重程度和它易于修复的程度并不总是一致，举个例子，当用户打开修真院网址的时候发现打不开，这是非常严重的，Critical级别的Bug。最后发现原因很简单，域名过期，解决方案也很简单，就是交钱续费而已。

一个系统是否能正常运行，并不在于导致它不能运行的问题复杂或简单。

Block的Bug也是非常严重的，它的含义是，用户的操作被卡住了，无法进行下一步。系统并没有大规模的崩溃，而是无法进行到下一步。拿12306来说，当你选好车票的时候，想要点击购买，这个时候却发现购买按钮点击之后无法使用，而其他的一切功能都正常。

这就是Block级别的Bug，一个地方卡死，导致你无法进行下一步的操作。

通常，在线上出现的Critical和Block，都可以称之为事故了。

Major的Bug是严重的，也是在Bug体系里的一个分界线，绝大多数团队在初期的目标，都应该是在提交测试之前，完全消除Major级别的Bug，减少Normal级别的Bug数量。

Major的Bug通常是指流程可以走的通，但是关键的业务或者是数据错误，影响用户的正常使用。比如说，在修真院的师兄弟体系中，你加入了班级，按理来说应该分配一个师兄。你按提示完成操作，但是却没有被分配到任何师兄。

这种级别的Bug往往是不没有任何操作流程上的问题，但是就是和预期的结果不对，而且影响了用户的正常使用，特别是在关键业务逻辑上。

Normal的Bug就比较常见了，像一些分支业务逻辑里，偶尔会出现的问题，又或者是一些不太重要的地方出现的错误。通常我们知道他是一个Bug，但是对大部分用户来说都无关紧要，可以用，可以不用，我们知道他有Bug，噢，没关系，我可以等等。

Normal的Bug应该被控制数量，我们建议的数量，是在开发人员提交测试之后，不超过3个。

Normal的Bug通常情况下都很容易被发现，不需要花太大的力气去寻找。

Minor的Bug，指那些无伤大雅的小问题，通常是指兼容性，不重要的文案错别字，样式错误等。

这种Bug上原则上的修复时间看开发人员的空闲期。

以上五种Bug级别，分别对应了在系统中对用户使用时候的影响度。需要特别指出的是，很多人在时间特别赶，或者是不好的开发流程习惯中，喜欢用一个词来描述：主逻辑。

11Bug的生命周期是怎么样的？什么情况下应该是Reopen？什么情况下去Close？

bug的生命周期是指在Bug管理工具中，一个bug被发现到这个bug被关闭的过程，Bug的生命周期被分成的阶段是新建、指派、接受、修复、关闭。Reopen一个bug的情况是，回测发现此问题依然存在，那么Reopen，如果回测发现此问题已经改好，但是引发了别的问题，那么这个bug close，重新提交一个新bug。 

12什么是测试用例，为什么要写测试用例，测试用例中的前置条件是什么？预期结果是什么？一个登录注册的小模块，正常来讲，应该有多少个测试用例？ 

前置条件是指测试执行所必须的条件，如测试环境ready, 依赖的测试数据ready等。预期结果是指该功能正常情况下所展示出来的效果。一般有：

1必填项分别为空注册

2用户名含非法字符注册

3两次输入密码不一致注册

4密码含非法字符注册

5邮箱格式不正确却正确做出响应

6已经注册的用户名进行注册

7用户名和密码为最大值进行注册

8用户名长度为（最大值）+1进行注册

9密码长度为最大值+1注册

10用户名和密码为（最小值）注册

11用户名为最小值-1进行注册

12密码长度为最小值-1进行注册

13用户名长度在最小值和最大值之间进行注册。

14改变已存在用户的用户名大小写进行注册

15tab键是否响应

登录模块

1使用合法用户名和密码登录

2使用错误的用户名或密码登录

3用户名和密码均为空登录

4密码为空进行登录

5用户名为空登录

6改变合法用户名或密码的大小写登录

7在合法用户名或密码前、中、后插入空格

8使用已被禁用/删除的账号登录

9登录界面是否支持快捷功能tab和enter键

13什么是产品经理？

，产品经理在产品策划阶段主要做的是将产品从一个需求、一个痛点乃至一种情怀转为解决方案，再将这个解决方案表达给开发，让开发将其实现。

今天把深度思考学习了一遍，明天打算开始学习aurex的具体操作以及在复习一遍深度思考，在开始进行任务中相关内容。