软件与硬件测试

温柔似野鬼°
618次浏览
2021年02月21日 09:07
最佳经验
本文由作者推荐

-

2021年2月21日发(作者:zhanlang)


软件测试


:


从是否关心软件内部结构和具体实现的角度划分:



白盒测试,黑盒测试,灰盒测试。




从是否执行程序的角度划分:




静态测试,动态测试。




从软件开发的过程按阶段划分:



单元测试,集成测试,确认测试,系统测试,验收测试。




其他还有回归测试、冒烟测试、随机测试



其中黑盒测试包括功能测试和性能测试;


功能测试有:逻辑功能测试、界面测试、易用性测试、安装测试、兼容测试;



性能测试有:一般性能测试、稳定性测试、压力测试、负载测试




16


种测试策略:


< br>功能测试,性能测试,压力测试,容量测试,安全性测试,


GUI


测


试,可用性测试,安装测试,配置测试,



异常测试,备份测试,健壮性测试,文档测试,


在线帮助测试,网络测试 ,稳定性测试



在:正常情况下测试;非正常情况下测试;边界 测


试;非法,极端测试;




1.



可移植性测试,英文是


Portability


testing


。又称兼容性


测试

< br>。


可移植性测试


是指测试


软


件


是否可以被成功移植到指定的硬件或


软件


平台上



2.



用户界面测试,英文是


User interface tes ting


。又称


UI


测试。

< p>
用户界面测试


是指测试


用户界面的风格是否满足客 户要求,文字是否正确,页面是否美观,文字,


图片组合是否完美,

操作是否友好等等。


UI


测试的目标是确保用户界面会通


过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合


公司或行业的标准。包括用户友好性、人性化、易操作性测试。


用户界面测试


用户分析


软件


用户界面的设计是否合乎 用户期望或要求。



3.



冒烟测试,英文是


Smoke testing


。在测试中发现问题,然后修复这个问题,想知道此问


题是否真的解决了。



4.



随机测试,


英文是


Ad hoc te sting


。


随机测试


主要是对被测< /p>


软件


的一些重要功能进行复测,


也包括测 试那些当前的测试样例


(TestCase)


没有覆盖到的部分 。



5.



安 装测试,


英文是


Installing


testing


。


安装测试


是确保< /p>


软件


在正常情况和异常情况下,


例如,进 行首次安装、升级、完整的或自定义的安装都能进行安装的测试。异常情况包


括磁盘空间 不足、缺少目录创建权限等场景。核实


软件


在安装后可立即正常 运行。



6.


白盒测试,英文是


White Box Testing


。又称结构测试或者逻辑


驱动


测试。



白盒测试


是把测试对象看作一个打开的盒子 。


利用白盒测试法进行


动态测试


时,< /p>


需要测试


软


件


产 品的内部结构和处理过程,不需测试软件产品的功能。



白盒测 试


法的覆盖标准有


逻辑覆盖


、


循环覆盖和基本


路径测试


。

其中


逻辑覆盖


包括


语句覆盖


、


判定覆盖


、


条件覆 盖


、判定


/


条件覆盖、


条件组合覆盖


和


路径覆盖


。< /p>



白盒测试


是知道产品内部工作过程,< /p>


可通过测试来检测产品内部动作是否按照规格说明书的


规定正常进 行,


按照程序内部的结构


测试程序


,< /p>


检验程序中的每条通路是否都有能按预定要


求正确工作,而不顾它 的功能,


白盒测试的主要方法有逻辑驱动、


基路测试等,主要用 于


软


件


验证。



白盒测试


常用工具有:


Jtest


、


VcSmith


、


Jcontract


、


C++ Test

、


CodeWizard


、


log iscope


7.


黑盒测试


,英文是


Black Box Testing


。又称


功能测试


或者< /p>


数据驱动测试


。



黑盒测试是根据


软件


的规格对软件进行的测试,


这类测试不考虑软件内部的运作原理,


因此


软件对用 户来说就像一个黑盒子。



软件测试人员


以用户的角度,


