工作中常见的界面测试(UI测试)用例设计总结5篇

第一篇：工作中常见的界面测试(UI测试)用例设计总结

大家在编写测试用例时，往往分不清什么是UI，什么是功能。最近特意整理了工作中经常进行的UI测试项。UI测试内容包括以下内容： 1.窗口测试主要测试内容如下：

窗口与窗口之间的调用情况；

窗口尺寸变化时窗口中控件能否自适应；

多个窗口同时打开和调用的情况；

窗口拖动是否正常；

主窗口和子窗口调用能否正常处理；

窗口能否根据浏览器大小进行缩放【双击浏览器、浏览器最大化、最小化和还原查看窗口的变化情况】；

窗口显示标题是否正确。

2.工具条测试主要测试内容如下：

工具条能否正常显示；

工具条能否隐藏；

可移动工具条在窗口中间位置其形状是否正确；

工具栏上工具按钮功能是否能正常实现；

工具按钮显示是否正确、友好、醒目易懂；

工具栏上的工具按钮是否有鼠标悬停提示；

工具栏上的工具按钮是否可以任意定制；

是否有输入框；

是否有个人用工具条；

是否有网站型工具条；

是否有专项型工具条；

是否有企业型工具条。

3.工具条测试主要测试内容如下：

输入正常的字母或数字；

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

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

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

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

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

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

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

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

输入非法数据；

输入默认值；

输入特殊字符集；

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

输入相同的文件名；

输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示。4.菜单测试主要测试内容如下：

菜单项是否符合需求，能否正常工作，是否与实际执行的内容一致；

菜单措辞是否准确；

菜单位置及顺序是否合理；

菜单图形布局是否一致；

下拉菜单是否根据选项含义进行分组；

菜单的热键、快捷键能否有效使用和重复；

帮助菜单的“关于”中应有版权和产品信息；

界面菜单公司信息和产品信息显示是否正确。5.页面布局测试主要测试内容如下：

页面布局是否根据分辨率大小自动调整；

页面长宽比例合理是否合适；

界面风格要一致；

背景色彩搭配要协调。6.图标测试主要测试内容如下：

是否符合表达习惯；

不同目标是否采用不同图标；

图标尺寸是否合适；

图标是否有标注，包括公司图标和产品图标。7.界面按钮测试主要测试内容如下：

按钮位置是否合适，是否有正常响应，是否有相应的匹配按钮如：按钮；

单选框和复选框按钮的测试；

功能按钮图标上或在鼠标经过时是否给予正确提示信息。8.时间控件测试主要测试内容如下：

时间年月日选择（开始时间不可大于结束时间）；

时间有效期；

时间年月日显示是否正确；

时间查询。

9.界面文字测试主要测试内容如下：

界面文字描述是否准确，无异议；

文字大小是否合适（一般9-12号）；

是否出现中英文混合；

界面文字是否可根据浏览器的编码方式自适应。10.界面信息提示测试主要测试内容如下：

提示信息是否具有可理解性的语言描述；

对重要、具有破坏性的操作命令是否有确认信息；

提示信息是否具有统一的标记和标准；

提示信息不易过长。

11.鼠标和快捷键测试主要测试内容如下：

是否支持滑轮；

鼠标点击右键是否显示菜单，取消右键是否隐藏；

无规则点动鼠标，查看界面的响应；

经过键盘或鼠标复制粘贴；

支持快捷键使用；

支持键盘自动浏览按钮（Tab键、Enter键）。

“确定”和“取消”当然在设计UI窗口测试用例时，要根据以上大的测试项，逐渐细分，尽可能多的设计较全面的测试用例，但是还要根据测试软件的具体实现架构进行设计用例

第二篇：常见的软件测试用例设计方法

常见的软件测试用例设计方法有以下几种：

一、等价类划分

1）确定等价类

有效等价类代表对程序的有效输入；无效等价类代表的是其他不正确的任何输入。如果需要，我们还可以将一个等价类划分为更小的一些等价类。

