手机登录测试用例

手机登录测试用例（9篇）

1.手机登录测试用例 篇一

如何做好测试计划和测试用例工作

如何做好测试计划和测试用例工作 用例设计 测试的流程中，测试计划是对整个测试活动的安排，而测试用例则是测试执行的指导，但是，现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性，在项目时间比较紧张的情况下，计划和用例往往成了形式上的东西，甚至有些测试人员脱离用例，完全凭借自己的经验在执行测试活动，对此，你有什么样的看法? 个人认为做好测试计划的编写工作应该从以下几个方面考虑问题： 1、要充分考虑测试计划的实用性，即，测试计划与实际之间的接近程度和可操作性。 编写测试计划的目的在于充分考虑执行测试时的各种资源，包括测试内容、测试标准、时间资源、人力资源等等，准确地说是要分析执行时所能够调用的一切资源以及受各种条件限制，可能受到的各种影响。说的再明确一点就是要“计划”“如何”去做“测试工作”，而不是“如何编写测试计划”。 2、要坚持“5W1H”的原则，明确测试内容与过程。 明确测试的范围和内容(WHAT); 明确测试的目的(WHY); 明确测试的开始和结束日期(WHEN); 明确给出测试文档和软件册存放位置(WHERE); 软件测试 明确测试人员的任务分配(WHO); 明确指出测试的方法和测试工具(HOW)。 3、采用评审和更新机制，确保测试计划满足实际需求。 因为软件项目是一个渐进的过程，中间不可避免地会发生需求变化，为满足需求变化，测试计划也需要及时地进行变更。 之所以采取相应的评审制度，就是要对测试计划的完整性、正确性、可行性进行评估，以保证测试的质量。 4、测试策略要作为测试的重点进行描述。 测试策略是测试计划中的重要组成部分，测试计划是从宏观上说明一个项目的测试需求、测试方法、测试人员安排等因素，而测试策略则是说明世纪的测试过程中，应该怎样具体实施。因此，测试策略一定要描述详尽并且重点突出。 打个不太恰当的比喻，你可以认为测试计划就是测试工作的预期输出，而测试执行是测试工作的实际输出，在预期输出!=实际输出的情况下，您会认为这样的测试合格么? 至于测试用例工作，我认为我们首先要明确测试用例在整个测试工作中的地位及其作用。个人认为，测试用例在整个测试工作中的地位和作用主要体现在以下几个方面： 1、测试用例是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式; 2、测试用例是团队内部交流以及交叉测试的依据; 3、在回归测试中，测试用例的存在可以大大的降低测试的工作量，从而提高测试的工作效率; 4、测试用例便于测试工作的跟踪管理，包括测试执行的进度跟踪，测试质量的跟踪，以及测试人员的工作量的跟踪和考核; 5、在测试工作开展前完成测试用例的编写，可以避免测试工作开展的盲目性; 6、测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。 当我们认识到测试用例在政工测试工作中的地位及其作用之后，相信大家都已经认识到了测试用例对测试工作的重要性和必要性，那么，我们就来讨论一下如何有效的保证测试用例的质量。 1、做好测试人员的.项目培训(主要指对需求分析、软件设计、测试计划的认知程度)工作。要想发挥团队中每一个成员的所有能力，最好的办法就是让他们每一个人都清楚这个项目中的所有细节，以及自己要在这个项目中所承担的责任。 2、尽可能的利用以往其他项目的测试用例;并将该项目中类似模块进行归类，按类编写测试用例，再根据每个模块的特点进行修改，要充分利用测试用例的可重用性。 3、在时间资源紧张的情况下，可以按照测试的关键路径编写测试用例，针对关键路径的测试用例一定要详尽，其他边缘模块的测试用例可以考虑仅通过性测试(既仅证真测试)。 4、采用针对测试用例的模块化编写。个人建议将测试用例和测试数据分开，测试用例中的操作步骤应主要体现于业务流程的检验，而测试数据主要体现于针对系统的数据处理结果的检验。考虑到软件项目的需求变更问题，建议将这两项分开，通过测试用例编号进行关联，以应对需求变化造成的测试用例的修改，从而减少测试用例的修改量，缩短项目周期，提高工作效率。 以上是针对“做好测试计划和测试用例的工作的关键是什么”的问题的个人见解，如有不同意见，请大家及时指出和补充。 焦点测试：www.testfocus.com.cn/

2.手机登录测试用例 篇二

关键词：系统用例,测试用例,复用,软件质量

1、引言

长期以来，软件质量问题一直困扰着大多数国内的软件企业。大多数企业，重开发、轻测试，认为软件测试是可有可无的事情。软件测试要么流于形式，由开发人员自己对自己的代码进行检查，要么根本没有，拿用户做实验，软件直接交给用户来测，待用户发现问题后再做补救。软件的质量根本无法保证。近年来，随着客户对软件质量的要求越来越高，软件行业也逐渐意识到，软件测试才是确保软件质量的最有效的手段。因此，近年来形成了比较完善的软件测试理论体系。但是，如何编写高效的测试用例。即，如何利用尽可能少的用例做到尽可能大的覆盖率，仍是每一个测试人员需要面对的问题。[1]

2、软件测试的一般方法

软件测试按照阶段划分一般分为：单元测试、集成测试、系统测试、验收测试。[1]单元测试针对每个模块进行的测试，通常在编码阶段进行，必要的时候要制作驱动模块和桩模块。单元测试的目的是看已完成的编码是否符合详细设计说明书上的要求。集成测试在单元测试的基础上，将所有模块按照设计要求组装成为系统，必须精心计划，应提交集成测试计划、集成测试规格说明和集成测试分析报告。集成测试着眼于各模块之间的接口是否正确。由于软件集成的过程是一个持续的过程，会形成多个临时版本。因此，在集成测试的过程中，需要不断地对系统进行冒烟测试，即对程序的主要功能进行测试。确认测试验证软件的功能和性能及其它特性是否与系统的概要设计说明书一致。系统测试和验收测试的目的在于检验系统的提供的功能是否与用户的要求一致，系统测试是在实际运行环境或相对真实的模拟环境下进行一系列的测试。

软件测试按照测试技术划分，一般分为：白盒测试和黑盒测试。白盒测试检查程序的代码设计。该方法将语句与判断作为研究对象，检查所有的结构和路径是否都是正确的。白盒测试以覆盖率作为衡量标准，覆盖率越高，其测试越充分。白盒测试一般分为语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖以及路径覆盖等[1]。然而100%的代码测试几乎是不可能的，白盒测试的成本非常高，除非在航空或军用领域，一般的应用系统只需针对最重要的核心代码进行白盒测试。

黑盒测试是从用户的角度对系统进行测试查找系统存在的缺陷。黑盒测试与需求紧密相关，系统业务需求分析的正确程度直接影响黑盒测试的质量。在进行嵌入式软件黑盒测试时，要把用户需求作为重要依据。黑盒测试针对的是系统的外在功能，因此对软件系统的分支覆盖率比白盒测试要低，在系统修改后，一般要进行回归测试。[5]

3、系统用例和测试用例的关系

作为分析建模活动的一部分，系统用例用来捕获信息的生产者、使用者和系统本身之间发生的交互。即，从某个特定参与者的角度用简单易懂的语言说明一个特定的使用场景。[2]下面通过一个实例来说明用例的组成与结构。

用例1：登录

[执行者]：员工

[基本路径]：

1）、员工插入安全锁触发系统登录过程。

2）、系统打开安全锁

3）、系统从安全锁中获取证书信息。

4）、系统验证证书的合法性。

5）、系统获取证书中的用户名。

6）、系统将用户的考勤信息存储至数据库。

7）、系统将用户的在线状态记录至数据库。

8）、系统从数据库中获得在线用户列表、通知列表、带接收文件列表、日程安排、收文回执列表等。

[扩展路径]：

2a、无法打开安全锁

2a1、提示用户安全锁错误。

2a2、用例结束

2b、PIN码不正确

2b1、输入未超过3次，要求用户重新输入PIN码

2b2、返回步骤2

2b1a、用户输入PIN码达到3次

2b1a1、用例结束

3a、无法获得安全锁中的证书

3a1、提示用户锁内证书无法获得

3a2、用例结束

4a、证书验证不合法

4a1、提示用户锁内证书不合法

4a2、用例结束

6a、无法存储至数据库

6a1、将登录信息存储至本地

6a2、重复尝试存储登录信息。

7a、无法存储至数据库

8 a 1、重复尝试存储在线信息。

这是一个利用硬件设备通过数字证书进行系统登录的用例。基本路径描述了自顶向下的易于理解的典型场景。在其中用户目标得以实现，风险承担者的利益也得到了保障。[4]扩展路径则表述了系统出现问题情况下的场景。扩展路径可以在执行后重新加入到基本路径中，也可以不再重新加入基本路径而终止用例。

我们在得到了系统用例之后，则可以通过该用例来设计测试用例。在设计过程中，不仅要考虑基本路径所产生的成功场景，也必须要考虑当扩展路径执行时的失败场景。

