今天完成的事：

1、写场景

明天计划的事情： 

1、调研写场景

2、修改操作手册

遇到的问题：

1、每天都有问题，每天都在被纠正

收获

一、什么是敏捷开发

敏捷开发的核心是迭代开发，敏捷一定是采用迭代开发的方式。

迭代开发将一个大任务，分解成多次连续的开发，本质就是逐步改进。

划分迭代采用“增量开发”，按照新增功能来划分迭代。软件的版本，都会新增一个用户可以感知的完整功能。

二、敏捷开发的好处

1.早期交付

2.降低风险

三、敏捷开发的流程

1.立项

2.story讲解

3.人员划分

4.定义接口文档（2-3天）

5.方案设计（1小时-1天，根据模块大而定）

6.方案评审（2-3小时）

7.禅道拆分（1-2小时）

8.开发

9.阶段测试

10.性能测试和coderevivew（1天）

11.压力测试

12.Demo

13.发布测试环境、集成测试

14.编写操作手册

15.发布线上环境，同时停止开发测试环境和开发环境

16.线上监控

敏捷开发流程：

1、谈需求，确认客户的具体需求；

2、找开发确认技术可行性；

3、如有迭代，确认好下一期需要做的需求；

4、产品、UI、开发、测试估时，估完时找客户确认；

5、签合同，创建项目群组，确认第三方服务；

6、产品进行竞品调研，写story，制作原型；

7、原型找客户确认好细节；

8、UE组内部评审ppt和原型；

9、需求评审，拉各组leader评审需求的可行性，给出项目的具体估时，产品在禅道上拆分好story，关联需求，定义优先级，新建wiki；

10、需求讲解，给实际做项目的人员讲解项目以及原型的细节；

11、UI设计；

12、代码开发；

13、demo，确认研发成果；

14、测试；

15、交付

二、如何做需求分析？

获取需求--处理需求--解决方案--排序需求--撰写报告--复盘、

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

1.要看BUG的严重程度：系统直接崩溃、瘫痪和逻辑出现严重问题，流程卡住，无法进行下一步时，需要修复后上线

2.部分功能出现闪退，功能没有实现，产品可以满足业务要求，部分小限制不符合验收标准，界面等UI问题显示错误等可以先上线后解决。

3.影响信息安全（信息或数据安全；帐户安全；财产安全等，必须延迟发布，假设上线了，不仅影响公司的声誉，还可能直接造成公司或者用户的经济损失。

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

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

不仅包含输入、输出的边界，还包含数据结构的边界，状态转换的边界，功能界限的边界或端点。

功能测试：对产品的各项功能进行测试，根据功能测试用例，逐项测试，检查产品是否达到用户邀请的功能（最高级别测试

功能测试就是黑盒测试，数据驱动测试，只需考测试的各个功能。

冒烟测试：在对一个新版进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测试性。（基本功能和流程能走通）（在功能测试完成之后，在新安装和更新的输入值之后，将在起始点执行一个简单的测试。

对程序主要功能的验证，而不会对具体功能进行更深入的测试.冒烟测试的最佳实践还是最好被自动化，在CI中每一个Build都自动的去执行主流程的测试，确保其是一个基本可用的版本。

黑盒测试:也称为功能测试.已知产品所具有的功能,通过测试来检测每个功能是否能正常使用。在测试时把程序看成一个不能打开的黑盒子，在不完全考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能能否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。

自动化测试：是指软件测试的自动化。软件测试就是在预估条件下运行系统或应用程序，评估运行结果，预先条件包括正常条件和异常条件。自动化测试就是将以人为驱动的测试行为转化成机器执行的一种过程。

回归测试：检验软件原有功能修改后是否保持完整。（当系统中出现复杂的bug时，通常会影响系统的核心区域，所以使用回归测试来重新测试系统的所有模块。

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

负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

应该由最高级别测试--功能测试主导。因为其实对产品的各项功能进行测试，检测每个功能是否能正常使用，如测试出每个功能均可正常使用，可保证产品在正常运行时没有问题。

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

