软件测试流程

　　集成测试51Testing软件测试网 e3c.O7[[0v{

0E}+?:_qh0　　系统测试51Testing软件测试网6P~2DI ]m(V~

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

Z)X4yV,pe9H4|I0　　为什么做不到？

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

　　单元测试：51Testing软件测试网,H/P{Lmhfx)`3z

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

jy X8pvX1m&u@0　　集成测试：51Testing软件测试网g?^L7m(]

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

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

　　系统测试：

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

1~Kg:Z!]0　　侃了会老生长谈的东西，大约每个测试人员都不怎么陌生这三个环节，也作了一些规避这些bug产生的研究，避免一些低级bug的产生。然而，现实让人泪奔；51Testing软件测试网p X,x I#T|8lq-H

　　为什么要这样说？（网友）51Testing软件测试网s+b$S\/_6q

.yPi9Q1w,gv,|t0　　1、是公司重效益，轻测试

　　2、程序规模小，不需要系统测试51Testing软件测试网DQ\5Z-\(h

1mh IJvQH1[A0　　3、程序员基本没有养成做单元测试的习惯51Testing软件测试网&XtI7W"R8Q!Jl'YyT

J@H!W?5a_DB0　　4、团队管理没有强硬的原则51Testing软件测试网.u1Y3u8h+u ig/[

{6~/pS;D9V0　　5、有些程序根本没有需求规格说明书，何谈，需求分析51Testing软件测试网J
F$k/y,j1I\R_XkC

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

　　以什么为标准来决定是否需要做bug管理呢？（待答）51Testing软件测试网U.YAYz8^q

9G)PpC
d0　　成本与质量之间的一个权衡51Testing软件测试网|9NsC&Y-zO3@2aqO6x