今天完成的事情：提交任务一通过，任务一的深度思考

明天计划的事情：开始任务二
遇到的问题：好多都没接触到，先搜集资料整理出来，在学习过程中纠错。
收获：

1. 什么是敏捷开发?  

敏捷开发（Agile）是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简单地来说，敏捷开发并不追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本。然后在后续的生产周期内，按照新需求不断迭代升级，完善产品。

　　敏捷软件开发特点：

　　首要任务是尽早地、持续地交付可评价的软件，以使客户满意。

　　乐于接受需求变更，即使在开发后期也是如此。敏捷软件开发能够驾驭需求的变化，从 而为客户赢得竞争优势。

　　频繁交付可使用的软件，交付的间隔越短越好，可以从几个月缩减到几个星期。

　　在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。

　　围绕那些有推动力的人们来构建项目，给予他们所需的环境和支持，并且相信他们能够把工作做好。

　　开发团队及在开发团队内部进行最快速、有效的传递信息的方法是面对面交谈。

　　可使用的软件是进度的主要衡量指标。

　　提倡可持续发展。出资人、开发人员及使用者应该共同维持稳定的开发速度。

　　为了增强敏捷能力，应持续关注技术上的杰出成果和良好的设计。

　　简洁，最小化那些没有必要投入的工作量是至关重要的。

　　最好的架构、需求和设计都源于自我组织的团队。

团队定期反思如何变得更有战斗力，然后相应地转变井调整其行为。

自我理解：敏捷开发就是快速开发出核心功能投入使用，后期不断完善、迭代。

2. 如何做需求分析？  
需求分析：从用户提出的需求出发，挖掘用户内心真正的目标，并转为为产品需求的过程。

1）软性分析

01.分析需求来源是否可靠？02.需求目的是什么？03.是最优的选择吗？04.需求符合现阶段的产品定位吗？

2）硬性分析

01.满足需求的条件成熟了吗？02.通过场景设想检验需求的合理性。03.现有数据对比。

3）结论分析01.需求的本质是什么？02.要不要满足需求？03.何时满足需求？

自我理解：从用户需求中提取出真正需求，通过权衡分析，提出产品需求

3. 怎么理解程序员会写出Bug这种事情，可不可以要求他们做到无Bug交付？怎么衡量Bug的修复时间和项目的上线时间冲突问题？  
有bug很正常，无bug交付是做不到的。优先级高的bug必须先修复再上线，优先级低的可以先上线在修复。

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

1）边界测试：边界测试是用来探测和验证代码在处理极端的或偏门的情况时会发生什么。
2）功能测试：功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。

3）冒烟测试：冒烟测试就是在每日build（构建版本）建立后，对系统的基本功能进行简单的测试。这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。

4）黑盒测试：黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。

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

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

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

5. Bug如果长时间未得到解决，应该怎么处理？做为PM，是否应该推动Bug的解决，如果PM成Bug的推动者，会不会导致开发人员越来越不主动？  
根据bug的严重程度处理，严重的bug推迟上线或已经上线的停机修复后再次上线；低优先级的bug可以下次版本迭代是修复。

大部分PM技术不如开发人员，bug的解决主要靠开发人员解决；PM也应该推动bug解决，注重团队合作和默契的培养。

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

测试Demo，根据测试结果的bug决定。没有严重和明显的bug，只有一些低优先级的bug的Demo可以通过

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

JIRA、Trac、gitlab、Bugzilla、Mantis   还没学到，之后再补

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

开发环境就是与测试环境分开的独立客户机、服务器、配置管理工具等。
测试环境是测试人员利用一些工具及数据所模拟出的、接近真实用户使用环境的环境，测试环境的目的是为了使测试结果更加真实有效。测试环境应该与开发环境分隔开，使用独立的客户机、服务器和配置管理工具。

线上环境即发布环境，真实用户访问的环境。

开发环境主导开发人员，测试环境主导测试人员，线上环境主导用户

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

版本回滚是回到上一版版本

开会后由产品负责人决定

10.什么样的Bug是允许上线的，什么样的Bug是不允许上线的？  
Major以上的bug不能上线，Major级的bug修复后上线，Minor级的bug可以上线后修复。

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

1）Bug的严重等级

1.Blocker即系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。

2.Critical即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。

3.Major即界面、性能缺陷、兼容性。

