软件测试part3.docx
- 文档编号:17607029
- 上传时间:2023-07-27
- 格式:DOCX
- 页数:37
- 大小:42.22KB
软件测试part3.docx
《软件测试part3.docx》由会员分享,可在线阅读,更多相关《软件测试part3.docx(37页珍藏版)》请在冰点文库上搜索。
软件测试part3
第3章软件测试生命周期介绍
3.1测试过程综述
在应用程序开发生命周期的开始阶段,就应该开始测试过程,而不是传统的在编码结束时才开始测试。
测试需要和应用程序开发阶段结合起来。
在软件开发生命周期的需求阶段,业务需求的定义是比较高级的,并且他们也是后续阶段以及最终实现的基础。
从广义上讲,测试从需求阶段就已经开始了,这样就能够尽量满足客户的需求来实现高质量的系统。
这样做的结果就是需求能够被验证,使之正确并且完整。
而不幸的是,大多数情况下,制定出来的需求是糟糕的。
糟糕的需求破坏了瀑布模型,导致了不符合用户需求的产品。
糟糕的需求包括了:
•只定义了部分功能
•没有考虑性能
•模棱两可的需求
•没有考虑安全性
•没有接口的文档说明
•错误和冗余的需求
•需求过于苛刻
•自相矛盾的需求
规格说明中,功能是最重要的,应该包括一个对功能的层级划分。
这样做的原因是能够提供描述说明,这些描述说明在不统的层面上被描述从而用户可以根据自己的需要阅读其细节。
特别的,这样做还可以使得把规格说明翻译成测试需求的过程简化。
另外一个需求规格说明的重要元素就是数据描述。
它应当包括一些细节,比如数据库是否是关系型的还是层次型的。
如果数据库是层次型的,一个好的表述应该包括数据模型或者有关于实体、属性、关系的实体关系图。
需求的另一个部分应该包括对系统与外界交互的接口描述,例如用户、外部软件、外部硬件。
与人的交互应该包含了对于用户如何同系统交互的描述。
这就需要包括接口的形式以及用户的技术能力。
在需求阶段,测试的组织需要同时执行两项功能。
它需要构造系统/接受测试计划,并且对需求进行查证。
需求查证要求开发小组要保证准备的文档的正确性和完整性。
1.技术复审测试需求
需求定义是创造性思维的结果,是设计的基础。
需求阶段的查证用到了一些静态技术。
这些技术检查规格文档的一致性,完备性以及语法,另外还包括以下内容:
(1)检查和走查
这些是评价第二章所描述的文档形式,接口需求,解决方案约束的正规技术。
(2)检查列表
这些是向前定向质量控制,包括保证需求完备性的一些问题。
(3)方法学检查列表
它提供了方法学的步骤,目的是保证方法学的实施。
如果复审非常的成功,没有发现缺陷,需求规格说明此时就是确定的,任何进一步的提炼都会被严格的监控。
如果复审并不是很成功,发现了一些缺陷,在复审过程中,作者需要纠正他们,并且这些缺陷要被管理员再次复审,并停止活动。
从另一方面来讲,如果在需求复审过程中发现了主要的缺陷,缺陷就需要被纠正,并且在稍后的时候复审应当再次进行。
在需求复审过程中发现的每一个缺陷都应该在文档上进行记录。
需求缺陷问题报告就是为了恰当地记录这些缺陷。
它包括了缺陷的种类和缺陷的类型。
对每一个缺陷的描述都应该在丢失,错误或者另外的列下来进行。
在需求复审的结论中,这些缺陷将被总结并且进行统计。
2.需求可追溯性矩阵
需求的可追溯性矩阵是一个文档,它追踪了用户从分析到实现的需求。
它也可以作为一个完备性检查用来查证所有的需求是否都已经被陈述清楚,或者不存在额外的和不必要的特性,同时它还可以作为对于新的人员的维护指导。
在软件生命周期的每一步中,需求、代码以及相关的测试用例都将被记录,从而保证了在最终的系统中,用户的需求确实得到了实现。
开发者和用户都能够很容易的将需求、设计规格说明、程序以及测试用例进行交叉引用。
更多的详情请参考附录3.8,需求可追溯性矩阵。
3.构建系统/接受测试计划
接受测试用来查证系统是否满足了用户的接受测试标准。
接受测试计划是基于需求规格说明的,在一个正规的测试环境中,接受测试计划是必不可少的。
这种测试采用了黑盒测试技术,来测试系统是否满足规格说明,这种测试主要是由终端用户来执行。
在接受测试过程中,项目组协调测试过程并且根据需要更新接受测试标准是非常重要的。
接受测试经常和系统级的测试计划相结合。
系统级的测试计划在以后也将讨论到。
需求阶段是第一个开发阶段,发生在开发阶段在逻辑设计、物理设计程序单元设计以及编码阶段之前。
在需求阶段,并不期望测试计划中所有的部分都要完成,因为并没有足够的信息。
在测试计划的介绍部分,对于最初非正式的测试活动的文档记录就已经开始了。
包括了系统描述,总体系统描述,接受测试目标,假设,风险,偶发性以及约束。
在此时,对于通过签名的合适的授权就应当被考虑在内了。
测试方法和策略的五个关键部分包括:
1)测试范围,2)测试方法,3)测试类型,4)后勤,5)衰退政策。
测试范围定义了测试的工作量,例如是否对整个系统测试,或者只测试一不部分。
测试方法文档说明了测试方法的基础,例如黑盒、白盒、灰盒测试,增量集成等等。
测试类型则决定了测试的类型,例如单元、集成、系统、接受测试,这些都将在测试范围中被执行。
在这里,系统级测试的类型的细节将被提及。
后勤则对开发、测试以及其他相关组织的工作关系进行了说明。
它定义了怎样以及什么时候测试组将收到软件,以及缺陷怎样被记录、纠正和查证。
衰退政策决定了在变更发生之后,先前被测试的系统是否能正常工作。
测试需求文档的一个主要难题就是测试者要决定问题的定义是否已经被翻译成需求文档。
这就需要对最终的产品进行预测,预测要对哪些内容进行测试从而确定需求解决了问题。
测试需求部分中,一个有用的帮助分析,复审以及文档华初始的功能分解的技术叫做需求/测试矩阵。
这个矩阵定义了项目的测试范围,保证了测试按照需求规格说明来进行。
同时,它还有助于确定哪些功能需要被测试而哪些不需要。
需求/测试矩阵的一些好处包括:
1、使得测试和脚本与需求相关联
2、简化复审
3、在整个软件生命周期中作为一个可追溯性机制,包括测试设计和执行
需求/测试矩阵说明了每一个需求,并且将需求与查证他们的测试用例和脚本相关联。
矩阵左边列出的需求还能够在测试方法和策略中有助于定义系统测试的类型。
一般情况下,并不会未单一的需求使用独特的测试用例,所以,要对一个需求进行彻底的测试,就要用到多个测试用例。
这样,测试用例就可以对于其他需求进行重用。
一旦需求/测试矩阵被建立起来,它就能够被复审,对测试用例设计和脚本的建立也可以开始了。
当一个测试用例与需求相关联时,状态栏用来跟踪其状态。
例如,状态栏中的“Q”就表示需求已经被QA复审过,“U”则代表使用者已经评价了此需求;“T”说明测试用例规范已经被评价并且准备好了。
在测试计划的测试规范部分,关于接受测试的信息可以获得也可以记录成文挡。
为了使用者接受系统这些测试是必要的。
过程是一系列使用同一操作模型的相关行为,例如告诉我们如何完成事件。
接下来的信息记录在测试过程部分;测试用例,原件,数据发展,测试执行,正确性,版本控制,测试库的维护,自动测试工具的用法,项目管理,检测以及状态报告。
现在考虑所需的测试个人资源还太早。
这包含需要的测试技巧,它们的角色和责任,数目和需求时间以及被需要的个人培训。
3.2逻辑设计阶段
商业需求在需求阶段被定义。
逻辑设计阶段提取商业需求以便为系统说明书做准备。
系统说明书能在物理设计阶段和编码中使用。
逻辑设计阶段进一步提取商业需求,此时的商业需求被定义在需求阶段,以功能和信息模型为观点。
1.数据模型,过程模型,以及相互关联
逻辑设计阶段为构建应用建立详细系统框架。
此阶段三个主要的交互者是数据模型,即实体关系表,一个过程模型和它们之间的相互关联。
数据模型是被需要信息的表示或者应用系统需要的数据对象类型。
它建立人和地点的联系以及应用的重要事情并且在后来的物理数据库设计中使用。
物理数据库设计是物理设计阶段的一部分。
数据模型是一个用来定义实体及其相互关系的图示方法。
实体是我们欲存储数据的地方。
它由一个完整确定的人,地点,事情以及使用者感兴趣的的事件构成。
它是用来保存和发布数据的。
实体的例子有顾客,定单,办公室以及需求定单。
每个实体是一张直线分隔成行与列的表。
每行是每个实体的特定的发生,象文件的记录一样。
每列是描述描述实体的一个属性。
属性的例子有大小,数据,值和地址。
数据模型的各个实体本身不存在,通过关系与其他实体相连。
关系是用户感兴趣的两个或者多个实体的联系,此应用是用来保存和发布数据的。
一对一的对于关系连接单个发生的实体或者另一发生的实体。
一个一对多的联系连接单个发生的实体或者另一实体的多个发生。
一个多对多的联系连接一个实体的多个发生到另一实体的多个发生。
关系类型定义了实体关系的集合。
过程是一个商业活动以及输入输出的联系。
过程的例子有:
接受定单,存货更新,运输定单,调度级别。
一个进程模型是图表的形式,应该描述进程的状况而不涉及进程执行的原因,方式和时间。
这些是进程的物理属性,在物理设计阶段定义。
进程模型是商业的分解。
进程分解是活动更为详细的分类。
它开始的最早直到基本子过程被定义,子过程是最小的对用户有意义的活动单元。
进程分解表以层次结构来描述进程,显示出连续层次的细节。
此图表重复的构建进程,子进程被分解。
根部的进程是分解的源头,父进程在更高的级别。
子进程处在低级别并与高级别即父进程相连。
数据流图经常被用来检验进程的分解。
它显示出所有的进程,数据存储访问和输入输出数据流。
它也显示数据流流向和流出进程的外部实体。
一个联系图表经常被称为CRUD矩阵或进程/数据矩阵,用来连接数据和进程模型。
它有利于数据和进程的发现和访问。
它鉴别并解决矩阵冗余和冲突,有必要时提炼数据和进程模型。
它在实体中描述进程,显示出某进程在实体中创建,浏览,更新,删除实例。
这常被称为“实体生命周期分析”用来分析实体的产生和灭亡并且在实体的进程中执行。
分析首先确定实体中有一相连进程创建实例。
如果实体中没有相连进程则创建它,进程不存在必须被定义。
然后确定实体中有相连进程更新,浏览,删除实例。
如果一实体从未更新,浏览,删除,可能实体将灭亡。
2.技术复审测试逻辑设计
逻辑设计阶段用静态技术来验证,是不能执行的应用。
这些在需求阶段被利用的技术检测是否遵循规则说明和模块的完整性。
同样的静态测试技术检测逻辑设计阶段的需求。
被回顾的产品包括数据模型,过程模型以及产生、引用、更新、删除(CRUD,Create、Read、Update、Delete)CRUD矩阵。
逻辑设计阶段发现的每个错误都应该记录下来。
错误问题报告被设计用来以文件的形式记录这些错误。
它包括错误种类和错误类型。
每个错误的描述被记录在缺失,错误,或者额外的列中。
在逻辑设计回顾的列中错误被总结和汇总。
示例2给出了逻辑设计阶段错误记录表格的例子(了解更多细节见附录3.2,逻辑设计阶段的错误记录)。
3.精练系统/接受测试计划
系统测试是全方位的测试,用来评价系统的功能,性能和整个应用的适应性。
它说明系统是否符合原目标。
在需求阶段,没有足够的细节来定义这些测试类型。
逻辑设计提供大量关于数据和过程模型的信息。
在测试方法和策略部分,测试的范围和类型能被提炼出关于执行的测试级别的详细信息。
系统级测试的例子用来评价使用的合适程度,包括功能,性能,安全性,可用性以及兼容性。
测试方法,后勤以及退化的策略能在这部分中了解。
本小节此节的测试项目,例如测试工具,测试过程,测试管理,测试库和测试工具被应用。
软件配置管理要素的初步计划,例如版本,控制变化和配置构架可以开始制定。
还包括软件配置管理工具的获取如果组织中不存在它。
测试安装执行部分是关于测试准备中考虑的事项,它包括系统测试过程,测试设备,测试资源,测试工具计划和测试组织。
测试详细规则部分中,更多功能细节可从数据和过程模型以及添加的需求测试矩阵中了解。
此时,系统级测试用例设计开始。
然而,此时完成详细的测试过程如测试程序和细节还太早。
测试用例输入/输出与其他各个测试用例相连的数据值。
测试用例的接受在此阶段应被完成。
在测试程序部分,早期阶段开始的项目被提炼。
测试工具和测试进度中的测试项目开始进行。
3.3物理设计阶段
逻辑设计阶段将商业需求解释为系统规范,以便于程序员在物理设计和编码阶段使用。
物理设计阶段决定如何自动获得需求。
在此阶段中高曾设计被建立,基本的程序构件和他们的相互关系已经主要的数据表示被定义。
物理设计阶段形成系统的结构方面。
逻辑设计测试是功能性的,物理设计测试是结构性的。
此阶段验证设计的结构状况和文档需求的完成情况。
它假设需求和逻辑设计是正确的并且强调设计本身的整体性。
1.技术复审测试物理设计
逻辑设计阶段采用静态技术验证。
例如不可执行的应用。
在逻辑设计阶段和需求阶段,静态技术检查规则约束和完整性的联系,并集中于设计结构。
物理设计验证的基础是用于验证设计的设计表示方案。
设计表示方案的例子包括结构图表,Warnier-Orr图表,Jackson图表,数据导航图表和关系数据库表,这些在逻辑设计阶段被绘制。
设计表示方案提供算法检验和对软件模块的输入输出的机制。
通过模型验证数据控制流可能存在各种矛盾。
例如,一模型可能需要一特殊的由另一模型创造但不正确的数据项。
静态分析能被用来检测这些类型的控制流错误。
在物理设计阶段的其他错误也能被检测。
设计规范通过反复应用细节而创造。
尽管层次规范结构对于设计的表示是一个很好的机制,但它不允许层次结构的矛盾。
例如,耦合调节模块间的独立程度。
当两模块几乎没有关联,称为松散耦合。
当关系密切则为紧耦合。
松散耦合被认为是一种好的设计方法。
耦合的例子包括内容耦合,公共耦合,控制耦合,标记耦合,数据耦合。
内容耦合发生在一个模型改变另一模型的内部结构。
数据耦合是两模型的交流通过变量和数组,它们在模型间作为一个参数直接的传递。
静态分析技巧能决定耦合是否在。
设计表示的静态分析检测静态错误和语法错误。
语法错误涉及信息和数据分解,功能分解以及控制流。
每个在物理设计评价阶段发现的错误都应该记录,整理,归档并将正确的送到设计团队,同时在相关文档中对关于此错误的部分进行说明。
示一记录了一个简单的物理设计阶段的错误记录形式(参见附录3.3,物理设计阶段检测记录以了解更多详情)。
2.测试用例的集成创建
集成测试的目的时检查试结构和软件框架是否所有的软件组成接口合适。
系统的功能性正确不能保证,仅仅按设计来执行。
集成测试是检测由连接测试模块的单个程序单元产生的错误的过程。
它直到所有的单元通过单元规则知道何时执行时才开始。
集成测试开始于测试几个逻辑单元或并合并所有的单元于一个单独的整体测试。
因为整体测试主要关心单元集成十分合适,测试目标是确保它们整和,参数被传递和文件处理过程的正确性。
集成测试技术包括至顶向下,由下至上,夹层测试和线索测试
3.集成测试的方法
以下介绍建立集成测试用例的方法。
第一步:
确定单元接口.每个模块的程序设计者确定并记录模块单元的接口,主要包括下列内容:
•外部需求(通过从终端询问信息)
•外部输入(管理事务数据以待处理)
•外部填充(获取,更新,或在计算机文件中创造事务)
•内部填充(传递或接收其他逻辑处理单元的信息)
•外部显示(发信息到终端)
•外部输出(向输出设备或单元提供处理结果)
第二步:
协调接口间的完整性集成测试执行时,要根据测试模板的需要收集测试需要的数据,任何时候都要注意模块单元之间的协调。
例如,如果程序A传送数据给B,单元B应表示它已收到来自于A的输出。
在集成测试执行前要监测接口的协调性。
第三步:
创建集成测试条件一个或更多个测试条件被准备为了每个程序单元的完整性。
一个条件被创造时,测试条件的数目被记录在测试模版中。
第四步:
评价测试条件的整体集成接下来的问题列表将有助于指导被记录在整体测试模版上的整体测试条件的完整性。
此列表有助于决定是否为测试整体过程创建的条件是完整的。
1.集成测试是否要为下列选项设计查询:
a.记录测试?
b.文件测试?
c.查找测试?
d.批判/合并测试?
e.属性测试?
f.压力测试?
g.控制测试?
2.是否模块间所有接口都有效,能够保证一个模块的输出能被令一个接受到。
3.如果测试事务被开发,模块与所有那些指明的文件交涉了吗?
4.集成测试前每个单元的处理合法吗?
5.所有单元开发者是否同意集成测试条件对于每个单元的接口测试已足够?
6.是否所有的软件单元被包含在集成测试中?
7.软件使用的正在测试的所有文件被包含在整体测试中?
8.正测试的所有与软件相连的商业事务包含在整体测试中吗?
9.正被测试的所有合并的终端功能包含在集成测试之中吗?
集成测试文挡开始于测试规范部分。
同样在这部分功能的分解继续被提炼,但是系统级测试用例在此阶段应该完成。
简介部分的测试项目在此阶段完成。
测试方法和策略、测试开发、测试执行、测试工具、测试人员需求、测试进度安排等都要进一步精练。
3.4单元设计阶段
此设计阶段开发物理架构或者系统的结构方面。
程序单元设计阶段被提炼来帮助详细设计。
程序单元设计是详细设计,其中详细的算法被制定且数据结构被选择。
它是一典型的详细控制流使得用程序语言翻译程序代码更加容易。
1.技术复审程序单元设计测试
一个好的详细的单元测试是容易被翻译成各种程序语言的。
它使用结构化的技术例如while,for,repeat,if和用例结构器。
这些结构的例子被用在结构化的编程中。
结构化编程的目标是用低代价产生高质量的语言。
一个结构化的程序仅有三个基本的控制结构被使用。
(1)顺序
申明以同样的顺序依次执行当他们出现在资源列表中。
顺序的例子是任务申明。
(2)选择
被测试条件依赖于测试是否正确或错误,一个或更多的可选执行路径被实施。
一个选择的例子是if-then-else.通过此结构条件被测试,如果条件正确,一批指令被执行。
如果条件错误,另外一批指令被执行。
两个集合连接在同一点。
(3)循环
循环法用来循环的多次执行指令序列。
循环的例子有dountil和dowhile.一个dountil循环执行一系列的指令然后测试循环终端条件。
如果是正确的,循环中断继续到另一结构。
如果是错的,指令集再次被执行直到到达终端逻辑。
一个dowhile循环测试中断条件。
如果正确,控制传递到下一结构。
如果错误,指令集被执行直到控制无条件的回到条件逻辑。
详细设计的静态分析检测涉及信息和逻辑控制流的语义错误。
在设计被正式修正之前,所有单元测试中暴露出来的缺陷的修改记录、方法都应该归档。
示1显示一例子表示程序单元设计阶段的记录形式(参见附录3.4,程序单元设计阶段错误记录,以了解更多详情)。
2.创造单元测试用例
单元测试是执行软件系统功能子函数的过程,是为了决定是否它执行了被分配的功能。
单元测试用来检测函数或模块的。
白盒测试用例被建立并归档以使单元逻辑有效,黑盒测试用例用规范来测试单元(参见3.6,测试用例,作为测试用例形式的一例)。
在更正和重复测试时,单元测试,伴随着必要的版本控制,被开发者执行。
在单元测试有例开发期间,知道哪部分代码易或那部分不易受测试用例的影响是很重要的。
通过了解范围,开发者能发现一些代码行决不执行或程序功能不按规范执行。
当覆盖面不大时,执行系统是存在危险因为错误可能存在于未实验的代码中。
单元测试用例规范开始和归档在测试规范部分但是此节的所以其他项目应完成。
在前面介绍的测试方法和策略、测试执行安装、测试工具、个人资源等工作应先于单元测试阶段完成。
然而测试测试过程部分的项目继续被提炼。
功能的分解,集成,系统,以及接受测试用例应该在此部分完成。
在测试过程和测试进度安排中要进一步对前面提到的各项工作精练。
3.5编码阶段
程序设计阶段属于详细设计阶段,此阶段详细的算法和数据结构的选择被制定。
详细的控制流使得用程序语言设计的程序代码更易理解。
编码阶段是用程序语言来解释详细设计的可执行代码。
1.技术复审测试编码
编码阶段产生可执行资源模型。
好的编程基础是编程标准已经制定。
一些好的标准应该包含注释,非安全编程控制构造器,程序延时,防御性编程等等。
注释涉及程序应如何被注释极其程度和级别。
非安全编程结构使程序难以维持。
一个例子就是goto语句。
程序延时是标准程序应如何安排页面,控制构造器的缩排以及初始化。
防御性编程描述编程防御策略的托管元素。
应设计一个处理和控制一般错误的规范。
静态分析技术,如结构化的预排和观测,能够确保程序代码和文件的合适形式。
通过检测编码,文件规范和类型检测的一致性来完成静态分析。
在复审编码阶段发现的每个错误应该被归档,分类,记录并以正确的形式送往设计团队。
示1给出编码阶段错误记录形式的例子(参见附录3.5,编码阶段错误记录,以了解更多详情)。
2.执行测试计划
在这个阶段末,每一个测试计划的每部分的所有项目都应该被完成。
软件的实际测试通过在需求、逻辑设计、物理设计和程序单元设计阶段生成测试计划的测试数据而完成。
由于结果已经在测试用试及测试程序中详细定义,执行的正确性被通过静态测试的观点被确认。
也就是说测试是被人工地被检查。
动态测试,或依时间的技术,包括用计算机执行一系列指令序列。
这些技术用来研究代码功能性与计算的正确性。
动态测试以开发生命周期相反的顺序进行。
它开始于单元测试来独立地验证每一个程序单元。
然后进行集成测试,系统和接受性测试。
在接受性测试完成后,系统就可以用来操作与维护了。
3.单元测试
单元测试是测试的基本阶段。
单元测试单独着眼于一个程序或系统的小块。
此过程执行各个模块来确保每个都实现自己被分配的功能。
单元测试的优势是允许测试和调试小单元,因此提供了一个更好的方式来解决单元合成整体的整合性。
除此之外,测试更小的单元码使得用更小的测试来完全的测试代码的逻辑完全可能。
单元测试也方便自动测试,因为更小单元的行为能获得并且进行最大化的重复利用。
相关例子包括模型本身是一单元,图形用户界面(GUI,GraphicUserInterface)例如窗口,菜单,以及函数,一系列程序,在线程序和存储过程。
4.集成测试
单元测试完成之后,所以模块必须被集成测试。
在集成测试中,系统逐渐构建通过在已集成模型的核心上每次添加一个或更多模块。
系统测试发生前单元组已完全被测试。
既然模块的单元测试先于集成测试,他们能被认为是黑盒测试,允许集成测试集中于模块接口。
集成测试的目标是确保每个模块在控制结构中正确的执行,并且模块接口正确。
通过按步骤联合模块,增加的测试被执行。
每一个模块增加到程序结构中并且测试集中在新增加模块的可操作性上。
这意味着当一模块适当的运行在程序结构中时,另一模块被加进来,并且测试继续。
此过程被重复直到所有的模块被组装并测试。
5.系统测试
集成测试之后,系统作为一个整体被测试,检测它基于系统/接受测试计划的功能和使用合适度。
在接受测试之前,系统在计算机操作系统环境中被完全测试。
系统测试资源是质量的属性,在软件质量保证清单上被详细说明。
系统测试是一系列的测试用来保证这些质量的属性,确保接受测试的执行相对自由。
系统测试保证了功能执行的正确性。
它同时也使某些非功能特性存在。
一些例子包含可用性测试,性能测试,压力测试,兼容性测试,转化测试和文挡测试。
黑盒测试这项技术集中测试一个程序的功能性而不是规范性。
白盒测试技术中逻辑路径被测试来决定它们产生的结果有多好。
灰盒测试是两种方法的融合,经常用于系统测试。
它是两者的折中,是很好的平衡测试方法,被广泛使用于系统测试中。
6.接受测试
系统测试完成后进行的接受测试是要保证软件系统满足初始需要。
此测试应被执行当软件成功的完成系统测试。
接受测试是使用者运行的测试,它使用黑盒技术来测试系统而不是规范。
终端用户有责任确保所有相关的功能被测试。
接受测试计划定义了执行接受测试的过程,并且应该尽可能的依照。
接受测试继续执行,即使错误发生,除非错误本身阻止继续。
一些项目并不需要正式的接受测试,当时间需求满足时,或者当终端用户在开发周期一
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 part3