【LuckyFrame】V2.5版本-开源自动化平台 持续更新【2018.5.25 更新优化版本】

seagull1985

什么是LuckyFrame

它是一款开源自动化测试框架，Lucky是我女儿的小名（容许小小的晒下幸福）

测试狗的痛点：不懂代码、什么是自动化框架、自动化成本太高、自动化没有界面

#革命性“自动化测试框架”，解决测试狗的痛点

我能做什么？

• 分布式测试：使用Web-Client的方式，Web端负责基本信息管理展示，Client负责用例执行，任意无限扩展客户端。
• 多途径用例管理：您即可以使用Web端自带的用例管理模块，也可以使用testlink来管理自动化用例。
• 质量管理：Web端不仅仅有用来管理自动化相关的模块，更可以做一些简单的质量数据收集分析以及数据的多图表展示。
• 多线程执行用例：客户端执行用例可以指定线程数量，用例运行更快速。
• 在线编辑用例：专属自动化用例设计结构，使用bootstrap table x_edit插件，更快捷、方便的编辑、调试自动化用例。
• 定时任务调度：支持自定义配置调度任务，包括指定线程数，指定执行客户端，远程执行shell重启tomcat,对jenkins中的项目进行构建等。
• 测试过程监控：客户端运行用例采用命令行的方式，在客户端可以实时查看过程。Web端可以通过任务查询查看测试进度。
• 日志定位：客户端LOG4J+数据库记录测试过程日志，2种方式都可以通过Web端实时查看定位问题。
• 接口+Web UI双纬度自动化：支持接口+Web UI自动化，客户端OS必须为Windows系统，UI自动化采用WebDriver3.0封装，纯关键字驱动，0编码。
• HTTP+Socket接口免编码：完全封装HTTP以及Socket接口，协议模板+纯关键字驱动，免编码，初级测试人员的福音，与其他类似开源工具相比优势明显
• 在线调试用例：直接通过页面的步骤编辑界面调试用例，省心、省力、省脑子，但是不能不要脑子。
• Bootstrap 小清新风格界面：整套Web系统基于Bootstrap风格，以及多种其下的插件，构建清爽界面。
• 更多......
  

2.5 版本更新，全面优化HTTP协议测试以及用例公共参数管理，期待您的体验。

自动化部分功能界面说明：

2.5版本更新部分页面首页

用例管理


步骤管理


Web UI测试过程中错误截图直接浏览器查看


测试计划管理


往测试计划中添加用例


调度任务管理


任务执行查询


用例执行情况


用例中日志打印


统计图表

协议模板

自动联机填充步骤

关于本人在开发此平台的的一些经验代码，已经另外开贴进行了归纳总结，有时间还会更新的，请大家关注 http://bbs.51testing.com/thread-1085342-1-3.html

如何获取项目的所有代码以及内容，在隐藏的内容中，需要回复才能看到，是希望大家通过回复能把贴子保持置顶位置，让更多的人看到，希望能理解。

想知道更详细的说明吗？想更快的建设你们的自动化吗？快点回复，看看怎么样找到项目吧。

游客，如果您要查看本帖隐藏内容请回复

c604507978

学习了，感谢大佬

51testing201515

谢谢分享

weichen_16

感谢分享。

枫丶

不错

西洲有月

围观一下啊 感谢分享

weimin520

谢谢分享

Miss_love

支持分享

15680167655

我学学学二

Miss_love

好东西啊 git上看了，不错的

iigx

厉害啦，我的哥

zysoft2002

good

helen_xm2020

学习学习

xiaobaien

求代码

126wanghui

现在是2020年1月，没有新的更新吗

dominolu

神回复

Yuri.wang

LOOKK

momo0518love

测试用例需要注意以下几点：
1、单个用例覆盖最小化原则
下面举个例子来介绍，假如要测试一个功能 A，它有三个子功能点 A1，A2 和 A3，可以有下面两种方法来设计测试用例：
方法1 ：用一个测试用例(确却的说是用例的逻辑部分)覆盖三个子功能 -Test_A1_A2_A3，
方法2 ：用三个单独的用例分别来覆盖三个子功能 - Test_A1，Test_A2，Test_A3

方法1适用于规模较小的工程，但凡是稍微有点儿规模和质量要求的项目，方法2则是更好的选择，因为它具有如下的优点：
1）测试用例的覆盖边界定义更清晰；
2）测试结果对产品问题的指向性更强；
3）测试用例间的耦合度最低，彼此之间的干扰也就越低

上述这些优点所能带来直接好处是，测试用例的调试、分析和维护成本最低。每个测试用例应该尽可能的简单，只验证你所要验证的内容，不要“搂草打兔子”捎带着把啥啥啥都带进来，这样只会增加测试执行阶段的负担和风险。

此外，覆盖功能点简单明确的测试用例，也便于组合生成新的测试。

2、单次投入成本和多次投入成本原则。
例如：第一条原则－单个用例覆盖最小化原则 - 就是一个很好的例子，测试A功能的3个功能点A1，A2和A3，从表面上看用Test_A1_A2_A3这一个用例在设计和自动化实现时最简单的，但它在反复执行阶段会带来很多的问题：

首先，这样的用例的失败分析相对复杂，你需要确认到底是哪一个功能点造成了测试失败；

其次，自动化用例的调试更为复杂，如果是A3功能点的问题，你仍需要不断地走过A1和A2，然后才能到达A3，这增加了调试时间和复杂度；

第三，步骤多的手工测试用例增加了手工执行的不确定性，步骤多的自动化用例增加了其自动执行的失败可能性，特别是那些基于UI自动化技术的用例；

第四，（Last but not least）将不相关功能点耦合到一起，降低了尽早发现产品回归缺陷的可能性，这是测试工作的大忌。

例如：如果Test_A1_A2_A3是一个自动测试用例，并按照A1->A2->A3的顺序来执行的，当A1存在Bug时，整个测试用例就失败了，而A2和A3并未被测试执行到。如果此时A1的Bug由于某些原因需要很长时间才能修复，则Test_A1_A2_A3始终被认为是因为A1的Bug而失败的，而A2和A3则始终是没有被覆盖到，这里存在潜在的危险和漏洞。当你在产品就要发布前终于修复了A1的Bug，并理所当然地认为Test_A1_A2_A3应该通过时，A2和A3的问题就会在这时爆发出来，你不得不继续加班修复A2和A3的问题。不是危言耸听，当A2/A3的代码与A1的Bug修复相关时，当你有很多如此设计的测试用例时，问题可能会更糟……，真的！

综上所述，Test_A1_A2_A3这样的设计，减少地仅是一次性设计和自动化的投入，增加地却是需要多次投入的测试执行的负担和风险，所以需要决策时（事实上这种决策是经常发生的，尤其是在设计测试用例时）选择Test_A1_A2_A3还是Test_A1、Test_A2和Test_A3，请务必要考虑投入的代价。

3、使测试结果分析和调试最简单化原则。
这条原则是实际上是上一条- 单次投入成本和多次投入成本原则 - 针对自动化测试用例的扩展和延续。在编写自动化测试代码时，要重点考虑如何使得测试结果分析和测试调试更为简单，包括：用例日志、调试辅助信息输出等。因为测试用例的执行属于多次投入，测试人员要经常地去分析测试结果、调试测试用例，在这部分活动上的投入是相当可观的。

徐飞飞飞

666

blackc

感谢