测试设计思路和框架

从需求出发分析产品的功能特性，梳理出性能指标、设计约束和使用保障要求。对于功能特性和需求场景，将每个功能特性和需求场景与测试数据和测试条件相结合，加上通过等价类划分、边界值等分析方法获得的测试数据，形成测试计划。测试计划的目的是实现测试目标的内部沟通并服务于外部评审。测试用例设计的主要输入文件，如需求规格说明书、产品设计等，都会影响测试用例的设计。场景法测试用例设计方法主要用于事件触发过程。基于测试用例的全面测试执行是基础，但在完成测试用例执行后，鼓励基于风险和反馈的探索性测试。在整个开发和测试过程中，思考和沟通是最重要的环节。

1. 测试设计和架构 1.1． 测试分析与设计流程

                                   图1  测试分析及设计流程图

1.1.1. 从需求演进到功能特性和需求场景

从需求出发分析产品的功能特性，梳理出性能指标、设计约束和使用保障要求。

从需求角度分析产品需求场景。 分析的核心是角色、场景、解决方案三个维度的梳理。 （在某种场景下什么样的角色用户有这个需求？满足这个需求、解决这个问题的解决方案和途径是什么？对应的具体流程是什么？）

分析需求不仅仅是某一类用户在单一场景下产生的需求。 很多场景下可能是各类用户共有的，所以需要以思维导图的形式梳理出具体的需求场景。

1.1.2. 从功能特性、需求场景到测试计划

对于功能特性和需求场景，将每个功能特性和需求场景与测试数据和测试条件相结合，加上通过等价类划分、边界值等分析方法获得的测试数据，形成测试计划。

测试计划的目的是实现测试目标的内部沟通并服务于外部评审。

1.1.3. 功能点判断

首先设计主要功能的测试用例，然后设计次要功能的测试用例。

1.1.4. 从测试计划到测试用例

编写用例并不意味着复制和粘贴测试计划。 您需要总结该计划。 在编写用例时，需要考虑测试计划的缺陷。

因为测试用例是测试执行的详细指南，所以需要根据测试用例编写的规范尽可能满足测试可执行文件。

1.2. 测试设计要考虑的因素

考虑到背景、需求、技术知识、团队、进度、风险因素以及穷举所有测试场景或组合的难度，在设计测试用例时，需要把握测试的风险和要点，并遵循分步过程只有充分分析和设计曲面的规律，才能达到理想的覆盖率。

因子含量

测试要求目标

包括功能测试和性能、接口集成测试目标。

用户实际使用场景

从用户的角度思考产品的每一个特性，确保为测试用例建立正确的判断依据。

输入文件

测试用例设计的主要输入文件，如需求规格说明书、产品设计等，都会影响测试用例的设计。 这些文件的描述方法、格式和详细程度需要仔细审查。

测试方法

测试用例的具体设计方法详见4.4章节。

被测试物体

不同阶段的测试用例有不同的侧重点，测试设计需要从不同的方面发现系统的弱点或薄弱环节。

1.3. 测试设计的基本原则

测试用例并不是简单地照搬产品需求、功能设计规范等，而是通过思考和优化来设计的。 测试是基于数据分析的数据流和基于逻辑结构分析的控制流。 测试设计方法是通过不断设计和优化测试用例来实现控制流和数据流的覆盖。

1.3.1. 薄弱环节及边界点判断

1.3.2 尽量寻找系统的薄弱环节和边界点，对特殊区域进行更多的测试，以降低测试风险，实现既定的测试目标。

1.3.3.优先级判断

1.3.4 先为高优先级的测试项设计测试用例，再为低优先级的测试项设计测试用例。

1.3.5 正常与异常分支流程的判断

根据具体需求，首先设计正向测试用例，然后设计异常和非法操作测试用例，具体见图2和图3。

                                                                             图2  具体需求测试设计顺序图

                      图3  软件流程示意图

1.4. 测试设计方法

在测试过程中，单一的方法无法满足测试设计的要求，必须采用多种方法才能满足测试设计的要求。 例如，将等价类划分与边界值分析结合起来。

1.4.1. 测试设计的基础

(1)需求说明

(2)掌握本行业的业务知识

(3)测试工程师的理解程度（个人经历）

1.4.2. 测试设计方法

1.4.2.1. 场景用例设计方法

