软件生命周期

软件开始研制到最终被放弃不用所经历的各个阶段
需求-设计-编码-测试-维护-弃用

软件开发模型

瀑布模型
需求分析-概要设计-详细设计-编码-测试-维护
优点：线性模型，文档驱动，只用关注当期阶段
缺点：不响应需求变化，测试人员没有尽早介入
敏捷开发模型
基础功能流程完成，之后迭代开发新的功能。以用户为中心、以客户需求为导向的开发过程，在此过程中随时做好“迎接变化”的准备，客户是敏捷的关键环节。

软件测试模型

V模型
需求分析-概要设计-详细设计-编码-单元测试-集成测试-系统测试-验收测试
优点：模型明确地将测试分为不同的级别或阶段；每个阶段都与开发的各阶段相对应；模型的测试策略包括低层测试和高层测试，低层测试是为了源代码的正确，高层测试是为了整个系统满足用户的需求。
缺点：测试是开发之后的一个阶段。实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现；过程是线性的
W模型
开发V：需求分析-概要设计-详细设计-编码-集成 -实施-交付
测试V：需求测试-概要设计测试-详细设计测试-单元测试设计-集成测试设计-系统测试设计-验收测试设计
测试伴随整个软件开发周期。测试的对象不仅仅是程序，需求、设计等同样要测试。

软件质量模型

功能性：能够满足明确和隐含要求的功能
可靠性：能够处理异常情况，在错误中很快恢复
易用性：易懂、易学、易用、漂亮好看
效率性：占用的资源，提供适当的性能。通常，效率就是我们常说的产品性能
维护性：是指产品可被修改的能力
可移植性：是指软件产品从一种环境迁移到另外一种环境的能力

软件测试分类

按阶段分类

单元测试
逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析
单元：单元是程序里最小的，可单独执行编码的单位。
如：源代码：如JAVA中的一个类/C语言中的一个函数，用白盒测试；功能模块：如web产品的一个页面，用黑盒测试
集成测试
将所有程序模块进行有序的、递增的测试，测试关注点是接口的传递参数与返回数据
系统测试
根据需求说明书，测试集成系统以验证整个系统功能与非功能是否满足需求。关注软硬件，分为自底向下和自顶向上，一般为黑盒测试。
验收测试
由用户验证是否可以接受整个系统，目的是识别未知应用环境对系统的影响。
α测试：内测版本
在软件公司内部展开的测试，由公司专业的测试人员执行的测试
β测试：公测版本
在软件公司外部展开的测试，可以由非专业的测试人员执行的测试

按是否看源代码分类

黑盒测试
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用
白盒测试
白盒测试也称结构测试或逻辑驱动测试，是指基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径、条件的测试
覆盖准则由弱到强依次是语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖
语句覆盖：程序中每条语句至少被执行一次。
判定覆盖：程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。
条件覆盖：每个条件至少有一次为真值，有一次为假值。
判定/条件覆盖：判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。
组合覆盖：每个判定中条件结果的所有可能组合至少出现一次。
路径覆盖：覆盖程序中所有可能的路径。

灰盒测试
灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况
通常，灰盒方法中使用自动化软件测试工具来执行测试过程。提供给测试人员的模块驱动程序可以减轻手动代码生成的负担。

是否运行

静态测试
静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性
动态测试
动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能。

是否自动化

手工测试自动化测试

其他策略

冒烟测试：对系统进行最基本功能的测试
最核心的业务流程（注册==》登录==》选商品==》购物车==》支付==》订单管理）
回归测试：修复一个bug后，把之前测试用例在新代码下重新测试 bug回归旧功能回归
随机测试：对被测软件的重要功能进行复测
探索性测试：同时设计测试用例与执行测试，边测试边学习被测系统

软件测试流程

