一：软件的生命周期：
问题的定义及规划：此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
做不做。
需求分析：在确定软件开发可行的情况下，对软件需要实现个各个功能进行详细分析。
做什么。
软件设计：怎么做
程序编码：做
软件测试：系统测试
运行维护：持续最久阶段
二：软件开发模型
瀑布模型
快速原型模型
增量模型
螺旋模型
三：软件测试与软件质量
质量保证（QA）：主要着眼于软件开发活动中的过程，步骤和产物，而不是对软件进行剖析找出问题或者评估。监督过程。
软件测试：关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。监管产品。
软件的组成：文档+程序+数据
比如：
需求文档
概要设计文档
详细设计文档
操作手册
源程序
......
四：软件测试分类
按开发阶段来划分：
单元测试
集成测试
系统测试
验收测试
按照测试实施组织划分：
开发方测试：alpha测试
用户方测试：Beta测试
第三方测试
按照测试技术划分：
白盒测试
黑盒测试
灰盒测试
OR
静态测试
动态测试
按测试需求划分：
功能测试
性能测试
...
按其他分类：
回归测试（部分回归、全部回归）
冒烟测试（smoke testing）
随机测试
五：软件测试过程模型
v模型：线性的
W模型：双V模型，开发的每个阶段都有测试测试活动与之相对应
H模型：H模型指出软件测试要尽早执行，只要某个测试达到准备就绪点，测试执行活动就可以展开。
X模型
前置测试模型
六：软件测试过程（重要）
测试需求分析
测试计划编写
测试用例设计（用例需要评审）
测试环境搭建
测试执行阶段
测试结果验收
什么是测试需求？
测试需求主要解决“测什么”的问题，即细化被测对象。
测试测试需求通常是以软件开发需求为基础进行分析，通过对开发需求的细化和分解，形成可测试的内容。
测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求。
软件测试计划：
测试计划Test plan,描述了要进行的测试活动的范围、方法、资源和进度的文档，它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。
测试计划包含6要素（5W1H）：
1)why——为什么要进行这些测试；
2)what——测试哪些方面，不同阶段的工作内容
3)when——测试不同阶段的起始时间
4)where——相应的文档、缺陷的存放位置，测试环境等
5)who——项目有关人员组成，安排哪些测试人员进行测试
6)how——如何去做，使用哪些测试工具以及测试方法进行测试
测试用例（TestCase）
测试用例就是一个文档，描述输入、动作、和一个期望结果，其目的是确定用于程序的某个特性是否正常的工作。
测试用例是软件测试的核心。
测试用例需要评审
测试用例包含主要哪些主要因素：
用例编号
测试的标题
优先级别
测试输入
操作步骤
预期结果
提交缺陷（通过缺陷管理工具，禅道或者jira）
缺陷报告的组成：
主要包括：
1)缺陷的标题
2)重现的步骤（包含步骤、期望结果、实际结果）
3)严重级别
4)优先级别
5)缺陷的类型
6)指派给谁
7)软件版本
8)模块
9)bug产生的环境，操作系统和浏览器
10)附件
11)一个缺陷报告中只能包含一个缺陷
缺陷的严重性与优先级
严重性：
1、致命：导致程序崩溃
2、严重：功能不通（比如注册失败）
3、一般：结果不正确（数据不一致）
4、不严重：界面上的问题（图片无法显示，文案错误），不影响功能的使用
优先级：
1、最高优先级
2、次高优先级
3、中等优先级
4、最低优先级
缺陷的生命周期
1)激活（测试）—>确认（开发）—>已解决（开发）—>关闭（测试）
2)激活（测试）—>确认（开发）—>已解决（开发）—>激活（测试）—>已解决（开发）—>关闭（测试）
思考：软件缺陷最主要是由哪些方面引起的？-需求
需求（56%）
设计（27%）
代码（7%）
其他（10%）
测试进度报告：
包含哪些内容：
1、今日Case执行情况/今日进度：
Total Case Executed Case Succeed Faile New bugs
注：Case执行情况可以用进度百分比来说明，同时讲讲清楚执行了哪些模块
2、Bug统计和分析
Total Active Close Resolved
3、风险评估
例如：
哪些bug block了测试进度，需要研发给出具体的修复时间
在测试计划时间内，该提测的内容没有准时提测，需要研发重新给出提测的具体时间
4、遇到问题
5、明日工作内容
测试报告（系统测试报告一般由测试组长编写）
测试环境（软硬件配置、网络环境）
测试的执行统计：测试的执行时间、测试的人力投入
测试的内容：测试功能模块、子功能、是否有遗留问题、遗留问题单号
测试结果：A类问题、B类问题、C类问题、D类问题、测试通过的标准、功能测试结论
问题统计及分析：问题按模块统计、问题按严重性统计、问题的详情、遗留问题分析
测试结论
黑盒测试技术
功能测试
数据驱动测试
基于软件需求规格说明书
测试用例的设计方法：
等价类划分
边界值分析法
因果图法
决策表法
错误猜测法
正交实验法
场景法
等价类划分：依据需求对输入的范围进行细分，然后再分出的每一个区域内选取一个有代表性的测试数据开展测试。
等价类=有效等价类+无效等价类
有效等价类：符合需求说明，合理地输入数据集合
无效等价类：不符合需求说明，无意义地输入数据的集合
等价类划分步骤：
1、依据常用的方法划分等价类，找出有效等价类和无效等价类
2、为等价类表中的的每一个等价类分别规定一个唯一的编号
3、设计一个新的用例，使它能够尽量多覆盖尚未覆盖的有效等价类。重复该步骤，直到所有的有效等价类均均被用例覆盖
4、设计一个新的用例，似它仅仅覆盖一个尚未覆盖的无效等价类。重复该步骤，直到所有的无效等价类均被覆盖。
何时采用？
-任何测试过程都需要采用
把可能的用例组合缩减到足以满足测试需求为止
边界值法
边界值分析法是对输入或者输出的边界值进行测试的一种测试方法，边界值分析法是作为对等价类划分法补充。
何时采用边界值？
边界值法是对等价类法的补充，两者结合使用
等价类与边界值的区别
--不是典型值，而是所有边界值
--不仅考虑输入，还要考虑输出
错误猜测法：
基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
场景法：
什么是场景？
由一系列相关活动组成、且场景中的活动还能有一系列场景组成。
从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景，通过运用场景来对系统的功能点或业务流程进行描述，从而提高测试效果。
基本流+备用流=场景法
场景法设计测试用例的步骤：
1：根据需求，描述出程序的基本流和备选流
2：根据基本流和各项备选流生成不同的场景
3：对每一个场景生成相应的测试用例
4：审核用例，去掉冗余，给用例确定测试数值
场景法适用场景：解决业务流程清晰的系统或者功能
基本流：最短路径、无差错、程序从开始执行直接到结束
备选流：特定情况下发生
因果图法：
因果图法是从需求中找出找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换成判定表。
-输入条件之间的关系（组合关系、约束关系等）
-输入和输出之间的关系
因果图步骤：
1、提取因果，赋予标识符
2、提取因果关系、表示因果图
3、表名约束条件
4、转换判定表
5、设计测试用例
如果是N个条件:2的N次方组合
因果图法什么时候使用？
-应用的输出结构依赖于各种输入条件的组合或各种输入条件之间有某种相互制约关系时
-当软件的输入条件过多时，可以考虑输入的所有排列组合情况，考虑条件之间的和条件结果之间关系，防止遗漏
因果图与等价类+边界值的区别：
等价类+边界值：着重考虑输入条件，忽略输入条件的组合情况以及各个输入条件之间的相互制约关系
因果图：针对输入条件之间的关系，考虑输入条件之间的组合，约束等情况
界面测试：UI testing
UI测试范围：
风格（主色调、背景）
正确性（标志、文字、图片、弹出提示信息）
一致性（单一页面、多个页面）
合理性（布局、工具栏图标、放大缩放时）
美观协调
等等
易用性测试：
安装易用性
功能易用性
界面易用性
辅助系统易用性
兼容性测试：
文档测试：
Web专项测试：
转载：https://blog.csdn.net/JCY58/article/details/101704463
查看评论