架构师需要掌握的:软件测试(4)

本篇文章主要介绍如何使软件测试文档化，使测试的计划，测试缺陷，测试结果对项目团队中每个成员都可见，且能理解。包括计划测试工作，编写和跟踪测试用例，报告发现的问题和成效评价。

计划测试工作

利用精心组织的测试计划，测试用例和测试报告，对测试工作进行正确的记录以及交流，将使达成目标变得更有可能。如果程序员编写代码而不说明它干什么，如何工作，何时完成，执行测试任务就很困难了。同样，如果测试员之间不交流计划测试的对象，需要什么资源，进度如何安排，整个项目就很难成功。软件测试计划是软件测试员与产品开发小组交流意图的主要方式。

软件测试计划的目的：规定测试活动的范围，方法，资源和进度；明确正在测试的项目，要测试的特性，要执行的测试任务，每个任务的责任人，以及与计划相关的风险。

测试计划只是创建详细计划过程的一个副产品，重要的是计划过程，而不是产生的结果文档。关键点在于制订过程中交流（而不是记录）软件测试小组的意图，期望，以及对将要执行的测试任务的理解，避免将撰写的测试计划称为束之高阁的文档（shelfware）。测试计划应包含以下内容：

1. 高级期望：目的是什么，测试的是什么产品（包含数量和适用范围），质量和可靠性目标是什么。

2. 明确在项目中的人，地点和事。项目中工作的人干什么，怎样和他联系。文档存放在哪里，如何获取。

3. 软件项目中定义的用词和术语。例如什么是Alpha，Beta版本。

4. 团队之间的责任。

5. 哪些要测试，哪些不要测试。

6. 测试的阶段。测试的计划过程应该明确每一个预定的测试阶段，并告知项目小组，该过程一般有助于整个小组形成和了解全部开发模式。并且测试阶段要有明确的进入和退出规则。假如没有明显的进入和退出规则，测试工作就会变成单一的，且毫无头绪的工作，很像边写边改开发模式。

7. 测试策略：它描述测试小组用于测试整体和每个阶段的方法。例如使用黑盒测试还是白盒测试，何时运用；采用手工还是使用工具和自动化测试等。

8. 资源需求：包括人员，设备，办公室和实验室空间，软件，外包测试公司，其他设备。

9. 测试员的任务分配：明确各测试员负责软件的哪些部分，哪些课测试特性。每个测试元都会清楚地知道自己负责什么，而且有足够的信息开始设计测试用例。

10. 测试进度：测试进度受到项目中先前事件的影响会较大。为了避免进度破坏（schedule crunch）。使测试任务摆脱进度破坏的一个方法是测试进度避免定死启动和停止任务的日期。相反，如果测试进度跟进测试阶段定义的进入和图此处规则采用相对日期，那么显然测试任务依赖于其他先完成的可交付内容。

11. 测试用例：测试计划过程中决定用什么方法编写测试用例，在哪里保存测试用例，如何使用和维护测试用例。

12. 软件缺陷报告：在计划阶段明确如何跟踪软件缺陷，避免跟踪缺漏或者不及时。

13. 度量和统计：跟踪项目进展，成效和测试质量。计划过程应用明确手机哪些信息，要做什么决定，由谁来负责收集。

14. 风险和问题：指出项目的潜在问题或者风险区域。

编写和跟踪测试用例

测试用例计划的目标：

1. 组织：测试用例的建立可能需要耗费几个月的时间。正确的计划会组织好用例，以便全体测试员和其他项目小组成员有效地审查和使用。

2. 重复性：项目过程中会有必要多次执行相同的测试。

3. 跟踪：计划执行多少个测试用例，多少个执行通过的，多少个失败。

4. 测试（不测试）证实：在少数高风险行业中，软件测试小组必须证明确实执行了计划执行的测试。发布忽略某些测试用例的软件实际上是不合法和危险的。

报告发现的问题

报告发现的问题也是一件艰巨的任务，包括：

1. 为什么所有软件缺陷不一定都能修复。包括没有足够的时间，不算真正的软件缺陷，修复的风险太大，不值得修复，无效的软件缺陷修复报告。

2. 软件缺陷有严重性（severity）和修复的优先级（priority）。

3. 软件缺陷的生命周期一般包括：打开状态（open），解决状态（resolved），关闭状态（closed）。

成效评价

通过使用软件缺陷跟踪数据库中的信息，可以进行查询，指出发现的软件缺陷类型，发现软件缺陷的速度，以及多少软件缺陷已经得到了修复。测试经理或者项目经理可以看出数据中是否有趋势显示需要增加测试的区域，或者项目是否脱离计划发布日期的轨道。

从"大老板"的角度考虑：软件项目进展正常吗？能够准备好如期发布吗？假如超过日期期限又什么风险？整体可靠性如何？

从整个项目角度看，质量和可靠性等级是多少？是否按照进度在进行？

使用数据来管理项目和团队。

参考：《软件测试》