如何规范某些软件质量特性的可测量性?

前言

问题描述：我们在测试过程中是不是发现无法给一些质量特性进行评估，比如：可移植性，美观，可维护性，易用性等。没有准确的给他们定一个标准，达到怎样就通过测试。那么如何规范这些软件质量特性的可测量性呢？

一、 质量属性

许多产品特性可以称为质量属性，但是在许多系统中需要认真考虑的仅是其中的一小部分。如果开发者知道哪些特性对项目的成功至关重要，那么他们就能选择软件工程方法来达到特定的质量目标，根据不同的设计可以把质量属性分类。

一种属性分类的方法是把在运行时可识别的特性与那些不可识别的特性区分开。另一种方法是把对用户很重要的可见特性与对开发者和维护者很重要的不可见特性区分开。那些对开发者具有重要意义的属性使产品易于更改、验证，并易于移植到新的平台上，从而可以间接地满足客户的需要。

对用户最重要的属性　　　　　　　

有效性　　　　　　　　　　　　

高效性　　　　　　　　　　　　

灵活性　　　　　　　　　　　

完整性　　　　　　　　　　　　

互操作性

可靠性

健壮性

可用性

对开发者最重要的属性

可维护性

可移植性

可重用性

可测试性

产品的不同部分与所期望的质量特性有着不同的组合。高效性可能对某些部分是很重要的，而可用性对其它部分则很重要。把应用于整个产品的质量特性与特定某些部分、某些用户类或特殊使用环境的质量属性要区分开。

定义质量属性必须根据用户对系统的期望来确定。定量地确定重要属性提供了对用户期望的清晰理解，这将有助于设计者提出最合理的解决方案。

二、对用户重要的属性

1.有效性

有效性指的是在预定的启动时间中，系统真正可用并且完全运行时间所占的百分比。更正式地说，有效性等于系统的平均故障时间除以平均故障时间与故障修复时间之和。有些任务比起其它任务具有更严格的时间要求，此时，当用户要执行一个任务但系统在那一时刻不可用时，用户会感到很沮丧。询问用户需要多高的有效性，并且是否在任何时间，对满足业务或安全目标有效性都是必须的。一个有效性需求可能这样说明：“工作日期间，在当地时间早上6点到午夜，系统的有效性至少达到95%，在下午4点到6点，系统的有效性至少可达到98%。

2.效率

　　 效率是用来衡量系统如何优化处理器、磁盘空间或通信带宽的。如果系统用完了所有可用的资源，那么用户遇到的将是性能的下降，这是效率降低的一个表现。拙劣的系统性能可激怒等待数据库查询结果的用户，或者可能对系统安全性

造成威胁，就像一个实时处理系统超负荷一样。为了在不可预料的条件下允许安全缓冲，你可以这样定义：“在预计的高峰负载条件下，10%处理器能力和15%系统可用内存必须留出备用。”在定义性能、能力和效率目标时，考虑硬件的最小配置是很重要的。

3.灵活性

　 就像我们所知道的可扩充性、增加性、可延伸性和可扩展性一样，灵活性表明了在产品中增加新功能时所需工作量的大小。如果开发者预料到系统的扩展性，那么他们可以选择合适的方法来最大限度地增大系统的灵活性。灵活性对于通过一系列连续的发行版本，并采用渐增型和重复型方式开发的产品是很重要的。灵活性目标可以是如下设定的：“一个至少具有6个月产品支持经验的软件维护程序员可以在一个小时之内为系统添加一个新的可支持硬拷贝的输出设备。”

4.完整性

　 完整性主要涉及：防止非法访问系统功能、防止数据丢失、防止病毒入侵并防止私人数据进入系统。完整性对于通过www执行的软件已成为一个重要的议题。电子商务系统的用户关心的是保护信用卡信息，web的浏览者不愿意那些私人信息或他们所访问过的站点记录被非法使用。完整性的需求不能犯任何错误，即数据和访问必须通过特定的方法完全保护起来。用明确的术语陈述完整性的需求，如身份验证、用户特权级别、访问约束或者需要保护的精确数据。一个完整性的需求样本可以这样描述：“只有拥有查账员访问特权的用户才可以查看客户交易历史。”

