前言:

我们在变化中成长。假设你拒尽了变化,你就拒尽了新的美丽和新的机遇。今天一菲用亲身经历和你好好聊聊一个好的软件测试工程师应该做到哪些?

一.初始软件测试
我在没有做测试工作之前,如果你问我一个关于杯子的质量问题,我很会说两个字,很好,但是现在的我就会想到很多这就是测试人的格局我骄傲。

下面听我絮叨一下。

在这里插入图片描述

还是这个问题,如果问我关于这个杯子的质量的问题,我会想到两个大的方向:

1.质量问题包含哪些方面?即通常所说的需求是什么?

这里提两个概念,就是==“显性要求”和“隐性要求”,==
如显性需求,首先应该是杯子,不是瓶子、盆子等等,用途是喝水的;隐性需求呢?那就比较笼统了,如大小、高度、容积、制作材料、温度承受范围,还有一些其他细节如颜色、边角圆滑等。

2.如何去准确获取、表现这些需求,即相关指标数据是多少?

这个时候我们就要知道它的大小、高度、容积,还有用到相关测量工具,如尺子、圆规。要知道温度承受范围,可能要用到温度计等。

举这个例子就是想告诉大家,在完成测试工作期的整个过程当中,测试设计执行之前,必须清晰了解它的显性需求和隐性需求,再之后需要有对应的测试方案和测试方法,你还需要考虑到需要执行哪钟类型测试,要用到什么测试工具等。就是我们必须知道设计测试用例之前,对于该测试项目上的基本点都有一个比较准确的认知。

二.功能测试实践

我的第一份工作接触的项目是国税门户网站,所进行的测试工作是主要是功能测试,如测试用例编写、执行,测试报告反馈。当时对所谓的软件生命周期都很模糊,感觉我只要做好自己的测试任务就好了,其他的东西由上级安排就好。
在这里插入图片描述
但是在后面的工作当中,让我真正接触到了项目开发、交付的实际生产过程,简而言之就是,工作任务是无止境的,永远有数不尽的需求要开发、测试,有茫茫多的Bug要跟踪。如何在这中间保持自己清晰的定位显得至关重要。由于在项目组中只有我一个测试人员,那么结果就是,“测试的事情就都是我的”,和我之前想的不一样,应了那句话计划该不是变化快,有或者说本来就是这样,是我自己想的太美好。

在这里插入图片描述
每天我和高管的对话都是这样子的。

1.“某某某,过来一下,这是这个版本修改的内容,大概是要在某月某日完成,你过(看)一下。”

“哦”。

2.到了测试执行,发现问题后提交给开发同事,开发回复:“设计如此。”

“哦”。

3.快要上线了,项目经理问:“某某某,现在系统的测试情况怎么样,能不能上线?”

“应该差不多吧”

在做工作中,磕磕碰碰总结了以下经验,不容易啊。

在这里插入图片描述
a、测试的依据,需求基线一定要清楚,要尽早参与;
b、测试要有计划方案,要有用例设计,不能随意的开展;
c、Bug的跟踪,要有自己的主见、原则;
d、测试结果的把握,要有结果分析。项目的上线,要综合你的以上测试过程,结合目前的情况总结报告,甚至是项目经理也要听取你的意见。你的角色不仅是测试,也是质量保证。

在后来的项目测试工作中,践行测试主管传递的思想原则的同时,我并行了解相关测试书籍、工具、技能,结合工作进行相关实践,逐渐地我的测试能力越来越强。

做了这么久的功能测试之后,测试过程中我变得更加有条理、原则、规范。但也仅是个人自觉的约束,很多过程并没有按照软件开发周期的标准来执行,如测试用例、测试报告有时候会在发布版本后才编写(虽然公司也通过了CMMI3),即测试的质量保证更多的依赖个人的素质。所以品格决定了你工作的成功与否,那就是态度决定一切。

在这里插入图片描述

三.性能测试实践

测试当然不仅有功能测试。第一次接触性能测试也是在国税门户项目组,只不过测试对象不是国税门户网站。其实那个软件系统的具体业务我都不太清楚(惭愧),只知道是叫一户式查询系统。

在工作当中,我了解到同性能测试的相关信息。

a、系统的部署组成,相关的服务器有哪些(此时还不知道具体的网络拓扑结构)。

b、相关场景的选择依据。

c、工具的使用,脚本的录制。

d、主要性能指标。

e、基于工具结果的简单分析。

原谅我当时的简单朴素,能把握的就这些了。

