测试经验总结由刀豆文库小编整理，希望给你工作、学习、生活带来方便，猜你可能喜欢“硬件测试经验总结”。
6年测试工作的思考
前言
在公司已经干了6年的测试了，干测试经理也5年了。正好趁此机会把自己6年来一直想写但没写的东西写出来。这篇文件纯粹是对自己工作的回顾。由于时间仓促基本上是想到什么些什么，有点儿乱，也请大家多多担待了。只要还有些人能从中找到些儿同感，或从中得到一些帮助，一些经验，我就知足了。
1.什么是测试
首先我要谈谈什么是测试。相信好多测试人员跟我一样，来公司之前也没有从事过任何测试工作。对于测试都是从零开始的。也有好多人跟我一样，从各种书上或是培训中得到过有关测试的各种定义。但不知道大家有没有净下心思考一下。什么是测试。在公司公司测试工作的定义是什么，测试的工作范围是什么。
测试的定义根据测试技术的发展，历经了3个主要的阶段。第一个阶段，认为测试就是找产品中的bug。第二个阶段，除了找bug以外，又增加测试是对软件质量的度量这一概念。第三个阶段，明确了测试是指为了度量和提高被测试软件的质量，对测试件进行工程设计，使用和维护的并发生命周期。注意其中提高的测试件，其主要是与软件这个词进行对应。明确测试也是一种开发过程。他的工作成果就是测试件，好像平时我们所谓的测试案例、测试脚本等等都可以称为测试件。然后使用测试件去度量和提高被测试软件的质量。
目前，在中国大部分软件企业，尤其是中小型的软件企业还停留在第一阶段。我个人觉得公司稍微好一点儿，处于一、二阶段之间。因为我们平时做的最多的一件事，还是找bug。至于测试案例和测试脚本等等，只占用工作量的很小一部分。而且我看不到大家在平时的测试工作中是完全依据测试案例进行测试的。目前测试案例等工作更多的成为了一种形式上的产物。从有些部分所有产品的测试案例在一个下午就能评审完就能看得出来。
说到这里顺便在谈一句测试计划。目前的测试计划是作为产品计划的一部分。先明确大概发版时间，然后是各个阶段的里程碑，其中提交集成的里程碑是死的。开发需要的时间就是那么多，剩下倒推的时间就是测试的时间。这样定出的计划是否能够起到计划的作用就不好说了。现在的计划更多的是罗列联调测试的各种内容，至于时间，不说也罢。所以从中也可以开出公司的测试也就停留在一、二阶段之间。
明确了公司测试的定义（个人理解），也就不难理解公司给测试人员的定位了。在测试人员中经常流传的一种说法就是国外测试人员的地位多么多么的高，开发就是coding。咱们公司开发比测试多拿多少多少，测试人员地位是开发序列中最低的。大家也要看看人家公司测试人员的素质，测试在开发过程中的重要性。再看看自己所从事的工作，就是找软件的bug。当然我也个人认为有经验极其丰富的测试人员对产品的贡献比开发和需求大。明确了这些，心里也就能少点儿不平衡感。
2.测试方法的思考
说完个人对测试含义的理解，再说说个人对测试方案的一些思考。
个人认为在公司6年，测试方法没有什么提高。主要还是以黑盒测试为主。中间也曾经引入过各种各种工具，但测试人员真正用起来的也就是robot。而且robot主要是进行回归测试，再加上一些人并没有真正认识到其价值，应用范围也极其有限。对整体测试效率的提升影响不大。所以目前的测试方案还主要是以需求为依据的黑盒测试。至于什么极限值了，成对测试法等等，都是建立在黑盒测试的基础上，而且从我一来公司就有相应的测试项目，只不过没有明确概念而已。
另一个说个人觉得6年来公司测试方法没有什么提高的原因是，6年前测试是以人为主，靠得是测试人员的经验，对产品的熟悉程度，对业务的理解程度。6年后测试还是以人为主，人就是测试的主体，产品质量的保证。还没有过渡到测试案例就是测试的主体，测试案例的完整性是产品质量的保证。只要测试还是以人为本，我觉得测试的效率就不会有太大提高，产品质量的信心来源也是对相关测试人员的信任。我个人觉得以黑盒测试为主要的测试方法没错，而且也比较符合目前公司的测试现状。但一定要注意各种经验的总结、积累，更重要的是共享。虽然目前测试案例在测试工作过程中的地位不重要，但其毕竟是编写者的经验积累。汇总起来也是一笔可观的财富。可现在如果有人问我850的测试方案在那里，其中还有多大比例能够用在现在的产品中，在现在的测试工作中有多少以前的案例能够复用。其他产品中的测试案例中有多少是关于接口功能，有多少我可以借鉴。我不知道，这也是自己工作不到位的地方。所以我要说的作为黑盒测试为主要的测试方法，一定要注意测试经验的总结和共享。
而且我认为一个人如果黑盒测试能做到位，做到最后培养的是一种测试的感觉。测到最后，产品你一看就能知道那里可能有问题，那里应该没什么问题。这样有重点地投入测试力量可以收到事半功倍的效果。可这是需要大量测试经验的积累的，不是我告诉你，你就知道的能力。在此前提上加强测试人员之间的横向沟通，形成经验贡献。可以较快的培养测试人员的测试感觉。
最为测试经验积累的另一个重要方法就是加强对测试案例的要求和管理。每版测试案例不仅要包括新增功能，还需要包括上一版本中继承的案例，修改或删除上版案例中变更的内容。从而形成一份完整的关于产品所有功能点、接口、升级、年结等等各方面的测试案例。真正做到测试案例是测试的主体，从而提高测试效率，提高产品质量。
3.测试工具的概念和作用
测试工具，什么叫测试工具。我认为任何能提高你测试效率的工具都可以称之为测试工具。不仅仅指robot或是loadrunner这类专门的测试工具，也不仅仅指使用各种编程工具编写的测试工具。像总账工具、eai等，即使只是帮我们导入一些常用档案，也可以节约我们的测试时间也可以称之为测试工具。
我个人现在公司测试在测试工具开发上还很不足。在公司里一提起测试工具，大家第一个想到的可能就是robot。即使是robot应用的也不够深入。大家经常认为robot主要录制gui的脚本，跟产品界面联系紧密。每次回放成功率不高，各个版本间脚本复用率也较低。而且每次总是以各种理由将脚本录制放到最后，经常就不了了之了。最后阶段的测试任务实在太紧。我想说的是robot的应用虽然有各种各样的局限性，但其毕竟提高了测试效率。比如说安装盘验证，使用robot验证，每天都可以节约一半以上的验证时间，这就是效率。认识了它的好处，才能想尽办法解决或避免在robot使用中的各种问题。以前同事有一套robot脚本规范就很好，使用后不仅提高了回放成功率，而且回放中断后，继续回放也变得很容易。所以说使用robot后，想100%回放成功不可能，想不再进行脚本的调试也不可能。认识这两个问题后，就需要加强robot使用经验的总结和共享，有针对性地加强robot使用问题的研究，每版测试开始时针对上版robot脚本的复用问题进行研究。这样才能用好它，真得使之成为一个工具，而不是一项任务。
一种工具也不是万能，有许多针对产品特性的测试工具。只能自己开发，大家应该积极提需求。凡是认为有可能提高测试效率的工具需求都可以提。能从网上找到现成的工具解决需求更好。不能，如果是普遍性的需求，可以专门进行开发。因为咱们产品的特性，每版间测试工具的复用度很大。从长远看就是节约开发成本，缩短开发周期。
在现阶段加大测试工具的适用范围和力度，用好各种测试工具，可能是提高整体测试效率最快最好的方法。但一定要加大推广的力度。否则有了好的工具，没人用或用不起来也是没用。
4.如何看待各种规则和执行
可能大家觉得平时开发过程中有好多规则、制度。这些除了一些自己公司内根据各种情况制定的外，大部分都是跟cmm体系相关的一些规则。可以说是已经被许多软件公司验证过，可以提高开发和测试效率的规则。但好多人觉得起没有什么用，就是在浪费时间。总是以一种完成任务或是应付差事的心情去做。我觉得大家之所以觉得其没用，恰恰就是由于你去做这件事的动机不对。总以应付差事的心情去做，你就不可能真正理解这么做的目的，这样做能给你带来什么好处，你从中会得到什么收益。所以我个人认为，既然有规则，不管是公司自创的或是借鉴其他标准，都是为了解决开发过程中的问题，为了提高开发的效率，保证产品质量。也许这些规则中有这样那样的不合理，但只有你认真地去做了，才能发现其中的不妥之处，才能改进，才能更有助于你的工作。
执行也是我觉得在工作中需要进一步加强的环节。许多规则就是因为执行力度不足，才容易让一些人找到空子，应付了事。但怎样加强执行力度，还是一个需要大家一起进行探讨的问题。
5.作为一名测试人员应该具有的素质
测试人员应该具有什么样的素质，相信好多人都有自己的理解，不同书上的观点也不尽相同。我就说说我在公司工作了六年，觉得一个合格的测试人员应该具有什么样的素质。业务和测试方面的能力就不说了。
测试人员应该具有的素质包括： 1.踏实细心和积极主动
我觉得作为一名测试人员首先要踏实细心。测试人员每天都要面对着枯燥的程序，从事着大量的重复工作，还要尽量发现产品中的bug。如果不踏实，你就坐不住，总想干别的，就无法净下心来想用户有可能怎么用，需求对产品是怎么要求的，现在产品中是怎么做的，哪里可能存在问题。不细心，就特别容易一些产品中微笑的错误，而恰恰就是这些错误是最影响产品形象的问题。
至于积极主动就不多说了。这是每个人都应该具有的素质。2.怀疑一切
不抱着怀疑一切的态度就不是一名合格的测试人员。经过你手测试的产品面对的是直接用户。你不认真负责，不抱着怀疑一切的态度。总想着这个功能本版没动应该没什么问题，这个功能没什么用户用不用认真测了。这样发出的产品，我是不敢让用户用。因为用户用起产品来是千奇百怪，有些用户的水平和对产品的理解比咱们还要深。所以一定要抱着怀疑一切的态度，认为产品每个功能都可能有问题，认真地测试产品的每一个测试点。
3.协作和团队感
协作和团队感也是十分重要的。要意识到测试、开发、需求是一个团队，一个整体。离了谁，产品的质量都无法保证。诚然有个别开发人员责任心不强，经常将未经任何验证的代码编译后发给测试进行验证。耽误了测试人员不少的时间。但越这样，测试人员越应该负责，否则产品发出去影响的是公司的形象。
还有个别开发人员开不起测试。此时就需要你通过各种方法去证明你自己的能力。比如测试出他根本就没考虑过的问题等等。以实际行动证明你离不开我，咱们是一个水平的。只有这样加强协作和团队建设，加强整个团队的质量意识，才能提高开发效率，保证产品质量。
4.自我提高和总结的能力
测试人员经常很迷茫，不知道自己的发展方向在哪里。测试技术还是专业知识。领导们所谓的个人发展方向考虑也经常是画一个饼在那里。这时就只能靠我们自己了。看你想今后从事哪方面的工作。一般情况下，如果升不到管理层就只有两条路可选了。一是业务精通，将来可以向需求或是售前、实施方向发展。一是技术精通，多掌握几种测试工具，又能力可以学习一些编程方面的知识。将来还继续从事测试方面的工作。随着中国软件开发的规范化，这条路也是很有发展的。
另外，我觉得作为一名合格的测试人员，一定要注意进行总结。通过总结可以对自己的工作进行一个回顾分析，看看那些做得不错，下次还继续这么做。那些工作还有改进的余地。对自己能力的提高是一个很好的帮助。
6.作为一名测试经理应该具有的能力
作为一名测试经理，我觉得除了具备一个测试人员应该具备的素质外，还应具备以下能力。
1.出色的沟通和协调能力
由于测试人员和开发人员的工作性质，必然导致测试人员和开发人员在工作中会产生冲突，对同一问题会产生不同的看法。这时，你怎么去协调，去沟通，解决这种矛盾，让自己所在的开发团队中极少的受此影响，就是考验你能力的时候。
2.条理性和计划性
作为测试经理，要负责带领团队内的其他测试人员全面的测试产品。由于测试项目很多，不仅包括产品功能，还要包括效率，性能，压力，并发互斥，环境等等方方面面。此时你如何去安排这些测试项目，哪些可以先做，哪些可以并行。与开发人员在一些项目的测试中如何协调就是考验你做事的条理性和计划性。
3.从全局考虑产品测试的能力
每一个测试人员在产品测试中，重点肯定是自己负责产品的功能，此时就容易遗漏其他的一些测试项目。有可能是接口的部分功能，又可能是升级或年结的部分功能。此时，你如何提请他们还有漏测的功能点。在有限时间内，能找出他产品测试上的薄弱点，就是考验你通盘考虑产品测试的能力。
后记
上面就是我对6年测试工作的一个回顾。这些都是我个人的一些观点，很不全面，也有不正确和遗漏的地方。大家看后，能从中得到一些自己需要的东西，我就知足了。
再次感谢在这6年中给了我许多帮助和支持的各位兄弟姐妹们。
附录A、QA工作心得
看过许多同行兄弟姐妹的工作感受，反映了一些从事QA工作过程中的困惑，心里也很有同感。之前做过几年的测试工作，到了新的公司开始做QA工作，虽说测试工作也是属于质量工作范畴，但是真正干起来才发现，还是有很大的不同的，尤其是思想方法和工作方法上。所以也是边学边干，这边和大家分享一点心得。
1、调整好自己的心态。
尊重开发人员、产品经理、项目经理等项目组内同事，不要把自己定位为监工，要把自己定位为服务员。如果你真的是从心里想帮助大家把事情做好，而不是教训别人，大家会感受到的。很多时候，调整好自己的心态才是难点。
2、有的放矢 不要盲目的发表意见，要做到有理有据，这也是避免项目组内成员产生争执和不理解的前提。在提出意见和建议前，最好做一下调查，收集一些资料和数据，或者和大家深入的聊一聊，开一些交流会，座谈会，收集到一线开发人员的真实感受，不要自己一觉得有问题就冲出来，这样肯定会被别人反感，也会降低大家对QA的认同和信任感。
3、数据说话
质量工作相对务虚不假，之前做测试好歹还有很多的bug摆在那里，刚开始做QA工作确实觉得虚了很多。自己的产出在哪里？后来发现，其实还是可以有很多的，呵呵。你可以给相关人员进行培训（质量知识、软件工程知识、产品开发知识、质量制度和规范等等），会议记录和培训资料算是你的产出的一部分。另外，对于项目过程中产生的问题，变更等，要有记录，一定周期内作出分析和报告，比如，变更发生率，项目延期的原因分布，与计划的不符合程度等等。进一步提出改进建议，有了这些数据支持，你提出建议也就更有说服力。
4、沟通再沟通
其实很多问题都是发生在沟通上，我觉得沟通好了，起码可以解决70%的问题。多为大家提供交流和沟通的机会，比如，发起一个交流会，让组内同事互相培训，形成一个良好的内部学习交流气氛。另外，什么也比不过面对面的沟通，抛弃聊天工具和email吧，走过去，和你的同事一起好好聊聊，吃饭的时候，坐车的时候，你会发现很多深入的问题的，呵呵。
5、循序渐进
规范制定好了，不要一下子就想完全推行到底。毕竟要改变别人已有的习惯，是会让别人不舒服的，呵呵。所以要循序渐进，分期分批，一点点来，习惯慢慢的就被改变了，这样大家就不会太抵触。而且，在分期分批推行规范的过程中，别忘了不断收集反馈意见，不断改进和修正规范，规范可不是qa说是什么就是什么的，一定要收集大家的意见，达成共识，这样才有被大家执行的基础。
6、展示自己
QA工作务虚，但是可以落到实处，是有很多实际工作要做的，比如文档编写，规范起草。培训、评审、跟进问题。这些工作的成果如何体现，效果如何，可以通过一些问卷调查，来收集大家的反馈，举个例子，如果推行产品开发流程规范前大家对流程的满意度是50%，推行规范两个月以后，满意度成了90%，你说这是谁的功劳呢？呵呵，这也是数据说话的一个方面，也是QA工作成绩的展现。说了这么多，其实我做QA工作也只有3个月，还有很多的不足，希望能和大家多多的交流，如果自己的一点心得，能够给大家一些帮助或启发，就深感欣慰了，呵呵。欢迎拍砖！
附录B、SQA之Q&A 软件质量保证，即 SQA，全称是 Software Quality Aurance。
问： SQA 目的是什么？
答： 对于任何的行业，讲到质量控制，归根结底都是为客户提供更高品质的产品，更好地满足客户的需求。质量有问题的话就不能满足客户的需求。在 CMMI 里边就有 “ 集成流程产品开发 IPPD(Integrated Product & Proce Development)”，为什么要集成呢？就是说产品的研发不仅仅是开发团队的工作，还要把市场团队、销售团队、整个的流程、包括客户的反馈都要考虑进来、集成进来。目的是为了什么？其实就是为了更好地满足客户的需求。六西格玛里面说 DPMO(Defect Per Million Opportunities)，百万产品里有缺陷的产品只有三个。这是为什么？就是为了减少差错，从而让客户享受非常高质量的服务。
问： SQA 等于测试？
答： 测试其实只是 SQA 的一个环节，SQA 的全称是软件质量保证。在国外很多的大型的企业，比如说摩托罗拉、爱立信，他们的研发团队里面都专门有一个 QA 部门，其实他们并不是做测试工作的。QA 部门其实是管理开发流程的执行，并专门负责制定产品开发流程。比如说 RUP 里面有一个角色，叫 Proce Engineer，过程工程师，他就属于 QA 部门，他的工作就是负责制定整个软件开发的流程。因为如果说要保证质量的话，不能只靠测试来保证。而必须在整个开发流程的各个环节都要做得很好，才能够真正地提升软件的质量。而测试只是整个开发流程最后的一个阶段。所以说一个好的流程就决定了一个软件的开发能不能按时交货，能否保证软件质量。这个流程就是由 QA 部门来制定的。QA 部门还有另外一个职责，就是保证整个研发团队能够严格按照这个流程来运作。在项目到达每一个里程碑的时候，QA 部门的 QA 经理就会介入，对项目做一个审核，检查前一阶段的工作是否按照公司制定的流程来运作。看看该有的工件是不是都有了，该有的步骤是不是都有了。开发团队要证明给 QA 人员看。只有过了这一关，QA 部门才会同意说开发团队可以往下走，进行下一步的工作。所以严格来讲，众广义上理解，SQA 是针对整个软件开发流程的，它关心的是怎样在软件开发生命周期中来保证好软件的质量。这是一个非常大的概念。
问： SQA 在 RUP 中是如何体现的？
答： 其实 RUP 整个流程都在讲 SQA。业界常见的模型，譬如 CMM/CMMI，六西格玛，ISO9000，RUP，它们做的基本上是同一件事情--都是在做流程改进，都在做质量控制，但是各自的侧重点不一样。像 RUP 和 SDP 专门侧重于从软件开发的整个生命周期来保证软件质量，所以对软件开发商特别适合。而其它的模型，侧重点则在其它的环节，比如说 ISO9000，用在制造业比较多一些； CMM，原来是应用在软件这个行业的，后来扩展到 CMMI，就扩展到其它行业它也适用。但适用面越广，它拉的层次就越高，可实际操作的东西就越少。RUP 是专门侧重于软件项目开发的。怎样来保证做好 QA 呢？ RUP 里定义了一个软件生命周期模型，分成四个阶段--初始阶段、细化阶段、构造阶段、交付阶段，每个阶段有不同的侧重点，通过多次的迭代，每次迭代里面都要做质量控制。
质量控制从需求开始，有很多需求分析和需求管理方面的技巧和技术方法，它们从需求方面来保证软件的质量；到了设计，就有很多成熟的设计方法，例如可视化建模，基于构件的架构设计和现在提出的模型驱动开发方法；再到实现，到测试等方面，都有很多的方法和技巧来提高软件的质量。这里面每一个环节的目的都是为了提高整个软件开发的质量。
开发过程中，什么样的问题会造成质量问题呢？其实最主要的就是沟通方面的问题，以及对系统复杂度把握程度的问题。我们逐渐发展了一些技术来帮助我们解决这些方面的问题，例如用 UML 这种标准化的语言来增强团队的沟通，用面向对象的技术来帮助加强对复杂度的控制能力。
原来这个系统很复杂，使用面向对象的方法，本身就是为了简化系统构建的复杂度。改变你看问题的角度，你对问题的把握程度就会不一样。譬如人看一个二维迷宫很容易就能找到出路，但蚂蚁在里面就走不出来，因为看问题的角度不一样。面向对象方法和可视化建模技术可以让开发人员可以更好地去把握系统，增强对系统的可控制能力，从而从这些维度上来提高和保证软件的质量。
现在有很多自动化的工具，如 IBM Rational RAD(Rational Application Developer)/ RSA(Rational Software Architect)，都是支持 MDA 的开发方法，在模型这一级进行开发，从模型直接生成代码。在开发方面我们有很多辅助工具，帮助开发人员尽量将人工做的工作、复杂的重复性的工作、不具有创造性的工作让工具来做。让人去关注他应该关注的方面，比如开发人员应该关注业务逻辑的处理，但是软件的构建方面我们是尽量让工具来降低构建细节上的难度。这样也是有助于提高质量的。
然后产品出来了，需要进行测试，有测试流程、测试规范来帮助保证质量，这是最直接的。然后还有很多的环节还会发生错误，比如配置管理、版本的管理，也需要相关的支持来保证软件的质量。所以说软件质量保证不应该只是在一个环节上，比如测试环节来保证，而应该是整个的流程，我们应该全面地去改进流程来保证质量。
问： 做 SQA 这方面的人员，在沟通方面需要的什么样技巧和能力？
答： 首先从大的方面说，整个团队的沟通，首先是大家要讲同样的语言。UML 只是这种语言的一部分，我们不要狭义地理解这种沟通语言就是 UML。它还包括采用一个什么样的流程方法，整个团队都要理解。譬如你说项目正处于 “ 精化(Elaboration)” 阶段，这个团队都要能理解这个术语。
还有就是整个组织机构内部大家采用的流程都是要一样的。举个例子来说，Rational 有很多产品，其中很多都是收购来的。不同的产品团队采用的开发方法、开发工具都是不一样的，他们到了 Rational 之后做的第一件事就是整合。这个整合一方面是说产品要整合起来（我们有 Suite 产品）；同时也是针对开发团队开发方法的整合，例如 Rational 花了一两年的时间把所有产品团队统一到 RUP 和 ClearCase/ClearQuest 平台之上，这是我们的首选。实际上到了 IBM 之后也是一样，IBM 现在正在做的计划就是让所有的实验室、研发团队都要使用 IBM Rational 自己的开发工具，他们都在使用 IBM 自己的开发方法、开发平台。这就是让大家的沟通基于一个统一的基础架构 ―― 统一的软件开发平台，这也是增强沟通的一种方式。另外，讲到 SQA 的人员，在 RUP 里对应的就应该是 Proce Engineer。他的主要的职能就是定义流程，保证流程的执行，并且不断地改进流程。对他的要求就是要对流程要比较了解，有实际项目的开发经验，不然没有办法理解流程，这是技能方面；另外就是与人的沟通能力要强，跟一般的开发人员和项目经理是有区别的，沟通的能力一定要强，他要负责说服项目团队来遵循标准。
问： QA 人员与目经理和开发人员之间的关系是怎样的？
答： 首先彼此之间是一个合作的关系。如果片面理解 QA 人员只是 “ 过程警察 ” 的话，就可能把他和其他的角色对立起来了。实际上在一个团队内部要避免这种认识。因为大家都是在一个组织架构内部的，大家的目标是一致的，就是要把公司的业务做好。所以 QA 人员的职责和任务就是帮助这个项目团队更好地进行软件的开发。既然已经定义的流程是比较适合企业的，项目就应该遵守这个流程来进行开发。如果有时候项目因为赶工，或是其它的原因违背一些流程上的规定的话，就会对软件的质量会造成一定影响，他就有责任来帮助开发团队来纠正这方面的一些错误。还有就是进度方面的问题。如果不按照流程来走的话，短期内看起来进度是快了一点，但从整个项目的周期来看，有可能是给以后的工作带来隐患，客观上肯定是延长整个开发的进度的。所以对于一些流程管理得比较好的企业，你会发现他们的 QA 部门和开发团队是相处得比较融洽的，配合是比较紧密的。在我们的客户里就看到过他们的开发团队非常感谢自己的质量控制人员，觉得他们对自己是给了很大的帮助。
QA 人员跟每一个角色的关系，如果你对应到 RUP 的话，RUP 里就定义好每一个角色是做什么工作的。RUP 里分了 9 个规程(discipline)，流程工程师是在环境规程里边，项目经理是在项目管理规程里边。每一个规程其实就是一类开发活动，其中的角色和他们所产生的工件集合，是一个分类。可以把项目经理相关的工作，他所涉及到的工件，比如说软件开发计划、风险管理计划、质量保证计划都放在一起，放在这个规程里面。所以 QA 人员跟项目经理的关系就是去检查项目经理在这个岗位上所做的职责是否到位，是不是跟流程相符合。其他的角色也是一样的，譬如一个测试人员，就要看你有没有根据规定把缺陷按正确的测试流程汇报，发现缺陷之后是否能够得到改正，并作一个复审，还有回归测试的时候有没有考虑测试的完备性等问题，就是看测试人员有没有做好具体的工作。QA 人员和整个项目团队在工作中的关系就是看每一个角色是不是很好地完成了自身角色所应该完成的开发任务。标准是什么？就是这个组织的流程，流程是保证质量很重要的一个依据。
问： QA 人员如何判断其工作效果和质量？
答： 最直接就是 RUP 里的工件。可以去检查这些工件，可以根据检查的结果来判断角色是否达到了要求。既然是检查这个结果的话，就有必要涉及到统一流程和工具的问题。就是说开发团队有必要采用统一的开发方法和流程。不然的话每一个开发团队各自采用不同的开发流程，流程工程师就很难去评价，没有一个可对照的标准，没有可比性。另外，和采用的工具也有关系，就是说团队要尽量采用统一的开发平台。采用统一的开发平台，工具会帮助自动收集很多的信息。比如说我们的 Project Console 可以帮助收集很多量化的指标；现在有 Portfolio Manager，项目组合管理平台，可以帮助了解项目进度还有项目进行过程中产生的各种结果；还有包括测试的报告等等，这些都最好有一个统一的标准。打个比方来说，现在的航空公司都会选择相同飞机制造厂商的机型，就是要降低维护的成本。因为机型比较统一的话，就比较好进行管理。在一个软件企业的话，在内部采用统一的软件开发平台也能有助于企业判断项目的情况，判断的方法也会相对比较简单，工作量会降低。
这是从 QA 的角度来看，其次从整个团队的角度来说，今天是做这个项目，明天做另外一个项目，作为企业的管理人员肯定不希望员工今天做这个项目用一个工具，明天做另外一个项目用另外的工具，这样学习成本就太高了。
