突然想起来，暂时记录下来，也许对后来的框架改造有帮助。
1.目前我的测试检查点的正确性判断与手工测试没什么区别，即在测试用例中给一个预期结构，通过页面获取元素值与其比较，这其实局限性很大：（1）.感觉是为了自动化测试而自动化;
（2）.预期结果大多数来自初始化的数据，实际，基本上是在数据库加数据，这样应该是不能在线上环境运行的；
（3）.实际结果与预计结果不一致时，不能断定就是有问题，有可能是预期结果数据未更新，实际这未做到完全自动化。
设想如下：
目前页面显示的数据大部分是来自服务端接口的返回参数值，有些是页面自己写死的，对于后者，自动化反而很简单，而对于前者，是否可以这样想：
（1）.如果平台做接口测试，那么我默认做过测试的接口所返回的数据是正确的，那么我只要检查页面值是否与接口返回值一致便可，举例如下：测试用例中包含数个查询条件，其查询结果覆盖的场景包括无数据、一条数据、分页数据，针对不同的查询结果，通过调用不同的查询场景组建来比较接口与页面值，达到比较真实模拟查询场景，同时在测试报告中应该涵盖本次查询测试覆盖到的场景（本次只覆盖了无数据和一条数据，未覆盖分页数据），有利于测试人员分析结果;
（2）.如果没有做过接口测试，或者接口测试结果还不稳定，那就从源头获取数据（数据库，redis等）来比较，其后面的处理与上面类似
可能存在的难点：
1.接口参数与页面参数如何对应，如果人工建立关系，其成本较高，但是也仅限于第一次，需要建立对应关系，如果接口参数变化，只需要维护对应的关系便可；
2.对于直接查数据源的，涉及多表联查，redis查询语句，其一需要查询语句可配，其二对应关系可配，便于维护，其三应该减少数据查询次数，避免多次建立链接
计划：针对上面说的查询类场景做做实验
