应届生找测试工作，你需要知道的必备技能和注意事项。

前言：

俗话说，人怕入错行。应届生的第一份工作，对一个人的职业生涯是非常重要的，毕业后前三年，是为自己打基础积攒经验的时间，选错行业和岗位，意味着前几年的经验清零，这对于个人成长是非常致命的。

我从以下几点分析应届毕业生在软件测试行业的个人发展，跟个人发展挂钩的，无非就是三个问题：

a.入行难度：这个岗位好上手吗？有硬性要求吗？对专业限制大吗？对应届生来说难吗？

b.岗位晋升：这个岗位的晋升机制是怎样的？容易吗？（上升空间及难度）

c.薪资涨幅：这个岗位的薪资涨幅情况（有钱赚吗，薪资天花板如何）

正文：

首先我们来看一下做软件测试需要哪些技能。

一、入行难度

大学里并没有针对软件测试的系统课程，国内企业普遍也是重开发，轻测试。但随着这几年的发展，越来越多的企业意识到测试的重要性，对软件测试人才的需求越来越多。目前市场上的测试人员，一部分是企业自己培养的，另一部分是来自培训机构。

如果你是科班出身的应届生，走软件测试方向的话，再好不过，有一定的基础知识，如果你不是科班出身的，也不影响，毕竟大学里并没有软件测试的系统课程，不过需要你去补充一下基础的东西。

作为一个大学里没软件测试课程的想从事软件测试岗位的应届毕业生，想要拿到软件测试的敲门砖，势必要付出一些努力的，不论科班非科班，因为起点几乎是一样的。

二、必备技能

测试学习大致分为三个阶段。

排在第一位的是：入门阶段

接下来就是自动化学习，进阶

最后大家要了解性能测试、 测试平台开发，领域专家方面的内容。

入门阶段需要掌握的知识有:

1、基本理论

a.测试的定义、测试的分类、测试的方法、测试的生命周期。

b.黑盒、白盒、灰盒 测试。

c.动态与静态测试。

d.测试计划、测试方案、测试策略、测试用例的编写、测试用例的设计方法。

e.测试和开发流程的关系、瀑布流、V字形、W字型（双V）、螺旋型、敏捷等。

f.单元测试、功能测试、集成测试、系统测试等。

g.BUG的定义、BUG的分类、BUG的六要素、BUG的生命周期。

h.PDCA、5W2H等分析管理的方法质量管理 体系CMMI。

i.测试常用语。

2、计算机知识

操作系统 、计算机网络、域和DNS、C/S架构B/S架构、网络协议。 CPU、内存、IO、带宽等。

3、Linux相关知识

操作环境、常用命令、测试环境部署、虚拟机VM。

4、书籍库相关知识

数据库相关知识

主要命令、增删改查、数据关联、分组查询。 Mysql、Mongodb数据库。

5、app测试相关知识

安装/卸载、离线、UI、登录等测试内容。 兼容性测试。 手机特有的功能点。

6、接口相关知识

接口测试基本理论、http协议、测试方法。接口测试需求分析、用例编写、评审。

7、工具使用

a.项目管理工具，例如Git、jira。

b.bug管理工具，禅道、jira。

c.测试用例管理工具、jira、Excel。

d.抓包工具，浏览器自带的F12，Fiddler。

8、Web基本知识 HTML、CSS、JavaScript

学习有两种方式，自学和培训。

自学适合自控力强，目标明确，学习能力强的同学们，还有很重要的一点，就是项目实战经验，自学在项目实战方面会比较欠缺，相当于还是零经验，所以还是要谨慎考虑。

三、岗位晋升

软件测试的晋升路线，结合国内软件测试岗位，在头部互联网公司和软件开发企业中，岗位的发展情况，做一个软件测试工程师晋升路线和具备能力的介绍，可以作为给软件测试新人的职业规划的参考。

起步：软件测试员

自身条件：最基本要求计算机专业毕业或具备一些基本的手工测试经验。

具体工作：执行测试用例，记录测试中的bug，并进行回归测试，通过测试工具，录制回归测试脚本，并执行。

一阶：软件测试工程师

自身条件：具备1~2年工作经验的软件测试员或程序工程师。具有承担初步自动化测试的能力，能独立完善自动化测试脚本。

具体工作：设计和编写测试用例，编写自动测试脚本程序且担任测试编程初期的领导工作。

二阶：高级测试工程师

自身条件：有3~4年经验的测试工程师或程序员。需要有一定的行业业务知识，储备系统分析员的能力。

