实施软件测试自动化的理由分析

　　首先，测试人员的工作比以往任何时候都更加困难，因为公司和组织希望以更快的速度和更低的成本开发出高质量的应用程序。
　　此外，在很多项目中，测试人员的所有任务实际上都是手动处理的，而实际上，有很大一部分重复性强的测试工作，是可以独立开来自动实现的。
　　还有，在大型项目中测试团队和其他的团队之间没有足够的合作，无法促进彼此的工作。
　　最后，从个人角度来说，测试人员通常很难花费大量时间来学习新技能；这是目前国内测试从业者的现状，太多的企业为了节约成本而将刚刚走出校门的毕业生作为测试工程师，他们每日做着繁忙的重复工作，又基于自身技能的不深，虽怀博览群书的心愿却不知从何出入手。所谓光阴似箭，因为一转眼我们就说到未来的5年、10年后，我们这些技能不深的测试工程师能做什么呢？而软件测试自动化，也是未来测试工程师或即将成为测试工程一项强有力的工作技能。
　　可以说，实施测试自动化是软件行业一个不可逆转的趋势，如果在这个领域走在了前列，无论从企业的核心竞争力还是个人的工作技能来说，都有巨大的优越性，而国内众多的软件厂商也的确在纷至沓来的着手开展着这项工作。

　　国内软件测试自动化实施现状分析

　　随着众多具有了一定优秀实施自动化测试经验的企业陆续出现，也伴随着很多组织对这项工作依然是丈二的和尚－摸不着头脑。对当前国内软件企业实施或有意向实施测试自动化时面临的主要问题，按实施的不同层次来说：
　　——干脆认为测试自动化是个遥不可及的事情，我们这样的小公司不必实施，人员、资金、资源都不足，以后再说吧！
　　——热血沸腾的实施测试自动化，购买了工具，推行了新的测试流程；几个月后，工具放在那里成了共享资源，测试流程又涛声依旧，回到原来的模式。
　　——公司实施了自动化测试；然而开发与测试之间，甚至与项目经理之间矛盾重重，出了事情不知如何追究责任；虽然还在勉强维持的自动化测试，但实施的成本比手工测试增加了，工作量比从前更大了，从而造成项目团队人员怨声载道，更怀念起那段手工测试的悠闲岁月，唉！那一场风花雪月的事，既然要结束又何必开始…
　　——自动化测试实施相对比较成功，但或多或少还有些问题，比如工具选择不准确，培训不到位，文档不完备，人员分配不合理，脚本可维护度不高等等，造成一种表面上的自动化测试流程，是一幅空架子，如同山间竹笋,嘴尖皮厚腹中空。

　　国内软件测试自动化实施不成功原因分析

　　——公司高层意识不到软件测试自动化的重要性；殊不知，其他竞争对手们都大张旗鼓的开展这方面研究和策划的时候，自己还对此持漠视态度，等到整个行业都提高到一个新的层次，那时再着手做，可能就是热锅上的蚂蚁了。
　　——所谓凡事预则立，不预则废。一个软件企业实施测试自动化，绝对不是拍脑袋说干就能干好的，它不仅涉及测试工作本身流程上、组织结构上的调整与改进，甚至也包括需求、设计、开发、维护及配置管理等其他方面的配合。
　　——软件开发是团队工作，在这一领域要尤其注重以人为本；所以人员之间的配合、测试组织结构的设置非常重要，每个角色一定要将自己的责任完全担负起来，这也是减少和解决前述团队矛盾的必要手段。
　　——对开展自动化测试的监督和评估相当重要，也包括对工作产品的检查和人员的考核。一定要将自动化测试全面深入的贯彻到测试工作中，不能敷衍了事，不能做表面工作。这项工作在CMM三级里规范的很好，只可惜我们的很多公司对CMM真的只是“过级”！

　　正确认识国内未实施软件测试自动化的根源

