今日谈谈逻辑路径测试法，举个例子，系统中有一个目录移动的功能，测试用例如下：

逻辑1：“三级目录1”移动至“一级目录1”下        预期：可以移动
逻辑2：“三级目录1”移动至“二级目录1”下        预期：可以移动
逻辑3：“三级目录1”移动至“二级目录2”下        预期：提示“三级目录1”已在“二级目录2”下，不能移动。
逻辑4：“三级目录1”移动至“三级目录1”下        预期：提示“三级目录1”不能移动至自己本身的目录下
逻辑5：“三级目录1”移动至“三级目录2”下         预期：可以移动


          一级目录1
                 二级目录1
                 二级目录2
                        三级目录1
                        三级目录2

连续几天写了几篇工作日记，没有别的目的，只是希望初学者能够来看看，了解测试的工作过程，我这是写文章，所以没有很好的修辞，更可能会是流水账，因为工作就是这样，工作本身就是按规则来的，不是小说。

     今天的工作过程中，有两件事值得一写，第一件事，我给开发A负责的一个模块提了一个BUG，而此BUG是开发B负责的一个模块引起的，所以开发A拒绝我提的BUG，对于这种情况，在缺陷跟踪工具中的正确处理流程应该是这样的，开发A将此BUG转给开发B，而不是退回给测试人员。所以做为测试人员，一定要跟开发A解释清楚正确的流程处理规则，并讲解原因，为什么要这样处理：虽然A模块是由B模块而引发的错误，但是此错误只有在A模块身上才能暴露出来，在做黑盒测试时，测试人员是通过系统给出的现像，来判断程序的正确性，程序内部的情况对于我们测试人员是透明的。

   第二件事就是一个测试方法的问题，我给它取名叫关联性测试。第一种情况是，我测功能模块A时，删除了一条记录，而功能模块B中的数据是与这条记录相关联的，所以要验证功能模块B中与之相关的数据也要做相应的处理。第二种情况是这样的，模块A是个手工新增数据的模块，模块B是个批量导入数据的模块，两个模块都是操作同样的一张存储表，如果在模块B中导入数据时，模块A中新增的数据就会全部清空，测试过程中，当我做批量导入时，页面报错，提示导入的数据不符合某个校验规则，也就是说，数据批量导入失败，在这种情况下，我再去查看模块A中的数据，发现全部清空了。

昨天有个开头，所以要坚持下来，争取有点工作积累就写下来，一是让自己沉淀和反思工作过程中的方法和错误；二是供测试新手做为参考，能学点东西，将

我的工作经验吸收为自己的工作经验。

    今天工作中有两件事值的说一说，第一件事，谈谈与开发人员的沟通，今天测试过程中，发现有一个页面和需求不一致，因为该项目是一个投产了的项目，这

次只是新增了一些功能，不至于页面与需求相差这么大，所以我选择先和开发人员沟通，看是程序问题还是需求问题，邮件发过去了，而开发的回复是：“这次

没有修改页面，这是需求问题，以后类似的问题请恕不回复！”开发人员的态度极不友好，他也只是站在开发的角度想问题，而我们测试人员，绝对不能同意他

这种观点，以后有类似的情况，还是要和开发先确认，为什么呢？因为我们测试的依据就是需求规格说明书，只要程序没有满足需求的要求，我们就要提BUG，

如果开发不承认BUG，这时就需要写邮件向需求人员确认，并抄送给开发，在邮件中描述清楚问题，让开发和需求人员给出最终的结果，如果是需求问题，就撤

销这个BUG，重提一个需求问题的BUG。

    第二件事是关于测试策略的问题，今天在测了几个相似的功能模块后，发现都出现类似的BUG，所以，在后面的测试过程中，我就关注这个BUG，每个类似的

功能模块测到这个位置的时候，我都用这种测试方法，发现了很多这样的BUG，所以说，这是一个好的测试策略，在测试过程中，经常可以用到。给这样的测试

策略命个什么名好呢？交给你们了，亲爱的测友们。

  

     好久没有写日记了，今天先写个短的，以后慢慢再写长点，写深入一点的。

     对于测试新手或者毕业生来说，会议和周报总是没有头绪，不知道重点在哪儿，开会会打瞌觉，写周报罗索一大堆，

针对这种情况我来谈谈应变的方法及需要掌握的技巧。

一、项目例会：项目例会其实没有多少内容，万变不离其宗，开会时把握三点要素就行了，首先项目经理或测试经理会让各位项目成员报告工作的进度和下周的计划；然后由各成员汇报工作过程中遇到的困难、风险及需要协调的工作；最后项目经理或测试经理再总结一下工作，并调整工作计划，然后布置工作的进度。

二、需求评审：需求评审一般由需求人员或开发人员来主持会议，因为工作性质的问题，需求人员或开发人员在讲解需求时一般都是站在系统设计或开发角度来讲解或讨论问题的，而此时，测试人员听起来觉得就很素然无味，感觉听起来跟业务和测试关系不大，没有什么帮助，那么也就提不出什么意见或者挑出需求的错误出来，基于这种情况，我推荐这么几条原则：1、会议看几遍待评审的需求，如果没有时间，大概看一下也可以2、会义席间，测试人员要关注业务流程，基础数据从何而来，测试数据如何来做，当然开发或需求人员是不会在会议席间来讲解的，这就需要你来提问了3、一些需求不理解或者有问题的地方，一定要及时提出来让开发或需求人员来解答，这会提高以后测试工作的效率，减少沟通成本

三、周报：周报只需写两项内容，1、这周都干了什么，任务的进度到哪了；2、下周计划干什么，准备完成多少任务。这两项才是领导关心的，其它的屁话都不要写。