（研发管理）研发改进体制
研发改进体制（草案）
版本 创建 日期 备注
王振刚 2004-4-14 创建
王振刚 2004-4-21 修改，添加一些新的内容
王振刚 2004-4-27 添加和修改部分内容
目录
目录 2
测试介绍 4
测试的分类 8
单元测试 8
集成测试 10
系统测试 11
验收测试 12
测试方法 12
黑盒测试 12
白盒测试 12
灰盒测试 12
测试方面 12
测试改进方案 13
测试工作需要回馈 13
测试工作需要总结 14
需要交流平台和形式 14
采用的方法 15
让别人给服务说话，清楚认识自己 15
自己回头看 16
了解同类产品 16
提高自身素质 17
如何提高程序能力 17
耳濡目染 17
自己连内功 18
实践中检验 20
测试发展 20
如何提高测试 20
制定完备的测试计划 21
提高案例设计水平 21
逃避测试的误区 25
如何调整团队的作战能力 28
歪曲理论推理 31
正确理解自动测试 31
测试的几中方法 33
网络方面的测试方法 33
数据库测试要点 33
网络游戏测试要点 33
C/S结构测试要点 33
WEB测试要点 33
嵌入式软件的测试方法 33
手机软件测试 33
MP3软件测试 34
通用软件的测试方法 34
办公类产品测试 34
杀毒类产品测试 34
工具类产品测试 34
ERP软件的测试方法 34
验证测试 34
测试管理工作 34
开发方面 36
开发分析 36
问题分析 36
目前存在的问题 36
产品方面 39
第一步、增强开发质量意识 40
第二步、增强测试本身素质 40
第三步、对产品开发过程中版本编译的控制 40
第四步、进度控制 40
第五步、控制进度问题 40
测试介绍
测试现在被普遍认为“保证产品质量”这个笼统的说法
下，而测试本身是什么呢？今天我们就测试本身跟大家一起
讨论讨论。
测试在国外已经发展比较成型了，而国内的测试现在还
处于摸索阶段，至于超着那个方向去发展，我觉得大家目前
还是处于比较迷茫的阶段。
主要原因是：国内软件产业起步晚，而且质量意识不强，造
成了软件工业发展缓慢，配套行业（测试发展缓慢），我觉得
这个很正常，因为从人类历史发展的角度来看，这个是必须
经历的阶段，从有这个概念到摸索，目前国内的测试应该处
于沉思期，主要是没有一个全套的指导思想，另外一个全新
的行业发展方向不明朗，造成了测试现在成了大家进入企业
的跳板，要么就是觉得自己的能力还不够，目前只能从事测
试，要么就没有编写程序的能力，但是同类产品比较了解，
所以做测试。
我对这个问题有自己的看法，我觉得在企业发展的同时，个
人要发展，那么个人怎么发展呢？（我说的是测试人员），那
就是技术不是针对产品的，因为现在的企业测试都是把测试
过同类产品当成了经验，那么这个人的经验积累就这么多了，
可增长和发展的空间不是很大。如果我们把测试的方法整理
成技术，那么他上一个规则或者说是一个标尺，我们只是分
析这个产品的那个方面需要用什么方法来测试，那么积累就
不会被约束，但是不能撇开经验，因为经验本身是设计出好
的案例的基础。
我们再看看测试案例的设计，测试案例的设计在国内现在是
一些刚刚入行的不会写程序或者程序功底比较差的人在写案
例，那么这些人设计出来的案例只是包含了整个测试过程中
功能测试的一部分案例而已，因为他们不懂得或者不理解程
序，不是从原理上去分析产品，不是从逻辑上去分析产品，
而是从用户使用的角度去分析产品，这样设计出来的案例的
可行性和可信度多大呢？大家可想而知了。所以我们在整个
引导大家的过程中，从技术和方法，结合具体实例和针对不
同的类型的产品的测试方法进行跟踪和描述。
首先，什么叫测试？测试干什么？
测试，是在开发过程中的一种活动，它是分白盒测试和
黑盒测试。在不同的阶段不同的人所承担着测试这个角色，
我们把整个活动统称为测试。
测试的工作内容主要包含了设计测试计划，设计测试案
例，执行测试，进行测试总结。
执行测试是在产品开发的整个过程中进行的，包括了单
元测试，系统测试，集成测试，系统测试和验收测试，那么
不同的阶段测试的重点不同。
单元测试的重点是函数级，包括需求，包括算法，包括
接口预留等内容。
集成测试是指把小模块结合起来，测试的重点是输入输
出数据，参数的处理，错误预处理，接口规范，参数约束等
测试内容。
系统测试的重点是功能性质，它的测试重点是按照需求
来对照测试，主要是功能实现的情况，包括功能使用逻辑和
操作逻辑，操作系统，兼容性（软件和硬件）等内容。
验收测试，主要是合同性质而言的，在国外现在软件外
包情况比较多，那么双方按照合同规定履行自己的职责，把
功能按照合同约定的形式条条比对。这是主要方面，那么在
企业内部，验收测试是除了功能验收以外，还包括易用性，
软 件 的 亲 和 度 等 方 面 的 内 容 。
序
我是一个充满激情的人，我把所有的激情投入到生活的每一
个空间。
我是一个不停折腾的人，因为生活在不停的折腾我。
我是一个不服输的人，因为我知道这个社会不会同情弱者，
只有不停的折腾，才有可能把握自己的命运。
我是一个傲慢的人，因为我把自己已经当成是行业的开拓者。
我是一个平和的人，因为我和不同的角色在对话
我是一个开放的人，我会将我知道的或者了解的用无私的信
鸽 传 播
关于产品开发流程分析（初稿）
王振刚（2004-4-14）
测试的分类
单元测试
单元测试是在测试过程中的最小粒度，它在执行的过程中紧密的依照
程序框架对产品的函数和模块进行测试，包含入库和出口的参数，输
入和输出信息，错误处理信息，部分边界数值测试。
这个部分的测试工作在国内现在是开发人员进行的。我相信未来的发
展应该是测试工程师来做这个事情。那么需要测试人员需要深刻的理
解程序，理解需求，理解设计，这样才能发现问题。
还有一种在国内先在操作的方法，就是当一个模块给某个开发工程师
以后，需要他给大家讲解他要完成这个模块或者函数的整体流程和思
路，进行统一评审，使得问题能够暴露的更充分些，这样做的目的有
以下个，第一，使得大家对设计者的思路明晰的理解，以便以后调用
或者配合的时候能够真切的提出需求或者相对完美配合。第二，在评
审的过程中，如果发现问题，那么大家可能没有犯过，这样就会更加
提高警惕，如果犯过，就会回想当时自己怎么解决的或者规避的，使
得大家能够在错误的过程中快速提高。第三，可以对平常犯错误进行
一个积累，我觉得这是生动的教科书，可以使得新的人员在新上手的
时候遇到这样的问题以后，我们就可以给他一个解决问题的方法或者
方向。
回顾，我们上面给大家介绍了两种方法，第一种就是通过在开发的过
程种进行测试，由开发（测试）工程师写测试代码，对所编写的函数
或者模块进行测试，第二种就是通过代码互评发现问题，将问题进行
积累，形成知识积累库，以便使得新人在同样的方面不至于再犯错误。
单元测试非常重要，因为他影响的范围和宽度比较大，也许由于一个
函数或者参数问题，造成后面暴露出很多表象问题出现。而且如果单
元测试做不好，使得集成测试或者后面系统测试的压力很大，而且项
目的费用和进度可能就会飚升。
对单元测试，现在用 CPPUnit的比较多，市场上也有其他对应的产品，
他们在不同的软件单位不同的阶段。正确的理解单元测试的重要性是
意识，需要在过程改进种不停的总结，慢慢的积累，将质量意识渗透
到整个开放过程中的各个环节。
保证单元测试顺利进行，需要渗透软件工程的很多思想，把 CMM和跟
踪机制建立起来，问题的分类、跟踪，如果把整个活动都渗透了，工
程师的意识都增强了，
集成测试
集成测试是在保证单元测试进行后进行的一个动作，能否集成的标志
不是所有的代码编译通过了就算是可以集成了，而是所有的能够在这
个虚拟环境下能够正常运转。
在集成测试种一般采用的方法是数据驱动或者桩驱动，因为集成测试
不能看到产品的表象，因为他是一些数据流的中间段，我们渴望能够
对中间数据进行分析，就可以知道或者就渴望知道流程或者算法中有
什么不妥当的地方。
集成测试比较适合做成自动化测试，我这里就不讲详细的方法，到后
面的自动化测试介绍中，我会提到这个方面的问题。和大家一起揭开
测试自动化的神秘面纱以及给大家讲一些构建，冒烟的概念。
集成测试也是不可缺少的一个部分，很多单位为了赶进度，会将这个
部分省略掉，就甩手给测试小组，如果没有对应的测试小组，就会是
程序员进行简单的使用后就交付市场，危险，这是个定时炸弹。因为
他时刻有可能产生市场对企业影响的额度，以及企业本身的声誉问题。
系统测试
系统测试是测试过程中的一个转折点，因为在现在国内的企业中，不
同的产品面对不同的用户群体，所以有的企业经过第三方产品的验收
测试，有的企业则没有通过验收，而是一些工具类或者通用类的产品，
那么他的验收测试是经过广大的用户群来做的，也就是说凡是通用类
产品的系统测试必须严谨测试以后，才可以投放到市场。但是对于对
企业或者其他专业性单位定制的产品我们必须进行验收测试。
系统测试工作是一个重复老动很多的工作，需要在工作种把握几个重
点，系统测试是保证系统能够正常运转，包括了功能，易用性，健壮
性，压力，边界数值设定等各个方面的内容。要想在这个阶段的工作
种找到乐趣，就要不停的摸索，找出能够将机器代替人的所有的东西，
找工作的快感。
系统测试需要有广泛的知识面，对测试工程师的要求需要了解和掌握
很多方面的知识，需要了解问题可能出现的原因，已经出现这个问题
可能是由于什么原因造成的，以便我们能够及时的补充测试案例，保
证 或 者 降 低 产 推 出 的 风 险 。
验收测试
验收测试类似于客户验证产品的质量，在软件行业发展的过程中，各种承包项目类似于国外
的外包项目将会不断的出现，那么外包项目的质量问题需要大家共同讨论。
外包项目的操作流程是当承包方提出具体的需求，然后有承包商来按照需求来开发项目，包
括单元测试，系统测试，集成测试等各个方面的测试，经过被承包商测试后的产品提交给外
包商的时候，需要进行验收测试，验收测试可以是外包商本身提供一套测试方案，然后对照
具体的需求，进行产品验证测试。也可以是双方找一个共同的第三方，进行产品的验证测试。
验收测试的测试重点主要是产品是否按照需求开发的，而不从针对功能进行的测试。所以验
收测试基本上不需要多少专业水平，也可以是承包商找到使用该产品的用户，来体验该产品
是否能够满足使用要求。这样以来使得双方可以有一个共同的平台，避免商业矛盾的产生。
验收测试的测试手段目前来说还是靠用户体验。
测试方法
黑盒测试
白盒测试
灰盒测试
测试方面
案例设计问题
分析：因为现在从总体上看，案例设计很细，但是重复和不必要的东
西太多了，个人认为原因有三个：
第一、设计案例的不了解产品设计的框架（从程序概念上讲）
第二、案例的设计没有一个反馈，涵盖情况不知
第三、开发产品质量意识淡薄，测试压力太大
第四、测试人员的素质分析没有，我们看不清问题出现在那里
进度问题
第一、测试的整体计划里面没有重复考虑风险，时间问题紧迫
第二、回归测试无法保证
测试改进方案
以上对存在的问题进行了分析，我们需要找到自己的弱项在那里，
那么从现在看来，我们现在测试队伍没有建立，没有形成相应的体制。
主要表现在一下几个方面：
测试工作需要回馈
测试案例执行跟踪和统计不明确。
问题：如果测试案例不进行跟踪，无法证明或者检测我们案例设
计的好坏，无法改进工作方法或者改善我们的思路，所以需要通
过这里把自身问题看清楚，这样有利于工作的开展。
在我们日常的生活中，存在这一种现象，因为这种现象导致了测
试一些列的发展。大家普遍认为，测试的含金量不高，导致了测
试工作就是一些不愿意做开发或者没有能力做开发的人来做，其
二，他们对测试设计的测试案例从不认真的审查，认为就那么回
事情。出现这种问题的愿意是由于开发还没有清楚的认识到测试
是一个服务部门，是为他们服务的，从私利的角度来讲，我们抛
开项目的关系，测试的主要工作是为了帮助开发将自己写的代码
更实用一些，让市场更认可一些，让开发人员的成就感强一些。
如果大家都从这个角度考虑问题，那就可能缓解或者解决上面的
第二个问题。
关于测试含金量不高的说法，我不赞成这个说法，在目前国内的
大环境下，测试是这样的，但是它在朝自己预想的发展。而开发
的发展除了新的语言在发展以外，思想或者体系我们能增加或者
能设想的空间已经不多了，而对于测试是一个全新的行业，他发
展首先需要支持，需要理解，我相信国内测试在 5~10以后，发展
更加迅猛。因为就算是现在很小的软件企业，已经开始重视测试
了。
测试工作需要总结
测试的总结机制没有
i. 测试案例的执行情况
ii. 测试案例发现问题情况
iii. 测试案例的冗余情况
iv. 测试周期内的曲线项目进展情况
需要交流平台和形式
信息交流平台和积累
v. 资源共享
vi. 信息共享
vii. 提高自己在开发中的信心，不要总是喊狼来了
viii. 人和人之间需要沟通和认同，团体也一样
采用的方法
让别人给服务说话，清楚认识自己
让开发人员说话，让对应开发人员给我们的测试案例提出相应
的意见，保证测试案例的覆盖面，以把握重点。
在整个开发过程中，由需求，开发，测试完整的团队，准确的
说还有市场部分，我们都把它归结为需求的搜索和定义部分。那
么在整个产品研发的过程中，各个部分需要完整的配合，否则整
个产品都不能按时上市。作为为开发和需求服务的测试部分，应
该摆正自己的位置，我们是一个团队中的一部分，是不可以缺少
的一部分。
人贵有自知，也难有自知。只有在认识自己的基础上才能选择
好自己的生活道路。首先要认清自己的能力。人的能力可以有天
壤之别，但只要不辜负自己这块材料，也就可以问心无愧了。认
识自己尤忌自大，这会使你为自己订立高不可攀的奋斗目标，到
头来高不成、低不就。其次要认识自己的本性。心理学家把人分
成六个类型：经济型、理论型、社会型、审美型、宗教型和权力
型。要选择一个适合自己本性的生活目标。
看清楚了自己，就可以很好的改善，也能把自己的事情做好，
同时呢，才能更好的服务。
自己回头看
让执行测试案例的人员反馈给我们数据，说明案例的冗余情况，
这样会慢慢提高自己的设计水平。
因为人们习惯于谈成绩，问题在成绩中可以淡化，我不同意此
观点。
其实在现实生活中，大家都经历了很多事情，都学会了总结，
可是同样的错误在现实中会多次出现，为什么呢？是因为回头了
多次，没有总结，总结了没有执行，执行了没有改变方式，改变
方式了但是没有认真考虑，还是错的。
把自己犯的错误列举出来，然后找出出现问题的真正原因，才
是自己最大的进步。如果淡化错误，将来可能就会将成绩磨灭掉，
所以积累，回头是工作中需要重视的问题。
了解同类产品
让市场人员反馈同类产品的问题以及市场对我们产品的需求。测
试过程是反映当前产品的质量，为什么要研究竞争对手的产品呢？
首先，测试中包含易用性测试，测试什么内容呢？就是测试怎么
好用，客户是怎么用的，我们怎么设计更贴近用户，那么不研究
竞争对手，我们怎么可能占领上风。
其次，了解竞争对手的产品，有利于测试工作捕捉重点，使得工
作开展有利有节。
可谓知己知彼，百战不殆，所以在现在的市场竞争中，了解同类
产品才可能发现对方的缺点，给以打击，发现对方的优点，快速
学习，闭门造车必定失败。
提高自身素质
从程序的概念理解产品，这样测试案例可以设计的比较有针对性。
常言说得好，“识重于才”，而见识却往往是生活阅历造就的。对
于一个初出茅庐的人，智者的指点是至关重要有时甚至是决定性
的。回想我十年来的经历，很多失败其实是没有人指点而造成的。
要寻找一个精神上的导师，他可以是你的父母，也可以是其他师
长。他阅历丰富而又不拘泥于自己的老经验；他能在紧要关头给
予你原则上的指导和精神上的支持。有时候仅仅是他失败的经验
就会使你受益匪浅。
如何提高程序能力
耳濡目染
让开发或者设计人员在讨论开发方案的时候参与旁听，耳濡目
染。其实这只是一种辅助的手段。
电视剧《霍元甲》播出以后，得到大家的欣赏。原因是因为他
本人身体虚弱，所以父亲从小不让练武功，而生长在那样的环境
中，他天天可以看到兄弟们在练功，招式已经记忆在心理，但是
苦在没有练功的机会，他利用体力劳动的过程中，改变劳动方式，
趁机练功，后来发展到独创“迷综拳”。
程序设计和开发是一个硬功夫，也是一个长远的事情，它是一
个积累的过程，不能一蹴而就，需要苦心练，多些理解，多些思
考。
面对程序开发，不要有太多的压力，因为程序开发就跟你学说
话一样，因为语言本身有很多通性，高级语言和低级语言本质上
差别不大，所以扎实的从基础的东西学起，这样才能完全的积累
下来。
计算机发展速度很快，各种概念，各种语言发展都很快，掌握
实质，不断学习，才能把握。所以还是需要多看，多想，多练。
自己连内功
从自身做起，了解程序架构和开发模式，努力提高理解和产品
的单元测试或者组件测试能力，这样以来可以了解程序的很多算
法，使得在产品的开发过程中就能把问题发现并且能够得到及时
的解决。
其次能够提高大家参与到项目的荣誉感，因为在测试本身是一
个服务性的行业，那么服务行业的特点是不停的改变思路，改变
服务模式，提高服务质量，当服务做好了，那么在整个研发中就
可以找到自己也是其中一个分子的感觉。
其三，连好内功，为自己将来提高工作效率，进行一些自动测
试以及从程序架构的概念上设计测试案例提供了技术保障。
以上是自己练好内功的用途。
在过去社会中，有很多擂台赛，目的是切磋技艺，弘扬中华武
术，各个门派直接交流和学习的过程，为了在擂台赛中取的很好
的成绩，我们需要努力练功，其次是多学本门派和其他门派的武
功，或者自创武功，在擂台上能够发挥的淋漓尽致，因为武功的
最高境界就是没有招式，要达到这个境界，需要内功深厚，避免
走火入魔，需要毅力，需要创新。
理论就是理论，无论在那里看到的理论都是一定的基础的，因
为所有的理论基础需要一个证明此理论的平台或者条件，所有一
定要看，想，用。看别人是怎么用的，在什么情况下用的，用的
目的是解决什么问题，在什么样的环境下能够做出来，需要什么
样的支撑；想自己现在目前是否有这个环境，就目前的环境能够
做什么，如果要搭建对方的环境需要多长时间，这个做法中存在
什么不托的地方，有什么需要改进的地方；在自己工作的环节中
找找看，看自己是否适合用这个东西，如果适合，怎么用，用到
什么程度，如果非常认可别人的做法，需要衡量需要多少资源和
时间，努力找自己的结合点。
千万不要再我们看到一个理论或者方法的时候就去推动它，或
者原理实践过一个什么思想就想在新的环境下实践他，都是不可
取的。好的事情或者好的做事方式他需要一些条件支撑，一旦硬
套，就可能出现问题。
实践中检验
尝试做一些灰盒测试部分（目前暂时是想法，但是还不完善）
测试发展
测试在国内还是处于摸索阶段，在过去的发展阶段，大家只是
初步针对不同的软件产生了不同的测试方式，但在操作方法，操作流
程等方面还需要继续摸索。对潜入式软件来说，行业内始终认为潜入
式软件是最难进行测试的，因为他需要很广的知识面，需要对各个点
的设计原理进行分析和测试。
在目前国内开发眼中的测试还没有形成概念，我们需要不断的
改变形象，加深他们对测试的印象，以便我们获取更多的帮助和协助。
测试未来发展需要两条腿走路，这样能够在各个环节保证产品
的质量。
第一步，系统测试继续练内功，将案例设计的能力提高
第二步，需要进行灰盒测试，对产品进行代码级的测试
第三步，需要进行部分白盒测试或者由开发人员进行执行
如何提高测试
提高测试需要从几个方面着手，其实只是自己的一些感觉，不一定就
需要按部就班，需要找自己适合的点。
制定完备的测试计划
清楚的认识测试计划，测试计划是一个文档，能够保证整个研发过程
中顺利执行的一个指导性文档，它描述了几个方面的问题。
第一、 描述了项目的目的
第二、 描述了项目的开发周期
第三、 描述了在测试中遇到的技术
第四、 描述了测试案例的设计周期
第五、 描述测试案例的执行周期
第六、 描述了测试过程中用到的工具或者技术
第七、 描述了测试过程中用到的资源情况
第八、 描述了测试过程中可能遇到的风险以及规避方法
提高案例设计水平
明确了解现在目前流行切实用的几种案例设计的方法，因为在不同的
产品不同的要求有不同的设计手段，我们需要不断的学习和总结，在
为了测试领域中，许多新鲜的词语都会出现。
这种方法类似与工业领域的随即抽取统计分析法，但是工业性质牵扯
到损坏或者人为原因，统计出来存在这偏差，但是应用与软件方面，
虽然存在着偏差，但是不可能象硬件那么偏差很高。
等效法
明确测试的目标，一般适合用到的范围是，制定被测试的对象是在满
足某个条件的区间内的所有的所有数据。
案例设计方法：从其中区间数据段中选择任意一个或者两个数据，只
要这个数据满足了，那么其他的数据就是满足的。
我现在举一些例子，来说明等效法在测试过程中如何应用的。
范例 1：在登陆某系统需要验证用户名，要求是长度是最小是 6位，
最长是 14位，名字中可以包含数字，但是不能以数字开头，可以包
含各种符号，不能包含中文。
1、随意字母组合成一个 12位的姓名，测试是否可以通过验证。
2.、随意生成一个长度 12位的姓名，测试是否可以通过验证
3、测试以任意一个数字打头 12位的姓名，测试是否可以通过验证
4、测试姓名长度位 12位且包含中文情况，测试是否可以通过验证
5、测试长度不满足条件情况下，是否通过验证
6、如果长度不满足，是以数字开头的，提示信息验证
7、如果长度不满足，姓名中包含中文的，提示信息验证
………….
(注：)这个可能比较简单，但是说明一个问题：为什么随意生成一个
12位姓名的,其实你选择 8位姓名长度或者 10位姓名长度是一样的，
所以这种情况下考虑采用等效方法比较合适。
范例 2:有这么一个需求，要求选择 1~12之间进行调整，手机的背光
就会随着数值的变化而变化。总体的是数值越大越暗。
以上需求是大家经常可以看到的。
测试案例设计：清晰记忆 1的情况，然后随意调整一个数值，因为要
求是变化了，至于变化成什么样子，变暗到什么程度才正确，没有明
确的指标数值，所以只需要记住临街点 1的情况，然后随意调整一个
数据，然后和当前调整后的数据进行比较。
（注：）没有明确的说明，只是含糊的结果，但是总体的结果是在变
化，那么这个时候比较适合使用等效法。
范例 3、如果
因果分析法
需要有一定的程序基础，了解程序的架构，就是当问题发生以后，能
够有效的补充相关的案例或者筛选相关的案例。因果分析的核心是从
自己的理解去分析问题所在的真正原因。
范例 1：删除磁盘上某个文件失败，分析原因：如果是管理员权限，
那么可以随意删除，无论这个文件的属性是只读的还是存档的，那么
如果不能删除磁盘文件，除非是坏道上的文件。分析完成以后，使得
测试案例设计有针对性，而不是盲目的将所有的文件格式都去尝试一
次。
范例 2：假设我们用 Excel作一个计算，结果和我们用计算器计算的
结果不同。
分析：Excel的计算函数单独运算没有错误，然后插入一行，结果错
误了，说明插入行导致计算错误，那么插入一行怎么会引起函数计算
错误呢？原因是由于插入行后，导致传给计算函数的区域没有更新，
所以造成计算结果错误，那么这个 Bug就很明确了。
范例 3:假设我们平常在做讲座的时候发现在某台机器上就会死机。这
是一种现象。
分析：为什么在这台机器上死，在其他机器上不死。原因有两个，第
一个先找系统原因，是否是我们的产品在当前这个系统下有 Bug,经过
验证没有，那问题出在那里？
其实演示产品需要的是硬件的支持，那就是显卡，如果显卡内存不够
大，可能导致某些演示文件死。
（注）因果分析需要有广泛的知识面，使得我们在分析的时候能够拓
宽面积，模糊的定位问题。
范例 4:用户给我发送一个文件，打印的时候发现是乱码。后来逼迫无
奈，就让用户将这个文件传真给我。这是现象。
分析：为什么打印出现乱码？问题基本定位，系统字库不够，系统下
打印驱动问题，打印虚拟内存问题，操作系统问题，软件本身问题？
最后问题经过验证，最终归结为在此操作系统下，打印驱动程序有问
题，使得文件不能正常打印。
（注：问题需要先框定范围，不要乱了套路。）
逻辑分析法
在逻辑分析方面，也需要有一定的程序理解能力。从程序逻辑和日常
常识去判断问题。逻辑分析法其实就一堆假设的罗列，推论出系列结
果的假设，然后将假设反推翻，问题就可以暴露出来。无论那种方法
都是通过表现去分析问题的实质的。
范例 1:我们在做 MP3播放器快进和快退测试中，要考虑的同步问
题，就是我们液晶显示屏上出现的歌词进度，时间进度和我们耳朵听
到的进度不同。我们分析一下，为什么出现不同步现象，为什么其他
的能同步，就某一个或者某几个不能同步。
首先我们了解同步的算法：快进和快退是按照当前歌曲的数据流来计
算应该到那里，它是以当前歌曲的数据流为系数，然后进行的一些调
整，那么出现不同步的原因是由于系数不同造成的，所以考虑到同步
问题，我们需要找不同格式不同数据流的歌曲，这样问题容易暴露，
容易清楚的定位问题的真正原因
（注：这个例子在这里有些牵强,现在找不到一个合适的例子）
范例 2:
边界数值分析法
在测试案例执行的过程中，所有调节的数据都需要考虑到边界数值的
测试方法，这里我就不在赘述。但是需要注意，边界数值的测试不是
枚举，只是抽样的方法。
逃避测试的误区
市场需求引导产品质量
测试是为了验证需求，保证产品质量，无论如何你都不可能做
成 100%的测试，不可能做成 NoErrors。所以我们针对不同的产品，
不同的市场定位，确定不同的测试方针。
因为企业面对的是客户，面对是企业长远利益，那么我们不可能
仓促的推出产品为了迎合市场，而是需要研究，调查市场的真正
需求，把用户所关心的功能提供给用户，使得其更加完善，更加
稳定。
我们从企业来分析，首先任何一家企业要生存，必须需要市场空
间的支撑，目的是为了盈利，我觉得没有必要说的那么冠冕堂皇，
这是事实，但是在把握产品质量和市场需求的时候，我相信很多
企业会选择市场需求的，因为这是机会，是把握企业生存的机会，
特别是对于发展性企业来说。（企业原因）
我们从开发来分析，因为在开发的过程中，由于软件行业的高流
动行和知识更新快的特点，风险加大，使得开发周期很难把握，
这样使得产品测试时间很难控制。因为开发的进度包括市场提出
需求的技术风险都很难把握。（开发的原因）
我们从测试来分析，测试在很多企业中是没有的，那么开发人员
自己来做，如果有测试人员，那测试也是随意性非常强，造成产
品上市后预留很多无法预估的风险，为企业的形象蒙上了面纱（测
试模式）
合理利用 2/8原则
测试是列举，不是枚举，所以设计案例的时候全面是不可能的，
那么需要灵活的运用 2/8原则，使得测试重点清楚，容易控制。
基于产品在开发过程中的种种风险，我们在有限的人力和资源的
情况下，合理的利用 2/8原则，如何把握 2/8原则？首先需要了
解产品的特点，让所有参与测试的人员能够了解产品的特点，这
样使得工作具有针对性，至于产品的噱头，我们可以进行充足的
测试，因为只是我们的产品立足市场的点。
在时间有限的情况下，把常用的功能测试保证了，不要摊全，摊
宽，这样到最后都无法总计产品的质量概念了。
以上这么说，是一种概况，在实际的工作中大家需要总结，把进
度，时间，质量等进行权衡，以保证产品的顺利发布。
回归测试的概念
测试次数不是轮回，测试的不同次数不是轮回，而是为了验证
问题，那么什么时候适合安排一轮测试，需要定义标准，否则耗
时耗力。
回归测试是不可缺少的环节，在一个产品测试完成后，直接到
用户手头的时候，需要千万小心，需要进行一次彻底的回归测试，
这个时候包括所有的功能以及所有已经修正的问题。避免版本出
现问题。
其实在不同的资料中对回归测试有不同的解释，我就不在这里
赘述。我想表明我的观点是，依照不同的开发模式，回归测试所
在的时间段也不相同；当前的开发模式有瀑布型和迭代型，例如，
在瀑布型的开发模式中，所有的测试活动（手工测试，系统测试，
部分集成测试）都在最后进行的，而切所理解的回顾测试是为了
保证在新的版本中测试修改后的问题，其实这个测试只是保证了
其中一部分工作
测试的概念
测试不是为了验证问题，而是为了发现以前设计中没有发现的
问题。
自动测试只是测试的一种手段，目的是为了提高工作效率
测试工具只是利用，不能依靠，因为工具本身没有智能的判断是
否会有问题发生，自动测试不是利于测试工具，而是需要编写或
者利于测试平台，编写适合自己的测试工作进展。
如何调整团队的作战能力
建议性质：因为曾经带过四个团队，而且这个经验最少在我
身上是成功的。
形式分析
测试团队，测试团队在现在国内来说在慢慢的得到重视，之所
以原来不重视是因为整个行业处于摸索期，不知道采用什么方
法，什么技术，作什么事情等的情况下，使得测试员好像是一
些没有能力人的集合（宣讲，不听的宣讲）。
目标计划引导
测试技术和未来发展规划，因为任何人的发展需要目标，那么
一个人的发展目标假如它和这个行业相关，那么它会付出一切，
努力的工作，所以需要大家认可一个目标，并且让大家认为是
可行的，然后我们分步骤一步步的去实现它。让他或者大家能
够看到自己所喜欢或者从事行业的发展方向。
过过老师瘾
因为在做任何事情的时候，每个人都有自己的想法或者步
骤，讲出来就好，这就需要开始的时候我们以任务的形式下达，
我相信，到后来大家愿意自己站出来讲了，我告诉你原因。因
为人本身有羞怯感，怕几个方面，怕讲错，怕人多，怕提问。
那么如果把这几个问题都解决了，是否羞怯感就没有了呢？
如何解决个人怕的问题：引导，因为一个人如果不能把自
己的想法和思路讲出来，那么不可能把事情做的很好，其二，
就是如果你把你的想法说出来，别人可能会指出你思路中走弯
路的地方，对个人来说可以跳高工作效率，使得思路更加完善。
其三，如果大家都把自己的思路说出来了，你不就节省的
很多学习时间吗，另外你想过没有，当别人形成这个想法的时
候，需要一定的积累，那是他的心血，这不就轻轻松松让你学
到了吗？如果固步自封，那么你的思路有可能是错的，有可能
是对的，但是你的知识面就只能局限在你所考虑的范围内，对
个人发展不利。
定学习目标
在软件行业里面，要有发展，就需要不停的学习，不停的进步，
不停的总结，才可能有长远发展，所以需要定义在这个行业阶段行的
学习目标，让人感觉这个行业现有的水平只是维持，要发展，需要学
习。
在工作中学习的方法，除了自学以外，就是“偷”了，所谓偷，就是
要学会问问题，把你想知道的东西刨根问底，当别人回答你问题的时
候，他一定是用他知道的东西的精华来总结，那么这样你在很短的时
间内，把他总结的精华全给你了。
在学习的过程中，需要学会总结，把能总结的都整理出来，第一是经
验的积累，第二呢能够做到分门别类，逐类旁通，使得相同或者类似
的错误不要重范。
兴趣和爱好
一个人工作有两种情况，第一中是真正的工作，完成就算完成了，自
己也在不断的学习，不断的总结，但是缺乏激情。第二中是把工作当
成自己的事业，渴望自己在这个方面成为权威或者说业界能够说话的
人，也是在不断学习，不断的总结，培养职业关，培养和引导大家的
兴趣和爱好，因为只有你了解了兴趣和爱好，才能更融洽的调和整个
工作组的气氛，这对测试行业的领导者来说是个挑战。
歪曲理论推理
测试人员是由于技术不过硬，才去做测试的。好，我给测试说几句，
测试水平不过硬成立，假设成立，那么这是相对的，相对开发来说的，
而且这种论调都是从开发那里扩散或传播出来的，测试在后期发现问
题后，开发也许心理很痛苦，但是他不愿意暴露在脸上，使得有些问
题越发变的严重，不得不修改。那么在产品后期暴露那么多问题，说
明了什么呢？这么低水平的测试都能考虑到你程序设计的种种漏洞，
那么说明了程序水平开发有待提高。
在 IT现在的行业中，开发的流程，模式，以及各种约定成俗
的东西越来越多，而且相对稳定，而测试是一个全新的行业，它需要
大家摸索支持，需要大家共同建立起来。
其实，在原来的开发模式中，商家为了适应市场，为了保证利润的最
大化，为了使得产品能够顺利的适应市场，那么采用各种方法，使得
产品质量的定位淡薄，而现在随着人们的要求越来越高，商家的意识
越来越强，各个公司或者组织渴望成立测试部门，保证产品的质量，
使得测试这个行业在最近几年才发展起来。
正确理解自动测试
首先，自动化测试是测试行业未来的发展方向，而在测试中采用什么技术，是的
自动化的概念是人们在工业生产的过程中，为了提高工作效率，不断
的对操作方法或者技术或者工具进行改进，减少人们普遍的手工劳动，
节省时间和成本。
而软件行业的自动化测试同样也有节约成本，提高效率的需求。所以
所有的改进需要考虑到成本的问题。
那么作为成本，需要从几个方面去考虑，第一实现成本，第二，人力
成本，第三，新技术的风险，第四，节省的成本，第五，被自动化的
功能是否需要大量的手工劳动。
所以我们理解自动化一定从成本的概念上考虑，最少从自动化测试概
念的起步应该从这个方面考虑。那么自动化测试的重点就在于他节省
人力，节省时间，得到的数据更精确些，而且操作的可重复性和 Bug
的可重现性更强一些。
在目前社会中，人们好像疯狂的讨论自动化测试工具，认为只要有自
动化测试工具了，我们就会自动化测试了。好像这个概念已经被认为
是正确的，而且是被默认的，但是我个人认为这个是一个误导的错误
的概念，其实软件的测试的自动化
测试工具介绍
测试工具在实际工作中的应用
工作中的自动化
测试的几中方法
数据驱动法
桩驱动
关键字驱动
网络方面的测试方法
数据库测试要点
网络游戏测试要点
C/S结构测试要点
WEB测试要点
嵌入式软件的测试方法
手机软件测试
手机现在在社会上应用很广，同时针对手机上的功能增加也非常快，例如，蓝牙，例如，短
信，例如，信息下载，这说明在未来发展中，手机将人们带在一个孤独的社会中去。
简单回想，我们的上辈人开始用手机，那是后简单的目的：就是通讯，而且还必须在既定范
围内，价格高昂等，这些只有很富有的人才能染指的东西现在在社会中的每个角落都可能。
放羊的。。。。
那么手机软件怎么测试呢？测试什么呢？怎么组织呢？
那么我做简单的分析：首先确定手机软件是嵌入式软件，那么我们抛开 IC测试，抛开盲区，
耐久性，耐碰撞性测试不提，就软件本身测试需要考虑的内容。
MP3软件测试
通用软件的测试方法
办公类产品测试
杀毒类产品测试
工具类产品测试
ERP软件的测试方法
验证测试
测试管理工作
我没有读过管理方面，只是看了一些书而已，在几个团队中应用，效
果还可以，所以拿出来和大家交流。
其实无论是开发管理和测试管理，其核心应该是“理”，如果理都不
通，那么管只能是强制性质，那么在软件行业，创造性的企业中，可
能不能维持的很久，所以需要先“理”清楚了，然后我们来管，到那
个时候也就不用管了，因为理顺了，所以大家都知道该怎么样做，什
么时候做了。
那么谈到“理”，我们需要理什么呢？理事情，把要做的事情理清楚；
理目标，把要达到的目的说清楚；理思路，把做事情的思路和方法理
清楚；理资源，把合理的资源调配到合适的位置上，让兴趣和能力结
合。我觉得从大的方面就需要先将这些事情理清楚了，才可能使得一
个团队具有非常的战斗力。
其次，还需要和善的沟通，做到无所不晓，因为在一个团队中，气氛
非常重要，也许一个人的今天心情不好，造成跟他配合的几个人都无
法工作顺心，也许是感应。所以需要和大家开诚布公，把能讲的问题，
能讲的事情讲清楚，让大家觉得你可以依靠，可以把心思告诉你，你
尽力为大家解决后患问题，让他们能够开心踏实的做事情。
另外，需要换位思考，充分让大家提出意见，因为如果一个团队要发
展，是需要大家一起努力的，这是大家都熟知的道理，但是做起来很
难。避免一言堂，让大家充分参与到设计中，在其中找到自我的感觉，
找到这里没有他是不可以的，这样每一个人才能关心项目的每一个角
落，而不是为了工作而工作了。
其二，需要在“理”的基础上帮助大家总结，大家在什么地方容易犯
错误，犯什么类型的错误，犯错误的原因是由于我们的思想老化了，
需要改进做事情的方式，还是由于工作能力或者经验的问题。那么就
需要对各种错误进行统计，以找到问题的根本原因。就问题而讨论问
题，问题的实质出在那里，然后帮大家改进，自己同时也会进步。给
大家讲我现实中的例子吧，我曾经带的一个测试组，大家做事情都很
卖力，而且成绩也非常显著，但是在做的过程中总是会有问题发生，
问题到底出在那里呢？后来找到了原因，就是由于工作环节中出现问
题了，所以他总是在那里犯错误，因为他是把工作当成工作来做了，
所以他就改这个地方，我后来找到他，也找到了问题的原因，一起把
问题解决了。后来我就告诉他们，如果谁在同一个地方犯同样的错误，
我们的结论是他不懂，教他，共同学习，直到他告诉我可以了；如果
第二次犯错误，那么我们给的结果是，他忘记了，好再学，直到他告
诉我，他可以了；第三次犯同样的错误，我们给的结论是故意犯错误
的，那么就要全组请喝可乐一灌。
这个例子在现实生活中很多，主要是引导，因为如果把工作当成工作
来作，可能不会用“心”，因为如果是用“心”工作他会找窍门，会
找方法，负责他会厌烦；如果把工作当成自己未来的事业来做，那么
就会用心工作，这样就需要我们正确的引导。
开发方面
开发分析
因为我们是第一次做 MP3的产品，所以从技术上还处于摸索阶段，第二我们对产品的质量意
识还存在一点问题，第三，四方沟通或者说回馈不够
问题分析
目前存在的问题
进度问题
四方配合问题，因为在炬力，存在硬件、软件开发，市场开发，测试准备四个方面的组织需
要开展工作，所以那个组织的进度耽误都会严重影响产品的发布周期，在现在竞争日益剧烈
的市场中，必须把握市场机会，所以需要对进度进行把握。
建议采用作战图的形式，对各个阶段点进行有利的把握，以给各个方面赢取更多的时间，明
确职责范围，则权利的有利结合，激发各个方面的积极性。采用利益共同体的原则，将各个
方面合理的结合，让开发关心测试工作，让测试关心开发工作，这样形成一个有利的整体，
让市场及时反馈信息，使得项目顺利进展。
沟通问题
SPEC设计完成后，各个方面在限定的时间内做出反馈，以及时跟进，以便对产品有个明确的
定位，各个方面对方案认可后，切实执行，如果出现技术问题，及时通知有关人士，以便进
度和方案进行合理的修改和微调。在产品开发阶段，需要及时的总结可能遇到的问题和对问
题的解决方案，通知相关人士，使得项目组的人有一种归宿感觉。
开发需要给每个 Bug做出合理的解释，或者对我们的测试人员进行相关培训，以便测试人员
能够深切的理解产品，能够对产品进行合理严格的测试。
跟踪问题
跟踪问题牵扯到 Bug的跟踪和进度跟踪，Bug的跟踪需要一套流程，及时的出来 Bug,使得发
现 Bug和解决问题形成一个完整的流程。
进度跟踪的方法，建议采用阶段点产品，定义明确的时间点，明确各个时间点上完成的功能
点，保证产品可以编译，可以抽查，可以运行以完成的相关功能。这样使得大家在各个时期
能够看到大家都在进步，产品在进步，有利于整个团队的士气。
版本控制问题
定制严格的产品发布流程，降低由于时间问题，压缩测试时间，给产品发布带来的风险。建
议采用的方法，由项目组定制编译计划，然后有相关人士进行讨论，各个方面达成共识之后，
坚决执行。
版本控制和进度控制密切相关。
进行严格的代码管理，以保证公司机密资料，在代码 Checkin和 CheckOut的时候建议由专
人进行审核后方能入库，以免误操作或者敌意的操作造成代码冲刷。控制版本有几个好处和
优点。
关于 Bug的回馈优点
第一、 开发方面回馈速度快
第二、 解决速度快
关于测试情况的总结
第一、 涵盖情况
第二、 Bug的质量问题
开发体系问题
第一、 设计的分析做吗？技术难度？设计的合理行，进度的可行性？
第二、 单元测试做了吗？
第三、 CVS的 CheckIn控制了吗？
第四、 进度风险预估了吗？
第五、 进度控制如何进行的？
产品方面：
产品分析：整个产品在开发前期，市场已经找到了市场切入点，但是在现在产品要发布了，
我们不能或者说很难用一系列的数据做说明，告诉高层这个产品可以发布了或者说不能发布，
因为分析的数据太少了。因为数据是说明问题的基础，但是现在定了产品发布的标准，只是
一个现存数据，没有预估分析可能性，对产品投入市场可能存在风险。
建议：
第一、 案例执行率
第二、 案例发现 bug率
第三、 重复 bug率
第四、 KLOC
第五、 产品日测试汇总图（察看历史曲线）
对产品研发整体改进思路
第一步、增强开发质量意识
做法：这个是个长远任务，但是我们可以做具体的事情，例如：检查开发单元测试情况或者
单元测试代码等活动
对设计的模块案例检查回馈情况，把质量和开发邦定，不要让测试单独承担这个压力。
活动方式：宣讲，制度，执行，邦定
第二步、增强测试本身素质
做法：因为测试不成型，这是现状，所以我们通过提供一些数据来提高案例设计的能力
或者说告诉测试人员我们的缺陷在那里。这个是长远的事情，因为需要人力去做
这个事情。提供如下数据：重复报告率，案例和 Bug的比率等。
加强程序概念的培训或者框架的了解，尽力从程序的概念上理解产品，尽量避免
例冗余。
活动方式：培训，数据，比较
第三步、对产品开发过程中版本编译的控制
做法：CVS库权限控制，所有的 Checkin和 Checkout需要控制，检查代码后方可入库
活动方式：专人控制，以面冲掉原来的代码
第四步、进度控制
做法：在产品开发周期中定制完整的编译计划，对阶段性产品进行测试或者抽查。以保
后期测试时间的争取和质量的保证。
活动方式：认可，执行，调整
第五步、控制进度问题
做法：明确开发模式，列举详细的开发进度，详细提出开发的功能情况，树立作战详细进度
表或者叫作战牌，以鼓舞士气，让每个参与者了解进度
活动方式：承诺，监督，跟踪
1做法：统一平台，统一流程，统一做事方式，实现任务单跟踪
活动方式：准则，平台，优化。
