总论
软件的质量一直是各企业比较头疼的问题。在这里，我将结合我自己的实践经验，来说说如何在开发过程中把好每个关口，以得到高质量的最终产品。希望能与广大关注软件质量的同仁分享！ 软件的质量保证活动是确保软件产品从诞生到消亡为止的所有阶段的质量的活动，即是为了确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动。如果象很多软件企业那样，仅仅到了产品后期进行简单的测试，是远远不够的。质量保证要做好，就要在越早发现软件中的问题，就要在过程和软件本身两方面把好质量关。具体的讲，就是步步为营，每项工作都必须审核，审核通过后才能开始下游工作。
软件质量保证的主要手段是检验，检验有两种方式：
Quality review，检查阶段产品是否与要求一致，防止软件差错到下个过程被放大。一般在各阶段的中途或向下一阶段移交时进行的检查。因为这时候还没有结果产品，所有的检查都是通过评审的形式实现的。（Verification）
测试，检验开发出来的软件的特性是否与需求相符，确保所有的软件功能需求都能得到满足，所有的软件性能需求都能达到，所有的文档都是正确的且便于使用。检查方式是由测试人员对产品结果进行正式全面的测试。（Validation）
根据上面这条思路，我们采取下面具体措施来把握软件的质量： Quality review，编码规范， Code review，单元测试，功能测试，性能测试，UAT测试。将他们具体到软件开发周期的各个阶段，如下图所示：

