首先说下，我们团队没有测试人员，所以测试任务由产品助理来负责。在互联网行业，规模比较小的公司团队，测试任务也多是由产品人员负责的，因为他们对做的出来的东西比较了解。互联网项目一定不能少了测试这一环境，无论是内部项目还是对外项目。人总是要求自己安心，还有别人放心。
互联网产品的测试较之软件行业的测试技术上没有那么复杂，但是变化性和更新迭代性比较其略有增加。我们主要实现的是对其产品功能的测试，目的就是为了检验最后工程师与设计师做出来的产品与我们最初确立的需求和预期是否吻合，还有就是发现其中明显的使用缺陷和实施错误。测试的结果是一个产品是否完成的标准，也是一个产品成功迭代更新的保障。
了解需求文档和项目原型
很多公司没有专门的需求文档，在此我们可以把市场客户调研问卷，产品立项会议记录，策划人员产出的ppt等等作为需求文档，我觉得所有和这个项目有关的文档都是需求文档。然后是项目原型，因为项目原型是通过需求讨论而产生的，在一定程度上已经相当全面的体现了需求。原型通常由产品经理和助理负责，所以他们也是最清楚需求的人。
对于对产品了解的人来说其实需求文档就在你的脑子里。
举例说一下产品需求文档，下面是一个文章信息发布模块的需求文档：
信息发布的需求
1.可分类显示信息，可删除、添加、修改新闻信息的类别。
2.可按照信息类别查询、添加、删除、修改某一条新闻信息。
3.新闻能够显示图片和文字，允许且只可以上传图片及压缩格式文件，新闻信息可以附带其他下载资料，如新商品的使用说明书等。
4.可以让某条重要信息固定出现在所有信息的最前面，也可让某条信息固定在某一类别信息的最前面。
5.可以显示浏览者对某条新闻信息的阅读次数。
…………
然后是产品原型，他更直观的表现了我们要做的东西，对测试来说，需要清楚地认知他的各部分模块功能还有内容是什么。而一些细节和可能出现的问题都想用下面的东西来解决，它就是测试用例。
写测试用例
在工程师开始进行开发时我们就可以写测试用例了，我的测试用例一般就是两种，一种是用MindManager思维导图，一种是用EXCEL表格，由于自己感觉表做起来好头疼，所以有时就用Word文档。
用思维导图能起到梳理思路的作用，从整体到每个分支，每个技术点都有他需要注意和测试的内容，当然你不必写的太详细，只要把纲列出来就差不多了，而其中的细节通过大脑的联想也会基本概括了。而文档写测试用例的作用是可以给工程师看作为他的辅助，还可以用来记录测试结果。
测试用例一定要拿出单独的时间来完成，最好不要与其他工作交织着进行，是为了更安静的总结你自己的思路。
下图是某项目思维导图的一部分，在此把此模块各个分支都列出来了，但是并没有详细预测列出测试点，因为第一太费时间，第二具体实践过程中会出现各种情况，包括以下问题但不限于以下问题。
下面这张图是测试用例文档，可以根据具体事宜设计具体文档，测试用例文档应该是没有固定格式的，其中的几个栏目要点也是有的可以省略，有的可以添加。如果最后需要领导看的话，最好把测试结果写清楚。
测试的实施与管理
我们知道有BugFree，Bugzilla等bug管理系统，他们能让我们更高效的提出bug和管理bug，对测试出的bug有分级和指派等功能。但是总是觉得这些管理系统，从安装，维护，到管理对互联网行业来说有些局限性。由于互联网更新速度块，讲究速度与创新，所以在bug管理这方面，最好也用互联网思维去解决。在这里，有一个在线项目协作管理工具就挺好，它就是Tower，很多人都知道它，现在很多创业公司都是使用的它，这是一个趋势吧。
在使用它的过程中，我们每开展一个项目，就为它创建一个项目测试专题模块。然后把测试中的问题提到这个模块。怎么表述和提交就不细说了，按照自己和程序人员的习惯就行。我们把每个问题指派给负责他的人，他也可以又不懂的在上面进行回复沟通。对于重要的问题，可以对题目进行标注，加急处理。也可以把问题当做任务指派给某个人，最后勾选完成就可以了。
当然已经完成的任务也是可以再打开的，因为可能由于后期某些修改更新出现新的问题。使得其不得不进行回归测试。
这样既起到了提交作用，又起到了纪录作用，还一定程度上完善了远程沟通。最重要的的是，Tower有时效性，更新速度块，一个程序和网站可能有多个版本。有针对性，指派任务明确，大家都有责任感。不死板，系统界面生动，沟通人性化，工作有热情。
在进行一般两轮测试提交和修改之后，等到上面的任务都完成，测试也就接近尾声了。
