漏测，这个词对于测试界的朋友来说，是最不想听到的一个词。尽管我们不太可能把软件中所有的bug都找出来，就像开发人员不太可能开发出零bug的软件，但对测试人员提交给自己的bug常耿耿于怀。另外一方面，漏测与否一直以来是很多公司衡量一个测试人员工作质量的重要考核点。

漏测，指测试人员测试通过的软件在后来被他人或自行发现仍存在bug，这种现象常被叫做漏测。由于软件的特殊性，漏测现象常发生，每发现存在漏测bug，相关测试与开发人员需要进行漏测分析，分析此bug的严重度，发生的概率，测试用例是否存在缺失，开发更改代码后的影响分析是否存在不足等。重要的是找出漏测的根源，提出改进的措施，避免同类问题反复出现。

【案例】

事情虽过去10多年了，但依然记忆犹新。那时笔者与一些测试同事一起工作在一家研发与生产PDA的私营台资企业。一天早晨，老板一反常态地在他的办公室里与电话对方发生大声的争吵，最后非常生气地把电话挂掉了。接着，开发与测试主管被叫到他的办公室，

办公室的门被关上了，他们在悄悄地商量着什么。后来，才知道我们已发布出去的软件，在法语版本上，有一个提示界面仍用英文显示着。测试漏测了，而这个点在用户试用现场，被用户发现了。我们听后都不相信这个事实，因为这个提示信息在常规操作中就能出现。问题已出来了，怀疑无济于事，开发与测试相关同事立即动手检查分析，最后开发定位到是由于有一个地方的处理用了HardCopy（硬拷贝），把英文字符串直接写在代码中了（据负责的工程师说，当时是为了调试的方便，后来在把字符串提取出来作为独立的资源文件时，漏了此字符串。后来对字符串资源进行本地化翻译时，也没有意识到此问题的存在。

对于测试来说，是漏了这条用例，是用例设计的遗漏。

查出问题的原因后，软件很快更改好了，测试复测，补丁版本当天即可以重新发布。然而，事情影响的严重性却超乎我们的意料。老板跟我们说，那家客户因为与其他代理商合同的原因，已不能接受我们的产品了，一个158万的单就此泡汤。一个单是小事，重要的是由它带来的负面影响是很难用短期的金钱来衡量的。这也许就是老板为什么会如此生气的主要原因吧。后来负责此模块的开发、测试人员受到通报批评，并扣除本季度全部奖金，相比之公司的损失，确实也算不了什么。

第二天，老板把我们每一个测试人员叫到他的办公室，问及我们漏测的原因是否找出来了，对日后如何进行防范是否有什么措施。反思的过程中，觉得问题与我们现在的测试模式密切相关，我们没有用例，是在看着简单描述的需求来测试，时间长了，连需求都不看了（自认为需求记住了，看懂了）。平时测试完全是在一种随机测试（目前很多人把它叫做Ad hoc测试），无系统可言，测试者的想法及操作没有留下记录，俗话说“好记性不如烂笔头”，一段时间后，哪些路径测试过，哪些没有覆盖到，无从说起。最后导致一些业务流程被测试N遍，而有些用户场景却一次都没有遍历到，也是顺理成章的事。

真佩服当时的老板,讨论解决办法的当时,亲自拿出一张A4空白纸,在上面写着一个个测试功能点,要求我们按照这种方法把各模块的功能点一个个列出来,测试过的则在旁边的小框内打钩。后来我们把它叫做测试checklist。回想起来，这虽然不是合格的测试用例，但比起原来拍脑袋式的随机测试，已向前跨了重要的一步。

 俗话说“失败是成功之母！”，但愿事例中的惨重代价对测试朋友有所启发与借鉴，把测试工作的核心--用例设计的工作做得更加扎实，为项目的测试成功打下坚实的基础。

 

