软件中的Bug 是指操作系统或应用软件程序的错误或缺陷。随着软件规模的扩大，软件的复杂程度也不断提高，软件Bug 的数量也成比例增加，由此产生的危害日益加剧。

因此，从某种程度上说，软件产品的竞争已经不是技术的先进与否，而是软件的质量是否稳定，是否含有更少的Bug 的竞争。随着对软件质量需求的不断增强，研究软件Bug 的产生原因，从而有效地发现、修正和预防Bug 成为软件行业日益重视的课题。

有一个美丽的传说

IT界流传着关于软件Bug 的名称起源的多个版本，其中流传最广的是Grace Hopper在计算机的继电器中发现一只“飞蛾”导致计算机死机的传说。

故事发生在1945年9月9日，下午3点。一个炎热的夏天，房间没有空调，所有窗户都敞开散热。Grace Hopper中尉正领着她的小组构造一个称为“MARK II”的计算机。这还不是一个完全的电子计算机，它使用了大量的继电器（一种电子机械装置）。Hopper的小组日以继夜地工作，机房是一间第一次世界大战时建造的老建筑。

突然，MARK II死机了。技术人员试了很多办法，最后定位到板子F第70号继电器出错。Grace Hopper观察这个出错的继电器，发现一只飞蛾躺在中间，已经被继电器打死。她小心地用摄子将蛾子夹出来，用透明胶布帖到“事件记录本”中，并注明“第一个发现虫子的实例。”，然后计算机又恢复了正常。从此以后，人们将计算机错误戏称为虫子（Bug）或臭虫，而把找寻错误的工作称为“找臭虫”（Debug）。Grace Hopper的事件记录本，连同那个飞蛾，现在陈列在美国历史博物馆中。

这个流传最广的版本，故事的真实性尚有待于进一步考证，但是Bug这一术语本身的简洁和恰当远比这个故事深刻。
Bug 一词一般用来指代昆虫以及节肢动物，特别是指一些有害臭虫。在自然界，它们经常是人类的主要竞争者。科学家推测，如果人类灭绝，Bug将成为这个星球的主宰生命。据《圣经》所言，上帝降临埃及将犹太人从奴隶制度中解放出来时，带来了10种灾难。其中3种都是Bug，包括臭名昭著的蚊子、苍蝇和蝗虫，这些Bug叮咬我们的肉体，毁坏我们的房屋，吞噬我们的庄稼，并且将很多疾病传染给我们。

与自然界的Bug具有特别类似特征的是软件中的Bug,从人类第一次开发软件开始，软件中的Bug一直以极其相似的方式折磨着人们。软件中的Bug如同自然界的Bug，它们无处不在，几乎所有的软件都有Bug。当我们遇到这些Bug时，它们同自然界中的Bug一样使我们惶惶不安，甚至陷入深深的痛苦之中。

因此，如同自然界的害虫带来对人们的深深伤害一样，称软件的错误或缺陷为Bug，已经成为软件界倍感棘手的老大难问题，这可作为软件Bug名称来源的另一个版本。

都是Bug惹的祸

人们对软件Bug的心态是既敬畏又憎恨，主要是因为软件Bug经常潜藏于无形之中，而一旦发作轻则引起数据丢失，重则物毁人亡，造成生命和财产的巨大损失。且看一组近期发生的与软件Bug有关的真实事例。

软件大佬比尔·盖茨遭遇软件Bug尴尬。大名鼎鼎的比尔·盖茨是何等显赫的人物，但是软件Bug从来六亲不认，根本不买他的账，使得软件大佬在演讲现场遭遇软件Bug引起计算机死机，真是“华佗无奈小虫何”。据外电报道，在CES 2005展会第一天，比尔介绍了微软的“无缝计算”战略，但就在演示的时候，可爱的Windows又出现了蓝屏，引起观众的哄笑。接下来在90分钟的演示中，一名产品经理演示了一款看起来属于用户友好的视频游戏Forza Motor Sport，游戏没有按照用户设置的要求进入赛车游戏，而是电脑显示器显示蓝屏死机和“系统内存溢出”的警告。实际上，硬件故障和软件Bug，已经在很大程度上浇灭了用户追求数字生活的激情。

软件Bug引起北美地区大面积停电事故。著名安全机构SecurityFocus的数据表明，2003年8月14日发生的美国及加拿大部分地区史上最大停电事故是由软件错误所导致。SecurityFocus的数据表明，位于美国俄亥俄州的第一能源(FirstEnergy)公司下属的电力监测与控制管理系统“XA/21”出现软件错误，是北美大停电的罪魁祸首。根据第一能源公司发言人提供的数据，由于系统中重要的预警部分出现严重故障，负责预警服务的主服务器与备份服务器接连失控，使得错误没有得到及时通报和处理，最终多个重要设备出现故障导致大规模停电。

导航软件Bug使俄罗斯飞船偏离降落地。2003年5月4日，搭乘俄罗斯“联盟—TMA1”载人飞船的国际空间站第七长期考察团的宇航员们返回了地球，但在返回途中，飞船偏离了降落目标地点约460公里。据来自美国国家航空航天局的消息称，这是由飞船的导航计算机软件设计中的错误引起的。

其实，软件Bug造成重大事故的例子不胜枚举，由此造成的损失每年接近600亿美元。2002年6月28日，美国商务部的国立标准技术研究所（NIST：National Institute of Standards and Technology）发表了有关软件缺陷的损失调查报告。报告表示，“据推测，由于软件缺陷而引起的损失额每年高达595亿美元。这一数字相当于美国国内生产总值的0.6%”。
软件Bug虽然仅是一只“小虫”，但说软件Bug猛于虎，确实千真万确。随着软件在社会生活中的不断渗透，特别是各种嵌入式软件在各种智能电器的应用，软件Bug造成的损失将会更大，对此，应该引起人们足够的警惕并采取一个可能措施，将损失降低到最小程度。警惕呀，软件Bug！

软件Bug的丑恶嘴脸

软件Bug是软件世界的“恐怖分子”，是最不招人喜欢的家伙。常听用户抱怨软件不好用，Bug太多，可是软件Bug外貌如何，却总是众说纷纭。

经过对各种软件Bug特征的综合研究，人们对于软件Bug的丑恶嘴脸有了一些比较系统的认识。判断一个软件运行结果是否属于软件Bug可以从以下几个方面分析，凡是属于下列现象之一者，就是软件Bug。这些现象分别是：

1. 软件未达到产品说明书标明的功能；
2. 软件出现了产品说明书指明不会出现的错误；
3. 软件功能超出产品说明书指明的范围；
4. 软件未达到产品说明书虽未指出但应达到的目标；
5. 软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

在以上5条中，需要特别讨论后面的3条。第3条是说如果软件的功能和特征超出了软件的设计说明书的要求，那么也属于软件的缺陷；第4条是说如果测试者发现软件不正常，尽管设计说明书没有注明，但是根据测试者的工作经验和测试的尝试，也能判断出是否属于软件缺陷；第5条说明了软件测试的根据应该是软件设计说明文档和最终用户的要求。

掌握软件Bug的这些特征，可以帮助人们采取各种软件测试手段，以便尽早、尽快地发现和报告软件质量问题，降低由于软件Bug造成的各种直接和间接损失。

可怜的“替罪羊”

显然，软件Bug都是人为造成的，但是在软件项目开发过程中，面对软件Bug带来的错误，一些软件开发人员却经常为自己的过失开脱责任，美其名曰“都是Bug搞的鬼，都是Bug惹的祸”。软件Bug沦为可怜的“替罪羊”，真是比窦娥还冤！
“追求完美，根除Bug”是绝大多数软件开发人员追求的目标，但是尽管如此，软件Bug却还是屡见不鲜，原因何在？有些学者给出了软件Bug产生的一些原因：

