2.对于分页，考虑未在首页的时候的测试，末页的情况。

　　3.对条件的查询来说，要针对于单个输入框的测试、交叉输入框的测试

　　4.对于删除、修改等，要考虑你删除完、修改完等测试用例的执行，往返测试

　　5.访问的渠道，通过搜索引擎、浏览器、收藏夹等通道进入。

　　6.先测什么而后测什么，不放过任何软件的死角。在测试中，一定要系统的看待问题，功能模块A的改动会否影响到其他模块的功能，不能想当然，一定要系统性的看待。有时候一个内存地址的改变，都有可能引起整个软件的崩溃

　　7.针对性能这块，应该采取什么手段进行操作，以便更全面去覆盖所有的点。性能通常进行负载测试、压力测试、安全性测试来校验。但如何入手得经过实践出真知。

　　8.针对于测试数据准备，我理解的数据准备原则应该是对web网站还是客户端来对于需要填写的数据进行验证，但有的数据是系统本身自带，需公司提供数据进行测试。但具体的数据需要多少还是很迷茫，数据来源从哪方面入手。执行是应该怎么执行

　　9.通过冒烟测试与第一轮迭代测试，发现许多不足的问题。1.不管你在进行什么样的测试，你必须依托于测试用例来执行，但对于一些用力不足的地方，可以不用依托于测试用例，如数据验证、随机测试等。在执行测试发现BUG了，要记录到缺陷管理系统，并记录BUG摘要、BUG的描述和步骤，这样不但可以节省测试人员与开发人员之间交流BUG的时间，还可以加速开发人员解决BUG的进度。

　　10.当提交BUG完，需开发人员去修复，并且发布，发布之后，测试人员在重新执行已发布的BUG，看是否解决，对于已解决选择关闭，对于未解决提出反馈。对全部已发布的BUG执行完，召开剩下未解决和已反馈BUG会议，会议主要针对于开发这边是什么问题导致这个BUG未解决还是遇到什么瓶颈，需要提供帮助。

　　11.测试人员和开发人员之间的协调能力很重要，遇到BUG或在规定时间BUG没解决，容易造成双方有争执现象，在开发和测试感觉必须要搭一个桥梁来使双方都能更好的处理之间产生的问题。

　　12.在研究一个BUG时，应考虑其类型、是否重复、哪种等级等，当我们在某种环境下发现BUG时，不是盲目的去登记，应考虑在多种环境下是否重现。

　　13.近阶段的执行测试，发现测试不是单纯的发现BUG，而是应该去协调一些未实现的功能更多去详细解释，以便开发更快的去实现其功能。

　　14.当我写入之前那么多BUG时，我发现并不是我想要，得不到那么多快感，我只是想说赶紧把未实现功能开发出来，不要总是在一直累积BUG，永远停留在那边，采取对开发人员去培训需求以便能够少出现更多的BUG。

　　15.安装在不同分辨率，不同操作系统环境下测试看是否出现问题

　　16.卸载后，是否出现桌面快捷方式、根目录、应用程序生成的文件夹是否还在残留着

　　17.在磁盘空间不足的情况下去安装、保存、导出，是否会出现问题

　　18.在测试时，注意操作上会因为失误而造成判断不精确