软件测试桌面系统测试自动化测试.doc

软件测试桌面系统测试自动化测试工具浏览器软件工程摘要:作为软件开发的重要环节，软件测试越来越受到人们的重视随着软件开发规模的增大、复杂程度的增加，以寻找软件中的错误为目的的测试工作就更加困难为了尽可能多地找出程序中的错误，生产出高质量的软件产品，加强对测试工作的研究尤为重要 本课题以Sun中国工程院的Linux桌面系统项目JavaDesktopSystem的测试工作为基础，结合现有测试理论对基于Linux的桌面系统的测试方法和测试技术进行了深入细致的分析研究并取得了多项创新性成果在理论方面提出了复合白盒测试法和缺陷图表统计模型复合白盒测试法是一种综合性的测试方法，它利用测试覆盖技术和面向缺陷的测试方法使发现的缺陷数量最大化，利用域比较测试技术和Mutation法降低测试用例的执行次数从而减轻工作量缺陷图表统计模型是基于缺陷统计分析的桌面软件质量评价方法，其核心包括缺陷分布统计、缺陷龄期统计和缺陷趋势统计这些理论方法已在JavaDesktopSystem的测试实践中得到应用，并取得很好的实际效果 设计测试用例和测试工具是桌面系统软件测试中的关键技术问题本文以JavaDesktopSystem的重要组件Mozilla浏览器为对象，阐述了测试用例DOM引擎和Javascript解释器、辅助测试工具IECT和自动化性能测试工具Loadpage的实现方法，并详细介绍了许多技术解决方案这些测试用例和测试工具在Mozilla浏览器的测试中正发挥着重要的作用标题:软件测试桌面系统测试自动化测试工具浏览器软件工程专业:软件工程学位:硕士单位:湖南大学关键词:软件测试桌面系统测试自动化测试工具浏览器软件工程论文简介：软件测试技术的自动化是软件测试的发展趋势，正确、合理地实施自动化测试，能够快速、彻底地对软件进行测试，从而提高软件质量，节省经费，缩短产品发布周期。本文系统的论述了在自动化测试中所遇到的一些问题和误解，包括测试计划、测试模型、测试流程、测试用例、测试脚本、缺陷管理、人员安排、测试工具使用，并在全国短波监测网络系统的测试中得到了实践。 在本文设计中，尽可能地应用各模型中对项目有实用价值的方面，而不拘泥于某个具体的模型。在测试实践中：以 W 模型作为参考框架，同时灵活运用H 模型独立测试的思想。 在达到恰当的就绪点时就开展独立的测试工作，同时将测试工作进行迭代。“尽早测试”、“全面测试”、“全过程测试”和“独立、迭代的测试”是测试所遵循的四个原则，这在实际测试项目中得到了应用并得到了良好的效果。 本文以整个短波系统开发生命周期为主线，相继引入了测试工具。其中测试辅助工具CVS可以建立资源版本，建立每日构建。TestDirector系统地控制整个测试过程，并创建整个测试工作流的框架和基础，使整个测试管理过程变得更为简单和有组织。winRunner 是对系统进行功能测试的，通过设计的脚本来自动复现手工操作。LoadRunner 是对系统性能进行测试的，通过模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题。以上工具交互配合适用，在不断的测试迭代中改善了短波系统开发过程，提高了系统的可靠性。软件测试精华三 分类： 软件测试 2008-11-17 21:05下面，谈谈软件测试的其他方面的一些问题。 一个被人忽略的软件测试目的 在谈到测试时，许多作者都引用了Grenford J. Myers 就软件测试目的提出的以下观点： 1.测试是程序的执行过程，目的在于发现错误；2.一个好的测试用例在于能发现至今未发现的错误；3.一个成功的测试是发现了至今未发现的错误的测试。 这是一种比较狭窄的观点。作为一个清醒的、纵观全局的软件开发人员或管理者，我们应当从软件过程的角度来看测试。 一个被人忽略的软件测试目的是：测试可以帮助发现当前开发工作所采用的软件过程（也是一个“软件”）的缺陷，以便进行改进。（在以下的讨论中，“错误”与“缺陷”基本上认为代表相同意义。） 怎样理解这种说法呢？ 首先，测试并不仅仅是为了要找出错误。分析错误产生的原因和错误在开发的哪一个阶段产生，具有非常重要的意义。 通过分析错误的原因，我们可以立即在开发行动中对其进行改正。同时，这种分析也能帮助我们推理出 与所分析的错误有关联的潜在错误，从而有针对性地设计出检测的方法。 通过分析错误产生于哪一个开发阶段、而又在哪一个阶段被发现，我们可以判断从错误的产生到错误的发现，跨越了多少个开发阶段。软件开发的一条重要原则是尽早发现与修正错误。（当然，更高的一条原则是尽量预防错误的出现。）一个错误能够超越本开发阶段而不被发现，就指明了该开发阶段的检测手段有缺陷，从而也不难有针对性地制定出加强的措施与办法。这也就是软件过程改进的一项重要内容。如果能做到在同一开发阶段发现及修正错误，该开发机构就可以预期有一个高质量的产品及一个低成本、高效率的软件过程。 有些项目的主持人，认为以尽快的速度把测试之前的所有开发阶段完成（实际并没有完成），早日开始测试，以图达到快速和高质量（因为似乎有更长的时间可用于测试）。实际的效果将会是俗语所说的“欲速不达”。从常识就可以知道，花开发时间去继续扩大发展前面阶段引入的错误，得出的只能是更大量的需要耗时修正的错误。 因此，正确分析与利用测试的结果，我们可以非常有效地进行软件过程改进。 软件开发全过程检测，力争本阶段修正错误 从上面的讨论，我们很自然的就能领会到，软件错误的发现绝不能等到测试才开始（按常规，最早的测试就是编码后的单元测试）。因此，笔者提出一个软件工程的守则：软件开发全过程检测，力争本阶段修正错误。单元测试是在软件开发的“实现阶段”才开始的，在此之前的“可行性研究与计划阶段”，“需求分析阶段”，“概要设计阶段”，和“详细设计阶段”，都必须有非常明确切实的手段与措施对开发结果进行检验，以保证阶段的正确完成。 怎样判断一个软件过程的优劣，怎样进行软件过程改进，都可以在这个守则的指导下进行。这个守则是简单明确的，但因企业背景、条件的不同，开发环境条件的不同，项目产品的不同，实际的软件过程的实现方法就会变化无穷。考虑实现这个原则的方法的时候，可以尽量多参考各种理论及经验，但在选择制定本企业开发实践中使用的软件过程时，就必须处处根据是否能给自身的项目带来好处，以及自身的条件进行考虑。千万不要仅仅为了满足某个“标准”的提法而做一些无实际意义的工作。要尽量避免烦琐，争取做到简单、有条理和有最大的效果。 软件测试的自动化 软件测试的工作量很大（据统计，会用到40% 的开发时间；一些可靠性要求非常高的软件，测试时间甚至占到总开发时间的60% ），但测试却是在整个软件过程中极有可能应用计算机进行自动化的工作，原因是测试的许多操作是重复性的、非智力创造性的、需求细致注意力的工作。计算机就最适合于代替人类去完成这些任务。企业在这方面的投资，会对整个开发工作的质量、成本、和周期带来非常明显的效果。 一些适于考虑进行自动化的测试操作为： 1.测试个案的生成（包括测试输入，标准输出，测试操作指令等）。2.测试的执行写控制（包括单机与网络多机分布运行；夜间及假日运行。测试个案调用控制；测试对象、范围、版本控制等。）。 3.测试结果与标准输出的对比。4.不吻合的测试结果的分析、记录、分类、和通报。5.总测试状况的统计，报表的产生。 测试自动化与软件配置管理是密不可分的。与测试有关的资源都应在配置管理中进行统一的计划考虑。另外，测试工具的采用也是一个提高质量的关键，有些专用的测试工具能帮助发现一些用任何测试个案都难以触及的错误。 14.安装与卸载测试我的学习总结前几天发表了“如何进行卸载测试”的贴子，得到很多回复，这里表示感谢！通过认真地学习与总结前辈们的宝贵经验，现整理一部分如下，主要是加深自己对它们的理解，还有希望大家继续补充与给出建议，谢谢！软件安装与卸载测试是相辅相成，通过互相补充，会发现更多的测试角度，谢谢=卸载测试=文件安装目录里的文件及文件夹（如：程序安装在几处的)非安装目录（向系统其它地方添加的文件及文件夹） 它们包括（exe,dll,配置文件等)快捷方式（桌面，菜单，任务栏，系统栏,控件面板，系统服务列表等）复原方面卸载后，系统能否恢复到软件安装前的状态（包含目录结构、动态库,注册表，系统配置文件,驱动程序,关联情况等）卸载方式程序自带卸载程序/系统的控件面板卸载/其它自动卸载工具（如:优化大师)卸载状态程序在运行/暂停/终止等状态时的卸载非正常卸载情况卸载软件过程中，取消卸载进程，然后，观察软件能否继续正常使用冲击卸载在卸载的过程中，中断电源，然后，启动计算机后，重新卸载软件，如果软件无法卸载，则重新安装软件，安装之后再重新卸载。卸载环境不同的(操作系统，硬件环境，网络环境等)下进行卸载卸载后,该系统是否对其他的应用程序造成不正常影响（如操作系统,应用软件等)=安装测试=一：基本目标1.安装程序能正确运行2.程序安装正确3.程序安装后能正确运行4.完善性安装后程序能正确运行二：一些方面0、安装手册给的所有步骤得到验证；1、安装过程中所有缺省选项得到验证；2、安装过程中典型选项得到验证；3、测试各种不同的安装组合，并验证各种不同组合的正确性(包括参数组合，控件执行顺序组合，产品安装组件组合，产品组件安装顺序组合(如b/s)等)4、安装过程中异常配置或状态（非法和不合理配置）情况进行了测试(如：断电；数据库终止，网络终止等)5、安装后是否能产生正确的目录结构和文件，文件属性正确；6、安装后动态库是否正确；6、安装后软件能否正确运行；7、安装后没有生成多余的目录结构,文件，注册表信息，快捷方式等；9、安装测试应该在所有的运行环境上进行验证(手册上指定如：操作系统，数据库，硬件环境，网络环境等)；10、自动安装还是手工配置安装11、至少要在一台笔记本上进行安装/卸载测试，因为有很多产品在笔记本中会出现问题，尤其是系统级的产品13、安装,该系统是否对其他的应用程序造成不正常影响（如操作系统,应用软件等)15.微软的测试题Test Paper for Software Design Engineer(Test time: 60 minutes)Name: Date: Location:Part 1: Technical Skills Set（请将 “ ”paste在您所掌握的技能程度表格内，并注明您的使用时间和相关的证书）技能列表 精通 熟练 掌握 了解 使用时间(月) 所获证书English (oral)English (written)OOP programming skillsC/C+ (pointer, memory)JavaC#NET算法&数据结构Win API experience plusPart 2 : Technical Test1 实现二分查找的递归算法的函数。（使用C+，不建议用伪码） 2 请指出该程序的错误。#include int *p;void Function();int n;n = 25; p = &n;void main()Function(); coutvalue of *p: *pendl;3. 英语写作Question: Please describe your career path in the next two years.16. 多线程与多进程线程的外壳是进程，进程管理线程；线程不占用系统资源，而进程占用系统资源；什么叫进程？进程同程序有什么区别？ 答:进程是程序在计算机上的一次执行活动。当你运行一个程序，你就启动了一个进程。显然，程序是死的(静态的)，进程是活的(动态的)。进程可以分为系统进程和用户进程。凡是用于完成操作系统的各种功能的进程就是系统进程，它们就是处于运行状态下的操作系统本身；用户进程就不必我多讲了吧，所有由你启动的进程都是用户进程。进程是操作系统进行资源分配的单位。 在Windows下，进程又被细化为线程，也就是一个进程下有多个能独立运行的更小的单位。在同一个时间里，同一个计算机系统中如果允许两个或两个以上的进程处于运行状态，这便是多任务。现代的操作系统几乎都是多任务操作系统，能够同时管理多个进程的运行。 多任务带来的好处是明显的，比如你可以边听mp3边上网，与此同时甚至可以将下载的文档打印出来，而这些任务之间丝毫不会相互干扰。那么这里就涉及到并行的问题，俗话说，一心不能二用，这对计算机也一样，原则上一个CPU只能分配给一个进程，以便运行这个进程。我们通常使用的计算机中只有一个CPU，也就是说只有一颗心，要让它一心多用，同时运行多个进程，就必须使用并发技术。实现并发技术相当复杂，最容易理解的是“时间片轮转进程调度算法”，它的思想简单介绍如下：在操作系统的管理下，所有正在运行的进程轮流使用CPU，每个进程允许占用CPU的时间非常短(比如10毫秒)，这样用户根本感觉不出来CPU是在轮流为多个进程服务，就好象所有的进程都在不间断地运行一样。但实际上在任何一个时间内有且仅有一个进程占有CPU。 如果一台计算机有多个CPU，情况就不同了，如果进程数小于CPU数，则不同的进程可以分配给不同的CPU来运行，这样，多个进程就是真正同时运行的，这便是并行。但如果进程数大于CPU数，则仍然需要使用并发技术。 在Windows中，进行CPU分配是以线程为单位的，一个进程可能由多个线程组成，这时情况更加复杂，但简单地说，有如下关系： 总线程数 CPU数量：并发运行 并行运行的效率显然高于并发运行，所以在多CPU的计算机中，多任务的效率比较高。但是，如果在多CPU计算机中只运行一个进程(线程)，就不能发挥多CPU的优势。 这里涉及到多任务操作系统的问题，多任务操作系统(如Windows)的基本原理是:操作系统将CPU的时间片分配给多个线程,每个线程在操作系统指定的时间片内完成(注意,这里的多个线程是分属于不同进程的).操作系统不断的从一个线程的执行切换到另一个线程的执行,如此往复,宏观上看来,就好像是多个线程在一起执行.由于这多个线程分属于不同的进程,因此在我们看来,就好像是多个进程在同时执行,这样就实现了多任务.Whoops，真绕口.所以结合楼上的答复，不知道楼主是否可以满意！关于多线程，多进程的问题，楼主可以看看操作系统方面的书，可以得到更多的启示！ 如上,多线程和多任务是有很明显的区别的.但是再想一下,在一个应用程序内实现多线程不也是靠CPU分配时间片吗?既然原理是相同的,那么多线程也可以说是多任务的. 17回归测试回归测试和验证修复的bug不是等同的.回归测试要求在新的版本中,重新遍历测试用例,因为开发人员在解决问题时可能会影响到相关的模块,只验证修复的问题是否已经解决不能叫做回归测试.我们最新采用的回归测试的方法是：把所有的测试说明中的用例全部执行一遍！（很麻烦的说）然后对于初次测试出问题的地方及其边缘重点测试！1、关于Bug的状态前面有帖子楼主可以看看，开发人员如果认为Bug已修复，应把Bug的状态改成Resolved，测试人员发现有Resolved的Bug就要进行回归测试以验证Bug是否真的解决，如验证通过则将Bug的状态改成Verified Pass，然后再由相关人员（如测试负责人）把Bug的装体改成Closed；如验证失败则将Bug的状态改成Verified Fail，让开发人员再去解决。2、关于楼主提到的“但是在测试用例很多的情况下，自己可能也不记得那些测试用例中有实际结果与期望结果不一致的用例”说明Bug的提交和记录存在问题，Bug所对应的测试用例编号是肯定要包含在Bug报告中的，这样回归测试的时候就不会搞不清楚了。3、现在开源的Bug管理工具也是有的，如bugzilla，最好还是去装一个吧。Bug的状态各个公司会不同，多少也不一样，我原来在德公司就有30来种状态。呵呵！一般只要能够区分下面几种情况，并且不让人误解就好了1，新提交的Bug2，开发正在修改的Bug3，已经修改好并且等待测试人员验证的Bug4，验证通过的Bug5，验证没有通过的Bug（这个要和新提交的Bug同样处理，不过有的公司需要记住没有改好的次数，用来考评开发的绩效）6，设计问题7，测试人员报错8，暂时不修改的Bug回归测试的方法具体问题具体分析，可能有人说我这样等于什么都没说，可是每个项目不同，不同时期也不同，甚至可能测试的人员都换了，如果以一种固定的方法来做，未免显得有点死板。个人认为，在测试的时候，最好能够边测试，边在测试用例上加上备注，说明实际结果。并且最好用颜色标记，如果你够仔细，能够把有问题的测试用例再标注上Bug的编号就更好了，这样在复查bug时，就知道修改好的bug是由哪个用例引起的，可以执行一下相关的用例，看是否真的改好并且没有影响到其他部分，这样就可以放心的Close了。如果有人觉得这样太过麻烦或者中途有人员的变动，也可以只看Bug的描述，按照bug的说明进行验证就够了，但是要记住最好能够对相关的模块进行一下测试，看看流程是否还能走通。不过这就要求Bug的描述要写得比较清晰，明了。18测试大纲和测试计划测试大纲只是简单的描述如何开展测试，而测试计划是针对测试中的每个环节的。单元测试、集成测试、系统测试等一般都写测试计划，写的重点不同。而大纲只是简要的写一下测试策略是什么，需要做哪些测试，测试过程如何组织，测试人员包括哪些。可以说管理人员写测试大纲，而测试人员写测试计划。 19测试版本大全转贴alpha 内部测试版beta 外部测试版demo 演示版Enhance 增强版或者加强版 属于正式版Free 自由版Full version 完全版 属于正式版shareware 共享版Release 发行版 有时间限制Upgrade 升级版Retail 零售版Cardware 属共享软件的一种，只要给作者回复一封电邮或明信片即可。（有的作者并由此提供注册码等），目前这种形式已不多见。Plus 属增强版，不过这种大部分是在程序界面及多媒体功能上增强。Preview 预览版Corporation & Enterprise 企业版Standard 标准版Mini 迷你版也叫精简版只有最基本的功能Premium - 贵价版Professional - 专业版Express - 特别版Deluxe - 豪华版Regged - 已注册版CN - 简体中文版CHT - 繁体中文版EN - 英文版Multilanguage - 多语言版Rip 是指从原版文件（一般是指光盘或光盘镜像文件）直接将有用的内容（核心内容）分离出来，剔除无用的文档，例如PDF说明文件啊，视频演示啊之类的东西，也可以算做是精简版吧但主要内容功能是一点也不能缺少的！另：DVDrip是指将视频和音频直接从DVD光盘里以文件方式分离出来。trail 试用版（含有某些限制，如时间、功能，注册后也有可能变为正式版）RC 版。是 Release Candidate 的缩写，意思是发布倒计时，该版本已经完成全部功能并清除大部分的BUG。到了这个阶段只会除BUG，不会对软件做任何大的更改。 RTM 版。这基本就是最终的版本，英文是 Release To Manufactur，意思是发布到生产商。Original Equipment Manufacturer (OEM) You may license products through an Original Equipment Manufacturer (OEM). These products, such as Windows operating systems, come installed when you purchase a new computer. OEM软件是给电脑生产厂的版本，无需多说。 Full Packaged Product (FPP)-Retail Physical, shrink-wrapped boxes of licensed product that can be purchased in a local retail store or any local software retailer. FPP就是零售版（盒装软件），这种产品的光盘的卷标都带有FPP字样，比如英文WXP Pro的FPP版本的光盘卷标就是WXPFPP_EN，其中WX表示是Windows XP，P是Professional（H是Home），FPP表明是零售版本，EN是表明是英语。获得途径除了在商店购买之外，某些MSDN用户也可以得到。 Volume Licensing for Organizations (VLO) You may enjoy potentially significant savings by acquiring multiple product licenses. Depending on the size and type of your organization. 团体批量许可证（大量采购授权合约），这是为团体购买而制定的一种优惠方式。这种产品的光盘的卷标都带有VOL字样，取Volume前3个字母，以表明是批量，比如英文WXP Pro的VOL版本的光盘卷标就是WXPVOL_EN，其中WX表示是Windows XP，P是Professional（VOL没有Home版本），VOL表明是团体批量许可证版本，EN是表明是英语。获得途径主要是集团购买，某些MSDN用户也可以得到。 这种版本根据购买数量等又细分为“开放式许可证”、“选择式许可证”、“企业协议”、“学术教育许可证”等以下5种版本 Open License Select License Enterprise Agreement Enterprise Subscription Agreement Academic Volume Licensing 由此可见，平时说的什么select/corp是许可证授权方式，他的出现是为了用若干种不同级别的优惠政策卖同一种软件，通过select/corp许可证授权方式得到的xxx的光盘都是VOL这一种、是并不是有很多种，只不过是相同的VOL光盘配以不同的许可证方式；而Volume Licensing (Product) Keys，即VLK，它所指的只是一个Key（密匙），仅仅是一个为证明产品合法化、以及安装所使用的Key，因为根据VOL计划规定，VOL产品是不需要激活的！ 或者说，VLK不是指一种版本，而是指这种版本在部署（deploy）过程中所需要的Key，而需要VLK这种Key的版本应该叫做VOL！只不过在实际中，没有必要强调这种叫法、称呼的准确性，加之很多人的VOL版本光盘是通过企业的选择式许可证、企业协议等方式得到的等等原因，所以才会有很多人叫他为“选择版”等等。 官方网站有一个表格，上面有一句话：“Different products require different Volume Licensing Keys (VLKs). Refer to the table below to make sure you have the correct VLK for your Microsoft product.”，我想这就很好的说明了VLK指的是Key而不是产品了。 很明显的，FPP需要激活，VOL不需要激活。20. 黑、白盒测试白盒测试和黑盒测试不是决然分开的，单独做黑盒测试或白盒测试都是做了测试的一个方面，很难保证发现了软件中大部分缺陷。在测试过程中往往把两者结合起来进行测试，从代码逻辑结构上保证正确，再从功能和非功能特性上保证正确，经过这两方面的测试，才能最大可能的保证软件质量。在测试过程中，采用这两种测试技术的时间有所不同。单元测试、集成测试、系统测试是按照测试的阶段来进行划分的，而白盒测试、黑盒测试是从测试技术的角度来划分的。一般来说，单元测试阶段进行的测试基本上以白盒测试技术为主，系统测试阶段进行的测试基本上以黑盒测试技术为主，而集成测试所采用的技术是介于白盒和黑盒之间的，有的技术文献也称之为灰盒技术软件测试是一个过程，一个完整的软件测试过程又分为三个阶段，分别是单元集成和系统（当然还有写别的测试过程），而黑盒和白盒只是在这些过程中所采用的测试方法罢了。 个人意见1. 黑盒测试黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测等，主要用于软件确认测试。“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。 2. 白盒测试白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。3. 灰盒测试灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。 灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。21Software Testing 10 Rules1. Test early and test often.尽早测试，经常测试2. Integrate the application development and testing life cycles. Youll get better results and you wont have to mediate between two armed camps in your IT shop.(这后半句怎么理解？)整合应用程序开发和软件测试生命周期，你将得到更好的结果，并且不必要在程序开发和软件测试两者之间左右为难。3. Formalize a testing methodology; youll test everything the same way and youll get uniform results.形成一套完整的测试方法；你将用同样的方法开展测试工作，并且可以得到始终如一的结果4. Develop a comprehensive test plan; it forms the basis for the testing methodology.开发一套完整、全面的的测试计划；作为软件测试方法论的基础部分5. Use both static and dynamic testing.采用静态测试和动态测试相结合的方法（可以采用静态代码检查工具作静态测试）6. Define your expected results.定义测试预期结果（在测试用例中，这是比不可少的项目)7. Understand the business reason behind the application. Youll write a better application and better testing scripts.理解应用背后的商业动机，找出真正的需求根源，你将写出更好的应用程序和测试脚本。8. Use multiple levels and types of testing (regression, systems, integration, stress and load).采用多层面和多类型的软件测试（回归测试、系统测试、集成测试、压力测试和负载测试）9. Review and inspect the work, it will lower costs.多工作评审和检视，可以降低成本（检视和评审可以提早发现问题，规避问题，避免造成不必要的损失，因此，可以降低成本）10. Dont let your programmers check their own work; theyll miss their own errors.不要让程序员检查自己的工作产品，程序员会忽略自己犯的错误。 博客园首页关于软件测试的一些基本知识作者：小寒来源：博客园发布时间：2008-06-02 15:35阅读：2780 次原文链接 收藏 软件测试方法：分为两类（1）静态测试：不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试（2）动态测试：通过输入一组预先按照一定的测试准则构造的实例数据动态运行程序，而达到发现程序错误的过程，特点如下：l 必须生成测试数据来运行被测试程序，取得程序运行的真实情况、动态情况，进而进行分析l 测试质量依赖于测试数据l 生成测试数据，分析测试结果的工作量大，使开展测试工作费时、费力、费人l 动态测试中涉及多方面工作，人员多，设备多，数据多，要求有较好的管理和工作规程一概述1 定义也称结构测试或逻辑驱动测试，按照程序内部的结构对程序进行测试，通过测试来检查产品内部动作是否按照设计规格说明书的规定正常进行，检查程序中的每条通路是否能按照预定要求正确工作2 测试内容把测试对象看成是一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序的所有逻辑路径进行测试，通过不同点检查程序的状态，确定实际的状态与预期的状态一致3 测试基本技术（1）词法分析与语法分析（2）静态错误分析（3）程序插桩技术4 测试方法（1）代码检查法（2）静态结构分析法（3）静态质量度量法（4）逻辑覆盖法（5）基本路径测试法（6）域测试（7）符号测试（8）Z路径覆盖（8） 程序变异5黑盒测试与白盒测试黑盒测试 白盒测试不涉及程序结构 考查程序逻辑结构用软件规格说明书生成测试用例 用程序结构信息生成测试用例可适用于从单元测试到系统联调 适用于单元测试和集成测试某些代码段得不到测试 对所有逻辑路径进行测试二白盒测试基本技术1词法和语法分析（1）获取信息l 可以获取软件组成的重要基本因数，如变量标识符、过程标识符、常量等l 组合获取的基本因数，可以得到软件的基本信息，如：v 标号交叉引用表：列出各模块中出现的全部标号及标号的属性，模块以外的全局、计算标号v 变量交叉引用表：列出变量定义及引用信息，变量的属性，变量类型（全局、局部）v 子程序、宏和函数表：列出各个子程序、宏及函数的属性，输入、输出参数信息v 等价表：列出在等价语句和等值语句中出现的全部变量和标号v 常数表：列出全部数字常数和字符常数（2）作用l 直接从表中查出说明/使用错误，如标号交叉引用表、变量交叉引用表l 为用户提供辅助信息，如子程序、宏和函数表、等价表、常数表l 用来做错误预测和程序复杂度计算，如操作符和操作数的统计表2静态错误分析用于确定在源程序中是否有某类错误或危险结构，包括以下几种：（1） 类型和单位分析对源程序的类型进行检查，为了强化检查效果，扩充一些新的数据类型，进行静态预处理程序，分析程序中的类型错误（2） 引用分析l 对程序中变量的引用进行检查，发现引用异常错误（如变量在定义前被引用，变量定义后未被引用）。l 采用深度优选的方法遍历程序流图的每一条路径l 建立引用异常的探测工具，包括变量定义表和变量引用表（3） 表达式分析对表达式进行分析，以发现和纠正在表达式出现的错误，如：l 在表达式中不正确的使用了括号造成错误l 数组下标越界错误l 除数为零l 浮点数计算的误差（最复杂）（4） 接口分析接口一致性是程序的静态错误分析和设计分析共同研究的题目，接口分析主要对下内容时进行一致性的分析：l 各模块之间接口一致性l 模块与外部数据库的接口一致性l 形参与实参在类型，数量，顺序，维数，使用上的一致性l 全局变量和公共数据区在使用上的一致性3程序插桩技术（1） 概述在动态测试中，是一种基本的测试手段，有广泛的应用主要借助向程序中插入操作，来实现测试目的的方法（即向源程序中添加一些语句（也称探测器），实现对程序语句的执行、变量的变化等情况进行检查）（2） 设计时考虑的问题l 明确要探测哪些信息l 在程序的什么部位设置探测点l 需要设计多少个探测点（3） 探测点设置位置（以Fortran为例）l 程序块的第一个可执行语句之前l entry语句的前后l 有标号的可执行语句处l 循环语句之后l 条件语句之后l logical if语句之后l call语句之后l go to语句之后（4） 断言语句在程序中的特定部位插入某些用以判断变量特性的语句，使得程序执行中这些语句得以证实，从而使程序的运行特性得到证实，我们把这些插入的语句称为断言语句。三白盒测试方法静态测试1 代码检查法（1） 目的通过桌面检查，代码审查和走查方式，对以下内容进行检查l 检查代码和设计的一致性l 代码对标准的遵循、可读性l 代码逻辑表达的正确性l 代码结构的合理性l 程序编写与编写标准的符合性l 程序中不安全、不明确和模糊的部分l 编程风格问题等（2） 代码检查方式方式名称 执行人员 检查内容 检查过程桌面检查 程序员 对源程序代码进行分析、检验，并补充相关的文档，发现程序中的错误代码审查 程序员和测试员组成的审查小组 通过阅读、讨论和争议，以程序进行静态分析的过程 第一步：小组成员提前阅读设计规格书、程序文本等相关文档第二步：召开程序审查会，开发人员读程序，审查小组讨论、发现、解决问题走查 程序员和测试员组成的审查小组 通过逻辑运行程序，发现问题 第一步：小组成员提前阅读设计规格书、程序文本等相关文档第二步：利用测试用例，使程序逻辑运行，记录程序的踪迹，发现、讨论、解决问题（3） 代码检查项目（采用分析技术）l 检查变量的交叉引用表：检查未说明的变量和违反了类型规定的变量，变量的引用和使用情况l 检查标号的交叉引用表：验证所有标号的正确性l 检查子程序、宏、函数：验证每次调用与所调用位置是否正确，调用的子程序、宏、函数是否存在，参数是否一致l 等价性检查：检查全部等价变量的类型的一致性l 常量检查：确认常量的取值和数制、数据类型l 标准检：检查程序中是否违反标准的问题l 风格检查：检查程序的设计风格l 比较控制流：比较设计控制流图和实际程序生成的控制流图的差异l 选择、激活路径：在设计控制流图中选择某条路径，到实际的程序中激活这条路径，如果不能激活，则程序可能有错l 对照程序的规格说明，详细阅读源代码，比较实际的代码，从差异中发现程序的问题和错误l 补充文档根据以上检查项目，可以编制代码规则，规范和检查表等作为测试用例（4） 编码规范程序编写过程中必须遵守的规则，规定代码的语法格式、语法规则，如排版、注释、标识符命名、可读性、变量、函数、过程、可测性、程序效率、质量保证、代码编辑、编译、审查、代码测试、维护、宏等各方面的编码要求（5） 代码检查规则对程序逻辑结构检查时，所规定的规则，形成（6） 缺陷检查表主要包括一些容易出错的地方和在以往工作中遇到的典型错误，形成表格形式重要性 审查项 结论文件结构 重要 头文件和定义文件的名称是否合理 2 静态结构分析法在静态结构分析中，测试者通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、内部文件调用关系图等各种图形图表，清晰地标识整个软件的组成结构，便于理解，通过分析这些图表，检查软件有没有存在缺陷或错误；包括控制流分析、数据据流分析、接口分析、表达式分析（1） 函数调用关系图：通过应用程序各函数之间的调用关系展示了系统的结构。列出所有函数，用连线表示调用关系，作用：l 可以检查函数的调用关系是否正确l 是否存在孤立的函数而没有被调用l 明确函数被调用的频繁度，对调用频繁的函数可以重点检查（2） 模块控制流图：由许多结点和连接结点的边组成的图形，其中每个结点代表一条或多条语句，边表示控制流向，可以直观地反映出一个函数的内部结构。*例子1GIS软件：存在无法执行的死代码；有多个出口，可能没有在所有出口进行内存释放与回收，有内存泄露的可能*例子2MIS软件：有多个出口，存在内存泄露的可能；有10逻辑判断结点，易出现逻辑错误，降低可靠性，可能会破坏对CPU操作进行优化的处理，影响其运行性能3 静态质量度量法（1） 软件质量：根据ISO/IEC9126 国际标准，包括以下六个方面：l 功能性（functionality）l 可靠性（reliability）l 可用性（usability）l 有效性（efficiency）l 可维护性（maintainability）l 轻便性（portability）（2） 质量度量模型（从上到下）l 质量因素（Factors）：与分类标准的计算方式相似，依据各分类标准取值组合权重方法来计算，依据结果将软件质量分为四个等级，与分类标准等级内容相同l 分类标准（criteria）：对某一软件质量分为不同的分类标准，每个分类标准由一系列度量规则组成，每个规则分配一个权重，每个分类标准的取值由规则的取值与权重值计算得出，依据结果将软件质量分为四个等级：v 优秀（excellent）：符合本模型框加中的所有规则（可以接受）v 良好（good）：未大量偏离模型框架中的规则（可以接受）v 一般（fair）：违背了模型框架中的大量规则（可以接受）v 较差（poor）：无法保障正常的软件可维护性（不可以接受）l 度量规则（Metrics）：使用代码行数、注释频度等参数度量软件各种行为属性四 白盒测试方法动态测试（即设计测试用例的方法）1 白盒测试的动态测试原则根据程序的控制结构设计测试用例（1） 保证每个模块的所有独立路径至少被使用一次（2） 对所有的逻辑值均测试true和false（3） 上下边界及可操作范围内运行所有循环（4） 检查内部数据结构以确保其有效性2 逻辑覆盖法（1） 概述 逻辑覆盖是通过对程序逻辑结构的遍历实现程序的覆盖（2） 分类依据覆盖源程序语句的详尽程度l 语句覆盖 SC（Statement Coverage）l 判定覆盖 DC（Decision coverage）l 条件覆盖 CC（Condition Coverage）l 条件判定组合覆盖 CDC（Condition/ Decision Coverage）l 多条件覆盖 MCC （Multiple Condition Coverage）l 修改条件判定覆盖 MCDC（Multiple Condition Decision Coverage）（3） 语句覆盖l 选择足够多的测试数据，使被测程序中每条语句至少执行一次l 缺点：对程序执行逻辑的覆盖很低（4） 判定覆盖l 设计足够多的测试用例，使得程序中的每一个判定至少获得一次真值和假值，或者使得程序中的每一个取真分支或取假分支至少经历一次，因此又称分支覆盖l 可以满足语句覆盖l 缺点：主要对整个表达式最终取值进行度量，忽略了表达式内部取值（5） 条件覆盖l 设计足够多的测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次l 不能够满足判定覆盖（6） 条件判定组合覆盖l 设计足够多的测试用例，使得判定中的每个条件的所有可能（真/假）至少出现一次，并且每个判定本身的判定结果也至少出现一次l 缺点：没有考虑单个判定对整体结果的影响，无法发现逻辑错误（7） 多条件覆盖l 也称条件组合覆盖，设计足够多的测试用例，使得每个判定中条件的各种可能组合都至少出现一次（以数轴形式划分区域，提取交集，建立最少的测试用例）l 满足条件覆盖一定满足判定覆盖、条件覆盖、条件判定组合覆盖l 缺点：判定语句较多时，条件组合值比较多（8） 修正条件判定覆盖l 每一个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次l 程序的判定被分解为通过逻辑操作符（and，or）连接的bool条件，每个条件对于判定的结果值是独立的练习1：采用多条件覆盖方法，对下程序进行白盒测试用例设计if (a 1 )&( b= = 0) x=x/a;if ( a = = 2)| (x 1 ) x=x+1;3 基本路径覆盖（1） 概述l 在程序控制流图的基础上，通过分析程序控制流图的环路复杂性，导出基本可执行路径的集合，然后据此设计测试用例l 设计出的测试用例要保证在测试中程序的每一条可执行语句至少执行一次（2） 程序控制流图l 控制流图是描述程序控制流的一种方式l 图形符号：圆圈代表一个结点 表示一个或多个无分支的语句或源程序语句l 边和点圈定的部分叫做区域。当对区域计数时，图形外的一个部分也应记为一个区域l 判断语句中的条件为复合条件时，即条件表达式由一个或多个逻辑运算符连接的逻辑表达式（a and b），则需要改变复合条件的判断为一系列只有单个条件的嵌套的判断 图形符号图所示（3） 程序环路复杂性l 程序的环路复杂性即McCabe复杂性度量，简单的定义为控制流图的区域数l 从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必须的测试用例数目的上界l 独立路径：包括一组以前没有处理的语句或条件的一条路径l 通常环路复杂性可用以下三种方法求得：v 将环路复杂性定义为控制流图中的区域数。v 设E为控制流图的边数，N为图的结点数，则定义环路复杂性为 V(G)EN2。v 若设P为控制流图中的判定结点数，则有 V(G)P1。（4） 基本路径测试步骤l 以详细设计或源代码为基础，导出程序的控制流图l 计算得到控制流图G的环路复杂性v(g)l 确定线性无关的路径的基本集l 生成测试用例，确保基本路径集中每条路径的执行五 其他白盒测试方法1 域测试（1） 概述是一种基于程序结构的测试方法，基于对程序输入空间（域）的分析，选择适的测试点进行测试（2） Howden错误分类相对于程序路径分类l 域错误：程序的控制流存在错误，对于某一特定的输入可能执行的是一条错误路径，这种错误称为路径错误，也叫做域错误l 计算型错误：对于特定输入执行的路径正确，但赋值语句的错误导致输出结果错误，称为计算型错误l 丢失路径错误：由于程序中的某处少了一个判定谓词而引起的（3） 测试理想结果：检验输入空间的每一个输入元素是否都产生正确的结果（4） 缺点l 为进行域测试对程序提出的限制过多l 当程序存在很多路径时，所需的测试点很多2 符号测试（1） 概述l 基本思想是允许程序的输入不仅仅是具体的数值数据，而且包括符号值，符号值可以是基本的符号变量值，也可以是符号变量值的表达式。l 符号测试执行的是代数运算，可以作为普通测试的一个扩充l 符号测试可以看作是程序测试和程序验证的一个折衷办法（2） 测试理想情况：程序中仅有有限的几条执行路径，如果都完成了符号测试，就可把握的确认程序的正确性了（3） 缺点l 分支问题l 二义性问题l 大程序问题3 Z路径覆盖（1） 概述对循环机制进行简化，减少路径的数量，使得覆盖所有路径成为可能，简化循环意义下的路径覆盖称为Z路径覆盖（2） 循环简化：限制循环次数，只考虑循环一次或零次情况4 程序变异（1） 概述是一种错误驱动测试错误驱动测试：指该方法是针对某类特定程序错误的