1. 开发人员不太了解软件需求，不清楚应该“做什么”和“不做什么”，常常做不合需求的事情，因此产生了Bug。
2. 软件系统越来越复杂，开发人员不太可能精通所有的技术，如果不能正确地使用技术，将产生Bug。
3. 软件设计文档不清楚，文档本身存在Bug，导致使用者产生更多的Bug。
4. 软件需求、设计说明书、程序经常发生变更，每次变更都可能产生新的Bug。
5. “人无完人”，任何人在编程时都可能犯错误，导致程序中的Bug。
6. 软件项目由于时间或资源紧张，开发人员经常处于进度的压力之下，急忙之下容易产生Bug，尤其是在软件发布最后期限来临之际。
7. 开发人员过于自信，喜欢说“没问题”，不真实的“没问题”将产生真正的问题，导致很多软件Bug。

当然产生软件Bug的原因可能还有很多，例如，沟通上的问题，开发人员的态度问题，以及项目管理问题等。但是从根本上说，软件存在Bug有其必然性，这主要是由软件产品的生产方式和生产过程决定的。软件产品属于无形产品，不能一目了然的看清其“庐山真面目”，虽然靠人为努力可以在一定程度上发现和减少软件Bug，但却不能彻底消除软件中的全部Bug。

爱恨交加Debug

软件开发人员寻找软件Bug的产生原因，修正Bug的过程，称为“Debug”，即调试。前文描述了软件Bug的5类表现特征，对于具体的各个软件Bug而言，表现却是千变万化，由此给软件调试和修正错误带来了很大困难。

通常情况下，软件调试和修正错误的难点不在于如何修正，而在于寻找和定位软件产生的位置困难。对于软件的界面布局错误或界面上的文字表达错误引起的软件Bug，开发人员可以很快地找出原因，在软件代码中迅速定位，然后容易地消除。实际上，任何软件开发人员都可以修正这类软件Bug，犹如快刀切瓜，探囊取物。

但是要修正软件功能错误，就不总是那么容易了。实际上调试和修正软件功能错误，才是考验软件开发人员水平的真正标杆。某些软件功能错误，由于非常具有蒙蔽性，表面上看上去可能是常见的一些原因造成的，而实际上却往往是其他原因带来的。而且，这些软件Bug经常潜伏于软件代码的许多比较“阴暗”的角落，很难定位产生软件错误的代码准确位置。因此，修正某些软件Bug常常成为软件开发人员的“噩梦”，他们往往为了修正一个较难的软件Bug，需要绞尽脑汁，反复阅读和分析软件代码，设置程序断点，单步跟踪程序的运行结果，截获和分析程序的中间运行数据，试图找到修正错误的“蛛丝马迹”，为此甚至夜不能寐，百思不得其解，这是程序员的“地狱”。当然正确修正高难Bug后的成就感非常强烈，这是程序员的“天堂”，对于程序员而言，天堂和地狱的只有一个Bug那么远。

需要注意的是软件的全部Bug并不是都需要修正的。在缺陷的修复过程中，我们常常还会受时间、成本等方面的限制而无法有效、完整地修复所有的软件Bug。因此评估软件Bug的重要度、影响范围和市场因素，选择一个折中的方案，考虑软件Bug成为我们在面对软件Bug时一个必须直面的事实。另外，由于错误的关联性，某些软件Bug虽然能够得以修复，但在修复的过程中难免会引入新的软件Bug。很多软件Bug之间是相互矛盾的，一个矛盾的消失必然会引发另外一个矛盾的产生，有时导致顾此失彼，得不偿失。

小Bug，大市场

由于市场和用户对软件质量的不断提高，软件行业的竞争逐渐加剧，而且寻找软件错误非常耗费时间和人力资源，所以现在越来越多的软件公司开始将软件测试外包出去，由第三方专业的测试公司进行测试，客观地寻找和报告软件Bug。由此促生了软件外包测试的兴起和迅速发展，产生了具有较大发展潜力的测试市场。

软件外包是新兴的软件开发模式，我国是继印度之后具有较大竞争优势的软件外包服务提供国之一。在软件外包中，软件测试的门槛相对较低，是最可以先期进入的领域。这两年来，软件外包从软件测试外包做起，已经成为越来越多的软件业人士的共识。实际上，我国软件外包测试已经开始起步，且具有较广阔的市场发展潜力。

国内已经出现了一些专门提供软件测试服务的公司。仅以软件本地化行业的公司而言，例如北京的一些由软件本地化公司转变而成的软件外包公司，他们正在为大型国际软件公司提供十多种语言的软件外包测试服务，采用到这些大型国际软件公司在中国的研发中心进行现场测试和软件外包公司内部成立测试部门测试相结合的服务方式。据了解，有些软件外包测试公司的测试人员数量已经达到数百人，而且未来两三年内仍将继续快速发展。

小Bug蕴含大市场，随着软件外包在全球范围的不断深入，我国软件服务行业迎来了发展机遇，扩大软件外包市场先从软件外包测试做起，将成为推动我国软件行业发展的积极策略。

文章出处：转载 作者：Karl E Wieger，Process Impact 发布时间：2005-12-23
 
 　　你的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段而且你要写软件需求说明书。这份说明有些大，但客户会很重视，所以说明必须得到赞同。

　　现在你正在设计其中的一个特性，已经发现了需求的一些问题。你可以用多种不同的方式解释需求15；需求9 的说明正好与需求21相反，你因该相信哪一个？需求24非常含糊，你根本不明白它的意思；你不得不花上一个小时与2位开发人员讨论需求30，只因为你们对其各有各的理解；并且，唯一能够澄清这些问题的客户没有给你们答复。你被迫破解众多需求的含义，并且你能预料到，如果你错了，你要做大量的重复工作。

　　许多软件需求说明书（SRS）写得非常糟糕。任何产品的质量需要其原始材料的质量保证，糟糕的软件需求说明书不可能产出优秀的软件。不幸的是，几乎没有开发人员受过与需求的抽象、分析、文档、质检有关的教育。而且，没有非常多的好需求可以借鉴学习，部分原因是很少有工程可以找到一个好的借鉴，其他原因是公司不愿意将其产品说明书放在公共区域。

　　这篇文章描述了高质量需求叙述和说明的几个特性（特点）。我们将用这些观点检查一些有缺陷的需求，带着痛楚重新编写。而且我会谈一些如何编写好的需求的提示。你也许想通过这些质量标准评估你的工程需求。对于修订，也许迟了，但你会学到一些有用的东西，并帮助你的小组在下次编写出更好的需求。

　　不要期望能够编写出一份能体现需求应具备的所有特性的SRS。无论你怎么细化、分析、评论和优化需求，都不可能达到完美。但是，如果你牢记这些特性，你就会编写出更好的需求，生产出更好的产品。

高质量需求叙述的特性

　　我们如何从一些有问题的需求中分辨出好的软件需求？这一节将分别介绍需求叙述应体现的6个特性，下一节将从整体上介绍SRS文档应具备的特性。判断每个需求是否具备应有的特性的一种方式是由持有不同观点的工程资金管理人所作的正规检查。另一种有力的方法是在编写代码前依据需求编写测试例子。测试例子能够明确显现在需求中描述的产品行为（特性），能够显现缺陷、冗余和含糊之处。

　　正确：每个需求必须精确描述要交付的功能。正确性依据于需求的来源，如真实的客户或高级别的系统需求说明书。一个软件需求与其对应的系统需求说明书相抵触是不正确的（当然，系统需求说明书本身可能不正确）。

　　只有用户的代表能够决定用户需求的正确性，这就是为什么在检查需求时，要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的：“这是没意义的”，“这可能是他们的意思”等众所周知的猜测。

　　可行性：在已知的能力、有限的系统及其环境中每个需求必须是可实现的。为了避免需求的不可行性，在需求分析阶段应该有一个开发人员参与，在抽象阶段应该有市场人员参与。这个开发人员应能检查在技术上什么能做什么不能做，哪些需要需要额外的付出或者和其他的权衡。

　　必要性：每个需求应载明什么是客户确实需要的，什么要顺应于外部的需求，接口或标准。每个需求源于你认可、具有权说明需求的原始资料，这是考虑必需的另外情形（译注，此句翻译不顺，请参照原文：Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。跟踪每个需求回溯到出处，如用例，系统需求，规章，或来自其他用户的意见。如果你不能标识出处，可能需求只是个镀金的例子，没有真正的必须。

