问题标签 [trx]

我有一个包含异步远程功能测试执行的 TFS 构建过程。当测试完成执行后，我想在原始构建摘要中发布生成的 TRX 文件并更新构建状态（如果需要）。

我已经搜索了一段时间，但到目前为止一直未能准确找到我正在寻找的内容：是否可以通过 PowerShell 脚本化 REST API 调用将 TRX 文件发布到构建摘要？

我们正在运行一个自动化测试，其中每个文件都算作自己的测试。我们使用动态数据属性来提供需要测试的文件。目前，每个文件都经过测试，但是在 TRX 文件中，它基本上将它们记录为子测试，如果任何 1 个测试失败，则整个存储桶都被视为失败。当我们在 azure 管道中发布测试结果时，这使我们无法准确读取实际失败或通过了多少文件（因为如果一个失败，那么整个事情都会被标记为失败）。有没有办法将这些子测试标记为实际测试，以便准确地完成计数？

在这里您可以看到实际上通过了 2 个子测试，但这并没有反映在标题中的结果中（请注意，它说 0/4 而不是 0/1 的原因是还有 3 个其他类似的测试“桶”具有通过和失败的测试，但也被标记为全部失败。

我正在实施智能合约，但我希望每笔应付交易都与 USDT 一起工作。我的合同运行良好，但它与 TRX 合作。

我使用 tronweb 从前端与之交互。

我尝试使用tokenid:on send 参数，但我发现它只适用于 TRC10。

我是 Jest 的新手，我正在尝试使用jest-trx-results-processor为 Jest 生成 trx 文件（以在 azure ADO 中发布结果） 。

我能够生成 trx，但在将结果文件添加到测试失败时遇到了困难。

现在它只创建没有 ResultFile 的 UnitTest 节点，例如：

但我想要下面的东西：

谁能帮助我如何使用jest-trx-results-processor在 trx 中获取 ResultFiles 节点。？

如何将 tron 发送到 tronlink web 中的智能合约功能。我正在尝试以下方法，但不起作用。

它正在调用智能合约功能，但不发送 tron。

要求：从 Jenkins 工作区，我需要读取测试结果文件（.TRX 或 .xml）并进一步解析它以获取测试数据以创建一些分析。

现在，我已将结果文件复制到我的本地文件夹中，并且可以使用 Python 读取和解析该文件。

我的问题是，我们可以直接从 Jenkins 读取文件吗？

好的 。所以我使用 tron-ide 在主网上部署了智能合约，将 user-fee-percentage 设置为零，但是从用户钱包调用合约时，它消耗的能量和 trx 来自用户钱包而不是合约钱包。这是合同https://tronscan.org/#/contract/TAx8Jq65YhvXc5saxFsqfLzKEwbQ1EdK64/transactions。你可以看到用户消费比率设置为 0 这是一个交易https://tronscan.org/#/transaction/0556bd0f5cedcf84b0f12025a3d7966bde9df3944823ddad4947c52230033423 。可以看出是消耗了用户的能量。有人可以对此发表评论。

因此，我一直在使用 Azure DevOps 构建应用程序并将其部署到 Azure，到目前为止，我发现这种方法非常易于使用。

我很感兴趣的是 Azure DevOps 如何收集和显示测试结果，我希望扩大我的测试范围以包括屏幕截图的集合，然后在 TestResults 附件选项卡中显示它们。问题是我被迫使用 Xunit，由于它无法访问 TestContext 类，它在保存文件方面存在问题。

我正在研究将附件保存到测试生成的 TRX 日志文件中的可能性，然后将其用作将结果存储到 Azure DevOps 的介质。

有人有在运行时操纵 TRX 的经验吗？

如果您对如何执行此操作有任何想法，我将不胜感激收到您的来信。

我有 2 个网络。TRC-20 和 ERC-20 网络。

现在我想在我的网站上使用不同的硬币。例如，USDT、Doge、比特币以及 ERC-20 和 TRc-20 网络中的任何货币。

当用户想要将资金从我的网站转移到 Binance 网站或任何其他网站时，该网站会为用户提供一个钱包地址，我必须将资金转移到该地址。

例如，它想将 USDT 转移到 Binance。我使用 web.js 为这个用户创建了一个钱包地址，这个地址的用途web.eth.createAccount是否重要？

或者我可以将它用于 USDT 吗？

在 ERc-20 网络上创建 USDT 钱包创建钱包时，我是否需要为用户做任何事情？

接下来的问题是我应该如何购买真实的USDT并将其存入此人的账户？我是否必须自己拥有一个 USDT 账户并从该账户转账给该人？

