干货分享 | 浅谈软件测试规划及测试用例

大家好，欢迎来到IT知识分享网。

软件测评，你需要知道的“要点”，干货为你备上了！

在开展软件测试前，软件的测试需求、测试用例的准备都是必不可少的！本文简单介绍了软件功能、性能、安全性测试中对于软件测试方向的选取及测试中的关注要点，并且针对软件的测试计划及测试用例的设计、管理、要素等方面进行简单介绍。

一、软件测试规划

1.1 功能测试

1.1.1功能测试方向

功能测试中测试指标需要根据用户需求对业务流程进行数据流向测试，确保关键业务流程正确执行；必须既包括正常输入和正常业务流程测试，也包括对非法数据输入和异常处理的测试，且对系统非正常操作的测试用例一般应占到总数的20%~30%。同时测试内容覆盖全部业务流程。

测试中对系统业务数据进行严格的正确性测试(包括数据是否超出正常值的范围、报表数据准确性等) ，以确保系统即时数据和历史数据准确无误。

测试中需要验证系统实现了全部需求和设计，测试覆盖所有功能点，确保各项功能是可正确执行的；屏幕显示是否规范、准确等，确保业务需求的功能实现。

测试需要重点关注用户经常使用、关系到系统核心功能、优先级别较高的功能点，并在回归测试时应优先执行。

功能测试主要考察应用系统存取访问的安全性及应用软件本身的安全性。确认系统具有防止对程序或数据被非授权访问的能力，主要包括操作安全性、存储安全性、传输安全性以及软件系统防御来自系统内部和外界的窃密、篡改和恶意攻击能力，包括权限管理、日志记录、数据备份与恢复策略等。

1.1.2功能测试主要关注点

（1）业务逻辑：业务逻辑是被测系统实现的核心。只有保障业务逻辑的正确实现才能使系统正常的完成用户的业务操作。

（2）功能逻辑：功能逻辑是被测系统功能模块实现的原理，只有系统的功能逻辑实现完成，才能实现系统的功能操作。

（3）功能输入：功能输入是人机交互界面，只有保障功能输入的正确性和有效性才能保证用户的良好体验。

（4）系统界面：系统界面是人机交互的接口，良好的界面设计才能保障系统的易用性和良好的用户体验。

（5）适合性：系统为制定的任务和用户目标提供一组合适的功能的能力。

（6）准确性：系统提供具有所需精度的正确或相符的结果或效果的能力。

（7）互操作性：系统与一个或更多的规定系统进行交互的能力。

（8）一致性：系统功能及数据实现与用户文档相互符合的能力。

（9）功能保密性：系统为防止对程序或数据被非授权访问而所提供的限制能力。

1.2 性能测试

1.2.1性能测试方向

软件各应用系统的容量，即数据存储能力、存储周期、并发访问量、性能要求，其具体指标可根据《软件需求规格说明书》或《概要设计说明书》确定。

软件的系统时间特性及资源利用特性，其指标需要分析系统用户行为，依据性能需求验证分级部署的应用系统支持高并发处理业务的能力。下面简单列举一些性能测试中的一些选取内容：

（1）系统的关键业务，诸如数据采集、数据同步、数据统计等，具备快速响应能力。

（2）系统数据容量在百万级基础上，响应时间满足用户性能需求。

（3）系统资源利用在合理的数值范围，不超过资源指标的预警值。

（4）测试在大用户量、大并发、大数据量和长时间连续运行等条件下，系统的响应时间和稳定运行情况。这些都是性能测试中需要关注的测试点。

1.2.2性能测试主要关注点

系统的性能表现是评价系统体验的一项重要指标，系统不但要能支撑原有预估用户量的访问，同时也要给用户提供一个良好的性能体验，且资源损耗情况又不能过于严重。针对性能测试，一般依据用户测试需求开展，用户可以从以下几个方向进行：

（1）负载测试：通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以测试和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。

（2）压力测试：压力测试通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大的服务级别的测试。通俗地讲，压力测试是为了发现在什么条件下应用程序的性能会变得不可接受。

极限压力测试举例：

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

②大数据恢复时间；

③大数据导入导出时间；

④大批量录入数据时间；

⑤大数据量的计算时间；

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

⑦采用测试工具软件；

⑧编写测试脚本程序；

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

（3）疲劳强度测试：主要特点是长时间对目标测试系统加压，目的是测试系统的稳定性，持续时间一般在1小时以上；疲劳强度测试属于用户并发测试的延续，因此核心内容仍然是核心模块用户并发和组合模块用户并发。

