今天完成的事：
任务一修改，bug生命周期，三个环境，项目流程
https://pan.baidu.com/s/1bL7xV6ixM7Q19UMT3hVYwA
提取码：kjfu
明天计划的事
任务二
遇到的困难
没有
收获：
BUG的生命周期 bug的几个状态。
BUG 生命周期中的各个状态   从一个bug被发现到这个bug被关闭这一段时间，bug可能会有以下状态：
new ，open Postpone，Pending Retest，Retest,Pending Reject,Reject,Deferred,closed.(请注意这里有很多种状态，我们需要根据不同情况来决定怎样或者是否需要跟开发人员沟通) 
 
下面就对这几种状态进行以下解释：
 
New:（新的）
 当某个“bug”被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug
 的状态设为New 
 
Assigned（已指派的） 当一个bug被指认为New之后，将其将给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug
 指定给某位开发人员处理，并将bug的状态设定为“Assigned”
 
Open（打开的） 一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”
 
 Fixed（已修复的）当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug
 返还给测试组
Pending Reset（待在测试的）
 当bug被返还到测试组后，我们将bug的状态设置为“Pending Reset”
 Reset(再测试) 测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset”
Closed（已关闭的）
 如果测试人员经过再次测试之后确认bug 已经被解决之后，就将bug的状态设置为“Closed”
Reopen（再次打开的）如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen”
Pending Reject（拒绝中）如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态设置为“Pending Reject”
Rejected(被拒绝的) 测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，发组负责人就将这个bug的状态设置为“Rejected”
 
Postponed（延期）有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed“
 
如果测试人员传递到开发组的
bug
被开发人员认为是正常行为而不是
bug
时，这种情况
下开发人员可以拒绝，并将
bug
的状态设置为“
Pending Reject 
Rejected(
被拒绝的
) 
测试组的负责人接到上述
bug
的时候，如果他（她）发现这是产品说明书中定义的正常行
为或者经过与开发人员的讨论之后认为这并不能算作
bug
的时候，开发组负责人就将这个
bug
Rejected
Postponed
（延期）
有些时候，对于一些特殊的
bug
的测试需要搁置一段时间，事实上有很多原因可能导致这
种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，
bug
的状态就被设置为“
Postponed
Deferred（延期的）有些情况一些特殊的bug显得不那么重要，同时也是可以消除的，这个时候我们可以将bug的状态设置为“Deferred”。
三个环境：
开发环境
测试环境
线上环境
一、story讲解
1.PM跟客户谈好需求后写好需求文档并制作竞品分析PPT，一般应该是UE组全组参与，用时的话因产品的复杂度不同而不同。
2.PM使用Axure或者其他工具画出产品的原型图，交给客户看，客户没有异议后，开始在禅道或者其他项目管理软件拆分story。
3.PM在禅道上拆分好story，并定义出优先级，关联好需求，因为后期开发是根据优先级进行开发的。
4.由PM讲解story，前端和后端都必须参加，用时的话因产品的复杂度不同而不同，一般在1-3小时。
5.UI根据产品原型图画出设计图，并找客户确认，直到客户无异议。
二、人员划分
1.PM在Wiki或者其他公司文档管理软件上创建项目主页，把竞品分析的PPT、需求文档和产品原型图（HTML文件）上传到Wiki。
2.UI将UI图上传到Wiki，并写好UI自检表。
3.项目负责人根据产品原型图和需求文档按照模块划分相关负责人（前后端都是）并上传到wiki。【文档标题：XXX项目人员分工前（后）端】
三、定义接口文档
1.前端和后端相关人员对照原型图和需求文档，根据模块和页面大概定义出接口。具体包括一个页面几个接口，每个接口的传入参数和返回参数。
2.后端每个模块的负责人根据讨论的结果，在Wiki上创建标准的接口文档。
3.后端负责人将接口文档发给前端负责人过目，如果有异议，继续修改，无异议则开始后续步骤。
四、方案设计
1.后端开发人员根据原型、需求文档以及定义的接口，做好方案设计。对于有疑问和难点的接口应该给出不同的方案，并写清楚不同方案的优缺点。
2.前端开发人员要根据原型图、需求文档和UI图写好方案设计，具体包括整体架构、框架和插件选择、文件结构、需求分析及实现、页面跳转等等。
五、方案评审
对前后端做出的方案进行评审，建议全体人员参，如不通过则继续修改。
六、禅道拆分
相关负责人按照优先级顺序在禅道拆分自己的任务，单个任务最好不要超过4个小时，拆分的要详细。
七、开发
1.搭建开发服务器。
2.开发人员根据禅道上的任务，按时完成自己的开发工作。
3.每天上午10点开晨会，统计任务进度，对疑难点和异议点进行商讨，并拿出解决方案，保证按照禅道上的时间点完成。
八、阶段测试（与开发并行）
前后端开发人员每天下班前必须将代码发布到开发环境并自测无问题方可下班。
九、性能测试
1.后端对每个接口进行性能测试，每个接口的响应时间不能超过200ms，如超过则优化，尽量缩短在200ms以内。
2.前端对页面加载进行测试，具体包括首次加载时间，DNS解析时间，等待响应时间，接收数据时间等等。
3.前端根据UI的自检表做好UI自检。
十、CodeReview
前后端负责人对代码做好CodeReview，不合理的地方要相关开发人员修改。
十一、压力测试
后端做好压力测试报告。
十二、Demo
1.项目负责人发demo申请邮件，收件人包括PM同学、QA同学、前后端开发人员。
2.开demo会议，主讲人：某个开发人员，
会议途中PM同学和QA同学可以随时提出问题。
3.PM同学发demo结果通知邮件，内容包括demo结果，如不通过有哪些问题。
4.如不通过，修改后召开第二次demo会议，直到通过为止，后续会议只需展示前次会议不通过的部分。
十三、测试
demo通过后：
1.开发人员对代码打tag
2.开发人员部署测试环境部署完成后发邮件，写明域名。
3.开发人员将代码交给QA同学进行测试，QA同学发送全体测试周期邮件。
4.在测试期间，开发人员要常去禅道看自己的BUG，及时确认BUG，并及时修改。
5.修改BUG完成后，开发环境前端代码由前端同学部署，后端代码由后端同学部署。测试环境的代码由后端同学每天固定时间统一部署前后端代码。
6.测试完成后，PM同学或者QA同学发送上线通知。
十四、发布线上
OP同学将代码发送到线上环境，并停止开发环境和测试环境。
十五、后期管理维护
OP同学进行后期线上监控，并及时发送错误报告。