5.互操作性

　　 互操作性表明了产品与其它系统交换数据和服务的难易程度。为了评估互操作性是否达到要求的程度，你必须知道用户使用其它哪一种应用程序与你的产品相连接，还要知道他们要交换什么数据。如wps可以写下这样的互操作性需求：“wps可以导入office生成的doc后缀的文件，亦可以导出同类格式的文档”。

6.可靠性

　　 可靠性是软件无故障执行一段时间的概率。健壮性和有效性有时可看成是可靠性的一部分。衡量软件可靠性的方法包括正确执行操作所占的比例，在发现新缺陷之前系统运行的时间长度和缺陷出现的密度。根据如果发生故障对系统有多大影响和对于最大的可靠性的费用是否合理，来定量地确定可靠性需求。如果软件满足了它的可靠性需求，那么即使该软件还存在缺陷，也可认为达到其可靠性目标。要求高可靠性的系统也是为高可测试性系统设计的。例如银行的支付系统，这些设备全天工作并且要求数据的完整和安全。用户要求真正与支付的那部分软件要高可靠性，而其它系统功能，例如周

期性地统计交易数据，则对可靠性要求不高。对于该系统的一个可靠性需求说明如下：“由于软件失效引起交易失败的概率应不超过1‰”。

7.健壮性

　　 健壮性指的是当系统或其组成部分遇到非法输入数据、相关软件或硬件组成部分的缺陷或异常的操作情况时，能继续正确运行功能的程度。健壮的软件可以从发生问题的环境中完好地恢复并且可容忍用户的错误。当从用户那里获取健壮性的目标时，询问系统可能遇到的错误条件并且要了解用户想让系统如何响应。举个图形引擎的例子，该图形引擎具有描述图形规划的数据文件，并且把这一规划传送到指定的输出设备上。许多需要产生规划的应用程序就要请求调用图形引擎。由于在图形引擎中，我们将无法控制这些应用程序的数据，所以此时健壮性就成为必不可少的质量属性。我们的一个健壮性需求是这样说明的：“所有的规划参数都要指定一个缺省值，当输入数据丢失或无效时，就使用缺省值数据。”这个例子反映了对一个“用户”是另一个软件应用程序的产品，其健壮性设计的方法。

8.可用性

　　 可用性也称为“易用性”和“人类工程”，它所描述的是许多组成“用户友好”的因素。可用性衡量准备输入、操作和理解产品输出所花费的努力。你必须权衡易用性和学习如何操纵产品的简易性。“CMS备货管理系统”的分析员询问用户这样的问题：“你能快速、简单地请求某商品备货并浏览其它信息，这对你有多重要？”和“你请求某一种商品备货到出库大概需花多少时间？”对于定义使软件易于使用的许多特性而言，这只是一个简单的起点。

对于可用性的讨论可以得出可测量的目标，例如“一个培训过的用户应该可以在平均 3分钟或最多5分钟时间以内，完成从供应商目录表中请求一种商品备货到出库的操作。”同样，调查新系统是否一定要与任何用户界面标准或常规的相符合，或者其用户界面是否一定要与其它常用系统的用户界面相一致。这里有一个可用性需求的例子：“在文件菜单中的所有功能都必须定义快捷键，该快捷键是由Ctrl键和其它键组合实现的。出现在Microsoft Word XP中的菜单命令必须与Word使用相同的快捷键”。

可用性还包括对于新用户或不常使用产品的用户在学习使用产品时的简易程度。易学程度的目标可以经常定量地测量，例如，“一个新用户用不到30分钟时间适应环境后，就应该可以对一个商品进行备货出库处理”，或者“新的操作员在一天的培训学习之后，就应该可以正确执行他们所要求的任务的95%”。当你定义可用性或可学性的需求时

，应考虑到在判断产品是否达到需求而对产品进行测试的费用。

