软件测试小结

第一篇：软件测试小结

1.什么是白盒黑盒测试

白盒测试：是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。

黑盒测试：又被称为功能测试、数据驱动测试或基于规格说明的测试，是通过使用整个软件或某种软件功能来严格地测试, 而并没有通过检查程序的源代码或者很清楚地了解该软件的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，2.测试方法：等价类划分、边界值分析方法、因果图、判定表

等价类划分法就是解决如何选择适当的数据子集来代表整个数据集的问题，通过降低测试的数目去实现“合理的”覆盖，覆盖了更多的可能数据，以发现更多的软件缺陷。

等价类划分法是一种典型的、重要的黑盒测试方法，它将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。利用这一方法设计测试用例可以不考虑程序的内部结构，以需求规格说明书为依据，选择适当的典型子集，认真分析和推敲说明书的各项需求，特别是功能需求，尽可能多地发现错误。等价类划分法是一种系统性的确定要输入的测试条件的方法。

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

因果图法即因果分析图，又叫特性要因图、石川图或鱼翅图，它是由日本东京大学教授石川馨提出的一种通过带箭头的线，将质量问题与原因之间的关系表示出来，是分析影响产品质量的诸因素之间关系的一种工具。从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变),可以通过因果图转换为判定表。

因果图法是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件涉及的各种组合情况。因果图法一般和判定表结合使用，通过映射同时发生相互影响的多个输入来确定判定条件。因果图法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。采用因果图法能帮助我们按照一定的步骤选择一组高效的测试用例，同时，还能指出程序规范中存在什么问题，鉴别和制作因果图。

因果图法着重分析输入条件的各种组合，每种组合条件就是“因”，它必然有一个输出的结果，这就是“果”。3.软件测试的二八原则

80%的缺陷出现在20%的代码中。也即80%的bug多发生在软件的20%的模块。

4.判定覆盖比条件覆盖有更强的逻辑性

判定覆盖, 也称为分支覆盖, 它的基本思想是: 设计若干测试用例, 使被测程序中每个判定的取真分支和取假分支至少执行一次, 即判断真假值均曾被满足。而条件覆盖的基本思想是: 要编写足够的测试用例以确保将一个判断中的每个条件的可能结果至少执行一次。

（1）判定覆盖又称为分支覆盖，它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即：程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。

往往大部分的判定语句是由多个逻辑条件组合而成。

（2）条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。

要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。

5.在代码测试覆盖中，覆盖了条件的测试用例不一定会覆盖代码里的判定分支

要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。

条件覆盖：设计若干测试用例，执行被测程序以后要使每个判断中每个条件的可能取值至少满足一次。

判断M表达式:设条件 a>0 取真 记为 T1 ；假F1

条件 b>0 取真 记为 T2 ；假F2

判断Q表达式:设条件 a>1 取真 记为 T3 ；假F3

条件 c>1 取真 记为 T4 ；假F4

我们用条件覆盖设计的思想就是让测试用例能覆盖T1、T2、T3、T4、F1、F2、F3、F4

【优点】：增加了对条件判定情况的测试，增加了测试路径。

【缺点】：条件覆盖不一定包含判定覆盖。例如，我们刚才设计的用例就没有覆盖判断M的Y分支和判断Q的N分支。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。

6.因果图方法会根据输入输出的依赖关系来设计测试用例

因果图法是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件涉及的各种组合情况。

7.质量模型包括：使用质量、内部质量、外部质量

软件质量模型可以分为：内部质量和外部质量模型、使用质量模型，而质量模型中又将内部和外部质量分成六个质量特性，将使用质量分成四个质量属性，8.软件测试的核心理念及核心技术（救命题）

9.程序规格规定：输入三个整数作为三边的边长构成三角形，当此三角形为一般三角形、等腰三角形和等边三角形的时候，分别计算。

用等价类划分的方法进行用例设计 输入条件要求：

整数、三个数、非零数、整数 输出条件要求：

两边之和大于第三边，等腰，等边 列出所有等价类:

1.使用质量模型包括：有效性、生产力、满意度、安全性；

2.基本软件的测试方法：单元测试、集成测试、系统测试；