“模型”（Model），是所研究的系统、过程、事物或概念的一种表达形式，很自然地，我们可以理解为软件质量模型便是对软件质量评价要素的一种表达形式。在软件工程中，软件质量模型是一个复杂且又抽象的概念，不同行业软件亦有不同要求。理解起来不会像有实物模型的产品质量好理解，例如谈起一辆车的质量，我们马上便会在脑海中浮现出车的模型，然后对车的轮子，离合，刹等组件的质量要求都能说上一二。软件质量是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面，就像评价一个人的优缺点一样，并没有绝对的唯一答案，它是多维的。我们可以通过改善软件的各种质量属性，从而提高软件的整体质量。对不同质量属性的评估过程，即为软件测试执行的过程。由此看来选择不同的质量属性进行评估决定着测试服务的过程。软件的质量属性，或叫质量要素，与行业特点、技术实现的复杂度等都有关。下面介绍ISO9162标准中提到的软件质量模型，如下图所示。

定义了软件的6大质量属性，其中每一属性其下又包括一些子属性，下面对这些属性进行解释。

一、功能性

功能性(Functionality)是指软件是否满足了客户的需求，结合其子属性，有以下几种特点。

1、  合适性

所提供的功能是用户所需要的，及用户所需要的功能软件系统已提供。笔者觉得此质量属性更适合由前端的需求人员把握，当然测试人员也需根据需求的适用性，以定义测试的重点与优先级。比如在医疗软件系统上如果有一款可供娱乐的游戏，试想医生一边给病人看病一边玩游戏会造成什么后果呢。

2、  准确性

软件系统提供给用户的功能是否满足用户对该功能的精确度要求。此特性好理解，在实际的工程应用中也常遇到，例如财务类软件。如果不涉及特殊用户的需求（如科研机构的特种应有），精度一般都容易满足。

3、  互操作性

软件系统与一个或多个周边系统进行信息交互的能力。例如，运行在windows操作系统上的应用软件，与运行在Linux系统上的软件进行通信，如下图所示。Linux系统是数据的发送方，把数据发送到windows系统上，在windows系统上运行的应用软件需能读出特有数据格式的能力，然后在界面上显示。

4、  安全性

指软件系统保护信息和数据的能力。可以从以下两方面理解：

1） 防止未得到授权的人或系统访问相关的信息或数据；

2） 保证得到授权的人或系统能正常访问相关的信息或数据。

常见的安全性测试：

1） 用户验证：登录密码验证（如windows登录验证，邮箱验证等）、IP地址访问限制等；

2） 用户权限管理:验证低级别用户是否具有了高级别用户的权限，各级别用户权限都得到了实现。例如windows 7操作系统，某些应用程序的运行必须以管理员身份才允许；

3） 系统数据的保护:例如对系统文件、用户密码文件等进行隐藏，机密文件内容进行加密、备份；

5、  功能性的依从性

遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。例如：在中国研发与生产的医疗设备如果要在美国上市销售必须经过FDA（Food and Drug Administration 美国食品及药物管理局）的审核，并通过。细心读者，你会发现每一质量属性都包括其依从性的子属性，由于定义类同，下面不再分开详述。

二、可靠性

可靠性(Reliability)是指软件是否能够一直在一个稳定的状态上满足可用性。

1、  成熟性

软件系统防止内部错误扩散而导致失效的能力。测试过程中常遇到的例子如：模块A更改了某参数，但没考虑到某参数同时被模块B调用，由于模块B并未作相关更改，结果使得模块B的相关功能失效。

2、  容错性

软件系统防止外部接口错误扩散而导致系统失效的能力。

例如：应用软件在操作过程中需操作一个文件，但由于此文件已遭破坏，由于缺少容错处理，结果执行文件操作时，软件崩溃。

3、  易恢复性

系统失效后重新恢复原有功能、性能的能力，包括对原有能力恢复的程度与速度。

典型的例子，我们经常使用的windows系统有时会遇到系统不响应的情况，只好按Reset或关掉电源重新开机。这种情况，当前未保存的数据当然是丢失了，系统重启后能否正常进入系统便是易恢复性的一种体现。

三、可用性

可用性(Usability),是衡量用户使用软件需要付出多大的努力的质量属性。其中，我们经常提到的易用性就是可用性的一个重要方面，指产品易于学习和使用，可减轻记忆负担等，具体可从以下几方面进行理解。

1、 易理解性

