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

yong8031

大神，学习下

yong8031

大神，学习下

yafengwang

这个不错 可以学习一下

suprookie

多谢楼主分享

yanwei86

好的，一定支持

帅哥小虾

谢谢楼主分享，下载过来看看

ray8780

感谢分享感谢分享

yangwei211

谢谢楼主分享，下载过来看看123123

handle5555

不错不错

370786710

666,看起来挺高大上的

blackc

感谢

徐飞飞飞

666

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

Yuri.wang

LOOKK

dominolu

神回复

126wanghui

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

xiaobaien

求代码

helen_xm2020

学习学习

zysoft2002

good

iigx

厉害啦，我的哥