软件测试管理知识总结
1 软件测试管理概述
1.1软件测试管理基础
1，软件测试管理目标：软件测试管理的目标是通过系统的、高效的、适用的技术、方法和体系来监督、促进和达到这个软件测试的目标。
• 可用测试资源
• 使用适当的测试技术和方法
• 明确具体软件测试任务
决定软件测试管理时应考虑：
2，软件测试管理定义：对每项具体软件测试活动以及总体软件测试全局的监督、评估、决策和管理的过程。软件测试的管理就是对每一种具体测试任务、流程、体系、结果、工具等进行具体监督和管理。
分类：比较常见把软件测试管理分为8类:
1.软件测试需求管理
2.软件测试质量管理
3.软件测试团队管理
4.软件测试文档管理
5.软件测试缺陷管理
6.软件测试环境管理
7.软件测试流程管理
8.软件测试执行管理
9.其它（计划、用例、报告、成本、风险）
3，软件测试管理范围与来源：
系统测试需要管理的内容：
需求分析阶段：测试需求。
测试计划{测试范围，时间进度，人员团队，环境（本地环境，测试环境，验收环境，
生产环境，镜像环境）的服务器，网络等。风险，质量
4，软件测试管理特色：
1）敏捷开发的流程：
2） 质量问题持续反馈：敏捷测试管理=质量问题持续反馈
3）自动化测试策略：新功能测试用手工测试旧模块可以使用自动化测试
4） 敏捷测试管理工具：HP Agile Manager、微软的Visual Studio 2012，包括TFS 2012、
Scrum模板（MS VS Scrum 1.0）、Test Manager 2012、Coded UI Test等。
1.2软件测试管理体系
1，建立软件测试管理体系的主要目的
1.对软件产品的评估和测量
2.对软件产品的缺陷识别和控制
3.产品设计和开发的验证
4.软件过程的监视和测量
5.有流程和规范指导
2，ISO 9001与软件测试
1)ISO9000基础：ISO是国际标准化企业的缩写。9000是标准的代号，ISO将9000下的编号分配给与质量管理和质量保证的有关标准。
2)ISO 9000质量管理体系的八大原则：
原则一：以用户为关注焦点
原则二：领导作用
原则三：全员参与
原则四：过程方法
原则五：管理的系统方法
原则六：持续改进
原则七：基于事实的决策方法
原则八：互利的供方关系
3)ISO9001对软件测试管理的指导作用
3，软件测试成熟度模型TMM
TMM是当前影响力最大的软件测试过程模型
它的优点如下：
a)等级水平结构、关键活动和角色的定义最为精细；
b)测试相关因素覆盖最全面；
c)支持测试过程成熟度增长；
d)有定义良好的评估模型的支持；
e)实施TMM能改进测试过程，并有助于提高软件质量、软件工程生产力和缩短研发周期，减少投入。
4，如何建立测试管理体系
某企业用于测试管理的结构图：
测试活动实例图：
1.3软件测试管理要素
1，测试管理五要素：质量；人员；流程；资源；技术
2，软件测试管理体系本身是软件的应用，就是一种技术，一是工具。软件测试管理体系涉及功能测试、性能测试、安全性测试等多种软件测试类型，包含了软件测试流程中各阶段的流程规范、测试理论、测试工具等各方面内容。
3，相互关系：试管理的5个工作面基于软件测试金字塔的构成
相互关系如下：
1.4 软件测试管理策略
2 软件测试需求管理
2.1软件测试需求概念
1，软件测试需求：以一个项目的观点看待软件测试工作，这个项目的范围就是软件测试需求，它定义了软件测试工作的范围，是进行其他测试活动的基础。
软件测试需求的内容： –功能测试需求
–性能测试需求
–可靠性测试需求
–国际化与本地化测试需求
–安全性测试需求
2，软件需求管理
1)软件需求的概念：
软件测试需求管理是要通过人为的和技术的手段、方法和流程，以保证和监督测试团队明确测试软件产品的目标。
定义1：软件需求就是一个为软件系统的需求进行启发、组织、建档的系统方法，一个建立和维护客户和项目团队之间关于变更系统需求所达成的一致性的过程。
定义2：一种获取，组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一的过程。
2)软件需求管理要求:
a)软件需求规格说明已文档化，并经评审后存档。
b)文档化的软件需求规格说明受管理和控制。
c)供软件工程和管理使用的分配基线已建立，使软件产品满足分配需求的接收标准；分配需求是制定软件开发计划的根据，是整个软件生命周期中估算、计划、执行和跟踪软件项目活动的基础。
d)软件开发计划、软件工作产品和软件过程活动与软件需求保持一致。
业界常见的测试过程中存在的问题 ：
软件测试本身的需求文档不全，有些需求待定；
产品质量维度事先没有全面明确，要包括的测试类型不全；
测试计划和编写测试案例没有规范；
没有系统的测试需求分析方法、流程或指导；
测试中经常会出现需求和缺陷遗漏、测试设计遗漏的问题。
3)软件测试需求管理意义
（1）失败经验教训说明必须要有软件测试需求管理
（2）业界专家建议必须实施软件测试需求管理
（3）缺乏成熟的理论和统一标准而需要需求管理
2.2软件测试需求分析
1，分析的目标和任务：
1）软件测试需求分析的目标：软件需求分析的目的就是要对软件测试要解决的问题进行详细的分析，弄清楚参与软件测试活动的干系人对软件测试活动和交付物要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。
2）测试需求分析主要有两个任务：
（1）通过对测试活动需要解决问题及其环境的理解、分析和综合，建立分析模型。
（2）在完全弄清所有测试活动干系人对测试的确切要求的基础上，用 “软件测试需求规格说明书”把测试需求以正式书面形式确定下来。
（Software Test Requirement Specification，SRS，简称测试需求书）
2，分析的方法
1）软件测试需求分析的意义：
如果把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试用例相当于软件的详细设计，测试用例的开发过程相当于软件的编码过程。但是软件测试不是简单把“软件”两个字全部替换成了“测试”这样简单，就测试需求分析的方法而言，即可以参考软件需求分析方法，又有其独特性。
2）软件测试需求分析的方法:
（1）通过软件的需求推导软件测试需求（最通用的方法）
3，分析的过程
1）软件测试需求分析的过程
（1）软件测试需求分析干系人分析
（2）需求收集和整理
（3）测试需求的优先级排序
（4）评审测试需求
4，分析结果和评审
评审内容: 评审的内容包括完整性检查和准确性检查。
评审的方法: 相互评审、交叉评审；轮查；走查；小组评审；评审人员
正式评审小组中，一般存在多种角色，包括协调人、作者、评审员等。
评审员需要精心挑选，保证不同类型的人员都要参与进行来，通常包括开发经理、项目经理、测试经理、系统分析人员、相关开发人员和测试人员等。
2.3 软件测试需求管理内容
1，变更管理
从关注几个方面的问题来分析软件测试需求管理的内容：
（1）定义测试需求
（2）测试需求确认
（3）建立测试需求状态
（4）测试需求评审
（5）测试需求责任制
（6）测试需求跟踪
1）软件测试需求的变更的原因：
a)客户的需求变更
b)市场需求变更
c)技术或非技术的其他原因
2）软件测试需求变更管理:
a)测试需求变更管理的必要性
b)测试需求变更管理的意义
c)软件测试需求变更的主要任务:
分析变更的必要性和合理性，确定是否实施变更；记录变更信息，提交变更申请；做出更改；修改相应的软件测试工作，如更新测试用例等；评审后，正式发布新版本的软件测试需求说明书。
d)建立测试需求管理模型
2，状态管理
在测试工作进展的过程中，可能存在若干种状态：
（1）只知道大致需求，具体细节还有待细化；
（2）已经初步确定，等待评审；
（3）已经确定的，并经过团队评审，在可预期未来不会发生变更；
（4）已经评审完毕正在进行设计、实现测试用例的测试需求；
（5）完成设计、实现测试用例的测试需求。
1)软件测试需求的状态
Open：对于原始需求或接收到的正式需求，但未正式进行需求分析之前的需求状态统一定义为：“Open”状态
Analyzed：对需求状态为“Open”的需求，若已完成需求分析过程，但还未正式通过需求评审前，其状态统一定义为“Analyzed”状态
Reviewed：对需求状态为“Analyzed”的需求，若已正式通过需求评审，但还未完成测试，或测试结果为不合格之前，其状态统一定义为“Reviewed”状态
Resolved：对需求状态为“Analyzed”或“Reviewed”的需求，若已完成需求设计和编码，且已通过单元测试，其状态统一定义为“Resolved”状态
Passed：对需求状态为“Resolved”的需求，如果已通过正式测试，其状态统一定义为“Passed”状态
Unresolved：对需求状态为“Resolved”的需求，如果未通过正式测试，其状态统一定义为“Unresolved”状态。
Closed：对需求状态为“Resolved”的需求，若需求已正式上线商用，且得到客户和项目团队的共同认可后，其状态统一定义为“Closed”状态。
Cancel：当原定义的某些需求被取消时（包括上线前取消和上线后取消），其需求状态统一定义为 “Cancel”状态。
Failed：对需求状态为“Closed”的需求，若需求在上线商用后发现问题或存在缺陷，需要对其进行修正时，其需求状态统一定义为“Failed”状态
测试需求状态转换
3，文档版本管理
定义：软件测试需求文档的版本管理是软件测试需求管理的基础，籍此可以使得同一软件测试需求文档可以被测试团队中不同的人员编辑，并且记录下每次编辑的增量，必要的情况下还可以回滚到某个版本。
HP Application Lifecycle Management文档版本管理的功能：
• 权限管理
• 每次文档升级后的版本管理和恢复
• 团队协作时同时操作
• 文档版本比较
4，跟踪管理: 指跟踪一个软件测试需求使用期限的全过程。
1)软件测试需求跟踪有两种方式，正向跟踪与逆向跟踪:
正向跟踪：以软件测试需求为切入点，检查软件测试需求说明书中的每个需求是否都能在测试用例设计和实现中有相应的测试用例对应。
逆向跟踪：测试用例设计和实现等测试交付物是否都能在软件测试需求说明书中找到测试需求与之对应。
2)软件测试需求跟踪的作用
• 为测试团队提供了软件测试需求跟踪能力。
• 通过跟踪软件测试需求的后续测试用例信息可以帮助确保所有软件测试需求被实现，没有遗漏。
• 在对软件测试需求进行增、删、改等变更时可以确保与之对应的测试用例也进行必要的更新，而不被不忽略。
• 及时可靠的对软件测试需求进行跟踪，使得维护时能正确、完整地实施变更，从而提高生产效率
2.4 惠普测试需求管理解决方案
用于现代应用测试的软件解决方案有惠普应用生命周期管理 (ALM) 是一款应用测试软件，可为您提供统一的存储库、一致的用户体验,可定制的仪表板，支持从单一存储库管理整个应用生命周期，包括从需求开始到准备交付为止的整个过程。
惠普应用程序生命周期管理流程图:
（1）指定版本
（2）指定需求
（3）计划测试
（4）执行测试
（5）追踪缺陷
惠普应用程序生命周期管理系统模块有11个模块，如图左侧边栏所示。
集成了产品功能管理、进度管理、测试计划、测试用例、测试结果、缺陷和测试报告等模块。
b)从记录产品的功能开始到根据功能点设计测试用例、执行测试用例记录缺陷生成测试报告，所有流程都在专业项目管理系统中完成。
c)测试工程师、开发工程师和项目经理通过系统进行有效沟通。
3, 软件测试团队管理最佳实践
最佳实践的十个建议:
a)明确测试人员的职责
b)培养人才阶梯
c)形成学习和培训机制
d)公平和透明的绩效考核标准
e)设立“back up”体系
f)确保测试人员有职业发展渠道
g)经常和员工交流
h)奖惩分明
i)打造共赢的团队文化
j)领导以身作则
3.2 测试团队的组织管理
1，常见测试团队的组织结构：
2，软件测试组织的专业分工
测试团队常见的角色分工
3，测试团队与开发团队的比例
影响测试团队与开发团队的比例的因素：
质量风险
测试意识
发布流程
测试效率
合理估计项目的开发测试比的方法
手工测试工程师和自动化测试工程师的比例
3.3 测试团队的员工管理
1，测试工程师的职责：测试工程师的职责要从不同维度划分
2，测试人员的综合技能要求
1.问题的分析和解决能力
2.面向客户的创新
3.精湛的技术
4.项目管理
5.对质量的执着追求
6.战略远见
7.自信
8.冲击力和影响力
9.跨界合作
10.人际关系意识
11.思维和心理素质
12.相关业务知识
13.软件测试专业技能
14.计算机体系结构
15.编程技能
3，测试人员的职业发展
职业规划的几个基本点: 测试技术轨道；测试管理轨道
建议职业规划的基本原则：择己所爱、择己所长、择世所需、择已所利
4 软件测试文档管理
4.1 测试文档的必要性和重要性
1，测试文档的必要性：编制测试文档的必要性体现在以下几方面：
a)提高项目测试过程的透明度
b)文档化能规范测试，提高测试效率
c)便于团队成员之间的交流与合作
d)对于项目“传承”的重要性
e)是测试人员经验提升的最好途径
f)有利于项目测试的监控作用
2， 测试文档的重要性：
测试文档是用来记录、描述、展示测试过程中一系列测试信息的处理过程，通过书面或图示的形式对项目测试活动过程或结果进行描述、定义及报告。
4.2 测试文档规范
1，国家标准《计算机软件文件编制规范 》
GBT9386-2008中规定的测试文档的格式和内容：
测试计划：描述测试活动范围、方法、资源和进度。它规定被测试的项、被测试的特征、应完成的测试任务、负责每项工作的人员以及与本计划有关的风险等。
测试说明：包括三类文档：
测试设计说明
测试用例说明
测试规程说明
测试报告 ：包括四类文档：
测试项传递报告
测试日志
测试事件报告
测试总结报告
2，国际IEEE 829标准：IEEE 829-1998也被称做829软件测试文档标准。作为一个IEEE的标准定义了一套文档用于8个已定义的软件测试阶段，每个阶段可能产生它自己单独的
文件类型。
测试计划
测试设计规格
测试用例规格
测试过程规格
测试记录
测试附加报告
测试摘要报告
4.3 常用测试文档
1，测试策略：在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束
而规定的软件测试的原则、方式、方法的集合。
制定软件测试策略的过程：
1.明确制定软件测试策略的输入
2.明确软件测试策略的输出
3.制定具体的软件测试策略：
（1）确定测试的需求
（2）评估风险并确定测试优先级
（3）确定测试策略
2，测试计划：一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。
编写测试计划的步骤：
1.确定测试计划的目标
2.确定测试计划的内容：测试对象；测试内容；术语定义；团队之间的责任分配；确定测试范围；测试阶段；测试策略；资源要求；测试人员要求；测试进度；测试用例；缺陷报告；风险和问题
3， 5W1H法制定测试计划：What, Where, When, Who, Why, How
3，测试规范：为了一个特定的测试目的(例如，产品的验收等)，对被测软件产品或功能进 行测试的有关文件。
测试规范的内容：
1.软件测试规范的定义
2.软件测试规范描述的内容：
• 测试计划规范
• 测试用例设计规范
• 测试工具使用规范
• 缺陷跟踪系统录入规范
• 缺陷严重等级和优先级划分规范
• 缺陷分类规范
• 缺陷状态修改规范
• 缺陷递交流程规范
• 测试报告规范
• 测试退出规范
• 软件测试类型规范
• 开发语言测试规范
• 软件测试流程规范
• 界面测试规范
4，测试用例：测试用例的格式
软件测试用例的基本要素包括：
测试用例编号
测试标题
重要级别
测试输入
操作步骤
预期结果
5，缺陷报告：为了便于管理测试发现的软件错误，通常要采用软件缺陷数据库，将每一个发现的错误输入到软件缺陷数据库中，软件缺陷数据库的每一条记录称为一个软件问题报告。
缺陷报告文档的几个特殊性如下：
• 只针对具体软件缺陷行为，也就是Bug具体信息。
• 有统一的在线模板。
• 缺陷报告的编写质量是衡量测试工程师技术水平的常用度量。
• 缺陷报告的信息直接关乎软件产品具体功能和设计行为。
• 缺陷报告是开发人员、测试人员、项目经理每天工作的主要共同的对象。
• 缺陷报告的数量是所有软件测试项目衡量软件质量重要指标之一。
6，测试结果报告：把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。
书写软件测试报告的一般方法:
1.确定报告的读者
2.书写测试报告的准则
• 报告内容应是真实的可靠的
• 使用准确、简洁的文风，保持测试报告有良好的格式
• 行文保持客观、对事不对人、关注问题本身
4.4 测试文档管理
1，测试计划的评审：测试计划评审的内容：可行性，正确性，全面性
测试计划评审的参与者：项目经理、软件开发团队、产品部门、市场测试文档管理工具部门等软件测试干系人。必要的时候甚至需要邀请法务等部门参加测试计划的评审。
2，测试用例评审：可分为测试组内部评审和项目组评审
评审主要侧重于：1 测试用例本身的描述是否清晰，是否存在二义性；
2. 是否考虑到测试用例的执行效率，往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；
3 是否针对需求跟踪矩阵，覆盖了所有的软件需求；
4. 是否完全遵守软件需求的规定。因为即使再严格的评审，也会出现错误，应视具体情况而定。
评审的角度不同，评审的侧重点也不同：
1. 收集客户需求的人员注重测试用例是否符合业务逻辑；
2. 分析软件需求规格的人注重测试用例是否跟软件需求规格要求一致；
3. 开发负责人会注重你的用例中对程序的要求是否合理。
3，测试文档管理工具：惠普 Application Lifecycle Management（ALM）是一款集成了测试文档管理功能的专业软件研发管理系统
使用HP ALM 进行测试管理包括四个步骤：
（1）明确条件：分析你的应用程序并且确定下你的测试条件。
（2）测试计划：根据你的测试条件创建你的测试计划。
（3）执行测试：在你的测试运行平台上创建Test sets。
（4）跟踪缺陷：报告在你的应用程序中的缺陷并且记录下整个缺陷的修复过程。
4.5 测试用例管理
1, 编写测试用例的挑战与应对: 传统的独立（电子表格）文件形式的局限性和挑战
1.测试用例的存储安全。
2.测试用例难于分类与查询。
3.与测试需求的对应关系难以维护。
4.团队合作问题。
5.测试用例的版本信息难于完整管理。
6.难以实现测试用例的执行与结果管理。
7.测试用例与缺陷的对应关系难以维护。
2, 最佳测试用例特点:
最佳测试用例的设计原则包括：
（1）依据原则
（2）全覆盖原则
（3）规范原则
（4）全面原则
最佳测试用例的特点有以下几方面：
（1）完整性
（2）准确性
（3）简洁性
（4）清晰性
（5）可维护性
（6）适当性
（7）可复用性
（8）其它
3，测试用例生命周期：
4，测试用例管理工具：通常使用基于数据库的软件研发管理系统
测试用例管理工具一般应包括如下功能：
• 测试用例ID管理
• 测试用例的维护
• 测试用例分类管理
• 用例的导入导出
• 用例搜索功能
• 提供测试需求、测试结果和缺陷的对应关系
4.6 测试文档最佳实践
在测试文档管理中应该要注意以下几个方面：
建立测试文档管理制度
加强文档版本管理
创建测试文档库的访问规则
使用工具管理文档
写缺陷报告的建议
• 多读优秀缺陷报告，学习最佳实践。
• 每个缺陷报告尽量截取图片和log，帮助开发人员快速定位问题。
• 对重现步骤自己要多执行几遍，确保开发人员可以再现缺陷。
• 缺陷报告要客观得体，不要包含自己的主观情绪。
5 软件质量模型
5.1 软件质量概念
1，软件质量的重要性: 导致项目进度延误、预算超支或项目失败、项目终止。
软件质量高降低项目开发成本，包括维护成本、修复成本等
2，软件质量的定义：
·ISO/IEC9126: 反映软件产品满足规定需求和潜在需求能力的特征和特性的总和
·MJ.Fisher: 所有描述计算机优秀程度的特性的组合
·ANSI/IEEE Std 1061-1992: 与软件产品满足需求所规定的和隐含的能力有关的特征或特性的全体
3，软件质量的特性： •用户–如何使用软件、软件性能和使用软件的效果
•开发者–中间产品的质量以及最终产品
•管理者–总的质量，而不是某一特性
5，ISO/IEC9126规定，软件质量可用6个特性来评价：
• 功能性：软件所实现的功能达到它的设计规范和满足用户需求的程度
• 可靠性：在满足一定条件的应用环境中，软件能够正常维持其工作的能力
• 可用性：对于一个软件，用户在学习、操作和理解过程中所做努力的程度
• 效率：在规定条件下，用软件实现某种功能所需的计算机资源(包括时间)的有效程度
• 维护性：当环境改变或软件运行发生故障时，为使其恢复正常运行所做努力的程度
• 可移植性：为使一个软件从现有运行平台向另一个运行平台过度所做努力的 程度
GB/T 16260-2006质量模型 ：
5.2 软件质量分层模型
1，McCall模型（FCM）：软件质量要素(factor)，衡量标准(criteria)和量度标准(metrics)。在FCM三层模型中，软件质量概念是基于11个特性之上，这11个特性分别面向产品操作(product operation)、产品修正(product revision)和产品转移(product transition)
2，Boehm模型：
• 软件质量模型第一层: 功能性、可靠性、可用性、效率、可维护性和可移植性
• 第二层给出了23个质量特性: 可访问性、可说明性、准确性、可扩充性、通信
性、完备性、简洁性、一致性、设备独立性、效率、人类工程、可读性、可维
护性、可修改性、可移植性、可靠性、健壮性、自包含性、自描述性、结构性、
可测试性、可理解性和可用性
• 第三层是软件质量度量，通过对软件开发各个阶段进行问卷调查，实现对软件
开发过程的质量控制
3，ISO/IEC 9126质量模型：该模型将软件质量定义为六大特性：功能性、可靠性、可用性、效率、可维护性和可移植性，每个特性又分为一系列子特性。
4，GB/T 16260-2006质量模型：该模型在上述模型的基础上对软件质量从6个质量特性和27个质量子特性进行概念性描述。
5.3 软件质量度量与评价
软件质量定量评价公式：
通过国内外多年研究，在软件质量的定量评价方面取得了一定成果。国外著名软件质量度量和评价产品中都给出了相关的计算公式，如Panorama++，Logiscope，McCabe IQ等
•可维护性：0.5可测试性+0.5可理解性
•可测试性：0.5结构性+0.5McCabe复杂度
•可理解性：0.25结构性+0.25McCabe复杂度+0.25简洁性+0.25自描述性
•结构性：0.2编码语句的最大嵌套层次+0.2修改全局数据+0.2使用Goto语句+0.2数据习惯用法+0.2无条件循环语句所占比例
• 简洁性：0.4实体的习惯用法+0.4局部调用+0.2被调用
• 自描述性：0.2B_comment + 0.3全部注释行所占的比例 + 0.5注释实体所占比例
• 可移植性：0.5 * 独立性 + 0.5 * 完整性
• 独立性：0.5 * 异常比例 +0.5 * 用户定义类型
• 完整性：(if语句 + case语句 + 初始化对象)/ 3
• 可靠性：0.33完整性+0.33模块性+0.34可测试性
• 模块性：0.5 * 编码行数 + 0.5 * 结构性
6 软件测试流程管理
6.1 软件测试流程管理基础
1，测试流程管理的意义：
a)角色分工的统一和集中分配便于管理和绩效考核
b)沟通所需的软件开发和测试流程环节和结果、步骤帮助团队成员明确各自的工作任务
c)明确测试流程便于领导层及时发现隐患，并采取行动
d)便于新员工快速学习应做的工作，并融入团队工作
6.2 软件测试的一般流程
1，开发模式与软件测试流程
ISTQB定义的软件测试过程：
a)测试计划和控制；
b)测试分析和设计；
c)测试实现和执行；
d)评估出口准则和报告；
e)测试活动结束
典型的软件测试流程:
需求分析
需求评审
开发人员编写排期
测试计划排期
编写测试用例
用例评审
提交基线
测试执行与结束
2, 计划与设计阶段: 测试设计与测试计划>>测试项目确认
3, 实施测试阶段:
实施测试阶段的环节：
1.执行测试用例
2.记录原始测试数据
3.记录和报告缺陷
4.对所发现的缺陷进行跟踪、管理和监控
具体测试流程：
1.系统测试
2.性能测试
3.自动化测试实施流程
4.测试的执行
5.缺陷管理流程
6.3 敏捷测试流程
1,敏捷测试流程的特点:全程参与；轻量级文档；轻量级测试用例
敏捷开发模型适用的场景：需求可能快速变化，开发周期短，发布频率快
敏捷测试的核心：迭代
流程分析：
在这个流程中弱化了文档，强调了各个人员的沟通，通过这种迭代的方式，三个月的项目，可以能两个月或两个半月就会完成。
敏捷测试的流程：第一块面板中是开发人员未实现的功能，第二块面板中是开发完成的功能，测试人员对其进行测试，发现不通过的就放回未开发的面板中，测试通过的将放到
第三块面板中。
2，敏捷测试中的新功能测试和回归测试
针对新开功能的测试的策略：
1.以用户用例（User Case）或者用户故事（User Story）替代测试用例。
2.持续进行验证，一旦一个具有完整功能的代码模块完成，立刻开始测试工作，而不是等待整个功能完全完成才着手测试。
3.更多实施端到端（End-to-End）的测试，重视从最终用户角度出发保证业务流程的正确性和健壮性。
回归测试的策略：
1）实现更多的自动测试来保证回归测试的效率
2）对回归测试做适当的裁剪
•通过代码变更区域的分析，只针对受影响的范围进行测试。
•根据用户关注程度和基于风险分析，对功能点进行优先级排序，必要的时候只测试高优先级的功能点，而忽视较低优先级的功能点。
3，敏捷(开发)测试活动：主要由三部分构成，从最初的用户故事设计和发布计划，到几次 Sprint周期的迭代开发和测试，以及最后的产品发布阶段。每个时间段都有相应的测试活动。
4，Sprint 周期中的主要测试活动：
·估算验收测试时间；
·测试框架的搭建；
·详细设计验收测试用例
5，敏捷测试中的测试工程师：
1）测试人员需要具备的素质
• 具有质量检测和编写代码的能力
• 具有防止缺陷和质量控制的能力
• 具有开发和执行测试程序的能力
• 总结而言，有三方面的基本素质要求：代码编写、测试和分析 。
2）测试人员的主要职责
• 定义质量
• 交流缺陷
• 及时反馈
6.4 惠普测试流程管理工具
使用惠普 ALM 进行测试流程管理的最佳实践：
使用专业的软件项目管理软件：
a)需求分析
b)测试计划
c)测试设计
d)测试执行
e)缺陷管理
f)测试总结
g)持续改进
7 软件测试执行管理
7.1 软件测试执行基础
1，软件测试执行的内容：主要包括4项任务：
• 执行测试计划预定的测试，包括执行所有已设计的测试用例
• 记录原始测试数据
• 记录缺陷
• 对所发现的缺陷进行跟踪、管理和监控
软件测试的执行包括：手动测试，自动测试
软件测试执行的内容就是要决定怎样执行测试和测试什么决定测试执行的内容需要明确以下信息 ：
1
a)测试执行依据的文档
b)制定测试执行计划
c)记录测试执行的结果
d)执行测试的过程
e)测试执行活动结束或终止
f)核实测试结果并报告缺陷
g)测试执行的准备
h)测试执行过程
2，影响测试执行的因素：
实际软件测试过程中，测试资源、测试质量、测试时间之间相互制约
软件测试执行影响因素：
• 测试计划
• 测试环境准备
• 测试实现
测试执行进度计划的影响因素：
• 过程成熟度
• 测试的时间
• 测试的规模
• 测试的资源
• 产品的质量
• 测试的文档
3，测试执行管理要考虑和关注的环节
1）戴明环指导测试执行
2）测试执行的起始
• 记录测试执行结果
• 测试执行的流程
• 测试执行入口准则
• 测试执行关键信息
3）测试执行的结束
• 确保所有的测试工作全部完成
• 移交测试工作产品
• 总结经验教训
• 在配置管理系统中归档所有的结果、记录、报表和其他文档及交付物
4，软件测试执行的控制
1）测试执行控制阶段的主要测试活动：
按预定的计划执行测试
确定测试执行范围和风险
确定测试执行目的
确定测试执行方法
确定测试执行资源
计划测试执行的进度
确定测试执行入口准则和出口准则
监控和记录测试执行过程
度量和分析测试结果
修正测试执行计划
做出决定
2）常用的度量指标
a)在测试分析和设计中发现的缺陷数
b)测试用例设计完成率
c)测试环境准备的进度
d)测试用例执行情况（如：测试用例执行率、测试用例通过率）
e)缺陷信息（如：缺陷密度、发现和修改的缺陷比例、再测试的通过率）
f)需求、风险或代码的测试覆盖率
g)测试的成本
3）对测试实现和执行阶段进行监控的度量方法：
1.测试环境配置的百分比。
2.测试数据装载的百分比。
3.测试条件和测试用例执行的百分比。
4.测试用例自动化的百分比。
4）评估出口准则和报告阶段涉及的度量：
1.测试需求的覆盖率。
2.测试用例的覆盖率。
3.测试用例执行通过/失败的数目。
4.提交的缺陷数目，根据缺陷的严重程度和优先级进行的分类。
5.提交的缺陷数目，接受的缺陷和被拒绝的缺陷的比例。
6.计划成本支出和实际成本支出的偏差。
7.计划花费时间和实际花费时间的偏差。
8.测试中识别的风险和处理的风险数目。
9.由于事件制约因素浪费的时间。
7.2 软件测试执行结果的评估
1，测试通过与失败：测试执行对每一项要测试的内容都必须有个结论。
即测试是否通过。答案为“是(Yes)”或者“否(No)”
通过：测试实际输出结果和测试期望结果一致
未通过：测试实际输出结果和测试期望结果不一致
• 测试结果的不一致或者失败并不一定是由于测试对象的缺陷引起的，也许是因为测试环境出错、测试人员执行测试时人为误差等。
• 如果是由于测试对象引起的不一致，那么测试人员需要提交相应的缺测试
结果的比较：手动比较；自动比较
2，测试覆盖率与通过率：测试执行人员应该正确理解四个度量指标
测试覆盖率：是用来度量测试完整性的一个指标
测试执行率：指实际执行过程中确定已经执行的测试用例比率
测试通过率：用来度量测试执行结果的一个指标
缺陷解决率：指某个阶段已关闭缺陷占缺陷总数的比率
3，测试通过标准
出口准则（Exit Criteria）:
•可用于报告和计划什么时候可以停止测试
•与利益相关者达成一致的通用和专门的条件，用于正式定义一个过程的结束点
•出口准则的目的可以防止将没有完成的任务错误地看成任务已经完成评估测试
出口准则和报告阶段的主要测试活动有:
•将测试状态和测试计划中的出口准则进行比较。
•评估是否需要更多的测试执行，或者是否需要更改测试出口准则。
•输出测试总结报告。
评估测试出口准则和报告阶段的主要输入:
1）测试状态报告、缺陷状态报告、风险状态报告、项目测试周报告/月报告、测试出口准则和测试计划。
2）回归测试所运行的用例全部通过。
3）缺陷经过验证。
4）所有缺陷都被指明处理方式。
5）同行审查没有新的缺陷或没有严重缺陷产生。
对测试组所测试项目或产品的测试审查工作的基本原则:
1）不依据所设计测试用例,进行自由测试。
2）测试时间保持在3个正常工作日以内。
3）如发现严重缺陷,则一轮测试结束后,更新版本并执行回归测试。
4）提交当日测试纪录。
5）编写同行审查总结报告(报告以简单为好)。
一种定义缺陷分类的方法：
A类—— 严重错误
(1) 由于程序所引起的死机,非法退出
(2) 死循环
(3) 导致数据库发生死锁
(4) 数据通讯错误
(5) 严重的数值计算错误
B类—— 较严重错误
（1）功能不符
（2）数据流错误
（3）程序接口错误
（4）轻微的数值计算错误
C类—— 一般性错误
（1）界面错误(详细文档)
（2）打印内容、格式错误
（3）简单的输入限制未放在前台进行控制
（4）删除操作未给出提示
D类——较小错误
(1) 辅助说明描述不清楚
(2) 显示格式不规范
(3) 长时间操作未给用户进度提示
(4) 提示窗口文字未采用行业术语
(5) 可输入区域和只读区域没有明显的区分标志
(6) 系统处理未优化
E类——测试建议（非缺陷）
4，测试执行结果报告：
定义：测试执行总结报告是将数据收集和分析结果进行文档化，并且提交给相应的团队作为以后项目的参考文档。测试执行总结报告是进行软件测试过程评估和改进的重要输入，也是进行相关开发过程改进和测试度量数据库更新的主要输入。
测试执行结果报告包含：
·一个测试执行的结果报告模板；
·缺陷状态报表；
·验收测试结果报告
测试执行总结报告主要构成部分：
• 概要信息
• 测试风险
• 测试工作量
• 测试执行
7.3 软件测试执行的最佳实践
1，测试执行注意事项
a)全方位的观察测试用例执行结果
b)加强测试过程记录
c)及时确认发现的问题
d)与开发人员良好的沟通
e)及时更新测试用例
2，提高测试执行水平的十个注意点
a)工作效率
b)耐心
c)责任心
d)排查问题的能力
e)回归测试的覆盖度
f)敏捷测试模式的效率
g)注意细节
h)提高自动化测试覆盖度
i)不断自我提高
j)提高业务熟练度
8 发布工作
1，定义：惠普应用程序生命周期管理（ALM）通过定义发布和循环来组织和跟踪即将进行的发布。测试流程始于在Management模块中定义Releases。该模块用于根据项目需求、测试和缺陷，累排列业务的优先级别和质量期望。
2，发布树例子：
1.）Cycle 1-New Features Testing：测试此次发布的程序中实现的新特点。新特点测试之后，开发团队修正测试中记录的缺陷。但是，根据缺陷的危急程度和严重性，一些缺陷可能会等到下一个周期才修正。
2) Cycle 2- Integrated System Testing：这个周期中测试新功能可能对原有功能产生的影响。
3) Cycle 3-Perfomance Testing：根据一些标准来测试应用程序的性能，例如程序支持的并发用户数量和程序响应时间。
4）Cycle 4-User Acceptance Testing： 这一周期确保新产品的点满足业务期望。
3，创建发布树工具
通过创建发布树来定义发布的分层架构。根据组织架构的测试流程，可以为每个程序创建一个发布文件夹，或多个程序创建一个文件夹。
4，新建发布/发布详细对话框
在New Release对话框，你可以定义一个新的发布。在Release Details对话框可以查看和更新所选择的发布的详细内容。
5，指定循环细节
在DETAILS页面，执行下列任务：
从START DATE 列表中选择周期开始日期
从END DATE列表中选择周期结束日期
在DESCRIPTION字段，输入周期期望完成的目标的描述。
6，重新计划发布/循环/里程碑: 该对话框可以用来重新安排发布、周期或者里程碑的开始和结束日期
7，添加附件到循环: 向周期添加附件时可能会有环境要求。
8，指定发布或循环的需求
在REQUIREMENTS子模块定义需求后，在MANAGEMENT模块中创建周期，并向发布或周期分配需求。在Requirement模块，确定每个周期中需要覆盖哪些需求，并由此将这些需求分配到相关周期。使用需求决定程序中哪些内容需要测试。
9，进度标签: 进度标签显示当前发布或周期进展状况的目测指标。可以看到已用时间和剩下时间，已经完成和剩下的测试实例，实际的和需要的执行比率等信息。
10，质量标签: 标签以图表的形式显示了全过程中提交的发布或周期缺陷
9 需求管理
使用ALM的应用程序生命周期管理路线图包括以下阶段：
1 定义循环需求的优点
需求详细描述需要解决或实现的内容，以达成正在开发的应用程序的目标。在项目前端清晰正确地定义需求提供以下优点：
a)向利益相关者提供定义优先级的指导方针
b)在利益相关者之间设定清晰的预期
c)减少浪费并消除不必要的支出
2 在ALM中如何使用需求
如何在 ALM 中创建和管理需求。包括以下步骤:
1.先决条件: 通过收集功能和技术规范、市场和业务需求文档以及利益相关者目标等信息，确定需求的范围。
2.创建需求: 通过创建需求树，定义需求范围的层次结构框架。
3.导入业务流程模型:如果使用业务流程模型，可以通过导入使用标准建模工具创建的模型，创建需求的框架 。
4.跟踪需求:可以在需求之间添加可跟踪性。
5.计算风险:可以根据需求的性质和你掌握的资源，使用基于风险的质量管理计算在哪个级别，测试每项需求。
6.创建覆盖率: 在需求和测试之间创建覆盖率，以确保在项目中实现所有需求。
7.链接到缺陷: 可以将需求链接到特定缺陷。
8.分配至版本: 将需求分配到在“版本”模块的版本树中定义的版本或周期。
9.分析需求: 复审需求以确保它们满足定义的需求范围。
10.建立基线: 创建基线以批准或比较应用程序生命周期中的重要里程碑。
3 介绍需求
对于每一个需求主题，测试工程师均应该创建相应的详细测试需求列表。
在需求树中的每一个需求均要求被详细描述，并且应该包括所有与需求相关的附件。测试工程师分配每个需求一个优先级，此优先级会作为测试组创建测试计划的一个考虑因素。
ALM在需求树中有机的组织并显示数据。需求树中每一行都显示了一条独立的需求。需求树中可以显示如表所示细节信息。
4 创建需求树
需求工具栏包括如下的按钮
5 创建需求
1）创建需求包括以下步骤
a) 创建需求：
•打开“需求”模块。在 ALM 侧栏的需求下，选择需求。在查看菜单中，选择需求树。
•创建文件夹。右击需求根文件夹，然后选择新建文件夹。要创建子文件夹，请右击文件夹并选择新 建文件夹。
•添加需求。右击需求文件夹，选择新建需求。要创建子需求，请右击需求并选择新建需求。
b) 导入需求
•除了直接在ALM 中创建需求以外，还可以从 Microsoft Word 、Microsoft Excel 或其他第三方需求管理工具将需求导入 ALM 项目。要导入需求，必须先安装相应的插件。
c) 更新需求
•对于每个需求，可以更新其详细信息、附件和多信息文本文档。右击需求，选择需求详细信息。将打开“需求详细信息”对话框。
d) 将需求转换到测试 ·为帮助在“测试计划”模块中建立测试计划树，可将需求用作定义测试的基础。
2）如何创建需求——用例场景
用例场景提供在“需求”模块中指定需求的示例。
3）需求详细信息
4）需求模块菜单和按钮
5）描述和注释选项卡
6）查看需求历史
6 可跟踪矩阵概述
1）可跟踪性矩阵允许你确定需求和需求之间以及需求和测试之间的关系的范围。它有助于你验证是否满足所有需求，如有更改还可标识更改的需求范围。
2）可跟踪性矩阵列出源需求及其关联的需求和测试。对于每个源需求都会列出关系总数。低值可能表示源需求关联的需求或测试不够。高值可能表示源需求太复杂，可以进行简化。零值表示不存在关联关系。
7 覆盖率分析
此需求有十二个子项（包括自身）。在“覆盖率分析”中，可以看到两个子项的状态为失败（一个或多个由此需求覆盖的测试失败）。进行分析时，可以看到与此需求关联的三个 (27%) 测试失败。
10 测试计划
此项内容过多，后续补充~
项目组织分布
软件测试的方法选择
一、项目管理部门主要任务
(1) 制定或修改软件开发计划和测试计划；
(2)对整个软件项目的进度进行评估;
(3)对一些重大问题进行决策，确保软件开发项目按计划保质量地完成;
(4)决定每周要完成的开发和测试任务;
(5)协调和解决开发部门和测试部门之间产生的问题;
(6)决定提前或推后发布软件。
二、开发部门主要任务
(1)按照开发计划及时间进度表，编写新的程序代码；
(2)对测试部门发现的软件缺陷报告进行分析，确定修改的优先级;
(3)对一批软件缺陷报告进行修复后，进行软件系统集成，产生新测试版本，在提交给测试部门之前进行最基本的检查；
(4)按照开发计划，在每个测试版本的提交日期内，将新的软件测试版本提交给测试部门进行软件缺陷修复验证和新一轮测试。
(5)返回第一步。
三、测试部门主要任务
(1)根据不同测试要求，设计测试用例;
(2)按照测试计划和项目进度表，实施软件测试；
(3)对发现的软件缺陷编写软件缺陷报告，并及时报告给软件开发部门;
(4)对开发部门提供的软件缺陷修改后形成的新测试版本，进行软件缺陷验证；
(5)对开发部力提供的新测试版本，开始新一轮的测试。
(6)返回第一步。
四、测试组织和开发组织的关系
基本原则:
l 在软件测试管理中，要特别强调避免一个组织测试自己编写的程序，原因是任何开发组织都很难客观地测试自己的程序;
l 应该成立独立的软件测试组织进行软件测试:
l 测试组织与开发组织之间的关系越远越好。
五、测试配置内容
测试人员:人数、经验和专长、全职、兼职。
测试设备:计算机，打印机等。
测试环境:硬件、软件环境。
测试工具:各类测试工具。
测试地点:办公室成实验室，面积大小等。
测试策略:是否需要专业测试公司，费用如何。
其他需求:移动存储器、电话、通讯等。
六、主测试环境要求
(1)符合被测软件运行的最低要求，保证支撑软件能正常运行。
(2)选用比较普及的操作系统和软、硬件平台。
(3)构造相对简单、独立的测试环境。除了操作系统，测试机上只安装被测软件运行和测试必需的支撑软件，以免不相关的软件影响测试。
(4)保证测试环境中没有病毒，利用有效的正版杀毒软件检测软件环境。
七、辅测试环境要求
(1)兼容性测试:在满足软件运行要求的范围内，选择一些典型的操作系统和常用应用软件，对被测软件的安装、卸载和主要功能进行验证。
(2)模拟真实环境测试:对有些软件，特别是面向大众的商品化软件，在测试时常常需要考察其在真实环境中的表现。
(3)横向对比测试:利用辅测试环境“克隆”出完全一致的测试环境，从而保证各个被测软件平等对比。
(4)国际化测试:利用不同的语言环境进行测试，保证在不同的国家和地区正常使用。
八、测试计划的重要性
测试跟踪:
在整个项目开发期间，计划执行多少个测试用例?在系统最终版本上执行多少个测试用例?多少个通过，多少个失败?有无忽略的测试用例?等等。如果没有测试计划，就不能回答这些问题。
测试验证:
在少数高风险行业中，测试小组必须证明确实执行了计划执行的测试。发布忽略某些测试用例的系统实际上是不合法和危险的。正确的测试计划和测试跟踪提供了一种验证手段。
九、测试说明
描述被测产品基本情况:
l 测试目的
l 变更信息
l 软件结构及技术要求
l 软件产品规格说明
l 测试范围
l 项目信息
十、测试计划的内容
1)测试说明
2)测试需求
3)测试策略
4)测试记录
5)测试资源配置
6)软件缺陷追踪
7)测试计划时间表
8)测试计划评审
十一、软件结构及技术要求
将被测软件划分成几个组成部分，规划成一个适用于测试的完整的系统，包括数据是如何存储的，如何传递的(数据流图)，每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有-些常规性的技术要求，比如运行平台、需要什么样的数据库等等。
十二、测试范围
简单的描述如何搭建测试平台以及测试的潜在的风险等。
十三、测试需求
列出所有要测试的功能项(测试项或测试点)。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。
l 功能的测试
l 设计的测试
l 整体考虑
十四、设计的测试
l 针对用户界面、菜单结构、窗体等的设计是否合理等的测试;
l 测试内容包括美观性、可用性、易用性等方面；
l 系统的外观很重要，要求有尽可能好的合理性。
十五、整体考虑
测试系统各模块之间的接口，即测试数据流从软件中的一个模块流到另一个模块过程中的正确性，这是保证软件系统正确的前提。
十六、测试策略
根据不同的测试区域选择不同的测试策略:
黑盒、白盒测试
-功能、性能测试
自动、手动测试
十七、测试记录
l 公正性说明
l 测试用例管理工具
l 软件缺陷管理工具
l 特殊考虑
l 经验判断
十八、公正性说明
l 要对测试的公正性、依照的标准做一个说明，证明测试是客观的。在整体上，软件功能要满足需求、实现正确、和用户文档的描述保持一致。
l 要保证测试的客观，就要保证测试人员能客观的完成测试任务。
十九、测试用例管理工具
描述测试用例模板，管理测试用例采用了什么工具，工具的来源是什么，如何执行的，用了什么样的数据。测试用例记录中要为将来的回归测试记录信息。
二十、软件缺陷管理工具
在测试的计划阶段，应该明确建立一个软件缺陷管理的方法和工具。工具的来源是什么，如何执行的，需要使用什么样的数据。
二十一、特殊考虑
针对一些外界环境的影响， 要对软件进行一些特殊方面的测试。
例如，对于一些用于高尖端产品的信息系统，如水下机器人、太空探测器等，测试者应给予某些特殊的测试，使它们能在恶劣的环境下有着较高的可靠性和适应性。
二十二、经验判断
经验判断就是利用历史数据针对系统运行或测试中经常出现的问题仔细研究考虑，使之发生率尽量的小。
例如对于数据库系统，数据的操作(存取，副除，修改等)是其基本功能，同时也是经常出现问题(如数据冗余、死锁等)的地方。
二十三、测试资源配置
制定一个资源配置计划，包含每一个阶段的任务、所需要的资源。当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。
二十四、软件缺陷追踪
l 描述软件缺陷报告的内容:缺陷名称、发现时间、发现者、修复者、发生的频率、所使用的测试用例，以及测试环境等。
l 描述如何界定一个软件缺陷的性质，对软件缺陷性质的描述尽可能是定量的。
l 描述软件缺陷报告的处理过程。
二十五、测试计划时间表
测试的计划表可以做成多个项目通用的形式，根据大致的时间估计来制作，操作流程要以软件测试的常规测试周期作为参考，也可以是根据什么时候应该测试哪一个模块来制定。
二十六、测试计划评审
在测试真正实施开展之前必须要认真负责的对测试计划检查一遍，并获得整个测试部门人员的认同，包括部门的负责人的同意和签字。
————————————————
版权声明：本文为CSDN博主「小白菜666」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_41224638/article/details/80503440
————————————————
版权声明：本文为CSDN博主「软软的软测工程师」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_41389678/article/details/95990457