1.邮件与开发沟通后仍长时间未解决，找开发组leader

2.肯定要推动，影响上线时间

3.PM不会是BUG的推动者，有测试和开发人员处理BUG，PM推动的是重要且长时间未得到解决的BUG，项目组为了同一个目标奋斗，开发人员怎么会变得不主动呢

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

Demo过程中，有一个Demo通过的基本原则， 就是但凡是肉眼能够发现的错误，都应该记为不通过， 而不是说，有几个Minor级别的小问题，可以通过

作者：技能树IT修真院

链接：https://www.zhihu.com/question/20694803/answer/618176213

来源：知乎

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

第一，Demo是开发团队向产品团队交付，所以Demo的主角是研发团队。 第二，Demo应该依照Story去演示功能，防止有遗漏。 第三，Demo之后就会打Tag（固定代码版本）， 所以Demo应该是非常严谨的，从来都没存在所谓的主流程跑通， 而是应该一行代码都不需要改动，直接发布到测试环境。 第四，Demo过程中，有一个Demo通过的基本原则， 就是但凡是肉眼能够发现的错误，都应该记为不通过， 而不是说，有几个Minor级别的小问题，可以通过。 第五，下次Demo的时候，可以只演示Demo中出现的问题，以节省时间。 第六，产品人员和测试人员应该参加Demo， Demo的时候不仅是要看一下研发团队的操作， 还应该自己亲自在PC或者是手机上操作。 第七，Demo的数据应该使用仿真数据 （而不是随意填写的测试一，测试王八蛋之类的）。 第八，在Demo之间，应该先进行性能测试，UI自检规范和CodeReview， 三者通过之后才允许Demo。 第九，如果有Bug的修复，也应该在开发环境先向测试人员演示通过， 才允许发布到测试环境，以减少反复发布测试的次数。 第十，Demo过程中发现的问题，应该记录下来责任人和预计修复时间。

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

 QC  商用  

优点：功能强大，结合BUG管理，需求管理和测试用例等功能

缺点：英文版的易用性不是很好，价格高（需要安装配置IIS和数据库，系统资源消耗比较大

 Bugzilla 免费  

优点：免费的开源的一款强大的BUG管理系统，比如强大的搜索功能，强大的后端数据支持，丰富多样的配置设定。

缺点：安装配置麻烦

 禅道 商用但是有免费版本

优点：基于WEB,开源、免费，安装配置简单。

缺点：没有直接的截图功能，以附件形式保存。（禅道偏向项目管理，包括：产品管理、项目管理、质量管理、文档管理等，测试功能只存放在质量管理中，测试只是禅道的部分功能）

       4. Mantis 免费

 优点：基于web，开源，报表功能强大，

缺点：英文版，可以通过汉化包和配置来汉化，有邮件支持但也需要修改配置，没有直接截图功能

      5. Jira 商用

优点：基于WEB，功能强大，能够内部及时交流，跟踪任务、bug，通过JIRA的邮件通知功能进行协作通知，在实际工作中使工作效率提高很多。（不限制用户数！不限制创建项目数和Issue的数量！一年内免费更新版本

缺点：无法直接管理测试用例

     6. Gitlab 免费

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

缺点：大型安装和配置上存在一些速度或性能问题 

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

开发环境：开发环境是程序猿们专门用于开发的服务器，配置可以比较随意， 为了开发调试方便，一般打开全部错误报告。

测试环境：一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。

生产环境：是值正式提供对外服务的，一般会关掉错误报告，打开错误日志。

区分的原因：

第一，开发人员往往没有办法测试出自己写的代码的问题。

第二，测试环境通常需要一个稳定的环境，不允许随时更改和发布，而开发环境通常每天会发布四五次还要多。

没有高低，谁来主导之分，完成一个阶段开启下一阶段。