易理解性指用户在使用软件系统的过程中，展示给用户的信息是否准确、清晰、易懂，能帮助用户准确理解系统当前真实的状态，并指导其进一步的操作。

一个典型的例子，如下图是我们都很熟悉的登录界面。

用户在输入用户名与密码后，点击“登录”按钮，弹出下图提示。

提示“用户名或密码不正确”告知用户的是不明确的信息，很容易误导用户。因为用户输入的信息有可能两者都错了，或其中之一错了。用户看到此提示后，只能再尝试输入用户名与密码，造成可能正确的信息重新输错了，错的反以为对了，只好反复验证，最后提示超过尝试次数而告终。

 

2、 易学性

易学性是指软件提供相关的辅助手段，帮助用户学习使用它的能力。例如：是否具有在线帮助。在线帮助常见的有两种，一种是跟随功能而变的帮助，如Word、Excel中的菜单项鼠标提示（tips）；另一种是在线帮助手册，如同windows程序按快捷键F1自动调出帮助手册内容。

3、 易操作性

易操作性指用户基本不用额外学习即能操作软件，包括多方面的内容。例如：

1） 常用功能路径不要太深，最好能提供快捷键，且这些快捷键具有普适性（用户已广泛接受），如前面提到的windows程序激活帮助功能的快捷键F1。目前有很多软件采用这种已符合人们的使用习惯的操作。

2） 最好提供一键返回桌面的功能，这一点苹果的Iphone手机做得比较好，无论用户当前在什么位置，只要按下“返回桌面”主键，立即可退出。

3） 操作尽量简单，例如软件的安装或升级，按提示点击“下一步”且不要太长的时间或多个选择路径。

4、  吸引性

吸引性指软件具体某些独特的，能让用户眼前一亮的属性，包括GUI（Graphical User Interface,图形用户界面），多媒体应用。例如：苹果Iphone 4手机，当短信发送成功时，除了弹出新颖的冒泡状提示，还会伴有声音提示你，且声音可由用户根据喜好自行设置。

四、效率

效率(Efficiency)，这里指衡量软件正常运行需要耗费多少时间及物理资源，是性能测试的重点内容。

1、 时间效率

时间效率主要指软件系统在各业务场景下完成用户指定的业务请求所需的响应时间。

一个典型的应用案例：我们在互联网上发表博文，点击“提交”后，一般情况都需等待几秒钟（当然一般都有体贴用户的温馨提示啦J），然后自动跳转到博文显示页面，那么此等待时间，我们可以理解为系统响应的时间。

2、 资源效率

资源效率主要指软件系统在完成用户指定的业务请求所消耗的系统资源，如CPU占有率、内存占有率、通信带宽占有率、软件内部消息包资源占有率等。例如不同业务功能之间，不同GUI界面相互之间的切换，如果切换过程中有明显的后影，或速度太慢，很可能资源占用方面没有处理好。

五、可维护性

可维护性(Maintainability)，衡量对已经完成的软件进行调整需要多大的努力，其又可分为下面四个子属性。

1、  易分析性

指软件系统提供辅助手段帮助开发人员分析识别缺陷、失效产生的原因，找出待修复部分的能力。这也是工程实践中很重要的一方面，可以减少缺陷定位的时间，提高开发人员工作效率。采用系统日志记录的方法，如同windows的事件查看器（eventvwr），把软件执行代码的轨迹或某些错误、状态进行记录，是一种常见的方法。

2、  易改变性

指软件缺陷的修复容易被实施，这与软件的设计有着密切关系。例如设计上封装性好、高内聚（同层次设计时，一个实体只完成一个功能）、低耦合的代码，为未来可能的变化留有扩充余地，它的易改性会更好。

例如：下面关于学生信息定义的代码结构

Struct student{

    Char name ;

    Unsigned int No;

    Char  Sex;

    Char Class;

    Int Reserved[20];   //保留

}

其中最后一行，数组Reserved[20]即为日后学生信息扩展而保留的结构成员。

3、  稳定性

指软件系统在长时间连续工作环境下能否正常工作，不出错，无异常情况等。测试人员常用长时间压力测试的方式检验软件的稳定性，稳定性与资源效率有紧密联系，例如内存的慢泄漏，时间越长，系统稳定性越差，内存资源占用越多，最后可能导致系统瘫痪。

