《软件测试的有效方法(第2版)》笔记(二)
最编程
2024-01-07 11:19:57
...
测试是用来确定应用系统属性的存在、质量及其真实性的一种手段。
测试过程尽量做到结构化。
1、应用程序的有效性取决于该应用程序与其所在环境的适应性。
适应性:指应用程序在帮助用户执行其日常工作方面的使用、帮助合意义的程度。适应性有如下所述的四个要素:
(1)数据:数据的可靠性、及时性、一致性、可用性;
(2)人员:良好技能、相应培训、悟性、兴趣;
(3)结构:提高技术、满足需求的恰当的开发方法;
(4)规则:按照一定规程处理数据。
应用系统必须与业务环境中的这四个要素相适应。
2、测试技术/工具的选择过程
2.1、结构测试与功能测试
基于结构分析的测试,其目的是为了发现程序“编码”过程中的错误;基于功能分析的测试是为了发现实现需求或者设计规格说明时的错误。
功能测试确保应用系统恰当地满足了需求;结构测试用于保证对各功能实现进行了充分的测试。
2.2、动态测试与静态测试
动态测试基于测试用例运行程序,执行的结果与期望结果值进行比较,看是否一致。
静态测试不需要执行程序,其手段如语法检查等。
静态测试主要用于需求和设计阶段,动态测试主要用于测试阶段。
2.3、人工测试与自动测试
由人所执行的测试称为人工测试,由机器执行的测试称为自动测试。
开发过程越是自动化,测试过程的自动化也就越容易。
3、测试技术/工具的选择
过程:选择测试因素-->确定SDLC阶段-->明确测试标准-->选择测试类型-
(系统结构或功能)->选择技术-->选择测试方法-->动态或静态
->单元测试技术-->选择测试方法-->动态或静态
4、测试技术与测试工具的区别
测试工具是执行测试过程的一个设备;测试技术是确保应用系统某方面或单元的功能正确的过程。
5、结构化系统测试技术:用于验证所开发的系统及程序的运行情况。目标是要确保产品设计在结构上合理,功能上正确。为确定实现的配置及其各功能共同作用以完成特定任务提供了一种机制。结构化测试技术由以下几种:
(1)压力测试:确定系统以期望的容量执行。
举例:分配了足够的磁盘空间;有充分的通信渠道。
压力测试技术用于检查系统面对意外情况下的大数据量时是否可以正常运行。所涉及的方面包括输入事务、内部表、磁盘空间、输出、通信、计算机容量以及人机交互等。
当应用系统所能正常处理的工作量并不确定时需要使用压力测试。压力测试意图通过对系统施加超负载事务量来达到破坏系统的目的。弱点在于准备测试的时间与在测试的实际执行过程中所消耗的资源数量都非常之大,通常在应用程序投入使用之前这种技术是无法进行的。
(2)执行测试:系统能达到期望的熟练性。
举例:事务轮转时间充分;软硬件使用良好。
执行测试技术用于检查系统是否达到了预期在产品状态下的成熟度。执行测试可以验证系统的响应时间、轮转时间及设计性能。
在开发过程的早期就应该进行执行测试,尽早制定已经完成的系统没有达到性能指标是非常有价值的。在关键时间点进行。关键时间点指的是当前的结果会影响甚至改变系统结构的时间点。
(3)恢复测试:系统失效之后可以恢复到可操作状态。
举例:引入失败;评估备份数据的充分性。
恢复测试技术用于确保系统在经历灾难后可以继续正常运行,它不仅可以验证恢复过程,而且可以验证过程各组件的有效性。
当用户认为系统操作的连续性对于其所涉及领域的某些功能至关重要时,需要进行恢复测试。
(4)操作测试:系统以正常操作状态执行。
举例:确定系统可以依据文档进行运行;JCL(工作控制语言)充分。
操作测试技术主要用于检查系统在正常的操作状态下是否可以执行。操作测试可以与其它测试联合执行。
任何应用程序在成为产品之前都应进行操作测试。
(5)(与过程的)一致性测试:系统的开发与标准和规程相一致。
举例:按标准执行;文档完整。
一致性测试技术用于验证应用程序的开发是否与信息技术指标、过程及准则相一致。一致性测试最有效的方法是过程审查。
系统开发标准和过程的一致性程度依赖于管理层对于所需遵循的特定过程和执行标准的重视程度。
(6)安全性测试:根据组织的重要性对系统进行保护。
举例:访问拒绝;规程适当。
安全性测试技术用于评价保护性程序及安全对策的充分性。安全性缺陷不如其它类型的缺陷那么明显。安全性测试是测试过程中高度专业化的部分。分物理安全性(针对利用物理方法收集信息的手段)和逻辑安全性(针对使用计算机处理和通信能力进行非法活动信息的手段)。
当系统保护信息和资产对于组织来说意义重大时,需要进行安全性测试。
6、功能性系统测试技术
功能性系统测试用于确保系统需求与定义都得到了满足。该过程通常包含创建用于评价应用程序正确性的测试条件。
用于执行功能测试的几种测试技术包括:
(1)需求测试:系统按制定方式执行。
举例:证明系统需求;与政策、规则相一致。
需求测试技术验证系统是否正确执行其功能,并且能保证在相当长的一段时间内保持其正确性。需求测试的执行主要通过执行创建的测试条件以及功能检查单来完成,通过需求得到测试条件,然后以类似于SDLC这种特定的方式表现,生成用于评价实现的应用系统的测试数据。
任何应用程序都应该对需求进行测试,此过程应该开始于需求阶段,并一直持续到系统运行和维护阶段。
(2)回归测试:验证系统中没有改变的部分仍能正确运行。
举例:未变更的部分正常运行;未变更的人工规程正确。
回归测试技术对已经测试过的部分进行重新测试,以保证它们在应用程序其它部分发生变更之后仍能正常运行。
当变更会对应用程序中没有变更的部分产生高风险的影响时需要进行回归测试。
(3)错误处理测试:错误可以得到防止或检测,并被修复。
举例:将错误引入测试;错误的再次注入。
人工系统与自动系统之间差别的特点之一就是预定义的错误处理特性。错误处理测试技术用于检查应用系统正确处理发生异常的能力。错误处理测试需要一组知识丰富的人员来预见应用系统可能发生的错误。它是测试错误的引入、错误的处理,控制条件以及条件的再次正确输入。
在系统整个生命周期中都应该进行错误测试。在开发过程中,应该识别错误带来的问题并且采取相应的措施将错误减少到可以接受的程度。
(4)人工支持测试:人机交互有效。
举例:具备人工规程;人员接受过培训。
人工支持测试技术主要包括人员在准备数据以及使用来源于自动程序数据的过程中执行所有功能。
在生命周期的全过程都应该验证人工系统功能的正确性。
(5)系统间测试:数据可以正确地在系统间传递。
举例:系统间参数变化;系统间文档更新。
系统间测试技术用于保证应用程序间相互管理的正确性。系统间测试的一个最好的工具是集成测试工具,它允许在产品环境下进行测试,可以以最小的代价测试系统间的耦合性。
在应用系统间的参数发生变更时需要进行系统间的测试。测试的程度和类型依赖于与出错的参数相关联的风险情况。
(6)控制测试:将系统风险控制降低到可以接受的级别。
举例:文件一致性规程正常;人工控制正确。
控制测试技术包括数据确认、文件完整性控制、评审追踪、备份和恢复、文档,以及与系统完整性相关的其它方面。主要用于确保对系统特定功能的检查。可以用于控制测试的一个方法是生成风险矩阵。
控制测试是系统测试中的一个完整的部分,占测试时间的很大比例。
(7)平行测试:发现原系统与新系统之间的意外差异。
举例:原系统与新系统一致;原系统仍然可以工作。
平行测试技术用于检查新应用程序的结果是否与原来的应用程序或者上一版本应用程序的处理相一致。它执行冗余处理以保证新版本或者新应用程序执行的正确性;给出同一应用程序不同版本之间一致的和不一致的地方。平行测试可以对整个应用程序进行,也可对应用程序的一部分进行。
当不能确定新应用程序处理的正确性,或者当新旧版本的应用程序非常类似时,需要进行平行测试。
7、单元测试技术
程序的测试和分析是验证程序具有其规格说明所要求的特性的最实际的手段。
测试是一种动态验证方法,它使用测试数据运行代码来评估程序对需求的满足程度。
分析是一种静态验证方法,通过分析代码而不是执行代码来检测需求的满足度。
“单元”可能小到一条语句,也可能大到是许多子例程的组合。单元最本质的特点是可以被看作一个整体。
8、功能测试和分析
功能测试和分析确保包含了主要的代码特征。
面向错误的功能测试和分析确保包含了常见的错误。
单元测试的分析和管理应该是系统化的,它由两步组成。第一,必须选择适合于项目的技术;第二,这些技术必须得到系统化的应用。
9、独立于规格说明技术的测试
规格说明细化了可能施加于给定的软件单元的那些假设,它们必须描述访问给定单元的接口以及该访问的具体行为。
1)基于接口的测试:在模块输入输出域特性及其相互关系的基础上选择测试数据。
(1)输入域测试:选择覆盖输入域边界的测试数据。
(2)等价划分:规格说明通常将所有可能的输入集合划分未几个等效的类。
(3)语法检查:对输入数据进行分析,对不正确的数据格式进行处理。
2)基于功能的测试
(1)特殊值测试:基于所要计算的功能的特点来选择测试数据称为特殊值测试。
(2)输出域覆盖:对于每个由等价划分所确定的功能都有其相关的一个输出域。
3)基于规格说明技术的测试
(1)代数学:在代数规格说明中,用公理或者规则来表示抽象数据的属性。在一个测试系统中,代数规则说明与实现的一致性是通过测试来检查的。每条公理都可以编译成与测试功能点集相关联的程序。驱动程序将这些测试功能点作为公理所对应的程序的输入数据,程序的反馈又说明了其对应的公理是否合适。
(2)公理:尽管断言计算作为一种规格说明语言具有广泛使用的可能,但是关于从这种规格说明生成测试数据方面尚未有公布的资料。
(3)状态机:许多程序可以用状态机描述,这又提供了另一种测试数据的选择方式。
(4)判定表:是一种表示等价划分的简洁方法,表的行表示输入满足的条件,表的列表示相应的输入所可能引发的动作集。
10、结构测试和分析
1)结构化分析
(1)复杂性度量
(2)数据流分析
用流程图来表示。通过它,推导出数据流的相关信息可以用于代码优化。异常检查以及测试数据的生成。
(3)符号执行
一个符号执行系统有三个输入参数:要解释的程序、程序的符号输入以及要执行的路径。
2)结构化测试:是一种动态的测试技术,其中测试数据的选择以及评价是依据测试过程中代码的覆盖目标而定的。该方法用于追踪在实际测试过程中所具体执行到的程序语句。
(1)语句测试
(2)分支测试
(3)条件测试
(4)表达式测试
(5)路径测试
11、面向错误的测试和分析
关注程序处理中有无错误的评估技术称为面向错误技术。分三大类:统计评估、基于错误的测试以及基于差错的测试。
基于错误的测试意于说明过程中不存在某些错误。基于差错的测试意于说明代码中不存在某些差错。
1)统计方法:利用统计技术来决定程序操作的可靠性。
2)基于错误的测试:可以由程序员的错误历史、软件复杂度、对易犯句法错误的结构的了解或者甚至是错误推测来驱动。
(1)错误估计:也叫错误种植法(Fault Seeding),是一种用于评估程序中错误的数目和特点的统计性方法。首先,将错误引入程序;然后,测试程序基于所发现的错误数目来估计尚未发现的错误数目。难点在于所引入的错误必须可以代表程序中尚未发现的错误。
(2)域测试:可以按照输入是否执行相同的路径来划分程序的输入域。这些划分称为路径域。
(3)扰动测试:需要决定构成被测试路径充分集的内容。
3)基于差错的测试:对评估测试数据非常有用。可以在深度上和广度上进行区分。在深度上,局部范围的方法证明差错对计算有局部作用,很可能该局部作用并不会引起程序失效,而全部范围的方法证明会使得程序失效;广度取决于所处理的差错类是有限的还是无限的。
(1)局部有限型
(2)全局有限型
(3)局部无限型
(4)全局无限型
上一篇: GB/T 38634.1-2020 系统与软件工程 软件测试 第1部分:概念和定义的标题重写如下: 软件测试:GB/T 38634.1-2020 系统与软件工程 第1部分——概念和定义
下一篇: 模拟测试 - 重新定义代码质量
推荐阅读
-
什么是可用性测试?有效性(Effectiveness)-- 用户完成特定任务和实现特定目标的正确性和完整性程度;效率(Efficiency)-- 用户完成任务的正确性和完整性程度与所用资源(如时间)之比;满意度(Satisfaction)-- 用户在使用产品时的主观满意度和接受程度。 2.如何获得可用性? 可以参考以下原则:Gould、Boies 和 Lewis(1991 年)为以用户为中心的设计定义了 4 个重要原则: 早期以用户为中心:设计者应在设计过程的早期就努力了解用户的需求。 综合设计:设计的所有方面都应同步发展,而不是按顺序进行。使产品的内部设计始终与用户界面的需求保持一致。 早期和持续测试:当今唯一可行的软件测试方法是经验主义方法,即如果实际用户认为设计可行,该设计就是可行的。通过在整个开发过程中引入可用性测试,用户就有机会在产品推出之前对设计提出反馈意见。 迭代设计:大问题往往掩盖了小问题的存在。设计人员和开发人员应在整个测试过程中对设计进行迭代。 3...什么是可用性测试? 可用性测试是根据可用性标准对图形用户界面进行的系统评估。 可用性测试是衡量用户与系统(网站、软件应用程序、移动技术或任何用户操作设备)交互时的体验质量。4.如何进行可用性测试? l 实验室实验
-
纯干货分享 | 研发效能提升——敏捷需求篇-而敏捷需求是提升效能的方式中不可或缺的模块之一。 云智慧的敏捷教练——Iris Xu近期在公司做了一场分享,主题为「敏捷需求挖掘和组织方法,交付更高业务价值的产品」。Iris具有丰富的团队敏捷转型实施经验,完成了企业多个团队从传统模式到敏捷转型的落地和实施,积淀了很多的经验。 这次分享主要包含以下2个部分: 第一部分是用户影响地图 第二部分是事件驱动的业务分析Event driven business analysis(以下简称EDBA) 用户影响地图,是一种从业务目标到产品需求映射的需求挖掘和组织的方法。 在软件开发过程中可能会遇到一些问题,比如大家使用不同的业务语言、技术语言,造成角色间的沟通阻碍,还会导致一些问题,比如需求误解、需求传递错误等;这会直接导致产品的功能需求和要实现的业务目标不是映射关系。 但在交付期间,研发人员必须要将这些需求实现交付,他们实则并不清楚这些功能需求产生的原因是什么、要解决客户的哪些痛点。研发人员往往只是拿到了解决方案,需要把它实现,但没有和业务侧一起去思考解决方案是否正确,能否真正的帮助客户解决问题。而用户影响地图通常是能够连接业务目标和产品功能的一种手段。 我们在每次迭代里加入的假设,也就是功能需求。首先把它先实现,再逐步去验证我们每一个小目标是否已经实现,再看下一个目标要是什么。那影响地图就是在这个过程中帮我们不断地去梳理目标和功能之间的关系。 我们在软件开发中可能存在的一些问题 针对这些问题,我们如何避免?先简单介绍做敏捷转型的常规思路: 先做团队级的敏捷,首先把产品、开发、测试人员,还有一些更后端的人员比如交互运维的同学放在一起,组成一个特训团队做交付。这个团队要包含交付过程中所涉及的所有角色。 接着业务敏捷要打通整个业务环节和研发侧的一个交付。上图中可以看到在敏捷中需求是分层管理的,第一层是业务需求,在这个层级是以用户目标和业务目标作为输入进行规划,同时需要去考虑客户的诉求。业务人员通过获取到的业务需求,进一步的和团队一起将其分解为产品需求。所以业务需求其实是我们真正去发布和运营的单元,它可以被独立发布到我们的生产环境上。我们的产品需求其实就是产品的具体功能,它是我们集成和测试的对象,也就是我们最终去部署到系统上的一个基本单元。产品需求再到了我们的开发团队,映射到迭代计划会上要把它分解为相应的技术任务,包括我们平时所说的比如一些前端的开发、后端的开发、测试都是相应的技术任务。所以业务敏捷要达到的目标是需要去持续顺畅高质量的交付业务价值。 将这几个点串起来,形成金字塔结构。最上层我们会把业务目标放在整个金字塔的塔尖。这个业务目标是通过用户的目标以及北极星指标确立的。确认业务目标后再去梳理相应的业务流程,最后生产。另外产品需求包含了操作流程和业务规则,具需求交付时间、工程时间以及我们的一些质量标准的要求。 谈到用户影响的地图,在敏捷江湖上其实有一个传说,大家都有一个说法叫做敏捷需求的“任督二脉”。用户影响地图其实就是任脉,在黑客马拉松上用过的用户故事地图其实叫督脉。所以说用户影响地图是在用户故事地图之前,先帮我们去梳理出我们要做哪些东西。当我们真正识别出我们要实现的业务活动之后,用户故事地图才去梳理我们整个的业务工作流,以及每个工作流节点下所要包含的具体功能和用户故事。所以说用户影响地图需要解决的问题,我们包括以下这些: 首先是范围蔓延,我们在整张地图上,功能和对应的业务目标是要去有一个映射的。这就避免了一些在我们比如有很多干系人参与的会议上,那大家都有不同想法些立场,会提出很多需求(正确以及错误的需求)。这个时候我们会依据目标去看这些需求是否真的是会影响我们的目标。 这里提到的错误需求,比如是利益相关的人提出的、客户认为产品应该有的、某个产品经理需求分析师认为可以有的....但是这些功能在用户影响地图中匹配不到对应目标的话,就需要降低优先级或弃掉。另外,通常我们去制定解决方案的时候,会考虑较完美的实现,导致解决方案括很多的功能。这个时候关键目标至关重要,会帮助我们梳理筛选、确定优先级。 看一下用户影响到地图概貌 总共分为一个三层的结构: 第一层why,你的业务目标哪个是最重要的,为什么?涉及到的角色有哪些? 第二层how ,怎样产生影响?影响用户角色什么样的行为? (不需要去列出所有的影响,基于业务目标) 第三层what,最关键的是在梳理需求时不需一次把所有细节想全,这通常团队中经常遇到的问题。 我们用这个例子来看一下 这是一个客服中心的影响地图,业务目标是 3个月内不增加客服人数的前提下能支持1.5倍的用户数。此业务目标设定是符合 smart 原则的,specific非常的具体,miserable 是可以衡量的,action reoriented是面向活动的, real list 也是很实际的。 量化的目标会指引我们接下来的行动,梳理一个业务目标,尽量去量化,比如 :我们通过打造一条什么样的流水线,能够提高整个部署的效率,时间是原来的 1/2 。这样才是一个能量化的有意义的目标。 回到这幅图, how 层级识别出来的内容,客服角色:想要对它施加的影响,把客户引导到论坛上,帮助客户更容易的跟踪问题,更快速的去定位问题。初级用户:方论坛上找到问题。高级用户:在论坛上回答问题。通过我们这些用户角色,进行活动,完成在不增加客户客服人数的前提下支持更多的用户数量。 最后一个层级,才是我们日常接触比较多的真正的功能的特性和需求,比如引导到客户到论坛上,其实这个产品就需要有一个常见问题的论坛的链接。这个层次需要我们团队进一步地在交付,在每个迭代之前做进一步的梳理,细化成相应的用户故事。 这个是云智慧团队中,自己做的影响地图的范例,可以看下整个的层级结构。序号表示优先级。 那我们用户影响地图可以总结为:
-
软件测试中有效的正交测试方法
-
《软件测试的有效方法(第2版)》笔记(二)