　　目前国内的软件公司，很多还是处于获取资本的原始积累阶段，我们不能说公司领导完全不重视测试，而是测试整体行业都没有被重视起来，这是其一；其二是公司高层有更需要重视的环节，例如寻找客户签订单，或者开发，这些是直接关系公司存亡的命脉性东西。
　　即便企业重视测试，如果公司做一番比较全面的评估（在后续的测试自动化引入入条件里，再详细说明），也不一定非要实施自动化测试。笔者认为一些中小软件公司在大刀阔斧推行自动化测试之前，在测试流程管理、测试缺陷流程、测试人员技能培训等方面做工作，这样可以用比较少的成本投入来获取相对较大且长期的收益回报。
　　最后，针对普通测试工程师的一些建议，在这样的公司里，其实有着很多意想不到的优越性：
　　（一）这样的公司测试如果不正规，那么你就有更大更多的发挥空间。
　　（二）你可以单独学习自动化测试技术，自己先试着应用到日常工作的软件项目中。
　　（三）你可以直接和开发人员沟通，甚至向他们学习开发技术，这对将来的自动化测试中开发脚本很有好处。
　　（四）每个优秀测试工程师的成长都是个循序渐进的过程。我遇到很多测试界的新手向我发牢骚，很惭愧我没有什么可以告诫他们的，只是希望这样的新人克服浮躁情绪，稳扎稳打练好基本功，想成为优秀的测试专家，就要经历这个阶段。

　　软件测试自动化的引入条件

　　如果你的测试部门有意向引入自动化测试，那么首先要从思想上统一认识。
　　一、 软件测试自动化的正确认识
　　1） 自动化测试能大大降低手工测试工作，但决不能完全取代手工测试。完全的自动化测试只是一个理论上的目标，实际上想要达到 100% 的自动化测试，不仅代价相当昂贵，而且操作上也是几乎不可能实现。一般来说，一个 40-60% 的利用自动化的程度已经是非常好的了，达到这个级别以上将过大的增加测试相关的维护成本。
　　2） 测试自动化的引入有一定的标准，要经过综合的评估，绝对不能理解成测试工具简单的录制与回放过程。实际上，从实现成熟度来说，自动化测试分五个级别：

