软件质量控制

引用：

软件质量得控制牵涉到很多变量。关键是在每个步骤都需要管理和控制。需要规范化整个软件开发过程。
1.需求得时候做需求评审。但是怎样引导客户来提出确切得需求，就需要很好得沟通技巧，在客户需求了解得前提下，针对开发项目所做得技术需求，应该进行评审。
2。概要设计时体系结构的评审、多次讨论。并保证足够的时间和精力来充分讨论所做的概要设计是否真正满足需求。不能以进度太紧等借口将概要做的马马乎乎，直接开始代码编写。（这也是以前做项目时最常犯的毛病。）项目经理必须有胆量有信心顶住老板的压力，很多BOSS衡量进度就会问，你编了几行代码了？怎么还在这里什么都没做？
3.详细设计尽可能统一、规范。编码时要有统一的编码规则。命名规则等约束。即使天才程序员也应遵循适当的规范。否则大家以后在维护天才的代码的同时，肯定会在心里大骂。
4。测试要在需求和设计阶段就开始，不能等到编码结束再进行。再编码过程中的单元测试应得到重视，程序员之间的交换测试可以取得一定的效果。发现问题越早，麻烦越少。
5.对重要的功能实现代码做CODEREVIEW。为避免流于形式，在会前要充分协调，作好准备。
6。版本控制。需求变动控制。适当地使用工具进行版本和需求变更的控制。避免后期版本混乱，做无用功。
7。当然还有文档，要做就做规范，做踏实。应付检查和交差的文档不做也罢，浪费时间而已。文档太难控制的话，在编码时作好注释也可作为一种方法。

 

而现实中是：

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

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

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

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

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

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

7.