软件测试经理工作总结

总结是事后对某一阶段的学习、工作或其完成情况加以回顾和分析的一种书面材料，它可使零星的、肤浅的、表面的感性认知上升到全面的、系统的、本质的理性认识上来，不如我们来制定一份总结吧。总结你想好怎么写了吗？以下是我为大家收集的软件测试经理工作总结，仅供参考，希望能够帮助到大家。

软件测试经理工作总结1

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

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

1、测试人员大量增加

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

2、个人素质的提高

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

3、机器设备的变化

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

4、开发人员对测试人员的态度改变

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

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

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

软件测试经理工作总结2

可能有的人的第一次表演很精彩，可能有的人是紧张的，可能有的人是兴奋的，可我的却是漏洞百出。到底是怎么一回事呢？让我慢慢地说……

那是一个特殊的日子，因为我将要第一次参加舞蹈比赛，我那时还很小，所以紧张的要命。虽然父母多次的安慰，但我还是非常恐惧，我怕自己忘动作，害怕动作不标准，害怕别人嘲笑我，我像个热锅上的蚂蚁——团团转。

这时，比赛已经开始了，台上每一个参赛的团体都跳的那么好，我赶紧练习起动作，心想：不能给团队丢脸。此刻，我怀里像揣了个小兔子“砰砰”直跳。马上就要到我们了，我走来走去，忽然，我听见主持人说：“接下来表演的是小雪花舞蹈团。”我们排好队走上舞台，让我吃惊的是，观众席坐满了人，真是座无虚席。我的心一下子提到嗓子眼儿上。坚持就是胜利我心想，我终于把那五分钟给熬完了，跳的过程我记得不是十分清楚，只知道跳完后，我快速地向后台跑去。

这次比赛，我从中锻炼了自己，战胜了我自己，超越了我自己，这就是我的第一次比赛，你的第一次是什么呢？

职责

1、在测试组织内部制定和分配测试角色。

2、针对测试物制定测试范围。

3、为符合测试需求做测试环境的配置和管理。

4、衡量可执行和可行性:产品是否可以测试 是否已经做好测试准备

5、制定测试计划、开展及汇总测试结果并管理。

6、测试团队成员的培养、扩员，测试资产的管理及扩增

7、自身熟练的技术水平

（一） 先说测试计划吧

一个好的测试计划是用来计划测试的，指导整个测试过程。所以一个好的测试计划一定是可以指导测试的，就是对整个测试过程中的人力，时间，资源，策略，范围的一个说明。

作为一个测试计划来讲，核心的三个要素是时间，资源，范围。（这句话摘自微软的软件测试培训材料），时间就是什么时候做以及要花多久做，资源就是你要调用的人力、机器等资源，范围是你要测试的东西以及测试重点。

除以上提到的3项之外，还有比较重要的项目有策略（具体就是怎么测）、风险控制（一旦有问题采取什么应急措施）等项目。

要把一个计划做得很有实用性，按照笔者的经验，要注意以下几个方面：

a. 上面提到的三要素不能少

b. 测试策略一定要交待清楚，就是大概怎么测试

c. 需要其他人员（部门）协调的，要交待清楚

d. 在估计测试所需的时间、人力及其它资源时，尽量做到客观、准确、留有余地，特别是估计开发时间和debug时间，以及要对自己的执行用例速度，回归速度心里有数

e. 测试计划中每个阶段要明确表明，并且测试阶段的输入、输出文档要清楚

f. 测试计划中的时间段不宜太长（最好以day为单位），太长就比较模糊，不好度量，不好check

g. 一定要有风险控制，要不然计划缺乏可执行性

h. 计划写完之后不是装在兜里，要组织PM和Dev进行评审

i. 要不断更新计划，记住：每个计划都是动态的，不是一成不变的

（二） 再说测试用例