　　优先权：为了表明在一个详细的产品版本中应包含哪些要点，需要为每个需求，特征，或用例分配实现的优先权。客户或其代理都应有强烈的责任建立优先权。如果所有的需求都被视为同等重要，那么由于在开发中，预算削减，计划超时或组员的离开导致新的需求时， 项目经理将不能起到作用。优先权的作用是提供给客户的价值，实现的相关费用，实现相关联的有关技术风险。

　　我是用3种级别的优先权：高优先权表明需求必须体现在下一个产品版本中，中优先权表明需求是必须的，但是如果需要可以推迟到晚一些的产品版本中，低优先权表明有它很好，但我们必须认识到如果没有充足的时间或资源，它可以被放弃掉。

　　明确：需求叙述的读者应只能从其得到唯一的解释说明，同样，一个需求的多个读者也应达成共识。自然语言极易导致含糊。要避免使用一些对于SRS作者很清楚但对于读者不清楚的主观词汇，如：用户友好性，容易，简单，快速，有效，几个，艺术级，改善的，最大，最小等等。每写一个需要都应简洁，简单，直观的采用用户熟知的语言，不要采用计算机术语。检查需求模糊的有效方式包括需求说明书的正规检查，根据需求写测试，建立用户的假想来说明产品某个特定部分预期的特性。

　　可证实：看你是否能够做出测试计划或其他验证方式，如检查和实证，来决定在产品中每个需求是否正确的实现。如果需求是不可验证的，决定需求是不是正确的实现就成了判断的事。需求之间不一致，不可行，不明确也能导致不可证实。任何需求如果说产品将要支持什么也是不可证实的。

高质量需求说明的特征

　　一个完整的SRS不仅是包括长长的功能性需求列表，还包括外部接口描述和一些诸如质量属性，期望性能的非功能性需求。下面描述了高质量的SRS的一些特性。

　　完整：不应该遗漏要求和必需的信息。完整性也是一个需求应具备的。发现缺少的信息很难，因为根本不存在。在SRS中将需求以分层目录方式组织，将帮助评审人员理解功能性描述的结构，使他们很容易指出遗失的东西。

　　在需求抽象时，相对于系统功能，你过多的注意用户的业务，将导致在需求的全局观和引进不是真正必需的需求上显得不足。在需求抽象上，应用用例方法会发挥很好的作用。能够从不同角度察看需求的图形分析模型也可以检查出不完整性。

　　如果你知道已缺少一些信息，使用TBD（to be determined）标准标志可以突出这些缺陷，当你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有的缺陷。

　　一致性：一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发生冲突。需求中的不一致必须在开发开始前得到解决。只有经过调研才能确定哪些是正确的。修改需求时一定要谨慎，如果只审定修改的部分，没有审定于修改相关的部分，就可能导致不一致性。

　　可修改性：当每个需求的要求修改了或维护其历史更改时，你必须能够审定SRS。也就是说每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清晰的查阅。通过良好的组织可以使需求易于修改，如：将相关的需求分组，建立目录表，索引，以及前后参考（照）。

　　可追踪：你应能将一个软件与其原始材料相对应，如高级系统需求，用例，用户的提议等。也能够将软件需求与设计元素，源代码，用于构造实现和验证需求的测试相对应。可追踪的需求应该具有独立标示，细密和结构化的编写，不应过大，不应是叙述性的文字和公告式的列表。 需求质量的评审

　　这些有关需求质量的特性的描述在理论上都是非常好的，但一个好的需求到底是个什么样子的呢？为了体现得更切合实际，我们做个小练习。下面有几个从实际的工程选出的需求，依据上面的质量标准，评估每个需求，看看有什么问题，然后用更好的方式重写。我将对每个例子都提出自己的分析和改进的建议。也欢迎你提出不同的见解。我所占优的只是我知道每个需求的出处。因为你我都不是真正的客户，我们只能猜测每个需求的意图。

　　例1．“产品应在不少于每60秒的正常周期内提供状态信息”
　　这个需求是不完整的：状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于60秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过60秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。
弥补缺陷，重写需求的一种方法：

　　1、状态信息
　　1．1后台任务管理器因该以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息
　　1．2如果后台进程处理正常，那么应该显示任务已完成的百分数/比
　　1．3任务完成时，应显示相关的信息
　　　1．4后台任务出错应该显示错误信息
　　为了分别测试和追踪，我将其分成了多个需求。如果将几个需求串接在一节中，在构造和测试时就很容易漏掉一个。

　　例2．“产品应瞬间在显示和隐藏不可打印字符间切换”
　　计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些动作？而且，在文档中改变显示的范围是多大：选中的文本，整个的文档，或其他的？这也是个模糊的问题。不可打印字符合隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。

　　象这样编写需求也许更好一些：“用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换”。现在就很清楚，不可打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。

　　例3．“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。单词“快速”使其模糊，没　　有加进错误报告的定义也是其部完整。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？

　　试试这个：“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不会产生错误报告”。现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。

　　例4．“如果可能，主管号码应通过联机校验，而不是通过主全体主管号码列表校验”。真感到绝望，什么是“如果可能”：如果技术上可行？如果主全体主管号码列表可以联机获得？要避免象“应该”的这类不确切的词。客户是需要这个功能性还是不需要。我曾看过一些需求说明书，采用诸如：应，将，应该/将要等一些词描述优先级的细微差别。但我更喜欢用“应”清楚的说明需求的意图，指明优先级。这是修改后的：系统应校验输入的主管号码而不通过联机的主全体主官号码列表。如果在列表中没有发现主管号码，将会显示一条错误信息，也不接受指令。

　　在理解各个已完成的糟糕需求上，开发人员将会遇到的难题是：开发人员与客户将会在审核需求，未达成共识前发生激烈的争论。详细检查大的需求文档不是一件轻松的事情。我清楚有人做过，而且他们花在检查上的每一分钟都是值得的。相对于开发阶段和用户的抱怨电话，在这个阶段修补缺陷是便宜的，

编写质量需求的方针

　　编写优秀的需求是没有公式化的方法的。这需要大量的经验，要从你在过去的文档中发现的问题学习。请在组织软件需求文档时，严格遵从这些方针。

　　句子和段落要短。采用主动语气。使用正确的语法，拼写，标点。使用术语，要保持一致性，并在术语表或数据字典中定义它们

　　要看需求是否被有效的定义，可以以开发人员的观点看看。在内心将“当你们做完了找我”这句加到文档尾部，看看能不能是你紧张起来。换句话说，你是否需要SRS的编写者的额外解释帮助开发人员很好的理解需求，以便于设计和实现？如果是的话，在继续工作前，需求还需要细化。

　　需求编写者还要努力正确地把握细化程度。要避免包含多个需求的长的叙述段落。有帮助的提示是编写独立的可测试的需求。如果你认为一小部分测试可以验证一个需求的正确，那么它已经正确的细化了。如果你预想到多种不同类的测试，几个需求可能已挤到了一起，需要拆分开。

　　密切关注多个需求合成了单个需求。一个需求中的连接词“和”/“或”建议几个需求合并。不要在一个需求中使用“和”/“或”。

　　通篇文档细节上要保持一致。我曾看见过多个需求说明书前后不一致。如：“对于红色合法的颜色代码应是R”及“对于绿色合法的颜色代码应是G”就有可以以分散的需求分离开，而“产品应能对来自语音编辑指示做出反应”应作为一个子系统，不应作为单个的功能性需求。

　　避免在SRS中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读，但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新，避免不一致性。

　　如果你遵从了这些方针，你能够尽早地经常正式或非正式的审查需求，这些需求对于产品的构造，系统测试以及最后的客户满意，都会成为好的奠基石。并且要记住，没有高质量的需求，软件就象一盒巧克力，你永远不知道你会得到什么。
 

http://www.itisedu.com   2006-11-14 10:52:59   中科永联 
[关键字]质量控制 测试 
1.方案说明
目前测试实施已经构建了较完整的过程，但测试质量保证还未形成系统性的方案。测试作为质量保证的内容，应该得到较好的控制和持续的改进，测试只有和质量控制结合起来才能够实现这一目标，该方案就是以此为出发点。

2.当前质量控制和测试协调的问题
协调问题

