阿潮先生

软件缺陷定义

2010-03-30T21:37:38Z

——陈建潮

1. 问题引入

一直在说软件缺陷，那么，软件缺陷的定义是什么呢？错误等同于缺陷吗？

2. 解答问题

（1）这是一个难以回答的问题。由于软件开发公司的文化和用于开发软件的过程不同，造成了用于描述软件故障、软件失败的术语有很多，比如说，缺点（defect）、偏差（variance）、谬误（fault）、失败（failure）、问题（problem）、矛盾（inconsistency）、错误（error）、毛病（incident）、异常（anomaly）、缺陷（bug）等等。

（2）但是，一般来说，我们习惯上把所有的软件问题都统称为缺陷（bug）。要阐述软件缺陷的定义，我们必须要先知道另一个概念——产品需求规格说明书（又称需求说明书）：是软件开发小组的协定，它对开发的产品进行定义，包括产品有何细节、如何操作、功能如何、有何限制等。

（3）软件缺陷的正式定义如下，只要符合下列5个规则中的任何一条都是软件缺陷：

l 软件未达到产品说明书表明的功能；

l 软件出现了产品说明书指明不会出现的错误；

l 软件功能超出了产品说明书指明的范围；

l 软件未达到产品说明书虽未指出但应达到的目标；

l 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好；

3. 分析问题

（1）比如说，日常使用的计算机的产品需求规格说明书一般描述如下：

l 计算器通过用户输入要计算的数字，能准确地完成加、减、乘、除的数学运算，并在显示屏上准确显示计算的结果。

l 在任何时候计算机都不会出现显示错误结果的情况，不会出现“死机”无响应的情况，不会出现崩溃无法恢复的情况。

（2）假设，测试员发现，按要求输入了两个数字1和2，并且按下了“+”号键，要求进行加法数学运算，但是，最终计算器并没有在显示屏上显示结果，又或者是计算器在显示屏上显示的是错误的结果，比如显示结果是4，而不是正确结果3。那么，根据第1条规则，这就是一个软件缺陷。

假设，测试员对计算器的键盘随意敲击（猴子测试），发现计算器“死机”了，对任何操作都无响应，那么，根据第2条规则，这就是一个软件缺陷。

假设，测试员发现，计算机除了能够进行加、减、乘、除的数学运算，还能够进行sin、cos等科学运算，虽然，运算处理的结果是正确的，但是，根据第3条规则，这就是一个软件缺陷。因为，很可能这个计算器就是为小学的学生开发的，而加入这样的科学运算会造成小学学生学习混乱。

假设，测试员发现，计算器在电池电力不足的情况下，会丢失运算处理后显示的结果，那么，根据第4条规则，这就是一个软件缺陷。

假设，测试员和最终的用户都认为，计算器的按键太小了、按键间距太密了、按键上的数字和运算符号显示不清晰，那么，根据第5条规则，这些都算是一个软件缺陷。

软件测试目的

2010-03-30T21:36:03Z

——陈建潮

1. 问题引入

软件测试是必要的，那么，软件测试的目的是什么呢？难道花费那么多资源用在测试上，仅仅是为了证明软件是错误的吗？

2. 解答问题

随着软件系统的规模和复杂性与日俱增，软件的生产成本和软件中存在的缺陷和故障造成的各类损失也大大增加，甚至会带来灾难性的后果。软件质量问题已成为所有使用软件和开发软件的人关注的焦点，从大量的事实已经证实了软件测试的必要性。

3. 分析问题

在表面看来，软件测试的目的与软件工程其他阶段的目的好像是相反的，软件工程其他阶段都是在“建设”的，简单说，软件工程师一开始就力图从抽象的概念出发，然后逐步设计出具体的软件系统，直到用一种适当的程序设计语言编写、生成可执行的程序；然而，在测试阶段，测试人员所做的却是努力设计出一系列的测试方案，不遗余力地“破坏”已经建造好的软件系统，竭力证明程序中有错误，程序不能按照预定要求正确工作。