3.系统测试：功能测试、恢复测试、安全测试、性能测试、协议测试；

4.软件测试越早，发现的问题越容易修改，投入的代价就越小。

第二篇：软件测试小结

第二阶段学习小结

1.白盒测试需要了解其内部结构和运行机制。白盒测试，也称之为结构测试和逻辑驱动测试。黑盒测试不需了解程序内部结构和内部特征。主要着眼于程序外部的用户界面，关注软件的输入和输出，关注用户的需求，从用户的角度来验证软件的功能。黑盒测试也称之为功能测试和数据驱动测试。

2.黑盒测试技术主要有：等价类划分法、边界值分析法、判定表方法、因果图法、错误推测法。

3.白盒测试主要技术有：语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖、路径覆盖。

4.测试用例的定义：测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。

软件测试的基本格式：软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。{系统测试用例的编号这样定义规则： PROJECT1-ST-001，命名规则是项目名称+测试阶段类型（系统测试阶段）+编号。定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。测试用例设计方法：（1）逐级细分法（2）输入域测试法（3）输出域分析法（4）正交试验设计法（5）业务流程分析法（6）状态迁移法（7）因果图法（8）判定表法（9）错误猜测法(10)等价类划分法（11）边界值分析法}。

5.Bug的描述：

① 和 bug 产生对应的软件版本。

② 开发的接口人员。

③ bug 的优先级。

④ bug 的严重程度。

⑤ bug 可能属于的模块，如果不能确认，可以用开发人员来判断。

⑥ bug 标题，需要清晰的描述现象。

⑦ bug 描述，需要尽量给出重新 bug 的步骤。

⑧ bug 附件中能给出相关的日志和截图。

6.软件测试环境的主要要素：配置测试环境是测试实施的一个重要阶段，测试环境适合与否会严重影响测试结果的重要性和真实性。一般来说，配置测试环境要满足五个基本元素：硬件、软件、网络环境、数据准备、测试工具。

7.测试环境的搭建:单机版测试环境搭建，b/s架构测试环境的搭建，c/s架构测试环境的搭建。

8.测试环境的管理：设置专门的测试环境管理员角色、明确测试环境管理所需的各种文档、测试环境访问权限的管理、测试环境的变更管理、测试环境的备份和恢复。

9.自动化测试工具介绍：性能测试—Loadrunner、Robot、Silk performer，功能测试—QTP、Winrunner、Robot、Silk test，其他测试—Xenu、AiRoboForm。

第三篇：文档加密软件测试小结

加密软件测试小结

1、山丽防水墙

a)厂家技术人员上门安装，简单培训使用方法以及功能 b)加密服务器使用加密KEY方式 c)客户端需登录到服务器

d)可以实现对U盘等移动设备的加密及管理

e)可以实现对网络传输文件的加密管理，即可以选择网络传输的不进行加密

2、亿赛通

a)代理商上门进行安装，简单培训使用方法及功能 b)加密服务器采用授权码方式 c)客户端需登录到服务器

d)可以实现对U盘等移动设备的加密及管理

e)可以针对所使用软件的进程进行加密，可以针对所使用的文件扩展名进行加密 f)可以针对特定文件夹进行落地加密，即只要放到这个文件夹中的文件自动进行加密 g)

3、IP-Guard a)厂家发送软件安装包，我们自行进行安装，附有使用说明文件 b)加密服务器采用授权码方式

c)客户端安装后无需登录到服务器，自动与服务器联系 d)可以实现对U盘等移动设备的加密及管理 e)对文件的加密是采用的监视软件进程方式，只要是该软件进程产生的文件即进行加密，软件进程采用特殊的控制方式，厂家可以提供工具生成授权软件的进程库。f)加密可以按保密级别以及使用部门进行区分，不同密级以及不同部门的加密文件不能互相打开

g)通过管理程序可以对客户端进行非常详细的控制和管理

山丽防水墙和亿赛通的授权使用日期都只有不到一个礼拜，所以测试的内容较少，主要测试了与PDM系统的兼容性，后期再向厂家申请试用时间。

