实用软件测试指南.doc

《实用软件测试指南.doc》由会员分享，可在线阅读，更多相关《实用软件测试指南.doc（23页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、实用软件测试指南北京吉威数源信息技术有限公司信息工程事业部2008年4月29日版本历史时 间人 员备 注2006.2.13张政、陈进2008.4.29魏春萍将人机界面测试纳入常用测试方法，见2.3.1将常见缺陷及解决方法中的内容合并到该文档中，见第四章目 录第一章目的11.1拟写背景和说明11.2参考资料2第二章软件测试基础知识22.1什么叫软件测试22.2软件测试人员的思维方式32.3常用测试方法32.3.1人机界面测试32.3.2健壮边界值测试52.3.3回归测试52.4软件测试工作的输出62.5软件测试过程6第三章测试过程中的几点要求63.1明确期望结果63.2多参考其他系统，提出优化建

2、议73.3不断学习，培养严谨、细致的工作习惯73.4建立最短、最快的反馈环路73.5注意边界值83.6观察数据库记录的实际变化是否正确83.7注意测试流程83.8前提条件不满足导致异常8第四章测试细则94.1界面设计细则94.1.1主窗口94.1.2弹出窗口124.1.3鼠标状态154.1.4消息提示框154.1.5输入框164.1.6下拉选择框164.1.7树形控件164.2非缺陷实例174.3常用的测试输入操作204.4白盒测试20第一章 目的1.1 拟写背景和说明本文档在软件开发及测试实践经验的基础上，结合大量的测试方面的参考书籍，在精简与实用的指导思想下进行编写。对于具体的测试要求与测

3、试流程，我们的原则是：实用第一。也就是说，如果某项内容是目前条件下可实行的话就纳入，达成共识，并坚定不移的执行；如果目前条件不具备，则决不采纳，以免流于形式，待条件成熟时再逐渐改善。虽然本文对一些基础知识进行了介绍，但并不完整、也不详细，仅是从满足目前基本测试方法培训的需要而编写的，只是冰山一角而已。应进一步阅读软件测试及质量保证方面的各种书籍，以获得完整的，更深入的软件测试方面的知识。对于有志长期从事软件质量保证与测试方面工作的读者，建议在有生之年尽快通读所有这方面的书籍，并积极投身于具体实践，不断总结提高。软件开发人员通过了解基本的测试理论及方法，也有利于提高软件开发水平与效率、提交更高质

4、量的成果。1.2 参考资料 部门ClearQuest的Bug记录软件测试的经验与教训软件测试基本理论软件测试活动规范软件测试基本内容软件测试的理论和实践软件回归测试及其实践国标测试分析报告（GB856788）国标测试计划（GB856788）第二章 软件测试基础知识2.1 什么叫软件测试关于软件测试的定义有很多，如软件测试就是使用系统、可控的手段对软件进行破坏的过程。再如，软件测试就是校验软件是否满足要求标准的过程等等。2.2 软件测试人员的思维方式为了对软件进行更有效的测试，测试工作者应采用什么样的思维方式？程序员在编码实现功能的过程中，首先考虑的都是合乎情理的输入和操作，得到正确的结果，然后

5、处理其他所有无意义的情况。而测试人员则需要尽可能的设想一些不合情理的操作，测试者常常采用与系统设计实现人员不同的逻辑及执行路线来对软件进行测试，比较极端的如连续反复打开同一个对话框100次、启动软件或操作软件的过程中突然拔掉网线。再如：一个简单的弹出式对话框，包括一个文本框，两个按钮“确认、取消”。程序员设计时最直接想到的，常规正确的操作方式是文本框输入值、点确定，计算结果输出，点取消，窗口关闭退出。但测试人员还应该想到其它一些“不尽情理”的操作，例如文本框输入了数值后点“取消”，没有输入任何值而直接点“确定” 或者进入界面之后直接点击“取消”等等。所以不按设计者预先考虑好的正常路线、逻辑或内

6、容对被测软件进行各种输入，是软件测试人员应掌握的最基本的思维方式与技巧还有就是探索式测试能力，就是结合各种测试手段，通过细致的观察输入与输出，通过类推、积极思考，来窥探可能存在的逻辑缺陷，把握其规律。很多掩藏较深、不易复现的缺陷，需要测试人员具备一定的探索式测试能力才能解决。2.3 常用测试方法基于不同的分类标准，测试方法有很多，这里不进行列举，下面只对目前我们用到的主要方法进行说明，在后面的章节，将对具体测试的内容与方法进行详细的列举：2.3.1 人机界面测试我们知道：“不立规矩无以成方圆”。在软件界面设计强调张扬个性的同时，我们不能忘记软件界面的设计先要讲求规矩简洁、一致、易用，这是一切软

