Softwareengeering = Technology + Management

　　现代软件测试思想:全生命周期的测试思想.

　　软件系统的规模的急剧增大--->国际协作模式,联合开发,

　　软件测试管理:softwaretest 团队组织管理,软件测试计划管理,软件缺陷跟踪管理,软件测试资源管理。

　　软件缺陷是软件与生具来的特征,是影响软件质量的重要和关键的因素之一，发现和排除缺陷是软件生命周期重要的工作之一。缺陷的密度是靠经验来估计的。

　　缺陷管理工具:

　　开源Bug追踪管理的工具:Bugzilla(Mozilla出品),BugOnline,Bugzero,Bugtracker,BugFree(借鉴微软的研发流程和Bug管理理念,PHP+MySQL)

　　软件测试管理工具:TestManager,TestDirector,TestRunner(与Bugzilla集成的一款管理工具),TestLink—优秀的开源测试管理软件,可以和更多缺陷管理软件进行集成(Bugzilla,Mattis)。Sourceforge的开源项目之一

　　TestLink应用环境:LAMP(Linux+Apache+MySQL+PHP)

　　Part2 静态分析篇

　　程序的静态分析是在不执行程序的情况下地其进行分析的技术,简称静态分析。静态分析的输入:程序源代码,目标代码。

　　静态分析工具扫描测试程序的正文,对程序的数据流和控制流进行分析,然后给出分析报告。通常采用以下方法进行源程序的静态分析。

　　1.生成各种引用表

　　直接从表中查出说明/使用错误等,如循环层次表,变量交叉引用表,标号交叉引用表等。

　　为用户提供辅助信息,如子程序(宏,函数)引用表,等价(变量)表,常熟表等。

　　2.编程规范检查

　　检查分析程序中违反编程标准的错误,如模块大小,模块结构,注释的约定,某些语句形式的使用,以及文档编制的约定等。

　　3.静态错误分析

　　静态错误分析主要用于确定源程序中是否存在某类错误或”危险”结构。

　　类型和单位分析

　　引用分析:使用最广泛的静态错误分析方法就是发现引用异常---异常探测工具

　　表达式分析:对表达式进行分析,以发现并纠正表达式中出现的错误

　　接口分析:接口的静态错误分析—检查过程及函数过程之间接口的一致性。检查形参和实参在类,数量,维度,顺序,使用上的一致性,全局变量和公共数据区在使用上的一致性

　　4.静态特性的统计功能

　　程序的统计信息,各种类型的语句出现的次数等等

　　错误预测和程序复杂度计算

　　静态分析工具可以保证代码的质量,发现并警告潜在的Bug。

　　独立的静态分析工具C的lint,Smalltalk的lint

　　程序理解工具

　　程序理解是人们将程序及其环境---面向人的概念知识过程中,是软件开发过程中的重要的活动,软件的测试＆维护,逆向工程--源代码理解。

　　软件规模的增大--->通过计算机来完成软件系统分析和理解的程序辅助工具的需求变地越來越迫切。

　　1.程序理解概述

　　大型软件系统---分析和理解的困难性---系统维护和演化任务艰巨---成本高,

　　1.1程序理解的概念

　　程序理解就是从计算机程序中获取知识信息的过程,程序排错,程序增强,程序重用以及文档整理。程序理解的目标是从不同抽象层次,多视角,多方面综合表达并展示程序理解的结果。

　　程序理解是软件工程领域的一个重要的部分。软件工程---如何提高软件开发效率和软件产品质量。程序理解在维护,逆向工程中起到举足轻重的地位。

　　程序理解的目标:理解软件系统以使性能提高,纠错,再设计和使用另一种语言冲新编写。

　　系统的概念建模,数据抽取,系统抽象---依赖于通过分析程序源代码来抽取程序和控制流信息。

　　1.2程序理解的任务和内容

　　任务:在不同抽象级别上建立基本程序的思维模型,从问题领域到程序设计领域的映射集。代码本身的模型,基本应用领域的模型。四个抽象层次:

　　实现层:程序设计语言进行理解,检查程序结构,程序的AST,符号表或普通源文件。技术涉及程序扫描,语法提取,语义检查,静态分析,动态模拟运行等过程。

　　结构层:在程序设计语言基础上,检查程序构造过程中的结构,对程序中出现的实体以及他们之间的关系的分析,数据调用,控制流程图,程序调用图。结构层包括:逆向工程信息提取,信息抽象,结构模型匹配...

　　功能层:从不同的模块的功能来推断他们之间逻辑关系。功能层包括:设计恢复,语义和行为模式匹配

　　领域层:检查特定于应用领域的概念,进一步从功能上推断此软件在其领域的作用,智能软件理解,格局设别,概念赋值和推理

　　从抽象层从低(源代码)到高(领域问题).

　　主要介绍结构层次的技术.

　　程序理解的几个方面:结构信息,数据流,控制流,程序操作,面向对象的理解

　　1.3程序理解的技术

　　结构层的理解技术有语句分析,表示程序单元之间的调用关系和被调用关系,与程序内部结构相关的程序控制流图和数据流图.

　　1.语句分析技术:程序的词法模式和语法模型

　　2.程序流分析:数据流和控制流---首要任务发现控制结构,分析方法(必经点分析和区间分析)。数据流分析是为了计算被分析程序在生成数据方面的行为,通常用于程序优化。

　　3.软件结构图:程序调用关系图(函数调用关系图)和系统结构图。程序调用关系图:对源程序中函数关系的一种静态描述;系统结构图反映的是系统中模块的调用关系和层次关系,谁调用谁,时序关系。

　　1.4程序理解工具

　　阅读源代码是程序理解的一项重要的活动。常见的程序开发工具：程序切分器,静态分析工具(有效工具,splint,Olink),动态分析工具。

　　2Olink程序理解工具

　　Olink是一个开源的C/C++工具,基础或核心部分。

　　Olink的源码包：smbase(c++的包和字符串库,替代C++标准库中相应的库),ast(生成AST的工具包),elkhound(用于管理GLR语法分析器,和bison功能相似,可以用来反分析任何上下文无关语法),elsa(在elkhound语法分析的基础上,将C\C++程序生成为相应的AST,可以对程序进行部分类检查,主要是与),libregion(基于区域的c语言内存管理库),libqual(可序列化的多太的类型修饰符推理接口),platformmodel(C/C++标准库的静态模型)。

　　书本上提供的网址Olink的网址是: http://www.cubewano.org/oink/downloads/2006-08-31/。然后打开后发现不知道导向了什么网站。

　　看了一堆理论,听作者吹了老久,感觉这个Oink工具好牛逼的说,原本想实践一下了,结果却是这样的.很不高兴.

　　下一篇是关于splint的,因为内容比较多,就不放在一起了

　　参考文献:

　　[1]软件测试实验指导教程/蔡建平, 清华大学出版社, 2009.11

相关文章：

软件测试实验学习笔记系列2 -- lint,splint的使用

　　主要特点：

　　代码覆盖：通过单元测试，将会显示哪行代码被选中

　　改善编码规则

　　搜寻编码规则：按照名字，插件，激活级别和类别进行查询

　　项目搜寻：按照项目的名字进行查询

　　对比数据：比较同一张表中的任何测量的趋势

　　架构图：

　　Eclipse插件：

　　Sonar Integration for Eclipse 是一个 Eclipse 插件，用以集成 Sonar 这个 Java 代码质量管理平台。

　　插件的 Update Site：http://sonar4eclipse.googlecode.com/svn/trunk/org.sonar.ide.eclipse.update/

　　小结

　　在这次采访中，郑文强和大家分享了很多宝贵的经验，摘要如下：

　　1、勤奋学习能够弥补基础的不足。

　　2、在决定发展方向的时候，不要生活在别人的期望中，而是要知道自己想做什么，擅长做什么。

　　3、去做自己喜欢的，还是去做人家喜欢的？最终我选择了前者。从目前的结果看，感觉到自己在公司内部可以做的事情更多了，参与的活动也在增加。不管对公司还是对个人，体现的价值都是在不断增加的。

　　4、把好的测试理论、测试思想与工作实践结合起来。

　　5、坚持去做自己喜欢的工作，不断积累、总结和分享。

　　6、认清楚自己，明确自己的优点和不足。

　　7、让跳槽符合自己的发展方向。

　　8、分享并不会导致“教会了徒弟，饿死了师傅”，因为学习是一个过程。另一方面，同事会因为你的分享而感谢和尊重你。

　　9、作为测试的负责人，不要期望自己在所有的方面都比其他人强，你的定位应该是为整个测试团队服务的角色。如果你能在团队内带头分享你的知识与经验，也一定能带动其他人的分享，更好地做好测试团队的知识与技能的储备，有利于测试经理更好地分配测试工作，并做好备份工作。

　　10、与脚本化测试相比，探索性测试更强调测试人员的思维自由度与主观能动性。然而，探索性的自由，并不代表它是不做准备的，它也不是随机的。好的探索性测试依赖于测试人员综合应用测试策略、测试技术与方法的能力，例如，获取测试数据，掌握测试设计技术，建立失效模式，创建测试模型等。口号式的探索性测试并不能帮助测试人员成功。

　　11、我几乎每天都会反省自己当天的工作，有了哪些收获，有了什么总结，多少时间又被浪费了等。通过这样的形式，不断提升自己的信心，提高学习的效率和有效性。

　　12、软件发布与否应当综合多个方面的因素来考虑，而不仅仅是测试的意见。

　　13、要想获得成功，勤奋是不可或缺的。

　　14、多实践，不要怕失败。不管是测试领域的知识，还是测试技能，或者是测试思想和方法，测试新人都需要勇敢地去实践，许多的经验、思想和收获来自于失败的经验教训。

　　15、面对职业发展迷茫的时候问自己喜欢做什么，目标是什么，当前的工作和活动是否能帮助自己达成这个目标。

　　16、从形式、覆盖率和有效性方面来评估测试用例的质量。

　　17、成为测试牛人的三个步骤：制订目标，明确技能目标，立即行动。

　　18、在参见面试前做好准备，并在面试过程中保持坦诚。

　　19、软件测试行业的发展前景乐观，同时测试工程师会面对不少的挑战。测试人员要提高自己的技能水平和价值。

　　20、软件测试行业将持续往前发展，而测试从业人员能否在这个平台中同步前进，这依赖于测试人员自己的不断积累、不断实践与不断交流。要发展，测试人员同样需要走出去，了解当前的测试热点、测试发展趋势、测试理念与思想的趋势等。

　　（未完待续）

　　中国软件测试专家访谈录（2）

　　根据形式、覆盖率和有效性来评估测试用例的质量

　　蔡：如何评估测试用例的质量？

　　郑：测试用例质量的评估，我主要考虑下面三个方面。

　　1、根据测试用例的形式评估其质量，主要包括：

　　（1）测试用例与需求规格说明中需求条目的可追溯性。例如，每个需求条目至少有1个测试用例与之对应。

　　（2）测试用例有无明确的期望结果。

　　（3）是否满足公司内部定义的测试用例模板。

　　2、根据测试用例覆盖率评估其质量，主要包括：

　　（1）需求的覆盖率。例如，我们主要负责系统测试级别，因此测试用例的需求覆盖率要求必须达到100%。

　　（2）质量特性的覆盖率。例如，我们在测试用例模板中采用测试类型的概念，要求每个功能的测试用例必须100%覆盖所有的测试类型。

　　（3）测试平台的覆盖率。例如，针对我们目前的通信产品，每个功能都需要在不同平台上运行；再如，不同的网元类型、接口类型、业务类型等。测试用例对这些平台的覆盖率也要求达到100%。

　　3、根据测试用例的有效性评估其质量，主要包括：

　　（1）测试用例的缺陷发现率。我们采用的计算方法是，系统测试发现的缺陷数目除以执行的测试用例数目（百分比）。

　　（2）脚本化测试的缺陷发现率。我们采用的计算方法是，根据测试用例步骤发现的缺陷数目除以总发现的缺陷数目（百分比）。如果这个百分比很低，则说明设计的测试用例的有效性方面比较差，不少bug是通过探索性测试发现的。

　　（3）遗漏到用户现场的缺陷率。我们采用的计算方法是，6个月内用户现场反馈的缺陷数目，除以系统测试级别发现的缺陷数目与6个月内用户现场反馈的缺陷数目之和（百分比）。

　　每个公司和测试团队在评估测试用例质量方面都会存在不同的度量指标，我们的要求是这些度量指标要简单容易收集，并且有利于改进测试过程和测试团队的测试能力，但切记不会做针对测试人员个人的能力与绩效的评估。

　　旁观者说：从不同的侧面去做度量，是一个更好的办法。这种办法可以在工作的很多方面得到应用。

　　成为测试牛人的三个步骤

　　蔡：有网友提到一个问题，如何成为测试牛人？

　　郑：不管是测试管理方向还是测试技术方向，都是可以成为测试牛人的。要成为测试牛人，你要有成为测试牛人的强烈要求。根据我的经验，下面的步骤有助于你成为某个领域内的专家。

　　第一步，制订目标：你希望成为哪个领域的测试牛人？例如，测试技术方面的牛人、测试自动化方面的牛人。

　　第二步，技能要求：要达到所制订的目标，你需要具备哪些方面的技能？以我自己为例，希望自己成为测试技术专家，我主要从下面几个方面不断积累经验与技能。

　　（1）深入了解测试对象的背景知识与业务功能。例如，我是做宽带接入产品的，除了测试对象的功能之外，我利用空闲的时间学习了VPN、MPLS、IPv6、IP路由交换协议等。

　　（2）深入了解我公司所采用的开发模型与测试流程，即需要清楚地知道在测试生命周期中，什么阶段需要做什么事情，有哪些输入与输出。

　　（3）测试人员要深入了解各种软件测试技术与方法。例如，我们采用敏捷开发，在面向业务的测试过程中，探索性测试与测试人员的结对测试是我们经常采用的测试方式，不仅可以有效发挥测试团队的主观能动性与及时分析反馈能力，而且可以更好地分配资源与加强测试团队内部的技能共享。

　（4）培养测试人员的各种软技能，例如，沟通与合作。对我而言，在业余时间喜欢看各种类型的书籍，例如，沟通、管理、心理学、演讲、理解与记忆、经济学、思维等。广泛涉猎各种知识，可以帮助我更好地提高软技能。

　　第三步，立即行动。

　　“千里之行，始于足下”，坚实走出每一步，坚持走出每一步，成功就在前面等你。

　　旁观者说：没有行动，再好的目标也仅仅是纸上的目标。

　　面试中的考量

　　蔡：你的测试经验很丰富，肯定参加和主持过不少的测试职位的面试。你在面试中看重什么？

　　郑：在面试过程中，我主要会从下面几个方面进行考量。

　　第一，会详细了解职位候选人在测试对象的产品背景知识与业务知识方面是否满足职位的要求。

　　第二，考察应聘者在测试流程、测试技术与方法等方面是否有所了解，结合测试项目和产品的特点，判断他所掌握的这些技能是否有助于测试团队的测试能力改进。例如，我们一直做的是系统测试工作，时间与资源经常非常紧张，除了基本功能的验证之外，测试中很多的精力放在用户业务的考察上，因此应聘者了解基于场景的测试、基于风险的测试等技能是受欢迎的。

　　第三，考察候选人在性格特征、为人处世等方面是否符合企业文化和团队氛围。

　　同时，员工的上进心与学习能力也很重要。例如，两个候选人，一个有一年工作经验，另一个有三年工作经验。只要有上进心，有一年工作经验的那位候选人在半年后就能做与有三年工作经验的那位朋友一样的事情，甚至做得更好。

　　旁观者说：这里也揭示了一个残酷的事实：如果没有高人一等的技能，年资有的时候会在找工作的时候帮倒忙（暂且称为年资拐点）。我们要尽可能延迟年资拐点的出现。

　　当然，面试中获取每个候选人真实的信息并不是一件容易的事情，我自己会从候选人的日常时间安排、个人兴趣爱好和业余时间计划等方面收集与分析信息。

　　基于我面试的经验，下面是我给测试职位应聘者的两条建议。

　　1、面试前做好充足的准备工作。

　　2、面试过程中，应聘者诚实很重要。面试过程中有些问题不会，可以直接回答不懂或者没有经验，切记不要不懂装懂。没有一个人是完人，面试官可以接受存在不足的候选人，但不会接受明显撒谎的人。

　　旁观者说：对，坦诚其实是面试中最好的态度。

　　软件测试行业的发展前景

　　蔡：对软件测试行业的发展前景，你怎么看？

　　郑：我是2001年开始从事软件测试工作的，从我个人的整个从业经历来说，软件测试行业一直在往专业化、系统化、正规化方向发展，因此软件测试应该是一直在往上走的趋势。针对软件测试行业的发展，可以从行业本身与测试从业人员两个方面进行分析。

　　软件测试行业前景乐观

　　首先，我国的软件测试行业相对欧美国家，现在还是处于很年轻的阶段。借鉴美国等软件测试的历史发展经验，测试行业发展的前景还是乐观的。在欧美国家，软件测试行业中经常可以看到有30年甚至40年测试经验的从业人员；而在国内，像我这样有11年软件测试经验的人都算是“很老的”测试人了。因此，欧美国家中30/40年的软件测试经验，可以说明这个行业能够提供机会，让他们一直做下去，而且做得不错。我相信这个现象同样适用于我国的软件测试行业。

　　旁观者说：有的朋友说，咱们国家的IT公司不养年纪大的人，你看身边哪有年纪大的？对于这一点不必悲观。之所以现在IT公司里没有年纪大的员工，主要是因为我们的IT行业太年轻。只要IT行业持续发展，公司规模增大，慢慢就会出现白发斑斑的IT工程师。