4、  易测试性

指从测试验证角度，软件存在可测试性的难易程度。例如：UI界面，提示框对话框，按钮响应状态变化等是很容易观察到的，可测试性强；有明确的输入输出数据，尽管此数据对于用户来说可能不容易被看到，但通过某种方法仍可验证到，可测试性次子。对鉴于系统设计原因，某种用户场景难于验证，测试的条件苛刻，需特定的实验室条件，如高温高压等，这种情况需考虑改变软件内部状态，通过发布特殊版本进行测试。易测试性作为可维护性的子属性之一，与质量是否存在必然的正向关系呢，即能不能说越容易测试的软件，其质量将越好。从工程最佳实践来看，这种必然的关系倒并不成立，但反过来是成立的，越难验证的软件，其存在问题的风险将可能成倍增大。

六、可移植性

可移植性(Portability)，是衡量软件是否能够方便地部署到不同的运行环境中的能力,它有下面几个特性。

1、  适应性

指软件系统无需做任何相应变动就能适应不同运行环境的能力，其中运行环境通常是指操作系统平台、数据库平台、硬件平台等。例如我们在项目常遇到的情况，某系统软件原来运行在windows XP操作系统上，但后来由于Microsoft 推出了windows 7,windows 8，应用新系统的用户比比皆是，新用户需要某系统软件能在新平台上正常运行。这种因平台的变化，系统应用软件的适应性在设计之初是需考虑的。本书5.2.3中 “设计需求转换为测试需求失败”的案例，便是一个关于应用软件适应性的案例。

2、  易安装性

指平台变化后，成功安装软件的难易程度。有些软件可不作任何变化即可成功部署，有些需作部分变化，如安装过程增加用户选项等。对于软件的安装过程，能尽量考虑用户少参与，多一些自动安装过程会让用户更放心。

3、  共存性

指软件系统在公共环境与其共享资源的其他系统共存的能力。这个特性表明我们在测试时不仅需要关注自身软件特性的实现，还要关注本软件是否影响了其他软件的正常功能。

关于共存性，笔者曾遇一个这样的案例，在应用程序进行输入中文时，只要打开紫光拼音，则软件将自动退出。还有一种是人为的限制，在已知情况下，软件A打开，限制软件B不能运行，有意防患，适合某特殊应用场景。

4、  易替换性

 指软件系统的升级能力，包括在线升级、打补丁升级等。易替换性相对于嵌入式产品软件系统来说，由于涉及硬件物料的更新换代，如某主控芯片、USB接口芯片的换代，还可能会触发底层驱动的升级。

 

 今天读《测试之美》中“用模糊测试让办公软件更可靠”。联想到模糊测试与我们日常工作中通过修改或自动生成特殊数据对测试对象进行验证的方法异曲同工。我们也叫它为破坏性测试，是探测应用程序的健壮性或异常处理能力的有效方法。此方法根据测试对象的不同，不同行业不同产品测试的重要性会有所不同，如果操作不当或测试的权重过大，常会引起开发人员的不满，结果此类bug不了了之，最常看到的场景如下：

1、  没有用户会这样用的，此bug无效！（没有用户会特意破坏数据来使用软件）；（测试人员感到委屈L ）

2、  考虑发生的概率极小，解决的代价大，不解决；（测试人员表示可以理解）

3、  延期解决；（测试人员可以接受）

4、  解决，加入容错措施；（最受测试人员欢迎）

 

建议：异常数据的模糊测试方法，我们测试人员必须采用，但重点放在用户常见场景的关键路径，异常路径放在次要或扩展场景中，且整个测试过程只考虑一次，因为健壮性或容错能力比起能给用户带来价值的核心功能的重要性要低很多。这也符合测试的2-8原则，信不信由你。

  需求覆盖，指测试用例对需求的1：1，或1：N的对应索引关系，是测试用例覆盖需求程度的一种度量方式。由于需求有粗细之分，常见的如一级需求、二级需求、三级需求，指的就是需求的粒度。用例对需求的覆盖度，目前有一些文档管理工具可自动建立它们之间的索引对应关系，如doors,testlink，也可采用excel人工建立体现覆盖情况的追溯关系表。由于文字描述的需求层次划分的主观性较强，度量本身难于精确化。

