1.怎么判断测试有没有通过？
断言成功代表用例成功，断言失败代表用例失败。存结果，是因为如果这个用例失败了，还想看下接口当中到底给你返回的数据是什么，失败在哪里。
页面的断言是非常精细的，说好是哪个地方，就是哪个地方。如果失败了，就去看测试报告，测试报告会告诉你哪里不一样。
还会实现截图功能，都是页面操作，断言失败了，就去对它进行截图，看下当时的页面是什么样子。
2.为什么写功能测试用例？目的是把需求搞明白。
如果能把功能测试用例写出来，证明至少功能有几种用例，用例中涉及到的数据是什么，有什么样的前置条件，有什么样的操作步骤，我的预期结果是什么样。
有了这些基础后再去做自动化测试。把功能测试用例转换成自动化测试用例，再去用代码实现，就会简单很多。
3.自动化测试用例与功能用例有什么区别？
自动化测试用例和功能测试用例的区别就是每一步都要非常的清楚。 所以才需要做评审。
功能是一样的，意味着用例很多都是一样的。自动化用例和功能用例一样，有前置，有操作步骤，有预期结果。但是前置条件中的任何一个数据，操作步骤中的任何一个数据，以及预期结果的比对方式、断言方式，以及我要比对的具体数据是什么，必须全部写出来。
写自动化用例的时候，每个地方都要写清楚涉及的测试数据是什么。
4.Web自动化的断言怎么写？
例如登录，你怎么判断登录成功了？
登录成功后，在界面，肉眼看到账户用户名，例如看到退出按钮，就可以证明登录成功了。
输入账户密码登录进去，看到页面跳转，怎么在代码层表达页面变化？
肉眼看到账户用户名，例如看到退出按钮，找到2个中其中一个元素就可以了。这就是ui中的断言。
例如：首页-能够找到退出按钮/用户名
把手工测试过程中看到的东西，你自己默默作为断言的东西，转换成代码的方式就好了。
5.自动化代码可以验证样式嘛？可以验证错误提示语的位置和颜色吗？
自动化测试只是针对功能，对于页面的样式而言，并没有刻意去做这个事情。
它只针对功能正确与否，样式通过自动化的方式是不好判断的。样式是你要看到页面确实变成了这个样子，确实这块是红色的，即使获取了这块的背景色是红色，也没有看到页面真正的样子。所以如果确实想判断样式是什么样子，一般不会通过自动化的手段去实现，一般是自己看看就行。
图片比对有单独的专门的第三方库sikuli，不是现在这个。
如果想把功能测试转换成自动化的测试用例，正式写代码之前去看看你要写的功能，每一条用例的前置、操作步骤和预期结果。
首先心中有数，实际上功能测试用例比较多，如果它的前置条件比较复杂，有很多工作要准备，首先想清楚前置条件用什么样的方式来实现，好不好实现，好不好做。
实际工作中，预期结果这块可能要比对3-4个条件，这种情况下，你的断言就要出现3-4个断言。在功能测试用例这块做了筛选，再去写自动化测试用例，最起码心中有底，知道该怎么实现了。
6.自动化测试用例必备3大步骤：前置、步骤、断言
没有断言的都不叫做测试用例。
我们实际工作都是大型项目，至少100个用例起步，假设有15个功能，这时候功能交叉非常多，100多个用例之间肯定有重复的步骤，重复的可能性还不太一样。
登录基本上除了登录用例以外，其它的功能全部是以登录作为前提，甚至还有其它的操作作为前提。这样的交叉程度非常乱，也非常的高。对于这样的大型项目，有种混乱的感觉，关联性高，感觉要崩溃。
做项目的时候，可以采用这样的方式：PageObject这个东西叫做页面对象。
先知道PageObject的应用场景以及它这么做的原因。
7.PageObject模式测试思想：
例如有140个用例，都是测试人员在系统当中的页面之间操作。无论是哪个用例，它所有的步骤，所有的前置，所有的断言，基本上都是从页面来获取来操作，从来就没有离开过页面。前置有可能通过别的手段准备的，但是至少步骤都是在页面上操作的。
例如20个页面，不同的页面的功能串起来，形成一条完整的业务用例。业务用例肯定有页面的功能是一样的。目前20个页面，实现140个测试用例，将来涨到200个测试用例，20个页面。
20个页面，封装成20个类，把每一个页面都封装起来，封装它的功能，这个页面有10个功能就封装10个函数，有20个功能就封装20个函数。假设20个页面当中封装成20个类，如果每一个页面平均下来有5个小功能，那就是100个小功能。
用例本质是页面的功能串起来的。 需要哪个页面，就调用哪个页面的函数就可以。如果第一个用例涉及到5个页面，那就按照用例的顺序调用5个页面，表示5个步骤，断言的时候也可以这样来做。
每一个步骤操作都是在页面执行的，不同的步骤在不同的页面操作的。第一步：登录页面，第二步：首页，第三步：标详情页，第四步：个人信息页标详情页。每一步都是在不同的页面。
不管哪个用例来调，在所有用例当中，只有一份表达这个功能在这个页面类当中是做什么的。
不管几个用例来调用这个函数，万一界面中元素定位发生了变化、操作步骤或者功能发生了变化。只要修改当前封装起来的函数就好了。
其它所有用例来调用我的，还是照常用，用例不需要改。
把页面对象的操作全部封装起来，然后用例可以随便调用。如果用例在这个里面需要四个页面，那就调过去就好了。任何用例需要的，按照需求调用就行。
用例是我们自己设计的，知道调用什么，断言什么，自身应该非常清楚。实现了页面对象和测试用例的分离。
页面的功能全部都封装分离了，测试用例和页面功能分开了。 如果测试用例要增加/删减一些步骤等等，那就改变你的调用顺序，改变你调用的页面类的函数就可以了。
页面的功能相当于一个公共的措施。
例如100个人去泡澡，澡堂有公共的用品，100个人要用，自己去申请就好啦。如果公共用品发生了变化，本来浴巾的颜色是白色的，过了两天换成绿色的，大家再去领浴巾的时候就都是绿色的。澡堂提供的食品，今天给的是橘子，大家领的都是橘子，明天是香蕉，大家领的都是香蕉。
对于测试用例而言，所有页面功能都是独立封装起来的，都放在这里，要用就来领，但是所有人领的都是一模一样的。
这种模式适合页面级别的自动化，例如pc端、app测试、网页测试，只要操作是在页面上点来点去的，通用这种模式。
这个就是分层设计思想，测试领域用，开发就是用这个思想的，独立、好维护、又有关联性。但是不同的领域中，它的实现方式是有区别的。测试领域就叫做PageObject。
先理解这种概念，再用代码来一步一步实现这种思想。
未完待续~
