diff --git a/site/pages/docs/api.mdx b/site/pages/docs/api.mdx
index 68cadae..9b759d5 100644
--- a/site/pages/docs/api.mdx
+++ b/site/pages/docs/api.mdx
@@ -134,6 +134,7 @@ const {
   downloadUpdate,
   downloadAndInstallApk,
   getCurrentVersionInfo,
+  parseTestQrCode,
   currentHash,
   packageVersion,
   client,
@@ -167,6 +168,8 @@ interface PushyContext {
     description?: string;
     metaInfo?: string;
   }>;
+  // 解析测试二维码，此方法需v10.11.2+版本
+  parseTestQrCode: (qrCode: string) => void;
   // 当前的版本hash
   currentHash: string;
   // 当前的原生版本号
@@ -307,6 +310,30 @@ interface PushyContext {
 
 ---
 
+#### function parseTestQrCode(qrCode: string)
+
+解析测试二维码，一般用于给 QA 人员测试热更新。如果在应用中已有扫码功能，则可以在应用中扫描 pushy 后台的测试二维码来测试任意版本的热更包。
+
+![testqrcode](./assets/testqrcode.png)
+
+代码示例：
+
+```js
+<Camera
+  onReadCode={({ nativeEvent: { codeStringValue } }) => {
+    // 先解析是否是pushy的测试二维码
+    if (parseTestQrCode(codeStringValue)) {
+      // 如果是pushy的测试二维码，则不再继续扫描
+      setShowCamera(false);
+      return;
+    }
+    // 如果不是，继续处理其他业务扫码逻辑
+  }}
+/>
+```
+
+---
+
 ### Android 方法
 
 #### UpdateContext.setCustomInstanceManager(ReactInstanceManager instanceManager)
diff --git a/site/pages/docs/assets/testqrcode.png b/site/pages/docs/assets/testqrcode.png
new file mode 100644
index 0000000..3186820
Binary files /dev/null and b/site/pages/docs/assets/testqrcode.png differ
diff --git a/site/pages/docs/bestpractice.md b/site/pages/docs/bestpractice.md
index 480c2ed..f06d8aa 100644
--- a/site/pages/docs/bestpractice.md
+++ b/site/pages/docs/bestpractice.md
@@ -62,13 +62,30 @@ splits {
 
 #### 测试、发布与回滚
 
-我们强烈建议您先发布一个**测试包**，再发布一个除了版本号以外均完全相同的**正式包**。
+自 v10.11.2 版本开始，可以使用以下两种快捷扫码方案来测试热更，而无需提前进行绑定：
+
+![testqrcode](./assets/testqrcode.png)
+
+- 若应用启用了 [DeepLink](https://reactnative.cn/docs/next/linking#%E5%90%AF%E7%94%A8-deep-links) 功能
+
+代码中无需任何改动，只需在上述界面中勾选“使用 Deep Link”，填入您应用的协议名，例如"pushy://"，然后使用系统相机或系统内置的扫一扫功能扫码（注意不能使用微信扫码），即可自动调起应用并触发更新。
+
+- 若应用自带扫码功能
+
+请参考 [parseTestQrCode](api#function-parsetestqrcodeqrcode-string) 方法的说明。
+
+<details>
+<summary>若您的应用不具有上述两项功能，或 pushy 版本低于 v10.11.2，则可以参考如下测试方式（不推荐）</summary>
+
+先发布一个**测试包**，再发布一个除了版本号以外均完全相同的**正式包**。
 
 例如，假设我们有一个正式包，版本为`1.6.0`，那么可以修改版本号重新打包一个`1001.6.0`，以一个明显不太正常的版本号来标识它是一个测试版本，同时后几位相同，可以表明它和某个正式版本存在关联（内容/依赖一致）。
 
 在每次往发布包发起热更新之前，先对**测试包**`1001.6.0`进行更新操作，基本测试通过之后，再在网页后台上将热更包重新绑定到**正式包**`1.6.0`上。如果在测试包中发现了重大问题，你就可以先进行修复，更新测试确认通过后再部署到正式线上环境。这样，可以最大程度的避免发生线上事故。
 
-万一确实发生线上事故需要回滚的话，首先利用版本控制系统回滚代码到正常的状态，然后重新生成热更包并推送即可。
+</details>
+
+万一确实发生线上事故需要回滚的话，更改绑定到之前正常的版本，或者首先利用版本控制系统回滚代码到正常的状态，然后重新生成热更包并推送即可。
 
 #### 元信息(Meta Info)的使用