通过表1六个用例执行了系统用例中步骤1-4中的场景。用例1为正面测试用例，它沿着系统用例的基本路径执行，未发生任何偏差。用例2-6为负面测试用例，它们在系统出现偏差时沿着扩展路径执行。负面测试是相对于基本路径而言的，对于扩展路径来说用例2-6是正面测试。

通过系统用例生成测试用例非常方便，二者之间的转换是非常自然的过程。与其他方法不同，这个方法对系统用例的依赖程度高。因此，测试用例的成功与否，取决与系统需求分析的正确程度。只有真正捕获了用户的需求，并且编写出正确的系统用例，才能得到高效的测试用例。

4、用例复用

测试用例复用是指重复使用“为了复用目的而设计的测试用例”的过程。[3]相应地，可复用测试用例是指为了复用目的而设计的测试用例。与软件复用的概念相对应，软件的复用是为了支持软件在应用维的演化，使用“为复用而开发的软件 (构件) ”来更快、更好地开发新的应用系统。好的测试用例用来确保软件的质量，而有效复用现有的测试用例更能提升软件测试的效率。[2]测试用例的复用技术目前已成为一个新的研究热点，由于本人的水平有限，在这里只能根据自己的经验提出一点自己的体会。

传统上，我们都是针对特定的系统设计软件系统设计测试用例，过于局限于某一种产品，依赖性非常强，不利于测试用例的复用。

需求分析的结果取决于用户需求，系统分析结果是针对问题域的某些问题的抽象程度较高的结果，很少受到设计技术及实现条件的影响，因此复用的机会更多。一般可以从现有系统的分析结果中提取可复用构件。[2]因而通过系统用例生成测试用例的方法则可以凭借软件工程中的软件构件技术实现需求、系统和软件的需求规约的复用；继而确保由这些复用构件生成的测试用例达到复用的目的。

5、结束语

通过系统用例我们可以很方便的得到测试用例，进行系统测试。测试用例能够达到的效果取决于系统需求分析的准确程度。因此，要求我们在系统开发的过程中要高度重视系统的需求分析，准确把握用户的需求。测试用例可以与系统用例同步开发，将测试介入到软件开发过程的时间大大提前，从而确保软件开发的每一阶段，都能通过测试保证开发的质量。

需要注意的是, 本介绍的方法属于黑盒测试的范畴。覆盖率能够达到30-40%。因此, 对于系统的核心模块, 如有必要还必须借助白盒测试的方法进行全面的测试。

参考文献

[1]柳纯录.软件评测师教程.清华大学出版社.2005

[2]邵维忠.面向对象的系统分析.清华大学出版社.2005

[3]Roger Pressman.软件工程-实践者的研究方法.机械工业出版社.2007

[4]Alistair Cockburn.Writings Effective Use Case.机械工业出版社.2002

3.可复用测试用例研究 篇三

0、引言

软件测试的关键环节是设计和执行测试用例。测试用例的质量与测试人员的技能、经验以及对被测软件的理解密切相关。如果测试人员对被测软件不甚了解，很难在短时间内设计出有效的测试用例；有的测试用例虽然面面俱到，但冗余现象严重，浪费时间、人力和物力。

随着软件复用技术的发展，测试复用引起了人们的极大关注，特别是对测试用例复用的研究。所谓测试用例复用，就是对一个软件的已执行的测试用例，将其不同程度地应用于该软件新的测试中或其他软件的测试中。测试用例复用是可行和必要的，表现在：1）软件测试对测试人员的经验和技能要求高，通过复用，可提高测试人员技能，解决其经验不足的问题，同时提高软件测试质量；2）软件测试是当前保证软件质量的一种有效手段，但其占用软件开发周期时间长，通过复用，可避免大量重复性劳动，缩短测试周期，提高效率；3）伴随着同一个软件的生存周期，软件经历了单元测试、集成测试、确认测试和系统测试，这一过程产生了成百上千的经过执行确认的高质量的测试用例，在前一测试阶段执行过的一些测试用例可在后续测试阶段中使用，包括在回归测试、维护阶段的版本升级和纠错测试中都可使用；4）同一领域或相同系统架构的不同软件，存在着测试用例复用的可能性，且随着软件复用技术的发展，很多有价值的组件可供使用，这也使测试用例复用成为可能。

由于软件的抽象性、复杂性和多样性，使得软件测试成为一项复杂的、需要智慧和创造性的工作，要实现测试用例复用并不是一件简单的事情。但测试用例复用是软件测试发展的一个必然趋势。本文从可复用测试用例的评估、描述、设计和使用四个方面对测试用例进行了系统研究，提出了可复用测试用例应具有的特性，为评估测试用例的可复用性提供准则；给出了可复用测试用例的系统描述要素，为规范和使用可复用测试用例提供了基础；提出了面向复用的测试用例设计过程和基于复用的软件测试模型，为测试用例复用提供了方法和实现策略。本文的研究内容在某类实时系统软件测试中进行了应用，证明是有效和科学的。

1、可复用测试用例特性

文献中定义了可复用测试用例的六个特性：通用性、简洁性、独立性、有效性、灵活性和检索方便。本文对大量测试用例和测试用例复用的各种应用情况进行了分析，认为可复用测试用例应具有以下特性：通用性、有效性、独立性、标准化和完整性，它们对可复用测试用例而言是充分的也是必要的。上述特性可作为评判一个测试用例是否具有可复用性的准则。

1）通用性。通用性是指可复用测试用例并不局限于具体的应用，不过分依赖于被测软件的需求、设计和环境，能够在某一类型、某一领域的相似软件的测试中广泛使用。

当前绝大多数的测试用例都不具有通用性，这样的测试用例只能用于被测软件和其当前环境，不可能用到其他软件中。

2）有效性。测试用例的目标是发现软件问题，因此，可复用测试用例也必须是能够发现软件问题的，并且是可靠和高效的。

3）独立性。可复用测试用例的独立性是指，对于测试需求R1和R2，测试用例集分别为cl和C2，c1和c2的交集为空，并且，每个可复用测试用例能够独立运行。测试用例是否具有独立性，决定了测试用例可复用能力的强弱。

如果测试用例之间存在着相互联系，或测试用例的运行环境取决于其他测试用例的执行状态，那么，其中的测试用例不能复用时，与之相关的测试用例的可复用性也不复存在。

如何将测试用例的关联性降至最低，是设计可复用测试用例必须解决的问题。首先，每个测试用例的目标应尽量独立、单一；其次，测试用例不包含过多的具体实现细节。

4）标准化。测试用例通常用自然语言来描述，充分体现了测试人员的创造性和个人风格。但对于可复用测试用例，太多的个人风格不利于其他测试人员对测试用例的理解，必然影响其复用。因此可复用测试用例的标准化程度也反映了其易理解和可复用的能力。为此可复用测试用例应遵循统一或规范的格式或结构，规范的命名规则，使用术语、用简明、易懂、无歧义的语言来描述，并且具有详细的文档。

5）完整性。每个可复用测试用例应包括全部应有的要素，不能有缺失，并且每个要素的描述是充分的。文献规定了测试用例应包括的要素，但对于可复用测试用例而言是不够的，应加以补充。

2、面向复用的测试用例设计过程

当前，测试用例设计都砥向不同的具体应用，与被测软件是紧耦合的。考虑到复用的目的，测试用例的设计应不同于以往。本文提出了面向复用的测试用例设计过程，给出了设计过程中应实施的各项活动，主要包括被测软件（系统）共性分析、测试策略分析、设计测试用例、测试用例评审、测试用例执行和修改、测试用例入库共六个步骤，如图l所示。该过程对现有测试用例的复用处理也是适用的。

2．1共性分析

同一领域或相同架构的软件存在着共性需求。通过共性分析或领域分析，并结合任务分析等方法，梳理出被测软件所属领域或相同类型软件的相同或相似特征及需求，例如，工作流程、共性场景、功能、性能等，从而挖掘出可复用点，例如，相对独立且类似的功能、相同的构件、相似的业务流程。该步骤实质上要抽象出被测软件应用领域的概念，类似于设计模式中的共性分析。

这项活动需要领域专家、软件专家、设计人员、测试专家等人员参与。

2．2 测试策略分析

针对共性分析挖掘出的可复用点，分析各复用点的测试策略，包括测试类型、测试方法、测试环境、测试覆盖率等内容。

2．3 设计测试用例

根据前两个步骤的分析结果对每个可复用点设计测试用例。在设计时，应使所设计的测试用例满足可复用测试用例的特性，特别要注意以下几方面：

1）每个测试用例的目的要尽量独立、单一，以满足可复用测试用例独立性的要求。

2）对一项明确的测试需求，应关注“测试思想”，即测试思路，以满足可复用测试用例通用性要求。当前，为了使测试用例是可操作的、可复现的，一般都要求测试用例要设计得非常详细，例如，每一操作步骤的输入数据、操作等信息都要具体描述。这样的测试用例和被测软件是紧耦合的，只有在同一软件的回归测试和版本升级维护测试中可能会复用到，在其他情况下复用是很困难的。在设计可复用测试用例时，测试用例的可操作性、可复现性要弱化，即，对测试用例进行通用化处理，排除和特定应用相关的具体信息，以降低测试用例和被测软件的相关度，例如，参数化或公式来代替具体的输入数据，抽象出共同或关键的操作等。但为了加强测试用例的可操作性和可复现性，在设计可复用测试用例时，应对一些差异之处进行预测，即进行可变性分析mJ，并用适当的方式描述出来。只有这样，当复用该测试用例时，测试人员可以在原有基础上对其进行完善，使其能够满足特定的测试情况。