区分模式的优势：

 开发模式自动reload代码，但是偶尔仍然需要手动reload

 某些模式多加载一些gem，比如debugger在开发环境，rspec在测试环境，或者unicorn在生产模式

 使用不同的数据库配置，比如测试环境会每次测试完成清理数据库，生产环境也不推荐随便migrate

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

回滚到上一阶段没有BUG的版本。

测试发现BUG，提交至老板那，判断是否回滚。

不影响用户使用不回滚，功能性问题需求回滚。

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

首先要了解BUG的优先级：

critical

block

major

normal

minor

Critical:最严重，系统崩溃，完全不可用。

Block：用户操作卡住，无法进行下一步

Major：BUG的分界线，关键业务逻辑走不通。

Normal：不太重要的功能出现BUG，可以在上线后解决

Minor：不重要的BUG，如兼容性、字体问题

以Major作为bug体系的分界线，通常而言，有Major以上的Bug是不允许上线的-都跑不通流程，你发布上线干嘛呢？如果出现major，开发人员应立即停掉手上项目开发，第一时间修复Major bug，并提交到测试环境。

系统是否能上线非常重要的一个依据就是，是否还存在major级别以上的bug，如果存在，能否先把这个模块去掉，先去上线没有问题的模块。

在提Bug的时候，要注意，一定要描述清楚Bug出现时间的操作步骤（关键点附截图），使用环境（操作系统，手机型号，浏览器版本，上下文）和预期结果（正确的结果是什么），同时标明是偶现，还是必现，以及提供重现的数据。

这对于开发人员来说，非常重要。毕竟他们天生会说：在我这里没问题啊（是你这个SB不会用吧）。

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

bug级别

严重程度由高到低依次为：

1.critical

2.block

3.major

4.normal

5.minor

critical：

系统直接崩溃，瘫痪。所有人员无法正常打开产品进行使用。

block：

逻辑出现严重问题，流程卡住，无法进行下一步。

major：

部分功能出现闪退，功能没有实现，但是不影响使用，功能菜单缺失

（一般demo结束之后，功能错误或者数据错误，重要的需求优化我们会提该级别bug，需求优化我们会注明是需求优化。不会影响系统稳定）

normal：

产品可以满足业务要求，部分小限制不符合验收标准，内容显示错误。界面主流浏览器（根据PM定）的兼容性。

minor：

界面等UI问题显示错误，比如字体大小，颜色，间距等问题，性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

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

生命周期就是指在Bug管理工具中,我们记录下来的一个Bug被创建,指派,修复,复查,关闭的过程.生命周期就是要讲清楚,Bug应该有哪些状态,分别是由谁去触发,参与的角色又是谁.

新建

指派

接受

修复

关闭

确认修复后验证，测试环境的BUG就在测试环境完成验证

线上环境的BUG，第一时间看测试环境能否重现，如果可以重现就在测试环境验证，如果不能重现就在线上完成。

如果验证的时候不通过，改成Reopen,重新打开，验证通过则Close

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

一个完整的开发流程，从提需求、开发、交付，测试用例用来判断已经完成整个过程。

前置条件：比如密码登录，前置条件时账户密码同时输入正确才能登录成功

预期结果：登录成功。

功能测试(Function Test)

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秒

安全性测试(Security Test)

1、登录成功后生成的Cookie是否有HttpOnly(降低脚本盗取风险)

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

3、账号和密码的验证，应该是用服务器端验证，而不能单单是在客户端用javaScript验证

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

5、账号和密码的的输入框，应该禁止输入脚本（防止XSS攻击）

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

7、考虑是否支持多用户在同一机器上登录；

8、考虑一用户在多台机器上登录

可用性测试(Usability Test)

1、是否可以全用键盘操作，是否有快捷键

2、输入账号，密码后按回车，是否可以登录

3、输入框是否可以以Tab键切换

兼容性测试（Compatibility Test）

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

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

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

4、不同的分辨率

本地化测试 （Localization Test）

1、不同语言环境下，页面的显示是否正确。