三、对开发者重要的属性

1.可维护性

　　 可维护性表明了在软件中纠正一个缺陷或做一次更改的简易程度。可维护性取决于理解软件、更改软件和测试软件的简易程度，可维护性与灵活性密切相关。高可维护性对于那些经历周期性更改的产品或快速开发的产品很重要。你可以根据修复一个问题所花的平均时间和修复正确的百分比来衡量可维护性。“CMS备货管理系统”包括如下的可维护性需求：“物流部门提出修改与增加备货商品的查询条件，对于现有报表的更改操作必须在3天内完成。”等等。在图形引擎工程中，我们知道，我们必须不断更新软件以满足用户日益发展的需要，因此，我们确定了设计标准以增强系统总的可维护性：“函数调用不能超过两层深度“，并且“每一个软件模块中，注释与源代码语句的比例至少为1∶2。”认真并精确地描述设计目标，以防止开发者做出与预定目标不相符的愚蠢行为。

2.可移植性

　　 可移植性是度量把一个软件从一种运行环境转移到另一种运行环境中所花费的工作量。软件可移植的设计方法与软件可重用的设计方法相似。可移植性对于工程的成功是不重要的，对工程的结果也无关紧要。可以移植的目标必须陈述产品中可以移植到其它环境的那一部分，并确定相应的目标环境。于是，开发者就能选择设计和编码方法以适当提高产品的可移植性。

3.可重用性

　　 从软件开发的长远目标上看，可重用性表明了一个软件组件除了在最初开发的系统中使用之外，还可以在其它应用程序中使用的程度。比起创建一个你打算只在一个应用程序中使用的组件，开发可重用软件的费用会更大些。可重用软件必须标准化、资料齐全、不依赖于特定的应用程序和运行环境，并具有一般性。确定新系统中哪些元素需要用方便于代码重用的方法设计，或者规定作为项目副产品的可重用性组件库。

4.可测试性

　　 可测试性指的是测试软件组件或集成产品时查找缺陷的简易程度。如果产品中包含复杂的算法和逻辑，或如果具有复杂的功能性的相互关系，那么对于可测试性的设计就很重要。如果经常更改产品，那么可测试性也是很重要的，因为将经常对产品进行回归测试来判断更改是否破坏了现有的功能性。因为我们知道随着图形引擎功能的不断增强，我们需要对它进行多次测试，所以作出了如下的设计目标：“一个模块的最大循环复杂度不能超过20。”循环复杂度度量一个模块源代码中逻辑分支数目。在一个模块中加入过多的

分支和循环将使该模块难于测试、理解和维护。如果一些模块的循环复杂度大于20，这并不会导致整个项目的失败，但指定这样的设计标准有助于开发者达到一个令人满意的质量目标。

四、属性的取舍

有时，不可避免地要对一些特定的属性对进行取舍。用户和开发者必须确定哪些属性比其它属性更为重要，并定出优先级。在他们作决策时，要始终遵照那些优先级。例如，增强软件可重用性的设计方法也可以使软件变得灵活、更易于与其它软件组件相连接、更易于维护、更易于移植并且更易于测试。一个单元格中的减号表明单元格所在行的属性增加了对其所在列的属性的不利影响。高效性对其它许多属性具有消极影响。如果你编写最紧凑，最快的代码，并使用一种特殊的预编译器和操作系统，那么这将不易移植到其它环境，而且还难于维护和改进软件。

类似地，一些优化操作者易用性的系统或企图具有灵活性、可用性并且可以与其它软硬件相互操作的系统将付出性能方面的代价。例如，比起使用具有完整的制定图形代码的旧应用系统，使用外部的通用图形引擎工具生成图形规划将大大降低性能。你必须在性能代价和你所提出的解决方案的预期利益之间作出权衡，以确保作出合理的取舍。为了达到产品特性的最佳平衡，你必须在需求获取阶段识别、确定相关的质量属性，并且为之确定优先级。

如果软件要在多平台下运行（可移植性），那么就不要对可用性抱有乐观态度。