　　3） 自动化测试能提高测试效率，快速定位测试软件各版本中的功能与性能缺陷，但不会创造性的发现测试脚本里没有设计的缺陷。测试工具不是人脑，要求测试设计者将测试中各种分支路径的校验点进行定制；没有定制完整，即便事实上出错的地方，测试工具也不会发觉。因此，制订全面、系统的测试设计工作是相当重要的。
　　4） 自动化测试能提高测试效率，但对于周期短、时间紧迫的项目不宜采用自动化测试。推行自动化测试的前期工作相当庞大，将企业级自动化测试框架应用到一个项目中也要评估其合适性，因此决不能盲目的的应用到任何一个测试项目中，尤其不适合周期短的项目，因为很可能需要大量的测试框架的准备和实施而会被拖跨。
　　5） 实施测试自动化必须进行多方面的培训，包括测试流程、缺陷管理、人员安排、测试工具使用等。如果测试过程是不合理的，引入自动化测试只会给软件组织或者项目团队带来更大的混乱；如果我们允许组织或者项目团队在没有关于应该如何做的任何知识的情况下实施自动化测试，那将肯定会以失败告终。
　　如果软件企业有意向实施自动化测试，那么应该具备什么样的条件才可以引入自动化测试呢，才可以最大可能的减少引入风险，并能够可持续性的开展下去呢？
　　二、对企业自身现状的评估分析
　　第一，从企业规模上来说，没有严格限制。无论公司大小，都需要提高测试效率，希望测试工作标准化，测试流程正规化，测试代码重用化。所以第一要做到的，就是企业从高层CTO开始，直到测试部门的任何一个普通工程师，都要树立实施自动化测试的坚定决心，不能抱着试试看的态度。一般来说，一个这样的软件开发团队可以优先开展自动化测试工作：测试－开发人员比例合适，比如1：1到1：1.5；开发团队总人数不少于10个。当然，如果你的公司只有三五个测试人员，要实施自动化测试绝非易事；不过可以先让一个、两个测试带头人首先试着开展这个工作，不断总结、不断提高，并和层层上司经常汇报工作的开展情况，再最终决定是否全面推行此事。
　　第二，从公司的产品特征来说，一般开发产品的公司实施自动化测试要比开发项目的公司要优越些。原因很简单，就是测试维护成本和风险都小。产品软件开发周期长，需求相对稳定，测试人员可以有比较充裕的时间去设计测试方案和开发测试脚本；而项目软件面向单客户，需求难以一次性统一，变更频繁，对开发、维护测试脚本危害很大，出现问题时一般都以开发代码为主，很难照顾到测试代码。但决不是说做项目软件的公司不能实施自动化测试，当前国内做项目的软件公司居多，有很多正在推行CMM等级标准，这是好事情；只要软件的开发流程、测试流程、缺陷管理流程规范了，推行自动化测试自然水到渠成。
　　第三，说说标准化的开发和管理流程。不管是CMM还是ISO，不管是开发流程、测试流程还是缺陷管理流程，这里不能一一阐述，可以参考RUP（Rational Unified Process， Rational 统一过程），可以参考很多业界文献，我只说明一点，也是我们IT从业人员甚至任何从业人员一个很好的工作原则：
　　a、 把你想做的写下来（计划管理）
　　b、 按照你写下来的去做（行为管理）
　　c、 把做的事情记录下来（报告管理）
　　d、 出现的问题要设法解决（跟踪管理）
　　在测试流程里，这几个要点都一一有所落实；如果你的软件开发团队据此开发软件，那么完全具备实施自动化测试的条件。当然，也许一些公司的测试管理比较混乱，出了问题不知道谁负责，测试人员或开发人员整日碍

　　其三是软件自动化测试切入方式的风险。正如前面所言，一定要记住将自动化测试与手工测试结合起来使用，不合理的规划会造成工作事倍功半。首先，对于自动化测试率的目标是 10/90 （10% 的自动化测试和 90% 的手工测试）。当这些目标都实现了，可以将自动化测试的使用率提高。对于何种测试情况下引入自动化测试，何时依然采用手工测试，我们分开阐述。
　　一般这样的测试条件下使用自动化测试：
　　· 项目没有严格的时间压力
　　· 具有良好定义的测试策略和测试计划（知道要测试什么 ，知道什么时候测试 ）
　　· 对于自动化测试你拥有一个能够被识别的测试框架和候选者
　　· 能够确保多个测试运行的构建策略
　　· 多平台环境需要被测试
　　· 拥有运行测试的硬件
　　· 拥有关注在自动化过程上的资源
　　· 被测试系统是可自动化测试的
如下条件是宜采用手工测试：
　　· 没有标准的测试过程
　　· 没有一个测试什么、什么时候测试的清晰的蓝图
　　· 在一个项目中，你是一个新人，并且还不是完全的理解方案的功能性和或者设计
　　· 你或者整个项目在时间的压力下
　　· 在团队中没有资源或者具有自动化测试技能的人· 没有硬件
　　其四是企业软件的开发语言风险。当前业界流行的测试工具有几十种，相同功能的测试工具所支持的环境和语言各不相同，这里笔者总结了当前国际上流行的几个软件测试工具生产厂商及一些主要IDE产品，读者可根据参考网址去了解列举工具和更多工具的详细资料。

