逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析
单元测试是对软件基本组成单元进行测试,
这里的基本单元不一定是指一个具体的函数
(
Function
或
Procedure
)
或一个类的方法,
“
单元
”
具有一些基本属性,
如:
明确的功能、
规格定义,明确的接口定义,可清晰地与同一程序的其它单元划分开来。
在纯
C
语言的代码中,为了操作方便期间,我们一般认为一个函数就是一个单元。
1.2.2
单元测试的主要目的:
1.
验证代码是与设计符合的
2.
跟踪需求和设计的实现
3.
发现设计和需求中存在的错误
4.
发现在编码过程中引入的错误
1.2.3
何时开展单元测试
一般地,
在编码阶段就应开展单元测试,
边写程序边测试是一个好习惯。
一个组织不要
孤立的划分出编码和单元测试两个阶段,也不要等代码都写完了才开始单元测试。
有时候需要将单元测试时间推后到集成阶段,甚至系统完成阶段。
单元测试可以分为计划、设计、实现、执行几个阶段。
“
计划
”
是作好人和时间的安排。
“
设计
”
确定采用什么样的测试方法,
达到一个什么样的覆盖率标准等。
“
实现
”
是设计生成各
个测试用例。
“
执行
”
包括驱动和桩函数的设计实现,测试数据准备,测试结果验证等等。
”。
你要在测试策略中很明确的提出你进行测试时所使用的方法和步骤。 我看到过很多公司严格地按照一些测试策略模板来写。
但是,其实不用模板,你也可以并且更高效地写测试策略。下面是一些简单的写测试策略的技巧, 1)在测试策略中要包括产品的背景信息。
在测试策略文档的第一段回答- stakeholder(项目利益相关者)为什么要开发这个产品?回答这个问题会帮助你更好更快地理解项目,并为所做的事情优先级排序。 2)测试环境,它应该包括你在那个操作系统平台上做测试,系统是基于那些补丁和安全更新。
例如,一个测试环境可能必须包含Window XP SP2 3)列出你将要测试的所有重要特征。如果你认为有些特征不属于本次发布的一部分,那么就标注“不会被测试的特征”。
4)写下在此项目测试中将应用到的测试方法。清楚的列出你将以那些类型的测试作为测试引导。
例如:功能测试,用户交互界面测试,集成测试,压力测试,安全测试等等。 5)回答以下问题:你如何进行功能测试?手动还是自动化?测试工具是什么?你将执行在测试管理工具中的所有测试用例吗? 6)用什么作为测试错误报告跟踪工具?当测试人员发现一个新的bug之后,流程应该是什么? 7)测试进入和结束的标准分别是什么? 8)如何去跟踪测试进度?什么度量可以用来记录测试结束? 9)任务分布 – 定义每个组员的角色和职责,包括测试组长,测试员,项目经理等。
测试战略将由开发人员review,确保测试的覆盖率全面且没有重叠处。测试经理和部门经理都要同意测试策略之后,测试工作才能展开。
测试小组的划分及分工。 10)有哪些风险会阻碍测试的完成?例如,代码的依赖性,测试工具的局限性等等。
要提前想到风险发生的解决办法。 11)测试日程表- 每个测试计划都应该包含一个预估时间来估计完成测试所需要的时间。
这需要几个阶段:一,测试人员必须至少完成一次的执行全部用例。二,如果一个错误被测试人员发现,开发人员将修复此错误。
测试员重新测试此用例,直到其功能正确为止。最后,但很重要的一点是测试员必须对修改过的地方执行回归测试以保证开发人员在修复一个错误的时候没有引入另外的代码错误。
测试日程表要包含每个测试部分涉及的测试人员。时间往往很难估计,因为测试中有很多不确定性的事情发生。
其中一个比较好的办法是参照前一个发布来估计。 12)回归测试的方法- 一个错误被修复后,必须要保证产品功能按用例标准运行。
回归测试是为了在修复一个问题时不引入另外的错误。因此相关的测试用例要在被执行一次,从而确保没有特殊的东西被引进。
在这个阶段,就要定义回归测试的方法。有的公司讲相关模块的单元测试用例全部遍历一遍,从而确保产品的质量。
弄清楚这些问题,你就可以写一个详细的测试策略出来了。
软件测试的方法根据软件工程的组织和实现方式,有很大差别,有些是比较技术化的方法,有些则是工程方法,主要分为: 黑盒测试方法群:等价类划分、边界值、因果图、基路径法、专家测试法、smoking、场景测试等 白盒测试方法群:同行评审、需求审查、代码审查、接口测试(调用测试和返回测试,需要结合等价类和因果图方法)等。
当在单元层面黑盒而在集成层面白盒时,基本上两类方法就会有结合了,就会出现习惯上说的灰盒测试(说实话,不做到纯产品级开发,基本上都是用的灰盒测试)。
软件测试计划是指导测试过程的纲领性文件,包含了产品概述,测试策略,测试方法,测试区域,测试配置,测试周期,测试资源,风险分析等内容;借助软件测试计划,参与测试的项目成员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。
测试计划和测试用例间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围,方法和资源配置;而测试用例是完成测试任务的具体战术。
测试计划中,最重要的是测试策略和测试方法。
测试计划工作的关键是
1. 明确测试的目标,增强测试计划的实用性---测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具具有较高的实用性,便于使用,生成的测试结果直观准确。
2. 坚持“5W”规则,明确内容与过程
“5W”规则指:what,why,when,where,how;用例5w规则创建软件测试计划,可帮助测试团队理解测试目的(why),明确测试范围和内容(what),确定测试开始和结束日期(when),指出测试的方法和工具(what),给出测试文档和软件存放位置(where)3. 采用评审和更新机制,保证测试计划满足实际需求
测试策略描述测试工程的总体方法和目标。
描述目前在进行哪一阶段的测试(单元测试、集成测试、系统测试)以及每个阶段内在进行的测试种类(功能测试、性能测试、覆盖测试等)。
测试策略的制定主要包含三个方面的内容:
(1)确定测试过程要使用的测试技术和工具;
(2)制定测试启动、停止、完成标准;
(3)进行风险分析和应对方案。例如测试与外部接口或者模拟物理损坏、安全性威胁。测试计划最关键的一步就是将软件分解成单元,按照需求编写测试计划。
扩展资料。
测试英文名Test、Measure;中文拼音cè shì;由中文"测"与中文"试"两个字组成的词语。
是动词、名词。
测试行为,一般发生于为检测特定的目标是否符合标准而采用专用的工具或者方法进行验证,并最终得出特定的结果。
测试策略
Test Strategy;test policy;testing strategy
例句:
文章主要讨论了编码完成后的方法的测试和类的测试,并分别给出了测试策略。
This paper discusses both the method testing and the class testing after finishing the coding.
而后,测试策略也将必须遵循测试管理框架。
Following this, the testing strategy will also have to follow the test management framework.
有了决策表,我们就可以根据测试策略轻松的添加和删除条件。
With a decision table, it is easy to add and remove conditions, depending on the test strategy.
软件测试策略把软件测试用例的设计方法集成到一系列已经周密计划过的步骤中去,从而使得软件的开发得以成功的完成。
同样重要的是,软件测试策略为软件开发人员、质量保证组织、和客户提供了一个路线图——这个路线图描述了测试的步骤,以及当这些步骤在计划和实施的过程中,需要多少工作量、时间、和资源。 因此,任何测试策略都必须和测试计划、测试用例设计、测试执行、还有测试结果数据的收集与分析结合在一起。
一种软件测试策略应当具备足够的灵活性,这样在必要的时候它能够有足够的创造性和可塑性来应付所有的大软件系统。与此同时,软件测试策略还必须保证足够的严格,这样才能保证对项目的整个进程进行合理的计划和跟踪管理。
Shooman[SHO83]对这个问题进行了探讨: 在许多情况下,测试是一个独立的过程,不同的测试类型的数量和不同的开发方法是一样多。许多年以来,我们对付程序出错的唯一武器就是谨慎的设计,以及程序员个人的智慧。
我们现在处于这样的一个时代——现代设计技术(和正式的技术复审)正在帮助我们减少代码中存在的初始错误。 类似地,不同的测试方法正在开始聚合为有限的几种方法和思想。
这些方法和思想就是我们所说的策略。在第16章中,我们已经介绍了软件测试技术①。
在本章中,我们将会把注意力放在软件测试策略上。
声明:本网站尊重并保护知识产权,根据《信息网络传播权保护条例》,如果我们转载的作品侵犯了您的权利,请在一个月内通知我们,我们会及时删除。
蜀ICP备2020033479号-4 Copyright © 2016 学习鸟. 页面生成时间:2.836秒