7、件界面设计和测试的必循之道，是软件人机界面在突出自我时的群体定位。美观、规整的软件人机界面破除新用户对软件的生疏感，使老用户更易于上手、充分重用已有使用经验，减少使用错误。由此我们在对软件人机界面进行测试时（设计评审阶段和系统测试阶段结合进行），不妨从下列一些角度测试软件的人机界面。1) 一致性测试一致性是软件人机界面的一个基本要求。目的是使用户在使用时，很快熟悉软件的操作环境，同时避免对相关软件操作发生理解歧义。这要求我们在进行测试时，需要判断软件的人机界面是否可以作为一个整体而存在。下面是进行一致性测试的一些参考意见：a) 提示的格式是否一致；b) 菜单的格式是否一致；c) 帮助的格式是否

8、一致；d) 提示、菜单、帮助中的术语是否一致；e) 各个控件之间的对齐方式是否一致；f) 输入界面和输出界面在外观、布局、交互方式上是否一致；g) 同一层次的文字在同一种提示场合（一般情况、突显、警告等）在文字大小、字体、颜色、对齐方式方面是否一致。2) 信息反馈测试假设系统的使用者是一个初出茅庐的生手，这要求我们的人机界面有足够的输入检查和错误提示功能。通过信息反馈，用户得到出错提示或是任务完成的赞许之语。下面是这类测试的一些参考意见：a) 系统是否拒绝客户的错误输入并做出提示（例：弹出警告框，声响）；b) 系统显示用户的错误输入的提示是否正确，浅显易懂（例：“ERR004”这样的提示让人不

9、知所云）；c) 注意系统界面中是否存在错别字（例：“请选则删除的文件！”其中的“则”应改为“择”）；d) 系统在界面（主要是菜单、工具条）上是否提供突显功能（比如鼠标移动到控件时，控件图标变大或颜色变化至与背景有较大反差，当移动开后恢复原状）。3) 界面简洁性测试a) 用户界面是否存在空白空间（没有空白空间的界面是杂乱无章的，易用性极差）；b) 各个控件之间的间隔是否一致；c) 各个控件在垂直和水平方向上是否对齐；d) 菜单深度是否在三层以内（建议不要超出三层，大家可以参考微软的例子）；e) 界面控件本身是否需要通过滑动条的滑动来显示数据（建议采用分页显示并提供数据排序显示功能）。4) 用户动

10、作性测试a) 是否允许动作的可逆性（Undo，Redo）；b) 系统的反应速度是否符合用户的期望值；c) 不同显示分辨率下窗体内容是否正确；d) 缩放窗体，窗体上的控件是否随着窗体而缩放；e) 用户在使用时任何时候是否能开启帮助文档（F1）；f) 系统是否提供模糊查询机制和关键字提示机制减少用户的记忆负担（地名查询的模糊设定）；g) 是否采用相关控件（如：日历，计算器等）替代用户手工键盘输入；h) 选项过多的情况下是否采用下拉列表或者关键字检索的方式供用户选择；i) 系统出错是是否存在恢复机制使用户返回出错前状态（如：Office XP的文件恢复）；j) 在用户输入数据之前，用户输入数据后才能

11、执行的操作是否被禁止（如特定的按钮变灰）。2.3.2 健壮边界值测试采用略小于最小值、最小值、略大于最小值、正常值、略小于最大值、最大值、略大于最大值等共7个值进行测试。如取值区间为min,max，可用公式表示如下：min-、min、min+、normal、max-、max、max+. 上面描述是针对数值型、日期型的输入，对于其他类型，可依照处理，可能会有所取舍,如：对于字符型，则将值对应成字符串的长度即可对于列表框、下拉列表等控件，则将值对应成控件中的列表项。2.3.3 回归测试在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。软件的改变可能是源于发现了错误并做了修

12、改，也有可能是因为在集成或维护阶段加入了新的模块。当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改；而开发者对错误理解的不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败；修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时，还需要补充新的测试用例来

13、测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。2.4软件测试工作的输出一般软件测试输出的主要成果是测试用例与缺陷报告。由于我们对于测试用例还没有找到合适有效的方式来编写、使用和管理，所以暂不采用，缺陷报告是目前是测试工作的主要输出成果。2.5软件测试过程软件测试是驱动软件开发过程的两大源动力之一，所以需要将软件测试活动与软件开发活动进行有效的结合，对测试的活动过程要进行设计与管理。目前的测试过程是按照 提交代码-测试记录发现的缺陷修复缺陷提交修改后的代码验证修复 做为基本流程来开展测试活动的。当然，这个基本流程中间，测试人员还需要进行阅读需求、设计文档，与开发人员沟