通过各种输入和观察软件的各种输出结果来发现软件存在的缺


陷,而不关心程序具体如何实现的一种软件测试方法。



黑盒测试


常用工具有:


AutoRunner


、


winrunner


8.


自动化测试,英文是


Automated Testing


。使用自动化测试工具来进行测试,这类测试


一般不需要人


干预


,通常在


GUI


、 性能等测试和


功能测试


中用得较多。通过录制

< br>测试脚本


,


然后执行这个测试脚本来实现


测试过程


的自动化。


国内领先的


自动化测试


服务提供商是泽众


软件


。 自动化测试工具有


QTP


、


Testc omplete


、


AutoRunner


和


TAR


等



9.


回归测试,英文是


Regression testing


。



回归测试


是指在发生修改之后重新测试先前的测试以保证修改的正确性。


理论上,


软件


产生


新版本,都需要进行


回归测试


,验证以前发现和修复的错误是否在新软件版本上再次出现。< /p>



根据修复好了的缺陷再重新进行测试。


回归测试


的目的在于验证以前出现过但已经修复好的


缺陷不再重 新出现。


一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。

< p>
通


常确定所需的再测试的范围时是比较困难的,


特 别当临近产品发布日期时。


因为为了修正某


缺陷时必需更改


源代码


,


因而就有可能影响这部分源代码所 控制的功能。


所以在验证修好的


缺陷时不仅要服从缺陷原来出现 时的步骤重新测试,而且还要测试有可能受影响的所有功


能。


因 此应当鼓励对所有回归测试用例进行


自动化测试


(指修改了旧代 码后,


重新进行测试


以确认修改没有引入新的错误或导致其他代 码产生错误)



10.


验收测试,英文是


Acceptance testing


。



验收测试是指


系统开发生命周期


方法论的一个阶段,


这时 相关的用户或独立测试人员根据


测


试计划


和结果对系统进行测试和接收。


它让


系统用户


决定是否接收系统。


它是一项确定产品


是否能够满足合 同或用户所规定需求的测试。



验收测试


一般有三种策略:正式验收、非正式验收或


Alpha


测试、


Beta


测试。



11.



单元测试,英文是


Unit Testing


。



单元测试


是最微小规模的测试


;


以测试某个功能或代码块 。


典型地由


程序员


而非测试员来做,< /p>


因为它需要知道内部


程序设计


和编码的细 节知识。


这个工作不容易做好,


除非应用系统有一


个设计很好的


体系结构


;


还可能需要开发测试驱动器模块或测试套具。



12.


集成测试,英文是


Integration Testing


。



集成测试


是指一个应用系统的各个部件的联合测试,


以决定他们能否在一起共同工 作并没有


冲突。


部件可以是代码块、独立的应用、


网络上的


客户端


或服务器端程序。

< br>这种类型的测试


尤其与客户服务器和


分布式系统


有关。一般


集成测试


以前,

单元测试


需要完成。



集成测试< /p>


是


单元测试


的逻辑扩展。


它的最简单的形式是:


两个已经测试过的单元组合成一个


组件,


并且测试它们之间的接口。从这一层意义上讲,组件是指多个单元的集成聚合。


在现


实方案中,


许多单元组合成组件,


而这些组件又聚合成程序的更大部分。


方法是测试片段的


组合,


并最终扩展进程,


将您的模块与其他组 的模块一起测试。最后,


将构成进程的所有模


块一起测试。此外 ,


如果程序由多个进程组成,应该成对测试它们,而不是同时测试所有进


程。



集成测试


识别组合单元 时出现的问题。


通过使用要求在组合单元前测试每个单元,


并确 保每


个单元的生存能力的


测试计划


,< /p>


可以知道在组合单元时所发现的任何错误很可能与单元之间


的接口 有关。这种方法将可能发生的情况数量减少到更简单的分析级别



13.


系统测试,英文是


System Testing


。



系统测试是基于系 统整体需求说明书的黑盒类测试,


应覆盖系统所有联合的部件。


系统测试