3）将设计出的测试用例用规范而精炼的自然语言清晰地描述出来，保证其完整、标准。软件评测组织或机构应定义本组织使用的规范和术语。

需要说明的是，对于一个具体的测试项目，因为面向复用，所以以上所设计的测试用例可能不完全满足被测软件的测试需求，为此，应针对被测软件的需求补充新的用例或对现有用例进行充实完善。

2．4 测试用例评审

可复用测试用例设计完成后，组织领域专家、软件专家、测试专家、软件设计人员对其进行评审，确保所设计的测试用例是正确的，满足可复用测试用例的特性。

评审同时应关注以下几点：每个共性需求的测试策略是否合适；每个共性需求是否被可复用测试用例所覆盖；每个共性需求是否被可复用测试用例进行了充分测试，例如，某一共性功能，不能仅测试正常情况，还应测试边界和异常情况。如果测试用例没有通过评审，则需要重新回到设计测试用例步骤。

2．5 测试用例执行和修改

将通过评审确认的测试用例用于被测软件，寻找其不正确或不完善之处并纠正完善。

2．6 测试用例入库

将经过测试执行确认的可复用测试用例统一纳入测试用例库中，供测试人员在后续软件测试或以后的项目中查询使用。测试用例库应是按照一定的组织结构形成的测试用例集合。

3、基于复用的软件测试模型

文献给出了一个测试用例复用流程：首先定义被测软件的测试用例类型；再根据所定义的从测试用例库中检索是否有适合的用例；如果可以找到，则提取出测试用例，程序结束；否则，需要设计测试用例，验证其正确性，如果正确，则添加到库中以便再次复用，程序结束。这个流程只适用于完全不需要进一步完善的可复用的测试用例，由于可复用测试用例的通用性，该流程显然不适用于实际情况。文献[12]给出了另一个测试用例复用模型，该模型建立在没有测试用例库的基础上，且将测试用例分为内外两类，本文认为这种划分是不必要的。

本文提出了基于复用的软件测试模型。该模型面向一个软件测试项目，但不同于以往的测试模型，主要表现在模型中融合了面向复用的测试用例设计以及对测试用例的复用上，模型如图2所示。

“测试需求分析和共性分析”中，测试人员一方面要根据被测试软件需求分析、设计说明等文档或软件代码梳理出被测软件的测试需求，另一方面要针对被测软件所属领域及软件类型进行面向复用的共性分析。

“定义测试策略”中，测试人员根据测试目标和上一步的结果定义测试策略，包括测试方法、测试类型、测试环境等内容。

“定义测试用例”中，测试人员根据测试需求和共性分析结果及所定义的测试策略，定义所需要的测试用例。这里定义的测试用例只是给出一个测试用例名称及其测试目的。

“查询可复用测试用例库”中，测试人员用多字段检索功能从可复用测试用例库中查找满足要求的测试用例。对测试用例的查询是不确定的，查询结果通常是一个相似的测试用例集合。如果可以找到，则“提取测试用例”并对其进行分析，确定出最合适的测试用例；如果没有，则“设计”新的测试用例。找到的测试用例，往往因其通用性，并不能完全满足测试需求，要对其“补充完善”。在设计新的测试用例时，要考虑到上节“设计测试用例”要求。

在传统模型评审的基础上，本模型“测试评审”还包括对新设计的可复用测试用例是否满足要求的审查；对复用的测试用例是否补充完善的审查；所有测试用例是否满足被测软件的测试需求的审查。

“执行测试用例”中，测试人员将所设计的测试用例逐用例逐步骤地执行。在执行过程中，认真观察并详实地记录测试过程、测试结果和发现的错误，形成测试记录。如果在执行过程中发现测试用例有不正确和不完善之处，则纠正；如果测试用例不充分，则补充。

测试人员在“测试总结”中对所有测试结果进行分析总结，将通过测试执行验证的可复用测试用例放入可复用测试用例库中，以便后续复用。

该模型的优点为：1）对已有的可复用的测试用例进行了复用，避免了大量的重复性工作，提高了测试质量和效率；2）考虑了面向复用的测试用例设计，避免再次产生大量的不可复用的测试用例。

4、可复用测试用例描述要素

测试用例的输入、操作、预期结果和评估标准、前提条件是测试用例不可少的要素，但对于可复用测试用例而言，这是不够的。本文在文献规定的测试用例要素基础上，增加了新的内容。从而从多个角度完整地对可复用测试用例进行了描述，为可复用测试用例的标准化提供了模板，为建立可复用测试用例库并对测试用例实施有效管理提供了基础，也为测试用例检索提供了多个检索字段。

1）测试用例名称：名称能清晰且简洁地表达测试用例的功能。

2）ID：该ID在数据库中是唯一的。

3）版本号：用于测试用例的版本管理，每个测试用例应按照定义的规则设定一个版本号。

4）测试需求：对要验证的测试需求的描述和测试要求，例如，功能、性能等。

5）测试阶段：被测软件所处的测试阶段，包括单元测试、部件测试、配置项测试、系统测试，或者单元测试、集成测试、确认测试、系统测试。

6）测试方法：黑盒测试中的等价类划分、因果图，白盒测试中的语句覆盖、分支覆盖等。

7）测试类型：有功能测试、性能测试、安全测试、用户界面测试、接口测试、安装测试等，可选择多项。

8）应用领域：说明被测软件所属领域。

9）系统类型：描述被测软件所在系统的架构，如B／S、C／S、嵌入式软件、非嵌入式软件等。

lO）软件编码：描述被测软件的编码语言。

11）测试环境：描述该测试用例执行的软硬件环境。

12）前提条件：测试用例执行前必须满足的条件，或称之为约束条件。

13）测试输入：对输入值的抽象描述或参数化描述，不能是具体的数据值。

14）操作步骤：说明执行该测试用例的一系列相关联的操作。

15）预期结果：说明测试用例执行后的期望结果。每一操作步骤也可有自己的预期结果。

16）评估标准：描述评判测试用例执行中产生的中间和最后结果是否正确的准则。

17）附件：对测试用例附加的一些描述信息，可任意表示，例如文本、图像、模型、与测试用例有关的一些文档，方便测试人员进一步理解测试用例。

上述要素对可复用测试用例而言是必要的，不可缺少。而且要注意的是，测试人员在描述测试用例各要素时，应尽可能地使用规范语言和术语，以使测试用例规范化和易于理解。

5、应用

4.手机登录测试用例 篇四

无论做什么工作，都是计划先行，然后按照所制定的计划去执行、跟踪和控制。软件测试也一样，先要制定测试计划，是做好整个测试工作的前提。所以在进行实际测试之前，应制定良好的、切实可行的、有效的测试计划。软件测试计划的目标是提供一个测试框架，不断收集产品特性信息，对测试的不确定性（测试范围、测试风险等）进行分析，将不确定性的内容慢慢转化为确定性的内容，该过程最终使得我们对测试的范围、用例数量、工作量、资源和时间等进行合理的估算，从而对测试策略、方法、人力、日程等做出决定或安排。

1．测试计划的要点

测试规划与软件开发活动同步进行，在需求分析时，就开始测试策划，确定测试需求、目标、资源等。测试计划可以按不同的测试阶段（集成测试、系统测试等）来组织，也可以为每个测试任务或目标(安全性、性能、可靠性等测试)进行考虑。

测试计划主要集中在测试目标、质量标准、测试策略、测试范围、测试用例设计方法、所需资源和日程安排等，其关键是制定有效的测试策略，界定清楚地测试范围，识别出测试中所存在的各种风险并找出风险回避、监控和管理的方法，针对不同的测试目标或阶段确定测试方法，对测试工作量及所需的资源、时间进行合理的估算。所有这些，都是为了两个根本目的：测试的质量和效率。

2．制定测试策略

制定测试策略主要分析测试的目标和质量指标、确定测试的对象和依据，测试的重点和所采用的方法，包括在规定的时间内哪些测试内容要完成，软件产品的特性或质量在哪些方面得到确认。测试策略可以分为：

基于测试技术的测试策略，根据软件系统的技术构成和层次结构，着重考虑如何分层测试、选择哪些测试工具、如何将白盒测试和黑盒测试有机地结合起来等。

基于测试方案的综合测试策略，根据测试的目标和范围，着重考虑如何更好地满足测试需求、如何让功能测试、适用性测试和兼容性测试等进行有机结合、如何充分利用测试资源、如何更有效地完成回归测试等。

为了更好地制定好测试策略，要做到：

全面细致地了解产品的项目信息：应用领域、测试范围、市场需求、产品特点、主要功能和技术架构；

基于模块、功能、系统、版本、性能、配置和安装等各个因素对产品质量的影响，客观地、全面地展开测试计划；

根据软件单元在系统结构的重要性差异和一旦发生故障将给客户造成的损失大小，来确定软件测试的等级、重点和先后次序；

