一、测试活动的生命周期
测试计划(测试准入) -> 需求分析与设计 -> 测试实现与执行 -> 测试报告(测试准出) -> 测试总结
1、测试计划
任务的安排与制定测试的方法
2、测试的分析
到底如何测试
用什么方法测试
3、测试的执行
行动
4、测试报告
测试执行结果的总结
5、测试总结
项目上线后
测试人员本次的测试总结
测试方法的不足地方，为下次做准备
二、软件测试的过程
按照测试阶段划分为: 单元测试、集成测试、系统测试、验收测试。
单元测试UT
单元测试是针对软件基本组成单元(软件设计的最小单元)来进行正确性检验的测试工作，单元测试的目的是检测软件模块《详细设计说明》(LLD)的符合程度。集合测试IT
集合测试是在单元测试的基础上，将所有模块按照概要设计要求组装成子系统或系统，验证组装后功能以及模块间接口是否正确的测试工作。集成测试的目的是检测软件模块对《概要设计说明》(HLD)的符合程度。
问题: 如何理解软件间的接口？
软件不同部分之间的交互接口，通常就是所谓的API --- 应用程序编程接口，其表现的形式是源代码。
系统测试ST
系统测试是将已经集成好的软件系统，作为整个系统与计算机硬件、外设、数据和人员等其他元素结合在一起，在实际运行环境下，对系统进行一系列的测试工作。
目的: 与《需求规格说明书》(SRS)进行比较，发现软件与系统需求定义不符合或与之矛盾的地方。-
单元测试UT、集合测试IT、 系统测试ST的区别
UT/IT/ST的区别 系统整合测试SIT
系统整合测试就是评估产品在其规格范围内的环境下工作，能否完成产品设计规格所需的功能以及与周边设备、应用软件的兼容性。大致可以分为硬、软件兼容性测试，认证测试。冒烟测试
冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫就足够了。也有人认为是形象地类比新电路基本功能检查。任何新电路板焊接后，先通电检查，如果存在缺陷，电路板可能会短路，板子冒烟。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。
有的公司运作模式为"转测试"，测试需要的基本用例，全部通过后，才是进入系统测试的准则。可以由开发人员或是测试人员进行测试，某一特性或模块测试不通过，即转测试不通过，不可进行系统测试。
冒烟测试，在系统测试之前，对主要的功能进行测试；
回归测试
回归测试是指修改了旧代码后，重新进行测试以确定修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅度降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。回归测试策略
选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括:
a、再测试全部用例，选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。
b、基于风险选择测试，可以基于一定的风险标准来从基线测试用例中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级低的或高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级，一般而言，测试从主要特征到次要特征。
c、基于操作剖面选择测试，如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些可靠性有最大影响的故障。这个方法可以在一个给定的预算下最有效的提供系统可靠性，但实施起来有一定的难度。
d、再测试修改部分当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受影响的部分。
总结: 再测试全部用例的策略是最安全的策略，但已经运行过许多次的回归测试不太可能揭示新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时可以选择适当的策略进行缩减的回归测试。
- 验收测试
在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也成为交付测试。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
实施验收测试的常用策略有三种，分别是:
- 正式验收
- 非正式验收或Alpha测试
- Beta测试
- 正式验收
正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详情成都不亚于系统测试，选择的测试用例应该是系统测试中所执行测试用例的子集。
优点:
- 要测试的功能和特性都是已知的；
- 测试的细节是已知的并且可以对其进行评测；
- 这种测试可以自动执行，支持回归测试；
- 可以对测试过程进行评测和检测；
- 可接受性标准是已知的；
缺点:
- 要求大量的资源和计划；
- 这些测试可能是系统测试的再次实施；
- 可能无法发现软件中由于主观原因造成的缺陷，这是因为你只查找预期要发现的缺陷；
- 非正式验收或α测试
在非正式验收测试中，执行测试过程的限定不像正式验收测试中那样严格。在此测试中，确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例，测试内容由各种测试员决定。这种验收测试方法不像正式验收测试那样组织有序，而且更为主观。
大多数情况下，非正式验收测试时最终用户组织执行的。
优点:
- 要测试的功能和特性是已知的；
- 可以对测试过程进行评测和检测；
- 可以接受性标准是已知；
- 与正式验收测试相比，可以发现更多由于主观原因造成的缺陷；
缺点:
- 需求资源、计划和管理资源；
- 无法控制所使用的测试用例；
- 最终用户可能沿用系统工作的方式，并可能无法发现缺陷；
- 最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷；
- 用于验收测试的资源部受项目的控制，并可能受到压缩；
- β测试(UAT测试)
β测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。这些用户与公司签订了支持产品预发发行合同的外部用户，他们要求使用该产品，并愿意返回所有错误信息给开发者
与α测试不同的是，β测试测试时开发者通常不在测试现场。因此，β测试是开发者无法控制的环境下进行的软件现场测试；
β测试中，由用户记录下遇到的所有问题，包括真的和主观认定的，定期向开发者报告，开发者在中和用户的报告后，做出修改，在将软件产品交付给全体用户使用；
三、软件测试的方法
- 测试方法划分
1. 按代码是否可见划分
- 白盒测试
- 灰盒测试
- 黑盒测试
2. 按状态划分
- 静态测试
- 动态测试
3.按人机划分
- 手工测试
- 自动化测试
白盒测试
白盒测试，指的是把盒子盖子打开，去研究里面的源代码和程序结果。
它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序找那个的每条通路是否都能按预定要求正确工作。黑盒测试
黑盒测试，指的是把被测的软件看做是黑盒子，我们不去关注盒子里面的结构是什么样子的，只关心软件的输入数据和输出结果。
它只检查程序功能是否按照要求规格说明书的规定正常使用，程序是否能适当地接受输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。灰盒测试
灰盒测试介于黑盒测试与白盒测试之间。
可以理解为，灰测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表性的现象、事件、标志来判断内部的运行状态，有时候输入时正确的，但内部其实是错误的，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒测试。静态测试
静态测试，指不实际运行被测软件，而只是静态检查程序代码、界面或文档可能存在错误的过程。
静态测试包括:
- 对于代码测试，主要是测试代码是否符合相应的标准和规范；
- 对于界面测试，主要测试软件的实际界面与需求中的说明是否相符；
- 对于文档测试，主要测试用户手册和需求说明是否真正符合用户的实际需求；
动态测试
动态测试，指实际运行被测程序，输入相应的测试数据，检查输出结果和预期结果是否符合的过程。手工测试
手工测试，即由人去一个个的去执行测试用例，通过键盘鼠标等输入一些参数，查看发挥结果是否符合预期结果。自动化测试
自动化测试，把以人为驱动的测试行为转化为机器执行的一种过程。
通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与预期结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。
四、总结
- 单元测试、集成测试、系统测试、系统整合测试、验收测试
- 回归测试、冒烟测试
- 黑盒测试、白盒测试、灰盒测试
- 静态测试、动态测试
- 手工测试、自动化测试
