0.认识需求
1.业务需求:组织或客户的高层次目标、描述为什么要开发系统(Why),希望达到什么样的目标、一般2-5条,记录在《软件愿景和范围》文档中。
2.用户需求:从用户角度,描述用户使用产品必须要完成什么任务;用户能使用系统来做什么(What);通过用户访谈、调查、对用户使用场景进行整理等方法获取。
3.功能需求:描述开发人员在产品中实现的软件功能,描述开发人员如何设计具体的解决方案来实现这些需求(how),数量往往比用户需求高一个数量级,属于《软件需求规格说明书》的一部分。
<0>软件需求规格说明书
其包括:
功能需求:
1.用户需求
2.系统需求:用于描述包含多个子系统的产品(即系统)的顶级需求,它是从系统实现的角度描述的需求,有时还需要考虑相关的硬件、环境方面的需求。
3.业务规则:业务规划本身并非软件需求,因为它们不属于任何特定软件系统的范围。然而,业务规则常常会限制谁能够执行某些特定用例,或者规定系统为符合相关规则必须实现某些特定功能。它包括企业方针、政府条例、工业标准、会计准则和计算方法等。有时,功能中特定的质量属性(通过功能实现)也源于业务规则。所以,对某些功能需求进行追溯时,会发现其来源正是一条特定的业务规则。
非功能需求:
1.质量属性:产品必须具备的属性或品质。系统的质量属性包括可用性、可修改、性能、安全性、可测试行、易用性等。
2.约束:也称为限制条件、补充规约,通常是对解决方案的一些约束说明。
3.外部接口
测试需求与软件需求密切相关。测试需求分析的主要输入是软件需求规格说明书。测试需求是解决“测什么”的问题,是整个测试项目的基础,是制定测试计划、开发测试用例的依据。测试需求必须是可以核实的,它们必须有一个可观察、可评测的结果。
明确测试范围既是功能点,明确功能处理过程包括单功能点与业务场景组合。
1.准备工作
软件测试是一项系统性工程,从不同的角度考虑可以有不同的划分方法,了解各种不同的测试分类,能更好地理解测试、开展测试。
<0>测试分类
根据测试阶段进行划分:依据软件测试流程中各个阶段要开展的测试来划分,包括单元测试、模块测试、集成测试、系统测试、验收测试等。
根据是否执行被测对象进行划分,按照是否需要执行被测软件的角度可分为静态测试和动态测试。静态测试不运行被测软件,比如需求文档评审、设计文档评审、代码走查等。动态测试则通过运行被测试软件开展测试。
根据是否使用工具划分,根据测试是手工执行的还是工具执行的可以分为手工测试和自动化测试,一般情况下性能测试用自动化测试方式。
根据测试技术划分,根据测试技术可以划分为黑盒测试、白盒测试和灰盒测试。白盒测试通过对程序内部结构的分析、检测来寻找问题。黑盒测试通过软件的外部表现来发现其缺陷和错误。灰盒测试是介于白盒测试和黑盒测试之间的测试,灰盒测试不仅关注输出、输入的正确性,同时也关注程序内部的情况。灰盒测试不像白盒测试那么详细、完整,但又比黑盒测试更关注程序的内部逻辑,常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。
根据测试类型划分,测试类型是从不同的角度来分析和测试产品,测试类型概念很早就已经存在,比如:性能测试、安全性测试、功能测试、兼容性测试等等。
软件测试类型是从不同的角度有针对性地来分析和测试产品。软件测试执行阶段是由一系列不同的测试类型的执行过程组成的,每种测试类型都有其具体的测试目标和支持技术,每种测试类型都只侧重于对测试目标的一个或多个特征或属性进行测试,准确的测试类型可以给软件测试带事半功倍的效果。
软件测试类型是从不同的角度有针对性地来分析和测试产品。软件测试执行阶段是由一系列不同的测试类型的执行过程组成的,每种测试类型都有其具体的测试目标和支持技术,每种测试类型都只侧重于对测试目标的一个或多个特征或属性进行测试,准确的测试类型可以给软件测试带事半功倍的效果。
编号 |
测试类型 |
测试角度 |
1 |
功能性测试 |
是对产品的各功能进行验证,根据功能需求逐项测试,检查产品是否达到用户要求的功能。 |
2 |
兼容性测试 |
测试软件在特定的硬件平台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能够正常的运行 |
3 |
安全性测试 |
针对未授权的访问,拒绝访问攻击等,一般包括程序、网络、数据库安全性测试。 |
4 |
接口测试 |
测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。 |
5 |
数据库完整性测试 |
该项测试内容主要是以数据库表为单位,检查数据库表以及表中各字段命名是否符合命名规范,表中字段是否完整,数据库表中的字段描述是否正确包括字段的类型、长度、是否为空,数据库表中的关系、索引、主键、约束是否正确。 |
6 |
用户界面测试 |
即UI测试,测试用户界面的功能模块的布局是否合理,整体风格是否一致,各个控件的放置位置是否符合客户使用习惯,操作是否便捷,导航是否简单易懂,界面文字是否正确,命名是否统一,页面是否美观,文字、图片组合是否合适等等。除此之外,UI 测试还要确保 UI 功能内部的对象符合预期要求,并遵循公司或行业的标准。 |
7 |
负载测试 |
负载测试是通过改变系统负载方式、增加负载等来发现系统中所存在的性能问题。负载测试更多的是一种测试方法,而不是测试类型,可以为性能测试、压力测试所采用。负载测试的加载方式也有很多种,可以根据测试需要来选择。 |
8 |
性能测试 |
性能测试是为获取或验证系统性能指标而进行测试。多数情况下,性能测试会在不同负载情况下进行。性能指标主要有:系统吞吐量、响应速度、cpu占用率、内存占用率等。 |
9 |
压力测试 |
压力测试通常是在高负载情况下来对系统的稳定性进行测试,更有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等。 |
10 |
疲劳强度测试 |
通过长时间运行系统,测试系统的性能,发现性能问题。一般会测试系统的日常业务(正常情况)和高峰业务(最大业务量)情况下长时间运行系统的结果。 |
11 |
恢复性测试 |
测试一个系统从灾难或出错中能否很好地恢复的过程,如遇到系统崩溃、硬件损坏或其他灾难性出错。可恢复测试一般是通过人为的各种强制性手段让软件或硬件出现故障,然后检测系统是否能正确的恢复(自动恢复和人工恢复)。 |
12 |
配置测试 |
一般是针对硬件配置的测试,测试软件在最低配置和推荐配置情况下是否能够正常运行。 |
13 |
安装卸载测试 |
确保软件在正常情况和异常情况的不同条件下,都能正确地完成安装和卸载。 例如,进行首次安装、升级、完整的或自定义的安装。 |
14 |
用户文档测试 |
软件文档是软件的一部分,要确保文档能够给用户提供正确的说明或指引,重点关注文档的正确性、完备性以及可理解性。交给用户的文档主要有:系统帮助、用户使用手册、用户安装手册、示例以及模板、图像声音帮助、用户许可协议等。 |
15 |
可用性测试(易用性测试) |
让一群具有代表性的用户对产品进行典型操作,同时观察员和开发人员在一旁观察,聆听,做记录。 可用性有五个指标,分别是易学性、易记性、容错性、交互效率和用户满意度。 |
16 |
稳定性测试(可靠性测试) |
稳定性测试(亦可称可靠性测试)通过给系统加载一定的业务压力,让系统持续运行一段时间(一般为7x24小时),检测系统是否能够稳定运行。 |
17 |
内存泄漏测试 |
内存泄漏是指用动态存储分配函数动态开辟的空间,在使用完毕后未释放,结果导致一直占据该内存单元,直到程序结束。内存泄漏测试就是测试有没有内存空间使用完毕之后未回收的情况,一般用专门的检测工具。 |
18 |
本地化测试 |
也称为国际化测试,有些产品为了满足特定区域用户的需要有多个语言版本,比如简体中文、繁体中文、英文、日文等,本地化测试是针对特定目标区域性或区域设置的产品进行测试,在本地化的软硬件环境下测试界面、安装卸载等内容,也要关注产品目标地区的文化、宗教、喜好等适用性测试。 |
测试类型是指功能测试、性能测试、安全性测试等等,实际实践:不同类型的测试会发现不同类型的Bug;测试类型是从不同的角度来分析和测试产品;不同产品对应的测试类型集合可能不同;不同测试类型的测试方法不同;不同测试阶段其测试类型不同;一般做法:测试团队根据产品特点建立测试类型库;如果没有自己的测试类型库可以参考质量特性与测试类型的对应关系表;在测试类型分析中分析并列出测试需求项需要哪些类型的测试.
2.分析步骤
<0>需求收集注意事项
广泛、全面、结合具体的产品背景、团队管理水平、测试阶段有针对性的收集
<1>测试需求可能的来源
用户需求;系统开发需求;产品愿景;产品设计说明书;同类竞争产品及其说明书;旧产品及其说明书:如果是产品升级换代的情形;相关的协议和规范:如果产品要符合某种规范则要将协议和规范包含在需求范围内,比如儿童手机对辐射度的规范要求。
来源编号 |
原始需求来源 |
文档名称 |
备注 |
1 |
用户需求 |
用户需求规格说明书_作业管理系统.doc |
|
2 |
开发需求 |
系统需求规格说明书_作业管理系统.doc |
|
|
|
|
|
|
|
|
|
概要需求整理:对被测对象有一个整体的把握;满足短时间内给出测试计划的需要;方便分配任务进行详细需求的整理
产品功能不是独立的,功能之间存在交互关系;为了提高测试的完备性,要对需求与需求之间的关系进行分析。
测试需求分析完成后,为了方便后续对测试需求的跟踪和维护需要建立测试需求跟踪矩阵。测试需求跟踪矩阵记录软件需求到测试需求的分解以及测试项到测试用例的分解。
测试需求跟踪矩阵应该记录的主要内容:软件需求到测试需求的分解;测试需求项;后续跟进测试需求向测试用例的分解.n实际项目中可以根据需要扩充测试需求的属性,比如测试需求的优先级、测试需求的测试类型等等。
测试需求跟踪矩阵需要不断的维护。一方面,软件需求一旦发生变化,应启动配置管理过程,将与软件需求变更相关的内容进行同步变更;另一方面,随着测试工作的进行,会不断添加新的跟踪内容,对跟踪表进行扩展。例如,测试设计阶段的测试用例、测试执行阶段的测试记录和测试缺陷都可以添加到跟踪矩阵中。
来源:CSDN
作者:光电的一只菜鸡
链接:https://blog.csdn.net/qq_35789421/article/details/104214662