需要在测试用例数和测试覆盖率上进行权衡而获得一个平衡点，以便能使用尽可能少的有效测试用例去发现尽可能多的程序错误。测试不足意味着让用户承担隐藏错误带来的危险；同时反过来看，过度测试则又会浪费许多宝贵的资源或耽误软件产品的发布时间。

3．确定测试范围

测试主要依据 “产品设计规格说明书”、代码所发生的变化及其影响的区域，来确定哪些功能和特性要测试，哪些功能和特性不需要测试。在确定测试范围时，主要考虑的因素有：

优先级最高的需求功能

新增加的功能和编码改动较大的已有功能

容易出现问题的部分功能

过去测试不够充分的地方

经常被用户使用的功能和配置（占20%）

4．所需资源和日程安排

为了合理、准确地安排日程，对测试工作量要进行正确的估计。除了对工作量的估计之外，还要正确评估参与该项目人员的培训时间、适应过程和工作能力等。由于涉及到不同的项目、不同的测试人员、不同的前期介入方式，要对每人每天能够完成的平均测试用例数目做出一个准确的估计确实很困难，但是可以根据以前一些项目测试的经验或历史积累下来的数据进行判断推理，并适当增加10%-20%的余量，估算结果就比较准确了。

在估算的基础上，进行有效的、合理的资源安排。在不同的测试阶段人力资源的需求是不一样的，所以人力资源的计划要有一定的灵活性和动态性，形成有机的动态平衡，保证测试的进度和资源的使用的效率。

5．编制测试计划的技巧

要做好测试计划，测试设计人员要仔细阅读有关资料，包括用户需求规格说明书、设计文档等，全面熟悉系统，并建议注意以下方面：

让所有合适的相关人员参与测试项目的计划制定，特别是在测试计划早期；

测试所需的时间、人力及其它资源的预估，尽量做到客观、准确、留有余地；

测试项目的输入、输出和质量标准，应与各方达成一致；

建立变化处理的流程规则，识别出在整个测试阶段中哪些是内在的、不可避免的变化因素，加以控制。

6．测试项目计划的评审

测试项目的计划不可能一气呵成，而是要经过计划初期、起草、讨论、审查等不同阶段，才能将测试计划制定好。测试计划的评审是完成测试计划关键的一个环节，包括测试组织内部的自我评审、讨论和修改，然后交到评审会进行正式的评审，直至测试计划得到审批。

测试计划的正式评审，项目中的每个人（产品经理、项目经理、开发工程师等）都应当参与。计划的审查是必不可少的，每一个参与者都可能根据其经验及专长提出问题或建议，弥补在测试范围、工作量、风险等各方面的不足，进一步完善测试计划。

二、测试用例在测试活动中的作用：

1.强化测试用例在测试活动中的作用

测试用例在实际中没有起多大作用 , 在实际测试时根本没有按测试用例执行，测试执行后没有把新的测试用例补充到用例库中等等。

为何如此？ 根本原因是对测试用例重要性的认识不够，测试流程不完善，针对测试用例的管理流程更不完善，其实，从三个方面具体来说：

1）测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据，如果这个依据不能足够发挥它应起的作用，那是不是说这个依据不明确、依据设计的不合理呢？答案是肯定的！

2）制定了完备有效的测试用例，为什么不按测试用例执行测试呢？首先是因为企业没有严格和良好的机制促使和保证测试执行者这样做；其次是个别测试人员投机取巧心理作祟的表现。

3）测试用例设计得不可能天衣无缝，不可能完全满足软件需求的覆盖要求，测试执行过程里肯定会发现有些 测试路径或数据在用例里没有体现，那么事后该将其补充到用例库里，以方便他人和后续版本的测试；如果没有这样做，那么测试部门负责人和每个测试员都难辞其疚，是该重新坐下来思考一下公司的测试用例管理规范和测试流程了。

2.改进测试用例执行过程

那么究竟如何做，才能尽量避免上述问题呢？

我们不妨从软件开发周期的每个阶段就把这些问题考虑进去，以便从初始就力争将问题缩到最小，将问题扼杀在萌芽阶段。

1）软件需求分析阶段，测试人员从软件生命周期的需求阶段就开始介入。通常测试人员的测试工作开展在开发周期的末尾，如果前期不涉入，如何通晓整个系统的需求和架构而对其充分测试呢？

项目的测试负责人和测试工程师在 需求阶段 的任务有：

a.参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；更重要的是，对不可测或难以测试性问题要及时与客户或项目经理协调解决。

b.全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。

2）软件分析设计阶段：

l 测试人员除制定测试计划书等基本工作外，还有一个相当必要的任务，那就是将系统的可测性落实到书面文档，以备将来编写测试用例。（之所以要这么做，是因为考虑到很多企业编写测试用例直接参考需求规格说明书或者分析流程图，这样跨度大，难度也大，是造成测试用例不完备、覆盖范围小的重要原因）。

l 测试人员更要编写一份《软件功能点测试描述书》，它是软件的详细测试分析文档，其主旨是将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等，这些信息都是描述性的，无须具体数据；它的作用是据此编写测试用例，以及测试执行时的参考依据，基于它直接来源于需求，覆盖当然最全，也最能贴近客户要求。

l 当然该文档不是非要不可，如果有类似的替代文档或有工具可自动实现此功能，则会倍加受推崇！

3）软件开发阶段： 编写测试用例。应该遵守的原则是：

n 首先，从覆盖率来说，测试用例库的用例要达到最大覆盖软件系统的功能点。编写测试用例时，基本上就是将《软件功能点测试描述书》中的每个功能点进行操作上的细化：一是从步骤上描述到达校验点的方式，二是从内容上描述以何种数据校验功能点；如此可实现趋向最大需求覆盖率。

n 其次，从数量来讲，一个多于半年开发周期（指从编码开始直到提交客户的时间段）的软件系统，它的用例数量不要低于 4000 个，甚至更多！（IBM 等大公司测试过程的人士会认为 4000 还是很少的数目。我们试想，对于一个中小型软件系统，如果设计出 5000 个用例，那它的测试覆盖率还怕不高么）！

n 再次，如此众多测试用例的管理问题。是的，最好是需要测试用例管理工具软件。以 word 或 excel 来编写测试用例也可以。）测试用例 格式上一般内容以外的几个要点：

l 制定适合本公司的测试用例模版；

l 是用例模版里要有关键字索引，以方便按关键字分类查找，如测试方法（分手工 / 自动两种）；

l 是测试用例要有 状态跟踪，可根据用例执行状态索引用例（测试通过、测试失败、测试中断等）；

l 是执行失败的用例要 链接到相应的缺陷报告，如有根据缺陷报告检索测试用例的试图更妙，可评估该缺陷影响范围的大小；

l [FS:PAGE] 是测试用例的修改，以及每个测试周期的运行都有 日志记录，以便后期追踪

和新员工参考；）软件测试阶段，测试负责人划分不同的测试阶段（如集成测试、系统测试、回归测试、性能测试等），再划分不同的子测试周期（如前两个星期做 冒烟测试，测试方式是手工 / 自动，测试版本是 **，测试环境是 **，包括服务器端与客户端等；接着做第一模块功能测试；如此顺次。），再为项目组测试人员分配测试用例（通常原则是每个人负责几块区域的测试任务），测试人员则按照详细的用例文档去执行测试，测试失败则提交软件缺陷报告。这里要遵循的几个原则是：

A）有健全且严格的体制保证测试执行者严格按照测试用例执行测试。这并不妨碍测试者创造力的发挥，因为前期用例的设计和编写就是项目全体测试人员智慧的结晶！我们一直苦苦追寻众多测试工程师加班加点辛苦工作的原因，其实大都发生这一阶段；如此实施，即便没有解决根本问题，也会大大提高测试执行效率。

B）如有对测试用例认识模糊或内容遗漏的地方，可暂做记录待后期解决，或经测试负责人与项目其他管理人员同意方可更新用例库。

C）测试负责人每日负责跟踪本测试子周期或阶段的测试用例执行情况，以及每日提交的缺陷报告，根据执行进展状态以及缺陷数量或严重等级与项目高层或其他人员展开交流，商议解决途径，并确定或调整未来时间的测试任务。

D）测试执行者负责执行自己区域的测试用例，还要负责跟踪该区域软件缺陷的修改进展，根据其状态 不断验证软件功 能点。

E）通过缺陷管理工具来 管理软件缺陷 ；这样的集成工具都提供了清晰的报告模版及强大的追踪功能，测试团队的每一成员按照自己的角色和权限访问缺陷管理工具，并不断跟踪软件缺陷的状态。

F）对于自动测试（包括自动化功能测试和性能、压力测试），有一些特殊要点。是自动化测试无须编写测试用例，只要在编写时将用例库里适合或需要自动测试的用例的测试方法（不同工具可能名称不同）设为自动即可，故而到此阶段才提及自动化测试。自动化测试的实施方案有所不同，每款测试工具的使用和测试流程也不同，但都可以从在这一阶段编写测试脚本，并运行自动测试。这里要提的其他几个基本原则是：

l 是选择恰当的测试工具品牌，并要求提供培训；

l 是项目的自动化测试工作有专人负责跟踪，以保证工作质量，他们可不参与日常测试；l 是确定自动化测试成员在项目中的角色，一般自动化测试成员隶属于项目测试负责人，负责人同样跟踪其工作状态；