通过测试发现，PDM系统中的零部件图纸如果进行加密的话，山丽防水墙是不能直接通过设计软件直接打开的，其他两款可以直接打开；文档文件也是，如果进行加密的话，山丽防水墙不能直接通过点击打开，需要先下载到本地硬盘才能打开。如果PDM服务器上的图纸文件进行加密的话，文档文件没什么影响，零部件图纸就会出现缩略图不能查看的问题，即使装了加密客户端也不能查看缩略图，用Product View也不能打开查看，把相应的进程加到加密软件的进程里面也不行，IP-Guard因为没有进程工具所以没能进行ProductView进程的添加测试。

鉴于缩略图的影响以及为了图纸的安全，我们建议服务器上的文件不能加密，明文保存，这就需要对PDM系统的访问进行限制，比如不装加密客户端的不能访问PDM系统。山丽防水墙目前还不能实现该功能，亿赛通厂家说有专用网关设备来实现认证访问，准备下周带来进行测试，IP-Guard目前就能实现不装客户端不能访问PDM服务器的功能。对于服务器端不加密的问题，山丽可以通过设置网络不加密来进行控制，但这样就能不能控制通过网络把图纸传送到其他电脑，亿赛通厂家人员说通过其专用网关可以进行控制，等待下周其设备到后进行测试；IP-Guard目前不具备该功能，厂家技术人员说可以实现，但需要进行二次开发。

另外还有其他几款加密软件，厂家说可以实现我们需要的功能，已经约好下面几周进行安装测试。

第四篇：CS结构软件测试小结

安装卸载类：

1、在已经安装软件的情况下，再次进行安装，表现是否正常（比如提示是否升级、检测到已安装），需要考虑已安装和现安装版本差异问题

2、各种杀毒软件（卡巴、瑞星、360）对安装程序的影响

3、是否能在控制面板里面卸载

4、安装后快速启动、桌面、开始程序里面的快捷方式情况

5、卸载时是否退出客户端（退出和不退出都要考虑），卸载后的表现

6、安装的程序是否带有插件

带有微软的framewor，而影响用户的安装和使用

7、安装目录的考虑（中英字符、长度、空目录、根目录、修改目录、默认目录）

8、是否需要考虑在虚拟机中的安装使用？

9、各个版本的安装包大小，客户端产品是需要下载的，所以包的大小对用户来说比较重要 字符（串）类（可输入编辑框或者文本框等也会涉及到）

1、需要考虑字符串长度、字符类型（中文、英文、数字等）、编码类型、如果是英文，还会涉及到大小写的区别。

2、全空格的考虑情况，字符中间含有空格，最导和最后包含空格情况考虑

3、涉及到编码的，要看各个编码下的显示是否正确，以及各个编码之间

4、当有限制长度类的输入时，需要考虑长度刚好达到限制和超过限制后仍然进行输入的情况，也就是需要考虑边界值。

5、对于只能输入字符的地方，尝试输入其他字符比如 汉字，看看操作表现是什么样子。界面类

1、应用程序所有可点击地方是否可以进行操作，菜单、按钮、超链接（文字颜色以及是否能正常超链）、文字等。

2、各种操作对应的正确、错误类提示信息是否正确

3、窗口的缩放（双击的最大最小，点击按钮的最大最小，关闭）、拖动（开多个窗口拖动）、任务栏（左键单击和右键单击的操作）、托盘区、任务管理器操作

一般客户端软件，开着窗口在桌面上移动的时候，cpu占用都比较高，这个性能需要控制在某个合适的范围内。

4、需要考虑窗口的模态性问题，比如有模态窗口的时候，进行其他的操作，以及模态窗口的重绘等。

5、需要考虑软件对键盘上各个键的响应情况，最多用的是enter、shift、crtl、上下左右箭头，home，vendors，pgup，pgdn，del，对tab键的支持等。还要考虑各种热键（全局热键和软件自身的热键）是否能正确响应。

6、各种控件的表现和操作是否正常，下拉列表、日历控件等

7、如果有托盘图标，需要考虑托盘图标的显示状态，是否能显示，操作是否正常等

8、软件的tooltip是否正确合理齐全

9、如果有排序类功能，排序是否正确，如果不正确，和windows系统本身的排序进行比对，看是否一致（例如中文在英文之后，英文是否区分大小写）

