互联网产品的測试

首先说下。我们团队没有測试人员。所以測试任务由产品助理来负责。

在互联网行业，规模比較小的公司团队，測试任务也多是由产品人员负责的。由于他们对做的出来的东西比較了解。互联网项目一定不能少了測试这一环境。不管是内部项目还是对外项目。人总是要求自己安心，还有别人放心。

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

了解需求文档和项目原型

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

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

举例说一下产品需求文档。以下是一个文章信息公布模块的需求文档：

信息公布的需求

1.可分类显示信息。可删除、加入、改动新闻信息的类别。

2.可依照信息类别查询、加入、删除、改动某一条新闻信息。

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

4.能够让某条重要信息固定出如今全部信息的最前面。也可让某条信息固定在某一类别信息的最前面。

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

…………

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

写測试用例

在project师開始进行开发时我们就能够写測试用例了，我的測试用例一般就是两种，一种是用MindManager思维导图，一种是用EXCEL表格，因为自己感觉表做起来好头疼，所以有时就用Word文档。

用思维导图能起到梳理思路的作用，从总体到每一个分支，每一个技术点都有他须要注意和測试的内容，当然你不必写的太具体，仅仅要把纲列出来就差点儿相同了。而当中的细节通过大脑的联想也会基本概括了。而文档写測试用例的作用是能够给project师看作为他的辅助，还能够用来记录測试结果。

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

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

以下这张图是測试用例文档。能够依据详细事宜设计详细文档，測试用例文档应该是没有固定格式的，当中的几个栏目要点也是有的能够省略。有的能够加入。

假设最后须要领导看的话，最好把測试结果写清楚。

。

測试的实施与管理

我们知道有BugFree，Bugzilla等bug管理系统，他们能让我们更高效的提出bug和管理bug，对測试出的bug有分级和指派等功能。可是总是认为这些管理系统，从安装，维护，到管理对互联网行业来说有些局限性。因为互联网更新速度块，讲究速度与创新，所以在bug管理这方面，最好也用互联网思维去解决。

在这里。有一个在线项目协作管理工具就挺好，它就是Tower。非常多人都知道它，如今非常多创业公司都是使用的它，这是一个趋势吧。

在使用它的过程中，我们每开展一个项目，就为它创建一个项目測试专题模块。然后把測试中的问题提到这个模块。

怎么表述和提交就不细说了，依照自己和程序人员的习惯即可。

我们把每一个问题指派给负责他的人。他也能够又不懂的在上面进行回复沟通。对于重要的问题。能够对题目进行标注。加急处理。也能够把问题当做任务指派给某个人。最后勾选完毕就能够了。

当然已经完毕的任务也是能够再打开的。由于可能由于后期某些改动更新出现新的问题。使得其不得不进行回归測试。

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

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

团队协作，交给用户

有时候因为时间紧迫或者项目工作量大等，须要团队其它人员的协助。

对于一些client产品。须要非常多类型的手机或者平板等，也须要动用公司的全部人来进行測试。

比方各个手机上的现实问题，兼容问题。不同浏览器的兼容问题等。

也能够吸取其它公司的经验，就是有奖測试。

在进行完常规測试后把项目版本号发给每个公司人员。随測出来新的问题或者提出新的解决方法就给予他们奖励，这样就更好的完好了产品。

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

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

关于自己主动化与工具

当中包含回归測试工具，性能測试工具，浏览器兼容測试工具等。依据项目的不同需求会须要不同的自己主动化工具辅助进行測试。

比方回归測试。

它是依据修复好了的缺陷再又一次进行測试。目的在于验证曾经出现过但已经修复好的缺陷不再又一次出现。一般指对某已知修正的缺陷再次环绕它原来出现时的步骤又一次測试。通常确定所需的再測试的范围时是比較困难的，特别当临近产品公布日期时。由于为了修正某缺陷时必需更改源码，因而就有可能影响这部分源码所控制的功能。

所以在验证修好的缺陷时不仅要服从缺陷原来出现时的步骤又一次測试，并且还要測试有可能受影响的全部功能。因此应当鼓舞对全部回归測试用例进行自己主动化測试。

工具如Selenium等。

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

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

这就是互联网产品的測试总结，或者说一个小的互联网团队的測试总结，写的时候也借鉴了其它两篇网上的文章。与其还是有非常多相通之处。

我仅仅是大致的描绘，应该有人有其它更好的全面仔细的经验。

转载出处：http://www.jianshu.com/p/715b01c22164

转载于:https://www.cnblogs.com/gccbuaa/p/6887890.html