09丨关联和断言：一动一静，核心都是在取数据

关联，有关有联，该数据一定是根据前面的业务获取的，是一个变化动态的，从服务器获得的，否则就可以在脚本中直接写好，变成一个参数了；同时该数据也一定是后面业务得以进行的必须输入，否则就没有存在的意义了；因此，关联数据起了一个承上启下的作用。取数据特点，从服务器返回信息中取数据，这个数据是动态的，且是后续业务必须的输入数据，需要继续使用的。 断言，美其名曰一言断分晓，明查是对是错矣。提取服务器返回的可判断业务成功的数据，对其进行判断，从而获知业务是否成功。取数据特点，也是从服务器返回信息中取数据，在业务成功时该数据是一样的，主要用于判断，判断结束后一般不会继续使用。

思考题：联和断言的逻辑是什么吗？它们取数据的特点又是什么呢？ 关联：取出前序调用返回结果中的某些动态值，传递给后续的调用。最常见的是唯一标识客户端的「Session ID」。 断言：又称检查点，断言是我们的预期，主要是保证脚本按照原本设计的路径执行。取的数据是服务端返回的，可标识业务成功与否的数据，并做判断。 请记住，测试一定要有断言。没有断言的测试，是没有意义的，就像你说自己是世界冠军，总得比个赛吧！

关联和断言，都是获取特定数据；关联将获取到的数据更新到下一次使用中；断言预知被解除数据的数值，判断执行结果是否正常；

今日思考题： 你能说一下关联和断言的逻辑是什么吗？ 关联的逻辑：数据由服务端生成且每次生成的数据是动态变化的，通过关联取到的数据在后续的请求中需要再次使用。 断言的逻辑：对服务端返回的，可标识业务成功与否的数据，将其取回来之后做判断。 补充：断言是根据需要来设计的，而设计断言的前提就是完全理解后端代码逻辑。（代码很重要，昨天老师也指示了，准备着手学起来） 它们取数据的特点又是什么呢？ 都是从服务器返回的信息中取出数据，不同的是：关联取的数据，每次都不一样；而正常情况下断言每次取的数据基本上是一样的。 老师讲的循序渐进，简单易懂。

断言，也就是loadrunner里的检查点：对脚本执行结果进行成功失败判断 参数化，a可以模拟，b也可以，同样c也可以去模拟，只不过模拟对象不同，但最终结果是一样的（最大程度的模拟现实环境） 关联，客户端去向服务器请求数据，服务器返回数据的同时带有一个可变的值或不变的值，当通过脚本形式去访问时，如果你的脚本中在模拟客户端请求时没有带这个值去请求的话服务器端是不认的，因为你的请求没有服务器要的值（没有通过服务器的验证），自然数据也不会给你了，有点类似http里的三次握手🤝

关联——动态的数据获取用于继续的使用 断言——判断业务逻辑是否OK

断言其实从测试人员的角度来解释，最简单直接的方式就是预期结果与实际结果做比较，判断是否一致，只是在这里，我们将其从人工方式转为了脚本去实现。 关联，最终体现在了业务上下游中的提取、传递、引用，个人认为可以解释为参数传递与引用，可以是接口与接口之间的、接口与前置条件之间的、后置处理器与断言之间的。 接口与接口之间：比如A接口的某个返回参数作为了后续接口的入参； 接口与前置条件之间：比如注册接口要保证注册号码的唯一性,我们在前置条件中做处理后，在入参中使用变量，或者直接使用相关的函数生成 后置处理器与断言之间：比如一个写入数据库动作的接口，我们在断言时候，可能需要在接口后置处理器中引入JDBC请求进行查询，然后再做如beanshell断言是否符合预期

断言 判断对错，关联只管取用，不管对错。关联取数一定是返回值中某一个特定的变化的值，断言则是判断返回值中有没有某一个特定值，有就说明程序按预定设计执行了

接口性能测试，若b接口需要关联a接口的返回数据，如token 。那么，a接口性能会影响到b接口的性能。 我一般是通过修改代码屏蔽掉这个参数的影响。但我不知道是否合适？ 合适或者不合适，或者如果需要分情况考虑，可不可以请老师帮我理理。感谢

关联和断言的逻辑是什么吗？ 它们取数据的特点又是什么呢？ 关联: 在发出的请求之中，用到收到的请求的数据。通常取到的是header或者页面内容数据，用正则表达式比较合适。 断言: 判断请求是否成功的标志。可以用json parsing的方式获取数据。判断HTTP status code也是一种合理的断言方式(比如，一个post请求，在成功时断言201 created)