今天完成的事情：今天了解了互联网各大职业的发展及需求，写完了测试用例，提交了任务一，总结一下，测试用例的编写并不复杂，但是是一个十分细致的工作，需要耐心及细心，刚开始编写时会有一点无从下手我们可以多参考一下师兄，师姐们的日报，然后在网上多看看，就能学会如何编写。然后会看一下深度思考的东西。

明天计划的事情：明天先看深度思考，然后开始任务二的学习

遇到的问题：今天遇到的问题有如何编写测试用例，互联网职业有哪些，优先级如何判断。

互联网的职业十分多，但是我们了解多一些的应该是PM，前端工程师，后端工程师，ui，qa，ios/安卓工程师；通过听知乎上的live，大概了解了每个职业的前景以及发展方向，职业成长等。

关于测试用例的编写，首先推荐的是人人都是项目经理上的文章，其次就是师兄师姐们的日报，写的非常的详细，我们可以多浏览，然后总结一下每个人的优缺点，进行学习，推荐多看近期的日报，会更有代表性，也更加的全面。

优先级的判断是一个朦胧的概念，我们百度到的大多都是一些概念性的文章，我觉得收获最大的是来自PM-王雯师姐的总结

她的总结如下，让我获益匪浅；

测试用例优先级划分

P0-核心功能测试用例（冒烟测试），确定此版本是否可测的测试用例，此部分测试用例如果fail会阻碍大部分其他测试用例的验证

P1-高优先级测试用例，最常执行以保证功能性是稳定的

P2-中优先级测试用例，更全面地验证功能的各个方面，异常测试，边界、中断、断网、容错、边界测试

P3-低优先级测试有力，不常常被执行，性能、兼容性、稳定性等

怎样分配测试用例的优先级

一般来说，功能性测试分类标注为高优先级，错误或边界测试标注为中优先级，非功能性测试标注为低优先级。再将各类分为重要的和次要的，根据具体情况对其进行升级和降级

再通俗一点讲；优先级的划分就是将那些重要且紧急的调高优先级，重要性第一；尽量不要让紧急的影响更大，特别是紧急不重要的；

今天的收获：学会了测试用例的编写，了解了互联网相关职业，了解了优先级的划分，明天就开始第二天的学习，先进行深度思考的学习。

今天完成的事情：完成了任务一的深度思考，了解了敏捷开发，了解了需求分析，开始了任务二，任务二在撰写日志，下载了axure，了解了一些axure的基础操作。

明天计划的事情，继续完成任务二的事情，制作axure原型。

遇到的问题：对于网站设计不熟悉，做网站设计分析时有一定的问题，在师兄的帮助下，百度找到了正确的答案。

收获：通过今天的学习我对于敏捷开发以及需求分析有了如下的一点理解；

1.敏捷开发
对于敏捷开发，我的理解就是这是一种十分灵活的工作方式，但是相对于传统的工作方式而言，敏捷开发对于工作团队的专业素养要求更加高，在一个没
有等待时间，每个人都有精确到天数甚至是小时的工作体系内，如果某一环的专业知识无法达标，那么整个开发都会陷入困境，所以从另一个方面来讲，敏开发会暴露出开发团队平时隐藏起来的问题，敏捷开发推崇无文档开发，所以对于团队的扩大而言，新加入的人群对于过往的工作会更加难以理解，所以相而言我认为文档的重要性还是有的，不需要每个人都写文档浪费时间，但是一个好的产品文档是作为一个好的PM所必备的，一个好的产品文档，对于别的门，公司来说可以大幅降低沟通成本，对于自身而言，对于自身的产品有着一个全面的认识，对于后面加入的新人而言，他可以在短时间内融入团队，对于队的开发进程有一个较为全面的了解。所以敏捷开发是一个十分灵活的开发方式，但我们也应该更加灵活的运用这一方式而不是一味的跟着开创者。
2.需求分析
  人都是有需求的，需求汇聚到一起，就成了客户的要求，而产品的意义就是为了迎合用户的需求，但是迎合用户的需求并不是完全按照用户的意愿来对自己产品进行修改，用户中只有很少一部分知道他真正想要的是什么，而产品需要迎合的却是特定的目标人群，所以需求分析的意义，就是将用户的需求转化为品的需求，然后再用产品的需求去满足用户的需求，听起来有点矛盾，但我的理解就是，任何人做任何事都有原因，这个原因往深处挖掘就是人性，每个人是有需求的，产品需求就是为了迎合人性，它的目标不是对人，而是对更深层的人性，所以满足人性，是一个好产品的前提，然后如何去找到这个根点，
就是发掘用户的动机了，一个人有欲望去做某件事情，应该是在某个环境下，某个事件所刺激的，所以，环境，用户与行为，就成了我们发掘用户动机的要素然后我们还需要对需求进行评定，不是所有的需求都要满足，我们需要有价值的需求，那么判断需求，我们就需要一定的标准，判定的标准就是，从四个维度广度，频率，强度，时机。广度是需求的受众面，频率是需求的频率周期，强度是用户对需求的需要，时机是需求与产品规划以及当下的环境的符合相性。
3.Bug
程序员写出Bug是一件十分正常的事情，无bug交付是几乎不可能实现的事情，特别是在敏捷开发一直推动的情况下，检查bug是一件非常困难的事情，所以
无bug交付我认为不能实现，我们能做到的只是在bug出现后最快的速度修复它，bug修复时间不能影响项目的上线时间，我觉得这是一个底线，我们应该为
bug修复留下充足的时间而不是到了上线时间之前才急忙排查bug，但是如果在临近时期，发现了一个重大的bug，我更加愿意，按照时间上线，然后以最快
的速度修复bug，更新产品。