l         测试人员不能及时了解项目进度并合理安排测试；

l         测试人员不能及时了解项目需求；

l         测试人员未在各种评审会议中发挥作用；

l         测试流程未充分适应实际需要；

l         测试流程未严格执行；

l         QA对测试过程没有有效监控；

l         QA未对测试结果进行评估；

l         测试结果能够反馈到项目组但未产生应有的作用。

考核问题

l         未测试人员考核；

l         项目考核未完善，目前效果不好。 

3.解决方案
3.1项目情况QA与测试沟通办法

l         项目进度：通过http://10.10.3.32/SQA/SQAWORK网站沟通，QA每周在出《项目情况周报》之前更新网站中的项目列表，项目状态发生改变就邮件通知测试管理人员察看网站；

l         评审会议：测试人员察看网站更新以后，与QA或项目经理确认；QA与测试管理人员在评审会议以后要提供一份《会议评估结论》，作为项目考评的一部分；

3.2测试流程改进

l         项目策划阶段：

说明：

1.项目立项后，QA将获得项目经理或技术总监发来的《立项申请书》，QA对《立项申请书》进行审核，如果发现问题及时通知项目经理及技术总监；

2.《立项建议书》无误后， QA及时更新网站中的项目列表，并通知测试人员获取《立项建议书》；

3.测试人员主动获取项目信息（背景，客户等）。

l         需求分析阶段：

说明：

1.       根据项目计划，项目组展开需求调研活动；

2.       QA获取项目情况，并及时与测试和项目组沟通，尽可能使测试参与需求调研；

3.       项目组根据调研结果进行需求分析；

4.       如果测试参与了调研，则根据自己的调研结果进行需求分析；如果无法参与调研则根据项目组的调研结果进行需求分析（需要独立进行）；

5.       项目组需求分析结束后，QA协调召开需求评审会议，并通知测试参加；

6.       评审结束后，测试和QA共同对评审进行评估；

7.       在需求阶段开始和评审开始，QA要更新网站的项目列表并通知相关人员；

8.       测试要在需求评审过程中对比项目组和自己的需求分析结果，但不需要干预项目组。

l         设计实现阶段：

说明：

1.       项目组根据计划进行系统设计活动；

2.       QA监控系统设计过程，并更新项目列表，及时通知测试人员；

3.       设计完成后，QA系统设计评审会议，测试参加；QA和测试共同对设计评审进行评估；

4.       设计评审完成，项目组进行系统实现；

5.       QA监控实现过程并更新项目列表，及时通知测试；

6.       测试主动获取项目信息。

l         测试准备阶段：

说明：

1.       QA及时掌握项目情况，在项目组编码结束以后，通知测试人员进行测试准备；

2.       测试人员应该在项目需求阶段完成以后就开始路径和用例设计，本阶段针对最终需求进行修正；

3.       QA与测试共同进行测试路径和用例评审；

4.       QA对评审结果作出评价；

5.       评审通过QA更新项目列表并通知项目组提交测试；

6.       项目组提交测试申请，QA审核测试申请内容（特别是版本和测试范围）；

7.       测试申请审核不通过，返回测试组；测试通过，QA通知测试；

8.       测试人员制定测试实施计划；

9.       QA审核测试实施计划；

10.   QA全程监控测试过程。

l         测试实施阶段：

说明：

1.       测试按照计划实施，QA全程监控；

2.       测试负责人根据测试时间长短定期向QA通报测试情况；

3.       初测结束后，测试负责人编写测试报告，通知QA核查，通知项目组排除缺陷；

4.       项目组修正系统后，提交复查；

5.       测试人员复查系统（最多两次）；

6.       复查结束，测试负责人完成测试报告。

l         测试评审阶段：

说明：

1.       测试报告完成后，由QA和测试负责人共同对测试结果作出评估；

2.       不管评估结果如何都要通报项目组并附带测试报告；

3.       QA对测试过程进行评估，对测试人员进行考核。

l         客户跟踪阶段：

说明：

1.       系统正式发布以后，QA需要在一段时间内持续跟踪客户使用情况；

2.       QA在跟踪时，通过到现场或使用E_Mail，电话将调查表发送给客户；

3.       客户填写好调查表，反馈给QA；

4.       QA将调查结果整理好定期发送给技术总监（项目组在允许的情况下通报）。

l        每个阶段的输入输出文档

1.       项目策划

《立项建议书》：项目组输出，QA，测试输入；

《项目计划mpp》，《项目配置库管理报告》：项目组输出，QA输入；

2.       需求分析

《需求规格说明书》：项目组输出，QA，测试输入；

  《需求评审报告》：QA和测试输出，项目组输入；

《阶段评审报告》：QA输出，项目组输入；

3.       分析实现

《数据库设计报告》，《详细设计报告》，《UI设计报告》：项目组输出，QA和测试输入；

4.       测试

《测试路径与用例分析》：测试输出，QA输入；

《测试设计评审》：QA输出，测试输入；

《测试实施计划》：测试输入，QA和项目组输入；

《测试报告》：测试输出，QA和项目组输入；

《测试报告评估》：QA输出，测试输入；

《测试过程评估》：QA输出，测试输入；

《测试人员考核表》：QA输出，技术总监输入；

5.       跟踪

《系统使用情况调查表》：QA输出，技术总监输入。
 

3.3维护项目与紧急项目测试流程

l         需要补充

     说明：

1.       项目经理按照维护计划，定期收集整理需要维护的需求；

2.       QA根据维护计划监控维护过程（这个期间可能会包含系统的客户使用情况调查）；

3.       项目组分析要维护的需求并制定解决方案；

4.       项目经理将维护方案发送给测试负责人和QA；

5.       项目组提交测试申请；

6.       在项目组实施方案的时候，测试组编写测试用例和修改自动测试脚本；

7.       测试组执行测试，在执行完成后编写测试报告并发送给QA和项目组；

8.       QA评估测试结果。

l         紧急项目测试流程

说明：

1.紧急项目简化了大部分工作流程，但需求和测试是最重要的，需要严格执行；

2.项目组在获取项目信息后如果时间非常紧迫可以向CTO提出紧急项目申请；

3.CTO未批准，项目按正常项目运作；如果批准，项目经理将批准意见和立项申请一同发送给QA；

4.QA及时更改项目列表并通知测试做好准备；

5.项目组收集分析项目需求，并召开一次需求评审会议，QA和测试人员需要参加；

6.评审通过后，项目组将《需求规格说明书》发送给QA和测试人员；

7.在项目组设计和实现项目的时候测试人员设计测试路径和测试用例；

8.项目组在实现项目后提交测试申请；

9.测试人员根据最终需求，修正测试用例并执行测试；

10.测试完成后，测试负责人编写测试报告并发送给CTO，QA和项目组；

11.后续流程按照正常项目走（包括测试评估，跟踪，结项）。 

4.系统测试阶段QA控制关键点
l         《系统测试计划》

l         《系统测试用例》评审会

l         《系统测试报告》

l         《不合格用例测试报告》

l         《详细系统测试用例报告》

l         《测试结项申请》
 
来源：51testing blog

软件质量保证,首先必须有概念的定义,什么是软件?什么是软件质量?什么是软件质量保证?

• 软件---IEEE定义:

软件是计算机程序,规程以及可能的相关文档和运行计算机系统需要的数据.

也就是说,包含计算机程序,规程,文档和软件系统运行所必需的数据四个部分.

• 软件错误,软件故障和软件失效的关系:

软件错误是指由于程序分析员,程序员或者软件开发组其他成员造成的语法,逻辑或者其他错误,部分或者全部不正确的代码段
软件故障是再特定应用期间导致软件不正确功能的软件错误
只有再软件故障激活被激活的时候,即用户试图使用故障的特定软件段时,他才变成软件失效

软件开发过程中产生的错误中只有部分会变成软件故障,而再这些故障中又只有部分转变成软件失效

• 软件错误的9种产生原因

1. 需求的不完善定义
2. 客户-开发者通信失效
3. 对软件需求的故意偏离
4. 逻辑错误设计
5. 编码错误
6. 不符合文档编制于编码规定
7. 测试过程的不足
8. 规程错误
9. 文档编制错误