10、操作界面的即使动态刷新

11、如果设计到焦点切换的，需要看鼠标的焦点切换是否正常，适合用户使用习惯。

12、涉及到列表类显示的，要看是否显示翻页，翻页是否正常

13、涉及到编辑框的，要看输入内容过多之后，是否有滚轮

14、窗口在屏幕上的位置是否需要具有记忆能力，比如某个窗口操作一次后，下次打开的位置定位在哪里？

15、有的客户端软件要求有飘窗类的提示，需要测试再不同情况下是否能出来，比如最小化到托盘、任务栏以及用ctrl+D显示桌面，是否能正常出来飘窗

16、需要考虑再不同显示器上的显示，各种比例和分辨率下的现实情况。

17、对换行符的处理，有的显示、输入区，如果有换行符的话可能会出现问题

测试遇到过含有换行符的话，后面的内容无法显示出来。

18、一些操作状态的延续变化，很难发现啊。

邮件列表中，在某个分组上点击右键，不放鼠标，将鼠标拖动到分组下的列表上，出现右键菜单不一致的bug。

19、对任务栏的考虑，要考虑任务栏在下方以及在屏幕上下左右侧的情况 兼容性

1、在中英文系统上使用的区别，在控制面板的区域和语言选项里面进行设置，管理选项卡里更改系统区域设置。

2、在不同操作系统上使用的区别（XP,VISTA,WIN 7,2000,2003）

3、在远程操作电脑的时候使用情况，测试的时候遇到过远程操作的时候会可能崩溃的错误。

4、浏览器：不同IE浏览器、带标签页和没有标签页，同一个IE浏览器不同版本的

5、同一个系统的不同系统用户操作（管理员和非管理员）

6、需要考虑不同分辨率，屏幕大小下是否能合适的显示。

7、需要考虑各种浏览器的缓存情况，会不会因为缓存而对测试产生影响

8、对于需要输入文字的地方需要考虑多种输入法切换是否能正常输入。输入达到限制后，再继续输入，是否有问题

9、在32位和64位系统上都需要进行测试。特别是对新的64位系统的支持度。

10、需要操作系统，比如sp1 sp2 sp3等，其他很多操作，可能会有影响的地方都需要考虑一下。

11、需要考虑计算机休眠、待机后再启动软件的表现情况，（还有待机）

各种杀毒软件对软件的影响。瑞星、卡巴、360等

杀毒软件对一些文件类型、端口等有监控，需要考虑。可能由于软件使用某些端口而被杀毒软件阻止而导致不能正常使用

12、jpeg格式图片有灰度图和RGB格式图片，都需要测试到。

13、考虑文件系统格式fat32 /ntfs下区别，比如fat32下有单个文件4G大小的限制等 5 用户体验类

1、界面文字提示是否友好、易懂、简练（因为用户都是懒惰的，不愿意看复杂的东西）

2、操作流程是否清晰，用户知道自己每步都是在做什么

3、有错误类信息，不要使用代码类文字，考虑到用户群体的情况，还要区分中英文（用哪个更好）上传下载传输类

1、上传是否超过最大容量、流量限制

2、上传格式

3、需要考虑不传输文件、传输文件内容为空（大小为0KB，边界值考虑）、文件内容包含特殊字符、文件名字符

4、涉及到网络传输，和端口有关系的，要考虑模拟一下端口错误，封端口的操作（需要补充具体如何封端口）

5、和网络有关系的要考虑使用代理的情况下，软件的运行状况，在传输中设置错误的代理，本地传输并没有受影响（自动收信过程中，设置了代理，但是自动收信还能继续），不受影响应该是正确的。

6、上传下载文件，考虑本地文件，还要考虑ftp，http上的文件。I/O读取类

1、需要考虑磁盘空间不足的情况

2、考虑同不同目录下相同文件的操作情况（比如邮件附件，两次添加同目录下的一个文件和分别添加不同目录下的相同文件的表现）和同目录下同名文件的重复操作

3、正在使用的文件是否是独占状态