软件辅助性测试 （Accessibility Test）

软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能

1、高对比度下能否显示正常（视力不好的人使用）

1.填写符合要求的数据注册：用户名字和密码都是最大长度(边界值分析)

2.填写符合要求的数据注册：用户名字和密码都是最小长度(边界值分析)

3.填写符合要求的数据注册：用户名字和密码都非最大和最小的数据(边界值分析，取内点)

4.必填项为空注册

5.用户名长度大于要求注册1位(边界值分析)

6.用户名长度小于要求注册1位(边界值分析)

7.密码长度大于要求注册1位(边界值分析，取离点)

8.密码长度小于要求注册1位(边界值分析)

9.用户名是不是符合要求的字符注册(划分几个无效的等价类，如是否有#，空格，等

10.密码是不是符合要求的字符注册(划分无效等价类)

11.俩次输入密码不一致(可以划分几个无效等价类)

12.重新注册存在的用户

13.改变存在的用户的用户名和密码的大小写，来注册

14.看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否有加密号等

二 、修改密码：

具体情况.具体分析。比如银行卡密码不用考虑非法输入和英文字母输入。也不用考虑tap键

1.不能输入旧密码，直接改密码

2.输入错误旧密码

3.不输入确认新密码

4.不输入新密码

5.新密码和确认新密码不一致

6.新密码中有空格

7.新密码为空

8.新密码为符合要求的最多字符

9.新密码为符合要求的最少字符

10.新密码为符合要求的非最多最少字符(取中间值)

11.新密码为最少字符-1

12.新密码为最少字符+1

13.新密码为最多字符-1

14.新密码为最多字符+1

15.新密码为非允许字符(如有的密码要求必须是英文和数字组成.那么要试汉字字符等)

16.看是否支持tap和enter键；密码是否可以复制和粘贴;密码是否以*进行加密

17.看密码是否区分大小写，新密码中英文小写，确认密码中英之大写

18.新密码和旧密码一样能否修改成功，另外一些其他想法如下:

A:要测试所有规约中约定可以输入的特殊字符，字母和数字，要求都可以正常输入，显示正常和添加正常

B:关注规约中的各种限制，比如长度，是否支持大小写

C:考虑各种特殊情况，比如添加同名同户，系统是否正确校验给出提示信息

D:数字上的长度之类的，包括出错信息是否合理

E:特殊字符:比如: / ' " 等是否会崩溃

F:注入式BUG.比如密码输入or 1 = 1

十四、什么是产品经理

产品经理是发现问题、提出需求，找到用户体验与商业目标的平衡点，并且能够解决问题的人。

测试用例是为某个目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

测试用例最大的作用是

1.帮测试人员理清测试过程以及测试步骤;

2.记录测试所覆盖的测试内容

3.为后续的测试提供可参考的依据，如：哪些是有影响的需要回归的。

4.在突发情况下，你被调离以及离职的情况，迅速了解测试进度以及系统测试覆盖程度。

1.便于理清测试思路，确保需覆盖测试的功能点无遗漏

2.便于测试工作量的评估

3.便于提前准备测试数据

4.便于把控测试工作进度

5.便于回归测试

6.把握app迭代过程中的测试侧重点

7.便于测试工作的组织，提高测试效率，较低测试交接成本

Major级别以上的Bug,都要求在2个小时之内做处理, 要么流转,要么接受. Normal以下不超过2天.

第一种.Major级别以上的Bug,立刻修复,停掉手里的事情. 第二种,Major级别以下的Bug, 跟着下一期的版本正常修复,或者是单独发布一些小版本.

需求分析

敏捷理念有一个3C原则（Card一句话的卡片式需求、Communications密切双向沟通、Confirmation确认达成共识），这个我觉得特别适合PM与Team之间的合作分工。

可以讲目前是同步串联模式（PM交付需求给设计，设计画UX和UI给开发和QA，开发和QA实现给运维），完全可以革新转换为异步并行模式（PM、开发、QA、TA、Ops打破各自边界，前期一起来介入需求的分析，避免了后期反复的沟通，也提升了团队对目标的一致性认可，自然可达到齐心协力的效果）

 是设计界的设计冲刺：强调PM、设计和开发一起集中几天来快速完成设计定稿，规避反复冗长的沟通确认；

 一个是敏捷界的持续交付：持续交付的核心是一开始团队就要思考完整的服务流程，而不是各自思考自己的单点功能，而后期集成测试的时候，发现很多接口都缺失或对接不上。

一、需求分析的原因和目的：

 理清具体有哪些需求和它们的优先级（考虑的是一个点：需求）；

 让团队能具体执行下去，团队包含设计、开发、QA、TA、运维等（考虑到的是一个线的局部：整个团队）；

 团队一起给客户高效地、持续地交付有价值的服务（考虑到的是一个完整的线：考虑到了外部的客户）；

 团队一起实现自我价值，获得成就感和物质奖励，内心充实（思考回归到人和自己）。

二、如何做需求分析

1.判断需求的真实性

伪需求只是表面的需求点，真实的需求需要产品经理结合用户的真实场景去具象化。

2.判断需求是不是刚需（需求量是否足够大，是否有持续性，不能是一锤子买卖。）

1、估计目标用户基数、消费能力，意愿预算，行业公开对比。

2、可以提升多少效率，节省多少成本

产品价值=（新体验/新效率-旧体验/旧效率）-换用新体验的成本

如果这个需求解决了，但是用户的更换成本太大，使用体验还不如原有的。那么这个需求就很可能不是刚需。因为他没有实际上解决用户的效率问题。创新的本质之一就是“效率”

3.需求是否有延展性

考虑这个需求的背后是不是可以带来更大的市场，也就是这个切入点可以进入更大市场的机会是多少。是否有足够的延伸性。只有这样的需求才可以算是刚需，可以为我们持续带来发展空间。

4.衡量需求的变现能力

需求可以短期变现还是中长期变现？（用户是不是长期持续地愿意为这个提供预算）

同样的需求变现，行业内是否已有人在做？他的做法是否可以借鉴，他的产品在一定的时间内是否会和我们产生正面竞争，如果会，差异化的变现能力在哪里；如果想不到差异化，那么如何通过跟随进行弯道超车？

变现是否会影响用户体验？

5.客观分析需求，代入使用场景综合考虑

需求可以短期变现还是中长期变现？（用户是不是长期持续地愿意为这个提供预算）

同样的需求变现，行业内是否已有人在做？他的做法是否可以借鉴，他的产品在一定的时间内是否会和我们产生正面竞争，如果会，差异化的变现能力在哪里；如果想不到差异化，那么如何通过跟随进行弯道超车？

变现是否会影响用户体验？

1、判断需求合理性，认识需求的本质

（1）用户需求忌被揣测

（2）用户需求具有欺瞒性

（3）用户需求不等于产品需求

2、展开用户调研，深度挖掘需求

（1）对需求方的调研

（2）对相关需求方的调研

（3）对不相关需求方的调研

3、对比竞品分析，保持理性思考

（1）确定目标竞品

（2）横纵向对比

4、制定需求方案，寻求最优解

bug级别

严重程度由高到低依次为：

1.critical

2.block

3.major

4.normal

5.minor

critical：

系统直接崩溃，瘫痪。所有人员无法正常打开产品进行使用。

block：

逻辑出现严重问题，流程卡住，无法进行下一步。

major：

部分功能出现闪退，功能没有实现，但是不影响使用，功能菜单缺失

（一般demo结束之后，功能错误或者数据错误，重要的需求优化我们会提该级别bug，需求优化我们会注明是需求优化。不会影响系统稳定）

normal：

产品可以满足业务要求，部分小限制不符合验收标准，内容显示错误。界面主流浏览器（根据PM定）的兼容性。

minor：

界面等UI问题显示错误，比如字体大小，颜色，间距等问题，性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。