校园论坛网站建设论文/重庆高端品牌网站建设

目录

软件测试概念、背景

软件测试员究竟做些什么

大多数软件测试员应该具备的素质

软件测试的实质

完全测试程序是不可能的

测试无法显示潜伏的软件缺陷

并非所有软件缺陷都要修复

软件测试员在产品小组中不受欢迎

术语：精准和准确

产品说明书的测试技术

产品说明书属性检查清单

产品说明书术语检查清单

测试分类

黑盒测试和白盒测试

静态测试和动态测试

动态黑盒测试

通过性测试和失效性测试

等价类划分

数据测试

边界条件

次边界条件

默认.空白、空值.零值和无

非法、错误.不正确和垃圾数据

状态测试

---

软件测试概念、背景

软件无处不在。然而，软件是人写的一所以不完美。

世界上有完美的软件吗？NO

世界上没有完美的软件。所有软件都可能存在缺陷、错误或漏洞，无论是操作系统、应用程序、游戏还是其他类型的软件。这些问题可能会导致功能问题、性能下降、安全漏洞或崩溃。

软件通常是由人类编写的，而人类是不完美的，因此软件也会反映出这种不完美性。即使经过严格的测试和质量控制，软件也可能在某些情况下出现问题。因此，软件的开发者通常会持续改进和更新软件，以修复问题、增加新功能和提高性能。

安全性也是一个重要问题，因为恶意软件可以利用软件的漏洞来攻击计算机系统。因此，不断更新和维护软件是保持其安全性和稳定性的关键。

总之，虽然软件可以非常出色，但没有软件可以被称为完美。它们都有潜在的问题，因此用户和开发者都需要不断努力来改进和维护软件。

软件测试是一项批判性的工作。随着当今软件的规模和复杂性日益增加，进行专业化、高效的软件测试的要求越来越迫切。太多的事情处于危机中，我们不需要更多的计算机缺陷芯片，更多崩溃的系统，更多被盗的信用卡账户。

软件测试员究竟做些什么

软件测试员的目标是尽可能早地找出软件缺陷，并确保其得以修复。

大多数软件测试员应该具备的素质

●他们是群探索者。软件测试员不会害怕进入陌生环境。他们喜欢拿到新软件，安装在自己的机器上，观看结果。

●他们是故障排除员。软件测试员善于发现问题的症结。他们喜欢解谜。

●他们不放过任何蛛丝马迹。软件测试员总在不停地尝试。他们可能会碰到转瞬即逝或者难以重现的软件缺陷。他们不会当做是偶然而轻易放过，而会想尽一切可能去发现它

们。

●他们具有创造性。测试显而易见的事实，对软件测试员来说还不够。他们的工作是要设想出富有创意甚至超常的手段来寻找觖陷。

●他们是群追求完美者。他们力求完美，但是当知道某些无法企及时，不去苛求，而是尽力接近目标。

●他们判断准确。软件测试员要决定测试内容、测试时间，以及看到的问题是否是真正的缺陷。

●他们注重策略和外交。软件测试员常常带来的是坏消息。他们必须告诉程序员，你的孩子(程序)很丑。优秀的软件测试员知道怎样策略和职业地处理这些问题，也知道如何和不够冷静的程序员合作。

●他们善于说服。软件测试员找出的缺陷有时被认为不重要，不用修复。测试员要善于清晰地表达观点，说明软件觖陷为何必须修复，并推进缺陷的修复。

软件测试的实质

完全测试程序是不可能的

软件测试新手可能认为，可以在拿到软件后进行完全测试，找出所有的软件缺陷，确保软件完美无缺。遗憾的是，这是不可能的，即使最简单的程序也不行，主要有如下4个原因:

●输入量太大。

●输出结果太多。

●软件执行路径太多。

●软件说明书是主观的。可以说从旁观者来看是缺陷。

测试无法显示潜伏的软件缺陷

例子：检查房间发现了虫子，那你可以说“这间房子一定有虫子”。但是，如果检查房间之后，没有看到虫子，你能肯定的说“这间房子一定没有虫子”吗？当然不能。

软件测试 可以报告软件缺陷存在，却不能报告软件缺陷不存在。你可以进行测试，发现并报告软件缺陷，但是任何情况下都不能保证软件缺陷没有了。唯一的方法是继续测试，可能还会找到一些。

并非所有软件缺陷都要修复

在软件测试中令人沮丧的是，虽然测试员尽了最大的努力，但并非找出的所有软件缺陷都要修复。不要泄气一这 并不意味着软件测试员未达到目的，或者项目小组将发布质量欠佳的产品。项目小组需要进行取舍，根据风险决定哪些缺陷要修复，哪些不需要修复。