4、涉及到文件操作时要考虑文件的类型（例如：txt、doc、gif、png、jpg。。。）、大小（0KB，正常、极大，其实也就是临界值考虑）

5、涉及到导入导出类操作的，需要查看导入导出过程中各种表现是否需要同步变化

6、涉及到文件保存时，需要考虑文件保存的类型、名称的默认给出。

7、文件拖动类的考虑

有的应用程序可以上传、下载、保存文件，那么拖动这些文件试试，看是否会有问题。

例如:对于foxmail邮箱这个软件，可以携带附件，那么试图拖动文件到附件区，或者从附件区拖动附件到文件夹，任务栏，或者拖动到程序中其他地方。另外，发现附件可以直接拖动到正文区进行显示的（新发现的功能，应该是编辑区的控件本身就支持吧，呵呵，惊讶了一把，居然还有这个功能，似乎很方便）。

8、系统对单个文件夹大小做限制，ntfs和fat格式的系统对单个文件大小有限制

9、图片文件原本为jpg格式的，但是修改后缀为gif后添加到表情 或者插入到其他地方。出现不能识别的问题。因为其他控件按照后缀先判断为gif格式，再走gif格式流程处理，但是实际上图片本身是jpg格式的

10、涉及到文件写入读取的，需要考虑移动设备，比如U盘、硬盘、ftp等 8 性能类

1、单核、双核的区别

2、内存大小的区别

3、同一个操作涉及不同的文件大小的时候，PC的反应（例如传输大文件和小文件）

4、涉及到网络操作时，超时是否及时、提示是否合理

5、是否有GDI泄漏（界面？）

6、使用过程中cpu、内存的占用情况 检索、过滤、搜索类

1、对分词的检索是否准确，比如如果检索ab，那么a b是否 会被检索出来？要视要求而定。

2、搜索的时候，对不同格式的文件内容，是否能够正常搜索，比如HTML格式和txt格式之间的区别，因为HTML格式本身含有标签以及其他一些内容，但是这些内容并不显示出来，所以搜索的时候是否需要搜索这些内容，需要进行考虑

3、搜索匹配时，对中英文的支持度（比如输入英文能否匹配中文，输入中文，能否匹配英文等。）

其他

1、客户端类软件，需要注意到开启的各个窗口之间数据同步一致性问题，各个窗口之

间事件触发是否会马上在其他窗口或者界面响应。

2、考虑界面上文字、各个窗口之间需要保持一致的文字说明。（诸如相同属性名称 文字提示信息等）

3、同一个操作涉及到的不同状态变化是否正常。（例如，点击某个链接，文字颜色是 否变化，点击某个按钮，按钮颜色或者属性是否变化等）

4、使用软件的过程中，多关注cpu、内存、句柄占用等方面的情况。

5、要能多考虑各种异常情况（磁盘空间不足、文件占用、网络断掉、断电、手动切进程模拟异常退出）

6、涉及到对文件目录的操作，需要考虑是否能记住/清除原来使用过的文件目录。如果是新建，要考虑是否可以新建成功（windows对新建文件的字符限制）

7、同一类的界面表现、操作应该尽量保持保持一致。（？没有描述好）

8、要多考虑进行了一个操作/设置后，可能会影响的其他方面，同步表现是否正常，设置是否有效等。

9、和服务器有相关的一些操作，都要考虑一些操作是在客户端处理，还是在服务器端处理的。服务器和客户端之间的一些交互返回信息，比如错误码等。

11、个人想法总结类

1、写总结、bug类语言描述一定要慎重，多读几遍，以便让其他人更能看明白，避免 求快而写错别字，用错术语。总结类需要写的更专业一些，避免通俗的、麽凌两可的的语言描述。宁可多花时间少写内容，少报bug，也不要报上去的bug，给别人看的总结出现过多纰漏，没有发现的bug可能是工作失误，但是发现了，但是却有不描述好，或者自己描述的不确定后事后自己都解释不清楚的话，那就更糟糕了，更上级看的总结也是如此，及时发现的bug再多，总结却是评价你这次测试的一个方面，如果总结写的很差，必然给领导留下很差的印象，或者总是在受到领导的批评。总之，三思而后行，是没错的，也许某些时候会降低工作效率，但是有时候，出现错误带来的负面影响比工作效率低下带来的负面影响更大。