（4）大容量测试：主要针对数据库有特殊要求的系统进行的测试，如系统的入库查询业务；可以分为实时大数据量，主要目的是测试用户较多或者某些业务产生较大数据量时，系统能否稳定运行；测试系统在极限状态下使用一段时间即系统累计一定量的数据时能否正常运行业务；大数据量测试可以分为两种类型：一种针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试；一种是与压力性能测试、负载性能测试、疲劳强度性能测试相结合的综合数据量测试方案。

1.3 安全性测试

1.3.1测试指标确定

安全性测试具体测试执行根据用户软件测试需求执行，根据需求要求确定具体测试值表及其测试方法。

（1）信息收集：信息收集分析是所有入侵攻击的前提/前奏/基础。通过对网络信息收集分析，可以相应地、有针对性地制定模拟黑客入侵攻击的计划，以提高入侵的成功率、减小暴露或被发现的几率。信息收集的方法包括主机网络扫描、操作类型判别、应用判别、账号扫描、配置判别等等。

（2）端口扫描：通过对目标地址的TCP/UDP端口扫描，确定其所开放的服务的数量和类型，这是所有渗透测试的基础。通过端口扫描，可以基本确定一个系统的基本信息，结合测试人员的经验可以确定其可能存在，以及被利用的安全弱点，为进行深层次的渗透提供依据。

（3）权限提升：通过收集信息和分析，存在两种可能性，其一是目标系统存在重大弱点：测试人员可以直接控制目标系统，然后直接调查目标系统中的弱点分布、原因，形成最终的测试报告；其二是目标系统没有远程重大弱点，但是可以获得远程普通权限，这时测试人员可以通过该普通权限进一步收集目标系统信息。接下来，尽最大努力获取本地权限，收集本地资料信息，寻求本地权限升级的机会。这些不停的信息收集分析、权限升级的结果将构成此次项目整个渗透测试过程的输出。

（4）不同网段/Vlan之间的渗透：这种渗透方式是从某内/外部网段，尝试对另一网段/Vlan进行渗透。这类测试通常可能用到的技术包括：对网络设备和无线设备的远程攻击；对防火墙的远程攻击或规则探测、规避尝试。信息的收集和分析伴随着每一个渗透测试步骤，每一个步骤又有三个组成部分：操作、响应和结果分析。

（5）溢出测试：当测试人员无法直接利用帐户口令登录系统时，也会采用系统溢出的方法直接获得系统控制权限，此方法有时会导致系统死机或重新启动，但不会导致系统数据丢失，如出现死机等故障，只要将系统重新启动并开启原有服务即可。一般情况下，如果未授权，将不会进行此项测试！

（6）WEB应用测试：Web脚本及应用测试专门针对Web及数据库服务器进行。根据最新的统计，脚本安全弱点为当前Web系统，尤其是存在动态内容的Web系统比较严重的安全弱点之一。利用脚本相关弱点轻则可以获取系统其他目录的访问权限，重则将有可能取得系统的控制权限。因此对于含有动态页面的Web、数据库等系统，Web脚本及应用测试将是必不可少的一个环节。在Web脚本及应用测试中，可能需要检查的部分包括：

①检查应用系统架构，防止用户绕过系统直接修改数据库；

②检查身份认证模块，用以防止非法用户绕过身份认证；

③检查数据库接口模块，用以防止用户获取系统权限；

④检查文件接口模块，防止用户获取系统文件；

⑤检查其他安全威胁；

（7）SQL注入攻击：SQL注入常见于应用了SQL数据库后端的网站服务器，入侵者通过提交某些特殊SQL语句，最终可能获取、篡改、控制网站服务器端数据库中的内容。此类漏洞是入侵者最常用的入侵方式之一。

（8）检测页面隐藏字段：网站应用系统常采用隐藏字段存储信息。许多基于网站的电子商务应用程序用隐藏字段来存储商品价格、用户名、密码等敏感内容。恶意用户通过操作隐藏字段内容达到恶意交易和窃取信息等行为，是一种非常危险的漏洞。

（9）跨站攻击：入侵者可以借助网站来攻击访问此网站的终端用户，来获得用户口令或使用站点挂马来控制客户端。

（10）Cookie利用：网站应用系统常使用cookies机制在客户端主机上保存某些信息，例如用户ID、口令、时戳等。入侵者可能通过篡改cookies内容，获取用户的账号，导致严重的后果。

