软件测试经理是这样炼成的.docx
《软件测试经理是这样炼成的.docx》由会员分享，可在线阅读，更多相关《软件测试经理是这样炼成的.docx（18页珍藏版）》请在冰豆网上搜索。
软件测试经理是这样炼成的
由安博测试空间技术中心提供上次我带了3个软件测试人员去一家做电影播放机（dMs）的公司面试。
最终这家公司选择了两个人，分别是小平和洪涛。
今天我和小平、洪涛来到了这家公司报道。
我们来这家公司不是普通的实习，是为这家公司建立软件测试团队。
他们两个都必须要能够掌控整个软件测试流程，有了问题必须主动独立的去解决，因为在这个公司只有我们才是软件测试专家。
如果能够圆满的实习成功，下一次在应聘的时候他们应该就能担任公司软件测试组长或者软件测试经理的职位。
当然事情没有那么轻松。
第一天就感觉遇到了很多问题。
明天过来可能需要解决的问题有：
需要的软件测试工具及模板：
1、需要一套模板包括软件测试计划，软件测试用例，测试日志，测试报告等
2、搭建bugzilla环境，所需要的软件测试工具，明天应该要用。
明天可能得你现场搭建了。
3、VSS的安装包。
关于软件测试流程：
1、如何与开发人员交流我们准备使用Bugzilla，通过Bugzilla建立起Bug的整个处理流程，但是这个公司开发人员应该不会使用Bugzilla，所以是不是要给他们公司培训一下工具的使用。
2、他们公司应该也没有用VSS对文档和所开发的软件进行版本管理。
所以公司应该有个软件配置管理人员。
不知道这个谁担任比较合适。
3、软件测试输出文档的审核，这个谁来做。
我可以在这里做一个周。
但一周以后呢？
是从我们当中选择一名做测试组长，还是由他们公司来安排，或者是咱们三个人来审核。
4、我跟公司的老师沟通过了，他只要求小平和洪涛做阶段总结。
而我
们要求每天的总结：
每天必须写日志，每周写周总结，每月写月总结。
这算初步建立了总结制度。
有了总结制度就会产生很多文档，这些文档是不是汇报咱们三个人。
这样也建立起了汇报制度。
跟他们是这样说的，希
望他们在完成工作任务的时候，如果用到了所学的知识，应该把所学的知识写到日志中。
以便让咱们了解哪个部分是与这个公司实践结合最紧的。
5、关于会议制度，咱们会参加公司的例会，而我们还需要单独每周开例会交流吗？
……
最重要的一点：
6、软件测试部门是不是独立存在的？
软件测试人员又是以什么样的角色进入项目组？
我跟公司CTO聊了聊，他希望软件测试人员能够同时介入多个项目。
想了想软件测试团队的组织结构应该是这样的…
3、做到了测试经理，完全可以把管理再岀神入化，每个人身上有什么特点，怎样能让每个组员的能力发挥到极致，怎么更好的争取测试人员的利益，怎样做到最好的资源调配，怎样让大家不再迷茫，另外，怎样提升自己的威信，提升执行力，领导力，怎样把管理做到让人啧啧，到了这种程度，通过横向和纵向对比，优势自然就出来了。
，测试行业照样有咨询、有顾问、专家，测试管理做好了也可以去做项目经理、去做部门经理，实在不行，完全可以去创业嘛。
软件测试管理初探
2009-04-2711:
12:
36
标签：
IT软件测试测试管理［推送到技术圈］
摘要：
长期以来，软件测试管理处在一个很低的水平上，自动化软件测试管理
工具的出现更是给人误解，似乎软件测试管理是简单的程式化的工作。
本文针对现状，
论述了笔者观念中的软件测试管理学科的大致组成以及每个组成部分具体内容。
笔者认为，软件测试管理对软件测试技术的实施有重要指导作用，对软件测试团队建设有保障和促进作用，是现代软件项目管理不可忽视的部分。
关键字：
软件测试管理团队组织管理测试计划管理缺陷（错误）跟
踪管理测试件管理
软件测试管理要解决的课题是如何确保软件测试技术能在软件项目在软件生命内得到顺利实施，并产生预期的效果。
按照管理的对象不同，软件测试管理大致分为软件测试团队组织管理、软件测试计划管理、软件缺陷（错误）跟踪管理以及软件测试件管理四大部分。
以下对这四部分具体包含的内容做一个概要的诠释。
软件测试团队组织管理通俗地讲就是测试团队应该如何组建。
在实际项目开发中，
我们常常看到有些单位忽视软件测试团队存在的意义，当要实施测试时，往往临时找几个程序员充当测试人员；也有些单位尽管认识到了组建测试团队的重要性，但在具体落实的时候往往安排一些毫无开发经验的行业新手去做测试工作，这常常导致测试效率的低下，测试人员对测试工作索然无味。
一个好的测试团队首先要有好的带头人，他必须具有极为丰富的开发经验，对开发过程中常见的缺陷或错误了然于胸，此外，他还应具有亲和力和人格魅力。
其次，测试团队还应有具备一技之长的成员，如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚本。
另外，测试团队还应有兼职成员。
如验证测试实施过程中，同行评审是最常使用的一种形式，这些同行专家就属于兼职测试团队成员的范畴。
测试团队里往往不乏缺乏开发经验软件新手，这部分人可以安排去从事交付验证或黑盒测试之类的工作。
软件测试计划管理通俗地讲就是安排好测试流程。
这部分内容具体涵盖软件测试策划、软件测试技术剪裁、测试进度管理、成本管理等几个部分。
其中测试策划工作主要是指具体测试活动实施之前做好策划工作，如起草测试大纲以及测试计划；软件
测试技术剪裁工作主要是指测试团队应根据软件项目的具体实际剪裁出所要实施的测试技术；测试进度管理工作主要是指排出各项测试的时间进度及人员安排，如有变动时应做相应调整；测试成本管理工作的内容即开列出测试活动中会涉及到的资源需求。
软件缺陷（错误）跟踪管理通俗地讲就是确保发现的缺陷（错误）已经被开发团队纠正或处理过并且没有引入新的缺陷（错误）。
具体来讲，当测试团队通过各种途径发现了文档或代码中的缺陷或错误以后，并不是交一份软件测试报告就草草了事，而是在递交报告以后继续督促开发团队及时关闭已知缺陷或错误（当然，如有必要应对这些缺陷、错误做严重程度排序，以便开发团队能视轻重缓急安排处理顺序）。
当开发团队关闭了测试报告中的缺陷（错误）以后，测试团队还需验证开发团队在关闭过程中有没有引入新的错误。
通常，这个过程称为回归测试。
回归测试如发现问题，继续报开发团组，按上述流程循环，直至回归测试最终通过。
软件测试件管理通俗地讲就是指努力建设好测试团队的财富库并对测试团队成员进行技能培训以帮助他们能使用好这个财富库。
这里，财富库是指软件测试件。
测试件（Testware,指测试工作形成的产品）是一个不常见到的词汇，它包括是测试团队在
长期实践过程中逐步积累起来的经验教训、测试技巧、测试工具、规格文档以及一些经过少量修改能推广至通用的测试脚本程序。
测试件管理工作做得越好，测试团队在实际测试过程中就能越少走弯路，测试团队内部的知识交流和传递就越充分，测试脚本或规格文档的重复开发工作也就能被有效地避免。
软件测试件管理工作包括两部分，一是建设，另一个是培训。
建设工作大抵是收集各类测试外文档、测试工具、测试脚本，也包括收集整理测试人员的会议发言、总结报告、技术心得等等。
培训工作大抵是通过技术讲座、正式或非正式团队会议、印发学习资料等形式进行。
以上从软件测试团队组织管理、软件测试计划管理、软件缺陷（错误）跟踪管理以及软件测试件管理这四个方面对软件测试管理学科的内容作了一个概要性的介绍。
需要指出的是软件测试管理学科目前尚处在一个不很成熟的发展时期，笔者所做的探讨虽然已经竭尽所能，但却不能保证已经涵盖了软件测试管理的学科全貌。
权当抛砖引玉，请各位读者朋友多多批评指正。
测试专家解析什么是软件测试架构师
文章引用自:
[引用]2009-02-19|发表者:
chenjunxia2006
软件测试架构师是一个新职位，但确实是一个非常必要的职位，主要有几点：
-根据V模型、广义测试概念等，（静态）测试的越早，发现缺陷越早，越有利于产品的质量、加快产品开发周期、降低企业的成本。
更重要预防设计出现严重
的缺陷，如果设计出现缺陷，在系统集测试发现问题时，所造成的返工将是可怕的。
这就需要对设计进行复审、评审，而在这过程中，需要测试人员参与。
-对于当前系统越来越复杂，不管是J2EE架构还是.Net架构，不管是集中式网络系统还是分布式系统，不管是主机系统还是服务器集群系统，其设计往往不是
-系统的性能、安全性、稳定性、可靠性等的测试，在技术、平台环境构造、系统部署上有很高的要求。
作为软件测试架构师，其主要责任是：
-审查系统架构、系统构件/组件及其接口关系等的设计
-确保系统的可测试性
-设计软件系统的测试策略和方法，特别是在系统的性能、安全性、稳定性、可靠性等方面的测试方法、技术线路和质量标准
-构件复杂的系统测试环境，并分析、解决测试中出现的较深的技术问题（Troubleshooting）和帮助做好缺陷的隔离
-对系统（性能、安全性、稳定性、可靠性）测试作出分析、评估，并提出为改善系统性能、可靠性而进行设计修改、代码重构的建议
-设计测试自动化的技术框架，主持重要的测试工具的研究、评估、设计
-参与系统部署的设计
-参与新技术的评估和引进
-帮助改进测试流程、提高测试效率
同时，招聘软件测试架构师，却是非常困难的，主要的原因有：
-对于大多数技术很好的工程师、架构师，对过程管理、测试策略和方法、质量等关注较少，理解不够，缺乏良好的RUP或CMM/CMM方面的造诣。
而测试工程
师在技术实现上机会较少、努力不够，技术功底不够，所以具有在系统架构和测试方法等多方面能力很强的人，是不多的。
-目前国内业界还存在偏见，具有精湛的技术和丰富的经验的技术人员，更愿意做开发，不愿意做测试，这种现象偶尔表现在公司的薪水体系上、或者企业的管理层对此重视不够、决心不够。
-国内测试专业发展比较迟，自然在人才市场上，有经验的、专业的测试工程师就不多，更何况是技术精湛的测试架构师。
-软件测试架构师定位不清楚，企业没有给出清楚的责任和工作内容。
-技术人员随着年龄增大，倾向于向管理发展，多数企业的政策也是向这方面引导。
例如副总、经理等管理职位薪水要比纯技术人员高。
实际，在多数外资企业，很强的技术人员（架构师）完全有可能高于他/她的上司。
软件测试工程师我的未来-软件测试师2008-07-2602:
02:
04阅读9评论1字号：
大中小
软件测试工程师指南
作者简介:
Timur赵,Nortel高级测试主管,浙大博士
当你生活于网络时代，只要原地不动就很容易落伍了没有经验，不知如何跻身于测试工程师的行列？
以下几个基本方向能使你从新手成为软件测试的行家里手。
软件工业是自动化工业的一部分。
而且是最活跃发展最迅速的一个方面。
到底有多迅速？
任何人的想像力都不够！
正如我们不会把我们的事务托付给不可靠的经纪，任何有分量的公司都不会采用没有质量保障的软件。
软件测试人员，我是说有水平有经验的软件测试人员永远是供不应求的。
软件测试经理不得不花很多的时间去面试有潜力的应聘者。
一些应聘者在软件方面或者软件测试方面毫无实际经验，明知道软件测试工作是一个高回报的和最合适的软件工业入门，就是无法抓住一个又一个机会。
这些人真正需要的是一个指南能告诉他们如何成为一个软件测试工程师。
首先，进入软件测试需要哪些技能？
1、软件工程技能你必须了解软件软件工程（设计、开发和简单测试），应用，系统，自动测试编程，及操作系统，数据库，网络系统和协议的设计和使用。
2、交流技巧如果想确定软件缺陷，你应当能够指出什么时候的缺陷算是缺陷
3、组织技能如果你在别人都头脑发昏的时候保持清醒，你就可能是一个好的软件测试工程师。
在网络
时代软件测试是一项有压力的复杂性工作，但如果你能从这些纷繁中找到一种途径，它就是一项回报丰厚的事业。
4、实践技能当一个工作需要经验，而你又需要一个工作去丰富你的经验时该怎么办？
这并不完全是一个两难的问题，你可能采用几种方式去获得实际经验。
5、态度除了技术水平，你需要理解和采取适当的态度去做软件测试。
1、软件工程技能（SoftwareEngineeringSkills）
软件工程技能可以分成三大块：
理解软件工程的规则，了解计算机编程和操作系统知识。
理解软件工程“规则”。
有一种过时的眼光认为软件工程只是由一些在工作期限之前疯狂编程、靠着非凡的协调能力和超人般的咖啡消耗整夜不睡，不停地设计和测试程序的“专家”们组成的。
这种现象确实存在，但你只有了解了软件开发的真正过程，才会是一个专业人员。
从哪开始呢？
先到图书馆去走一走。
你需要建立软件测试知识的软件工程基础。
我的建议是阅读RogerPressman的软件工程：
APractitioner'sApproach,fifthedition（职业入门，第五版，McGrawHill,2000年版）和GlenfordMyers的TheArtofSoftwareTesting（软件测试艺术，JohnWiley&Sons,1979年版）。
Pressman的书是一个对软件工程原理的全面介绍。
有很多关于软件技巧、项目管理、要求分析和软件设计等软件工程方面的好书，但Pressman对这些方面在一本书里作了介绍。
GlenfordMyers不到二百页，1979年发行，却是软件测试方面的圣经。
Myers定义及诠释的测试方法论已成为软件测试的基本模块。
Myers还考查了软件测试中的经济（缺陷的代价）和心理学方面（测试的目标就是发现失误及不成功之处），以及主导软件开发和测试的基本原则。
对参考书进行基本研究是一个好的开端，但这只是单方对话。
如果你能和上千个直接具有软件工程和测试经验的人以及想进入这一领域的人对话是不是再好不过了呢？
感谢那些网络电子部落，你已经可以做到了。
Comp.software-eng覆盖了设计、编程、项目管理等软件工程的各个方面。
Comp.software.testing涵盖了软件测试的自动化、培训、技巧等方面。
等等，别只停留在这里！
你是不是应当经常访问这些网址呢？
Bug-Net（）是有关软件缺陷的在线杂志。
阅读有关缺陷的文章是学习如何工作及失败的极好方式。
你也应当查阅软件测试及质量工程杂志（）。
STQE是
确定网络软件测试资源很好的始发站。
计算机编程。
不能想像有的人喜欢测试产品却从不阅读、检查和理解组成产品的软件一样不要误解我的意思。
你不必花所有的时间去读源代码，但任何你做过的有关自己程序的设计、编写和纠错都能大大地有助于测试别人编写的程序。
你怎样学习编程？
通过编程。
可以严肃地说，开始学习写计算机程序是最简单的事。
记住我说的是“开始学习”。
软件编程环境，例如MicrosoftWindowsFoundationClasses（MFC）orSun'sJavaFoundationClasses（JFC,alsocalled"Swing"）不断变得越来越复杂，越来越难跟得上。
但我在努力超越自己。
你应当怎样学习编程呢？
首先，买MicrosoftVisualBasic。
不要让名字骗了你。
你能用这套组件建立相当复杂的程序。
而且它只要一百元左右。
下一步呢？
等等，是visual编程警告的时候了！
现在你为你的PC买一个程序语言的时候，你其实是买了一个集成开发系统或称为IDE。
这些IDE通过对
编程的简化把开发过程流水线化。
这些IDE其实会帮你写很多编码。
这非常有利于尽早开发出一个产品，却不利于你学习编程。
如果你用Windows产生程序，你别无选择，因为环境介入太多使你无法从头编程。
如果你从Unix系统产生程序，你能自己写所有的编码。
一旦你习惯了与参量、控制结构、对象、输入输出及更重要的VisualBasic纠错打交道的时候，你就可以
开始学习C语言了。
学习C能使你熟悉十六进制系统，通过指针分配和参考内存，存取个体位码及建立程序模块。
我总是认为在学Java之前最好先学会C，因为C强迫你自己去完成许多任务而Java会自动处理（例如，释放未用的空间）。
用C工作比Java难，但你能学到编程更多的基本方面。
你其实能用VisualC++IDE从头写C程序，但最好还是在Unix系统中学C。
操作系统知识。
你已经把它交给了在Redmond,Washington的那些人了。
在短短的几年内，WindowsNT已经成为世界上大部分计算机的标准操作系统。
如果你要用NT工作，你需要了解它的寄存地址。
（它是一种用于存储你的系统结构的各个方面的数据库。
）我发现PeterNorton写的InsideWindowsNT4.0（SAMS,
1998）是一本很好的介绍书。
但是，如果你的应用或系统要求高的保密度、产出、可靠性及灵活性，Unix
依然是最好的选择。
如果你想成为一个成功的软件工程师，你必须能在Unix的世界里工作，如果你想从头学习编程，也要在Unix下进行。
你的选择是什么？
你可以到当地的学校或大学学习课程，或者在家建立一个Unix系统。
别昏过去了，你所需要的只是一台PC和一份能让你从网络免费下载的Linux拷贝。
（你大约花二十九元能买一份在一个CD-ROM中带了所有文件的拷贝。
）Linux不是Unix的“玩具”版，它是真实的。
它已经发行了七百万份拷贝，一些主要的PC生产商甚至先替你装载了它。
好了，你已经到了Unix或Linux系统了。
你应当学些什么？
文件和目录结构，标准输入输出和错误流，背景（background，也称为"daemon"）处理，从C调用系统功能，好，我可以接下去了。
一个好的开端是读ArnoldRobbins的UnixinaNutshell（O'Reilly&Associates,1999）或者是EllenSiever的Linuxina
Nutshell（O'Reilly&Associates,1999）。
2、交流技能（CommunicationsSkills）
能写出计算机程序却写不出一个完整句子的软件工程师现在还有。
但不幸的是，要成为一个成功的软件测试工程师，你需要清楚的交流。
你怎么去学习写？
通过写。
如果文字水平太粗糙，上一门创造性写作的课。
每天写工程流水记录或发email关键是学习（或重新学习）怎样用清晰可懂的语言表达你的思想。
一个好的写作参谋是WilliamStrunkJr.和E.B.White写的TheElementsofStyle（Allyn&Bacon,2000），它一点也不象初中教科书。
测试工程师必须把产品测试的技术写成文件。
测试计划提供指导并把测试设计转化为设置、实现测试和评估结果的步骤指导。
具有一般软件和产品特性不同层次经验的工程师都能使用这样一个详细的测试计划。
如此测试设计者或测试方案作者之外的工程师也能能进行测试。
测试计划也帮着佐证测试策略的正确性。
项目中的每个人都应当参与审查（即市场、开发、支持、技术写作
及测试人）。
计划的审查是必不可少的，因为尽管测试工程师尽最大努力来达成一个对产品的全面定义，这一测试设计者所基于的定义不一定是完整或准确的。
此外，就象开发者很难测试他们自己的编码一样，测试工程师也很难明确评估他们自己的测试计划。
每一个计划审查者都可能根据其经验及专长建议修改，有时候审查者还能提供测试工程师在组织产品定义时不具备的信息。
例如，一个市场人员可能了解到了新的客户要求，一个软件支持专家可能从有关的产品领域了解到了一个新的缺陷报告。
测试计划强调测试计划和执行的原则。
在测试计划中描述进行测试所需的测试设计和步骤是另一层关于测试设计和计划的原则。
在测试设计和计划中的错误与欠缺在设计转化成测试计划中特定的结构和测试步骤后就经常是再已无法弥补。
测试计划可作为其它项目，例如为不同的产品准备测试时的参考资料。
当被测试软件找到缺陷解决并证实后，测试计划所述的测试可以用于证实缺陷的解决方案。
同时，一个主要的测试设计信息来源，特别对于旧产品的新版本而言，是相关产品或前版本的测试计划。
在建立新版本时，旧版本的软件测试计划都应当被重新审查。
与功能与设计说明不同，测试计划将从测试的角度来描述产品的功能操作。
从这方面说，测试计划构成了公司公共档案的一部分。
随着时间的流逝人们会离开公司，带走他们的知识。
以前产品的测试计划就能帮助你定义新产品的测试。
软件测试工程师还要写测试结果报告。
测试结果必须写成文档，这样就能确定被测软件的状态，提供关于必须要解决的缺陷的记录。
产品测试中发现的所有缺陷的记录是测试部门最显眼、保存时间最长的文档。
测试计划和测试报告在项目的最后常被遗忘，但现存缺陷的清单（或数据库）代表项目未完成的议程。
这一
议程没完成是因为一些缺陷必须在对原来产品的一个patch或maintenancerelease的时候纠正，或者它们在这个产品作为后续产品的基础之前被修复。
在与软件产品打交道的过程中，测试工程师比其他部门的人参与项目的更多方面。
测试部门应当记录项目过程中重大事件（例如设计决定）的信息。
这个信息应能帮助测试部门和其他部门避免在后续项目中犯同样的错误。
错误是不可避免，在一个项目中可能出问题。
从这些经验中学习就可能避免问题，避免今后的同样错误。
从错误中学习的第一步就是记住它们，记忆的第一步就是把它们写下来。
3、组织技能（OrganizationalSkills）
每当执行一个软件项目的测试计划，几乎不可能不遇到至少会阻碍一些测试而必须解决的缺陷。
一个测试工程师应当能灵活地停止测试产品的一部分而开始测试其他部分。
有时被测软件需要做根本变动引起大量的测试结果失效，测试也许得重做不止一次。
在问题被查找和改变在进行的过程中，测试工程师必须有条理，保持对执行测试的软件的前后关系的明确感受（例如目前被测试的程序特定版本的不同部分）网络时代要求的动态开发和测试模式使组织性的工作方式对测试工程师越来越重要。
在整个开发过程中被测试软件可能会不断地改进。
测试工程师在计划和实施测试的时候必须考虑这些变化因素，必须控制测试环境来保证测试结果的有效性。
记住计划是一个动词。
作为一个软件工程师，你永远不会有你想要的所有时间和资源。
你总是必须通过理解技术和产品，开发组织方式，从你和其他人的错误中学习，以及在设计必须改变和出问题的时候的迅速调整，使你的测试效果和效率最大化。
如何能做到这点呢？
基本代数：
量化任务、目标和结果来减少方程中的变量数。
把产品的功能定义成要求。
在测试计划和测试中量化测试及其预期的和实际的结果，把信息提供给项目组。
你东点一下西点一下是不能完成整个测试的。
未来软件开发的组织模式要求有灵活的设计和不断进化的开发周期。
对产品测试必须随着产品的进化而进化。
4、实践经验（Hands-OnExperience）
这是个典型的两难问题。
你需要软件测试经验来找工作，你没工作你就没经验。
你该怎么办？
Becareful!
这需要勇气和你的PC的小心备份
作为自愿者参与beta测试。
怎样发现需要beta测试员的公司呢？
首先，给你在软件公司工作的亲友打电话。
偶尔有人会需要beta的测试人员。
如果这不行，到你最喜欢的网络搜索引擎上去找“betatest”。
你会发现很多小（和不那么小的）公司亟需beta测试员。
为什么？
这得感谢互联网，竞争的加剧使公司必须做出产品模型
升级会员 