<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
在超图 工作 两年了，这两年来，从刚开始对测试认识的朦朦胧胧，现在思路也逐渐清晰了，也明确了自己的发展方向。虽然对那些测试理论和测试工具以及测试技术有了一些加强，但是自我感觉还是不够深入。
我一直希望能真正融入到测试的队列中去，让自己每年对 测试 的 理解和技术更深入一层，成为一个专业的测试人员。 这几天整理了一下思路，回顾了这两年来做测试的点滴想法。
1. 软件测试人员应该不断学习
身为测试人员，虽然我们平常的 工作 大部分都比较安逸。但是千万不能温水煮青蛙。应该自强不息，不断 学习 ，提高自己的测试技术。因为测试本来门槛就稍低，如果懈怠，随时都有可能被取代。重点就是深入学习测试技术，然后将技术应用到现有的项目中。
2. 测试人员应该熟悉业务需求
测试人员的水平主要体现在 测试用例 的设计上。要设计出全面，覆盖广的测试用例，需要测试人员对自己所测试的项目的业务需求非常熟悉，甚至要比开发人员还要熟悉。 1 、要熟读功能需求文档，任何有疑问的地方都要去和负责人确认。 2 、把自己当成最终用户，经常使用自己所测试的软件，模拟用户的行为。 3 、熟记软件的每个功能。
3. 学会如何跟开发人员相处
测试人员必须跟开发人员密切合作，所以跟开发人员搞好关系是相当重要的。 1 、和开发人员常打交道，尊重开发人员的工作成果，这样开发人员也会认真对待你提出的 bug 。 2 、集中问问题，将需要问的问题都总结起来，集中问开发人员，这样能节省大家大量的时间，也不会打扰开发人员的工作。 3.bug 描述要清楚，要能重现。以免开发人员要么将问题踢回，要么还得找你重新问，会耽误彼此的时间，降低工作效率。要写好 Bug ，描述精确，简洁，没有歧义，详细简洁的重现步骤，加截图。
4. 提升文档的编写能力
测试人员写文档的地方比较多，平时测试用例、测试计划、测试报告以及用户手册等等都体现着测试人员文档编写能力的重要性，如果后期往 TestLeader 发展，还要非常擅长汇总测试报告，能够将完整，清晰，漂亮的测试报告发给各个组，让公司所有的人都能清晰的看到测试组的工作情况。
5. 实行“一对多”的模式
“一对多”的模式是指：一个人可以同时测试多个项目，一个项目由多个人测试。因为每个人的见解和操作方式不同，所以发现问题的可能也不大一样，更有利于找出不易发现的 bug ，一个测试工程师测久了自己的项目，容易形成眼盲。会对一些 Bug 熟视无睹。
6. 测试人员应该深入学习一写测试技术
初入测试，可能还提留在探索的阶段，不清楚要学习哪些和测试有关的技术，这时就需要我们主动去发现，通过书本和网上去看别人都是怎么做，汲取可用的经验，避免少走弯路。测试人员要提升的技术包含方方面面。
例如：性能测试（可参考的工具 loadrunner ）、自动化测试（可参考的工具 QTP ）、脚本语言（ VBScript 、 Python ）、数据库（ SQLServer 、 Oracle ）、操作平台（ windows 、 Linux ）、 Web 测试（ Selenium ）等等，还有很多很多，这么多的技术，学习只是一方面，更重要的是要根据我们现有的项目和测试环境，去分析什么才是最适合的，这样才可能真正将所学应用到项目上来。
7. 建立一套完善的测试流程
测试流程已经大同小异了，但是真正按照流程来做的还是很少。如果条件允许的情况，还是应该尽量去按照流程去走，先去做单元测试、然后集成测试，而不是上来就直接进行系统测试。
8. 多于客户和领导沟通
这点是想说给开发人员的，每一个开发人员一定要有自己见解，当某个功能和领导意见不一致时，应该用自己的理由去和领导说明，而不是领导说什么那就是什么，当被问到为什么要这么设计时，他的回答是：领导让这么做的。
因为每一个领导看项目的感觉又会不一样，所以今天领导提出一个想法，你改了，明天另一个领导又有新的意见，你又去改回来了。开发人员也没自己的意见，时间久了，一个功能改十次，再强的开发人员也会被拖垮的，而且时间上确实被大大的浪费了。
以上 8 点仅个人在工作中总结的一点意见和想法，仅供大家做下参考，如果不合适的地方，还望指正。