今天完成的事情：（一定要写非常细致的内容，比如说学会了盒子模型，了解了Margin） 

重新梳理任务一的深度思考

知道了一些对之后出去找工作有用的项目，找时间会去好好复盘

明天计划的事情：（一定要写非常细致的内容） 

梳理任务二知识点

遇到的问题：（遇到什么困难，怎么解决的） 

暂无

收获：（通过今天的学习，学到了什么知识）

1.    什么是敏捷开发? 

敏捷开发，强调去文档化、去流程化，追求高效沟通和合作，是一种让所有开发人员参与讨论，分阶段性的，不断反馈项目进度的开发方法。

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。

敏捷开发的原则：1. 快速迭代2. 让测试人员和开发者参与需求讨论3. 编写可测试的需求文档4. 多沟通，尽量减少文档5. 做好产品原型6. 及早考虑测试

个人看法：

敏捷开发简单说就是用有效的办法去做有用的事情，过程的目的是让项目做得更好，不是为了过程而过程，不用过程来“框死”项目，过程是可变的，是要为项目服务的。

2.    如何做需求分析？

从用户提出的需求出发，挖掘用户内心真正的目标，并转为为产品需求，需求分析的过程是思考如何把用户需求转化为产品需求，我们不能简单地看用户需求，而是应该去挖掘用户产生这个需求时，其心里是什么驱动着用户。

用户需求：是用户从自身角度出发，自以为的需求。

产品需求：是提炼分析用户真实需求，并符合产品定位的解决方案。

要充分了解人性，知道用户需求是怎么产生的，才可能通过产品需求去迎合用户需求，在挖掘用户需求同时，还要判断是伪需求还是真需求。

需求分析要先从用户的动机入手，找准目标用户群体，然后找到目标用户的真实需求，还要综合考虑该需求的价值（广度/频率/强度/时机）。

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

Bug其实一直都在,多熟练的工程师都没用。只是谁先发现而已，Bug就像是宿命一样，伴随着程序员的终生。我们想做的，能做的，就是尽可能的减少Bug，以及在测试环境发现Bug后，快速的修复Bug。

正常来说，只要Bug不影响到核心业务流程，不影响主要功能使用和项目上线时间，仅仅影响用户体验的非关键业务逻辑，是可以上线之后再发布Bug的修复，这通常都是由产品经理、测试人员和公司主要负责人共同的决定

4.边界测试，功能测试，冒烟测试，黑盒测试，自动化测试，回归测试，性能测试的含义分别是什么，应该谁来主导，原因是什么？ 

边界测试：定义输入条件一定范围，测试的时候取范围边界或者超过边界的值进行测试

功能测试：对产品的各功能进行测试，根据功能测试用例逐步检测

冒烟测试：对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性，不强调程序的主要功能，只对基本功能进行测试，耗时短

黑盒测试：把被测的软件看作是一个黑盒子，不去关心盒子里面的结构什么样，只关心软件的输入数据和输出结果，通过测试检测每个功能是否都能正常使用，主要注重于软件的功能需求，而非逻辑结构

自动化测试：通过预设条件下运行系统或应用程序来测试一个软件的功能。可以重复的执行程序来进行相同测试，得出测试结果，但是需要注意的是，预设条件应包括正常条件和异常条件

回归测试：修改了旧代码以后，重新运行测试以确认修改后没有引入新的错误或导致其他代码产生错误

性能测试：软件的性能主要有时间性能和空间性能两种，可以通过自动化的测试工具模拟多种正常、峰值、异常负载条件来对系统的各项性能指标进行测试

主导人：如果有专门的测试人员（QA），应由测试人员负责。

原因：专门的工作就要由专门的人负责。

5.Bug如果长时间未得到解决，应该怎么处理？做为PM，是否应该推动Bug的解决，如果PM成Bug的推动者，会不会导致开发人员越来越不主动？

PM已经通知开发人员但Bug长时间内依旧未得到解决，需要及时反馈上级以推进工作

PM可以成为Bug的推动者之一，但是PM不是作为一个主要的、长期的推动者，在一个成熟且中等规模以上的公司，往往是公司的体制决定一切，做项目不是一个人的事。

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

重要的依据就是，对这个Demo进行多方面的测试，看看它是否还存在Major级别以上的Bug，若是Demo中无明显可见性错误，功能可正常运行，不影响使用就可以通过。

7.常用的Bug管理工具有哪些，互相之间有什么差别，你更喜欢哪一种，为什么？ 

1、 QC(Quality Center) 2、 Bugzilla 3、BugFree（禅道）4、 EasyBUG 5、 Mantis

6、Jira 7、Bugtags  8、 Trac 9、Gitlab 10、Redmine
本人没有进行过相关的工具使用，暂不做评述

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

因为线上很慎重，没有人敢轻易把未经验证的代码发布到线上

开发环境：是研发团队的领地，开发人员写代码的环境，可以把开发环境当成是蛮荒之地，项目尚且在编码阶段，编写和修改代码相对来说是比较随意。   