（11）后门程序检查：系统开发过程中遗留的后门和调试选项可能被入侵者所利用，导致入侵者轻易地从捷径实施攻击。

（12）第三方软件误配置：第三方软件的错误设置可能导致入侵者利用该漏洞构造不同类型的入侵攻击。

（13）其他测试：在渗透测试中还需要借助暴力激活成功教程、网络嗅探等其他方法，目的也是为获取用户名及密码。

1.3.2安全性测试主要关注点

在对被测系统进行安全测试中，对于安全性和访问控制的两个关键要求：

（1）应用程序级别的安全性，包括对数据或业务功能的访问。

（2）系统级别的安全性，包括对系统的登录或远程访问。

应用程序级别的安全性，确保在预期的安全性情况下，用户只能访问特定的功能或用例，或者只能访问有限的数据。系统级别的安全性，确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。通常情况下，利用工具扫描系统应考虑两个方面的问题：主机的安全性：远程服务类型、操作系统类型及版本、弱口令漏洞、后门、应用服务漏洞、网络设备漏洞、拒绝服务漏洞等。应用的安全性：防会话标志更新攻击、防跨站点脚本编制攻击、防格式字符串攻击、防SQL注入、防目录索引、防信息泄露、防路径遍历、防潜在文件上载以及系统后门等。

二、软件测试策略及用例规划

2.1测试策略

2.1.1功能测试

依据软件需求说明书和相关技术文档的技术要求，结合用户对系统整体应用方向，对系统涉及到的所有业务逻辑、功能逻辑、功能项的全覆盖测试，采用等价类划分方法、边界值分析方法、错误推测方法、场景法等用例设计方法设计用例和执行功能测试。

2.1.2 性能效率测试

通过站在用户体验的角度，使用专业的负载生成设备，在性能模型的基础上验证系统是否能够达到用户提出的性能指标，是否符合用户文档中对系统设计时的性能关注点。在系统正常交互量及峰值交互量的情况下发现系统中存在的性能瓶颈，最后达到优化系统的目的。

2.1.3 可靠性测试

根据软件系统可靠性结构、寿命类型和可靠性试验信息，利用概率统计方法，评估出系统的可靠性特征量。通过可靠性测试可验证软件系统在规定的时间内以及规定的环境条件下，完成规定功能的能力。

2.1.4 维护性测试

通过监控软件和维护措施，监控运行状态和故障诊断能力，验证通过维护向导或监控指标快速判断故障发生点，根据历史故障确定系统维护性遵循易分析性、易定位、易修复性和可测试性。

2.1.5 可移植性测试

根据系统运行的环境要求，在不同操作系统平台、不同数据库平台、不同中间件平台及各种硬件设备、支撑软件等实施系统部署，举证系统具备良好移植性和兼容性。

2.2 制定测试计划

根据系统整体的建设周期制定整个项目的测试计划，根据制定的测试计划科学、合理分配测试任务，推进测试工作，具体包含：

（1）识别项目测试活动，定义输出成果，估算每项活动所需的时间；

（2）识别项目延期风险，并确定应对策略；

（3）综合相关内容，确定阶段里程碑，并形成详细测试计划；

（4）对测试计划进行评审、修改，直至测试计划获得批准；

（5）将测试计划分发给各测试组，分配测试任务；

（6）定期汇报测试任务完成情况，跟踪计划推进进度。

2.3 测试用例库

在针对大型软件测试项目时，应用系统功能点繁多，测试实施过程中会设计和开发大量测试用例和脚本。在实际项目中，测试用例是测试工作的核心，是测试执行环节的基本依据，经常因为管理不善和设计盲目，使得用例库庞大而且难以维护，测试脚本管理繁杂，并且成了测试人员的负担，增加测试执行人的工作劳动强度，测试效率低下。

为此，测试实施过程中的需要和应用系统后期维护升级的测试需要，拟规划测试用例库建设目标：构建高质量的可重用测试用例，建成系统基准测试用例库。具体可体现在以下几个方面：

（1）采用专业、成熟的管理平台，对测试用例库和脚本实施管理；

（2）建立测试用例的标准模板，可分为自动化类，手工类；

（3）归类用例，对共用模块建立用例集，形成公共用例库，共享用例；

（4）所有的测试用例按标准编写，归入测试用例总库；

（5）测试用例经测试执行、反馈、修改后分别进入子库公用测试用例库、专用测试用例库(针对特殊需求、个别应用)；

