我对其他人如何组织他们的测试脚本感兴趣,或者看到他们工作过的任何地方组织好的测试脚本。此外,这些测试脚本的详细程度如何。这特别涉及为手动测试而创建的测试脚本,而不是为任何自动测试目的而创建的测试脚本。
我认为问题是这样,测试脚本中存在很多复杂性,但没有组织复杂或大型代码库所使用的原则的好处。你需要能够指定一段代码应该做什么,但是当他们阅读它时不会让某人厌倦死亡。
另外,如何布局测试脚本,我不热衷于创建适合由数据输入类型运行的完全指定的脚本,因为这不是我们的团队,维护它们的开销似乎太高。此外,我觉得如此详细地指定流程会消除实际进行产品质量测试的人员的责任。人们是否指定每个按钮点击和输入值?如果没有,那么指定了什么级别的细节。
答案 0 :(得分:2)
人类执行的测试应该处于非常高的抽象层次。
E.g。 stackoverflow注册的测试用例:
好:
具有现有OpenId的网站访问者 帐户注册为stackoverflow 用户并发布答案。
为:
1)导航到 http://stackoverflow.com 2)点击 登录链接3)等...
这很重要有几个原因:
a)它使测试保持可维护性。因此,每次重新标记导航元素时,您都不必更新测试脚本(例如,“登录”更改为“登录”)。
b)它可以帮助您的测试人员免于疯狂地处理细微的细节。
c)编写详细的手动测试脚本是对有限测试资源的一种不良使用 详细的手动测试脚本会将您的测试人员转移到编写错误文档问题的错误中。您希望利用时间找到会影响客户的真正错误。
答案 1 :(得分:1)
可以按优先级对测试进行分组。 BVT /烟雾测试可以具有最高优先级,其功能,集成,回归,本地化,压力和性能具有较低的优先级。根据您的测试通过,您将选择优先级并运行具有该优先级或更高优先级的所有测试。您需要做的就是确定特定测试的优先级。
答案 2 :(得分:0)
我尝试将手动测试融入自动化结构中 - 你可以同时拥有两者。
自动化测试(例如xUnit框架)使用的组织方案适用于 我。事实上,它们可用于半自动化测试,通过停止和调用要运行的手动测试,输入输入或要检查的GUI。该方案通常是镜像生产代码的目录结构,或者将测试包含在生产代码中,有时作为内部类。单元级别以上的测试通常可以放在更高级别的目录中(假设您有足够深的目录树)。这些更高级别的测试可以进入(镜像)目录,这些目录没有生产代码,但是出于组织目的。
详细程度 - 嗯,这取决于,对吧?
答案 3 :(得分:0)
也许你应该试试一些测试库? HP QualityCenter和IBM产品再次提供了一些工具,但这可能很昂贵。你可以找到更便宜的东西,它可以让你按照需求/功能将它们组织成树形结构,为它们分配优先级,将它们分组到试验版中,将它们分组成回归测试套装等......