• 软件质量--IEEE定义

软件质量是
1. 系统,部件或者过程满足规定需求的程度.
2.系统,部件或者过程满足顾客或者用户需要或期望的程度

另外的关于软件质量的定义:
符合明确陈述的功能和性能需求,明确文档化了的开发标准和所有专业开发软件预期的隐含特征(有点拗口,呵呵)

• 软件质量保证--IEEE定义:

软件质量保证是:
1. 一种有计划的,系统化的行动模式,他是为项目或者产品符合已有技术需求提供充分信任所必需的.
2. 设计用来评价开发或者制造产品的过程的一组活动.与质量控制有区别.

然而,这和实际的软件质量保证有些偏离,首先:
SQA不应局限与开发过程
SQA行动不应局限与功能需求的技术方面,而应该包含同进度和预算有关的活动.
基于这个考虑,有一个SQA的扩展定义:

软件质量保证是:一个有系统的,有计划的行动集合,他是为提供软件产品的软件开发过程与维护过程符合其已建立的技术需求以及跟上计划安排与在预算限制之内进行的管理上的需求的充分信任所必需的.

　作者：贺忻　　来源：测试时代　　2006年10月13日

国内的软件产业发展了20多年的时间，已经由个人英雄时代步入到中、小团队协作时代。相信不久的将来，国内一定会出现航

母级的软件企业，那时候我们会迎来集团军作战的时代。不同的时代表明软件规模的不同，也标志着软件质量管理的复杂度急剧上升，同时对软件质量的保障方法也提出了更高的要求。

　　本文并不打算系统的阐述软件企业的质量保证体系，而是想从另一个侧面同大家分享软件企业在软件开发过程中两个重要角色之间的协作关系，以两个角色之间高效的互动来说明在开发过程中，我们如何来有效的保障软件产品的质量。
 
1.软件企业的质量保证体系

　　我们知道质量保证体系的建设是一个系统工程，质量的保障不是某些人或者某些部门的工作，而是整个企业的文化，理念的贯彻。如果一个企业在进行质量保证体系的建设和推广过程中，只是在强调方法，强调规范，而不是把质量意识，企业文化贯穿其中，那质量保证体系是否能持续的发挥作用，并形成为企业的核心竞争力就值得怀疑了。
   
　　一般软件企业在规划质量保证体系的时候都会选择一个模型，目前比较流行的模型有：ISO9000：2000、CMMI、RUP、XP等，具体选用那种模型，还需要看企业的实际情况，并且能充分的协调：人、技术、过程三者之间的关系，使之能充分的发挥作用，促进生产力的发展。
   
    在软件企业的质量保证体系建设过程中，一般需要独立完成以下几个流程：
      
　　项目管理流程、软件开发流程、软件测试流程、质量保证流程、配置管理流程
   
　　以上这些流程需要相辅相成，各自之间都有相应的接口，通过项目管理流程将所有的活动贯穿起来，共同来保证软件产品的质量。
   
    整个软件质量保证体系中，所有的流程围绕软件开发流程展开，唯一的目标就是保证软件开发的质量，所以在众多的流程中，软件开发流程为质量保证体系中的主流程，其它的流程为辅助流程。之所以我们需要建立众多的辅助流程，就是为了让软件开发过程透明、可控，通过多角色之间的互动，来有效的降低软件开发过程中的风险，持续不断的提高软件产品的质量。

2.QA、QC的职责

　　在我们开始讨论QA、QC的职责之前，我们先假定一个前提条件，即：企业内部的质量保证体系已经建设完毕，即上述的五个流程已经编写完毕，并且通过了试运行，目前正在按部就班的执行。
   
    QA的英文为：Quality Assurance 我们翻译为“质量保证”。

    QC的英文为：Quality Control 我们翻译为“质量控制”。

    我们将这两个角色之间进行一下职责划分，以方便我们后续的讨论

    QA：监控公司质量保证体系的运行状况，审计项目的实际执行情况和公司规范之间的差异，并出具改进建议和统计分析报告，对公司的质量保证体系的质量负责。

    QC：对每一个阶段或者关键点的产出物（工件）进行检测，评估产出物是否符合预计的质量要求，对产出物的质量负责。
 
    通过上面的职责划分，我们发现，如果我们将软件的生产比喻成一条产品加工生产线的话，那QA只负责生产线本身的质量保证，而不管生产线中单个产品的实际质量情况。QA通过保证生产线的质量来间接保证软件产品的质量。

    而QC不管生产线本身的质量，而只关注生产线中生产的产品在每一个阶段的质量是否符合预期的要求，如果我们生产的是杯子，那QC只关注：生产的材料是否是预期的，每个杯子瓶口的直径是否符合要求，杯子把手是否符合设计要求等等具体的、可量化的点。
   
    针对软件企业的软件开发过程而言：

    QA可以进一步明确为SQA，即：软件质量保证，只负责软件开发流程的质量，企业内相对应的角色为：软件质量保证人员，有的企业就直接称之为SQA。

    QC可以进一步明确为SQC，即：软件质量控制，只负责软件开发过程中各个阶段产出的工件的质量，产出的工件可能是相关的文档或者代码等，企业内相对应的角色为：软件测试人员。
      
　　由于各个企业采用的开发流程和测试流程不一样，在各个阶段SQC的对应人员不一定都为测试人员，如在需求阶段，产生的工件为《需求规格说明书》，对该文档的主要质量控制手段为评审，这时候在此阶段担任SQC职责的就是评审小组的成员。      

3.QA、QC的良性协作

　　通过以上分析发现，SQA和SQC虽然主要的工作都是为了保证软件的质量，但是着眼点不尽相同。

　　SQA通过控制过程来保证软件产品的质量，而SQC是通过控制每个阶段的“结果”来保证软件产品的质量。
 
　　如果在软件开发过程中我们只要SQA或者SQC是否可以保证软件产品的质量那？答案一定是不可以的，通过下面的分析我们看看原因到底是什么。
 
　　软件企业中只有SQA的角色

　　如果企业中只有SQA的角色而没有SQC，我们假设企业对SQA的投入力度很大，于是企业得到了一个很好的流程（生产线），但是这个时候软件的产品是否就没有问题了那？如果我们的生产源头没有得到有效的控制，进入生产线的材料是残次品，那不管我们的流程控制的多好，那最终的产品的质量都不会高。

　　可能有朋友会说，如果我进行了很好的流程控制，对原材料的控制方法当然也纳入到了我们的流程之中，原材料没有了问题，那这件事情是不会发生的。

　　如果是制造业，这件事情可能会存在，但是在软件产业中，这件事情几乎不会发生。因为在软件产品的开发过程当中，几乎所有的原材料都是自己生产的，如需求规格说明书、概要设计、详细设计等，单靠过程的控制无法得到无缺陷的“原材料”。由于软件开发的固有特性，我们在每一步的生产加工过程中，都会引入新的缺陷，不管我们的流程规划的多么完美。所以，在每一阶段完成后，都需要对上一阶段的工作产品进行检验，评估这个阶段的工作产品是否符合预定的质量要求，只有这样才能保证最终软件产品的质量。
 
　　软件企业中只有SQC的角色

　　如果企业当中只有SQC而没有SQA的角色，我们也假设企业对SQC的投入力度很大，在每一个阶段SQC都找出了相应的缺陷，这时候企业的质量保证是否就没有问题了那？
   
　　如果纯从质量保证的观点来看，在理想情况下，上述的软件企业的质量的确是没有问题，因为在每一个阶段，通过大量专业SQC（测试）的努力工作，找出了软件产品中的“全部”缺陷，这样的产品的质量当然没有问题了。
   
　　但是我们从另外一个角度看一下这个问题：首先软件中的缺陷在理论上是不可能被全部找出来的，由于软件测试的不可遍历性。其次，如果我们维护一个上述的软件测试团队，成本是相当高的，目前国际上还没有那个商业性的公司能够维护的起（微软的产品还会有大量的缺陷），也就是说在实际操作过程中几乎没有公司会同意上述的做法。另外，如果我们在软件生产的过程中，只单一的强调对结果的检验环节，而忽视过程控制，会造成持续的返工、极大的推迟交付产品的日期，最终造成软件开发的失败。这样的做法就像我们想减肥，不是去节食、多做运动，而是去不断的称体重想达到减肥的目的一样可笑。所以，我们想提高软件的质量，不是持续不断的进行测试，而是要改变软件开发的方式，改变我们的流程，在过程中保证软件产品的质量。
   
