This comes from a developer's perspective rather than a tester's, so it may or may not apply.
I can't speak for the organization as a whole, but in our project we have spent some time creating "real-world-like" data that we load into the test database using SQL scripts. This data is a combination of real data from the production environment and data that is tailored to represent specific "problem situations" in our product.
The scripts are run automatically as part of building our software and are used by automated integration tests, driven by a unit testing framework. These tests will test finding, creating, editing and deleting data through various interfaces that are available.
During such a build and test run the test database is reset and reloaded with data on a number of occasions. This is done in order to remove dependencies between tests; one test should not rely on data created or modified by another test, and also because the data for some tests might differ from that data of other tests. A majority of all tests are executed based on the same test data though.
Setting up this test data (and maintaining it) has been (and is sometimes) somewhat of a headache, but in the long run it has worked well in our case.
In most of same situation, Tester prefers to load test data using scripts cause not possible to load the data [time consueming] using UI part.And for tester key-point, each test should be perform on only single row data or whole db data. So for better testing follow way to make scripts to load data. and one more pont here, Make script is once time investment to load data for whole project.
In the end we decided to migrate from a system where data is setup via the front end to a data insert system. But keep an eye on the data to make sure it is real world. This has worked well and the tests run much faster.
I had the same problem with test data. In our organization, there is a batch job which populates the database with production like data. I co-ordinate with functional testers to get the testdata for my loadrunner scripts.
发布评论
评论（4）
这来自开发人员的角度而不是测试人员的角度，因此它可能适用也可能不适用。
我不能代表整个组织，但在我们的项目中，我们花了一些时间创建“类似真实世界”的数据，并使用 SQL 脚本将其加载到测试数据库中。 该数据是来自生产环境的真实数据和为代表我们产品中特定“问题情况”而定制的数据的组合。
这些脚本作为构建软件的一部分自动运行，并由单元测试框架驱动的自动化集成测试使用。 这些测试将测试通过各种可用的界面查找、创建、编辑和删除数据。
在此类构建和测试运行期间，测试数据库会多次重置并重新加载数据。 这样做是为了消除测试之间的依赖关系； 一个测试不应依赖于另一测试创建或修改的数据，而且还因为某些测试的数据可能与其他测试的数据不同。 不过，大多数测试都是基于相同的测试数据执行的。
设置此测试数据（并维护它）一直（有时）有些令人头痛，但从长远来看，它在我们的案例中效果很好。
This comes from a developer's perspective rather than a tester's, so it may or may not apply.
I can't speak for the organization as a whole, but in our project we have spent some time creating "real-world-like" data that we load into the test database using SQL scripts. This data is a combination of real data from the production environment and data that is tailored to represent specific "problem situations" in our product.
The scripts are run automatically as part of building our software and are used by automated integration tests, driven by a unit testing framework. These tests will test finding, creating, editing and deleting data through various interfaces that are available.
During such a build and test run the test database is reset and reloaded with data on a number of occasions. This is done in order to remove dependencies between tests; one test should not rely on data created or modified by another test, and also because the data for some tests might differ from that data of other tests. A majority of all tests are executed based on the same test data though.
Setting up this test data (and maintaining it) has been (and is sometimes) somewhat of a headache, but in the long run it has worked well in our case.
在大多数相同情况下，测试人员更喜欢使用脚本加载测试数据，因为不可能使用 UI 部分加载数据[耗时]。并且对于测试人员关键点，每个测试应该仅对单行数据或整个数据库数据执行。 因此，为了更好的测试，请遵循制作脚本来加载数据的方法。
这里还有一点，制作脚本是一次为整个项目加载数据的时间投入。
In most of same situation, Tester prefers to load test data using scripts cause not possible to load the data [time consueming] using UI part.And for tester key-point, each test should be perform on only single row data or whole db data. So for better testing follow way to make scripts to load data.
and one more pont here, Make script is once time investment to load data for whole project.
最后，我们决定从通过前端设置数据的系统迁移到数据插入系统。 但请密切关注数据以确保它是真实世界。 这很有效并且测试运行得更快。
In the end we decided to migrate from a system where data is setup via the front end to a data insert system. But keep an eye on the data to make sure it is real world. This has worked well and the tests run much faster.
我的测试数据也有同样的问题。 在我们的组织中，有一个批处理作业，它用类似生产的数据填充数据库。
我与功能测试人员协调，获取 loadrunner 脚本的测试数据。
I had the same problem with test data. In our organization, there is a batch job which populates the database with production like data.
I co-ordinate with functional testers to get the testdata for my loadrunner scripts.