需求评审
前期准备：
明确自己负责的需求模块，提前熟悉需求文档，针对需求描述，思考如何进行测试设计，只要需求的描述不能够完全支持写用例，就要提出来（二义性、模糊、描述不清楚）
评审过程中：
产品、开发、测试开会来评审需求内容，评审需求说明书是否有遗漏，确保项目组的成员对于需求说明书的理解达成一致
制定测试计划和测试方案
测试计划：
测试的目的和范围执行计划的角色和用户任务的进度安排风险估计与应急预案测试的准入及准出标准
测试方案：
测试策略测试环境测试工具
设计测试用例
执行测试用例与缺陷管理跟踪
编写测试报告

缺陷及缺陷管理

缺陷：产品实现不满足用户需求或测试执行时，实际结果和预期结果不一致
缺陷的判定标准：未达到需求说明书指明的功能；出现了需求说明书指明不应该出现的错误；实现了需求说明书之外的功能；未达到需求说明书虽未明确提及但是应该实现的目标（如：性能要求等）；用户角度发现的各种问题与错误
缺陷要素：
ID编号模块优先级标题严重程度
前置条件复现步骤实际结果预期结果附件

测试用例设计方法

等价类划分法

概念
一类具有共同特性的测试输入的一部分（测试子集）
作用
利用科学的方法将测试从无穷的穷举测试（测试输入全集）中解放出来
分类
有效等价类，无效等价类
设计测试用例的步骤
需求分析-划分等价类-设计测试用例
典型应用场景
具有输入功能，但输入之间没有组合关系

边界值分析法

边界确定
上点：边界上的点（正好等于），必选
离点：距离上点最近的点（刚好大于、刚好小于），开内闭外
内点：范围内的点（区间范围内的数据），必选
设计测试用例的步骤
明确需求-确定有效和无效等价类-确定边界范围值-提取数据编写测试用例
典型应用场景
在等价类的基础上针对有边界范围的测试数据输入的地方，常见词语描述：大小、尺寸、重量、最大、最小、至多、至少等修饰词语，如有边界范围的输入框类测试

场景法

概念
用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例
设计测试用例的步骤
需求分析-绘制流程图（确认场景中关键业务步骤-确定业务之间的先后顺序-用箭头连接即可）-设计测试用例（一条流程路径就是一条测试用例）
典型应用场景
对于多个功能之间的组合逻辑测试，可以使用场景法

判定表法

概念
一种以表格形式表达多条件逻辑判断的工具
条件桩：列出问题中的所有条件。列出条件的次序无关紧要。
动作桩：列出问题中可能采取的操作。操作的排列顺序没有约束。
条件项：列出条件对应的取值。所有可能情况下的Y/N值或0/1值。
动作项：列出条件项的各种取值情况下应该采取的动作结果。
设计测试用例的步骤
明确条件桩（找到所有的输入条件）-明确动作桩（找到所有的输出结果）-对条件桩进行全组合-明确每个组合对应的动作桩（基于每一种条件的组合情况，确定本组合下的输出结果）-设计测试用例，每行数据对应一条测试用例
典型应用场景
有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系

因果图

概念
用图解的方法表示输入的各组合关系，写出判定表，进而设计测试用例的一种【黑盒测试】方法
基本符号
恒等（-）：条件成立，结果成立。
非（~）NOT：条件成立，结果不成立；条件不成立，结果成立。
或（V）OR：只要有一个条件成立，结果就成立；所有条件都不成立时，结果才不成立。
与/且（^）AND：多个条件必须同时成立，结果成立；只要有一个不成立，结果就不成立。
设计测试用例的步骤
需求分析-画出因果图-将因果图转换为判定表-生成测试用例

正交法

概念
用最小的测试用例获得最大的测试覆盖率
k因素m水平Ln(mk)
k代表因素（输入参数）
m叫水平（输入参数的取值）
n代表测试用例数
设计测试用例的步骤
需求分析-确定因素与水平（因素：控件名称；水平：每个控件对应的取值）-确定要采用的正交表-将正交表中的字母用文字代替-设计测试用例（一行就是一条测试用例）