场景法测试用例设计方法主要用于事件触发过程。 当事件被触发时，就会形成相应的场景流程。 不同的事件触发不同的序列和不同的处理结果，形成一系列事件结果。 这一系列的事件触发过程也可以看成是不同的路径，可以利用路径覆盖的方法来设计测试用例。 因此，情景分析法也称为过程分析法。

                       图4  场景用例设计方法

首先，对系统运行所涉及的各个流程（如图3所示）进行了图表化。 从最基本的流程开始，将流程抽象为不同函数的顺序执行。 在最基本的流程的基础上，我们再考虑次要的或异常的流程。 就这样，各个流程逐渐细化，各个看似孤立的流程又相互关联。 当完成所有流程的图解之后，所有路径的设计就完成了。 当然。

找到路径后，需要为每条路径设置优先级，以便在测试时先测试高优先级的路径，再测试低优先级的路径。 如果时间紧张，你甚至可以考虑忽略一些低优先级的。 小路。 优先级的选择基于两个原则：一是路径使用的频率，使用越频繁，优先级越高； 第二，路径的重要性，故障对系统的影响越大，优先级越高。 将根据两个原理分别得到的优先级相乘即可得到整条路径的优先级。 根据优先顺序，测试可以更有针对性。

设置每条路径的优先级后，为每条路径选择测试数据并构建测试计划。

1.4.2.2。 等价类划分方法

典型的黑盒测试方法要求测试人员对需求文档中的功能需求进行详细分析，将程序的输入域划分为若干部分，然后从每个部分中选取少量有代表性的数据作为测试用例。 经过这样的划分之后，每个类的代表数据在测试中就相当于该类中的其他值。

(一)分类

1）有效等价类：有意义的输入数据的集合；

2）无效的等价类：无意义的输入数据的集合；

(2)方法

例如：我们要测试由“司机输入5位车次车次”组成的字符。 首先将子集划分为：空车次、1-4位、5位、5位及以上、非数字，然后从每个子集中选出几个代表值：

（1）空车次：（无效等舱，无意义）；

（2）1-4位数字：1234（无效等效类别）；

（3）5位数字：00000（有效等效等级）根据需求是否合理；

(4) 5位以上：123456（同等等级无效）；

（5）非数字：fy7ui（无效的等效类）；

1.4.2.3.边值分析法

等价类测试的一个特例主要考虑等价类的边界条件。 选择等价类边缘的元素是指输入和输出的等价类中恰好位于边界上或刚刚超出边界的数据集。 例子。 对于所选的测试用例，应选择恰好等于、刚好大于、刚好小于边界的值。

例如：如果轮径值设置为860，则边界值为859、861。如果是完整测试，除了边界值外，还需要测试正常值。

1.4.2.4。 错误的猜测方法

在测试过程中，测试工程师可以根据经验或直觉推测程序中可能出现的各种错误，从而针对这些错误编写有针对性的测试用例。

这种方法没有固定形式，主要依靠经验和直觉。

1.4.2.5。 探索性测试设计

基于测试用例的全面测试执行是基础，但在完成测试用例执行后，鼓励基于风险和反馈的探索性测试。 优先考虑安全相关功能和风险级别较高的功能进行探索性测试。 已完成 对测试中问题较多的功能模块进行第二步探索性测试。

需要注意的是，探索性测试一旦发现问题，需要对测试计划中没有考虑到的点进行梳理并进行回顾，以完善测试计划的测试用例库，提高测试设计能力人员。

2、测试程序编写的目的和要求 2.1． 测试程序编写的目的

在整个开发和测试过程中，思考和沟通是最重要的环节。 记录生成并达成共识的内容，并以思维导图展示。 然后就可以看到整个需求点测试的全景，然后不断细化成测试故事点，大脑很容易接受这种思维扩散和总结的模式。

2.1.1. 加强内部和外部审查

在审核测试计划时，可以直观地与需求一一对应，可以快速确认需求覆盖率，并确认测试场景和主要观察项目。

2.1.2.测试用例输入

作为测试用例的输入，可以省略测试计划阶段比较关心的测试场景和关键观察项。 测试的详细描述可以省略。 这部分内容将在测试用例设计阶段进行补充。

2.1.3. 指导测试执行过程

测试计划作为测试执行的一个过程，可以让执行者更好地理解测试计划，更有目的地执行每个测试用例。

2.2. 编写测试计划的要求

综合性

尽量覆盖各种路径和业务点，考虑准备跨年、月的数据，以及并发测试的大量数据。

目的

在列出的测试场景中，需要清楚地识别需要观察的输出。

