一 软件测试行业基本介绍
1. 为什么需要软件测试
一款软件从无到有会经历很多开发阶段由不同的人来参与开发，所以最终产出的软件功能会存在问题。因此为了保证软件的功能是可用的，我们必须进行测试；
当前的软件行业已经不再是功能为主了，用户不仅仅只盯着功能是否满足需求，还会对软件是否容易上手，执行效率是否OK...等一系列其他体验都有了更高的要求，所以这也需要我们对软件进行大量的测试。
2. 为什么选择软件测试
国内的软件行业对于专业的软件测试人员需求是慢慢变大；
有些人喜欢创造世界所以他们做了开发，而我们就是希望世界更加完美。
3. 为什么不让开发自己做测试
当前行业有许多的测试从业人员本身之前都是开发岗；
专业度：软件测试和软件开发分别属于软件行业当中两个不同的技术方向。所以让专人做专事对质量更加有保证；
思维定式：在软件的开发周期中，对于程序员来说他们大多数的时间都是思考如何实现具体的软件功能，而不会从用户的角度考虑如何去“奇葩”的使用这些功能；
测试力度：相对于开发来说，产品就相当于是他们的“孩子”，所以“下手“就不会那么狠。
二 软件测试基本介绍
软件知识简介
软件的组成：程序、数据、文档
软件的分类：按层次划分：系统软件，应用软件
按组织划分：商业软件，开源软件
按结构划分：单继软件，C/S结构，B/S结构
1. 软件测试定义
使用人工或自动化手段运行程序，为了发现软件的错误而执行检验的一个过程。
2. 软件测试目的
以最少的人力、物力、时间找到软件中的缺陷并修改，从而回避风险。
3. 软件测试作用
通过测试工作可以发现并修复软件当中存在的缺陷，从而提高用户对产品的使用信心；
测试可以记录软件运行过程中产生的一些数据，从而为决策提供数据支持；
测试可以降低同类型产品开发遇到问题的风险。
4. 软件测试的七个原则
所谓的测试的原则就是我们在执行测试工作时必须要遵守的一些规则。
测试显示软件存在缺陷（Testing shows presence of defects）
测试只能证明软件中存在缺陷，但并不能证明软件中不存在缺陷。软件测试是为了降低存在缺陷的可能性，即便是没有找到缺陷，也不能证明软件是完美的。
穷尽测试是不可能的（Exhaustive testing is impossible）
现在软件的规模越来越大，复杂度越来越高，想做到完全性的测试是不可能的。在测试阶段，测试人员可以根据风险和优先级来进行集中和高强度的测试，从而保证软件的质量。
测试尽早介入（Testing early）
为什么测试要尽早介入呢，简单的说就是保证软件质量，降低风险和成本。测试人员一般在需求阶段就开始介入，使缺陷在需求或设计阶段就被发现，缺陷发现越早，修复的成本就越小。
缺陷集群性（2/8原则）（Defect clustering）
缺陷集群性表明小部分模块包含大部分的缺陷。软件测试中存在Pareto原则：80%的缺陷发现在20%的模块中；一个功能模块发现的缺陷越高，那存在的未被发现的缺陷也越高，故发现的缺陷与未发现的缺陷成正比。
杀虫剂悖论（Pesticide Paradox）
反复使用相同的杀虫剂会导致害虫对杀虫剂产生免疫而无法杀死害虫。软件测试也一样。如
果一直使用相同的测试方法或手段，可能无法发现新的bug；为了解决这个问题，测试用例应当定期修订和评审，增加新的或不同的测试用例帮助发现更多的缺陷。测试人员不能一直依赖于现有的测试技术，而要不断的提升测试方法以提高测试效率。
测试活动依赖于测试内容（Testing is context dependent）
根据业务的不同，软件测试内部也分为不同的行业，比如游戏行业、电商行业、金融行业。不同的行业，测试活动的开展都有所不同，比如测试技术、测试工具的选择，测试流程都不尽相同，所以软件测试的活动开展依赖于所测试的内容。
没有错误是好事谬论（Absence of error-fallacy）
有可能99%没有bug的软件也是不能使用的。如果对错误的需求进行了彻底的测试，这种情况就发生了。软件测试不仅是找出缺陷，同时也需要确认软件是否满足需求。如果开发出来的产品不满足用户的需求，即便找到和修复了缺陷也作用不大。
三 测试对象
对于当前的测试行业来说我们最经常测试的主体就是软件（主体功能），但是需要我们明白的是一个软件也不仅仅只有功能需要测试。我们可以将软件分为三个部分组成：功能集合+使用说明+配置数据。对于一款软件来说从无到有需要不同的过程，我们可以将这个过程分为不同的阶段，然后每个阶段都会相应有测试对象。
1. 需求分析阶段：各种需求规格说明；
2. 软件架构设计：API接口文档（接口测试）；
3. 编码实现阶段：源代码（白盒测试、单元测试）；
4. 系统功能使用：软件功能主体（当前行业做的最多的一种测试）。
四 测试级别（测试阶段）
软件的开发都会依据相应的开发模型，而测试级别指的就是在这个模型当中我们人为定义的开发步骤。
其中对于测试来说我们最常见的级别分类如下：
1. 单元测试
单元测试是完成最小的软件设计单元（一般就是类、函数、组件）的验证工作，目标是确保模块被正确的编码，通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。
2. 集成测试
通过测试发现与模块接口有关的问题。目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构，应当避免一次性的集成（除非软件规模很小），而采用增量集成。
3. 系统测试
根据软件需求规范的要求进行系统测试，确认系统满足需求的要求，由测试人员充当用户的角色对软件的主体功能进行测试。
4. 回归测试
当发现并修改缺陷后，或在软件中添加新的功能后，重新测试。用来检查被发现的缺陷是否被改正，并且所做的修改没有引发新的问题。回归测试可以通过人工重新执行测试用例，也可以使用自动化的工具来进行。
5. 验收测试
配置审查确保已开发软件的所有文件资料均已编写齐全，并分类编目。
Alpha测试是由用户在开发者的场所来进行的，在一个受控的环境中进行测试。
Beta测试由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件。
五 系统测试分类
1. 功能测试：验证当前软件主体功能是否实现 。
2. 兼容性测试：验证当前软件在不同的环境下是否还可以使用。windows环境能使用吗？Linux环境能使用吗？谷歌浏览器能使用吗？其他浏览器呢？不同的设备上呢？mac？iPad？
3. 安全测试:验证软件是否只是对授权用户提供功能使用。比如银行卡，支付宝等等。
4. 性能测试:相对于当前于软件消耗的资源，产出能力；运行效率。
六 常用系统测试方法
1.按测试对象分类
白盒测试：软件底层代码功能实现，同时逻辑正确。
黑盒测试：测试软件外在功能是否可用（点点点）。
灰盒测试：介于两者之间（接口测试）。
2.按测试对象是否执行分类
静态测试：测试对象不运行，侧重文档和界面。
动态测试：将软件运行在真实环境当中。
黑盒测试有可能是动态测试（运行程序，看输入输出），也有可能是静态测试（不运行，只看界面）
白盒测试有可能是动态测试（运行程序并分析代码结构），也有可能是静态测试（不运行程序，只静态察看代码）
动态测试有可能是黑盒测试（运行，只看输入输出），也有可能是白盒测试 （运行并分析代码结构）
静态测试有可能是黑盒测试（不运行，只察看界面），也有可能是白盒测试（不运行，只察看代码）
3.按测试手段分类
手工测试：由测试人员手动的对被测对象进行验证，优点就是可以灵活的改变测试操作和境。
自动化测试：两种形式：一种是自己写测试脚本，另外一种是通过第三方测试工具对被测对象进行测试。
优点：高效率完成人不能做的测试。
七 软件质量特性
描述当前软件是否好用，在当前的软件行业里面我们所采用的一套标准是基于ISO这个组织制定的， 从软件测试角度而言，测试工程师需要了解每个特性及其子特性，以便于在分析测试需求、提取测试需求及评价被测对象时有的放矢，依据标准开展有效的测试活动。
1. 功能性：指软件在指定条件下使用时，满足用户明确和隐含需求的功能的能力。
适合性：软件为指定的任务和用户目标提供一组合适功能的能力；
准确性：软件提供具有所需精确度的正确或相符的结果或效果的能力；
交互操作性：软件与一个或更多的规定系统进行交互的能力；
保密安全性：软件保护信息和数据的能力，以使未授权的人员或系统不能阅读或修改这些信息和数据，而不拒绝授权人员或系统对它们的访问；
功能性依从性：软件遵循与功能性相关的标准、约定或法规以及类似规定的能力。这些标准要考虑国际标准、国家标准、行业标准、企业内部规范等；
2. 易用性：指在指定条件下使用时，软件被理解、学习、使用和吸引用户的能力。
易理解性：软件使用户能理解软件是否合适，以及如何能将软件用于特定的任务和使用环境的能力；
易学性：软件使用户能学习其应用的能力；
易操作性：软件使用户能操作和控制它的能力；
吸引性：软件吸引用户的能力；
易用性依从性：软件遵循与易用性相关的标准、约定、风格指南或法规的能力。这些标准要考虑国际标准、国家标准、行业标准、企业内部规范等，如企业内部的界面规。
3. 可靠性： 可靠性是指软件在指定条件下使用时，维持规定的性能级别的能力。可靠性要求有两个重要的概念：平均故障修复时间（mean time to repair，MTTR）、平均无故障时间（mean timebetween failures，MTBF），MTTR值越小，说明故障修复时间越短，故障处理响应速度较快，MTBF值越大，说明软件故障率低，系统可靠性高。
成熟性： 软件避免因为某些错误而导致失效或故障的能力；
容错性： 在软件出现故障或者违反指定接口的情况下，软件维持规定的性能级别的能力；
易恢复性： 在失效发生的情况下，软件重建规定的性能级别并恢复受直接影响的数据的能力；
可靠性依从性： 软件遵循与可靠性相关的标准、约定或法规的能力。
4. 效率性：效率是指在规定条件下，相对于所用资源的数量，软件可提供适当性能的能力。
时间特性：在规定条件下，软件执行其功能时，提供适当的响应和处理时间以及吞吐率的能
力，即完成用户的某个功能需要的响应时间；
资源利用性：在规定条件下，软件执行其功能时，使用合适的资源数量和类别的能力；
效率依从性：软件遵循与效率相关的标准或约定的能力。
5. 可维护性：可维护性是指软件可被修改的能力。修改可能包括修正、改进或软件对环境、需求和功能规格说明变化的适应。
易分析性：软件诊断软件中的缺陷、失效原因或识别待修改部分的能力；
易改变性：软件使指定的修改可以被实现的能力；
稳定性：软件避免由于软件修改而造成意外结果的能力；
易测试性：软件使已修改软件能被确认的能力；
维护性依从性：软件遵循与维护性相关的标准或约定的能力。
6. 可移植性：可移植性是指软件从一种环境迁移到另外一种环境的能力。
适应性：软件无须采用有别于为考虑该软件的目的而准备的活动或手段，就可能适应不同指定环境的能力；
易安装性：软件在指定环境中被安装的能力；
共存性：软件在公共环境中同与其分享公共资源的其他独立软件共存的能力；
易替换性：软件在同样环境下，替代另一个相同用途的指定软件产品的能力；
可移植性依从性：软件遵循与可移植性相关的标准或约定的能力。
八 软件测试流程
1. 需求分析评审
需求分析目的是理解需求，理解业务
弄清楚我们的产品有哪些功能？有哪些非功能性需求？
明白我们的用户群体是什么？用户会如何来使用我们的产品？
需求是否合理？技术实现难度？
具体执行如下：
2.测试需求分析
当对需求有完整和全面的理解后，接下来我们需要制定详细的测试计划，为即将开始的测试工作做好充足的准备
资源估算：整个项目需要多少资源？硬件资源，人力、时间资源等
进度控制：每个测试活动时间点控制
风险控制：对于在测试活动过程中出现问题的解决方案
资源配置：如何更有效率的使用资源
验收标准：文档、项目、测试过程的验收标准定义
测试策略：测试中使用的测试策略
3. 测试用例设计
测试用例设计是软件测试工作的灵魂
任何一项测试活动的核心都是测试思维，即如何进行测试。而测试用例就是测试思维的体现。功能的测试优先级、如何操作、输入什么数据、应该有什么的结果等等都体现在测试用例中。
4. 测试用例评审
测试用例的评审就是为了给测试用例进行查漏补缺。
评审方式：
测试内部评审
项目组评审：项目相关人员参与评审（开发、测试、产品等等）
5. 执行测试用例
前面的工作做的充足的话，在执行测试用例的时候就会非常简单了。只需要根据测试用例一条一条去执行程序即可。发现缺陷就提交缺陷，测试通过就继续执行。
其实测试执行的过程真的很简单，只是在执行的过程中各部门的协作，沟通以及各项文档的输出很复杂。
测试与开发沟通无疑是关于某个功能或者产品的，主要围绕几个以下几个点：
程序某个地方存在问题；
产品需求信息在测试和开发中不统一；
程序某功能应该是怎么处理；
缺陷修复后的验证；
测试和需求的沟通
测试人员与需求的沟通难点主要还是体现在需求不明确或者需求变更上。很多时候需求人员的需求文档都是不全面的，测试人员在写测试用例时需要一次又一次的与需求进行确认，一来二去，需求估计有种想把桌子里40米长的大刀放桌上来。
另一方面在项目过程中，不可避免的会出现需求变更，只要出现变更就意味着之前的测试准备工作就作废。
测试与需求如何沟通呢：
切记不能停留在口头沟通，确认
所有的需求确认或者需求变更都需要文档化，实在不行也需要发邮件
每一次确认、变更都需要通过项目相关人
建立完善的需求变更体系，流程上控制需求变更
测试结果的反馈
测试结果的反馈容易出现问题的地方就是结果描述不清楚，增加项目的时间和沟通成本。解决这个问题最好的办法就是将测试结果尽可能的描述清楚。
6. 缺陷管理
在开发阶段，测试人员最重要的产出就是缺陷。缺陷并不是数量越多，就越有价值。更应该关注缺陷的质量、缺陷的管理以及缺陷分析。
缺陷流程处理图：
缺陷管理是软件测试活动中极其重要的一环，很多时候测试用例并没有发现多少缺陷，反而自己在运行程序的过程中发现了很多缺陷，那这些缺陷就是对测试用例的补充，对之后的测试就可以提供思路。
7. 输出测试报告
测试报告一般是在项目测试结束或一个迭代完成之后由测试负责人编写。若不是项目，只有一两个测试人员，那就是由该项目主导人来写，若只有你一个来测试，那就是由你来写。
测试报告主要内容大致可以分为测试范围、测试进度、缺陷管理、测试结论四大部分，在实际编写过程中，我们根据企业的要求输出这四个部分或包含这四个部分以上的内容即可。
测试范围
测试范围主要是写本次项目或本次迭代需要测试的功能，一般来说是以新增功能和修改功能为主，以回归测试内容为辅，测试报告中的测试范围可以摘取测试计划中的测试范围，再根据本轮测试活动中实际测试的功能进行补充
测试进度
测试报告中的测试进度由二部分组成：一个是时间进度安排（展示），另一个是人员测试时间花费缺陷管理缺陷管理是测试报告中的核心内容，而测试报告中需要对本轮测试缺陷从不同维度进行输出，目的就是为了从缺陷分析中得出软件质量、修改bug的效率、开发质量等
测试结论
测试报告中的测试结论绝对是占C位的，也有企业写测试报告只需要测试结论就行； 测试结论中包含对本轮测试过程的总结，主要是得出本轮测试之后项目是否达到了上线标准，所以测试结论有测试通过，可以上线，或者是测试不通过，建议不上线。
8. 产品发布
进入发布阶段就意味着产品已经通过了测试，可以发布到线上，交付给用户使用。
测试通过准则规范
测试需求功能覆盖率100%
测试用例通过率95%以上
遗留缺陷没有严重程度3级以及以上的缺陷
9. 结束测试
整理整个测试过程中产出的文档，并进行归档整理，以便日后使用。
总结：
软件测试整个过程，关注的是在整个软件生命周期中，各个阶段的测试活动
通过对各个阶段的过程质量把控，从而提高产品的测试质量。产品的质量并不是测试能决定的，而是整个项目构建过程中，通过一次次的优化过程，不断的总结成长，是整个项目团队决定的。
不同的工种都在这个过程中起到举足轻重的作用，而全程软件测试强调不断提高每个阶段的质量，最终提高项目团队的综合能力，从而提高产品质量。