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

学习了深度思考

1、什么是敏捷开发

一、迭代开发

敏捷开发的核心是迭代开发（iterative development）。敏捷一定是采用迭代开发的方式。

那么什么是"迭代开发"呢？迭代的英文是 iterative，直译为"重复"，迭代开发其实就是"重复开发"。

对于大型软件项目，传统的开发方式是采用一个大周期（比如一年）进行开发，整个过程就是一次"大开发"；迭代开发的方式则不一样，它将开发过程拆分成多个小周期，即一次"大开发"变成多次"小开发"，每次小开发都是同样的流程，所以看上去就好像重复在做同样的步骤。

举例来说，SpaceX 公司想造一个大推力火箭，将人类送到火星。但是，它不是一开始就造大火箭，而是先造一个最简陋的小火箭 Falcon 1。结果，第一次发射就爆炸了，直到第四次发射，才成功进入轨道。然后，开发了中型火箭 Falcon 9，九年中发射了70次。最后，才开发 Falcon 重型火箭。如果 SpaceX 不采用迭代开发，它可能直到现在还无法上天。

迭代开发将一个大任务，分解成多次连续的开发，本质就是逐步改进。开发者先快速发布一个有效但不完美的最简版本，然后不断迭代。每一次迭代都包含规划、设计、编码、测试、评估五个步骤，不断改进产品，添加新功能。通过频繁的发布，以及跟踪对前一次迭代的反馈，最终接近较完善的产品形态。

二、增量开发

迭代开发只是要求将开发分成多个迭代，并没有回答一个重要的问题：怎么划分迭代，哪个任务在这个迭代，哪个任务在下个迭代？这时，一般采用"增量开发"（incremental development）划分迭代。

所谓"增量开发"，指的是软件的每个版本，都会新增一个用户可以感知的完整功能。也就是说，按照新增功能来划分迭代。

举例来说，房产公司开发一个10栋楼的小区。如果采用增量开发的模式，该公司第一个迭代就是交付一号楼，第二个迭代交付二号楼......每个迭代都是完成一栋完整的楼。而不是第一个迭代挖好10栋楼的地基，第二个迭代建好每栋楼的骨架，第三个迭代架设屋顶......

增量开发加上迭代开发，才算真正的敏捷开发。

三、敏捷开发的好处

3.1 早期交付

敏捷开发的第一个好处，就是早期交付，从而大大降低成本。

还是以上一节的房产公司为例，如果按照传统的"瀑布开发模式"，先挖10栋楼的地基、再盖骨架、然后架设屋顶，每个阶段都等到前一个阶段完成后开始，可能需要两年才能一次性交付10栋楼。也就是说，如果不考虑预售，该项目必须等到两年后才能回款。

敏捷开发是六个月后交付一号楼，后面每两个月交付一栋楼。因此，半年就能回款10%，后面每个月都会有现金流，资金压力就大大减轻了。

3.2 降低风险

敏捷开发的第二个好处是，及时了解市场需求，降低产品不适用的风险。

请想一想，哪一种情况损失比较小：10栋楼都造好以后，才发现卖不出去，还是造好第一栋楼，就发现卖不出去，从而改进或停建后面9栋楼？

对于软件项目来说，先有一个原型产品，了解市场的接受程度，往往是项目成功的关键。有一本书叫做《梦断代码》，副标题就是"20+个程序员，三年时间，4732个bug，100+万美元，最后失败的故事"，这就是没有采用敏捷开发的结果。相反的，Instagram 最初是一个地理位置打卡 App，后来发现用户不怎么在乎地理位置，更喜欢上传照片，就改做照片上传软件，结果成了独角兽。

由于敏捷开发可以不断试错，找出对业务最重要的功能，然后通过迭代，调整软件方向。相比传统方式，大大增加了产品成功的可能性。如果市场需求不确定，或者你对该领域不熟悉，那么敏捷开发几乎是唯一可行的应对方式。

敏捷开发总的流程如下：

1.需求规划和分期

2. 需求评审

3. 需求讲解

4. 方案评审

5. 每日晨会

6. 性能测试

7. CodeReview

8. Demo

9. 测试阶段

10.线上Bug修改流程

2.如何做需求分析？

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

