谈谈3年多的测试管理经验的心得，望大家多多指教，提出宝贵建议：

　　1.具有较好的人格魅力和亲和力：

　　真正来说做到这一点非常难。这不仅要求测试经理有宽广的胸怀，良好的沟通能力和语言表达能力，还要求测试经理具有较强的应对能力。向上能把工作汇报的让领导满意,令领导信任。能把工作任务轻松, 无异意的下发给下属, 并让他们饱含工作热情共同协作去完成测试任务。如果您能够把扭转下属的思想，把“要我测试，变成我要测试”，我想你一定很强了。如果陌生的人一见到你，通过谈话就觉的你很强，都愿意和你交朋友，那你的人格魅力一定不错了，呵呵。

　　2.最好具备较强的测试技术水平：

　　一般来说，作为测试经理，在一个测试技术性的团队里，如果你有很强的技术，并且你的技术是最棒的，下属不能够搞定的问题，你都能够做的很好，即时有时候你凶了点，团队里的成员心底里都还是很敬佩你。如果你有技术，但是技术不高，你组内的技术高手一定是你的亲密战友，这个时候唯一的出路就是凝聚团队的力量，取长补短，也能够取得较高的效率。还有一点值得注意：在分派工作的时候，找一下组内的骨干，看看是否有新的或者好的处理办法，这样一来，避免在开会的时候遇到分工或者技术上的尴尬局面。但有的测试经理具备了很强的技术，整天对团队的成员都板副面孔，那你也很难做到人见人爱。唯有为人处事比较圆滑，待人真诚中肯、随和亲切，整天都是笑脸相迎，那呆在这样的团队里工作，一定很开心。所以要做到人见人爱的测试经理，较强的测试技术水平不能够忽视。

　　3.乐意处理下属在项目中碰到的困难：

　　在带领一个团队开展测试工作的时候，当你的下属碰到困难的时候，你更多的是给下属鼓励和安慰，帮助下属分析出现问题的原因。比如说一下：“幸苦了”！“干得不错”！“慢慢来，没关系的”！下属听了也很开心的，并且以后干活可能会很卖命，因为他的工作得到了领导的认可。或许该问题你也不一定解决得了，这时候你一定要挺身而出，协调测试团队的资源尽力帮他解决问题，久而久之，你的威信就树立起来了，之后就好办事了。

　　4.勇于承担责任，把功劳推给测试团队：

　　软件测试经理，作为一个中层经理。管理者一定要想管好下属，必须“身先士卒”、“以身作则”，事事为先、严格要求自己，处处起到表率作用。示范的力量是惊人的，一旦通过表率在团队中树立起在员工中的威望。将会上下同心，大大提高团队的整体战斗力。常言到：“得人心者得天下”，做下属敬佩的领导，将使管理事半功倍。如果下属在测试项目中出现问题，上级领导怪罪下来，自己勇于承担，多检讨自己，少怪罪他人。始终用平和语气与下属沟通，最后一定要找出出现问题的真正原因。让出现问题的下属，自己过意不去，从心底里佩服你，想法补偿你。项目得到喜讯，比如：某个测试项目做的很好，领导表扬的时候，把功劳推给大家，很多时候，容易让人感动，让人佩服得“五体头地”哈哈。

　　5.对下属多一些宽容和生活关心：

　　特别是对下属不懂，自己懂得很精的地方，下属问的时候，一定要有耐心，给下属详细讲解。切忌：看不起下属。如果真是这样，你这个经理就很失败了。反正对下属，在很多地方，要多一些理解和包容，最好能和下属打成一片，当下属不认为你是领导的时候，你就真是领导了。如果做领导做到别人都当你是朋友，那你真的就成功了。

　　还有一点就是要察言观色，随时发现和了解下属的困难，不管是工作方面，还是私人方面，都要关心。比如说：某个下属买了房子，准备装修，那他一定很关心装修方面的东西。如果你懂得很多，那和他交谈时，多一些这方面的话题，他也会很开心，觉的你这个人相当热心，并且也会觉的大家有共同语言，以后当你碰到问题的时候，他一定会鼎立帮助你，因为他认为你是他最信任的知己。也可以多在生活上关心下属。比如有项目要加班什么的，有时候陪陪下属加班呀，吃个午饭宵夜呀，聊点家常呀什么的，自己买单后，公司报销，效果真的不错哟！

个人理解这个问题问的是一个优秀测试经理所应具备的素质和能力（当然啦最优秀的人也未必是人见人爱：）。

　　我认为一个好的测试经理应该具有如下几方面的素质和能力：

　　1、员工管理

　　我的管理哲学是要相信你的人并且让他们开开心心地工作，他们也会用优秀的成绩来回报你的。有人说管事不如管人，我觉得是很有道理的。细的来说应该向以下方向努力：

　　- 创造公平公正的工作环境。奖勤罚惰，鼓励创新（不要停留在口头上，要落实到制度）。很多时候不怕穷就怕比，不合适的奖惩很容易让优秀员工萌生去意。

　　- 对于员工的工作积极鼓励为主。通常人的物质需求很难被完全满足，但一句窝心的表扬或中肯的批评会让你的下属产生被尊重感。测试工作经常枯燥乏味，极具人情味的鼓励常常是最好的动力。

