标签：需求 测试计划 应用 --- 测试用例 测试 重点 软件测试

第一章
1.软件测试管理目标
明确为什么不能测试所有可能性:
1) 可能进行测试的数目是无限的
2) 真正能执行的测试只是代表性的案例
3) 很难确定理想的可能测试的数目
4) 用较少的测试资源获取更多的信息
2.软件测试管理的目标应考虑以下几个方面：
1) 可用测试资源
2）使用适当的测试技术和方法
3）明确具体软件测试任务
3.软件测试任务图
集成测试 单元测试 测试准备 内部验收 系统测试
集成测试1. 1.制定测试策略 1.单元测试计划
内部验收准备 1.系统测试计划 1.计划明确测试 2. 明确测试用例 2.编写测试用例 2. 2.执行内部验收 明确测试用例 用例 2.
执行集成 3.建立测试环境 3.3. 执行单元测试
3.问题处理 3. 测试 执行系统测试缺陷分 4. 缺陷分析 4. 缺陷分析4. 析 交付与确认4. 交付成果：

单元测试计划 集成测试计划 系统测试计划 内部验收报告
单元测试用例 集成测试用例 系统测试用例
单元测试bug记录表 集成测试bug记录表 系统测试bug记录表
单元测试报告 集成测试报告 系统测试报告
4.软件测试管理定义：
就是对每一种具体测试任务、流程、体系、结果、工具等进行具体监督和管理
5.常见的实践是可以把软件测试管理分为8类：
1）软件测试需求管理
2）软件测试质量管理
3）软件测试团队管理
4）软件测试文档管理
5）软件测试缺陷管理
6）软件测试环境管理
7）软件测试流程管理
8）软件测试执行管理
6.单元测试的考虑：
1）模块接口
2）算法和逻辑


3）数据结构（全局和局部）
4）边界条件
5）独立的路径
6）错误处理
7.1）敏捷开发迭代流程图：
==（输入）需求---设计---开发---测试（需求—计划---设计---执行--）---发布（输出）===
2）敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计进行评审，更重要的是能够及时、持续地对软件产品质量进行反馈。简单地说，敏捷测试管理要特别注意的就是持续地对软件质量问题进行及时反馈。
8.敏捷测试过程管理工具有HP Agile Manager 和微软的
Visual Studio 2012,包括TFS 2012、Scrum 模板、Test
Manager 2012、Coded UI Test等
9.软件测试管理体系的主要目的是确保软件测试在软件质量保证中发挥应有的关键作用。特别体现在以下5个方面：
1）对软件产品的评估和测量
2）对软件产品的缺陷识别和控制
3）产品设计和开发的验证
4）软件过程的监视和测量
5）有流程和规范指导
10.ISO 9000质量管理体系的8大原则


原则1:：以用户为关注焦点
原则2：领导作用
原则3：全员参与
原则4：过程方法
原则5：管理的系统方法
原则6：持续改进
原则7：基于事实的决策方法
原则8：互利的供方关系
11.TMM 软件测试能力成熟度5级
TL1 初始级
TL2 阶段定义级
TL3 集成级
TL4 管理和测试级
TL5 优化级
12.测试管理体系的架构：
制定测试需求 设计测试用例 生成测试执行用例 执行单元测试 执行集成测试 执行系统测试 分析测试结果
制定测试策略 定义测试过程 建立测试脚本 建立测试结果 记录测试结果 记录测试结果 提出变更请求
明确资源进度 定义测试环境 回归测试 回归测试 回归测试 分析测试情况
评审测试计划
生成测试报告