　　通过以上分析发现，如果想有效的保证软件产品的质量，SQA和SQC缺一不可，两种角色必须相互配合，在“过程”和“结果”都正确的基础上，才能有效改善软件产品的质量。

4.质量的持续改进

　　软件质量的提高，过程的改进是一个循序渐进的过程，不可能一蹴而就。针对软件企业而言，如何调配有限的资源，针对质量保证的短板，来有针对性的做出质量改进的规划才是企业迫切需要解决的问题。
   
　　首先，企业必须对软件质量的保证提出切实的目标，质量保证的目标绝对不是为了过级，拿到认证，这些只是附带的结果。企业质量保证的目标应该是提高产品的竞争力，重塑企业的文化。
   
　　其次，在质量保证的技术层面，SQA人员和SQC人员的互动，会为企业选择质量保证的短板提出建设性的意见。
   
　　SQC（测试）人员在工作过程中会产生出大量的过程数据，SQA人员通过对这些数据的统计分析，发现企业的问题所在，进而反馈到流程的改进活动中，再通过SQC人员搜集的大量数据来验证流程改进的有效性，最终达到质量的持续改进。
   
　　质量是企业的根本，不管我们现在的产品销售情况如何，企业之间的竞争早晚会过渡到质量的竞争上来，所以只有我们自己练好内功，才有希望打造出我们自己的百年老店。

1、关于生产日期的问题

例如超市所买的吐司，它所显示的生产完全在可以食用的范围内，但是为什么吃坏了肚子？根据以前的工作经验，我判断，这包吐司可能是经过再加工的。因为超市自制的面包类商品，如果没有销售完毕，是不可能扔掉的。有两种方式：一种就是撕掉原本的标签，修改生产日期。第二种就是将没有销售完的商品进行粉碎，制作成新的产品。

当然，那些所谓的当天生产的食品谁也说不清楚是不是当天生产的，按照习惯，超市在早上8点钟开门，超市员工最早在五点半左右上班，很多时候都是来不及的，所以很多标签上“当天生产”的东西，例如包子、炒面、粽子等其实都是前一天生产的。我们买到的，都是贴了标签后的当日生产，而起出了事情也没法说，上面的生产日期，确实没错。新鲜出炉的，不一定是新鲜的，可能是再加工的。所以，保质期更像是一件虚伪的外衣。

2、关于熟食菜料的问题

超市熟食专柜的菜品，很多一部分都是超市自己的生菜或者半成品做的。很多一部分，比如说鱼，有相当的一部分是用水产科即将死亡或者已经死亡的鱼做的，因为经过加工后，你就根本不知道，这鱼是死的还是活的，同一道理，其他的菜肴也是如此。当然，并不是所有的都是这样，但是确实存在这样的问题。鸡蛋碎掉了怎么办，制作成蛋饺子或者蛋花丝，用来做配料。

另外，在食品加工过的过程中，添加了什么配料，有没有防腐剂，都没有做说明，要知道防腐剂超量了对身体是有影响的。那些佐料，是不是也是使用了正轨的，在保质期内的商品，还是怎么样，都是值得怀疑。在我工作的两年多重，只处理过百货商品的报废，但却从来没有处理过食品的报废（过期和破包），但是按照程序，报废的单子和手续，需要我来办理的。总之，是很好用好料制作味美的食品的。

3、关于超市卫生的问题

员工的口罩，更像是装饰品，员工只有在上级部门检查的时候才会戴起来，平常不太会带，就是检查了，检查的走了就拿掉了，当然，在柜台前售卖的人员除外，不过也有一些是装样子的。我记得很清楚，有一天，去他们的操作间，就看见他们没有戴一次洗手套，裸着手自己在腌制鸡腿。拿着擦过桌子却未洗净的抹布，擦一下菜刀，就开始切菜，刀子会干净吗？

在操作间，你可以看到蟑螂和老鼠，当然并不是很多，但确实存在，我都亲眼看到过，员工的衣服有的时候放在更衣柜里都有蟑螂，看着都恶心。然而，一些盐、酱油之类的都会堆在地上，包括半成品的食品。所以这一类食品的卫生问题，是不是存在细菌呢？可想而知了。已经在卖的食品，掉了怎么办，捡起来继续卖！你看见了不卖给你就成，卖给来没看见的人。

4、关于盒装水果的问题

很多时候，我们看到水果都切成一块一块，装在盒子里来卖，为什么要切呢？因为水果发生了质变，可能因为日子久远了，腐烂了，然后将腐烂的那一部分切除，没有腐烂的切成块，装盒之后出售。价格比起整个的水果便宜多了，但是要知道那是即将要扔掉的。所以买水果要买整个的，虽然价格稍贵，那是吃来舒心。

对于礼盒装的水果，因为我也买过几次，所以也注意了，盒装水果其实就是在原来的基础上多了一个盒子，而且盒子内的水果基本上是不怎么样的，在摆放位置上进行调整之后，看起来就是好水果了，其实买盒装的，还不如买散装的。

5、关于油炸食品的问题

油炸食品的油，不是只用来炸的，食品炸完之后倒掉太可惜了，可以用来再去炒菜。而且，这些油可以重复利用多次。另外一些食品即将变质的时候，往往会使用油炸的方式，使之味道发生变化，从而挽救了“即将下岗”的食品，这真是一次了不起的行动。

一油多用，炸完鸡翅炸鸭头，炸完鸭头炸春卷，所以很多时候，那个味道交杂在一起，还说这个春卷还不错，有点鸡肉的香味，不知道是重复再利用的功劳。

本文出自kuailederen的51Testing软件测试博客，严禁转载。

　　产品部：负责需求采集，需求说明说编写，后期的需求变更。

　　研发部：负责需求的具体实现，测试阶段负责对测试的支持和缺陷的修改。

　　测试部：负责产品上线前的测试工作。

　　每个部门在整个软件过程都肩负着不通的责任分工，但每个部门之间又形成了一个相互依存，相互促进的关系。就拿需求来说吧，需求真是反映了客户的需要，需求又是研发部技术实现的唯一标准，要求100%按照需求来实现代码，并且不多也不少；需求是测试人员设计测试用例时唯一正确的预期结果，一切与需求不符的都视为缺陷。相反，研发人员和测试人员作为产品的第一用户，又对需求起着诊断的作用，不断的发现不合理的需求或者是新增需求，并提出需求变更。

　　同时，产品部还有跟踪测试进度，监督测试质量的职责，那么这些都怎么来保证有效的实施？ 有什么样的标准去衡量质量？怎样跟踪进度？怎样来对需求做出科学合理的管理呢？

　　CMMI，大家所熟悉的名字，正是一些大公司在解决这些具体问题时所总结的经验，并形成了具体的管理过程，制定了有效的流程和标准，然后才得到世界的认可并成为一种标准。

　　说这些的目的是，公司应该根据自己具体的情况来实施质量管理的整个过程，谁又能说我们的这套标准若干年后不能成为电信增值行业的标准呢？毕竟质量管理方面现在大家都处在探索阶段。我想这正是中国大部分软件企业所缺少的，不注重对理论知识的探索和知识产权的追求。（说的有点大，哈）

　　简而言之，目前我们所说的狭义的质量管理是刨去市场运营，单纯的就整个开发过程（指的是产品上线前的阶段，这里并没有忽视产品维护，而是分而谈之）而言，工作所围绕的中心是项目的整体进度和质量，也就是说怎么样在最短的时间内，把高质量的产品开发出来，然后投入市场。这样就存在两个矛盾，一个是时间上的，想把产品尽早的投入市场而缩短开发的周期；另一个矛盾是不断的担心质量问题的出现，因为产品上线后发现问题，去解决所需要花费的成本是成倍的增加。