　　- 积极为下属着想。很多测试人员经常会为自己的将来担心。假如你能积极地去为他们设计将来就能够坚定他们的信念跟着你好好干。具体地你需要为他们做实实在在的职业规划，为他们争取更多的培训资源，不断地告诉他们的自身价值，不要光画饼。承诺的事情要兑现。对于工作认真负责的员工要尽力为他们争取合理的薪资福利，即便失败了他们也会感念你的爱护，加倍努力工作。

　　- 勇于替他们承担责任。很多时候测试经理是夹在管理层、开发组、客户、测试组之间的一块板，肩膀要够硬，要为你的人减压，成为他们的主心骨。

　　2、和老板的沟通能力

　　这是毋庸置疑的，当老板对你不满的时候你还能安心做你的测试计划么？有几点小诀窍：

　　- 定期汇报，经常让他感觉到你和你的测试组的存在。在公司里测试部门并没有受到足够的重视，常常被人忽视，要经常晒一晒你们的工作和产生的作用

　　- 经常报喜，很多公司是极端重视客户反馈的，用户的积极评价要第一时间“谦虚“地转到老板的邮箱里。如何让客户是不是地给点好评会在后面讲到

　　- 体现成长，测试团队的积极成长很容易让老板高兴。时不时地搞些技术研讨会，邀请相关经理们来听一听。但一定要精心准备，不然的话适得其反。

　　- 在报告里清晰地描述测试工作的进展，用扼要的数字让老板相信现在一切尽在你的掌控（也就是他的掌控拉）。将来也一样。对风险做清楚而充分的准备。

　　3、和开发的沟通

　　最怕看到的就是测试和开发的对立。要避免这个就需要让开发经理和开发人员知道测试存在的意义。大家都是为项目服务的。个人觉得测试经理应该具有一定的开发背景，理解测试人员的心理。要求测试组在项目前期帮助开发组理解，澄清需求，而不是一味提问题（特别是很傻的问题）。再后面可以帮助开发人员设计测试数据，走读单元测试。对于与测试相关的风险要适时提出。测试的缺陷报告要易懂易复现。测试lead应当要对测试组提交的结果把关。必要时测试经理也应当积极介入项目。对于产生的争议要尽快和开发经理或项目经理沟通，请求协调。鼓励测试组积极和开发组增加语言交流。这比冷冰冰的测试报告强的多。要是你手下mm 多质量又好的话要先恭喜一下了。

　　另外要增强自身的技术修养，要与开发人员有“共同语言“。这样交流起来就容易多了，也容易使开发人员产生尊敬。总而言之要站在项目的高度而不是测试部门的利益。有时间经常参加一下项目的会议，必要时从质量和流程的角度为开发组地过失作一些辩护。

　　4、客户关系

　　对客户没啥说的，一要积极，二要快。积极就是要有一定前瞻性，等问题出来了大家都不愉快。将问题扼杀在萌芽。举个例子如果客户对产品的测试工作有了微词，赶紧打电话给客户了解情况并提出改进意见。通常客户尤其是欧美客户会很欣赏这样的做法。等客户的抱怨信到了你老板那里大家的日子都不好过了。

　　前文提到要尽可能地向客户“讨”感谢信或表扬信。怎么弄？当然前提是工作要做好，日常沟通要到位。小技巧是为什么不换位思考，你要感谢信他们就不要么？他们就没有老板么？漂亮话是不要本钱滴

　　最后总结一下，一切以人为本，老板高兴了你就有资源，有资源了你的下属就会高兴，就会好好干活，工作质量就高，那开发也高兴，客户也高兴，客户高兴了你的测试团队就有更多的成长机会，同时老板也喜欢。这是一个非常好的良性循环。说起来容易做起来难，没有几分修为又怎能做到这样八面玲珑呢？

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。

本文出自51Testing软件测试网，感谢会员sun_0910在每周一问（08-08-11）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html

　　1、人际关系

　　这个很重要，我把这项列在了新人的今年计划上面，不光是QA内部，还有和DEV，公司QA，任何和工作相关的人的关系。 QA和DEV的关系很微妙， 所以我觉得新人如果给自己定位不对的话，很容易走歪。

　　2、态度

　　新来的MM每次问我问题都和我说谢谢，搞的我都不好意思了，但是这是对你起码的尊重。 听另外一个同事说， 他带的那个新人因为有靠山， 回答她问题变得理所当然的事情， 连谢谢都不说， 还指示他，你应该教我这个，教我那个， 那味道就不好了（同事和他的新人都是外国人……）， 所以那个新人来公司3，4个月了， 都没给她什么任务。

　　3、主动

　　我刚进公司那会， leader直接告诉我， application怎么下， test case在哪儿 (那时还没Use case呢)， 然后自己跑， 碰到问题再问。 然后我就每天把看的结果告诉他， 把问题列给他， 然后他再给我答复。 差不多2个星期就上手了吧。。不过也发现那个application上面很多bug，搞的我们leader都不好意思了呢~