　　其次，客户对软件产品的质量要求越来越高。尽管说软件产品的质量是构建进去的，而不是测试出来的，但是软件测试对提高产品质量是建设性的，因此测试在研发中的不可或缺性将会不断得到提升。这对软件测试行业而言是利好消息。

　　旁观者说：社会对软件的依赖和对软件质量要求的提高，是软件测试行业发展的基础。从这个方面来说，测试从业人员可以去培育和引导社会对软件质量的要求。

　　第三，2012年的软件测试很热闹，除了在上海成功举行了中国第一届软件测试大会之外，在北京、上海等地轮番上阵了ISTQB测试沙龙、测试专题讨论、软件测试俱乐部沙龙等民间测试活动，并且参与的测试从业人员都是几百人的量级。这样的现象在前几年是不可想象的，这从另一个侧面反映了测试行业的蓬勃发展。

　　测试人员要提升自己的技能水平和价值

　　蔡：测试工程师将来会遇到哪些挑战呢？

　　郑：测试行业前景看好并不代表每个测试从业人员都有好的前景，这依赖于测试人员如何提升自己的测试技能与提供的测试价值。今后一段时间测试业界内的热点是：

　　1、自动化测试与手工测试之争。随着软件测试成熟度的提高，加强自动化测试将是一个合理的趋势，这对于测试从业人员而言是一个发展方向。但是自动化测试并不能代替手工测试，因为自动化测试的基础来自于测试人员的思维与设计，测试从业人员应该将自动化测试作为一个提高测试效率的手段，而不应该是最终的目标。自动化测试工具并不能保证项目的成功，但是可以帮助优秀的测试人员更加出色地工作。

　　2、探索性测试与脚本化测试之争。测试从脚本化测试的关注过程，到探索性测试更关注测试人员的思维与主观能动性，并不能说明两者之间谁好谁坏，或者谁替代谁的问题。测试人员需要做的是如何平衡两者之间的关系，如何更好地发挥两者各自的优势，弥补各自的不足。

　　3、敏捷开发模式下的敏捷测试。敏捷测试更强调整体团队运作，强调将质量构建进产品而不是在生产出来之后再进行测试，强调自动化测试，以及同时强调面向技术的测试与面向业务的测试。敏捷测试要求测试人员掌握熟悉范围之外的新技能，例如，测试驱动开发、持续集成。

　　软件测试行业将持续往前发展，而测试从业人员能否在这个平台中同步前进，这依赖于测试人员自己的不断积累、不断实践与不断交流。要发展，测试人员同样需要走出去，了解当前的测试热点、测试发展趋势、测试理念与思想的趋势等。

　　旁观者说：博取各家所长，兼容并蓄。

　　书籍推荐

　　1、《软件测试艺术》：软件测试的经典著作，展示了测试大师Glenford Myers多年的软件测试思想和技术。书中探讨了代码检查、走查与审查、测试用例的设计、单元测试、系统测试、极限测试等主题，是测试人员入门的一本优秀教材。

　　2、《软件测试经验与教训》：本书分享了3位作者多年的测试经验，知道成功的测试需要什么。书中汇总了293条测试经验建议，阐述了如何做好测试工作，如何管理测试，以及如何澄清有关软件测试的常见误解。读者可以将这些经验用于自己的测试工作中，避免一些容易犯的错误，提高测试效率与有效性。

　　3、《A Practitioners Guide to Software Test Design》：关注测试用例设计的一本著作，其中包括了白盒测试技术、黑盒测试技术与基于经验的测试技术。每个测试技术本身都结合了技术原理、案例分析和优缺点分析，是每个测试人员了解和应用测试用例设计的一本好书。

　　4、《赢在测试：软件测试先行者之道》：蔡为东写的这本书，汇集了多名测试行业的测试精英，其中描述了他们是如何认识测试，发展测试，规划测试，以及如何在测试行业中取得成功的，为测试从业人员的职业发展提供了参考方向。这本书为处于迷茫阶段的测试人员规划自己的测试职业发展，提供了许多现实可行的方向。

　　5、《思维导图：大脑使用说明书》：要想在测试领域有所建树，测试人员持续不断地学习与积累是非常重要的，而如何有效地阅读与学习将是决定成败的一个关键。思维导图是一个简单易学的革命性思维工具，它可以帮助你提高记忆力和理解力，激发想象力，更好地制订生活和工作计划。

　　小结

　　在这次采访中，郑文强和大家分享了很多宝贵的经验，摘要如下：

　　1、勤奋学习能够弥补基础的不足。

　　2、在决定发展方向的时候，不要生活在别人的期望中，而是要知道自己想做什么，擅长做什么。

　　3、去做自己喜欢的，还是去做人家喜欢的？最终我选择了前者。从目前的结果看，感觉到自己在公司内部可以做的事情更多了，参与的活动也在增加。不管对公司还是对个人，体现的价值都是在不断增加的。

　　4、把好的测试理论、测试思想与工作实践结合起来。

　　5、坚持去做自己喜欢的工作，不断积累、总结和分享。

　　6、认清楚自己，明确自己的优点和不足。

　　7、让跳槽符合自己的发展方向。

　　8、分享并不会导致“教会了徒弟，饿死了师傅”，因为学习是一个过程。另一方面，同事会因为你的分享而感谢和尊重你。

　　9、作为测试的负责人，不要期望自己在所有的方面都比其他人强，你的定位应该是为整个测试团队服务的角色。如果你能在团队内带头分享你的知识与经验，也一定能带动其他人的分享，更好地做好测试团队的知识与技能的储备，有利于测试经理更好地分配测试工作，并做好备份工作。

　　10、与脚本化测试相比，探索性测试更强调测试人员的思维自由度与主观能动性。然而，探索性的自由，并不代表它是不做准备的，它也不是随机的。好的探索性测试依赖于测试人员综合应用测试策略、测试技术与方法的能力，例如，获取测试数据，掌握测试设计技术，建立失效模式，创建测试模型等。口号式的探索性测试并不能帮助测试人员成功。

　　11、我几乎每天都会反省自己当天的工作，有了哪些收获，有了什么总结，多少时间又被浪费了等。通过这样的形式，不断提升自己的信心，提高学习的效率和有效性。

　　12、软件发布与否应当综合多个方面的因素来考虑，而不仅仅是测试的意见。

　　13、要想获得成功，勤奋是不可或缺的。

　　14、多实践，不要怕失败。不管是测试领域的知识，还是测试技能，或者是测试思想和方法，测试新人都需要勇敢地去实践，许多的经验、思想和收获来自于失败的经验教训。

　　15、面对职业发展迷茫的时候问自己喜欢做什么，目标是什么，当前的工作和活动是否能帮助自己达成这个目标。

　　16、从形式、覆盖率和有效性方面来评估测试用例的质量。

　　17、成为测试牛人的三个步骤：制订目标，明确技能目标，立即行动。

　　18、在参见面试前做好准备，并在面试过程中保持坦诚。

　　19、软件测试行业的发展前景乐观，同时测试工程师会面对不少的挑战。测试人员要提高自己的技能水平和价值。

　　20、软件测试行业将持续往前发展，而测试从业人员能否在这个平台中同步前进，这依赖于测试人员自己的不断积累、不断实践与不断交流。要发展，测试人员同样需要走出去，了解当前的测试热点、测试发展趋势、测试理念与思想的趋势等。

　　（未完待续）

　　● 对象：开发人员提交给测试人员的产品版本

　　● 定义：是对测试版本有明确的标识、说明、并且测试版本的交付是在项目管理人员的控制之下。

　　● 作用：在于能跟踪记录整个测试过程，包括测试本身和相关文档，以便对不同阶段的待测试软件有相关文档进行标识和差别分析，便于协调和管理测试工作。

　　如何有效的控制测试版本？

　　● 制定合理的版本发布计划，并加强版本控制管理
　　● 强化测试准入条件
　　● 强化BUG管理
　　● 做好版本控制的文档管理工作
　　● 积极解决问题的态度

　　制定合理的版本发布计划，并加强版本控制管理

　　软件版本的发布应有计划的执行，在项目开发计划中明确发布版本的时机和版本更新的策略，简单的说就是明确在什么条件下可以发布测试初始版本；什么条件时进行主版本、子版本的更新。这样可以避免频繁的发布测试版本和随意修改版本号给测试带来的混乱。

　　强化测试准入条件

　　软件测试的启动是有条件的，在开发人员发布测试版本时，应有相应的文档支持如自测报告、软件版本说明等等，这是前提，不满足这个前提，测试活动不应启动。

　　软件版本说明可以使测试人员了解当前版本的具体内容和与上一版本的差异。

　　自测报告对版本质量的一个保证，避免出现版本质量太差的情况。

　　强化BUG管理

　　充分使用TD测试管理工具，做好BUG管理工作。首先，在提交BUG时，应完整填写BUG的详细内容，如发现版本、对应人员、发现的模块等等；其次，在开发修改BUG时，应注明修复问题的信息；最后，在测试人员关闭BUG时，应填写选择关闭BUG的版本号。这有利于分析不同版本和不同模块的BUG走势。

　　BUG提交界面

　　做好版本控制的文档管理

　　在每次提交测试版本，执行测试时都会生成相应的文档以便来记录版本信息和测试记录及测试结果等等，管理好这些文档，不仅有助于跟踪和监测测试版本的执行，而且也便于对测试活动的追溯。

　　积极解决问题的态度

　　无论是开发人员还是测试人员，在版本控制过程中都应有积极的态度，遇到问题及时沟通，以高效的方式来解决问题。

　　版本控制的评价标准是什么？

　　● 对软件测试的版本控制来说，衡量其效果的标准可归根结底为两点：效率和质量。

　　● 如果版本控制最终使软件测试效率得到提高、使软件质量得到提升，那就是成功的。反之，则是失败的。

　　笔者会先介绍当前互联网的软件测试与传统的软件测试区别与联系，然后针对互联网软件测试的特性再结合持续集成工具思想的运用，最后将比较详细的介绍Hudson持续集成构建平台在项目中的实践与分析，从而解决了在多个项目并行开发的软件项目中应该如何应用持续集成以保持项目整理开发过程的高质量和高效率问题。

　　关键词：软件测试；持续集成；自动化测试；

　　一、引言

　　在互联网信息时代，随着Internet的快速增长及Web应用的不断发展，使其快速渗透到商业、电子商务、军事、工业、教育等领域和个人生活的各个方面，对我们的生活及工作产生了深远的影响。在当今市场需求和Internet技术进步的不断推动下，Web应用日益增加，互联网的软件规模不断扩大，复杂性增加，操作易用性降低，面对互联网的用户也越来越多，因此软件的质量越来越成为人们共同关注的问题，作为保证软件质量和可靠性的重要手段，软件测试已成为互联网软件项目开发过程的重要环节。

　　在整个软件生命周期中每个环节都存在软件测试的活动，软件测试伴随着软件开发，以检验每一个阶段性的成果是否符合质量要求和达到预先定义的目标，尽可能早的发现问题并修复问题已成为当前互联网时代软件开发与测试过程的目的，也就孕育了要提高上游软件质量，发挥测试工程师在软件项目需求、设计阶段参与的重要性。互联网的信息和产品更新速度较传统软件产品是非常之快的，保证好软件系统的质量和稳定性，运用敏捷的测试思维、测试工具来改变传统的测试方法和测试观念，正是在互联网软件实施过程中必须面对的。针对互联网软件开发的特点，笔者结合多年的软件测试经验与测试策略、工具，总结一些比较适用的方法、流程和工具综合运用到互联网软件开发与测试过程中，综合运用持续集成构建的思想进一步保证软件质量和提升开发效率。

　　二、 现状分析

　　目前在互联网软件开发测试过程中，存在效率低下、质量不高的情况，具体可以总结成以下几个方面：

　　第一、RD编写的代码质量不高

　　开发工程师在编码阶段，经常犯一些比较低级的错误，致使提测版本的代码质量较低，如空指针异常、重复犯错及违背编码规范等，常常会被在冒烟测试阶段退回而重新开发，增加提测版本质量和效率的风险，也影响到项目整体开发进度。

　　第二、单元测试流程不规范，质量和覆盖率较低

　　为了提高上游代码质量，在开发过程增加了单元测试流程和规范，各部门产品线统一推广与执行，实施一段时间后发现流程在各产品线执行执行的比较混乱，存在一些流程和规范细节问题，执行出现脱节，导致单元测试的代码质量与代码覆盖率下降，在某些项目过程中暴露的非常明显，较严重地影响了项目进度和质量。

　　第三、测试方法单一，测试策略陈旧，测试过程的效率和质量低下

　　项目过程，测试工程师从立项前的需求讨论到立项后的需求、DEMO、设计评审和TC编写几乎全程参与，一定程度提升测试工程师在项目研发过程的地方和影响力，另外也带来了测试方法单一和测试策略陈旧的问题，全靠手工测试已成为项目测试过程的瓶颈，往往就导致项目、需求排队现象，进一步分析说明了我们的测试产出比低下，效率不高。

　　必须改变整个项目过程的测试方法，引入新的测试工具和测试策略，必须发挥自动化的力量缓解手工测试的瓶颈和解决效率低下的问题。

　　第四、上线后出现故障频繁，bugfix需求增多

　　项目和小需求在互联网行业中更新非常快，如果过程没有更好的控制软件风险的话，上线后的需求就会出现很多故障，导致用户大量投诉，后续修复的工作量将投入很多资源去支持，一定程度上浪费了精力和物力，降低了生成率。

　　尤其是在大项目和新增需求发布上线后，故障的频繁让开发、测试心惊胆战，不仅要处理手中新的需求，还要跟进线上故障的bugfix需求，使工程师的精力分散，增加了质量的风险。如何把故障减少下来，如何提升测试阶段和开发前期的质量，已摆在工程师及主管们面前。

　　第五、无数据支撑来度量和评估开发和测试人员的质量和效率

　　软件过程度量目前实施的还不规范，无基本度量的数据来支撑说明存在的问题，只能通过某阶段某现象说明有问题存在，但无法给一个标准去度量和评估，这样给软件开发和测试过程的质量和效率评估带来很多不便，如何收集过程数据，如何制定度量标准，还需要进一步在软件开发过程进行分析与梳理。软件过程度量也是为保证软件质量的纽带，其实这个专题研究的内容也是比较广的，从软件工程上来讲，测试过程改进有很多模型参考，这里不展开说明。

　　三、互联网软件测试特性

　　在基于互联网软件系统开发过程中，通常就是以Web系统为基础，按照B/S的访问方式为主，包含客户端浏览器、Web应用服务器、数据库服务器的软件系统，首先从技术实现上来说，一般的Web系统结构，不论是.NET还是J2EE框架，都是多层框架设计，有用户操作界面层、业务逻辑层、数据驱动层；其次从结构上来讲，都是有客户端部分、传输网络部分和服务端部分。

　　1、系统架构

　　一个比较典型的互联网软件系统的结构示意图如图-1，前端的用户浏览器，通过网络访问应用服务器及数据库服务器传回的数据。

图-1

　2、互联网软件测试特点

　　1）不断创新，改变易用性，留住用户

　　在互联网软件开发过程中，我们往往关注点会集中在用户体验、软件的创新及能为用户带来的价值，所以必须建立在用户体验基础上进行创新，留住用户，改变易用性，是互联网软件开发与测试的首要特点。

　　2）采用敏捷的开发测试思维，快速实现新功能，快速修复线上bug

　　基于创新的思维决定了我们在互联网行业的软件开发过程中，必须采取小步快走、版本微创新和快速获取用户反馈，只有这样才能体验客户第一，改变软件服务的对象观念。第二个互联网软件开发测试的特点就是快，行业觉得要快速实现新功能并快速发布，快速修复线上存在的问题。

　　在很多互联网公司，开发和测试团队往往是技术团队的主力军，信息更新快捷和项目需求发布的频繁，很多程度上与传统软件开发和测试过程分离开来，组成比较小的团队进行软件开发与测试，这样有利于处理需求的响应速度的提升，也有利软件开发过程的风险和资源管理。

　　3）采用的工具协助敏捷开发测试过程，提出了自动化测试

　　大家知道，如果缩短软件开发和测试过程的时间，在保证需求质量的前提下，我们必须提供我们的过程效率，那么如何提高呢？这里就引起在互联网软件项目中的自动化测试，尤其在软件测试过程，自动化测试不仅仅是测试技能的提升，更是能给测试工程师乃至整个研发团队带来质的价值和创新，是真正提高了整个研发过程的效率。自提出自动化测试以后，工程师不断研究与实践，发现自动化脚本与更新维护成本非常大，久而久之维护的工作量已超出预期评估时间，这样导致要花大量的资源投入自动化维护，增加成本，经过大量项目实践与分析，在互联网行业的自动化不能是单纯的基于页面UI功能自动化，必须基于架构进行分层设计自动化，深化自动化技术和平台化的服务，做到持续集成才更有效。

　　3、敏捷测试思维

　　通过了解互联网系统架构和软件开发测试过程，我们必须改变以往的测试思维和测试策略，抓住Web软件测试的特点综合选取更适合的方法去运用，直到提出持续集成构建，才在项目中慢慢推广应用起来，其实就是采用敏捷的开发过程和测试思维相结合，把软件开发整个过程质量控制提到上游。

　　四、持续集成介绍

　　1、持续集成是什么

　　大师Martin Fowler对持续集成是这样定义的： 持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

　　在敏捷开发与测试中，持续集成是极限编程十二实践之一（1999年Kent Beck编写的《解析极限编程》），最初被使用极限编程方法的开发人员所推捧，并在过去的几年中得到广泛应用，成为业界广为人知的软件开发实践。该实践用于解决软件开发过程中一个具体且重要的问题，即“确保当某个开发人员完成新的功能或修改代码后，整个软件仍旧能正常工作。”

