学习困难。开发人员处理已经解析的数据,因此他们并不关心格式。但是在集成级别,我必须知道格式的所有细微差别。了解格式比编写测试本身需要更多的时间。
容易出错。最后,您不知道为什么测试失败。是因为测试中的系统还是测试数据不正确?
对于那些长期参与该项目的测试人员来说,这些并不是什么大问题,但对于像我这样的新手来说却是真正的障碍。所以我们在做什么:
我们正在创建测试数据生成器。我们正在将生成器中的知识编码,包括业务分析师,其他测试人员和开发人员的文档资料和答案。测试数据生成器包含测试人员可以组合在一起以创建完整测试数据的预定义数据块。测试人员显然必须学习DSL(基于Java),但是我希望它比最终格式更容易。
我们正在创建测试数据验证器。在将生成器创建的测试数据序列化为特定的XML格式之前,需要先针对一些基本约束(例如,必填字段,跨测试数据不同部分正确的值)进行验证。这样可以消除基本错误。
我们还能做些什么来简化测试数据的创建过程?
我们如何确保测试数据正确?
#1 楼
生成测试数据是一个困难的问题,因为如果您不了解数据的含义,那么您很可能会生成会在测试中引发误报的测试数据(由于错误数据而导致的测试失败,而不是产品中的错误)。 。我成功使用的方法是从等效分区生成参数化测试数据。我将这种方法用于各种数据,例如Unicode字符串,设备上的联系信息(例如名称,电话号码等)以及JSON blob(正负测试)。
<基本上,此方法需要对数据建模,将数据分解为等效子集,然后生成满足模型约束的测试数据。 (实际上听起来您走对了。)要了解这种方法,请参阅我的白皮书《 MS Research》中的白皮书《参数化随机测试数据生成》。我在这里也有一篇文章。
当然,模型是对现实的抽象,因此您生成的数据仅与模型,等效集以及如何使用这些参数进行参数化一样好设置在您的发电机中。数据生成可能变得非常复杂,并且可能还包括对特定值进行加权,排序等。
关于验证生成的数据,所有预言本质上都是启发式的。因此,在这种情况下,您可以验证生成的数据满足模型要求。它不是防弹的,但比完全随机或猜测的要好。
最后,别忘了也使用真实数据。
如果您还有其他问题或需要帮助,请告诉我。
评论
Bj,说得好。我特别喜欢这些句子中很高的“每词洞察力”:“当然,模型是对现实的抽象,因此,生成的数据仅与模型,等效集以及如何使用参数化参数一样好生成器中的那些集合。数据生成可能变得非常复杂,还可能包括对特定值进行加权,排序等。”
–贾斯汀
15年2月19日在22:36
#2 楼
由于错误的oracle(和比较器)或不正确的测试输入数据(即测试步骤),测试可能返回假阳性或假阴性。为了解决这些问题,我在文献中发现了以下方法。不正确的oracle和比较器
活页夹在他的《测试面向对象系统》一书中提出了以下方法来限制设计不正确的oracle的问题:
如果可能,请与您的系统用户一起查看oracle
产生的一些预期结果和假设。由于某些特殊的
约束,对于开发人员或测试人员而言,看上去正确的值可能会有些许不正确。
oracle越复杂,伪测试结果的机会就越大。尝试最简单的解决方案。
如果oracle
基于规范,请不要忘记验证该规范。
请仔细检查该规范中的遗漏和矛盾之处。
对于具有明显预期结果的测试用例,请尝试使用oracle,对于
示例,全部为零,全部为零。这样的测试用例检查oracle
和比较器。
如果可行,请尝试使用几个独立的资源。例如,如果您要从参考文献中的
表中选择值,请尝试查找其他提供相同信息的参考文献
。从这些
源中插入值。如果您将现有系统用作oracle,请尝试在不同的配置或平台上运行
,更改一天中的时间
,更改后台负载,等等
生成数百万个测试用例输入的程序通常并不难,产生其预期结果通常等同于开发SUT。两种Oracle模式可以部分克服
此限制。内置的测试Oracle将检测到部分但不是全部
任何输入的输出不正确。您可以将现有的
系统用作黄金标准的oracle。使用您的测试输入运行现有系统。它将自动产生您的部分或全部预期结果(Trusted System Oracle模式)。
可测试性设计
提示:如果需要一个非常困难或昂贵的Oracle,请考虑放弃一个测试策略或测试用例。尝试尽可能使用现有的代码,文件或测试套件。
可测试性设计技巧:
如果可能很难开发应用程序规范或需求,请考虑重新编写应用程序规范或需求。
考虑一个
部分或近似的oracle。不要假设您的oracle必须为每个可能的输入和状态生成完整的预期结果。
专注于生成必须正确的输出或
困难和/或耗时的输出用手检查。
考虑使用
几种预言来弥补弱点。例如,您可以使用现有系统为新系统生成大约一半的关键输出。您可以实现内置的测试断言来检查较新输出上的关系。
测试输入数据不正确
一个原因为什么测试数据无效的原因可能是测试输入数据的错误生成器。因此,“软件测试中的经验教训”建议像其他任何软件一样对它们进行单元测试和审查。
似乎,测试测试框架将带来无穷无尽的测试。实际上,根据定义,单元测试必须比被测试的系统更简单,因此不需要进行测试。第二,您不必每次都验证新的测试数据,而只验证一次生成器。最后,通过生成器测试,您还更有信心修复一个生成器不会引入任何新的错误。
评论
这是一个递归答案,不是很有帮助...
–Rsf
2012年10月29日7:58
我更新了答案以显示它不是递归过程,但仍然与无效的测试数据问题有关。
– dzieciou
2012年10月29日19:36
评论
我喜欢这种方法。使用DSL的优势在于,与XML相比,您的测试用例可以更简洁(并且可能更易于维护)。是的,它们似乎更易于维护。例如,重构的成本较低,而且借助编译器,我得到了有关语法的即时反馈。