5月24日工作日记

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

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

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

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

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

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

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

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

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

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

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