我们不能简单地看用户需求，而是应该去挖掘用户产生这个需求时，其心里是什么驱动着用户。

所以，更应该思考，需求分析的过程，是如何把用户需求转为为产品需求，中间的纽带是什么？一、需求筛选

需求有真假、强弱、缓急……在资源（人力、金钱）有限的情况下，做哪些不做哪些，哪些先做哪些后做，这些都是需要产品经理做出判断的。

需求分析可以分解成三个部分：需求筛选、需求透视、需求排序。这三者的逻辑是这样的：首先筛掉不做的需求，其次对要做的需求进行进一步提炼，最后对提炼过的需求进行优先级排序。至于为什么是这样一个步骤，是基于这两方面的考虑：1.对不做的需求进行提炼和排序是显然是在做无用功 2.而对未经提炼的需求进行价值评估和优先级排序很可能会产生大的误差。

需求筛选：

1.真实性

2.一致性

3.价值性

4.可行性

二、需求透视

需求按认知层面的划分，可以分成表面需求和本质需求。需求透视这一步骤，目的就在从获取的表面需求中提炼出用户的本质需求。理解用户的本质需求，则有利于我们更好地提出产品需求。

在具体说这三个概念之前，我觉得有必要再引入一个概念，这个概念叫“需求鸿沟”。“需求鸿沟”的大体意思就是：产品所能满足的需求和用户的真正需求之间，总是存在着一道不可跨越的鸿沟。我们所做的任何努力，都是在缩小这一道鸿沟。

还是以福特造车的老梗为例吧。福特在没造车前曾经问消费者们想要什么，消费者们告诉他说是更快的马。要是一般人恐怕就信以为真了，然而机智的福特早就看穿了一切，他知道消费者们本质上追求的是更快的速度而非更快的马。于是乎，他基于更快的速度这个本质需求造出了车。

马呢，是一种产品，它一定程度上满足了用户对快的需求。而快的极致是什么？瞬移。瞬移在我们现有的技术条件下是不可实现的。但我们能做的就是让用户更快一点，至少比马更快——那就是给用户一辆汽车。也就是说，产品所能提供的，永远是不完美的解决方案。表面需求，就是用户自己想出的1.0版解决方案。本质需求，就是不可达到的终极目标。产品需求，则是产品经理基于现行条件给出的优于用户所提解决方案的2.0版解决方案。

关于这三个概念，其实还有一个典型的例子。这个例子来自于嘀嘀的产品技术副总裁张博在接受采访时曾说过的一段话：(我认为这段话同样很好地阐释了表面需求、本质需求和产品需求者三个概念)

以销售为导向的思维方式是直接满足客户的需求，客户要什么我就给什么，但是用户说的不一定是他真正想要的。以产品为导向的思维方式则是用户要什么，得分析用户背后的需求是什么，从需求的本质倒推产品方案。以前司机在操作其他软件的时候，会突然跳出嘀嘀打车的抢单界面，容易误点抢单。有司机就提出能否增加确认键，多点一次确认键才是真正的抢单。这是用户说的，但产品是不是就该这样做呢？当时产品按照司机的建议做了，反对的声音更大，二次确认键操作麻烦，带来安全隐患。“我们犯了一个错误，司机真正的需求是想解决误抢单的问题，而不是要一个确认键，确认键只是解决问题的方法之一。

–  产品需求更多是属于需求实现环节的概念。在这里提出来主要是因为它跟表面需求、本质需求存在强关联性，和这两者一起能对需求做出更为完整的呈现，方便理解。

三、需求排序

需求排序，简单来说就是依据需求的重要性给需求排列优先级。需求排序有三个基本考虑因素，分别是战略定位、产品定位、用户需求。具体而言，有七个主要的考察维度：

1.相关性

考察需求与企业的战略定位、产品定位之间的相关性。一般情况下越靠近基础服务的需求越重要，因为越基础的服务越靠近产品所满足的本质需求。

2.逻辑性

考察需求之间的逻辑关系。有些需求之间是存在逻辑顺序关系的，必须先完成A之后才能去做B。比如如果没有完善的基础服务，功能性的需求往往也无法实现。

3.价值

考察需求能创造的企业价值、用户价值的性质（哪方面）与数量（多少）。