　　现在我带新人， 基本就是把简单的流程演示下， 把相关的文档和test case发给他们， 照着文档跑。 然后有问题再问我。 因为我不可能把所有的东西一股脑的都传给新人， 更何况，每个人的测试思路都是不一样的。 有问题， 说明你在学习，思考， 然后才是有效的理解。 而且，我相信， 好的leader是喜欢会challenge自己的下属的。 所以， 作为新人， 要主动出击， 多问问题~

　　4、及时和Leader沟通

　　这个方面， 就不光是技术方面的了， 还包括对进公司的感受， 自己的职业发展方向的想法了， 要让leader觉得， 自己可以帮助到你， 不过说到底还是一个沟通技巧了。

　　还有一个方面就是技术上的准备， use case/requirement/test case是很重要的一块， 也是必须要看的。 剩下的一些process的东西， 我倒是觉得没必要一开始就弄的很清楚。 慢慢来， 一切都会清晰起来的， 相反， 项目上要想尽快上手， 就必须把测试相关的抓好， 并且要让leader， 你ready了。

　　事情是做出来的， bug是找出来的， 光说不练是没用的。

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。

本文出自51Testing软件测试网，感谢会员poisson在每周一问（08-09-01）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html

　　1、让研发团队的领导重视测试：

　　测试经理作为测试部门的老大，让公司领导重视测试，明白测试给项目带了的价值，那是义不容辞的责任。如何说服公司的领导，让公司的研发总监重视，这一点非常关键。只要这一点做好了，测试才会变得很轻松、愉快。如果公司的领导都不重视测试团队，只看重开发团队，即时测试部门发现了一大堆问题，公司领导也觉的很正常，不在乎，何谈降低测试轮次？如果公司研发领导很重视每轮的测试报告，自然开发部门不敢怠慢，代码的质量肯定要高得多，降低测试的轮次简直就是轻而易举的事情。

　　2、测试团队和开发团队的独立性：

　　国内很多的研发团队都不是很重视测试团队，很多情况下都是开发部门的经理说了算，什么时候测试？什么时候结束？都是如此，这就让测试团队的成员非常郁闷，很无赖，经常是抱怨居多。在这种情况下，多数时候，项目为了赶进度，项目经理和开发经理急了。为了尽快发现问题，只要开发了几个新功能和修复了几个 Bug，也就安排大量测试人员立马验证，这样反反复复，版本平凡发布，测试效果极差，软件质量也得不到保证。如果测试部门和开发部门独立以后，发布版本测试都必须通过沟通来解决。你说开发部门的经理“说测试就测试”的想法，说了还能算吗？呵呵！！我们公司很多时候，在测试版本不符合要求时，要送测试部门进行测试，都是开发部门的经理和项目经理给我们测试部门的老大说好话，拍马屁，老大高兴了，我们方才开始测试，否则一切按流程行事，他们也没有办法。保持部门的独立性和平等性，同样重要。

　　3、细化送测标准，建立完善的测试规范：

　　测试经理在编写测试计划的时候，就应该考虑如下的问题：开发部门开发完成到什么时候我们可以开始接受测试？如果这点测试经理不明白，后面重复测试平凡发布版本，不是什么新鲜事。目前，我们公司的做法是：测试经理编写详细的测试规范，在规范中明确规定了软件版本的送测标准（如：某个独立模块的功能点完成了多少百分比，才能够开始测试等等，都要写成一个标准）。测试规范制定完毕后，开会评审让项目经理、开发经理和测试经理达成一个一致的建议，后面测试的时候就按测试规范中的标准执行就可以了。严格把握软件的送测标准，也能够有效的减少测试的次数。

　　4、测试部门建立详尽的预测试标准：

　　如果被测试软件符合送测标准以后，开发部门才能够请求测试部门进行测试。测试部门接受到开发部门的配置表以后，在服务器上取下测试的版本，编译、部署后，安排部分项目核心人员，对部分主要的功能进行预测试，如果预测试通过了，就可以开始测试。如果预测试不通过，就打回开发部门修改好后再预测试，直到预测试通过为止。同时，我们也要制定严格的软件测试结束标准，来把好质量关，避免一味的追求减少测试轮数，而忽视质量，结果自然可想而知。建立详尽的预测试标准，这样也能够减少测试的轮数。

　　5、保持测试和开发独立的测试环境：

　　大部分的项目硬件都非常昂贵，现在很多的公司为了节省成本，开发和测试环境都在同一台机器上。开发人员就在测试机器上开发，这样混乱的测试环境，导致很多测试出来的Bug有可能不能够重现，开发人员对不成功重现的Bug就要求列为无效的Bug，弄得测试的兄弟们递交Bug都胆战心惊的。测试人员为了重新 Bug不得不另取以前的版本，重新编译后，再测试，这样做无意识又增加了测试的轮次。后来测试环境和开发环境分开了，虽然在同一台机器上，数据库都分开了，测试数据再也不会被开发人员修改了，在测试出现的问题，一般在开发那边都能够出现。后来为了保护测试组里成员的利益，我也去掉了绩效考核中“对无效的 Bug”的考核项，大家终于可以放心的提缺陷了。

