广东广州网点快速网站建设,wordpress 关于我们,做网站用php如何学习,微网站 php#x1f345; 点击文末小卡片#xff0c;免费获取软件测试全套资料#xff0c;资料在手#xff0c;涨薪更快 “尽早的介入测试#xff0c;遇到问题的解决成本就越低”
随着软件测试技术的发展#xff0c;测试工作由原来单一的寻找缺陷逐渐发展成为预防缺陷#xff0c;… 点击文末小卡片免费获取软件测试全套资料资料在手涨薪更快 “尽早的介入测试遇到问题的解决成本就越低”
随着软件测试技术的发展测试工作由原来单一的寻找缺陷逐渐发展成为预防缺陷探索测试破坏程序的过程测试活动贯穿于整个软件生命周期中故称为全程软件测试
全程软件测试强调整个软件生命周期中各阶段的测试活动。无论是需求阶段开发阶段还是测试阶段都需要确定在当前阶段测试活动的内容以及成都确保每个阶段的质量才能保证产品最终的质量。
全程软件测试 全程软件测试图解 根据全程软件测试的时间轴线图我们可以发现测试活动贯穿软件开发的整个生命周期各个阶段测试活动内容如下 那每个测试活动又到底是如何进行的需要用的哪些技能或者方法呢
需求阶段
一、测试需求分析
我个人一直认为需求分析是整个测试活动中除了测试用例设计之外最重要的部分。
需求分析目的是理解需求理解业务。弄清楚我们的产品有哪些功能有哪些非功能性需求明白我们的用户群体是什么用户会如何来使用我们的产品
那我们到底该怎么来进行需求分析呢 具体执行如下 二、测试计划制定
当对需求有完整和全面的理解后接下来我们需要制定详细的测试计划为即将开始的测试工作做好充足的准备。对于测试计划的理解我一直分为两种工作规模去看个人理解不正确的地方还请见谅
小公司团队
小公司测试团队可能本身都没几个人按照传统理论需要考虑测试活动中各方面的问题给人的感觉就像杀鸡用3米长的大砍刀一样。
我的理解是小团队的测试计划讲清楚以下四个要素就行。
时间根据以往经验以及需求理解进行时间估算小建议时间节点多争取1到2天时间缓冲项目过程中难免出现意外事件任务将测试活动拆分成具体的任务人任务的执行人以及质量监控负责人风险控制
大作坊团队
大公司测试团队往往是涉及多个项目整个公司的硬件、时间、人力等资源的分配就更为复杂。在这种情况下需要对各方面有更为精细的计划。
资源估算整个项目需要多少资源硬件资源人力、时间资源等进度控制每个测试活动时间点控制风险控制对于在测试活动过程中出现问题的解决方案资源配置如何更有效率的使用资源验收标准文档、项目、测试过程的验收标准定义测试策略测试中使用的测试策略
小结
在需求分析阶段测试人员既要详细的理解产品需要又要从用户的角度出发分析出需求中不完善的地方还要协调开发与测试对于需求理解的一致性保证需求信息在开发和测试双方中的统一。
这也就是尽早的将产品缺陷给暴露出来也会有效的预防缺陷。
开发阶段
在经过需求阶段的准备工作后进入开发阶段就意味着撸起袖子加油干的时候。开发阶段对于软件生命周期而言是最重要的阶段。那在这个阶段又是如何开展测试活动的呢
一、测试用例设计
测试用例设计是软件测试工作的灵魂。
任何一项测试活动的核心都是测试思维即如何进行测试。而测试用例就是测试思维的体现。功能的测试优先级、如何操作、输入什么数据、应该有什么的结果等等都体现在测试用例中。那么问题来了
到底怎么设计测试用例呢
由于篇幅原因这次我主要介绍一下接口测试用例设计方法
首先我们来看一看接口的执行过程 任何一个接口其实都由这三部分构成那我们在设计测试用例时就可以根据这方面进行考虑。
针对接口的输入条件进行设计 针对接口的处理逻辑进行设计 针对输出结果设计 其他方面考虑
接口超时处理废弃接口处理
二、测试用例评审
测试用例的评审无疑是为了给测试用例进行查漏补缺。
评审方式
测试内部评审项目组评审项目相关人参与评审开发、测试、产品
注意
项目组评审时一般是会议的形式由于测试用例的数量关系会议上评审会占用很长的时间造成时间资源的浪费。
建议大家在评审前先将测试用例邮件发送给评审会议相关人让他们提前能对测试用例进行了解熟悉。会议中进行反馈记录后会后再修改。
三、测试执行
前面的工作做的充足的话在测试执行的时候就会非常简单了。只需要根据测试用例一条一条去执行程序即可。发现缺陷就提交缺陷测试通过就继续回归。
各位看官现在应该是心里一万个XXX呼啸而过哪有说的那么简单。
其实测试执行的过程真的很简单只是在执行的过程中各部门的协作沟通以及各项文档的输出很复杂。下面我们来聊聊在测试执行过程要注意的几方面问题。
1、测试与开发的沟通 “XXX 我这有个问题你过来看下” “什么问题你演示下我看看” “这不是问题这个地方只能这样做”或者 “这不是问题我刚刚跟需求确认过的” “这样做不合逻辑啊” “那你说怎么处理” “我觉得应该....处理”
“你先跟需求确认下吧”
这应该是测试工程师的日常吧。测试与开发沟通无疑是关于某个功能或者产品的主要围绕几个以下几个点
程序某个地方存在问题产品需求信息在测试和开发中不统一程序某功能应该是怎么处理缺陷修复后的验证
既然知道问题的核心我们就要想办法规避这些问题。假设一开始提问题的时候就把问题的特征位置以及操作步骤截图都一目了然的提交给开发是不是很大程度上可以节省测试演示的时间
另一个最容易出现的问题就是信息不统一这个需要整个项目组有意识的培养健全的工作流程通过工作流程来规避这种信息不对称的情况。这种情况将大大增加测试与开发的沟通成本。
2、测试与需求的沟通
测试人员与需求的沟通难点主要还是体现在需求不明确或者需求变更上。
很多时候需求人员的需求文档都是不全面的测试人员在写测试用例时需要一次又一次的与需求进行确认一来二去需求估计有种想把桌子里40米长的大刀放桌上来。
另一方面在项目过程中不可避免的会出现需求变更只要出现变更就意味着之前的测试准备工作就作废。
所以在与需求的沟通是非常频繁又火星四溅的那怎么更好的与需求进行沟通呢
切记不能停留在口头沟通确认所有的需求确认或者需求变更都需要文档化实在不行也需要发邮件每一次确认、变更都需要通过项目相关人建立完善的需求变更体系流程上控制需求变更
3、测试结果的反馈
相信大家应该遇到过偶现的缺陷开发重现时就没有了忙活了半天被开发嫌弃了一顿
测试结果的反馈容易出现问题的地方就是结果描述不清楚增加项目的时间和沟通成本。解决这个问题最好的办法就是将测试结果尽可能的描述清楚。
测试结果反馈分为两种
在沟通工具中向开发反馈缺陷在缺陷管理工具中提交缺陷
到底怎样提交/描述清楚一个缺陷在下文中我会详细介绍。
四、缺陷管理
在开发阶段测试人员最重要的产出就是缺陷。缺陷不仅仅是数量多就越有价值。更应该关注缺陷的质量、缺陷的管理以及缺陷分析。
怎么样提出质量高的缺陷怎么样对缺陷进行管理和分析见下图 缺陷处理流程图 缺陷管理是软件测试活动中极其重要的一环很多时候测试用例并没有发现多少缺陷反而自己在运行程序的过程中发现了很多缺陷那这些缺陷就是对测试用例的补充对之后的测试就可以提供思路。
小结
在开发阶段测试人员最主要的工作就是发现缺陷但是在这个过程中会伴随着很多其他的问题需要我们在工作流程中去规避。最重要的就是把测试放在整个项目中是各个部门的团队协作。
很多团队的问题并没有出在测试用例设计测试执行缺陷提交中更多的出现在各部门之间的沟通、协作中。
发布阶段
进入发布阶段就意味着产品已经通过了测试可以发布到线上交付给用户使用。那如何确认测试已经通过在发布过程中我们测试人员又需要完成哪些工作
测试通过准则规范
上线前需要确认测试已经通过现在程序越来越复杂如果没有量化的规范就很难确定测试到什么时候可以上线。所以我们需要设定测试通过的准则只有达到准则才能上线
测试需求功能覆盖率100%
测试用例通过率95%以上
遗留缺陷没有严重程度3级以及以上的缺陷
测试报告
完成测试后提交测试报告给出此次测试过程中的数据例如测试用例的数量发现缺陷的总数各个严重程度的缺陷数量总共修复的缺陷数量以及缺陷修复率等等
系统回滚方案
每一次发布都不能说百分之百的没有问题如果真的出现问题我们该如何处理
如果线上出现的问题不是很严重尽量当时处理掉再上线
如果线上出现的问题很严重就必须要系统回滚保证线上用户的正常使用
系统回滚方案须跟开发/项目经理确认
线上功能检查
程序原有功能的回归测试
新上线的功能全面测试
小结
每一次发布后测试人员都应该持续反馈改进、总结每个版本中遇到的问题不管是缺陷还是流程问题从一次次的问题中总结一些经验提高整个软件生命周期的质量
日常维护阶段
产品上线后用户能稳定的长期使用就意味着发布的功能进入到日常维护阶段。而这里并不是终点这个阶段将一直存在。
在这个阶段测试人员的主要工作就比较简单
持续测试没有产品是没有缺陷的即使收集用户反馈的问题并尽快组织人员修复长时间稳定性测试自动化测试
总结
全程软件测试关注的是在整个软件生命周期中各个阶段的测试活动。
通过对各个阶段的过程质量把控从而提高产品的测试质量。产品的质量并不是测试能决定的而是整个项目构建过程中通过一次次的优化过程不断的总结成长是整个项目团队决定的。
不同的工种都在这个过程中起到举足轻重的作用而全程软件测试强调不断提高每个阶段的质量最终提高项目团队的综合能力从而提高产品质量。
最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走 这些资料对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你凡事要趁早特别是技术行业一定要提升技术功底。