　　其五还要做时间估算。在评估完前面几项指标后，需要估算实施测试自动化的时间周期，以防止浪费不必要的时间，减少在人员、资金、资源投入上的无端消耗。虽然到测试自动化步入正轨以后，会起到事半功倍的效果，但前期的投入巨大，要全面考虑各种因素，明确实施计划并按计划严格执行，才能最大限度降低风险。
　　其六是工作流程变更风险。测试团队乃至整个开发组织实施测试自动化，或多或少会因为适应测试工具的工作流程，带来团队的测试流程、开发流程的相应变更，而且，如果变更不善，会引起团队成员的诸多抱怨情绪；所以应该尽量减少这种变更，并克服变更中可能存在的困难。
　　其七是人员培训与变更风险。简单而言，就是测试团队人员的培训具有风险性，例如每个角色的定位是否准确，各角色人员对培训技能的掌握程度是否满意，尤其实施途中如果发生人员变更等风险，都要事先做出预测和相应的处理方案。
　　一个企业或软件团队实施测试自动化，会有来自方方面面的压力和风险，但是凭借团队成员的聪明才智和公司高层的大力支持，事先做好评估，做好风险预测，那么可以告诉你一个激动人心的消息：你的团队成功引入了测试自动化！有了测试自动化，我们即可享受它带来的超凡价值和无穷魅力：我们的测试工作变得更简单、更有效，我们工作在一个专家级的团队里，因此我们每天都在享受这种成功的喜悦！

框架经理-FrameworkManager简介

作者：陈能技

前言
    FrameworkManager是由Yaron Assa（www.AdvancedQTP.com）开发的一个开源的QTP自动化测试框架，目的是让QTP的脚本编写更为优雅和清晰（for elegant， clean scripting with QTP）。

一、FrameworkManager简介
    FrameworkManager处理了应用程序的UI层的所有麻烦和细枝末节的琐碎事情，让你编写出更好、更清晰、更简介的测试脚本。FrameworkManager除了提供一个极为简单的接口用于构建和维护脚本之外，还解决了QTP的对象库和描述性编程的问题。
 
    通常我们构建的代码会变得很臃肿，过于复杂而难以维护，例如写了很多的Select-Case或If结构的语句（如果输入域仅能接受Email格式数据，则这样；如果只能接受地址，则那样...）。按照这种方式写的脚本会难以维护，因为一旦被测试的应用程序添加了新的输入域，则需要重复很多代码修改和调整的工作，使用FrameworkManager则能让这些工作成为过去。
 
    FrameworkManager仅仅关注脚本需要的信息，从而保持脚本代码的简单，避免凌乱的代码。决策判断的结构语句被分解成独立的小类，这些小类可以被轻易地维护和更新，而不至于引入大量的BUG。更重要的是，FrameworkManager是环境无关的，能被轻易地扩展用于处理那些尚未被识别的对象和控件。

二、FrameworkManager的特点
    下面列举FrameworkManager的一些功能特性：
1．保持脚本简洁明了。处理对象变成了简单的oObject.Input(“New Value”)。
2．在内部自动处理不同输入类型，例如两个文本输入框，一个仅能输入Email，一个仅能输入数字。
3．在内部自动处理相互关联的操作，也就是说，把两个或多个对象操作组合成一个逻辑顺序的操作，例如单击一个按钮来验证输入框的数据；输入密码紧跟着验证密码。

4．在内部自动选择值验证的方式，例如：
Delegation – 在某个对象中输入一个值，但是在另外一个对象中显示出来。 Regular Expressions – 输入一个值，但是以前缀或后缀显示出来。
5．在内部自动处理条件输入-你可以很容易地设置一个标记来标识某个对象是不可输入的或不可操作的（untouchable），例如你有两个输入域，通过一个按钮来控制其“enabled”和“disabled”属性。
6．在内部自动处理随机值-例如从一个combo-box或list-box控件中随机选择其中的一项。
7．可轻易地为应用程序对象添加个性化的属性，例如标志某些输入域为强制性的（mandatory），把这些输入域与某个查询窗口中的数据域关联，然后在脚本中利用这些数据，快速填充这些强制性输入域的数据。
8．被测试应用程序的对象都被结构化成一个树状，让你可以在脚本中做复杂的对象搜索和操作，例如在某个TAB页下的所有输入框输入所有数据；从一个WebTable转到其父级的Frame中。
9．为了更好地组织对象树，可以添加一些虚拟的层次，从而得到一个可读性更强的对象树。
10．可扩展性强-可以在不修改已有代码的情况下添加新的数据类型产生和输入方法。FrameworkManager可以处理你添加的任何扩展、不可识别的控件和针对被测试应用程序的业务逻辑处理。
三、获取FrameworkManager
    FrameworkManager目前的最新版本是0.81，可到以下地址下载：
