如何进行软件质量控制工作？

　　为了开发出符合质量要求的软件产品，在软件开发生存期过程中始终贯彻着质量管理和控制。概括地说，软件质量就是“反应实体满足明确的和隐含的需求的能力的特性的总和”。具体地说，软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的和隐含特征相一致的程度。那软件质量控制有没有一定的标准呢？小编现在就来揭晓答案！

　　标准

　　(1)软件需求是度量软件质量的基础，与需求不一致就是质量不高。

　　(2)指定的标准定义了一组指导软件开发的准则，如果没有遵守这些准则，几乎肯定会导致质量不高。

　　(3)通常，有一组没有显式描述的隐含需求（如期望软件是容易维护的）。如果软件满足明确描述的需求，但却不满足隐含的需求，那么软件的质量仍然是值得怀疑的。

　　即使有了标准之后，，我们又应该怎样才能保证软件的质量呢？软件质量的控制牵涉到很多变量，关键是在每个步骤都需要管理和控制。需要规范化整个软件开发过程。

　　1.需求的时候做需求评审。对于任何软件项目过程而言，需求不仅仅是一个不可避免的环节，也是软件开发的基础。往往用户需求明确、变更少的项目的成功率就高，而那些用户需求混乱、变更频繁的项目几乎从一开始就注定了失败的命运。但是怎样引导客户来提出确切得需求，就需要很好得沟通技巧，在客户需求了解得前提下，针对开发项目所做得技术需求，应该进行评审。

　　2.概要设计时体系结构的评审、多次讨论。并保证足够的时间和精力来充分讨论所做的概要设计是否真正满足需求。不能以进度太紧等借口将概要做的马马乎乎，直接开始代码编写。（这也是以前做项目时最常犯的毛病。）项目经理必须有胆量有信心顶住老板的压力，很多BOSS衡量进度就会问，你编了几行代码了？怎么还在这里什么都没做？

　　3.详细设计尽可能统一、规范。编码时要有统一的编码规则。命名规则等约束。即使天才程序员也应遵循适当的规范。否则大家以后在维护天才的代码的同时，肯定会在心里大骂。

　　4.测试要在需求和设计阶段就开始。这里说的是CodeReview，也叫PeerReview。这可能是目前我们能有的对代码质量的保证最重要的环节（之一）了。不能等到编码结束再进行。再编码过程中的单元测试应得到重视，程序员之间的交换测试可以取得一定的效果。发现问题越早，麻烦越少。

　　5.对重要的功能实现代码做CODEREVIEW。为避免流于形式，在会前要充分协调，作好准备。

　　6.版本控制。需求变动控制。适当地使用工具进行版本和需求变更的控制。避免后期版本混乱，做无用功。

　　7.当然还有文档，要做就做规范，做踏实。应付检查和交差的文档不做也罢，浪费时间而已。文档太难控制的话，在编码时作好注释也可作为一种方法。

　　8.完备的测试集。写代码的都知道，很多时候，写出可以测试所有情况的单元测试和综合测试，需要的工夫可能比写函数货程序本身要费劲的多。然而，完备的测试集是代码持续开发中保证正确性的第一道防护线，不论是后期的修改、重构、移植等，都会事半功倍。

　　而现实中是：

　　1.产品中没有白盒测试的概念，从最底层代码开始，经过多年的修改，已经是千疮百孔。具体一个函数有多少隐含的问题要进行测试、统计一下。

　　2.代码不进行重构，公司领导不重视重构，导致代码腐烂很严重。很简单的事实，一个配置变量在多处进行维护着，一旦进行修改，就要去修改很多处。再加上模块充斥着几千行的类和几千行的文件。最大的一个类triadapter达到了16258行，welldatamanager17055行，类使用起来倒是很方便，要数据相关的东西，你只要找welldatamanager就好了，然后你就在几万行的代码中徘徊吧。其他的代码重复、过度依赖等等问题就更多了。

　　3.黑盒测试力度不够。七八个人编码，两个人进行测试。并且随着时间长了，固定的两个人对软件产生了习惯性，导致很多地方测试不到。

　　4.没有规范的软件开发流程。软件设计、测试用例编写

　　5.测试时间不足，软件发布前一周还在进行软件功能的开发。

　　6.需求不稳定。需求反复修改带来的问题。比如绘制刻度的时候，现实垂直画、后来水平画、再后来还是垂直画。

　　小编结语：

　　“20世纪是生产率的世纪，21世纪是质量的世纪，质量是和平占领市场最有效的武器。”美国著名质量管理学家约瑟夫•朱兰博士的这句话，道出了质量控制在今天产品开发中的地位。随着经济全球化进程的不断推进，要增加产品的国际竞争力，产品质量作为经济发展的战略问题变得越来越重要，软件质量正被视为软件企业的生命。

　　看完本文后，您是否对软件质量控制有了一定的了解了呢？欢迎大家跟小编分享！