因为兴趣选择零基础入门软件测试，因为高薪选择零基础转行软件测试，不管你是什么情况，小编今天就教你零基础如何学好软件测试，让你离梦想更进一步!

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

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来进行刻画。接下来，用户需求将进一步转化为三类需求项，即功能需求项、性能需求项以及约束性需求项。这三类需求项就是通常意义上的软件需求项。管理这三类需求项的矩阵被称为需求矩阵。

理论上，在测试资源许可并且确有必要的前提下，测试的使命将是验证和确认待开发的软件及其中间产品满足需求矩阵各个需求项。(注意：为了简化讨论，这里笔者没有把需求的验证与确认纳入进来，实际上这部分工作也是软件测试工作的重要组成部分。详细论述请参阅拙文《试论软件测试学科架构建设》)然而，几乎没有几个公司或开发团队能够提供这类测试所需的诸多的资源，此时，一种可行的策略是将待测试的软件需求项按照优先关系进行排序，以帮助测试经理决策在既定资源的情况下，应该如何统筹安排测试工作。

软件需求项是测试需求分析的起点，这一点在工程实践中并不绝对。对于不同阶段的测试(这里主要指单元测试、集成测试、系统测试和验收测试，暂不考虑验证技术和需求设计确认)，测试需求开发所涉及的工作内容和方法都会略有差异。例如，如果是一个验收测试，那么，除了个别的需求需要做进一步明确外，几乎可以将测试需求等同于用户需求和业务需求(由于该类测试是以客户为主体，因此并不需要向下追溯到软件需求);又如，如果是系统测试，除了需要对不具备可测试性的软件需求项进一步开发外，几乎可以对软件需求和测试需求不做区分。再如，如果是集成测试，测试需求应该从概要设计规格说明中导出。如果尚不存在概要设计规格说明，就需要从软件需求规格说明出发，与软件设计人员协同工作，具体定出构成系统的各个模块、子系统、分系统的功能、性能、约束性条件以及相互接口关系。根据协同工作的结果，开发出对应的测试需求。最后，如果是单元测试，测试需求应该从详细设计规格说明中导出。如果项目不存在概要设计规格说明，就需要从概要设计规格说明出发，与软件设计人员明确每个模块内部的对象属性与方法以及对象与对象间的通信关系。根据此结果，进一步开发相应的测试需求。相应地，上一节所说的对软件需求项进行优先关系排序在实践中要变通地理解为对测试需求项进行优先关系排序。

哪些测试需求项应该先测，哪些可以延后，那些是可以并行等，都需要在测试需求开发阶段一并分析清楚。除了对软件需求项、测试需求项做优先关系排序、对不具备可测试性或不确定的需求进一步细化、明确化之外，测试需求开发阶段的工作还包括分析各测试需求项之间可能的时间关系排序。

读者朋友可能会问，对于整周期的开发项目，以上论述是否意味着测试需求开发的依据文档是否要根据测试所处的阶段而不断调整呢?是的，笔者认为这也是完全必要的。我们不能指望软件需求项能够描述清楚集成或单元测试阶段的测试需求。

测试需求的开发总是有赖于相应层次的软件规格说明书(只有在开发团队不能提供的情况下才确有必要循着“详细设计规格说明->概要设计规格说明->软件需求规格说明->用户需求规格说明->项目章程、合同、项目建议书、工作说明书等”的顺序往前追溯)。通常相关依据文档的可测试性越好，测试需求开发所需要的工作量越少。

三、零基础如何学好软件测试，不懂测试方法怎能事半功倍?

1、从测试设计方法分类

Black box黑盒测试：把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。从软件的行为，而不是内部结构出发来设计测试.

White box白盒测试：设计者可以看到软件系统的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择。

Gray box. 灰盒测试：介于黑盒和白盒之间

总结： 实际工作中，对系统的了解越多越好。目前大多数的测试人员都是做黑盒测试，很少有做白盒测试的。 因为白盒测试对软件测试人员的要求非常高，需要有很多编程经验。做.NET程序的白盒测试你要能看得懂.NET代码。做JAVA程序的测试，需要你能看懂JAVA的代码。 如果你都能看懂了，你还会做测试么