QR：Quality Review
CR：Code Review
一、Quality review
有些中文的资料中将其成为审核，他的目的是确保开发的过程结果的质量。根据内容和正式性上我们可将其分为两类，
一类是在开发周期中在每个阶段的内部做的小范围的审核。它是在本模块内进行的审核，目的是确保被审核内容与它的上游工作产品一致，并能够顺利开展下游工作。一般要求与本内容有关的上游人员，下游人员，以及在本内容上有技术权威的人参加。时间根据内容的多少而定，一般半个小时到2个小时。
另一类是开发周期中在每个阶段末对本阶段所有产品的审核。它是全组性的审核，较正式一些。一般由项目经理或本开发组负责人来发起和主持，并要求他们提前将会议邀请发给需要参加会议的人，以及将需要将会议的内容大体介绍给大家，以便大家做好准备。团队中与本技术有关的所有人员都要求参加，必要的话，还邀请的项目组之外的其他人员，一般会邀请有关领域的专家。会议上，会按照一定的逻辑顺序一一审核本阶段提交的所有产品。
不论是哪类审核，他们的讨论内容都是一致的。大致有下面几点：
1、 讨论被审核对象的有关问题
2、 深入地审核系统的体系架构和所使用的技术
3、 确认技术过程（Build/Release，源码控制，等）
即便是会议，它的记录和问题跟踪就很重要。每次审核都要求由主持人或由他指定他人在当天将会议的内容整理出来并置于配置管理之下。我们称之为review notes，它的内容包括：参加人，时间，议题，发现的问题，下一步要做的工作，风险，下次会议的时间（如果安排有第二次审核的话），等。这里要强调的是，对每项工作都必须当场指定一个负责人，以便责任到人。在第二次审核的时候，需要将第一次所有记录的问题全部检查一遍。
为了使审核能够更有效地开展，并真正起到提高软件质量的作用，请认真遵守如下有几条原则：
1、 某阶段未通过阶段评审不得进入下一个软件研制阶段；
2、 评审时对事不对人，评审的是产品，而不是评审生产者；
3、 评审就要挑刺，找问题、缺陷和隐患；
4、 评审组的人员面越广越好；
5、 评审组不作无休止的争论和辩驳，将争论点记录下来，供以后甄别；
6、 评审只是提出问题，没有解决问题的任务；
为了确保Quality review的质量，需要列出软件开发不同阶段上的Review内容。利用这个Checklist，主持人根据项目的具体内容安排合适的Quality review。由于各个公司的开发模式不同，checklist的内容也会千差万别。公司可根据自己的情况慢慢地建立一套适合自己Checklist，用来指导Quality review，也可以用来跟踪Quality review的执行。
二、编码规范
在多个开发人员 共同写作的情况下，必需建立一个合适的编码规范。这不仅仅是为了开发效率来考虑，而且也是为了后期维护考虑。定义规范的目的是让项目中所有的文档都看起来像一个人写的，增加可读性，减少项目组中因为换人而带来的损失。
为了保证程序源代码的可维护性，建议公司建立一套严格而合适的编码规范以约束程序员的编码习惯。目前有很多编码规范的工具，他们大多都可以很好地与开发平台兼容，设置和使用都很方便。
三、Code Review
Code Review，就是审查代码的质量。根据形式分为两种，一种是交叉代码审查，就是自己的代码由他人来检查，就象检查作业一样；另一种是代码会审，就是以会议的形式，大家共同审核代码的质量。
Code review过程如下：
1、 代码完成并提交。
2、 项目负责人决定哪些代码需要审查，并指派审核人。审查人对被审查文件必须填写code review report。
3、 通过后，源码作者在代码文件的题头信息中给出审查人和审查通过的信息，格式为：Cross review passed by XXX on year/month/day。若没有通过，则只填写code review report即可。
4、 根据交叉代码审查的结果，项目负责人决定哪些代码需要代码会审。一般需要对有问题争议的代码进行会审。
5、 代码会审。会审针对争议进行，在交叉审查中已检查过的内容可忽略。会后由项目负责人亲自或指派他人针对此次代码会审填写code review report。
6、 代码会审通过后，源码作者在代码文件的题头信息中给出通过代码会审的信息，格式为：Meeting review passed on year/month/day。
7、 将修订后的代码提交配置管理库。
Code review report的内容包括：模块名称，日期，被审核者，审核者，审核的文件名，审核的内容，参考和依据，结论，发现的问题，提出的建议，等内容
交叉代码审查安排的原则：
1、 安排的审查人一定是功能相关的人，越相关越好。这样可以节省熟悉模块功能的时间；
2、 审核的人必须对被审核的文件掌握相关领域的知识，最好是同级或上级，以便能够很快理解他人的代码；
四、单元测试
单元测试集中检验软件设计的最小单元----模块。测试之前必须先通过编译程序检查并改正所有语法错误，然后用详细设计描述做指南，对重要的执行通路进行测试，以便发现模块内部的错误。
单元测试要求开发人员来编写测试用例并执行测试。单元测试的设计，编码，和实施可能会给开发人员无形中增加很多工作量，但事实证明，好的单元测试可以发现在后期测试中60%以上的Bug。值得庆幸的是，目前有很多免费的单元测试工具，多少可以给广大的开发人员带来一些方便。
五、功能测试
为了保证软件能满足功能要求而做的测试。测试的内容就是软件的所有功能，它是测试中最重要的一部分。需要制定测试计划，规定要做测试的范围，要求，方法等。还需要制定一组测试步骤，描述具体的测试用例，旨在说明软件与需求是否一致。
功能必然涉及到逻辑，所以需要测试方案。测试方案包括预定要测试的功能，应该输入的测试数据和预期的结果。设计测试方案的目标是，确定一组最可能发现某个错误或某类错误的测试数据。
几种主要的黑盒测试的设计技术有：
1、等价类划分。将所有可能的输入数据，即程序的输入域划分为若干部分，然后从每一部分中选取少数。不光考虑输入等价类，有时还需要考虑输出等价类。
2、边界值分析。对等价类划分的补充，不是从等价类中随便选一个数据作为代表，而是选几个特定值，如等于、刚刚大于、刚刚小于边界值。
说到测试，就不得不提到回归测试。当软件经过测试发现错误，程序员对一个错误的修改可能会引起另外的错误出现，所以，在修改之后还要进行测试，这种测试就叫回归测试。
在整个产品提交之前要进行正式的回归测试，有必要给出回归测试的要求：
3、每次测试需要将所有的功能都走一遍；
4、对不同状态的bugs要求check一遍，重新定他们的状态，特别关注状态改变的bugs。
5、check Bugs时，注意走一下与此Bug 有关联的功能，以及与此Bug相类似的功能。
六、性能测试
为了保证软件能满足性能要求而做的测试。要求设计测试用例，模拟错误数据和软件界面可能发生的错误，测试各项性能是否达到预期的指标。如果是基于Web的系统，请注重下面三方面的测试：
1、安全测试：安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用，有无漏洞。
2、负载测试：通过模拟大批量用户的并发请求，给系统施加较大的负载，这时检测整个系统处理交易的能力。
3、压力测试：在反常数量或资源（使用的容量达到规定的极限）的情况下执行应用程序，检测中间件系统在长时间、高负载情况下的运行处理能力，从而检验系统的稳定性。例如，①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②定量地增长数据输入率，检查输入子功能的反映能力；③运行需要最大存储空间（或其他资源）的测试用例；④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。使用Jmeter工具能够方便地测试系统的负载。