从图上我们可以清楚地看到，测试是贯穿于SpecDD整个过程的，从需求到开发到大规模测试，无一不显现着测试的影子。

　　不过虽然测试贯穿整个过程，但是其实是不同类别的测试，比如需求阶段的叫做“设计测试“，开发阶段的“验证测试”，而产品进入大规模测试阶段叫做“Full Cycle Testing”，而我今天想讲的 Floater QA，即使是属于开发阶段的测试，下面来主要介绍一下：

　　从英文上分析 Floater QA的意思大约是流浪的QA，引申开来大致就是这个QA不会去固定做一个工作，而是会参与很多地方的测试，哪里有需要就会去哪里。（以下简称FQA）

　　那这个FQA有哪些地方需要去参与呢？

　　● 参与测试用例的编写

　　● 参与功能最初的验证性测试，修改测试用例，并且给出改善建议

　　● 与开发人员与项目经理紧密合作解决所有阻碍下一步测试的问题

　　为什么需要有FQA这么一种QA的设置呢？

　　因为在实际的软件开发过程中，我们可能会经常遇到一种情况，一个功能或者一个产品给QA去测试的时候，由于开发不可能把所有地方都测试过，所以一旦发现严重的问题，这些问题会阻碍QA去进一步的测试，但是开发不一定每次都是能第一时间去修复它，那也就使得对于这个功能的测试会因此暂停。如果这种问题不断累积的话，我们会发现一个更加严重的问题：开发很忙，因为有很多功能需要去做；而QA需要测试的功能也很多，但是却发现很多没法测试下去。

　　所以引入FQA这么一类人，他们跟开发与项目经理合作最紧密：

　　1、当功能还在开发的时候，先去写测试用例

　　2、当功能开始有Build可以测试的时候，FQA首先去介入测试，他的测试其实是为后面的正规测试做准备，所以要确保该功能基本功能能够工作正常，符合设计文档，发现了问题，需要直接面对面与开发沟通，快速修复，如果这个最初的测试无法通过FQA的测试，那意味着这个功能的开发部分工作还没有结束，无法让正式的QA团队去进行测试。（平常情况下，开发人员为了改进度，可能草草跑了一下功能就说做好了，导致以后发现很多问题，进而影响其他功能，影响整个进度，而FQA的出现，能让这种情况较少出现）

　　3、FQA测试完成后，开发人员可以正式把这个功能打到“待测试的状态”，让正轨的测试人员在各种的环境下进行更加细致的测试和性能测试。

　　4、FQA测试的同时需要根据需要更新测试用例，让之后的正规QA测试可以做些参考。

　　所以，用一句话形容FQA的作用就是：帮助开发人员去高质量完成开发工作，帮助测试人员去顺利进行测试工作，帮助产品的开发能够在可控的范围下进行。

相关链接：

什么是SpecDD？

敏捷开发中的测试——SpecDD模型

　　对于架构，更具体一些指架构模式，如第6章介绍的关于测试对象分析的三层架构模式。一边是深不可测、充满挑战的技术与艺术的高度体现，一边是“又恐琼楼玉宇，高处不胜寒”的担忧。高深的东西如何平民化，即那些高调的架构，能不能具体应用到工程实践中，很好地达到预期，而不是成为束之高阁、脱离实际的一堆废话或模型。这里站在项目测试的实用角度，总 结工作中的经验与教训，提出架构设计的操作模型，如图4-9所示。从图中我们可以看到一个完整的测试架构设计过程包括以下几个阶段。

　　1、业务测试框架设计：它包括业务测试技术与流程管理两个部分，基本框架的设计离不开业务需求与公司流程体系。其表现形式可以是一种测试方法、一块代码程序、一系列的流程规范等。

　　2、提取测试需求：广义上理解，包括与测试工作相关的业务及非业务需求，只有有了需求（工作中出现的问题也可认为是一种需改进的需求），才可进一步完善框架。

　　3、决策/部署测试策略：为测试需求服务的一系列解决方案。

　　4、开发测试套件：具体解决测试需求的措施集，如测试用例集、脚本程序、测试工具等。

图4-9  测试架构设计过程示意图

　　这4个阶段，它们之间是相互作用，相互影响的。细心的读者也许已注意到，位于图中内侧的“提取测试需求”，它与测试框架的设计并不是一种直接关系，没错，它们之间的关系要通过后续的工作体现在框架中。可以理解为一个新的测试项目开始了，以新的测试需求为起点，通过部署测试策略，开发新特性的测试套件，来完善测试框架。如此往复，依托一个个测试项目，不断改进、壮大测试框架。以使后续的项目测试能重用测试框架的内容或方法，并使整个测试过程始终在有序可控的状态下进行，最终能以高质量且减少项目的整体测试时间来完成测试工作，这也是架构设计的最主要目的。

　　对这4个阶段，可以理解为它是一个系统级的最顶层划分，对于每一个阶段，它又可划分为不同的节点。其包含的意思及操作的方法，将在接下来的章节中进行详细讲述。

　　一个好的架构，只有在应用中收到实际的效果后，方显它的价值，比如节省了多少测试时间或提高了测试的全面性等。

　　主动向他人提需求，是一种架构能力的体现，从而影响开发、需求，甚至其他用户、市场部门为测试部门服务。测试架构设计，需重视过程，它是个不断发展的过程。架构必须由经验丰富的设计人员设计，很大程度上依赖于过去项目的成功与失败的经验。但是正因世界上万事万物都在不停地发展变化着，软件开发的方法、模式、具体项目的要求也不同。随着过程中遇到问题的不同，需要做出快速响应，并进行合适的调整，从而提高架构的应用性，丰富它的内涵。提升它应用的高度与广度，为它画上更大的外延，这也是符合事物的发展规律的。

　　什么是SQA？相信不少同事都有着这样的疑问。SQA的工作价值体现在哪里？相信不少刚入行SQA同仁也有这样的迷惑。如何提升SQA的工作价值？我想工作多年的SQA依然有着这样的困扰。这里，我就第二、三个问题谈谈自己的想法。

　　当前，国内多数IT公司在项目管理上的组织架构，都是弱矩阵的组织形式，因此项目经理没有实际的行政权力。同时，他们有各自的工作，没有较多时间投入项目管理，例如：项目经理主要是由产品、业务、运营等角色担任，他们不是专职和专业的项目经理。

　　SQA（Software Quality Assurance）软件质量保证：基本职能是依据组织定义的流程，以独立第三方的角度，客观的对项目活动进行稽核和评价。如果该SQA出色的完成了基本工作职能，项目成员可能仍不知道SQA的价值体现。如SQA处理不当，甚至会引起项目成员的反感，他们认为SQA是来找茬的。即便项目在SQA的检查监督下顺利的完成，也会让项目成员感觉不到SQA的存在价值。

　　基于以上两个背景，SQA的衍生职能应运而生。

　　一、SQA是项目成员在项目管理上的导师