　　6、重视单元测试，提高被测软件质量：

　　很多时候，测试部门和开发部门单元测试比较马虎或应付客户了事，测试的时间短，留下了很多缺陷。到了后面每轮系统测试的时候，才被发现，加之项目进度的压力，给公司也带来了较大的经济负担。加大单元测试的力度，力争尽早发现并修复缺陷，同样也是减少测试轮次的一种好方法。

本文出自51Testing软件测试网，感谢会员zhuzx在每周一问（08-08-18）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html

　　7、重视测试用例的评审，提高测试用例的质量：

　　就目前来说，很多的公司都不是很规范。一种情况：变更了软件需求，相应的测试用例，没有及时增加，测试人员测试时，完全凭个人的理解和经验，想到哪里就测到哪里，随便测试。在这种情况下，不同的人在不同的时间测试时，就会发现并提出不同的缺陷，这样混乱的测试就导致测试轮数较多，效率自然低下。另外一种情况就是测试人员设计测试用例的水平不高，测试用例质量较差，导致测试反复进行，也测试不出Bug。这就要求测试部门主管，加大测试用例评审的力度，力争以最少的测试用例，测试出较多的Bug。

　　8、部门员工进行模块交叉测试，避免漏测提高测试效率：

　　测试主管在安排测试的时候，也要注意“用人之长，避人之短”。测试启动阶段，要对这个系统集中培训，让测试部门的成员对整个系统达成一致意见，最好在第一轮测试时，尽可能发现较多缺陷，开发人员尽早修复。第二轮测试就可以进行模块交叉测试。一方面我们可以避免个人原因造成的漏测试，另外一方面也可以利用每个人不同的思维方式，很容易发现其它模块的缺陷，避免多次重复测试，提高测试人员的积极性。测试效率提高了，发现的问题多了，后面测试的轮次自然要减少。

　　9、加强项目成员的管理，定期报告发现缺陷的情况，增加督促力度：

　　加强项目成员的管理，同样能够减少版本的发布和测试的轮次。测试人员每天都编写测试日志，邮件抄送给项目部成员和公司领导报告每天测试情况，加强不同层次的领导对开发人员的督促力度。这就对应了第一条，如果公司领导不重视测试，也就无所谓。如果公司领导很重视测试结果，马上作出反应，给各个部门的经理施加压力，软件质量被重视了，自然测试版本减少。如果哪个开发人员开发的模块每天都有很多缺陷，开发人员自然很不光彩，毕竟大家都很要面子，开发人员也敢轻而易举，开发的模块功能不测试就直接扔给测试部。这也是一种有效的方法，当然也可以把缺陷的数量、严重程度作为开发人员的绩效考核标准，提高开发人员的“质量意识”，缺陷自然很少。我们公司就是这样做的，一般在2到3个版本时，就很难发现缺陷，测试人员也相互看看其它成员发现的缺陷，一旦有的测试人员发现了较多的Bug，发现缺陷很少的测试人员很急，比较有个比较吗？特别是测试半天都没发现Bug的测试人员，就经常给我讲自己测试过程中的苦衷，我也很理解他们，多给他们鼓励鼓励。

　　10、严格控制需求变更的流程，减少后期的需求变动：

　　在项目开发中，经常碰到这样的情况，客户代表中有产品部、科技部、业务部等等部门的人员，很难通过某个客户代表户讲清需求。客户代表，随着对开发系统的不断深入了解，有可能客户不断的提出新的需求，或者说是不断修改需求，所以对于需求的变更，我们一定要有一个严格的标准流程。通过开发方和客户的评审后，再编写相应需求文档，最后开始开发。很多时候，繁琐的需求变更流程和领导的多级审批签字，并且需求的变更请求，也有相关的记录，很多客户都怕承担需求变更带来风险。也让业务人员觉得变更比较麻烦，不得不放弃需求的变更。严格控制需求的变更流程，做到有效的需求变更，这也许是一种减少测试版本的方法。

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。

本文出自51Testing软件测试网，感谢会员zhuzx在每周一问（08-08-18）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html

　　2. 错误的测试心理：

　　(1) 软件测试就是证明软件没有错误的过程；

　　(2) 软件测试就是证明软件完成了它既定功能的过程；

　　(3) 软件测试就是建立"软件做了其应该做的"信心的过程；

　　3. 软件测试的过程是为了通过发现并修正更多的缺陷来增加程序的质量和可靠性。因此，在测试伊始，就应该抱着发现更多的缺陷的目的来设计和执行测试，而并不是简单的为了证明程序能够正确运行而进行测试。

　　4.“软件测试是为了发现错误而执行程序的过程。”

　　5. 人类的行为总是具有高度的目标性，目标的确立有着重要的心理学影响。如果我们为了证明程序能够正确运行，就会在潜意识中倾向于实现这个目标，就会设计出较少导致程序失效的测试数据；相反，如果我们为了发现程序中的错误而进行测试，就会想方设法、处心积虑地去设计出“变态”的测试数据，来实现自己的“阴谋”，而这种阴谋的实现却恰恰能够给程序增加更多的价值。

