近日看到一个帖子：

 我所在的公司目前就我一个测试，我一个人对接开发，对接产品，公司也没什么流程，我不知道我该做什么，也没有前人经验可以借鉴，我该怎么办？

看到有很多刚刚步入测试行业的测试工程师发出这样的疑问和求助：

•     公司如果只有我一个测试员，我该怎么做才能把公司的工作做好呢？
•     对于我个人发展来说，只有我一个测试，能有很好的发展前景么？
•     到底，这种情况下我该走还是该留呢？为什么会有这样的现象？

首先我们来分析一下，为什么现在这么多公司都只有一个测试人员呢？

 这种现象产生的原因大概有以下两种：

第一：因为国家现在支持鼓励自主创业，所以越来越多的初创型互联网软件公司拔地而起。

这种类型的公司，处于刚起步的阶段，资金都一般非常有限，所以基本只能承担得起他们认为必须存在的岗位。

比如开发——创造生产软件的人，销售或者运营——能够直接帮助公司赚钱产生盈利的人；

然后对于类似测试的岗位，是属于锦上添花，而不是必须存在的角色。

所以，你会发现，很多二三线城市的中小型企业，没有设立测试岗位，基本都是开发自己开发完做简单的自测就直接发布上线。

如果公司只设置了一个测试员的职位，也是司空见怪的，并且还说明该公司已经度过了最初始阶段，开始慢慢认识到测试岗位的重要性，这反而是一种成熟进步的体现。

第二：也是源于国内对测试工作不重视。

很多公司，认为测试员做的事情没有技术含量，点点点大法谁都可以做，所以让开发做完后顺便测一测，或者给到运营部门简单试一试，基本就可以上线了。

他们对专业测试工程师的技能没有认知，不能理解测试工作对产品质量的重要性，所以认为测试岗位可有可无。

设置一个测试员的岗位，对他们来说已经满足到极致了。一个测试员的尴尬处境

基于以上分析得出的目前互联网行业的现状，很多初入测试行业的测试员，在公司独立担当测试部门所有的工作，经常会遇到有心无力，寸步难行的尴尬处境。

一般在这样的公司里，是不会有任何规范的流程的，都是各部门的人根据自己的想法和意愿来开展工作。

比如：

•     开发编程完成之后，直接发个包给测试员进行测试，没有需求规格说明书来详细描述这个项目的业务流程和用户需求；
•     开发也没有流程来规范自己的单元测试，所以仅仅凭借自觉和个人使命感，很难要求他们每个人做到位，更别说提供相关的单元测试报告；
•     所以测试并没有写测试用例的依据和基准，只能自己一边熟悉开发给的软件，一边根据自己的理解来写测试用例，这样测试工作不仅效率很低，而且也容易导致测试用例设计不充分和测试不彻底的问题。
•     另外，开发对测试工作也没有认同感，经常连续修改或者新增加需求，然后直接给版本到测试，测试基本都是按照开发的节奏来开展工作，测试工作完全没有自主性。
•     经常，测试花了很多时间和努力测试产品，开了很多bug，开发并不会很积极的修复bug，当然也没有流程来推动bug的修复，自己一个基础测试员孤立无援，人微言轻，也说服不了开发，沟通效率很低，成果很差。
•     甚至，有时候，还没有等测试完成所有的测试工作，软件产品已经默默的上线了，自己也没有被通知。

然后线上产品出了严重的问题，又会找到测试，要测试来承担后果和责任。任何事情，好像都跟测试没有真正的关系，深觉自己的工作没有人重视，也没有人理解，感觉很被动，很无助。
 

 

那身处于这样的公司，独自一个人担任测试岗位，面对这么多的困难，我们应该怎么办呢？

很多人承受不住压力，也感觉自己无力扭转局面，就想到要放弃，要离职跳槽。

那除了选择逃避，我们难道没有别的方式可以尝试了么？

当然不是，这样的工作处境，如果你能很好的处理，可以加速你的个人成长，积累到别人得不到的经验值，甚至能帮你跟公司一起成长，实现共赢。

那么，要达到这样的目的，我们可以从以下这几个方面出发来开始行动
1、 跟领导多沟通

首先，跟公司上级领导沟通，找到自己作为一个测试员在公司的定位。

领导既然设置一个测试岗位，并且招聘你进来做测试工作，肯定是有自己初衷的，希望你能帮忙解决什么样的问题，并且达到什么样的效果，这是你需要通过沟通来明确的。