制定测试计划----测试计划---------测试执行------------单元测试---------集成测试-------系统测试--------评估测试
13.软件测试的5个要素/测试管理的5要素：
质量、人员、技术、资源、流程
14.测试管理金字塔和关系实例图：
一个中心---1人（以人为本）---2个目标（关注点：测试覆盖率、测试效率）---3个支撑（人员、流程、技术）---5要素或5个工作面---8关系----13原则----21关键域---34个方法
5个工作面：
1）质量---人员---技术
2）质量---人员---资源
3）质量---技术---流程
4）质量---流程---资源
5）人员---技术---流程---资源
15.为什么要进行软件测试管理？
（1）软件测试的工作量要占整个软件开发工作量的40％以上，对于高可靠、高安全的软件来说，这一比例可能会达到60％～70％。因此，软件测试是软件开发过程中的一项重要工作，必须对其进行科学有效的管理。
（2）一项软件测试工作涉及到技术、计划、质量、工具、人员等各个方面，是一项复杂的工作，因此需要对其进行管理。
（3）任何软件测试工作都是在一定的约束条件下进行的，要做到完全彻底的测试是不可能的。
（4）只有系统化、规范化的软件测试才能有效地发现软件缺陷，才能对发现的软件缺陷实施有效的追踪和管理，才能在软件缺陷修改后进行有效的回归测试。
第二章
1.软件需求的定义 ：
1）（正在构建的）系统必须符合的条件或具备的功能
2）一种获取，组织并记录系统需求的系统优化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程
2.测试需求和测试设计的区别：
1）测试需求并不等同于简单的测试范围，也不是测试计划。因此也有专家定义测试需求不是对测试提出的要求的总和，而是根据程序文件和质量目标对软件测试活动所提的要求。
2）测试需求不同于测试设计。按照IEEE标准，测试设计的目的是：细化测试计划中描述的测试途径，确定要包含的特性和测试，确定完成测试所用到的测试用例和测试规程，最后给出测试失效和通过的标准。
3.软件测试需求分析的目的
就是对软件测定要解决的问题进行详细分析
4.测试需求分析主要有两个任务：


1）通过对测试活动需要解决问题及环境的理解、分析和综合，建立分析模型；
2）在完全弄清所有测试活动干系人对测试的确切要求的基础上，用“软件测试需求规格说明书”把测试需求以正式书面形式确定下来
（软件测试需求分析环节：建立软件测试需求模型----编写测试需求说明书）
5.软件测试需求分析的最通用的方法：
通过软件需求推导软件测试需求
6.软件测试需求分析步骤：
1）根据软件开发需求说明书逐条列出软件开发需求，并判断其可测试性，如果不具备可测试性，则需要提交申请对软件开发需求说明书进行变更，任何软件开发需求都应具备可测试性。通常来说，对软件开发需求说明书的可测试性检查应该在软件开发需求说明书的评审过程中提出并解决。
2）对步骤1）中列出的每一条开发需求，形成可测试性的描述。针对这条开发需求需要进行测试范围的界定。开发需求和需要进行测试的范围不是1:1的关系，可能是1：n或n：1，必要情况下，需要对开发需求进行分解和合并。
3）对步骤2）中形成的每一条测试范围，根据质量标准，逐条制定质量需求，即测试通过标准，用以判断测试成功和失败。


4）对步骤3）确定的质量需求，分析测试执行时需要实施的测试类型，至此形成专业的测试需求。
5）建立测试需求跟踪矩阵，输入测试需求管理系统，对测试需求实施严格有效的管理。
7.软件测试需求分析过程中还有许多其他重要的环节：
软件测试需求分析干系人分析、测试需求的收集与分析/整理、测试需求的优先级排序和评审测试需求
8.评审的内容包括完整性检查和准确性检查
评审的形式，有以下常用几种：
1）相互评审、交叉评审
2）轮查
3）走查
4）小组评审
9.软件测试需求管理的内容：
1）定义测试需求
2）确认测试需求
3）建立测试需求状态
4）测试需求评审
5）测试需求责任制
6）测试需求跟踪
10.为什么变更？变更的原因;
1) 客户的需求
2）市场的需求


3）技术或非技术的其他原因
11.软件测试需求变更的主要任务：
1)提出变更
2)分析变更的必要性和合理性，确定是否实施变更
3)记录变更信息，填写变更控制单，提交变更申请
4)做出更改，并交上级审查
5)修改相应的软件测试工作，如更新测试用例等，确定新的版本
6)评审后，正式发布新版本的软件测试需求说明书
12.测试需求状态转换：
1）Open
2）Analyzed
3）Reviewed
4）Resolved
5）Passed
6）Unresolved
7）Closed
8) Cancle
9）Failed
(Unresolved缺陷多种原因：
1）测试问题
2）需求分析问题)
13.软件测试需求跟踪是指跟踪软件测试需求使用期限的全

过程。需求跟踪包含的正向跟踪和逆向跟踪合称为双向跟 踪。---------------- ----------------软件开发需求 到测试需求 从测试需求回溯
---------------软件测试需求------------------
到测试用例 从测试用例回溯
-----------------测试用例-----------------------
（正向跟踪） （逆向跟踪）
14.惠普应用生命周期管理流程
----------------------------报告和分析------------------------------
指定版本---指定需求----计划测试---执行测试---追踪缺陷