可重用软件能普遍适用于多种环境中，因此，不能达到特定的容错（可靠性）或完整性目标。

对于高安全的系统，很难完全测试其完整性需求；可重用的类组件或与其它应用程序的互操作可能会破坏其安全机制。

在软件中，其自身不能实现质量特性的合理平衡。在需求获取的过程中，加入对质量属性期望的讨论，并把你所了解的写入软件需求规格说明中。这样，才有可能提供使所有项目风险承担者满意的产品。

五、可测试性的具体体现

功能测试

性能测试

极限压力测试

容错测试

并发测试

功能测试

1.安装测试

a.安装过程中对于缺省安装目录及任意指定的安装目录，是否都能正确安装；

b.若是选择安装，查看能否实现其相应的功能；

c.在所有能中途退出安装的位置退出安装程序后，验证此程序并未安装成功（没有程序组及程序项产生）；

d.软件安装后，对其它已经安装的软件是否有影响；

e.裸机安装后，各功能点是否可用；

f. 安装前，安装程序是否判断可用磁盘空间大小，如果不能满足安装空间要求，安装程序能否继续；

g. 安装过程

中查看 版权声明、版本信息、公司名称、LOGO等是否符合标准；

h.安装过程中界面显示与提示语言是否准确、友好；

i.重复安装时系统是否有提示、是否可以覆盖安装、是否可以升级安装、是否允许多版本共存；

j.是否有注册码或硬件加密狗，在没有它们（或错误）存在的情况下能否顺利安装。

2.配置测试

a.是否可以按照用户手册的说明，运行于多种操作系统（Windows 各版本 、Unix 、Linux 等）；

b.按系统最低要求进行软件的安装配置，查看能否正常实现各种功能；

c.数据源等信息配置不正确时能否给出提示信息；

d.是否可以按照用户手册的说明，支持多种数据库。

3.卸载测试

a.卸载后注册表中的注册信息及相关的程序安装目录是否能完全删除掉；

b.卸载过程中完全删除共享文件后，看其它程序能否正常运行；

c.卸载后，是否对其它已经安装的软件有影响；

d.系统卸载后用户建立文档是否保留；

e.软件卸载画面上的软件名称及版本信息是否正确；

f.在所有能中途退出卸载的位置是否能正确退出；

g.卸载过程中界面显示与提示语言是否准确、友好；

h.卸载后安装此系统能否打开原来保存的文件，并一切运行正常；

i.卸载程序如果要求重新启动机器，在重启动之间是否给用户提示以保存现有的己运行的程序的资料；

j.是否可以选择组件进行卸载；

k.卸载过程中，对意外情况的处理（掉电等）；

l.在卸载过程中，是否有终止或者结束按钮。

4.运行与关闭测试

a.运行时是否与其它应用程序有冲突(内存冲突)；

b.是否可以同时运行多个程序；

c.任务栏有无程序运行提示；

d.若有未保存的数据，关闭系统时是否有提示；

e.后台服务程序在点击关闭按钮时是否有确认提示；

f.运行时是否过份占用系统资源、退出时能否完成释放占用的系统资源。

5.服务程序的测试：

a.系统是否限制服务器程序启动的数量,如不限制,同一范围内启动多个服务是否对系统有影响；

b.服务程序能否长时间正常运行；

c.外界异常后，服务程序的自动恢复能力（服务器掉电、网络中断后恢复、数据库异常后恢复…）；

d.在点击关闭按钮时是否有确认提示；

e.应用程序与其他程序是否兼容（能否避免内存冲突）。

6.系统管理（参数设置）

a.参数设置后，能否正确的进行应用；

b.设置错误参数，系统的容错能力；

c.修改参数，对与之相关模块的影响；

d.系统是否有默认的参数，A 有：默认的参数是否起到作用 ；B 没有：不设置，系统能否运行或者给出提示。

7.用户、权限管理

a.赋予一个人员相应的权限后，在界面上看此人员是否具有此

权限，并以此人员身份登陆，验证权限设置是否正确（能否超出所给予的权限）；

