单元测试

　　集成测试

　　系统测试

　　程序的常规步骤，但实际的软件生产过程中，这几步骤远远做不到，应视情况而定。

　　为什么做不到？

　　这与很多因素有关，如：公司的规模、性质，软件的规模、性质，软件的开发类型（有些只是demo版本），还有一个原因是由以上派生出来的原因，团队的管理制度（有没有强制去做一些友好的步骤，比如单元测试，大家都知道好，为什么都不去做呢？）；

　　单元测试：

　　一般研发部门的领导都是要求开发人员编写单元测试代码，因为领导凭着自己的经验能够意识到单元测试的重要性，基本上每个小的功能都要编写单元测试。虽然是测试，也不一定非得在编写完代码之后编写，因为单元测试有其特殊性，在开发某个功能之前，毫无疑问，工程师已经对模块中每个小功能的实现做了详细的思考和规划，一个功能应该怎么实现，心中了如指掌，在这个前提下完全可以预先编写单元测试用例，而且编写单元测试，同时也是全面分析某个功能可能出现的任意bug的过程（这是一次很重要的分析过程，从而会在很大程度上避免一些错误，而在现实中，这种问题出现的太多了，给人的感觉是程序员只是一味地实现功能，而不去考虑功能实现的完整性、健壮性），如此，编写好的程序只要一运行，能利马知道这段代码的好坏；另外一个好处是，单元测试能“监听”以后开发中的代码改动、模块衔接所出现的大多错误，从而大程度的避免了新的bug，是这是磨刀不误砍柴工吧；

　　集成测试：

　　以前总是以为书上说的大道理不如实际应用中的经验来的实在，走过一段路后发现，其实不然；我的总结是，当你的成长遇到瓶颈时，理论开始起作用了，我想说的是“软件工程”里说的内聚与耦合得概念。初学时不理解他的真正含义，如今用到时才感到他的重要性。对于模块的开发者而言，像要建造一架飞机，程序员的的工作是生产一个飞机翅膀或者制作一个飞机轮子。假如说你制作的轮子的主要实现还是靠了机身本身的主干结构，而模块本身并没有太多的新东西，只是改改颜色，增加点花纹什么的，可以看出，这个轮不能从飞机身上摘下来，或者摘下来很费劲，并且不能使用，失去了本身的意义；它的核心再机身，而不是轮子本身，又假如你制作的轮子，整个功能的主题都在轮子上，飞机使用时，只需要挂在上去即可，如果飞机不想使用，摘下来换别的即可；这正好类似程序模块见的内聚、耦合概念，让每个模块在不影响使用的前提下尽量的提高内聚性，降低模块之间的耦合性，这样的好处是，利于模块的重用，方便问题的定位，有利于程序整体结构的工整；（个人认为类的思想也有这样的好处，另外类的一个作用是重用，重用以减少代码量）；在软件测试时，集成测试是耗时长，重复多的、重要的环节；大部分bug再这个阶段被发现，我再测试过程中感受多的是，模块之间的耦合性处理的不好，造成了改动一个模块的功能，间接触发其他模块的功能发生错误（没有完整的程序需求和详细设计，是产生这类bug很重要的因素），而且修改时程序员总是很难意识到这类问题的发生，因此也造成了bug定位难的情况。

　　这个阶段的回归测试，是个比较累人的重复流程，每次程序的改动后，为了避免造成关联模块的bug，改动完后都要进行相关的回归测试，回归的深度基本上设计所有相关模块，因此这种测试，使用自动化测试配合手动测试比较具有实际意义；

　　系统测试：

　　程序提交前的后一轮测试，实际上这轮测试可以想想成工业上的“试车”，是现场调试。涉及到了程序使用的各个方面，因为是在现场的环境中测试，因此这个阶段测试出来的bug更具有实际意义；一般来说这个环节是在实际环境中做更复杂的集成测试的步骤，避免出现bug的因素主要是需求的准确性；这个阶段出现较多的bug一般为，网络方面的，一般都会涉及到网络后台、网络的稳定性，而这点在集成测试时往往会忽略。

　　侃了会老生长谈的东西，大约每个测试人员都不怎么陌生这三个环节，也作了一些规避这些bug产生的研究，避免一些低级bug的产生。然而，现实让人泪奔；

　　为什么要这样说？（网友）

　　1、是公司重效益，轻测试

　　2、程序规模小，不需要系统测试

　　3、程序员基本没有养成做单元测试的习惯

　　4、团队管理没有强硬的原则

　　5、有些程序根本没有需求规格说明书，何谈，需求分析

　　一般的外包程序，都是简单测试一下，连提交bug的必要都没有，一边测试一边改正（到底这样的程序是否需要做bug管理，我自己也不知道），没有需求规格说明书，没有需求分析；我在想对于开发周期比较小的程序如果做完整的开发测试流程，是否会在时间上得不偿失，因为小程序bug还是相对部较少的。任何流程规则的制定，看来要以现实为依据才是好的，没必要可以的遵守固有的原则，好用万岁！大型程序，还是需要做完整流程的；

　　以什么为标准来决定是否需要做bug管理呢？（待答）

　　成本与质量之间的一个权衡