　　项目管理是每个SQA从业人员必备的专业知识，而流程则是将项目管理理念结合公司实际工作进行提炼。SQA在项目工作中，应以项目管理专家的角色，在项目管理上对组员进行指导，详细解释流程定义的活动，让成员知道做什么（what）、怎么做（how）、为什么（wh、y）。例如：工作量估算的方法、WBS的分解、进度计划的编制等。

　　二、帮助项目取得成功，协助项目经理共同管理

　　实际工作中，总结以下几点：

　　1、SQA要稽核项目工作，首先要了解项目工作并仔细阅读项目需求，每日及时跟进项目进展，SQA可以此来提升对项目的代入感，同时对项目成员提升SQA的存在感。这是协助管理项目的基础条件。

　　2、协助项目团队识别和管理风险问题，及时跟进风险问题解决情况，当风险问题不能在项目层面解决时，SQA以独立第三方的身份将问题上升到更高层面解决。

　　3、指出项目成员在流程上的错误，并告知错误工作可能存在的风险问题，按照流程给出正确的指导。由于SQA涉及项目众多，可以将其他项目曾经发生的问题作为案例，当项目成员再次发生类似违规操作时，可以提出曾经的案例作为反面教材，并告知可能的后果。SQA要让项目成员感到，我们是发现问题而不是找茬。

　　综上所述，SQA要提升其工作价值，必须做到两个衍生职能，即项目团队的导师和辅助项目管理。我认为，做好第一个衍生职能，能够提升项目成员对SQA的信赖，并更好的融入项目团队中。以此为基础再做到第二个衍生职能， SQA工作才能更好的体现SQA的工作价值。

　　（1）宽泛地讲，需求来源于用户的一些"需要"，这些"需要"被分析、确认后形成完整的文档，该文档详细地说明了产品"必须或应当"做什么。

　　（2）是用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。

　　（3）期望？！ 一种心理活动、笼统、不细致、不懂过程

　　需求的重要性

　　（1）Frederick Brooks在他1987年经典文章"No Silver Bullet"中阐述了需求的重要性：

　　开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。

　　（2）需求是产品的根源，需求工作的优劣对产品影响最大。

　　（3）国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。

　　了解客户、最终用户、间接用户的概念

　　（1）基本概念

　　"用户"（user）是一种泛称，它可细分为"客户"（customer）、"最终用户"（the end user）和"间接用户"（或称为关系人）。

　　掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。

　　（2）客户是掏钱买软件的人，所以他是"上帝"

　　（a）某饭店经理在解释"先有鸡还是先有蛋"这个哲学问题时，精辟地阐述了客户的地位：

　　如果顾客先点鸡，那么就先有鸡；如果顾客先点蛋，那么就先有蛋。

　　（b）"现代营销学之父"菲利普o科特勒所著的《市场营销导论》是这样描述客户的：

　　客户永远是本公司的座上客。客户并不依赖我们，而我们却依赖客户。客户不是我们工作的障碍，而是我们工作的目标。我们并不因为服务于他而对他有恩，他却因为给予我们服务于他的机会而有恩于我们。客户不是我们要与之争辩和斗智的人。从未有人曾在与客户的争辩中获胜。客户是把他的欲望带给我们的人，因此我们的工作就是满足这些欲望，从而使客户和我们共同获益。

　　（c）与客户打交道的主要目的是：一是获取需求，二是签合同。

　　软件需求的层次

　　（1）原始问题描述：对要解决问题的叙述，它是软件需求的基础

　　（2）用户需求：用自然语言和图表给出的关于系统需要提供的服务及操作的约束

　　（3）系统需求：是用户需求的映射。此时可开发一个简单原型以便给用户一个直观印象。

　　（4）软件设计描述：在系统需求的基础上加入更详细的内容，它是软件详细设计和实现的基础

　　需求工程的组成

　　把所有与需求直接相关的活动通称为需求工程。

　　需求工程的一些感悟

　　（1）不论是合同项目还是自主研发的产品，都必须开展需求开发和需求管理活动。

　　（2）开发者对待需求工程的态度可分"被动型"、"主动型"和"领先型"三种，只有后两种才有可能开发出成功的产品。

　　"被动型"是指开发者被动地对待需求工程中的各项活动，能少干则少干，能偷懒则偷懒。他们认为需求是用户的事情而不是自己的事情。开发过程中经常发生需求变更，导致产品迷失方向，不是半途而废就是陷入半死不活的状态。

　　"主动型"是指开发者积极地开展需求工程中的各项活动。他们把获取准确的需求当作自己的职责，会想尽一切办法克服需求开发和需求管理过程中的困难，而不是找借口推卸责任。俗话说"良好的开端是成功的一半"，"主动型"需求工程是开发成功产品的必备条件。

　　"领先型"是需求工程的最高境界。开发者发掘了连用户自己都没有意识到的需求，导致用户跟着新产品跑而不是新产品围着用户转，这叫引导消费。需求工程做到这个份上，才能使产品立于不败之地，长盛不衰。

　需求开发的主要困难与对策

　　···知识技能问题

　　（1）应用域的知识是无边无际的，任何人都不可能是"万事通"。

　　（2）当需求分析员缺乏应用域知识时，他该怎么办？

　　（a）首先他要有勇气做事，否则连实践的机会都没有。

　　（b）其次他应当赶紧补习应用域知识。

　　···态度问题

　　（1）相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为：

　　需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。

　　（2）用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。

　　（3）软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。

　　需求获取

　　需求获取时期的主要工作：

　　（1）归纳和整理用户提出的各种问题和要求；

　　（2）弄清用户企图通过软件达到的目的；

　　（3） 借助各种工具和方法，陈述用户提出的实际需求，并标定软件的作用范围。

　　最终目的弄明白要"做什么"。

　　获取需求应采用的步骤

　　（1）确定产品的不同用户类型

　　（2）确定用户需求的来源

　　（3）挑选出每一类用户和其他涉众的代表并与他们一起工作

　　（4）商定谁是项目需求的决策者

　　获取需求的方法

　　（1）明确最终用户，与用户交谈，向用户提问题。向用户群体发调查问卷。透过客户所提出的表面需求理解他们的真正需求。

　　（2）参观用户的工作流程，观察用户的操作。

　　（3）与同行、专家交谈，听取他们的意见。

　　（4）界面原型法，是指开发方根据自己所了解的用户需求，描画出应用系统的功能界面后与用户进行交流和沟通。

　　（5）可运行的原型系统法

　　（6）分析已经存在的同类软件产品，提取需求。

　　（7）从行业标准、规则中提取需求。

　　（8）从Internet上搜查相关资料。

　　    切记：

　　    设定用户代言人

　　    如果个别客户不能在需求方面达成一致意见，那么必须由用户代言人作出决策。

　　需求分析

　　（1）需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。

　　（2）分析方法大体有两类："问答分析法"和"建模分析法"。后者技术性比较强，写出来有学术味，故大多数软件工程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简单易用（保你一学就会），很有实用价值。

