我原来发表过这个文章，老blog不知道什么原因进不去了，后边还要加东西，所以重新发表一下。

我是在2006年5月到新单位工作的，如今已经工作了4个月，新单位是一个很不错的单位，项目饱满，资金等方面也没有太多的问题，但就测试部门工作的情况却很不乐观。具体表现是人员少，任务重，人员不稳定。领导对测试部门的工作很不满意，在面试我的时候就多次表示了对公司目前测试不满，期待我来之后能够带领测试部门有一个比较好的发展。

首先说说我们公司测试部门在这四个月的变化吧

1测试人员大量增加，原来的测试人员为3人，现在为14人，人员扩充了3倍，目前来说，测试人员的数量还不是很多，但相比原来部门的扩充速度还是很快的，另外一个方面，由于我们工作比较有成效，领导基本认可开发人员和测试人员比例可以达到1：0.8或1的比例。我想这个比例对一个国内的企业来说已经是很高的比例了。

2个人素质的提高。具体的个人素质提高不是很好说，还是用项目来说吧，我刚来的时候，测试人员在一个系统测试的时候，一般测试需求点位500个左右，后来一个项目在作回归测试的时候，测试需求点达到15000个，第二次回归测试的时候测试需求点达到了49000个，这里要说明的是，我们测试需求点的增加不是为了增加而增加，而是对被测试需求各种使用情况分析的更详细，程序覆盖强度越来越大的结果，测试发现的问题深度逐步增强的反应。

3机器设备的变化，测试人员是开发群体的弱势群体，他们的机器配置也是公司最低的，刚来的时候，全部测试人员都使用P4 1.7完全不能满足自动化测试的需要，目前，测试人员基本都是P4 3.0双核，液晶，测试人员很高兴。另外我们还有专门的测试流程管理服务器，一些淘汰下来的老机器作为专门跑测试用例的测试专用机。

4开发人员对测试人员的态度改变。测试人员在开发过程中处于弱势地位，这是一个不可回避的现象，原来开发人员可以随意的让测试人员作自己认为需要的测试，而测试人员是没有办法拒绝的，甚至连具体测试的方法和手段开发人员都要干涉，而一旦出问题，首先怪罪测试人员，而不是找自己的责任，测试人员成了项目失败的替罪羊。而现在这种已经发生了很大的改变，至少测试人员有能力展示他们的特长。而不是开发人员的附属。

5领导对测试工作的态度转变

我刚到单位的时候，领导们对测试工作很不满意，给我印象最深的是领导说，测试部门的工作人员，可用的就留下，不可用的就直接开除，这对测试人员的工作评价实在不高，现在好多了，首先测试部门现在的工作得到了领导的认可（原来我们总是被批评，而现在总是被表扬），其次，人员、设备的配置在增加，最重要的是，我们要求的测试时间可以得到保证。

 

到单位工作4个月了，测试部门出现这么多的变化，有很多原因，但最重要的就是那句话：做正确的事情，正确地做事情。

个人认为做正确的事情比正确地做事情要重要，道理很简单，中国的一句成语，南辕北辙是最好的解释了，如果不能了解什么事情是正确的事情，那么你做事情的效果越好，则整个项目失败的可能性越大。下边先说说我到单位做的几个事情。

1和领导达成一个协议

    和领导达成一个协议是一个很关键的事情，我在面试的时候，就了解到了领导们对测试部门的工作很不满意，希望很快扭转测试部门目前的工作状态，但一个部门工作状态的改变不是一件很容易的事情，在面试的时候，我就和领导们达成了一个协议，争取测试部门在3个月内有一个小变化，6个月内有一个大变化，12个月内形成一个良好的工作环境。领导是 一个明白人，没有强迫我在几天或几周内就要 有一个大变化，这为我们部门以后的发展打下了一个良好的基础。

