p.p1 { margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px ".PingFang SC"; color: #454545 }
span.s1 { font: 12.0px "Helvetica Neue" }
之前有提到过，自己曾基于公司业务系统从无到有码过一套测试框架，但由于开发时的思想同时受限于公司业务及框架的适用性上，导致最终虽然框架可完美支持业务，但在易用性、兼容性及可扩展性方面依然存在一定问题，维护成本较高。后有幸结识RF，甚为喜欢。
那为什么说它好呢？
这就要从框架本身说起。关于对测试框架的认识，其实可大可小，各人理解不一。比如说如Junit等xxUnit系列，可以说是单元测试的框架，以白盒的方式调函数，调模块，加setup、加assert，覆盖代码段的功能，可以在代码层面做任何测试，但不太会用它做接口的联调或业务的串联测试。如TestNG+xxx等，偏向于用例及流程的控制，TestNG本身并不调用业务逻辑。相对全一点的，早期如Rational系列，从CQ到TM再到Rational Robot，覆盖从需求到测试再到测试管理，但实在是太重。后期如大家最熟知的QC+QTP／LR，全开发流程串联，功能强大，但同样的问题，一是略重，二是要用你的业务系统去适应QTP，当然用的好的话可以直接自己写测试agent作为第三方测试工具连QC，但除了调用接口要跟QC完美契合外，Report也用适应QC本身的报表，需要人力成本。再者QC的二次开发难度较大（有需要可以找我...），需大量时间做研究实践。
...未完待续
时间： 2024-08-15 13:32:10