2021年9月27日所学（个人笔记）

测试用例的方法

等价类

• 概念：把具有相同价值的一类放在一起，大大节省了测试的过程。——本质：找相同点分类
• 分类：有效等价类：代表对程序有效的、符合规范的输入

无效等价类：其他任何可能的输入（即不符合规范的输入值）

有效等价类和无效等价类都是使用等价类划分法设计用例时所必须的，因为被测程序若是正确的，就应该既能接受有

效的输入，也能接受无效输入的考验。

• 案例

邮箱登录

QQ号注册

边界值

• 概念：边界值法设计测试用例，是对输入或输出的边界值（有效等价类和无效等价类的界限）进行测试的一种黑盒测试方

法。

• 边界值法存在的意义：测试研究表明错误往往会发生在输入或输出范围的边界上，所以边界值法是对这些边界进行测试，是

对划分等价类法的一种补充。

• 上点：边界上的点（符合条件的边界点）

内点：边界内的点

离点：离边界最近的左右两点

（如下图）

• 案例

• 边界值分析法拓展

自动化测试报告流程

• 测试过程描述

测试目标

[本次测试需要达到的目标。即开发实现和业务需求的期望。内容包括：

1、项目背景：简要描述本项目立项的缘由，如修改生产中发现的某些问题或业务需要新建一套系统等；可从移交测试文

档中引用摘抄

2、本次测试的目标：明确本次测试要达到的目标，如验证功能符合需求，新增功能不影响现有功能，性能达到XXX目

标，需兼容XXX平台，系统等]

测试依据

测试范围

测试环境

测试实际进度

[记录测试实施各阶段的计划开始、计划结束、实际开始、实际结束时间、参与人以及相关进度说明。对于实际进度与计

划有偏差超过10% 的，需对进度偏差原因进行说明。]

• 执行结果

注：与第三方接口中的金额域，必须与第三方进行联调验证；如第三方无法支持联调测试，开发、测试人员必须通过查

看通讯报文的方式进行金额域正确性验证。

• 测试结果分析

测试需求覆盖分析

[罗列功能点/交易的规则点数及覆盖规则数，进行需求覆盖分析。]

测试用例执行分析

缺陷分布分析

[可通过表格、饼图等方式对有效缺陷（即不含否决缺陷）辅助分析]。

遗留缺陷

[测试结束后，对暂不修复或无法修复的缺陷说明原因、分析影响，提出应对解决措施。]

测试缺陷列表

[可将缺陷从QC中导出，嵌入此处。导出要素及顺序为：缺陷ID、摘要、描述、状态、严重程度、注释、发现人、提出

日期、关闭日期、缺陷类型。]

• 测试结论

测试有效性分析

[分析测试过程及测试结果的有效性。包括总结测试需求覆盖率、测试案例通过率，缺陷处理率，遗留缺陷处理率等指标

验证测试过程的有效性，描述测试手段、测试环境、测试数据等方面验证测试结果的有效性。另外，对于存在的风险还

应该做 分析，以说明是否影响本次测试结果的有效性]

[通常可以使用下面的语言进行有效性分析]

本次测试涉及  个功能点，  条规则；测试中，共设计  个测试案例，执行  个，没有发现缺陷/发现  个缺陷，其中，  个

已修复，  个否决，  个遗留。

设计的案例对测试需求覆盖率为100%，且所有案例均在环境稳定的情况下测试并得出明确测试结果。

测试结论

[对测试结果给出总体结论：对被测对象的质量进行综合评价；明确测试通过或测试不通过结论。]

  “”基于开发提交的测试版本，完成系统测试，被测功能达到预定需求，测试过程完整有效，

系统测试通过。

• 建议

[针对测试过程中出现的问题做风险分析，对下阶段工作，如业务测试、上线及上线后的开发、测试工作提出有建设性的建

议。如无建议，本章可以删除。]

• 附录

[根据情况补充其他参考信息，例如：缺陷严重程度说明、缺陷状态说明等，如果没有，本章节可以删除。]

用例测试报告流程

• 项目概述

项目背景

项目名称：亿达商贸有限公司POS系统 

用户：XXXXXXX

    《亿达商贸POS系统》可用于商品管理、商品类别、供应商的管理、客户管理、采购信息及销售信息、采购退货和销售退货、库存统

计、系统维护等应用模块。

测试版本：V1.0

测试目的

为了要找出错误，通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。保

证整个软件开发过程是高质量的，同时满足用户指定的需求（功能、性能、安全性、兼容性）。

对象框架

亿达商贸POS系统是B/S构架的软件，开发环境是linux，是基于Spring、MySQL的数据库平台上。

标准

本测试项目中采用了：国家软件测试GB/T2500-2010和GB/T16260的相关标准。

术语

软件测试：使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的

差别。

硬件环境：指测试必需的服务器，客户端，网络连接设备，以及打印机扫描仪等辅助硬件设备所构成的环境。

软件环境：指被测软件运行时的操作系统，数据库及其他应用软件构成的环境。软件环境又可分为主测试环境和辅助测试环境。

验收测试：是软件产品交付用户正式使用前的最后一道工序。它是以用户为主的测试，软件开发和质量保证人员也应参加。