2、开发对于一个软件安装和使用中生成的各种文件，最好有一份比较好的说明文档，当然开发可能没有时间去写，而且公司里面如果没有强行要求的话，他们也是不会写的，所以测试人员就只能自己多去钻研了，对于这些文件的了解对于测试也是很有必要的。遇到不懂的要及时跟开发沟通询问。有时候可能需要花费比较多的时间来了解开发的一些处理流程和文件具体含义（比如一些XML文件具体保存的是什么内容），这就需要协调和测试时间的冲突，因为要花时间了解，所以测试必然会耽误时间，但是了解之后却有利于进行某些功能的测试。慢慢改进吧。

3、不属于自己的任务，还是不要多去做的好

4、有时候自己提出来的产品问题，不一定会被领导、策划或者其他相关开发人员接受，除非等到产品发展部提出来。

5、测试中，只要有一点问题，就应该及时提出来，如果自己用的不顺手，或者觉得不合理的，自己多记录和总结，虽然不一定会被公司采纳，但是可以作为自己的总结类内容，整理出来。

12、可用性用户体验

1、跟网络有关系的，对网络错误的提示，有的需要及时，有的不需要频繁提示网络错误，应该多提供几次重连，比如三次，如果重连三次都发现网络错误连接失败，就提示用户，否则太频繁会有骚扰和降低用户对产品的信赖

2、给用户提供的操作，用户可以用，也可以选择不用，所以界面上需要提供取消类的入口，否则强制性的使用体验上不是很好，比如提供上一步类的入口也类似。

3、需要判断重复性的操作（已经安装、已经导入、已经。。）是否能提示用户

4、涉及到告诉用户文件类型的操作，应该尽可能明确的给予显示类型，因为不是很多用户对文件类型有概念。比如如果某个功能需要导入txt格式文件，尽量做到能自动检测显示出来，而不是让用户自己去找

5、像日历这种控件，不仅仅需要提供月更改入口，还要提供便利的年更改的入口

6、对于一些快捷键，能给予tip或者附带在文字后面的，尽量让用户可见，否则让用户揣测，那太不人性化了点吧。

7、发现***和其他圆角的窗口有同样的情况，最大化时鼠标移到屏幕的最右上角点击，如果没点中按钮而是正好点在圆角的地方，则关掉的不是闪电邮而是它后面的窗口，比如浏览器……因为我经常把鼠标往右上角一推就按，不会去找按钮，所以好几次了。不过这倒也不太算是毛病..

第五篇：软件测试（推荐）

一、简答5*6’

1.为什么不让时间有余的人做测试工作

表面上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心，善于学习、思考和发现问题，细心有条理，总结问题，如果具备这样的优点，做其它工作同样也会很出色，因此这里还有一个要求，就是要喜欢测试这项工作。2.软件测试风险主要体现在哪里

我们没有对软件进行完全测试，实际就是选择了风险，因为缺陷极有可能存在没有进行测试的部分。因此，我们要尽可能的选择最合适的测试量，把风险降低到最小 3.所有软件测试缺陷都需要修复吗

从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试人员要做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队，要做的是对每一个软件缺陷进行取舍，根据风险决定那些缺陷要修复。发生这种现象的主要原因如下：-没有足够的时间资源。在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且在项目中没有预算足够的回归测试时间，修改缺陷可能引入新的缺陷。

-有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进行修复。-不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有时间时考虑再处理。缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复，不同角色的人员从不同的角度来思考，以做出正确的决定。4.如何减少测试人员跳槽带来的损失 建议我们从以下两个方面做起：

-加强部门内员工之间的互相学习，互相学习是建立学习型组织的基本要求，是知识互相转移的过程。在此基础上，可以把个人拥有的技术以知识的形式沉积下来，也就完成了隐性知识到显性知识的转化。

-管理者就应该把员工的个人成长和企业的发展联系起来，为员工设定合理发展规划并付诸实现。

5.验收测试的注意点有哪些 测试要注意下面的事项：