具体工作：帮助开发或维护测试或编程标准与过程，分析软件需求，获得测试需求。确定测试需求相应的测试方法，获得测试策略方案。参与同行的评审(软件需求，软件测试计划等)，并为其它初级的测试工程师或程序员充当顾问。

三阶：测试组负责人

自身条件：有4~6年经验的测试工程师或程序员。具有丰富的行业业务知识，具有系统分析员的能力，专长性能测试。

具体工作：负责管理1~3名测试工程师或程序员。集中于技能方面，担负一些进度安排和工作规模/成本估算职责。分析性能瓶颈的原因，为开发团队提供bug解决策略。

负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品，负责开发项目的技术方法，能够为用户提供支持与演示。

四阶：测试/编程高级负责人，资深安全或性能测试工程师

自身条件：有6~10年经验的测试工程师或程序员。

具体工作：负责管理8~10名技术人员。性能测试整体方案设计，软件系统性能问题定位和性能优化，内存优化及分析数据溢出等，分析系统的安全漏洞等。负责进度安排、工作规模/成本估算，按进度表和预算目标交付产品。负责开发项目的技术方法。为一些用户提供支持与演示。

五阶：测试/质量保证/开发(项目)经理

自身条件：有10多年的工作经验。

具体工作：管理8名或更多的人员参加的1个或多个项目。负责这一领域(测试/质量保证/开发)内的整个开发生存周期业务。为一些用户提供交互和大量演示。负责项目成本、进度安排、计划和人员分工。

六阶：公司级质量总监 / 计划经理

自身条件：有15年以上开发与支持(测试/质量保证)活动方面的经验；具体工作：管理从事若干项目的人员以及整个开发生存周期。负责把握项目方向与盈亏责任。

QQ群：642830685

微信公众号：程序媛一菲

软件测试应该注意哪些事项?

1． 查找bug时的注意事项

a.软件系统的实现过程就是一组控件实现自己的功能逻辑的过程。我们通过几个常用的web控件，来说明一下我们需要注意的地方。

文本框

文本框更多的情况下是用来输入信息的。文本框都一样，可是不同地方的文本框需要输入的信息就不会都一样了，比如说，有的是用来输入时间日期的，有的是用来输入文字的。首先我们要结合需求，确定文本框的具体作用，要是用来输入日期时间的，就要注意可以输入几种格式的日期时间，是只读的，还是可进行手动修改的，是否对汉字、特殊符号等做了输入限制（很多时候，录入不匹配的信息，系统会出现错误）。要是用来输入文字的，验证是否对录入的文字长度做了限制（如果超出数据库设置的最大值，会出错）还要注意文本框设置的可视长度，和录入的信息以及页面的整体风格是否和谐。

标签

标签，基本上不用实现什么逻辑功能，只是起到显示标记的作用。对于标签，我们注意的就是不要出现错别字（当然，任何地方都不能有错别字这样低级的错误），当标签和其它控件联合使用的时候，我们要结合页面的整体风格，确认它的设置是否合适，如label与其他控件之间的距离、标签的字体样式及颜色是否合适等。

单选按钮

单选按钮，顾名思义，就是只能选择一个。一般情况下，单选按钮都是以组出现的。如录入性别信息时，有“男”和“女”两个选项，我们要确认只能选择其中的一种，不允许两项都可以选择，而且提交的是选择的信息。

复选框

可以这样说，复选框和单选按钮的作用是相对的。使用复选框的地方，一定是要求可以进行多选的，自然就要验证是否实现了多选功能。这里我举这样一个例子：有

A、B、C三个查询条件，是用复选框的形式实现的。当验证完每一个查询条件后，最好再进行组合验证，就是说当只选择A和C或B和C时进行查询。也许有时候bug是由后台查询语句出错导致的，并不是复选框本身的错误。我想说的是不要忘记进行这样的测试验证。

下拉列表

下拉列表的作用和单选按钮的功能有些相似，从列表中选择一条自己需要的信息。很多时候，列表的选项中有一条是使用频率最多的，即使用户没有做特殊要求，系统最好把使用频率最多的那一项设置为默认选项，这样可省去用户的一次操作步骤(不仅是这里，要注意整个系统中对默认选项的设置，软件就是应该最大程度的方便用户)。而且还要注意下拉列表的宽度是否合适，列表信息是否显示完全了。

按钮