可以很肯定地说，这只是表面现象，暴露问题、“破坏”程序并不是软件测试的最终目的，软件测试的目的是尽早发现软件缺陷，并确保其得以修复。换而言之，软件测试的最终目的是提高软件质量。所以，软件测试表面看起来是“破坏”，其实质却是为了“建设”质量更高的软件产品。用一句不太恰当的话总结就是，破而后立。

软件测试的必要性

2010-03-30T21:35:32Z

——陈建潮

1. 问题引入

前面曾经提到，根据统计表明，软件测试的工作量往往占软件开发总工作量的40%以上，可能我们会思考这样一个问题，花费那么多资源在测试上，花费在一个对整个软件工程“没有任何建设成果”的活动上，值得吗？

2. 解答问题

事实上，答案是肯定的。软件缺陷和故障问题在某些情况下会造成相当严重的损失和灾难，花费大量的资源在测试上，目的是为了提高软件质量，尽可能地减少软件缺陷造成的损失。

3. 分析问题

让我们先来了解几个“著名”的计算机工程事故吧，借此说明软件缺陷和故障问题有时会造成相当严重的损失和灾难。

（1）2007年5月18日，国内大量用户的电脑集体出现问题：开机后自动重启、蓝屏，屏幕上显示unknown hard error的字样，安全模式下也无法正常进入系统等等。用户的第一反应就是感染了病毒，而在经过金山毒霸反病毒专家的仔细分析后，发现了问题的症结所在：诺顿杀毒软件的误报所致，赛门铁克SAV 2007-5-17 Rev 18版本的病毒定义码中，将Windows XP操作系统的netapi32.dll文件和lsasrc.dll文件判定为Backdoor.Haxdoor病毒，并进行隔离，导致重启电脑后无法进入系统，并出现蓝屏、重启等现象，造成了大量的数据丢失，系统崩溃，损失惨重。

此次电脑病毒误报事件被反病毒专家称为是近5年来国内影响面最大的误报事件。诺顿在企业级用户中占据了30%的份额，这次低级的错误造成了大量的电脑系统崩溃，造成了巨大的损失，虽然，赛门铁克已经公开道歉，修复了Bug，并提出了拯救系统的方案，但是，赛门铁克还是很可能面临着巨额的索赔。其实，针对类似很多的“误杀门”事件，软件厂商只需在软件发布前做一个完整的兼容性测试就可以很有效地避免这样的灾难事故了。

（2）2000年12月4日上午10时30分起，浦东地区不少电话用户突然发现通话受阻，一部分移动电话、寻呼机用户也受到影响，无法正常收发信息。由于故障地区位于浦东中心地区，大量中外商务机构包括证券大厦、期货交易所等都在其中，造成了严重的局面。

经电信部门紧急查寻，发现问题出在一电话汇接局内的贝尔电话交换机上，估计是软件系统发生故障。上海有关部门立即调集了一批电信专家和技术人员来到现场，与上海贝尔公司派出的专家一起进行“会诊”和抢修。通话受阻情况在当晚午夜得到平息。

最终，上海电信部门确认了交换机软件的缺陷是造成这次事件的主要原因。虽然这一系统7年前就已经安装在汇接局，并一直没有被发现有缺陷。但有关专家认为，如果多种作用因素同时出现，或者是瞬间出现极高的话务量，这一缺陷迟早会“现身”。

（3）1999年12月3日，美国航天局的火星极地登陆飞船在试图登陆火星表面时失踪了，造成了巨大的损失。错误修正委员会观测到故障，并确定出现误动作的原因极可能是由于某一数据位被意外地更改了。大家对这一错误感到非常震惊，认为该问题应该在内部测试时就予以解决。

简单来说，火星登陆计划的过程是这样的：当飞船降落在火星表面时，它将打开降落伞减缓飞船的下降速度。降落伞打开后的几秒钟内，飞船的三条腿将迅速撑开，并在预订地点着陆。当飞船离火星表面1,800米时，它将丢弃降落伞，点燃登陆推进器，在余下的高度缓缓降落在火星表面。