第三章
1.测试团队角色：
1）测试经理：他们负责测试计划和测试统筹安排，具备软件测试、质量管理、项目管理和人员管理等领域的知识和经验，能指导和管理其他测试人员的工作
2）测试设计人员：他们需要掌握测试方法、流程和测试规格说明等，具备测试设计、测试分析以及软件工程等领域的知识和经验
3）测试自动化人员：测试自动化人员不但具备测试的基础知识，还有编程经验以及丰富的测试工具和脚本语言知识。
4）测试环境管理员：负责测试环境的技术人员。一般是安装和操作测试环境方面的专家，具备系统管理员知识。建立、维护和支持测试环境，需要经常与系统管理员和网络管理员进行协调。他们也帮助一般测试工程师和开发工程师搭建测试环境。
5）测试执行人员：他们执行测试并编写缺陷报告，具备IT基础知识、测试基础知识，能应用测试工具，熟悉被测试对象。
2.测试团队与开发团队的比例（测试比例不是唯一确定的）
1）质量风险
2）测试意识
3）发布流程
4）测试效率
5）合理估计项目的开发测试比例的方法
（1.看项目的性质，遇到问题影响范围是100%的核心任务，投入开发与测试比例至少为1:1
2.遇到缺陷影响范围可控或有替代方式的业务，上线步骤是递进的，开发和测试之比2:1或更高
3.有些项目对质量要求不是很高的，只需做简单验证性测试即可发布，只需设立一到两名测试人员即可）
6）手工测试工程师和自动化测试工程师的比例
第四章
1.测\试过程实施所必备的核心测试文档包括：
测试计划、测试规范、测试用例和软件测试报告
2.测试文档的必要性;


1)提高项目测试过程的透明度
2)文档化能规范测试，能提高测试效率
3)便于团队成员之间的交流与合作
4)测试文档的重要性还表现在对于项目“传承”的重要性
5)测试文档是测试人员经验提升的最佳途径
6)有利于项目测试的监控作用
3.项目测试文档是用来记录、描述、展示测试过程中一系列测试信息的处理过程，通过书面或图示的形式对项目测试活动过程或结果进行描述、定义及报告
4.测试计划：
描述测试活动的范围、方法、资源和进度。它规定被测试的项、被测试的特征、应完成的测试任务、负责每项工作的人员以及与本计划有关的风险等。
5.测试说明包括三类文档：
1）测试设计说明
2）测试用例说明
3）测试规程说明
6.测试报告包括4类文档：
1）测试项传递报告
2) 测试日志
3) 测试事件报告
4) 测试总结报告
7.国际IEEE 829标准：
1）测试计划
2）测试设计规格
3）测试用例规格
4) 测试过程规格
5) 测试记录
6) 测试附加报告
7) 测试摘要报告
8.测试策略和测试计划的区别：
测试策略定义：在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。通俗地讲，测试策略描述了要进行哪些种类的测试和如何测试的问题。
测试计划：5W1H what where when who why how
9.简述制定软件测试策略的过程
1）首先要明确制定软件测试策略的输入
2）其次要明确软件测试策略的输出
（1.确定测试的需求2.评估风险并确定测试优先级3.确定测试策略）
10.测试计划定义;
一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排以及任何偶发事件的风险。软件测试计划是指导测试过程的纲领性文件，是测试文档中的重中之重。它包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。
11.测试用例基本要素：
1）编号
2) 标题
3) 重要级
4) 测试输入
5) 操作步骤
6) 预期结果
12.编写缺陷报告的5c准则;
1）Correct(准确)
2）Clear（清晰）
3）Concise（简洁）
4）Complete（完整）
5）Consistent（一致）
缺陷报告生命周期
提交缺陷报告-分配缺陷报告-处理缺陷报告-反测报告--（反测通过—关闭缺陷报告）（反测未通过处理缺陷报告）
13.对测试计划的可行性、全面性以及正确性等进行评审
14.评审的内容：
1）用例设计的结构安排是否清晰、合理，是否利于高效地对需求进行覆盖
2）优先级安排是否合理
3）是否覆盖测试需求的所有功能点
4）用例是否具有很好可执行性
5）是否删除冗余的用例
6）是否包含充分的的负面测试用例
7）是否从用户层面来设计用户使用场景和使用流程的测试用例
8）是否简洁，是否便于重复使用
15.使用ALM进行测试管理包括4个步骤：
1）明确条件
2）测试计划
3）执行测试
4）跟踪缺陷
16.最佳测试用例的设计原则：
1）依据原则
2）全覆盖原则
3）规范原则
4）全面原则
17.最佳测试用例的特点：
1）完整性
2）准确性
3）简洁性
4）清晰性
5）可维护性
6）适当性
7）可复用性
8）其他