　　6. 心理学研究表明：人们对于预先知道“无法实现”的工作，表现会很糟糕。因此，将软件测试定义为“验证软件中不存在错误的过程”，是无法达到和实现的(程序中不可能不存在缺陷)。

　　7. 软件测试更适宜被定义为试图发现程序中的错误的破坏性过程。一个成功的测试用例，通过诱发程序出错，而对其进行改进和修正。

　　8. 黑盒测试，又称为数据驱动或输入输出驱动的测试。测试过程中，将程序视为一个黑盒，不关心其内部结构和原理，而是将重点放到发现程序不按其规范正确运行的环境条件上。

　　9. 为了进行有效的黑盒测试，需要穷尽出所有的可能情况，并为每一种情况进行测试用例的设计，显然这是无法完成的任务。

　　10. 由于穷举所有测试用例是无法实现的，所以：一、我们不可能保证程序种不存在错误；二、测试投入的目标应该定位在通过有限的测试用例设计与执行，最大程度上提高发现错误的数量，以取得最好的测试效果。

　　11. 白盒测试又称为逻辑驱动测试，允许检查程序的内部结构。这种测试通过对程序逻辑结构进行检查，从中获取测试数据。

　　12. 在白盒测试中的穷举路径测试，如同黑和测试中的穷举输入测试一样，不可能实现。

　　13. 穷举路径测试存在的错误隐患:

　　(1) 程序设计本身不符合设计的规范。在这种情况下，即使穷尽了所有的路径测试，也依旧无法发现这种缺陷。

　　(2) 程序设计可能缺少某些必须的路径，不管你怎么测，也都不可能穷尽到未加入到代码中的路径，除非你是多啦A梦。

　　(3) 穷尽路径测试很可能无法暴露数据敏感的错误。

来源：http://www.51testing.com/html/200812/n101060.html

案例描述：

　　简单叙述一下问题吧：

　　公司其它部门有个项目，需要做很严格的测试，请求我们部门支持，部门就指派我负责。因为项目刚开始不久，项目经理说测试的人员目前还未定，暂时只有我一个人，所以我过来了之后就一直在埋头编写测试计划和测试用例，就像以前做过的那样。但今天早上我的主管把我叫去了，跟我说了一番话，对我触动很大。他说其它部门请我们去支持测试，是希望我们给他们带去一些更专业的测试思想和方法，而不仅仅是叫我们去给程序找BUG。我应该更多的考虑如何去做好测试，把整个过程想清楚，需要什么资源，如何安排，要大胆地向项目经理提出，而不是跟着项目的进度走，那样就根本体现不出我们部门的价值。我觉得他说得很有道理，但是说实话，我对一个项目的测试经理究竟需要考虑些什么，注意些什么，该做些什么，并不是十分清楚。所以在此提出来讨论，希望大家给我些建议，谢谢！

　　意见：

　　这么久都没有人给个好的思路讲一讲这个关于如何做项目的测试经理，也许这个问题问的太大了吧，今天有感而发，说说我的观点吧。

　　对于项目的测试经理，每个公司组织结构、项目管理模式不一样，想做好项目的测试经理，首先是要和开发负责人、项目负责人达成共识，是对于项目的软件质量理解的共识，对于速度、成本、质量这三个方面，更偏向于那一面、还是都持平。

　　当然，站在测试的角度，希望软件质量是很高的，那么站在项目的测试，做为测试，要明白能做什么？起到的作用是什么？

　　程序一旦提交到测试，进度完全是可以在测试这一方来主控了。

　　本帖的案例，我看了一下描述，目前苦恼的问题是：

　　1、领导说其它部门请我们去支持测试，是希望我们给他们带去一些更专业的测试思想和方法，而不仅仅是叫我们去给程序找BUG。

　　2、我应该更多的考虑如何去做好测试，把整个过程想清楚，需要什么资源，如何安排，要大胆地向项目经理提出，而不是跟着项目的进度走，那样就根本体现不出我们部门的价值。

　　从上面的描述可以了解到，部门领导会这么说可能是因为：

　　1、在项目测试的过程中进度没有过程控制点，具体一点就是没有具体的工作计划（什么时间，用多少人力做什么样的测试？）

　　2、程序提交测试后，什么时候能发布、可不可以发布没有个确定点；测试没有自己的主见，项目经理说测试进度怎么做就怎么走

　　要想做好项目的测试，我想需要具备下面的一些素质吧，仅供参考：

　　1、深刻了解测试的整个工作流程、也就是在项目的测试工作中需要做的测试需求、测试计划、测试用例、测试报告、bug分析

　　2、及时的收集测试过程中的问题、了解测试进度，把问题和进度反馈给项目的各方负责人

　　3、很好的沟通、协调能力，应变测试过程中发生的需求变更、bug修改进度缓慢、开发延期提交等等一系列问题

　　4、很好的承受工作压力和适应能力，做为一个测试负责人，如果不能抗得住、下面的测试执行者就会慌乱

　　5、具有发现问题寻求好的解决问题的途径

　　6、关心组员的工作表现、会换位思考等等

来源：http://www.51testing.com/html/200812/n100507.html

