自动化用例设计原则
接上篇文章~
文章总览图
#独立的测试账号
#正常用例
#前提条件：
##############################尽量不要依赖于测试环境的数据，如果没有，就自己造环境。###########
#1.用户已登陆
#2.有能够投资的标 #如果没有标，则先加标。#通过查询数据库来处理，或者接口的方式加标。
#操作系统的数据库，只能查询，不能随便改系统的数据。这个系统不是你实现的，它内部有一些逻辑操作，
#你不知道它是怎么做的，会牵连到很多这种关联的数据库，如果不懂表之间的结构关系，你也没有办法做得到，
#那就别随便修改数据库里面的数据，可能你一改，这个系统就要出很多bug。
#接口发生过程中，会对关联的表结构都去做处理的，你是不知道的，所以只能查询不能改。
#你自己的测试数据存在数据库中，可以单独做处理，系统数据就不要去动它。
#3.用户有余额可以投资
#1.充一个亿
#2.接口方式查询下当前用户还有多少钱。> 6000 不用充值。 如果小于用例中投资的金额，那就充值。
#步骤
#1.在首页选标---不根据标名，根据抢头标。默认第一个标。
###标页面-获取一下投资前的用户余额
#2.标页面--输入投资金额、点击投资按钮。
#3.标页面--点击投资成功的弹出框-查看并激活，进入个人页面。
#断言
#钱 投资后的金额，是不是少了投资的量
#个人页面 - 获取投资后的金额
#投资前的金额-投资后的金额=投资金额
#投资记录对不对
#利息对不对？
#异常用例：非常好创造环境，非常好写的，没有什么难度。
#舍弃----以后手工测试可以单独测试这块
#异常用例：全投操作？ 标的可投金额 > 个人余额
# 投资金额 > 标的可投金额 #满足这种条件的标以及用户
1.金额的断言，我们是这样断言的。但是万一你在操作的时候，别人也在操作呢？
因为你还要调试，白天你还要冒个烟什么的。如果你正在操作的时候，别人也在操作同样的账号。你投资了一千，在你去检测的时候，人家顺便投了个两千出去了，就比你稍微慢一丢丢，那这个时候你来看你的可用余额，你会发现不对啊？少了三千块。
这个用例就错了，这个用例一错，你会怀疑为什么金额差距这么大呢？难道是个 Bug?
你就需要去验证。像这种情况下，我们该怎么办？
这个环境不止你一个人在用，别人也在用。但是这个东西是你的个人数据，不是公共，不像我们的标，是所有用户都可以操作的公共数据。
但是你的个人信息中的可用余额以及投资记录，如果也有人在用，也很可能造成你的断言结果不正确。
当你的项目组要求你做自动化测试的时候，别着急写代码，首先要有独立的测试账号。这个账号只有你用，其它人一律不许用。 告诉所有测试团队的人都是这么做。当然，有条件准备独立的测试环境更好，没有的话就和大家共用。
如果你的账号是你在用，别人也在用，一旦你的自动化用例运行失败，你敢说这个结果就是系统的问题吗？
你并不知道你在操作的时候，别人有没有在操作。
实际工作过程中也是这样的，先分析清楚了再写。不然就会经常写着写着写不下去了。
异常用例：有很多异常用例，有一些是方便填写的，比如投资金额错误，是非常容易处理的。
Web 自动化用到了回归，回归上面虽然有主流程，但是有一些异常场景。优先实现主流程，但是在你的任务计划当中，如果有一些异常场景也要写进来。
你把一些很好写的，没有太大数据准备工作的用例果断用代码实现，就不需要再手工考虑了。
2.但是有一些异常用例比较麻烦，比如全投操作。全投操作的前提是标的可投金额大于个人余额。大于你的个人余额的情况下，全投才有效果。
还有些比较极端的用例场景，投资金额 > 标的可投金额。这种情况下需要创造一个环境，首先你要找到一个标，可投金额你自己定，如果它的可投金额是 50 万，那你的投资金额就要改到 60 万。
需要找到满足这种条件的标以及用户，因为这个用户你是固定用同一个，想办法让它的金额发生变化，满足这个投资金额 > 标的可投金额条件。
好不好在前面正常场景的基础上再来创造一个这样的条件？
除非你自己创建一个全新的账号，自己创建一个这样的标，然后用另外一个账户。另外一个账户里面对金额既有要求，自己用接口添加一个标，这个标里面固定的投资金额是 50 万。那你确保你当前账号里面有 50 万以上，然后你用这个钱去投它，投它之后出现对应的提示信息。
但是，不是投完这个标就完了。在设计测试用例的时候，你这个用例执行完成之后，你还要恢复这个数据，不影响其它测试用例执行，但是实际情况下可能吗？
这种极端条件，这次自动化测试运行要满足，下一次自动化测试运行也要满足。这个做起来比较复杂。
要确保每次运行的时候都满足这样的条件，你还要确保它运行完成之后完全不影响别的操作。比如全投操作，如果你执行成功了，用户就没有钱了。没有钱了怎么办？那其它用例还要考虑钱够用不够用。
这样代价太大，所以，像这样的异常用例，手工测试一下吧。 也不需要每次都测试，在关键时候，手工测试下就好。比如要上线了，就针对这 2 个特意去测试下。其它的时候就不测试它了，只跑自动化用例能够实现的。
像这种异常用例，要考虑的条件非常得多，既不能影响其它也不能影响下一次运行，这个环境造起来成本很高。
容易实现的就先实现，不容易实现的，就先放着。等以后有心情有时间有条件的时候再来做这个事情。当然，你不实现它，你需要标识出来，方便后面的手工用例中独立得去运行就好了。
所以，把用例写好之后，把PageObjects补充完整，再去写测试用例就非常快了。
第一种，默认选择第一个：
不能通过href定位，里面有个 id，id 这个东西你是永远不知道它是谁的。标名不一样，自然这个 id 就不一样了。
通过文本内容或者这个class定位。
为什么不用轴定位？
找唯一的元素才用轴定位。而这里可以我不管它匹配到几个结果，但我只取第一个。
虽然有 3 个匹配，但是我现在就选匹配的第一个。不管是哪一个，不管标名是什么。
有 3 个没关系，默认第一个，就点击第一个就好了。
代码
#选标操作-默认选第一个 = 元素定位的时候，过滤掉不可以投的标。
#万一第一个标是不可以投的，第二个标是可以投的呢？
#因为不可以投的标，肯定是个不同的状态，跟可以投的标的状态是绝对不一样的。
#你在定位表达式中直接过滤它，马上就可以做到这个事情了。在过滤之后的标中，默认选第一个，
#因为xpath表达式可以匹配几个的。默认选匹配的第一个就好。
def click_first_bid(self):
pass
第二种，不想选第一个，我要随机选：
#随机选一个可以投资的标
def click_bid_by_random(self):
#找到所有符合的标
eles=self.driver.find_elements()
#随机数
index=random.randint(0,len(eles)-1)
eles[index].click()
1.为什么要len-1?
看源码是这样说的：
def randint(self, a, b):
"""Return random integer in range [a, b], including both end points.
"""
2.投资
#投资
def invest(self):
#在输入框中，输入金额
#点击投标按钮
pass
当非 10 的整数倍的时候，就点击下，点完后再去判断文本内容是不是我要比对的内容。如果代码报错，说是不能点击，不能点击的时候再把它分为 2 步。现在就把它按一步来写。
3.获取用户余额，要把它写在投资步骤一起吗？
只有投资成功才需要获取余额。异常用例不需要获取用户的余额。
4.什么都不输入，点击投标，弹出提示框：
需要获取它的提示信息，除它之外，需要把这个框 X 掉才行。
在我的异常场景当中，要不要把这个框 X 掉？还是说，我只断言它的错误提示是否正确。
在投资失败的用例当中，我是否只判断提示信息，还是说把框 X 掉，去用户的界面中看看金额有没有少？
要不要去看看用户的金额有没有变化？
怕万一投资金额失败了，系统有 Bug，结果还扣了钱。
这个因人而异，有的人写的测试用例中有这个断言，其它人可能就不写。有些地方你认为要断言，但是手工测试不想去看的东西，代码中就可以帮你去看。手工测试不想做这么全面的时候，代码可以验证的全面一些。
测试用例可以因人而异，但是框架都是不变的。
不同的项目，不同的人去测，做出来的东西绝对是有差异的，但是整体的框架是绝对没有差异的。
所以这个地方就随便自己，只是一个做的更全面，一个做的不全面一点，本人认为必须做，虽然做项目的时候暂时是没有问题，万一哪天出现你想都想不到的问题，所以在做自动化的时候把它覆盖一下是有必要的。 这样就确保一旦有问题，我马上就能发现，没有问题也不要紧，我很放心我做了。
如果接口测试做过了的，Web 页面就可以跳过不做。
5.为什么手工测试的点和自动化测试都会搞混？
本身手工测试的点和自动化测试很多都是一样的，Web 自动化测试和接口自动化测试也是黑盒测试，就是功能测试，当然点都是一样的。
自动化用例设计原则（重点）
1、不是所有的手工用例都要转为自动化测试用例。
2、考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分成多个用例来实现脚本。
3、选择的用例最好可以构建成场景。例如，一个功能模块，分多个用例，多个用例使用同一个场景。?
4、选择的用例可以带有目的性。例如，这部分是用例做冒烟测试，那部分用例是做回归测试等，当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。
5、选取的用例可以是你认为是重复执行，很烦琐的部分。例如，字段验证、提示信息验证这类，这部分适用于回归测试。
6、选取的用例可以是主体流程，这部分适用于冒烟测试。
7、自动化测试也可以用来做配置检查、数据库检查。这些可能超越了手工用例，但也算用例拓展的一部分，项目负责人可以有选择地增加。
8、平时在手工测试时，如果需要构造一些复杂的数据或重复一些简单的机械式动作，则告诉自动化脚本，让它来帮你，或许你的效率会因此而得到提高
在编写自动化测试用例过程中应该遵守以下几点原则：
1、一个用例为一个完整的场景，从用户登录系统到最终退出并关闭浏览器。
2、一个用例只验证一个功能点，不要试图在用户登录系统后把所有的功能都验证一遍。
3、尽量少的编写逆向逻辑用例。一方面因为逆向逻辑的用例很多（例如，手号输错有几十种情况）；另一方面自动化脚本本身比较脆弱，对于复杂的逆向逻辑用例实现麻烦且容易出错。
4、用例与用例之间尽量避免产生依赖。
5、一条用例完成测试之后需要对测试场景进行还原，以免影响其它用例的执行。
1.为什么说，不是所有的手工测试用例都要转为自动化测试用例？
有些太麻烦的事情，自动化的成本太高，如果这个用例我要用自动化实现，第一，浪费的时间太久了；第二，我浪费了这么久的时间，把它做成了自动化，结果发现稳定性不高，也就是动不动就挂了，动不动就失败了，不是这里不行就是那里不行。像这种情况下，干脆就不要做自动化了。不转换为自动化用例，标记为手工测试用例并说明原因。
Web 自动化用例最重要的原则就是稳定，如果用例写了 100 个，通过率只有 40%，怎么调试都通过不了 50%，那就好好审视下自己，到底是自己技术不行呢还是说我这个用例选的不行。用例太复杂就意味着实现的过程很多，出问题的点就非常多。有的时候我们写自动化用例，有的东西是场景性的，流程性的。
流程性的大家可能会去做。一个主流程，主流程当中涉及 5 个步骤，每个步骤当中，都是件不小的事情。这个如果你把它在一个用例当中，可能有 200 行代码，200 行代码是比较复杂的，前 10 行代码中只要挂一行就跑不通了。要维护 200 行，保证每一行都成功，你得浪费多长时间啊。像这种情况下，如果你实在做不到，可以把它拆分成 5 个用例，5 个用例之间是有先后顺序的。指明它的先后顺序，先执行谁，后执行谁，再执行谁。
这样把 200 行代码分成 5 个用例，每个用例不超过 40 行。如果你觉得 40 行太多，就再细分下，分成 10 个。
一个用例就是一个函数，一个函数就不宜太复杂，越复杂越难处理。
设计测试用例的时候肯定是想要构建用户的使用场景。用户的场景当中可能通用的数据，比如模块公共数据都会用一样的。作为一个用户，不会用很多类型的数据去做这样一件事情。
2.做自动化测试是因为项目需要才要去做。
在开始分析用例的时候，先想好什么样的用例做回归测试，什么样的用例做冒烟测试，那冒烟测试就是从回归用例中选出来的一些比较核心的用例，属于回归测试用例中的一部分。
一个用例为一个完整的场景，从用户登录系统到最终退出并关闭浏览器。稳定性和独立性是 Web 自动化的优先原则。无论其它用例有没有执行，无论其它用例执行成功还是失败，对于本用例而言，完全不受任何影响。
3.一个用例只验证一个功能点，不要试图把所有的功能都验证一遍。
在设计投资用例的时候，这个用例中不需要算利率，因为我的目标只有一个功能点。能够投资成功，钱有没有少，就这两点。其它的不管，如果有额外的，再去设计就好了，反正写代码都执行下，都没关系的。
像这个前置条件，用户登录成功，不要去断言用户是否已经登录成功。一个用例当中断言只用在你认为本用例当中需要比对的地方，其它的东西都是你应该执行的步骤和前提。这里只需要调用登录就可以了，不需要管它成功或失败，因为你在执行测试用例的时候，如果用户登录没有执行成功，它一定会报错。马上就知道这个用例失败了，但是这个不是你要写断言的地方。
而单独写登录的时候，确实是要断言的。
4.逆向逻辑的用例：
#舍弃----以后手工测试可以单独测试这块
#异常用例：全投操作？ 标的可投金额 > 个人余额
# 投资金额 > 标的可投金额 #满足这种条件的标以及用户
5.用例与用例之间尽量避免产生依赖：
就像投资用例和登录用例就没有关系，各自干各自的事情。每个用例准备各自的前置，而且每个用例之间也要做到互不依赖。
除非是没有办法，一定要依赖，那就是流程性质的用例。 流程性质的用例，没有办法，因为我把它拆成 3-4 个用例，它是一定要依赖前面一个成功的，后面一个才能执行。
6.一条用例完成测试之后需要对测试场景进行还原：
def setUp(self):
pass
def tearDown(self):
pass