是否有针对项目的单一测试方法的标准流程和模式？

Question

问:在我是唯一的测试人员的项目中，我需要关于如何最好地进行测试的建议。

是否有每个测试人员都应该遵循的标准流程？

是否每个测试人员都应该遵循特定的模式？

背景

• 目前，我正在一个新的项目中工作，在那里我是我公司唯一的测试人员。
• 我知道用selenium编写测试用例、自动化测试、与开发和业务分析师资源进行通信。
• 我有客户提供的要求
• 我只手动准备和执行测试用例，然后自动化特定的测试用例。

Answer 1

按顺序：

1. 首先学习业务领域和流程。
2. 手动测试快乐路径
3. 手动测试悲伤的路径
4. 自动实现幸福之路
5. 手动测试可选路径
6. 单元测试
7. 使悲伤的道路自动化
8. 自动化可选路径
9. 手动测试浏览器/设备
10. 性能和负载测试
11. 使浏览器/设备自动化

Answer 2

我开始工作，但与利益相关者，以建立共同的理解范围的测试活动。为此，我使用了IEEE 829主测试计划的精简版本。这样做的目的是从涉众那里获取尽可能多的信息，而不必创建一个没有意义的详细文档(很有可能其他人不会真正阅读它)。

我在整个项目中不断更新这个计划。即使有一个标志，我保留该版本，并继续更新一个新的副本，因为我走。我使用它作为一张地图，并测量进度和识别范围爬行整个项目。

Introduction

测试项目

• 清楚地确定您所关注的事物；以及那些依赖关系或受影响但不会成为您的焦点的事物。
• 重要的是，每个人都同意在被测试的系统周围划清界线。

特性有待测试的

• 范围内每个特性的简单列表。它不需要是系统的每一个特性，仅仅是在这一轮测试/通常是所有新特性中重要的特性。

特性无需测试

• 通常，在项目开始时，这将是空的，但是，由于那些被认为是太困难和低价值的东西可能会在这里添加。

风险失效模式

• 不是在IEEE 829中，我添加它是为了确定优先级。在这里，我创建了一张关于失败模式和可能原因的思维图。

逼近

• 在本节中，描述您计划进行的测试和任务的种类。这个点的探索性测试，那个点的自动化。建立一个专门的框架来管理bits、D和E等。
• 准确的妆容将取决于你测试的内容。我的建议，如果你已经承诺，是欠承诺和超额交付。

…

根据项目的具体情况、环境要求、计划、测试完成标准等，挑选和选择下一个IEEE 829标题。

然后创建一系列测试任务来处理特性和预期的失败模式。我不试图用一个单独的测试用例来处理每个特性。根据我的经验，事情发展得很快，试图做到这一点，而且常常花上几天时间在旧新闻上写笔记。

如果您在sprint中工作，那么在待办事项中添加一些测试任务，这些任务是有意义的。还计划时间来回顾开发小组正在编写的故事，并处理可能出现的任何bug。

Answer 3

作为公司里唯一的测试者，我和你自己处于相似的地位。

在接近一个项目的测试方面，我的建议是找到一种对您和您的公司最有效的方法/过程，因为每个公司/测试人员是不同的。

用不同的方法进行实验，看看哪种方法最有效。我过去使用过的方法是：

• 遵循ISO/ISEE标准的测试计划
• 心境图
• 检查清单

每一次会议都是从了解范围和相关利益攸关方的情况开始的。从这些对话中，我了解到发行版所需要的不仅仅是功能测试(即确保其正常工作，确保现有功能仍然有效(回归))，还包括非功能性(性能、安全性、可用性)。

根据公司的工作方式，您可以将其细分为特性/需求:对于每个功能/需求：

• 它能正常工作吗？
• 与其集成的现有功能是否按其应有的方式工作？
• 它能表演吗？
• 安全吗？
• 它有用吗？等

然后，这是一个决定什么是自动的，什么不是按照上面的方法。我通常遵循基于技术和业务风险的基于风险的测试策略。

严重性=业务影响(高、中、低)概率=技术/可测试风险(高、中、低)

这形成了一个矩阵，并帮助我决定优先级，什么是自动化和其他决策的重要内容。

最重要的是总是有一个每个人都能达成一致的完成/发布标准的定义--干系人、开发人员、测试人员等等。总有很多东西需要测试，新的和富有想象力的发现缺陷的方法等等，所以这对于帮助知道何时完成非常重要，并且通过让每个人达成一致，它帮助大家一起来帮助发布一个版本。

希望能帮上忙？