看过了很多关于测试方面的书籍以及网上盛行的一些电子资料，同样也去考了评测师考试，一路走来，虽然自己有别于测试人员的日常工作，但是恰恰就由于自己站在一旁，所以更能发现目前大部分人测试工作的无序、低效率和低水平。曾经做过几个项目的性能测试，关于性能测试下文我将会详细说一说自己的看法，做过几个项目的验收测试，也做过一个项目的测试活动的审查工作。可以说，自己也实实在在拿着项目，真枪实弹的做测试。到目前为止，即使我所负责的数次测试工作能够发现问题，并且是在项目组已做了系统测试的基础上，但是我对自己的测试实战水平以及测试管理都不是很满意。下面说一说我对测试工作的几点看法。

　　● 不能脱离测试模型理论，也不可照搬理论

　　测试模型很理论且目前还在不断探索阶段，还没有一个具有统帅地位的模型在各个企业盛行。现在的状况是，很多人就了解V模型，而且仅仅也是理论上了解，运用到实际中，就执行不下去了，最后索性不关注测试模型了。这里，我想说的是，你用V模型能够在实战中顺利开展工作，那就奇怪了。因为这个模型根本就是不符合当前开发模型的嘛。这个测试模型就是开发模型中的瀑布模型的配套措施。

　　测试模型到底在实际工作中能不能够运用呢，我的看法是，取各个测试模型的精髓即可。根据公司现状，人员组织结构，人员配备情况，人员素质水平来规划自己的测试模型。弄好后，要写入《测试计划》中，发给所有测试人员，获得大家同意。

　　测试模型的精髓我感觉就可以这么简单的概括，越早投入测试越好，越早发现问题越好，不断的测试，独立的工作。

　　● 测试技术不能光说不练

　　针对目前的面向对象的发开特定，几乎没有人做面向对象的集成测试，还是一股脑的对着屏幕一顿点击，输入一些测试数据，可以说几乎没有多大技术含量。想一想，你整天做没有技术含量的工作，怎么提高自己的薪水，怎么提高测试人员在项目中的地位和形象。

　　除了对于系统做一些黑盒测试之外，现在基本上这也做不好，是否可以对各个阶段的输出物做一个测试，这里主要指的是个人评审；同时针对评审（不仅指测试人员的评审，指的是经过了技术评审、会议评审）后的文档设计你测试人员的测试用例。

　　目前，测试人员老挂在嘴边的就是，需求没有文档，没有需求可追寻，无法写测试用例。如果老是这样子，你觉得对你的测试工作有帮助么，你觉得你这么抱怨了后，你的水平就提高了？你的薪水会因为你会发发牢骚就涨么？（不过，也有部分人，因为会发牢骚而得利的）基本不会，那么你就要想办法，怎么在如此恶劣的工作环境下，将测试工作开展得顺利。

　　我提供的方法就是：

　　◆ 测试用例关联到需求，即使需求很烂，也要关联到；

　　◆ 借助需求分析以及设计文档，形成自己的测试设计方案或者说是测试用例设计文档（此文档应该包括测试需求），这份文档必须经过大家的评审，然后根据文档写用例；

　　◆ 不要跟我提什么单元测试、集成测试、确认测试、系统测试，在这里，只要你运用黑盒测试方法给我测程序功能就OK；网上所流行的一些通用测试用例，一些界面测试检查点，通通都不能够直接运用进来，除了增删查改功能的测试点可以借鉴以外，其他的东西通通都不要浪费时间去测，这些方面的通用测试用例，不是没有用，肯定有用，但是这些不是我要测功能的手段，这些可以全部放到易用性测试方面，测试的话，别搅和在一起，到头来什么都做不好，你根据那些检查点肯定能够测出一些问题，但是，这些问题无关乎功能的实现，开发人员不在乎，项目经理不在乎，用户有时也不在乎，当许多事情堆在一起的时候，就要分紧急重要了，功能实现是最重要的，易用性其次，所以，在功能性测试完成后，大家再回过头来测一测易用性，有时这些易用性，只要测几个界面就可以，这个模块的这个界面出现的bug，在其他界面其他模块也存在，所以没必要那么每测一个界面发现了有共性的问题就登记一条。

　　● 再怎么不济也要定测试策略

　　测试的技术有哪些大家都知道，不再累赘重复，那么如何将这些常用技术落到实处，这就要针对项目特点制定测试策略了。

　　常见的做法就是没有测试策略，莫非是这些人已到达登峰造极的地步，手中无剑，飞花摘叶便可杀人无形?我看不是，这些人才懒得管什么测试策略，对着系统就是一顿乱搞，就是写个测试策略，大多就是写用黑盒测试方法进行测试，完了。真想骂人，这也叫策略？要他们去打仗，他们估计就说拿着杆枪对着敌人开枪就是。既然是大学毕业的高材生，既然是像模像样的坐在办公室弄信息系统，怎么着也要整出一套测试方案出来吧，怎么做，做哪些方面，做到什么程度，什么时机做什么，遇到阻碍有什么应对措施。即使你不可能搞这么多，也不相信搞了这些项目就成功，那么你至少应该统领全局，告诉下面的人，运用哪些技术如何测嘛。说了这么多，我说说自己的看法。

　　目前做测试，其所测对象按道理应该是程序、数据、文档的，现在只说程序，那么目前所测的程序，可以说基本是B/S结构，面向对象开发出来的程序，所以我所要谈的测试策略就是围绕面向对象开发出来的WEB应用系统。

　　◆ 首先，把系统分成若干模块，分配到测试人员。

　　◆ 然后，让测试人员分析测试需求，写成测试设计文档，再来写用例，不准直接写用例。测试设计文档，必须既有整体宏观的把控又有微观的考虑，什么意思，换句话说，宏观方面，测试人员要根据项目组的分析设计文档将自己所负责模块的功能图画出来，这里不强调一定是功能图的形式展现，不管用状态图、流程图、用例图、场景图还是因果图，反正一条，这个模块的功能，在宏观上你要了如指掌，并且能用图形绘制出来；微观上，测试人员在有了宏观的感知后，分析出测试场景，基本路径一定要覆盖，并且要想出一些异常场景。接下来，就可以根据自己所分析出来的测试场景进行用例设计了，这里的用例设计还得继续微观化，必须运用等价类、边界值的理念设计用例，并且这种理念要在测试设计文档中体现出来，写用例只是将用例设计文档的思路具体化。

　　◆ 接着，由一个人负责各个模块之间有数据来往，这里不提有接口的情况，因为面向对象的开发，接口无处不在，测试人员也压根弄不明白接口调用，这里测试人员只需将各个模块之间有数据调用的场景给测到了，就OK。

　　◆ 最后，测一测易用性，将网上盛行的通用测试用例拿来跑一跑，测一测性能。关于性能测试下文再来扯一扯。

本文出自wanggege11的51Testing软件测试博客：http://www.51testing.com/?140437