是针对整个产品系统进行的测试,


目的是验证系统是否 满足了需求规格的定义,


找出与需求


规格不相符合或与之矛盾的 地方。



系统测试


的对象不仅仅包括需 要测试的产品系统的


软件


,


还要包含软 件所依赖的硬件、


外设


甚至包括某些数据、

某些支持软件及其接口等。


因此,


必须将系统中的


软件


与各种依赖的资


源结合起来,在系统实际运 行环境下来进行测试。



14.


端到端测试,英文是


End to End Testing


。



端到端测试类似于


系统测试


,


测试级的“宏大”的端点,


涉及整个应用系统环境在一个现实


世界使用时的模拟情形的所有 测试。


例如与数据库对话,


用网络通讯,


或与外部硬件、


应用


系统或适当的系统对话。


端到端架构测试包含所有访问点的


功能测试


及


性能测试


。


端到端架


构 测试实质上是一种



灰盒



测试,一种集合了


白盒测试


和


黑盒测试


的优点的测试方法。



15.


卸载


测试,英文是


Uninstall Testing


。



卸载


测试是对


软件


的全部、


部分 或升级


卸载


处理过程的测试。


主要是测 试


软件


能否卸载,


卸

< br>载是否干净,


对系统有无更改,


在系统中的残留与后来的 生成文件如何处理等。


还有原来更


改的系统值是否修改回去



16.


接受测试,英文是


Accept Testing


。



接受测试是基于客 户或最终用户的规格书的最终测试,


或基于用户一段时间的使用后,

看


软


件


是否满足客户要求。一般从 功能、用户界面、性能、业务关联性进行测试。



17.


性能测试,英文是


Performance Testing


。



性能测试


是在交替进行负荷和


强迫测试


时常用的术语。理 想的“


性能测试


”(和其他类型的


测试


)


应在需求文档或质量保证、


测试计划


中定义。


性能测试


一般包括

< p>
负载测试


和压力测试。



通常验证


软件


的性能在正常环境和系统条件下重复使用是否还能 满足性能指标。


或者执行同


样任务时新版本不比旧版本慢。


一般还检查系统记忆容量在运行程序时会不会出现内存泄露


(mem ory leak)


。比如,验证程序保存一个巨大的文件新版本不比旧版本慢。



17.1


健全测试,英文是


Sanity testing


。



健全测试


是指一个初始化的测试工作,


以决定一个新的


软 件


版本测试是否足以执行下一步大


的测试能力。例如,


如果一个新版


软件


每


5


分钟与系统冲突,


使系统陷于泥潭,说明该软件


不够“健全”,不具备进一步测试的条件。



17.2


衰竭测试,英文是


Failure Testing


。



衰竭测试是指


软件


或环境的修复或更正后的“再测试”。可能很难确定需要多少遍 再次测


试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。

< p>


17.3


负载测试,英文是


Load testing


。



负载测试


是测试一个应用在重负荷下的表现。例如测试一个


Web

< p>
站点在大量的负荷下,何


时系统的响应会退化或失败,以发现设计上的错误 或验证系统的负载能力。在这种测试中,


将使测试对象承担不同的工作量,以评测和评估 测试对象在不同工作量条件下的性能行为,


以及持续正常运行的能力。(


是指让被测系统在其能忍受的压力的极限范围之内连续运行,


来测试系统的稳定 性。


)



负载测试

的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。


此外,


负


载测试


还要评估性能特征,例如,响应时 间、事务处理速率和其他与时间相关的方面。



17.4


强迫测试,英文是


Force Testing


。



强迫测试


是在交替进行负荷和


性能测试


时常用的术语。< /p>


也用于描述对象在异乎寻常的


重载


下


的系统功能测试之类的测试,


如某个动作或输入大量的重复,


大量数据的输入,


对一个


数据


库系统


大量的复杂查询等。



17.5


压力测试,英文是


Stress Testing


。和


负载测试


差不多。


< /p>


压力测试是一种基本的质量保证行为,


它是每个重要


软件


