如何将软件测试从零提升到一个大约六年的开发代码基础和一个没有实际知识的团队中？

Question

去年我在这里问了一个(删除的)问题，在反馈中，有人告诉我，做软件测试并不容易。我们可能会为协议找到准备好的测试用例，但在大多数情况下，测试是基于需求的，而且其中大多数都是独特的。

今天，我为一位学生准备了一篇论文，主题是自动化测试(测量技术，而不是软件测试)，但我也找到了标准化测试信息交换网站。

这告诉我，确实有一些意图，以某种方式标准化软件测试。

因此，我感兴趣的是，如果以前没有自动化软件测试解决方案阻止自由的工程决策，那么在软件开发中应用哪种自动化测试技术、标准、最佳实践shell才能长期保持可维护的过程。

本问题中提到的原址案文如下：

互操作性--标准化的测试信息交换--您是否尝试过从一个自动化测试工具切换到另一个测试工具，但是由于您已经花费了太多的时间和太多使用旧解决方案存在的自动化测试用例，所以决定不采取行动？目前已有数以百计的自动化软件测试工具解决方案，每个解决方案都为自动化测试用例提供了自己的开发语言。一个工具可能使用VBScript；另一个工具可能使用专有脚本语言；而另一个工具可能允许您从多种编程语言中选择创建自动化测试用例。在自动化测试工具社区中，这种自动化测试用例开发的非标准化方法的挑战是，自动化测试解决方案之间没有互操作性，也没有数据交换能力。如果您想从工具A切换到工具B，您必须在tool B中重新创建所有测试；不存在自动化此过程的标准化方法。为了解决这一和其他互操作性挑战，我们IDT和其他公司一起，提出了OMG (www.omg.org)的一个标准，称为自动化软件系统软件测试过程的测试信息交换(简称TestIF)。该标准的目标是实现一个规范，该规范定义了在工具、应用程序和使用它的系统之间交换测试信息的格式。术语“测试信息”是有意模糊的，因为它包括测试(测试用例)、测试结果、测试脚本、测试过程以及通常作为软件测试工作的一部分记录的其他项的概念。长期目标是标准化作为测试过程一部分的所有与测试相关的工件的交换。

Answer 1

我认为“加强测试”与其说是一个目标，不如说是一个子目标。所有测试的实际目标是降低风险。

为了减轻风险，你需要知道这些风险是什么。因此，第一步是风险评估过程，这通常会产生一个风险矩阵。我会召集一群关键的利益相关者，有经验的技术人员和头脑风暴的这些风险可能是什么，在一定程度上基于您的历史与软件，以及有多好的发布。

对于每一种风险，企业将决定其影响(例如，“系统崩溃”的风险可能是财务或声誉损失)，并分配一个分数(通常为1-5)。同时，技术队将决定概率，也是从1比5得分.然后，将这两个因素相乘并按产品进行排序，以获得风险的强制排序(即优先级)。

那么，对于每一个风险，你必须有一个缓解策略。许多风险将通过某种类型的测试来减轻--功能测试、性能测试、失败模式测试、集成测试、数据迁移测试、渗透测试等等。然后，团队必须制定一个测试计划，为涉众提供风险减轻的信心。

其中一个关键的风险通常是“软件质量不高”或类似的东西。质量保证减轻了这一具体风险。

为了有秩序地进行质量保证，您必须开发质量度量。如果您是从零开始，我建议从现有的代码库和缺陷跟踪系统中收集数据，以便建立一个基线；例如，您可能在最近的五个版本中发现，平均有一个sev1缺陷和10个sev 2。然后，您可以为零sev1和小于5 sev2设定一个目标，诸如此类。然后，开发团队和QA团队将需要制定一个计划来实现这一目标。

开发团队可以通过代码评审、自动化单元测试、手动单元测试、对编码和其他技术来提高质量。对于每一个目标，都可以设定目标，例如，对于自动化单元测试，您可以确定在某一特定日期前需要80%的代码覆盖率。QA团队可以使用自动或手动的烟雾和功能测试。您可能有专门的资源来设置性能和压力测试。QA和开发负责人应该建立一个持续测试、测量和报告的过程。

这些测试方法标准吗？说大也大吧。每种测试的术语和一般技术都或多或少是一致的。然而，每种类型的测试的优先级将根据您的风险区域的位置以及您对它们的排序而有所不同。有些软件会完全跳过某些测试--例如，您可能不会在内部应用程序上进行某些类型的安全测试--而其他测试可能具有更高的优先级--例如，在高性能的24/7应用程序上测试系统稳定性。这些选择和决策将是特定于业务和产品的，就像所有业务决策一样，都受到资源可用性、预算和时间限制的限制。一个尺码并不适合所有的尺寸。