3. 测试用例标准化 3.1． 编写测试用例之前

测试用例是对测试场景和操作的描述，因此必须了解测试目标、测试对象、测试环境要求、输入数据和操作步骤，概括为5W1H。

5W1H内容

测试目标（原因）

为什么要测试？ 功能、性能、可用​​性、容错性、兼容性、安全性等。

测试对象（什么）

测量什么？ 要测试的项目，例如：对象、函数、类、按钮、系统、表格等。

测试环境（地点）

在哪里测试？测试用例运行的环境，包括系统配置和设置要求，以及操作系统、通信协议等单机或网络环境。

测试先决条件（何时）

测试什么时候开始？ 运行测试用例的先决条件或约束。

输入数据（哪个）

什么数据？ 系统在运行过程中接受各种可变数据，如数字、文件、字符等。

操作步骤（方法）

如何测试？ 执行软件、程序等的顺序步骤。如：点击按钮。

3.2. 测试用例编号规则

测试用例编号是唯一的，测试用例编号格式为：

SYS(系统)-XXXX(产品名称)-YYYY(子系统名称)-TC(测试用例)-0001

3.3. 测试用例内容编号组成示例

用例名称

Ø 清楚地描述测试的目的和关键测试要素。 Ø 不允许重复、包含关系或数字与数字的差异。

需求标识号（需求编号）

Ø 每个需求功能点对应一个需求编号。 Ø 每个需求编号需要与一个应用案例编号配对。 需求和用例之间的关系可以是一对一或一对多，但不能是多对一。

需求名称

用例对应的需求名称

用例状态

Ø描述每个用例当前的状态， Ø初始用例状态正常。在用例维护过程中，状态被删除、添加、修改等。

脚步

Ø每个操作步骤应对应一个或多个预期结果Ø操作步骤必须按顺序编号

前提条件

Ø 测试前需要描述测试需要所处的外部环境以及测试对象和辅助对象的状态和配置。 Ø 完成预设条件中描述的状态、配置和外部环境后，需要保证测试正确执行。 性、一致性， Ø 预设条件应该是测试场景之前的操作， Ø 预设条件必须按序号编号

预期结果

Ø为了测试用例的测试目的，测试步骤中操作后对应的预期输出状态。 Ø 预设结果必须按序号编号。 Ø 预期的结果应该是直接可见的内容，而不是可能二分法的概念描述（比如也许、可能）

（例如不应该写临时限速申请成功，但在ATS调度界面上看到黄色临时限速灯带且临时限速申请成功，则临时限速速度可以为在ZC打印中看到，起始和结束位置都是正确的等等，有观察描述）

3.4. 编写用例规范规范内容

系统的

Ø 对于系统业务流程，需要充分描述整个系统的业务需求。 系统由若干子系统以及它们之间的关系组成。 Ø 对于模块业务流程，需要说明其内部功能、关键功能以及它们之间的关系。

综合性

Ø覆盖尽可能多的路径，尽可能覆盖每一个服务点，接口需要覆盖码位的死亡状态。 Ø考虑跨年、跨月的数据以及大量数据并发测试的准备

连贯性

Ø 对于系统业务流程，需要说明各个子系统是如何协同工作的（是否需要接口，各个子系统之间是否有正确的接口，如果依赖负向链接，页面的链接是否正确）正确） Ø 对于模块业务流程，需要说明 说明同级模块和上下级模块如何构成一个子系统，其内部功能接口是否连贯

正确性

Ø 接口输入的数据应与测试文档中记录的数据一致。 Ø 预期结果应与测试数据发生的业务一致。

可重复使用性

注重测试用例的可重用性，即在以后类似系统的测试过程中可以重用，减少测试设计人员的工作量。

统一

测试用例编写应制定统一的模板，并商定模板的适用方法。

4. 测试计划和用例审查要点

在测试计划/用例的设计和准备过程中，应组织同行评审。 准备工作完成后，应组织专家评审，合格后方可使用。 评审委员会可由项目负责人及测试、软件开发工程师、分析设计等相关人员组成，也可邀请客户代表参加。

4.1. 在审查测试用例之前

在测试用例审查之前，必须定义测试用例以满足以下标准：

检查项目内容

覆盖范围

覆盖所有测试范围内容

易读性

清晰准确地描述先决条件、步骤和预期结果

易于维护

用很少的时间维护用例

使用方便

设计思想简单易懂，测试用例组织结构合理，执行流畅，操作一致性好。

