软件测试有几种不同的定义方法：
a.软件测试是为了发现程序中的错误而执行程序的过程。
b.软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例，并运用这些测试用例运行程序，以及发现错误的过程，即执行测试步骤。
软件测试的目的：
a.发现被测对象与用户需求之间的差异，即缺陷；
b.通过测试活动发现并解决缺陷，增加人们对软件质量的信心；
c.通过测试活动了解被测对象的质量状况，为决策提供数据依据；
d.通过测试活动积累经验，预防缺陷出现，降低产品失败风险。
1、测试策略
测试策略：如何用尽量少的资源来尽量好的完成测试，给测试活动提供技术上的指导，以便测试活动的实施者能够很快的开展自己的工作。
测试策略：在不同的项目背景下，根据产品需求和指标，分析产品的功能项和业务逻辑，并判断测试的重点和方向，在当前有限的条件下，统筹各方资源、采取合理有效的方法来推动项目的测试活动开展，以最少的软硬件、人力资源投入得到最佳的测试效果，达到符合当前环境的最优决策。
测试策略可以归属到测试方案中的一个重要组成项，通过采用有效的测试手段与方法，对产品模块&子模块进行划分，明确测试要点，然后按照功能性与非功能性（易用性、兼容性、性能、安全性...）的分类，明确所采用的测试方法（黑盒/白盒/单元/集成/系统/回归/验收...）、用例设计方法（等价类、边界值、流程分析法、），并设置不同的测试优先级，从而指导后面编写测试用例等工作的开展。
2、测试方案
测试目的：看测试对象是否满足需求规格说明书、测试对象业务流程的合理性和正确性、测试对象的功能、兼容、性能、稳定性。
测试方案：阐述对于某一个特定的测试点如何去测试的思路，也就是阐述用什么方法、如何去测试这些方法。主要包括测试目的、测试准备、测试分工、测试范围、测试风险。
测试准备：测试参考、测试环境、测试平台、测试数据、测试案例、测试工具、测试版本。
测试参考：开发流程图、交互稿(原型)、需求说明书、软件设计书。
测试环境：正式环境、开发环境、测试环境。
测试平台：PC、Web、APP、H5、Android、IOS。
测试范围：功能、接口、兼容、性能、安全、安装、埋点、稳定性。
测试项：功能测试(功能清单、核心业务流程、测试案例)、兼容性测试(硬件兼容、软件兼容、数据兼容、网络兼容)、性能测试(CPU、内存、流量、耗电量、响应时间)、安全测试( 漏洞、防攻击能力、敏感数据加密处理等)。
3、测试计划
测试计划：是对全过程的组织、资源、原则等进行规定和约束，并制定测试全过程各个阶段的任务以及时间进度安排，并提出对各项任务的评估、风险分析、管理需求。测试计划是从管理角度对整个测试活动进行规划和控制。
测试计划包括：概述（文档目的、文档读者）、用户需求概述、设计运行环境、条件与限制、测试方案（测试环境、测试需求）、组织范围、测试通过与否的标准、测试挂起&恢复条件、测试进度人力分布计划、测试风险、测试任务安排、测试准备工作。
4、测试工作流程
测试工作流程：评审需求、测试计划(任务分解)、设计测试用例、测试入口检查、执行测试用例、报告缺陷、回归测试、验收测试、测试出口检查。
从两条线分别展示软件测试的基本过程，如图 0-2 所示。
（1）一条线是从软件工程过程来看，经过需求评审、设计评审、代码评审与单元测试、 集成测试、系统测试和验收测试阶段。
（2）另一条线是从项目管理角度看，经过测试计划、测试设计、测试执行与监控、测 试结果分析与评估（报告）和项目总结阶段。
5、研发测试工作流程
项目部：新增产品、创建平台、创建计划、维护模块、创建WBS（上传需求）、定义范围（项目计划）、项目监控、项目验收、项目回顾会议（总结大会）。
研发部：评审需求-范围、开发计划（任务分解）、概要/详细设计、编码实现/单元测试、冒烟测试、提交产品进行测试、修复缺陷。
测试部：评审需求-范围、测试计划（任务分解）、设计测试用例、创建测试版本、测试入口检查、分批分类执行测试用例、报告缺陷、分批分类进行回归测试、验收测试、测试出口检查、创建发布、项目软件质量报告。
6、缺陷管理过程
软件质量保证活动中，涉及到几个概念：错误、bug、缺陷、失效。
a.错误：指文档中表述或编写过程中产生的错误现象，静态存在于文档中，一般不会被激发。
b.bug：指存在于程序代码或硬件系统中的错误，通常是由编码或生产活动引入的错误，其静态或特定诱因下动态存在。
c.缺陷：综合了错误、bug等相关术语，一切与用户显性或隐性需求不相符的错误，统称为缺陷。错误实现、冗余实现、遗漏实现、不符合用户满意度都属于缺陷。
d.失效：因缺陷引发的失效现象，动态存在于软硬件运行活动中。
缺陷产生的原因：
a.需求表述、理解、编写引起的错误；
b.系统设计架构引起的错误；
c.开发过程缺乏有效的沟通及监督，甚至没有沟通或监督；
d.程序员编程中产生的错误；
e.软件复杂度越来越高；
f.与用户需求不符，即使软件实现本身无缺陷；
g.外界应用环境或电磁辐射导致的缺陷。
重点强调：
- 开发人员认为BUG无效时，应设置合理的解决方案，添加备注说明无效原因，并将BUG转至测试人员。
- 开发和测试人员对BUG的有效性、解决时间、解决方案存在争议时，测试人员将BUG转至需求人员评判。
- 需求人员认为BUG无效时，应添加备注说明无效原因，并将BUG转至测试人员。
- 需求人员认为BUG有效且需当期修复，应将状态重新“激活”，并添加备注说明解决时间、解决方案，并将BUG转至开发人员。
- 需求人员认为BUG有效，但不需当期修复，应添加备注说明解决时限、解决方案，并将BUG转至测试人员。
6.1 缺陷字段
1 bug类型
开发-代码错误：开发正确理解需求情况下进行的代码开发，导致代码逻辑问题、代码报错、错字等功能，导致与需求不一致；
开发-设计缺陷：开发在对需求理解有偏差的情况下进行代码设计，开发导致与需求不一致；
开发-功能缺失：需求描述的功能未实现；
开发-性能问题：性能相关指标，如反应速度、占用资源等；
开发-数据问题：数据库或者数据表设计、数据质量等；
开发-优化建议：易用性建议、兼容性建议、界面美观建议等；[需求文档里已明确要求]
开发-安全问题：安全相关指标，如SQL注入、用户信息泄露；
需求-需求建议：需求文档未明确；对应解决方案为“转为需求”；[包括隐性需求]
需求-需求错误：需求不完善、需求变更
需求-需求变更：评审后的设计变更
需求-新增需求[客户]：客户建议的需求新增
运维-环境相关：安装部署脚本、软硬件环境资源等
其他-以上类型未涵盖到的所有其他类型，如标准规范
2 严重程度
指示缺陷对业务的相对影响，并在分配缺陷优先级时参考使用
1 - 危急
影响关键功能，系统主要功能丧失，用户数据受到破坏，造成系统奔溃、悬挂、死机或危及人身安全，用户没有可用的解决方法，比如：
系统崩溃，不可恢复的数据丢失；
页面无法展示或直接报错；
与需求有很大的偏差，导致主要功能块缺失，阻止进一步的测试；
系统整体性能太差，影响用户正常使用；
数据流环节上严重的数值计算错误；
产品设计存在严重的安全问题；
漏洞被利用后可能导致系统瘫痪；
数据丢失或隐私泄露；
2 - 高
系统主要功能部分没有实现、产品需求规格不符、功能与要求不符、数据流错误、程序接口错误、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。安全问题、稳定性等。
影响关键功能、偏离需求、阻碍系统交付成果的实现，但存在用户可用的解决方法；
次要功能被禁用或与需求稍有偏差，用户解决方法可能存在也可能不存在；
对于某些系统组件，性能比最低要求或可比系统更差；
数据流环节上轻微的数值计算错误；
程序接口错误；
用户所要求的的功能缺失；
软件中数据保持后数据库中显示错误；
3 - 中
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。比如：
易用性建议、兼容性建议、界面美观建议等。
操作时间长
查询时间长
格式错误
边界条件错误
删除没有确认框
数据库表中字段过多
容错性不好
大数据无响应或没有滚动条等
当BUG类型为“优化建议”时，可选择该严重程度
4 - 低
界面、性能缺陷、建议类问题，不影响操作功能的执行，可以优化性能的方案等。比如：
开发过程缺陷，例如不遵循标准
界面上的拼写错误
界面格式不规范
页面显示重叠、不该显示的要隐藏
描述不清楚，提示语丢
文字排列不整齐，光标位置不正确
用户体验感受不好，可以优化性能的方案
严重程度为1和2的缺陷必须在发布前修复
7、测试报告
测试报告主要包括：编写目的、项目背景、测试概要、测试内容和执行情况、覆盖率、通过率、bug统计与分析、测试结论与建议。
测试概要：测试概要分析表、测试用例设计方法、测试环境与配置。
测试内容和执行情况：项目测试概况表（项目版本、开始时间、结束时间、用例数、用例通过数、问题数、用例通过率）、功能测试、性能测试、兼容性测试、稳定性测试、可靠性测试、可维护性测试、安全性测试。
覆盖率与通过率分析：测试用例覆盖率分析表(需求、模块、用例数、执行数、执行覆盖率、未执行原因)、测试用例通过率分析表(功能、模块、执行用例数、用例通过数、用例失败数、用例通过率)。
Bug统计与分析：解决方案、严重程度、优先级、状态、类型、遗留bug激活状态、延迟修复。
8、测试分类
测试阶段-分类：需求测试、单元测试、集成测试、系统测试、用户测试、回归测试。
测试方法：静态测试和动态测试。
黑盒测试：等价类划分、边界值分析、错误推测法、因果图。
测试方法-分类：黑盒测试、白盒测试、灰盒测试、静态测试、动态测试、手动测试、自动化测试
- 黑盒测试：功能测试、数据驱动测试或基于需求规格说明书的功能测试，通过测试活动来检查被测对象每个功能能否正常使用，是否满足用户的需求。
- 白盒测试：基于程序代码内部结构的测试。白盒测试中，测试工程师深入考查程序代码的内部结构、逻辑设计等。白盒测试需要测试工程师具备很深的软件开发功底，精通相应的开发语言，一般的软件测试工程难以胜任该工作。
9、测试的基本原则
原则1:测试显示存在缺陷
原则2：穷尽测试是不可行的
原则3：测试尽早介入
原则4：缺陷集群性
原则5：杀虫剂悖论
原则6：测试活动依赖于测试背景
原则7：不存在缺陷的谬论
10、找bug的核心思维与境界
测试人员的思维模式，常用的有逆向思维、发散性思维、组合思维、比较思维，主要有逆向思维、发散性思维。
发散性思维：一种探求多种答案，最终使问题获得圆满解决的思维方式。
逆向思维：不走寻常路。
测试的三种境界：
a.第一重境界：围着Bug转，通过发现bug，协助开发人员分析问题、定位问题、最后解决了bug，才能对质量有实质的贡献。
第一重境界又分为3个阶段：第一阶段是发现bug；第二阶段是定位bug;第三阶段 是关闭bug.
b.第二重境界：站在Bug上，服务于整个产品的开发链，项目的成功可以带来测试的成功。
c.第三重境界：挑战零缺陷，以预防为主，事后的测试验证为辅，主动推动设计尽量一次做好。
11、测试左移
在提测之前介入测试。在测试阶段到来之前，尽可能的抓紧开发前(需求分析)和开发中的时间做测试，提前发现问题，防微杜渐，避免积重难返。
1) 需求阶段：测试对象是需求，越早的发现需求不合理的地方出问题的几率就越低。在需求评审时不只是了解需求，更是要去评估需求的质量，分析需求的合理性以及完整性；
2) 开发阶段：参与设计方案的设计，了解开发的实现方式。开发阶段可能产出只是代码，而不是完成的功能，这时候比较合适的测试是做持续集成的单元测试，通过代码覆盖率的方式找到未经测试的代码，尽可能的保证代码都被测试到。
12、测试右移
往发布之后移。上线后仍需关注线上情况，进行一些测试活动。通过线上监控和预警，监控线上性能和可用率，一旦线上发生任何问题，及时发现问题并跟进解决，给用户良好的体验，将影响范围降到最低。
还有关注线上业务及用户使用情况，更多地关注用户价值高、使用率高的功能，在用例中补充遗漏的场景，尽量多地覆盖这些功能。