我们不再需要对用户做出错误的假设。

当我们测试时，想法总是要找到所有问题，但其实我们只需要关注那些会影响我们用户的问题就可以。

“如果一棵树在一片空旷的森林上，当风吹过时，它会发出声音吗？”这样的问题在测试环境中很简单......但是如果有一个没有人会遇到过这样的错误，那么我们就应该不关心这个错误了！

但生活从来都不简单，所以问题通常是：

我们怎么知道这个问题对我们的用户是否重要？

许多年前，这是一个非常难回答的问题。

N年前，过去我们常常使用安装在台式机或与服务器隔离光盘来提供软件服务，因此很难从用户那里获得直接反馈。

我们会从支持团队获取错误列表，产品经理会谈论功能需求，如果我们真的幸运的话，我们会听取专业服务团队关于人们如何部署系统以及使用的信息。

在那些日子里，我们会对系统的功能做出假设，生成测试用例，建立人物角色，当我们不同意错误的优先级时进行分类分析，并总体上祈求能够得到最好的结果

今天，我们大多数人都可以看到我们的最终用户如何使用我们的系统。

我们经历了两次非常重要的互联网演变，完全改变了这一现实。

第一个是技术问题 - 云计算。

今天，我们许多人都能够将产品发布到云端，而不是将它们发送给我们的用户。这意味着我们够监控最终用户实际使用我们系统的方式。

这获取听起来微不足道，但如果您的公司正常运作并且在设计新产品时考虑了这一诉求，如果他们遇到任何异常，错误或障碍时，我们就可以用track系统来跟踪用户正在执行的操作，他们在哪里使用哪些功能（以及哪些功能很少或者根本没有被人使用），

这几乎就相当于让你在你的用户后面坐着，看看他们如何使用你的系统。 过去通常在现场访问调查或在我们公司拥有昂贵的可用性实验室来做的事情。

第二个是方法论 - DevOps。

一旦我们开始在云中工作并在我们自己的服务器集群中部署我们的应用程序，最好的开发者可以在生产中环境中快速部署部署和管理系统，而这些人通常也在编写这些系统。

唯一的问题是开发人员缺乏如何大规模管理运营系统以及多个服务器和服务并行交互的知识。

长话短说......我们将我们的敏捷开发团队与我们的云运营团队合并在一起，我们获得了DevOPS的新概念。

DevOps还意味着，与我们的敏捷开发团队合并我们的Ops团队，我们还将测试专家注入这些团队，因此我们可以在部署“事件”发生之前和之后开始合并我们的测试操作。

您可以停止对用户正在做什么做出假设，只需查看和学习

这与用户和配置文件有什么关系，希望你现在明白它与它有关。

如果我们不得不对系统中最常用的功使用模式做出假设，那么现在我们可以简单地查询我们的监控系统以获取这些信息。

如果您有真实的用户数据库，现在可以为您的团队创建更符合用户实际行为操作的角色。

也许最重要的是，如果我们只能根据发布日期后，团队的3或6个月缺陷率来衡量发布系统的质量。 实际上我们无法获得有关系统中问题的实时反馈，但现在我只需要通过hot-fix，在用户没有任何感知的情况下 快速的修复线上问题。

质量不仅仅是没有错误

更好的是，我们现在可以为系统的质量添加新的维度！ 我们现在可以看到用户是否正在是否使用我们希望它们用的功能。

例如，如果您的团队在新的报告模块上工作了几个月，但用户并不使用它，那么您就知道遇到了怎样的问题。 它可能是UX问题，或功能定义问题，或完全不同的东西。 但事实上，你投入了大量的时间与精力，并没有得到你想要的结果，他并不是系统的功能上的错误，但确确实实是你的系统存在所谓的“质量问题”。

几年前，我们需要等待数月才能获得有关功能的反馈。 今天我们可以在几小时或几天内得到快速反馈。

DevOps和cloud还有很多其他积极的方面......

事实上通过devops与云服务您可以获得与生产环境相似或相同的环境进行测试，以及更多的事情。

关于更多的相关信息 我将在别的文章中说明

我的个人主页：qaseven.cn