对于需求覆盖与软件质量的关系，我们可以问一个这样的问题，需求覆盖率达到了100%，就表示所有需求点都有测试用例对应了吗，回答这一点，我想是很容易的。因为在过去的经历中，测试需求总会大于软件需求，如软件对异常情况，边界值的处理（有些需求是来自设计的限制）。需求一般不会描述如此详细，往往会出现有些用例没有需求对应，或者说用例对需求的覆盖可达120%，甚至150%的覆盖，但就能说明软件质量可靠、稳定吗。只能说用户需求确认已实现，测试的程度（全面性）如何，只能是在一个较低要求的层次上回答了这个问题，就好象是解决了温饱问题。再具体一点，例如，张A问李B，“李B，你吃了饭吗？”，李B回答说：“吃了”，那么说用例对需求的覆盖达到了100%，意思就好比此场景的回答。至于李B吃的什么，有哪些菜，有哪些配料组成，它们是如何搭配的，营养结构是否全面、合理，是否影响身体健康。回答这个问题，犹同回答测试全面性与充分性的问题。

我们都清楚，在软件生命周期中需求经常会发生变化，需求测试对于测试来说是一个不可忽视的阶段，它同软件设计一样，是一个迭代的过程。那么需求覆盖是对需求测试的一种反馈，但绝对又不止这些，需求测试在实际工作可以如何开展，有哪些注意问题，有兴趣的读者可以参阅我的<<软测之魂—核心测试设计精解>>第八章的需求测试部分（http://product.china-pub.com/197462）