4.2. 用例评审检查项目

从测试用例的框架和结构出发，深入到各个部分和细节

检查项目

分析设计思路是否符合业务逻辑、是否符合技术设计逻辑

部分有轻有重，一定要抓住难点和重点，从不同角度进行审视。

在细节方面，是否遵循写作规范和模板，描述是否清晰。

回顾测试用例的积极和消极方面

正测试用例参考需求和设计文档，根据关联功能和运行路径，覆盖率达到100%

负异常测试用例可以发现更多软件缺陷

4.3. 清单审查

通过清单进行审查，对清单上的问题回答“是”或“否”。

5、测试用例的完善和维护

测试用例必须定期修改和更新。在测试过程中发现测试用例考虑不周，需要对测试用例进行修改和完善。

行为要求

添加新用例

Ø 对于系统的新功能，如果在评审或测试过程中发现缺少测试用例或者系统本身存在设计缺陷而没有相应的测试用例，则需要按照设计和规范的规范添加新的测试用例。编写测试用例。 Ø 当添加新的测试用例时，需要将新的测试用例插入到同一功能模块的底部并进行解释。

删除过时的用例

Ø由于需求的变化，一些用例不再适用，需要删除。 应删除整行测试用例，并在备注中注明删除原因。 删除的测试用例应移至用例删除库，并在备注中注明原因。 Ø 如果删除整个功能模块，则需要将整个模块对应的测试用例迁移到用例删除库中，并添加注释说明原因。

修改测试用例

Ø根据需求的变化，需要对不再满足当前测试需求的用例进行修改，并添加注释说明原因。 Ø 测试用例的修改、删除和添加都应反映在“测试用例目录”中的“测试用例状态”中。

删除多余的用例

如果有两个或多个测试用例测试同一组输入，则需要删除它们，只留下其中一个。

补充遗漏用例

如果产品基线后现场发现的缺陷是由于室内漏测造成的，则需要改进测试用例。

本文约2618字，阅读需要7分钟

win7系统不显示管理员帐户的情况如何处理？ 我们点击开始菜单->所有程序->附件->命令行程序，在右键菜单中选择“以管理员身份运行”。 这样，以管理员身份打开命令行程序，输入sc并添加参数，就完成了； 接下来为大家带来win7系统删除Windows服务的详细步骤：

1.什么是Windows服务？

Windows服务，又称Windows服务，是Windows操作系统和Windows网络的基础，是系统核心的一部分。 支持整个Windows的各种操作。 DNS客户端、打印程序、Windows更新服务、计划任务、Windows时间服务等服务，都关系到机器能否正确运行。 如果不能正确管理这些服务可能会影响机器的正常运行。

服务首先是一个Win32可执行程序，或者是由rundll32.exe形成的运行.dll的进程。 它与普通的应用程序不同。 例如，当您打开WORD时，会出现一个界面，但该服务没有用户界面。 也不能直接双击对应的.exe程序来运行。

2. Windows如何控制服务？

Windows服务由更高级别的services.exe服务管理，该服务负责启动、停止、运行和暂停服务。 我们最常用的操作是通过Windows服务MMC接口完成相关操作。

在Windows7系统中，我们点击开始菜单，在搜索框中输入“服务”，双击顶部第一个结果即可打开服务管理，在Vista和XP系统中，还可以通过运行来打开服务管理服务.msc ——

3. 如何删除Windows服务

如今的流氓软件越来越多地将自己注册为服务。 一般非Windows系统服务以023的形式列出，如下段所示：

O23 - 未知 - 服务：BKMARKS 【为传输协议提供数据安全保护机制，有效维护数据传输的安全性和完整性。 ] - C:WINDOWSSYSTEM32RUNDLL.EXE

O23 - 未知 - 服务：ewido 反间谍软件 4.0 防护 [ewido 反间谍软件 4.0 防护] - D:Program Filesewido 反间谍软件 4.0guard.exe

O23 - 未知 - 服务：KSD2Service [KSD2Service] - C:WINDOWSsystem32SVCH0ST.exe

对于这些流氓软件，需要删除相关的.exe文件，使其无法再运行，或者直接清除服务本身，使其在计算机重新启动时不会再次启动。

删除方法有两种：

方法 1：使用 sc.exe Windows 命令

单击“开始”菜单->“所有程序”->“附件”->“命令行程序”，在右键菜单中选择“以管理员身份运行”。

