文章目录
- 前言
- 软件缺陷
- 软件开发的过程
- 软件测试
- 黑盒测试
- 等价类划分
- 判定表法
- 因果图法
- 边界值分析法
- 白盒测试
- 配置测试
- 兼容性测试
- 外国语言测试
- 易用性测试
- 自动化测试和测试工具
- 缺陷轰炸和beta测试
前言
由于本人拖延症严重而且成绩较差,所以才在考试结束将近一个星期后,将自己的复习笔记整理出来,不足以及错误之处烦请指出。
软件缺陷
软件缺陷是指软件产品中的某种错误、故障或失效,导致软件在运行时表现出不符合预期的行为或结果。
产品说明书简称为“产品说明”,是软件开发小组的一个协定,它对开发的产品进行定义,给出产品的细节,如何做、做什么、不能做什么。
以下有五种情形,它们都属于软件缺陷:
- 软件未实现产品说明书要求的功能;
- 软件出现了产品说明书指明不该出现的错误;
- 软件实现了产品说明书未提及的功能;
- 软件未实现产品说明书虽未明确提及的,但是应该实现的目标;
- 软件难以理解、不易使用、运行缓慢或者——从测试员的角度来看——最终用户认为不好。
可以简记为:欠缺功能、错误功能、多余功能、欠缺潜在功能、易用性差
少了,错了,多了,少了潜在,不好用都是软件缺陷。前四项与产品说明书有关,最后一项与用户有关。
软件缺陷产生的最大原因是产品说明书,余下的其他原因有:设计、编码等。
对软件开发来说,何时发现软件缺陷的意义是:发现的越晚,修复的代价越大,而且代价随时间增长是指数增加的。应该尽量将软件缺陷扼杀在产品说明书阶段。
软件测试员的工作目标是尽可能早地发现软件缺陷并确保它得到修复。
为什么正规的软件开发中必须有测试员承担测试工作而不能让开发工作和测试工作由程序员一并完成?
答:因为:
- 由于代码本来就是自己写的,测试时容易落入自己的思维定势,不易发现缺陷;
- 测试员和程序员的工作风格以及思维方式截然不同,很难同时适应两者;
- 开发工作和测试工作是同时进行的,不能等到开发工作结束再做测试,而一个人同时完成两种任务会严重影响效率;
- 容易产生道德风险,程序员倾向于掩盖自己的错误而不是揭露它们,从而不利于测试工作。
软件开发的过程
软件开发的过程描述了开发软件产品的成员做什么、如何交互、如何决策的细节。
在软件行业中,用于描述制造出来并交付他人的软件产品组件的术语是“可交付的部分”。
软件产品的一个关键部分是进度表。制定进度表的目的是了解哪项工作完成了,还有多少工作要做、何时全部完成。
常见的软件开发模式:大爆炸模式、边写边改模式、瀑布模式、螺旋模式、敏捷软件开发。
大爆炸模式是最简单的软件开发模式,它没有测试。
边写边改模式将反复进行,直至有人放弃。
瀑布模式的各步骤是分立的,没有交叉;瀑布模式无法回溯。
对于测试人员,瀑布模式的一个严重问题是:因为测试仅在最后进行,所以一些根本问题可能出现在早期,但是直到准备发布产品时才可能出现。
螺旋模式兼有几种模式的某些特点,是软件测试人员最喜欢的模式!
敏捷开发是目前最流行的快速软件开发模式,适合面向互联网应用的、中小型的软件项目。
软件测试与软件开发过程(V模型)
请介绍测试一个软件的全过程包括哪几个步骤?每一步如何来做?
答:第一步:制定测试计划;第二步:建立测试用例集合;第三步:做等价划分,缩减测试用例集合;第四步:执行测试用例;第五步:汇报测试结果。
软件测试
软件测试中的杀虫剂怪事是指:软件测试越多,软件缺陷对于测试的免疫力越强,无法被发现。
如何解决?测试员必须编写不同的、新的测试程序,使用新的测试技术来测试。
测试的原则
- 完全测试程序是不可能的
- 软件测试是有风险的行为
- 测试无法显示潜伏的软件缺陷
- 找到的软件缺陷越多,就说明缺陷越多
- 杀虫剂怪事——软件测试越多,软件缺陷对于测试的免疫力越强,无法被发现
- 并非所有的软件缺陷都需要修复
- 什么时候才叫缺陷难以说清
- 产品说明书从来没有最终版本
确认是保证软件符合产品说明书的过程;
验证是保证软件满足用户的需要的过程。
符合产品说明书的软件未必在实际中满足用户的需要,因为产品说明书可能有错误或者不完善。
冒烟测试是指在对一个新版本进行系统测试之前,先对软件的基本功能进行简单的测试。
单元测试是在软件开发过程中要进行的最低级别的测试活动,是针对软件设计的最小单位即程序模块、函数、类或方法所进行的正确性检验的测试工作。
系统测试是在整个系统投入运行之前,对系统的各元素进行组装和确认测试,确保在系统实际运行时软件、硬件、 外设、网络等系统元素能够相互配合并正常工作。
回归测试是当软件发生改变时,重新测试已经通过测试的测试区域,以验证修改的正确性及其影响。
黑盒测试也称为功能性测试或行为测试。
静态测试:指测试不运行的部分——只是检查和审核;
动态测试:是指通常意义上的测试——使用和运行软件。
没有产品说明书和需求文档的情况下能做黑盒测试。**这是因为尽管没有写产品说明书,但总有人知道产品是什么样的。**通过询问软件设计者和编制者可以测试没有写出来的产品说明书。
黑盒测试
常用的黑盒测试方法:
● 等价类划分法;期末考试考了
● 边界值分析法;
● 因果图分析法;期末考试考了
● 判定表法; 期末考试考了
● 状态迁移法;
等价类划分
对测试用例做等价划分的目的是缩减测试用例集合。
等价类划分方法把所有可能的输入数据,即程序的输入域划分成若干部分,然 后从每一部分中选取少数有代表性的数据做为测试用例。
等价类是指某个输入域的子集合。
有效等价类
:是指对于程序的规格说明来说,是合理的,有意义的输入数据构成的集合。
无效等价类
:是指对于程序的规格说明来说,是不合理的,无意义的输入数 据构成的集合。
等价类划分的目标是将可能的测试用例集缩减到可控制并且仍然足以测试软件小范围内。
其实总体上一共就分为两大步骤:
第一步:划分等价类
第二步:选取测试用例
具体来说就是分为三步:
第一步:1. 形成等价类表 2. 每一等价类规定一个唯一的编号
第二步:1. 设计一测试用例,使其尽可能多地覆盖尚未覆盖的有效等价类;重复这一步骤,直到所有有效等价类均被测试用例所覆盖。
第三步:1. 设计一新测试用例,使其只覆盖一个尚未覆盖的无效等价类;重复这一步骤,直到所有有效等价类均被测试用例所覆盖。
判定表法
判定表(Decision Table)是分析和表达多逻辑条件下执行不同操作的工具。
在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了,因为它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。
它反映输入与输出之间的关系,适用于软件功能测试。
举个简单的决策表例子:
如果一个软件的规格说明指出:
(1)当条件1和条件2满足,并且条件3和条件4不满足,或者当条件1、3和条
件4满足时,要执行操作1。
(2)在任一个条件都不满足时,要执行操作2。
(3)在条件1不满足,而条件4被满足时,要执行操作3。
那这个决策表应该这样画:
因果图法
因果图方法是一个非常有效的黑盒测试方法,它能够生成没有重复性的且发现错误能力强的测试用例,而且对输入、输出同时进行了分析。
从因果图生成的测试用例(局部,组合关系下的)包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加。
如果在设计阶段就采用了判定表,也就不必再画因果图,而是可以直接利用判定表设计测试用例了。
边界值分析法
边界值分析法是对等价类划分法的一种补充方法。
首先应确定边界情况。
- 列出单元功能、输入、状态及控制的合法边界值和非法边界值,对数据进行测试,检查用户输入的信息、返回结果以及中间计算结果是否正确。
- 通常输入和输出等价类的边界,就是应着重测试的边界情况。
- 应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,不是选取等价类中的典型值或任意值作为测试数据。
边界值选择原则:1. 边界条件 2. 次边界条件 3. 特殊值默认、空值、空白、零值和无 4. 无效数据
一个输入文件应包括1~255个记录,则测试用例可取1和255,还应取0及256等。
规格说明要求计算出“每月安全金扣除额为0至1165.25元”,其中测试用例可取0.00及1165.24、还可取-0.01及1165.26等。
最大值加1或最小值减1,例如:第一个减1,最后一个加1;开始减1,完成加1。
此外还有状态图法,场景法,正交实验法,本文不再详细探讨。
白盒测试
包括静态白盒测试和动态白盒测试,静态白盒测试的过程叫做正式审查,动态白盒测试常用的方法有:程序插桩技术、逻辑覆盖法、路径覆盖法。其中逻辑覆盖又可以分为以下几种:
- 语句覆盖
- 判定(分支)覆盖
- 条件覆盖
- 判定/条件覆盖
- 条件组合覆盖
基本路径测试则在下篇文章中详细讨论,重点是计算圈复杂度和确立独立路径集合。
配置测试
测试软件能否在不同的硬件上正常工作叫做配置测试。
关于配置测试:
- 一般情况下,都做配置测试,因为软件在某些硬件平台出现配置缺陷是常见的事情;
- 有配置缺陷的产品仍然可以发布,如果软件仅在很少见的硬件上发生缺陷;
- 保证软件产品在所有的硬件上都没有任何缺陷是不可能的;
兼容性测试
测试软件能否打开它的以前版本的文件属于兼容性测试。
测试软件能否与其他软件正确交换数据属于兼容性测试。
软件在某些操作系统平台上不能工作属于兼容性测试。
软件的不同版本之间的兼容性包括两种类型:向前兼容性和向后兼容性。
-
向前兼容性:Forward compatibility 例如:Windows3.1能兼容运行Windows10开发的程序,Windows3.1具有向前兼容性。
旧版本软件能够处理新版本生成的数据或文件。
-
向后兼容性:Backwards compatibility 例如:Windows10系统能兼容运行Windows3.1开发的程序,Windows10具有向后兼容性。又比如在开发Office 2007的时候,要考虑如何打开Office 2003的doc/xls/ppt文件,而不能仅仅只能打开docx/xlsx/pptx文件。
新版本软件能够处理旧版本生成的数据或文件。
如果有一个Windows平台上的字处理软件需要做兼容性的测试,请简单介绍一下大概有多少种的测试工作要做。
- 需要测试它在Windows的各个版本上工作是否正常;
- 需要测试它和其他的字处理软件,例如记事本、word之间的数据交换;
- 需要测试它和自己以前的版本之间的兼容性;
- 需要测试它是否满足Windows上的标准和规范,或者和通信协议之间的兼容性。
外国语言测试
易用性测试
对用户界面的测试属于易用性测试。
软件的易用性通常很难精确定义,现实中,可以采取替代方案:如果软件工作的平台上有相关的标准和规范,则遵照它们的规定。
以一个Windows上的复杂软件(含文档、图片及声音、视频混排功能)为例,如果对它进行配置测试、兼容性测试和易用性测试,请简介有哪些工作要做?
配置测试:在各种硬件及其组合上能否正常工作(CPU、内存、主板、显卡、声卡、打印机等),其中出问题可能性较大的是显卡和声卡;
兼容性测试:与操作系统平台(含各种版本)的兼容性;与自己以前的版本及以后的新版本的兼容性;与其他字处理软件交换数据是否正常;网络通信和磁盘文件存取是否正常;
易用性测试:**界面是否遵守该平台上的易用性标准和规范;界面是否美观;**某项功能是否容易找到对应的按钮或者菜单命令;操作是否简单易学、容易记忆、不易混淆;功能是否会步骤层次太多,难于返回上层;界面是否有多余的功能或者不必要的元素。
配置缺陷:软件在某种计算机硬件上不能正常工作;软件与某种打印机冲突,无法正常打印;
兼容性缺陷:软件与另一个软件交换数据出错
哪一种缺陷容易被beta测试所发现的缺陷:
- 配置缺陷
- 兼容性缺陷
- 易用性缺陷
自动化测试和测试工具
软件发布之前要经过多次重复代码——测试——修复的过程。
另一类自动化测试工具不是为帮助执行或者自动执行测试用例而设计的,其目标是模拟用户可能的操作。此类自动化测试工具叫做测试猴子。
缺陷轰炸和beta测试
共享测试任务的有趣方法是安排缺陷轰炸:在一段时间内(一般为几小时),整个测试小组停下常规的工作,参加轰炸——选择软件的某一区域,所有测试员集中测试这个区域或者这组特性。
beta测试:软件分发给选定的潜在客户群,让他们在实际环境中使用软件。
软件测试计划是测试员与产品开发小组交流意图的主要方式。
测试计划只是创建详细计划过程的一个副产品,重要的是计划过程,而不是产生的结果。
在报告软件缺陷时,测试员要对软件缺陷分类,以简明扼要的方式指出其影响,常用的分类是给软件缺陷划分严重性和优先级。
严重性:软件缺陷的恶劣程度,当用户碰到该缺陷时影响的可能性和程度。
优先级:修复缺陷的重要程度和紧迫程度。
打开状态:当软件缺陷首先被软件测试员发现时,被记录报告并指定给程序员修复态。
解决状态:一旦程序员修复了代码,报告又回到测试员手中。
关闭状态:测试员执行验证测试,确认软件缺陷确实得以修复,如果是,就把软件缺陷关闭。
回归缺陷:原来认为已经修复、测试和关闭的缺陷可能会再次出现,这样的缺陷叫做回归缺陷。
质量是免费的,制造高质量的产品实际上不需要额外开销。
质量的费用可分为两类:一致性费用和非一致性费用。
一致性费用指与**一次性计划和执行测试相关的全部费用,**用于保证软件按照预期方式运行。
如果发现了软件缺陷,必须花时间分离、报告和回归测试以保证其得以修复,则非一致性费用就会上涨。
因为软件缺陷在软件发布之前发现,所以这些费用归属于内部失败。
如果软件缺陷被遗漏并落到客户手中,就是代价昂贵的产品支持电话,可能还要修复、重新测试 和发布软件——更糟糕的情况下,产品要召回或者卷入官司。这些也是不一致费用,属于外部失败。
由于内部失败引起的一致性费用加上非一致性费用小于由外部失败引起的非一致性费用。
质量保证人员**:主要职责是检查和评价当前软件开发的过程,找出改进过程的方法,以达到防止软件缺陷出现的目的。**
QA团队的任务是保证产品具有高质量!
重复测试:不断执行同样的操作。主要目的是检查是否存在内存泄漏。
压迫测试:使软件在不够理想的条件下运行——内存小,磁盘空间少、CPU速度慢、调制解调器速率慢等,观察软件对外部资源的要求和依赖程度。
重负测试:与压迫测试相反,尽量提供条件任其发挥,让软件处理尽可能大的数据文件。时间也是一种重负测试。