但是，美国航天局为了省钱，简化了确定何时关闭推进器的装置。为了替代其他太空船上使用的贵重雷达，他们在飞船的脚上装了一个廉价的触点开关，在计算机中设置了一个数据位来关掉燃料。很简单，飞船的脚不着地，引擎就不熄火。

遗憾的是，错误修正委员会在测试中发现，当飞船的脚迅速撑开准备着陆时，机械震动很容易触发着地开关，设置错误的数据位。设想一下，飞船开始着陆时，计算机极可能关闭了推进器，而火星登陆飞船下坠1,800米之后便冲向火星表面，摔成碎片。

这一事故产生的后果非常严重，然而其幕后的原因却如此简单。在登陆开始之前，飞船经过了多个小组测试。其中一个小组测试飞船的脚落地过程，另一个小组测试此后的着陆过程。前一个小组并不去注意着地数据位是否置位，因为这不是他们负责的范围；后一个小组总是在开始测试之前重置计算机、清除数据位。双方独立工作都很好，但从未组合在一起进行过集成测试，从而导致了这一严重事故的发生。

Web测试中的界面测试

2010-01-17T11:24:19Z

【以下内容转摘于http://www.51testing.com/html/30/n-133830.html】，网站界面测试的关注点是什么，说的比较清楚，与大家一起共勉。

　　一、文本框、按钮等控件测试

　　1、文本框的测试

　　如何对文本框进行测试：

　　a、输入正常的字母或数字；

　　b、输入已存在的文件的名称；

　　c、输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入256个字符，检查程序能否正确处理；

　　d、输入默认值，空白，空格；

　　e、若只允许输入字母，尝试输入数字；反之，尝试输入字母；

　　f、利用复制，粘贴等操作强制输入程序不允许的输入数据；

　　g、输入特殊字符集，例如，NUL及\n等；

　　h、输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示；

　　i、输入不符合格式的数据，检查程序是否正常校验，如程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示。

　　在测试过程中所用到的测试方法：

　　a、输入非法数据；

　　b、输入默认值；

　　c、输入特殊字符集；

　　d、输入使缓冲区溢出的数据；

　　e、输入相同的文件名；

　　2、命令按钮控件的测试

　　测试方法：

　　a、点击按钮正确响应操作。如单击确定，正确执行操作；单击取消，退出窗口；

　　b、对非法的输入或操作给出足够的提示说明，如输入月工作天数为32时，单击“确定”后系统应提示：天数不能大于31；

　　c、对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会；

　　3、单选按钮控件的测试

　　测试方法：

　　a、一组单选按钮不能同时选中，只能选中一个；

　　b、逐一执行每个单选按钮的功能。分别选择了“男”、“女”后，保存到数据库的数据应该相应的分别为“男”、“女”；

　　c、一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空。

　　4、up－down控件文本框的测试

　　测试方法：

　　a、直接输入数字或用上下箭头控制，如在“数目”中直接输入10，或者单击向上的箭头，使数目变为10；

　　b、利用上下箭头控制数字的自动循环，如当最多数字为253时，单击向上箭头，数目自动变为1；反之亦适用；

　　c、直接输入超边界值，系统应该提示重新输入；

　　d、输入默认值，空白。如“插入”数目为默认值，点击“确定”；或删除默认值，使内容为空，单击“确定”进行测试；

　　e、输入字符。此时系统应提示输入有误。

　　5、组合列表框的测试

　　测试方法：

　　a、条目内容正确，其详细条目内容可以根据需求说明确定；

　　b、逐一执行列表框中每个条目的功能；

　　c、检查能否向组合列表框输入数据。

　　6、复选框的测试

　　测试方法：

　　a、多个复选框可以被同时选中；

　　b、多个复选框可以被部分选中；

　　c、多个复选框可以都不被选中；

　　d、逐一执行每个复选框的功能。

　　7、列表框控件的测试