主要是开发人员主导

测试环境：处于项目完成开发正查找bug阶段.是测试人员所掌控的世界，在这里，所有的Bug的发现，流转，验收和版本的管理，必须摆脱开发环境的野蛮和无序。

主要是由测试人员主导

线上环境：处于真实运营、产品已经发布阶段，要求不能有影响用户功能使用的bug，如果有Major级别以上的Bug出现，优先级始终排在最高级。

主要是用产品用户主导

9.什么是版本回滚，在发布上线的过程中，如果发布不成功，多久之内应该要回滚，谁来决定，原因是什么？

回滚（Rollback）指的是程序或数据处理错误，将程序或数据恢复到上一次正确状态的行为。回滚包括程序回滚和数据回滚等类型

同理延伸出版本回滚，在此次版本中程序或数据处理出现问题后，在造成较大影响前，需要及时将版本恢复到上一版的状态。

这通常都是由产品经理、测试人员和公司主要负责人共同的决定

任何一个项目都不能由一个人说了算，最重要的是综合考量，合理安排计划，版本回滚是被迫处理方式，问题需要立即找到，并要在有限的时间高效的最低损失的情况下完成。

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

关于系统能否发布上线的一个非常重要的依据就是，是否还存在Major级别以上的Bug，

存在影响到核心功能无法正常运行的致命bug是不允许上线，如果时间紧，可以尝试把这个模块去掉，先去上线没有问题的模块。

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

Bug的优先级是用来标志Bug的严重程度，以便用于在Bug修复和上线之间提供决策支持。五种级别的划分，分别对应有它自己的含义：

Critical的Bug是最严重的，代表着系统崩溃，完全不可用。

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

Block的Bug也是非常严重的，它的含义是，用户的操作被卡住了，无法进行下一步

拿12306来说，当你选好车票的时候，想要点击购买，这个时候却发现购买按钮点击之后无法使用，而其他的一切功能都正常

Major的Bug是严重的，也是在Bug体系里的一个分界线。Major的Bug通常是指流程可以走的通，但是关键的业务或者是数据错误，影响用户的正常使用。

继续拿12306来说，比如你已经付款成功，但买的是一等座的票，出来的却是二等座的票面信息。

Normal的Bug就比较常见了，像一些分支业务逻辑里，偶尔会出现的问题，又或者是一些不太重要的地方出现的错误。

通俗的说对大部分用户来说都无关紧要，可用可不用，我们知道他有Bug，但没关系，我可以等等。

Minor的Bug，指那些无伤大雅的小问题。

通常是指兼容性，不重要的文案错别字，样式错误等

要注意的就是，Bug的严重程度和它易于修复的程度并不总是一致。

举个例子，当用户打开网址的时候发现打不开，这是非常严重的，Critical级别的Bug。

最后发现原因很简单，域名过期，解决方案也很简单，就是交钱续费而已。

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

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

New:缺陷的初始状态

Assigned:指派开发人员修改

Open:开发人员开始修改缺陷

Fixed:开发人员修改缺陷完毕

Pending reset:待测试人员再次测试

Reset:测试人员正在再次测试中

Closed:回归测试通过

再次测试之后确认bug 已经被解决。

Reopen回归测试失败

如果经过再次测试发现bug（前提是bug本身存在而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组。

Rostpone:推迟修改

Rejected:开发人员认为不是程序问题,拒绝缺陷

Duplicate:与已经提交的Defect重复

Defect: 缺陷，包含 bug，可能是不满足易用性的一些小问题

Abandon:被Rejrect 和Duplicate的Defect,测试人员确认的确不是问题后,将Defect置为此状态

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

测试用例：简单来说，就是有条不紊的给系统挑刺，然后做记录。用一个固定的模板，来把我们做过所有开脑洞的测试记录下来，这个，就是测试用例

前置条件：指要达到预期测试结果，需要满足那些条件才能达到。如：账号密码不一致时，就需要登录失败，那么此时就得保证账号正确或密码正确以及账号正确时是存在的

预期结果：前置条件下，进行相对应步骤操作，所期望或预想到的结果

注册状态：注册用户名是否合规、是否已注册、密码是否符合要求，验证码是否正确

若有手机或邮箱验证，延伸，手机和邮箱格式是否正确，验证码是否正确，验证码是否成功发送

登录状态：账号是否合规、密码是否合规、账号密码都正确、账号正确密码不正确、账号不正确密码正确

短信快捷登陆，手机号码是否存在，验证码是否正确，第三方登陆，是否能正确读取第三方资料并成功跳转

忘记密码状态，提供邮箱或者绑定手机号码找回，通过相应的验证后，提供密码重置服务

14.什么是产品经理?

产品经理角色就是对一个产品负根本责任的管理者，产品经理主要的工作就是：规划、设计产品，对产品研发过程的控制，最终把产品卖出去的一个过程。