http://www.advancedqtp.com/knowledge-base/projects/frameworkmanager/frameworkmanager-version-081/ 下载后把文件解压出来，可看到FrameworkManager的文件结构如下所示： \Documentation 帮助文档。 \Libraries FrameworkManager框架的代码，包括对象树类、输入类等。 \Resources 包含对象树的Excel文件。 \Demo App 用于演示FrameworkManager用法的Demo小程序。 \Tests 用于演示FrameworkManager用法的Test。

四、FrameworkManager框架的组成
FrameworkManager框架主要由3大部分组成：
1．对象树文件（ObjectTree）
这个Excel文件作为可扩展的对象库（Object-Repository），它包含FrameworkManager识别对象所需要的所有数据，以及所有对象的元数据（meta-data），例如强制输入域等。
2．对象树类（clsTreeLevel）
这个类包含FrameworkManager的真正机制。在运行时，根据对象树Excel文件生成对象树实例，所以对象操作都是通过树节点进行封装的。
3．子类（Min、i-classes）
对于树中的每一个节点（例如clsTreeLevel类中的每一个实例），都可以“插入”（plugged）一个这样的子类（mini-class）。它们控制相关的程序对象如何输入数据、操作，如何产生随机的数据等。

对象树Excel文件
     可以在\Resources\ObjectTree.xls中找到该Excel文件，如果要让clsTreeLevel.vbs正确地运行起来，请确保把clsTreeLevel.vbs文件中的sExcelFile这个常量的值修改为Excel文件所在的实际路径，对象树类与对象树就是通过这个常量关联起来的。
打开Excel文件可看到如图1所示的内容
    

    可以看到Excel文件分成两部分，左边部分是具有层次结构关系的对象树，右边部分是对象的相关属性，例如QTPClass、InPutType等。 下面解释一下Excel表中右边部分的各个列名所代表的属性的含义：
? Mandatory – True/False：用于标识该输入域是否为强制性的。
? Condition-只有当该输入域的条件得到满足时，才输入。在Excel单元格中填写的格式是：FieldName>Expected Value| FieldName>Expected Value（多个条件用“|”隔开），例如VB Demo_Example 2_Field 1_Enable_Flag>False表示在对象数中该节点的值必须为False。对于负条件，则使用：FieldName>%NOT%UnExpectedValue
? PreActions – 在输入之前必须完成的操作，填写格式为：FieldName>Value|FieldName>Value（多个前置的操作用“|”隔开），输入空值可用“%EMPTY%”表示。
? PostActions-与PreActions类似，用于表示在输入之后必须完成的操作。
? DPID-对象的描述性编程字符串，例如：vbname:=Something|visible:=True。如果不想使用描述性编程，而是希望通过自己编写的函数来指向一个QTP对象的话，则可使用“%FunctionName%”来获取，例如下面的GetBrowser函数：
    Function GetBrowser(sRedundentParam)
     If Browser("Something").Exist then
    Set GetBrowser = Browser("Something") 
    Else Set GetBrowser = Nothing End If End Funtion