4.强度

考察需求的强弱。强需求通常具备三个特征：必要性（不可缺少）、高频次（需求次数多）、持续性（长时间保持足够的需求频次）。在考察需求强弱时，可以参考马斯洛需要层次理论。

5.广度

考察需求的覆盖面。也就是具备目标用户占比，或者说提出这种需求的目标用户数量。

6.频率

考察需求在单位时间内出现的次数。一般情况下需求的频率越高，其重要性越高。

7.类型

依据KANO模型对需求做出的分类，考察需求的类型。KONO模型认为用户需求可分为三类：

1）基本型需求

用户认为产品必须提供功能来充分满足的需求。如果这些需求没有得到满足，用户基本上就不会使用我们的产品。如果这些需求得到满足，用户对产品的满意度也不会有多大的波动。比如微信中的聊天功能。（也就是我们常说的痛点）

2）期望型需求

用户认为产品应该提供更优秀的功能来更好地满足的需求。期望型需求并不是产品必须有的需求,有的期望型需求只是用户期望有的，但是用户也不一定会明确表达出来。如果这些需求没得到满足，用户对产品的满意度会下降。一般用户进行产品反馈的，大都是期望型需求。比如微信中聊天表情虽然包。（也就是我们所说的痒点）

3）兴奋型需求

用户自己并没有意识到的隐性需求。这类需求的满足可以给用户带来极大的惊喜。当这类需求得到满足后，用户对产品的满意度和品牌忠诚度将会有显著提高。因为用户没有意识到的缘故，所以这类需求即使没有被满足，也不会引起用户不满。比如微信聊天中的红包功能。（也就是我们说的兴奋点）

这三类需求的重要性判断原则是这样的：

基本型需求最重要，期望型需求和兴奋型需求在不好判断时通过需求重要性公式确定。

期望型需求和兴奋型需求的重要性公式：重要性=功能使用用户百分比(用户使用率)×功能使用次数百分比(功能使用率)×类别重要性百分比

（通常情况下，我们可以将期望型需求百分比定为50%,兴奋型需求百分比定为25%）

关于这个公式，我们可以用一个案例来说明。假设A功能和B功能做一个比较,A功能是期望型需求 50% ，假设有100个用户，有50个使用过A功能，A功能的用户使用百分比就是50%，这50个人使用了10000次，那么使用次数百分比就是10000除以50为200。类别重要性就是50%乘以200乘以50%，级别数值就是50；B功能是兴奋型需求，百分比为25%，100人中有30个人使用过B功能，用户百分比就是30%，30人中使用了90000次，使用次数百分比就是90000除以30，就是3000，级别数值就是25%×3000×30=225，这样B功能的重要性就高于A功能。

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

bug跟设计的整个流程都是相关的。从需求开始，文档里面就开始有bug了，要么没写到，要么没写清楚，甚至错误。然后将需求转化为实现，里面转换肯定又不是百分之百对的。再加上程序员是人，难免写几个 “错别字”。还有加上本身对语言的不完全掌握，或者编译器变动，都会产生变动。当然，还有很多很多方面了。要没有bug。那就是跟绝对真理的说法一样，是不可能的！

什么样的程序员才能写出没有bug的代码呢？
不干活的程序员写不出bug
bug是可以减少但不能消灭的东西，好的程序员可以在作风和习惯上遵守一套严格的规约来避免bug，用一套合理高效的测试工具来发现bug, 减少犯错的概率，延长无bug的时间，但彻底消灭bug，估计还是神域，非凡人可达

怎么衡量Bug的修复时间和项目的上线时间冲突问题？

1.这个bug是否致命.出现就会crash,或者影响核心业务流程.

2.这个bug是否很显眼,用户一启动App就会遇见.

3.这个bug是否必现.

4.fix这个bug的时间是否会严重影响项目上线

5.只要还是看这个BUG的严重程度，不影响核心场景操作闭环的可以后修。或者先上线在修。如果这个BUG会导致用户主流成跑不通还是先修了再说。

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

边界测试:

探测和验证代码在处理极端

功能测试:

功能测试是为了确保程序以期望的方式运行而按功能要求对软件进行的测试,通过对一个系统的所有的特性和功能都进行测试确保符合需求和规范。 功能测试也叫黑盒测试或数据驱动测试,只需考虑需要测试的各个功能,不需要考虑整个软件的内部结构及代码.一般从软件产品的界面、架构出发,按照需求编写出来的测试用例,输入数据在预期结果和实际结果之间进行评测,进而提出更加使产品达到用户使用的要求。

冒烟测试:

描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程，在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。冒烟测试是代码开发完成后进行的功能完整性测试。

黑盒测试:

黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。

自动化测试：

自动化测试可分为1.自动化性能测试；2.自动化功能测试。

性能测试主要是使用测试工具，Loadrunner、Jmeter等，对软件进行压力测试、负载测试、强度测试等等，因为这些无法用手工进行代替，所以必须自动化。

自动化功能测试：包括单元测试、接口测试、UI测试。主要是编写代码、脚本，让软件自动运行，发现缺陷，代替部分的手工测试。但一般只有大的项目才需要进行自动化，中小型项目不推荐使用自动化测试。

回归测试：

以确认修改没有引入新的错误或导致其他代码产生错误。

回归测试是指漏洞由开发人员修改之后再次测试的过程。

回归测试需要验证之前的漏洞是否解决完成。

为了验证漏洞是否正确修改且其他功能是否正常。

性能测试的含义：

“性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。”

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

Bug如果长时间未得到解决，应该怎么处理？

1.告知开发bug的判断依据，同时明确开发说不是bug的理由。
2.对开发的理由进行校验，校验依据1.参照需求文档，2.跟产品经理进行沟通确认。

校验结果不是bug，关闭bug，如果是bug提交给开发进行处理，确保产品质量

做为PM，是否应该推动Bug的解决，如果PM成Bug的推动者，会不会导致开发人员越来越不主动？

遭遇Bug时，别十万火急。PM需要有战略眼光（不是战术），请先分析Bug，找到根本诱因，并衡量全局重要性，再对Bug进行解决。若不是每一次都着急解决每一个Bug，PM可以花更少的时间四处“灭火”，从而拥有更多的时间去思考产品战略——如何给用户带去更多的价值。产品经理的精力，需要放在需求挖掘和产品方案上。

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

流程是否完整，是否打通所有环节；

bug的修复程度，正常来讲，最好在p1级别的bug修复率在90%或者95%以上的时候，进行demo，并且保证剩余p1级别中没有阻断性bug，不影响正常演示。

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

常用BUG管理系统

1.EasyBUG

优点：

1)基于WEB的在线的，不用配置；

2)界面简单，操作容易上手，基本上只要是会上网的人一看就会用

3)拥有截图功能，以图片的形式直接存在，而不是以附件形式；

4)BUG解决流程记录在案；有统计报表，一目了然；

5)国产且免费的。

缺点：

1)需要手动录入bug标题，保存bug截图提交，追踪及时性靠人工自觉

价格：vip640/年

2. QC(Quality Center)

惠普公司的，企业级基于WEB测试管理工具

功能列表：

1.制定可靠的部署决策。

2.管理整个质量流程并使其标准化。

3.降低应用程序部署风险。

4.提高应用程序质量和可用性。

5.通过手动和自动化功能测试管理应用程序变更影响。

6.确保战略采购方案中的质量。

7.存储重要应用程序质量项目数据。

8.针对功能和性能测试面向服务的基础架构服务。

9.确保支持所有环境，包括 J2EE、.NET、Oracle 和 SAP。

 优点：

1)功能很强大，结合有BUG管理，需求管理及用例管理等功能；

2)和其它的测试工具，比如Loardrunner测试工具的接口做得比较好，数据可以在它们中共享；

3)管理整个质量流程并使其标准化。

4)通过手动和自动化功能测试管理应用程序变更影响

缺点：

1)需要安装配置IIS和数据库，系统资源消耗比较大；

2)纯英文版的且易用性不是很好，且收费；

资源地址：http://www.hp.com/

价格：30美元（不确定）

3、BugFree(后来进化为禅道bug管理)

bugfree优点：

1)开源免费,配置安装简单

2)有简单的报表统计功能；

3)整体使用还是比较容易上手