　　我一直在思考，质量管理的过程可不可以以成本为导向？使各部门都以此为目标去参加质量管理。其实无论以质量为导向，还是以成本为导向，我们的最终目标都是一样的-----缩短开发周期，提高软件质量。就像教育孩子，爸爸告诉儿子说，期末考试不及格我打你屁股，而妈妈告诉儿子说，期末考试都几个了，我带你去公园玩。那个方法更有效呢，答案不言而明了。以成本为导向的软件管理，正是这种让管理者去主动的思考如何利用质量管理降低成本，而不是单纯的去承受质量管理所带来的压力。

　　下面我简单的就如何在保证软件质量的过程中，各部门所应该起到的作用说一下个人观点。

　　产品部：负责需求采集，需求说明说编写，后期的需求变更。另外还负责对整个项目进度的跟踪，及质量的监督。

　　可以说，产品部在整个软件过程起着非常重要的作用。首先，产品部是最了解客户需求的人员，也是主动去采集客户需求的人员。如果产品部对客户的需求非常明确，就能写出非常详细且需求明确的需求说明书，一份这样的说明书，将对研发部和测试部有着极大的帮助。

　　据统计，有80%的缺陷直接来自需求，包括采集需求阶段对需求不了解，了解不全面，或者主观的判断错客户的需求；包括由于需求说明书不详细，不明确，导致开发人员对需求的理解有偏差或者错误，开发出不适合客户需要的功能；包括测试人员无法从需求说明书中获得正确的测试需求，以至于失去衡量功能点是否正确的标准。

　　其次，客户的需求并不需要客户直接提出来，而有很多的隐含需求是需要我们产品人员去主动发掘的。比如网站产品的个人管理界面，客户没有提出美观大方的要求，但我们也要给他们这种美感，并且给予充分的提示信息，让客户轻松方便的进行配置管理；再比如，客户没有提出对通话清晰度的要求，但我们要在满足客户通话最低质量标准上，不断的提高通话质量，这些就是客户没有提出，但我们应该知道这正是客户需要的隐含需求。

　　第三，产品部还负责线上问题的采集。包括线上发现的缺陷，客户提出的新需求等。线上缺陷可以归位到我们的缺陷库，防止以后测试时遗漏。客户新需要为我们产品的升级提供参考价值。这些都需要慢慢的积累，是一笔宝贵的财富。

　　具体实施的建议：

　　● 制定符合公司的需求采集流程。公司个人产品，公司企业产品还有国际产品，用户群体的不通而获取需求的渠道就不通。

　　● 制动标准的需求说明书模板。

　　● 产品部对需求说明书初稿的评审，确认需求正确，明确。（保证需求说明书中的需求是客户真是的需要）

　　● 需求说明书移交研发部和测试部，并主动帮助研发人员和测试人员正确的理解需求。（保证向研发人员和测试人员准确转达了客户的需要）

　　● 对项目进度的跟踪，对项目质量的控制。

　　● 对需求变更的管理

　　建议适当的时候启用需求管理工具，对需求的管理，对需求变更的管理将十分的清晰。

　　研发部：前期负责具体需求的技术实现，测试阶段负责对测试人员的支持，缺陷的修改。

　　简单的说，只要对需求理解充分，代码实现就容易很多。 我只说些对质量管理和对测试部门比较重要的部分。

　　1. 规范的开发流程，生成概要设计文档，详细设计文档及其他技术性文档，还包括产品安装卸载手册，配置手册，用户使用手册等。其中面向客户的文档也是需要经过测试部门测试的。

　　2. 开发阶段的测试工作。由开发人员执行单元测试，集成测试等，保证移交到测试部门的产品符合测试启动标准（测试启动标准由测试部门制定）

　　3. 严格的需求管理与版本管理。如果开发人员觉得某个需求应该改动，必须与产品部沟通，严格走需求变更流程，不允许私自更改需求。 版本管理，没有经过测试的产品不私自线上部署。

　　建议有一名专门的配置管理，版本管理人员。

　　测试部门：执行产品上线前的测试工作，保证产品达到上线标准方可通过测试。

　　一个优秀的测试团队至少应该包括以下三个方面：

　　1. 合理的测试技能搭配。

　　一个测试团队并不都需要经验丰富，技术过硬的“全才”，有一个梯度是最好的选择。

　　毕竟让一个经验丰富的高几工程师去测试简单的功能测试，时间久了他就会失去兴趣。而让他写一些测试方案，把经验传授给初级测试工程师，却迎合了他的技术特点，这对测试新人也是一种成长。

　　还有功能测试，性能测试，自动化测试等，都需要合理的技能搭配。

　　2. 建立合理的测试流程，测试标准。

　　包括：

　　● 启动测试标准： 定义了可以接收测试项目的标准

　　研发部把产品提交测试部之前，需要组织人员测试，保证基本功能，基本业务流程没有错误，保证实现了需求说明书中的全部内容。这样可以避免把带有严重的却容易发现的缺陷的产品提交给测试，而启动了测试资源，生成了测试成本后，却无法执行下去。

　　● 中止测试标准： 定义了可以中途停止测试的标准

　　在测试进行过程中，当发现有严重缺陷而导致基本功能，基本流程无法执行时，应中止测试，返回研发人员。

　　● 通过测试标准： 定义了通过测试，可以上线的标准

　　当所有high以上的缺陷均被修复，而其他缺陷均不影响产品的功能，使用时，可视为测试通过。

　　● 设计用例标准：定义了以个规范的编写用例标准和属性

　　规范了用例的外在属性：测试目的，测试环境，测试数据，测试前提，备注等。

　　规范了用例的内在属性：用例标题，用例步骤，用例期望，用例执行结果。

　　● 缺陷生命周期：定义了一个缺陷被处理的整个过程

　　QC管理工具为缺陷提供了一个在测试和开发人员之间的交流平台，交流的过程以改变缺陷的状态为标示，并要求双方写明处理的理由。便于缺陷的跟踪和修复确认。

　　● 缺陷级别划分： 定义了缺陷的等级，及等级的划分标准

　　根据缺陷对系统的影响程度，赋予了不通的等级，等级高的会被优先处理。等级高的缺陷越多，说明系统的质量越差。

　　● 测试计划模板：

　　测试计划一般包括：测试的时间安排，测试资源的划分，测试风险的应对等主要内容。

　　● 测试方案模板：

　　测试方案写明本次测试应该被怎么执行，怎么来测试才能效果更好，它写明测试的内容，测试的方法，测试的重点和一些注意事项，供测试人员在实际测试过程中参考。

　　● 阶段测试报告模板：

　　测试人员对自己负责测试的项目,内容进行总结，是对自己工作的一个回顾总结的过程。

　　● 总结性测试报告模板：

　　一般由项目的主要测试负责人负责编写，分析整个项目的测试过程，测试覆盖，用例执行情况，缺陷修复情况，提一些建议或者新需求等，供与项目有关的所有人员清楚的看到测试的整个过程，清楚的认识项目的质量，从而评判产品能否上线。

　　3. 测试团队组织建设与培训

　　组织建设包括一些集体活动

　　培训包括测试素质培训，测试技能培训。

　　还可以进行每周一问一答活动，由所有测试人员共同思考测试有关的某一问题，集众人智慧，建设公司自己的测试知识体系。

　　这些都是有利于测试团队的成长，融洽的团队氛围，积极的团队精神面貌，提高测试水平，增加忠诚度等。

　　总结：测试的质量管理只要抓住从整体角度入手，发挥各部门协调处理问题的能力，对整个过程制定一系列流程和约定，对整个实施过程都要有文字记录，对每一个结果都要进行总结和存档。一句话，使整个质量管理过程变成一个可看得见的，可控制的，能够预测规避风险的过程，这也是CMMI的精髓所在。

本文地址：http://www.51testing.com/?117068/action_viewspace_itemid_100141.html

1          质量、质量特性与质量职能

现代质量管理认为，质量是客户要求或者期望的有关产品或者服务的一组特性，落实到软件上，这些特性可以是软件的功能和安全性等。软件产品质量是最终的检验标准，而最终的检验者是客户，从这个意义上说，软件质量就是客户的满意度。