这样，以管理员身份打开命令行程序，输入sc并添加参数。 使用方法非常简单：

sc删除“服务名称”（如果服务名称中有空格，需要前后加引号）

至于上面：sc删除KSD2Service

sc命令的详细解释请参考本文底部。 Windows7 Home/Vista Home已经为您整理好了。

方法二：直接编辑注册表（不推荐）

打开注册表编辑器并找到以下键值：

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services 一般服务都会在这里显示一个同名的主键，直接删除相关键值即可。

4、特殊情况

1.如果服务显示rundll32.exe，并且该文件位于system32目录中，那么您无法删除该rundll32.exe文件，该文件是Windows系统文件。 这时只需清除相关服务即可。

2、如果某个服务被删除后立即自动重新建立，则说明后台有一个进程对其进行监控和保护。 需要先在进程管理器中杀掉对应的进程，或者在Win7/Vista安全模式下启动后按F8删除。

////// 附录：SC命令行程序参数详细解释 ///////

描述：

SC 是一个命令行程序，用于与服务控制管理器和服务进行通信。

用法：

sc [命令] [服务名称] ...

该选项的格式为“ServerName”

输入“sc [command]”以获得有关命令的进一步帮助

命令：

查询---------查询服务的状态，

或者枚举服务类型的状态。

queryex---------查询服务的扩展状态，

或者枚举服务类型的状态。

启动----------启动服务。

暂停----------向服务发送PAUSE控制请求。

interrogate-----向服务发送INTERROGATE控制请求。

continue--------向服务发送 CONTINUE 控制请求。

stop----------------向服务发送停止请求。

config----------更改服务的配置（永久）。

描述-----更改服务的描述。

failure---------更改服务失败时要执行的操作。

failureflag-----更改服务的失败操作标志。

sidtype---------更改服务的服务SID类型。

privs----------更改服务所需的权限。

qc--------------查询服务的配置信息。

qdescription----查询服务的描述信息。

qfailure--------查询失败时服务执行的操作。

qfailureflag----查询服务的失败操作标志。

qsidtype--------查询服务的服务SID类型。

qprivs---------查询服务所需的权限。

qtriggerinfo----查询服务的触发参数。

qpreferrednode -- 查询首选服务 NUMA 节点。

删除----------（从注册表中删除服务）。

create----------创建服务（将其添加到注册表）。

control---------向服务发送控制。

sdshow----------显示服务的安全描述符。

sdset----------设置服务的安全描述符。

showid---------显示与假定名称对应的SID字符串。

triggerinfo-----配置服务的触发参数。

Preferrednode --- 设置首选服务 NUMA 节点。

GetDisplayName--获取服务的DisplayName

GetKeyName------获取服务的ServiceKeyName。

EnumDepend------枚举服务的依赖关系。

以下命令不需要服务名称：

SC

boot------------(ok bad) 表示是否将上次启动保存为

最后一次正确的启动配置

Lock------------锁定服务数据库

QueryLock-----查询SCManager数据库的LockStatus

例子：

sc 启动我的服务

QUERY 和 QUERYEX 选项：

如果查询命令有服务名，则会返回

服务的状态。其他选项不适合此

条件。如果查询命令不带参数或

使用以下选项之一，将枚举该服务。

type= 要枚举的服务类型（驱动程序、服务、全部）

默认=服务）

state = 要枚举的服务状态（非活动、全部）

（默认=活动）

bufsize=枚举缓冲区大小（以字节为单位）

（默认=4096）

ri = 开始枚举的恢复索引号

（默认=0）

group = 要枚举的服务组

（默认=所有组）

语法示例

sc 查询 - 枚举活动服务和驱动程序的状态

sc 查询事件日志 - 显示事件日志服务的状态

sc queryex eventlog - 显示事件日志服务的扩展状态

sc 查询类型= 驱动程序 - 仅枚举活动驱动程序

sc 查询类型= 服务 - 仅枚举 Win32 服务

sc query state= all - 枚举所有服务和驱动程序

sc query bufsize= 50 - 枚举缓冲区为50字节

sc 查询 ri=14 - 枚举时恢复索引=14

sc queryex group="" - 枚举不在组中的活动服务

sc 查询类型 = 交互 - 枚举所有非活动服务

sc 查询类型= 驱动程序组= NDIS - 枚举所有 NDIS 驱动程序

这篇关于win7系统删除Windows服务的操作方法的文章已经讲解到这里了，你学会了吗？ 更多精彩内容欢迎继续关注！