我们要注意Button和submit两种按钮的不同之处，Button主要是用来实现相应的方法函数，submit是用来提交相应的表单到相应的action处。这里有一点就是，当单击执行一个删除类的按钮时，一定要加上提示信息，而且提示信息上要有确定和取消功能，以防用户不小心删错信息。

b. 现在的软件系统不再像以前那样单调，软件中实现了很多特效。举一个简单的例

子来说明一下，比如对一个按钮，当光标放到上面的时候，它是一种效果，当光标离开之后，它又是另一种效果。也要注意光标的变化，当光标在可输入的文本框上面时是“I”形状的，在一般的按钮上是弯曲三个手指的小手形状的。我们要注意特效的统一性，而且特效也不是用的越多越好。效果的实现使系统变得更加的多彩，用户也会更加愉快的使用软件。

c. 每一个稍微复杂一点的系统一般都是由多个页面组成的，而不会只使用一个单调

的页面，这时我们就要注意界面显示的色调风格是否统一、字体大小从标题到具体内容是否体现出层级，同类、同层次的风格设置是否统一。虽说系统可以由多个界面组成，但是我们也不希望看到冗余的界面。也许有的需求中并没有对界面作出特殊的要求，但是我认为高质量的界面也是一款高质量的软件不可或缺的组成部分。

d.测试软件时，一定不要漫无目的的测来测去。这样不仅会增大工作量，而且也不

能对系统作出彻底的测试，。我们要有计划有目的的进行测试工作。要是担心忘记某些功能点，“地毯式”测试也是行得通的，从页面的第一个功能点到最后一个进行地毯式的搜索测试。

e.注意界面上的分页和滚动条等小问题，有的地方信息很少，一页足可以显示完，

就不需要分页功能了；有的窗口会看到滚动条，如果再把窗口设置的大一点，就可以全部显示了，那就最好把滚动条去掉，我想每个用户都希望一眼就看到所有的信息，而不想拉来拉去的。还有就是该有时间的地方，一定要有时间信息，尤其是涉及到打印报表的地方。

f一般的系统都需要使用用户名和密码登陆，而且会为不同的用户分配不同的权限。

不要总是使用正确的用户和密码在相应的权限范围内进行测试工作，从打开登陆窗口的那一刻就要意识到测试工作已经开始了。在测试过程中不要按部就班的操作程序，你也不知道用户在使用过程中会怎样操作程序，有时候就要反其道而行之，要知道测试是具有破坏性的。

g.用户使用软件的环境和软件开发时的环境不可能完全一样。我们可以考虑并验证

以下这几个问题：

其他的浏览器是否有相同的问题?

其他的软硬件配置是否有相同的问题?

不同的安排设置是否有相同的问题?

以前的版本否有相同的问题?

2． 提交bug时的注意事项

a .发现一个问题时，不必急着提交，可以先做验证(包括复现、对比测试等)进行证实，

看是概率性问题还是每次必现的问题，需要时也应使用不同版本不同机器做对比验证，当然，如果已经很确信是一个bug了，也就不用浪费时间去对比验证了。

b.描述要清晰、准确，不要使用含糊的词语(例如，好像，似乎)来描述发现的现象。

关于这点，如测试某款软件时，提交一个bug描述为“软件帮助说明中好像有错别字”，并没有说出哪一页哪一行以及具体哪个字错了，应该修改成什么样的。因此就不能说是个好的描述。

c.要考虑开发人员的感受，有些问题尤其是有些主观性比较强的问题，在问题描述

中一般不要出现带强烈感情色彩的词语标点符号，如“要求”、“必须”和感叹号等(特殊情况除外)。在提交此类问题时可以使用一些诸如“建议……”、“希望……”、“请……”之类比较委婉些的词语。

d. 不能确认一个现象是不是一个bug的时候可以向其他人或者开发人员进行确认，

然后再去提交。

e.概率性的问题，测试过程中难免遇到一些概率性问题，很难找出其产生的规律，

甚至该问题在测试过程中只出现一次，对于此类问题也一定要提交，并补充说明无法复现或者无规律。

f.描述问题时，要实事求是，不要夸大，比如概率性问题，本来出现的概率只有10%，

你把它写成50%都是不应该的。

g. 提交bug时，应该在描述清楚问题点的时候把正确的预期输出结果写明，即正确

的结果应该是什么样的，这点很重要。现在我们提交的bug中有些测试和开发双方都知道该修改成什么样子了，而在bug描述中未写出修改成什么样子的，如“来电时按挂机键不能拒接来电”这样描述一个bug，并没有写明该如何修改，一般这样描述大家一看就知道该如何修改，所以写不写预期正确结果大家都可以接受。但对于有些bug的描述一定要把预期的正确结果给写进去，否则开发人员会无所适从，不知道该修改成什么样子的。

