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