　　简单来说，持续集成是频繁、持续的在多个团队成员的日常工作中进行集成、验证并反馈。一个典型的持续集成周期基本包含如下几个步骤：

　　1）持续集成服务器不断从版本代码库的服务器上检查代码状态，看代码是否有更新；

　　2）若发现代码有最新的提交，集成服务器就会从版本代码库服务器下载最新的代码；

　　3）等代码完成更新结束后，持续集成服务器调用自动化编译脚本进行代码编译；

　　4）运行所有的自动化测试；

　　5）进行代码分析

　　6）输出可执行的软件，提高给测试人员进行最后的测试与验证

　　7）通过测试工程师的测试与验证，最后发布集成到发布

　　通过上面的持续集成构建步骤我们不难知道，其实持续集成就是一个循环、多次运用、统一检查的过程，如图-2所示描述

图-2

2、持续集成模式

　　根据持续集成在项目中的运用与分析，从基础搭建模式到企业级的解决方案模式，基本可以分成下面三种模式，它们分别是递增的关系，在软件开发中随着系统的复杂度和测试件的可测性不断改进的过程，最理想的持续集成达到是统一化、流程化和服务化的过程。

　　1）基础模式

　　目前，有很多种持续集成工具，其中不乏开源产品，如Maven、Hudson平台。项目伊始，我们可以建立自己的持续集成服务器，整个项目的持续集成基础结构如图-3所示：

图-3

　　并发多个工程师进行代码开发，每个工程师有独立的开发环境和开发分支，然后统一提交到中央代码库，最后进行统一集成编译。

　　2）阶段式模式

　　在基础模式的框架基础上，我们增加软件开发过程单元测试、静态代码检查、UI功能自动化检查，如图-4

　　阶段模式的持续集成较集成提升了很多，在集成server中增加了很多构建套件，综合利用持续集成的特点进行统一管理。

图-4

　　3）管道模式

　　阶段式持续集成重复任务多，而过程化集成的管理复杂性太高了，任何过程化上的变化都要修改已经写好的脚本，而这些脚本维护比较困难。既然以上两种模式都不灵了，所以就引出了高级模式就是管道式的持续集成模式。

　　管道式持续集成形式上与过程化持续集成相类似，但却在概念上有显著不同。在管道式持续集成中，所有的过程单元都运行在同一管道的上下文中，即各单元所使用的原材料都是完成相同的，即代码基线相同。当持续集成服务器发现有新的代码时，会创建新的一个管道，所有的过程单元都在这一个管道中运行，包含编译打包、单元测试、功能测试、性能测试和自动化测试。而每个单元产生的产物也在该管道中有效。如图-5所示：

图-5

　　不难看出管道模式的持续集成综合了基础模式和阶段模式的优点，在管道式中，每次构建都会试图从管道的一端走到另一端。因此，你不会遗漏任何一个版本的成功产品代码，基本上可以使项目研发过程全部自动化了。

　3、持续集成流程

　　一般在互联网软件开发和测试过程中，增加了持续集成构建，在开发和测试环节会进行多次集成与构建，做的比较好的公司，如google，微软等，可以集单元测试、功能自动化测试等集成在一起构建，做到分支代码变更脚本通知一条龙智能流程化和服务化，可见下图-6流程所示。

图-6

　　4、持续集成优点

　　通过上述概念和模式的阐述，让读者很容易发现持续集成最大的优点就是降低风险，提高项目研发过程的效率和质量，迎合在互联网时代信息快速更新的现象。持续集成本身并不能帮助开发工程师找到bug，它是通过不断的测试和反馈来尽早的发现缺陷，问题发现的越早处理问题的成本就越小越容易解决，由于无法证明通过了测试的代码是无bug存在的，所以持续集成中的测试非常重要，好的测试能够更多更快的发现当前版本中的错误。

　　往往在开发和测试过程中，软件的缺陷是累积性的，当缺陷很多时，就很难发现它们，利用持续集成构建的思想，在项目过程中可以尽早的发现缺陷，最大限度的降低了我们在项目后期发现缺陷的可能性和偶然性。

　　每成功构建运行一次就意味着之前做的代码提交可以成功集成，没有与他人提交的分支代码发生冲突，没有带来新的缺陷，有利于开发人员对项目保持自信心和提高工程师的工作激情。

　　持续集成在项目中的频繁部署将会使最终部署的难度降到最小，用户能够看到频繁上线的软件，并做及时的沟通反馈，有助于增强互联网模式下用户的信心和动力，也有助于Web产品化和服务化朝着正确的方向快速发展。

　　5、持续集成构建分析及工具

　　在敏捷的软件开发和测试团队中，我们所要做的只不过是：不断的回顾、找出问题与瓶颈、不断地重构。通过不断重构持续集成基础结构以及自动化构建脚本，使其达到我们对“反馈时间”和“判断质量准确性”的要求。另外，我们已将“持续集成”扩展到整个软件开发周期，涵盖了持续部署及发布。在上面的配置文件中，不难看出在管道模式中的两个Stage分别名为 “UAT”测试和交付的“Production”，它们一个用于部署新版本到我们自己的持续集成服务器，另一个用于部署新版本到一个公用的持续集成服务器。部署 ‘UAT’的频率为两天到一周之间，‘Production’的频率基本都是一周。这样，我们可以得到快速反馈，改进自己的产品，同时其它团队可以尽早地使用我们开发的新功能。

　　目前业界主流的持续集成工具主要有：Apache Continuum，CruiseControl，Hudson，Maven，LuntBuild等等，开源工具使用的比较多是Hudson框架。

　　五、Hudson介绍

　　1、Hudson简介

　　是一个功能强大的持续集成框架，可以持续构建和测试软件项目，并监控持续集成中生成的报告，属于开源框架，可以进行多元化插件开发与集成。

　　框架的优点是基于WAR包，安装部署非常简单，提供了功能完善的Web管理界面和强大的报告输出功能，另外就是有丰富的插件支持，并支持自动化安装，便于维护。

　　2、核心应用

　　由于是开源框架，在项目实践中可以不断完善我们持续集成过程存在的问题，可以集成更多的插件解决我们想要自助的集成模式。

　　目前在笔者参与的项目中的核心应用主要有几个部分：

　　1）静态代码检查（Findbugs工具）

　　2）单元测试（Junit）

　　3）代码覆盖率检查（Cov）

　　3、安装与配置

　　开源框架，有便利的安装指南，安装起来非常快捷，主要步骤有：

　　● 下载Hudson WAR包

　　● 部署到Jboss服务中

　　● 安装Html Report Plugin插件

　　● 安装Cobertura Plugin插件

　　● 安装Findbugs Plugin插件

　　● 创建分组视图和用户权限

　　配置也比较简单，主要配置插件和SVN代码及环境相关的条件，我们先看下配置插件，见下图所示：

　　Cobertura配置（图-7）

图-7

Findbugs的配置（图-8）

图-8

　　在Hudson持续集成平台中创建一个Job（图-9）

图-9

　　下面是配置代码库，以Svn代码库代码管理为例（图-10）

图-10

　　后续进行配置定制执行任务和执行shell脚本，然后完成生成单元测试报告和生成代码覆盖率报告的配置，最后完成生产bug扫描报告和自动发生邮件提醒的配置，当然也开源插件集成到自动发到手机提醒。都配置完成后就可以进行build 运行查看配置信息的报告，如果都通过自己在项目中需求的话，基本配置就完成了，后续在项目中就能发挥Hudson平台进行持续集成带给我们价值。

　　六、 Hudson在项目中的应用

　　可以看出，持续集成的关键在于完成的自动化、完成的流程化，需要借助相关工具和平台才能完成，所以持续集成环境的搭建需要花费比较大的精力，但是环境一旦搞定后，只需要花费很短的时间去维护，而且可以给我们项目开发和测试的效率带来很大的回报。根据持续集成的重要实践，下面以笔者工作中的实例，主要是在Hudson平台进行持续集成进行应用和分析，在项目中的持续集成流程，详见下图-11说明

图-11

　　下面以当前正在开发的一个项目（项目名称为Campaign）为例说明Hudson在项目中的应用及分析，如图-12所示：

图-12

　　从Hudson持续平台上截图中可以看到，目前这个项目并行有5条分支（应用）在开发，平台上很清晰的记录了每个应用开发过程构建集成的记录信息，如成功、失败和持续的Time，图中s列颜色分别代表了：蓝色-集成构建通过，黄色-集成构建（冒烟失败）不通过，还有一种红色-集成构建过程编译失败或发生错误。

下面分别拿不通过和通过的两个应用分支来看（Campaign-Bss和Campaign-Settle）

　　（一）先看Campaign-Bss（图-13）分支集成情况：

图-13

　　图-13中标红圈起来的我们一一说明和分析下：

　　● 左侧表示：持续集成的历史记录，可以看出有红色编译失败或错误阶段到黄色冒烟失败的build history记录

　　● 右侧表示：插件集成后检查，如Findbugs（静态代码）检查、静态代码检查，单元测试和UI自动化覆盖率检查。图-13中覆盖率的图很明显随着Build次数覆盖率是提高的，也就是说最后的Build覆盖率肯定比前一次要好，质量要高，直到达到约定的提测条件时且主干无failed的情况下才通过（主干无failed是只单元测试脚本在研发过程中可能有变更，如添加、修改和删除，有运行失败的风险，所以要求研发工程师要保证单元测试脚本每次Build后必须是100%Pass）

图-14

　　● 进一步查看Coverage Report 我们不难发现更详细的信息展现在我们眼前，如图-14所示，比较详细的输出了工程包摘要，如Lines（代码行覆盖）这里统计代码行共计525行，完成覆盖245行，所以结果统计是Lines为47%

　　● 分析下下面圈起的信息是显示代码框架中（接口）实现类、方法的名称（如dao层和bo业务的接口实现类等信息），其中com.ali.bp.bss.activity.dao.impl 在Conditionals为N/A（说明开发还未提交代码集成），可以通过下面名称详细查看代码覆盖率覆盖的情况

　　（二）再看Campaign-Settle（图-15）分支集成情况：

图-15

图-16

　　Campaign-Settle分支集成通过后，总体无Findbugs增加，Lines覆盖率为63%，从图-15和图-16中不难看出比Campaign-Bss分支集成后的质量要好。

　　通过这个项目的案例我们来做个小结与分析，从上面（一）和（二）持续集成分析报告来看，（二）的结果最终是集成成功且冒烟通过，而（一）被测试退回重新修复问题再等待集成验证。我们通过Hudson这样的一个持续集成平台，规范了研发过程的集成测试流程，让测试协助开发一起提升整个研发过程的质量和效率，提高软件系统的上游质量。

　　很明显目前我们在项目中运用的持续集成还没有到达管道模式的一体化平台，像UI功能自动化当前是在另外一个系统上运行，如果没有通过在Hudson平台配置的话，在持续集成平台中是看不到运行结果报告的，另外还有一些插件有待后续进一步研究与实践，像在C++框架模式如何实现Hudson持续集成目前还是调试实践中，当然业绩也有很多好的关于持续集成的平台与案例学习与借鉴，还是希望能通过项目实践证明持续集成能真正解决当前互联网行业软件开发模式存在的一些问题。

　　七、结束语

　　结合笔者在互联网行业工作经验，浅谈了在前端基于java应用的软件测试过程中，我们运用敏捷的开发和测试思想，采用Hudson持续集成构建平台，整体打破了传统测试思维，经过多个项目的实践证明，采用持续集成提升了软件开发和测试过程的质量和效率，提高了互联网软件生产效能。

　　我们说持续集成并不是一蹴而就的工作，要想真正做到管道的持续集成构建模式，需要在项目过程中不断积累经验来提升与改进，当然实施持续集成也是需要根据团队的实际情况来实施，但这并不能成会“偷赖”的另一个说法。俗语道“没有做不到，只有想不到”，只要不断反思、重构与实践总结，在互联网软件测试过程中创新每天都会出现。

　　在软件系统开发完成后，必须进行测试和评价，以确定软件质量是否达到预定目标，这样才能保证软件系统安全可靠地运行。通过软件测试可以尽可能地和尽可能多地找出各种隐藏的错误和缺陷，及时进行修改和弥补。软件测试将直接影响到软件产品的最终质量。

　　测试组的任务是用尽可能高的精度测试所开发的软件产品与规定需求的差距及其应用时的适用性。如果发现缺陷，则软件产品不能通过验收和使用，并退回给开发组。测试组的另一个任务是制定软件应用计划，负责计划在生产领域如何正确地使用程序及数据库。

　　测试组的职责是确定测试过程、测试计划和组织测试过程及执行测试，但是不负责被测试系统的质量。

　　测试组能够有效地、成功地完成任务的关键因素是要有专门的测试设备、现代化的测试数据库和测试工具。

　　在软件开发过程中，需要采用分析的质量保证措施来对软件产品进行测试和评价。分析的质量保证措施包括静态测试和动态测试。静态测试在对软件进行分析、检查和测试时，不实际运行被测试的程序。动态测试是通过运行程序来检验软件的动态特性和运行结果的正确性，并根据程序的运行过程对程序进行评价的过程。动态测试是依据经验进行测试的过程。它试图使用定量的输入，依靠经验来调整程序，使其与规范的偏差在容许的范围内，容许值取决于质量需求。动态测试也可以看成是一个评价和验证系统或系统部件的过程，它采用人工的或自动的方法来辨别实际成果与期望成果的差别，并使系统满足规定的需求。

　　动态测试中常用的技术概念：

　　1、测试：可看成是运行程序的过程，其目标是找出错误。

　　2、调试：找出引起错误的原因的过程。它要规定怎样修改错误、检查修改后对程序的影响并进行修改。调试错误后要进行再测试。

　　3、错误：是指计算值、观测值、测量值之间，或条件与真值之间，不符合规定的或理论上的正确值或条件。

　　4、缺陷：是指与期望值或特征值的偏差。缺陷能影响程序的功能，例如：一个程序可能有好的功能，但其可维护性可能很差。缺陷可以发生在所有产品质量规范规定的特性中。

　　5、失效：是指功能部件执行其功能的能力丧失。一个部件的失效或影响较高层单元的运行或产生严重的后果。失效将影响产品的可靠性。

　　6、故障：是指功能部件不能执行所要求的功能。可能由错误、缺陷或失效引起。故障可影响程序的有效性。

　　二、软件测试规范：

　　测试组在测试过程中应遵循一定的命名和设计规范，以此来保证程序的标准化和可维护性。测试组需要遵循的规范暂时包括如下几个：VB编程命名规范、数据库命名规范、数据库设计规范。具体内容请参考各文件。

　　测试中发现的问题和测试方法规范如下：

　　1、软件错误等级定义表（Error Class）

　　2、软件错误类型定义表（Error Type）

　　3、常用软件测试方法（Testing Method）

　　建议采用以下测试方法：

　　1、黑盒法（Black Box）；

　　2、白盒法（White Box）；

　　3、可用性测试（Usability Testing）；

　　4、单元测试（Unit Testing）；

　　5、集成测试（Integrate Testing）；

　　6、功能测试（Function Testing）；

　　7、负载测试（Overload Testing）；

　　8、性能测试（Ability Testing）；

　　9、安装/卸载测试（Install / Uninstall Testing）；

　　10、验收测试或@测试（Check&Accept Testing）；

　　Item 1. 项目的逻辑结构混乱（这里的“项目”是版本控制中的术语，见A.1）

　 　这是在实施版本控制过程中一个容易出现的问题，尤其是对于项目开发（此处非术语）。其原因有很多，比如：开始时对需求不明确，导致软件本身结构混乱，使 在定义软件的逻辑结构时，时常变化。又如：一个团队中，大家各自都之关心自己负责的模块，每个人各自制定适合自己的逻辑结构，导致最终的项目结构是一个大 杂烩（多个结构组合而成）。久而久之，就会导致软件管理混乱，增加维护负担，反而降低效率。结构中，有的目录可能是“死角”，永远都没有使用到；有的目录 可能是重复的，造成冗余；有的目录可能大家同时在用，各自对代码的修改彼此影响。自始至终合理安排和规划项目的逻辑结构，这是一定需要坚持的。

　　Item 2. 多人修改同一个文件

　 　一旦出现这样的情况，很有可能某人辛勤劳动的成果，会被别人毁于一旦。其解决办法是：在一般情况下，确保在任何时刻都只有一个成员对某个特定的文件进行 修改，这样可以防止文件被其他成员的修改意外更新。为了适应多人同时修改同一个文件的情况，版本控制管理员也可以改变此缺省设置以允许对单个文件同时有多 个签出（checkout），并且仍禁止对他人的修改进行覆盖。

　　Item 3. 本地版本和服务器版本不一致

　 　有时会碰到这样的情形，开发人员在从服务器那里更新本地版本时，只更新了部分内容，导致本地编译不通过。应该时刻注意保持本地版本和服务器版本的一致 性，这是一个认识的问题，因为服务器版本才是真正唯一有效的。多个程序员还必须注意不要为了解决同一个问题而浪费时间。对某项功能的实现，由于本地和服务 器的不一致，导致大家重复实现。应该对服务器端数据的全部内容，包括所有子文件夹，定期进行备份，这是绝对重要的一项工作。

　　Item 4. 用户权限混乱

　　对于所有开发人员和各自负责的模块，根据实际情况，制定合理的用户权限，哪些人对哪些目录只有可读权限，哪些人对哪些目录有读写权限。不应该出现所有人都是管理员这样的极端情况。

　　Item 5. 手工修改文件的只读标记

　 　为了防止你对没有签出的文件进行修改，版本控制管理工具会将这些文件指定并标明为只读文件。当你签出一个文件时，只读标记便被删去。一种经常出现的不良 习惯是，为了图省事，在没有签出文件时便试图修改文件，当发现文件不能保存时，便手工修改其只读标记。这是一切混乱的“源头”，它将导致不一致、有效内容 被覆盖等问题。