　　测试方法：

　　a、条目内容正确：同组合列表框类似，根据需求说明书确定列表的各项内容正确，没有丢失或错误；

　　b、列表框的内容较多时要使用滚动条；

　　c、列表框允许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的情况；

　　8、滚动条控件的测试

　　要注意一下几点：

　　a、滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如word中浏览100页文档，浏览到50页时，滚动条位置应处于中间；

　　b、拖动滚动条，检查屏幕刷新情况，并查看是否有乱码；

　　c、单击滚动条；

　　d、用滚轮控制滚动条；

　　e、滚动条的上下按钮。

　　9、各种控件在窗体中混和使用时的测试

　　a、控件间的相互作用；

　　b、tab键的顺序，一般是从上到下，从左到右；

　　c、热键的使用，逐一测试；

　　d、enter键和esc键的使用。

　　在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。

　　ps：密码输入框测试时要特别注意进行字母大写输入的测试。

--------------------------------------------------------------------------------

二、查找替换操作

　　案例演示：打开word中的“替换”对话框。

　　测试本功能有通过测试和失败测试两种情况：

　　通过测试：

　　a、输入内容直接查找、或查找全部；

　　b、在组合框中寻找已经查找过的内容、再次查找并确认文档的内容正确，如已经查找过“测试用例”、再次进入不用重新输入查找内容、直接在文档中搜寻就可以。

　　失败测试：

　　a、输入过长或过短的查询字符串。如假设查询的字符串长度为1到255，那么，输入0、1、2、256、255和254进行测试；

　　b、输入特殊字符集。如在word中^g代表图片、^代表分栏符、可以输入这类特殊字符测试；替换测试大体相同。

　　关于编辑操作窗口的功能测试的用例：

　　a、关闭查找替换窗口。不执行任何操作、直接退出；

　　b、附件和选项测试。假如设定“精确搜寻”、“向后”搜索等附件选项等等来测试；

　　c、控件间的相互作用。如搜寻内容为空时、按钮“搜寻全部”、“搜寻”、“全部替换”、“替换”都为灰色。

　　d、热键、Tab键。回车键的使用。

　　插入操作

　　1、插入文件

　　测试的情况：

　　a、插入文件；

　　b、插入图像；

　　c、在文档中插入文档本身；

　　d、移除插入的源文件；

　　e、更换插入的源文件的内容。

　　2、链接文件

　　测试方法：

　　a、插入链接文件；

　　b、在文档中链接文档本身；

　　c、移除插入的源文件：

　　d、更换插入的源文件的内容。

　　3、插入对象

　　要测试的内容：

　　a、插入程序允许的对象、如在word中插入excel工作表；

　　b、修改所插入对象的内容。插入的对象仍能正确显示；

　　c、卸载生成插入对象的程序、如在word中插入excel工作表后卸载excel、工作表仍正常使用。

　　编辑操作

　　编辑操作包括剪切、复制、粘贴操作。

　　测试剪切操作的方法

　　a、对文本、文本框、图文框进行剪切；

　　b、剪切图像；

　　c、文本图像混合剪切。

　　复制操作方法与剪切类似。

　　测试时，主要是对粘贴操作的测试方法是：

　　a、粘贴剪切的文本、文本框及图文框；

　　b、粘贴所剪切的图像；

　　c、剪切后，在不同的程序中粘贴；

　　d、多次粘贴同一内容，如剪切后，在程序中连续粘贴3次；

　　e、利用粘贴操作强制输入程序所不允许输入的数据。

　　三、界面测试用例的设计方法

　　1、窗体

　　测试窗体的方法：

　　a、窗体大小，大小要合适，控件布局合理；

　　b、移动窗体。快速或慢速移动窗体，背景及窗体本身刷新必须正确；

　　c、缩放窗体，窗体上的控件应随窗体的大小变化而变化；

　　d、显示分辨率。必须在不同的分辨率的情况下测试程序的显示是否正常。

