很多人做测试做时间久了，经验、能力都有了的时候，少不了要承担更大的任务，其中做为TL负责一些项目的测试也是很多测试人员发展的必由之路。下面把个人项目测试经验或者说心得体会简单做下总结。
做为一个项目测试负责人，应该具备哪些知识技能呢？测试技能是少不了的，这包括常见测试方法、技巧以及有关工具的使用等；其次产品知识也必不可少，如做手机测试应该对GSM原理要有个了解，做B/S测试，至少对OSI、TCP三次握手都要有所了解。而这两方面的知识、经验也只是做为TL的基础，其他方面软件工程、软件开发的思想也都应该具备的，当然你可以列出更过！
谈到项目测试管理，具有软件工程、CMM、ISO甚至XP的思想会更好，最近我也一直在思考如何根据公司情况，取长补短，把它们融合到项目测试中来。实际上，这些思想对做好项目管理测试工作还是有很大帮助的。这里只对测试过程管理经常需要面对的问题做下总结。
一、文档管理
CMM及ISO中都对文档案比较看重，基本上每个阶段都有要求输出各种形式的文档，文档输出是有必要的，但为了输出文档而编写有关文档就不好了，很多人一提到有关烦琐的文档就反感、认为也是走走形式。的确编写有关文档的确很麻烦！但必要的文档还是有必要的，下面简单罗列下，我们整个测试周期应该输出的文档：
1． 测试需求
软件测试的第一步就是需求分析，只有对软件需求做了准确、完整的分析后，才可能有完整地测试需求，测试需求做的好，才能对接下来各种测试工作的开展做好基础，需求分析偏离，后期很多测试任务都将会受到影响。测试需求分析应该由TL组织一些经验丰富的测试人员、开发人员甚至客户共同参与评审，并输出相应测试需求评审文档，后续软件需求变动时，测试需求也应该相应调整。
测试需求分析包括：
1） 测试内容——软件需要进行哪些方面的测试，如功能测试、性能测试、可靠性测试、易用性测试、安全性测试等；
2） 测试环境——需要什么样的测试环境；
3） 测试工具——准备选择哪些测试工具，包括缺陷管理工具、自动化测试工具等；
4） 测试资源——需要哪些测试工具，测试设备等；
5） 测试人员——准备投入多少人员进行测试，不同阶段需要的人员数量、能力是否要有差别（或者说针对性）；
考虑到实际的项目千差万别，涉及到具体测试上，需求可能还会有所不同。
2． 测试计划
如何结合项目计划、测试需求、公司资源等实际情况编写一份可行的测试计划是一项最基本的要求。测试计划不必太详细，但一定要从宏观上对项目测试有个整体把握，对测试进展、阶段工作安排、资源需求、可能出现风险等都要考虑到。
测试计划不同于测试策略，测试计划属于战略问题，测试策略属于战术问题，前者属于做什么，后者属于怎么做的问题！
3． 测试用例
这个就不用多说了，做测试这个是少不的，而一份测试用例的好坏却对测试执行的效率、效果都有很大的影响的，有人说测试用例不是写出来的，而是设计出来的，我觉得很有道理。测试用例一定要有很强的针对性，不同阶段、不同对象的测试用例设计上都有很大讲究的！
好的测试用例是设计出来的。
4． 测试报告
单元测试、集成测试、系统测试、回归测试、发行测试等不同阶段都要输出有关测试报告，每个小的不同阶段也要根据实际情况出相应的测试报告，报告形式多样，主要目的是让相关人员了解项目软件状态。
5． 测试记录
测试记录包括的东西比较多，这里我们指示项目测试周报及测试人员任务分配记录，当然也包括测试用例执行的记录等。测试记录是对测试工作的跟踪!
6． 测试总结
测试总结包括的测试人员的技术总结、项目阶段测试总结、整个项目的最终测试总结等，这些对他人而言是一些经验借鉴等。
7． 培训文档
培训包括专业测试技术、工具应用等，这方面的资料文档也应该分门别类的做好保存记录。
8． 其他文档
重要的邮件，会议记录，从其他方面搜集的相关文档等。
二、测试策略
不同的阶段、不同的版本，怎么制定一个有针对性的测试方案，怎样的测试能够更快更多的暴露软件问题，测试策略的好坏是最能反应一个TL能力的一个方面，好的测试策略能够起到事半功倍的效果。测试策略的制定上可以从以下方面考虑：
1． 何时何人进行何方面的测试；
2． 哪种模块需要重点测试，哪些模块可以一劳永逸（当然有些不太可能）；
3． 什么时候只要有针对性的验证测试即可，什么情况下需要回归测试、全面测试？
4． 如何保证一个版本（模块）测试不遗漏重要问题？
5． 采用哪些测试手段来测试（如有针对性的专项测试、交叉测试等）？
6． ……
其实，测试策略制定上可以根据测试人员的特点、测试软件版本的特点等因素综合考虑。如在实际项目测试中我经常会将某个模块分配给某个测试人员执行后，自己还会有针对性的进行一些测试，或者再让另外一个测试人员进行交叉测试，同一个模块在不同版本上让不同测试人员来进行等，这里并不是信不信任问题。
三、缺陷管理
现在的缺陷管理基本都采用缺陷管理工具来进行了，常见的有TD、CQ、TM、Bugfree等，这些管理工具其实也都大同小异。缺陷管理工具的采用大大方面了信息的传递、共享等，测试人员提交缺陷时也方便了很多，自动只要按照相应的格式要求进行填写即可。
TL应该对经常查看缺陷状态，以发现软件版本中存在的问题，并且对一些缺陷状态进行跟踪，对缺陷的描述、严重性等进行去伪存真。尽量保证每个测试人员提交的缺陷质量，对于一些开发人员未及时处理的问题也可以跟催下。
事实上，缺陷也是项目管理的一个重要依据！
四、风险管理
我经常将宿舍的钥匙放一把在公司，为的是防止有一天钥匙忘记了或者丢了等不至于破门而入，果然有一次钥匙被反锁进房间了，于是公司存放的钥匙也就派上了用场。我想这也算是风险管理吧。
哲学上说，这个世界万物存在的唯一形式就是变化。的确，没有一层不变的，测试上也有一些不可预期的变化，软件项目开发过程中存在很多不可预期的东西，如用户需求变化、开发人员的变化、测试人员的变化、资源的不足、临时新任务冲突等，这些都不是一层不变的，有变化就有风险，当变化出现时，该如何面对！这些变化的应对措施，即便没有文档明确化，但至少要做到心中有数！
当然风险也不一定全是变化导致的，比如测试的准备、时间等的不足，这对既定的客观因素对测试的执行也都是有风险的。
软件测试的风险无处不在，每个不同阶段都有不同的风险，如何在有限的时间、资源下采用更有效的应对手段来应对风险，将风险降到最低，这是每个TL都应该好好考虑的问题。
五、资源管理
包括测试资料、环境的管理等。可以说很多，但也没什么好说的。
六、学习培训
包括自我学习和引导团队成员学习.
为了满足测试需要和发展需要，这方面是少不了的，当然个人自学也很重要。我做测试5年了，自以为无论理论还是实践经验都够丰富，但每天还是会忙里偷闲补充些知识，往深处专是少不了的，但同时也要广度的发展！不然地话，恐怕连忘的都不够了！
在项目测试期间，TL根据实际情况可以组织一下正式或者非正式的学习、交流培训，当然也应该适当地引导相应项目成员进行学习，包括给他们锻炼的机会！以提高个人及整体的测试能力。
七、人员管理
很多人一提到管理，都特别兴奋，认为可以管人了，而且相信每个人都能滔滔不决说上一大堆道理来。这里就不谈管人了，只谈下管己。
如何管己，首先工作上要做到积极主动，这句话人人都会说，但真正做起来就不容易了，积极主动包括积极地发现问题、积极思考问题、积极沟通、积极处理问题等。可能有时候，大家都有一个体会，有时候有些事情，可以今天做完也可以明天做完的，相信今天做完跟明天做完是不同的。现在市场上有些诸如情绪管理、时间管理之类的书，也可以找些来读读。
八、其他方面
做一个TL，除了有发现问题解决问题的能力外，在做项目时还要注意到以下方面：
1． 信息共享要及时，比如有些相关邮件、测试变动等，要随时告诉给项目测试成员；
2． 遵守测试流程进行，但不要拘泥于流程；
3． 定期小组会议，经验交流；
除了技术能力上的要求外，其实其他很多非技术因素都很重要，如情绪管理、沟通交流、制度流程、文化环境等对项目测试的成败都有着非常重要的影响。
感觉以上有些东西比较理论化，如果能够让理论来指导实际，实践能够再升华到理论，相互促进，最终把测试工作做好，我想这才是最终目的！
