今天完成的事情：因为工作问题放下一段时间，要继续学习了。

                           1.重新温习之前所掌握的关于PM测试相关资料；

                           2.根据需求撰写测试用例；

                           3.提前预习任务二（Axure）

明天计划的事情：1.根据任务一萝卜多需求编写完测试用例，有点多，比较需要耐心；

                           2。准备完成任务一最后一步；

遇到的问题：1.测试用例需要编写的太多，有没有一个标准呢? 在网上查了下，没有具体答案，只是说用例要尽量详细和完善。

                    2.点进去后台管理一脸茫然，不知道怎么测Bug；   

收获：1.不得不说一段时间不学，脑中的知识就会模糊很多，今天重新复习了下，开始慢慢找回了：

             测试用例的具体内容：

                                      序号： 方便查找和排序，就是按顺序下去的。

                                      模块：该功能点具体属于哪个模块的，填写这个主要是方便查找，如：注册/登录模块

                                     编号：对每个用例进行编号，方便后期跟进。毕竟用文字说，容易口误。不过此处建议编号设计的有点规则，方便快速定位查找。如：A0001。其中A表示注册/登录模块。00表示账号登录，01 表示账号密码登录下的第一个测试用例。

                                      功能点：具体指某个功能，如：账号登录、首页、发布等。

                                      子功能点：具体指功能点，如：账号密码登录、手机验证码登录、邮箱登录、第三方授权登录等。

                                      用例名称：具体测试用例的名称。如：输入账号、输入密码、密码不合规等等。

                                      前置条件：指要达到预期测试结果，需要满足那些条件才能达到。如：账号密码不一致时，就需要登录失败，那么此时就得保
 证账号正确或密码正确以及账号正确时是存在的。

                                     操作步骤：指要达到预期测试结果，需要按这些步骤来。最好说明在什么页面，点击或操作什么内容，输入什么内容。预期结果：说明按照前面写的应该呈现出怎样的结果。

                                      测试结果：如果符合预期结果，直接填写正常或OK，如果不符合，则说明不符合或NO，

                                      预期结果：如果正常，可以不用填写，如果不符合预期结果，则说明哪里不符合。---------写出相应步骤应出现的结果；

                                      测试人员：填写测试人的名字，方便后期跟踪BUG。

                                      测试日期：填写测试的时间，方便后期查询。

                                         BUGID：跟测试编号一样，自己设定ID规则，方便快速查询。

                                         BUG负责人：此处应该有技术那边填写，具体落实到某个人身上，才能更好的解决到问题。

 PS:看了下其他师兄的日报，发现并没有这么多内容，有些好像不是那么必要。

 2.再撰写测试用例的时候，发现可以大开脑洞，想多各种奇怪的Bug，把自己当做用户去测试，这样会更好。