b.删除或修改已经登陆系统并正在进行操作的人员的权限，程序能否正确处理；

c.重新注册系统变更登陆身份后再登录，看程序是否能正确执行，具有权限是否正确；

d.在有工作组或角色管理的情况下，删除包含用户的工作组或角色，程序能否正确处理；

e.不同权限用户登录同一个系统，权限范围是否正确；

f.覆盖系统所有权限设定；

g.能否添加信息为空的用户(其中包括空用户名及空口令、空用户名非空口令、非空用户名及空口令)；

h.能否添加长用户名及长口令，如果允许，新用户能否正确登录；

i.系统是否允许删除系统管理员这一特殊用户或修改系统管理员口令，删除或修改后系统的实际情况；

j.登录用户能否修改自己的权限；

k.添加用户（有标识或编号）:标识相同，用户名不同；标识相同，用户名相同；标识不同，用户名相同；标识不同，用户名不同；

l.登录用户能否修改本人（或其他人）的信息，删除本人（或其他人）；

m.修改用户的信息（包括权限，口令，基本信息等），对其他模块的影响；

n.修改用户信息：修改后的用户信息和已经存在的用户信息相同；修改后的用户信息和已经存在的用户信息不同；

o.不给用户授权，是否允许登录；

p.改某些设置时，是否会影响具有上级权限及相同权限人员的设置；

q.系统管理员修改了某些数据，以其他人员身份登录时数据是否改变；

r.用户能否同时属于多个组，各个组的权限能否交叉；

s.删除后重新添加的用户是否具有以前的权限；更改用户各项属性（包括权限）看对权限是否有影响。

8.系统登录测试

a.使用合法用户登录系统；

b.用户名、口令错误或漏填时能否登陆；

c.系统是否容许多次非法登陆,是否有次数限制；

d.使用已登录账号登录系统系统能否正确处理；

e.使用禁用帐号登陆系统能否正确处理；

f.删除或修改后的用户用原用户登录；

g.不输入用户名和口令，重复点“确定”和“取消”按钮，是否允许登录。

9.注销

a.注销为原模块、新模块系统能否正确处理；

b.中止注销能否返回原模块、原用户；

c.注销为原用户、新用户系统能否正确处理；

d.使用错误的帐号、口令或无权限帐号、被禁用帐号进行注销。

10.修改口令

a.正常情况；

b.输入错误的原口令或新口令与确认口令不一致系统能否正确处理；

c.修改口令后，用原口令是否能登录（同时验证新口令是否有效）；

d.是否能修改其它用户的口令。

11.右键功能

a.右键菜单中的功能是否与菜单（或工具栏）中

对应的功能一致；

b.右键菜单中的功能能否正确实现；

c.同一菜单下的热键是否相同。

12.记录列表

1.增加重复记录、空白记录，系统能否正确处理；

2.修改后不保存（有保存按钮），系统能否正确处理；

3.删除或修改正在使用信息，系统能否正确处理；

4.删除级联记录的上游或下游记录，系统能否正确处理；

5.删除记录时是否有提示；

6.记录中包含的缺省系统信息能否删除和修改；

7.记录列表能否及时反应记录的变化；

8.记录变化之后系统相关信息能否及时更新。

13.统计、查询

a.对非法的时间范围系统能否正确处理；

b.统计查询语句包含多个与或非条件时，系统能否正确处理；

c.条件逻辑混乱，系统能否正确处理；

d.多表查询统计及单表查询统计功能是否正确实现；

e.分类查询、精确查询、无条件查询、组合查询能否完整列出满足条件的记录；

f.能否按系统默认的条件进行查询；

g.当统计时间段为当日、跨日、跨月、跨季、跨年度时，统计查询结果是否正确；

h.当某些操作被别人取消后，设置条件段为取消前、取消后、包含取消操作的一段时间；

i.以不同的权限登录时，统计、查询是否正确；

j.在查询或统计大数据量时，系统是否允许终止操作；

k.查询、统计按钮是否允许双击或更多的点击，系统做何反映；