　　（3）采用方法：绘制关联图、创建用户接口原型、分析可行性、确定需求优先级、编写数据字典等。

　编写需求文档

　　（1）需求文档包括用户需求和详细的系统需求描述。

　　（2）要求

　　    正确：正确地反映用户的真实意图；

　　    清楚：易读易懂；

　　    无二义性

　　    一致

　　    完备：没有遗漏一些必要的需求；

　　    可实现： "可实现"意味着在技术上是可行的，并且满足时间、费用、质量等约束；

　　    可验证

　　    确定优先级：确定高中低三个级别，将风险降到最低。

　　    阐述"做什么"而不是"怎么做"

　　需求验证

　　（1）需求验证是为了确保需求规格说明准确、完整地表达了必要的质量特点。

　　（2）审查需求文档、依据需求文档编写测试用例、确定产品验收合格的标准。

　　（3）验证内容：有效性、一致性、完备性、现实性等。

　　需求管理的重要性

　　如果对已经建成的大楼不满意，要求设计师把大楼的结构调整一下，别人一定会认为这很荒唐。但在软件项目中，这样的事情很常见。

　　软件缺陷，发现和修复的越早则成本越低。不幸的是，需求阶段出现的错误往往很难发现，所以需求管理也需要讲究科学。

　　原则：需求必须分优先级、必须文档化、需求一旦变化就必须对需求变更的影响进行评估。

　　需求变更存在的必然

　　大师说："没有不变的需求，世上的软件都改动过3次以上，唯一一个只改动过两次的软件的拥有者已经死了，死在去修改需求的路上。"

　　变更管理

　　进行变更管理，首先要建立变更控制委员会，变更管理过程包括变更描述、变更分析和变更实现三个阶段：

　　变更描述：始于一个被识别的需求问题或一份明确的变更提议

　　变更分析：评估被提议的变更产生的影响

　　变更实现：执行变更，需求文档、系统设计和实现都要修改

　　变更描述阶段，产生需求变更请求表

　　变更影响分析

　　需求变更影响分析模板中包括的内容：

　　    变更请求号

　　    标题

　　    描述

　　    分析者

　　    分析日期

　　    优先级评定

　　    相关代价、收益与风险

　　    预计对进度、成本、质量的影响

　　    被影响的其他需求及任务

　　    要更新的计划及文档

　　变更控制流程

　　需求状态

　　定义：某时间点需求的情况反映。

　　客户需求的四种情况：

　　    客户可以明确且清楚地提出的需求

　　    客户知道需要做什么，但却不能确定的需求

　　    客户提出需求，但需求的业务不明确

　　    客户自己也说不清楚的需求

　　需求状态：

　　已建议   已批准  已拒绝

　　已设计   已实现  已验证

　　已交付   已删除

需求文档版本控制

　　对于开发人员来说，最为沮丧的事情莫过于当软件功能实现后，却发现该项功能已被项目经理取消了。原因在于需求文档版本混乱，开发人员没有得到最新的软件需求。

　　需求跟踪

　　目的：建立和维护从用户需求到测试的一致性与完整性，确保实现都以客户需求为基础，实现的需求覆盖了预期的需求，并确保输出与用户需求的符合性。

　　需求跟踪的作用

　　（1）在需求验证中，便于确保所有需求被应用

　　（2）有助于变更影响分析

　　（3）便于需求的维护

　　（4）便于测试时找出问题所在

　　（5）便于项目跟踪和减少项目风险

　　（6）简化了系统再设计，易于软件重用

　　案例分析：一个项目需求分析和处理的案例

　　1、 案例背景

　　当地一家销售电动工具公司的董事会成员正在举行二月份的董事会会议，这家公司是一家专门制造和销售用于木工用的"黑客"牌电动工具的一家小型公司。会议室里在座的，有董事会主席贝斯·史密斯（Beth Smith）和两个董事会成员罗斯玛丽·奥尔森（Rosemary Olsen）和史蒂夫·安德鲁（Steve Andrews）。贝斯首先发言："我们今年以来的销售非常好，打来的订货电话，已经要把我们的电话都要打爆了，但是，我们没有办法能继续招募到熟悉我们的电动工具、同时还了解我们销售过程的小姐。而与我们竞争的其他公司，都已经上了自动客户服务系统（Call Center）。所以，我们也要上这个系统，才能保住我们的市场。"

　　"我们必须建立一个计算机自动客户服务系统。"罗斯玛丽响应道。

　　史蒂夫建议："难道我们不能把售后服务转给麦肯罗公司（公司下属的一家子公司，以服务为主）做吗？向他们要求一下，看他们是否能把电动工具的服务也接过去？"

　　"他们也紧张，听说明年他们甚至可能会削减一些服务项目。"贝斯回答。

　　"我们需要多少钱才能搞这么一个系统？"罗斯玛丽问道。

　　"大约10万美元，"贝斯回答，"如果我们不能在两个月后就开始启用这个系统，估计我们的定单可能会减少20%。"

　　"我们除了钱还需要很多东西。我们需要了解是否有更好的方案、开发这个系统需要多少时间，以及，这个系统是不是真的适合我们！"史蒂夫说。

　　"哦，我想我们完全可以自己来做这个项目，这将是很有趣的！"罗斯玛丽兴奋地说。

　　"这个项目不是我们的专长，我们不可能及时完成。"贝斯说道。

　　罗斯玛丽回答说："我们有几个技术人员，虽然不够，但只要再招聘一二个高手，就可以解决它，并且做好。"

　　"项目是我们真正需要的吗？我们上了这个项目以后，公司的销售任务就能完成了吗？"史蒂夫问道，"此外，我们正在经历一个困难时期，我们的资金并不宽余。或许我们应当考虑一下，我们怎样能用较少的资金来运作一切。例如，我们用这个系统只处理定单，而并不包括服务，。这样系统是不是就会小一点，也省一点、快一点？"

　　罗斯玛丽插话说："多妙的主意，我们可以先完成销售定单的处理，等这部分完成投入使用后，再开发服务部分。公司可以在改进销售功能的同时，继续开发服务功能。这样，我们就可以做得更好。"

　　"好了，"贝斯说，"这些都是好主意，但是我们只有有限的资金和技术人员，并且有一个增长的需求。我们现在需要做的是，确保我们在两个月后不必担心丢失定单。我想，我们都同意必须采取行动，但是不能确定我们的目标是否一致。"

 　2、案例习题

　　（1） 项目目标是什么？

　　（2）已识别的需求是什么？

　　（3）如果有的话，准备开发的项目应具备什么样的假定条件？

　　（4）项目牵涉到的风险是什么？

　　3、案例分析

　　根据本案例的背景，我们的分析简单描述如下。由于本案例比较简单，而且是自主开发，因此，有些内容可以简略。至少必须描述的内容，用下划线表示：

　　（1）业务需求