h. 很多时候，提交的bug都需要重现，而有的bug是在测试过程中偶然间发现的，

时间一长，会对发现bug时的特定数据或环境模糊，导致不能重现bug。所以提交bug时描述的越详细越好。如果语言文字难以清楚的描述出发现的问题，最好能附件图片或者log记录等做辅助说明。

i. 提交测试bug的时候，如果该问题在某一特定环境下才能出现，一定要将该问题

产生的环境(硬件、软件)描述清楚。

g.提交问题前要清楚的知道软件需求、规格定义。相信很多人都遇到过这样的尴尬

情况，提交了一个重要问题后，却被告知其实那并不是一个问题，软件就是那样设计的或者需求就要求那样处理的。

k.有些问题出现了，不一定就是我们测试软件本身的问题，也可能是其他一些问题

导致的，如“手机通话时自动掉线”问题，这有可能是信道切换失败导致的，是网络的问题，不是我们手机软件本身的问题。类似情况还会很多，这都我们有着丰富的产品背景知识。

l. 编写bug report没有什么定式，没有绝对的范本，最基本的是能够让客户或目标修

改，浏览bug report人员看懂，而且在短时间内，而不需反复思考的。其他有时要考虑目标读者的一些喜欢。例如有些类似的bug到底是合并还是单独提交，bug的步骤划分(到底是每一步都为一点，还是有些点可以合并)。在这一点上我觉得“灵活和适应”是很关键的。

m.在发现一个Bug并填写完bug report之后，在review的时候，需要特别注意的一点是：这个bug report会不会让其他人还有联想或发挥的空间。一个好的bug report是不可以细分的, 换句话说就是这个bug是不会让他人觉得你还有些地方需要在测试一下，或许还有其他的问题。例如，有个测试人员发现在输入16这个数字(允许范围内)且提交时系统会返回一个错误：不能输入48以下的数字。这确实是一个错误，但是如果就只按现在的步骤提交，另一个可能会有这样的想法：是不是输入48以下的数字都会有这样的问题呢?这样他有可能要求你在测试其他的数据。这样就延长了这个bug的生命期，而且浪费了大家的时间。

n. Bug提交完毕后，并不是就万事大吉了，后续跟踪验证等还多着呢。

3． Bug提交之后需要注意的事项

a.如果编程人员需要问题重现，应尽量减少重现的步骤以达到用最少的步骤来重现

问题;这对编程人员来说是很有帮助发现问题根源的。因为最少的步骤可以开发人员迅速、准确的锁定问题的根源。

b.最好由报bug的人验证bug是否可以关闭。任何人都可以修复bug，但只有那个发

现bug的人才能够确信bug是否真正的已被修复。

c. 当你的bug报告以“not repro(不可重现)”打回给你时，先检查一个步骤是否有遗漏

或清晰，再去找编程人员。编程人员通常是在无法用bug报告中的步骤重现bug时才选择这个选项。

d.要对提交的bug时刻进行跟踪，要保持和编程人员的沟通交流，是bug及时得到解决，以免影响项目的整体进度。

我想，作为一名软件测试人员，即便再优秀、再喜欢这份工作，也会感觉到测试过程的枯燥乏味。有时候改掉一个bug，又会导致另一个或更多bug的出现，面对这种似乎无休止的进行下去的测试工作，心里难免有些烦躁。但是烦躁归烦躁，切不可让自己的情绪过多的影响到自己的工作，时刻都要做到认真负责、脚踏实地，希望我自己也能够这样努力下去。

五、写在最后：

最终你相信什么就能成为什么。因为世界上最可怕的两个词，一个叫执着，一个叫认真，认真的人改变自己，执着的人改变命运，不期待突如其来的好运，只希望所有的努力终有回报。

不要沮丧，不必惊慌，做努力爬的蜗牛或坚持飞的笨鸟，我们试着长大，一路跌跌撞撞，然后遍体鳞伤。坚持着，总有一天，你会站在最亮的地方，活成自己曾经渴望的模样。

新的一年来到了，有新的目标同时也有新的压力，重新背起行囊，继续前行吧，相信不忘初心，勇往直前的你最终可以开出一朵属于自己的一朵花儿来，加油。

六.絮叨：

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

愿你我相遇，皆有所获！ 欢迎关注微信公众号：程序媛一菲，下面这些硬核资源就是你的了。