软件测试基础--使用测试文档

来源:互联网 发布:暖气片不热 知乎 编辑:程序博客网 时间:2024/06/13 22:23

一、计划测试工作
测试计划是指工作中会遇到的最基本测试文档。
1.测试计划的目的
规定测试活动的范围、方法、资源和进度;明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人,以及与计划相关的风险。

测试计划只是创建详细计划过程的一个副产品,重要的是计划过程,而不是产生的结果文档。
测试计划过程的最终目标是交流(而不是记录)软件测试小组的意图、期望,以及对将要执行的测试任务的理解。
二、编写和跟踪测试用例

1.测试用例计划的目标
有条不紊地仔细计划测试用例的重要性:

  • 组织:正确的计划会组织好的测试用例,以便于项目小组有效地审查和使用。
  • 重复性:假如没有正确的计划,就不可能知道最后执行哪个测试用例及其执行情况,以便重复原有的测试。
  • 跟踪:
  • 测试(或者不测试)正式

2.测试用例计划综述
(1)测试设计
整体项目计划在非常高的等级上编制,它吧软件拆分为具体特性和可测试项。而测试设计说明的目的是组织和描述针对具体特性需要进行的测试。以下是测试设计说明的部分内容:

  • 标识符
  • 要测试的特性:测试设计说明所包含的软件特性描述,还明确指出作为主要特性的辅助特性需要间接测试的特性;还要列出不被测试的特性,即计划中由于错误分析包含进来的特性。
  • 方法:描述测试软件特性的通用方法。
  • 测试用例确认:对用于检查特性的具体测试用例的高级描述和引用。该部分不定义师姐测试用例值。
  • 通过/失败规则:描述测试特性的通过和失败又什么构成。

(2)测试用例
IEEE 829标准称测试用例说明为:编写用于输入的实际数值和预期输出结果数值。测试用例还明确指出使用具体测试用例产生的 测试程序的任何限制。其包含的重要信息:

  • 标识符: 又测试设计过程说明和测试程序说明引用的唯一标识符。
  • 测试项:描述被测试的详细特性、代码模块等,应该比测试设计说明中的特性更加具体。
  • 输入说明:列举送到软件执行测试用例的所有输入内容或者条件
  • 输出说明:描述进行测试用例预期的结果。
  • 环境要求
  • 特殊过程要求:描述执行测试必须做到的特殊要求
  • 用例之间的依赖性

(3)测试程序
IEEE 829 标准称测试程序为:明确指出为实现相关测试设计而操作软件系统和实验具体测试用例的全部步骤。详细定义了执行测试用例的每一步操作,以下是需定义的内容:

  • 标识符:把测试程序与相关测试用例和测试设计绑在一起的唯一标识符
  • 目的:程序的目的以及执行的测试用例的引用信息
  • 特殊要求
  • 程序步骤:日志、设置、启动、程序、度量、关闭、重启、终止、重置、偶然事件

3.测试用例组织和跟踪
管理和跟踪基本上有四种:

  • 凭脑子记:绝对不要采用,除非软件只限于个人使用,不需要跟踪测试
  • 书面文档
  • 电子表格:是非常奏效的流行方法
  • 自定义数据库:理想的方法是使用测试用例管理工具

三、报告发现的问题
1.报告软件缺陷的基本原则
- 尽快报告软件缺陷:软件缺陷发现的越早,在进度中留下的修复时间就越多。
- 有效描述软件缺陷:短小(只解释事实和演示、描述软件缺陷必须的细节),单一(每一个报告纸针对于一个软件缺陷),快速技巧提示(当出现疑问时,单个报告软件缺陷),明显并通用(用使用者容易看懂的、简单易行步骤描述软件缺陷的,修复的机会大),可再现(按照预定步骤可以使软件达到缺陷再次出现的相同状况)
- 在报告软件缺陷时不要做评价
- 对软件缺陷报告跟踪到底

2.软件缺陷的地位
测试员要对软件缺陷进行分类,以简明扼要的方式指出其影响,常用方法是划分严重性和优先级。严重性表示软件缺陷的恶劣程度,优先级表示修复软件缺陷的重要程度和紧迫程度。
3.软件缺陷的生命周期
缺陷生命周期
打开状态:软件缺陷被测试员发现,记录报告并指定程序员修复。
解决状态:程序员修复代码
审查状态:项目经理或者委员会决定软件缺陷是否应该修复。
关闭状态:修复缺陷完成或者审查决定不修复缺陷,都会进入关闭状态
推迟状态:审查可能认定缺陷应该在将来的某一时间考虑修复,但是在该软件版本中不修复。

原创粉丝点击