bugfree缺点：

1)没有直接的截图功能但是可以以附件的形式存在；

2) bugfree是基于php开发的，所以要运行就需要安装php环境，略复杂

3)页面是非常清晰整洁的web页面，但是需要填写字段

禅道功能列表：

1. 产品管理：包括产品、需求、计划、发布、路线图等功能。

2. 项目管理：包括项目、任务、团队、build、燃尽图等功能。

3. 质量管理：包括bug、测试用例、测试任务、测试结果等功能。

4. 文档管理：包括产品文档库、项目文档库、自定义文档库等功能。

5. 事务管理：包括todo管理，我的任务、我的Bug、我的需求、我的项目等个人事务管理功能。

6. 组织管理：包括部门、用户、分组、权限等功能。

7. 统计功能：丰富的统计表。

8. 搜索功能：强大的搜索，帮助您找到相应的数据。

9. 灵活的扩展机制，几乎可以对禅道的任何地方进行扩展。

10. 强大的api机制，方便与其他系统集成。

禅道的优点：

1）禅道开源免费，从下载到使用不需任何费用。开源的软件更能够根据企业自身需求在源码的基础上进行修改，让国内外众多企业节省项目管理成本。

2）禅道的功能非常完备，可扩展性，且代码开放可做二次开发。

3）禅道价格实惠，售后服务方式选择多且有官方技术服务的保障。

禅道的缺点：

1）禅道的界面设计稍稍逊色，不够简洁，颜色使用也比较单一，不够丰富。

2）虽然禅道有新手入门操作演示，但部分新人上手还是会存在一些问题。

4.Bugzilla

基于Web方式，免费的开源的一款功能强大的Bug管理系统

功能列表：

⒈ 强大的检索功能

⒉ 用户可配置的通过Email公布Bug变更

⒊ 历史变更记录

⒋ 通过跟踪和描述处理Bug

⒌ 附件管理

⒍ 完备的产品分类方案和细致的安全策略

⒎ 安全的审核机制

⒏ 强大的后端数据库支持

⒐ Web，Xml，Email和控制界面

⒑友好的网络用户界面

⒒丰富多样的配置设定

⒓版本间向下兼容

优点：

1)比如强大的检索功能，强大的后端数据库支持, 丰富多样的配置设定等；

2)免费

3)安全性高

缺点：

1)安装需要Perl和配置MYSQL数据库，过程比较繁琐，修改配置文件比较麻烦；

2)英文版的，能汉化但是汉化后容易出现乱码；  

3)界面美观度差，不支持截图上传

5、 Mantis

Mantis是一个基于php技术的轻量级缺陷跟踪系统，是以web操作的形式提供项目管理及缺陷跟踪服务。其实用性满足中小型项目的管理和跟踪。更重要的是开源、免费。

功能列表：

1.缺陷跟踪管理(默认为bug管理系统)

2.问题跟进分析报告

3.可以添加子项目、模块等功能

4.配置不同权限发送email通知

5.工作流自定义配置

6.路线图、修改日志

7.统计报表、图形报表

8.与TESTLINK、wiki等集成

优点：

1)开源不收费、B/S架构模式，Windows平台，可邮件通知，操作较为灵活

2)可以跟踪成粗版本变更历程

3)可以生成项目bug各种指标统计图标

4)丰富的过滤器搜索功能

缺点：

1)安装配置复杂，界面不美观

2)工作流整体已写死，不好进行配置，配置不灵活

3)管理不便，修改配置大部分需要进行代码修改

6、JIRA

JIRA是集项目计划、任务分配、需求管理、缺陷跟踪于一体的软件。

优点：

1)JIRA的界面效果非常不错。安全性、可扩展性方面也不错。  JIRA的使用范围广，所以拥有众多开发者提供的扩展插件以供不同选择。

2)工作流定制功能实用性特别高，可定制性也很好。

3)针对issue驱动的项目管理非常有效，也基于多年来的插件积累，可以展现非常强大的交互、统计视图，纯粹项目管理使用JIRA的确是个不错选择。

缺点：

1)从使用上来说还是不大符合国人的使用逻辑。

2)虽然有中文版本，但是中文版本在使用的过程中，部分页面还是会有很多英文，不能做到全中文界面。