　　Item 6. 没有指定工作目录或存在多个工作目录

　　每个开发人员必须拥有一个独一无二的工作目录，它不能与任何其他开发人员共享（这里的“工作目录”是版本控制中的术语，见A.2）。

　　Item 7. 频繁的签入或很少签入

　　掌握好签入的时间，比如一天，或者在其他人需要的时候。并非每次微小的改动都需要马上签入，也并非每改完一个文件都将其签入，但也不要忘记签入。

　　Item 8. 从服务器上获取最近版本时的疏忽

　　如果选择获取当前已经签出并且已经修改的文件最新版本，操作时必须非常小心。如果你选择取代文件，你将用最近一次签入的文件版本改写你做的修改，这可能会使你所做的工作白费。大多数情况下，最保险的做法是选定Apply To All Items，并选择Leave。

　　A 软件版本控制中出现的几个主要概念

　　参考Visual SourceSafe，这里列出几个主要的基本概念。

　　A.1 项目（Project）

　　版本控制的一个单位，包含若干不同类型的文件。其下所属代码及相关文档，以目录结构分别存放。一个软件可以对应一个或多个项目，视情况而定。

　　A.2 工作目录（Working Folder）

　　开发人员对项目文件进行调试修改的地方，一般位于本地机器上。开发人员签出（checkout）项目中的文件时，将被拷贝到工作目录下，当修改完文件后，开发人员再将文件从工作目录签入（checkin）服务器。

相关链接：

没有使用版本控制的黑暗时代——版本控制心得（一）

版本控制之我见——版本控制心得（二）

　　多通道 描述的是具有多个界面的应用程序。随着我们从桌面发展到基于 Web 的计算甚至是移动计算，多通道越来越常见。由于设备（平板、手机、 笔记本电脑、台式计算机）以及与设备交互方式（特定于设备的 “应用程序”、浏览器和传统的客户端应用程序）的组合，同一个应用程序的界面越来越多。比如，使用相同业务逻辑的面向 Web 应用程序、移动应用程序甚至是一个 CLI（命令行界面）的银行应用程序。由于面向服务的架构 （SOA） 和 Web 服务日益流行，在很多情况下，集成者要做的工作就是把服务与新的前端重新组合。但业务逻辑（亦称服务）则保持相同。

　　以开发团队重用代码来减少维护成本并提高生产效率相同的方式，要跟上开发团队，测试团队就需要一些方法来重用测试场景并实现自动化。

　　应对多通道测试的挑战

　　几年前，我是一名自动化测试架构师，负责为具有多个界面的两个（而不是一个）应用程序构建所有的自动化。二者都有遗留的 “本地” 用户界面，使用的是 Microsoft Windows 32 位 MFC （Microsoft Foundation Class） 控件、一个使用了 JavaScript 的 Web 界面、ASP 和 JSP（Active Server Pages 和 JavaServer Pages）、一个新的（更新的）Eclipse SWT （Standard Widget Toolkit） 界面以及一个命令行界面。当然，不可能找到对所有这些界面均有效的自动化工具，但我们可以暂时将其放到一边。

　　编程时，您往往会专注于通 过促进重用减少需要维护的代码量。有了面向对象的编程和重构，很少有理由需要在多个地方具有相同的代码了。但是需要设计一个架构，这样我就可以考虑如何从 一个单一的测试自动化代码库解决多个界面的测试。首先，尽管它们是同一个应用程序的所有界面，但并不是所有的界面都会浮现相同的功能，更不用说使用同样的 方式了。但也有许多以客户为中心的场景（用例），这对跨所有界面进行测试很有意义。

　　然而，负责设计测试用例和测试计划的测试团队没有以这种方式考虑他们的测试。事实上，他们是分离的，并根据他们所要处理的界面以竖井方式分离。构建并测试了该 CLI 的团队认为他们只需要少量的客户场景测试。他们主要集中于单元测试， 并没有真正考虑通过 CLI 的一个客户流。负责 Eclipse UI 的测试团队想要大量的 UI 特性和自动化的功能。他们有一长串需要执行的测试用例，要实现这个目标，需要完全专注于客户流。但是，我们为什么就不能使用由主题专家 （SME） 为应用程序煞费苦心完成的用来测试所有界面的这些信息呢？

　　一种层次结构方式

　　使用 面向对象的编程 （OOP） 的典型测试自动化框架一般会抽象化控制集的实现细节，而不是通过控件表达的概念性操作。这实际上是许多商业 GUI 自动化工具使用的方式。例如，所有文本字段会接受文本，用 setText（string） 方法定义一个文本字段类，并在此应用程序的所有版本上使用它。但这并不适用于跨界面构建自动化测试的所有情况。当一个 GUI 使用单选按钮而另一个使用复选框时会发生什么呢？您实际上不能对于相同操作依靠于同一界面。以下显示了这种传统的 OOP 方式。

图 1. GUI 控制层次结构

　 　在我们的示例中，界面的差异很大，但所代表的操作和业务流程则实质上相同。为了最大化重用，我们选定了一个业务逻辑层次结构（参见图 2）以跨多个界面重用测试场景。这不仅能最大化我们的代码重用，还意味着将会依赖测试工具来管理 GUI 界面，而这正是他们的设计初衷。图 2 显示了此方式，您可能已经识别出了这个抽象工厂模式。

图 2. 业务逻辑层次结构

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 推荐标签： Bug 软件测试 缺陷管理

　　微博上抛出一个讨论话题：下午一test lead问到，有些测试的 bug会在A版本里出现，然后记录它；但开发人员在当前B版本试图重现时发现不能重现，故reject它。那么测试就郁闷了，待到下一轮回归测试可能是C 版D版本，如果再出现自然reopen，但如果不复现是否真的应该关掉它吗？各位对这种sometimes bug怎么处理的啊？

　　这个问题可能每个测试人员都会遇到，我说说我个人观点，供大家讨论。

　　1、在A版本发现的bug应该在A版本进行重现

　 　我们知道，有很多原因会导致A版本的bug可能不能在B版本重现：1）开发人员自己偷偷解了bug，以免受到KPI考核；2）环境差异，可能B版本的代 码在A版本的环境也会出问题，但是在开发环境可能就不能复现；3）代码变更，也许是其他的代码引起的bug，B版本时其他开发已经修改，此类可以归纳为相 关联功能引起的bug；4）AB两版本进行复现的前置条件及步骤已不同。

　　既然有这么多可能性，那我们就应该排除影响，让问题简单化，保持环境和代码一致的情况下进行复现。A版本的bug如果在B版本不能复现，时间和条件允许的话，那就回退代码到A版本，有个前提不用回退，那就是已准确定位问题了，并且确定在B版本已经解决它了。

　　2、项目时间允许的情况下，开发人员应大力协作复现bug

　　对于”疑难杂症“，开发人员应大力配合测试人员进行复现：1）如果对于不好调试的代码就打印更多log；2）可以通过连接测试环境数据库并 回滚代码到A版本，根据获悉的已有情况添加断点调试代码；3）做更细致的code review等等方式。在自己负责的那部分代码确定完没有问题，这时候就需要考虑到接口，是否在接口数据处理上的问题，就需要其他开发人员配合。而测试人 员需要尽最大努力来还原当时的场景：环境，数据，前置条件及测试步骤等。

　　3、测试人员要再次确认用例设计的覆盖度及周密性

　　有几种情况会导致不可复现：1）环境；2）代码；3）数据。而数据又可以归纳到代码容错性处理上，环境其实是可以很好还原的，那出现不容易复现的bug就大多数是归于代码和数据上了，对于测试而言，用例设计的覆盖不够，不够严谨就会导致bug不在我们的掌握中。

　　这个时候，我们有两种情况：一是原本用例就没有好好设计过，未经评审过，大家测试时就很随意，勿容置疑，赶紧把用例好好琢磨琢磨，再叫上项目相关人员进行评审，这么做的目的也是为了保证测试用例得到了项目相关人员的认可，各种情况大家都讨论过，保证在需求上大家的一致性，保证软件覆盖度能满足本次项目需求的要求，做到需求100%覆盖，开发人员若再提出更多建议，那也可以弥补一些黑盒测试时可能遗漏的情况；二是该项目已经经过严格的需求评审及用例评审了。当然，即便如此也不能避免漏测以及对特殊情况的考虑。

　　当然，要这么做的前提是这个bug很严重，影响了版本的发布，有必要召集大家协力解决掉它。

　　4、绞尽脑汁，它仍然不能复现时，保持关注

　 　我相信，通过以上步骤的努力，仍然不能复现的bug一定是优先级不高的，那就再评估重要度，若通过项目组决定不影响版本发布，就密切关注此bug，在发 布后验证时也重点关注下。而且该bug不能关闭，依次往以后版本中顺延，并且每轮测试时都要尝试再次复现。那何时可以关闭呢？也许3，5个版本发布后，没 有出问题就可以决定关闭它了。

　　5、思考测试流程及测试规范，及时更正走过的弯路，制定提交bug的规范，便于开发及我们自己复现

　 　有一次，就会有第二次，我们应该及时响应，即便不能亡羊补牢，也要防患未然。 提交bug的规范，这个可能每个公司情况不一样，有些公司木有限制，提交的bug也是千人千面，这对于开发人员理解bug和复现bug无疑增加了难度。而 规范了bug提交，若记录了此bug的前置条件，使用的数据及操作步骤，可能会大有益处。当然，此处不是说每个bug都这么详细。

版权声明：本文出自 zzzmmmkkk 的51Testing软件测试博客：http://www.51testing.com/?258885

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。

　　随着计算机软件技术的发展，各种计算机软件种类繁多，功能各异，加上计算机软件规约的约束和发展，软件的规范性变得更加重要。为了开发合格的软件，在软件开发过程中，离不开软件测试。为了更好的完成软件测试工作，在软件测试过程中进行配置管理和版本控制尤为重要。

　 　本文首先介绍了软件测试过程中的配置管理概念和版本控制概念，然后对软件测试过程中的配置管理和版本控制做出了详细分析，论述了配置管理的流程、方法意 义。接着介绍了版本控制的评价标准，软件测试过程中版本控制方法的应用及几种版本控制软件，最后阐述了在软件测试过程中的版本控制的作用，以及怎样有效的 在软件测试过程中进行软件测试版本控制。

　　关键词：软件测试；配置管理；版本控制；

　　1、软件测试的基本概念

　　在现代社会，随着计算机时代的到来，计算机的应用已扩大深入到社会生活的 方方面面，而随着计算机技术和计算机软件的不断发展，软件的规模日趋大型化和复杂化，致使软件开发中的软件测试工作变得越来越繁杂，工作量越来越大。为了 更好的对软件测试进行控制和管理，节约时间、人员、成本等，软件测试中的配置管理和版本控制随之产生。对软件测试中的资源如何调配，人员如何配置管理和控 制成为我们更加关心的问题。

　　对此，为了理解软件测试中的配置管理和版本控制，我们先了解软件测试的概念和意义。当我们清楚的认识到为软件测试的作用和意义，我们才能更加清楚的认识到软件测试过程中的配置管理和版本控制的重要性。

　　1.1 软件测试的概念

　　软件测试作为软件开发过程中的重要组成部分，是用来确认一个程序的品质或者性能是否达到开发之前所提出的一些要求。换句话讲，软件测试就是为了发现程序中的错误而不得不进行并且不可避免必须要执行的过程。

　 　从一个软件的立项之初，软件测试工作就将开始，并且将会贯穿整个软件开发过程。首先了解下测试人员的任务：寻找bug，避免软件开发过程中的缺陷，衡量 软件的品质，关注用户的需求。通过了解测试人员在测试过程中的任务，我们就会对软件测试产生一个大概的了解。进行软件测试工作的最终目的是什么呢？目的其 实只有一个就是要确保软件的质量。满足用户的需要，使用户对软件质量产生足够的信心。

　　1.2 软件测试的分类

　　软件测试是一项复杂而又细致的工作，作为计算机科学的一门学科，它自有其独到的作用和规则。软件测试从产生一直发展到如今，已经拥有了很完善的软件测试理论体系和知识概念体系。如今，软件测试大致分为功能性测试和性能测试，其中又包括手工测试和自动化测试。 随着软件测试工作的日益繁杂和工作量的加大，手工测试不再能够满足测试需求，因而自动化测试越加显得重要。我们之所以做这么多工作，都是为了检验程序是否 满足规格需求说明书，能否满足用户需求，或者预期结果与实际结果之间的差别。通过了解软件测试的分类，我们知道软件测试在软件生命过程中的重要性和不可或 缺性。

　　1.3 软件测试的国内外现状

　　为了了解软件测试在国内外的现状，我们经过 深入调查了解到，随着软件开发的日趋成熟，国内外的软件企业逐步认识到软件测试在软件开发过程中的重要性。软件测试受到国内外软件企业越来越多的重视，纷 纷不约而同的加大了对软件测试的投入。我们先看两组数据，2007年中国软件企业对软件测试的投入为：1%一下：24%；1%-5%：34%；5 %-10%：22%；10%-30%：16%；30%以上：4%。我们再从微软的 项目人员比例上看：Windows200 Team：程序经理 450，开发人员 900， 测试人员 1800，技术支持人员 600， 技术传播人员 1120， 本地化人员 110，培训人员 115，文档人员 100，市场人员 100， 内部IT 50，合计 5345。仔细分析对比这两组数据，从中我们可以看出，国内外软件企业对软件测试的重视程度，他们不惜将大量的资金，人力物力投入其中。国内外的软件企业 之所以如此重视软件测试，原因只有一个那就是软件测试已成为软件开发过程中不可或缺的一部分。假如软件开发过程中离开了软件测试，我们可以想象后果将会有 多么的严重。首先我们无法保证软件的质量，也无法保证软件是否满足用户的需求，也无法保证我们程序的可用性。在软件开发中如果不进行软件测试，很可能使我 们的程序成为镜中花水中月，不可实现。唯有充分了解软件测试在软件开发过程中的重要性，我们才能更加重视软件测试工作。

　　了解了软件测试 在软件开发过程中的作用和意义，以及国内外对软件测试的重视程度和资源投入对比，为了保证软件质量，使我们的软件更加符合用户需求，我们应当思考如何更好 地进行软件测试，在软件企业投入了足够的人力物力等资源之后，怎样利用这些资源来更好的进行软件测试工作自然成为了我们应该思考的问题。

　　2、软件测试的测试配置管理

　　2.1 进行测试配置管理的必要性

　 　在拥有了足够的资源和人力之后，我们能否认为软件测试工作可以很好的进行并且能够保证软件测试过程不会出现问题呢？也许我们认为只要需要的测试条件满足 了，我们就可以圆满的完成测试工作了，其实这样的观点是错误的。软件测试工作是由人来进行的，因而首先要考虑到人的问题，一项工作只要有人的参与，就必须 要将人的因素考虑进去。人无完人，金无足赤，测试人员对软件测试工作造成的负面影响在软件测试中是不能够忽略的。软件是由人来编写实施的，但是软件开发又 是一个极其容易产生错误的复杂过程，因其产生就注定了它不会是一个简单的过程。尽管程序员和软件工程师等为了完善软件而做出了巨大的努力和工作，但是软件 错误仍然是不可避免的。世上不存在百分百完美的软件，因此软件过程中的软件错误是不可避免的，这是他自身的一种特性。我们所能做的就是尽量减少软件中的错 误，争取做到使这些错误可以忽略不计，或者尽量不影响我们的正常使用。给定了足够的资源之后，我们再进行软件测试工作，这时仍然不能认为没有问题了，还需 要在软件测试时进行配置管理。在软件测试中缺少了测试的配置管理我们是做不好测试工作的。我们进行软件测试就是为了以最少的时间，最少的人力物力去尽可能 多的发现软件中潜藏着的各种错误和缺陷。但是伴随着软件测试工作量的加大，软件企业仅仅投入更多的人力物力以及其他各种资源是不够的，他们还需要思考除此 之外怎样才能更好的进行软件测试。为了更好的进行软件测试，我们应该对测试人员、测试环境、生产环境进行配置管理。只有建立了完整的合理的软件测试配置管 理体系，软件测试工作才能更好的进行，更加完美的完成测试目标。

　　如果在软件测试过程中缺少了测试配置管理将会造成及其严重的后果。据我 们实际调查了解到，在日常的软件研发工作中，很多软件企业都会或多或少的在软件测试时遇到很多的问题，而这些问题的产生都是因为在测试过程中缺乏配置管理 流程和工具。因为人员具有频繁的流动性，并且在组织的过程中会产生知识和财富的流失，再加上现代社会的激烈竞争，如果一个企业没有设计配置管理流程和使用 必要的配置管理工具，就可能会因此而造成无可估量的损失，甚至导致整个软件项目的崩溃。因而作为一个软件企业，必须要做到及时了解项目的进展状况，对项目 进行管理，遇到突发状况的解决。软件工程思想发展到现在，认为在软件过程中如果能够越早的发现缺陷和风险，这时只要采取相应的措施，所要付出的代价就越 小。缺乏配置管理流程的一个很明显之处就是测试过程中缺乏并发执行的手段，没有了配置管理的支持，软件过程中的并发执行将会变得十分的困难。这时往往会造 成修改过的bug重复出现，又或者几个人员进行相同的测试工作和进程，从而产生不必要的浪费。如果企业不能很清晰很流畅的对整个软件测试过程进行管理，就 会造成测试工作的不同步，不一致。在测试工作中需要测试人员完成的没有完成，而暂时不需要或者以后在完成的却首先完成了，这样会增加测试工作的复杂性和难 度，因此我们需要在软件测试中进行配置管理。

　　由于公司及部门的发展，项目经理已经开始面对人数众多，时间跨度较长的版本管理挑战。

　　如张湘辉（1994年加盟微软，现任微软大中华区CTO）所说：

