软件及硬件测试.docx
《软件及硬件测试.docx》由会员分享，可在线阅读，更多相关《软件及硬件测试.docx（9页珍藏版）》请在冰豆网上搜索。
软件及硬件测试
软件测试:
从是不是关切软件内部结构和具体实现的角度划分：
白盒测试，黑盒测试，灰盒测试。
从是不是执行程序的角度划分：
静态测试，动态测试。
从软件开发的进程按时期划分：
单元测试，集成测试，确认测试，系统测试，验收测试。
其他还有回归测试、冒烟测试、随机测试
其中黑盒测试包括功能测试和性能测试；
功能测试有：
逻辑功能测试、界面测试、易用性测试、安装测试、兼容测试；
性能测试有：
一般性能测试、稳定性测试、压力测试、负载测试
16种测试策略：
功能测试，性能测试，压力测试，容量测试，平安性测试，GUI测试，可用性测试，安装测试，配置测试，异样测试，备份测试，健壮性测试，文档测试，在线帮忙测试，网络测试，稳固性测试在：
正常情形下测试；非正常情形下测试；边界测试；非法，极端测试；
1.可移植性测试，英文是Portabilitytesting。
又称兼容性。
是指测试是不是能够被成功移植到指定的硬件或平台上
2.用户界面测试，英文是Userinterfacetesting。
又称UI测试。
是指测试用户界面的风格是不是知足客户要求，文字是不是正确，页面是不是美观，文字，图片组合是不是完美，操作是不是友好等等。
UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或阅读功能。
确保用户界面符合公司或行业的标准。
包括用户友好性、人性化、易操作性测试。
用户分析用户界面的设计是不是合乎用户期望或要求。
3.冒烟测试，英文是Smoketesting。
在测试中发觉问题，然后修复那个问题，想明白此问题是不是真的解决了。
4.随机测试，英文是Adhoctesting。
主若是对被测的一些重要功能进行复测，也包括测试那些当前的测试样例（TestCase）没有覆盖到的部份。
5.安装测试，英文是Installingtesting。
是确保在正常情形和异样情形下，例如，进行第一次安装、升级、完整的或自概念的安装都能进行安装的测试。
异样情形包括磁盘空间不足、缺少目录创建权限等场景。
核实在安装后可当即正常运行。
6.白盒测试，英文是WhiteBoxTesting。
又称结构测试或逻辑测试。
是把测试对象看做一个打开的盒子。
利用白盒测试法进行时，需要测试产品的内部结构和处置进程，不需测试软件产品的功能。
法的覆盖标准有、循环覆盖和大体。
其中包括、、、判定/条件覆盖、和。
是明白产品内部工作进程，可通过测试来检测产品内部动作是不是依照规格说明书的规定正常进行，依照程序内部的结构，查验程序中的每条通路是不是都有能按预定要求正确工作，而不顾它的功能，白盒测试的要紧方式有逻辑驱动、基路测试等，要紧用于验证。
经常使用工具有：
Jtest、VcSmith、Jcontract、C++Test、CodeWizard、logiscope
7.，英文是BlackBoxTesting。
又称或。
黑盒测试是依照的规格对软件进行的测试，这种测试不考虑软件内部的运作原理，因此软件对用户来讲就像一个黑盒子。
以用户的角度，通过各类输入和观看软件的各类输出结果来发觉软件存在的缺点，而不关切程序具体如何实现的一种软件测试方式。
经常使用工具有：
、winrunner
8.自动化测试，英文是AutomatedTesting。
利用自动化测试工具来进行测试，这种测试一样不需要人，通常在GUI、性能等测试和顶用得较多。
通过录制，然后执行那个测试脚本来实现的自动化。
国内领先的效劳提供商是泽众。
自动化测试工具有QTP、Testcomplete、和TAR等
9.回归测试，英文是Regressiontesting。
是指在发生修改以后从头测试先前的测试以保证修改的正确性。
理论上，产生新版本，都需要进行，验证以前发觉和修复的错误是不是在新软件版本上再次显现。
依照修复好了的缺点再从头进行测试。
的目的在于验证以前显现过但已经修复好的缺点再也不从头显现。
一样指对某已知修正的缺点再次围绕它原先显现时的步骤从头测试。
通常确信所需的再测试的范围时是比较困难的，专门当临近产品发布日期时。
因为为了修正某缺点时必需更改，因此就有可能阻碍这部份源代码所操纵的功能。
因此在验证修好的缺点时不仅要服从缺点原先显现时的步骤从头测试，而且还要测试有可能受阻碍的所有功能。
因此应当鼓舞对所有回归测试用例进行（指修改了旧代码后，从头进行测试以确认修改没有引入新的错误或致使其他代码产生错误）
10.验收测试，英文是Acceptancetesting。
验收测试是指方式论的一个时期，这时相关的用户或独立测试人员依照和结果对系统进行测试和接收。
它让决定是不是接收系统。
它是一项确信产品是不是能够知足合同或用户所规定需求的测试。
一样有三种策略：
正式验收、非正式验收或Alpha测试、Beta测试。
11.单元测试，英文是UnitTesting。
是最微小规模的测试;以测试某个功能或代码块。
典型地由而非测试员来做，因为它需要明白内部和编码的细节知识。
那个工作不容易做好，除非应用系统有一个设计专门好的;还可能需要开发测试驱动器模块或测试套具。
12.集成测试，英文是IntegrationTesting。
是指一个应用系统的各个部件的联合测试，以决定他们可否在一路一起工作并无冲突。
部件能够是代码块、独立的应用、网络上的或效劳器端程序。
这种类型的测试尤其与客户效劳器和有关。
一样以前，需要完成。
是的逻辑扩展。
它的最简单的形式是：
两个已经测试过的单元组合成一个组件，而且测试它们之间的接口。
从这一层意义上讲，组件是指多个单元的集成聚合。
在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部份。
方式是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一路测试。
最后，将组成进程的所有模块一路测试。
另外，若是程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。
识别组合单元时显现的问题。
通过利用要求在组合单元前测试每一个单元，并确保每一个单元的生存能力的，能够明白在组合单元时所发觉的任何错误极可能与单元之间的接口有关。
这种方式将可能发生的情形数量减少到更简单的分析级别
13.系统测试，英文是SystemTesting。
系统测试是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。
是针对整个产品系统进行的测试，目的是验证系统是不是知足了需求规格的概念，找出与需求规格不相符合或与之矛盾的地址。
的对象不单单包括需要测试的产品系统的，还要包括软件所依托的硬件、外设乃至包括某些数据、某些支持软件及其接口等。
因此，必需将系统中的与各类依托的资源结合起来，在系统实际运行环境下来进行测试。
14.端到端测试，英文是EndtoEndTesting。
端到端测试类似于，测试级的“宏大”的端点，涉及整个应用系统环境在一个现实世界利历时的模拟情形的所有测试。
例如与数据库对话，用网络通信，或与外部硬件、应用系统或适当的系统对话。
端到端架构测试包括所有访问点的及。
端到端架构测试实质上是一种"灰盒"测试，一种集合了和的优势的测试方式。
15.测试，英文是UninstallTesting。
测试是对的全数、部份或升级处置进程的测试。
主若是测试可否卸载，卸载是不是干净，对系统有无更改，在系统中的残留与后来的生成文件如何处置等。
还有原先更改的系统值是不是修改归去
16.同意测试，英文是AcceptTesting。
同意测试是基于客户或最终用户的规格书的最终测试，或基于用户一段时刻的利用后，看是不是知足客户要求。
一样从功能、用户界面、性能、业务关联性进行测试。
17.性能测试，英文是PerformanceTesting。
是在交替进行负荷和时经常使用的术语。
理想的“”（和其他类型的测试）应在需求文档或质量保证、中概念。
一样包括和压力测试。
通常验证的性能在正常环境和系统条件下重复利用是不是还能知足性能指标。
或执行一样任务时新版本不比旧版本慢。
一样还检查系统经历容量在运行程序时会可不能显现内存泄露（memoryleak）。
比如，验证程序保留一个庞大的文件新版本不比旧版本慢。
健全测试，英文是Sanitytesting。
是指一个初始化的测试工作，以决定一个新的版本测试是不是足以执行下一步大的测试能力。
例如，若是一个新版每5分钟与系统冲突，使系统陷于泥潭，说明该软件不够“健全”，不具有进一步测试的条件。
衰竭测试，英文是FailureTesting。
衰竭测试是指或环境的修复或更正后的“再测试”。
可能很难确信需要多少遍再次测试。
尤其在接近开发周期终止时。
自动测试工具对这种测试尤其有效。
负载测试，英文是Loadtesting。
是测试一个应用在重负荷下的表现。
例如测试一个Web站点在大量的负荷下，何时系统的响应会退化或失败，以发觉设计上的错误或验证系统的负载能力。
在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，和持续正常运行的能力。
（是指让被测系统在其能忍受的压力的极限范围之内持续运行，来测试系统的稳固性。
）
的目标是确信并确保系统在超出最大预期工作量的情形下仍能正常运行。
另外，还要评估性能特点，例如，响应时刻、事务处置速度和其他与时刻相关的方面。
强迫测试，英文是ForceTesting。
是在交替进行负荷和时经常使用的术语。
也用于描述对象在异乎寻常的下的系统功能测试之类的测试，如某个动作或输入大量的重复，大量数据的输入，对一个大量的复杂查询等。
压力测试，英文是StressTesting。
和差不多。
压力测试是一种大体的质量保证行为，它是每一个重要测试工作的一部份。
压力测试的大体思路很简单：
不是在常规条件下运行手动或自动测试，而是在运算机数量较少或系统资源匮乏的条件下运行测试。
通常要进行压力测试的资源包括内部内存、CPU可用性、磁盘空间和网络带宽等。
一样用并发来做压力测试。
（是指持续不断的给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能经受的最大压力。
）
恢复测试，英文是Recoverytesting。
是测试一个系统从如下灾难中可否专门好地恢复，如碰到、硬件损坏或其他灾难性问题。
指通过人为的让（或硬件）显现故障来检测系统是不是能正确的恢复，通常关注恢复所需的时刻和恢复的程度。
要紧检查系统的容错能力。
当系统犯错时，可否在指按时刻距离内修正错误并从头启动系统。
第一要采纳各类方法强迫系统失败，然后验证系统是不是能尽快恢复。
关于需验证从头初始化（reinitialization）、检查点（checkpointingmechanisms）、（datarecovery）和从头启动（restart）等机制的正确性；关于人工干与的恢复系统，还需估测，确信其是不是在可同意的范围内。
18.平安测试，英文是SecurityTesting。
是测试系统在避免非授权的内部或外部用户的访问或故意破坏等情形时怎么样。
这可能需要复杂的测试技术。
检查系统对非法侵入的防范能力。
期间，测试人员假扮非法入侵者，采纳各类方法试图冲破防线。
例如：
①想方设法截取或破译口令；
②专门定做破坏系统的爱惜机制；
③故意致使系统失败，企图趁恢复之机非法进入；
④试图通过阅读非保密数据，推导所需信息，等等。
理论上讲，只要有足够的时刻和资源，没有不可进入的系统。
因此系统平安设计的准那么是，使非法侵入的代价超过被爱惜信息的价值。
现在非法侵入者已无利可图。
19.，英文是CompatibilityTesting。
是测试在一个特定的硬件/软件//网络等环境下的性能如何。
向上兼容向下兼容，硬件兼容。
的兼容性有很多需要考虑的地址
20.可用性测试，英文是PracticalUsabilityTesting。
可用性测试是对“用户友好性”的测试。
显然这是主观的，且将取决于目标最终用户或客户。
用户面谈、调查、用户对话的录象和其他一些技术都可利用。
程序员和测试员通常都不宜作可用性测试员。
21.比较测试，英文是CompareTesting。
比较测试是指与竞争伙伴的产品的比较测试，如的弱点、优势或实力。
来扬长避短，以增强产品的竞争力。
22.可同意性测试，英文是AcceptabilityTesting。
可同意性测试是在把测试的版本交付测试部门大范围测试以前进行的对最大体功能的简单测试。
因为在把测试的版本交付测试部门大范围测试以前应该先验证该版本关于所测试的功能大体上比较稳固。
必需知足一些最低要求。
比如可不能很容易程序就挂起或崩溃。
若是一个新版本没通过的验证，就应该阻拦测试部门花时刻在该测试版本上测试。
同时还要找到造成该版本不稳固的要紧缺点并催促尽快加以修正
23.，英文是BoudaryTesting。
又称。
一种方式，适度等价类分析方式的一种补充,由长期的测试工作体会得知，大量的错误是发生在输入或输出的边界上。
因此针对各类边界情形设计，能够查出更多的错误。
是围绕边界值的测试。
通常意味着测试各功能是不是能正确处置最大值，最小值或所设计软件能够处置的最长的字符串等等。
24.强力测试，英文是MightinessTesting。
强力测试通常验证软件的性能在各类极端的环境和系统条件下是不是还能正常工作。
或说是验证的性能在各类极端环境和系统条件下的经受能力。
比如，在最低的硬盘驱动器空间或系统经历容量条件下，验证程序重复执行打开和保留一个庞大的文件1000次后也可不能崩溃或
25.装配/安装/配置测试是验证程序在不同厂家的硬件上，所支持的不同语言的新旧版本平台上，和不同方式安装的软件都能够如预期的那样正确运行。
比如，把英文版的MicrosoftOffice2003安装在韩文版的WindowsMe上，再验证所有功能都正常运行。
26.隐藏数据测试在验收和确认时期是十分必要和重要的一部份。
程序的质量不单单通过用户界面的可视化数据来验证，而且必需包括遍历系统的所有数据。
假设一个要求用户两条信息-----用户名和密码来创建帐户。
那个用户输入这两条数据后保留。
最后，一个确认窗口将通过数据库中找到这条数据来显示用户名和密码给用户。
为了验证所有的数据保留是不是正确，一个QA测试人员会在那个确认窗口简单的查看下用户名和密码。
若是他们成功了？
假设数据库记录了第三条信息----创建日期，它可能可不能出此刻确认窗口，而只在存档中才显现。
若是创建日期保留的不正确，而QA测试人员只验证屏幕上的数据，那么那个问题就不可能被发觉。
创建日期可能确实是一个bug，由于一个保留了一个错误的日期到数据库中，那个问题也不可能会被引发注意，因为它被用户界面所隐藏。
这只是一个简单的例子，可是它却演化出了一点：
隐藏的重要性。
27.等价划分测试的英文是equivalencepartitiontesting。
等价划分测试是依照等价类设计的一种技术。
是的典型方式之一，通过把被所有可能的输入数据域划分成假设干部份。
从每一部份当选取少数有代表性的数据作为，可有效减少测试次数，极大提高测试效率，缩短软件开发周期．等价类划分测试的目的确实是为了在有限的测试资源的情形下，用少量有代表性的数据取得比较好的测试成效。
有效等价类和。
有效等价类中的数据代表的是一组符合需求文档的正确的成心义数据。
那么正相反。
28.判定表的英文是decisiontable，是指一个表格，用于显示条件和条件致使动作的集合。
概念：
是分析和表达多逻辑条件下执行不同操作的情形的工具。
的优势：
能够将复杂的问题依照各类可能的情形全数列举出来，简明并幸免遗漏。
因此，利用能够设计出完整的集合。
在一些问题当中，某些操作的实施依托于多个逻辑条件的组合，即：
针对不同逻辑条件的组合值，别离执行不同的操作。
判定表很适合于处置这种问题
29.深度测试的英文Depthtest，是指执行一个产品的一个特性的所有细节，但意外试所有特性。
当比较函数返回真的时候才显示出成效来。
必需启用“#深度测试”，才能执行测试。
不利用的时候需要关闭。
30.基于设计的测试的英文是design-basedtesting，是依照的构架或引出的一种方式。
一种基于设计模型的测试方式（ModelBasedTestIngSystem,MATIS）.该方式利用用户界面自动生成方式,把设计模型中的类属性概念和实现中的控件属性组织在一路,构建描述界面的逻辑对照表,辅助引擎执行自动测试脚本.借助设计模型中扩展的类概念,MATIS方式能够自动生成和测试数据。
31.文档测试的英文是documentationtesting，测试关注于文档的正确性。
有三大类别离是开发文件、用户文件、治理文件。
1.开发文件：
可行性研究报告、、数据要求说明书、、、说明书、模块开发卷宗。
2.用户文件：
用户手册、操作手册。
3.治理文件：
项目开发打算、、测试分析报告、开发进度月报、项目开发总结报告。
测试中的主若是对相关的设计报告和用户利用说明进行测试，关于设计报告主若是与设计报告中的设计思想是不是一致；关于用户利用说明进行测试时，主若是测试用户利用说明书中对程序操作方式的描述是不是正确，重点是用户利用说明中提到的操作例子要进行测试，保证采纳的例子能够在程序中正确完成操作。
一样来识,文档是的重要组成部份,因此也是软件测试的要紧内容。
在的整个生命周期中会显现很多文档,通常能够把文档粗略地分为三类:
开发文档,治理文档和。
由于文档与代码不同,不能直接运行,关于文档的测试通常只能以文档审查的方式进行。
关于治理文档和审查通常归属于治理范围,而不是测试范围,因为关于治理文档审查的目的不是为了发觉和排除用户所看到的软件中的缺点,而是为了更好地治理软件开发的进程。
关于开发文档,由于这些文档本躯表现了所在开发时期的实际形态,关于这些文档的测试事实上是初期软件测试的要紧活动。
是那些随程序一路交付给用户的文档,它们事实上是交付给用户的的重要组成部份。
关于这些文档的测试是对最终的一部份。
32.域测试的英文是domaintesting，概念参考等价划分测试（equivalencepartitiontesting）；
一样分为单和多域测试，其中单域测试包括设备测试和业务测试，设备测试包括测试某个系统的设备、中继媒体网关设备、设备、接入媒体网关和IAD等设备。
等价类划分有两种不同的情形：
有效等价类和。
设计时要同时考虑这两种等价类，因为不仅要能接收合理的数据，也要能经受意外的考验。
一有效等价类：
是指关于程序的规格说明来讲是合理的、成心义的输入数据组成的集合。
利用有效等价类可查验程序是不是实现了规格说明中所规定的功能和性能。
二：
与有效等价类的概念刚巧相反。
33.接口测试的英文是interfacetesting，接口测试测试系统组件间接口的一种测试。
的益处：
由于代码本身确实是用（固然接口的类型不同，不必然是Junit来实现）来实现的，是属于的范围，因此必然也包括自动化测试所固有的优势。
1）提高测试质量
的进程是一个和改良的进程，而每一次的改良都可能引进新bug,因此当软件的一部，或全数修改时，都需要对软件产品从头进行测试。
其目的是要验证修改后的产品是符合需求的，而当没有代码时，往往会由于各类各样的缘故，回归不充分，致使bug遗漏。
2）提高测试效率
的规模愈来愈大，功能点愈来愈多，开发人员的自测或测试人员的人工测试超级耗时和繁琐，必将致使测试效率的低下，而正好解决这些耗时繁琐的任务，在对外接口功能不变的情形下，达到了一次编写，永久利用的成效。
3）提高
通过很难测试到一些更深层次的异样和平安的问题，通过一些辅助的一些测试工具，能分析出代码的覆盖率，通过覆盖率的提高来提高测试的深度。
4）更好地重现
由于每次执行都是相同的代码，一旦代码犯错，必然回归犯错
5）更好定位错误
由于是一种自下向上的测试，因此一量犯错，超级容易定位犯错，不向那样了，一旦有Bug，需要几层验证以后才能确信犯错位置
6）降低修改bug的本钱大体和开发人员的编码平行工作，因此发觉问题会比早很多，因此减少了修改bug的本钱。
7）增进测试人员和开发人员之间的合作关系，为了更好地开展工作，需要对开发技术有深切的明白得和实践，有了与开发工程师更多的交流。
8）降低了项目不能按时发布的风险由于很早就介入，在提交给前对项目代码的核心模块已经做了详尽的测试，必然加速系统测试的时刻，由此来保证项目的按时发布。
9）提升测试人员的技术。
做必需了解开发人员的开发流程和一些开发技术，也需要了解测试工具的一些利用方式和一些测试思想，提升了测试人员的技术附加值，提高了自身的竞争力。
10）促使项目开发进程的标准化
要进行接口，需要完善的文档进行保障，没有测试文档，将步履维艰，接口测试将增加开发进程标准化产出，而标准化产出也保证了项目质量。
34.逆向测试/反向测试/的英文是NegativeTesting，测试对准于使系统不能工作。
与正面测试的比较：
（Negativetesting）是相关于正面测试（Positivetesting）而言的。
它们也是测试设计时的两个超级重要的划分。
简单点说，正面测试确实是测试系统是不是完成了它应该完成的工作；而确实是测试系统是不是不执行它不该该完成的操作。
形象一点，正面测试就象一个毕恭毕敬的小学生，教师叫我做什么，我就做什么；而就象一个顽皮捣蛋的小孩，你叫我如此做，我偏不如此做，而且和你对着干。
开发人员也是最讨厌修改此类bug的。
35.非功能性需求测试的英文是non-functionalrequirementstesting，是与功能不相关的需求测试，如：
、可用性测试等。
什么缘故非功能性需求很重要？
在您设计解决方案的进程中知足功能性需求固然是很重要的。
可是，若是没有考虑非功能性需求，您的解决方案那么很难取得实效。
非功能性需求特点：
1.不要离开实际环境；2.靠得住性；3.可用性；4.有效性；5.可保护性；6.可移植性。
升级会员 