01.对交易中涉及的所有步骤使用适当的检查点/断言
当页面未完全正确下载时，没有检查点可能会导致更好的响应时间。
用于断言的文本应该是静态的，或者应该在所有运行/环境中保持一致。如果做得不好，脚本维护成为开销。例如，如果最畅销汽车的名称被用作断言，那么一旦畅销汽车名称发生变化后，该脚本可能会在几天后开始失败。
02.确认您的性能测试工具是否自动处理cookie
如果被测站点设置了cookie，这些cookie可能会出现在记录的脚本中，并且需要由脚本设计者通过使用变量来显式处理。该变量允许脚本在测试过程中接收不同的cookie值，而不是使用记录的值。
如果站点使用来自应用程序服务器的HTTP会话cookie，Cookie替换是必须的。
03.确保该脚本不包含不正确或无关的URL。指定的网址应该按正确的顺序排列
录音时可能会有这种可能，剧本作者会去他/她的受欢迎的网站。
可以使用测试工具的“播放”功能来验证脚本实际执行的操作。
04.识别脚本中存在的所有动态数据（作为服务器的响应）并将其关联起来
通常可以通过记录脚本两次并在它们之间进行比较来找到它。
05.参数化脚本以支持动态数据集
在存在动态数据的情况下，每个模拟用户都会执行完全相同的路径，但避免缓存响应并正确执行数据库交互。
06.检查脚本中的思考时间和步调时间
不建议为每个步骤或每个用户使用常量思考时间值。
请检查您的工具是否支持在某个范围内分配思考时间值。
思考时间值和起搏时间值应在性能需求收集阶段进行规划和确定。
07.用户很少从网站注销，因此不要假设相同并相应地设计脚本
每次注销时，都可能比实际更快地清除缓存中的http会话信息。
08.在设计时验证脚本
用一个迭代和一个用户来验证它
通过多次迭代和一个用户来验证它
用多个并发用户进行多次迭代来验证它
09.应该以某种方式编写脚本，以便可以针对多个环境执行脚本而无需进行任何重大更改
不同的环境可以是测试，压力，预生产等
10.考虑先为原始路径构建脚本
它有助于轻松排除故障和优化
11.最终脚本应该代表实际的用户活动
不应该太简单，太专注，直到真正需要
12.在设计脚本时注意可重用性
开发简单的脚本来构建更复杂的脚本和场景。
所有简单的脚本应该是原子性的。
13.遵循标准的命名约定和文件夹结构
抵制使用工具提供的默认值（例如目录路径，日志文件位置）的诱惑。了解每个设置的结果，然后应用它。
有助于可读性和审查脚本。
推荐阅读：
sales@spasvo.com
