软件测试管理知识总结

1 软件测试管理概述
1.1软件测试管理基础
1，软件测试管理目标：软件测试管理的目标是通过系统的、高效的、适用的技术、方法和体系来监督、促进和达到这个软件测试的目标。
可用测试资源
使用适当的测试技术和方法
明确具体软件测试任务
决定软件测试管理时应考虑：

1. 测试设计说明
2. 测试用例说明
3. 测试规程说明
   测试 告 ：包括四类文档：
4. 测试项传递 告
5. 测试日志
6. 测试事件 告
7. 测试总结 告
   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，测试用例生命周期：

敏捷测试的流程：第一块面板中是开发人员未实现的功能，第二块面板中是开发完成的功能，测试人员对其进行测试，发现不通过的就放回未开发的面板中，测试通过的将放到
第三块面板中。

2，敏捷测试中的新功能测试和回归测试
针对新开功能的测试的策略：
1.以用户用例（User Case）或者用户故事（User Story）替代测试用例。
2.持续进行验证，一旦一个具有完整功能的代码模块完成，立刻开始测试工作，而不是等待整个功能完全完成才着手测试。
3.更多实施端到端（End-to-End）的测试，重视从最终用户角度出发保证业务流程的正确性和健壮性。
回归测试的策略：
1）实现更多的自动测试来保证回归测试的效率
2）对回归测试做适当的裁剪
过代码变更区域的分析，只针对受影响的范围进行测试。
据用户关注程度和基于风险分析，对功能点进行优先级排序，必要的时候只测试高优先级的功能点，而忽视较低优先级的功能点。
3，敏捷(开发)测试活动：主要由三部分构成，从最初的用户故事设计和发布计划，到几次 Sprint周期的迭代开发和测试，以及最后的产品发布阶段。每个时间段都有相应的测试活动。

a) 创建需求：
开“需求”模块。在 ALM 侧栏的需求下，选择需求。在查看菜单中，选择需求树。
建文件夹。右击需求根文件夹，然后选择新建文件夹。要创建子文件夹，请右击文件夹并选择新 建文件夹。
加需求。右击需求文件夹，选择新建需求。要创建子需求，请右击需求并选择新建需求。

b) 导入需求
了直接在ALM 中创建需求以外，还可以从 Microsoft Word 、Microsoft Excel 或其他第三方需求管理工具将需求导入 ALM 项目。要导入需求，必须先安装相应的插件。

d) 将需求转换到测试 ·为帮助在“测试计划”模块中建立测试计划树，可将需求用作定义测试的基础。

2）如何创建需求——用例场景
用例场景提供在“需求”模块中指定需求的示例。
3）需求详细信息
4）需求模块菜单和按钮
5）描述和注释选项卡
6）查看需求历史
6 可跟踪矩阵概述
1）可跟踪性矩阵允许你确定需求和需求之间以及需求和测试之间的关系的范围。它有助于你验证是否满足所有需求，如有更改还可标识更改的需求范围。

2）可跟踪性矩阵列出源需求及其关联的需求和测试。对于每个源需求都会列出关系总数。低值可能表示源需求关联的需求或测试不够。高值可能表示源需求太复杂，可以进行简化。零值表示不存在关联关系。
7 覆盖率分析
此需求有十二个子项（包括自身）。在“覆盖率分析”中，可以看到两个子项的状态为失败（一个或多个由此需求覆盖的测试失败）。进行分析时，可以看到与此需求关联的三个 (27%) 测试失败。

10 测试计划
此项内容过多，后续补充~