14、通等等其他活动。在软件测试过程中，对于基本的、常见的界面布局及输入控制等缺陷可以很容易的进行快速测试并得到结果，而对于模块的功能性的验证，则需要测试人员预先了解被测模块的设计目标，所以测试人员最好能在模块的需求分析与设计阶段就能有一定程度的参与。另外，目前我们使用ClearQuest、SourceSafe进行软件测试过程的辅助管理。第三章 测试过程中的几点要求3.1 明确期望结果了解系统功能，对系统的每一个功能按钮和菜单测试之前都应该先有一个明确的期望结果。试想一下如果自己都不明确什么是正确的结果，也就无从谈错误的概念了，同时由于程序员本身对需求理解可能有偏差，实现过程也可能引入更多的偏差，所

15、以测试人员在测试之前既要同程序员交流，了解他们的设计思路和期望输出结果，也需要从具体的功能需求出发（例如各种需求分析文档），更直接的了解功能设计上的期望结果。3.2 多参考其他系统，提出优化建议除了直接引起系统崩溃和功能异常的各种错误和Bug以外，在测试的过程中还需要测试人员能够多站在用户的角度去考虑系统在易用性、合理性和界面设计方面的欠缺，给程序员提供建议，以便能够不断的完善和优化系统。举例来说： 系统构建平台中的用户管理功能，管理员应该设置为保留用户不能删除。 系统构建平台中数据目录管理中图层属性缺省设置哪几项更便于用户使用。 在动态表单的设计中，某字段设置了他的关联字段后则字段类型也应该

16、默认保持一致。 制图输出界面，颜色选择框，字体类型和大小选择框和当前添加或者选中的文字、元素的状态的关联。从以上例子中我们可以看出，这些bug记录都不属于程序编码错误引起异常的范畴，但测试人员可以通过学习oracle系统的用户管理功能，ArcMap的制图部分，向系统设计人员了解关联字段的具体涵义和用途，了解业务上最基本的图层属性设置，从而发现和提出这些问题。即使有时候这些问题可能并不合理，或者存在技术实现方面的困难，或者是测试人员自己对需求和业务的理解偏差。3.3 不断学习，培养严谨、细致的工作习惯对被测系统进行深入的了解，多参考其他系统，增广知识，积极思考，培养严谨、细致的工作习惯，这样才能

17、在测试工作中目光如炬，洞察先机。3.4 建立最短、最快的反馈环路程序员提交代码后，应该及时测试，发现问题及时反馈，并且及时验证程序员的修改，尽可能建立最短、最快的反馈环路。测试员的反馈有助于帮助程序员避免相似的问题再次发生，而且，越早发现问题，代码修改的代价也越小。但频繁的打断程序员工作，演示发现的问题并不合适，应该怎样达到平衡还需要测试人员根据不同程序员的性格习惯自己把握好频度。3.5 注意边界值基本的测试理论强调“健壮边界值测试”，想阐述道理也就是程序错误和异常的高发“地带”就是在一些边界情况，或者更广义的理解为极端的情况。举例来说： 在地图上绘制实体：一般方式的添加，程序员在开发时候必然

18、也试验过，而当我们将鼠标移动超出地图边界范围后，程序员如果没有考虑到这种情况，问题可能就出现了。 系统构建平台系统中我们可以进行添加、删除用户、角色、权限、表单、组织结构等等很多类似的操作，而这些操作我们都可以找到它共有的一些极端的边界情况进行测试。比如 （1）删除所有记录后添加；（2）记录已经添加到一定数量需要分屏显示的情况继续添加是否有问题；（3）单个添加和删除都没有问题，那么多个呢？比如说同时给角色增加两个权限。 地图一般的放大、缩小没异常，那当放大缩小到较剧烈的程度会怎么样呢？3.6 观察数据库记录的实际变化是否正确程序对数据库的添加，删除等操作可能牵涉到不止一张表，程序执行数据库操作