不需要修复软件缺陷的原因有几个:

●没有足够的时间。在任何一个项目中，通常是软件功能太多，而代码编写人员和软件测试人员太少，而且进度中没有留出足够的空间来完成项目。假如你应在制作税务处理程序，4月15日(赶在应付税务检查之前一 译者注)是不可更改的交付期限一-必须按时完成软件。

●不算真正的软件缺陷。也许有人会说:“这不算软件缺陷，而是-项功能。”很多情况下，理解错误、测试错误或者说明书变更会把可能的软件缺陷当做功能来对待。

●修复的风险太大。遗憾的是，这些情形很常见。软件本身是脆弱的、难以理清头绪，有点像一团乱麻，修复一个软件缺陷可能导致其他软件缺陷出现。在紧迫的产品发布进度压力下，修改软件将冒很大的风险。不去理睬已知的软件缺陷，以避免造成新的、未知的缺陷的做法也许是安全之道。

●不值得修复。虽然有些不中听，但是事实。不常出现的软件缺陷和在不常用功能中出现的软件缺陷是可以放过的,可以躲过和用户有办法预防或避免的软件缺陷通常不用修复。这些都要归结为商业风险决策。

软件测试员在产品小组中不受欢迎

哈哈哈，这段还是蛮有意思的。

还记得软件测试的目标吗?

软件测试的目标是尽可能早地找出软件缺陷，确保其得以修复。

软件测试员的工作是检查和批评同事的工作、挑毛病、公布发现的问题。唉，做这项工作不会受普遍的欢迎的!

下面是保持小组成员和睦的建议:

●早点找出缺陷。这是软件测试员理所当然的工作，但是做到很难。在三个月之前而不是在产品即将发面前夕找出严重的软件缺陷，会产生更小的影响，更容易让人接受。

●控制情绪。诚然,软件测试员真心喜爱自己的工作，当发现严重的软件缺陷时非常兴奋。但是，如果兴冲冲地闯进程序员同事的房间告诉他程序代码中存在可怕的缺陷时，他是不会高兴的。

●不要总是报告坏消息。假如发现某段代码没有软件缺陷，就大声宣扬。花一点时间找程序员聊聊天。如果总是报告坏消息，别人对你就会惟恐避之不及。

术语：精准和准确

软件测试要精度还是准度很大程度上取决于产品是什么，最终取决于开发小组的目标(请恕直言)。计算器软件需要两者都达到一正确的答案就是正确的答案，错误的就是错误的。但是，可能会决定计算只精确到五位十进制数，那么，精度可以有所偏差。只要软件测试员清楚产品说明书，就可以量身定做测试程序来确认。

产品说明书的测试技术

产品说明书属性检查清单

经过深思熟虑，可称为“一字不漏”的优秀产品说明书应具有8个重要的属性:

●完整。是否有遗漏和丢失?完全吗?单独使用时是否包含所有内容?

●准确。既定解决方案正确吗?目标定义明确吗?有没有错误?

●精确、不含糊、清晰。描述是否一清二楚?是否有单独的解释?容易看懂和理解吗?

●一致。产品功能描述是否自相矛盾，或与其他功能有无冲突?

●贴切。描述功能的陈述是否必要?有没有多余信息?功能是否符合原来的客户要求?

●合理。在规定的预算和进度下，以现有人力、工具和资源能否实现?

●代码无关。产品说明书是否坚持定义产品，而不是定义其软件设计、架构和代码?

●可测试性。功能能否测试?给测试员提供的建立验证操作的信息是否足够?

在测试产品说明书、阅读文字、检查图表时，要仔细对照_上述清单，看看它们是否具有这些属性。如果不具备，那就是发现了需要指出的缺陷。.

产品说明书术语检查清单

在审查产品说明书时，作为前一个清单的补充，还有一个问题用语检查清单。问题用语通常表明功能没有仔细考虑一可能归结于前文所述的某一属性。从产品说明书中找出这样的用语，仔细审查它们在上下文中是怎样使用的。产品说明书后面可能会阐明或掩饰，也可能含糊其辞一无论是哪种情况，都可视为软件缺陷。

●总是、每一种、所有、没有、从不。如果看到此类绝对或肯定的描述，需要确认是这样

的。软件测试员要考虑违反这些情况的用例。

●当然、因此、明显、显然、必然。这些话意图说服你接受假定情况，不要中了圈套。