一般公司设置了测试岗位并且招聘到一个测试工程师，肯定是对这个岗位的输出有所期待的，任何一份工资和人力支出肯定都是期望有所回报的。

所以通过跟领导沟通，明确他希望你在这个岗位上达到什么样的效果，完成哪些工作，以及完成到哪个程度。

在这个基础上，你再结合自己的想法，落实一些实质的工作计划，并且提出一些建设性的意见和建议。

比如，领导希望你尽个人之力，完成所有的测试工作，包括测试文档和各个测试输出，并且产品质量不允许存在任何纰漏。

这样的要求，很显然，当前的现实状况是不允许的。

所以你就可以分析现状，表达出自己的难处，当然尽量不要显出是自己的能力不足而不能担当重任，而是现实骨感无法超越；然后可以提出一些实质性的建议。

如果是测试部门的初建阶段，一个人肯定是没有办法完成所有的工作的。

• 所以可以列出现有的工作量以及优先级，率先保证高优先级工作的质量和效率，

• 比如产品的主要且重要模块的功能和质量，必要的测试文档的输出等；

• 如果之后还有余力和时间，再覆盖次优先级的模块功能，完善各种细节和文档输出。

只有一个测试员的阶段，不建议自己去实现自动化测试，除非领导可以帮忙协调开发人员搭建自动化测试框架，并且协力去完成自动化测试的实现。

•     不然一个人肯定没有办法在保证项目发布质量的同时，再去维护一个自动化框架的。
•     所以这个时候，考虑自动化测试，不但不能节省人力和提高效率，反而会浪费时间和精力，适得其反。
   

建议让项目相关人员协助测试工作，一起保证产品质量。

•     比如开发把握好单元测试的质量，尽量把能够直接进行系统测试的产品交付给测试人员，保证有效的资源能被充分利用起来，达到理想的测试效果；
•     让运营部门人员参与到测试中，可以由你写出所有的测试用例，以及介绍一些主要的测试机巧和方法，然后分配任务到特定的人员。
•     可以由你自己主要重点模块的测试，其余部门人员分担一些其他的功能模块或者一些回归测试。
•     这样，一方面可以让相关部门人员知道测试不仅仅是点点点，而是有法可依，有技术可寻的，认识到测试工作的技术性和专业性；
•     另一方面，全员测试，最大程度的对产品进行测试，共同努力保证产品质量。

如果还是没有办法满足测试要求，也可以向领导申请招人名额，可是正式员工，也可以是实习生。 

• 不要害怕表达难处，也不要害怕提要求，如果是合理并且有充分理由的要求，领导不仅不会驳回，反而会觉得你是一个很有想法，而且有在为公司利益思考和努力的优秀员工。
• 当然，这些需求的提出，都必须建立在你充分且正确地评估了所有的测试工作量的基础上进行，最好能有可以量化的数据，以及一些不可规避但是可以预见的风险，一起呈现给领导并努力说服他，争取得到他的理解和支持。
• 这样以后工作中，有了强大的后盾，不管是部门之间的沟通，还是工作责任划分，都可以开展得更加顺利。

2 、充分学习产品业务

测试也应该多跟需求和产品部门沟通，充分理解公司的业务主线，熟悉产品的功能流程。

测试人员所需要必备的技能，其中之一就是业务能力，业务能力不足的测试工程师不是一个合格的测试人员！

何为业务能力？

就是你对当前你所测试的产品和功能模块的理解，以及你对你所在的行业的认知，还有相关产品的业务和知识的储备。

相信我们每一个从事在测试行业的人，平时在公司里都能发现一些这样的情况：

– 总有些人在需求分析会议的时候，能提出一些跟大家不太一样又很有建设性的建议；

• 也总有些人能在测试用例评审的时候，提出一些你没先到但是确实对用户场景很有针对性的测试点；

• 也总有些人拿到产品执行测试的时候发现bug的数量和质量都让其他人望其项背…

这就是业务能力的差异导致的对产品的理解和认知的差异。

虽然，这个需要一定时间的沉淀和丰富的经验积累，不是轻松简单容易可以获得的，但是，千里之行始于足下，业务能力的培养，就是从学习需求文档开始的，然后通过跟产品和需求的沟通和讨论过程中不断提高。

在这个基础上，你才能让自己的测试用例更加充分。

并且，如果需要别的部门人员协助测试的时候，你也能更好的分配工作，跟领导汇报的时候，也能更准确的评估测试工作量。测试过程中，才能更有效的避免漏测的情况，尽最大可能满足用户的需求。

