超详细一文到底!软件测试基本流程

前言:

采用通用的测试流程,能高效、高质量的完成软件测试工作,有助于减少沟通成本,对各阶段产出有明确认知等等。最终目标:实现软件测试规范化、标准化。以下为非通用标准,仅供大家参考

一、软件测试流程图

二、各阶段详解:

1、需求分析:

主要是明确本期需求必须完成哪些工作,具体完成到什么程度,细节是什么,记录需求不明确、缺失等疑问;要求需求必须完整、准确、清晰具体。很多时候是各角色私下进行,不组织大会。主要参与人员:RD、QA、UE。

2、需求评审:

PM同学对需求进行整体阐述和补充,其它成员带着需求分析时的疑问参加,提出疑问;目的是提前发现需求不明确、有冲突、无法实现、需求不全等问题。主要参与人员:项目经理、PM、RD、QA、UE。

3、计划与排期:

(1)RD计划与排期:根据评审后的需求,RD产出具体的开发计划和排期,包括人力安排,模块划分,开发设计文档产出以及具体提测时间等。主要产出人员:RD接口人。

(2)UE计划与排期:根据根据评审后的需求、RD排期给出相应计划和排期,包括:人力安排,模块划分,具体资源产出时间,根据提测时间规划走查时间点。主要产出人员:UE接口人。

(3)测试计划与排期:根据评审后的需求、RD排期给出相应的测试计划和排期,包括:测试方法(是否单测,是否进行接口测试,是否进行性能测试,是否分模块提测等),测试范围、人力安排,模块划分,case产出时间,case评审时间,测试完成时间,风险点。主要产出人员:QA接口人。

注意:所有的计划与排期要发邮件抄送给全员,并找对应peer确认,如有变动需及时联系相应peer。

4、测试环境搭建:

根据开发环境、测试计划搭建测试环境,可由RD支持。一般至少维护两套稳定的测试环境,满足项目并行以及单项测试(例如:压测、安全测试)需求。

注意:环境搭建好后,最好能自动部署代码,减少回归测试时代码部署时间。

5、测试用例:

(1)case编写:根据测试计划、修改好的需求文档编写测试用例,并根据RD产出的概要设计文档和详细设计文档(如无具体文档,可找对应RD问询代码逻辑和结构),补充测试用例。

(2)case内部评审:case完成后QA内部要先进行内部评审,评审不通过修改;评审通过后发邮件给全员,方便大家提前了解case,带着问题参加case评审。

(3)case全员评审:按测试计划的时间进行case评审,找出项目成员之间理解不一致的点,以及case缺失遗漏的点。根据评审结果修改case,并产出准入case(准入case:最核心的功能点以及阻碍测试的点)。

注意:a、准入case要邮件形式发送给相应RD,确保提测前准入case被执行通过,要求RD以邮件形式回复执行结果。

b、case要存档,并且要根据项目情况及时跟进修改(例如二期需求后一期case的变更),保证case是最新的且可作为参考的。

6、RD提测:

(1)提测前RD要确保自己执行准入通过(主要确保RD自测,培养良好的开发习惯),且PM首次走查通过(主要确保RD没有大的功能缺失,PM没有要改动或新增的大功能点,减少进入正式测试阶段的返工)。

(2)RD自测和PM走查均通过,QA进行准入测试;准入不通过打回,由RD修复后重新提测,重新走RD自测、PM走查、QA准入测试流程。RD自测、PM走查、QA准入测试均通过,QA进入正式测试。

7、正式测试:

根据测试计划、测试case执行测试,报bug,RD修复后QA回归。每天产出当日测试报告,明确具体测试进展,bug情况,项目风险等。针对风险及时进行策略调整,确保项目如期上线。

8、show case 与走查:

测试全功能走通,bug已基本收敛的情况下show case,此时PM进行详细走查,UE进行视觉走查。主要参与人员:PM、RD、UE、QA。测试/走查不通过,提交bug,RD修复,修复后验证bug。测试/走查通过,对软件进行全功能验证。

9、全功能验证:

主要是针对非第一期需求的产品,新增需求以及改动需求可能会对原有功能造成影响。验证不通过,提交bug,RD修复后验证bug,并重新进行全功能验证。这个阶段建议采用自动化提升效率,如UI自动化、接口自动化等。全功能验证通过,上预发布验证。

10、预发布验证:

主要是防止因数据不同步等导致的bug。此时要注意对线上版本进行验证,也要注意当前版本和线上版本的交互。预发布验证通过后,启动上线流程。

11、上线:

RD或OP启动上线,上线不成功,RD修复bug,QA回归bug、全功能验证、预发布验证,重新启动上线。上线成功后要进行线上验证。

注意:上线过程要注意做好数据和版本隔离,避免对线上造成影响。

12、线上验证:

线上验证不通过回滚,RD修复bug,QA回归bug、全功能验证、预发布验证,重走上线和线上验证流程。线上验证通过后,要实时跟进用户反馈,添加/修改监控。

注意:最好有一键回滚机制,做好回滚演练,真的遇到过上线后全业务挂掉的情况。

13、跟进用户反馈,添加/更新监控:

(1)成功上线后,要实时跟进用户反馈,及时发现用户反馈的问题,防止有大问题影响用户使用。整理用户反馈最多的需求点,反馈给PM,反向影响需求。

(2)及时添加/更新监控,实时监控线上服务,保证线上服务正常、稳定运行,出现问题第一时间响应。

最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:

这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!

LVS(Linux Virtual Server)是一种基于 Linux 系统的负载均衡集群技术,它主要用于将网络流量分发到多个服务器上,以提高系统的可靠性、可扩展性和性能。 LVS 集群一般包括四个组件:调度器(LVS 调度器)、前端服务器(负载均衡器)、后端服务器(真实服务器)和存储服务器(用于共享数据)。首先,调度器接收来自客户端的请求,然后根据配置的调度算法(如轮询、加权轮询、最小连接数等)将请求分发到多个前端服务器。前端服务器接收到请求后,通过相应的负载均衡算法将请求转发到后端的真实服务器上进行处理。在整个过程中,存储服务器用于存放共享的数据,以确保所有的真实服务器都能获取到相同的数据,并提供一致的服务。 LVS 集群的优点是能够提高网站的稳定性和可靠性,当某一台服务器出现故障时,调度器会自动将请求分发到其他可用的服务器上,从而保证服务的连续性。同时,LVS 集群还能够通过增加前端服务器和后端服务器的数量来提高系统的性能和吞吐量,以满足不断增长的用户需求。 在实际应用中,LVS 集群需要合理配置,包括选择合适的调度算法、调整每台服务器的权重、选择适当的硬件设备等。此外,还需要及时监控集群的运行状态,及时发现和解决故障,以确保整个系统的正常运行。 总的来说,LVS 负载均衡集群是一种强大而高效的集群技术,能够帮助企业提高系统的可靠性和性能,是现代互联网应用中不可或缺的重要组成部分。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值