　　以Windows 7为例，包含七八千万条甚至上亿条代码，五六千人同时开发，还有很多合作伙伴确保周边产品兼容。对这样一个超大的项目而言，不能一眼盯到结果，不能像跑百米一样，始终盯着终点。我们的经验是盯终点肯定乱，因为要经历非常漫长的过程。

　 　从心理上说，当发现离终点还很遥远时，人就会泄气，不能以那么快的速度玩命跑下去。最好的方式，是将事情分成很多步骤来做。Windows7从开始到完 成可能要耗时两年，以两年时间为一个周期，那么前六个月团队就会被弄垮，所以你必须以也许每两个月为一个终点。就像跑一千五百米，我们要考虑第一圈跑多 快，第二圈跑多快。

　　这就需要把每个终点区分得很好，设定有效的里程碑，在逻辑上要很精准，是不是到了这个里程碑，同样要非常清楚。这样每个里程碑达到时，大家可以庆祝一下，重又奔向下个目标。如同爬珠穆朗玛峰，没有说不断爬上去，而是先到大本营，再到第几个营地，最后才能登顶。

　　从过去的3.0，BM2.0等较长时间的版本管理中，能够看出我们的里程碑管理做得并不好。以前的里程碑就是一些项目关键时间点的划分，例如：转测试，转联调等，项目组在里程碑处的行为基本就是核实是否满足进入下个阶段的标准，满足则进入。总体来说项目还是以最终发布时间点为目标，这样非常容易导致团队的疲惫。因此结合部门历史经验和其他公司的做法，产出里程碑管理的概念。

　　二、目的

　　里程碑管理目的是解决时间跨度较长或任务比较艰巨的版本管理问题。里程碑管理期望可以达到以下4个效果：

　　1、使团队将长期目标划分为不同的短期目标，就像跑长跑一样，不是以5W米为目标，而是把目标分解到每一圈

　　2、在里程碑处，团队进行有效的休整。就像队伍打仗时，一定要有休整，才能持续保证旺盛的战斗力

　　3、促使组员进行上个阶段的总结，找出自己的不足，并吸取其他人的优点，从而让组员进行成长

　　4、整理下个阶段的工作思路，促进大家进行整体思考，并对模块进行全面分析。

　　三、具体内容

　　1、给予项目组时间，进行全员总结，包括上个阶段的总结，下个阶段的工作思路，做成PPT

　　2、由每个人在会议上将自己的总结PPT进行分享 （做成ppt并在项目会议上进行分析，会引起大家的重视，自然效果会好）

　　3、进行表彰，表彰做得好的人员，由主管亲自颁发奖品（结合奖励措施）

　　4、用本小组经费进行欢庆，吃饭+KTV之类

　　四、计划支持

　　1、项目计划中安排好总结时间

　　2、制定里程碑奖励措施，并且在上个里程碑点处进行宣传，过程中进行相关数据统计

　　3、向公司提前申请所需的时间和金钱资源

相关链接：

项目实战笔记之一：高效会议的组织方法

项目实战笔记之二：风险管理

项目实战笔记之三：时间估算的三步曲

项目实战笔记之四：团队建设（尊重）

　　这是管理人员面临的挑战，德鲁克也在《卓有成效的管理者》中对管理者和这种监工做了明确区分，其中的观点是监工是上司，但不是管理者。

　　一个抱着积极、认真负责，打拼事业心态的员工做事的有效产出和机械完成任务的人员的有效产出是多么的不对等，这里不需要再列举各类研究结果。尊重是激励文化构建的基石，如果没有尊重，激励就是空中楼阁亦或是短暂的激情。本篇笔记重点谈谈在项目管理过程中对如何给予员工足够的尊重。

　　1、项目的意义

　　成就感是让团队努力向前的最好激励方案，任何项目的成立都是有意义的，如果能够让整个项目团队时刻清晰的认识到自己是再做一件对部门、乃至对公司意义重大的事，则往往能够焕发出团队很强的战斗力。受到关注就会给人被看重感，人就感觉到要对事情付更多的责任。

　　推荐策略：

　　1）项目启动时，高层领导进行动员，宣传项目意义

　　2）项目中期，规划负责人/项目经理要能定期发出一些市场人员/客户对项目的期望

　　3）项目结束后，高层领导要能够反馈项目获得的成绩

　　2、项目时间估算

　　我个人比较推崇的估算方法是自下向上的估算（具体可以上篇文章：时间估算的三步曲），自下向上的估算能够给予项目组员一定的发言权及主人翁感，并且能够调动大家责任心，通常大家愿意为自己的决定负责，但是如果是领导直接压下来的任务尤其比较紧急时，通常有些抵触。当然在自下向上的估算中，要有专家进行指导和把关，包括估算漏掉的哪些事情，项目组内例行需要消耗的时间等，并且针对”狮子大开口“的时间需要进行讨论，达成一致。

　　在这种估算方法做出的项目计划下，如果项目最后出现了问题，尽管项目经理要承担直接责任，但是项目团队成员通常会比较自主的愿意与团队共度难关。因为决策是大家一起制定出来的。

　　推荐策略：尽量使用自下向上+专家指导的方法进行估算，如果有人员到位或者估算周期的有限制，至少要保证关键人员的参与，而慎用自上向下的估算方法.

　　3、善用加班文化

　　IT公司加班是件很自然的事情，如果哪家公司没有加班情况，反而会让人感觉不正常。做为项目经理应该首先理解，加班虽然是IT公司的普遍现象，但是确实是组员为了项目做出了额外的奉献，他们牺牲与家人团聚的时间，牺牲了休息时间，甚至影响了健康。这种行为值得我们尊重，我们要小心使用这项权力。

　　1）不要动不动就抛出一句“这个今天搞不定，就打地铺解决”等，这种言论是对员工额外奉献的一个严重的漠视，而且带着很强的个人意愿

　　2）时时保证项目的进展的透明性，可以通过周会，日报的形式在团队中发布。当遇到赶工时，跟当事人讲解当前团队面临的困难，总之，加班是个艰难的决定，是为了整个团队的绩效，不是项目经理的个人意愿

　　3）任何加班时项目经理都应该尽量身先士卒带队

　4）在一些公共场合，尤其有上级领导在时，公开表扬那些为团队做出很多额外贡献的人

　　5）绩效考核肯定以结果为导向，不能以加班多少论英雄，但要有其他措施安慰最辛苦的人

　　推荐策略：加班是一种奉献精神，我们要小心使用，认真对待。不能简单的当做管理者的权力，轻言肆用，否则久之必招其离心。

　　4、开放沟通的团队氛围

　　人都希望自己能够有发言权，能够对关心的事情产生影响。上至国家领导人的选举，下至日常的工作生活。如果发言权被长期压制，就会产生压抑和叛逆的心理。因此构建一个具有开放沟通的团队氛围则显得很重要。而往往言路开明后，项目经理总是能在一些讨论中，得到很多比预期更好的解决问题的方案。一个强权的管理者，容易获得一定程度上的执行力，但是容易被自己的盲点击败。而一个开明的管理者，往往能使用集体智慧，获得跟随者，更容易产生威望。

　　推荐策略：

　　1）项目沙盘等关键策略制定时，要全体项目参与讨论

　　2）项目经理鼓励大家发现问题，提问问题，对于好的措施，能够采纳执行

　　5、责任到户 VS 大锅饭

　　从头到尾的责任到户制应该是最理想的工作分配方式了，在这种分配方式下，团队成员有一块自己土地，通常愿意花更多的时间与精力去耕耘（例如：某个全新的模块），如果这个模块又是他一直想尝试的方面，那将会更加完美，我们有理由相信他将会在这里充满了激情。

　　然而世界上总没有十全十美的事情及百分百通用的方案，尽管责任到户制如此之好，但是在某些项目上我们达成不了这样的期望。

　　我所亲身经历过的两个版本就遇到了这样的状况。两个版本的共性是：在一个很大的系统上做覆盖面很大的，很多小点的修改（例如：更换所有UI系统），但是基于老系统的复杂性及历史问题，项目在中会遇到很多bug，各种各样，在bug没有查到原因之前并不好确定这个问题谁改动引发或是谁的责任，这种情况下责任到户制会出现失效。在面对系统这么多的bug时，项目经理很容易想到一种方法：“那就是给大家分配bug数，下指标，每天每人要解决3-4bug等”。两次项目经历中，项目经理确实都想到了这种方法，区别是前者实施了，后者被我阻止了。原因如下：

　　1）团队组员容易产生不被尊重感，被当成解决问题的机器

　　2）团队之间的协作会发生困难，而且过度强调这项指标，例如谁每天不修改完这个bug数，就要加班到10：00之类的，会导致部分组员开始取巧，每天争抢容易处理的bug

　　3）没法发挥人的主动性，将团队目标和个人目标相背离

　　这种情况下大锅饭的机制似乎更合适一些，如果团队没有达成目标则需要一起想办法或加班解决，而不是将这人归咎个某个人。

　　推荐策略：在正常项目中尽量使用责任到户制，而对于一些特殊项目，则选用大锅饭制，没有一成不变的方案，具体情况具体变通。

相关链接：

项目实战笔记之一：高效会议的组织方法

项目实战笔记之二：风险管理

项目实战笔记之三：时间估算的三步曲

　　第一个阶段：项目经理简单估算+倒推+部门预备机动人员

　　优点：估算速度非常快（很多时候，项目计划都是从上级给的发布时间倒推出里程碑）

　　缺点：计划非常不准，项目成功率不高。主要原因是：

　　1）项目经理个人思维限制考虑事情不可能百分之百周全，尤其遇到新的项目经理，项目成功的几率更是直线下降。

　　2）部门的人员总是要干活的，当项目发生风险时，原计划的机动人员总是不够用，或是不能停下手头的事投入项目中，如果遇到多个项目同时需要机动人员支援时，整体部门基本要全线加班，集体奋斗了。

　　3）项目组成员参与度不够，如果工作加班，有一定怨言

　　总体来说：还好每当这时候项目经理都能身先士卒加班，这时候部门的同事都是难兄难弟，总是很辛苦，但是项目结果总是不理想，不能按期交付。

　　第二个阶段：公司级形成估算团队做专家估算

　　为了改进估算，同时保证各部门绩效的公平性，公司针对A部门的项目会找其他的部门的专家参与估算，估算使用3点发计算出版本时间点，如果某个专家估算的不 准，则要求重新估算或当面讨论，最终取得一致后将成为项目发布的绩效点.

　　优点：相对公平，有一定信服力

　　缺点：

　　1）容易出现扯皮现象，项目估算时间很长，并且外部估算的时间计划难以转化为内部计划，工作量浪费很大。

　　2）专家质量与主动参与度难以保证，尤其是参加多次估算后，专家容易倦怠

　　3）公司不关注人员分配，不考虑具体项目的最长路径，计算时间公式为：工作量/人力=项目时间

　　4）项目组成员参与度不够，如果工作加班，有一定怨言

　　总体来说：公司级的估算是CMMI引进到公司的，起到了很大作用，但是一定程度上造成了公司级的RDM组织和部门的对立，能力强的项目经理能够做很多线下活动，从而得到自己的绩效时间期望。

　　第三个阶段：部门自下向上估算+专家指导

　　其实第二个阶段和第三个阶段在一定程度上是有重叠的，第二阶段中，有一些先知先觉的项目经理，在公司开始进行估算前，首先进行了内部自下向上的估算，这样自己知道了自己的底限，如果有关键路径消除不掉，则要在总工作量加大，以达成自己的预期。

　　第三阶段主要的特点是项目估算以部门及项目为主导，当出现关键路径后，部门或公司专家帮助消除，如果消除不了，以项目估算为准做绩效点。

　　优点：

　　1）能够保证信服力

　　2）鼓励项目经理一开始把版本事情考虑周全，如果项目计划可行性非常高

　　3）全体项目人员参与的估算，更加准确，并且成员愿意为自己估算的时间负责

　　4）RDM和部门关系形成互助关系

　　5）估算结束后，直接产出可执行的项目计划

　　缺点：

　　1）估算周期稍长，通常需求基线后1-2周能给出

　　总体来说：这种方法是我个人最推崇的方法，能够有效提高员工的参与度及估算的准确度，同时维持组织的互助性，对版本成功非常有帮助。

相关链接：

项目实战笔记之一：高效会议的组织方法

项目实战笔记之二：风险管理

　　交流的前提：调节好自己的情绪

　　项目中间出了问题，换成谁都得恼火，特别是出现一些比较低级的错误，造成了不必要的损失，这时候你怎么办，马上跑过去，找到当事人，劈头就骂，假如你是别人上级，估计问题不大（其实也有很大问题呀，被骂人很有可能口服心不服）。假如别人跟你是平级或组外人员，再加上责任划分不是很明确，别人本来还有点愧疚感，被你这一骂，逆反的心理起了作用，就跟你吵起来了，大家吵得脸红耳赤，不可开交；等大伙把你们俩拉开的时候，你会发现：好像问题还没解决呀？

　　出了问题，应该以解决问题为主要目的。情绪一来，火气一大，骂得别人狗血淋头，反过来是你，你受得了吗？在进行交流之前，一定要适当地调节好自己的情绪；是调节情绪再进行交流，而不是心平气和地去和别人交流，因为脾气不是一天两天养成的，一下子达到这境界有可能吗？

　　说真的，我脾气也不小，特别是刚毕业那一会，几乎是有点属于眼睛容不下沙子，容不了别人犯错。在跟别人吵得脸红耳赤后的两三天，你再回过头看到引发争吵的问题，你会发现那个问题其实也没严重，稍微处理一下就可以解决的事，犯得上吵架吗？（不知道大家有这样的感觉吗？），情绪关键在于调节，以下是我的小方法：

　　（1）先歇而后行；遇了比较恼火的问题，觉得情绪上不是很好，不要马上去处理，先歇息一下，让其有一小段时间的间隔，比如上午出了点问题，下午再去交流处理，中午就是个间隔；这样做看似是误了些时间，实际则不然；估计你马上过去处理，怒气冲冲了，一般也办不好事情。

　　（2） 预演骂人；即然有了时间间隔，再加上现在火在心头，可以先预演一下骂人先了，找个没人的地方，阳台，走廊；把你想骂人的话骂出来，想怎么骂就怎么骂，当然最好是在心里或者低声，不要影响到别人。

　　经过了以上的调节之后，再去跟当事人进行交流，假如这时候还想骂人，那就骂他，经过了调节情绪还是要骂，可见这事比较重要，活该挨骂。不过就我自身，经过了（1）（2）之后，我觉得也没那么严重吧，该怎么处理就怎么处理得了，犯得上骂人吵架吗？就算有责怪也不会是那种骂得狗血淋头的。

　　关于情绪的小心得：

　　情绪对工作很重要，情绪好则工作效率高，情绪差则反之；在工作里遇到有些人情绪控制的能力很差，动不动就发火、骂人；这不仅仅是个人的问题，极容易形成怒火传递，例如：上级领导把小组的组长骂了，组长则骂组员，组员只好把怒火发泄在工作上，工作做不好上级领导又火（是不是成了一个循环了？），整个公司充满了火药味，大家一肚子怨气，这又何必呢？做为小组的组长要勇于承担一定的责任，让怒火在组长这一级别止步是很有必要的。

　　与测试小组的交流

　　测试小组拿到开发打包的程序，按照设计，需求说明及使用说明书对程序进行相关的测试，测出来的BUG分为如下几个级别（因公司而异）：

　　1、设计中存在功能但产品中没有

　　2、极其严重的错误导致无法工作

　　3、一个主要的错误但还可以工作

　　4、一个普通的错误但还可以工作

　　5、一个小问题

　　6、最好能加上的功能

　　这个BUG级别对开发人员来说比较重要

　　1、修复错误的时候尽量先修复级别高的。特别是时间紧的时候。还有很多时候都不是把整个程序开发完了再交给测试人员进行测试的，这时候测试人员把BUG表送过来了，但你手上又有任务，这时候只要先把3以上的错误修复即可，即保证了测试能够继续下去，又不会误自己的开发任务。

　2、BUG级别是考核开发、测试人员绩效的重要依据，也是之间矛盾产生的根源。测试人员希望找出越多的高级别的错误，这正好表明了程序开发的质量不高，而在程序员这边素有把程序看做自己的孩子这一说法，再加上同一个错误划分级别主观因素比较重，测试人员与开发人员常为了BUG的级别发生争吵（在有些很严格的公司，一定数量某级别的BUG整个软件不能发版，听我一个同学说过，在他公司发生过一个开发人员在拿到BUG表后，直接把测试人员叫出来“单挑”），像这些情况主要是缺少有效的交流造成的，以下是我的做法：

　　（1）BUG表应先交给开发组组长，组长先过目

　　一来发现BUG级别划分不当，可与测试组的组长交流，平衡双方的利益，两个同一级别的人讨论下面组员的事，利益冲突不是很大，容易平衡，

　　二来防止两组组员之间闹矛盾，同一张BUG表由组长交给下面组员，与测试人员直接交给相应的开发人员，效果是完全不同的，前者组员一般是无条件接受，后面则不然。

　　三来防止两组组员之间作弊，有时两个人员私交太好，会做些小动作，影响组长对组员能力的判断，

　　四来有利于组长对组员工作的监督，你不知道他的程序出了多少问题，你又怎么知道他修复BUG时在忙些什么呢？

　　（2）平时多注意融洽感情，不要一见面交流都是工作上的事。像融洽小组内部关系一样，利用空余时间两组可以一起出去活动活动，再则可以在适当的时候请测试小组的人员吃吃便饭，中国俗语：吃了别人的嘴软，拿了别人的手短；这样的话在工作中测试人员说话就客气多了，万事好商量，当然这只为了搞好关系，更有利于开展工作，私下里搞太多小动作也是没必要的，务实才是根本。

