一、软件测试的概念与过程
1.1 软件的概念与分类
软件：是计算机系统中与硬件相互依存的一部分，包括程序、数据以及与其相关文档
的完整集合
- 程序是按事先设计的功能和性能要求执行的指令序列
- 数据是使程序能正常操作信息的数据结构
- 文档是与程序开发、维护和使用有关的图文材料
1.2 软件的分类
按功能用途分：
系统软件
操作系统：Unix、DOS、Windows、Linux 等。
驱动程序
支持软件
界面工具：X Window 等。
开发工具软件：Visual Studio、JBuilder、Eclipse 等。
数据库管理系统：SQL Server、Oracle、MySQL 等。
应用软件
QQ、游戏、各类网站、搜狗输入法等。
按架构分（重点）：
单机软件：
蜘蛛扑克、扫雷等
分布式软件：
C/S 软件（架构）
- Client/Server，客户端/服务器
- 需要安装用户应用程序，服务端负责处理数据，客户端负责与用户交互
- 特点是有专用客户端。
- 如 QQ、微信等。
- 优点：可充分发挥客户端处理能力，服务器负荷较轻
- 缺点：用户必须安装对应的应用程序，服务器负荷较轻，应用程序需要适配不同的设备
B/S 软件（架构）
- Browser/Server，浏览器/服务器
- 特点是使用通用客户端。
- 无需安装特定的应用程序，浏览器即为统一客户端，几乎所有的逻辑处理和交互都有服务器完成
- 如网上银行、论坛、网页游戏等
- 优点：维护和升级的方式更简单；成本低
- 缺点：服务器负荷较重
1.3 软件缺陷产生的原因
- 需求不明确。软件需求不清晰或开发人员对需求理解不明确，从而导致软件在设计时偏离了客户的需求目标
- 客户--开发中通信失效
- 软件结构复杂。
- 编码问题。在开发过程中，程序员水平参差不齐，再加上开发过程中缺乏有效沟通和监督等
- 项目周期短。
- 使用新技术。在使用技术上开发时，如果新技术不成熟或者是开发者对新技术掌握不精也会影响
- 测试过程的不足
- 不符合文档编制与编码规定
- ...
软件测试的目的：
- 对于开发者来说，软件测试就是通过找到的问题缺陷来帮助开发人员找到开发过程中存在的问题，比如开发的模式、技术等方面的问题，从而预防下次缺陷的产生
- 对于软件测试来说，使用最少的人力、物力、时间等找到软件中隐藏的缺陷，从而保证软件的质量，同时也是为以后软件的测试积累经验
- 对于客户需求来说，软件测试能够检验软件是否符合客户需求，对软件质量进行评估和度量，为客户评审软件提供有力的依据
软件测试：使用人工或者自动的手段来运行或者测定某个系统的过程，目的在于检测它是否满足规定的需求或是弄清预期结果和实际结果之间的差别
不同时期关于测试的其他定义：
1.4 软件测试的流程
- 编写测试计划。比如测试一个软件的周期大概是多长、测试的人员大概有哪些、需要测试哪些、不需要测试哪些等
- 分析测试需求。这里可能包括很多，比如从开发人员那里获取的文档、用户提供的一些文档以及测试经理提供的文档等，通过这些文档去了解用户真正的需求是什么
- 设计和编写测试用例。根据需求来列举一些案例，比如测登录部分我有哪些方法可以进行测试，例如我可以输账号正确的也可以输账号错误的等
- 搭建测试环境。例如需要安装哪些操作系统，linux还是windows甚至是其他的一些，操作系统里面需要安装哪些软件等
- 执行测试用例，提交测试报告以及跟踪缺陷报告。根据所写的用例进行操作，发现问题后反馈给开发人员进行修改，在开发人员修改后需要再次进行测试即跟踪缺陷
- 测试评估和总结。在以上流程都完成后，可能需要考虑以上的测试够不够，还需不需要从增加一些测试以及在整个测试过程中发现了多少缺陷，解决了多少、哪些是必须要解决的，哪些是暂时可能不需要解决的、总共写了多少测试用例，满不满足需求等
1.5 区分 三个概念
测试 & 调试：
软件质量保证 & 软件测试：
二、软件测试的原则与测试工程师的要求
所有的测试都应追溯到用户需求：软件缺陷出现最多的地方是软件需求规格说明书（即软件需求定义），而不是程序代码
缺陷雪崩：
测试的成本：
2.1 软件测试的原则
- 测试应基于客户需求。所有的测试工作都应该建立在客户需求的基础之上
- 测试要尽早进行。软件的错误存在软件生命周期的各个阶段，因此应该尽早开始测试，这样测试人员能够尽早地发现和预防错误从而提高测试效率
- 穷尽测试是不可能的。由于时间和资源的限制，进行完全的测试是不可能的
- 遵循GoodEnough原则。GoodEnough即测试的投入与产出要适当权衡，形成充分的质量评估过程，整个过程建立在测试花费的代价上。测试不充分会导致无法保证软件质量，测试过多投入又会造成资源浪费，因此在测试时要根据实际要求和产品质量考虑测试的投入
- 测试缺陷要符合“二八”定理（Pareto）。一般情况下，软件80%的缺陷会集中在20%的模块中，缺陷并不是平均分布的，因此在测试的时候，要抓住主要矛盾，如果发现某些模块比其他模块具有更多的错误，则应投入更多的人力、精力去重点测试这些模块以提高测试效率
- 尽可能使用分阶段测试。例如单元测试、继承测试、系统测试、验收测试等
- 测试旨在发现存在的缺陷。
- 并非所有软件缺陷都要修复。
- 避免缺陷免疫。同样的测试用例被反复使用，发现缺陷的能力就会越来越差；测试人员对软件越熟悉就会忽略掉一些看起来比较小的问题，发现缺陷的能力就会越来越差
2.2 软件测试行业概述
乐趣：
- 破坏程序纯粹的快乐
- 破坏行为具有价值
- 体现出魔术般的力量
- 学习的乐趣
烦恼：
- 必须追求完美
- 由他人来设定目标，供给资源，提供信息
- 测试往往是线性收敛
- 投入了大量辛苦，用户发现的致命缺陷将否定全部工作
第三方测试：
是指独立于软件公司自身测试的测试，所谓的第三方是指在软件公司和软件用户之间的另一方
优秀的软件测试工程师品质：
态度
有责任心
破坏的态度
对事不对人
三心二意
细心、信心、耐心
团队合作的沟通意识、时刻保持怀疑的态度（即缺陷预防意识）
具备一定的开发技能
了解开发原理
便于与开发沟通
习惯打破砂锅问到底（善于思考）
改善测试员和其他小组成员之间的沟通和相互关系的方法：
以合作而不是争斗的方式开始项目
时时提醒项目的每位成员：共同目标是追求高质量的产品。
对产品中发现的问题以中性的和以事实为依据的方式来沟通
不要指责引入这个问题的小组成员或个人。比如，客观而实际地编写缺陷报告和评审发现的问题。
换位思考
尽量理解其他成员的感受，以及他们为什么会有这种反应。
有效沟通
开发与测试具有不同的思维方式，确信其他成员已经理解你的描述，反之亦然。
提高开发技能
三、软件开发和测试模型
3.1 软件开发模型
软件开发生命周期模型是软件产品从最初构思到退役的过程
软件的生命周期（重点）：
通俗来讲就是一个软件从定义、开发直到被淘汰下线的过程
大致需要经历如下几个步骤：
- 市场调研：市场调查、需求收集
- 可行性分析：根据公司能力和需求实现后能够带来的收益进行分析
- 需求开发：明确详细的需求，形成软件需求规格说明书（是开发和测试的依据）
- 设计：UI设计、模块设计、架构的选型等
- 编码：用代码去实现
- 测试：验证软件的功能是否完善且正确等
- 上线运营：发布上线、运营、维护
- 下线废弃
常见的开发模型：
- 大爆炸模型
- 边写边改模型
- 瀑布模型
- 螺旋模型
- 敏捷开发模型
- 快速原型模型
- 迭代模型
- ...
i. 大爆炸模型（直接冲过河去的 模型）：
一大堆东西（人力和资金）放在一起，巨大的能量释放，要么产生了优秀的产
品，要么是一堆废品
特点：
- 大爆炸模式是最简单的软件开发模式，计划、进度安排和正规开发过程都几乎没有，所有精力都花在开发软件和编写代码上
- 一般，大爆炸模式几乎没有测试，即使有也要挤在产品发布前，通常都会避免在此模式下进行测试
ii. 边写边改模型
从最开始的一些粗略的想法，接着进行一些简单的设计，然后开始漫长的来回编写、测试和修改缺陷的过程，直到觉得足够才发布产品
特点：
- 没有计划和文档编制，项目能够迅速展现成果，所以比较适合用完就扔的项目
- 测试在边写边改模式中未特别强调，但是在编写代码和修复缺陷过程中举足轻重
- 软件测试会陷入无休止的循环往复，因为每天都可能在测试新版本
iii. 瀑布模型
采用瀑布模式的项目从最初的构思到最终产品要经过一系列步骤。每一个步骤结束时，写好文档，项目小组组织审查，并决定是否进入下一步。如果项目未准备好进入下一步，就停滞下来直到准备好
特点：
- 瀑布模式所有一切都有完整细致的说明
- 测试对象非常明确，即程序（缺点）
- 在瀑布模型中，测试被认为是在软件开发过程的后期阶段进行的“一次性”活动，这带来一个巨大的缺点，因为测试仅在最后进行，所以一些根本性问题可能出现在早期，但是直到准备发布产品时才可能发现
iv. 螺旋模型
开始不必详细定义所有细节，从小开始，定义重要功能，努力实现这些功能，接收客户反馈，然后进入下一阶段，重复上述过程，直至得到最终产品
特别适合于大型复杂系统
特点：
- 融合了瀑布模型（分析、设计、开发和测试的步骤）、边写边改模型（螺旋模式的每一次）和大爆炸模型（从外界观察）的一些特点
- 引入了其他模型所忽略的风险分析，在进入下一阶段之前需进行风险评估，这样一直循环往复直到完成所有阶段的任务
敏捷模型：
敏捷开发的核心思想是：以人为本，适应变化
特点：
- 以用户需求为核心，采用迭代（迭代，就是不断对产品进行详细、渐进式的改进，每次改进一小部分，如果可行再逐步扩大改进范围）、循环渐进的方式进行软件开发
- 软件项目在构建初期被拆分为了多个相互联系又各自独立运行的子项目，然后迭代完成各个子项目，开发过程中，各个子项目都要经过开发测试
- 当用户有需求变更时，敏捷模型更够迅速地对某个子项目做出修改以满足客户的需求
3.2 软件测试模型
常见的测试模型：
- V 模型
- W 模型
- H 模型
- X 模型
- 前置模型
- 敏捷测试模型
- ...
i. V 模型
“V”的左端表示传统的瀑布开发模型，而“V”的右端表明相应的测试阶段
优点：
- 明确地将测试分为不同的级别或阶段
- 每个阶段都与开发的各阶段相对应
- 测试策略包括低层测试和高层测试，低层测试是为了源代码的正确性，高层测试是为了整个系统满足用户的需求
缺点：
- 测试是开发之后的一个阶段。实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现
- 测试的对象就是程序本身。忽视了测试活动对需求分析，系统设计等活动的验证和确认的功能，直到后期的验收测试才被发现
- 过程是线性的、顺序的，不能反复和迭代
ii. W 模型
W 模型既强调了测试方案设计，也强调了测试执行
优点：
- W 模型从 V 模型演化过来，实际上开发是 V，测试是并行的 V，测试与开发同步进行，有利于尽早地全面的发现问题
- 测试伴随整个软件开发周期
- 测试的对象不仅仅是程序，需求、设计等同样要测试
缺点：
W 模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型
iii. H 模型
真正的测试级别之间不存在严格的次序关系，各阶段间可以反复触发、迭代、增量
特点：
- 将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。测试贯穿产品整个生命周期，与其他流程并发地进行
- 软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的
软件测试不仅仅指测试的执行，还包括很多其他的活动（计划、需求分析、用例设计、环境搭建、提交缺陷、评估总结等）
当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶
软件测试要尽早准备，尽早执行
iv. 敏捷测试模型
基于 XP 的项目的步骤：
敏捷测试的要点总结：
- 不同的软件生命周期模型需要使用不同的测试方法
- 应尽可能地去应用模型中对项目有实用价值的方面，但不强行地为使用模型而使用模型，否则也没实际意义
- 各种模型可以适当结合
四、软件测试阶段
测试阶段也称测试级别
4.1 软件测试分类
按照测试阶段分类：
- 单元测试
- 冒烟测试：对系统的基本功能进行简单的测试，终点是验证程序的主要功能，不会对具体功能进行深入测试
- 集成测试：将已经测试过的单元组合在一起测试它们之间的接口，用于验证软件是否满足设计需求
- 系统测试：将经过测试的软件在实际环境中并与其他系统的成分（如数据库、硬件等）组合在一起进行的测试
- 验收测试：对软件产品的说明进行验证，逐行逐句安装说明书的描述对软件产品进行测试，确保符合客户的各项要求
按照测试技术分类：
- 黑盒测试：将程序当做一个输入域到输出域的映射，只要输入的数据能输出预期的结果即可，不必关系程序内部是怎样实现的
- 白盒测试：需要知道程序内部的实现流程，具体是怎么实现的
按照软件质量特性分类：
- 功能测试：测试软件的功能是否满足客户的需求，包括准确性、易用性、适合性等
- 性能测试：测试软件的性能是否满足用户的需求，包括负载测试、压力测试、兼容性测试、可移植性测试、健壮性测试等
按照自动化程度分类：
- 手工测试
- 自动化测试
- 按照测试类型分类：
- 界面测试：验证软件界面是否符合客户需求，包括界面是否美观、按钮是否齐全等
- 安全性测试：测试软件在没有授权的内部或外部用户的攻击或恶意破坏时如何进行处理，是否能保证软件与数据的安全
- 文档测试：以需求文档、软件设计、用户手册、安装手册为主，主要验证文档说明与实际软件之间是否存在差异
其他分类：
- α测试：对软件最初版本进行测试
- β测试：对上线之后的软件版本进行测试
- 回归测试：当发现缺陷并由开发人员修改，对修改后的程序再次进行测试，并且不会引入新的缺陷
- 随机测试
4.2 单元测试
组件也称为单元
什么是组件测试：
组件测试（Component Testing）也称单元测试
组件测试的 重点 、 所需知识 和 前提条件：
组件测试使用 的技术 、 能够发现的缺陷：
组件测试需要编码：
4.3 集成测试
什么是集成测试：
单元测试通常是单人执行，而集成测试通常是多人执行或第三方执行
集成测试的重点 、所需知识 和前提条件：
集成测试使用的技术 、 能够发现的缺陷：
集成测试的策略：
4.4 系统测试
系统测试的 重点 、 所需知识 和 前提条件：
系统测试使用 的技术 、 能够发现的缺陷：
4.5 验收测试
验收测试的 分类：
扫一扫
1241
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