下面就需求覆盖的追溯方法与大家分享下个人的一些体会：

   下图是以用例为主线(逆向追溯），设计的每一条用例依据都是需求，用例与需求的对应关系体现出一对一，一对多的关系。

 

 

 

另一种方法是以需求为主线（正向追溯），从需求出发，检查每一需求是否有对应的用例，从而确定对需求的覆盖是否达到了100%。下图是以需求为主线的需求与用例索引矩阵图。

  优点是什么呢？需求点明确，可以保证每一需求点都有测试用例与之对应。不象用例为主线的方法，把用例对应的需求点分散在不同的地方，如果有小需求点漏了，也不足为怪哦。

 

无论以用例为主线，还是以需求为主线，建立需求与用例的追溯表，有一个问题很容易暴露出来。细心读者也许你已注意到，用例T1.5怎么没有需求与之对应呢？紧扣需求设计用例本身是没错。如果只看需求，不关心系统的设计或其他相关模块的需求，会使我们陷入只看到局部的需求，以为只要覆盖了需求说明书中的点，即达到了100%覆盖。而实际上，一个软件系统，由若干模块组成，模块与模块之间会存在一些藕合关系。或者有人会认为模块与模块之间接口关系不是集成测试关心的吗？没错，集成测试是要关心，但也没有说系统测试不要关心。到后期系统测试阶段，随着需求的变更，模块之间的接口可能会发生变化，如一些全局数据结构，全局变量等。这样，在系统测试阶段关心模块间的接口显得必不可少。

 

说明：ET，Exploratory Testing

今天是端午节（Dragon Boat Festival），动员全家去海岸城的“潮江春”喝早茶（吃早餐，广东人的一种时尚，品味生活方式），7点多我们起床了，想着锻炼身体为目的，我们徒步前往（约100分钟的路程），让我感到意外的事，7-8点这个时间段，路上行人怎么稀稀落落，连公交车也少。一会才醒过来，是端午节，大家都在放假过节呢。怎么样，想到软件运行过程中，用户休假期间的这种场景，等用户休假回来可不能不动了。如，医院的医疗设备，再比如我们平时工作的电脑，有时也会忘记关机，这种情况，软件看似停留在某一界面，但它是一直运行的，且在后台某些时间段还可能悄无声息地帮用户干着某些事，如定时备份重要数据，清理垃圾等。仪器或设备为了节电进入休眠，如手机，可不能休眠几天或几周后，手机打不开了，仪器不动（停机了）等。

通宵测试法，是一种短假期的测试法，如静置一个晚上就是一种用户场景的测试，在ET中谓之假期测试法。

测试过程中常被忽略，但却受用！

读完JW的“局部探索式测试法”有以下理解
1、探索式其实是一种测试模式，也可理解为风格，测试过程中不限于某种具体方法设计用例，如等价类，边界值，错误推测试，数据组合等，是根据具体的对象进行分析，边执行边设计用例，根据对系统的理解、经验、现场提示等进行输入，分析输出，或根据输出分析输入，等。
2、很适合经验丰富测试人员发挥。
3、抓住一个点后，可以很快通过执行评估出初步结果，很适合敏捷开发过程的摸底测试（冒烟测试）。

 

 

可以用一种这样的思路：通过黑盒功能测试用例的执行，收集用例对代码的覆盖率，代码覆盖率有函数级、行级、分支级覆盖，诚然分支级的覆盖更具意义，但这个覆盖率要达到多少才算合适呢？是否有个确定的答案？

下面是关于代码覆盖率的一则故事（转自西西软件园）

曾经在网上看到一个文章是关于“测试用例自动生成的系统”的，摘要内容如下： 

     一种测试方案生成的方法及其系统，该系统至少包括数据输入及显示模块、测试规范数据库、数据解析模块及测试方案生成模块；其将被测试样品条件参数中的全部信息与测试规范进行比较，并依据该比较结果，生成测试方案；本发明的测试方案生成的方法及其系统，在改变了依靠测试人员的经验来制定测试方案的现状，以及提高了测试方案设计效率的同时，保证了测试方案的精确和严密；在测试规范和规格参数之间建立了对应关系，使测试规范的改变不影响存储该测试规范数据库结构，降低了升级的代价；并可在生成的测试方案中添加新的测试内容，通过相应处理，把新的测试内容自动加入到系统中原有测试规范的对应位置，从而实现了测试规范的自动完善和升级。

    看了几遍，有以下理解：

1、该系统把规格参数录入作为数据库，这些规格参数就是测试数据，参数之间的组合，需符合规范（有约束），用户输入参数后，可得出允许的数据组合，谓之测试方案。

2、测试规范即为测试点，与规格参数有着对应关系；

3、规格参数增加，即需求增加了，对应的测试规范（测试点）可根据与规格参数的变化，自动增加。

但还是有点云里雾里，在想着我们实际工作中设计的测试用例能自动化产生吗？除非是有一定逻辑关系的数据组合，或条件组合用例。不过思路还是挺好的。

 

 昨天回归一个bug，代码走查中，查到一处存在代码风险。

背景：某嵌入式软件有合同管理的功能，其中一项信息是合同的有效期，这个有效期字段属于日期格式，会随着系统日期的变化而变化，即用YYYY/MM/DD，还是MM/DD/YYYY, 或DD/MM/YYYY。当系统日期格式改变后，退出合同管理界面时，提示“日期格式”无效。

 

原因：开发人员在coding时，在给合同有效期的显示格式赋值时采用了一个固定值，这样当系统日期改变后，发现与它当前日期格式不同，而是提示日期格式无效。

更改：代码片段

原来：ContrDateFormt = DATEFORMAT_YYYY_MM_DD(一个枚举值)

更改后：ContrDateFormt = GetCurDateFormt();

 

在对更改点进行回归时，走查了相关代码，通过查整个项目工程的代码中对日期格式直接赋值的地方，发现还有一处仍采用固定日期格式的，但此函数暂无人调用，它是一个孤立的函数。不过，日后有用到的话，就会出现上述同样的问题。这让我想起这样一种常见工作场景：

测试说：怎么又出来之前的bug了。

开发说：我真没改什么，调用的函数原来就存在的。

测试说：我才不相信呢，没改它自己会跑出一个bug来吗？

原来现象是一样，但产生的背景是不一样的。嘿嘿！开发也没注意到这个函数原来是孤岛，它有黑洞，谁叫他要上呢。上了后，第一个倒霉的当然就是他啦，而测试人员是很相信自己的眼睛的，多从现象出发判断问题。J

如何控制Bug的蔓延--防不胜防的糖衣炮弹

有这么一种现象，总是很难控制，就是已上线的软件版本更改，每一个更改都必须有来源，这是公司规定的流程。但是在执行的过程中，常会有偏离。

1、               有些开发工程师在更改代码过程中，看到一些代码有问题，控制不住手氧，改之，结果改出问题（没想到对别的地方有影响）（改完之后，有些技术高手们有时还会窃喜，“我多好，又悄悄地做了一次雷锋）；

2、               测试发现了之前版本遗留的bug，特别是严重的，没经过评审，直接改之，风险不受控（更改非计划内）。

3、               测试提交了一个bug，开发解决时，把系列的问题解决了，影响到多个模块，但测试回归bug没有分析到所有的路径，漏测。开发解决问题的影响分析并没有传递给测试。

第3点，测试吃的亏多着呢，即使有要求开发更改代码要作影响分析，但人为的东西，不可控制。写与不写，写了是否全面了，是不一样的。想起“落后就要挨打”的古训，如果测试人员对每一个提交的软件版本，都能做好代码分析，即使开发不说，或说全，漏测的机会也会少很多。

“冒烟测试”,这一术语应用于不同的行业中,如，水管系统，木制乐器的修理，电子工程，软件工程，娱乐业等领域。

在水管系统应用中，冒烟测试是指在水流经管路系统之前，先用实际的烟雾穿透整个管路系统，从而检查出是否存在渗水的地方。

在木制乐器的修理应用中，做冒烟测试时先堵住乐器的未端,然后把烟从另一端吹入检测是否有渗漏(这种检测方法不常用)。

在电子工程领域的应用中，冒烟测试是指当电路设计好，第一次加电自检时检测在设计或线路上是否存在缺陷，如果存在缺陷常会出现板子冒烟的现象。

在娱乐业应用领域，冒烟测试时使用大量的演习烟雾，以确保在事件发生期间在案发现场的烟雾探测器不会被引发爆炸。

软件工程中的tt应用：冒烟测试是指对提交测试的软件在进行详细深入的测试之前而进行的预测试，这种预测试的主要目的是暴露导致软件需重新发布的基本功能失效等严重问题。冒烟测试可以由开发人员执行，也可以由测试人员来执行。即，在版本编译后正式提交测试之前由开发人员执行；或开发发布版本后，测试人员在接受这个版本作为正式版本进一步测试前执行。微软提出在审查了变更的代码后，冒烟测试是确认修复的缺陷及功能变更是否有效的最经济有效的方法。冒烟测试能手动执行，也可以在版本编译后自动化执行，它是对基本功能的确认，非深入测试，但要覆盖到面，即所有的更改点都要进行确认。采用自动化执行是，可以结合每日构件后进行自动化的每日smoking test，如果测试通过，则把更改后的代码自动合并到主干代码仓库中，作为正式提交测试的版本。

对于smoking test在软件开发过程中的应用，下面提出一种可实施的步骤：

1.     根据软件的变更，包括新需求的实现、bug修复，设计出更改满足预期的功能级checklist。

2.    准备好测试环境。如：软件的运行环境是嵌入式产品，如手机，数码相机，医疗仪器等，需准备好用户使用的真实运行环境。如果是windows平台运行环境，请准备干净的操作系统。

3. 执行checklist，确认基本功能有效，足以支持更进一步的详细、全面测试。

最近遇到一个比较头痛的问题：不该修改的数据却被系统修改了，且是偶发。后来分析发现是由于浮点数比较存在的问题。
  例如: float A,B；
if (A!=B)
  {
   修改某数据   //需求要求
  }

而实际上，当A与B对于用户来说是相等的，如都为5.12，由于精度问题（浮点数在计算机当中的二进制表达方式就决定了大多数浮点数都是无法精确的表达的），系统认为它们是不相等的，使得不该修改的数据被修改了。

发现此问题后，由于整个软件系统中还存在数据处理的地方，作为测试人员应如何有效地全面地揪出同类问题呢？+

欢迎讨论。