l.查询出的数据是否允许修改。

14.文件操作

a.保存

* 文件是否能够正确保存在在缺省位置或指定位置（本地、网络）；

* 系统能否正确处理长文件名、特殊字符文件名保存；

* 文件能否保存为其它扩展名；

* 如应用程序对文件名区分大小写，当这些文件在导出到介质中时，系统能否正确处理；

* 介质空间已满时，系统是否给出提示。

b.打开

* 打开文件是否正确显示上一次保存的内容；

* 系统能否正确处理非系统默认扩展名的文件；

* 文件能否被其他程序正确打开；

* 打开对话框中，是否有默认扩展名的文件类型；

* 打开对话框时，是否有默认的路径。

c.打印输出

* 是否有打印预览，能否设置打印字体，打印效果是否合乎客户要求；

* 打印预览的内容是否正确，内容是否能够进行拖拽操作，是否影响实际的打印；

* 安装或不安装打印功能模块，对其它模块是否有影响；

* 打印机未安装系统有无提示；

* 打印中途能否进行正常的打印中断，是否可以选择打印的内容。

* 能否进行本地或网络打印。

d.导入、导出功能

* 导入的文件格式非要求时，系统如何处理；

* 导入、导出的有效文件能否完整正确地显示并被使用；

* 导出后的文件是否允许修改，如果允许，导入后能否使用；

如不允许，系统有何限制；

* 导入，导出是否可以选择路径；

* 在客户端和服务器端进行导入，导出；

* 在客户端和客户端之间进行导入，导出；

* 在本地进行导入，导出；

* 不同文件格式的导入，导出。

e.检入与检出

* 单文件、多文件检入与检出；

* 能否多次检入与检出；导出后的文件是否允许修改，如果允许，导入后能否使用；如不允许，系统有何限制；

* 文件检出后其它人能对其做何操作。

15.界面上对象的功能（文本框，下拉框，按钮，热键等等）

a.工具条

* 工具条能否正常显示/隐藏；

* 工具条按钮在不可用时是否置灰，例如在不置灰情况下，重复点击工具条上的按钮，看系统是否能够正常进行操作；

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

* 工具条船坞状与非船坞状时其上按钮是否相同；

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

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

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

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

b.下拉列表

* 列表记录的每一行是否显示完整；

* 列表记录不能在一页中显示时，是否有纵向滚动栏；

* 列表滚动栏上滑块能否自由滑动，对应内容显示是否正确；

* 列表中内容能否自动排序

c.窗口

* 打开的窗口不确认关掉，能否再调其它窗口，且连续开窗口系统能否正确处理；

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

* MDI中，子窗口的平铺、重叠、排列图标功能是否正确；

* 窗口的标题、图标是否和菜单命令、按钮一致；

* 子窗口和主窗口的属性是否正确；

* 窗口中的上下左右滚动条是否能达到预览全部界面的效果。

d.文本框

* 对输入域的必添项处理是否正确；

* 输入域是否有长度限制；

* 输入域如对某些字符禁止输入时，限制是否成功；

* 中文、英文、空格，数字，字符，下划线、单引号 等所有特殊字符的组合；

* 口令域；

* 时间域；

* 货币域；

* 身份证（18或15位）；

* 电话号码；

* 关于时间的其它操作；

* 数据字段一致性。

口令域

* 口令为空格或包含空格、特殊字符（所有特殊字符的测试）时系统能否正常处理；

* 口令位数是否有限制；

* 口令与帐号相同，系统是否有提示；

* 口令为字典单词系统能否正确处理；

* 特殊的对系统安全性要求较高应该注意；

* 口令应有最少位数限制；

* 口令应为数值、大小写字母、特殊字符的组合；

* 口令禁止设为空，不能和要被修改的口令一致；

* 口令区分大小写。

时间域

* 年度超过4位；

* 月份输入0或大于12；

* 日期输入0或大于当前月份

的天数；

* 年度，月份，日期输入负数；

* 时间输入大于或小于边缘值的数据；

