1 软件测试管理概述
1.1软件测试管理基础
1，软件测试管理目标：软件测试管理的目标是通过系统的、高效的、适用的技术、方法和体系来监督、促进和达到这个软件测试的目标。
可用测试资源
使用适当的测试技术和方法
明确具体软件测试任务
决定软件测试管理时应考虑：
1）敏捷开发的流程：
3）自动化测试策略：新功能测试用手工测试旧模块可以使用自动化测试
4，如何建立测试管理体系
某企业用于测试管理的结构图：
1.3软件测试管理要素
1，测试管理五要素：质量；人员；流程；资源；技术
2，软件测试管理体系本身是软件的应用，就是一种技术，一是工具。软件测试管理体系涉及功能测试、性能测试、安全性测试等多种软件测试类型，包含了软件测试流程中各阶段的流程规范、测试理论、测试工具等各方面内容。
1.4 软件测试管理策略
2 软件测试需求管理
2.1软件测试需求概念
1，软件测试需求：以一个项目的观点看待软件测试工作，这个项目的范围就是软件测试需求，它定义了软件测试工作的范围，是进行其他测试活动的基础。
软件测试需求的内容： –功能测试需求
–性能测试需求
–可靠性测试需求
–国际化与本地化测试需求
–安全性测试需求
2，软件需求管理
1)软件需求的概念：
软件测试需求管理是要通过人为的和技术的手段、方法和流程，以保证和监督测试团队明确测试软件产品的目标。
定义1：软件需求就是一个为软件系统的需求进行启发、组织、建档的系统方法，一个建立和维护客户和项目团队之间关于变更系统需求所达成的一致性的过程。
定义2：一种获取，组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一的过程。
2)软件需求管理要求:
a)软件需求规格说明已文档化，并经评审后存档。
b)文档化的软件需求规格说明受管理和控制。
c)供软件工程和管理使用的分配基线已建立，使软件产品满足分配需求的接收标准；分配需求是制定软件开发计划的根据，是整个软件生命周期中估算、计划、执行和跟踪软件项目活动的基础。
d)软件开发计划、软件工作产品和软件过程活动与软件需求保持一致。
业界常见的测试过程中存在的问题 ：
软件测试本身的需求文档不全，有些需求待定；
产品质量维度事先没有全面明确，要包括的测试类型不全；
测试计划和编写测试案例没有规范；
没有系统的测试需求分析方法、流程或指导；
测试中经常会出现需求和缺陷遗漏、测试设计遗漏的问题。
3)软件测试需求管理意义
（1）失败经验教训说明必须要有软件测试需求管理
（2）业界专家建议必须实施软件测试需求管理
（3）缺乏成熟的理论和统一标准而需要需求管理
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”状态
测试需求状态转换
（1）指定版本
（2）指定需求
（3）计划测试
（4）执行测试
（5）追踪缺陷
惠普应用程序生命周期管理系统模块有11个模块，如图左侧边栏所示。
2，软件测试组织的专业分工
测试团队常见的角色分工
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，测试用例生命周期：
5.2 软件质量分层模型
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, 计划与设计阶段: 测试设计与测试计划>>测试项目确认
流程分析：
在这个流程中弱化了文档，强调了各个人员的沟通，通过这种迭代的方式，三个月的项目，可以能两个月或两个半月就会完成。
敏捷测试的流程：第一块面板中是开发人员未实现的功能，第二块面板中是开发完成的功能，测试人员对其进行测试，发现不通过的就放回未开发的面板中，测试通过的将放到
第三块面板中。
2，敏捷测试中的新功能测试和回归测试
针对新开功能的测试的策略：
1.以用户用例（User Case）或者用户故事（User Story）替代测试用例。
2.持续进行验证，一旦一个具有完整功能的代码模块完成，立刻开始测试工作，而不是等待整个功能完全完成才着手测试。
3.更多实施端到端（End-to-End）的测试，重视从最终用户角度出发保证业务流程的正确性和健壮性。
回归测试的策略：
1）实现更多的自动测试来保证回归测试的效率
2）对回归测试做适当的裁剪
过代码变更区域的分析，只针对受影响的范围进行测试。
据用户关注程度和基于风险分析，对功能点进行优先级排序，必要的时候只测试高优先级的功能点，而忽视较低优先级的功能点。
3，敏捷(开发)测试活动：主要由三部分构成，从最初的用户故事设计和发布计划，到几次 Sprint周期的迭代开发和测试，以及最后的产品发布阶段。每个时间段都有相应的测试活动。
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 测试计划
此项内容过多，后续补充~
来源：媛媛要加油呀
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！