QTPClass-指定对象的类型（micclass），例如VBCombobox、Browser等。
? InputType-当给对象树的某个节点输入时采用的子类，例如Text、Combo。这里填入的子类名加上前缀“Input”和后缀“Class”就成为脚本中能识别的子类（mini-class），对应IputClasses.vbs中的InputTextClass、InputButtonClass等。
? Type-对象树节点的业务逻辑意义，例如Field、Tab、SaveButton等。
? RandomValueType-当给对象树的某个节点随机输入时采用的子类，例如Text、Combo等。这里填入的子类名加上前缀“RandomValue”和后缀“Class”，就成为脚本中能识别的子类，对应RandomValueClasses.vbs中的RandomValueTextClass、RandomValueCheckboxClass等。
? ValueInObject-对象树节点的输入操作被验证时所需的标识。有时候在一个字段输入一个值后，需要访问另外一个字段或对象，以便检查输入是否成功。
? ValidatePattern-用于验证输入操作的正则表达式。用%Value%表示原本的输入值。用“.*%Value%.*”表示实际值中只要包含了原本的值即为成功。

? clsTreeLevel类
    clsTreeLevel类用于构建Excel文件中所描述的对象树的实例。实例化的对象树用一个公共变量oRoot来保持，通过oRoot，可以访问到对象树中的任何一个指定的节点，例如：oRoot.GetLeaf(Identifier)，这个方法返回对象节点的实例。 对象树的每个节点都有一个GetChildList和GetParentList方法，用于返回当前节点的儿子对象列表或父亲对象列表，通过这两个方法可以实现对象树节点的导航，访问任何需要的节点。 通过oNode.QTPObject.GetROProperty可以获取某个节点对象的属性，

    例如QTPObject.GetROProperty("enabled")返回对象节点的enabled属性。 每个节点对象都有一个Input方法，用于对被测试应用程序中的相应对象做输入操作，例如单击一个按钮、设置日期等。 每个节点对象都有一个Value属性，可以返回对象的当前值。 如果你想对节点对象做额外的非标准的输入操作，则可以在各输入子类（mini-class）中定义个性化的操作，然后通过ExecuteCustom命令来激活它们。

? 输入子类（InputClasses）和随机值子类（RandomValueClasses）
为了保持主类（clsTreeLevel）的代码稳定、清晰和简洁，处理实际对象的操作和输入并没有在主类中实现，而是在单独的子类中处理，每一个子类负责特定类型的对象的任务处理，例如InputTextClass用于处理标准的文本输入框，InputComboboxClass则用于处理标准combo-box输入框。 目前为止，FrameworkManager提供两种类型的子类（mini-class）：输入类（Input）和随机值类（RandomValue）。输入类用于处理对象，随机值类用于产生随机值。每个节点对象通过Excel表格中的设置的InputType和RandomValueType来关联相关的子类。

     可以为FrameworkManager扩展新的子类。如果碰到未处理的控件，可以立即编写一个新的子类，在Excel文件中设置相关的类名即可，而不需要更新那些select-case或if结构语句。

五、FrameworkManager的使用方法
    基于前面对FrameworkManager框架的分析，我们基本上明白了FrameworkManager的整体框架的原理。下面简单介绍一下FrameworkManager的使用方法。

    首先，需要在Test的Resources中添加FrameworkManager框架文件目录中的Libraries下的几个文件，包括clsTreeLevel.vbs、General.vbs、InputClasses.vbs、RandomValueClasses.vbs，如图2所示。
           
       添加了这些库文件后，就可以使用FrameworkManager了。针对被测试应用程序，我们还需要为其建立对象树，这个需要在ObjectTree.xls文件中进行编辑。包括各个对象节点以及对象节点所对应的输入操作等。 有了对象树后，我们就可以通过类似下面的脚本来使用FrameworkManager进行对象的测试： Call oRoot.GetLeaf("VB Demo_Example 1_Field 1").Input("Random") 读者可以先参考FrameworkManager框架所附带的Demo程序来了解FrameworkManager的使用方法。然后再修改ObjectTree.xls文件，替换成自己的测试项目中的对象和所需的输入操作。

   
 

5周年了,陪伴我们不断成长~

期待下个5年~

声明本文属于原创,请勿随意转载,如有需要,请先经过笔者同意.尊重原创,鼓励原创.

内功心法前提条件

修炼此功必先戒骄戒躁,

要想练成此功需要多想多做.

一．初级阶段，