●某些、有时、常常、通常、惯常、经常、大多、几乎。这些话太过模糊。 “有时”发生,作用的功能无法测试。

●等等、诸如此类、依此类推、例如。以这样的词结束的功能清单无法测试。功能清单要

绝对或者解释明确，以免让人对功能清单内容产生迷惑。

●良好、迅速、廉价.高效、小、稳定。这些是无法量化的术语，它们无法测试。如果说

明书中出现这些用语，必须进一步准确定 义其含义。

●处理，进行，拒绝，跳过,排除。这些用语可能会隐藏大量需要说明的功能。

●如.... 那么..... (没有否则)。 找出有“如...那么..”.而缺少配套的“否则”结构的陈述。想想“如果”没有发生会怎样。

测试分类

黑盒测试和白盒测试

软件测试员用于描述测试方式的两个术语是黑盒测试(black-boxtesting)和白盒测试(white-box testing)。

在黑盒测试中，软件测试员只需知道软件要做什么一而 无法看到盒子里的软件是如何运行的。只要进行一些输入，就能得到某种输出结果。他不知道软件如何运行、为什么会这样，只知道程序做了什么。

在白盒测试(有时称为透明盒测试(clear- box testing))中，软件测试员可以访问程序员的代码，并通过检查代码的线索来协助测试-可以看到盒子里面。 测试员根据代码检查结果判断或多或少可能出错的数目，并据此定制测试。

静态测试和动态测试

描述软件测试的另外两个术语是静态测试(static testing)和动态测试(dynamic testing)。

静态测试是指测试不运行的部分一只是检 查和审核;

动态测试是指通常意义上的测试一-使用和运行软件。

对这些术语最好的一个类比是

        检查二手汽车的过程。踢一下轮胎、 看看车漆、打开引擎盖检查都属于静态测试技术。

        发动汽车、昕听发动机声音、上路行驶都属于动态测试技术。

动态黑盒测试

不深入代码细节测试软件的方法称为动态黑盒测试。它是动态(dynamic) 的，因为程序在运行----软件测试员像用户一样使用它;

同时，它是黑盒子(black-box), 因为测试时不知道程序如何工作----带上 了眼罩。测试员输入数据，接受输出、检验结果。动态黑盒测试常常被称为行为测试，因为测试的是软件在使用过程中的实际行为。

清楚了被测试软件的输人和输出之后，接下来要开始定义测试用例(test case)。

测试用例是指进行测试时使用的特定输人，以及测试软件的过程步骤。

通过性测试和失效性测试

测试软件有两种基本方法:

通过性测试(test-to-pass) 和失效性测试(test-to-fail).

在进行通过性测试时，实际上是确认软件至少能做什么，而不会考验其能力。软件测试员并不需要想尽办法让软件崩溃，仅仅运用最简单、最直观的测试用例。既然软件测试的目标是找出软件缺陷，为什么还要进行通过性测试呢?为什么不尽量去设法找出软件缺陷呢?不，开始不是这样的。

原因就是：从简单的开始测试，就像测试一辆刚生产的汽车，肯定是先上去开一下看能不能启动，而不是一上去就尽全力的高速的开，这样容易出问题。

确信软件在普通情况下能正确运行之后，就可以采取各种手段搞垮软件来找出软件缺陷了。纯粹为了破坏软件而设计和执行的测试用例称为失效性测试或错误强制测试。

失效性测试通常不会突然出现。虽然看起来与通过性测试差不多，但是它是蓄意攻击软件的薄弱环节。

等价类划分

等价类划分是一种测试设计技术，用于将测试数据分成不同的等价类，以便在测试过程中更有效地覆盖不同的情况。这种方法通常用于软件测试，以确保对不同情况的测试覆盖足够广泛，同时避免冗余的测试用例。等价类划分有助于提高测试的效率，同时确保系统的可靠性和质量。

等价类划分的基本思想是将输入值分为几个等效的类别，以便在每个类别中执行相同的测试操作，因为可以合理地假设，如果测试一个类别中的一个值，那么测试其他类别中的值应该产生相似的结果。通常，等价类划分包括以下步骤：

