软件测试的基本流程
软件测试和软件开发一样,是一个比较复杂的工作过程,如果无章法可循,随意进行测试势必会造成测试工作的混乱。为了使测试工作标准化、规范化,并且快速、高效、高质量的完成测试工作,需要制订完整且具体的测试流程。

软件测试的流程
不同类型的软件产品测试的方式和重点不一样,测试流程也会不一样。同样类型的软件产品,不同公司所指定的测试流程也会不一样。虽然不同软件的详细测试步骤不同,但它们所遵循的最基本的测试流程是一样的:分析测试需求-制定测试计划-设计测试用例-执行测试-编写测试报告。下面对软件测试基本流程进行简单介绍。
(1)分析测试需求
测试人员在制订测试计划之前需要先对软件需求进行分析,以便对要开发的软件产品有个清晰的人认识,从而明确测试对象及测试工作的范围和测试重点。
在分析测试需求时还可以获取一些测试数据,作为测试计划的基本依据,为后续的测试打好基础。
测试需求分析其实也就是对软件需求进行测试,测试人员可以发现软件需求中不合理的地方,如需求描述是否完整,准确无歧义,需求优先级安排是否合理等。测试人员一般会根据软件开发需求文档制作一个软件需求规格说明书检查列表,按照各个检查项对软件需求进行分析校验如图所示

上表列出了需要对软件需求进行什么样的检查,测试人员按照检查项逐条检查和判断,如果满足要求则选择【是】,如果不满足要求则选择【否】,如果某个检查项不适用则选择【NA】。表1-3只是一个通用的软件需求规格说明检查列表,在实际测试中,要根据具体的测试项目进行适当的增减或修改。

在分析测试需求时要注意,被确定的测试需求必须是可核实的,测试需求必须有一个可观察,可评测的结果。无法核实的需求就不是测试需求。测试需求分析还要和客户进行交流,以澄清某些混淆,确保测试人员与客户尽早地对项目达成共识。

(2)指定测试计划
测试工作贯穿于整个软件开发生命周期,是一项庞大而复杂地工作,需要制定一个完整且详细地测试计划作为指导。测试计划是整个测试工作地导航图,但它并不是一成不变的,随着项目推进或需求变更,测试计划也会不断发生改变,因此测试计划的制定是随着项目发展不断调整,逐步完善的过程。
测试计划一般要做好以下工作安排。
①确定测试范围:明确哪些对象是需要测试的,哪些对象不是需要测试的。
②制定测试策略:测试策略是测试计划中最重要的部分,它将要测试的内容划分出不同的优先级,并确定测试重点。根据测试模块的特点和测试类型(如功能测试,性能测试)选定测试环境和测试方法(如人工测试、自动化测试)。
③安排测试资源:通过衡量测试难度、时间、工作量等因素对测试资源进行合理安排,包括人员分配、工具配置等。
④安排测试进度:根据软件开发计划、产品的整体计划来安排测试工作的进度,同时还要考虑各部分工作的变化。在安排工作进度时,最好在各项测试工作之间预留一个缓冲时间以应对计划变更。
⑤预估测试风险:罗列出测试工作过程中可能会出现的不确定因素,并制定应对策略。

(3)设计测试用例
测试用例(Test Case)指的是一套详细的测试方案,包括测试环境、测试步骤、测试数据和预期结果。不同的公司会有不同的测试用例模板,虽然它们在风格和样式上有所不同,但本质上是一样的,都包括了测试用例的基本要素。
测试用例编写的原则是尽量以最少的测试用例达到最大测试覆盖率。测试用例常用的设计方法包括等价类划分、边界值分析法、因果图与判定表法、正交实验设计法、逻辑覆盖法等,这些设计方法在后面的章节中会陆续交接。