　　与销售人员的交流

　　假如开发的是产品，在与销售人员的交流主要是对销售人员的培训（这部分的工作可以由开发人员去做，也可以交给测试人员，因公司而异），出现的问题主要有：销售人员在培训时不认真，培训时都说懂了，等去给客户做演示时出了问题就推托是软件的问题，以此推卸责任，到时丢单的责任就说不清了，在培训时，我的做法是：

　　（1）培训之后一定要进行考核，不及格者有相应处理措施。没有考核就没有压力，没考核，销售人员在下面听课是漫不经心，搞小动作，发短信，玩手机游戏； 一问有问题没，懂了没？个个都说懂，到了客户那就出问题；在培训之前先声明要考核，考核不通过有相应处理措施，这招一出下面的人不但听得认真，问题也多，这才能真正起到培训的作用。

　　（2）要求销售给客户演示的流程一定要按照之前的规范走，甚至连录入的数据都要求一样。这是确保销售人员在给客户演示时不会出现错误的，特别是程序开发时拖了时间，测试不够深入，这时候连录入的数据都要求与之前练习的一样，因为这时候你不知道程序大概还有多少错误，什么时候会出错，但你只要知道这样操作一定不会出错就够了。

　　还有个人认为开发人员程序应多与销售人员聊聊天，在闲聊时不仅可以获取到客户的很多想法，还可以从中提高与人交流的技巧，要知道销售人员的主要工作就是与人交流呀！

　　与客户之间的交流

　　客户用程序的时候出了问题，当然很着急，人之常情嘛；问题转到开发，去帮客户解决问题，要尽量耐心点并表示一定的歉意，在具体的交流时针对问题有两种大的处理方法。

　　（1）坦然承认是我方失误，换取客户的理解和信任。

　　（2）反扯是客户方问题，倒打一耙。

　　“客户是上帝”，只要说客户用的软件出了问题就应该是我方的失误，采用第一种方法进行处理，其好处也不用我多说了，书上及各种相关的小故事都有很详细的说明；例如：有客户自己电脑中了毒，软件用不了，像这种情况，我们一般也二话不说帮他清毒并弄好防毒的措施。

　　但客户是上帝，也不能太过份，特别是有些客户是那种得理不饶人，吃硬不吃软的，你跟他说是你的问题，他可就威风了，以此来为难你，让你难堪；遇到这种情况，一律采用方法（2）进行回击，其实软件出了问题，很大部分是客户对软件操作不当，或者环境出了问题，这本来就是有点扯皮的。

　　在实际操作中我基本上都是使用方法（1）（占99%），毕竟大部分客户都是比较好说话的，相互理解的，再有你责怪我、骂我，有个度我也就接受了。但林子大了，什么样的鸟都有呀，遇到特殊的，方法（2）特殊对待。

相关链接：

工作感言：项目收尾阶段管理

　　简单的说，我们要去做一件事情必须有以下要素：目标，动力，行动和达到目标以后的收获。一个很简单的问题，但却在质量管理过程中被抛弃的问题。我们质量管理的目标是保证产品质量；动力是高质量的产品在市场中的竞争优势；动力就是质量管理；而收获当然是利润了。

　　老板的利润=市场的收益-研发的成本

　　研发的成本=人力成本+资源投入成本

　　所以老板的利润=市场收益-（人力成本+资源投入成本）

　　假设，市场收益一定，那么增加利润的手段是有减少人力成本和资源投入。人力成本通过减少雇佣人数，压低个人的薪资待遇，尽量不支付除基本工资以外的任何费用等。表现为加班严重，一个人做两个人的活，平时一切都好商量除了涨工资，员工得不到正常的奖金福利待遇，得不到任何培训机会等等。而资源投入一般不会被消减，因为这是保证赚钱的工具。那么众位打工的，自己为什么幸苦的工作却得到那么少的报酬，就是这样造成的。

　　我们不要怪罪老板，因为他也迫不得已。要想在市场竞争中取得优势，唯一的途径就是成本的优势。

　　我不是社会学家，但我知道根源所在，不知道别人是否认可。众所周知，我们国家的经济主要为手工制造和原始材料加工，这些初级产品没有任何质量优势，而唯一的优势就是价格。这也是中国获得世界工厂“美誉”的前提，他所利用的就是国内廉价的劳动力和生产成本。举了例子：一双美国某一品牌的运动鞋材料成本为三美元，各种税务成本1美元，但在美国生产地人力成本却需要10美元以上，那么这双鞋的成本为14美元。如果生产线在中国大陆呢？材料成本不变3美元，税务成本肯定少于1美元，而在中国的人力成本最多不过2美元，那么这双鞋的成本就是不足6美元。

　　道理就是这么简单。中国的经济就是靠着廉价的劳动力发展起来的。我绝对没有说错。

　　言归正传，在我们软件的质量管理中，所最可能压缩成本的也就是人力成本，这也是为什么公司只招会干实活的人，而不愿意招质量管理人员的原因。在老板看来，多个会干活的人可以多赚钱，而多个质量管理的人，只会给公司增加额外的投入，所以只要目前的管理能够维持下去，那么就没有必要改变它。另外，质量管理是一个漫长的过程，不可能立竿见影，这也是公司缺少动力的原因之一。

　　所谓质量管理人员的尴尬，在很长的一段时间内将继续持续下去，而想走质量管理这条路得人，必须慎重，因为现在还没有它生存的土壤----公司没有做它的动力。

版权声明：本文出自 kuailederen 的51Testing软件测试博客：http://www.51testing.com/?117068

原创作品，为经作者允许请勿转载，否则将追究法律责任。

　　Java代码：

上面的文档给出的解决方案只是能够部分地解决工具问题，但有时候这种hang死会发生在timeouts().pageLoadTimeout()发生作用之前。也就是说，这需要更为彻底的方法去解决这个问题，我想到最简单的方式是用独立的守护线程去看守，具体代码如下：

　　● 瀑布式流程问题之一：

　　版本发布的时间越来越长。在敏捷流程中，版本是由一系列增量集成在一起组成的，这些增量通过一个一个迭代按顺序开发。我们还可以在任意时间停止迭代。一旦发现产品的价值已经达到最大，尤其是发现软件里过半的功能很少被使用的时候，就可以停止迭代。我们还可以在到达交付期限或者预算上限的时候，停止迭代并发布软件。我们只会开发并积累有价值的增量。

　　● 瀑布式流程问题之二：

　　无法按时发布。在敏捷流程中，版本的发布延迟最多不会超过30天，因为每个迭代的最长期限就只有30天。当到达交付期限的时候，就可以交付累积的增量。由于不会在迭代中开发低价值的功能，因此可以比以往更早地发布完整的系统。在传统开发流程中，常用功能占所有功能总数的不到一半。而在敏捷流程中，我们根本不会在不常用的功能上浪费时间。

　　● 瀑布式流程问题之三：

　　在版本发布的最后阶段让软件稳定的时间越来越长。在敏捷流程中，每个迭代所产生的增量都是完整和可用的，后续迭代所产生的增量都会包含之前所有迭代产生的增量，因此任何迭代产生的增量都是完成且可用的。也就是说，没有软件稳定化时期，因为软件一直保持稳定。

　　● 瀑布式流程问题之四：

　　做计划的时间越来越长，而且不准确。在敏捷流程中我们不再做大而全的计划，而只是设定最终目标，然后确定为了达到该目标所需的高价值功能和特性，同时还会确定交付日期以及估算成本。这样在第一个迭代开始前做计划所需的时间通常只有瀑布式或预测型流程的20%。我们只会为即将到来的迭代的需求做详细的计划，因此我们把每个迭代的计划称为“及时雨计划”。另外值得注意的是，需求是涌现的，在评审迭代产生的软件增量的时候，我们可能会发现下一个迭代需要实现的最佳需求。

　　● 瀑布式流程问题之五：

　　在发布期间很难进行改变。版本发布中期的概念在迭代增量式项目中已经不复存在了。我们能够以最小的代价，在每个迭代开始前发现或者提出需求。

　　● 瀑布式流程问题之六：

　　质量持续恶化。在敏捷流程中，每个迭代产生的增量都是完整可用的。因此，增量必然已经通过质量测试。而后续迭代产生的增量同样要满足相同的质量要求，也就是说我们再也不必在项目的最后阶段为了赶上交付期限而牺牲质量，因为质量始终伴随着这个软件的整个开发过程。

　　● 瀑布式流程问题之七：

　　拼命竞赛进度使员工士气受挫。版本稳定化阶段已经不再需要了，因此加班的“死亡之旅”也随之而去。

　　作者并没有详细的论述这个问题。下面，我列出了一些常见的场景和划分。你怎么看待这个问题呢？

　　外部质量

　　● 可扩展性

　　我一直认为，一个没有明确的目标的可扩展性设计往往会变成过度设计。因此，我觉得可扩展性相关的质量问题应该作为外部质量看待。敏捷中强调 做的刚够就好。

　　● 功能不完整的实现

　　有些时候，对某个功能模块的实现中存在 明显的 功能不完整。这一点我认为也是外部质量。因为，我们采用迭代式开发的目的就是可以逐渐的完成这个功能。但是，我认为这种功能不完整应该是 显而易见 的。否则，我认为就属于内部质量中的“逻辑严整性”和“语义清晰性”的问题了。

　　● 性能

　　性能优化往往会牺牲架构的简单性和代码的可维护性。而且，我个人认为从实际的产品角度来看，性能只有“能够接受”和“不能接受”的差别，而没有“好”和“不好”的差别。因此，我认为它是产品是否能够验收的一个重要指标。但不是一个我们应该时刻关注的质量问题。

　　内部质量

　　● 代码规范

　　混乱的代码意味着更加难以维护。划分外部质量和内部质量的一个重要标准是：对产品的可维护性有很大影响的质量问题应该称之为内部质量。因此，我认为代码规范为“内部质量”。

　　● 设计和实现的逻辑严整性

　　例如：你设计了一个集合类，就应该确保集合的基本增删改操作正确。你可以在集合的删除操作中抛出“NotSupportException”或断言错误以标示该集合是一个只增集合。但是，你不能通过忽略删除方法的实现来达到同样的目的。

　　另外一个逻辑严整性问题的例子是：Equals方法和GetHashCode方法实现上。你可以同时不实现这两个方法。如果实现，就一定要实现正确。不能因为目前没有需求将该对象作为Hashtable的Key，而忽略GetHashCode的实现。

　　一个逻辑上不严整的设计往往会对将来使用该模块的开发人员造成误导。 最终造成可维护性问题。因此参考上面的原则，我认为这一条应该归为“内部质量”。

　　● 语义清晰性

　　这一条和“逻辑严整性”类似。不能在方法命名等地方出现语义上的不清晰。对将来的使用者造成误导。

　　关于划分原则的思考

　　● 对产品未来可维护性有影响的点应该归为内部质量

　　正因为“可维护性”往往是一个不易被觉察的问题，我才觉得可维护性是团队最应该关注的质量问题。是不能够放弃的底线。相对而言，“可扩展性”和“可维护性”如此相似，却恰恰相反，它看起来如此美妙。但，过度设计往往都是因为对“可扩展性”的追求而导致的。它反而是我们程序员应该时刻警惕的东西。

　　● 内部质量往往比较虚，而那些清晰明确的问题或目标个人认为归为“外部质量”比较好。

　　人的精力是有限的，正因为这种有限性，让我们需要建立一些简单的原则来帮助我们将精力放在更重要的问题上。尽可能减少我们关注的范围，会让我们在这个范围内做的更好。因此，我觉得应该尽可能的将那些显而易见的问题排除出“内部质量”问题之外。这样，我们才能够更好的控制“内部质量”。那些显而易见的问题，其实，往往都不是问题。

　　● 性能

　　这一点我一直很犹豫，因为往往一个不好的架构会导致难以修复的性能问题。但是，就这个话题而言。我还是更加倾向于将性能看做是外部质量。因为它往往是显而易见的。产品的Master，Customer等等很多人会关注与这个问题上。很多时候，在产品前期准备的时候就已经提出了明确的性能要求。因此，它是一个重要的产品测量点，但是，不是“内部质量”。

　　【关键词】软件开发；软件工程；质量控制

　 　软件质量是指开发出来的软件不仅可以满足客户明确提出来的要求还要满足某些没有明确提出来的要求，软件质量越高，客户需求满足度就越高。软件项目质量控 制不仅仅是控制软件设计的最终结果，它其实要求贯穿于软件设计项目的全过程，从软件开发初期的客户需求调查，到最终的软件交付评审，每个阶段都要进行仔细 的控制，才能提高软件开发的质量。

　　一、软件开发过程的问题分析

　　1、不能明确分析软件的需求

　 　软件的需求是决定软件质量的一个非常关键的因素，如果不能够准确明了的分析软件需求，就达不到软件应有的效果，从而不能真正满足客户的要求。然而软件的 需求不是显而易见的，它需要软件开发人员和客户或者业务人员之间进行充分有效地沟通和交流，使得在软件开发一开始就能够将需求提得既明确又充分，这样才能 为以后的工作打好基础，避免在一开始就偏离了软件开发的方向。在设计开发的过程中也要不断与客户进行沟通和交流，及时按照客户的意见调整软件，才能提高软件开发的质量。

　　2、软件开发工作不规范

　 　由于软件质量许多指标不能量化，因此，软件开发的质量好坏也没有办法直接考核软件开发人员的责任，这样就致使软件开发人员不会很重视软件开发的质量，往 往更关心项目开发的成本和进度。此外，软件开发人员没有制定软件开发计划或者并不能按照软件开发的计划进行工作，为了赶进度经常跨阶段进行开发工作，这样 就没法保证软件开发过程的科学性和系统性，软件开发的质量也不能得到保证。软件开发管理人员和技术人员也会影响软件开发的质量。软件开发工作需要他们之间 进行频繁的沟通和交流，倘若不能及时沟通，对开发过程中出现的不同认识和误解等等问题不能及时消除，就势必会影响到软件产品的质量。此外，软件开发人员在 开发过程中一旦出现流动，就会给软件开发工作带来很大的影响，也不利于提高软件产品的质量。

　　二、提高软件开发质量方法和对策

　　1、软件产品质量控制方法

　　（1）软件工程方法

　 　软件工程的基本方法就是把软件开发过程划分为若干个阶段，在每个阶段开发过程中都设置不同的目标、成本、时间等验收标准，在前一阶段工作通过验收后才能 开始下一阶段的工作，这样就会达到提高软件开发的质量的目标。软件工程将开发过程分为软件生产方法、需求分析、软件设计、软件生产工具、测试、验证与确认、评审和管理等8个阶段，每个阶段都以软件质量控制为核心，规范每个操作流程，从而提高软件开发产品的质量。

　　（2）ISO9000-3标准

　 　ISO9000系列标准原本并不能直接用于管理软件制作，而是为制造硬件产品而制定的标准。后推行的ISO9000-3标准为使软件产品达到质量要求， 要求软件开发机构建立质量保证体系，明确供需双方的职责，针对所有可能影响软件质量的各个因素都要采取有力措施，作出如何加强管理和控制的对策和措施。 ISO9000-3标准叙述了需方和供方应如何进行有组织的质量保证活动，规定了从双方签订开发合同到设计、实现以至维护整个软件生存期中应当实施的质量 保证活动，但并没有规定具体的质量管理和质量检验方法和步骤。

　　（3）CMM认证

　 　CMM是一种专门针对软件产品开发及服务的高效管理方法，强调软件开发过程的不断改进和提高，在软件企业中引入CMM，有助于解决软件开发过程中质量控 制方面出现的问题。CMM不仅对软件企业工程能力进行评估，更着重于软件开发过程的管理，强调“对软件开发过程进行持续的改进”。CMM通过优化企业开发 流程，改善现有的规范、团队配合工作方法，来弥补软件企业对某个项目经理或开发工程师的单纯依赖。软件能力成熟度模型重点是从组织管理方面研究评估软件生 产过程，从而提高软件质量。

问题描述：

　　ericzhangali：

　　用三个角色来描述：开发部门，测试部门，客户。

　　公司和客户合作的方式是根据客户一个模糊的需求做出原型，由客户使用后一次次提出修改意见，一次次修改后由客户决定何时可以量产。

　　目前的流程是：

　　1）开发人员有新版本直接release给客户，以改动大小和多少决定是否送测试部门测试。

　　2）客户收到版本后评测，把修改意见反馈给开发人员。

　　3）测试部门收到测试需求后测试，并把测试结果反馈给开发人员。

　　出现的问题是：

　　1）如果开发人员决定需要送测，往往也是在送测的同时已经release给客户。测试是否失去了部分意义。

　　2）开发人员只关注客户反馈的需求和bug，并不关心测试部门反馈的bug。测试是否失去了部分意义。

　　3）测试人员不了解客户需求，测试工作无法把握重点。

　　4）如果流程管理认为测试部门应该把握release产品的质量，要求每次release前都要送测，是否合理。（背景是经常客户要求很急，上午的电话或mail，下午就要新版本。）

　　希望讨论的问题除了上面的之外还有，

　　1）项目经理/产品经理如何协调这三者的关系？

　　2）与客户打交道的窗口是在开发部门合适还是在质量部门（测试部门）合适？

　　（虽然与测试紧密相关，但揣测一下，觉得还是发在项目管理区。）

　　精彩回复：

　　AlexLJM：

　　1）如果开发人员决定需要送测，往往也是在送测的同时已经release给客户。测试是否失去了部分意义。

　　这种是Alpha和Beta测试同时进行。其实关注点不同，不能就说就没意义。

　　2）开发人员只关注客户反馈的需求和bug，并不关心测试部门反馈的bug。测试是否失去了部分意义。