4.Minor即易用性及建议性问题。

2）Bug的优先等级

1.Immediate 即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。

2.Urgent 即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。

3.High 即“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。

4.Normal 即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。

5.Low 即“低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。

12.Bug的生命周期是怎么样的？什么情况下应该是Reopen？什么情况下去Close？  
生命周期中的一般缺陷状态：新建-->指派-->打开-->已解决-->待验-->关闭

如果待验的bug在验证时没有解决好，我们则需要进行循环，重新指派

中间其他状态：拒绝、延期等。

1.New（新的）

当某个bug被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New。

2.Assigned（已被指派的）

当一个bug被只认为New之后，将其提交给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为Assigned。

3.Open（打开的）

一旦开发人员处理bug的时候，他就将这个bug的状态设置为Open，这就表示开发人员正在处理这个bug

4.Fixd（已修复的）

当开发人员进行处理（并认为已经解决）之后，他就可以将这个bug的装填设置为 Fixed，并将其提交给开发组的负责人，然后开发组的负责人将这个bug返回给测试组。

5.Pending Reset（待再测试的）

当bug被返回到测试组后，我们将bug的状态设置为Pending Reset。

Reset（再测试）测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为reset

6.close（已关闭的）

如果测试人员经过再次测试之后确认bug已经被解决之后，就将bug的状态设置为“Close”

7.reopen（再次打开的）

如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug传递给开发组，并将bug的状态设置为“Reopen”

8.Pending Reject（拒绝中）

如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下，开发人员是可以拒绝，并将bug的装填设置为“Pending Reject”

9.Rejected（被拒绝的）

测试组的负责人接到上述bug的时候，如果他发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能作bug的时候，发现负责人就将这个bug的状态设置为Rejected。

自我理解

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

测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。 
前置条件即执行的条件比如登录账户的前提条件是账户及密码正确，登陆成功就是预期结果

功能测试：

1）输入正确的账号和密码，点击提交按钮，验证是否能正确登录。（正常输入）

2）输入错误的账号或者密码,验证登录会失败，并且提示相应的错误信息。（错误校验）

3）登录成功后能否能否跳转到正确的页面（低）

4）账号和密码，如果太短或者太长，应该怎么处理（安全性，密码太短时是否有提示）

5）账号和密码，中有特殊字符（比如空格），和其他非英文的情况（是否做了过滤）

6）记住账号的功能

7）登录失败后，不能记录密码的功能8）、账号和密码前后有空格的处理

9）密码是否加密显示（星号圆点等）

10）牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用

11）登录页面中的注册、忘记密码，登出用另一帐号登录等链接是否正确

12）输入密码的时候，大写键盘开启的时候要有提示信息。

13）什么都不输入，点击提交按钮，看提示信息。（非空检查）

界面测试(UI Test)：

1）布局是否合理，2个Testbox和一个按钮是否对齐

2）Testbox和按钮的长度，高度是否复合要求

3）界面的设计风格是否与UI的设计风格统一

4）界面中的文字简洁易懂，没有错别字。

性能测试(Performance Test)：

1）打开登录页面，需要几秒

2）输入正确的账号和密码后，登录成功跳转到新页面，不超过5秒

3）压力测试，最大承受多少人登陆

4）XX人数下并发登录，登录时间

安全性测试(Security Test)：

1）账号和密码是否通过加密的方式，发送给Web服务器

2）账号和密码的输入框，应该屏蔽SQL注入攻击

3）错误登录的次数限制（防止暴力破解）

4）考虑是否支持多用户在同一机器上登录

5）考虑一用户在多台机器上登录

兼容性测试（Compatibility Test）：

1）主流的浏览器下能否显示正常已经功能正常（IE6~11,FireFox,Chrome,Safari等）

2）不同的平台是否能正常工作，比如Windows,Mac

3）移动设备上是否正常工作，比如iPhone,Android

4）不同的分辨率

本地化测试（Localization Test）：不同语言环境下，页面的显示是否正确。

登录注册模块测试用例1.功能测试用例2.界面测试用例3.性能测试4.安全性测试5.兼容性测试6.本地化测试等

14. 什么是产品经理?  

发现需求从用户需求中提取出真正需求，通过对用户、技术、商业价值等权衡分析，从而完成需求的产品的人。