比如，规格说明规定了“请输入书籍的数量（1~99）以及书籍的类型（硬皮、软皮或活页）”。它们对应的等价类分别如下：

书籍数量

书籍类型

2）生成测试用例

1.为每个等价类设置编号。

2.编写测试用例，尽可能多的覆盖尚未被覆盖的有效等价类。直到所有的有效等价类都被测试用例覆盖。测试用例及其覆盖的有效等价类如下：

3.编写测试用例，覆盖一个且仅一个尚未被覆盖的无效等价类。直到所有的无效等价类都被测试用例所覆盖。测试用例及其覆盖的无效等价类如下：

用单个的测试用例覆盖无效等价类，是因为有些输入的错误检查可能会屏蔽或取代其他输入的错误检查。比如②⑦，也许程序提示“非法的书籍数量”后，就不会执行对书籍类型的检查了。

二、边界值分析

经验证明，考虑了边界条件的测试用例比其他没有考虑边界条件的测试用例，具有更高的测试回报率。所谓边界条件，是指输入和输出等价类中恰好处在边界、或超过边界、或在边界以下的状态。

上例中的书籍数量范围是1~99，那么应该针对0，1和99，100的情况分别设计测试用例。

从定义可以看出，等价划分只关注输入空间（输入等价类）的不同，边界值分析还需要从输出空间（输出等价类）设计测试用例。

举例来说：

某个程序按月计算个人所得税的速算扣除数，且最小金额是0，最大金额是13,505。使用边界值分析法，应该设计测试用例测试速算扣除数结果为0和13505的情况。此外，还应观察是否可能设计出导致速算扣除数为负数，或者超过13505的测试用例。

边界值分析法和等价划分重要的区别是，等价划分是从等价类中挑选任意一个元素作为测试数据；边界值分析法考察正处于等价划分边界或在边界附近的状态。

三、因果图

边界值分析和等价划分的缺点是，未对输入条件的组合情况、输入条件之间的相互制约关系进行分析。

1）因果图的基本关系

恒等（Identify）:若a为1，则b为1；否则b为0。

非（NOT）:若a为1，则b为0；否则b为1。

或（OR）:若a或b或c为1，则d为1；否则d为0。

与（AND）:若a和b和c都为1，则d为1；否则d为0。

2）因果图的约束条件

1、对于输入条件的约束有E、I、O、R四种：

异（E）:E必须总为真，而a、b最多只有一个为1。

或（I）:I为真时，a、b和c中至少有一个必须为1。

唯一（O）:a、b中，有且仅有一个必须为1。

要求（R）:如果a为1，b也必须为1。

2、对于输出结果的约束只有M一种：

屏蔽（M）:如果结果a为0，则b强制为0。

一、假设有一规格说明：

“第一列中的字符必须是‘A’或‘B’，第二列中的字符必须是一个数字。在这种情况下，对文件进行更新。如果第一个字符不正确，产生提示信息X12。如果第二个字符不是数字，产生提示信息X13。”

（1）将规格说明分解为可执行的片段，确定“因”和“果”，为每个“因”和“果”都赋予唯一的编号。“因”是条件，是指一个明确的输入条件等价类。“果”是动作，是指一个输出或系统转换（输入对程序或系统状态的延续影响）。

（2）分析规格说明的语义，转换为因果图。原因①和原因②不可能同时成立，为因果图添加对应的约束条件，得到右图。

因果图和添加了约束条件后的因果图

（3）将因果图转换为判定表，每一列代表一个测试用例。

判定表

（4）将判定表中的列转换为测试用例。

二、将因果图转换为判定表的思路（以上述的例子来说明）

1.选择一个“果”作为当前状态。例：71。

2.对因果图回溯，找出导致该“果”为1的所有因的组合（需要考虑到约束条件）。例：001，000。

3.在判定表中为每个“因”的组合生成一列。例：（列3）和（列4）。