　　如果开发不关心测试的意见，那按照我们这里的话来说就是瞎忙活。测试最终的目的是为了更好的为产品质量服务。其实我们有时候的角色也有点Client。把1）和2）和起来看。这产品就根本不需要测试跟进。

　　3）测试人员不了解客户需求，测试工作无法把握重点。

　　没有需求的测试是盲目的。盲目的测试有时候不仅提高不了产品质量还会给整个产品带来副作用。不过很多公司都没有书面需求的习惯。这个时候就要测试人员具有需求分析的能力甚至要亲自收集客户的意见。

　　4）如果流程管理认为测试部门应该把握release产品的质量，要求每次release前都要送测，是否合理。（背景是经常客户要求很急，上午的电话或mail，下午就要新版本。）

　　按照我公司的流程。这个版本是不可能出去的，除非研发自己承担后果。（我公司产品release一般需要QA部门的签字）

　　1）项目经理/产品经理如何协调这三者的关系？

　　项目经理更多的是要对产品负责，产品经理则要对客户负责。项目经理负责研发/测试的梳理和协调工作。产品经理负责客户的说服/说明以及协调工作。这里面其实就是项目经理和产品经理之间沟通问题。

　　2）与客户打交道的窗口是在开发部门合适还是在质量部门（测试部门）合适？

　　不知道其他公司怎么处理。我公司基本上研发/测试都有与客户打交道的机会。测试部门甚至以后会成半个客服部门。我觉得无论研发还是测试，都应该多了解市场，多了解客户的想法。具体到打交道，一个项目的研发/测试主要负责人一起出发。呵呵。

鹿鸣：

　　按照标准的开发流程，任何不经过测试的产品，都不能发给客户。

　　没有测试部门的确认，软件产品的质量问题由项目组负责，测试部门不承担任何的责任。

　　如果开发部门不支持测试部门的工作，测试部门有权利不测试产品。

　　“测试人员不了解客户需求，测试工作无法把握重点。”这个问题问的很好，每一个测试人员对此都会迷茫，主要是时间和经验的关系，小软件好把握，但大的系统，如果没有经过系统的培训是很难了解软件过程的。所以真正测试行业软件的时候，都需要有相关行业经验的参加测试小组或做为顾问。测试小组也需要进行一定 的培训。（我测试过很多比较大的家伙，了解那些东西就要花费很长的时间，实际很多的项目，测试3、4次才知道里面的东西具体是怎么运作的）。

　　上面是测试部门的一些事情。下面说说管理方面的。

　　在实际过程中，测试部门一般都比较的弱势，除非公司特别重视产品的质量。很多的时候，留给测试的时间都不够，在软件行业的都知道，项目很少有按时完成的， 基本都会拖期，这个时候影响最大的其实就是测试。如果客户急着要，即使产品没有经过严格的检验一般也都发出去了。

　　项目经理的责任就是严格的掌握开发时间，了解客户的需求，和测试部门进行协调，准备好一切测试部门的相关资料。（现在程序员都在赶进度，基本没有文档，所以在测试前写测试用例是基本不可能的，反正至少在我工作过的公司，无论是程序员的设计还是测试人员的用例等，都是事后补的，这是没有办法的事情）。

　　在很多的时候，测试部门可以说是代表客户利益的，但真正成熟的软件公司，分工都很详细，比如有专门的需求设计人员，负责和客户打交道；还有专门的售后服务技术支持人员；通常测试部门只负责产品的质量，不会和客户发生关系。

　　AlexLJM：

　　在很多的时候，测试部门可以说是代表客户利益的，但真正成熟的软件公司，分工都很详细，比如有专门的需求设计人员，负责和客户打交道；还有专门的售后服务技术支持人员；通常测试部门只负责产品的质量，不会和客户发生关系。

　　我们公司以前就是这样做的。可惜在定位一些问题要不要改善的时候，经常要经过一个流程才能反馈回结果，有时候这个结果根本就不符合我们的需要。后来痛定思痛，决定减少这个流程。

　　鹿鸣：

　　测试部门测试完毕签字确认后，实际就已经和项目没有什么关系了。除非有太大的质量问题出现，表明是测试部门的责任，这个时候会由公司给予测试部门相应的处罚，与客户或项目组无关。

　　至于客户的问题，应该有技术支持人员（通常由开发人员兼职或转职）解决。

　　技术支持人员解决不了的问题，如果原项目组还存在，反馈给项目组；项目组解决不了的，就告诉客户下一版本解决，能拖则拖，拖到客户忘了为止。

　　如果项目组不存在，而问题真的很多，客户还必须使用这个软件。那真是太好了，赶紧重新组织项目组，开发2.0，又能挣一笔钱，哈哈。

　　AlexLJM：

　　技术支持人员解决不了的问题，如果原项目组还存在，反馈给项目组；项目组解决不了的，就告诉客户下一版本解决，能拖则拖，拖到客户忘了为止。

　　如果项目组不存在，而问题真的很多，客户还必须使用这个软件。那真是太好了，赶紧重新组织项目组，开发2.0，又能挣一笔钱，哈哈。

　　ericzhangali：

　　同意楼上两位说的流程。但是感觉目前的情况是把测试工作划分一部分到客户的相关部门。客户认同的方式似乎就是发版本给他，他测试，提交bug list和修改意见，修改后再发给他，他再测试。。。直到他满意，这里面的一次次release我个人觉得不是很正式。在时间压力大的时候或改动很微小的 时候，这种不是很正式的release是不是一定要送测，在VSS上打label，然后得到一份不是很关注的测试报告呢？因为同时版本也已发给了客户，也 许很快，客户也反馈了报告。

　　往往有一个现象就是客户提交的bug list和测试部门提交的差别很大。倒不认为这是alpha和beta同时进行。

　　这种方式确实测试部门不承担责任。由开发部门/人员承担。

　　至于测试人员了解需求的问题，情况是，对每个客户，产品的功能大致是相同的，测试人员也是比较了解的，也有老手写好的full test用例和simple test用例。但每个具体的客户可能外观要求不同，有的功能细节有不一致，甚至不同客户关注的问题点也不同。我是指这个情况测试人员不了解，这个情况只有 直接和客户联系的开发人员了解。但开发人员又没有太多时间跟测试人员详细说。

　　如果把窗口转移到测试部门，不知道客户会不会有意见。他们可能更希望和直接的开发人员联系，提出需求。

ericzhangali：

　　两位可能不太了解我的情况，我口才有限，觉得有些表达不清楚。呵呵。

　　我觉得可以理解成原型法的一个挖掘需求阶段，但又不完全是挖掘需求。

　　大致的过程是：

　　当接到一个新的客户时，我们按照他们要求的功能和UI大致做一个实现，砍到我们认为我们的solution暂时做不到的，或行为和我们的solution差别比较大的就劝说按我们的方式做。得到这个实现后，客户就不断地测试，递交bug list和需要修改的需求，我们就不断地给他新版本。

　　这个过程可能超过一个月，频率可能一两天或两三天就发出一个新版。同时我们自己的测试部门也做测试，发现的问题，优先处理严重的。直到客户觉得基本达到其要求，他才会量产、小批的给他的客户试用。然后反馈试用出的问题和需求，我们再做修改。这个频率一般不高。再然后，他才正式量产。

　　我觉得，小批生产前的是不是属于正式的发布？是否一样地需要严格按流程管理？

　　AlexLJM：

　　我觉得，小批生产前的是不是属于正式的发布？是否一样地需要严格按流程管理？

　　当然不算正式发布，顶多算个验收测试。看你说的情况，严格按照流程管理只会增加管理成本，导致项目延期。

　　鹿鸣：

　　现在规模软件开发，重视的是开发流程，努力找到一种适普和容易控制的开发方法。但理论和实践是有差别的，所以才有一个不断调整的过程。这样，根据不同的实际情况，可以对软件开发流程有自己的理解和方法。

　　现在流行的剪裁rup就是为了适应各种不同的情况而实施的。所以很难说哪个好或不好。但通常情况下，流行的方法都是经过理论和大量实践，所以一般都适合于各种情况。

　　至于你们公司，是否有修改的可能和必要？如果没有，那么当前这种开发情况就是最合适的。否则可以找咨询公司，为你们公司的实际情况设计一套开发方案，这涉及大量的细节，这里简略的讨论实在不是很合适。

　　ericzhangali：

　　呵呵。质量流程部门坚持要每次release前都送测，他们好象不在乎送测的意义有多少。看你说的情况，严格按照流程管理只会增加管理成本，导致项目延期，说服不了测试部门。

　　我觉得对release的定义模糊。

　　客户工程师一个电话打来说改一个bug，马上发个新版，是不是一次release。

　　如果只要有送出就要经过测试的话，我觉得还是由测试部门和客户打交道吧，接收需求，研发修改，提交测试，再送出。至于时间，由测试部门去和客户协调。

　　wbsndts：

　　按照这样的现实情况，谈需求的窗口不应该是研发部门了。

　　ericzhangali：

　　唉，规则都是人制定的，也都是人执行的，混吧。

　　由于测试的人远离客户，他们不清楚客户的需求的关注的权重，往往他们报来的bug和客户提出的bug相差很远。我们只能优先考虑客户的bug，而渐渐疏远公司流程中测试活动的产物。

　　这日子只能先这样过了。。。

　　关键字：软件测试；嵌入式测试；软件质量

　　1、引言

　　嵌入式软件的开发和测试也就与普通软件的开发和测试策略有了很大的不同，嵌入式软件系统是一种针对特殊任务、特殊环境而进行特殊设计的定制产品，有其专门的开发环境、软硬件紧密结合、严格的实时要求等特点。使得嵌入式软件测试与普通软件测试虽有相似之处，但有也有其自身独特的特点。

　　2、软件测试和嵌入式软件测试

　　2.1 软件测试的定义及目的

　　软件测试，即Software Testing。软件测试的定义有很多，在1979年出版的一本经典著作《软件测试艺术》（The art of software testing）中，GLEMFORD

　　J.MYERS曾经对软件测试下过如下定义：软件测试就是为了发现错误而执行程序或系统的过程。虽然它不太完善，但放在当时的情况下是可以说的通的。

　　随着计算机和软件技术的发展，软件应用的复杂性和规模的不断扩大，软件测试技术的研究也取得了很大的突破。早期的定义已经不适用了，许多专家对软件测试提出了各种各样的定义。综合起来，我们可以定义“软件测试是由一个程序的行为在有限测试用例集合上，针对期望的行为的动态验证组成，测试用例是从通常的无限执行域中适当选取的”。

　　长期以来对软件测试存在着两种不同的认识。一种观点认为，软件软件测试的目的是证明 软件的正确性；而另一种观点则认为，软件测试的目的是尽可能寻找软件中隐藏的错误和缺陷。

　　2.2 软件测试的特点

　　1）大多数硬件实验失败的方式和方法是固定的，而软件测试失败则是毫无规律的，探索所有软件测试失败的模式是不可能的。

　　2）软件方面的许多缺陷都源于设计和实现上的错误，而不是源于生产制造方面的缺陷。

　　3）软件质量保证的关键在于我们如何让避免产生错误和消除已经产生的错误，是程序中的错误密度达到尽可能低的程度。

　　4）软件测试是一个动态的执行过程，体现在输入、行为和行为的输出结果上。

　　5）软件测试是一个有限的集合。

　　2.3 嵌入式软件测试的定义及目的

　　嵌入式软件是一种比较特出的软件，软件经过分析，设计，编码后只有烧入硬件环境中才可以看见，比如数字电视的中间件软件，洗衣机的自动控制软件，手机游戏软件等等。嵌入式软件测试/嵌入式测试或叫交叉测试（cross-test）的目的与普通软件测试是相同的，都是为了发现软件缺陷，而后修正缺陷以提高软件的可靠性。嵌入式系统安全性的失效可能会导致灾难性的后果，即使非安全性失效，由于其应用场合特殊也会导致重大经济损失。因此，往往嵌入式软件对可靠性的要求比普通软件高。这就要求对嵌入式软件进行严格的测试、确认和验证，以提高产品的可靠性。

　　2.4 嵌入式软件测试的特点

　　嵌入式软件测试与普通软件测试相比，有其自身的特点：

　　嵌入式软件测试是在特定的硬件环境下才能运行的软件。

　　嵌入式软件测试除了要保证嵌入式软件在特定环境下运行的高可靠性，还要保证嵌入式软件系统的实时性。

　　嵌入式软件产品为了满足高可靠性的要求，不允许内存在运行时有泄漏等情况发生，因此嵌入式软件测试除了对软件进行性能测试、GUI测试、覆盖分析测试是同普通软件测试一样都不可或缺之外，还要对内存进行测试。

　　嵌入式产品不同于一般软件产品，在嵌入式软件和硬件集成测试完成之后，并不代表测试全部完成，在第一件嵌入式产品生产出来之后，还需对其进行产品测试。

　　嵌入式软件测试的最终目的是使嵌入式产品在能够满足所有功能的同时安全可靠的进行。

3、嵌入式软件测试与普通软件测试的异同点

　　3.1 嵌入式软件测试与普通软件测试的相同点

　　嵌入式软件测试作为一种特殊的软件测试，它的目的和原则与普通软件测试是相同的，都是为了发现软件缺陷，而后修正缺陷以提高软件的可靠性。它们的中心任务都是验证和确认其实际实现是否符合需求要求，在验证过程中发现系统缺陷。

　　嵌入式软件测试与普通软件测试具有相同的信息流，如图3-1。

图3-1 软件测试信息流

　　嵌入式软件测和普通软件测试对象相同，包括软件中所有内容，贯穿软件定义与开发的整个过程。也就是说，需求分析、概要设计、详细设计、程序编码等各阶段所得到的文档及源程序，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应当称为软件测试的对象。

　　3.2 嵌入式软件测试与普通软件测试的区别

　　由于嵌入式系统的自身特点，如实时性(Real-timing)，内存不丰富，I/O通道少，开发工具昂贵，并且与硬件紧密相关CPU种类繁多，等等。嵌入式软件的开发和测试也就与一般商用软件的开发和测试策略有了很大的不同，可以说嵌入式软件是最难测试的一种软件。

　　嵌入式系统由于自己本身的特点，如实时性强、内存不丰富、I/O通道少、开发工具昂贵并且与硬件紧密相关、CPU种类繁多等等，决定了不同的嵌入式系统必须有不同的测试方法。

　　3.2.1 嵌入式软件测试的各个阶段测试的环境是不一样的

　　嵌入式软件开发和运行的环境是分开的，嵌入式软件开发环境往往是交叉开发环境。因此，各个阶段测试的环境是不一样的。

　　单元测试阶段：所有的单元测试都可以在宿主机环境下进行，只有个别情况下会特别指定单元测试要直接在目标机环境下进行。应该最大化在宿主机环境下进行软件测试的比例，通过尽可能小的目标单元访问其指定的目标单元界面，提高单元的有效性和针对性。

　　在宿主机平台上运行测试的速度比在目标机平台上快得多，当在宿主机平台上完成测试后可以在目标机环境下重复做一次简单的确认测试，确认测试结果在宿主机和目标机上没有不同。在目标机环境下进行确认测试将确定一些未知的、未预料到的、未说明的宿主机与目标机的不同之处，例如，目标机编译器可能有缺陷，但在宿主机编译器上没有。

　　集成测试阶段：软件集成也可在宿主机环境下完成，在宿主句平台上模拟目标环境运行，在此级别上的确认测试可以确定一些与环境有关的问题，比如内存定位和分配方面的一些错误。

　　在宿主机环境上的集成测试的使用，依赖于目标系统的具体功能有多少。有些嵌入式系统与目标机环境耦合的非常紧密，这种情况下就不适合在宿主机环境下进行集成。对于一个大型的软件开发而言，集成可以分几个级别。低级别的软件集成在宿主机平台上完成有很大优势，级别越高，集成越依赖于目标环境。

系统测试和确认测试：所有的系统测试和确认测试必须在目标机环境下执行。当然在宿主机上开发和执行系统测试，然后移植到目标机环境重复执行是很方便的。对目标系统的依赖性会妨碍将宿主机上的系统测试移植到目标系统上，况且只有少数开发者会卷入系统测试，所以有时放弃在宿主机上执行系统测试可能更方便。

　　确认测试最终必须在目标机环境中进行，因为系统的确认必须在真实系统下完成，而不能在宿主机环境下模拟，这关系到嵌入式软件的最终使用。

　　3.2.2 嵌入式软件测试的复杂多样

　　因为嵌入式系统的一个突出的特点，是其专用性，即一个嵌入式系统只进行特定的一项或几项工作，嵌入式软件运行的平台都是为进行这些工作而开发出来的专用硬件电路，他们的体系结构、硬件电路，甚至所用的元器件都是不一样的，所以嵌入式软件运行的平台也是复杂多样的。

　　由于开发平台的复杂多样性，使的嵌入式软件的测试从测试环境的建立到测试用例的编写也是复杂多样的。与不同的开发平台对应的嵌入式软件是肯定不相同的。嵌入式软件测试在一定程度的上并不只是对嵌入式软件的测试，很多情况下是对嵌入式软件在开发平台中同硬件的兼容性测试。因此，对于任何一套嵌入式软件系统，都需要有其自己的测试、创建其自己的测试环境、编写其自己的测试用例。

　　3.2.3 嵌入式软件测试中对实时性有严格要求

　　由于嵌入式系统的实时性，决定了嵌入式系统的运行时间也是受严格限制的。嵌入式软件在测试时应当充分考虑系统实时响应的问题，很多嵌入式系统会要求系统的响应时间应在多少毫秒之内。在测试有严格响应时间要求的嵌入式系统时要做负载测试。

　　3.2.4 嵌入式软件测试需要进行插桩测试