3)对于国内用户提供的售后服务稍显弱一些，存在时间和沟通上的一些障碍。

7、Bugtags

Bugtags是国内首款为改善移动产品质量而专门打造的测试平台产品。使用Bugtags平台可以随时随地对移动产品提出准确的改善意见，使得测试更简单，修复问题更轻松，产品用户满意度更高。

功能列表：

1. SDK集成简单

一行代码极速集成，完全不影响原有程序结构

2. 所见即所得提交问题

一键截屏，使用标签描述问题，在应用内直接提交问题，免去截图连电脑上传描述等步骤

3. 自动收集设备与应用运行状态

极大提高了问题描述准确度，帮助开发人员快速定位和解决问题

4. 自动收集分析崩溃信息

每一次用户的闪退现场信息，都会上传到云端，分析数据让解决问题更轻松

5. 简单有效的问题生命周期管理

抽取传统缺陷管理系统的最核心功能，有效管理和跟踪问题

优点：

1) 可以在APP端手动提交问题; 只需要在 App 中点击错误位置，描述错误原因，指派给相应的人员即可，设备信息、版本、用户步骤、运行时数据、日志全部自动帮你记录了下来。大大提升了测试效率，提高质量。

2) 可以收集闪退信息

3) 支持 bug 截图

4)第三方sdk集成

8、Gitlab

Gitlab管理bug也是最近才接触到。跟项目绑定，特别方便管理bug，随时assign给相关开发，也可以看到开发提交bug时的Commits，每次发版可以对照相关提交，既方便测试，也可以在出现问题时找到对应开发。

9.Trac

Trac是一个为软件开发项目需要而集成了Wiki和问题跟踪管理系统的应用平台，是一个开源软件应用。Trac以简单的方式建立了一个软件项目管理的Web应用，以帮助开发人员更好地写出高质量的软件；Trac应用力求不影响现有团队的开发过程。

Trac是以面向进度模型为项目管理模型的，很明显的特点就是它以里程碑(Milestone)方式进行项目管理的。每个里程碑中的具体要做哪些事情，就使用Ticket来进行定义、跟踪等。里程碑是什么呢？里程碑是一些事件，我们设立这些事件是为了表明当这些事件发生的时候，我们的工作已经达到了某种程度。为什么我不用时间点呢？原因在于使用时间点往往让人误以为，里程碑是按照时间来设计的，而不是按照事件来设立的。

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

开发环境是研发团队的领地，你可以把开发环境当成是蛮荒之地。

测试环境，是测试人员所掌控的世界。

在这里，所有的Bug的发现，流转，验收和版本的管理，必须摆脱开发环境的野蛮和无序。

测试环境并不是单纯意义上的找Bug，更是对线上环境发布的演练。

所以测试环境其实是包含了“演练发布脚本”+“寻找系统Bug”两个环节。

线上环境即发布环境，真实用户访问的环境，要求不能有任何BUG，且不能频繁发布，这样对用户体验性不好。

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

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

定义
　　删除由一个或多个部分完成的事务执行的更新。为保证应用程序、数据库或系统错误后还原数据库的完整性，需要使用回滚。
　　回滚泛指程序更新失败, 返回上一次正确状态的行为。
　　回滚对程序员意味着非常严重的失误。所以回滚次数往往与程序员的薪金直接联系。主流互联网公司通常都将回滚定位为最严重的事故。
　　回滚与恢复有本质的区别。

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

Priority()和Severity(严重程度)是的两个重要属性。很多新人经常混淆这两个概念。通常，人员在提交Bug时，只定义Bug的Severity, 即该Bug的严重程度，而将Priority交给Project Leader 或Team Leader来定义，由他们来决定该Bug被修复的优先等级。某种意义上来说，Priority的定义要依赖于Severity，在大多数情况下，Severity越严重，那这个Bug的Priority就越高。你知道如何合理定义bug的Sevrity么？
通常Bug管理系统里Severity分为四个等级Blocker, Critical, Major, Minor/Trivial（也可自定义，但通常是这四个）, 而priority分为五个等级：Immediate, Urgent, High, Normal, Low。
Severity

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

