随笔 - 22&
&&&&&&&&&&&
一、功能测试
1、链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
2、表单测试
当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
3、Cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
4、设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。
5、数据库测试
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
二、性能测试
1、连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2、负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？
3、压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
三、可用性测试
1、导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。
导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
2、图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。
3、内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的&拼音与语法检查&功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓&相关文章列表&。
4、整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。
对所有的可用性测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
四、客户端兼容性测试
1、平台测试
市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。
因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
2、浏览器测试Web应用的测试内容都包括哪些方面浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
　　五、安全性测试
Web应用系统的安全性测试区域主要有：
（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
1.怎么做好文档测试?仔细阅读，跟随每个步骤，检查每个图形，尝试每个示例,检查文档的编写是否满足文档编写的目的,内容是否齐全，正确，完善.标记是否正确.
软件测试分哪2种方法？分别适合什么情况？
软件测试分2种：白盒测试和黑盒测试。白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试，它着重于程序的内部结构及算法，通常不关心功能与性能指标；黑盒测试又称功能测试、数据驱动测试或基于规格说明的测试，它实际上是站在最终用户的立场，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定2.白盒测试有几种方法?总体上分为静态方法和动态方法两大类。静态：关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义动态：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
3.系统测试计划是否需要同行审批，为什么?需要，系统测试计划属于项目阶段性关键文档，因此需要评审。
4.Alpha测试与beta的区别?Alpha测试在系统开发接近完成时对应用系统的测试；测试后仍然会有少量的设计变更。这种测试一般由最终用户或其它人员完成，不能由程序或测试员完成。Beta测试当开发和测试根本完成时所做的测试，最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其它人员完成，不能由程序员或测试员完成。
5.比较负载测试，容量测试和强度测试的区别?负载测试：在一定的工作负荷下，系统的负荷及响应时间。强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。容量测试：容量测试目的是通过测试预先分 析出反映软件 系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状& 态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试 还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。
6.测试结束的标准是什么？用例全部测试。覆盖率达到标准。缺陷率达到标准。其他指标达到质量标准
7.描述软件测试活动的生命周期？
测试周期分为计划、设计、实现、执行、总结。其中：计划：对整个测试周期中所有活动进行规划，估计工作量、风险，安排人力物力资源，安排进度等；设计：完成测试方案，从技术层面上对测试进行规划；实现：进行测试用例和测试规程设计；执行：根据前期完成的计划、方案、用例、规程等文档，执行测试用例。总结：记录测试结果，进行测试分析，完成测试报告。8.软件的缺陷等级应如何划分？A类&严重错误，包括以下各种错误： 1． 由于程序所引起的死机,非法退出 2． 死循环 3． 数据库发生死锁 4． 因错误操作导致的程序中断 5． 功能错误 6． 与数据库连接错误 7． 数据通讯错误B类&较严重错误，包括以下各种错误： 1． 程序错误 2． 程序接口错误 3． 数据库的表、业务规则、缺省值未加完整性等约束条件C类&一般性错误，包括以下各种错误： 1． 操作界面错误（包括数据窗口内列名定义、含义是否一致） 2． 打印内容、格式错误 3． 简单的输入限制未放在前台进行控制 4． 删除操作未给出提示 5． 数据库表中有过多的空字段D类&较小错误，包括以下各种错误： 1． 界面不规范 2． 辅助说明描述不清楚 3． 输入输出不规范 4． 长操作未给用户提示 5． 提示窗口文字未采用行业术语 6． 可输入区域和只读区域没有明显的区分标志
9. 当开发人员说不是BUG时,你如何应付？开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要 不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？ 程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不 要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场， 让问题得到最后的确认。
10．你为什么想离开目前的职务？因为公司运作情况并不理想，公司需要调整部门体系，公司考虑到缩减部门人员，所以大批量的裁员（有6，7个），这是我的第一份工作，对公司也有较深的 感情，因为在这里我找到了职业理想（就是测试），所以公司需要精简人员，我自愿退出。虽然很舍不得，但我将会有新的发挥能力的舞台。
11．您认为做好测试用例设计工作的关键是什么？白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题
12. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序 的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：1、是否有不正确或遗漏的功能？2、在接口上，输入是否能正确的接受？能否输出正确的结果？3、是否有数据结构错误或外部信息（例如数据文件）访问错误？4、性能上是否能够满足要求？5、是否有初始化或终止性错误？软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计 或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测 试。白盒测试主要是想对程序模块进行如下检查：1、对程序模块的所有独立的执行路径至少测试一遍。2、对所有的逻辑判定，取&真&与取&假&的两种情况都能至少测一遍。3、在循环的边界和运行的界限内执行循环体。4、测试内部数据结构的有效性，等等。单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这 一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进 程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。
阅读(...) 评论()UI&Automation在功能自动化测试中的应用
AutomationUIwindowsUIUI
AutomationUI
AutomationUI
Automationwindows
2UI Automation
UI AutomationUI.NET Framework 3.0Windows Presentation
FoundationWPFUIUIUI.NET Framework3.0Windows XPWindows VistaWindows Server
2003Windows Server
2008Win32.NET WindowsWPF
UI AutomationAutomationElementAutomationElementUIUIUI TreeDesktopUI AutomationAutomationElement&&&&
RootElementProcess IdProcess NamesWindows NameAutomationElementDialogButtonTextBoxCheckBoxPattern
UI Automation1
UI Automation-
UIAutomationProvider.dll
UIAutomat-
ionTypes.dll
UIAutomationClient.dll
UIAutomationT-
UIAutomationCore.dll UI
UIAutomationClientSideProviders.dll
UI-UIUIUIAutomationClient.dllUIUIAutomationTypes.dllUIAutomationClient.dllUI
UIAutomationClient.dllUIAutomationTypes.dllUIAutomationClientProvider.dll
UIAutomat-
ionProvider.dllUIAutomationClientSideProvider.dll.NETUIUIAutomationProvider.dllUIUI
3UI Automation
UI AutomationUI
InvokePatternAutomationPatternAutomationPatternUIExpandCollapsePatternGridPatternGridItemPatternInvokePatternMultipleViewP-
atternRangeValuePatternScrollPatternSelectionPattern
SelectionItemPatternTablePatternTableItemPatternTextP-
atternTogglePatternTransformPatternValuePatternWin-
dowPattern
windowsUI Automation
UI AutomationUIUI
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。功能测试/功能测试
定义Functional testing（功能测试），也称为behavioral testing（行为测试），根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。功能测试是为了确保程序以期望的方式运行而按功能要求对软件进行的测试，通过对一个系统的所有的特性和功能都进行测试确保符合需求和规范。功能测试也叫黑盒子测试或数据驱动测试，只需考虑各个功能，不需要考虑整个软件的内部结构及代码.一般从软件产品的界面、架构出发，按照需求编写出来的测试用例，输入数据在预期结果和实际结果之间进行评测，进而提出更加使产品达到用户使用的要求。应用以上是属于程序软件类的测试，下面介绍应用电子技术方面的测试印刷电路板，又称印制电路板，印刷线路板，常使用英文缩写PCB（Printed circuit board），是重要的电子部件，是电子元件的支撑体，是电子元器件线路连接的提供者。由于它是采用电子印刷技术制作的，故被称为“印刷”电路板。在印制电路板出现之前，电子元件之间的互连都是依靠电线直接连接而组成完整的线路。电路面包板只是作为有效的实验工具而存在，而印刷电路板在电子工业中已经成了占据了绝对统治的地位。20世纪初，人们为了简化电子机器的制作，减少电子零件间的配线，降低制作成本等优点，于是开始钻研以印刷的方式取代配线的方法。三十年间，不断有工程师提出在绝缘的基板上加以金属导体作配线。而最成功的是1925年，美国的Charles Ducas 在绝缘的基板上印刷出线路图案，再以电镀的方式，成功建立导体作配线。直至1936年，奥地利人保罗·爱斯勒（Paul Eisler）在英国发表了箔膜技术，他在一个收音机装置内采用了印刷电路板；而在日本，宫本喜之助以喷附配线法“メタリコン法吹着配线方法（特许119384号）”成功申请专利。而两者中Paul Eisler 的方法与现今的印刷电路板最为相似，这类做法称为减去法，是把不需要的金属除去；而Charles Ducas、宫本喜之助的做法是只加上所需的配线，称为加成法。虽然如此，但因为当时的电子零件发热量大，两者的基板也难以配合使用，以致未有正式的实用作，不过也使印刷电路技术更进一步。发展1941年，美国在滑石上漆上铜膏作配线，以制作近接信管。1943年，美国人将该技术大量使用于军用收音机内。1947年，环氧树脂开始用作制造基板。同时NBS开始研究以印刷电路技术形成线圈、电容器、电阻器等制造技术。1948年，美国正式认可这个发明用于商业用途。自20世纪50年代起，发热量较低的晶体管大量取代了真空管的地位，印刷电路版技术才开始被广泛采用。而当时以蚀刻箔膜技术为主流。1950年，日本使用玻璃基板上以银漆作配线；和以酚醛树脂制的纸质酚醛基板（CCL）上以铜箔作配线。1951年，聚酰亚胺的出现，便树脂的耐热性再进一步，也制造了聚亚酰胺基板。1953年，Motorola开发出电镀贯穿孔法的双面板。这方法也应用到后期的多层电路板上。印刷电路板广泛被使用10年后的60年代，其技术也日益成熟。而自从Motorola的双面板面世，多层印刷电路板开始出现，使配线与基板面积之比更为提高。1960年，V. Dahlgreen以印有电路的金属箔膜贴在热可塑性的塑胶中，造出软性印刷电路板。1961年，美国的Hazeltine Corporation参考了电镀贯穿孔法，制作出多层板。1967年，发表了增层法之一的“Plated-up technology”。1969年，FD-R以聚酰亚胺制造了软性印刷电路板。1979年，Pactel发表了增层法之一的“Pactel法”。1984年，NTT开发了薄膜回路的“Copper Polyimide法”。1988年，西门子公司开发了Microwiring Substrate的增层印刷电路板。1990年，IBM开发了“表面增层线路”（Surface Laminar Circuit，SLC）的增层印刷电路板。1995年，松下电器开发了ALⅣH的增层印刷电路板。1996年，东芝开发了B2it的增层印刷电路板。就在众多的增层印刷电路板方案被提出的1990年代末期，增层印刷电路板也正式大量地被实用化。为大型、高密度的印刷电路板装配（PCBA,printed circuit board assembly）发展一个稳健的测试策略是重要的，以保证与设计的符合与功能。除了这些复杂装配的建立与测试之外，单单投入在电子零件中的金钱可能是很高的 - 当一个单元到最后测试时可能达到25,000美元。由于这样的高成本，查找与修理装配的问题是重要的步骤。今天更复杂的装配大约18平方英寸，18层；在顶面和底面有2900多个元件；含有6000个电路节点；有超过20000个焊接点需要测试。在朗讯加速的制造工厂（N. Andover,MA），制造和测试艺术级的PCBA和完整的传送系统。超过5000节点数的装配对我们是一个关注，因为它们已经接近我们现有的在线测试（ICT,in circuit test）设备的资源极限（图一）。我们制造大约800种不同的PCBA或“节点”。在这800种节点中，大约20种在个节点范围。可是，这个数迅速增长。新的开发项目要求更加复杂、要有更大的PCBA和更紧密的包装。这些要求挑战我们建造和测试这些单元的能力。更进一步，具有更小元件和更高节点数的更大电路板可能将会继续。例如，正在画电路板图的一个设计，有大约116000个节点、超过5100个元件和超过37800个要求测试或确认的焊接点。这个单元还有BGA在顶面与底面，BGA是紧接着的。使用传统的针床测试这个尺寸和复杂性的板，ICT一种方法是不可能的。在制造工艺，特别是在测试中，不断增加的PCBA复杂性和密度不是一个新的问题。意识到的增加ICT测试夹具内的测试针数量不是要走的方向，我们开始观察可代替的电路确认方法。看到每百万探针不接触的数量，我们发现在5000个节点时，许多发现的错误（少于31）可能是由于探针接触问题而不是实际制造的缺陷（表一）。因此，我们着手将测试针的数量减少，而不是上升。尽管如此，我们制造工艺的品质还是评估到整个PCBA。我们决定使用传统的ICT与X射线分层法相结合是一个可行的解决方案。
黑盒测试/功能测试
概述黑盒测试（Black-box Testing，又称为功能测试或数据驱动测试）是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。比如黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。黑盒测试试图发现以下类型的错误：（1）功能错误或遗漏（2）界面错误（3）数据结构或外部数据库访问错误（4）性能错误（5）初始化和终止错误用例设计（1）等价类划分方法（2）边界值分析方法（3）错误推测方法（4）因果图方法（5）判定表驱动分析方法（6）正交实验设计方法（7）功能图分析方法等价类划分是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的，常用的黑盒测试用例设计方法。划分等价类等价类是指某个输入域的子集合.在该子集合中，各个输入数据对于揭露程序中的错误都是等效的.并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试.因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况：有效等价类和无效等价类。有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。无效等价类：与有效等价类的定义恰巧相反。设计测试用例时，要同时考虑这两种等价类.因为，软件不仅要能接收合理的数据，也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性。方法下面给出六条确定等价类的原则。①在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。③在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。④在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。设计用例在确立了等价类后，可建立等价类表，列出所有划分出的等价类：输入条件 有效等价类无效等价类... ... ...... ... ...然后从划分出的等价类中按以下三个原则设计测试用例：①为每一个等价类规定一个唯一的编号.②设计一个新的测试用例，使其尽可能多地复盖尚未被复盖地有效等价类，重复这一步.直到所有的有效等价类都被复盖为止.③设计一个新的测试用例，使其仅复盖一个尚未被复盖的无效等价类，重复这一步.直到所有的无效等价类都被复盖为止.边界值分析法边界值分析方法是对等价类划分方法的补充.⑴边界值分析方法的考虑：长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例，可以查出更多的错误.使用边界值分析方法设计测试用例，首先应确定边界情况.通常输入和输出等价类的边界，就是应着重测试的边界情况.应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据.⑵基于边界值分析方法选择测试用例的原则：1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据.2）如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据.3）根据规格说明的每个输出条件，使用前面的原则1）.4）根据规格说明的每个输出条件，应用前面的原则2）.5）如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例.6）如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例.7）分析规格说明，找出其它可能的边界条件.错误推测法错误推测法： 基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法.错误推测方法的基本思想： 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例. 例如，在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等，这些就是经验的总结. 还有，输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.因果图方法前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等. 考虑输入条件之间的相互组合，可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.利用因果图生成测试用例的基本步骤：⑴ 分析软件规格说明描述中，那些是原因（即输入条件或输入条件的等价类），那些是结果（即输出条件），并给每个原因和结果赋予一个标识符.⑵ 分析软件规格说明描述中的语义.找出原因与结果之间，原因与原因之间对应的关系. 根据这些关系，画出因果图.⑶ 由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件.⑷ 把因果图转换为判定表.⑸ 把判定表的每一列拿出来作为依据，设计测试用例.从因果图生成的测试用例（局部,组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而线性地增加.前面因果图方法中已经用到了判定表.判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.判定表通常由四个部分组成条件桩（Condition Stub）：列出了问题得所有条件.通常认为列出得条件的次序无关紧要.动作桩（Action Stub）：列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.条件项（Condition Entry）：列出针对它左列条件的取值.在所有可能情况下的真假值.动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作.规则：任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则。显然，判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列.建立步骤（根据软件规格说明）①确定规则的个数.假如有n个条件.每个条件有两个取值（0,1），故有5种规则：②列出所有的条件桩和动作桩。③填入条件项。④填入动作项.等到初始判定表。⑤简化.合并相似规则（相同动作）。B. Beizer 指出了适合使用判定表设计测试用例的条件：①规格说明以判定表形式给出，或很容易转换成判定表。②条件的排列顺序不会也不影响执行哪些操作。③规则的排列顺序不会也不影响执行哪些操作。④每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。⑤如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。优点⒈ 基本上不用人管着，如果程序停止运行了一般就是被测试程序crash了⒉ 设计完测试例之后，下来的工作就是爽了，当然更苦闷的是确定crash原因缺点⒈ 结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG的东西很值得借鉴⒉ 没有状态转换的概念，一些成功的例子基本上都是针对PDU来做的，还做不到针对被测试程序的状态转换来作⒊ 就没有状态概念的测试来说，寻找和确定造成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来说，就更麻烦了，尤其不是一个单独的testcase造成的问题。这些在堆的问题中表现的更为突出。工具的选择那么，如何高效地完成功能测试？选择一款合适的功能测试工具并培训一支高素质的工具使用队伍无疑是至关重要的。尽管现阶段存在少数不采用任何功能测试工具，从事功能测试外包项目的软件服务企业。短期来看，这类企业盈利状况尚可，但长久来看，它们极有可能被自动化程度较高的软件服务企业取代。用于功能测试的工具软件有很多，针对不同架构软件的工具也不断推陈出新。这里重点介绍的是其中一个较为典型自动化测试工具，即Mercury公司的WinRunner。WinRunner是一种用于检验应用程序能否如期运行的企业级软件功能测试工具。通过自动捕获、检测和模拟用户交互操作，WinRunner能识别出绝大多数软件功能缺陷，从而确保那些跨越了多个功能点和数据库的应用程序在发布时尽量不出现功能性故障。WinRunner的特点在于： 与传统的手工测试相比，它能快速、批量地完成功能点测试； 能针对相同测试脚本，执行相同的动作，从而消除人工测试所带来的理解上的误差； 此外，它还能重复执行相同动作，测试工作中最枯燥的部分可交由机器完成； 它支持程序风格的测试脚本，一个高素质的测试工程师能借助它完成流程极为复杂的测试，通过使用通配符、宏、条件语句、循环语句等，还能较好地完成测试脚本的重用； 它针对于大多数编程语言和Windows技术，提供了较好的集成、支持环境，这对基于Windows平台的应用程序实施功能测试而言带来了极大的便利。
&|&相关影像
互动百科的词条（含所附图片）系由网友上传，如果涉嫌侵权，请与客服联系，我们将按照法律之相关规定及时进行处理。未经许可，禁止商业网站等复制、抓取本站内容；合理使用者，请注明来源于。
登录后使用互动百科的服务，将会得到个性化的提示和帮助，还有机会和专业认证智愿者沟通。
此词条还可添加&
编辑次数：12次
参与编辑人数：10位
最近更新时间： 06:42:05
申请可获得以下专属权利：
贡献光荣榜