　　以前我们公司招测试Leader的面试题目中也有类似的一个题目？我面试了很多人，回答都不是很理想，都只能够回答上几句话，并且都有“需求不明确”等同感，只是工作中太忙缺少总结，给出一个常见的很熟悉的问题，马上作答不知道如何说起。

　　下面是我的一些看法，恳请各位同行批评指正：

　　1.根据客户的功能点整理测试需求追朔表：

　　一般的客户都要把要开发软件的功能点写成一个表格交给市场部，让市场部门转交研发部。所以客户的功能点是编写测试用例一个最最重要的依据。

　　2.根据开发人员的Software Specification List整理我们的功能测试点：

　　一般来说，开发人员实现一个功能都要把该功能分成几个子模块来实现，所以Software Specification List也是我们参考的另一个比较重要的依据。

　　3.开展项目跨部门讨论会：

　　可以抽出时间，叫市场部的项目负责人、产品经理、项目经理、软件开发经理和软件开发人员，分别讲讲他们对整个产品的认识和设计模式，对每个功能点的理解和认识，理顺思路，达成共识，测试人员负责记录，测试Leader负责整理汇总，形成测试的部分参考文档。

　　4.测试人员整理用例需求疑问递交项目组和客户代表回复：

　　测试人员根据项目讨论会后的理解，测试过程中可能碰到的问题（如：边界值、输入数据类型等等）和需求不明确的问题，整理用例需求疑问，让相关的模块负责人在“用例需求疑问”表格中回复，并给出详细解释和说明。

　　5.项目内部用例评审：

　　测试人员根据对项目的理解，编写测试用例要点，测试组内部评审修改后，可以召集项目组的成员，帮助Review一下，然后进行修改。经过多次修改和评审以后，测试用例要点可能会更加全面一些。

　　6.邮件和客户代表确认部分争议问题：

　　测试人员与开发人员、项目组成员，在需求问题上讨论有时候观点不一致，各说各有理，这种情况下最好把争议问题写成邮件，发给客户让客户来拍板，确定那种需求合理，到底如何做？抄送项目组的全体成员，方便大家都了解客户的意见。最后编写测试用例的时候，以客户的邮件内容为准。

　　7.项目Demo和部分已开发系统：

　　大部分的系统，由于没有需求，为了避免项目风险，开发方一般都要做成Demo，不断让客户确认后签字，不断展现新开发的功能，以达到吸引客户的目的。如果项目中有Demo，Demo也是参考标准。如果什么都没有，那已经开发的部分功能模块，要去随时让用户了解了解，并提出部分修改意见，也可以为我们熟悉系统提供部分依据。

　　8.参考同行业和竞争对手的类似产品：

　　假如说是做一个网上书店类似的网站，我们编写测试用例的时候，可以看看“当当网”，“China—pub”等等类似成熟相关的网站。很容易发现本公司产品的问题，无意识给产品添加了竞争力。对于竞争对手的了解一定不能够少。

　　9.交叉模块的测试，最容易被人忽略：

　　一般的产品，功能部分的交叉，即是说在A模块中设置了参数，在B模块和C模块中体现该参数的实际运用。比较难的如我们现在测试的“银行系统”中的交叉模块，还可能牵涉到不同的用户，3个以上的模块之间的调用。即是有了需求也很少写，同时也是需求编写的一个薄弱环节。这样的测试用例编写问题，一般初级测试工程师很难考虑全。对于有这种交叉功能的模块，必须要求项目组中的精兵强将，画出相关的调用关系图，表明调用关系，方便后面编写测试用例。

　　10.可以使用电话、MSN、Skype等网络聊天工具咨询部分需求：

　　我们做的产品，大多数的客户都在国外，测试经理也可以用这些网络聊天工具和客户确认部分需求疑问。不过要要事先越好时间，并注意异地的“时差”。

　　我以前的团队中主要使用这些方法，如果大家有什么好的方法，请大家补充，完善！！

原出处及链接：http://www.51testing.com/html/200810/n95728.html

产品经理的英文称谓是Product Manager，
项目经理的英文称谓是Project Manager，两者的缩写都是PM。

自从1927年美国P＆G（宝洁）公司出现第一名产品经理（Product Manager）以来，
产品管理（Product Management）制度逐渐在越来越多的行业得到应用和推广。

产品经理（Product Manager），又称品牌经理（Brand Manager）。
一般来说，产品经理是负责并保证高质量的软件产品按时完成和发布的专职管理人员。
他的任务包括倾听用户需求；负责产品功能的定义、规划和设计；
做各种复杂决策，保证开发队伍顺利开展工作及跟踪程序错误等等。
总之，产品经理全权负责产品的最终完成。
另外，产品经理还要认真搜集用户的新需求、竞争产品的资料以及研究产品的发展趋势等。

有一句话说的很精辟：

　　产品经理——靠想。产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润的。

　　项目经理——靠做。项目经理是把事情做正确，把事情作得完美，在时间，成本和资源约束的条件下完成目标。

　　从管理的角度讲,项目经理是纵向的,而产品经理是横向的。