18.测试用例的粒度：
是指一个测试用例覆盖软件功能点的范围，覆盖面广被称为力度粗大，覆盖面窄被称为力度细小
19.设计测试用例时应考虑以下因素：
1）项目的进度
2）软件工程师的情况
3）客户需求
4）项目是否具有延续性
20.测试用例生命周期：
确定测试需求---测试用例设计---测试用例执行---测试用例管理
21. 测试用例管理：
包括测试用例组织、测试用例跟踪和测试用例维护
22.几大测试文档有哪些？具体内容是什么？
测试需求文档：
测试执行计划：
测试计划：一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排以及任何偶发事件的风险。软件测试计划是指导测试过程的纲领性文件，是测试文档中的重中之重。它包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容，包含了测试的背景、人员和内容、以及计划要做的测

试。
测试用例：是对于计划中要做的测试内容、测试项生成的用例。
测试结果报告:：包含了用例测试的结果和总结，以便将来维护时使用
测试规范：为了一个特定的测试目的，对被测软件产品或功能进行测试所需的有关文件。
软件测试报告：
测试策略：在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。通俗地讲，测试策略描述了要进行哪些种类的测试和如何测试的问题。
缺陷报告：为便于管理测试发现的软件错误，通常要采用软件缺陷数据库，将发现的每一个错误输入到缺陷报告中，软件缺陷数据库的每一条记录称为一个软件问题报告
第五章
1.缺陷状态
New Open Fixed Reopen Closed Rejected Pending Distract
Cancelled
2.缺陷之间的状态转换关系
3.缺陷报告
一个好的缺陷报告应该包含哪些信息？
唯一的缺陷ID，精确描述但简短的标题、缺陷类型、严重级别、优先级别、报告人、详细准确的重现步骤（包含位置、操作、现象等三要素），UI截图、所属模块、负责人、

预期结果、实际结果，重现环境、前置条件等等信息（其 余可以补充）。XXX
ID：事件/缺陷 缺陷标题：手机号不合法也能注册成功XXX
报告者：2014/10/20 报告的日期： New 状态：) 一般严重度：3() 一般优先级：3(WIN7,IE8
测试平台：，注册成功。 在账户注册功能页面上，输入手机号后提交 详细描述：XXX
：关联的测试用例号ID45678911033 测试数据：手机号： 打开网站首页问题重现步骤：1. 2.点击免费注册 3.填写手机号 4.提交注册信息 实际结果：提示注册成功期望结果：注册失败，提示手机号不合法。
4.严重级与优先级优先级是从项目管理和时间管理的观点来厘定高低的，而 严重性是从质量管理的观点来思考的。Cosmetic Minor 4级：级：Critical 2级：Major 3级：严重级：1Should Fix 级：应修正级：必须修正优先级：1Must Fix 2Fix if Time 3级：有时间就修正 第六章 定义的软件测试流程1.ISTQB评—测试分析和设计测试实现与执行—测试计划和控制— 估出口准则和报告—测试活动结束 2.敏捷测试流程图： 发开 发开 析分求需单简 开发

========= ---------------------- -------------------
==============
分解 测试 功能
测试 --------------------- =========
完成 完成
发现问题===== 开发修复
第七章 （决定怎样执行测试和测试什么）软件测试执行的内容：
1. 主要包括项任务：4执行测试计划预定的测试，包括执行所有以设计的测 ）1 试用例 ）2 记录原始测试数据 3）记录缺陷 ）4 对所发现的缺陷进行跟踪，管理和监控: 2．影响测试执行的因素 环境和工具在实际的软件测试过程中，测试资源、测试质量、测试时 间之间是相互制约的 PDCA3.戴明环（循环） 四个阶段和个步骤应该作为测试执行管理的指导思想8（检Do（计划）PlanPDCA四个阶段：是（执行）Check Action查）（处理）

8个阶段：找问题、找原因、找主要原因、制定计划措施、实施计划、检查、总结经验、提出新问题
4. 测试的四个度量指标
测试覆盖率、测试通过率、测试执行率、缺陷解决率

标签：需求,测试计划,应用,---,测试用例,测试,重点,软件测试
来源： https://www.cnblogs.com/R-bear/p/15758908.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。