4.对于每种“因”的组合，判断所有其他“果”的状态，并放置在对应的每一列中。例：已得在001，000两种组合下结点71的结果为1。判断在“因”为001的组合下，得到70和72的结果为0。判断在“因”为000的组合下，得到70的结果为0，72的结果为1。将“果”的状态填入其对应的列。

对因果图进行回溯时，需要做到以下考虑：

1.当回溯经过一个结果为1的OR结点时，不要将OR结点的1个以上的输入同时设为1。

2.当回溯经过一个结果为0的AND结点时，应列举出导致该结果为0的所有输入情况的组合。然而，当该AND结点的一个输入条件为0时，其他输入有一个或更多的1，则不必考虑其他输入为1的所有情况。

3.当回溯经过一个结果为0的AND结点时，所有输入皆为0的这一种情况应当列举出来。

找出因果图中，所有导致输出状态为0的输入条件

(1)根据上述第c)条思路，我们只需列出使得结点⑤和结点⑥皆为0的情况。结点①②③④的取值状态为：

0，0，0，0（5=0，6=0）

(2)根据第b)条思路，对于结点⑤为1而结点⑥为0的情况，应该列出导致⑥为0的所有输入情况组合。同时，只需列出一种使得⑤为1的情况即可，不需要列出⑤为1时的所有输入情况组合。又根据第a)条思路，当结点⑤为1时，我们不应将结点①和②同时设为1。于是，得到结点①②③④的取值状态：

1，0，0，0（5=1，6=0）

1，0，0，1（5=1，6=0）

1，0，1，0（5=1，6=0）

同样的，对于⑤为0而⑥为1的情况，也只需要列出⑥为1的一种情况即可（尽管在本例中也只有这一种）。

0，0，1，1（5=0，6=1）

因果图有助于用一个系统的方法选择出高效的测试用例集。它还有一个额外的好处，就是可以指出规格说明的不完整性和二义性。但通常它不能生成全部应该被确定的有效测试用例。

注意：因果图方法没有充分考虑边界条件。建议，最好是单独考虑边界值分析。这不意味着我们要为此增加相应多的测试用例，而是在由因果图生成测试用例时，可以将边界条件分析一并考虑进去。最好的结果是既满足了两方面的目标，又不需要增加新的测试用例。

四、错误推测

错误猜测是一项依赖于直觉的非正规的过程，其基本思想是人们利用直觉和经验猜测可能犯得错误或错误易发情况的清单，然后编写测试用例来暴露这些错误。

例如，程序输入中出现0这个值，就是一种错误易发情况。因此可以编写测试用例检查特定的输入值中有0，或特定的输出值被强制为0的情况。同样，在出现输入或输出数目不定的地方，如，对某个列表进行搜索，结果为“空列表”或“只包含一个”条目的列表，也是错误容易发生的情况。

第三篇：常见的测试用例设计方法都有哪些

/ 6

（常见）测试用例-设计方法-面试题目

常见的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

1.等价类划分

常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.2.边界值分析法

边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.3.错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例.例如, 在单元测试时曾列出的许多在模块中常见的错误.以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行.这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例.4.因果图方法

前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等.考虑输入条件之间的相互组合,可能会产生一些新的情况.但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多.因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例.这就需要利用因果图（逻辑模型）.因果图方法最终生成的就是判定表.它适合于检查程序输入条件的各种组合情况.5.正交表分析法

有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。

6.场景分析方法

指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。

您认为做好测试用例设计工作的关键是什么？

白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题

详细的描述一个测试活动完整的过程。

1.项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功

能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后sqa进入项目，开始进行统计和跟踪

2.开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。

3.测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

4.测试用例完成后，测试和开发需要进行评审。

5.测试人员搭建环境

6.开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现bug后提交给bugzilla。

7.开发提交第二个版本，包括bug fix以及增加了部分功能，测试人员进行测试。

8.重复上面的工作，一般是3-4个版本后bug数量减少，达到出货的要求。

9.如果有客户反馈的问题，需要测试人员协助重现以及回归测试。

