| ID | TestCase | Premise | KeywordDriven | ParameterInput | EcpectedResult | Remarks |
| 1 | 输入站点，可正确访问主页面 | 我所调用的函数名 | http://www.baidu.com/ | Y | 仅从功能点出发，若再细致点，可以考虑下最后这个斜杠； | |
| 2 | 页面正常展示（图片，链接） | Y | 这里不需要输入，只需要取出所有的链接以及图片即可；图片验证的时候，只需要取出对应的url拼接下，看是否可访问即可，链接更容易验证；需要注意的一点是，在验证这些问题时，我们不需要再思考后续的站点，只需要检查下http返回值即可 | |||
| 3 | 使用正确的用户名登陆 | username：zhoujun；password：123456 | Y | 类似这类问题验证时，可能需要考虑的东西比较多：1.登录时长，若一直卡着怎么办；2.用哪些内容去证明我登录成功还是失败了；当然也可以在这里加个计时器，计算下我登录的耗时； | ||
| 4 | 异常登录1 | username：xxx；password：123456 | N | |||
| … | … | username：zhoujun；password：abcd | … | |||
| 下载 | sdk name | 这类下载问题需要考虑：1.可下载；2.下载的东西是正确的；需要解决一些问题：1.下载的时候我是不可控制的，即我无法获取下载是否完成；2.若下载内容过大时，就会对1的解决造成很大麻烦；3.每次下载并验证完毕后，我需要删除避免对下一次验证造成影响； | ||||
| 对于浏览器的一些基本操作，个人感觉对上述操作外，基本无其他需要考虑的了，而针对于这些操作，最难的可能是并不是函数功能的实现，而是他的稳定性。我对这一套链路的思路包括，用例设计、函数实现，结果对比； 用例设计就如上面这类格式，使用关键字（其实就是个函数名）去驱动； 这里有一点值的我考虑，我是对每一条用例都做一次打开浏览器呢，还是从头到尾只开一个浏览器的进行操作；可能后者效率会比较高，但是关联性太大，不易控制，前者则更为容易控制，前提是若有成百上千的用例，难道我就要不停的开、关浏览器么？ |
对于上述备注的一些问题，除了下载的控制没法做外，其余问题均可有效解决； 当然对于整个测试方案来说，需要考虑的东西远远大于这些，兼容性，缓存，很多功能点并不是那么容易实现的。 还有一点，忘了写了。。。JS！ |
|||||