（6）用例库的建设是一个积累的过程，需不停地维护，期间要进行增加、删除、修改等操作，以维护测试用例库的完整性，提高测试用例库的可用性，提升测试用例库的效率和效用。

2.4测试用例设计与管理

测试用例的设计需要依据软件需求规格说明中的功能需求、数据需求，利用测试计划中所规定的测试方法和策略，按测试目标对每一个测试点分别设计在不同情况下的测试动作、输入数据和预期结果。

依据软件需求规格说明中的非功能需求，制定相关验收项，分别针对系统可靠性、效率、维护性、可移植性测试用例。

设计测试用例的过程中，测试人员将尽可能的与开发人员、产品设计人员实时沟通，不断加深对测试系统的理解，对软件的结构层次、数据流程或操作流程进行分析。借助等价类、边界值、错误推测方法设计测试用例。具体应遵循以下规则：

（1）全面性，测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，确保功能覆盖全面无遗漏；

（2）正确性，正确输入用户实际数据或模拟生产数据，以验证系统是否满足需求规格说明书的要求，确保系统正确实现了需求功能；

（3）异常处理能力，设计的测试用例除对测试点本身正确的测试外，还需考虑用户实际使用的情况、与其它部分关联使用的情况、非正常情况(业务逻辑不合理、操作或输入数据非法、数据越界以及极限输入数据、特殊字符)操作和环境设置等；

（4）用例设计应考虑到业务的扩展应用、特殊业务规则以及服务异常中断等；

（5）综合分析系统应用，系统功能优先级高的优先设计用例，并且优先执行测试；

（6）回归测试中，先运行曾经发现缺陷的测试用例，然后再运行从来没有发现缺陷的测试用例，回归测试做到用例全覆盖；

（7）测试用例应包含多种元素，能够指导测试的执行和明确测试执行环境。

2.5测试用例要素

软件名称：被测项目的名称，写明该用例归属于哪个软件目。

编号/版本：被测项目的编号或版本号，用于区分同一软件的不同版本。

模块名称：指出本用例用于哪个功能模块，也可根据软件的菜单项进行划分。

功能特性：指出被测功能的特性及其所能实现的目标。

预置条件：需要在执行测试用例之前完成的操作，如运行软件，打开页面等。

用例编号：用来标识用例的唯一编号。编号根据公司的编号规范制定。

参考信息：用于指出该用例参考了哪些文档，记录下来它们的名称、章节号和功能项。

用例说明：描述实现用例需要执行的操作步骤。

输入数据：规定执行测试用例所需的数据或条件。

预期结果：表明执行测试用例后应该得出的结果。

环境要求：注明执行本条测试用例需要具备的软、硬件和网络环境。

特殊规程要求：描述对执行本测试用例的测试规程的一切特殊限制。

用例间的依赖关系：也称之为“相关用例”。列出必须在本测试用例之前执行的测试用例名称，归纳依赖性质。

测试结果：本测试用例执行完毕后的实际结果与预期结果相比较，说明测试用例是否通过。

缺陷编号：如果本测试用例没有通过，就要马上作缺陷记录，提交缺陷报告，得到编号并记录下来，便于日后跟踪。

2.6测试用例设计原则

（1）测试用例的代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。

（2）测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。

（3）测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。

2.7测试用例设计过程

（1）软件需求分析：测试需求应该在软件需求基础上进行归纳、分类或细分，方便测试用例设计。

（2）业务流程分析：进行测试用例设计前，先熟悉软件的业务流程。业务流程图可以帮助理解软件的处理逻辑和数据流向，从而指导测试用例的设计。

（3）测试用例设计：在用例设计中，除了功能测试用例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。

（4）测试用例评审：测试用例设计完成后，为了确认测试过程和方法是否正确，是否有遗漏的测试点，需要进行测试用例的评审。

（5）测试用例完善：测试用例编写完成后需要根据软件产品的不断变化不断更新和完善。

（6）测试用例维护：测试用例的维护是一个不间断的过程，通常可以将软件开发的基线作为基准，维护的主要内容包括删除无用的测试用例、修改测试用例和新增测试用例。

2.8测试用例设计方法

测试用例的设计可以采用等价类分析方法、边界值分析方法、因果图分析方法、错误推断法、功能图分析方法、用例场景分析法等。

三、总结

以上就是关于软件测试中功能、性能、安全测试，以及测试用例等方面的简单介绍，欢迎大家一起交流学习哦。