项目测试相关

上学时，软件测试是我觉得最枯燥的课，可能因为上课使用的例子都是诸如密码验证、登录等基本的功能，老师又反复要求列举测试覆盖，从那时就觉得测试是简单枯燥没有挑战的事情，并没特别在意。工作生涯是在游戏公司开始的，做了三年mmorpg网游，大多时间是在写功能逻辑，有专门的QA团队负责用黑盒测试进行验收，更加让我觉得测试没有营养。除了压测用的机器人，以及平常对比benchmark，可能因为游戏迭代快，很少见写代码进行测试（也可能我写的机器人不方便做这个 - -）。直到后来去了互联网金融行业，做了些基础功能，自己会顺手用go自带的test文件写一些不放心的地方的测试，明白程序员在写逻辑方面的进阶之一就是要写好测试用例，而且深觉有测试文件的比没有测试文件的功能可信度大的多。

有些功能比较大，写test不知从何下手（也怪当初没用心听课），也想总结一套测试流程，于是上网搜如何测试。这篇“为什么要写单元测试，何时写，写多细”关于测试覆盖程度的文章总结的蛮完善，还引用了stackoverflow上一篇大神关于覆盖率的解答。又逐步了解到测试覆盖，go test -cover这个利器检查测试覆盖率。各个大语言也都有自己的测试覆盖工具。还有分布式的测试环境。

看下大厂如何做测试：
fabric，有一个单独文件夹test：
test/docker-compose.yml大概是个基础测试环境，只有基础的ca、orderer、vp各一个节点。chaincodes文件夹下面是chaincode的示例。
test/envsetup下有个复杂一些的docker-compose：一个orderer、一个cli、分属于两个组织的四个peer，使用example/e2e_cli/base/docker-compose-base.yaml中定义的服务。generateCfgTrx.sh的作用大致为：使用example/e2e_cli/base/下的配置文件生成认证文件和组织架构（configtxgen的代码在common/configtx/tool/configtxgen/main.go）。channel-artifacts用于存放generateCfgTrx.sh产生的组织架构临时文件。
test/feature下是一些展望。
test/daily，通过README了解到这是每日的回归测试单元。runDailyTestSuite.sh通过调用ledger_lte.py、testAuctionChaincode.py、systest_pte.py执行单元测试。对于go的单元测试，go test结果通过管道符传给github.com/jstemmer/go-junit-report转化为xml格式（README中的示例go test -run ORD77 -v | go-junit-report >> results.xml），目的应该是把go test的结果格式化展示分析（可惜报告展示的链接404，IBM之类的大厂代码严谨，有些测试内容过于详细，最近看test目录已经八个月没更新了）。testAuctionChaincode.py使用pytest做测试框架，主要调用test/tools/AuctionApp/api_driver.sh进行create_channel、join_channel、install_chaincode、instantiate_chaincode、post_users、get_users、download_images……等功能调用peer的cli发命令返回输出。

(待续)