1测试需求点的改进。网络上有一个帖子说微软的用户登录功能的测试用例有5000个测试用例，很多做测试的朋友第一个反应是变态。大家的这个反应有很多妒忌、羡慕的意思，其实更多的是不知道为什么微软会写那么多的测试用例，而如何写出来（这是测试人员第一个基本功）就更不了解了，于是才有了这个反应。其实编写测试需求，编写测试用例几万，几十万，几百万并不是一个很难的事情，关键看你是否掌握编写测试需求以及测试用例的方法。
测试需求的来源是系统需求报告（或者叫软件规格说明书等名字），测试需求报告主要内容是本次测试需要测试那些点，一般的系统需求说明书是按照系统，子系统，模块、功能、子功能、数据的形式来编写的，（这里是指的比较规范的需求说明书），比如人力资源管理，可能包括前端人力资源管理子系统（给人力资源部门的工作人员使用），后台管理子系统（系统管理员进行用户管理，权限管理等操作的系统）。用前端人力资源管理子系统而言一般有人员基本信息管理模块，薪金管理模块等模块，而人员基本信息管理模块又可以分为添加新人员基本信息功能，修改人员基本信息功能，删除人员基本信息功能,查询人员基本信息功能，汇总人员基本信息功能等功能，而在添加新人员基本信息功能里会涉及到人员基本信息的具体数据内容，比如人员姓名、性别、出生时间、到本单位的时间等信息。以上内容都应该在软件需求报告中获得，很多单位由于开发流程的差异测试人员即使不能在需求文档中获得，也应该可以从概要设计文档或者详细设计文档中获得，最糟糕的，也可以从开发人员的开发的系统上获得（顺便说一句，测试人员获得这些信息的顺序，可以代表开发部门开发的规范性和开发能力的高低，越早获得说明开发越规范）。作为一个测试人员可以依据这些信息编写测试需求，但此时编写的测试需求会很粗糙。一个系统编写的测试需求点会是几百到几千之间。写到这一步作为初级测试人员应该是很不错了，但这些东西都是用开发人员的成果转化过来的，还没有看出测试人员的能力。让我们将测试需求点进一步分割下去。拿人员基本信息管理的添加功能来举例吧，首先：可以分为添加0条数据，添加1条数据，添加n条数据。添加0条数据是指进入添加功能界面，然后不添加数据直接退出，（我曾经见过有一个系统在用户进入添加数据界面后你不添加数据就不让你退出添加功能，没有天理呀），添加一条数据就是添加一个数据，然后退出添加功能的界面，添加n条数据是连续添加数据。添加0条数据不能再扩充了。但添加一条数据和添加n条数据是可以扩充。比如姓名输入域可以测试的内容包括：标准数据，合法数据，非法数据。标准数据是指在输入最不可能出错的数据的情况下，该功能是否可以使用，如果在我们选择最不可能出错误的数据的情况下系统无法使用，我们就认为此功能根本不可使用，下边的合法数据的测试以及非法数据的测试就可以不进行了。合法数据的测试是对系统来说应该可以处理的数据，比如拿日期型数据来说，有闰年的问题，所有月的第一天，所有月的最后一天，年应该是4位，月可以是2位或者1位，而且应该小于等于12，另外一个是年、月、日之间应该有分割符号，这些内容都可以作为合法数据进行测试。如果合法数据测试通过则我们认为系统在处理合法数据的时候是应该没有问题的，如果项目时间紧张，在完成此类测试后就可以给用户试用了。这里有几个问题大家主要注意一下，一个是合法数据测试完成并不意味着测试完成，因为测试非法数据的测试还没有执行，而且就一般的规律来看，在输入非法的数据的情况下，系统出问题的可能性更大，之所以说可以给用户使用主要是迫于工期的压力，我们可以将部分测试工作和用户试运行这两个工作并行，但任务并行必然带来风险，如果开发人员都是熟练的开发人员（简单说都是5年以上的开发人员），风险会比较小，如果开发团队都是1-2年的开发人员最好不要并行。（风险太大）。第二点，在合法数据我们会进一步细分，比如单个数据输入域合法数据的测试和组合输入域的合法数据测试，单个数据输入域的测试，是在标准数据的基础上，对某一个测试输入域的合法数据进行测试，这样比较好明确的发现问题点，对开发人员的帮助会比较大，比如在人员基本信息管理的添加功能的测试中，我们有了标准数据，在标准数据测试通过的情况下，我们对姓名数据输入域进行测试，那么我们会将标准数据作为一个基准，在其他输入域不变的情况下（前提是其他输入域没有唯一性要求）只测试姓名输入域在合法数据的测试情况。其他数据输入域的情况依次类推。在单一数据输入域合法性测试完毕之后，可以进行组合测试。一般来说，单一合法性数据测试没有问题，组合出问题的可能性比较小。这里有一个问题，一个测试数据量比较大，比较好的解决方法有两个，一个是采用自动化测试工具，比如我们将字符型的数据输入域的需要测试的数据加以总结并放到一个电子报表里，你只要做好测试自动化脚本，并参数化相关输入域就可以完成相关输入域的测试，而且脚本的量并不是很大。另外一个方法是采用正交试验法。具体的方法和理论根据可以看《测评工程师教程》的相关内容，也可以减少测试用例的数据。保证测试质量。非法数据的构造的方法和合法数据的构造方法基本相同，这里就不多说了。基本上字符型输入可以有几十个检查点，日期型的可以有几百个测试检查点，浮点数和整形数的检查点也不会少，这样大致的统计下来写出几万，几十万的测试需求点不是很难的事情