　　进行测试时还要注意状态栏是否显示正确，工具栏的图标执行操作是否有效，是否与菜单懒中图标显示一致；错误信息内容是否正确、无错别字且明确等等。

　　2、控件

　　测试方法：

　　a、窗体或控件的字体和大小要一致；

　　b、注意全角、半角混合；

　　c、无中英文混合。

　　四、菜单

　　进行测试时要注意：

　　a、选择菜单是否可以正常工作、并与实际执行内容一致；

　　b、是否有错别字；

　　c、快捷键是否重复；

　　d、热键是否重复；

　　e、快捷键与热键操作是否有效；

　　f、是否存在中英文混合；

　　g、菜单要与语境相关、如、不同权限的用户登陆一个应用程序、不同级别的用户可以看到不同级别的菜单并使用不同级别的功能；

　　h、鼠标右键快捷菜单。

　　特殊属性

　　a、安装界面应有公司介绍或产品介绍、有公司的图标；

　　b、主界面及大多数界面最好有公司图标；

　　c、选择“帮助”->“关于”命令、应看见相关版权和产品信息。

十大负面测试用例

2010-01-17T11:19:25Z

【以下内容转摘与http://bbs.51testing.com/thread-112478-1-1.html】，十分有用，与大家一起共勉。

负面测试（Negative testing）是相对于正面测试（Positive testing）而言的。它们也是测试设计时的两个非常重要的划分。简单点说，正面测试就是测试系统是否完成了它应该完成的工作；而负面测试就是测试系统是否不执行它不应该完成的操作。形象一点，正面测试就象一个毕恭毕敬的小学生，老师叫我做什么，我就做什么；而负面测试就象一个调皮捣蛋的孩子，你叫我这样做，我偏不这样做，而且和你对着干。开发人员也是最讨厌修改此类bug的。

正面测试主要根据需求，功能说明书，设计文档等相关参考文档来执行测试，而负面测试则主要根据错误猜测，逆向思维来测试系统，一定程序上的的依赖测试人员的经验积累。

执行负面测试时，不单单要测试系统是否处理了用户的异常操作，还要检查系统对于这些异常操作是否给予了正确的错误提示。它是系统对用户进行继续正确操作的指引。

简言之负面测试的三部曲就是：

1、检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束；
2、测试系统是否处理了用户的异常操作；
3、检查系统的错误提示是否清晰且充分。

以下是Steve Miller的《Top 10 Negative Test Cases》，概括性的提到了一些做负面测试时经常需要注意的测试。

负面测试用例被设计于用软件未意欲被使用的方式测试软件，它也应该是测试工作的一部分。以下就是在设计测试工作量时你应该考虑的十大负面测试用例。

1、植入的单引号。大多数基于SQL的数据库系统在用户存储包含一个单引号的信息时会出现问题，例如John's car。每一个可以接受文字数字型数据条目的屏幕都要试试输入包含一个或多个单引号的文本。

【补充】其实不只是单引号，基本上测试人员应该测试所有的特殊字符和空/空格（单纯的空格和文本前后的空格）。单引号，逗号，/，<，>（对于web的应用程序）都是很容易引发错误的。在开发早期测试组就可以建议开发组写一个通用的函数来处理这些特殊字符，然后在处理用户的输入时套用这个函数就可以避免此类错误了。

2、必需输入的数据条目。功能说明书上应该清楚的指出屏幕上必须输入数据条目的字段。测试屏幕上每一个被说明为必须输入的字段以保证它强制要求你在字段中输入数据。

【补充】对于强制输入的字段，在屏幕上最好有些标识以说明其为必须输入的字段。一般在字段前或后用红色的*号表示。测试时必须要检查有标识的字段是否和功能说明书或其他参考文档一致，错误信息提示是否正确，强制输入的字段是否真的必须输入。

3、字段类型测试。功能说明书上应该清楚的指出要求特定数据输入要求（日期字段，数字字段，电话号码，邮编等等）的字段。测试屏幕上每一个被指出有特定类型的字段以保证你输入了基于字段类型的符合正确格式的数据（数字型字段应该不允许字符或特殊字符，日期型的字段应该允许输入一个正确的日期等等）