测试工作的一部分。


压力测试的基


本思路很简单:


不是在常规条件下运行手动或自动测试,

而是在计算机数量较少或系统资源


匮乏的条件下运行测试。


通常要进行压力测试的资源包括内部内存、


CPU


可用性、< /p>


磁盘空间


和网络带宽等。


一般用并发来做 压力测试。


(


是指持续不断的给被测系统增加压力,直到将


被测系统压垮为止,用来测试系统所能承受的最大压力。


)



17.6


恢复测试,英文是


Recovery testing


。



恢复测试


是测试一个系统从如下灾难中能否很好地恢复,


如遇到

< br>系统崩溃


、


硬件损坏或其他


灾难 性问题。


恢复测试


指通过人为的让


软件


(或者硬件)


出现故障来检测系统是否能正确的


恢复,通常关注恢复所需的时间以及恢复的程度。



恢 复测试


主要检查系统的容错能力。


当系统出错时,


能否在指定时间间隔内修正错误并重新


启动系统。


恢 复测试


首先要采用各种办法强迫系统失败,


然后验证系统是否能 尽快恢复。


对


于


自动恢复


需验证重新初始化


(


reinitializati on


)


、


检查点


(checkpointing


mechanisms)


、


数据恢复


(data recovery)


和重新启动


(restart)


等机制的正确性;对于人工干预的恢复系


统,还需估测

< br>平均修复时间


,确定其是否在可接受的范围内。



18.



安全测试,英文是


Security Testing


。



安全测试


是测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。

< br>这


可能需要复杂的测试技术。


安全测试

< br>检查系统对非法侵入的防范能力。


安全测试


期间,


测试


人员假扮非法入侵者,采用各种办法试图突破防线。例如:



①想方设法截取或破译口令;


< p>
②专门定做


软件


破坏系统的保护机制;

< p>


③故意导致系统失败,企图趁恢复之机非法进入;


< p>
④试图通过浏览非保密数据,推导所需信息,等等。理论上讲,只要有足够的时间和资源,


没有不可进入的系统。


因此系统安全设计的准则是,

使非法侵入的代价超过被保护信息的价


值。此时非法侵入者已无利可图。

< p>


19.


兼容测试


,英 文是


Compatibility Testing


。



兼容测试


是测试


软件


在一个特定的硬件

< br>/


软件


/


操作系统


/


网络等环境下的性能如何。向上兼


容向下兼容,< /p>


软件兼容


硬件兼容。


软件


的兼容性有很多需要考虑的地方



20.


可用性测试,英文是


Practical Usability Testing


。



可用性测试是对“ 用户友好性”的测试。


显然这是主观的,


且将取决于目标最终用 户或客户。


用户面谈、


调查、


用户对话 的录象和其他一些技术都可使用。


程序员和测试员通常都不宜作


可用性测试员。



21.


比较测试,英文是


Compare Testing


。



比较测试是指与竞 争伙伴的产品的比较测试,


如


软件


的弱 点、


优点或实力。


来取长补短,以


增强 产品的竞争力。



22.


可接受性测试,英文是


Acceptability Testing


。



可接受性测试是在 把测试的版本交付测试部门大范围测试以前进行的对最基本功能的简单


测试。

< p>
因为在把测试的版本交付测试部门大范围测试以前应该先验证该版本对于所测试的功


能基本上比较稳定。


必须满足一些最低要求。


比如不会 很容易程序就挂起或崩溃。


如果一个


新版本没通过


可测试性


的验证,


就应该阻拦测试部门花时间在该测 试版本上测试。


同时还要


找到造成该版本不稳定的主要缺陷并督 促尽快加以修正



23.


边界条件测试


,英文是


Boudary Testing


。又称


边界值测试


。< /p>



一种


黑盒测试


方法,适度等价类分析方法的一种补充


,


由长期的测试工作经验 得知,大量的


错误是发生在输入或输出的边界上。


因此针对各种 边界情况设计


测试用例


,


可以查出更多 的


错误。


-


-


-


-


-


-


-


-