一、开发常对我说的话，听了心里蛮高兴的，这是开发对我们测试工作的一种肯定和支持：

1）“幸好有你帮我把关”

2）“有你把关，我们放心多了”

3）“我发现你测得好细阿”

4）“你好细心阿”

5）”你辛苦了“

二、测试有时候并不是仅仅测试需求点，更需要站在用户的角度上去考虑他们的使用感受、操作习惯、及用户可能出现的操作流程。

三、缺陷应该从一开始就要杜绝。缺陷如果从一开始就没有杜绝的话，那么有关这方面的功能或流程，开发就会延用或仿照原来的流程和设计方案走下去，结果缺陷就越积越多了。我目前所负责的系统就是这样子，发现了很多缺陷，结果开发说：‘这个问题系统一直都是存在的，其他的产品也是这么做的’、‘业务不会这样子操作的， 业务会人工逻辑控制的了’、‘因为以往相关功能也是这么处理的，如果要改的话，那么就需要业务提需求，把原来的也一起改掉’，结果跟业务、开发电话会议沟通后，业务说“没关系的，系统是一直都是这样子的，我们会自己人为控制了”，最后我们就无话可说了，只有把缺陷拒绝关闭了。（我们没有业务的权利大啊，呵呵~ 纳闷~）。可我之前听说公司的财务系统出现了一个严重的错误，造成了大量批处理后的数据错误，原因是一位不熟悉该系统业务操作流程的同事由于操作错误引起的。公司的财务系统使用了那么多年，这个缺陷就一直存在了，想想中间可能有过测试人员发现过这个缺陷，但也许是因为开发或业务类当时似上面的话而放弃了自己的坚持了。所以缺陷必须在一开始就杜绝，绝不可因为“不会那样操作的”而放弃了，因为这不仅仅是这个需求的问题，而是关系到后面系统功能在不断增强的问题，我们不可给开发以后说“系统一直都是这样子做”的推词机会。

四、一个新增的业务操作流程一定要仔细和重点测试。这是因为这关系到后面系统有关这个流程功能的不断增加，如果第一步功能实现没走好，那么后面的功能需求也将会跟着错下去的。这其实业是上面第三点的一个补充了。（最近测试了一个需求（主要业务流程为“机构申请、中心审核、机构跟踪等”），我是最有这个体会了。因为开发说后面还有很多需求都是关于这个流程的，他以后的需求都是在此基础去做的，所以我就很细心地测了，因为我怕影响到开发后面的开发，所以我尽量尽早地去发现错误了）

五、关于功能实现所采用的技术的安全性和可靠性。最近接触到一个需求，这个需求的功能实现涉及到跨多个数据库访问的问题。在这个需求的测试过程中，开发还进行过两次的有关跨数据库访问技术的调整。过程中，开发问了我个问题说“你们黑盒测试的话，怎么保证这个程序的对后台数据的正确性，及技术实现的安全性和可靠性呢？因为有时候前台的功能是实现了，但程序里面的缺陷怎么办？”。是啊，谁来保证功能实现所采用的技术呢？只有开发自己吗？......

六、与开发、业务的相处。这个怎么说呢，不过我是抱着互相帮助的心理的。平常业务有不懂系统功能有关程序实现方面的问题，他们问我，我会很快地尽量详细回答他们。有关测试数据和测试环境的问题，我也都会努力的帮助他们。我平常有不懂的业务知识我就找业务他们，他们也很乐意地为我讲解。对于开发，他们咨询我有关我们的测试流程、测试环境问题、他们需求有关测试的情况等等，我都会尽可能地告诉他们。测试发现的缺陷我一般都会先跟开发打个招呼沟通一下确认一下，或如果是很明确的缺陷在我报了之后，我都会第一时间告诉开发的，好让他们先有个心理准备。在开发程序移交部署后告诉了我，我也会尽早的去验证的，缺陷验证通过后我也会第一时间告诉他们，因为我明白他们也焦急，通过了他们就放心了，呵呵~。我平常咨询需求问题和需求实现方式等，、开发也会很快地回复我的。所以我跟他们相处得都很好，工作也很开心和顺利。

七、与开发、业务关系太好的问题。最近发现了些问题，跟业务同事关系太好了，他们测试的时候总是不放心自己测试，总是会问我我的测试结果。他们发现了缺陷也会不敢确定，总让我给他们验证一遍，这样我总是处于很忙之中，分心去处理他们的事情了（我们的IT和UAT测试阶段界限不清晰，所以很多时候我们的测试时间都是混在一起测的了）。而对于开发，当我一发现缺陷的时候，除了报了缺陷，还直接把缺陷告诉开发了（我想尽早地让他们知道缺陷以便尽快修复），但不知道这样不停地告诉他们缺陷，会不会影响他们的工作？ 这个得问一问才行，呵呵~