【补充】其实这里还有一个字段格式和字段内容的测试。有些字段对输入的格式有要求，这些字段的格式一般在屏幕上也有相应的提示。所以在测试时需要测试提示的格式是否合理（和功能说明书或其他参考文档相一致）以及系统是否正确识别输入的格式。有些字段对字段的内容有限制，如常见的用户名，不能包含特殊字符，首字不能未数字等要求。所以在测试时需要测试提示的格式是否合理（和功能说明书或其他参考文档相一致）还有不符合内容要求的数据输入时系统是否正确的处理。

4、字段长度测试。功能说明书上应该清楚的指出可以在字段中输入的字符数（例如，first name必须是50个或更少的字符）。写测试用例以保证你只可以输入特定的字符数。防止用户输入比允许范围更多的字符比因用户已输入过多的字符而给出的错误信息更加的文雅些。

【补充】一般对于限制长度的字段，现在开发大多采用限制输入的方法（设置字段的长度）来处理。所以测试时需要测试限制的长度是否合理（和功能说明书或其他参考文档相一致），对于没有限制长度的字段，要测试无穷输入时是否出错，有问题报bug时建议开发人员根据需要限制长度。

5、数字型的边界测试。对于数字型的字段，测试上下边界是非常重要的。例如，如果你正在计算某个账户的利息时，你永远不会输入一个负的利息数给应该赢取利息的账户。因此，你应该尝试用负数测试。同样，如果功能说明书上要求字段在某一个特定的范围（如从10～50），你就应该尝试输入9或51，它应该给出一个得体的信息表示失败。

6、数字的约束测试。大多数数据库系统和编程语言允许数字条目被识别为整数或长整数。通常，整数的范围是从-32,767~32,767，长整数的范围从-2,147,483,648~2,147,483,647。对于那些没有特定边界限制的数字数据条目，用这些限制测试以确保不会出现数字的溢出错误。

【补充】小数型的数字字段同样也需要格外的测试。一般对于未指出数字类型的字段，尝试输入负整数，负小数，0，正整数，正小数进行测试。

不管是哪种数据库系统，对于数字一般都有多种数字类型。所以测试人员一定要测试的全面。

7、日期边界测试。对于日期型的字段，测试上下边界是很重要的。例如，如果你正在检查一个出生日期的字段，很大可能出生日期不能早于150年前。同样，出生日期应该不是将来的某一天。

【补充】一般来说，每种数据库系统的日期都有个范围，如SQL Server最小日期是1753年1月1日，所以如果是输入型的日期字段同样也应该测试早于1753的日期。

8、日期的有效性。对于日期字段，确保不允许无效的日期是很重要的（04/31/2007是一个无效的日期）。测试用例也应该检查闰年（每个第4年和第400年是一个闰年）。

9、web会话测试。很多的web应用程序依赖浏览器的会话来追踪已登录的用户，应用程序的设置等等。应用程序的大多数屏幕不被设计为没有首次登录就可以被运行。应用程序应该确保在打开应用程序的某一页面之前会话里有一个有效的登录。

10、性能的改变。当发布产品的最新版本时，应该有一套运行于识别屏幕（列出信息的屏幕，add/update/delete数据的屏幕等等）速度的性能测试。测试包里应该包括比较先前版本和现有版本性能统计值的测试用例。这个可以帮助识别那些可以证明是随着对现有版本的代码变更而引起的潜在的性能问题。

【补充】从第一条到第八条是我们在测试字段时常常需要做的测试，一般的测试人员都不陌生。第九条在测试web应用程序中会作为检查应用程序的安全性而做的一项测试。而第十条估计很多公司都不会将它考虑到测试的范畴中，一般最多也就是在测试用例中添加校验某一个操作是否在系统允许的响应时间里，很少去做这样的比较，除了一些有针对性的性能测试。