1. 识别输入：首先，确定要测试的系统或组件的输入。这可以是函数、方法、或系统接受的任何形式的输入数据。
2. 确定等价类：将所有可能的输入值分成不同的等价类，每个等价类中的值都应该产生相似的结果。等价类通常是基于输入数据的特征和属性来划分的。例如，如果测试一个要求输入年龄的系统，等价类可以是儿童、青少年和成年人。
3. 选择代表性值：对于每个等价类，选择一个或多个代表性的值来进行测试。这些代表性值通常是类别中最有代表性或最具挑战性的值。
4. 设计测试用例：为每个等价类设计测试用例，以验证系统对该类别中的输入的处理方式。测试用例应该包括输入数据、预期的输出或行为，以及执行测试所需的步骤。
5. 执行测试：执行设计的测试用例，并记录测试结果。
6. 重复上述步骤：根据需要，重复上述步骤来覆盖不同的等价类。

通过等价类划分，可以在保持测试覆盖的同时，减少测试用例的数量。这有助于节省时间和资源，同时确保对系统的不同方面进行充分测试。等价类划分是测试用例设计的重要技术，特别在功能性测试、边界值测试和错误处理测试方面非常有用。

举个例子

假设有一个简单的用户登录系统，用户需要输入用户名和密码才能登录。我们要使用等价类划分来设计测试用例，以确保系统在不同情况下能够正确工作。

1、识别输入：用户登录系统的输入是用户名和密码。

2、确定等价类：我们可以将用户名和密码的等价类划分为以下几类：

空输入：没有用户名和密码。

有效用户名和密码：合法的用户名和密码。

无效用户名：用户名不存在系统中。

无效密码：用户名存在，但密码不匹配。

3、选择代表性值：对于每个等价类，选择代表性的值。

空输入：用户名为空，密码为空。

有效用户名和密码：例如，用户名 "user123"，密码 "password123"。

无效用户名：一个不存在的用户名，例如， "nonexistentuser"。

无效密码：有效用户名但不正确的密码，例如，用户名 "validuser"，密码 "wrongpassword"。

4、设计测试用例：为每个等价类设计测试用例。

对于空输入，测试用例应该包括一个用户名为空和密码为空的情况。

对于有效用户名和密码，测试用例应该包括一个合法的用户名和密码的情况。

对于无效用户名，测试用例应该包括一个不存在的用户名的情况。

对于无效密码，测试用例应该包括一个存在的用户名但不正确的密码的情况。

5、执行测试：执行这些测试用例，输入相应的用户名和密码，然后记录系统的响应（例如，成功登录、失败登录等）。

数据测试

对软件最简单的认识就是将其分成两部分:数据( 或其范围)和程序。数据包括键盘输入、鼠标单击、磁盘文件、打印输出等。程序是指可执行的流程、转换、逻辑和运算。软件测试常用的一个方法是把测试工作按同样的形式划分。

对数据进行软件测试，就是在检查用户输入的信息、返回的结果以及中间计算结果是否正确。

数据的例子如下:

●在文字处理程序中输入的文字。

●电子表格中输入的数字。

●太空游戏中余下的射击次数。

●图像处理软件打印的图片。

●存放在软盘中的备份文件。

●通过调制解调器在电话线上发送的数据。

边界条件

边界条件是特殊情况，因为编程从根本.上说在边界上容易产生问题。软件是很极端的一一即要 么对要么不对。令人奇怪的是如果对一定范围的数据进行操作，程序员往往在处理大量中间数值时都是对的，但是可能在边界处出现错误。

如果软件测试问题包含确定的边界，那么看看以下的数据类型:.

数值、速度、字符、地点、位置、尺寸、数量

同时，考虑这些类型的下述特征:

第一个/最后一个、最小值/最大值、开始/完成、超过/在内、空/满、最短/最长、最慢/最快、最早/最迟、最大/最小、最高/最低、相邻/最远这些绝不是确定的列表，而是一些可能出现的边界条件。每一个软件测试问题各不相同,可能包含各种不同的数据以及其独特的边界。

测试边界

由于软件容易在边界上产生缺陷，因此，如果要从等价划分中选择包含的数据，从边界条件中选择会找出更多的软件缺陷。

然而，仅仅测试边界线上的数据点往往不够充分。最好测试一下边界的两边。

技巧

提出边界条件时，一定要测试临近边界的有效数据，测试最后一个可能有效的数据，同时测试刚超过边界的无效数据。

越界测试的做法通常是简单地对于最大值加1或者很小的数,以及对于最小值减1或者很小的数，例如:

●第一个减1/最后一个加1。

●开始减1/完成加1。

●空了再减/满了再加。

●慢上加慢/快上加快

●最大数加1/最小数减1。

●最小值减1/最大值加1。

●刚好超过/刚好在内。

●短了再短/长了再长。

●早了更早/晚了更晚。

●最高加1/最低减1。

例子