在这里插入图片描述
网报项目的相关合作方有多个,网络、防火墙、CA认证服务、核心申报等分别是不同的公司负责交付,如果测试过程中有出现问题,往往不好定位是谁的责任。在这种情况下,了解系统的网络部署的设计结构是十分关键的。接下来谁开展具体的测试场景。

四.具体的测试场景开展

a 、熟悉了解网络拓扑图,相关机器、服务器的物理及网络部署,为之后进行分层次测试做好准备。
b、并发数的计算,按照计算公式C=nL/T是比较理想化的,由于项目并没有相关措施监控,因此难以获取到平均在线人数、操作时间等具体参数。
c、根据实际业务选择需要测试的业务功能场景。
d、性能测试场景,如系统最大并发数,单个节点最大并发数,不同网络接入点最大并发数,稳定性测试等。
e、其他指标如响应时间、资源使用。

五.确定以上方案和指标之后再进行具体的准备和执行。

a.执行过程中,肯定会出现些许问题,开始从系统最外围即外网进行测试,
  b.如果结果不理想,那么就要定位原因,过滤出指标差的业务场景.
  c.然后单独测试,此时相关场景加上时间戳信息,再在各个服务器上采集日志,
  d.之后为了确认真实,再更换不同服务器地址进行测试对比不同接入点的结果。
  e.最后就是拿具体的结果给对应的合作方讨论分析。

整体的设计方案执行下来,花了不少的时间。

虽然这个过程比较繁琐和曲折,但是最终是完成了原定的测试目标。过程是艰辛的,但让我在今后的做事方式更加有条理、按步骤、踏实、耐心。所以应了那句话,阳光总在风雨后,不经历风雨怎能见彩虹,真香定律!

在这里插入图片描述

在这里推荐一个软件测试交流群,QQ:642830685,群中会不期的分享软件测试资源,测试面试题以及行业资讯,大家可以在群中积极交流技术问题。

六.变化中成长

走过堤岸,有依依杨柳,迈入田野,是无边麦浪。人总会经历不同的旅途风景,在变化之间获得不同的成长见识。

第一份工作经历形成了我对测试的基本认识及工作方式,接到测试任务之后就会条件反射的设想需要开展的测试类型,相关方案。但对于这些工作是否可以更标准化、工程化的开展还只是一个朦胧的概念。之后重新更换测试工作,工作开始并没有什么不同,只是测试执行之前要求必须编写测试用例。但随着时间的推移,让我体验到了不一样的氛围。所以测试要尽早开始,并且排除随意性,有计划的进行,这是软件测试基础理论的原则之一。落地手工功能测试的同时,我们在持续进行自动化功能测试和性能测试工作。

不管是功能自动化测试,还是接口、系统性能测试,我们都已实现工程化、自动化的工作方式,也践行了软件测试中经常提及的测试应该要持续进行的原则。

七.以下是个人测试经验中的一些观点:

a、尽量把测试往前推,尽早发现,降低修复成本;
b、测试的目的不是发现Bug,而是预防Bug的发生;
c、通过各种技术手段和流程改进,逐步的解放公司内部测试人员,让他们把精力放在对产品的把握上。

当然,不管有多好的工作起点平台,测试人员的素质才是决定最终测试质量的保证。在从原有重复的工作方式中解放后,测试人员的综合素质如所处行业知识、测试思维、测试设计方案都影响到具体的测试结果,所以随着大环境的转变,传统的功能测试已经被自动化测试所冲击,但是测试是技术为王,所以只有不断的汲取新的知识和技能,才能让自己充满竞争力,不会被行业淘汰。
在这里插入图片描述
八.写在最后:

软件测试的工作是辛苦的。每天需要执行用例、跟踪Bug,还要与开发、产品同事做辩论,但正是因为这些默默的付出,你让一场本该在用户面前发生的灾难,提前在自己面前发生了,怎么样,亲眼看着自己设计的项目出现了bug ,开心吗?

在这里插入图片描述
在这里推荐一个软件测试交流群,QQ:642830685,群中会不定期的分享软件测试资源,测试面试题以及行业资讯,风里雨里我在群中等你,看完后别忘举起你可爱的小手给我点个赞,你的点赞是我持续更文的不竭动力,笔芯!
 
在这里插入图片描述

内容来源于网络如有侵权请私信删除

文章来源: 博客园

原文链接: https://www.cnblogs.com/syf12/p/14319269.html

你还没有登录,请先登录注册
  • 还没有人评论,欢迎说说您的想法!