今天完成的事情：（一定要写非常细致的内容，比如说学会了盒子模型，了解了Margin） 
明天计划的事情：（一定要写非常细致的内容） 
遇到的问题：（遇到什么困难，怎么解决的） 
收获：（通过今天的学习，学到了什么知识）

看了一个漂亮师姐写的东西。懂了测试是干什么的，别的不懂

http://www.jnshu.com/daily/72196?dailyType=others&total=68&page=1&uid=15565&sort=0&orderBy=3

 但是即使测试熟悉了，一旦产品开发出来，测试拿到参评就开始使用找bug吗，我想即使测试熟悉了产品，在测试的过程中肯定对产品的功能有所遗忘，即使是熟悉过文档，由于一款产品的功能模块实在太多；如果测试只是凭着对需求文档的熟悉度，就开始乱点，没有计划没有目标开始测试，到头来自己做过哪些操作都忘记了，更别谈测试效率，能把测试工作做好了。所以在产品的规划设计阶段，测试就 已经开始参与到产品中来，开始熟悉产品，收集各种文档整理成一些操作步骤，这样就形成了测试用例，于是用例的生命周期就开始了。所以用例的第一个作用就是，把产品需求转换为一种可操作的步骤，方便以后有步骤有计划的进行测试。而在这样的转换过程中，由于这种很强操作的逻辑在进行，往往测试能发现产品中设计的bug，因为在设计用例的过程中，实际上是在脑海中模拟使用产品；所以，在写用例的过程实际上就是对产需求进行测试的一个过程。所以写用例的第二个作用就是验证产品的需求是否合理。如果发现产品需求不合理，或需求有矛盾的地方，甚至不明确的地方，这时候我们的用例进行不下去了；因为我们写的前一个步骤可能有多个结果，那么产品要的是那个结果呢，或者那几个结果呢。于是我们需要找产品确认；产品一看，这确实需要优化，或需要考虑或者需要想出更好的方案。所以这里又体现了测试用例的第三个作用：监督产品对需求做出更加详细的设计。而当产品想出好的方案之后，给了测试回复，于是测试把他写进测试文档。这有体现了测试用例的第四个作用：记录产品的设计细节，保障以后的查阅。而测试有了这样一个与产品沟通的过程，对该模块有了更深的印象，这里体香了测试用例的第五个作用：加深测试人员对产品的认识和印象。当产品开发出来了，测试这边的准备也差不多了，于是测试人员开始按照测试用例的描述测试，每过完一个用例标记完成；这样测试也知道自己做过哪些操作，避免没有目的随机测试，并且通过测试用例的执行条数，大致了解该模块的测试进度，这又体现了测试用例的第六个作用：反应测试进度。而测试人员在执行用例的过程中往往会突然发现当初设计的用例步骤中，还可以做这样一个操作，于是发现了bug，这又体现了测试用例的第七个作用：帮助发现拓展测试范围，扩大测试覆盖面，发现软件中潜藏的缺陷。