软件测试流程

在真实的工程实践中，不同的软件项目在研发生命周期的各个阶段都会有不同的测试类型。

软件模块集成阶段会有代码级集成测试，打包部署后会有面向终端用户的 GUI 测试；

再比如，电商网站的测试会分为服务器端基于 API 的测试、中间件测试、前端 GUI 测试等

测试过程

传统测试过程：

阶段	输入和要求	输出
Requirement review	市场产品需求定义，分析文档和相关技术文档	问题列表，批准需求分析文档。测试计划书起草。
Design Review	产品规格设计说明，测试计划和测试用例。	功能的测试计划和测试用例
Unit testing.	原程序编程规范产品规格设计说明书和详细程序设计文档。	缺陷报告，跟踪报告；完善的测试用例与计划。
Integration testing.	通过单元测试的模块或组件，编程规范，程序设计文档，系统设计文档。	权限报告跟踪报告完善的测试用例测试计划。集成测试分析报告，集成后的系统。
System testing.	代码软件包系统设计说明书测试计划，系统测试用例，测试环境等。	专业报告系统性能可靠性的分析报告缺陷报告，阶段性测试报告。
Acceptance testing.	产品规格设计说明预发布的软件包确认测试用例。用户要参与验收测试，包括阿尔法贝塔测试。	用户验收报告，缺陷报告，版本审查。最终测试报告

在单元测试中需要编写桩程序，即被测试【上层】模块调用的，得到相应的数据。

反之调用测试模块的为驱动程序。

你不仅需要从业务本身出发来对软件进行手工测试验证，

还需要掌握完整的自动化测试开发技术来设计自动化测试用例。

你必须系统性地思考如何才能将测试数据的准备工具化，服务化，最终实现平台化。

测试分类

压力、性能（响应时间）、安全性、兼容性、易用性

有界面需要做 GUI 测试，在网页中包括是否为

单元测试

单元测试的用例是一个“输入数据”和“预计输出”的集合。

在明确了代码需要实现的逻辑功能的基础上，什么输入，应该产生什么输出。

①单元测试总共四个阶段： setup ,exercise,verify, teardown

分别做准备，执行，验证，拆卸【垃圾回收可能会帮你做】

，如果没有明确的预计输出，那么测试本身就失去了意义。同样地，“预计输出” 绝对不是只有函数返回值这么简单，还应该包括函数执行完成后所改写的所有数据。

桩代码的应用首先起到了隔离和补齐的作用，使被测代码能够独立编译、链接，并独立运行。同时，桩代码还具有控制被测函数执行路径的作用。

总结：单元测试是对软件中的最小可测试单元在与软件其他部分相隔离的情况下进行的代码级测试；

自动化测试

对于一些中长期项目，我的建议是：对比较稳定的软件功能进行自动化测试，对变动较大或者需求暂时不明确的功能进行手工测试，最终目标是用 20% 的精力去覆盖 80% 的回归测试。

软件产品比软件项目更适合做自动化测试

需要在多种平台上重复运行相同测试的场景。

某些测试项目通过手工测试无法实现，或者手工成本太高。

被测软件的开发较为规范，能够保证系统的可测试性。

某些用例的自动化必须要求开发人员在产品中预留可测试性接口，否则后续的自动化 会很难开展。

单元测试阶段的“自动化”内涵不仅仅指测试用例执行的自动化，还应该包含以下五个方面：

用例框架代码生成的自动化； 2. 部分测试输入数据的自动化生成； 3. 自动桩代码的生成； 4. 被测代码的自动化静态分析； 5. 测试覆盖率的自动统计与分析。

白盒测试

分支覆盖保证语句覆盖【保证--> 强于】
条件覆盖一般强于分支覆盖
组合条件覆盖强于分支与条件覆盖

分支为走不同的流程。

可以将不同部分为模块测试。

逻辑驱动法
- 分支覆盖
- 条件覆盖
- 条件路径覆盖
基本路径测试方法
1. 程序流程图
2. 计算程序环境复杂
3. 确定基本路径
  使用到图形矩阵

的黑盒测试方法

是等价类划分和边界值分析方法

例：“用户登录” === 功能性测试

已经/未注册

输入正确/错误用户名

正确/错误密码

结果：登录成功/失败

验证码正确/失败

其他问题：

大小写敏感，
界面 : 密码加密
权限问题
tab,Enter 是否可用
其他功能问题：限制长度，pattern要求

测试需要根据需求分析报告功能来设计测试用例。显示功能性需求。

非功能性需求:主要涉及安全性，性能及兼容性三大方面。

安全性【安全性】

例如：在web应用下：

在用户名和密码输入框中分别输入典型的sql注入攻击字符串。

或者输入典型的xs跨站脚本攻击。

连续多次登录失败，系统是否会阻止尝试？

同一用户在同一终端多个浏览器上登录，以及同一用户在多台终端浏览器上登录。是否具有互斥性？

性能【服务器】

正常与极端情况下的响应时间。

并发场景下服务器监控指标，死锁与不合理资源等待。

兼容性测试

不同浏览器，不同设备，不同版本验证页面显示是否正常

不同分辨率，显示以及功能是否正确。

“穷尽测试”是指包含了软件输入值和前提条件所有可能组合的测试方法，

完成穷尽测试的系统里应该不残留任何未知的软件缺陷。

是采用基于风险驱动的模式，有所侧重地选择测试范围和设计测试 用例，以寻求缺陷风险和研发成本之间的平衡。

测试用例

记住：测试用例是用来保证功能完善性。

“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。测试用例是你在正确划分基础上的输入集合。

何为正确的划分？

整体完备性： “好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。【包括所有人】
等价类划分的准确性：指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。【需要选出一个代表】
等价类集合的完备性：需要保证所有可能的边界值和边界条件都已经正确识别。【包括所有阶级】

如等价类划分法、边界值分析法、错误推测方法、因果图方法、判定表驱动分析法、正交实验设计方法、功能图分析方法、场景设计方法、形式化方法、扩展有限状态机方法等等，

等价类划分、边界值分析和错误推测这三大类方法就足够了：

例：0~100 成绩输入系统

①等价类划分：

根据拥护可能输入的所有情况

数字
- 0~100整数
  - 0~59
  - 60~100
- 其他实数
  - 浮点数
- 其他整数
字符

②边界值分析：

得到所有测试用例

③错误推测方法

错误推测方法是指基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。

这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。

在软件企业的具体实践中，为了降低对个人能力的依赖，通常会建立常见缺陷知识库，在测试设计的过程中，会使用缺陷知识库作为检查点列表（checklist），去帮助优化补充测试用例的设计。

面向终端用户的 GUI 测试，最核心的测试点就是验证软件对需求的满足程度，这就要求测试工程师对被测软件的需求有深入的理解。

在我看来，深入理解被测软件需求的最好方法是，测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。

可能从业务需求的角度去设计针对性明确、从终端用户使用场景考虑的端到端（End-2-End）的测试用例集。

总结：

只有深入理解被测试软件的架构，你才能设计出“有的放矢”的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。
必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑。
. 需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。