继上边测试入门接着整理测试基础:测试的对象,测试的八大原则及测试的策略有哪些?
测试对象有哪些
1、文档
需求分析,概要设计,详细设计以及程序编码等各个阶段所得到的文档,包括需求规格说明书、概要设计规格说明,详细设计规格说明书等,都是软件测试的对象。
2、code
这里的code就是指在程序编码阶段所输出的前后端的code,主要就是后端code,可通过单元测试方法进行测试。单元测试指的是对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义,一般来说,要根据实际情况去判定其具体含义,如C语言中单元指一个函数,Java里单元指一个类,图形化的软件中可以指一个窗口或一个菜单等。总的来说,单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
3、接口
这里的接口分为内部接口及外部接口。内部接口就是各个子系统内的交互接口,如dubbo服务接口;外部接口就是指与外部系统交互的接口,比如第三方支付接口等。而在做接口测试可以发现整个测试接口60%甚至更多的bug。接口测试可以使用工具或自动化进行,常用的工具有postman,chares等
4、界面
界面主要是对系统的UI测试及通过系统的界面测试并验证需求文档,code及接口的正确性。而对于比较完善且成熟的系统推荐UI自动化,减少手工重复操作。
5、系统(软件、硬件等)
系统测试是对整个系统的测试,将硬件、软件、操作人员看作一个整体,检验它是否有不符合系统说明书的地方。这种测试可以发现系统分析和设计中的错误。在做完集成测试后,作为计算机系统的一个部分,与系统中其他部分结合起来,在实际运行环境下对计算机系统进行的一系列严格有效地测试,以发现软件潜在的问题,保证系统的正常运行。如一些安全测试,性能测试等。
测试的八大原则
1、测试能证明系统存在bug,但不能证明系统无bug
2、穷尽测试是不可能的:通过风险分析及功能需求的优先级来确认测试的关注点。
3、尽可能早的介入测试
4、缺陷集群性:发布前所发现的缺陷和软件运行失败都是由于少数软件模块引起的。
5、杀虫剂悖论
在软件测试中有一种称为杀虫剂悖论(pesticide paradox)的现象,即对软件进行越多的测试,那么该软件对软件测试人员的测试就越具有免疫力。
首先,我们先来看下什么是杀虫剂悖论,每年各种各样的害处袭击田野和农作物,农业专家们要找到正确的对抗方法,用改良的配方设计出杀虫剂。但是害虫适应了新的杀虫剂,产生了免疫力,使新杀虫剂失效。随后的几年里,老的杀虫剂只能用来杀死没有免疫力的害虫,同时还必须引入一些新的改良配方,同更顽强的新编译害虫作斗争。新旧杀虫剂的结合有时阻碍了旧杀虫剂效能的发挥。随着时间的流逝,旧的杀虫剂变得毫无用处。于是,害虫和杀虫剂不停的战斗,看最终谁占上风。有时杀虫剂赢,但是,有时害虫又可以成功的战胜最新的杀虫剂。这场斗争的结果是大自然和杀虫剂的不断发展变化。
在软件测试中,为了克服“杀虫剂悖论”,测试用例需要经常的评审和修改,不断增加新的不同的测试用例来测试软件或系统的不同部分,保证测试用例永远是最新的,即包含着最后一次程序代码或说明文档的更新信息。这样软件中未被测试过的部分或者先前没有被使用过的输入组合就会重新执行,从而发现更多的缺陷。软件测试人员必须不断地编写新的不同的测试来检验程序的不同部分从而找出更多的bug。让其他的人来测试你的程序将有助于打破”杀虫剂悖论”。
6、一切从用户出发
7、持续的测试,持续的反馈
8、80/20原则
用户80%的时间都是在用系统产品中20%的功能,所以这20%是测试重点;80%的缺陷都是出于系统20%的功能。
80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们,如果你想使软件测试有效地话,记住常常光临其高危多发 “ 地段 ” 。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。
80-20 原则的另外一种情况是,我们在系统分析、系统设计、系统实现阶段的复审,测试工作中能够发现和避免 80% 的软件缺陷,此后的系统测试能够帮助我们找出剩余缺陷中的 80% ,最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷,却无法保证能够发现所有的软件缺陷。
80-20 原则还能反映到软件测试的自动化方面上来,实践证明 80% 的软件缺陷可以借助人工测试而发现, 20% 的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分,因此尚有 5% 左右的软件缺陷需要通过其他方式进行发现和修正。
其他原则:
9、建立清晰的阶段性目标
10、测试独立性:测试应该独立于一个测试团队,职责分离,而不是开发人员自己测试自己的代码
11、测试活动依赖测试背景
12、可测试性:准入准出原则
13、测试计划是一个持续的过程
测试策略是什么
从字面意思来讲,测试策略应该是比较高层的概念,应该着眼于测试中大的方面,而不是细枝末节。一般来说,测试策略描述了软件开发过程中进行测试方法,用来告诉测试过程中所有可能的参与者,测试活动应该如何进行。其中主要会包括测试目标,测试新功能的方法,测试项目的时间和资源,以及测试环境等等。
除此以外,测试策略应该描述测试过程中存在哪些风险,以及如何能够规避或者降低这些风险。同时,测试策略也会提到测试的级别,哪些测试应该被执行,入口出口条件是什么。创建测试策略时候我们可以参考各种需求文档和设计文档。(转载自https://www.zhihu.com/question/48486053/answer/356730648)
一般来说,测试策略在结构上可以包括以下一些要点:
(1)测试级别:根据动态测试在软件开发过程中所处的阶段和作用分为单元测试,集成测试,系统测试,验收测试及回归测试。大部分的测试组织里面,单元测试由开发负责,而其余四个由测试部门或者质量保证部门负责;从是否关心软件内部结构和具体实现的角度划分为白盒测试,黑盒测试及灰盒测试。
(2)角色与职责:需要在测试策略里面明确定义各个角色,以及该角色的职责。比如项目经理,测试组长,测试工程师…
(3)环境需求:这一点非常重要,它将描述测试时需要的系统环境,包括软硬件以及网络环境等等。在澄清环境需求的时候,测试组织可以识别出资源方面的风险。
(4)风险分析:影响测试过程的风险都应该尽早被识别出来,而且必须有相应的解决办法以便消除或者减轻这些风险。
(5)测试进度:测试进度将会评估完成测试所需要的时间。在设定进度的时候,首先需要明确测试范围,然后根据测试资源的多少来制定能被各方面认可的测试进度计划。做一个非常准确的进度计划是困难的事情,因为测试过程中充满了各种不确定性,所以一般计划者需要考虑增加一定的buffer。当然,制定进度计划的时候可以参考已有的项目的数据。如果是一个全新的软件项目,专家认为将初始计划的时间翻倍比较靠谱!
(6)回归测试方法:回归测试用来保证之前fix bug的代码不会影响软件的其他部分,这样需要我们选择已经执行过的测试用例重新运行。测试人员需要找到一个方法来确定哪些测试用例应该在回归测试中运行,用例不能太多,因为资源有限,用例也不能太少,否则会达不到必须的测试强度。不过,如果测试部门对待测系统以及软件架构非常了解的话,就比较容易找到合适的回归测试集合。
(7)测试范围:这个没啥好说的,就是你要测试的内容,可能是某些模块,可能是某些指标,比如功能,性能,易用性…
(8)测试优先级:测试范围内的东西不会都是一样重要的,加上测试资源各种有限,所以为测试排定优先级是十分的必要。
(9)测试入口/出口标准:这个标准一般研发内部根据公司标准讨论确定,但一般在实际测试时很难完全遵照执。