* 进行字符及汉字的输入，看程序能否正确处理；

* 系统中所涉及时间是否取服务器时间；

* 有范围的输入域，开始时间大于、小于、等于结束时间，系统能否正确处理；

* 时间范围同当前时间的关系是否正确；

* 是否包含缺省时间且缺省时间意义是否正确；

* 系统对闰年，闰月的处理；

* 对不同的时间格式（yyyy-dd-mm,yy-dd-mm,yyyy/dd/mm,yy/dd/mm等）是否允许输入；

* 输入的时间在与之有关的模块中是否能正确的起到作用及对其他模块的影响；

* 对时间点的测试。

货币域

* 输入负值、零、特大数、小数系统能否正确处理；

* 系统对小数点后数位的控制是否正确；

* 系统能否正确处理数值计算；

* 输入非数值型数据（包括特殊字符），系统能否正确处理；

* 系统能处理货币的种类。

身份证

* 身份证中输入非法的年月日信息（包括超界数字及字符，汉字），程序能否进行检验并正确处理；

* 由身份证号码计算年龄，系统对出生年份末两位数是00的身份证号码能否正常处理；

* 在年龄和身份证均作为用户信息输入时，是否具有关联；

* 在身份证的输入中，是否允许输入字符”x”。

电话号码

* 输入特殊的电话号码，如119，110，800等看程序是否能正确处理；

* 验证－，（，） * # 是否有真正含义；

* 电话号码长度是否有限制；

* 电话号码是否允许输入汉字，英文。

关于时间的其它操作

* 时间的跨月份、年度操作；

* 12小时、24小时制的操作；

* 客户机与服务器时间不同的操作（包括客户机与服务器两地时差不同）。

数据字段一致性

* 不同窗口中同一类数据输入域的数据接口是否一致(如添加用户及用户登录窗口对用户标识和口令的长度是否一致)。

e.图表曲线

首先，在一定的时间段观察曲线走势，如果有类似的软件可对比的话可以进行对比大体趋势，然后，再找关键点，对比关键点的数据。测试中，需要找到曲线的计算公式，找关键点进行计算。（进行对比是必要的，第一，可以节省一些不必要的工作量；第二，也有可能是编码人员所用的公式本身就有问题，而你所有测试所做的计算都是徒劳了。）

f.列表

* 列表记录不能在一页中显示时，是否有纵向滚动栏；记录长度超过列表宽度时，是否有横向滚动栏；

* 列表滚动栏上滑块能否自由滑动，滑块滑动时，对应内容显示是否正确；

* 列表内容是否可直接输入；

* 列表中每列数据能否按升序、降序排列。

16.备份与恢复

a.备份T日的数据，进行操作，然后恢复，查看恢

复的数据是否正确；

b.备份到不同介质上，并考虑介质空间已满的情况；

c.用系统提供的恢复功能进行恢复：

d.用数据库进行恢复；

* 在备份和恢复还没有结束的时候，终止（掉电，网络不通等）备份和恢复；

* 有操作的时候，进行备份和恢复；

* 没有任何操作的时候，进行备份，恢复；

* 部分备份，全部备份，部分恢复，全部恢复有选择的备份和恢复；

e.进行备份，恢复操作是否有权限限制 A 有: 分别用有权限的用户和没有权限的用户进行操作 B 没有：单个用户进行备份，恢复；多个用户同时进行备份和恢复。

17.系统日志的处理

a.系统能否正确记录日志信息；

b.系统是否有清空日志的功能；

c.系统是否有导出日志的功能；

d.当日志数据超过容量时，系统如何处理。

性能测试

具体用例不好设计，下面列出了一些有性能要求的测试点：

a.查询

b.保存

c.统计

d.刷新

e.显示

f.传输

g.响应

h.下载

打开网络上其它介质上的文件时，可制造网络拥挤情况下的文件打开操作。主要的测试点集中在几个点上：一是数据量小的时候主要的查询统计刷新等功能点；二是数据量积累到一定程度时的查询统计刷新时间，这里的一定程度是根据实际的项目和客户需求来定的。