　　嵌入式软件最终的测试需要在目标机平台上进行，在对目标机进行测试时，我们需要对在宿主机上编译通过的代码进行插桩处理。插桩完成之后，需要重新对代码进行编译，如果编译通过，就可以将编译好的代码下载到目标机上执行。在目标机执行程序的时候，需要将插桩时预测好的数据返回到宿主机上，因此，宿主机和目标机上要有能够相互传递数据的网线或者串口线，宿主机上同时要有能够处理返回的数据的处理程序或软件

　　3.2.5 嵌入式软件对系统的可靠性和安全性要求比一般的软件系统高

　　因为嵌入式软件对系统的可靠性和安全性要求比一般的软件系统高，所以还需要进行系统的可靠性测试。对于不同的嵌入式系统，需要制定相应的符合系统需求的可靠级别，在进行可靠性测试时应该将系统的可靠性级别考虑进去。

　　一些嵌入式系统，比如工厂车间的某些控制系统，他们要在电磁很强的恶劣的环境下可靠的工作，而且要保证操作人员的安全。但是对于手机软件来说，他的可靠性和安全性就不如工厂车间的车床控制系统要求的高。

　　然后，做好质量保证与检验。其一是切实搞好开发阶段的管理，检查各开发阶段的质量保证活动开展得如何；其二是预先防止软件差错给用户造成损失。为了确保每个开发过程的质量，防止把软件差错传递到下一个过程，必须进行质量检验。质量检验的原则，一、用户要求的是产品所具有的功能，这是“真质量”。靠质量检验，一般检查的是“真质量”的质量特性。二、能靠质量检验的质量特性，即使全数检验，也只是代表产品的部分质量特性。三、必须在各开发阶段对影响产品质量的因素进行切实的管理，认真检查实施落实情况。

　　当开发阶段出现异常时，要从质量特性方面进行检验，看是否会给后续阶段带来影响。虽然各开发阶段进展稳定，但由于工程能力不足，软件产品不能满足用户要求的质量。这时可通过检验对该产品做出评价，判断是否能向用户提供该产品。要以一定的标准检验产品，根据产品的质量特性，检查各个过程的管理状态。

　　另外，就是建立软件质量保证体系。软件的质量保证活动，是涉及各个部门的部门间的活动。例如，如果在用户处发现了软件故障，产品服务部门就应听取用户的意见，再由检查部门调查该产品的检验结果，进而还要调查软件实现过程的状况，并根据情况检查设计是否有误，不当之处加以改进，防止再次发生问题。为了顺利开展以上活动，事先明确部门间的质量保证业务，确立部门间的联合与协作的机构十分重要，这个机构就是质量保证体系。必须明确反馈途径。必须明确各部门的职责。必须确定保证系统运行的方法、工具、有关文档资料，以及系统管理的规程和标准。必须明确决定是否可向下一阶段进展的评价项目和评价准则。必须不断地总结系统管理的经验教训，能够修改系统。

　　质量保证活动的实施步骤

　　Target：以用户要求和开发方针为依据，对质量需求准则、质量设计准则的各质量特性设定质量目标。

　　Plan：设定适合于被开发软件的评测检查项目(质量评价准则)。研讨实现质量目标的方法或手段。

　　Do：制作高质量的规格说明和程序。在接受质量检查前先做自我检查。

　　Check：以Plan阶段设定的质量评价准则进行评价。计算结果用质量图的形式表示出来。比较评价结果的质量得分和质量目标，看其是否合格。

　　Action：对评价发现的问题进行改进活动，如果实现并达到了质量目标就转入下一个工程阶段。这样重复“Plan”到“Action”的过程，直到整个开发项目完成。

版权声明：本文出自 cmriqa 的51Testing软件测试博客：http://www.51testing.com/?489136

　　关于开发人员自测

　　开发人员做好自测，是非常必要和也是大趋势。Google公司里面，纯粹的测试人员是很少的，前期都是开发自测（包含必要的测试），后期才是用户体验方面的测试；从成本上分析，BUG越晚发现修复成本越高；从修改的效率来讲，越早处理会越快。另外，写出高质量的代码，是能力的体现，专业的体现，自身价值的体现。

　　开发人员自测的困难

　　就我自己接触到开发人员来看，一般会遇到下面这些困难：时间、进度太紧（也许是由于潜意识里任务完成后满足感驱使的）；对自己的代码过于自信；认为测试是测试人员的责任；不知道如何有效的自测。

　　思维上

　　从上面的困难看来，思维上应该先需要转变下。

　　● 代码质量、项目质量都是自己的责任，提交代码到代码库里，提交版本给测试给客户，都应是经过自己测试的。否则拿出去东西影响其他人的工作，影响客户眼中的印象和满意度，这样带来的危害更大。

　　● 代码达没有达到效果，健不健壮，不试试，那怎么知道？凭感觉那是不靠谱，实践是检验真理的唯一标准。

　　为什么开发人员不忍尝试破坏自己的成果了？为什么不能让自己的成果更加健壮？否则就相当于在溺爱自己的孩子。

　　测试世界的基本思想

　　● 测试与开发人员思考角度最大不同就是一个破坏软件，一个建造软件。所以想要测试，就应该是考虑怎样才使软件出了点问题？

　　● 对于任何功能都有基本流和备选流，或者说正面情况和反面情况。这些情况都应该是要需要去测试的。那如何选择测试的数据和路径？

　　● 有一个重要的概念叫做“等价类划分”，大致可以这样理解，由于测试数据和测试路径理论上讲是无穷尽的，那么就需要对这些数据和路径进行分类，哪些能走到正常情况，哪些能走到异常情况。再从各个分类里面选一些出来完成测试即可，这样覆盖率就会更高，同时测试起来更快。

　　● 数据选择，选一组正常数据（符合规定，用户可能真正会用到的）；选几组异常数据（特殊符号，不支持，长度大，空的，会触发特殊逻辑的）。

　　● 路径/场景选择，选一两组最普通的、最直接的、用户最有可能的完成功能的；选几组复杂一点、多次操作、间接完成功能的。

　　习惯上

　　改变习惯是非常困难的，坚持完成一个功能就测一个功能（真正带点测试思路去测）；公司推行的规范，Checklist，Code Analysis或者自己总结出来的自测列表等等，也要坚持定期自己检查检查，再认真对待、改进结果。

　　多总结、反思自己的所犯的问题，这样才能有所提高。测试会帮助你的思维变得更加全面和周到。

　关于用户体验

　　界面设计、动作交互设计、用户体验，这块的重要性应该不需要进一步阐述了吧。

　　这里也是从思路上简单讲讲怎么考虑用户体验：

　　● 首先是学习。一般来讲，我们做的东西都不是全球第一，全球首款。那么我们在做东西前，可以学习下模仿下前人已经做出来的效果（切忌只关心功能）。

　　比如，界面布局；页面 margin，页面中主体的对齐、留白；字体大小、粗细的使用；

　　其实看到的一切都是可以关注的。

　　● 平时还可以对自己使用软件和网站进行观察和体会，看看他们做得好的是在具体怎么做。

　　比如，操作成功、失败的提示怎么表现；注册流程、购物车流程、是怎么进行的；日历控件、向导控件是怎么在用；图片库、视频库怎么放置的，怎么播放的。

　　● 当我们真正要做的时候，还可以看看那些规范、指南。看看其他人都建议怎么做，建议避免那些效果。

　　● 最后，我们做的时间，在界面设计上尽量风格统一（按钮大小、颜色，边距，Grid，表单设计等），动作交互设计上尽量和主流的效果一致（如何给出提示信息，如何弹出层，如何做表单的验证）。

　　关于持续学习和追求精益求精

　　也是就我自己接触到开发人员来看，很少人会在做之前或者做的过程中，跳出来暂别任务，看看工作任务的技术有没有什么最佳实践有没有其他方案，或者和能力更强的开发人员进行讨论和交流。很多人都喜欢过分独立的解决问题，但问题就来了，一个方面是时间的消耗，另一个方面是容易闭门造车。

　　另一现象是很多人对其他的人建议反馈或者提出的问题，比较随便，怀着防备的心情，戴着有色眼镜，没有认真考虑和对待，没有考虑是不是自己真的没有做好，真的有问题。

　　当然这些不是完成任务的必需品，但是我以为这些方面却是一个人成长或者成就的基础。

　　想要提高，这是你自己的责任，就该想想怎么去解决。态度决定一切，追求卓越。

版权声明：本文出自 omg 的51Testing软件测试博客：http://www.51testing.com/?166582

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。

　　这是一篇英文的文献，昨天把他翻译出来了。觉得还是比较有用，所以决定在这里把它贴出来。原文在：

　　http://www.stickyminds.com/sitewide.asp?ObjectId=10094&Function=DETAILBROWSE&ObjectType=ART&sqry=%2AZ%28SM%29%2AJ%28MIXED%29%2AR%28relevance%29%2AK%28simplesite%29%2AF%28Test%2Dbased+Project+Progress+Reporting%29%2A&sidx=0&sopp=10&sitewide.asp?sid=1&sqry=%2AZ%28SM%29%2AJ%28MIXED%29%2AR%28relevance%29%2AK%28simplesite%29%2AF%28Test%2Dbased+Project+Progress+Reporting%29%2A&sidx=0&sopp=10

　　二、摘要

　　面向交付的项目管理和测试驱动开发能够结合在一起，能够为客户、开发成员和管理者提供客观的更容易理解的方法来测量项目的进度。在这篇文章里，john ferguson smart提供了一个学习用例来说明如何通过这种途径进行工作。

　　三、名词解析（自己添加的）

　　3.1 面向交付的项目管理是一种项目管理方法，测试驱动开发是一种开发方法。

　　3.2 面向交付的项目管理：就是本文说的，把任务分下去，总体任务代表一个总的交付，然后各个子任务代表子交付。项目根据各个交付任务来进行管理。

　　3.3  迭代的开发方法：就是先完成部分主要的功能，形成一个版本。然后再逐渐添加新的功能，形成新的版本。

　　3.4  测试用例（test case）：可以理解为就是测试用的程序和方法。每个测试用例对程序的某个功能进行测试，看是否实现了这个功能，有没有bug。完备的测试用例就是对程序的各个功能和稳定性进行全面的测试。设计好的测试用例，才能全面而且尽可能快的完成程序的测试。

　　3.5 测试驱动开发：表示总的程序需要什么功能，各个子模块需要什么功能。指定好测试用例，程序完成了测试用例的功能，就表示开发完成了。将测试用例用于开发过程中，而不是说先把程序写好了，最后再测试。

　　3.6 可交付性（deliverable）：可以理解为可以交付的工作产品，就是具备独立功能的一段代码。

　　3.7 beta版本：beta版本就是软件开发的一个阶段，一般这个阶段，程序已经可以完成大部分的功能，也比较稳定了。一般beta版本开发出来以后，就会提供给用户或者内部人员免费使用，然后根据使用发现的bug，进行修正。

　　四、可交付性的定义

　　所有的工程项目，原则上都具有可交付性。如果采用迭代的开发途径，为了制定一个迭代的、基于里程碑节点的交付方案，需要将主交付性可以分成多个小的子交付性。（比如一个应用程序可以分成多个模块、函数或者用户开发实现）。

　　五、WBS和项目计划

　　工作分解结构（WBS）是一个大家熟悉的而且非常有用的工具，用来将一个项目分解成容易管理的（也有人说可以消化的，或者可以咀嚼的）多个任务。在一定程度上，你分配WBS任务给单独的开发组成员，（某些时候，是一小群开发成员），然后要求他们产生一个具体的可交付产品。

　　工作分解结构（WBS）往往是跟项目计划紧密相连。这里，对于工作分解结构（WBS），工作需要细化到每个任务对应一个可交付性的条款，然后分配到具体的小组成员。将具体的交付工作分给具体的小组成员，可以让开发者将开发活动上聚焦在具体的、短期的目标上，同时也可以培养开发者的buy-in能力和责任感。

　　六、测试用例

　　自然，我们也为每个交付要写一组测试用例。这些测试用例代表了每个模块可以被接受的标准。可以有很多方法来做测试计划和测试用例。大部分会包含某种形式的，一系列的执行动作和步骤，伴随着特定的结果。在我们的用例中，对于每一个可交付的模块，我们将对应的测试用例填到Excel电子表格中，并加注额外的信息以便容易使用。下面就是Excel表格的表项。

　　● 一个独一无二的测试用例号

　　● 显示ID

　　● 显示区域

　　● 执行的动作

　　● 期望的结果

　　● 得到的结果

　　　　→ 结果：通过，失败，还没有测试

　　　　→ 描述任何非期望的行为

　　　　→ 相关的缺陷追踪问题

　　根据我们的经验，一组好的测试用例能够很完美的指示产品是否准备好交付。理想的情况，是测试用例和产品的功能定义一同交给开发者，尽管在实际中，测试用例一般要晚一点点。分析文档和测试用例为每一个模块提供了具体的有形的目标，使得开发者能够关注于代码的编写。

七、用测试来衡量进度

　　7.1 衡量测试结果

　　基于测试的进度报告能够用一种容易理解的、客观的观点来审视项目进度。在我们的项目中，对每个模块需要报告下面的测试状态：

　　● 全部的测试用例

　　● 通过的测试

　　● 失败的测试

　　● 还未进行的测试

　　我们从下面三个主要方面来进行度量：

　　● 一个模块当所有的测试用例都由QA执行过，并测试成功，这个模块就算完成了。QA包括内部测试组和用户测试人员。

　　● 测试一个模块需要的测试用例的数目反映了模块的复杂度。虽然不总是这样，但常常如此。

　　● 开发是迭代的：新版本被频繁的交付，测试也需要不停的进行，而不是仅仅在项目的最后才进行测试。

　　在这些条件下，各个模块的全部进度都可以通过各个模块的测试用例通过的数目来衡量。如果你能可靠的在特定的时间点（里程碑节点），获得各个模块通过的测试用例数、失败的测试用例数和未测试的用例数，就可以把它制成如图一所示的表格。

图一：测试状态表

　　7.2 模块进度状态

　　我从不相信一个开发者说他的一个模块快要完成了。在我的书中，只有所有的测试用例都通过了，一个模块才算完成了。然而，有些被普遍接受的原则认为，如果一个程序，85%的测试用例通过了，就可以进行beta版测试了。尽管你理论上认为必须100%的测试用例通过，才能说产品准备好了，但是我们的用户通常会接受产品，尽管产品还存在一些不严重的问题，并且这些问题在将来能够被修补。因此，我们把模块的“预产品”状态定义为至少95%的测试用例通过并且没有严重的问题。最后，我把模块开发过程的阶段划分原则制定出来。

　　我们划分成五个状态来表示五个开发阶段，通过测试成功的测试用例的数目来客观的衡量。

　　● 计划阶段：还没有开始编码

　　● 开发阶段：开始编码

　　● beta版本阶段：85%测试用例通过。

　　● 预产品阶段：95%的测试用例通过，没有发现严重的问题

　　● 产品准备好阶段：100%的测试用例通过

　　一旦你有了测试用例通过的百分数，你就对模块的开发进度和稳定性有了一个很好的评价。我们将这些数据用图形来表示，写在每周的进度报告中。

　　可以将进度表示成紫色的条图，用来指示模块的工作进展。这能够鼓励开发者自发主动的清楚工作的进度。如图2所示。

图2 进度颜色条码图

　八、基于测试的进度总览

　　我们从更高的层次上，通过测试用过的数据来看项目的进度。如图四所示。这图对外行人很容易看懂，在项目的进展报告中，放在在执行总结情况这部分特别有用。

图3 基于测试的项目进展总览图

　　九、缺陷数据

　　我们使用的迭代的开发周期，提供了方便的追踪缺陷数据的基础。（译者注：因为迭代是周期性的提交版本，可以周期性的对每个版本测试，发现版本的缺陷）。我们一般一到两周会提交一个面向用户交付的版本，每周或者几天就会提交一个内部版本。新版本的整洁性比增加的模块数目或者修正的bug数目更重要。然而，QA人员在接受一个新版本之前，必须对上一个版本进行一个合理长的时间测试。交付的日期就必须一起商量决定。在期望的交付日期前，我们要考虑交付是否可行（能否修正严重的问题），要考虑哪些新模块以及哪些bug能够对用户声明。

　　为了实现这个，我们把缺陷数据放在缺陷数据库，从数据库中提取出缺陷数据来衡量产品的质量可可靠性。全局缺陷状态图表示了各个缺陷状态（open, to-be-deployed,pending validation等）的缺陷数目。

　　我们对每次交付，都要衡量缺陷的状态——记录公开的问题数目和总的问题数。这对于交付规划是非常重要的。

　　十、历史数据

　　对于跟踪随时间变化的测试的结果也是很重要。它能告诉你软件的可交付性和稳定性的速度（多长时间可以产生一个交付版本，多长时间可以达到某种稳定程度）。如图6和图7所示。

图6 历史数据：随时间的测试完整性

图7 历史数据：随时间的测试完整性

　　十一、这个方法不能做的

　　（译者注：这个方法指基于测试的项目进度管理）

　　这种方法不完备，也不是要取代传统的项目进度跟踪和汇报。这种方法的特别之处在于它是纯粹面向交付的。因此它能够幸运的忽略哪些诸如延时、开销、资源消耗、关键途径等等术语。这些术语能够而且应该被诸如Gantt图，PERT图等代替。实际上，这种方法能够给上层管理人员、小组成员和项目投资人等一个项目进度的直观表示方法。基于测试的交付状态是一个重要的而且容易理解的项目汇报方式。但是延迟、花费和面向任务的观点同样重要。

　　十二、对这种方法的评价（自己添加的评论）

　　测试用例的设计非常重要，要完备，系统。要有机制对测试用例的优先级进行设定，哪些优先级高，先实现；哪些没那么重要，后实现。 对各个测试用例要归属各个版本，哪个版本应该实现哪些测试用例。要设计好。