2、从测试是手动还是自动上分类

Manual Test 手动测试：测试人员用鼠标去手动测试 (测试GUI)

Automation 自动化测试：用程序测试程序 (测试API)

对于项目来说， 手动测试和自动化测试同等重要，都是保障软件质量的方法。 目前大部分的项目组都是手动测试和自动化测试相结合。因为很多测试无法做成自动化，很多复杂的业务逻辑也很难自动化， 所以自动化测试无法取代手动测试。

对于软件测试人员个人发展来说， 做自动化测试是个挑战，也是测试人员发展的一个方向， 需要测试人员学习大量的开发知识(开发的知识真是学无止境啊)。 从长远角度来看，自动化测试肯定是越来越吃香的。

而手动测试比较适合刚工作不久的人，手动测试最大的缺点就是技术含量低，单调乏味，容易废人。

总的来说，手工测试胜在测试业务逻辑，而自动化测试胜在测试底层架构。

如果被测试的程序可测试性比较好， 很有必要做成自动化测试。 能做自动化的尽量做成自动化， 下面这些情形是可以做自动化的：

1) 测试存储过程。 例如用C#去测试存储过程

2)测试Web servies. 例如： 用SoupUI工具，或者C#,Java 去测试Web servies。

3)界面和业务逻辑分离的系统，比如，MVC，MVP架构， 或者WPF 程序。 可以用测试脚本去测试这些程序的API。

3、从测试的目的分类

功能测试

测试的范围从小到大，从内到外， 从程序开发人员(单元测试)到测试人员，到一般用户Alpha/Beta测试

Unit Test 单元测试：在最低的功能/参数上验证程序的准确性,比如测试一个函数的正确性(开发人员做的)

Functional Test 功能测试：验证模块的功能 (测试人员做的)

Integration Test 集成测试：验证几个互相有依赖关系的模块的功能 (测试人员做的)

Scenario Test 场景测试：验证几个模块是否能完成一个用户场景 (测试人员做的)

System Test 系统测试：对于整个系统功能的测试 (测试人员做的)

Alpha 测试：软件测试人员在真实用户环境中对软件进行全面的测试 (测试人员做的)

Beta 测试：真实的用户在真实的用户环境中进行的测试, 也叫公测 (最终用户做的)

非功能测试

一个软件除了基本功能之外，还有很多功能之外的特性，这些叫“Quality of Service requirement”服务质量需求。没有软件的功能，这些特性都无从表现出来，因此，我们要在软件开发的适当阶段-基本功能完成后做这些测试。

Stress test 压力测试：验证软件在超过负载设计的情况下仍能返回正确的结果，没有崩溃

Load test 负载测试：测试软件在负载情况下能否正常工作

Performance test性能测试：测试软件的效能，是否提供满意的服务质量

Accessibility test：软件辅助功能测试-测试软件是否向残疾用户提供足够的辅助功能

Localization/Globalization：本地化/全球化测试

Compatibility Test：兼容性测试

Configuration Test：配置测试-测试软件在各种配置下能否正常工作

Usability Test：可用性测试 –测试软件是否好用

Security Test：软件安全性测试

性能测试

性能测试要求测试人员熟练性能测试工具，比如QTP, LoadRunner, Jmeter。 Visual Studio也提供了很多性能测试的工具. 要求测试人员对低层协议非常理解和编写脚本

性能测试非常有技术含量， 很有发展前途， 是软件测试人员的一个职业发展方向。

安全性测试

安全性测试的内容很广， 非常有难度啊。 我只接触过XSS(跨站脚本攻击)和SQL注入攻击。

安全性测试非常有技术含量， 我认为也是软件测试人员的一个职业发展方向

4、按测试的时机和作用分类

在开发软件的过程中，不少测试起着“烽火台”的作用，它们告诉我们软件开发的流程是否畅通。

Smoke Test：“冒烟”–如果测试不通过，则不能进行下一步工作