以往是否曾经从事过性能测试工作？请尽可能的详细描述您以往的性能测试工作的完整过程。

曾经做过一套网管系统的性能测试，主要测试该软件在同时管理大量终端的情况下，在响应时间，cpu/磁盘/内存等参数是否满足要求。

也曾经做过软交换系统的呼叫性能测试，主要是测试软交换系统在有大量呼叫的情况下，响应时间，呼叫成功率，cpu/磁盘/内存等参数是否满足设计要求。

您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

测试网管系统中，使用的mimic来模拟终端，能够大量的节省成本。

测试软交换系统的时候，使用的prolab来模拟终端并发送呼叫软交换，他完成了同时数百人才能完成的摘机拨号工作，主要工作原理是产生一些符合要求的ip包并发送给软交换系统，同时对软交换系统的回应进行处理，决定下一步动作。

您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？

主要是保障在大量用户的情况下，服务能正常使用。

在您以往的工作中，一条软件缺陷（或者叫bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（bug）记录？

1.在传统的bugzilla中，bug描述应该包括以下的信息

2.和bug产生对应的软件版本

3.开发的接口人员

4.bug的优先级

5.bug的严重程度

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

7.bug标题，需要清晰的描述现象

8.bug描述，需要尽量给出重新bug的步骤

9.附件中能给出相关的日志和截图。

高质量的bug记录就是指很容易理解的bug记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。

1、黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别？

软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。

黑盒测试主要是为了发现以下几类错误：

1）是否有不正确或遗漏的功能？

2）在接口上，输入是否能正确的接受？能否输出正确的结果？

3）是否有数据结构错误或外部信息（例如数据文件）访问错误？

4）性能上是否能够满足要求？

5）是否有初始化或终止性错误？

白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。

白盒测试主要是想对程序模块进行如下检查：

1）对程序模块的所有独立的执行路径至少测试一遍。

2）对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。

3）在循环的边界和运行的界限内执行循环体。

4）测试内部数据结构的有效性，等等。

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。

系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）

系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

● 单元测试的主要目的是针对编码过程中可能存在的各种错误，例如用户输入验证过程中的边界值的错误。

● 集成测试主要目的是针对详细设计中可能存在的问题，尤其是检查各单元与其它程序部分之间的接口上可能存在的错误。

● 系统测试主要针对概要设计，检查了系统作为一个整体是否有效地得到运行，例如在产品设置中是否达到了预期的高性能

● 验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要(需求)。

2、您认为做好测试计划工作的关键是什么？

1）明确测试的目标，增强测试计划的实用性

编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确

2）坚持“5W”规则，明确内容与过程

“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。

3）采用评审和更新机制，保证测试计划满足实际需求

测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。

4）分别创建测试计划与测试详细规格、测试用例

应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

3、你认为公司的BUG测试流程是什么？

1）当测试工程师发现了一个bug而且在bug tracking tool里面没有相同的bug, 他需要填写所有需要的bug信息并且把这个bug分配给test leader

2）如果这个bug不是一个真正的bug, test leader需要close这个bug

3）test leader需要审查bug的各种信息都完备，如果有信息不完整，他需要把状态改成”feedback” 并重新assign给提交者

4）如果这个bug是一个真正存在的bug, test leader需要把这个bug分配给相关的开发团队的PM, 并且把bug状态改成Assigned

5）如果这个bug属于另外一个开发团队，PM需要把这个bug重新分配给那个开发团队的PM

6）PM审查bug,并且分配给相应的开发人员去改正。

7）开发人员收到bug以后，对相关的缺陷进行改正，并且重新分配给提交bug的测试人员并且把状态改成”Fixed”

8）测试人员需要对这个bug进行重新测试，保证相关的缺陷已经改正，测试人员可以reopen这个bug如果缺陷依然存在并且重新分配给相关的开发人员或者close这个bug如果缺陷已经改正。

4、测试人员所应具备的知识

1）基本的测试知识，测试方法，测试用例，缺陷的概念