1.1       质量的重要性

质量是企业的生命，没有质量，企业就不能生存和发展。以质量求生存、求发展，是现代企业经营管理的质量理念。

产品质量。产品质量是指产品能够满足使用需求所具备的特性。一般包括性能、可靠性、安全性、经济性，以及外观质量等。

1.2       什么是软件质量

保证软件质量就是要满足明确声明的功能和性能需求、明确文档化的开发过程以及专业人员开发软件所具有的所有隐含特性。

从这个定义可以理解：

         软件需求是质量度量的基础，与需求不符就是质量不高。

         正确性（Correctness）：所制作的功能达到设计规范并满足使用者需求的程度；

         可靠性（Reliability）：于规定的期间和条件下，仍能维持其性能水准的程度；

         易使用性（Usability）：使用者学习、操作、准备输入、理解输出所做努力的程度；

         效率（Efficiency）：软件执行某项功能所需电脑资源的有效程度；

         可维护性（Maintainability）：当环境改变或软件发生错误时，执行修改所做努力的程度；

         可移植性（Portability）：从一个电脑系统或环境移到另一电脑系统或环境的容易程度。

2          质量管理

2.1       质量管理的定义

质量管理是确定质量方针、目标和职责，并在质量体系中通过诸如质量策划、质量控制、质量保证和质量改进使其实施的全部管理职能的所有活动。

质量管理是各级管理的职责，但必须有最高管理者领导。质量管理的实施涉及到组织中的所有成员。

质量管理任务是正确制订和贯彻执行质量方针和政策；保证和提高产品质量和服务质量，生产出物美价廉的产品，以满足用户需要；不断降低物质消耗，降低质量成本，提交经济效益；提高领导和职工的质量意识和素质，促进企业素质和管理水平的提高；研究和发展质量理论和质量科学。质量管理是揭示产品生产、形成和实现运动的规律，运用规律以指导质量管理活动。

3          质量保证和测试

软件质量保证（Software Quality Assurance，即SQA）与测试（Testing）有相同之处，但Quality Assurace 和Testing 又具有两个显著不同的流程和职能。

3.1       SQA与测试的不同

正规化的测试流程基于标准化的软件开发生命期。强调书写正式的测试文档（比如测试计划、测试设计、测试用例和测试过程），以实现可重复的结构化软件测试。测试文档应以正式的需求规格说明书为基础，模型中的测试计划是用来验证需求的，有了测试文档就可以执行测试。

之后是检查测试文档、基于文档执行测试、召开测试前和测试后的会议，以及书写测试报告等。

正规化的测试流程包含5个重要的子流程：

         检查项目计划

         创建测试计划

         创建测试设计、测试用例、测试软件和测试过程；

         执行正式的测试

         更新测试文档

类似的，QA流程模型是建立在项目早期的QA计划基础上的，象测试一样，QA也是一个贯穿整个开发生命周期的流程。

SQA计划形成后，QA要进行以下活动：

         协调度量工作

         协调风险管理工作

         执行审查

         协调风险管理工作

         执行审查

         协调文档检查会议

         促进/协助流程改进

         监察测试工作

1.          SQA组织的职能是向管理层提供正确的信息，以开发程序正确执行；

2.          SQA最主要的职能是促进和协助流程的改进，收集度量数据（有些来自文章检查的结果）、确定和管理风险都能够帮助流程改进。

3.          SQA的另一个主要职能是充当测试工作的监督者，管理人员和开发人员不必再担心“谁来监督测试人员”，有了独立的SQA组织，测试工作就可以被客观的检查和评价。SQA可以确保测试工作是按照他们定义好的流程（如同测试计划和其他测试文档中所写的那样）执行的，并且可以协助测试部门和人员改进测试流程。

4.          从另一个角度看，通过比较SQA和测试的不同，我们也看到了测试和SQA是如何通过协作建立起一个正规化的质量支持基础构架来支持项目开发的

3.2       对于SQA与测试工作的一些误解

1.          误解一：如果发布出去的软件有质量问题，那时软件测试人员的错；

这种观点是错误的，因为软件质量是“做”出来的，而不是“测”出来的。

2.          误解二：软件技术要求不高，比编程容易多了；

很多人认为软件测试技术要求不高就是运行一下软件，然后看结果对不对。但实际上，如何在有限的投入下，提高软件质量的效率和产出是一件很见功底的事情。所以，好的测试人员不仅要掌握各种测试技术和测试工具，还要具备丰富的编程经验和对bug的敏感性。另外，测试统计技术也是一项很特别的技术

3.          误解三：设计——实现——测试，软件测试是开发后期的一个阶段；

实际上，软件测试贯穿整个软件产品生命期。一方面，软件测试也要经历测试计划、测试用例的设计和实现，以及测试运行一系列的阶段，因此，早在软件需求阶段，甚至更早，软件测试的工作就要开始了。另一方面，软件测试越早进行越好，因为bug越早发现，bug造成的影响和修改bug的代价就越小。而且，软件测试并不仅仅针对程序，软件的需求、设计等也要被测试；

4.          误解四：SQA工作就是要做测试；

软件测试就是一种有效的提高软件质量的手段，但测试毕竟是一种事后的，检验性的，任何在软件生产过程中保证软件过程的质量和效率其实比单纯的产品检验具有更重要 的意义。不断的改进我们的软件过程是SQA的一项最重要的任务。

SQA和测试虽然具有上面所述的不同之处，当他们需要协作和共同作用才能有效提高软件产品的质量。

4          软件度量

只有可度量的才是可控制的，也才是可测试的。度量的目的是为了判断SQA活动的成本和进度状态，进而改善SQA活动。本节介绍软件度量对研发的意义，以及如何进行度量活动。

4.1       为什么需要进行软件度量

可能人们有疑问：度量活动对我们的研发工作有上面所述的作用吗？我们花费时间和人力来做度量，值得吗？

度量活动可以对我们的软件开发项目状态和产品质量给予量化的表示，为我们加强和改进研发工作提供详细的指导。

1.          软件度量的作用

用数据指标表明验收标准；

监控项目进度和预见风险；

分配资源时进行量化均衡；

预计和控制产品的进度、成本和质量。

2.          度量的目的

1)         理解

就是通过分析获得过程、产品资源、环境的信息，确定以后预测的基线和模型。这是评估、预测、改进活动的基础。对于不同的组织和软件类型，过程模型不一样，没有通用的组织模型。

2)         预测

就是通过理解过程、产品各要素之间的关系建立模型，由已知的要素推算、估计其他要素，以便合理分配资源、合理制定计划。

3)         评估

就是分析活动与计划的符合程度，确定是否有偏差，以便控制其执行；

         评估最终产品的质量；

         评估新技术的影响；

         评估过程改进对过程和产品的影响。

4)         改进

就是根据得到的量化信息，可以帮助我们识别障碍物、查找问题的根源，以及能提高产品质量和过程效率的其他方法。与以前的量化信息比较，可以证实这些方法是否有效。

软件度量的根本目的就是通过量化的分析和总结，帮助我们提高生产效率，提高产品质量，降低成本和产品研发周期。

4.2       软件度量的概念

度量是根据一定的规则，将数字或符号赋予系统、构件、过程等实体的特定属性，从而使我们能清晰的理解该实体及其属性的量化表示。简而言之，度量就是对事物属性的量化表示。

软件度量活动的结果不一定能直接应用。因为通常对于软件度量活动的结果，简单的看数据，很难分析出过程特征。

为便于分析、理解，可以用指标来表现度量活动的结果，它是对于一个度量结果或者多个度量结果的组合，并采用一些易于理解的形式，使我们对于过程、系统、项目、产品能有深入的理解。

1.          软件度量相关概念

         测量（Measure）是对产品过程的某个属性的范围、数量、纬度、容量或大小提供一个定量的指标；

         测度（Measurement）是定义一个测量的行为；

         度量（Metric）是对软件产品进行范围广泛的测度，他给出一个系统、构件或过程的某个给定属性的度的定量测量；

         指标（Indicator）是一个度量和一组度量的组合，他对软件过程、软件项目或产品质量提供更全面、深入的评价和了解。