互联网产品的测试

首先说下，我们团队没有测试人员，所以测试任务由产品助理来负责。在互联网行业，规模比较小的公司团队，测试任务也多是由产品人员负责的，因为他 们对做的出来的东西比较了解。互联网项目一定不能少了测试这一环境，无论是内部项目还是对外项目。人总是要求自己安心，还有别人放心。

互联网产品的测试较之软件行业的测试技术上没有那么复杂，但是变化性和更新迭代性比较其略有增加。我们主要实现的是对其产品功能的测试，目的就是 为了检验最后工程师与设计师做出来的产品与我们最初确立的需求和预期是否吻合，还有就是发现其中明显的使用缺陷和实施错误。测试的结果是一个产品是否完成 的标准，也是一个产品成功迭代更新的保障。

了解需求文档和项目原型

很多公司没有专门的需求文档，在此我们可以把市场客户调研问卷，产品立项会议记录，策划人员产出的ppt等等作为需求文档，我觉得所有和这个项目 有关的文档都是需求文档。然后是项目原型，因为项目原型是通过需求讨论而产生的，在一定程度上已经相当全面的体现了需求。原型通常由产品经理和助理负责， 所以他们也是最清楚需求的人。

对于对产品了解的人来说其实需求文档就在你的脑子里。

举例说一下产品需求文档，下面是一个文章信息发布模块的 需求文档 ：

信息发布的需求

1.可分类显示信息，可删除、添加、修改新闻信息的类别。

2.可按照信息类别查询、添加、删除、修改某一条新闻信息。

3.新闻能够显示图片和文字，允许且只可以上传图片及压缩格式文件，新闻信息可以附带其他下载资料，如新商品的使用说明书等。

4.可以让某条重要信息固定出现在所有信息的最前面，也可让某条信息固定在某一类别信息的最前面。

5.可以显示浏览者对某条新闻信息的阅读次数。

…………

然后是产品原型，他更直观的表现了我们要做的东西，对测试来说，需要清楚地认知他的各部分模块功能还有内容是什么。而一些细节和可能出现的问题都想用下面的东西来解决，它就是测试用例。

写测试用例

在工程师开始进行开发时我们就可以写测试用例了，我的测试用例一般就是两种，一种是用MindManager思维导图，一种是用EXCEL表格，由于自己感觉表做起来好头疼，所以有时就用Word文档。

用思维导图能起到梳理思路的作用，从整体到每个分支，每个技术点都有他需要注意和测试的内容，当然你不必写的太详细，只要把纲列出来就差不多了，而其中的细节通过大脑的联想也会基本概括了。而文档写测试用例的作用是可以给工程师看作为他的辅助，还可以用来记录测试结果。

测试用例一定要拿出单独的时间来完成，最好不要与其他工作交织着进行，是为了更安静的总结你自己的思路。

下图是某项目思维导图的一部分，在此把此模块各个分支都列出来了，但是并没有详细预测列出测试点，因为第一太费时间，第二具体实践过程中会出现各种情况，包括以下问题但不限于以下问题。

下面这张图是测试用例文档，可以根据具体事宜设计具体文档，测试用例文档应该是没有固定格式的，其中的几个栏目要点也是有的可以省略，有的可以添加。如果最后需要领导看的话，最好把测试结果写清楚。

测试的实施与管理

我们知道有BugFree，Bugzilla等bug管理系统，他们能让我们更高效的提出bug和管理bug，对测试出的bug有分级和指派等功 能。但是总是觉得这些管理系统，从安装，维护，到管理对互联网行业来说有些局限性。由于互联网更新速度块，讲究速度与创新，所以在bug管理这方面，最好 也用互联网思维去解决。在这里，有一个在线项目协作管理工具就挺好，它就是Tower，很多人都知道它，现在很多创业公司都是使用的它，这是一个趋势吧。

在使用它的过程中，我们每开展一个项目，就为它创建一个项目测试专题模块。然后把测试中的问题提到这个模块。怎么表述和提交就不细说了，按照自己 和程序人员的习惯就行。我们把每个问题指派给负责他的人，他也可以又不懂的在上面进行回复沟通。对于重要的问题，可以对题目进行标注，加急处理。也可以把 问题当做任务指派给某个人，最后勾选完成就可以了。

当然已经完成的任务也是可以再打开的，因为可能由于后期某些修改更新出现新的问题。使得其不得不进行回归测试。

这样既起到了提交作用，又起到了纪录作用，还一定程度上完善了远程沟通。最重要的的是，Tower有时效性，更新速度块，一个程序和网站可能有多个版本。有针对性，指派任务明确，大家都有责任感。不死板，系统界面生动，沟通人性化，工作有热情。

在进行一般两轮测试提交和修改之后，等到上面的任务都完成，测试也就接近尾声了。

团队协作，交给用户

有时候由于时间紧迫或者项目工作量大等，需要团队其他人员的协助。对于一些客户端产品，需要很多类型的手机或者平板等，也需要动用公司的所有人来进行测试。比如各个手机上的现实问题，兼容问题，不同浏览器的兼容问题等。

也可以吸取其他公司的经验，就是有奖测试。在进行完常规测试后把项目版本发给每一个公司人员，随测出来新的问题或者提出新的解决方法就给予他们奖励，这样就更好的完善了产品。

交给用户，最终的使用者是用户。

在我们把它交给用户之前，我们已经做了上面的团队测试。基本不会出现特别大的失误和低级错误，甚至已经趋于完善。接下来就让用户去内测吧，来看看他们的智慧吧。而对于针对企业客户的项目，可以让他们自己或者他们的几个客户先体验一下。

关于自动化与工具

其中包括回归测试工具，性能测试工具，浏览器兼容测试工具等。根据项目的不同需求会需要不同的自动化工具辅助进行测试。

比如回归测试。它是根据修复好了的缺陷再重新进行测试。目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围 绕它原来出现时的步骤重新测试。通常确定所需的再测试的范围时是比较困难的，特别当临近产品发布日期时。因为为了修正某缺陷时必需更改源代码，因而就有可 能影响这部分源代码所控制的功能。所以在验证修好的缺陷时不仅要服从缺陷原来出现时的步骤重新测试，而且还要测试有可能受影响的所有功能。因此应当鼓励对 所有回归测试用例进行自动化测试。工具如Selenium等。

使用的目的是为了节约时间与人力，这样的前提下，如果它们提高了我们的效率会让事情更完美。

附件： 一个简单的思维导图

这就是 互联网产品的测试总结，或者说一个小的互联网团队的测试总结，写的时候也借鉴了其他两篇网上的文章，与其还是有很多相通之处。我只是大致的描绘，应该有人有其他更好的全面细致的经验。