19、时候很有可能出现外在表现正常，但数据库没有完成全部要求的操作的情况。测试人员可以打开数据库表进行比较，掌握程序是否对数据库进行了正确的操作。3.7 注意测试流程在测试过程我们经常会发现有些错误难以复现，很有可能这些错误是因为一系列特定操作引起的，注意测试流程能够帮助我们快速、准确的复现错误，从而为程序员解决问题提供足够的帮助信息。3.8 前提条件不满足导致异常很多功能的实现是需要在特定前提下才能够正常执行的，例如：在系统构建平台系统中要删除一条记录（用户，角色，表单等等都有可能），必须首先有选中的记录；执行编辑操作，必须首先选择一个编辑图层；添加地物，该图层必须首先处于编辑状态；要进行裁切操作

20、，需要至少有两个面状实体等等，类似的例子在系统中还有很多。既然这些功能的实现需要特定的前提条件，那我们自然想到当前提条件不满足的情况下系统将如何处理。要求有选中地物的没有任何地物被选中，数据库删除操作缺少当前选中的记录或者要求有选中的面状的地物的而当前选中的是一条线，要求有两个选中地物的我只选择了一个或者选择了多个等等，条件的缺失，错误或者任何其他可能的干扰条件我们都需要去测试是否会引起系统的异常。第四章 测试细则4.1 界面设计细则4.1.1 主窗口1) 细则描述：主界面上的按钮需要添加快捷提示，正确情况如Error! Reference source not found.所示：图1 按钮与

21、快捷提示解决方案：设置button的hint属性。2) 细则描述：主界面上所有的可停靠部分（dockPanl、toolbar、StatusBar等）、注意关闭之后还能恢复，正确情况如Error! Reference source not found.中“方案”窗口：图2 正确情况解决方案：在主目录视图菜单下添加控制显示的功能项，设置这些控件的Visible属性。3) 细则描述：注意修改dockPanl、toolbar、StatusBar、MainMenu 的标题 ，否则当这些控件在浮动状态时，它们缺省的英文标题（customer）就会显示出来。正确情况如Error! Reference sou

22、rce not found.所示，“浏览”工具栏为浮动状态时显示中文标题； 图3 正确情况解决方案：修改这些控件的Text属性。4) 细则描述：按钮高度统一成25象素，对于按钮的caption，如果字数比较少的，文字之间加空格填充（空格数自定义，合适就好），如Error! Reference source not found.中红框所示：图4 正确的按钮高度解决方案：设置button的属性。5) 细则描述：控制Tab键的切换顺序。解决方案：设置控件的TabIndex属性。6) 细则描述：注意整个程序界面中英文一致。解决方案：设置界面属性。7) 细则描述：菜单的名称应该和弹出窗口的标题保持一致，

23、正确的情况如Error! Reference source not found.中红框所示，错误的情况如Error! Reference source not found.中红框所示。 图5 正确的标题图6 错误的标题解决方案：设置窗体属性4.1.2 弹出窗口1) 细则描述：弹出窗口是模式窗口还是非模式窗口，模式窗口如Error! Reference source not found.所示，非模式窗口如Error! Reference source not found.所示。图7 模式窗口图8 非模式窗口解决方案：show() 方法弹出非模式窗口，ShowDialog()方法弹出模式窗口。2)

24、 细则描述：任务栏上是否需要显示窗口。一般情况下任务栏上均不会出现，只有比较大的模块或子系统才会在任务栏上显示。需要显示在任务栏的情况例如Error! Reference source not found.所示，不需要显示在任务栏的情况如Error! Reference source not found.所示图9 需要在任务栏显示的窗口图10 不需要在任务栏显示的窗口解决方案：设置窗体的ShowInTaskBar 属性。3) 细则描述：弹出窗口的初始位置设置是否合适。一般情况下窗口的弹出位置设置在中间位置。也有一些特殊情况，为了方便用户放在其他位置上，只要便于用户操作，初始位置没有一定之规。解

25、决方案：设置窗体的startPosition属性。4) 细则描述：弹出窗口是否需要最大化、最小化按钮。一般情况下弹出窗口均没有最大、最小化按钮。只有一些大的功能或子系统提供最大、最小化按钮。一般在任务栏显示的窗口均有最大、最小化按钮。解决方案：设置窗体的MaximizeBox和MinimizeBox属性。5) 细则描述：弹出窗口是否需要固定窗口大小（不能拖动缩放）。一般情况下有最大、最小化按钮的窗口不固定大小，没有最大、最小化按钮的窗口固定大小。解决方案：设置窗体的FormBorderStyle属性。6) 细则描述：弹出窗口关闭时是否需要有提示。对于大的功能或子系统退出时需要有适当的提示。7)