l 是选择最简单、最重用的测试用例使用自动测试方法；

l 是使用工具厂商提供的测试框架编写脚本，千万别采用单纯录制回放的方式，要开发出健壮且重用性强的测试脚本 ；

l 是有专人更新脚本，也有专人跟踪自动测试结果；

l 一般选择的测试工具品牌和缺陷管理工具品牌是同一厂商，以方便不同类型缺陷的集中管理；

l 是在多人协作开发测试脚本、代码量相对较大情况下，应考虑使用配置管理工具来管理测试脚本。）由于不同公司开发产品的特殊性，也许需要特殊类型的测试，如安全测试、甚至代码级单元测试等，这些内容需要酌情考虑测试用例的编写，以及测试的执行。）软件验收阶段 ：除了提交软件测试评估报告（各种类型测试结果的评估都应有报告）这些基本工作外，对于测试用例，此时要集中时间更新，更新整个测试周期中一切需要更新的内容，以方便未来新版本的测试。即便您开发的是项目软件--提交客户后没有新版本--那也需要后期维护，维护阶段需要重新测试某功能点，然而用例如果不准确，碰巧又是一个

新员工来做，那就死翘翘了！）其他说明：加强测试部门内部人员的培训教育很重要，包括工作技能与个人素质两方面，可通过国内主要的培训机构，也可是购买工具厂商的直接培训。应该说，很多测试新人对于测试用例的书写还存在问题，更别提及测试用例的管理或执行；以此可见，我们的测试工程师需要培训的空间还很大。

3.总结

5.手机登录测试用例 篇五

关键词软件测试，测试用例，复用，分词

0 引言

软件测试是在规定的条件下对程序进行操作，以发现程序错误，由此来衡量软件质量，并对其是否能满足设计要求进行评估的过程。作为软件生命周期中的重要环节，其成败直接决定着软件的最终质量。软件测试工作不仅保证了软件质量，而且降低了日后维护成本。随着我国软件产业的蓬勃发展以及对软件质量的重视，软件测试也逐渐受到软件企业的关注，正逐步成为一个新兴的产业。测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于测试某个程序路径或核实是否满足某个特定需求。

6.优化测试用例的黑盒测试方法研究 篇六

关键词：黑盒测试,测试用例,分类树方法

0 引言

黑盒测试方法是一种从软件系统的功能说明书出发去寻找软件错误的测试方法, 测试软件系统功能。与白盒测试方法不同, 黑盒测试方法不关注软件的逻辑结构, 将待测试的软件看作一个黑盒子, 只关注软件功能的实现。常见的黑盒测试方法有:随机测试、等价类划分、边界值分析和因果图等。

1 常用黑盒测试方法

1.1 随机测试

该测试方法仅仅依靠测试者的直觉和个人经验去设计测试用例, 对软件进行随机测试, 因此较难发现错误, 效率较低, 大型软件一般很少使用。

1.2 等价类划分

该方法是从软件输入数据的限定条件出发, 或者从软件的输出数据倒推输入数据的特性, 从而划分为不同的类别, 每一个类别称为等价类, 每个等价类中可选取一组数据作为该等价类的代表, 对系统进行测试。如系统要求输入的数据为0~5之间的整数, 就可划分出3个等价类:小于0的整数;0~5的整数;大于5的整数。

1.3 边界值分析

此方法通常结合等价类划分方法一起使用。系统在边界处产生错误的概率较大, 因此有必要对边界处加强测试。选取的测试数据可以略大于、略小于或等于边界值。对上述等价类的例子而言, 可设定-1、0、1、4、5、6进行测试。

1.4 因果图

与等价类划分和边界值分析方法相比, 因果图方法既考虑了输入条件的组合关系, 又考虑了输出条件对输入条件的依赖关系, 效率较高。它将自然语言描述的规格说明转换为类似数字逻辑电路的因果图。步骤如下: (1) 将功能说明书分解成片段。将输入条件分成若干组, 分别对每个组使用因果图, 减少输入条件组合的数目; (2) 识别原因和结果, 并加以编号。原因是指输入条件或输入条件的等价类, 结果是指输出条件或系统变换。每个原因和结果都对应于因果图中的一个结点, 当原因或结果成立 (或出现) 时, 相应结点的值为1, 否则为0; (3) 根据功能说明中规定的原因与结果之间的关系画出因果图; (4) 根据功能说明在因果图中加上约束条件; (5) 根据因果图画出判定表; (6) 为判定表的每一列设计一个测试用例。

2 优化测试用例数量的黑盒测试方法

前述黑盒测试方法测试用例数量有时过多, 有必要采用化方法选取有代表性的测试用例来提高发现错误的概率。

2.1 分类树方法

该方法与等价类划分类似, 不同之处在于分类树方法是用树状图来表示各类别。操作步骤如下:

(1) 从软件系统的功能说明书中识别出不同的类别。以求两数中较大数的程序为例:假设程序要求的输入文件是File, File接收两个数据a和b。计算a-b的结果, 由得到的结果判断两数的大小。因此, 输入文件File有3个类别:不存在、存在但为空文件、存在但非空。a-b的值也可分为3类:大于0、小于0、等于0。

(2) 根据得到的类别构造分类树。

(3) 根据分类树的结点设计测试用例表。

(4) 从用例表中挑选可行的测试用例。

本文以企业员工考勤系统为例探讨分类树设计测试用例的方法。此考勤系统的功能说明书如下:

(1) 统计企业每月考勤结果。员工平时上下班刷卡的时间记录在考勤系统中。根据考勤记录统计员工的出勤情况。每个员工都有一个ID, 可唯一识别员工的个人信息, 如员工的姓名、岗位、工资等信息。

(2) 在考勤系统界面上输入员工ID, 系统information文件中存放员工个人信息, 根据该文件可识别员工的权限, 如果ID号码不合法, 或是离职员工, 系统将提示“无法统计出勤情况”。在职员工分为两类:一类是普通员工, 需进行功能说明书第3步的操作;另一类是特权员工, 如总经理等级别的员工, 常因出差、招标等原因外出, 因此考勤可以适当放宽, 执行功能说明书第4步操作。

(3) 上班时间为早上9:00到下午5:00, 刷卡时间允许前后波动15分钟。普通员工一个月内最多可迟到3次。超过3次, 每超过1次扣除员工月工资总额的1/30。假设刷卡时间为time, 月工资为salary, 迟到次数为count。迟到次数小于3次, 系统提示“无迟到记录”;迟到次数等于3次, 系统提示“本月迟到达到3次”;迟到次数大于3次, 系统计算本月应扣除工资:salary/30× (count-3) , 并将结果显示出来。

(4) 特权员工刷卡时间不作为考勤的唯一标准。统计此类员工考勤信息时, 系统弹出“特权员工不按照普通员工的考勤考核办法”。

根据考勤系统的功能说明书, 可以分析得出系统的不同类别, 如下表1所示。

由表1可知, 每个分类分别有3、2、2、3个类别, 将这些类别分别组合, 可知该系统的用例总数为3×2×2×3=36个。但其中有些用例是不合法的, 比如:“information文件的状态”如果是空, 则不可能与“员工ID状态”这个分类进行组合。此类不合法的测试用例无需进行测试。因此实际测试用例少于36个。构造系统分类树, 如图1所示。

该分类树中图形含义如下: (1) 圆点表示开始, 代表根结点, 表示系统的输入域。位于顶点下方的“information文件的状态”为顶层分类; (2) 矩形框表示按照功能说明进行的分类 (即表格1中第一列的项目) ; (3) 分类树的终端即叶子结点用列 (竖线) 来表示; (4) 分类树中的每一行代表一个测试用例。

分类树下方用横线隔开, 每一行可以设计一个测试用例。可设计如下7个测试用例: (1) 输入information文件状态为“不存在”, 预期输出:考勤系统弹出错误提示; (2) 输入information文件状态为“存在但为空”, 预期输出:考勤系统弹出错误提示; (3) 输入information文件状态为“存在但不空”, 员工ID状态为“无此ID”, 预期输出:考勤系统弹出“无法统计出勤情况”的提示; (4) 输入:information文件状态为“存在但不空”, 员工ID状态为“有此ID”, ID的权限为“特权员工”, 预期输出:考勤系统弹出“特权员工不按普通员工的考勤办法考核”; (5) 输入:information文件状态为“存在但不空”, 员工ID状态为“有此ID”, ID的权限为“普通员工”, 迟到次数count小于3, 预期输出:考勤系统弹出“无迟到记录”; (6) 输入:information文件状态为“存在但不空”, 员工ID状态为“有此ID”, ID的权限为“普通员工”, 迟到次数count等于3, 预期输出:考勤系统弹出“本月迟到达到3次”; (7) 输入:information文件状态为“存在但不空”, 员工ID状态为“有此ID”, ID的权限为“普通员工”, 迟到次数count大于3, 预期输出:考勤系统显示员工本月应扣工资金额。由图1可知, 由分类树设计的7个测试用例, 相比原先由组合关系得到的36个测试用例, 数量明显减少, 根据系统的输入数据域, 可全面测试系统功能。