我们正在尝试开发一个用于立方体卫星操作的流程图。我们的流程图在一个流程图中包括下行链路和上行链路部分。它使用 SoapySDR 作为 SDR 的驱动程序。大多数使用的块都包含在 GNURadio 的核心中。使用了 Daniel Estévez 的 gr-satellites 的几个区块。通过 TCP 服务器（接收器和源块）提供数据输入和输出。

我们的 GFSK mod/demod 流程图

上行部分从 TCP 端口获取二进制数据并提供 KISS 去帧。解帧后的数据被打包到 HDLC 帧中。HDLC 成帧器块的输出是表示流的各个位的字节（0x00 和 0x01 字节）。对于 KISS 去帧和来自 gr-satellites 的 HDLC 帧块被使用。之后 G3RUH 加扰和 NRZI 编码完成。使用的 Scrambler 块来自 GNURadio 核心，NRZI Encoder 来自 gr-satellites。产生的比特流需要再次重新打包成字节，随后发送到 GFSK 调制器。Repack Bits 块用于此操作。它将传入的 8 个字节（代表 1 个字节的 8 位）打包成一个输出字节。如果比特填充和 NRZI 编码导致总比特数不能被 8 整除，则比特流的结尾被剪切。

GFSK Mod 参数为：

• 每个符号的样本数：40
• 灵敏度：(0.625*pi)/40 (偏差 3kHz, 9600bd -> mod. index 0.625)
• 蓝牙：0.5

在这一部分中，我们正在处理一个我们无法解决的问题。虽然使用 2 个后同步码来确保在 Repack Bits 块中至少有一个被正确重新打包，但似乎没有完全发送。我们已经尝试了几个接收器（流程图的下行链路部分、我们的 cubesat TRX 模块、带有第二个 SDR 的 UZ7HO hs-soundmodem），但没有一个能够正确接收数据包。

我们开始连续快速发送数据包。其中一些通过接收器。似乎第 (N+1) 个数据包的第一个前导字节用作第 N 个数据包的后导字节。

在此之后，我们尝试增加后同步字节数。这样一来，成功率就提高了。有趣的事实是，所有使用的接收器都正确接收了某些数据包。我们最终得出的结论是 20 个后置字节足以通过几乎 100% 的数据包。这似乎有效，但绝对不是解决此问题的正确方法。在正确的操作中，只需要一个后同步字节。增加后同步字节数会影响整体数据吞吐量。

检查编码块后，我们还保存了 GFSK Mod 块的输出。它是一个 32 位浮点 IQ 文件，通常直接发送到 SDR。我们创建了一个小而简单的流程图来解调和解码保存在文件中的这些数据。

用于 IQ 解调和解码的流程图

作为第一种解调方法，我们使用了 gr-satellites 包中的 FSK 解调器模块。解调后，我们还进行了解码过程并将输出保存到文件中。

这是二进制形式的解调和解码数据：

x1111111 11111000 00111111 11111111 11111111 11111111 11111111 11111111 10101011 11111111 01101010 0101110101111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 0111111001111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 0111111001111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 0111111001111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110001011

我们可以看到 150 字节的前导码（粗体），后面跟着一个不完整的数据字节。这个不完整的数据部分似乎是正确的，因为第一个预期字节是 B4 → LSB 00101101 MSB

我们尝试的第二种方法是使用来自 GNURadio 核心的 GFSK Demod 块。我们使用与第一种方法相同的输入文件。

这是二进制形式的解调和解码数据：

xxxxx011 00000000 00110001 1111111001111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 0111111001111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 0111111001111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 0111111001111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 0111111000101101 00001111 11000110 00000000 00000000 01001010 10111110 11001010 10001010 00111010 00

这里我们只能看到 149 个前导字节而不是编码的 150 个字节。之后我们可以看到一个不完整的数据包。执行了位去填充并且分析显示数据字节是正确的。

在整个数据编码过程中，流程图的“数字”部分似乎是正确的。没有观察到错误并且数据包以预期的方式改变。

我们可以看到两个解调器对数据的解调方式不同。在两个输出中，数据包的结尾都丢失了。如果我们将 postambles 设置为 5，则第二种方法能够正确解调数据包，观察两个 postambles。使用第一种方法时，仍然缺少后置码。仅使用 5 个后置码通过空中传输数据包的成功率非常低。

通过空中发送和解调数据最终会遇到类似的问题。数据包的结尾只是丢失了。有人知道问题出在哪里吗？