2）测试计划

3）数据方面(数据库/XML/Hibernate/LDAP)

4）表现层知识(JSP/HTML/Struts/CSS)

5）EAI(中间件/SOA概念, 项目相关的经验)

6）测试自动化知识

7）设计模式知识(UML等等)

8）敏捷实践(TDD, Refectoring, CI等等)

9）软件生命周期经验(分析，设计，团队开发，测试，部署)

10）管理经验(Estimation, Mentoring, 团队组织)

11）学习能力

5、测试类型共划分为哪些？

1）功能测试：对软件功能进行测试，检查软件的各项功能是否实现了软件功能说明书（软件需求）上的要求。

2）界面测试：对用户界面进行测试，检查用户界面的美观度、统一性、易用性等方面的内容。

3）流程测试：按操作流程进行测试，主要有业务流程、数据流程、逻辑流程、正反流程，检查软件在按照流程操作时是否能够正确处理。

4）并发测试：在网络环境、并发环境和多用户条件下对软件进行的测试。

5）极限测试：在软件的极限条件下进行的测试，主要有对数据的极限值、边界值操作，对软件进行致命操作等。

6）数据处理测试：对软件数据接口进行的测试，主要检查软件数据处理中输入、处理、输出数据过程。

7）安全测试：对软件安全性方面的测试，主要检测软件中加密、解密、数据备份、恢复、病毒检测等问题。

8）性能测试：对软件整体性能的测试，测试内容有适应性、健壮性、可恢复性、灾难恢复能力等

9）安装测试：在不同PC条件、操作系统、模拟客户机等条件下进行软件的安装测试，主要检查软件打包或发布之后存在的问题。

10）性能测试：对软件整体性能进行测试，测试的内容有适应性、健壮性、可恢复性、灾难恢复能力等

6、你是怎么看待测试的？

1）试想一下如果一个系统开发完毕后不能正常运行可能造成的后果，损失钱财，损失时间，损失客户，等等

2）介绍一下软件测试的意义

a.发现软件错误；

b.有效定义和实现软件成分由低层到高层的组装过程；

c.验证软件是否满足任务书和系统定义文档所规定的技术要求；

d.为软件质量模型的建立提供依据。

3）介绍一下软件测试的目的？

a.确认软件的质量，其一方面是确认软件做了你所期望的事情（Do the right thing），并且确认软件以正确的方式来做了这个事件（Do it right）。

b.提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息。

c.软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。因此软件测试的第三个目的是保证整个软件开发过程是高质量的。

正是基于以上所述，我认为软件测试是整个软件质量保证过程中重要的一部分，这也就是我选择软件测试这个行业的原因

7.如何撰写集成测试计划？

1）确定集成测试对象

2）确定集成测试策略

3）确定集成测试验收标准

4）确定集成测试挂起和恢复条件

5）估计集成测试工作量

6）估计集成测试所需资源

7）进行集成测试任务划分（包括任务名、责任人、输入和输出、风险及应对措施、进度安排等）

8.测试技术方面的鬼话？

1、功能测试的规范化、流程化操作；

2、利用Robot录制和编写自动功能测试脚本

3、利用LoadRunner进行性能测试执行

4、主流关系型数据库（例如Oracle、SQLServer）的优化策略

5、非关系型数据库（例如Trip）的配置、安装、常用命令等

6、非Windows操作系统的安装和常用命令

7、常用服务器的安装、配置和优化策略（Weblogic，TomCat）

8、对系统存在的性能问题进行定位诊断

9、对系统存在的性能问题提出优化解决方案，并配合研发和集成人员进行系统调优

问hr的问题：

1.贵公司近期和远期的发展目标是什么？

2.贵公司的主要竞争对手有哪些？

3.贵公司有多少开发人员有多少测试人员？

4.贵公司又进一步扩充测试人员的计划吗?

5.如果我有幸能进入贵公司的话，我有怎么样的发展？

6.测试人员的沟通能力很重要，贵公司有规范的沟通渠道吗？