• 严重花屏
• 内存泄漏
• 用户数据丢失或破坏
• 系统崩溃/死机/冻结
• 模块无法启动或异常退出
• 严重的数值计算错误
• 功能设计与需求严重不符
• 其它导致无法测试的错误, 如服务器500错误

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

• 功能未实现
• 功能错误
• 系统刷新错误
• 数据通讯错误
• 轻微的数值计算错误
• 影响功能及界面的错误字或拼写错误
• 安全性问题

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

• 操作界面错误（包括数据窗口内列名定义、含义是否一致）
• 边界条件下错误
• 提示信息错误（包括未给出信息、信息提示错误等）
• 长时间操作无进度提示
• 系统未优化（性能问题）
• 光标跳转设置不好，鼠标（光标）定位错误
• 兼容性问题

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

• 界面格式等不规范
• 辅助说明描述不清楚
• 操作时未给用户提示
• 可输入区域和只读区域没有明显的区分标志
• 个别不影响产品理解的错别字
• 文字排列不整齐等一些小问题

Priority

1.Immediate

即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。
2.Urgent
即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。

3. High
即“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。
4.Normal
即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。
5. Low即”低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。

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

生命周期就是指在Bug管理工具中,我们记录下来的一个Bug被创建,指派,修复,复查,关闭的过程

BUG的生命周期

　　● BUG初始状态（Unconfirmed&New态）
　　● BUG分配状态（Assigned态）
　　● BUG重新分配状态（Reassigned态）
　　● BUG修复状态（Resolved&Fixed态）
　　● BUG验证状态（Vertified&Fixed态）
　　● BUG重新打开状态（Reopen态）
　　● BUG关闭状态（Closed&Fixed态）

在使用禅道时Bug的生命周期可以总结为：

提交缺陷：测试人员提交新的缺陷，并对该缺陷进行描述，分级。操作，预期结果。

分派缺陷：开发人员打开缺陷，但是该模块并不是自身开发，可以将缺陷重现指派给对应模块开发人员。

确认缺陷：开发人员根据缺陷描述进行重现，分析缺陷。确认是否为软件缺陷。

不予解决：开发人员认为不是缺陷，标记为不予解决。指派给产品进行分析是否为缺陷。

处理缺陷：开发人员对缺陷进行处理，解决缺陷所出现的问题。

回归缺陷：当缺陷被解决时，由测试人员对缺陷进行回归测试，确认该缺陷被解决。

关闭缺陷：缺陷被解决，已进行回归测试且结果为PASS。

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

一个完整的开发流程。从提需求、开发、交付。这中间都应该有个结果。就如你做一件事，得有个东西来判断你是否已经完成了这件事。那么测试用例就是这个东西了。

为什么要写测试用例
　　1.深入了解需求的过程，一个项目立项开始，测试就开始介入，我们从产品的需求文档、原型图，效果图等相关文档去熟悉产品的各个模块，各个业务流程。或者在产品规划和设计阶段，测试开始熟悉产品。而编写用例的过程中，会充分的思考产品需求的细枝末节，需求的不合理、有矛盾、不明确的地方，还能对产品提出更好的建议，监督产品对需求做出更加详细的设计。整个过程是对需求深入了解的过程，产品的整个印象都在测试脑海里。
　　2.测试执行的指导，用例编写是把产品需求转换为一种可操作步骤的行为，方便以后作为测试的标准，有步骤有计划的进行测试。如果没有这个标准，会使你的测试过程无计划，无目标，变成一个放任主流的状态，完全没有受控性。这样的产品质量保证显然是空谈。
　　3.规划测试数据的准备，在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据
　　4.反应测试进度，测试人员开始按照测试用例的描述测试，每过完一个用例标记完成；这样测试也知道自己做过哪些操作，避免没有目的随机测试。并且通过测试用例的执行条数，大致了解该模块的测试进度。
　　5.举一反三发现潜藏缺陷，测试人员在执行用例的过程中往往会突然发现当初设计的用例步骤中，还可以做这样一个操作，于是发现了bug，这又体现了测试用例的作用， 帮助发现拓展测试范围，扩大测试覆盖面，发现软件中潜藏的缺陷。
　　6.分析缺陷的标准
　　通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。
　　测试用例可以用来衡量一个项目测试质量。测试用例的健壮性，完整性，覆盖程度等，都对项目测试质量有影响。因此在平时的测试流程中，编写测试用例就是测试过程中很重要的一步，每一个测试工程师都需要并且非常熟练的编写测试用例，能在编写测试用例中尽可能的覆盖任何异常的测试点；如何能编写优秀的测试用例，就需要测试人员掌握更多的用例编写技巧以及思考出更多的测试点。