八、与开发的沟通。前段时间公司举行了一次测试理论和流程的培训，其间讲师说了一句话“我们要对事不对人，开发写出的程序不管是好是坏，对他们自己来说他们都是喜好不已的，我们不可妄加评论他们的代码，更不可一句话地说好还是坏（对业务需求也一样）”。其实与开发沟通不必太过于针对和强调BUG，如果是认为是其哪个地方的代码的问题，应该用探讨性语气来与他们沟通。

九、站在开发的角度，体谅他们的苦。我自己也做过开发，不过幸好我们的一个项目，客户最多来两三次来检查项目质量，但我都受不了客户，每次来都提一大堆问题，之后我们就得改程序。现在想想我们的开发还真可怜，业务不断地要求完善功能，提新需求；我们测试发现的缺陷他们也要改阿改的，所以他们总是处于被动之中，忙碌之中、紧张之中（现在我想，如果我在公司是做开发的，我还真吃不消呢。其实想想，公司那么多的IT部门之中，我们测试部门是最幸福的了）。所以不要埋怨开发有时候不及时回复你的邮件，不接你的电话。我想开发也不是故意不理你的，他们忙啊。有的可能还需要了解他的性格，有的开发做起事情来真的太投入和专注了，他们不想被打断。（其实自己这样想心理也会舒服很多的）

   公司的测试执行作为一个单独的步骤已经开始推广了 ，上个星期我的测试案例大都让执行人员来执行了，但测试执行的结果却让我大跌眼镜。我随便挑了几个执行通过案例来看，查了一下系统数据记录，我需要看到的数据都没有产生，不放心阿，那这是什么原因呢？

  有的其实很明显就可以看到是执行人员从中偷懒了。而有的呢，经与他们沟通后发现他们没有看清楚的我的案例或是没有理解案例所要求的操作意思。对于前两者我能说什么呢？我只能说测试执行一给测试带来一环不必要的风险了。而对于后者，我得改进，但如何改进呢？

  那就得改进案例使得无歧义了，可这个难度可大了。即使是一篇研究报告可能都会存在歧义的，更何况我们编写案例的时候只是在寻找如何用案例来验证需求程序，没有那么多精力去咬文嚼字啊或去考虑更多的执行人员到时候会怎么理解自己的案例了。

  其实我个人认为，只要对系统稍了解的人员都应该比较容易理解我的操作要求了，只是公司领导对执行人员的要求和理解就是像一部机器那样，按照设定好步骤来执行，他们不需要了解系统。可这真的可行吗？也许可以，那就是要求我们这些编写案例的人员需要写清楚点击哪个菜单，哪个按钮了。但我们没有精力放在这些操作上阿，我们也没有必要把精力放在这些无聊的操作上阿。测试的目的是什么？ 不就是为了发现更多的缺陷吗？

  也许公司推行测试需求分析、测试案例设计、测试执行分别独立的测试流程对于管理上是比较好的，但对于系统的改善是否有好处呢？从改善方面我们就不好说了，因为我们还没看到结果。但却增加了我们的工作量和沟通量（特别是开发人员），目前测试流程各步骤是这样子的：

1、测试需求分析：测试需求分析的人员将需要跟开发和业务需求提出人沟通需求

2、测试案例设计：测试案例设计人员需要跟需求分析人员沟通测试需求，并且需要与开发人员沟通系统程序设计的实现等

3、测试执行：执行人员需要与案例设计人员沟通如何执行；案例设计人员需要去跟踪执行情况，验证缺陷是否是真的存在，还需要与开发沟通缺陷、协助查错等。（当然按照流程的话，案例设计人员可以不管这些事情的，但能放心得下吗？）

  当然，这种场面绝对不是领导们所愿意看到的，特别是执行步骤上，他们的理想状态是没有沟通。不过如果真的如他们所要求的那样--案例说明点击的按钮或菜单，执行人员把所使用的数据保留，也许是可以零沟通的。但我还是怀疑，文字真的可以代替沟通吗？真是难为开发了

  总之啊，如果真的需要做到领导们的那理想状态，测试需求分析人员和案例设置人员都必须要努力地去减少歧义，减少沟通。但实际真的能做到吗？大家追求了那么多年的业务需求清晰性，不也始终在努力中吗？沟通始终都是在所难免，必不可少的。

 也许我们这些下属们站的低，看不到全局吧。希望这样子流程在有得有失中，得大于失吧。

   今天看到一个文章，提到需求测试和案例测试，突然想起了公司半年前开始实施推广的测试流程（测试需求、测试案例、测试执行分别独立进行）曾经也提过这两个词，但那时并不在意，今天再看到这两个词，结合对当前公司所实施的测试流程的体会，其实我们已经在进行这两项的测试工作了。真是茅塞顿开啊，另有一幡体会啊，呵呵~