7.请介绍一下贵公司的福利情况。

8.请问我什么时候能知道结果？

第四篇：编写测试用例和测试计划

第六章 编写测试用例和测试计划

主要内容：软件测试计划；软件测试方案；软件风险分析

1.软件测试计划

1.1 软件测试计划的简介

1测试计划概念：测试计划在测试中处于中心位置，它阐述了测试准备工作和执行测试的必要条件，同时也形成了测试过程质量保证的基础。

2测试计划的作用：组织和管理测试；使测试工作和整个开发工作整合起来；资源和变更事先最为一个可控制的风险。

1.2 如何编写软件测试计划

1认识测试项目不仅仅只有单一测试计划

2避免不分析直接进行测试阶段日程安排

3避免测试任务的安排超前于开发任务

4避免有些系统测试类型无法按期进入测试

5不正确的变更测试计划

6测试计划里明确更新周期和暂停测试原则

7测试计划不是一成不变的1.3 测试计划包括：简介，目的，范围，测试策略，进度，缺陷的严重程度的定义，风

险分析。

2.软件测试方案

2.1 软件测试方案的概念

软件测试方案描述测试的特征，测试的方法，测试环境的规划，测试工具的设计和选择，测试用例的设计方法，测试代码的设计方案。即包括以下几点：

 明确测试策略（黑盒，白盒，灰盒等）

 细化测试特征

 测试用例的规划

 测试环境的规划

 自动化测试框架的设计

 测试工具的设计和选择

2.2 软件测试计划于软件测试方案的区别

 测试计划是组织管理层面的文档。测试方案是技术层面的文档。

 测试方案需要在测试计划的指导下进行，测试计划提出“做什么”，测试方案明确“怎么做”

 回报的对象不同，测试计划向领导汇报，测试方案是组员共享该文档

3.软件测试的风险

 软件需求风险

 人员的风险

 测试环境的风险

 测试工程师对产品的业务不熟悉

补充：

回归测试：把以前检查过的已经修复好的缺陷，拿来另测看有无带来新的缺陷 反侧：把开发人员已经处理的缺陷拿来测，看是否修复

第五篇：软件测试中报表测试用例设计方法总结

软件测试中报表测试用例设计方法总结

报表的测试主要分为以下几个方面:界面,安全性,准确性,展示速度(性能)

数据统计方面

1、报表统计数据的正确性；

2、报表统计数据的完整性；

3、报表统计数据的合法性；比如，统计金额字段需求要求有“$”等；

报表格式

1、表头字段表示的正确性；

2、表头字段表示的完整性；

3、表头字段表示的字体，字号，美观程度；

4、各统计字段的显示是否满足需求；比如：数据过长时要求折行还是缩小；

5、页眉和页角的表示；

报表的预览和印刷

1、预览中的显示完整性；

2、多页情况下，第2页的表头显示；

3、能否实现需求要求的特定印刷情况；（比如，印刷使用指定的模板）

4、预览后印刷；

5、不预览，直接印刷

6、需求规定各类打印机的测试；

数据准确性测试，带有报表测试的系统分为两类，一类是业务系统中，带有统计分析功能模块，该模块中包含分析报表，这个系统的主体是业务系统，报表是为办理业务的而提供帮助的。

比如说，应年检统计报表，某月应交罚款车辆统计报表，这样的报表数据准确与否，可通过增加、删减、修改相关业务或相关业务的参数，查看统计报表数据变化，检查数据准确性。

另一类是系统只有统计功能，就是我说的数据仓库展现这类，它与业务系统分离，并且经过多层处理，比如数据仓库的数据，经过抽取，清洗，展现前会经过数据挖掘，数据再处理，有些字段在原始数据表中根本就没有。这样的数据准确性测试比较复杂，当然检查出数据错误，修改定位也是很不容易的。

从整个项目节约成本看，逐层测试效果是最好的。完全修改率也是最高的。

