软件测试的目的
-
软件测试的目的是为了发现错误而执行程序的过程
-
测试是为了证明程序有错,而不是证明程序无错
-
好的测试用例在于发现至今未发现的错误
-
一个成功的测试时发现了至今未发现的错误的测试
- 注意:测试不仅仅是为了找出错误,通过错误产生的原因和错误分布的特征,可以帮助项目管理者发现当前所采用的软件过程的缺陷,以便改进。同时通过分析也可以帮助我们设计有针对性的检测方法,改善测试的有效性。
- 没有发现错误的测试也是有价值的,完整的测试时评测质量的方法,详细而严谨的可靠性增长模型可以证明这一点,例如Bev Littlewood发现,一个经过测试正常运行n小时的系统有继续运行n小时的概率。
验收测试
-
分为α、β、正式验收测试
-
α测试时内侧版本,即现在所说的cb,此版本仅仅是一个初步完成品,通常只在开发者内部交流,α测试的目的是评价软件产品的FLURPS (即功能、局域化、可用性、可靠性、性能、支持)尤其注重产品的界面和特色。α测试即为非正式验收测试
-
Beta是公测版本,是对所有用户开放的测试版本。该版本相对于α 版已有了很大的改进,消除了严重的错误, 但还是存在着一些缺陷,需要经过大规模的发布测试来进一步消除。这一版本通常由软件公司免费发布, 用户可从相关的站点下载。通过一些专业爱好者的测试, 将结果反馈给开发者, 开发者们再进行有针对性的修改。
-
Gamma版本,指的是软件版本正式发行的候选版。该版本已经相当成熟了, 与即将发行的正式版相差无几, 成为正式发布的候选版本。
正式验收测试是一项管理严格的过程,它通常是系统测试的延续。在某些组织中,开发组织(或其独立的测试小组)与最终用户组织的代表一起执行验收测试。在其他组织中,验收测试则完全由最终用户组织执行,或者由最终用户组织选择人员组成一个客观公正的小组来执行。
缺陷的属性
- 缺陷标识:缺陷标识是标记缺陷的一组符号,每个缺陷必须有一个唯一的标识。
- 缺陷类型:缺陷类型是根据缺陷自然属性划分的缺陷种类,
- 缺陷严重程度:是指缺陷的引起的故障对软件产品的影响程度。
- 缺陷优先级:指缺陷被修复的紧急程度
- 缺陷状态:指缺陷通过跟踪修复过程的进展情况
- 缺陷起源:指缺陷引起的故障或第一次被检测到的阶段。
- 缺陷来源:指引起缺陷的起因
- 缺陷根源:指发生错误的根本原因。
软件测试分类
-
从是否关心内部结构和具体现实分
- 分为黑盒测试
- 白盒测试
- 会和测试
-
从是否执行被测软件:
- 静态测试
- 动态测试
-
从软件开发各阶段分
- 单元测试
- 集成测试
- 确认测试
- 系统测试
- 验收测试
确认测试
- 在完后集成测试后,验证软件功能和性能及其他特性是否满足用户要求,目的是保证系统按照用户预期要求工作,通常采用黑盒测试。
软件测试的生命周期
- 1、新建(new)
- 2、打开(open)在测试者提交一个缺陷后,测试组长确认其确实为缺陷会把它置为打开阶段
- 3、指派、分配( assign)一旦缺陷被置为打开,会把缺陷交给相应的开发人员或开发组,这时状态变为“分配”
- 4、测试(text)当开发人员修复缺陷后,会把缺陷提交给测试组进行新一轮测试
- 5、延迟(deferred)缺陷状态被置为“延迟的”意味着缺陷将在下一个版本进行修复,将缺陷置为延迟原因有很多,有些由于缺陷有现金不高,或时间紧。
- 6.不接受的(rejected)如果开发不认为是一个缺陷,他会不接受,并将状态置为“不接受的”
- 7、重复提交(duplicate)如果一个缺陷被重复提交两次,或两个缺陷表明意思相同,那么缺陷状态将被置为“重复提交”
- 8、已核实(verified)缺陷一旦被修复就会置为“测试”,测试人员会执行测试,如果缺陷不再出现就说明缺陷被修复,同时状态被置为已核实。
- 9、再次打开(reopened)若缺陷被修复后仍然存在,测试人员会将状态置为再次打开。
- 10、关闭(close)缺陷一旦被修复,测试人员会进行测试,如果缺陷不存在了,会把缺陷状态置为关闭。
测试用例
什么是测试用例?
- 测试用例是指为特定目的设置的一组测试条件、预期条件、预期结果,测试用例是执行测试的最小实体,他是测试工作的核心,是一组在测试时输入、输出的标准、是软件需求的具体对照。
测试用例的主要元素
- 标识符:唯一标识每一个测试用例
- 测试项:准确描述需要测试的项目及其特征
- 测试环境要求:表示执行测试用例的测试环境
- 输入标准:执行测试用例的输入要求(这些输入可能包括数据文件、或者操作)
- 输出标准:按照输入环境和输入标准得到的期望预期结果。
- 测试用例之间的联系:标识该测试用例与其他测试用例之间的关系
设计测试用例的设计过程
- 分析系统工作的流程
- 确定并制定测试用例
- 确定测试用例的数据
- 测试用例的修改和更新
- 测试用例修改的原因:
- 在测试过程中发现测试用例考虑不周
- 在软件交付后反馈的软件缺陷,而缺陷又是由测试用例存在漏洞引起的
- 软件自身功能更新以及软件版本更新,测试用例也要配套更新
黑盒测试
黑盒测试又称功能测试,他通过检测软件功能是否能正常使用,在测试中,把软件当做打不开的盒子,在完全不考虑程序内部结构和内部特征的情况下,在程序接口进行测试,他只能检测程序是否按照程序规格说明书运行,程序能否适当接收输入数据产生正确的输出信息。
黑盒测试主要着眼于程序外部结构,不考虑程序内部逻辑。主要针对软件界面,软件功能进行测试。
别名:功能测试、数据驱动测试、基于规格说明书测试。
优点:
- 从产品功能进行测试
- 适用于测试各个阶段
- 容易上手生成测试数据
缺点: - 如果规格说明有误无法发现
- 某些代码得不到测试
- 不易进行充分测试
黑盒测试的主要方法
- 概述:从理论山讲,黑盒测试只有采用穷举输入测试,把所有输入条件都作为测试情况考虑,才能查出程序的所有错误,实际上测试数据有无数多个,不仅要进行所有合法输入,而且要对不合法但可能输入的条件进行输入,这样看来完全测试时不可能的,所以我们要进行有针对的测试。通过测试案例指导测试的实施 保证测试有组织、按步骤有计划的实施。黑盒测试的行为必须加以量化,才能保证软件的质量。而测试用例就是将测试方法量化的方法之一。
- 具体黑盒测试方法包括
- 等价类划分法
- 边界值法
- 错误推导法
- 因果图法
- 决策表法
- 场景法
- 正交测试法
白盒测试
静态测试
动态测试
未完——
软件的生命周期
一个软件的生命周期包含:
- 制定计划
- 需求分析
- 软件设计
- 程序编码
- 软件测试
- 软件运行
- 软件维护
- 软件停用 8个阶段
软件测试的生命周期
- 测试计划
- 测试设计
- 测试执行
- 测试总结
软件测试的5w1h
- what 测试什么
- why/which 为什么做/输入什么数据
- where 在哪做
- who 谁来做
- when 什么时候测试
- how 怎样进行测试
测试5c原则
- correct(准确)每个组成部分描述准确不会产生误解
- clear(清晰)每个组成部分清晰,易于理解
- concise(简洁)只包含必不可少的信息 不包含多余的信息
- complete(完整)包含该复现的完整步骤和其他本质信息
- consistent(一致)按照一致的格式书写全部缺陷报告
制定测试计划的目的
- 为测试各项活动制定一个现实可行、综合的计划,包括每项测试
活动的对象、范围方法、进度、预期结果。 - 为项目建立一个组织模型,并定义项目中每个角色的责任和工作内容
- 开发有效的测试模型,能正确的检验正在开发的软件系统
- 确定测试需要的时间和资源,以保证其可获得性有效性
- 确定每个测试阶段的标准、要完成的标准
- 是被测试活动的风险,并消除存在的风险,降低不可能消除风险所带来的损失。
测试计划包含的元素、内容要素
- 测试的范围
- 测试的策略
- 测试的需求
- 测试的资源要求
- 测试的人员要求
- 测试的进度
- 停止测试的标准
- 测试用例设计方法
- 测试中潜在的风险和问题区域
- 角色职责
为什么要进行软件测试?软件测试的目的是什么?
- 因为软件也是一种产品,是产品就应该经过测试菜可以流通上市,所以软件产品也需要测试是无可厚非的,在项目生命周期中,测试是给软件把关的重要环节。
- 软件测试的目的是为了发现错误而执行程序的过程
- 测试是为了证明程序有错,而不是证明程序无错
- 好的测试用例在于发现至今未发现的错误
- 一个成功的测试时发现了至今未发现的错误的测试