　　1、背景：一家小型的木工电动工具公司，今年以来的销售形势很好，接受定单的电话很多，已经忙不过来了。因此，需要开发自动客户服务系统。

　　2、项目机遇：通过自动客户服务系统的开发和投入使用，使公司的销售获得增长。

　　3、项目目标：开发一套为本公司销售和售后服务使用的计算机自动客户服务系统（Call Center）。

　　4、市场需求：

　　5、客户价值：满足公司自身发展的需要。

　　6、项目风险：项目目标、方案、时间、资金、开发人员等。

　　（2）方案描述：

　　1、功能视图：自动接听电话，对客户的定单和售后服务要求做出响应。

　　2、主要特征：自动处理一些原来由人工完成的工作，有可能增加新的服务功能。

　　3、假设和依赖：二个月时间内完成，总投资为10万美元，自主开发，自己使用。

　　（3）范围局限

　　1、首次发行范围：

　　2、随后发行范围：

　　3、局限和专用性：只为自己公司使用。

　　（4）系统环境：

　　1、用户概貌：

　　2、项目优先级：可以先完成定单响应，再完成售后服务功能。

　　（5）成功因素：

　　我们现在完成的，实在需求获取阶段中介绍的"项目视图"中的内容。在项目视图中，我们对项目做了初步的描述。在背景和目标分析阶段，我们回答本案例问题的答案是：

　　1、项目目标是什么？

　　答：开发一套为本公司销售和售后服务使用的计算机自动客户服务系统（Call Center）。

　　2、已识别的需求是什么？

　　答：自动接听电话，对客户的定单和售后服务要求做出响应。

　　3、如果有的话，准备开发的项目应具备什么样的假定条件？

　　答：二个月时间内完成，总投资为10万美元，自主开发，自己使用。

　　4、项目牵涉到的风险是什么？

　　答：项目目标、方案、时间、资金、开发人员等。

　　系统的功能包括：

　　1、从公司的客户方面看，新系统可以自动支持电话、FAX，E_mail、Web等多重通信方式所提供的服务，最大限度的满足客户的需要，最有效地为客户提供快捷方便的服务。

　　2、从公司方面看，新系统要可以支持接入公司的交换机中继线路（24条中继），自动或智能话务分配、坐席画面与电话同步、自动录音等功能。

　　3、从提供服务的内容看，可以有：公司产品查询、合同和定单查询、自动处理定单、产品售后服务信息查询、供货信息查询、方案介绍、产品推介、产品报修、故障咨询、投诉等。进一步的购买洽谈，可以转人工处理。

　　4、整个系统可以与目前公司已经有的客户信息系统、产品信息系统等建立联系，形成综合的服务系统。

　　国外收费软件，价格昂贵（几十万）

　　难于找到破解版和序列号。

　　功能强大，主要用于管理变更（需求、缺陷等）与其他Rational 产品集成,特别是ClearCase.

　　支持的数据库:SQLserver ,Oracle,Access.

　　产品模式:C/S,B/S结构,web服务器需要另外安装.配置较为复杂.

　　其他功能强大．

　　URTracker:

　　国产软件，价格低/每用户￥50．（试用版１个月，试用版后免费５用户）

　　容易下载．

　　系统需求：

　　Windows2000/xp/2003

　　IIS5/6

　　.Net Framework1.1

　　SQL Server2000 / MSDE 2000

　　优点：操作简单，界面友好，容易上手．满足缺陷追踪的功能．

　　缺点：查询功能相对较弱，不能自己订制，报表功能也较弱．

　　产品模式：B/S 结构

　　Bugfree:

　　国产开源软件，免费．

　　容易下载．

　　系统需求：MySql+PHP+Apache

　　优点：流程清晰，能完整的记录Bug解决的流程，可自定义配置。

　　缺点：熟悉PHP。

　　产品模式：B/S结构

　　Bugzilla:

　　国外开源软件，免费

　　容易下载

　　优点：满足缺陷管理功能．比较出名的开源软件。

　　缺点：Windows平台配置较为复杂，用户界面差．

　　产品模式：B/S结构．

　　支持数据库：Mysql

Mantis:

　　国外开源软件。

　　轻量级的缺陷跟踪系统

　　优点：Mantis相对Bugzilla有更好的操作界面。

　　第二、安装和使用都相对简单一点。但比其他软件稍复杂。

　　而对于一般的项目，Mantis作缺陷跟踪，已经绰绰有余。

　　缺点：界面梢差，目前的版本还存在一些问题。

　　产品模式：B/S

　　系统需求：PHP+MySql

　　TestDirector:

　　国外收费软件，价格昂贵（几十万）

　　优点：用户界面友好，功能强大,安装简单，与LR,WR集成，有多种主流case工具接口AddIn.

　　集成了测试需求管理、测试计划和用例管理、测试日程控制、测试执行和缺陷跟踪等功能

　　强大的统计分析功能

　　缺点：由于其早期版本不能灵活的对项目管理流程进行配置，又由于其昂贵的价格，因此目前

　　应用的企业也不是很多。

　　TD更侧重于测试过程管理

　　支持数据库：Oracle,SQLserver,Access

　　产品模式：B/S结构

　　JIRA

　　国外收费软件

　　采用J2EE技术，JIRA 是目前比较流行的基于Java架构的缺陷跟踪系统。

　　优点：界面友好，JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。

　　安全性、可扩展性方面发挥到了极致

　　系统需求：运行于所有的安装了JDK的操作系统上，并能够跟几乎所有的兼容JDBC的数据库一起使用

　　JIRA更加侧重于缺陷追踪和项目管理

　　BugZero

　　5用户版，100条记录免费。

　　TestTrack Pro:

　　Seapine公司的

　　（1）组织架构中QA团队误区：

　　在不少公司，基于成本考虑，缺少了真正的高素质的质量保证人才，这其实是管理层的意识问题，认为设立QA岗位，人才的招聘、培训、薪酬、福利、工作环境的消耗将是一笔不小的成本支出，根本没有必要，实际上是一个不好的作法。组建QA团队，确实是需要一笔费用，如果是高水平的团队，付出费用更大，但从长远来看，这笔费用肯定可以从将来产品质量的提升、成本的降低、进度的提前、客户满意度提升、市场占有率等方面获取丰富的回报。一个质量管理优秀的公司，所获得的收益远远超过了QA团队的人力成本。

　　（2）“进度优先还是质量优先”误区？

　　实际上要根据公司的商业目标来确定，如果项目进度是十万火急的，不能按时交货，可能就会遭受严重经济损失或失去生存机会，我想肯定的选择是公司的生存第一，在进度保证的前提下，再考虑质量保证。但在一些业界优秀的公司，进度已经往往作为质量的一部分，进行综合平衡考虑和解决。

　　（3）QA团队的“选人”误区：

