想象一下，您正在设计一个系统，并且您希望开始编写确定功能的测试 - 还有性能和可伸缩性。您是否可以共享任何技术来处理不同环境中的大量数据？
答案 0 :(得分：2)
我强烈建议在进行性能和可伸缩性测试之前优先考虑功能测试（使用TDD作为开发工作流）。 TDD将确保您的代码设计良好且松散耦合，这将使得创建自动化性能和可伸缩性变得更加容易。当您的代码松散耦合时，您可以控制依赖项。当您可以控制依赖项时，可以为要编写的任何高级测试创建所需的任何配置。
答案 1 :(得分：0)
做一些功能测试。考虑一下风险管理技巧，请参阅这篇文章How to handle risk Management in Big data这将对您有所帮助。
答案 2 :(得分：0)
分开不同类型的测试。
一个重要提示：您的测试数据集应尽可能真实。使用生产数据，根据需要进行匿名化。由于大数据性能取决于数据中的统计分布，因此您不希望使用合成数据。例如，如果您使用的虚假用户数据基本上具有相同的用户信息一百万次，那么您将获得非常不同的可伸缩性结果，而不是具有广泛值的实际杂乱的用户数据。
有关更具体的建议，我需要了解您正在使用的技术。在Hadoop中，查看MRUnit。对于RDB，DBUnit。 Apache Bigtop可以提供灵感，虽然它针对的是Hadoop上的核心项目而不是特定的应用程序级项目。
答案 3 :(得分：0)
我遇到过两种情况：
用作其他应用程序的数据仓库或数据接收器的大型HDFS数据集
使用HBASE或其他分布式数据库的应用
两种情况下的单元测试提示： -
一个。首先测试应用程序的不同功能组件，对大数据应用程序没有特殊规则;就像任何其他应用程序一样，单元测试应该确定应用程序上的不同组件是否按预期工作;那么你可以整合功能/服务/组件等来做SIT（如适用）
湾特别是如果有HBASE或任何其他分布式数据库，请测试数据库需要什么。对于例如分布式数据库通常不支持像传统数据库那样的ACID属性，而是受限于称为CAP定理（一致性，可用性，分区容差）的东西;通常有3个中有2个有保证。对于大多数RDBMS，它是CA，通常对于HBASE，它是CP和Cassandra AP。作为设计人员或测试计划员，您应该知道，根据您的应用程序功能，哪些是您的分布式数据库的CAP约束，并相应地创建测试计划以检查实际情况
关于性能 - 再次很大程度上取决于基础架构和应用程序设计。有时某些s / w实现比其他实现更加繁重。您可以检查分区数量，例如，所有基于案例的
关于可扩展性 - 与传统架构相比，大数据实现的优势在于它易于扩展。我从未想过这是可测试的。对于大多数大数据应用程序，您可以轻松扩展，特别是水平扩展非常容易，因此不确定是否有人考虑测试大多数应用程序的可伸缩性。
答案 4 :(得分：-1)
为了测试和测量性能，您可以使用静态数据源和输入（可能是巨大的转储文件或sqlite DB）。
您可以创建测试并将其包含在您的集成构建中，以便特定的函数调用花费超过X秒，抛出错误。
随着您构建更多系统，您将看到该数字增加并打破您的测试。
你可以花20％的时间来获得80％的功能，剩下的80％用于提高性能和可扩展性：）
可扩展性 - 考虑面向服务的架构，以便您可以在两者之间安装负载均衡器，只需在系统中添加新硬件/服务即可增加状态/处理