AI智能应用开发
AI大模型开发（Python）
AI鸿蒙开发
AI嵌入式+机器人开发
AI运维
AI测试
跨境电商运营
AI设计
AI视频创作与直播运营
微短剧拍摄剪辑
C/C++
狂野架构师
热门课程
- AI智能应用开发
- AI大模型开发（Python）
- AI鸿蒙开发
- AI嵌入式+机器人开发
- AI运维
- AI测试
- 跨境电商运营
- AI设计
- AI视频创作与直播运营
- 微短剧拍摄剪辑
- AI大数据开发
- 前端开发
- C/C++
- 狂野架构师
软件测试的流程都有那些？
更新时间:2019年03月20日13时45分 来源:网络 浏览次数:
全程软件测试，强调整个软件生命周期中，各阶段的测试活动。无论是需求阶段，开发阶段，还是测试阶段，都需要确定在当前阶段测试活动的内容以及成都，确保每个阶段的质量，才能保证产品最终的质量。
全程软件测试图解
具体执行如下：
缺陷处理流程图
全程软件测试图解
根据全程软件测试的时间轴线图，我们可以发现测试活动贯穿软件开发的整个生命周期，各个阶段测试活动内容如下：
那每个测试活动又到底是如何进行的？需要用的哪些技能或者方法呢？
需求阶段
一、测试需求分析
我个人一直认为需求分析是整个测试活动中除了测试用例设计之外最重要的部分。
需求分析目的是理解需求，理解业务。
弄清楚我们的产品有哪些功能？有哪些非功能性需求？
明白我们的用户群体是什么？用户会如何来使用我们的产品？
那我们到底该怎么来进行需求分析呢？
需求阶段
一、测试需求分析
我个人一直认为需求分析是整个测试活动中除了测试用例设计之外最重要的部分。
需求分析目的是理解需求，理解业务。
弄清楚我们的产品有哪些功能？有哪些非功能性需求？
明白我们的用户群体是什么？用户会如何来使用我们的产品？
那我们到底该怎么来进行需求分析呢？
具体执行如下：
二、测试计划制定
当对需求有完整和全面的理解后，接下来我们需要制定详细的测试计划，为即将开始的测试工作做好充足的准备。对于测试计划的理解，我一直分为两种工作规模去看（个人理解，不正确的地方还请见谅）小公司团队
小公司测试团队可能本身都没几个人，按照传统理论需要考虑测试活动中各方面的问题，给人的感觉就像杀鸡用3米长的大砍刀一样。
我的理解是小团队的测试计划讲清楚以下四个要素就行。
时间：根据以往经验以及需求理解进行时间估算（小建议：时间节点多争取1到2天时间缓冲，项目过程中难免出现意外事件）任务：将测试活动拆分成具体的任务
人：任务的执行人以及质量监控负责人
风险控制
大作坊团队
大公司测试团队往往是涉及多个项目，整个公司的硬件、时间、人力等资源的分配就更为复杂。在这种情况下，需要对各方面有更为精细的计划。
资源估算：整个项目需要多少资源？硬件资源，人力、时间资源等进度控制：每个测试活动时间点控制
风险控制：对于在测试活动过程中出现问题的解决方案资源配置：如何更有效率的使用资源
验收标准：文档、项目、测试过程的验收标准定义
测试策略：测试中使用的测试策略
小结：
在需求分析阶段，测试人员既要详细的理解产品需要，又要从用户的角度出发，分析出需求中不完善的地方，还要协调开发与测试对于需求理解的一致性，保证需求信息在开发和测试双方中的统一。
这也就是尽早的将产品缺陷给暴露出来，也会有效的预防缺陷。
开发阶段
在经过需求阶段的准备工作后，进入开发阶段就意味着撸起袖子加油干的时候。开发阶段对于软件生命周期而言是最重要的阶段。那在这个阶段，又是如何开展测试活动的呢？
一、测试用例设计
测试用例设计是软件测试工作的灵魂。
任何一项测试活动的核心都是测试思维，即如何进行测试。而测试用例就是测试思维的体现。功能的测试优先级、如何操作、输入什么数据、应该有什么的结果等等都体现在测试用例中。那么问题来了 到底怎么设计测试用例呢？
（由于篇幅原因，这次我主要介绍一下接口测试用例设计方法） 首先，我们来看一看接口的执行过程。
当对需求有完整和全面的理解后，接下来我们需要制定详细的测试计划，为即将开始的测试工作做好充足的准备。对于测试计划的理解，我一直分为两种工作规模去看（个人理解，不正确的地方还请见谅）小公司团队
小公司测试团队可能本身都没几个人，按照传统理论需要考虑测试活动中各方面的问题，给人的感觉就像杀鸡用3米长的大砍刀一样。
我的理解是小团队的测试计划讲清楚以下四个要素就行。
时间：根据以往经验以及需求理解进行时间估算（小建议：时间节点多争取1到2天时间缓冲，项目过程中难免出现意外事件）任务：将测试活动拆分成具体的任务
人：任务的执行人以及质量监控负责人
风险控制
大作坊团队
大公司测试团队往往是涉及多个项目，整个公司的硬件、时间、人力等资源的分配就更为复杂。在这种情况下，需要对各方面有更为精细的计划。
资源估算：整个项目需要多少资源？硬件资源，人力、时间资源等进度控制：每个测试活动时间点控制
风险控制：对于在测试活动过程中出现问题的解决方案资源配置：如何更有效率的使用资源
验收标准：文档、项目、测试过程的验收标准定义
测试策略：测试中使用的测试策略
小结：
在需求分析阶段，测试人员既要详细的理解产品需要，又要从用户的角度出发，分析出需求中不完善的地方，还要协调开发与测试对于需求理解的一致性，保证需求信息在开发和测试双方中的统一。
这也就是尽早的将产品缺陷给暴露出来，也会有效的预防缺陷。
开发阶段
在经过需求阶段的准备工作后，进入开发阶段就意味着撸起袖子加油干的时候。开发阶段对于软件生命周期而言是最重要的阶段。那在这个阶段，又是如何开展测试活动的呢？
一、测试用例设计
测试用例设计是软件测试工作的灵魂。
任何一项测试活动的核心都是测试思维，即如何进行测试。而测试用例就是测试思维的体现。功能的测试优先级、如何操作、输入什么数据、应该有什么的结果等等都体现在测试用例中。那么问题来了 到底怎么设计测试用例呢？
（由于篇幅原因，这次我主要介绍一下接口测试用例设计方法） 首先，我们来看一看接口的执行过程。
任何一个接口其实都由这三部分构成，那我们在设计测试用例时就可以根据这方面进行考虑。
针对接口的输入条件进行设计：
针对接口的输入条件进行设计：
针对接口的处理逻辑进行设计：
针对输出结果设计：
其他方面考虑：
接口超时处理
废弃接口处理
二、测试用例评审
测试用例的评审无疑是为了给测试用例进行查漏补缺。
评审方式：
测试内部评审
项目组评审：项目相关人参与评审（开发、测试、产品）注意：
项目组评审时，一般是会议的形式，由于测试用例的数量关系，会议上评审会占用很长的时间，造成时间资源的浪费。
建议大家在评审前先将测试用例邮件发送给评审会议相关人，让他们提前能对测试用例进行了解，熟悉。会议中进行反�。锹己�，会后再修改。
三、测试执行
前面的工作做的充足的话，在测试执行的时候就会非常简单了。只需要根据测试用例一条一条去执行程序即可。发现缺陷就提交缺陷，测试通过就继续回归。
各位看官现在应该是心里一万个XXX呼啸而过～～哪有说的那么简单。
其实测试执行的过程真的很简单，只是在执行的过程中各部门的协作，沟通以及各项文档的输出很复杂。下面我们来聊聊在测试执行过程要注意的几方面问题。
1、测试与开发的沟通
“XXX 我这有个问题，你过来看下”
“什么问题？你演示下我看看”
“这不是问题，这个地方只能这样做”或者 “这不是问题，我刚刚跟需求确认过的”
“这样做不合逻辑啊！”
“那你说怎么处理？”
“我觉得应该....处理”
“你先跟需求确认下吧”
这应该是测试工程师的日常吧。测试与开发沟通无疑是关于某个功能或者产品的，主要围绕几个以下几个点：
程序某个地方存在问题
产品需求信息在测试和开发中不统一
程序某功能应该是怎么处理
缺陷修复后的验证
既然知道问题的核心，我们就要想办法规避这些问题。假设一开始提问题的时候就把问题的特征，位置，以及操作步骤，截图都一目了然的提交给开发，是不是很大程度上可以节省测试演示的时间？
另一个最容易出现的问题就是信息不统一，这个需要整个项目组有意识的培养健全的工作流程，通过工作流程来规避这种信息不对称的情况。这种情况将大大增加测试与开发的沟通成本。
2、测试与需求的沟通
测试人员与需求的沟通难点主要还是体现在需求不明确或者需求变更上。 很多时候需求人员的需求文档都是不全面的，测试人员在写测试用例时需要一次又一次的与需求进行确认，一来二去，需求估计有种想把桌子里40米长的大刀放桌上来。
另一方面在项目过程中，不可避免的会出现需求变更，只要出现变更就意味着之前的测试准备工作就作废。
所以在与需求的沟通是非常频繁又火星四溅的，那怎么更好的与需求进行沟通呢？
切记不能停留在口头沟通，确认
所有的需求确认或者需求变更都需要文档化，实在不行也需要发邮件每一次确认、变更都需要通过项目相关人
建立完善的需求变更体系，流程上控制需求变更
3、测试结果的反馈
相信大家应该遇到过偶现的缺陷，开发重现时就没有了，忙活了半天，被开发嫌弃了一顿 测试结果的反馈容易出现问题的地方就是结果描述不清楚，增加项目的时间和沟通成本。解决这个问题最好的办法就是将测试结果尽可能的描述清楚。
测试结果反馈分为两种：
在沟通工具中向开发反馈缺陷
在缺陷管理工具中提交缺陷
到底怎样提交/描述清楚一个缺陷？在下文中，我会详细介绍。 四、缺陷管理
在开发阶段，测试人员最重要的产出就是缺陷。缺陷不仅仅是数量多，就越有价值。更应该关注缺陷的质量、缺陷的管理以及缺陷分析。
怎么样提出质量高的缺陷？怎么样对缺陷进行管理和分析？见下图：
接口超时处理
废弃接口处理
二、测试用例评审
测试用例的评审无疑是为了给测试用例进行查漏补缺。
评审方式：
测试内部评审
项目组评审：项目相关人参与评审（开发、测试、产品）注意：
项目组评审时，一般是会议的形式，由于测试用例的数量关系，会议上评审会占用很长的时间，造成时间资源的浪费。
建议大家在评审前先将测试用例邮件发送给评审会议相关人，让他们提前能对测试用例进行了解，熟悉。会议中进行反�。锹己�，会后再修改。
三、测试执行
前面的工作做的充足的话，在测试执行的时候就会非常简单了。只需要根据测试用例一条一条去执行程序即可。发现缺陷就提交缺陷，测试通过就继续回归。
各位看官现在应该是心里一万个XXX呼啸而过～～哪有说的那么简单。
其实测试执行的过程真的很简单，只是在执行的过程中各部门的协作，沟通以及各项文档的输出很复杂。下面我们来聊聊在测试执行过程要注意的几方面问题。
1、测试与开发的沟通
“XXX 我这有个问题，你过来看下”
“什么问题？你演示下我看看”
“这不是问题，这个地方只能这样做”或者 “这不是问题，我刚刚跟需求确认过的”
“这样做不合逻辑啊！”
“那你说怎么处理？”
“我觉得应该....处理”
“你先跟需求确认下吧”
这应该是测试工程师的日常吧。测试与开发沟通无疑是关于某个功能或者产品的，主要围绕几个以下几个点：
程序某个地方存在问题
产品需求信息在测试和开发中不统一
程序某功能应该是怎么处理
缺陷修复后的验证
既然知道问题的核心，我们就要想办法规避这些问题。假设一开始提问题的时候就把问题的特征，位置，以及操作步骤，截图都一目了然的提交给开发，是不是很大程度上可以节省测试演示的时间？
另一个最容易出现的问题就是信息不统一，这个需要整个项目组有意识的培养健全的工作流程，通过工作流程来规避这种信息不对称的情况。这种情况将大大增加测试与开发的沟通成本。
2、测试与需求的沟通
测试人员与需求的沟通难点主要还是体现在需求不明确或者需求变更上。 很多时候需求人员的需求文档都是不全面的，测试人员在写测试用例时需要一次又一次的与需求进行确认，一来二去，需求估计有种想把桌子里40米长的大刀放桌上来。
另一方面在项目过程中，不可避免的会出现需求变更，只要出现变更就意味着之前的测试准备工作就作废。
所以在与需求的沟通是非常频繁又火星四溅的，那怎么更好的与需求进行沟通呢？
切记不能停留在口头沟通，确认
所有的需求确认或者需求变更都需要文档化，实在不行也需要发邮件每一次确认、变更都需要通过项目相关人
建立完善的需求变更体系，流程上控制需求变更
3、测试结果的反馈
相信大家应该遇到过偶现的缺陷，开发重现时就没有了，忙活了半天，被开发嫌弃了一顿 测试结果的反馈容易出现问题的地方就是结果描述不清楚，增加项目的时间和沟通成本。解决这个问题最好的办法就是将测试结果尽可能的描述清楚。
测试结果反馈分为两种：
在沟通工具中向开发反馈缺陷
在缺陷管理工具中提交缺陷
到底怎样提交/描述清楚一个缺陷？在下文中，我会详细介绍。 四、缺陷管理
在开发阶段，测试人员最重要的产出就是缺陷。缺陷不仅仅是数量多，就越有价值。更应该关注缺陷的质量、缺陷的管理以及缺陷分析。
怎么样提出质量高的缺陷？怎么样对缺陷进行管理和分析？见下图：
缺陷处理流程图
缺陷管理是软件测试活动中极其重要的一环，很多时候测试用例并没有发现多少缺陷，反而自己在运行程序的过程中发现了很多缺陷，那这些缺陷就是对测试用例的补充，对之后的测试就可以提供思路。
小结：
在开发阶段，测试人员最主要的工作就是发现缺陷，但是在这个过程中会伴随着很多其他的问题，需要我们在工作流程中去规避。最重要的就是把测试放在整个项目中，是各个部门的团队协作。
很多团队的问题并没有出在测试用例设计，测试执行，缺陷提交中，更多的出现在各部门之间的沟通、协作中。
发布阶段
进入发布阶段就意味着产品已经通过了测试，可以发布到线上，交付给用户使用。那如何确认测试已经通过？在发布过程中，我们测试人员又需要完成哪些工作？
测试通过准则规范
上线前，需要确认测试已经通过，现在程序越来越复杂，如果没有量化的规范，就很难确定测试到什么时候可以上线。所以我们需要设定测试通过的准则，只有达到准则才能上线测试需求功能覆盖率100%
测试用例通过率95%以上
遗留缺陷没有严重程度3级以及以上的缺陷
测试报告
完成测试后，提交测试报告，给出此次测试过程中的数据，例如：测试用例的数量，发现缺陷的总数，各个严重程度的缺陷数量，总共修复的缺陷数量以及缺陷修复率等等系统回滚方案
每一次发布都不能说百分之百的没有问题，如果真的出现问题，我们该如何处理？
如果线上出现的问题不是很严重，尽量当时处理掉再上线如果线上出现的问题很严重，就必须要系统回滚，保证线上用户的正常使用系统回滚方案须跟开发/项目经理确认
线上功能检查
程序原有功能的回归测试
新上线的功能全面测试
小结：
每一次发布后，测试人员都应该持续反馈，改进、总结每个版本中遇到的问题，不管是缺陷还是流程问题，从一次次的问题中总结一些经验，提高整个软件生命周期的质量日常维护阶段
产品上线后，用户能稳定的长期使用，就意味着发布的功能进入到日常维护阶段。而这里并不是终点，这个阶段将一直存在。
在这个阶段，测试人员的主要工作就比较简单
持续测试，没有产品是没有缺陷的
即使收集用户反馈的问题，并尽快组织人员修复
长时间稳定性测试（自动化测试）
总结
全程软件测试，关注的是在整个软件生命周期中，各个阶段的测试活动。
通过对各个阶段的过程质量把控，从而提高产品的测试质量。产品的质量并不是测试能决定的，而是整个项目构建过程中，通过一次次的优化过程，不断的总结成长，是整个项目团队决定的。
不同的工种都在这个过程中起到举足轻重的作用，而全程软件测试强调不断提高每个阶段的质量，最终提高项目团队的综合能力，从而提高产品质量。
小结：
在开发阶段，测试人员最主要的工作就是发现缺陷，但是在这个过程中会伴随着很多其他的问题，需要我们在工作流程中去规避。最重要的就是把测试放在整个项目中，是各个部门的团队协作。
很多团队的问题并没有出在测试用例设计，测试执行，缺陷提交中，更多的出现在各部门之间的沟通、协作中。
发布阶段
进入发布阶段就意味着产品已经通过了测试，可以发布到线上，交付给用户使用。那如何确认测试已经通过？在发布过程中，我们测试人员又需要完成哪些工作？
测试通过准则规范
上线前，需要确认测试已经通过，现在程序越来越复杂，如果没有量化的规范，就很难确定测试到什么时候可以上线。所以我们需要设定测试通过的准则，只有达到准则才能上线测试需求功能覆盖率100%
测试用例通过率95%以上
遗留缺陷没有严重程度3级以及以上的缺陷
测试报告
完成测试后，提交测试报告，给出此次测试过程中的数据，例如：测试用例的数量，发现缺陷的总数，各个严重程度的缺陷数量，总共修复的缺陷数量以及缺陷修复率等等系统回滚方案
每一次发布都不能说百分之百的没有问题，如果真的出现问题，我们该如何处理？
如果线上出现的问题不是很严重，尽量当时处理掉再上线如果线上出现的问题很严重，就必须要系统回滚，保证线上用户的正常使用系统回滚方案须跟开发/项目经理确认
线上功能检查
程序原有功能的回归测试
新上线的功能全面测试
小结：
每一次发布后，测试人员都应该持续反馈，改进、总结每个版本中遇到的问题，不管是缺陷还是流程问题，从一次次的问题中总结一些经验，提高整个软件生命周期的质量日常维护阶段
产品上线后，用户能稳定的长期使用，就意味着发布的功能进入到日常维护阶段。而这里并不是终点，这个阶段将一直存在。
在这个阶段，测试人员的主要工作就比较简单
持续测试，没有产品是没有缺陷的
即使收集用户反馈的问题，并尽快组织人员修复
长时间稳定性测试（自动化测试）
总结
全程软件测试，关注的是在整个软件生命周期中，各个阶段的测试活动。
通过对各个阶段的过程质量把控，从而提高产品的测试质量。产品的质量并不是测试能决定的，而是整个项目构建过程中，通过一次次的优化过程，不断的总结成长，是整个项目团队决定的。
不同的工种都在这个过程中起到举足轻重的作用，而全程软件测试强调不断提高每个阶段的质量，最终提高项目团队的综合能力，从而提高产品质量。
最新资讯
0
分享到：
江苏乐鱼播客教育科技股份有限公司 版权所有Copyright 2006-2024 All Rights Reserved 苏ICP备16007882号营业执照增值电信业务经营许可证出版物经营许可证
苏公网安备 32132202001156号