　　曾看到一些公司，为了通过CMMI评估，都成立了QA组织，但是选人的标准也是基于成本考虑，往往是一些刚毕业不久的大学生，由于缺乏足够的开发和项目管理经验，在项目的流程执行中，不能给予项目团队有效的指导，不能识别公司的商业目标的价值，只能机械按照过程体系的要求执行，造成项目团队的不信任，甚至引起严重对抗，从而破坏了和诣、开放的卓越团队文化。在一些跨国大公司，其实QA的标准要求是很高的，要有多年的项目开发管理经验，甚至是曾担任过资深的项目经理优先，只能这样，才能够深该理解公司的商业目标和过程体系，并可以作为导师或顾问有效识别、规避项目风险、指引项目团队前进的方向。

　　（4）QA团队的“定位和运作”误区：

　　QA团队并不能只作为高高再上的检查者，或者只定位为“警察角色”，更应该是作为服务者的角色出现，QA团队是必须为项目团队服务的，要有一颗“谦虚”的心，要做到能换位思考，要能站在管理层和项目团队的角度来考虑问题，我想这样就会明白QA团队的价值和意义。

　　QA团队核心工作是推动过程改进、进行缺陷预防，实现公司商业目标 ，因此QA团队最重要的是要明白流程的价值，由于所有流程是基于一定的环境或条件建立的，对不同项目可能作用都不同，甚至可能不适用，要能够从公司全局出发，根据成本、进度、质量、客户满意度等条件进行判断，给项目团队提供帮助，进行过程裁剪，并提供给管理层高价值的真实项目情况，成为管理层真正的“眼睛和耳朵 ”。只有这样，QA团队才能取得管理层的支持，质量保证意识才能融入并扎根于公司卓越企业文化之中。

　　条件：

　　缺陷管理

　　首先正规测试团队至少会有一个缺陷管理系统，不管是Bugzilla还是Mantis 或是其它系统，因为软件测试过程本身就是围绕着缺陷进行的，这也是测试工作的一个重要组成部分。我个人还是比较青睐于使用开源工具。

　　测试用例谁来写

　　我不提倡测试新人去写测试用例，这些工作应该分配给那些经验丰富的测试人员去做。新人写测试用例存在一定量的风险性，例如考虑不周达不到预期覆盖率，延缓测试周期和上线时间。

　　Bug有owner

　　对于Bug来说，测试人员开启的Bug应该由本人来关闭。做到Bug也要有属主

　　测试工作量评估

　　测试工作量应该由测试人员本人估算，从下到上估算工作量，而不是从上到下分派工作量，如果遇到工期固定可以简化测试用例，测试分轻重

　　Bug描述

　　Bug一定要做到描述简洁清晰争取做到PD 一看就懂，减少不必要的交流。对于不容易重现的Bug可以清晰的描述操作步骤和具体操作时间产生什么类型的错误。通过以往工作经验个人认为没有不能重现的Bug。

　　开发人员对测试人员的测试结果产生疑议。如果测试人员根据自己的测试经验判定是个Bug，可以先组织测试人员内部进行缺陷讨论。判定Bug的严重级别后再进行相应处理。有不同看法是正常的，但是不要轻易妥协。

　　不要浪费测试人员时间。测试人员接到测试任务拿到需测试产品发现低级错误的数量以及功能的不完整性，有权退回。这是在浪费测试人员时间。

　　测试人员不要过于依赖测试工具

　　测试人员对测试工具的完全依赖是一种不好的做法，不要忘了最强大的是你的测试思想，在必要的场合采用工具确实能给测试人员带了意想不到的收获但是这只是一种测试手段不能代表测试的全部，如果需要使用工具，我建议往开源方面靠拢。

　　让测试人员了解产品背后的商业意义

　　整个项目中什么功能模块是最重要的，为什么要开发这个新功能，这个功能在整个项目中有何种意义，这可以让测试人员对该功能产生一个内心重要级别。对测试用例和以后的回归都起到很大帮助。

　营造测试气氛

　　开发人员开发完功能后需要自测，然后再交送给测试人员，共同把好质量关。开发可能会说我写出来的东西我自己还要测试那还要你做什么。如果开发的产品连正常流程都无法跑通就交给测试被一次一次的打回，这样不光影响项目进度，还可能会导致该测试人员会你开发出的产品有情绪抵触，质量很难得到保证。

　　测试技术学习

　　测试团队可以定期拿出一个课题由部分专人负责研究，然后定期Share研究成果组织团队人员研究讨论，促进工作学习两不误。

　　测试人员不够

　　如果碰到时间紧任务重测试周期被缩短的情况。我不建议省略写测试计划，测试用例，测试报告去闷头测试。测试可以分轻重，可以申请安排开发做辅助测试。也不能省略那些书面文字。不是走形式。测试人员要彻底认识到这些东西是非常有价值的，在适当时候可以保护你。

　　先写测试用例再测试不是死规矩。事实上应该是这种工作流程，但是有些时候当没有测试用例思路时，可以先手工运行一遍功能，想到什么写什么，最后形成完整规范测试用例。做到灵活测试。

　　测试人员有义务向PM阐述对功能的流程以及易用性方面自己的想法。如果是为了功能的可伸缩性那就不仅仅是测试人员需要参与讨论有可能还有PD OP DB等等。最初目的是为了以后如何更方便的开展自动化。让自动化能覆盖的更多更全面。

　　为了保证产品质量测试越早进行越好。不仅是功能测试，其中也包含性能。

　　了解当前产品质量

　　测试人员每个人都应该了解当前产品质量，知道哪块薄弱，知道自己该干什么，提倡每个人都可以提出建设性意见。

　　开发人员告诉测试人员你应该如何测试。

　　这种现象可以从多方面理解：

　　1、作为测试人员你做的不够好，长时间来你充当一个喊话筒的角色，从你以往提交的Bug来看没有任何深度。想受人尊敬受人重视还是要靠自己踏实争取。

　　2、测试团队不规范，或者说根本就没有测试团队。让开发领着干活自己又不会写代码心理不好受抱怨多多。

　　更多时候还是需要自己多努力，知识要靠一点一滴的积累。很难重现的Bug你能重现，能告诉开发哪块功能将来可能产生问题，指出系统瓶颈等等类似很多。这些都是需要经验积累。渐渐的你会发现自己在团队中起到了应有的价值得到同事以及上司的认可。

　　测试环境维护

　　测试环境由谁来维护其实我觉得并不重要，这里指的谁可以是运维可以是研发可以是QA，但是最好要保证专人来维护，不要谁都可以插手。再没有打招呼的前提下擅自发布新功能或者修改是不可取的。保证版本的统一性很重要。要做到正式发布功能之前OP可以在测试环境下抓取项目整包进行发布。当然对于极小功能小修改可以例外。

　　收集需求文档

　　测试人员为了写出一份还算完整的TestCase东奔西跑到处收集信息。开发文档和产品需求文档出炉后请第一时间送交的QA 手里，保证QA的工作开展。

　　1）数据不准

