我对软件测试中的每个人都有三个词：优先级、优先级和优先级。
您无法测试软件的所有可能组合，尤其是 API 和 IoT 设备，您将大部分用户体验交由核心产品和服务的集成商处理。你就是做不到，所以我们现在应该举手放弃，对吧？
无论如何，您是哪种测试人员？
我不是;充其量我是一名自动化工程师。我几乎没有全职、敬业的测试专业人员所需的头脑或耐心。但我每天都和他们以及很多其他人交谈，我内心深处仍然是一名开发人员，所以我对参与软件交付过程的每个人都很亲切。
您不必成为测试人员也能理解作为人的局限性。人类会犯错误，每天只有那么多时间。开始体验左移测试职责的开发人员可能会确保对所有功能和过程进行单元测试，但通常不会走得更远，仅仅是因为时间不够。人手不够，时间不够……我经常听到两件事，这也是我与 Ready 一起从事自动化测试工具业务的部分原因！应用程序接口 。
旁注：我还想借此机会说“ 没有预算 ”和“不是优先事项”是不投资于更美好未来的最糟糕的理由，自动化让你有时间构建更好的软件，并获得您的交付管道权对于快速迭代向前发展至关重要。
但我们不应该总是测试更多吗？
不，嗯，是的。实际上，有点但并非总是如此。引入更多测试的回报递减的一个方面是，如果您不优先测试最关键的业务组件和工作流，那么作为专业测试人员，您的工作、业务和您自己都会失败。
我们可以简单地测试一切，我们只是没有时间，我们还需要保持敏捷。如果我是一名测试人员，我可能会因为想要确认我被告知要从事的工作在此时此刻以最有影响力的方式实际影响业务的底线而被解雇。我不会坐在那里创建测试，以便我们可以报告我们今天有 79% 而不是 78% 的测试覆盖率。我希望看到投资回报率，即使显然“ 软件测试中没有投资回报率 ”。
所有的新东西都不应该被测试吗？
在 7 月的 APIdays IoT San Francisco 2015 演讲后，我遇到了一个问题：“如果你不知道人们将如何组合你的设备和 API，你如何确保你已经测试了一切？”毫不客气地，这类问题凸显了物联网领域的不成熟。我们有一种非常年轻的创业文化（想想拥有多个博士学位的 20 多岁）解决大问题，最常见的是围绕数字世界如何以尽可能低的价格尽快将自己融入物理世界。
会有一些破碎的东西，不完整的想法，以及绝对可以从中吸取教训的失败。在 APIdays 之后的一周 ，我也在 O'Reilly Solid 上亲眼看到了这一点 。演讲者都是经验丰富的行业领导者，很高兴这些人在舞台上与年轻的工程师交谈，他们在不考虑协议或集成标准的情况下构建各种物联网设备。平均展位赞助商是研究生院的天才，他们实际上是 DevOps 的本地人，正在建设我们的未来……如此忙于实施，他们甚至可能不知道问更重要的问题，“我们应该”？
你对初创公司有什么看法？
没有什么私人的，我自己也参与过一些。 “初创企业的孩子们”正在非常努力地工作，比我以前工作的要努力得多，以便在我们为自己建立的竞争激烈的技术市场上取得成功或打破它。当我说“孩子”时，我的意思是比喻；为初创公司带来各种背景、技能和经验的人，在事情锁定并开始运转之前，仍然经常需要学习很多关于运行精益操作的知识。
有些事情需要时间来学习（多亏了我们的蜥蜴脑），我们（技术行业）最好记住，人们在接受和正确利用新技术方面仍然天生很慢（例如， 轻量级 的行业采用速度缓慢但不断增加） 服务虚拟化 工具）。
如果有一件事我会质疑与创业文化有关，那就是当你忙于加速而没有时间问“我们应该吗？”时，一些重要的角落可能会被砍掉。例如，API 安全现在是一个 大问题 ，因为过去几年发生了许多非常公开的 API 安全故障。 Moonpig、Uber、Tinder 和其他公司本可以通过将 免费知识 应用到他们的设计中来避免这种情况。
你的软件越接近金钱和安全，风险就越大，就像在 金融 和医疗机构中，或者更糟糕的是 国防 和航空旅行；主动识别关键服务的漏洞是进行监管审计的根本原因，并防止创业文化思维引入的安全疏漏对普通数字公民的日常生活产生巨大的负面影响。
那我怎么知道什么时候测试够了呢？
这取决于你，是你的软件，是你的客户和他们的期望，它们应该帮助你知道什么时候适可而止。在没有正式的用户体验和运营指标的情况下，您可能需要从您的技术团队开始设定一些目标。您还应该直接与您的消费者交谈，获得他们对您的软件的期望的反馈和意见。
如果您想了解一般的测试，请阅读一些 James Bach 或 Michael Bolton 的 书籍，但是当涉及到 SLA 和向管理层报告等细节时，有一些关于质量的非常具体的问题要问。例如，关于测试物联网和其他倍数设计复杂性（如微服务、超媒体等）的一组稍微成熟的问题可能包括：
- 我的目标应该是测试所有事物和排列吗？
- 用户体验指标如何说明我的客户将什么视为优先事项？
- 哪些技术疏忽导致了我们最严重的业务赤字？
- 我是否需要在此时此刻构建/测试/发布它？
- 通过运送我们拥有的东西，我们会得到什么和/或失去什么？
好的，所以我不必测试更多？
我们不都希望吗？对不起，不，这不是免费的午餐。是的，你应该进行更多的测试，几乎是普遍的。大多数软件供应商和工程师都知道，自动化测试是通过较少人工干预实现高质量的唯一途径，但还没有看到缺乏适当测试所带来的痛苦。
优秀的工程师和技术人员有良心，知道什么时候需要更多关注，这就是为什么我让你来回答“我需要多少测试？”这个问题。您不需要内心的声音告诉您需要测试和监控只有您知道如果出现任何时间故障都会削弱您的业务的东西。所以在那一刻，我谦虚地向你提出，如果你看到或感受到未来的痛苦，那么你有责任编写测试，或者至少将其放在优先级积压中，或者你的团队肯定会跟进的事情.
通常积压的是“测试覆盖率”，这是一种有用的评估工具，但也只是一种广谱方法，可以了解软件交付中的技术差距。它可以帮助您了解何时在没有适当的团队沟通的情况下实施新事物，但它本身不应成为目标。您的客户最后一次说“如果您的测试覆盖率达不到 82%，我就不想使用您的软件”是什么时候？正确的。大多数消费者关心不良软件的下游影响，例如应用程序崩溃，而不是您为防止错误进入生产所做的事情。报道不是黄金偶像，它只是一种评估你的弱点所在的方法。
与安全测试一样，测试覆盖率只是衡量准备情况的一个方面，它应该是以客户为中心的软件质量的更大视角的一部分。测试和客户价值之间的联系体现在其他领域，如 Beta 验收测试、 性能监控 和消费者反馈。当我们需要时，它就在那里。
这是我测试“所有事物”的经验，但你的是什么？我很想听听你的想法。