极限压力测试

* 接收大数据量的数据文件时间；

* 大数据恢复时间；

* 大数据导入导出时间；

* 大批量录入数据时间；

* 大数据量的计算时间；

* 多客户机同时进行某一个提交操作；

* 采用测试工具软件；

* 编写测试脚本程序；

* 大数据量的查询统计时间。

容错测试

* 通过断开网线的强制性停止数据传输以及重新将网线接上，查看提示信息及对系统的影响；

* 系统断电，恢复后查看对系统的影响程度；

* 死机后，看程序如何处理；

* 服务器DOWN掉，客户端程序如何处理。

并发测试

* 登录的并发操作：多人同时登录系统，使用不同或相同账号；

* 提交的并发操作：多人同时提交相同的工作项、不同的工作项；

* 对数据库操作的并发操作：多人同时从数据库中读出（或向数据库导入） 相同文件、不同文件。

六、容易出错的测试点

* 新建和修改

* 删除

* 提示信息的验证

* 考虑硬盘空间已满的情况

* 修改系统时间

* 响应速度慢的按钮

* 支持并发过程的功能

* 打印功能

* 系统初始化

* 版权声明

* 捆绑硬件的软件测试

* 备份与恢复

新建和修改

1. 创建或修改的内容为已经存在的内容，系统是否有提示；

2. 修改正在使用的数据。

删除

1. 应有确认提示；

2. 若删除的内容在文件或数据库中，应作实际

校验；

3. 删除正在使用的数据；

4. 考虑删除数据的相关数据是否同时被删除；

5. 重新使用已删除的数据。

提示信息的验证

* 有些操作系统会给出成功（有时没有成功提示）或失败的提示，一定要验证提示的正确性（尤其是一些重要操作，如修改口令），即用其它方法检查所作的操作是否真正成功或失败。

考虑硬盘空间已满的情况

1. 数据存储和备份；

2. 生成文件；

3. 拷贝文件。

修改系统时间

对于和时间有关的业务，测试时考虑修改系统时间对系统的影响。

响应速度慢的按钮

对于响应速度慢的按钮进行连续点击；或中途取消，再继续…

支持并发过程的功能

凡是支持并发过程的功能，一定要做并发测试（手工进行或利用工具）。

打印功能

测试打印功能时，要考虑能否正确打印，打印效果与预览是否一致。

系统初始化

1. 如果系统安装后需要进行初始化，初始化过程是否正确；

2. 如果系统安装后不需要进行初始化，安装后的默认设置是否正确、适当。

版权声明

版权声明是否符合标准，如果有公司的logo，图标是否正确（最容易测试的地方，也是最容易被忽略的地方）。

捆绑硬件的软件测试

如果捆绑硬件，则在测试软件产品前要对硬件的性能、稳定性进行严格测试。（包括大数据量的传输入等）

备份与恢复

1. 备份与恢复过程本身的正确性；

2. 备份内容的正确性（通过事先准备的测试数据在恢复后验证）；

3. 备份与恢复过程中对异常情况的处理（掉电、网络不通等）；

4. 在原始机上的恢复；

5. 在非原始机上的恢复；

6. 在裸机（只有操作系统和必要的数据库或第三方产品）上的恢复；

7. 在一台机器上进行若干次的备份与恢复；

8. 如果是支持多数据库的软件，备份与恢复是容易出错的地方。

七、错误类别

在整个测试过程中对每条问题都制定有错误归类，现按照问题的严重程度，把问题主要分为四类：

A：严重影响系统运行：导致系统出现不可预料的严重错误的问题，例如：运行过程中出现页面或页面无法显示、死机等。

B：影响系统运行：系统中重要的功能出现运行错误，例如：导致用户必须重新登录的问题，导致个别用户不可用的问题；

C：不影响系统运行但必须修改：系统中基本的操作或功能没有实现或实现有误的问题，以及不符合常规的操作界面的问题。

D：所提建议：不影响系统运行，对系统的可用性等提示的建议性的问题。