软件测试经理是需要这样炼成的

Tesherlock

刚刚进入一个新的公司为其建立团队可不是件容易的事情。
　　1、最重要的就是在公司里找到一个能和你直接沟通的人。需要资源不知道找谁，这个是特别麻烦的。一些最基本的问题。比如说：机器的问题，安装盘的问题等等都是小问题，但对公司的环境不熟悉，再加上公司分工又不是很明确，遇到这样的小问题的时候，真是不知道找谁好。如果能在进入公司前都把这些事情沟通好，那么进入公司后就会以最快的速度开展工作。

　　2、进入公司以后，应尽可能快的熟悉公司的所开发的软件功能和业务流程体系架构等等。这个最好的方式是由专门的公司方面的业务专家提供1-2次的培训。

　　3、为公司搭建好测试的平台以后，工具的如何使用呢？应对所有的开发人员和涉及到测试的测试人员作一次工具如何使用的课程，这个应由我们来负责。

　　4、通过这个测试工具基本上建立起了测试的流程，开发应该也知道如何利用测试工具与测试人员配合，下一步要做的就是开发人员应当是坚持使用测试工具，坚持把测试工具里面的测试流程加入到他们日常的开发工作中去。当然这是离不开公司领导（CTO，开发经理）的支持的，所以得到这些领导们的认可是成功的第一步。

　　5、当然测试人员要做就是测试工具的管理和测试用例、Bug报告的提交和维护。每天测试人员都要严格按照以前在学校所学到的规范化流程工作。输出文档是相当重要的：每天要有测试日志，每周要有周日志，每一阶段都应该有测试报告。其实这一部分学校里面学到的知识足以应付了。所有输出文档都要发送给相关同事，阶段性的成果要发送给公司的CTO，主管质量的同事。这是建立起汇报制度。汇报的输出文档相关同事要进行评审，这是建立输出文档的评审制度。每周我们都必须参加公司的例会，定期必须与公司其他相关同事开碰头会。这个是建立起的例会制度。

　　6、在作测试的过程中，最经常要做的可能就是沟通工作，毕竟我们是外来的和尚，如何与公司的开发人员沟通，如何与质量部经理沟通等等这样的沟通渠道应该建立起来。在公司里面出现测试人员与其他开发人员意见不一致而且双方协商解决不了的时候，应该采取一个什么样的沟通机制。沟通渠道很重要啊！
浅谈软件测试计划吧。
　　刚刚介入一个项目，初步了解了项目的业务背景和需求以后，公司要求我们周一进入项目组。进入项目组以后，当然是继续了解有关项目的需求，还有一件事情我们必须要做，那就是写测试计划。测试计划是我们宏观上把握测试的第一步，它是对将来我们要做什么的，怎么做的一个指导性的文件。实际的测试过程是不断变化的，当然计划也是要不断修订更新的。

　　前天拿到了，公司原有的测试计划。看了以后都无语了。基本上是摆设，对于实际的测试基本上没有指导性的作用。怎么办？记得上次提到在公司面试的时候，Dennis.Li对该问题的回答非常不满意。后来他对我说，面对问题没有思路，其实回答这类问题很简单，把原来学到的理论实践知识联系起来就可以了。哎，对啊，其实回答任何问题，我们首先要作的就是找到以前相应知识的积累。

　　还是回到主题上，如何写一份测试计划呢？或者说测试计划中应该包括那些内容呢？

　　这个问题是作为一个测试组长，测试经理必须要掌握的，也是大家在面试的时候最经常问到的一个问题。反正都是理论的东西，回答这类问题死记硬背不就解决了吗？其实测试计划里面的各个方面是系系相连的。

　　测试计划的各个部分：

　　公司作任何事情都应该有目标吗？是的，测试计划本身也不例外。即：测试计划目标，当然我们是要作测试具体的软件，这个软件有什么背景，它又是有那些主要功能模块组成的，这就组成的测试计划的概述。

