想象一下，您正在设计一个系统，并且您想开始编写确定功能的测试 - 以及性能和可伸缩性。您是否可以分享任何技术来处理不同环境中的大量数据？
问问题
2216 次
5 回答
2
我强烈建议在进行性能和可伸缩性测试之前优先考虑功能测试（使用 TDD 作为您的开发工作流程）。TDD 将确保您的代码设计良好且松耦合，这将使创建自动化性能和可伸缩性的道路变得更加容易。当您的代码松散耦合时，您可以控制依赖项。当您可以控制依赖项时，您可以为要编写的任何高级测试创建所需的任何配置。
于 2011-05-24T17:09:31.077 回答
0
将不同类型的测试分开。
- 功能测试应该是第一位的，从少量的模拟数据开始单元测试。
- 接下来是集成测试，在数据存储中使用少量数据，尽管显然与具有大型数据集的存储不同。
- 您也许可以通过同时进行性能和可伸缩性测试来减少开发工作。
一个重要提示：您的测试数据集应尽可能真实。使用生产数据，必要时匿名。因为大数据性能取决于数据中的统计分布，所以您不想使用合成数据。例如，如果您使用一百万次基本上具有相同用户信息的虚假用户数据，您将获得非常不同的可扩展性结果，而不是具有广泛分布的值的真实用户数据。
如需更具体的建议，我需要了解您使用的技术。在 Hadoop 中，查看 MRUnit。对于 RDB，DBUnit。Apache Bigtop 可以提供灵感，尽管它针对的是 Hadoop 上的核心项目，而不是特定的应用程序级项目。
于 2014-11-12T15:14:39.467 回答
0
我遇到过两种情况：
用作其他应用程序的数据仓库或数据接收器的大型 HDFS 数据集
具有 HBASE 或其他分布式数据库的应用程序
两种情况下的单元测试提示：-
一个。先测试应用的不同功能组件，大数据应用没有特殊规定；就像任何其他应用程序一样，单元测试应该确定应用程序上的不同组件是否按预期工作；然后你可以集成功能/服务/组件等来做 SIT，如果适用的话
湾。具体来说，如果有 HBASE 或任何其他分布式数据库，请测试对 DB 的要求。例如，分布式数据库通常不像传统数据库那样支持 ACID 属性，而是受到称为 CAP 定理（一致性、可用性、分区容限）的限制；通常保证 3 个中有 2 个。对于大多数 RDBMS，它是 CA，通常对于 HBASE，它是 CP 和 Cassandra AP。作为设计人员或测试计划人员，您应该根据您的应用程序特性了解分布式数据库的 CAP 约束，并据此创建测试计划以检查实际情况
关于性能 - 很大程度上取决于基础设施和应用程序设计。有时某些软件实现比其他实现更费力。例如，您可以检查分区的数量，它基于所有大小写
关于可扩展性——与传统架构相比，大数据实现的最大优势在于它易于扩展。我从未认为这是可测试的。对于大多数大数据应用程序，您可以轻松扩展，尤其是水平扩展非常容易，因此不确定是否有人考虑测试大多数应用程序的可扩展性。
于 2014-11-16T03:41:17.377 回答
0
做一些功能测试。考虑一些风险管理技术参考这篇文章如何处理大数据中的风险管理这将对您有所帮助。
于 2014-10-08T07:56:18.000 回答
-1
为了测试和测量性能，您可以使用静态数据源和输入（可能是巨大的转储文件或 sqlite DB）。
您可以创建测试并将其包含在您的集成构建中，以便特定函数调用需要超过 X 秒，抛出错误。
随着您构建更多系统，您将看到该数字增加并破坏您的测试。
你可以花 20% 的时间来获得 80% 的功能，剩下的 80% 用于性能和可扩展性 :)
可扩展性 - 考虑面向服务的架构，这样您就可以在两者之间使用负载均衡器，并且您可以通过简单地向系统添加新硬件/服务来增加您的状态/处理
于 2011-05-24T13:14:08.043 回答