和测试计划一样，测试用例很多时候也沦为形式，这是软件测试的可悲之处，软件测试的依据就是测试用例，如果用例弃之不用，你凭什么做好测试？这个很可笑。但是实际测试过程中很多时候测试用例并没用到实处，笔者认为还是用例实用性问题，有的时候用例洋洋洒洒数万字，到回归测试的时候根本用不上，至于如何选择回归测试用例，我曾经写过另一篇文章，欢迎查阅。

下面我就个人体会谈谈做好测试用例的关键。

首先，在做用例之前，要做两件事情。

第一， 透彻了解程序（需求和架构）。

第二， 做一个正式的测试设计（最好文档化）。然后再开始写用例。一般写用例的步骤和建房子一样，先搭框架，然后填材料，填材料的时候，主要根据需求做相关的设计，具体的设计方法就是那几种（郑老的书上写的很清楚）

一般来说，设计一个比较实用的测试用例，注意如下几个方面：

a. 选用好的用例管理工具（这个很重要，千万不要用word，excel）

b. 用例一定要及时更新（补充新的想法，删除过时的需求）

c. 做好用例分级

d. 做好用例评审，写用例之前可以征询相关人员的意见

e. 可以考虑结对编写，这个是不错的主意

f. 要全面，包括功能、性能、兼容性、安全性、易用性、容错性等等

g. 注意把握适当的颗粒度

OK，以上是我个人总结的一些心得，希望对您有些帮助.

-----------------------------------------------------------------------------------------

我不知道lz说的做好测试计划中的“做好”两字具体指的是什么

对于目前大部分公司存在的状况，很多测试计划文档只是一种形式而已

所以我的理解是：怎样让测试计划对整个测试工作真正具有指导作用

这里把测试计划和测试方案分开来讲（计划对应于管理层面的问题，方案对应于技术方面的问题）

测试计划中最重要的内容包括：进度安排；人力、物力资源分配（包括组织结构等）、风险假设和规避措施。（其他像软件版本号之类的，只要是个人都会写，这里不列了）

写好测试计划的关键在于：

1 充分了解你的团队的整体实力和团队中每个成员的特点

2 充分理解为当前软件制订的整个研发活动过程

带过项目的人都知道：在实际项目中，往往进度才是第一位的，但是对进度的把握和估算却是极其困难的。只有做到这两点才有可能对进度有比较准确的把握，对人员有一个合理的分配。否则所谓的进度，所谓的资源分配，都是拍脑袋得出的结果，风险假设更是无从谈起，这样的测试计划文档只能流于形式也就不足为奇了。

写好测试方案的关键在于：

1 有一个合理的测试计划

2 熟悉相关业务

3 深入体会用户的实际需求

这个不想多解释了，不难理解。

至于测试用例

看到上面不少朋友认为关键在于理解用户需求

其实理解用户实际需求是一切的根本

并且对于有些测试（比如像单元测试）对应的测试用例通常和用户需求之间的关系可能并不直接或是十分密切

当然，如果有一份好的需求和设计文档的话，什么事情都解决了。 可是现实往往是不存在这样的文档的。

所以我的看法是：

1 对业务理解的深入程度

2 经验

3 有自己的文档

前两条不解释了。自己的文档包括两方面：一个是常用的特殊测试数据，比如一些特殊字符，极限长度的输入等等。这个在项目时间紧迫的时候是非常有帮助的（有的时候甚至可以当成check list）。另一个就是自己测试模块对应的相关需求和设计文档。服务器上的标准文档拖到本地来并且记得及时更新。然后在测试过程中，需要什么内容文档上没有，最直接的方法是和开发人员沟通。（其实我很反对这么做。你想，按开发人员自己说的标准去测他们自己开发的模块能测出因为需求或者设计错误导致的问题么……应该是和客户和designer去沟通，可惜一般没有这条件-_-）任何标准文档上缺少的内容，只要是和你有关的，一定要记得做记录。当然你有时间有精力把整个系统的需求和设计文档都捣鼓出来最好，不过通常是没这可能性的。

---