而且，更多的沟通和交流，也能促进部门之间的合作，当用户需求发生变动的时候，或者测试过程中遇到需求不明朗的时候，也能更高效地确认并得到答案，良好的沟通总是能大大地提高工作的效率。
3、 制定并优化相关流程

观察并且通过各方位了解目前你能看到的整个团队的问题，梳理并总结给出你的建议。

一般只有一个测试岗位的初创型公司必然存在流程不规范甚至没有任何流程的弊端，所以协助公司制定流程，或优化现有流程是个势在必行的工作。

制定一个完善的流程，不仅能提高测试工作效率，也能让各部门的职责划分清晰明了，让公司业务运转更加顺畅。

制定测试流程，规范测试的工作，先从做好自己开始。 +规范测试各个阶段的输出。

如测试计划，测试用例以及测试报告等文档的输出内容和格式。

当然，因为是初期阶段，所有的测试文档不一定都是必须品，也不一定要特别详细并且完全符合规范要求，可以制定一个初级版本，设立多个可视化的小目标，允许在日后工作过程中一步一步地优化和完善；

+规范bug 的编写模板和跟踪处理流程。如测试提bug 的时候需要提供的必须包含的信息（步骤，数据和日志，以及现场截图等）；

bug处理过程中，无论开发还是测试修改bug状态的时候，必须要添加相应的说明备注，方便后续跟踪人员快速知晓整个过程。

制定部门之间的合作流程，帮助各部门协作更顺畅。 +规范产品管理需求的流程。

如需求分析阶段，必须提供规格说明书，以作为开发和测试开始工作的依据；

项目进行过程中，尤其是第一轮测试过程中，不建议增加新的需求；项目临近发布阶段，严禁加入新的需求；

产品需要上线或者发布，必须等到测试人员完成所有测试工作并且提交测试通过的报告文档; +规范开发对接测试的流程。

如开发交付产品的时候，需要提供单元测试报告，保证自测通过；开发修复bug 的时候，同样需要提供单元测试报告，或者至少提供自测结果以及对测试的建议，以帮助测试进行回归测试；

要求开发关闭bug为非修复状态的时候，必须跟测试沟通，得到确认允许后再关闭，避免开发和测试之间的冲突矛盾；

规定在项目临近发布阶段，所有重要的代码改动都应该慎重并且经过相关人员的审核，以避免严重的回归问题，或者发布后的线上问题。

制定各项流程只有，还需要在流程里说明，如果没有按照流程规范执行，导致的问题和带来的风险应该由流程打破者全权承担。这样才能更好的推动流程的执行，制定的流程才能发挥其最大的效益。

公司的流程制定以及管理，能很大程度的提高工作效率。测试人员有则可依，不会太被动，被产品或研发打乱了测试节奏；责任划分清晰，让大家都明确自己该做到的本分，以及应该承担的风险，这样才能让各部门的人协力合作，来保证我们的产品的质量。

 

04 丰富自身技术

小公司，测试部门只有一个测试员时，是高挑战，同时也伴随着着高机遇。

所以我们应该好好把握住机遇，让自己伴随着公司一起成长。

等公司足够成熟了，你如果可以独当一面，就可以担当起测试部门负责人的角色，成为测试部门的开创者。

但是，在这之前，我们需要先强大自己的知识体系，丰富自身的硬核技术。

丰富测试理论基础

从软件测试流程，到各种测试用例设计方法，以及各种类型的测试技巧，bug的处理流程和常用管理工具等。

这些基础知识都是需要完善和扎实，只有熟练掌握了这些测试理论知识，才能形成自己的测试思维，成为一个专业并且能指导他人的测试工程师；

否则，没有这些测试基石，一切高楼大厦都只能是空想而已。

在公司项目中去实践所学习的测试方法和技巧。

理论总是需要实践才能出真知，所以能学以致用才是真正的学会并掌握。

所以在工作中多实践并总结经验，工作之余再不断丰富知识理论，也可以去参加一些测试工程师的培训班，实践和理论相辅相成，让自己的知识储备日益丰厚。

最后，也可以学习一些进阶的相关技术，比如公司常用的开发语言，数据库的一些知识，以及一些常用的测试工具，如抓包工具，日志分析定位工具，自动化测试工具和性能测试工具等。

想到达到一定的高度，这些技能的掌握也是必须的。

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

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取