2.2 正交试验设计

正交试验设计 (Orthogonal experimental design) 是研究多因素多水平的一种设计方法, 它根据正交表从全面试验中挑选出部分有代表性的点进行试验。正交表是均衡分散的, 在减少测试用例的同时, 也能对软件进行全面的测试。在正交测试中, 次数 (Runs) 表示测试用例的个数;因素数 (Factors) 表示影响某结果的变量个数;水平数 (Levels) 表示每个因素取值的个数;正交表的表现形式记为:Lruns (1evelsfactors) 。其操作步骤如下: (1) 找出与软件系统输出结果相关的因素与水平; (2) 根据不同的因素和水平, 选择适当的正交表。如果影响软件的水平数相同, 因素数刚好符合正交表, 则直接选用该正交表。如果水平数相同, 但在正交表中找不到相应的因素数, 则取因素数最接近但略大实际值的表; (3) 将正交表转化为含有因素的测试用例方案。

3 结语

分类树方法与等价类划分相似, 但主要采用树形图来设计测试用例, 可以减少用例数量。此方法对测试者软件项目经验要求不高, 而且可以不依赖自动化工具即可进行测试。正交试验设计法也可以优化用例的数量。该方法由正交表来设计测试用例, 减少试验次数。但利用正交试验设计法有时因素数和水平数与正交表不会恰好相符, 有一定的误差。本文两种方法各有优点。

参考文献

[1]段力军.软件产品黑盒测试的测试用例设计[J].测试技术学报, 2007, 21 (2) :160-162.

[2]CHEN TY, PAK LOK POON.Experience with teaching blackbox testing in a computer science/software engineering curriculum[J].Education, IEEE Transactions on Issue Date:Feb.2004, 47 (1) :42-50.

[3]郭学品, 钟声, 黄成.软件测试用例设计分析[J].海南广播电视大学学报, 2010 (4) :16-19.

7.Web安全测试用例设计研究 篇七

随着电子商务和互联网的广泛应用,Web应用软件被越来越广泛的使用。除了传统的应用如电子邮件、新闻网站等,目前Web应用软件也被越来越多的关键性任务使用,例如互联网证券、互联网银行、网络购物等涉及金钱交易的应用,以及政府部门的电子政务等业务通过互联网来开展等。上述关键性的应用对软件安全的要求越来越高,假如由于软件的不安全造成系统被破坏或信息被泄露,将会给国家、集体甚至个人带来巨大的损失。所以,确保Web应用软件的安全是非常重要的,设计全面、有效的安全测试用例则是重中之重。

2 常见Web安全问题

研究Web应用软件的安全性测试技术,首先应对已知的应用软件安全问题进行研究,了解各种漏洞产生的原因、触发的条件、造成的后果,抽象出各类漏洞的特征,进行科学的分类,才能有效指导安全性测试工作,保障其科学性、高效性和针对性。OWASP(The Open Web Application Security Project)是一个致力于web应用安全的国际组织,OWASP分析实际应用中经常出现的安全漏洞,并对各类漏洞进行总结描述,发布每年度的最危险的十大漏洞,能够很好地反映Web安全所面临的威胁和这些威胁的发展趋势,被众多权威性机构(如美国国防部、国际信用卡数据安全技术标准、美国联邦贸易委员会等)列为应用程序安全规范。根据OWASP提出的Web应用安全漏洞数据分布来看,Web应用程序面临的安全形势依然严峻,常见的安全问题包括:

1)注入式攻击。例如SQL、OS以及LDAP注入,发生在不受信任的数据作为一条指令或是查询要求的一部分被发往解释程序之时。攻击者所植入的恶意数据可以骗过解释程序,导致该指令或查询要求在无意中被执行。

2)跨站点脚本(简称XSS)。每当一个应用程序携带了不受信任的数据并将其发送至页面浏览器而又未经过相关验证及转换解析时,XSS类漏洞就会蠢蠢欲动。XSS允许攻击者在受害者的浏览器中执行脚本,这会导致用户的会话遭受劫持、网站受到破坏或者是将用户的访问目标重新定向至某些恶意网站。

3)无效的认证及会话管理功能。应用程序的相关认证及会话管理功能在执行过程中常常发生各种问题,导致攻击者有可能获取到密码、密钥、会话授权或是通过利用其他执行性漏洞来盗取用户身份。

4)对不安全对象的直接引用。当开发者公开引用某种对内部执行对象,例如索引系统、一个文档或是数据库关键信息时,就有可能发生这种不利情况。由于缺乏访问控制检查等安全保护措施,攻击者能够利用引用信息对未获授权的数据进行访问。

5)伪造的跨站点请求(简称CSRF)。CSRF类攻击的特点是,强迫受害者的某个已进行登录操作的浏览器向安全保护薄弱的页面应用程序发送一条伪造的HTTP请求,包括受害者会话缓存内容及其他任何自动产生的包含认证信息的内容。这就导致了攻击者可以通过强制受害者浏览器向具有漏洞的应用程序传递请求的方式,使相关的应用程序认定该请求是受害者本人所发出的合理请求。

3 Web安全测试内容

攻击者攻击网络的手段多种多样,目的在于寻找并利用网络中存在的漏洞。要想实现周密的安全防范,就需要分析攻击者入侵网络的方式。攻击者对网络攻击的方式包括本地攻击、远程攻击和伪远程攻击。他们的目的主要包括:非法访问目标系统,以获取不应有的访问权限;篡改相关数据,修改重要资料;获取所需资料;使用有关资源,发布虚假信息、占用存储空间甚至发动分布式攻击等。

攻击者进行Web应用攻击行为的过程包括:首先,发现Web系统或应用程序中已存在的漏洞;然后,根据具体漏洞的类别采取对应的、有效的攻击手段;最后,人工分析攻击结果,获取想要的信息或权限。按照目前常见的攻击手段,应该有针对性的进行测试,主要的测试内容如下:

1)漏洞扫描。安全漏洞扫描一般需要借助特定的漏洞扫描器完成,漏洞扫描器其实就是一种能自动检测本地主机或远程端安全性弱点的程序。系统管理员通过漏洞扫描器能及时发现维护的信息系统中存在的安全漏洞,这样在保卫信息系统网络安全过程中可以有的放矢,及时对漏洞进行修补。按照常规标准划分,漏洞扫描一般分为两类,分别为网络漏洞扫描器(Net Scanner)和主机漏洞扫描器(Host Scanner)。网络漏洞扫描器是指通过网络,远程检测目标主机或网络系统的安全漏洞的程序,典型的程序包括ISS Internet Scanner、Satan等。主机漏洞扫描器是指在本地主机或网络系统上运行检测安全漏洞的程序,如著名的COPS、Tiger等软件。

2)功能验证。功能验证属于软件测试当中的黑盒测试方法,对涉及软件的安全功能,如权限管理功能、用户管理功能、认证功能、加密功能等进行测试,验证上述功能是否安全有效。进行黑盒测试的目的是为了模拟一个用户可能采取的恶意行为,观察Web应用系统及其配套的安全措施能否真正地起到防护过滤恶意行为的作用。

3)网络侦听。实际上,网络侦听是指在数据交互或数据通信过程中对数据进行截取并分析的过程。目前,比较通用的网络侦听技术就是捕获网络数据包,我们通常称为Capture,黑客可以通过该项技术盗取公司或个人有价值的数据,同理,测试人员一样可以利用该项技术测试Web应用软件或系统的安全性。

4)模拟攻击测试。模拟攻击测试对于安全测试来说是一种特殊的黑盒测试案例,我们通过模拟攻击的方式来验证信息系统或软件的安全防护能力,在数据处理与数据通信环境中常见的攻击包括冒充、重演、消息篡改、服务拒绝、内部攻击、外部攻击、陷阱门、特洛伊木马等。

4 测试用例设计原则

一个完整的Web安全测试用例体系设计可以从身份验证、加密、输入验证、敏感数据、配置管理、授权、异常管理、会话管理、参数操作、审核和日志记录、部署与基础结构等几个方面入手。下面将详细描述测试用例设计时需要注意的要点。

1)数据加密设计原则。执行数据传输操作需要对某些数据进行信息加密和过滤,比如用户登录密码信息、用户信用卡信息等。此时,其他操作也需要相应进行,如解密发送到客户浏览器或用户电子邮箱、将信息存储到数据库等。目前的加密算法种类越来越多,设计越来越复杂,但数据加密的过程一般是可逆的,意思就是能对数据进行加密,也能对数据进行解密。一般可在后台数据库查看登录的账户和密码是否进行了加密。

2)目录设计原则。Web的目录安全是一个不容忽视的因素,如果Web服务器或Web应用程序的设计不合理,攻击者就可以通过简单的URL推测和替换,完全获取整个Web目录的权限,这样就对Web站点造成很大的安全性隐患。我们可以采取一定的预防措施,如在访问每个目录时设置index.htm,或者访问Web服务器的目录时对权限进行严格的设定,从而使发生安全问题的可能性尽可能地降低到最小程度。

3)登录设计原则。一般的Web应用站点都会采用登录或注册后使用的方式,所以必须对用户名和密码进行匹配校验,以防止用户非法登录。进行登录测试时,需要考虑的方面包括输入的密码是否区分大小写、是否有长度条件限制,最多可以尝试登录多少次,哪些文件或者页面需要登录后才能访问或下载等。