在这个阶段除去了刚开始时候新鲜感以后,坚持是很重要的,学习在线帮助时很枯燥的,很多东西看不懂,很多东西是懂非懂的,特别是看英文的帮助对于一部分英文基础比较薄弱的测试人员会望而却步,其实不妨学习的时候看看中文版本的,然后拿手头的项目练习，有问题先思考，查英文帮助(因为英文的描述最地道),自己找答案，最后才提问。往往能成为高手的人,自己解决的问题都很强的.于是找一个好的学习文档很重要,笔者推荐论坛里的精华文章,同时也期待一本可以结合实践的书来指导大家的学习.

二．中级阶段

三人行必有我师,学习别人是一条捷径.现在网络上积累了很多很好的知识,去学习前人积累的经验，特别是别人的问题和解答的办法。最关键是自己要去实践,掌握了才是自己的.积累的过程是漫长的,捷径就是自己找一个项目去练习,巩固知识点,同时收获很多心得.

三．高级阶段

去尝试帮助别人解答问题，从中提高自己解决问题的能力，同时增加自己的积累。在帮助别人的时候,自己往往能提高的更多,并享受其中的成就感.这时候除了国内的几个大网站,不妨去国外的网站走走看看,总能看到一些让自己兴奋不已的东西.这个阶段,我们要求精益求精的提高我们脚本的质量,包括一些特殊功能方面的研究,比如框架管理,日志系统,研究DLL等等.此时你需要掌握至少一门开发语言,测试并不只是写用例,点鼠标的黑盒缺陷杀手,今后的趋势要求测试人员具备更多技能,比如开发,设计,管理,专业背景等知识.

四．最终阶段

学无止境，其实单单QTP有很多方面可以研究,开发插件,拓展自己的知识面,不可以停顿自己前进的步伐,开拓研究还没被大家熟悉的领域。引领潮流,或许几年里QTP会被更先进的东西替代,不变是我们追求知识的执著.不骄傲不自满,乐于分享,收获更多.

也谈单元测试

Founding测试工作室

引子

一般的业界认为,80%的缺陷将会在单元测试阶段(Unit Test)被发现并解决,而系统集成测试(SIT)只能发现总缺陷数的15%,最终在客户验收测试(UAT)只会发现少于5%的缺陷,而这3个阶段修改的成本也是成几何级数增长,比如在单元测试阶段花1块钱能修复的缺陷,到了系统集成测试阶段就需要至少10块钱,因为经过测试人员的发现,开发人员确认修复,最后测试人员的关闭,经历了一系列的流程,成本自然会很高,至于到了客户验收测试的时候,除去了修改缺陷,内部回测以外,大量缺陷往往会遗失客户的信心,危害巨大.于是本文将着力介绍单元测试,希望对广大开发人员有所帮助.

关键字

单元测试,系统集成测试,用户接收测试

单元测试的定义

　　单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把在出生日期的输入框中输入”我爱方正”,那么我们的程序需要截获这样的异常,并在页面给与客户友好的提示信息。

　　单元测试通常是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

　　工厂在组装一台电视机之前，会对每个元件都进行测试，这，就是单元测试。

　　其实我们每天都在做单元测试。你写了一个函数，除了极简单的外，总是要执行一下，看看功能是否正常，有时还要想办法输出些数据，如弹出信息窗口什么的，这，也是单元测试，我们把这种单元测试称为临时单元测试。只进行了临时单元测试的软件，针对代码的测试很不完整，代码覆盖率要超过70%都很困难，未覆盖的代码可能遗留大量的细小的错误，这些错误还会互相影响，当BUG暴露出来的时候难于调试，大幅度提高后期测试和维护成本，也降低了开发商的竞争力。可以说，进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。

　　对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。

为什么要使用单元测试

　　我们编写代码时，一定会反复调试保证它能够编译通过。如果是编译没有通过的代码，没有任何人会愿意交付给自己的老板。但代码通过编译，只是说明了它的语法正确；我们却无法保证它的语义也一定正确，没有任何人可以轻易承诺这段代码的行为一定是正确的。