26、 细则描述：弹出窗口的标题注意修改，注意弹出窗口的标题不要显示为英文，同时要和菜单项的名称相一致。解决方案：设置弹出窗体的属性8) 细则描述：对于弹出窗口，高度不能超过550象素，宽度不能超过750象素（大小可调窗口的初始大小也应遵照此规范）。解决方案：（这样设置有利于800*600的分辨率显示）。9) 细则描述：控件本身的右键菜单功能应该被屏蔽，有如Error! Reference source not found.所示情况是不正确的。图11 右键菜单4.1.3 鼠标状态鼠标状态切换：为了让用户感觉界面更友好，在需要用户较长时间等待的地方，鼠标应该注意切换为等待状态。4.1.4 消息提示框1

27、) 细则描述：默认的所有的提示框统一使用DevelopExpress的消息提示框，如Error! Reference source not found.所示，不要使用.Net系统原有的MessageBox。图12 正确的提示框解决方案：使用GUIUtil 类的封装的静态方法，输出消息提示框。2) 细则描述：选择合适的消息提示框。（“确定”，“确定、取消”，“是、否、取消”等几种消息提示框）。解决方案：使用GUIUtil 类的封装的静态方法，输出消息提示框。3) 细则描述：适当的增加提示信息来确认相关操作。解决方案：例如：删除数据库记录操作、关闭编辑状态、保存等情况增加消息框引导用户完成操作。图

28、13 适当的提示4.1.5 输入框1) 细则描述：输入框允许输入的类型。（是整数还是浮点型，是输入数值还是字符串。）解决方案：使用GUIUtil 类的封装的静态方法，对所有输入框进行输入控制。2) 细则描述：输入框允许输入的范围。（字符串的最大、最小长度，数值的最大、最小值。）解决方案：设置控件属性3) 细则描述：是否允许0的输入，明确0代表什么含义。（例如：在地图图层比例尺设置的时候，0代表的是地图可以放大到无限大，而在打印输出模块，线转面功能的宽度设置的时候，0宽度被认为是不合理的、无意义的，需要禁止用户输入。）4) 细则描述：是否允许输入一些特殊字符，如单引号，如果允许，是否合理。4.1

29、.6 下拉选择框1) 细则描述：下拉选择框是否允许用户输入，还是只能选择已列出选项。如果允许用户输入，则文本框输入所有的需要注意的地方，对下拉选择框一样适用。4.1.7 树形控件1) 细则描述：树控件初始状态设置是否合理，哪些需要展开，哪些需要折叠，或者是否需要全部展开等。解决方案：设置树形控件的属性2) 细则描述：TreeList、GridControl的列头拖动丢失问题。解决方案：设置控件的 TreeList的AllowMoveToCustomozationForm 属性为false.(为防止属性设置丢失，建议在程序初始时在代码中设置属性)在gridView 的DragObjectOver

30、 事件增加if (e.DropInfo.Index 0) e.DropInfo.Valid = false;4.2 非缺陷实例1) 细则描述：改变主界面风格，图例框的滚动条风格没有变化，与整体不统一，这是系统控件的bug，程序员无法控制，如Error! Reference source not found.中红框所示：图14 滚动条2) 细则描述：下拉框的底部为灰色，这是控件自身的美化效果，不是系统的bug，如Error! Reference source not found.所示：图15 下拉框3) 细则描述：窗体标题中的文字无法对齐，如Error! Reference source not

31、 found.所示，这是采用的cell组件自身的问题，程序员无法修复。图16 标题文字4) 细则描述：图中提示框中的描述信息有英文，提示信息中一般不允许有英文，但有些专业术语翻译过来可能更糊涂,所以有时提示信息中使用英文。如Error! Reference source not found.所示：图17 提示文字5) 细则描述：如Error! Reference source not found.所示情况无法修改,很多问题的出现程序员也无法预料。图18 提示文字6) 细则描述：如Error! Reference source not found.所示，删除其中的某条书签记录后，在该系统中默认选

32、中第一条书签记录，而没有默认选中所删除项的下一条书签记录，这种情况不属于系统的bug。图19 默认选项4.3 常用的测试输入操作1) 功能键（F2、F3、F4等）2) 控件的左、右键、双击、拖拽操作（例如在TreeList、GridControl的列标题点击）3) Tab键，顺序是否混乱4) 修饰键（例如 Ctrl 、shift、Alt等）5) 不输入6) 特殊字符（ ；# ； 等）7) 窗口最大、最小化切换操作4.4 白盒测试1) 用 Order By 在所有的工程中搜索，有时可能会有所收获。实际案例：有两个模块总是存在问题，反复检查无法解决，后来偶然发现程序中有Order By F_Code 的写法，在所有的工程中用 Order By 一搜索，竟然有 6 处之多。请大家吸取教训。