一、 软件相关知识
1.什么是软件？
软件=程序（源程序，目的程序）+数据+文档
备注：软件测试对象包括以上三部分
2.IT技术部门结构组成
-
产品部：用户需求文档（预期结果），界面原型图
-
开发部：编码，得到程序（源程序，目的程序）（实际结果）
-
测试部：比对实际结果与预期结果之间的差别（得到程序的bug、文档的bug、数据的bug）
-
运维部：后期运行上线中涉及的数据维护、技术问题等。
3.软件的生命周期（软件是怎么做出来的？）
-
项目计划
-
需求（需求规格说明书SRS）
-
设计（概要设计说明书+详细设计说明书）
-
编码（源程序，目的程序）
-
测试（bug）
-
运行上线
（测试从需求阶段就开始介入）
（瀑布模型中测试在编码之后介入）
4.软件的项目组成人员
-
项目经理
-
需求分析人员
-
设计人员
-
编码人员
-
测试人员
-
运维人员
-
配置管理人员：
配置项=代码+文档，整个软件研发过程中所有交付件。
- SQA：软件质量保障工程师
职责：
a) 指定规范，流程
b) 监督项目组成人员按照流程工作，若违反，提出NC项（不符合项）
c)检测评审项目成果，尤其是测试交付件
5.软件研发模型/流程
- 瀑布模型
100%需求——100%设计——100%编码——100%测试——投入使用
优点：需求稳定，重复工作少，质量高
缺点：项目周期长，成本高
- 螺旋模型
50%需求——50%设计——50%编码——50%测试——首版本上线
版本迭代，迭代周期4-8个月
- 敏捷模型（小版本迭代）
20%需求——20%设计——20%编码——20%测试——首版本上线
版本迭代，平均迭代周期1个月左右
优点：项目周期短，小版本迭代，快速上线
缺点：需求不稳定，重复工作多，质量下降
6.软件缺陷引入的原因
-
需求：50%~60% 不重视需求导致频繁变更
-
设计：20%
-
编码：15%
-
其他：5%
-
软件缺陷的分类
1) 遗漏：软件未实现需求中明确说明的部分
2) 错误：软件中的实际效果与需求中描述的不一致
3) 额外实现：软件实现了需求中未明确说明的部分
二、测试基础
1.软件测试的定义
使用人工或自动化的手段来运行软件的过程，其目的在于检测他是否满足规定的需求，或是弄清楚预期结果与实际结果之间的差别
2. 软件测试的目的
-
发现错误 有些错误偶发，有些错误藏很深
-
检测是否满足功能需求、性能需求、可靠性需求等
-
软件测试不能证明软件不存在缺陷
3.软件测试的原则
-
所有的测试工作都应该追溯到用户需求
-
尽早启动测试工作，需求阶段就介入
-
穷尽测试是不可能的
-
测试是有风险的 遗漏
-
并非所有的缺陷都值得修复
-
杀虫剂怪事（测试用例对缺陷存在免疫能力）
-
帕累托法则，28法则
80%缺陷存在于20%的核心业务模块中
- Bug的群集效应
发现的缺陷越多，说明存在的缺陷越多
A25个bug B6个bug 增强测试谁
- 前进两步，后退一步
V1.00
5000=500fail+4500pass
V1.01 回归测试
（1）验证缺陷修复是否正确（执行500条用例）
（2）重复测试
——完全重复测试（工作量巨大，考虑使用自动化）
——选择重复测试（主要选择相关功能进行重复测试）
三、测试方法
1.根据测试技术划分（根据是否关注程序内部结构）
-
黑盒测试：不需要关注程序内部结构
-
白盒测试：需要分析程序源代码（代码走查，写驱动，打桩）
-
灰盒测试：白加黑
2.根据是否动态运行软件
-
静态测试：测试过程中不需要运行软件，包括代码走查、需求评审、文档测试、用例评审
-
动态测试：测试过程中需要运行软件
3.根据是否使用自动化测试工具
-
人工测试
-
自动化测试
四、测试过程
1、 测试阶段
- 单元测试（UT）
测试范围：最小单位，函数或类
测试依据：详细设计说明书
测试方法：白盒测试
评估基准：逻辑覆盖，每个逻辑都测
- 集成测试（IT，组装测试）
测试范围：模块之间的接口，集成后的功能
测试依据：概要设计说明书（概设）
测试方法：灰盒测试
评估基准：接口覆盖
- 系统测试（ST）
测试范围：整个系统的功能及非功能（性能、兼容、安全、界面等等）
测试依据：需求规格说明书（SRS）
测试方法：黑盒测试
评估基准：需求覆盖
- 验收测试（UAT）
三种测试策略
a) 正式验收测试（外包）
——参与人员：以用户为主的测试，参与人员包括项目组人员（产品、开发、测试），用户代表
——验收测试的结果，两种（用户可接受；用户不可接受）
b) α测试：
——用户参与测试，在开发场地开展，旁边有技术人员指导
c) β测试：
——用户参与测试，在用户实际环境展开，无技术人员指导