如果文本输入域允许输入1~255个字符，就尝试输入1个字符和255个字符代表合法划分的数据。还可以输入254个字符作为合法输入。输入0个字符和256个字符代表非法划分的数据。

次边界条件

上面讨论的普通边界条件是最容易找到的。它们在产品说明书中有定义，或者在使用软件的过程中明显。而有些边界在软件内部，最终用户几乎看不到，但是软件测试员仍有必要进行检查。这样的边界条件称为次边界条件或者内部边界条件。

寻找这样的边界不要求软件测试员成为程序员或者具有阅读源代码的能力，但是确实要求大体了解软件的工作方式。

2的幂和ASCII表是这方面的两个例子。

所测试的软件可能有许多其他的次边界条件，所以软件测试员应和开发小组的程序员交流，看看他们能否对其他的应该测试的次边界条件提供建议。

2的幂

在建立等价划分时，要考虑等价划分中是否需要包含2的幕的边界条件。例如，如果软件接受用户输入1~1000范围内的数字,谁都知道在合法区间中包含1和1000,也许还要有2和999。

为了覆盖任何可能的2的幂的次边界，还要包含临近4位边界的14、15和16， 以及临近字节边界的254、255和256。

ASCLL表

注意，表5-2不是良好的、连续的列表。0~9的ASCII值是48~57。斜杠字符(1)在数字0的前面，而冒号字符(:)在数字9的后面。大写字母A~Z对应的ASCII值是65~90。小写字母对应的ASCII值是97~122。这些情况都代表次边界条件。

如果测试进行文本输入或文本转换的软件，在定义数据划分包含哪些值时，参考一下ASCII表是相当明智的。例如，如果测试的文本框只接受用户输入，字符A~Z和a~z，就应该在.非法划分中包含ASCII表中这些字符前后的值一@、 [、'和{。

默认.空白、空值.零值和无

另一种看起来很明显的软件缺陷来源是当软件要求输入时一一比如在文本框中一不是没有输入正确的信息，而是根本没有输入任何内容，可能单单按了Enter键。这种情况在产品说明书中常常忽视，程序员也经常遺忘，但是在实际使用中却时有发生。

好的软件会处理这种情况。它通常将输入内容默认为边界内的最小合法值，或者在合法划分中间的某个合理值;或者返回错误提示信息。

非法、错误.不正确和垃圾数据

数据测试的最后一种类 型是垃圾数据。这是失效性测试的对象。经过边界测试、次边界测试和默认值测试等通过性测试证实软件能够工作之后，就该进行垃圾数据测试了。

从纯粹的软件测试观点来看，如果利用前述技术全面测试证明软件能够工作了，就不必再做破坏实验。然而，现实中考虑到软件要应付用户千奇百怪的使用方式，这样做肯定没错。

如果想一想今天打包后的软件将售出数亿份拷贝，就完全可以断定一定有一部分用户会错误地使用软件。如果错误操作导致崩溃或者数据丢失，用户不会责怪自己一而 会指责软

件。软件如果没有按照用户的意愿运行，就算有一个缺陷，经常是这样。

非法、错误、不正确和垃圾数据测试是很有意思的。

例如：

• 如果软件要求输入数字，就输入字母。
• 如果软件只接受正数，就输入负数。
• 如果软件对日期敏感，就看它在公元3000年是否还能正常工作。
• 假装有“肥胖的手指”，同时按下多个键。

此类测试没有实际的规则，只是设法破坏软件。要发挥创造力，要会走偏门。在此工作中寻找乐趣吧!

状态测试

到目前为止，我们测试的是数据一数字、 文字、软件输入和输出。

软件测试的另一方面是通过不同的状态验证的程序的逻辑流程。软件状态(software state)是指软件当前所处的条件或者模式，参见图5-8和图5-9。

        图5-8显示了处于铅笔绘画状态的Windows画图程序，这是软件启动时的初始状态。注意，铅笔工具被选中，光标的形状很像铅笔，可以在屏幕上画出细线。图5-9显示了处于喷涂状态的Windows画图程序。在该状态下，喷枪工具被选中，喷枪大小确定，光标的形状很像喷漆罐，绘制效果很像喷漆。

        进一步观察画图程序提供的全部选项一所有的工具、 菜单、颜色等。一旦选中其中一项，使软件改变了外观、菜单或者某些操作，就是改变了该软件的状态。软件通过代码执行进入某一个分支，触发一些数据位，设置某些变量，读取某些数据，转入一个新的状态。注意软件测试员必须测试程序的状态及其转换。

参考书籍：软件测试原书第二版