　　比如：

　　？ 对于评审的会议，评审的参与人有的是来学习的，在统计人数、工作量时就不应该统计在内。

　　？ 有的数据当时没有采集，而是靠时候回忆采集上来的。

　　？ 有的代码行数不是通过工具统计上来的，而是靠人估计估计出来的。

　　2）过程不稳定

　　过程不稳定的原因可以细分为：

　　i）过程太大

　　比如：对于整个项目的工期偏差率建立回归分析模型，由于影响因子太多，每个因子都有影响，但是影响都不是很大，这样对于采集数据的要求，过程的稳定性等要求很高，很难建立起回归方程，因此此时需要划分项目的阶段建立每个阶段工期偏差率模型或者不去细致的分析影响因子，而是建立蒙特卡罗的模拟模型，或者分不同类型的项目建立回归方程。

　　ii）过程定义不稳定

　　在过程定义中定义的不够细致，对于过程成功的要点没有定义清楚，比如：

　　对于评审的流程，为了保证评审过程的稳定，应该要求：

　　● 评审的时长不能超过2小时。

　　● QA跟着每次评审控制会议不要过多讨论。

　　● 会议开始是要声明规则。

　　● 评审会与讨论会要分开。

　　iii）过程执行不稳定

　　在流程定义中有要求，但是实际执行时没有做到位，比如：

　　● 开评审会的时候进行了大量的讨论比如设计的评审会，所以会议的工作量、会议的时长都不准。在设计会议上讨论了设计方案的合理性。

　　● 会议的时间超过了2个小时，4个小时的评审会议，后边的2个小时效率很低的。

　　● 会议的主持人在会议上没有讨论的现象进行控制。

　　iv）过程的输入不稳定

　　不同的项目在执行过程时，投入差别太大，过程执行的前提条件不稳定，导致过程的输出也会不稳定。比如：测试过程投入的单位工作量，有的项目投入的多，有的项目投入少，而如果这些输入没有被识别出来作为因子的话，则方程就无法建立起来。

　　3）影响因子（X）识别不全

　　● 在识别对于Y的影响因子时没有识别出来关键的影响因子，比如测试过程的单位规模的测试工作量等；

　　● 识别了关键影响因子但是不好量化表达，采集数据有难度，比如人员的技术水平；

　　● 采集了关键因子的度量数据，但是数据不全，缺少样本点；

　　影响因子的识别需要经验识别，也需要统计的假设检验，也可以进行实验设计。

4）对于大过程建模，影响因子太多，每个因子相关性都不大

　　如果是对于大的过程建模，则可能存在如下的问题：

　　● 影响因子多，每个因子的相关性都不是很大；

　　● 影响因子多，采集数据有难度，对每个数据都要求很准确；

　　● 影响因子之间彼此有交互叠加的作用，有相关性，建模困难。

　　5）样本量太少

　　样本量太少，增加或删除一个样本对回归的结果影响很明显，则规律不具有典型性。比如，在下图中如果删除右上角的一个点，则两个变量之间就没有相关性了，如果删除了右下的2个点则两个变量之间就是相关的。之所以出现这种现象就是样本点太少而导致的。

　　6）样本不随机

　　比如有2个变量X1，X2与Y都应该是正相关的，但是在实际中存在的数据却是：

　　此时如果对这些类型的数据进行分析，则表现出来Y与X1，X2是不相关的。

　　以测试过程为例，我们的经验与常识：

　　假设或常识1：高水平的测试人员找出的BUG多， 低水平的测试人员找出的BUG少。

　　假设或常识2：高水平的开发人员犯的错误应该少，低水平的开发人员犯的错误应该多。

　　我们的实际数据：

　　在实践中常常采用的策略：

　　策略1：关键的模块应该由高水平的开发人员进行开发，非关键的模块由低水平的开发人员进行开发。

　　策略2：高水平的测试人员要测关键的模块，低水平的测试人员测试非关键的模块。

　　如果是这样，对于测试过程做了度量以后，数据无法证明假设1和2的成立。

　　以上六个原因就是最常见的原因，这些原因在实际中克服起来并非那么容易，这也是为什么4-5级需要比较长的实施周期的原因。

　　相信大家看了零基础学习SVN之（一）：SCM与SVN的使用（基础篇）这篇博客之后，对版本控制就有了一定的理解，同时也应该知道SVN与CVS是比较流行的两款SCM工具。那么到底这两款工具有什么区别呢？

　　1、版本编号方面

　　例如，我们的版本库为A，其中有文件a，b，c。

　　在SVN中，新版本的版本号不是针对某个特定文件的，而是针对整个库而言的。提交了5次和提交了6次，文件a有可能不同，也有可能相同，即1.0版和1.1版可能相同。因为第6次提交有可能是因为文件b或c进行了修改。而在CVS中则相反，每次更新可能只对文件的版本号进行修改，即a文件的1.0版和1.1版是肯定不同。

　　（在这里纠正一个概念，“文件a的第2版本”这个说法是错误的，应该是“文件a的第2次修改，即第二次Commit”）

　　SVN的全局性版本编号为SVN带来了诸多的优势：如对目录或文件执行拷贝，无论涉及多少文件，SVN不需要对单个文件依次执行拷贝命令，仅仅需要建立一个指向相应的全局版本号的一个指针即可。

　　2、目录的版本控制

　　CVS只能对文件进行版本控制，不能对目录进行版本控制，这就导致CVS失去了很多功能：

　　1）没有移动操作

　　CVS里没有移动（move）这个操作，当人为进行文件移动操作时，CVS只能注意到，一个文件在一个位置被删除了，而在一  个新位置创建了另外一个文件。由于它不会连接两个操作，因此也很容易使文件历史轨迹丢失。所以使用CVS时，每个文件的位置一定要谨慎的选择。

　　2）没有重命名操作

　　CVS里没有重命名（rename）这个操作，人为的对文件进行重命名会使得命名前后的文件失去历史联系，而记录历史本来是版本管理的主要目的。

　　3）没有拷贝操作

　　CVS中没有拷贝（copy）这个操作，人为的拷贝对CVS而言，只能看到新的文件的增加，而不能记录拷贝源文件和目标文件之间的联系。

　　而SVN从很大程度上避免了这些不足，SVN将目录作为一类特殊的文件来处理。当目录中的子目录/文件被删除、重命名、或新的子目录/文件被创建时，目录的内容将发生改变。因此，SVN象记录普通文件的修改历史一样记录对目录的修改历史，当发生文件/目录的移动、重命名或拷贝操作时，SVN能够准确记录操作前后的历史联系。同样，像对文件的不同历史版本进行比较一样，SVN支持对目录的不同历史版本的比较，清晰展现目录的变化历史。

　　3、原子性提交

　　CVS和SVN同样作为SCM版本控制管理工具，SVN的原子性提交可谓是技高一筹啊！