4)服务器脚本语言设计原则。脚本语言存在一定的安全隐患,每种脚本语言的细节略有不同,有些脚本语言允许访问根目录,其他脚本语言只允许访问邮件服务器,但是有经验的黑客可以通过脚本漏洞获取服务器的用户名和口令。设计测试用例时需确认站点使用了哪种脚本语言,并研究该语言的漏洞,还需要考虑是否存在没有经过授权就在服务器端编辑或放置脚本的情况。

5)SSL设计原则。现在越来越多的Web站点使用SSL安全协议进行数据传送。SSL是Secure Sockets Layer(安全套接字协议层)的缩写,是Netscape首先发布的网络数据安全传输协议。SSL的原理是通过私有密钥/公开密钥的加密技术(RSA),在TCP层和HTTP层之间对用户与服务器之间的通信进行加密,确保信息传递的安全性。SSL是在私人密钥和公共密钥的基础上进行工作,任何用户都可以获取公共密钥来加密数据,但解密数据需要使用相应的私人密钥。打开一个SSL站点后,有时候能看到浏览器弹出警告信息,地址栏的http变成https,对SSL进行测试的时候需要确认上述特征,以及站点是否具备时间链接限制等相关的安全保护措施。

5 结束语

Web应用是一种典型的应用程序,Web应用本身越来越复杂,同时它所使用的开发语言和开发模型在不断发展,所有这些因素给测试带来了很大的难度。目前的安全测试主要依赖测试工程师的直觉和经验,Web安全测试被认为是一个耗时、代价昂贵的过程,因此,迫切需要设计一套系统的Web安全测试用例对Web应用进行全面的测试。本文正是基于以上目的,对Web安全漏洞进行分类,研究了Web安全测试内容,阐述了安全测试用例设计原则。

参考文献

[1]方建超,徐全军.网络安全漏洞检测技术分析[J].计算机安全,2005(10):32-33.

[2]施寅生,邓世伟,谷天阳.服务安全性测试技术研究[J].计算机工程与科学,2007,29(10):11-13.

[3]刘焕洲,缪淮扣.Web应用程序建模和测试用例生成方法[J].计算机工程,2008,34(6):60-62.

[4]The Open Web Application Security Project[EB/OL].http://www.owasp.org/index.php/Main_Page.

8.基于改进遗传算法的测试用例生成 篇八

遗传算法作为一种高效全局搜索算法,其在解决大空间、多峰、非线性、全局化等复杂问题时显示了独特优势和高效性。从而被引入测试领域,为解决测试数据生成这一难题带来新的转机。但是,实际应用中由于遗传算法自身缺陷,它只能找到接近全局最优解,而不能保证收敛到全局最优解,常常出现早熟收敛和局部收敛性差等问题。为了克服以上缺陷,Srinvivas等提出了自适应遗传算法,其基本思想是根据种群中个体适应度动态改变交叉概率与变异概率,增加了种群搜索速度,保证算法收敛速性。自适应策略在某些程度和某些方面提高了算法的性能[3],但是仍有可改进之处:局部寻优能力差、种群个体之间差异性不明显[4]。

基于以上原因,文中将遗传算法和禁忌搜索算法相结合而构成一种改进的遗传算法。其主要优点是吸取了遗传算法和禁忌搜索算法的长处,避免了两者的短处,发挥了遗传算法全局搜索能力和禁忌搜索局部寻优能力,克服了遗传算法局部搜索能力差及其早熟现象和禁忌搜索全局搜索能力差、效率不高的问题。文中就算法的改进以及应用于测试用例生成问题的方法进行了详细讨论,并通过实验和分析,把改进的算法(以下称为TUGA)和自适应遗传算法(以下称为AGA)[5]在性能上进行了比较。

1 遗传算法的改进

1.1 基本原理

遗传算法是以自然选择和遗传理论为基础,将生物进化过程中适者生存规则与群体内部染色体的随机信息交换机制相结合的搜索算法。遗传算法以一种群体中的所有个体为对象,并利用随机化技术的指导,对一个被编码的参数空间进行高效搜索。其中,选择、交叉和变异构成了遗传算法的遗传操作;参数编码、初始群体的设定、适应度函数的设计、遗传操作设计、控制参数设定5个要素组成了遗传算法的核心内容。算法过程,如图1所示。

1.2 TUGA算法提出

遗传算法中交配是随机的,虽然这种随机化的杂交形式在寻优的初级阶段保持了解的多样性,但在进化后期,大量个体集中于某一极值点上,容易造成近亲繁殖,以致个体差异性不够明显,往往得到的是局部最优解,生成的测试用例达不到满意的覆盖率。

因此,必须实施一定策略对这种情况进行改进。文中做法是引入禁忌搜索算法,利用禁忌算法的记忆功能和爬山能力强的优点,对淘汰的个体进行大范围的转移搜索,并将生成新的优质个体代替淘汰的个体。这样遗传算法就具有了禁忌算法局部搜索能力强的优点,加大生成最优解的概率。TUGA过程可简单描述如下:

步骤1:初始化参数;种群大小PopSize、禁忌表长度L、种群Pop 。

步骤2:计算种群中个体的适应度,检查是否满足终止条件;如满足退出。

步骤3:对种群中个体进行选择操作。

步骤4:对种群中个体实行自适应交叉、自适应变异操作。

步骤5:对被淘汰个体进行大范围转移搜索,并用产生的新个体代替被淘汰个体。

步骤6:生成新一代种群,转到步骤2。

1.2.1 禁忌搜索模块的设计

定义1 两个个体之间相似度为S,表示为

定义2 以一点为中心的一个球体,在这个球体中非中心的任一点称为中心点的邻居。

自适应遗传算法中融入了禁忌搜索法的思想,使得那些只有通过禁忌检验的个体,才能真正地被作为新的个体所接收。这一方面使得那些有效基因缺失、但适应度不高于其父代的个体被禁忌掉;另一方面,也使得那些包含有有效基因、但适应度较低的个体有更多机会参加交叉和变异,从而延缓或避免了早熟收敛的发生,也提高了遗传算法的爬山能力。

(1)邻域解集合大小和选取方式是影响算法性能关键参数,它是在当前解得邻域中择优选取,选取过大将会造成较大计算量,选取过少生成优质解概率就会变小。文中生成邻域的策略是以当前解x为中心,以R为半径产生一系列邻域,即

这样x′就是当前解x随即生成的离散化的邻域解;

(2)在遗传算法进化过程中,每一代进行完交叉和变异后,对低于γ水平的个体淘汰出种群,设淘汰个体为αi{α1,α2,…,αn},使用禁忌搜索算法每个个体αi进行大范围转移搜索,挑选一个体代替αi加入新一代种群。邻域搜索过程如下:

步骤1:选定一个初始解φnow=αi及禁忌表L=Φ。

步骤2:根据上述方法生成φnow邻域β。

步骤3:从β中选出最优个体Best;当f(Best)>(fφnow)且S>ε时,φnow=Best,Best加入禁忌表L;否则,若Best∉L,φnow=Best,并修改禁忌表L。

步骤4:若满足条件终止搜索,否则转到步骤2。

1.2.2 遗传模块的设计

文中对传统遗传算法3个基本算子进行了改进,并加入了精英保留策略,算子改进如下:

(1) 选择算子。

选择操作体现了适者生存原则,决定了种群中个体的分布。为了加快淘汰劣质个体速度,提高优质个体被选中的概率,文中用各个个体的适应度值减去群体中最差个体的适应度值,以此值作为选择个体的标准。

这种方式比传统的“轮盘赌”方法更优,使得优良个体被选中进行交叉和变异的概率明显增加,而使最差个体根本得不到遗传的机会,整体收敛速度也得以明显加快。选取概率计算如下

其中,fi是要被选择个体适应度,fworst是最差个体适应度;

(2) 自适应交叉、变异。

传统的遗传算法变异率和交叉率是固定不变的,是纯粹的随机搜索,带有一定盲目性,可能使得具有较高适应度个体遭到破坏[5];也可能变异力度不够,出现了搜索过程缓慢停滞不前。为此,文中采用了自适应算子,动态调整交叉概率和变异概率,很好地克服了上述缺陷。这种有指导性的进化具有更高鲁棒性、全局最优性和效率[4]。交叉率Pc、变异率Pm计算公式如式(4)所示

式中,fmax是群体中最大适应度值;favg是每代群体的平均适应度值;f′要交叉个体中较大的适应度值;f要变异个体的适应度值。式(5)中Pc1=0.9,Pc2=0.6,Pm1=0.1,Pm2=0.001;

(3) 精英保留策略。

将种群中最好的个体不进行遗传操作,直接复制到下一代种群,作为下一代种群的新个体。

1.2.3 适应度函数构造

一般而言,适应度函数是由目标函数变换而成的。而对于软件测试而言,用测试用例覆盖准则来表示测试用例的测试效率。覆盖率高的测试用例其测试效率就越高,进而其适应度函数的值就越高。适应度函数的构造是遗传算法在测试用例生成方面应用的关键所在,直接影响到问题求解的效率。