前置条件

一般正常情况，考虑一下几个方面：

1. 页面布局是否合理，如导航栏上面应该显示三个按钮，实际上却显示了两行。
2. 页面文字描述是否准确，如气泡提示：密码格式错误，请重新输入。实际上却显示：账号密码错误。
3. 如果有加载规则，是否符合加载规则。如：进入页面加载20条内容，实际上却加载了10条。
4. 如果有排列规则，是否符合排列规则。如应按照时间倒序排列，实际上却是正序排列。
5. 操作是否符合要求，如单击某个点，是否准确跳转或显示内容。如本应该进行跳转，实际上却未进行跳转。
6. 输入框输入的内容是否有符合格式要求。如：账号不允许”,”,而实际上却允许了。
7. 输入的内容是否符合合法性要求。如：账号密码是否一致等问题。
8. ……

预期结果：期望达到的效果

一个登录注册的小模块，正常来讲，应该有多少个测试用例？

登录-点击登录，跳转到登录页面

账号密码输入正确登录成功跳转个人页面，在登录状态修改密码，输入之前登录密码，输入新密码确认新密码，提示修改成功，自动退出登录状态返回登录页面重新登录。

账号密码输入错误显示密码错误，点击重新登录可重新输入密码登录，点击找回密码，可手机短信找回/邮箱找回、进入更改密码页面，输入新密码，确认新密码点击确定，提示修改成功

账号输入错误显示账号格式错误，重新输入

注册-点击注册，跳转到注册页面

账号，重复在用户名后显示账号已注册，不重复显示可以使用（账号为数字或字母，可组合使用，账号最长11个单位，最短4个单位）。

密码，密码分高中低安全等级，高为大写字母+小写字母+数字，中为字母+数字，低为纯数字或纯字母（密码为11位，可字母数字组合）

邮箱，输入邮箱地址，重复显示×，不重复显示√，邮箱为账号和密码必须输入才可以注册账号

绑定手机号，输入11位手机号，点击发送验证码，验证码为6位，60秒内有效，60秒后可重新发送。不绑定手机可空

输入图片验证码，验证码为4位，数字加字母组合，正确在输入框后显示√，错误显示×。

点击确定，提示注册成功，跳转到登录页面。

14.什么是产品经理?

产品经理（product+manager）通常业内简称“PM”指负责某类或是某项产品研发，运营，管理的+经理人。

2、产品经理是产品的灵魂人物，是产品的核心。

3、产品经理可以说是是一个小小总经理。产品经理必须为一个产品的盈亏负责。同时也应该有相应+的权限和报酬。

4、每个产品，有自己虚拟的账户，应该有自己的计划进度表，要一切尽在掌握。每个产品应该有自+己的功劳簿。做到赏罚分明。产品经理要负责产品的营运进度，产品经理要负责销售进度，产品经理要对+该产品成本支出和销售收入了如指掌。产品应该是他的儿子，各个部门只是保姆，虽然尿布是保姆换，但+责任却在儿子的父亲。

5、大多数时候产品经理行驶的是执得权，产品在不同的生命周期中，其职位重要性起很大重用

产品经理定义

产品经理，又称品牌经理（Brand Manager）。

是企业守门员、品牌塑造者、更是营销骨干。它既是一套完善的营销运作制度，更是博大精深的营销操作。产品从创产意到上市，所有相关的研发、调研、生、编预算、广告、促销活动等等，都由产品经理掌控。

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

学习任务2，把遇到的问题找到答案

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

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

(BUG)什么情况下应该是Reopen？什么情况下去Close？ 这几个问题之前查资料好像看到了解答，又突然找不到了

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

学习了深度思考，知识好多，无法全部消化，感觉涉及的知识不止任务一，头脑风暴般，慢慢整理