　　SVN提交文件，只有当全部文件修改都成功入库，该提交才变得有效。一旦中断，SVN将会自动执行“回滚”（rollback）操作。SVN 这种机制保证所有的修改要么全部入库生效，要么一个也不入库。由于SVN的原子性提交特性和全局版本编号方式，当提交成功完成时，一个唯一的、新的全局版本编号产生，而提交时用户提供的日志信息与该新的版本编号关联，只进行一次存储（区别于CVS的按文件重复存储）。

　从事软件质量保证工作已有几个年头，经常有朋友问起软件质量保证到底是干什么的？每次总回答就是辅导和监督项目开发按照公司研发过程执行的，仔细想想实际并没有这么简单，为了让更多朋友了解质量保证这个岗位，在此结合这几年的工作经验进行如下总结，若有不对的地方欢迎大家指正与交流，谢谢！

　　1、什么是质量保证？

　　在CMMI中，质量保证的英文全称是Process and Product Quality Assurance，即过程与产品质量保证。一般大家更习惯叫质量保证或QA，它的目的是为员工和管理层提供过程和相关工作产品的客观洞察。之所以说它客观是因为：

　　1）质量保证人员是一个独立于项目组之外的第三方审计人员，不能是直接参与开发、测试和项目管理的人（当然实际也有例外，有些公司QA可能是兼职的）；

　　2）质量保证人员不受监督对象部门的绩效评价；

　　3）质量保证人员具有独立的问题汇报渠道（可以跨级上报——QA很重要的特权）。

　　2、软件质量保证工作内容？

　　一般设有软件质量保证岗位的公司都有一套依据自己公司实际研发现状制定的完整研发过程体系，所有的软件质量保证人员入职一家新公司，首先需要做的事情就是学习和深刻了解该公司研发过程体系，否则后续工作是无法开展的。

　　一般软件质量保证工作内容主要分三大块：

　　1）过程辅导

　　依据研发过程体系辅导所有开发项目/版本前期及项目过程各个环节及各环节具体活动执行（含流程、方法、模板及过程中相关工具的使用）。

　　辅导时机：

　　● 到达项目/版本计划中计划的时间点

　　● 触发事件驱动（如：邮件）

　　辅导方式：

　　● 口头

　　● 邮件

　　● 电话

　　● 通讯工具（如：QQ、RTX等）

　　● 必要时可以开展正式的课堂培训（一般很少）

　　2）过程检查

　　所有开发项目/版本开发过程中，依据当前的研发过程体系客观的对实际执行情况进行检查与评价。

　　检查的方式：

　　● 参加项目会议（评审会、周会）

　　● 与各个环节人员沟通

　　● 触发事件驱动（如：邮件）地进行检查

　　● 检查工作产品

　　测试的角色（Test）要独立出来么 ？

　　独立出来的测试角色怎么才能发挥作用？

　　有些成功人士和成功的公司号称没必要有独立的测试角色（Test），你怎么看？

　　最近又看到一些关于开发人员要不要负责测试的讨论。例如：

　　http://www.51testing.com/html/94/n-807994.html

　　大多数的开发团队并不需要一个独立的测试角色。即使有一个，他的所有的开发时间比上所有的测试时间应该>20：1。

　　我正好在写相关的教案，也来凑个热闹。

　　[这篇文章的一些事例来自于我曾经和现在的团队。希望这些例子不足以影响相关人物和团队的伟大形象。任何软件团队都会犯错误，伟大的团队有勇气面对自己的错误并不断改进。]

　　首先，明确两个概念：

　　软件测试（Test）：运用定义好的流程，工具去验证软件能实现预先设计的功能和特性，工作的流程和结果通常是可量化的，例如，测试用例，bugs，代码覆盖率，MTTF，软件效能的参数。[注：正因为流程和结果是可明确定义的，可量化的，很多测试工作可以自动化]

　　软件质量保证工作（QualityAssurance）：软件团队的成员为了让软件达到事先定义的质量而进行的所有活动，包括测试工作。

　　对于这两个术语，不同人有不同的定义，有人认为它们是互通的，在《现代软件工程》的上下文中我尽量使用上述的定义.

　　测试的角色（Test）要独立出来么？

　 　回答：首先，我相信有分工是好事，软件团队中应该有独立的测试（Testing）角色。所有人都可以参与QA的工作（报告bug什么的），但是最后要有 一个角色对QA这件事负责。不但角色要独立，而且在最后软件发布的时候，必须得到此角色的签字保证（signoff）。我在微软参与的项目都是这样做的。

　　在开始论证之前，先引用斯密特·亚当斯的《国富论》来暖场（我没读过这本书，直接从网上抄的）。

　　分工理论

　 　亚当斯认为，分工的起源是由人的才能具有自然差异。…假定个人乐于专业化及提高生产力，经由剩余产品之交换行为，促使个人增加财富，此等过程将扩大社会 生产，促进社会繁荣，并达私利与公益之调和。他列举制针业来说明。“如果他们各自独立工作，不专习一种特殊业务，那么他们不论是谁，绝对不能一日制造二十 枚针，说不定一天连一枚也制造不出来。他们不但不能制出今日由适当分工合作而制成的数量的二百四十分之一，就连这数量的四千八百分之一，恐怕也制造不出 来。”

　　分工促进劳动生产力的原因有三：第一，劳动者的技巧因专业而日进；第二，由一种工作转到另一种工作，通常需损失不少时间，有了分工，就可以免除这种损失；第三，许多简化劳动和缩减劳动的机械发明，只有在分工的基础上方才可能。

　　我们看团队形式的职业体育比赛，各个位置的分工都很明确，拿足球来说，有专注进攻的，有专注防守的，但是在我的印象中，那些伟大的前锋大多数只管一件事-进攻。亨利（ThierryHenry）参加防守么？

　　当然一些球赛也有没有分工的时候，原因有好几个：

　　事太小，几个小孩踢个半场。

　　无知，小孩们刚开始玩球。

　　人手不够，一对一打篮球，你要参与防守么？沙滩排球，两人都是全攻全守。

　　如果你的软件团队做的事情和上面的情况类似，那当然不必分工。你们做的很可能不是商用软件，你的软件团队大概也不用受什么软件工程规律的束缚。

　　任何产业产业成熟到一定阶段的时候，独立的质量保证角色是不可避免的。团队内部有QA角色，团队外部也有独立的QA角色。

　　拿药品和食品来做例子，除了生产厂家自己的检测之外，这些产品还要接受行业主管部门相关机构的检测和认可（药品检验，食品检验），才能上市。在出现争议的情况下，还要第三方机构来进行测试或认证。

　　设计是用户需求到编码实现的必经阶段，软件项目在设计阶段的禀赋决定了软件项目的资质。好的软件设计不是软件项目成功的唯一条件，但是没有好的设计软件项目肯定无法做好。

　　一、软件设计的重要性体现在以下几个方面：

　　1、软件设计在整个软件项目的建设中起着承上启下的重要作用。

