[Feature] 改进自动化测试以及 ci 看护

[unicornx]

Describe problem solved by the proposed feature

参考：

• https://docs.qq.com/doc/DY0NwZ3dpaEdaUmxZ
• 使用 yml 看护主线 bsp: https://mp.weixin.qq.com/s/_NnsRlQliF2STD2FelR-Bw
• 主线上 CI 运行的 UTest：https://github.com/RT-Thread/rt-thread/blob/master/.github/workflows/action_utest.yml

这个 issue 用于列出主题相关的需要做的工作，具体确定下来了的工作可以另外提 issue 或者 PR。

1. 三个配置文件方式（ut 里的 .config; bsp 里的 .attachconfig; 涛哥 yml）-> 归一化为 yml
2. 在跑 utest 的 QEMU 需要在 github 编译的时候自动使能 RT_USING_CI_ACTION 宏。
3. 基础测试用例：libc 作为模板，去找一下，看看有没有开源测试用例
4. 编写用例的时候一定要注意延时，延时在 QEMU 里不确定。
5. 考虑使用沙盒，在沙盒里面运行 UT
6. 目前 utest 测试用例的位置放在 examples 下，感觉不合适，utest 的重要性值得放到源码树根目录下？而且 examples 下还有些其他的 test，感觉整合一下，专本在源码根目录下放一个 testsuites 的目录
7. 目前 utest 测试用例除了 examples/utest 外，在其他目录下还有 (搜索 UTEST_TC_EXPORT)，是否需要合并到一起？还是各个组件模块自己维护自己的 utest cases？感觉自己维护是不是好一些？这样一些默认不是放在 RTT 主仓的组件的 test cases 以后也不会占用 RTT 主仓的空间？
8. 文档描述问题：https://www.rt-thread.org/document/site/#/rt-thread-version/rt-thread-standard/programming-manual/utest/utest?id=%e9%85%8d%e7%bd%ae%e4%bd%bf%e8%83%bd . "the buffer size for console log printf" 这个配置项在最新的内核中是在 “Using console for rt_kprintf” 下面。不是在 “Kernel Device Object” 下面。
9. examples/utest/README.md 需要改进，譬如该文件中 “/” 和 ”\" 混用。
10. 文档描述问题：https://www.rt-thread.org/document/site/#/rt-thread-version/rt-thread-standard/programming-manual/utest/utest?id=%e6%b5%8b%e8%af%95%e7%94%a8%e4%be%8b-log-%e8%be%93%e5%87%ba%e6%8e%a5%e5%8f%a3 utest 测试框架依赖 ulog 日志模块进行日志输出? 我这里在 qemu-virt64-riscv 上做实验，发现 ulog（RT_USING_ULOG）并没有开启，也可以工作啊？
11. 测试用例命名，参考 https://www.rt-thread.org/document/site/#/rt-thread-version/rt-thread-standard/programming-manual/utest/utest?id=%e6%b5%8b%e8%af%95%e7%94%a8%e4%be%8b%e5%af%bc%e5%87%ba%e5%ae%8f 中针对 “测试用例命名要求”，但目测目前代码中的不符合，貌似不少前面多一个 "testcases.", 是不是要纠正一下？
12. bsp/cvitek 的 CI 编译看护有加入吗？提了一个 issue ：[Feature] 希望将 bsp/cvitek 下的 duo 产品加入 ci 看护 #9795
13. utest 中 unit 我理解就是 case 的意思，我建议在给 unit 的函数命名的时候采用数字编号。在此基础上每个 case 涉及的上下文独立管理，譬如每个 case 编写对应的 caseX_init/caseX_cleanup，管理 case 自己独立的全局变量。不好的例子参考 thread_tc.c。
14. 在 testcase 的源文件中加入 doxygen 注释，对每个 case 的输入和输出进行规范化描述，作为测试文档的一部分方便后来人阅读和理解这些 case 设计的目的。
15. [Bug] examples/utest/testcases/posix 下部分代码是 GPL 的，和 RT-Thread 的 Apache 授权冲突 #9796

疑问：

• utest 比较适合 RT standard 下的测试，编译进 kernel。对于 RT-smart 的测试，有什么想法没有，内核 API 测试应该还是可以用 utest，但用户态的测试感觉要引入其他的机制，譬如 ltp？

• CI 运行测试用例是否可以运行 Fail 后不阻塞后面没测试完成的用例？
  A：我目前理解 testcase 前一个失败不会 block 下一个执行，但是在 testcase 中如果存在多个 unit，则只要有一个失败，后面的就不会执行了。见 UTEST_UNIT_RUN 的实现。

• examples/utest/configs 是干什么用的？

• 如何测试不同配置下的行为？需要针对不同的配置做不同的内核吗？还是有什么更好的方法在一个内核中测试不同配置的行为？

• 如何理解 RT_USING_CI_ACTION 的含义和用途，是不是说对于那些 utest 的 testcase，必须要在这个开关的控制下才可以在 CI/qemu 上跑？举个例子：我发现在 examples/utest/testcases/kernel/thread_tc.c 中有个 case：test_timeslice() 在 testcase() 中被注释掉了。

  static void testcase(void)
  {
      ........
      /* timeslice */
      // UTEST_UNIT_RUN(test_timeslice); /* Can not running in Github Action QEMU */
  }
  UTEST_TC_EXPORT(testcase, "testcases.kernel.thread_tc", utest_tc_init, utest_tc_cleanup, 1000);

  所以我有一个想法是，把 RT_USING_CI_ACTION 应用到 utest 的 unit 级别。默认 RT_USING_CI_ACTION 是关掉的，所以所有的 unit 都参与 utest 编译，但是如果定义了 RT_USING_CI_ACTION 则只有定义了 RT_USING_CI_ACTION 的 unit 函数才会参与编译。

  另外我看到有些 testcase 的写法习惯是基本上一个 testcase 内只有一个 unit，然后加入 Kconfig 对 case 进行控制。感觉这也是一个控制 testcase 颗粒度的思路。

Describe your preferred solution

No response

Describe possible alternatives

No response

[BernardXiong]

最好还是不放腾讯文档吧，可以直接挪到issue中

[supperthomas]

之前做了一个自动化执行命令行的，有需要可以拿去用
https://github.com/supperthomas/RTT_AUTO_EXE_CMD

这个就是可以通过kconfig的方式，模拟人手动执行，在qemu里可以看到效果

[BernardXiong]

CI 运行测试用例是否可以运行 Fail 后不阻塞后面没测试完成的用例？

这些是不好判断的，特别是如果一些测试用例还依赖于前面的测试用例时。或者在测试用例中主动也考虑到这样的情况

[supperthomas]

可以考虑在yml中继续添加每个case的expect节点，用于匹配在真机或者qemu中成功的string