一、什么是TO模式
所谓的TO就是test object，通俗解释一下就是每个测试用例当成一个对象，给每个测试用例单独写个类，主要就是完成元素初始化和业务操作；
元素的定义与测试脚本分开，需要什么去调用即可。这样就是如果元素发生变化，你去维护Objects类即可，测试类你基本不用管
TO模式模型分析图
为何使用TO模式：
1、增强程序的可扩展性
2、减少代码的冗余
3、增强程序的可读性、可维护性
4、TO模式极其适合目前像自动化测试这样的小型项目，模式清晰、简单不复杂，恰如其分的满足项目所需
二、TO模式与PO模式的比较分析
什么是PO模式：
所谓的PO就是page object，通俗解释一下就是每个页面当成一个对象，给这些页面写一个类，主要就是完成元素定位和业务操作；至于测试脚本要和他区别开来，需要什么去这些页面类去调用即可。这样的好处就是如果页面元素发生变化，你去维护页面类即可，测试类你基本不用管。
PO模式模型分析图
相较于TO模式我们可以发现，PO模式多了一层page,且相关元素的初始化和页面逻辑处理都是在这一层处理，他是以页面为对象，封装对应页面所需的相关操作；然后某测试用例要想实现相关操作，只需调用对应页面封装的方法操作即可。
所以，相较于TO模式而言，PO模式可扩展性更强，且以页面为对象的设计思路，使代码的可读性更高；但是不足之处也在于次，以页面为对象的设计思路，使得相较TO模式会多出一个page层，项目层次对于这种自动化测试的小型项目太过复杂，有种杀猪用牛刀的感觉（注：在此分析优劣仅代表个人观点，至于哪种设计模式的选择可自由选择）
三、项目中TO模式的应用
以泰然金融自动化测试项目TRCASAppiumProject-auto为例：
base：主要定义一些test测试用例的相关基类（appium统一配置）、及共用用例
tests：测试用例脚本
ui.objects：以测试用例为单位的相关元素
utils：相关工具类
四、TO模式编写测试脚本
赞成为第一个赞同者