首先建立测试数据模型，模拟所有应用表，建立简单易跟踪的数据用例，底层的数据表测试，方法很原始，嘿嘿，通过SQL语句和手工计算，对数据进行比对。对系统中的报表数据准确性测试方法较为灵活，①系统中报表重叠的进行比对

②对子报表汇总与父报表比对，就是对月报表汇总与年报表比对，日报表汇总与月报表比对，这只是一个方面，可以从维度关系考虑，地域，行政级别、时间，个人等方面下手，进行汇总比对

③这个方法如果延伸点呢，可以将报表间的业务逻辑关系作为比对依据。呵呵，这要看测试人员的需求了解深度个人能力了。插几句不想干的话，做测试工作总让我保持快乐状态，前两天我的一个同事说，公司里一直没有人喜欢做测试工作，这个工作太枯燥。嘿嘿，我当时就说我做了这么多年的测试工作从来没有感觉到枯燥。重复性工作不代表枯燥，编程其实不也是重复嘛，人每天谁不重复昨天的事啊，吃饭，吃这个动作重复一生，有谁觉得麻烦枯燥啦？

④使用SQL和手工计算进行比对。以上是差错方式，接下来讲一下查什么错？哪些地方容易出错

●原始表使用错误：因为表比较多，又加上没有统一的数据关系对应表，很容易表使用错误，当然这应该是单元测试检查出来的错误。

●数据处理逻辑错误：这一点容易因为测试人员和开发人员对需求理解有偏差造成争执，所以在需求评审时，对数据处理规则用表达式或伪代码表示清楚。还有就是程序员失误，逻辑编写有偏差，边界值、特殊情况处理不当。

●数据权限：不同用户对数据有着不同的查看权限。这关系到数据的安全性。

●数据误差：数据的保留位数，数据是否是处理计算是否是最后一次计算使用了位数保留和四舍五入。

●由于字典表，数据错误，而造成的数据错误，如，根据性别统计，购买量，表中的男女颠倒，或者没有考虑性别缺失项，用了ifelse,这样就是把表中缺失该项内容的算成了else条件里。或者逻辑中应该考虑用户状态，数据状态类似的字段，容易被忽略，测试应该考虑到。

●最后一项，当数据量相当大的时候，统计应该考虑，切割速度，也就是数据的完整性，由于数据切割的滞后，带来的数据不完整，而造成统计结果不完整。如统计昨天的销售情况，而昨天的数据并没有完全从业务系统数据到数据池，再者月底数据，由于最后一天的数据切割不完整而造成的正月统计数量不准确。

报表的界面和输入输出测试

界面分为输入界面和输出界面；统一的界面要求：美观、统一、易操作。

输入界面要求是：

①输入项字段长度不允许超过字段长度；

②输入不符合字段要求的，不允许查询。如money类型，在输入汉字，字母、特殊字符等不允许查询，并有友好的操作提示。

③用户权限范围外的输入，不允许查询。如用户输入不是其权限范围内的客户号，不允许查询，并有友好的操作提示。

对于选项，应不出现可选择的用户权限以外的选项。

对于汉字模糊查询，考虑不常见字，如“?”即汉字因译码问题，造成的汉字存储出现乱码问题。

输出界面要求：

①因为是报表所以应该有打印、打印预览、报表导出等功能。不能因为报表导出丢失数据，不能因为打印缺少了报表表格框

②报表排列方式可调，用户可按任意列升序或降序排列，或者，按某一关键列的一定规则排序

③报表标题明确，不能含糊误导用户

④报表内可关联查询的项，应能特殊显示，如鼠标有箭头变为手掌，子报表格式与父报表格式统一，数据统一。

报表测试根据项目的定义有大有小,有时只是作为软件的一个部分进行测试,有时整个项目都是测试各种报表.但不论如何,报表的作用始终都是将系统中已经存在的数据根据用户的设置计算加工/整理汇总/最终以清晰的格式展示给用户,以便用户进一步做数据分析或统计.软件中的报表实现一般分为定义报表的所需数据(一般可以通过选择或手工输入条件来缩小数据范围)和定义报表格式两个部分.报表格式除了如国家各行业标准中规定的报表使用固定格式外,大多是根据企业或用户的需要定制报表.所以,做报表测试时要注意以下方面:

