软件质量控制

Mario洁

软件质量得控制牵涉到很多变量。关键是在每个步骤都需要管理和控制。需要规范化整个软件开发过程。
1.需求得时候做需求评审。但是怎样引导客户来提出确切得需求，就需要很好得沟通技巧，在客户需求了
解得前提下，针对开发项目所做得技术需求，应该进行评审。

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

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

4。测试要在需求和设计阶段就开始，不能等到编码结束再进行。再编码过程中的单元测试应得到重视，
程序员之间的交换测试可以取得一定的效果。发现问题越早，麻烦越少。

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

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

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



而现实中是：

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

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

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

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

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

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