测试执行流程与规范
目录
1.软件测试基本流程图
2.测试各阶段工作流程
2.1需求分析、评审阶段
2.2 测试计划阶段
2.3 测试设计阶段
2.4测试实施阶段
2.5 测试结束阶段
3.测试的常见类型（按阶段区分）
3.1 单元测试
3.2 集成测试
3.3 冒烟测试
3.4 系统测试
3.5 回归测试
3.6 验收测试
4.测试的常见类型（按内容区分）
4.1 功能测试
4.2 UI测试
4.3 接口测试
4.4 性能测试
4.5 兼容性测试
4.6 安全测试
5.缺陷管理
5.1 缺陷提交规范
5.2 缺陷生命周期
5.3 缺陷等级划分
5.4 缺陷的状态
5.5 用例执行结果
1.软件测试基本流程图
2.测试各阶段工作流程
2.1需求分析、评审阶段
目的：
- 评估需求是否可实现、需求主逻辑是否正确、是否满足产品预期
- 明确产品方向、基本功能、用户需求
- 核实需求的描述是否准确、完整
- 确保产品、开发、测试对功能的理解一致
- 站在用户的角度，以用户的要求进行详尽的分析后对需求进行评审
- 以测试人员的角度，审查需求是否定义了清晰的测试标准和测试规范；在需求评审前，测试人员应尽可能详细的了解项目的需求，并且收集尽可能多的与项目相关的专业知识。
| 过程要点 | 详细说明 |
| 输入条件 | 项目进入软件设计阶段，至少有需求文档、软件设计说明书或软件原型 |
| 工作内容 | 测试人员根据相关文档梳理、提取测试点，确定测试内容（功能、性能、兼容性等）、使用的测试方法（手工测试、自动化测试），以保证此次需要测试的内容覆盖完整。 |
| 退出标准 | 提取完整的测试需求点 |
| 输出内容 | 明确测试内容，列出具体功能列表 |
2.2 测试计划阶段
目的：
- 对需求模块进行拆解深入分析与开发了解相关实现逻辑方案
- 评估功能新增、修改后的影响范围
- 罗列相关的测试模块、测试阶段、所需时间、测试人员安排
- 公示输出的测试方案、粗略计划、详细安排计划
2.3 测试设计阶段
测试人员根据软件需求规格说明书和产品设计说明书编写测试用例。根据每一个测试需求点和功能点，运用不同的用例设计方法编写用例，针对不同的测试内容，可能会涉及到的用例包括：功能测试用例、性能测试用例、接口测试用例、自动化测试用例。测试用例编写完成后需进行用例的评审。
2.4测试实施阶段
1）按照制定的测试计划进行测试
2）及时检查是否有风险，并及时上报
3）针对每个功能场景，需熟悉到业务实现层逻辑，考虑更多影因素，补充用例
4）使用测试管理工具记录、提交、跟踪缺陷，并督促开发人员复现、定位、修复缺陷，然后验证和关闭缺陷
2.5 测试结束阶段
约定的测试周期完成后，测试人员总结此次测试结果，编写测试报告
3.测试的常见类型（按阶段区分）
3.1 单元测试
完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。
3.2 集成测试
集成测试也称为组装测试或联合测试。在单元测试完成的基础上，各模块联调测试。集中在各模块接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的验证等；可以是整个产品的集成测试，也可以是大模块的集成测试，集成测试主要是针对程序内部结构进行测试，特别是针对程序之间的接口进行测试。集成测试分为两种形式：
自顶向下集成：模块的集成顺序是首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。
自底向上集成：从原子模块开始来进行构造和测试，对底层组件行为较早验证，工作最初可并行执行，比自顶向下效率高。缺点是驱动的开发工作量大，对高层的验证被推迟，设计上的错误不能被及时发现。适应于底层接口比较稳定，高层接口变化比较频繁，底层组件较早被完成。
3.3 冒烟测试
冒烟测试是开发完成之后，正式移交测试前做的测试工作。开发人员对软件主要功能进行验证，如果通过该测试，可以移交测试进行正式测试，否则重新编译版本，直至成功，该过程可由开发人员自测，保证移交测试版本的质量，防止出现阻碍测试的情况出现。
3.4 系统测试
系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足需求规格的定义，找出与需求规格不符或矛盾的地方，从而提出更加完善的方案，是整个测试最关键重要的部分。系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包括软件依赖的硬件、外设甚至包括某些数据、某些支持软件及接口等。因此，必须将系统中的软件与依赖的各种资源结合起来，在系统的实际运行环境中进行。
3.5 回归测试
回归测试是指在发生修改之后重新测试先前修改的用例以保证修改的正确性。回归测试目的在于验证以前出现过但已经修复好的缺陷不在重新出现。
3.6 验收测试
验收测试是系统开发生命周期方法论的一个阶段，相关用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让是一项确定产品能否满足合同或用户所规定需求的测试，验收测试包括α和β测试。
α测试：由用户在开发者的场所进行，在一个受控的环境进行
β测试：由软件最终用户在用户场所进行，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行修改，并开始准备发布最终的软件。
4.测试的常见类型（按内容区分）
4.1 功能测试
功能测试也称为黑盒测试，是在已知产品功能的前提下，通过测试检每个功能是否能正常使用。功能测试不考虑程序的内部逻辑和结构，在程序接口进行测试，只检查程序功能是否按照需求规格说明书的规定正常使用，程序能否适当地接收数据而产生正确的输出信息，因此应该穷举输入数据，不但要考虑合法数据还要考虑不合法但可能的输入进行测试。
4.2 UI测试
界面测试，主要测试用户界面的功能模块布局是否合理、整体风格是否一致、各个控件的放置位置是否符合用户的使用习惯。
4.3 接口测试
当模块之间、子系统之间有接口交互时，需要根据接口文档进行测试。接口测试也可称为集成测试或灰盒测试，主要用于检测外部系统与系统之间以及内部各个子系统之间的交互性。测试的重点是检查数据的交换，传递和控制过程，以及系统间的相互逻辑依赖关系等。
4.4 性能测试
性能测试是通过性能测试工具模拟多种正常、峰值以及异常负载条件对系统的各项性能指标进行测试。性能测试的目的是确定一个系统的瓶颈，来获得系统能提供的最大服务级别，一个系统须达到的性能指标通常源于用户需求。性能测试内容主要包括三方面：应用在客户端、网络以及服务端的性能表现。常见的性能指标有：响应时间、吞吐量、事务成功率、服务器资源、CPU使用率、内存使用量、I/O吞吐量等。
性能测试类型有负载测试、强度测试、容量测试等。
负载测试：模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。
强度测试：也称为压力测试，是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。
容量测试：容量测试的目的是通过测试预先分析出软件系统某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试关注系统可处理同时在线的最大用户数 ，通常和数据库有关，容量关注的是大容量。
4.5 兼容性测试
Web兼容性测试范围主要从操作系统（不同Windows版本、CentOS版本）、浏览器（IE版本、Chrom版本）、分辨率三方面考虑。
4.6 安全测试
主要包含权限管理测试、认证测试、会话管理测试、服务器测试、数据注入测试等。
权限管理测试：验证页面是否进行权限判断、页面资源标志是否和用户信息匹配、用户登录后应以会话中的用户session的用户身份信息为准。
认证测试：避免账号和密码遭暴力破解。（系统存在验证码机制、不允许纯数字纯英文等简单密码、认证失败的错误提示不展示详细出错信息、系统有锁定策略、不存在绕过认证的漏洞、使用安全数据传输、强口令策略）
会话管理测试：会话管理用于保持用户的整个会话活动与计算机系统跟踪过程。（cookie中不会带有session ID信息、用户操作停止后设置会话保存时间、用户登录后每次请求服务器数据变更session ID、注销后删除用户信息）
服务器测试：服务器运行账号不应是特权账号或更高级别账号，如root、administrator；未使用端口应为关闭状态、不能通过任何方式获得服务器的详细版本信息
数据注入测试：当系统接受数据注入时，可能会造成数据泄露、数据被修改等严重影响、导致业务中断。
5.缺陷管理
5.1 缺陷提交规范
5.2 缺陷生命周期
5.3 缺陷等级划分
| 缺陷等级 | 定义 | 细则 |
| 高 | 对产品的功能、可靠性、兼容性、性能有严重影响的问题 |
|
| 中 | 对产品的功能、可靠性、兼容性、性能有一般影响的问题 |
|
| 低 | 对产品的功能、易用性有轻微影响的问题 |
|
| 建议 | 未必是缺陷 | 测试人员角度提出的建议 |
5.4 缺陷的状态
| 状态 | 描述 |
| New:（新的） | 当某个“bug”被第一次发现的时候，测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New |
| Assigned（已指派的） | 当一个bug被指认为New之后，将其反馈给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned |
| Open（打开的） | 一旦开发人员开始处理bug的时候，他就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug” |
| Fixed（已修复的） | 当开发人员进行处理（并认为已经解决）之后，他就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组 |
| Pending Reset（待在测试的） | 当bug被返还到测试组后，我们将bug的状态设置为Pending Reset” |
| Reset(再测试) | 测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset” |
| Closed（已关闭的） | 如果测试人员经过再次测试之后确认bug 已经被解决之后，就将bug的状态设置为“Closed” |
| Reopen（再次打开的） | 如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen |
| Pending Reject（拒绝中） | 如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态设置为“Pending Reject” |
| Rejected(被拒绝的) | 测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected |
| Postponed（延期） | 有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed“ |
5.5 用例执行结果
| 执行结果 | 说明 |
| P | 用例通过 |
| F | 用例不通过，提交缺陷 |
| NT | 要执行而没执行（时间约束、技术约束等） |
| Delay | 延期，不知何时会解决 |
| Defer | 延期，后续轮次会解决 |
| NP | 这个版本计划不执行 |
| NA | 不执行，产品或组件本身不涉及该项规范，不需要验证 |
| Block | 因缺陷阻塞 |
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！