文中采用QUEST/Ada系统中的覆盖表[6],覆盖表中每条记录都有一个类型域、一个True域和一个Flase域;类型域表明该记录的类型即语句、分支、条件、判定、循环、路径;True域和Flase域表明该类型域是否被覆盖。在一次测试中一般不会出现所有记录类型,而只是出现与测试目标相关的记录类型。表1是当测试目标为条件-判定覆盖时一个可能的覆盖表,其中Y表示该域被覆盖,N表示该域未被覆盖,-则表示该域不适用。

通过覆盖表记录可以计算个体的适应度即被覆盖区域和所有区域之比。以表1的条件-判定为例,假设被测程序中条件个数为x,判定个数为y,被覆盖的判定个数为m,True域被覆盖的条件个数为α,False域被覆盖的条件个数为b,则适应度值F为

覆盖表可以根据程序插桩理论对被测试代码进行插装得到,覆盖表可以在很大程度上提高搜索效率。采用覆盖表可以避免对源程序进行复杂的符号分析,从而可以用于较大规模的程序[7,8]。

2 实验结果与分析

为了验证用TUGA生成测试用例的有效性,在Windows XP系统下,用C语言编写了TUGA算法框架。并用软件测试中广泛应用的三角形判别问题作为被测程序,并就TUGA与AGA二者时间效率和搜索能力进行了比较。

图3、图4是文中方法和AGA算法在种群大小从40～200时生成最优解所耗费的时间连线图,横坐标表示种群大小,纵坐标表示生成最优解时间(单位:ms)。实验中分别对TUGA算法和AGA算法独立运行10次,生成最优解所耗费时间则是10次运行的平均值。

上述实验数据表明,在同等参数条件下,文中提出的基于TUGA算法测试数据生成和基于AGA算法的测试数据生成方法相比,在时间效率和搜索能力上具有非常明显的优势。

3 结束语

测试数据的自动生成是测试阶段关键的技术问题,改进测试用例生成方法,对提高软件测试的自动化程度,具有十分重要的现实意义。文中应用TUGA算法解决了软件基于路径的测试数据生成问题,克服了自适应遗传算法在测试生成方法上的不足和缺陷,因此TUGA算法可以作为一种较为理想的算法进行测试用例生成。

摘要：在软件测试中,测试用例生成是软件测试中的关键技术问题,对于软件测试的自动化有着重要影响。为了提高测试用例生成的效率,文中提出了一种用于测试用例生成的改进算法。该算法引入了自适应算子和禁忌搜索思想,将自适应遗传算法和禁忌搜索有机结合,充分发挥遗传算法的全局搜索和禁忌搜索算法局部搜索优势,提高了测试数据的生成能力。实验结果表明,该算法在测试数据自动生成的效率和有效性方面,均优于自适应遗传算法。

关键词：测试用例生成,遗传算法,禁忌搜索算法,转移搜索

参考文献

[1]Zhang J,Xu C,Wang X.Path-oriented Test DataGeneration Using Symbolic Execution and Constraint Sol-ving Techniques[C].Beijing:Proc.of the Int′1Conf.on Software Engineering and Formal Methods,IEEE Compumr Society Press,2004:242-250.

[2]荚伟,高仲仪.基于遗传算法的软件结构测试数据生成技术研究[J].北京航空航天大学学报,1997,23(1):36-40.

[3]Srninasm,Painaikm.Adaptive Probabilities of Crossoverand Mutation in Genetic Algorithms[J].IEEE Trans onSystems,Manand Cybe Rnetics,1994,24(4):656-659.

[4]闵建虎,赵振勇.基于遗传算法的BP网络学习算法研究[J].电子科技,2008,21(11):62-65.

[5]Tsoulos I G,Lagaris I E.GenMin:An Enhanced Ge-netic Algorithm for Global Optimization[J].ComputerPhysics Communications,2008,61(19):2925-2936.

[6]王小平,曹立明.遗传算法-理论、应用与软件实现[M].西安:西安交通大学出版社,2002.

[7]Xue Yunzhi,Chen Wei,Wang Yongji.An AutomatedApproach for Structural Test Data Generation Based onMessy GA[J].Journal of Software,2006,17(8):1688-1697.

9.软件测试用例复用技术研究与实践 篇九

随着电子智能化技术的飞速发展, 硬件越来越依赖软件的质量, 不管是生产商还是使用者都对软件质量问题非常重视, 所以软件质量已经成为大家的关注焦点。

当然软件生产商保证高质量的产品是最重要的一个环节, 全世界比较统一用的对高质量软件的实现一般分为两个途径:首先要标准化软件生产流程、生产标准以此从源头管控好软件的质量;其次要加大对设计软件进行可靠性评估和测试, 多角度模拟客户使用环境来评估软件的使用性能。所以软件测试可以直接用来衡量软件质量的好坏。

2 测试用例

2.1 测试用例的定义

2.2 测试用例的设计

业界一般将软件测试分为静态和动态测试。前者指的是程序没有运行而是直接检查程序本身的语法结构和接口等手段来审查软件的准确性。常用的静态测试方法有代码走查、测试工具方法等。

与静态测试方法对立的动态测试方法则直接启动程序运行, 直接检查运行结果跟预期之间的差异来判定其运行质量。常用的动态测试方法有执行程序方法、分析程序输出结果方法等。

动态测试又分为白盒测试和黑盒测试。

白盒测试主要是测试员根据内部结构和程序路径涉及的测试的一种方法。白盒测试标准范畴囊括了逻辑覆盖、循环覆盖和基本路径覆盖。其中常用的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖和路径覆盖, 该六种覆盖标准发现错误的能力呈由弱到强的变化。

虽然白盒测试有点多, 可靠性强, 但是其成本高、费用大, 其测试费用甚至超出软件本身的设计费用, 所以比较流行的是黑盒测试取而代之。

黑盒测试的原理是检查每一个功能运行是否正常, 测试人员只需要根据程序的输入和输出就可以知晓程序的正确性、黑盒测试用例IDE设计方法一般划分为边界值分析法、正交试验设计法、功能图法、穷举法等。

3 可复用测试用例的生成

可复用的测试用例的存在是测试用例复用的重要条件。由于件系统的多样性和复杂性, 要实现测试用例的复用不是一件简单的事情, 进行测试用例复用需要耗费各种资源, 但是我们复用测试用例的很大目的就是为了提高效率, 节省资源, 所以为了实现软件测试用例的复用, 我们需要有系统的方法和策略。产生可复用测试用例的过程框架如图1所示。

3.1 共性/领域分析

共性/领域分析这项活动需要型号设计总师、型号测试总师、软件测试组长、软件测试参加人员等人员参与。

共性是指不同的事物所共有的性质。共性分析即提取不同系统中存在的共性。提取共性是实现软件测试用例复用的基础。所以想要实现软件测试用例的复用, 必须要从大量系统中提取共性, 即可复用的内容。软件测试用例的设计依据的是软件需求规格说明书, 因此, 复用内容的提取来源于软件需求。通过对大量同一领域的已有系统的功能、界面元素、工作流程、业务规则及系统接口进行分析, 从中提取共性要素。

3.2 测试策略分析

软件测试策略是为软件工程过程定义的一个软件测试的模板, 也就是把特定的测试用例方法放置进去的一系列步骤。软件测试人员针对共性分析挖掘出的可复用点, 分析各复用点的测试策略, 包括测试类型、测试方法、测试环境、测试覆盖率等内容。

进行软件测试策略分析时包含以下特征:

(1) 测试从模块层开始, 然后扩大延伸到整个基于计算机的系统集合中;

(2) 不同的测试技术适用于不同的时间点;

(3) 测试是由软件的开发人员和独立的测试组管理;

(4) 测试和调试是不同的活动, 但是调试必须能够适应任何的测试策略。

3.3 可复用测试用例的设计与产生

在软件需求进行共性分析后, 再根据相应测试策略细分至可操作程度后, 便可根据对可操作共性的输入输出进行分析, 并生成测试用例。在所有的输入集合中, 软件测试人员可根据输入参数和环境变量的不同, 将输入划分为若干类别, 每个类别不能相交, 这些不同的类别又可分为若干选择, 每个选择有相应的输入值。每个类别中的选择也不能相交, 且每个类别中所有选择的并集需要覆盖整个输入集合。

4 结语

在应对软件测试规模不段扩大及软件测试复杂度不断提高的挑战时, 基于共性分析的测试用例复用方法对于提高测试的效率和质量是有效的。在新系统测试时从测试用例库中选取可复用测试用例, 并在使用过程中持续优化可复用的测试用例。软件测试人员通过实践会发现测试用例复用给测试工作带来的收益会随着可复用的测试用例的日益积累优化更加明显。

参考文献

[1]李登辉.基于偶然正确测试用例识别的错误定位方法[D].北京:北京化工大学, 2015.

[2]田春艳.基于灰色关联逼近理想解方法的测试用例评价模型研究[D].昆明:昆明理工大学, 2009.

[3]孙召倩.利用路径相似度识别偶然性正确测试用例的方法[D].大连:大连海事大学, 2014.

[4]夏菁.测试用例精简工具的研究[D].北京:北京邮电大学, 2015.