软件测试自动化文档

Question

在描述软件测试自动化(在任何阶段、自动化计划、测试设计、实现、报告)时，可以使用什么文档类型？有任何标准类型的文件吗？是否有人可以为不同类型的文档提供任何示例和模板？手工测试文档和自动化测试文档有什么区别？

Answer 1

以下是我的建议：

1.试验战略文件：

这概述了所有测试目标，哪些测试目标存在，以及如何执行全面测试，连接从单元测试、组件测试、系统测试和集成测试到的所有级别。这不是一个标准或什么-但它可以是某种程度上的这类。

2.试衣：

这是测试用例和条件的集合，这些测试用例和条件是关于何时以及如何执行每个用例的。针对每个元素的每一组输入、过程和预期输出行为。有时，不仅仅是成功和失败被注意到，因此对此做了进一步的分析。

3.测试环境/设置和程序

如果您正在完全或部分地自动化测试过程，那么应该记录一下测试的(各种元素)将如何准确地执行。如果这里执行的测试方法是否正确，就应该进行辩论和验证。相关的开发人员和QA应该知道如何操作一组工具和遵循哪些过程。

4.可追溯性矩阵：

这是一个定义良好的矩阵，它确定哪些测试用例集是相关的，以保证每个功能点都是稳定的。在这里读更多或这个维基链接。每当发现新的bug或请求新特性时，都应该更新可跟踪矩阵以捕获这些更改。

5.测试结果

无论是自动生成还是手动执行，结果(详细和汇总)都应该在测试执行表中捕获。最重要的是，应该捕获原始的观察结果(如日志、应用程序的实际输出)，以便能够验证结论。文档需要捕获这些测试所针对的构建；不同的构建可能不会针对相同的测试产生相同的行为。

程序和格式可以根据需要制定。最重要的是，根据我个人的经验，不让水严格遵守某种格式，而是允许人们像日志一样记录这件事，只做一些强制性的事情，让人们自由地输入更多的信息。测试从来都不是静态的(至少对于任何相当复杂的项目)，因此随着时间的推移，所有这些模板都必须不断发展--通常下一步可能是与最后一步的重大背离。如果模板过时了，或者人们不这么做，因为它太僵化了，那么最终，通过测试过程获得的大部分相关知识将不会得到正确的反映。

Answer 2

答案在很大程度上取决于软件做什么，如何设计，甚至取决于软件将应用于哪个行业。一些行业对测试文件和验证有着非常广泛的监管要求，例如FDA CFR 21在制药和生物技术行业的第11部分。

此外，请考虑，即使您的组织会虔诚地遵循所有相关的IEEE测试文档标准，例如：

• IEEE 829:软件测试文档
• IEEE 1008:单元测试
• IEEE 1012:软件验证和验证
• IEEE 1028:软件检查
• IEEE 1044:软件异常的分类

有大量直接和间接相关的文档和标准您也应该定义和使用，例如：

• IEEE 830:系统要求规范
• IEEE 730:软件质量保证计划
• IEEE 1061:软件质量度量和方法
• IEEE 12207:软件生命周期过程和生命周期数据

如果所有这些IE3标准看起来都是不可逾越的--特别是对于较小的组织和团队--那么请看一看软件工程知识体系，它不那么“科学”，更简洁。

最后，在某种程度上，使用ALM工具来保存测试的电子记录而不是正式的文档是一个非常有效的选择，只要您有定义标准化使用的过程。

Answer 3

你看过IEEE829-1998，软件测试文档标准吗？我知道在我的公司，这个标准中的测试文档被用来描述整个测试策略。例如，主测试计划实际上将在“方法”部分中包含有关测试自动化的信息。