不管你是因为兴趣想转软件测试，还是因为高薪选择软件测试，小编在这里就跟大家说说，软件测试零基础可以学吗？

       一、想要零基础学好软件测试，当然需要对测试有一个良好的认知。

       　1、什么是软件测试?

       软件测试(英语：Software Testing)，描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出之间的审核或者比较过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

       　2、怎样才算一个真正的软件测试工程师?

       真正的软件测试工程师算是半个产品经理，半个开发工程师。有人觉得这个标题有点讽刺，真正的测试?难道我们不是真正的测试，平常做的都不是测试的工作吗?其实不肯定也不否定，但这是一个包含关系，如果只是评审+用例编写执行，那么确实不是一个真正的测试。

       正如标题那样，我认为真正的测试 =“半个产品+半个开发”。

       半个产品，主要体现在理解这个需求为什么要做?其核心价值在哪里?吸引用户的特点是什么?意味着在评审阶段，你除了帮助完善功能需求外，更重要的是理解这个需求对于用户有什么价值，你是用户你会怎么想有什么感受,不能简单的走完流程就可以了，比如一个播放视频类应用， 多样性 流畅度 简易性 快速性等 这是在评审之后可以总结出来的，那么抱着这个价值点，围绕这我们的整个测试流程，往往能够发现不一样的地方。比如还是播放类应用，在我了解个特性后，在测试过程中我会更加留意播放方面的性能，以及兼容性，在我设计测试方案的时候就会标明这几个测试重点，以便我自己或者组员能够在测试过程中多加留意这部分的测试点，然后在设计测试用例的时候会提高优先级和覆盖率。可以发现，测试有了测重点。

       半个开发，其实个人认为这是偏向于灰盒测试了，体现在一个需求，你除了要明确这个需求的业务逻辑，其代码逻辑(数据流逻辑)也是需要知道的，从后台获取的json数据结构到客户端展示再到存储至本地数据，这一个流向，都是需要去了解并测试的(这部分参照之前写的测试分析文章)，所以测试验证的不仅仅是功能层面的东西，还是内部的具体实现(当然，具体到类方法的测试那是测试开发的职能，不关咱测试的事)，我们要保证的，就是这一阶段数据的正确性和容错性。这样做的好处是，能从内部发现缺陷，在出现问题的时候可以大概定位到问题出在哪，在出问题面对boss的质疑能够把责任丢给开发，哦不，是更好的解决问题。

       那么半个开发还体现在对工具效率的提升上，能够通过小脚本，小框架去提升测试效率，这要求对于基本的语言要求是必须的，大公司面试的某一轮考研的就是你的代码能力，所以测试还是半个开发这一点是毋庸置疑滴。

       　二、认识了软件测试，也认识了软件测试工程师，不知道软件测试流程，零基础怎能学好软件测试?所以接下我们对软件测试的流程做一个简单说明：

       　　1、测试项目启动与规划

       一般地，项目启动过程组包括两个过程[参见PMBOK2004版]：即制定项目章程和制定项目初步范围说明书;而项目规划过程组则会综合项目的成本、范围、时间、质量、风险、人力、沟通、采购等因素制定项目计划，该项目计划将用于指导项目的实际执行。

       对任一项目而言，有三个文件是非常重要的。即：项目章程、项目范围说明书，项目管理计划。这三个文件均产生于项目启动阶段和项目规划阶段。其中项目章程被认为是三大文件之首(项目章程、项目范围说明书，项目管理计划)。一个项目，不论大小，都应该有项目章程。

       一个典型的项目章程包括如下内容：

       1)项目名称及背景描述;

       2)项目经理任命及职责范围界定;

       3)项目业务需求描述;

       4)项目发起的原因;

       5)主要项目干系人及其初步需求;

       6)产品及预期交付成果描述;

       7)项目假设和约束条件。

       项目章程由项目发起人(Sponsor)签发，自签发之日起，项目经理即获得法定权力。项目经理在获得法定权力之后的第一动作是制定项目初步范围说明书。为了制定这份文档，他/她将广泛地收集来自项目发起人的需求，以便在项目计划正式编制之前，与项目发起人在项目范围的理解上达成一致。项目初步范围说明书还将在后续项目范围规划过程中进一步细化，并融入项目客户、执行组织、项目干系人等各方面需求，进而形成完整的项目范围说明书。项目初步范围说明书编制完成以后，项目经理将进入项目计划编制阶段。这个阶段将会涉及项目管理方方面面的规划、计划。比较典型的有项目范围基线、项目成本基线、项目进度计划、项目质量计划、项目风险分析及应对计划、人力资源计划、项目沟通计划以及项目采购计划。这些计划、规划经过权衡、调整，最终将集成为一个完整的项目管理计划。项目管理计划经由项目发起人、高级管理层审批以后，即可生效。此后，项目经理将召开项目开工会议(Kickoff meeting)，宣布项目正式开始进入执行阶段。

       项目启动阶段的项目章程和项目初步范围说明书(或SOW)，也可以体现在分包或采购合同中。这在软件外包服务型企业中最为常见。通常，伴随合同到达项目经理手中的还有项目建议书(Project Proposal)，项目建议书由项目发起人制定，内容和项目章程中有关产品、可交付成果的描述大致类似，此外，还应包括对项目经理成功完成此项目的一些指导性建议。项目经理根据合同、SOW以及Project Proposal进行综合考虑，与相关干系人磋商，在项目团队相关专家的帮助下，制定出合适的项目管理计划。

       上面讨论的是一般项目启动过程组与规划过程组。具体到测试项目的启动与规划，工作内容也是类似的。读者朋友请根据所在测试项目的特点做适当调整。需要交待清楚的是测试项目启动与规划过程组有可能与其他六个过程组有重叠。比如，规划过程组有可能在整个项目生命期内都有更新和完善(典型的有滚动波浪式规划)。

       对于整周期软件开发项目的测试而言，上述过程组的内容会有较大的差异。比如：项目章程将重点关注开发，而不会过多讨论测试相关的工作。对于这一类型的软件测试，笔者建议在任命开发项目经理的同时，由项目经理[适用于项目型或强矩阵组织]或高层经理[适用于弱矩阵或职能型组织]指定项目测试经理。测试经理应根据项目章程、项目初步范围说明书和项目建议书尽早开始软件测试相关规划和设计(即会先粗略地进行软件测试需求分析和软件测试设计，以后再进一步细化)，并和项目经理沟通、协调，以将一些重要的信息及时反映给项目经理，从而使项目计划能较好地支持测试工作的开展。

       　2、软件测试需求分析

       理论上，软件测试需求是源于软件需求的，而软件需求又是源于用户需求的。然而，有些时候在分析软件测试需求时并不存在已经文档化的软件需求规格说明。在这种情况下，要分析软件测试需求可能仍然需要追溯到用户需求(当发生这种情况时，普通测试工程师会很吃惊地发现自己原来还肩负着需求开发工程师的部分职责。是的，事实上，资深的软件测试工程师会发现软件测试这个职位几乎涉及所有的开发技能和部分管理技能。)由于后者涉及需求工程的专门知识，本文略过不做细述;这里重点讨论前者。在一个规范化的软件需求规格说明中，用户需求是由更高层次的业务需求(体现在项目章程、SOW、项目建议书等文档中)细化而成，它通常描述了用户使用该软件系统会涉及到的不同的执行路径、工作逻辑以及所预期的处理结果。在UML表示方法中，用户需求通常通过Use Case来进行刻画。接下来，用户需求将进一步转化为三类需求项，即功能需求项、性能需求项以及约束性需求项。这三类需求项就是通常意义上的软件需求项。管理这三类需求项的矩阵被称为需求矩阵。