Build Verification Test(BVT)：验证构建是否通过基本测试。

Acceptance Test：验收测试，为了全面考核某功能/特性而做的测试

BVT测试是一种Smoke Test, 指Build生成好之后，自动运行的自动化测试脚本来检查这个Build的基本功能。 如果BVT测试失败了，需要开发人员马上修改，重新生成Buil

5、按测试测策略分类

Regression Test 回归测试：对一个新的版本，重新运行以往的测试用例，看看新版本和已知的版本相比是否有退化 (regression)

Ad hoc Test 探索性测试：随机进行的，探索性的测试。

Santiy Test：粗略的测试， 只需要执行部分的测试用例

Regression Test 回归测试：

对软件测试人员来说就是重复测试，所以回归测试最好是自动化的，否则测试人员就要一遍又一遍地重复测试。

1）开发人员做些小改动，就需要测试人员做回归测试。确保现有的功能没有被破坏;

2）Bug Fix 也需要回归测试，确保新的代码修复了Fix, 也确保现有的功能没有被破坏;

3） 项目后期，需要做一个完整回归测试， 确保所有的功能都是好的。

四、零基础如何学好软件测试?我们都知道盲区这个概念，当然它在软件测试中也是存在的，那么我们该如何避免这些测试盲区呢?

1、充分理解软件需求

需求方面的如果理解有误或者分析遗漏，那么将对软件功能测试很难全面覆盖。基本功能测试有遗漏的话，那是不可饶恕的，所以在测试前以及测试过程中要多注意软件需求文档、产品规格书，尤其是没有文档化的规格更改、需求变动，这都是很容易出现误测或漏测的。这在项目进程中需要项目成员之间加强信息沟

通。

2、制定一份完善的测试方案

测试方案包括的内容比较多，这里我们主要指测试用例，测试前需要制定一套完善的测试用例，完善指我们的测试用例至少要覆盖所有软件需求，同时对于边界测试、中断测试、性能测试都要涵盖。测试用例编写很简单，但编写高质量的测试用例真的不容易，至少，让我称之为高质量的不多。测试方案应该要经过评审的，至少要和开发人员一起有针对性地讨论下测试内容、重点和需求。

3、多采取交叉测试

也就是同一项目组的不同测试模块的测试人员互换模块，相互测试。由于每个人的测试角度、思维方式等都不太一样，所以这种互测是发现更多问题的一个有效途径。事实证明，这种效果非常棒!

4、多学习同类产品的bug库

同类产品的bug库对于测试人员而言，是个非常好的资源，测试人员从那里可以了解更多产品容易出问题的地方，甚至很多问题本产品上就潜在着，还未被发现。

5、多沟通、交流

每一阶段，项目测试组长都应该组织小组测试人员多多交流，分析、总结下测试中遇到的问题，由于是一些概率性以及容易被忽略的问题，单个测试人员测试时可能遇到，但并不以为意，这样，通过讨论、交流，能够加强测试人员对问题的印象，在接下来测试中加强薄弱环节的测试。

6、加强相关产品知识学习

尤其是一些技术原理上的东西，只有深入了解了，测试上才能更加发现更多原来力所难及的问题，如协议层的问题。

7、经常测试、充分测试

测试上有个原则：及早测试、经常测试、充分测试。要发现更多的问题、减少测试盲区，多测是少不了的。

其实，更广义地理解，测试盲区还涉及到测试软件质量目标和针对性问题，测试还要注意把握一个度和量，我们要知道软件在生命周期内的质量目标是什么。过犹不及，将大量时间浪费在测试一些用户永远无法涉及到或者无关轻重的地方，这都是很盲目的!

五、零基础如何学好软件测试?我们了解了测试定义、流程、方法、盲区之后，我们还需要能写出一份完美的测试报告：

我们要认识到软件测试报告远非一种形式，更多是一个测试活动的总结，项目是否结项的重要参考和依据。因此本文指导一些才从业不久的朋友怎么编写一份高质量的测试报告。

1、要有明确结论