1.数据的正确

用户使用报表就是期望通过一个简单方便的平台能快速的查找到他所需要的数据.所以在测试报表时首先就要检查报表中的数据是不是用户需要的数据,如果没有加工的数据,是否保持了原貌;加工过的数据查看加工的结构是否和手工加工的结果一致.简言之,需要测试以下内容.数据的来源：来源于哪张表,哪个字段,数据库中的数值与界面数据的对应.如数据库中性别的数据可能是0或1,但界面显示为男或女,这个对应关系是否正确.数据的范围：是否只显示了报表设置的对应范围；特别要注意边界数据,要清楚报表的需求,是否需要过滤掉被选择的数据.如时间选择为200627~200727,那么是否应该包含9-27这天.数据的对应关系：数据库中的字段是否与报表中的信息对应

数据的格式：小数位,千位符,四舍五入等是否与报表设置一致；单位或税率转换是否正确；组合显示的数据是否合理

数据的排序：排序方式是否与报表设置一致(如果没有设置,是否有一个清晰的默认排序方式,如按字母或数字排序)

流水号：如报表有使用流水号,流水号的生成和格式是否正确.取消操作是否会生成流水号.明细与合计的一致性：各部分明细或小节是否与最后总和一致

其他

测试这一部分内容需要对业务逻辑相当熟悉,对数据库的设计也要非常了解.必要时可以通过自己写查询语句查看数据.有些报表的条件有多有少,但测试方法都是一样.根据条件通过等价类划分和排列组合设置各种条件组合.千万不要盲目的测试,否则会导致该测的没测,多余的测试做了一堆..一般来说有类别划分的(一般界面表现为下拉框),每个类别都要测试到,如性别中的男,女都要测试.输入的可以用等价类来划分要测试的数据.2.格式的正确

数据验证正确后,就需要看看报表的输出格式是否符合要求.可以从以下几方面来检查.报表的整体风格：报表是否符合规定的或用户设置的格式

报表标题：报表的标题是否是正确的报表名称；如报表中有嵌入的数据(会跟随用户的选择而变化的).需要检查数据是否正确,如XX企业9月份财务报表,这个9月就是用户选择的;或者XX公司200627~200727的网站访问量,这个时间段也是用户选择的.公司的一些标志：如logo,名称,地址之类的是否正确

报表的页首与页尾：是否采用了一致的规则.分页：当输出的内容多时,分页是否正确.翻页功能是否正确

友好性：数据或图表是否清晰,一目了然,数据的展示符合用户的习惯；需要特别提醒的数据(如合计,异常数据)是否突出显示；复杂算法处,用户不明白或容易混淆处是否有注释；一些默认的格式是否让人感觉舒服,如对齐,边界,间隔等

3.权限的控制

对于有权限控制的系统，报表当然也应该和用户所具有的权限相一致。需要从两方面校验权限的控制。

报表的条件定义:在条件选择区域，有些下拉框中应该不能显示用户权限范围外的数据。如普通文员在使用报表时，报表名称下拉框中是不可以显示管理者才能查看的报表的。有些以输入的文本框有级别的划分时，都应该要测试输入超越权限的数据的相应。

注意这里一定要测试每个条目。

报表内容：报表中的内容不能显示用户本没有权限查看的数据。

4.报表的输出

报表在电脑上生成后，并不是报表的结束。报表一般都需要打印出来他用，如开会或者提交审批之类。所以报表的打印功能也是非常重要的。测试主要分成三部分：

●打印设置

●打印预览

●实际打印效果

除了打印之外，用户有可能需要导出报表做进一步的分析或用于和其他报表的比较。所以也应该提供导出报表的功能。一般可以导出为CSV,Excel,pdf,html,xml格式。