　　例如我们姑且理解项目经理是一个开发部门的项目经理,那么他一定是对某个产品进行开发的管理,负责开发的进度,开发过程中的协调,供应链等有关开发方面的问题,他最大的目标是时间第一,立项目标达成第一.并不会很尊重产品本身的市场需求以及业务逻辑的问题.

　　在一个公司中类似这样纵向管理的部门都是一个个职能部门,例如市场部,主要负责推广,销售部主要负责销售等,而产品经理是横向管理的,也就是说他将负责某个产品或者某个产品线从商业计划\市场竞争\开发需求\推广方案\渠道策略\物流等各个方面.当然产品经理不一定是决策人,每个公司对产品经理的权限限制也不同,但是产品经理一个产品线从头到尾的重要参与人.想做好产品经理需要很多方面的才华和技能,他也是一个公司中最适合培养复合型人才潜力的职位。

　　一个产品经理可能没有权利,但是一个产品经理要善于运用同事关系,客户关系去协调去促进事情的发展,一个项目是属于项目经理开发的,他有开发目标达成的责任.而这个项目也是属于产品经理的,他有对商业计划负责的责任.因此作为产品经理就意味着的和本产品有关的事,不论是开发\生产\推广\销售\成本\物流\渠道都是你的问题!

　　如果希望做一个复合人才就选择产品经理,如果希望做一个专注人才就选择项目经理。

　　项目经理与产品经理另一个重要区别是授权的范围不同：

　　项目经理一般是被授权的合同履约的负责人：

　　项目合同是规定承、发包双方责、权、利具有法律约束力的契约文件，是处理双方关系的主要依据，也是市场经济条件下规范双方行为的准则。

　　项目经理是公司在合同项目上的全权委托代理人，代表公司处理执行合同中的一切重大事宜，包括合同的实施、变更调整、违约处罚等，对执行合同负主要责任。
当然，根据企业的不同，老板能否给予项目经理相应的授权是另一回事。

　　产品经理的授权是保证流通链的畅通：

　　产品经理保证其所负责的产品，从上游创意、研发开始，至采购、生产，到下游渠道、通路，直至终端用户的整个流通链的畅通，因此要求产品经理既要有产品知识，也要有市场意识，还要具备协调能力，例如：财务、售后、物流……

　　但是，产品经理并无对外签订合同的授权。

　　做软件“大餐”的工序

　　软件质量保证（SoftwareQualityAssurance，以下简称SQA）的目的是验证在软件开发过程中是否遵循了合适的过程和标准。软件质量保证过程一般包含以下几项活动：
  首先是建立SQA组；其次是选择和确定SQA活动，即选择SQA组所要进行的质量保证活动，这些SQA活动将作为SQA计划的输入；然后是制定和维护SQA 计划，这个计划明确了SQA活动与整个软件开发生命周期中各个阶段的关系；还有执行SQA计划、对相关人员进行培训、选择与整个软件工程环境相适应的质量保证工具；最后是不断完善质量保证过程活动中存在的不足，改进项目的质量保证过程。

　　独立的SQA组是衡量软件开发活动优劣与否的尺度之一。SQA 组的这一独立性，使其享有一项关键权利——“越级上报”。当SQA组发现产品质量出现危机时，它有权向项目组的上级机构直接报告这一危机。这无疑对项目组起到相当的“威慑”作用，也可以看成是促使项目组重视软件开发质量的一种激励。这一形式使许多问题在组内得以解决，提高了软件开发的质量和效率。
  选择和确定SQA活动这一过程的目的是策划在整个项目开发过程中所需要进行的质量保证活动。质量保证活动应与整个项目的开发计划和配置管理计划相一致。一般把该活动分为以下五类：

　　1）评审软件产品、工具与设施

　　软件产品常被称为“无形”的产品。评审时难度更大。在此要注意的一点是：在评审时不能只对最终的软件代码进行评审，还要对软件开发计划、标准、过程、软件需求、软件设计、数据库、手册以及测试信息等进行评审。评估软件工具主要是为了保证项目组采用合适的技术和工具。评估项目设施的目的是保证项目组有充足设备和资源进行软件开发工作。这也为规划今后软件项目的设备购置、资源扩充、资源共享等提供依据。

　　2）SQA活动审查的软件开发过程

　　SQA 活动审查的软件开发过程主要有：软件产品的评审过程、项目的计划和跟踪过程、软件需求分析过程、软件设计过程、软件实现和单元测试过程、集成和系统测试过程、项目交付过程、子承包商控制过程、配置管理过程。特别要强调的是，为保证软件质量，应赋予SQA阻止交付某些不符合项目需求和标准产品的权利。

　　3）参与技术和管理评审

　　参与技术和管理评审的目的是为了保证此类评审满足项目要求，便于监督问题的解决。

　　4）做SQA报告

　　SQA活动的一个重要内容就是报告对软件产品或软件过程评估的结果，并提出改进建议。SQA应将其评估的结果文档化

　　5）做SQA度量

　　SQA度量是记录花费在SQA活动上时间、人力等数据。通过大量数据的积累、分析，可以使企业领导对质量管理的重要性有定量的认识，利于质量管理活动的进一步开展。

　　要说明的是，并不是每个项目的质量保证过程都必须包含上述这些活动或仅限于这些活动，要根据项目的具体情况来定。

