一、背景
提到软件开发，我们的脑海里总是浮现出这样的情景：开发组的每一位成员都在辛苦的工作，有的加班加点，甚至通宵达旦是常有的事，虽然项目经理修改了一次又一次的进度计划，而实际的开发情况却总是很令人担忧，以至于每次向领导汇报工作的时候总是觉得以前制定的计划没有很好的完成，总是觉得人力资源不够，总是觉得我们没有太多的时间。等到代码终于开发完成了，测试进度却又非常令人担忧，每一个小BUG都要花很长的时间去查找，改了某一个小错误却又引起了很多错误，结果产品发布遥遥无期，而项目组里的每一位成员已经筋疲力尽。
怎样摆脱这样的困境呢?为何软件开发项目管理这么困难呢?为何我们做的计划总是不能按时完成呢?为何软件开发不能像硬件开发那样可以控制呢?原因在于软件开发完全靠人的大脑思维产生出产品，而每个人的大脑思维是不一样的，因此在软件开发过程中有太多不确定的、可以变化的因素，我们怎样把握住这些变化因素呢?就像我们题目所说的一样，软件开各阶段的成果质量管理，如果我们能够很好的控制软件生命周期每一个阶段的质量，也就很好的控制了整个软件开发的整个过程。
二、软件开发质量
2.1、开发质量较低的原因分析
2.1.1、原因常见
缺陷集中出现有两种可能，一是大量出现缺陷的模块特别复杂，以至于软件设计者和程序员没有能力保证程序没有错误。二是编写这些模块的程序员比编写其他模块的程序员水平要低，或者做事情要毛糙。第一种可能是可以避免的，如果模块太复杂就将其分解为若干更小的模块，直道划分的模块够简单为止，这也是模块划分过程中应该要做的。
2.1.2、缺陷如何分析
1、缺陷的概念
软件缺陷是指软件对其期望属性的偏离，它包含三个层面的信息：
1. 失效(failure)：指软件系统在运行时其行为偏离了用户的需求，即缺陷的外部表现。
2. 错误(fault)：指存在于软件内部的问题，如设计错误、编码错误等，即缺陷的内部原因。
3. 差错(error)：指人在理解和解决问题的思维和行为过程中所出现的问题，即缺陷的产生根源。
2、缺陷原因分析
一个差错可导致多个错误，一个错误又可导致多个失效。
软件缺陷原因的分析不能只停留在“错误”这一层面上，而要深入到“差错”层面，才能防止一个缺陷（以及类似缺陷）的重复发生。
因此软件缺陷的根本原因往往与过程及人员问题相关，缺陷预防总是伴随着软件过程的改进。
软件缺陷原因分析过程一般包括选择缺陷数据、分析缺陷数据、识别公共原因并提出改进措施三个步骤。采用该方法的软件组织通常是在软件项目的每个开发阶段结束后，或者定期（如每个月末）进行缺陷原因分析，提出改进措施，从而促进组织的过程改进。
3、软件缺陷原因分析方法
Step1：选择缺陷数据。
对小项目，可选择某一时期内发现的所有缺陷。
对大项目，可选择一个缺陷样本集合。
Step2：分析缺陷的根本原因
对缺陷逐个进行分析，常以会议的方式进行。
可对分析出的根本原因进行分类，例如：
IBM：疏忽、培训、通信失效、书写错误
Motorola：开发阶段相关、人员相关、项目相关、复审相关
缺陷原因分析工具——因果图（鱼骨图）
2.2、怎么控制软件开发质量全流程
1、需求（将测试引入到需求分析阶段，将需求的问题，在需求分析阶段就找出来）
我们知道人与人的交流总是会存在一些误会，同样一句话，心情不好与心情好的时候听起来的感觉可能会截然相反，正是因为人们之间存在着理解上的偏差，在描述需求的语言上就应该注意尽量避免歧义的产生。如果对UML比较熟悉的话，需求分析可以利用UML工具进行，这样可以减少一些自然语言引起的歧义，但是UML可能与用户沟通起来有一些障碍，因为并不是所有的用户都了解UML各种图形的意思。除了工具之外，我们可以从以下几个方面来保证需求描述的质量。
1、看句子和段落是否简短，一个很长的句子，看起来会非常困难，因此无法弄懂真正的需求，另外过长的句子和段落容易让人忽视一些需求，所以如果一个句子不能完全描述清楚需求，应该将其拆分成多个小句子。2、句子是否有语法错误，还要注意标点符号，有时，标点符号点错了，就完全成了另外一个意思了。3、是否存在模糊不清的需求，出现类似于可能，大概，或者等词汇表述的需求。4、另外注意引用的术语和词汇是否前后一致。5、是否存在一些形容词、比较性词语，比如：容易的、快速的、方便的、有效的、许多、很少、简单、复杂、最新的，界面友好的，减少、扩大，不小于等等，需要将描述性词语进行量化，并且给出具体值或者范围，要不然不同的人根据不同的理解就会得出不同的结果，最终可能跟用户最初的要求有偏差，那“炒回锅肉”的事情就不可避免地会发生。
另外保证需求质量的一个很重要的因素就是需求是否细化，如果需求不细化也会很容易造成代码的返工，于是就出现了我们的程序员尽管总是加班加点却总是不能如期的完成任务的情景。那么我们怎样才能判断需求细化的程度呢?需求细化程度确实很难把握，什么样的需求可以算是比较细了，不用再进行细化了呢?哪些需求又太粗了呢?答案是需求是否可以写出相应的测试用例，如果写不出来，就说明需求还不是很细，还需要再进行细化。
2、设计
软件架构设计在软件产品开发周期中占有很重要的位置，我们开发出来的软件产品在开发伊始到产品发布会涉及到方方面面的角色，例如：用户、项目管理人员、程序员、测试员、维护人员等等。不同的角色对架构设计的要求也不相同。例如用户关心的是需求，因此我们的设计对需求的覆盖率是多少?对于程序员来说模块是否清晰，类的功能是否单一等等，对于测试人员来说系统的是系统的可测试性。对于维护人员来讲系统的扩展性、可维护性如何?一个高质量的软件架构，应该最大限度的考虑并满足不同角色的不同要求。正是因为有这些要求，我们在进行软件设计的时候，应该进行全面的考虑。一般用来衡量软件设计质量的标准可以从以下几个方面来考虑：
1)、功能性：包括完全性、正确性、安全性、兼容性、互用性。完全性包括功能点覆盖率，重点功能点覆盖率，优先功能覆盖率。正确性包括需求一致度。安全性根据软件需求的不同有不同的安全性要求。
blog.mypm.net
2)、效率：包括产品运行的时间效率和利用的硬件资源两方面来考虑。
3)、维护性：包括架构的可改正性，可扩充性以及可测试性。如果用户的一个很小的需求变更会引起架构设计很大的变化，那么这样的架构设计的可改正性和可扩充性就比较差。 转自项目管理者联盟
项目管理培训
4)、可移植性：包括硬件的独立性、软件独立性、可安装性、可重用性。软件设计是否模块化、每个模块的可复用性如何都是应该考虑的因素。
项目经理博客
5)、可靠性：包括缺陷数量、容错性、可用性。
6)、使用性：包括可理解性、易学习性、可操作性、易沟通性。我们软件的最终目的是让用户来使用的，如果易用性不好，可操作性不好都会影响用户对软件的接纳程度。因此在软件的可使用性也是非常重要的。
3、编码
代码质量的一个很重要的标准就是代码的可读性及规范性，可读性不一定是简单的代码，而是容易理解的代码，因为过于复杂的代码难以测试和维护，同时出错的几率也会更高。如果一个方法内部的代码很长，而且使用了很多令人难以理解的数据集，这样就会带来代码维护的困难，因为很少有人能够有效地分析它们，因此也就是最容易出现缺陷和错误的地方。类之间的耦合度会造成类与类之间的相互关联，当一个类发生改变时会使其他的类发生意想不到的变化，一般从导入类的个数判断类之间的耦合度，如果导入类的个数很多，每一个导入类发生变化都会影响到该类本身，另外如果该类的public方法太多也会导致类之间的高耦合性增加。
项目管理者联盟文章
也许有的程序员会认为写出可读、规范的代码会影响工作进度。的确，对于程序员个体短时间来说为代码写上注释是要花费些时间，但如今软件开发是多人协作
周期很长的过程，写过程序的人都知道，如果自己写了不规范的代码，随着自己所写的代码越来越多，到后来需要修改某个前期写的模块时都不知道自己当初是怎么想的了，读自己的代码也需要花很长时间才读懂。况且如果随着人员的调动等其他原因，往往维护代码的程序员已不是当初写代码的人，很多情况就是读懂了一段糟糕的代码还比重新写出一段代码花费的时间还长，严重影响工作效率(有些时候还影响维护人员的心情)，反过来，如果大家都讲究把代码写成规范可读的，无疑对于整个组织来说提高总体工作效率是非常有用的。
代码质量另一个非常重要的衡量手段就是测试，通过统计测试代码所产生的缺陷情况，如严重等级分布、缺陷曲线的变化等可以从一个方面来简单地评估代码质量。
2.3、项目团队如何提高软件质量
一：软件开发的源头—需求
问题：笔者自己亲身的经历的一个项目《昆山地税短信业务系统》，用户确实也在项目的需求规格说明书上签了字，但是最后做出的东西，尽管实现了需求规格说明书中的功能，但是却是用户不想要的。
遇到这样的情况，我认为最重要的是要做到以下几点：
■ 第一要做到：根据需求开发一个Demo,让测试人员尤其是用户来确认，因为国内的很多用户不会提出需求，但是等开发商做好了软件之后，用户根据你目前所做的软件（依照现有的界面或者功能情况，然后再结合自己的业务）他们就会提出新需求了，在这方面我深有体会。所以有问题，有不明白的地方让用户早提出来，否则弄到最后大家都很被动。
■ 第二要做到：其次，在开发期间，还可以邀请客户参与软件设计规格说明书、测试计划、测试用例等的评审，当软件能基本正常工作时再次邀请客户从头到尾再看一遍（product work-through）。最后，就是开发人员和测试人员做好自己的本质工作，构建高质量的软件，进行充分的测试（但是如果客户或者用户没有足够的时间评审你的设计规格说明书、测试计划、测试用例，但是至少要能做到在软件基本上能工作的时候，把软件放在用户能够使用的地方，让用户亲自试用，因为用户对业务的了解远远比开发人员好，他们能在早期发现该软件中一些不利于用户使用的地方）。
■ 第三点要做到：重点评审需求中不明确的功能模块和存在分歧的模块，对于不明白的地方一定要弄懂，因为需求是软件开发的源头。
■ 第四点要做到：对于一些重点模块和用户业务常用的模块，要重点评审，比如说笔者前做无线POS机的系统，“销售”这个功能当然是重重之重了（因为对于零售商来说，如果软件的功能上的问题，而导致不能“销售”，那么用户对于花了钱买了这样的软件部室暴跳如雷吗？）。
二：做好单元测试，目前国内很多软件企业根本没有一个单元测试的标准
■ 笔者的亲身经历1：上海某软件外包公司的开发人员曾经私下讨论说：这个功能可能有问题，让测试人员以后去发现吧。有这样的心态开发出的软件按怎么可能没有bug，如果没有bug那就真是怪事了。
■ 笔者的亲身经历2：笔者所在的软件公司曾经为loreal做的无线pos机器（终端和服务器端居然没联通,也就是说开发人员联调都没有通过，这样的软件你敢保证没有问题吗？）
比如：SAP的单元测试做法如下：
■ 自我测试，要求开发人员在完成自已负责的模块后，马上进行测试，消除模块内部的错误 。
■ 相互测试，要求开发人员之间测试对方的模块，由于不同开发人员的思维、开发方式的不同，对方会很容易找到一些自已很难发现的问题 。
■ 代码检查，通常是由资深开发人员及开发经理来进行，从模块功能、性能、可用性、编码规范、模块集成性等角度进行全面检查。这一工作会在系统实现的各个阶段定期进行。SAP还提供了如CATT等辅助测试工具。
三：通过软件测试来提高软件的质量
（1） 测试人员最好能做到交叉测试，因为测试人员毕竟考虑问题产生思维定势，能做到交叉测试，最好了。
（2） 测试经理在测试人员的安排上，要注意以下几点：
■ 不要安排新手测试已经快要结束的项目
■ 安排好的测试人员测试水平较差的开发人员的代码
■ 安排经验较差的测试人员测试水平好的测试人员的代码
（3） 要尽可能模拟用户的真实使用环境，进行测试
笔者以前做过一个加密软件，用户反馈回来的一个问题，在公司内部环境下总是重新不了，最后才发现用户服务器的使用环境是windows2003 server打了补丁，而在公司的测试环境中虽然使用的也是windows2003 server但是没打补丁，因为环境不一致，导致在用户那里出问题了。
（4） 在系统测试阶段要弄到用户的真实数据进行测试
因为有一些Bug，只有用用户的真实数据才能测试出来，测试人员自己造一些数据是测试不出来的。这一点我在测试欧莱雅（中国）系统的时候深有体会，比如欧莱雅的会员数据系统，欧莱雅的会员成千上万，千奇百怪。
（5）要尽早做好性能测试（有可能能在早期发现一些设计上的重大问题）
比如：数据库设计方面的错误，这样的问题要早发现，如果在后期发现补救的可能性非常小。笔者以前从事过的一个系统，设计人员在设计的时候，把销售、入库、订货、会员、退库、退货这么多的业务同时放在这一张表上来操作，当在大用户量并发的情况下，很容易使数据库出现死锁等情况。
（6）测试的核心---测试用例的设计
测试人员在设计测试用例的时候，要结合用户的实际使用情况：
■ 用户是这样操作软件的吗？这样的操作符合用户习惯吗？
■ 测试用例覆盖了所有的用户需求吗？
■ 用户有非正常的操作步骤吗？比如：软件在突然断电情况下，比如在输入手机号码的位置，输入汉字，来检验程序的容错性和健壮性
（7）测试人员要多看服务器端的日志
无论是测试B/S或者C/S结构的软件，无论是在做功能测试还是做性能测试的时候一定要多看服务器端的日志文件。
■ 笔者的亲身经历1：比如查看IIS日志，tomcat日志，在日志当中你会发现很多你想要的东西，比如软件的一些潜在的错误，其实在日志当中是可以看出来的。
■ 笔者的亲身经历2：比如在欧莱雅（中国）的service.exe程序的时候，当时测试人员忽略了看日志文件信息，导致欧莱雅的服务器平均每隔2-3天重新启动--这是一个很严重的问题，但是如果早期测试人员如果多看日志的话，就能发现一些文件打开没有关闭导致内存泄漏方面的问题。
（8）软件测试注意的事项-测试人员如何迅速找出问题的经验
■ 首先测试经过变更（修改的功能）的部分，然后测试没有变化的部分。修改和更新都意味着新的风险。
■ 首先测试核心功能，然后测试辅助功能，测试产品所完成的关键和常用功能，测试完产品基本任务的功能（比如笔者近期测试点法院审判软件，首先一定要保证整个审判的流程能跑通）。
■ 首先测试能力，然后测试可靠。先测试每个功能是否完全能用，然后在深入检查任何一个功能在很多条件不同条件下的表现如何。
■ 首先测试常见情况，然后测试少见情况。使用常用的数据和使用场景。
■ 首先测试常见威胁，然后测试罕见威胁。用最有可能出现的压力和错误情况进行测试。
■ 首先测试影响大的问题，然后测试影响小的问题。测试在失效的情况下会产生大量破坏的产品部件
■ 首先测试最需要的部分，然后测试没有要求的部分。测试对团队其他人有重要意义的任何部分的任何问题
（9）测试人员一定要熟悉公司相关的业务
■ 比如我以前做欧莱雅无线POS销售系统测试的时候，其中有个测试人员做的就很好：因为这个测试人员的优点是非常熟悉销售、促销、羽西会员，薇姿会员的业务等。另外，比如测试ERP软件的测试人员，肯定要对ERP的运作模式很熟悉，才有可能找出软件的缺陷，尤其是业务上的软件缺陷才是有价值的缺陷。
■ 如果这点做不到，那么测试人员找出的软件缺陷肯定是纯软件的缺陷，价值不大。
■ 做为测试经理，你一定要求你的项目组中的至少1-2个成员对公司的产品很熟悉。
四：提高软件质量的另一个重要手段：评审
首先众所周知：测试时保证软件质量的一个重要手段；但同时想提高软件软件仅仅依靠软件测试是肯定不够的，软件开发商可以增加各个阶段的评审，比如：
需求评审，测试计划的评审，测试用例的评审，设计文档的评审，代码的评审，最后发布产品阶段的评审等等。
举例代码的评审效果就很好：
■ 笔者以前所在的公司开发了个报表，中间有个会员更新的功能，当时一个刚入门的开发人员，是这样实现系统：比如先把会员的第一个字段比如“姓名“，先update,然后再重新insert数据库；然后第二个字段比如“电话”先update,然后再重新insert数据库；然后再依次下去，这样的执行效率当然是低下的。
当然了，后来这个问题，在做代码评审的过程中，被项目组的其他程序人员发现了。也就是说这样的软件缺陷不一定非要等项目后期由测试人员来发现这样的问题。
五：给开发人员的建议：
■ 不要频繁的拷贝代码，这样很容易注入缺陷到你的代码中
■ 不要认为公司里已经有了测试人员，所以我不需要对代码精雕细琢，甚至可以马虎一点；如果开发人员真的抱有这样的心态的话，那么有测试团队的公司在软件的质量效果上肯定不如没有测试人员，但是每个开发人员都对自己的代码尽职、尽责。
六：给测试人员的建议：
测试人员应当把下面二句话作为自己的座右铭：
■ 每个测试人员都应该把“尽早测试，经常测试”（Test early and test often ）。
■ 测试人员永远记住一句话：不要让程序开发人员对你说：“用户不会进行这样的操作”为理由，拒绝修改Bug。因为，如果，你遗漏掉这个Bug，你将直接面对的是用户的的指责。
三、软件开发效率
五、参考
711
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