(4)执行测试
执行测试就是按照测试用例进行测试的过程,这是测试人员最主要的活动阶段。在执行测试时要根据测试用例的优先级进行。测试执行过程看似简单,只要按照测试用例完成测试工作即可,但实则并不是如此。测试用例的数目非常多,测试人员需要完成所有测试用例的执行,每个测试用例都可能会发现很多缺陷,测试人员要做好测试记录与跟踪,衡量缺陷的质量并编写缺陷报告。

当提交后的缺陷被开发人员修改之后,测试人员需要进行回归测试。如果系统对测试用例产生了缺陷免疫,测试人员则需要编写新的测试用例。在单元测试、集成测试、系统测试、验收测试各个阶段都要进行功能测试、性能测试等,这个工作量无疑是巨大的。除此之外,测试人员还需要对文档资料,如用户手册,安装手册,使用说明等进行测试。因此不要简单的认为执行测试就是按部就班地完成任务,可以说这个阶段是测试人员最重要地工作阶段。

(5)编写测试报告
测试报告是对一个测试活动地总结,对项目测试过程进行归纳,对测试数据进行统计,对项目地测试质量进行客观评价。不同公司的测试报告模板虽不相同,但测试报告编写的要点都是一样的,一般都是先对软件进行简单介绍,然后说明这份报告是对该产品的测试过程进行总结,对测试质量进行评价。
一份完整的测试报告必须包含以下几个要点。
引言:描述测试报告编写目的、报告中出现的专业术语解释及参考资料等。
测试概要:介绍项目背景、测试时间、测试地点及测试人员等信息。
测试内容及执行情况:描述本地测试模块的版本,测试类型,使用的测试用例设计方法及测试通过覆盖率,依据测试的通过情况提供对测试执行过程的评估结论,并给出测试执行活动的改进建议,以供后续测试执行活动借鉴参考。
缺陷统计与分析:统计本次测试所发现的缺陷数目、类型等,分析缺陷产生的原因,给出规避措施等建议,同时还要记录残留缺陷与为解决问题。
测试结论与建议:从需求符合度、功能正确性、性能指标等多个维度对版本质量进行总体评价,给出具体明确的结论。
测试报告的数据是真实的,每一条结论的得出都要有评价依据,不能是主观臆断的。

测试的准入准出
测试的准入住处是指什么情况下可以开始当前版本的测试工作,什么情况下可以结束当前版本的测试工作。不同项目、不同公司的测试准入准出标准都会有所不同。下面介绍一些通用的测试准入准出标准。
测试准入标准如下:
(1)开发编码结束,开发人员在开发环境中已经进行了单元测试,即开发人员完成自测。
(2)软件需求上规定的功能都已经实现。如果没有完全实现,开发人员提供测试范围。
(3)测试项目通过基本的冒烟测试,界面上的功能均已经实现,符合设计规定的功能。
(4)被测试项目的代码符合软件编码规范并已通过评审。
(5)开发人员提交了测试申请并提供了相应的文档资料。
测试准出如下:
(1)测试项目满足客户需求。
(2)所有测试用例都已经通过评审并成功执行。
(3)测试覆盖率已经达到要求。
(4)所有发现的缺陷都记录在缺陷管理系统。
(5)一、二级错误修复率达到100%。
(6)三、四级错误修复率达到了95%。
(7)所有遗留问题都有解决方案
(8)测试项目的功能、性能、安全性等都满足要求。
(9)完成系统测试总结报告。
有时,在测试过程中可能会出现一些意外情况导致测试工作暂停,这个暂停并不是上述所说的测试结束,而是非正常的。测试中需要暂停的情况包括以下几种。
(1)测试人员进行冒烟测试时发现重大缺陷,导致测试无法正常进行,需要暂停并返回开发。
(2)测试人员进行冒烟测试时发现Bug过多,可以申请暂停测试,返回开发。
(3)测试项目需要更新调整而暂停,测试共奏也要相应暂停。
(4)如果测试人员有其它优先级更高的任务,可以申请暂停测试。

版权声明:本文为R-bear原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/R-bear/p/14969448.html