更新可以执行性能测试脚本,例如使用LoadRunner可能会花费大量时间并且非常令人沮丧。如果应用程序有一些更新,您通常必须运行脚本,然后找出必须更改的内容,更新并再次运行等等。有没有人有一些具体的最佳实践如何缓解这种更新地狱?一个显而易见的事情是与开发人员的良好沟通。
答案 0 :(得分:1)
这取决于更新的类型。如果更新非常引人注目,例如添加新字段供用户填写,那么有人必须手动修改测试脚本。
但是,如果更新很小,例如,隐藏字段的某些更改或面向用户字段的内部名称的更改,则可以编写一个脚本来检查更改并自动更新测试脚本。
其中一个性能测试平台NetGend会自动处理隐藏字段和面向用户字段的内部名称,因此可以非常轻松地创建脚本来对HTML进行性能测试形成。测试人员只需要填写他/她必须使用浏览器输入的值,因此不需要相关性。如果您需要了解更多信息,请给我发消息。
答案 1 :(得分:1)
您可以采取许多措施将脚本与构建隔离,以构建可变性。 OSI堆栈越高,维护费用越低,但虚拟用户类型的资源成本越高。假设更改仅限于页面级资源和网站或应用程序的一些隐藏字段,那么您可以在HTML模式下进行录制。你爆炸了EXTRARES部分,因为HTML模式下的页面解析器会自动解析页面并加载页面资源,即使没有明确的引用 - 如果开发人员正在进行相当多的实验,那么保持这些部分同步真的很痛苦
接下来,对于在变化方面具有非常高速度的表单,请考虑对一个表单使用web_custom_request()。您可以使用关联语句根据需要获取所有名称|值对,并动态构建表单提交。为此你会有更多的前期工作,但你应该在第四个改变的版本附近获得回报,你通常会重建一些脚本。
查看代码中引用的所有主机。参数化所有这些项目。我有一个模板,我用于Web虚拟用户,它通过控制面板额外属性部分配对默认值和更改任何主机名的功能。看一下lr_get_attrib_string()的示例,了解如何实现拾取,并将其与NULL检查以及代码中具有默认值的总体配对
这似乎是违反直觉的,但是对于经常发生的更改会大量评论您的脚本,以便您知道在哪里可以预先进行额外的人工更改以处理更动态的数据集。
几乎没有任何工具可以帮助您避免应用程序的设计和流程中的结构变化,例如在工作流程中插入新页面,但要注意高变更页面上的设计,通常只有少量的测试代码会导致测试代码的使用寿命很长。
当然,如果您的应用程序是基于Web服务的,那么使用暴露的公共服务会有很长的使用寿命。代码可能会在服务的后端发生变化,但通常暴露的公共接口非常稳定。