（1）用户现场测试不可能测试全部功能，因此要测试核心功能。这需要提前做好准备，这些核心功能一定要预先经过测试，证明没有问题才可以和用户共同进行测试。测试核心模块的目的是建立用户对软件的信心。当然如果这些模块如果问题较多，不应该进行演示。（2）如果某些模块确实有问题，我们可以演示其它重要的业务功能模块，必要时要向用户做成合理的解释。争得时间后，及时修改缺陷来弥补。（3）永远不能欺骗用户，蒙混过关。6.完全测试程序是可能的吗

实际上完全测试是不可能的。主要有以下原因：-完全测试比较耗时，时间上不允许；

-完全测试通常意味着较多资源投入，这在现实中往往是行不通的；-输入量太大，不能一一进行测试；-输出结果太多，只能分类进行验证；-软件实现途径太多；

-软件产品说明书没有客观标准，从不同的角度看，软件缺陷的标准不同；因此测试的程度要根据实际情况确定 7.是不是发现的缺陷越多就说明软件缺陷越多 其中的原因主要如下：

-代码复用、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的子类会包含基类的错误，反复拷贝同一代码意味可能也复制了缺陷。-程序员比较劳累是可以导致某些连续编写的功能缺陷较多。

“缺陷一个连着一个”不是一个客观规律，只是一个常见的现象。如果软件编写的比较好，这种现象就不常见了。测试人员只要严肃认真的测试程序就可以了。8.软件测试就是QA吗

软件测试人员的职责是尽可能早的找出软件缺陷，确保得以修复。而质量保证人员（QA）主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。测试人员的主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象。软件测试和质量是相辅相成的关系，都是为了提高软件质量而工作。9.测试产品和测试项目区别

习惯上把开发完成后进行商业化、几乎不进行代码修改就可以售给用户使用的软件成为软件产品，也就是可以买“卖拷贝”的软件，软件项目是一种个性化的产品，可以是按照用户要求全部重新开发，也可以修改已有的软件产品来满足特定的用户需求。项目和产品的不同特点，决定我们测试产品和测试项目仍然会有很多不同的地方：

-质量要求不同。通常产品的质量要高一些，修复发布后产品的缺陷成本较高，甚至会带来很多负面的影响。而做项目通常面向某一用户，虽然质量越高越好，但是一般只要满足用户要求就可以了。测试资源投入多少不同。做软件产品通常是研发中心来开发，进度压力要小些。同时由于质量要求高，因此会投入较多的人力、物力资源。项目最后要和用户共同验收测试，这是产品测试不具有的特点。此外，测试产品与测试项目在缺陷管理方面、测试策略制定都会有很大不同，测试管理者应该结合具体的环境，恰如其分的完成工作 10.如何编写提交给用户的测试报告

测试报告一般分为内部测试报告和外部测试报告。内部报告是我们在测试工作中的项目文档，反映了测试工作的实施情况,一般外部测试报告要满足下面几个要求：

根据内部测试报告进行编写，一般可以摘录；不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道；报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的；报告上面的内容尽量要真实可靠；整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告。总之，外部测试报告要小心谨慎的编写。

二、论述2*12’

1.请论述为什么要进行软件测试，并列举历史上2~3个著名软件测试（缺陷）案例，说明测试重要性

软件测试的目的,第一是确认软件的质量，其一方面是确认软件做了你所期望做的事情（，另一方面是确认软件以正确的方式来做了这个事情。第二是提供信息，比如提供给开发人员或程序经理的回馈信息，为风险评估所准备的信息。第三软件测试不仅是在测试软件软件产品本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。因此，软件测试的第三个目的是保证整个软件开发过程是高质量的。

爱国者导弹防御系统把“枪口”对准了自己人 美国迪斯尼公司的狮子王游戏软件的兼容性问题 售票系统性能问题

2.论述软件测试科学的发展历程 1957年之前－调试为主 20世纪50年代，计算机刚诞生不久，只有科学家级别的人才会去编程，需求和程序本身也远远没有现在这么复杂多变，相当于开发人员一人承担需求分析，设计，开发，测试等所有工作，当然也不会有人去区分调试和测试。

