产品测试的目的是为了发现不符合产品质量要求的问题，并反馈给开发人员，让开发人员完成修正后，通过测试再次校验直到该问题完成修正为止，最终向用户交付符合质量要求的产品。
产品测试是对产品开发结果进行校验的标准手段且是确保产品质量的最后一道关卡，从这一点上来说产品测试是一件目的性很明确、企图心很强的工作，在上一篇中我们简单介绍了与产品测试相关的信息，本篇从测试方法、测试范围、介入时间、测试结果、反馈机制、验收标准等层面来探讨产品测试这项很重要的工作。
第一章：测试方法
为了确保最终交付的产品质量，在实践过程中总结出来一些行之有效的方法，从不同的角度对产品进行测试。对于测试可以选择的分析角度有是否关心内部结构、是否执行代码、开发过程级别、是否需要人工干预、测试实施组织<测试主体>、测试所处的环境等，选择不同的角度会有不同的分析结果。
1.1内部结构
根据测试时是否关心产品的内部结构，测试可以分为白盒测试、黑盒测试、灰盒测试。
1.1.1白盒测试
白盒测试：又称为结构测试或逻辑测试，是一种按照程序内部逻辑结构和编码结构，设计测试数据从程序中发现程序内部在算法、溢出、路径、条件等方面问题的测试方法。
1.1.2黑盒测试
黑盒测试：又被称为功能测试、数据驱动测试或基于规格说明的测试，把测试对象当成完全看不见的黑盒，在不考虑程序内部结构和处理过程的情况下，仅依据程序功能需求规范考虑，确定测试用例和推断测试结果的正确性，它是站在使用软件或程序的角度，从输入数据与输出数据的对应关系出发进行的测试。
黑盒测试：包括功能测试、性能测试等
1.1.3灰盒测试
灰盒测试：是一种综合测试法，它将“黑盒测试”与“白盒测试”结合在一起，是基于程序运行时的外部表现又结合内部逻辑结构来设计用例，通过执行程序并采集路径信息和外部用户接口结果的而进行的测试。
1.2执行代码
根据测试时是否执行代码，测试可以分为静态测试和动态测试。
静态测试：指不运行被测试程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来确认程序的正确性。
动态测试：是指通过运行被测程序，输入相应的测试数据，检查输出结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能指标。
1.3过程级别
根据测试时所属的开发过程级，测试可以分为单元测试、集成测试、系统测试。PS：重点学习了解一下测试，然后可以用自己的语言组织一下。
单元测试：又称模块测试，是针对软件中的最小可测试单元（程序模块或功能模块），进行正确性检验的测试工作。其目的在于检验程序单元本身（各模块）是否存在各种差错，是否能正确地实现了其功能，满足其性能和接口要求。
集成测试：又叫组装测试或联合测试，是在单元测试的基础上进行的一种有序测试，将通过测试的单元模块组装成系统或子系统在进行测试，旨在检验软件单元之间的接口关系，以期望通过测试发现各软件单元接口之间存在的问题，最终把经过测试的单元组合成符合设计要求的软件。
系统测试：是把集成的软、硬件系统作为一个整体进行的测试活动，包括功能测试、性能测试、接口测试、人机交互界面测试、强度测试、余量测试、安全性测试、可靠性测试、恢复性测试、边界测试、数据处理测试、安装测试、容量测试、互操作测试、敏感性测试、标准符合性测试、兼容性测试、本地化测试等等。
验收测试：是指在系统测试的后期，以用户测试为主或有测试人员等质量保障人员共同参与的测试，是软件面向用户前的最后一道关卡。
1.4人工干预
根据测试时是否需要人工干预，测试可以分为手工测试、半自动化测试、全自动化测试。
手工测试：就是测试人员按照事先为覆盖被测试软件需求而编写的测试用例，根据测试大纲中所描述的测试步骤和方法，手工地一个一个地输入执行，包括与被测试软件进行交互（如输入测试数据、记录测试结果等），然后观察测试结果，看被测试程序是否存在问题，或在执行过程中是否有异常发生，属于比较原始但是必须执行的一个步骤。
自动化测试：实际上是将大量的重复性的测试工作交给计算机去完成，通常是使用自动化测试工具来模拟手动测试步骤，执行用某种程序设计语言编写的过程。
全自动化测试：就是指在自动测试过程中，不需要人工干预，由程序自动完成测试的全过程。
半自动测试：就是指在自动测试过程中，需要手动输入测试用例或选择测试路径，再由自动测试程序按照人工指定的要求完成自动测试。
1.5实施组织/测试主体
根据测试主体的不同可以分为开发人员自我测试、非用户第三方测试、用户测试三种方法。开发人员自我测试通常是指开发人员在开发过程中边开发边测试自己代码的行为，非用户第三方测试通常是指开发人员以外的人员对开发人员的开发结果进行测试的行为（由此衍生了专业的测试人员QA），用户测试通常是指产品通过开发人员自我校验和非用户第三方校验之后正式上线面向产品最终用户试用的行为。
开发人员自我测试是集中在代码、功能层面的测试，目的是通过自我测试确保完成的代码逻辑和功能的完整性、可用性、有效性等。
非用户第三方测试是集中在产品整体解决方案层面的校验，主要包含功能流程、业务流程、数据流、产品体验等产品综合解决方案的校验，目的是确保向用户交付的产品是可以为用户提供有效解决方案并满足其需求场景的。
用户测试也可以分为内测和公测，内测是选择一些种子（典型）用户使用产品并提供反馈信息，公测则是把产品面向广大的用户群体进行测试并建立有效的反馈信息收集通道收集用户反馈。用户测试是从用户使用产品的角度出发，挖掘产品提供的针对需求场景解决方案的有效性、合理性、体验感等。
1.6测试环境
根据测试所处的环境不同，可以把测试分为阿尔法测试、贝塔测试。
阿尔法测试：是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。
贝塔测试：使组织各方面的典型终端用户在实际需求场景中使用贝塔版本，并反馈使用报告。
第二章：测试范围
随着互联网行业的发展，学科内知识的积累和进步，对于测试工作内容的划分越来越精细，测试范围根据测试内容的不同可以分为代码测试、功能测试、流程测试、UI(界面)测试、文档测试、交互测试、内容测试、性能测试、版本测试等。
测试范围越广测试、力度越细所需要投入的成本（时间或者资源）就越高，在实际实践过程中，往往会根据产品的侧重点不同选择重点的测试范围，在有效降低测试成本的同时确保向用户交付的产品质量。
2.1代码测试
代码测试主要是针对代码的逻辑、算法、条件、路径、溢出、选择、方法、函数、标准、规范等的测试，代码测试是产品开发过程中第一道测试关卡，也是确保产品的功能实现、扩展性、维护便利性的核心关卡。
2.2功能测试
功能测试主要是测试软件的功能是否符合产品设计并能真正的满足用户的需求场景，功能测试包含逻辑功能、易用性、兼容性、安全性等方面。
逻辑功能测试（logic function testing）：主要是用来测试功能背后的逻辑是否完整、完善、准确。
易用性测试（usability testing）：是指从软件使用的合理性和方便性等角度对软件系统进行检查，来发现软件中不方便用户使用的地方。
兼容性测试（compatibility testing）：包括硬件兼容性测试和软件兼容性测试。
2.3流程测试
流程测试主要是针对产品的功能流程、数据流、业务流等各种各样的流程进行的测试，确保产品的各种流程可以完整、准确、一致的运行。避免出现单个功能使用正常，功能组合在一起则不能正常使用等问题。
2.4UI（界面）测试
UI（界面）测试主要是针开发人员开发出来的面向用户的界面所包含的可见的、静态的部分的测试工作，主要包括页面的布局、线框的粗细和样式、色彩的三要素、字体的大小和样式、文字段落样式等各方面是否符合设计的需求。
2.5文档测试
文档测试主要是针对面向用户的各种使用手册、使用帮助、在线指导、常见问题等文档类的内容进行测试，通过测试确认文档是否满可以完整、准确的向用户传达有效信息并能帮助用解决实际使用场景中的问题而满足用户的需求。
2.6交互测试
交互测试主要是针对面向使用者触发动作后界面内或者界面之间动作交互的行为进行测试，通过测试确认页面内部响应动作或页面之间的跳转、转换等动作是否符合交互设计的需求，并且交互动作不会给用户带来违和感。
2.7内容测试
内容测试主要是针对产品所需内容的完整性、准确性，以及内容本身所包含的意义内涵进行系统测试和分析，确保内容符合产品定位和使用场景，避免因为内容内涵的不到位而带给用户不好的使用体验。
2.8性能测试
产品的性能测试从时间性和空间性来分析，可以分为时间性能和空间性能。时间性能：主要指软件的一个具体事务的响应时间（respond time）。空间性能：主要指软件运行时所消耗的系统资源。
产品的性能测试根据测试的目的不同可以分为一般性能测试、稳定性测试（可靠性测试）、负载测试、压力测试。
一般性能测试：指的是让被测系统在正常的软硬件环境下运行，不向其施加任何压力的性能测试。
稳定性测试（reliability testing）：是指多次、连续运行被测系统，检查系统运行的稳定程度。
负载测试（load testing）：是指让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。
压力测试（stress testing）：是指持续不断的给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。
2.9版本测试
回归测试（regression testing）是指对软件的新的版本测试时，重复执行上一个版本测试时的用例。
冒烟测试（smoke testing），是指在对一个新版本进行大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
随机测试（random testing），是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。
第三章：测试流程
测试的流程是贯穿产品的整个生命周期的，在生命周期的不同的阶段测试所担负的作用有所不同。根据时间顺序来探讨，可以把测试流程分为需求了解、计划制定、用例设计、测试执行、BUG收集、BUG修正、结果跟踪、验收通过、测试报告等阶段。
3.1需求了解
测试的核心目的是为了确保向用户交付的产品能满足用户需求场景并且符合产品设计需求。
只有充分了解产品所满足的目标用户的需求场景，以及了解为了满足这个需求场景需要怎样的解决方案，进而了解为了实现这些解决方案需要哪些功能和内容，最终明确呈现的产品又应该具备怎样的视觉和交互体验，才能实现测试的核心目的。
因此从这个层面来说，测试需要从产品需求分析层面就开始介入，通过产品需求文档、设计文档、产品原型等各种产品需求辅助资料来充分的全面的了解产品需求。
在实际工作场景中，测试相关人员应该保持与产品相关人员的密切沟通，及时的从产品相关人员处获取最新的产品相关信息，以避免产品需求发生变更而未能及时的获取到相关信息造成的偏差。同时有条件的团队可以创立完善的机制，确保需求变更发生时需求辅助资料同步变更及时性和有效性。
3.2计划制定
在对产品需求有清晰的了解之后，为了确保在规定的产品交付时间周期内完成对产品的测试，测试相关人员应该制定严格的测试计划。由于测试工作只有在开发人员完成自己的工作输出之后才能进行，所以测试的计划在制定过程中结合开发计划的进度制定测试计划。
如果测试工作的开展完全放在开发工作之后进行，将极大地延长产品的交付周期，造成产品最终交付的时间成本过大。为了缩短这个时间成本，需要在产品开发过程中可以同步推进测试工作。
基于开发未完成相应的工作之前，测试相关人员可以了解到的只有产品需求的相关资料，而基于产品需求相关的资料可以开展的工作只有测试用例设计。
因此在了解完产品需求之后，在开发人员按照开发计划推进开发的过程中，测试相关人员可以根据需求同步推进测试用例的设计工作，当开发人员完成开发之后测试人员可以及时的跟进测试，通过这种方式可以有效的缩短产品测试的总体时间成本。
3.3用例设计
测试用例是为了验证软件不同层面的需求实现情况而编制的测试输入、执行条件以及预期结果的用例集合，通过科学化的组织归纳，将软件测试的行为转化为可量化、可管理的行为模式。
测试用例文档一般有简介和测试用例两部分组成。
简介部分一般包含测试的目的、测试范围、定义术语、参考文档、概述等等。
测试用例一般包含版本号、模块名称、用例编号、用例名称、用例级别、预知条件、验证步骤、期望结果（含判断标准）、测试结果、测试时间、测试人员等。一般而言针对一个具体的需求点会有N组测试用例，根据测试范围的不同，测试用例的数量也会有所不同。
测试用例设计常用的基本方法有：等价类划分法、边界值分析法、错误推测发、因果图法、逻辑覆盖法等。
不同类别的软件，其实现的需求场景不同，因此其测试用例差异很大。再具体实践过程中，需要结合产品的实际情况进行灵活变通。
3.4测试执行
测试执行是当开发人员完成对应的程序开发之后，测试人员按照测试用例测试完成开发的程序的过程。
测试执行的工作可以分为三种方式，一种是通过自动化的方式进行测试，另外一种方式则是通过人工的方式进行测试，还有一种是通过自动化和人工结合的方式进行测试。
3.5BUG收集
BUG是指程序执行后并未按照预期的结果输出或者在程序执行的过程中发生了异常，BUG收集的过程是指测试相关人员发现BUG并把BUG进行记录的过程，记录BUG时需要记录其出现的条件和执行步骤等信息，方便其他人员可以通过同样的条件和执行步骤重现该BUG。
PS：之所以要进行BUG收集的工作是因为，开发人员完成开发就把BUG修复完，团队配合效率的需求，两者工作的推进在时空上是分开的。
BUG的收集一般由开发人员、测试人员、产品经理、运营人员、用户等发现，为了提升BUG的管理效率，在实践过程中团队一般会使用文档或者第三方工具加强对BUG的管理。
在产品向用户交付时，会经过非常严格和系统的测试，但是仍然可能存在隐藏的BUG在用户端被发现。为了降低BUG对用户的负面情绪，并且方便产品快速的修正，需要建立及时有效的方式收集用户使用过程中发现的各种问题。
常见的BUG反馈通道有在线问题反馈、问卷调研、邮件、热线电话、在线沟通等，当用户发现产品的BUG时应该可以通过上述反馈通道的一种或几种把问题反馈给团队，团队内部应该有专门的人员负责对用户发现BUG的收集与管理。
在BUG收集的过程中，会根据BUG的来源、严重级别等维度，对BUG进行分类，方便查找、管理、修正等。
3.6BUG修正
BUG修正是由开发人员通过修改程序解决程序异常或者使得程序运行输出结果符合预期结果，这项工作主要是由开发人员来完成的。
前面提到，开发人员要想解决这些BUG，必须根据记录的BUG进行重现该BUG，从而可以知道在什么条件下该BUG会出现或会出现什么异常，开发人员根据的条件和步骤通过重现BUG进行修正。
通过不断的修正BUG，使得产品中存在的BUG越来越少，从而使得产品趋向于完善，进而给用户带来更佳的使用体验。
3.7BUG跟踪
BUG跟踪是自BUG被发现并记录后为了确保该BUG确实被修正而开展的工作，具体工作内容有根据BUG所处的优先级和修复时间，在开发人员完成修真之后进行再测试，如果没有再发现该BUG则把该BUG标记为关闭（已修正等），如果该BUG仍然存在则再次记录确保直到该BUG被修正为止。
在实践过程中，开发人员或测试人员为了偷懒，往往会在BUG修正完成之后只测试会导致BUG出现的用例，而与该功能相关的其他用例则被省去，这会极大的提升产品的隐藏BUG。
因为程序之间存在的关联性，很多时候开发人员在修正完一个BUG的时候，会引发其他的BUG，因此开发人员在修正完该BUG之后，测试人员应该全面重复测试与该功能相关的所有用例，确保该BUG被修复的同时没有引发其他BUG。
对于BUG的跟踪，一般采用的策略是谁发现、谁记录、谁记录、谁跟踪，对于用户发现的BUG则跟踪人员由记录人员进行跟踪。
3.8验收通过
不同的产品面向的用户不同，产品所关注的侧重点不同，团队所具备的资源不同，产品所处的阶段不同，产品测试通过验收的标准有所不同。
在制定产品验收标准时应该综合考虑上述情况，根据实际需求确定产品的验收标准，验收标准并不是一成不变的，但是不鼓励在一个开发周期内频繁的更换验收标准。
3.9测试报告
测试报告是产品通过验收后，由产品开发人员、测试相关人员、产品经理等各方对产品完成上线前验收后，可以出具的一份综合报告，这份报告的目的旨在告诉团队内部或外部该产品是经过严格测试的，并且可以约束团队内的相关成员对产品负责。
测试报告具体的内容、格式等，不同的团队可以根据自己的需要确定。
第四章：认知误区
虽然软件测试在确保产品质量方面有着至关重要的作用，但是在实践过程中很多团队确实对测试介入时间、测试负责比例、测试任职条件、测试力度等存在较大的认知误区，这影响着团队对测试活动的开展和测试质量的提高。
4.1测试介入时间
根据互联网产品研发的实践经验，产品研发一般可以分为：需求分析、产品设计、软件编码、软件测试、软件发布。因此有些人会认为软件测试是在软件编码后进行的，实则软件测试是一个系统工程，包括产品测试需求分析、测试计划设计、测试用例设计、执行测试用例、BUG收集、BUG修正、BUG跟踪、验收通过、测试报告等。
因此，产品的测试贯穿于产品的整个生命周期，在不同阶段介入了解产品测试不同阶段的内容。比如：了解产品测试需求阶段，在产品需求分析阶段介入，其所了解的产品测试相关的内容由产品的需求文档、设计文档等资料；了解功能开发情况阶段，在开发完成编码进行集成测试时介入，其所了解的产品测试相关的内容是测试用例的执行结果等信息。
如果产品测试的工作在产品完全完成开发之后再进行，将延长产品总的开发周期，在产品开发范围、时间、成本确定的情况下，往往很难在规定的时间内完成测试相关的工作。
测试人员在各个阶段介入的过程，也是一个提前发现问题，修正问题的过程。问题被发现的越早，其修正成本就越低；如果所有的问题是在产品开发全部完成之后才进行的，那么为了修正软件需求阶段或设计阶段的问题，将会付出极大地成本（人力和时间）。
4.2测试负责比例
在职责分工上，测试人员担负着产品质量的主要责任，但是为了确保产品最终的商业成功，团队中其他角色也应该有这种责任和意识去确保产品的质量成功，这要求其他岗位的人员也分出来部分精力来关注产品质量。
在实际实践过程中，团队内不同岗位的人可能会认为产品测试是测试人员的事情，产品出现问题与自己无关。特别是产品上线后，更是让人坚信，如果产品出现问题则责任都在测试人员。
团队存在的目的就是为了确保产品成功，一个团队包含的角色有产品人员、运营人员、开发人员、测试人员等，不同的角色其确保产品成功的点有所不同。如果说产品人员是为了确保产品（设计）成功，运营人员是为了确保商业成功，开发人员是为了确保开发成功，那么测试人员可以说是为了确保质量成功。
如果没有产品人员的产品（设计）成功和开发人员的开发成功，测试人员要想确保质量成功也是一件不可能的事情，而对于运营人员来说如果质量成功无法保证想实现运营成功也几乎是一件不可能的事情。
而且当测试人员发现产品存在问题需要修正时，如果没有开发人员的高效配合和有效的解决方案的落地，是很难修正这些问题的。
这也就要求团队应该从产品的整个生命周期的各个环节来加强产品质量的管控从而确保产品的质量，只有这样才能最大可能性避免向用户交付有质量问题的产品。在实践过程中如果遇到产品的质量问题，团队中不同的岗位和角色应该积极主动的去思考自己如何做的更好才能避免或解决这些产品质量问题，并最终向用户交付符合质量标准的产品。
4.3测试任职条件
在实际产品开发过程中，为了节省团队成本，很多团队使用的测试方式为黑盒测试，白盒测试基本上有开发人员自己搞定，这造成了不少团队对测试产生了认知误区，认为测试就是点点鼠标、按按键盘、用用软件等，这项工作好像任何一个人都可以做，互联网产品相关的从业人员胜任这项工作应该是绰绰有余的。
实际上随着测试技术的不断发展，软件测试的规则、流程、标准、工具、方法等在不断发展和更新，从事测试相关工作所需要掌握的知识和技能也越来越多。如果未系统的学习和掌握测试相关的知识而担负起产品质量监测的重任，很难全面的设计测试用例、并做到有效执行，最终会导致产品存在BUG的可能性大大提高，最终影响用户的使用体验。
从对产品质量负责的角度来说，担任测试只能岗位的人，即使不是专业的测试人员也应该掌握测试相关的知识和技能，这可以极大地提高测试的效率和降低BUG出现的概率。
4.4测试力度
测试既然这么重要，那是不是所有类型的产品我们都必须要进行全面、系统、严格的测试呢？这是一个与测试力度相关的问题，下面我们探讨一下这个问题。
随着互联网行业的发展，互联网开始融入到各行各业，以互联网为载体而研发的产品越来越丰富，在不同的行业不同的场景下，对产品需求的侧重点有所不同，因此对产品的测试力度和测试范围在一定程度上会有所取舍，一定程度上节省一些测试成本，提高团队的输出效率。
比如针对组织类用户使用的互联网产品，可以指定一款具体的浏览器作为专用浏览器，这将节省大量的浏览器兼容性测试所需要的时间。因为针对组织类的用户，产品提供方可以向他们提出这种可接受的约束和要求；但是当产品面向不同用户时，不同的用户使用的浏览器不同而且使用的浏览器版本不同，产品提供方很难要求用户使用自己的产品前先去下载一个自己指定的浏览器。
因此在产品设计时就可以充分的考虑产品的定位、面向的用户、使用的场景、解决的问题、实现的方式、测试的范围、验收的标准等信息，然后根据产品的实际情况出发设计验收标准、确定测试力度，从而避免不必要的人力浪费。
另外随着现在各种开发技术的进步和成熟，很多第三方的开发框架已经经过了各种严格的测试，可以充分的避免很多不必要的BUG，使用这些成熟的框架也可以大大节省测试所需要投入的时间和资源。
有所侧重和胡乱测试是不能混为一谈的，有所侧重仍然需要加强测试过程的计划制定与过程管理和控制，同时应该充分评估测试力度下降是否会对项目带来巨大的潜在风险或者带来的风险是否可控。