　　有了整体对项目的了解，我们到了测试计划的第二部分：测试是凭空产生的吗？当然不是，它需要参考很多文档即测试参考文档，比如需求文档，软件测试需求，概要设计说明书，用户手册。除了参考上述文档以外，测试本身也要产生很多文档即测试提交文档比如说测试计划，测试用例，缺陷报告，用例通过统计表，测试报告等等。千万不要小看这些文档，其实这一部分是对于测试人员非常重要的，这就是通常所说的测试人员的输入和输出。当有人问你的测试输出有那些的时候：主要就是上面的那些文档，这也是你工作成果的体现。

　　第二部分输出的文档如何管理呢？测试人员如何安排自己的工作？开发人员能及时响应测试人员要求吗？

　　其实这是测试计划第三部分考虑的内容：术语与定义。都应该有那些术语呢？1）测试用例编号。2）测试用例和文档编号。这是对测试文档进行统一管理的依据。时间非常紧迫作为测试人员我们应该如何安排自己的工作呢？我们应该根据3）测试优先级。好不容易发现了1个bug，他的危害到底有多大？应该在什么时候解决最合适。因为开发人员是负责解决bug的。沟通必须要有统一的语言，如果开发人员用英语，测试人员用中文，结果肯定会是乱成一团。所以4）缺陷的严重程度和5）缺陷优先级是给开发人员看的。这个要和开发人员达成一致。这样的话，开发人员根据测试人员的要求作出合适的响应。

　　我们到底要测试软件中的那些功能？

　　这个是我们测试中的对象，如果对象都没搞清楚，还谈什么恋爱啊！（呵呵）如果这个都不清楚，我们写计划还有什么用。所以测试计划的第四部分就是：测试软件具体有那些功能需要测试即：测试内容。

　　其实第四部分测试内容解决了是什么，或者说要做什么的问题。那下面我们要作的就是怎么做的问题。用什么样的方法进行测试呢？当然我们解决任何问题，都需要策略，这就是软件测试的第五个部分：测试策略。测试策略应根据具体的软件采取不同的策略，一般都包括功能测试，界面测试，安装卸载测试，易用性测试等等。

　　知道了作什么，也知道了怎么做。那接下来就是谁来做的问题。

　　谁来做测试，测试人员职责分工是怎样的呢？

　　这个就是测试计划第六个部分应该包括的内容。确定谁来做测试，只有人可不可以作测试呢？拿着木板当砍刀，当然不行，谁来做是一个整体。我们需要那些测试工具，需要什么样硬件软件环境。都应该提出来。即：资源。

　　现在是测试什么，如何测试，谁来做测试都全了。这样就行了吗？不行啊，哥们[FSAGE]我们是IT公司，高科技含量的企业，高科技含量的企业更需要高效的管理。软件测试的第七部分：测试进度。主要包括测试任务的分配。分配到具体的人头上。时间上我们也是需要考虑的，所以也应该包括各阶段的资源要求和时间安排。项目管理里面必须要有的就是过程管理，也就是项目里程碑。到了一定的时间，我们必须完成一次小的飞跃。其实以前有个马拉松选手，用这个里程碑使的最好。他们自己的比赛路程划分成各个小的路程。比如说1000米是一个里程，他就在每个1000米里冲刺。这样有了一个个小的飞跃，最终使我们能够完成大的胜利。

　　万一软件发布了以后，你测试的某些模块发现了好多非常严重的Bug，而这个模块是因为时间进度，项目经理要求，资源所限导致的。与你本身关系不大，或者与测试组关系不大。但是问题发生了，我们难道只能等着挨骂吗？

　　不是的，做IT的人都是聪明人，就像我们以前学习C语言的Switch语句一样，考虑完各种情况，最后还有个default。凡是都会想到意外情况，而这一部分就是我们测试计划的第八部分所要考虑风险分析。

　　我们可以把整个测试过程中所要用到的所有的模板文档作为附录放到测试计划的最后面。主要有的模板：测试日志，例会记录，测试用例，测试总结等等。

　　上面就是一般测试计划包括的九个部分，你记住了吗？

　　记住了，是成为测试经理第一步。

咚咚宝031102

chengning

sunpeng