纵观一些软件测试报告，可能测试人员基于规避自己的责任，或者迫于软件开发经理的压力，导致在报告中尽写一些模棱两可的结论。这样的测试报告是没有任何作用的，更多体现了测试团队的懦弱和无能。一个有效的测试报告，关键是有一个建立在真实测试数据上，客观、公正的明确结论。公司领导把质量交付给你，是希望你能保证公司的软件质量，如果结论都闪烁其词，你让公司怎么相信、支持测试团队。

2、每一条结论都是建立在事实、数据上

前面已经提到，测试报告中最重要的就是要有明确的结论。有可能是一组数据，也有可能是一句话。这些结论不管以何种形式展现出来，有个重要的原则：每条结论必须建立在事实、数据上。测试结论不能依照少量的不可靠的数据进行推测，更不能凭空捏造。否则，整个测试报告就真正沦为了一个形式，可能还会因此导致一些未知的负面后果。

3、测试报告中结果应尽可能图文结合方式展现出来

测试报告的读者往往是项目经理，或者公司高层，更有甚者为软件买单客户。所以测试报告应尽可能以直观的形式展现出来。比如数据最好以列表的形式展现出来，测试迭代情况最好以折线图展现出来，并在图表下配以文字说明。这样的测试报告不仅仅是赏心悦目，更让高层见到了测试团队的专业性，从而更容易获得认可。

4、测试报告中，必须客观填写，但可以在结尾给予一定的建议

测试报告中很关键的一点就是，必须客观真实的反应软件测试的质量检测结果。所以在报告中，应该排除过多的个人因素，客观的去填写结果、说明和报告。但是，如果你有一些想法和建议，也可以在报告结论之后进行附加说明。我一直认为测试人员除了发现缺陷，还有一些具有创造性的东西。

下面说下一个标准测试报告应该包含的内容信息：

1)概述，包括本次测试的目的，测试的背景介绍。

2)测试环境，包括测试软硬件环境及配置，以及测试环境的网络拓扑图

3)测试的一些参考资料

4)测试参与人员，以及投入的时间情况说明

5)测试的进度情况，包括计划进度和实际进度

6)测试情况介绍，包括测试的内容项说明。如功能测试具体的测试项，测试通过情况;性能测试的测试项，测试通过情况等

7)缺陷的统计和分析，包括迭代次数，缺陷的分布情况，缺陷的覆盖情况，缺陷的发展趋势等

8)本次测试的结论

9)测试人员就本次测试的一些建议

六、零基础学好软件测试是为了增加我们自身的一种技能、为了明天的一份高薪工作，学以致用，我们也应该在这里了解一下软件测试工程师日常的工作是什么?

日常的工作流程一般是这样的(以一个版本迭代为周期):

评审新需求，记录关键点–>编写测试点(用例)–>测试之前向开发了解部分实现–>执行测试(翻阅代码，查看主逻辑走向<可选>)–>提交BUG–>回归BUG(查看BUG代码改动)–>新需求的性能评估(可选)–>发布前的系统测试(结合自动化)–>发布–>自动化用例的补充(可选)–>业务逻辑总结归总–>休息

在一天工作的八个小时中，有位资深软件测试工程师是这样安排的：30%的时间用于评审用例维护等准备以及后期工作;20%的时间用于执行测试用例，BUG回归;50%的时间用于自动化和新技术学习，引入!不知道你的一天会怎么安排呢?

零基础如何学好软件测试，本文给你提供的是一个思路，您需要在这些概况内容的基础上去深入了解、钻研，比如文中有提到测试需求，那么你还需要拓展如何收集需求、如何定位需求等内容;文中提到黑盒测试，那么你还需要拓展什么是黑盒测试、黑盒测试的特点优势是什么、在什么情况下使用以及如何使用黑盒测试等内容。如果你觉得自己没有很强的毅力，但你还想快速上手软件测试，那么你来达内软件测试培训机构，企业总监级授课讲师手把手带你入门，让你零基础学好软件测试，给自己4个月，给自己一次逆袭的机会!

免责声明：内容和图片源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。