参考文档

《POS_需求_20190621_v4.1.doc》

受众、读者

受众、读者：主要针对项目经理，管理人员、测试工程师人员。

• 测试说明

测试对象范围

测试环境

1.硬件设备

2.辅助工具

测试管理工具：禅道

     版本控制工具：SVN

测试资源

测试策略

1.功能测试

功能测试是从用户的观点出发，主要以亿达商贸POS系统软件需求说明书和操作使用手册为依据，对程序功能和程序接口进行的测试。

2.业务测试

业务测试关注的要点是业务流程，及数据流从软件中的一个模块流到另一个模块的过程中的正确性。

3.功能测试检查项

表单测试：必填项，提示信息，边界值，数据类型，字符长度，特殊字符

链接测试：风格，链接正确，导航文字描述，图片链接

图形测试：图片大小，位置，相关说明，字体，大小，颜色，背景等

表格：样式

内容测试：信息归类是否正确，显示位置，检索功能

浏览器测试：功能，风格显示等

任务分配

文档管理

用例管理

缺陷管理

• 风险控制

系统风险

影响计划的潜在因素

应急措施

测试的局限性

• 质量评估标准

测试模块通过标准

测试项的通过标准目前定义为：当此项的功能能够正确地完成，并且它的操作没有引起其他功能项或整个系统的错误，则认为此项测试

通过。

验收测试通过标准

验收测试的通过标准目前定义为：对于每一类测试，当没有发现致命性错误和严重性错误，一般性错误数量小于测试用例总数的5%，则

认为系统通过本次测试，但要以测试结果评审会的评审结果为最后标准。

• 关键里程碑
• 附录及其他

联系方式

会议记录模板

测试用例模板

工作日志模板

缺陷报告模板

功能测试流程

• 需求分析与评审
• 测试计划与测试方案
• 测试用例设计
• 测试用例评审
• 执行用例
• 缺陷跟踪及报告产出

测试计划

1.软件测试计划简介

• 测试计划概念

定义：制定测试目的、范围、方法、时间进度及软件测试重点的过程。

• 编写人员和使用人员

测试计划一般由测试组长或者项目经理来负责撰写。测试人员按照计划里的内容来安排和调整自己的测试工作。

写：测试组长和项目经理

用：测试人员

你：也有可能...

2.软件测试计划内容

• 项目概述

背景

目的

对象

术语

• 测试说明

测试对象范围

测试环境

测试资源

测试策略

任务分配

文档管理

• 风险控制

系统风险

影响计划的潜在因素

应急措施

测试局限性

• 测试质量评估标准

模块测试通过标准

验收测试通过标准

• 任务里程碑记录
• 附录以及其他

测试用例

1. 什么是测试用例：

为某个业务目标，而编制的一组由测试输入、执行条件以及预期结果组成的案例。

1. 为什么要使用测试用例

• 在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。
• 测试用例的使用令软件测试的实施重点突出、目的明确。
• 在软件版本更新后只需修正少部分的测试用例便可开展测试工作，降低工作强度、缩短项目周
• 检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计思路。

1. 测试用例的内容（重点重点重点，面试会问）*********

主要内容

• 用例编号（如何命名）
• 所属模块
• 用例标题（验证谁在什么情况下，去做什么，最后结果是什么）
• 优先级
• 前置条件
• 操作步骤
• 测试数据
• 预期结果
• 实际结果

辅助内容

• 通过否
• bugID
• 编写人员
• 编写时间
• 测试人员
• 测试时间
• 备注

缺陷

1.什么是缺陷

软件缺陷就是通常说的Bug，它是指在软件中（包括文档和程序）存在的影响软件正常运行的问题。

2.缺陷产生的原因

• 需求不明确和变更（沟通不充分产生）
• 软件结构复杂（架构不合理，认知不到位）
• 编码问题（程序员都是培训的，太菜了）
• 项目期限短（时间问题，越快越忙越出错）
• 使用新技术（不是最新的才是最好的，大脚都知道老人活好）

3.缺陷分类

• 测试种类分类

界面类

功能类

性能类

安全类

兼容类

• 缺陷的严重程度

严重

一般

次要

轻微

• 缺陷的优先等级

立刻解决

高级优先

正常排队

低优先级

• 缺陷发生阶段分类

需求阶段缺陷

架构阶段缺陷

设计阶段缺陷

编码阶段缺陷

测试阶段缺陷

缺陷报告

1.什么是缺陷报告

描述软件缺陷现象和重现步骤的合集

2.缺陷报告的核心要素

• 缺陷编号
• 缺陷状态
• 缺陷标题
• 重现步骤（复现步骤）
• 严重程度
• 优先级
• 缺陷类型
• 测试环境

3.缺陷报告模板

缺陷管理

1.提交缺陷的注意事项

• 可复现：缺陷可以复现
• 唯一性：一条缺陷只报告一个问题
• 规范性：缺陷报告编写要规范，符合公司或者项目要求

准确：描述的信息正确的

具体：有细节且是真实特定的，避免使用模糊不清的词语，如功能中断，功能不正确，功能不起作用等等。

简洁易懂：描述简单容易理解，不要产生歧义。

2.缺陷的跟踪流程