您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 其他相关 > 正文

测试方法的辩证统一

发表于:2018-06-05 作者: 朱 少民 来源:质量屋
软件测试的众多方法是辩证统一的,它们相互依赖而存在,相互对立又相互补充,任何一种测试方法都有其优点,在特定的测试领域能得到充分发挥。同时,任何一种测试方法都不能覆盖所有测试的需求,在某些场合存在一定的局限性和不足。这种测试的辩证统一,从下面这些相对应的测试方法就得到很好的印证。
·         白盒测试方法和黑盒测试方法
·         静态测试 (static test) 和 动态测试( Dynamic test)
·         手工测试(Manual test)和自动化测试(Automated Test)
·         有计划测试(Planned Test)和随机测试(Ad-hoc test 或Random test)
·         新功能测试(new feature test)和回归测试 (Regression testing)
白盒测试方法和黑盒测试方法
黑盒测试方法,不考虑程序内部结构和内部特性,而是从用户观点出发,针对程序接口和用户界面进行测试,根据产品应该实现的实际功能和已经定义好的产品规格,来验证产品所应该具有的功能是否实现,是否满足用户的要求。
所以,黑盒测试方法技术相对要求低,方法简单有效,可以整体测试系统的行为,可以从头到尾(end-to-end)进行数据完整性测试。黑盒测试方法适合系统的功能测试、易用性测试,也适合和用户共同进行验收测试、软件确认测试。黑盒测试方法不适合单元测试、集成测试,而且测试结果的覆盖度不容易度量,其测试的潜在风险比较高。
由于白盒测试方法,已知产品的内部工作过程,针对性很强,可以对程序每一行语句、每一个条件或分支进行测试,测试效率比较高,而且可以清楚已测试的覆盖程度。如果时间足够多,可以保证所有的语句和条件得到测试,测试的覆盖程度达到很高。白盒测试方法所以适合单元测试、集成测试,而不适合系统测试。白盒测试方法准备的时间很长,如果要覆盖全部程序语句、分支的测试,一般花费比编程更长的时间。
白盒测试方法所要求的技术也较高,相应的测试成本要大。对于一个应用的系统,程序的路径数可能是一个天文数字,即使借助一些测试工具,白盒测试法也不可能进行穷举测试,企图遍历所有的路径往往是做不到的。即使,穷举路径测试,也不能查出程序违反了设计规范的地方,不能发现程序中已实现但不是用户所需要的功能,可能发现不了一些与数据相关的错误或用户操作行为的缺陷。所以白盒测试方法也存在一定的局限性。
静态测试和动态测试
静态测试是通过对软件的程序源代码和各类文档或中间产品(产品规格说明书、技术设计文档),采用走查、同行评审、会审等方法来查找错误或收集所需要的度量数据,而不需要运行程序,所以相对动态测试,可以更早地进行。
静态分析的查错和分析功能是其他方法所不能替代的,静态分析能发现文档中问题(也只能通过静态测试实现),通过文档中问题或其他软件评审方法来发现需求分析、软件设计等问题,而且能有效地检查代码是否具有可读性、可维护性,是否遵守编程规范,包括代码风格、变量/对象/类的命名、注释行等。静态测试已被当做一种自动化的、主要的代码校验方法。
动态测试是通过观察程序运行时所表现出来的状态、行为等发现软件缺陷,包括在程序运行时,通过有效的测试用例(对应的输入 / 输出关系)来分析被测程序的运行情况、或进行跟踪对比,发现程序所表现的行为与设计规格或客户需求不一致的问题。
动态测试是一种经常运用的测试方法,无论在单元测试、集成测试中,还是在系统测试、验收测试中,都是一种有效的测试方法。但动态测试不能发现文档问题,必须等待程序代码完成后进行,发现问题相对迟得多,一旦发现问题,必须重新设计、重新编码,必然增大不良质量的成本。
手工测试和自动化测试
手工测试是指通过测试人员自身对系统进行操作来完成操作,而自动化测试是通过计算机运行测试工具和测试脚本自动进行。自动化测试具有很多优点,如执行速度高而缩短测试周期、可以多次重复运行相同的测试而减少测试的单调性、真实反映测试结果、二十四小时不知劳累运行等等,所以在测试工作中,我们尽力实现测试自动化、或扩大自动化测试的覆盖范围。但是自动化测试前期投入大,对被测对象要求高以及存在其它的局限性。
软件测试自动化绝不能代替手工测试,它们两者有相应的测试对象和范围:
1.    工具本身并没有想象力和灵活性,根据业界统计结果,自动测试只能发现15-30%的缺陷,而手工测试可以发现70-85%的缺陷;所以自动化测试有其局限性,不适合软件的新功能测试,而特别适合回归测试,可以保证对已经测试过部分进行测试的准确性和客观性。
2.    在系统功能的逻辑测试、验收测试、适用性测试、涉及物理交互性测试时,也很难通过自动化测试来实现,多采用黑盒测试的手工测试方法;
3.    单元测试、集成测试、系统负载或性能测试、稳定性测试、可靠性测试等比较适合采用自动化测试;
4.    当界面、需求变化比较频繁时、开发周期很短的软件、或做一次性软件开发项目(而不是做软件产品)时,自动化测试吃力不讨好,投入大而产出小。
5.    有些测试工具只能运行在Windows平台上,不能运行在Mac/Unix等平台上。
多数情况下,手工测试和自动化测试相结合,以最有效的方法来完成测试任务。
有计划测试和随机测试
在测试执行前,我们一般都进行测试的策划、计划,分析测试的重点和范围,精心设计测试用例,来做好测试执行前的准备,通过测试计划和测试用例进行的测试是有计划的测试,而不通过事先计划或不借助测试用例,完全凭感觉、猜测而进行自由、灵活的测试,被称作随机的测试或ad-hoc test。有计划的测试效率高、针对性强,可以很好地达到测试目标,但由于用户使用软件的情景很多、千变万化,测试用例很难覆盖各种情况,特别是一些边界和特殊的操作。根据经验和历史数据统计,对于大型系统软件测试用例的覆盖度一般在90%到95%之间。所以,必须借助一些自由的ad-hoc test,充分发挥测试人员最大的灵动性、创造性,进行各种猜测和试探,去发现一些相对隐藏比较深或偏僻的软件缺陷。ad-hoc test另外一个作用是帮助测试人员尽早地熟悉产品,改进测试用例。
新功能测试和回归测试
即使在开发一个新软件(第一个版本),在进行系统测试还是功能测试时,总会发现一些严重的缺陷而需要修正,这时就要构造一个新的软件包(Full Build)或新的软件补丁包(Patch),然后进行测试。这时的测试不仅要验证被修复的软件缺陷是否真正被解决了,而且要保证以前所有运行正常的功能依旧保持正常,而没有受到这次修改的影响。对于检验原有正常功能没有出现回归的缺陷而进行的测试,称为回归测试。对于开发第二、三个版本或以后的版本,这种回归测试所占的比重越来越大。所以,一个完整的测试,可以看作新功能或新修改的测试,加上回归测试的组合。
在软件产品实现过程中,新功能的实现固然重要,可以增强产品的亮点和竞争力,增加市场份额,但是不能正常工作的已有功能所引起的客户抱怨可能更大,因为客户已经习惯地使用已有功能了,而对于新功能,客户还没怎么使用(没尝到甜头)或者客户可能不知道这个新功能,甚至我们可以在客户知道前去掉这个功能。所以,从这个意义上说,回归测试显得更为重要。