1957–1978－证明为主 当时计算机应用的数量，成本和复杂性都大幅度提升，随之而来的经济风险也大大增加，测试就显得很有必要了，这个时期测试的主要目就是确认软件是满足需求的，也就是我们常说的“做了该做的事情”。

1979–1982－破坏为主 我们不仅要证明软件做了该做的事情，也要保证它没做不该做的事情，这会使测试更加全面，更容易发现问题。

1983–1987－评估为主 人们提出了在软件生命周期中使用分析，评审，测试来评估产品的理论。软件测试工程在这个时期得到了快速的发展.1988–至今－预防为主 预防为主是当下软件测试的主流思想之一。测试不是在编码完成后才开始介入，而是贯穿于整个软件生命周期。3.论述软件缺陷的由来

软件缺陷的产生主要是由软件产品的特点和开发过程决定的。

软件本身：①需求不清晰，导致设计目标偏离客户的需求，从而引起功能或产品特征上的缺陷。②系统结构非常复杂，而又无法设计成一个很好的层次结构或组件结构，结果导致意想不到的问题或系统维护、扩充上的困难；即使设计成良好的面向对象的系统，由于对象、类太多，很难完成对各种对象、类相互作用的组合测试，而隐藏着一些参数传递、方法调用、对象状态变化等方面问题。③对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错误。④对一些实时应用，要进行精心设计和技术处理，保证精确的时间同步，否则容易引起时间上不协调，不一致性带来的问题。⑤没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等问题，从而存在系统安全性、可靠性的隐患。⑥系统运行环境的复杂，不仅用户使用的计算机环境千变万化，包括用户的各种操作方式或各种不同的输入数据，容易引起一些特定用户环境下的问题；在系统实际应用中，数据量很大。从而会引起强度或负载问题。⑦由于通信端口多、存取和加密手段的矛盾性等，会造成系统的安全性或适用性等问题。⑧新技术的采用，可能涉及技术或系统兼容的问题，事先没有考虑到。

团队工作：系统需求分析时对客户的需求理解不清楚，或者和用户的沟通存在一些困难。不同阶段的开发人员相互理解不一致。对于设计或编程上的一些假定或依赖性，相关人员没有充分沟通。项目组成员技术水平参差不齐技术问题。算法错误：在给定条件下没能给出正确或准确的结果。语法错误：对于编译性语言程序，编译器可以发现这类问题；但对于解释性语言程序，只能在测试运行时发现。计算和精度问题：计算的结果没有满足所需要的精度。系统结构不合理、算法选择不科学，造成系统性能低下。接口参数传递不匹配，导致模块集成出现问题。

项目管理的问题：缺乏质量文化，不重视质量计划，对质量、资源、任务、成本等的平衡性把握不好，容易挤掉需求分析、评审、测试、等时间，遗留的缺陷会比较多。系统分析时对客户的需求不是十分清楚，或者和用户的沟通存在一些困难。开发周期短，需求分析、设计、编程、测试等各项工作不能完全按照定义好的流程来进行，工作不够充分，结果也就不完整、不准确，错误较多；周期短，还给各类开发人员造成太大的压力，引起一些人为的错误。开发流程不够完善，存在太多的随机性和缺乏严谨的内审或评审机制，容易产生问题。文档不完善，风险估计不足等。4.软件测试V模型

①绘制示意图

②阐述每个步骤是做什么 需求分析

即首先要明确客户需要的是什么，需要软件作成什么样子，需要有那几项功能

概要设计

主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。详细设计

对概要设计中表述的各模块进行深入分析，对各模块组合进行分析等。软件编码

按照详细设计好的模块功能表，编程人员编写出实际的代码。单元测试

按照设定好的最小测试单元进行按单元测试，主要是测试程序代码，为的是确保各单元模块被正确的编译，单元的具体划分按不同的单位与不同的软件有不同。集成测试

经过了单元测试后，将各单元组合成完整的体系，主要测试各模块间组合后的功能实现情况，以及模块接口连接的成功与否，数据传递的正确性等，其主要目的是检查软件单位之间的接口是否正确。根据集成测试计划，一边将模块或其他软件单位组合成系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。系统测试

经过了单元测试和集成测试以后，我们要把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞，等。验收测试

主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到符合效果的。