　　SQA 计划中必须明确定义在软件开发的各个阶段是如何进行质量保证活动的。它通常包含以下内容：质量目标；定义每个开发阶段的开始和结束边界；详细策划要进行的质量保证活动；明确质量活动的职责；SQA组的职责和权限；SQA组的资源需求，包括人员、工具和设施；定义由SQA组执行的评估；定义由SQA组负责组织的评审；SQA组进行评审和检查时所参见的项目标准和过程；需由SQA组产生的文档。

　　选择合适的SQA工具并不是试图通过选择SQA工具来保证软件产品的质量，而是用以支持SQA的活动。选定SQA工具时，首先需要明确质量保证目标。根据目标制定选择SQA工具的需求并文档化，包括对平台、操作系统以及SQA工具与软件工程平台接口的要求等。

　　如何使白壁“无瑕”

　　按工序去做也不一定能得到一盘完美的“大餐”，因为火侯等因素实在很难掌握。万一掌握不好怎么办？软件质量控制主要就是发现和消除软件产品的缺陷。对于高质量的软件来讲，最终产品应该尽可能达到零缺陷。而软件开发是一个以人为中心的活动，所以出现缺陷是不可避免的。因此，要想交付一个高质量的软件，消除缺陷的活动就变得很重要。缺陷消除是通过“评审”和“测试”这类质量控制活动来实现的。

　　缺陷在软件开发的任何阶段都可能会被引入。项目质量管理过程包含了许多可以识别缺陷、消除缺陷的过程。“识别缺陷”和“消除缺陷”本来是两个不同的过程，但在这里为了简便统一用“消除”来代表它们。潜在的缺陷越大，用来消除它所花的费用越高。因此成熟的软件开发过程在每一个可能会引入潜在缺陷的阶段完成之后都会开展质量控制活动。这些为了消除缺陷的活动包括：需求评审、设计评审、代码走查、单元测试、集成测试、系统测试以及验收测试等。

　　质量控制的任务就是策划可行的质量管理活动，然后正确地执行和控制这些活动以保证绝大多数的缺陷可以在开发过程中被发现。

　　正如前面提到的，在进行评审和测试时可检测到缺陷。评审是面向人的过程，测试是运行软件（或部分软件）以便发现缺陷。在一个项目里，评审和测试活动是预先策划好的（计划书中确定执行哪些质量控制活动和何时执行这些活动）。在执行过程中，根据已定义好的过程来执行这些活动。通过执行这些活动来识别缺陷，然后消除这些缺陷。例如，系统测试过程一般包括制定测试计划，测试计划中应列出在测试执行过程中所有的测试用例，评审测试计划，并且最终执行测试计划。

可惜是，对与国内大多公司目前还只是希望~

　　需求分析师：项目实施后客户对需求变更的多少，变更越少，需求分析师业绩越好。需求分析师的工作对项目成败有极大的影响，它对人的要求很高，比如沟通能力，对业务的熟悉程度和判断能力（潜在需求），对客户组织（谁说了算）/人员（性格等）的掌握程度，对系统运行环境的了解等。

　　系统架构师：项目整个过程的架构保持不变，如果有变化，那么架构师的工作即为失败。系统架构基于需求分析的结果，所以有时候架构更改要归咎于需求分析师。其实目前软件架构的资料信息很多，基本上都是知识，创新的机会不多，像David H.Hansson不满web开发的烦琐，创建了Rails on Ruby的例子属于极少数，我们多数都选择成熟的框架和技术。架构师需要有广泛的知识和长期的经验。并且能追踪软件技术的最新发展。

　　系统设计师：项目实施后维护开发（针对新需求）工作量的多少，改动越少，设计师的业绩越好。设计师的工作是项目中最具创新潜力的部分，精妙的模型，算法开发，公司的核心技术都来源于此处，不同设计师的工作成果可能是天上地下，当然了，缺少巧妙设计的软件系统也可以跑，但后续的维护开发必定会成为一个成本黑洞。

　　软件开发师：软件的bug数量和修复bug的时间以及bug的严重程度，公司可以有一个公式来量化这些指标。软件开发师的工作是项目质量的基本保证，软件系统最终要在这里变成成品。很多时候软件开发师也兼着设计工作，那么他们的重要性就更大了，好的开发人员多数是好的设计人员，因为写代码本身也是在做设计。

　　测试工程师：软件实施后bug的数量和严重程度。考核开发人员和测试人员都用了bug指标，但这些bug应该是独立计算的。这里bug是广义的，比如压力测试不过关，也算一严重的bug。

　　最后是架构/设计/开发/测试的反复，这里情况比较复杂，比如代码质量低下造成测试人员工作量的剧增，测试人员是比较冤枉的，这里就需要项目经理的智慧了，具体情况具体分析，对项目经理的要求是全面的，项目经理需要对团队士气负责，要知道，软件开发是智力活（体力活的观点非常错误），人的因素最重要。

　　项目经理负责真实而准确的记录项目所有数据，这是业绩考核的根据，他必须做到公平、公正、公开！

  不太清楚系统架构师，系统设计师区别是什么？？？