　　从整个软件项目开发阶段来看，软件项目可以分为需求、设计、编码、验证四个阶段。设计承接需求分析，基于准确的需求分析，对项目目标进行结构化搭建。设计阶段产生的设计说明书以及设计规范是编码阶段的作业指导，也是测试人员开发测试用例的指导书。

　　2、软件设计是对软件项目质量进行保障的关键步骤。

　 　软件项目的质量与需求分析、设计、编码、验证段这四个阶段的质量之间的关系，可以用C语言表达为：最终的软件质量 = 需求分析质量 && 设计质量 && 编码质量 && 验证质量，这种“与”的关系表明任何一个阶段出现质量纰漏，软件项目的最终质量都无法保障。

　　3、设计阶段提供的软件表示，使软件项目质量的评价成为可能。

　 　反映软件设计质量的要素有：准确性、稳健性、安全性、通信有效性、处理有效性、可操作性、完备性、一致性、可追踪性、可见性、可扩充性、复用性、模块 性、清晰性、自描述性、简单性、结构性、硬件系统无关性、软件系统无关性、文档完备性等。通过这些考核要素对设计阶段质量进行控制，从而达到从项目前端控 制软件质量的效果。同时该阶段的设计规范也是进行软件质量评价的参照标准与基本要求。

　　因此，想做好整个软件项目的质量保障，必须充分重视设计阶段的质量保障工作。山东省软件评测中心作为国内最早一批获得国家实验室认可并取得政府授权的中立的第三方机构，在十余年的软件项目质量服务过程中发现：

　　二、设计阶段经常出现的质量问题从大的方面看有以下几种原因：

　　1、需求分析阶段工作不充分

　 　好的软件设计必然基于准确的需求分析，离开正确的需求分析，软件设计就是做得再好，在源头上也是错误的，更无任何意义，有时甚至是南辕北辙。有些软件项 目因为工期紧张或乙方软件企业管理不规范，甲方用户人员技术受限或配合不到位或承建方需求分析人员业务、技术经验不足等这样那样的原因，需求调研没有做 透，更有甚者基本的业务逻辑还没有完全理清，就匆匆开始需求分析然后又囫囵吞枣的进行自我想象中的架构设计，结果可想而知。

　　2、设计不充分

　 　有许多软件企业不重视设计阶段的工作，或者略掉设计直接进行编码。这样必然把许多的问题遗留给编码阶段，等写了一部分代码后再后头看，错了，返工……另 外，设计人员由于技术欠缺或经验不足，或者对业务理解不够深入，未能充分考虑后期需求变动对设计的影响也是造成设计不充分的一类重要原因。

　　设计不充分往往导致频繁变更与诸多性能、安全方面的漏洞。在软件项目里，越是在项目前期发现问题，解决成本越低。据相关机构统计，在设计阶段发现偏差比在需求分析阶段发现并修正要高出5 倍，在编码阶段觉察偏差则会提高到10倍，而如果延续到单元测试或系统测试阶段发现设计缺陷修正成本则会提高到20倍。另外，设计人员由于技术欠缺或经验不足，或者对业务理解不够深入，未能充分考虑后期需求变动对设计的影响也是造成设计不充分的一类重要原因。

　　3、过度设计

　 　与设计不充分相对应的一种情况是设计过度，过度设计一般是由于设计人员在做项目分析设计时，过分的考虑潜在的、未来的以及准备扩展等因素，过度的抽象， 过多思考封装、分离解耦，导致太多颗粒单位，太多插件等等，给设计资源造成不必要的浪费，并且可能导致原本可以简单实现的逻辑变复杂，造成系统整体性能的 下降与维护成本的上升等等，以至于影响到用户体验或者简直没法用。

　　上述情况都会造成软件设计质量的下降，那么我们应该如何做好设计阶段的质量保障工作？

　　Q（ amandating ）：

　　看着大家丰富的阅历和工作履历，以及职业前景的广阔，不禁想起自己可怜的履历。

　　没有开发背景的硕士（还不是computer专业而是communication专业），工作直接做了测试，接着做QA，现在兼职做EGP成员。

　　想问问专家，指点一下，最佳发展道路是？难道一直做QA？

　　同时说明一下发展道路上所需的资质，多谢了

　　A（ lilyli ）：

　　我的学历不及lz，但是工作经历上多了开发和项目管理两个阶段，这两个阶段的工作经历对于我做QA的帮助还是很大的，因为我可以结合我的项目经历，站在PM的角度和开发工程师的角度看问题，开展符合项目情况的质量管理活动。

　　个人认为QA是比较富于挑战性的工作，具备了项目开发知识还不够，还需要在软件工程、沟通能力、工作方式方法上做提高，才能帮助QA工作更好的开展。

　　发展的道路没有最好的，只有最适合的。如果你喜欢QA工作，那就做下去，兴趣会使工作变的更愉快

　　A（steplv）：

　　关于楼主问的问题，我略谈一下自己的浅见。

　　你问的是QA的职业发展道路与所具备的资质，在这里，我不想扯远，就这两点，我大体谈谈自己的看法。

　　1、一直走QA这条路

　　如果单纯要走QA这一条路，要具备什么素质，我曾经写过一篇文章《浅谈QA所应该具备的知识》（在本网站中的地址是：http://www.51testing.com/html/32/n-78432.html）， 这里面有详细叙述，这里不再多说。但如果说QA这一条路的发展，个人认为，随着中国软件企业越来越多的走出去（做外包或者其他），势必需要具备国际认可的 标准与规范，就跟“Made in China”这个品牌一样，需要接受国际环境的挑战，那么， 作 为行业的发展，QA将来一定会有所作为的，就跟现在PM的价值一样，只是体现方式不同而已。所以，一定要相信，QA这个行业在将来一定会有所发展并初具规 范与规模，当初本人选择这个行业也是在无形中看到了这点。毕竟社会是进步发展的，QA这个行业也是一样，需要发展，可能只因我们现在处于初级阶段，所以会 存在太多的困扰，但正因为有这些困扰，所以才需要我们去解决。

　　2、走向QA管理

　　我这里所指的管理，是指QM（质量管理），逐渐上升成为QML。这个过程需要大量QA经验、项目开发与管理经验、甚至软件配置、软件测试等经验的积累，也许过程比较长，也许比较短，一看机遇，二看自身能力。需要具备的资质还是包括“第1条、一直做QA这条路”中的内容，只是要求更精，而且此阶段尤其突出沟通能力、协调能力，并要注意培养自己的情商、逆商。

　　3、走向高级管理

　 　这里所说的管理，是指总监这一级别，也就是所谓的质量总监（或分管质量管理副总），如果真正走到这一步，那是相当的牛气了。这个阶段，专业知识体系不在 话下，更多的是侧重于对于整个企业质量管理体系的建立与优化、维护，企业的研发流程管理优化与维护，以及质量战略的制订、统筹企业管理。具备的素质我也不 知道，呵呵