　　幸运，单元测试会为我们的承诺做保证。编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。有了单元测试，我们可以自信的交付自己的代码，而没有任何的后顾之忧。

　　什么时候测试？单元测试越早越好，早到什么程度？XP开发理论讲究TDD，即测试驱动开发，先编写测试代码，再进行开发。在实际的工作中，可以不必过分强调先什么后什么，重要的是高效和感觉舒适。从我们的经验来看，先编写产品函数的框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码，每写一个功能点都运行测试，随时补充测试用例。所谓先编写产品函数的框架，是指先编写函数空的实现，有返回值的随便返回一个值，编译通过后再编写测试代码，这时，函数名、参数表、返回类型都应该确定下来了，所编写的测试代码以后需修改的可能性比较小。

　　由谁测试？单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。测试部门可以作一定程度的审核。

　　单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行维护。

　　经常与单元测试联系起来的另外一些开发活动包括代码走读(Code review)，静态分析(Static analysis)和动态分析(Dynamic analysis)。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。

现状分析

　　工作中,笔者也遇到了很多开发人员会有一些理由来证明可以不做单元测试,下面罗列了一部分,和大家分享.

　　1、 编写单元测试太花时间了。

　　我们知道，在开发时越早发现BUG，就能节省更多的时间，降低更多的风险。

　　如果你仍然认为在编写产品代码的时候，还是没有时间编写测试代码，那么请先考虑下面这些问题：

　　1）、对于所编写的代码，你在调试上面花了多少时间。

　　2）、对于以前你自认为正确的代码，而实际上这些代码却存在重大的bug，你花了多少时间在重新确认这些代码上面。

　　3）、对于一个别人报告的bug，你花了多少时间才找出导致这个bug 的源码位置。

　　回答完这些问题，请你一定不再以“太花时间”作为拒绝单元测试的借口。

　　2、 运行测试的时间太长了。

　　合适的测试是不会让这种情况发生的。实际上，大多数测试的执行都是非常快的，因此你在几秒之内就可以运行成千上万个测试。但是有时某些测试会花费很长的时间。这时，需要把这些耗时的测试和其他测试分开。通常可以每天运行这种测试一次，或者几天一次。

　　3、 测试代码并不是我的工作。

　　你的工作就是保证代码能够正确的完成你的行为，恰恰相反，测试代码正是你不可缺少的工作。

　　4、 我并不清楚代码的行为，所以也就无从测试。

　　如果你实在不清楚代码的行为，那么估计现在并不是编码的时候。如果你并不知道代码的行为，那么你又如何知道你编写的代码是正确的呢?

　　5、 但是这些代码都能够编译通过。

　　我们前面已经说过，代码通过编译只是验证它的语法通过。但并不能保证它的行为就一定正确。

　　6、 公司请我来是为了写代码，而不是写测试。

　　公司付给你薪水是为了让你编写产品代码，而单元测试大体上是一个工具，是一个和编辑器、开发环境、编译器等处于同一位置的工具。

　　7、 如果我让测试员或者QA（Quality Assurance）人员没有工作，那么我会觉得很内疚。

　　你并不需要担心这些。请记住，我们在此只是谈论单元测试，而它只是一种针对源码的、低层次的，为程序员而设计的测试。在整个项目中，还有其他的很多测试需要这些人来完成，如：功能测试、验收测试、性能测试、环境测试、有效性测试、正确性测试、正规分析等等。

　　8、 没有真实的环境运行单元测试。

有时候因为模块开发计划的问题,有的模块没办法走通正常的流程,但是我们现在所讨论的只是针对开发者的单元测试。也就是说，你可以自己在数据库创建测试数据,或者使用mock 对象,来完成测试。

题外话

  写这篇文章,没别的意思,就想来说明,单元测试的重要性,呼吁公司上下重视起测试工作,为提交一个高质量的应用系统给客户而努力.

What's Agile Test？Please check it.