作为一个测试，最尴尬的莫过于分给你的task，别人做交叉兼容测试的时候，在你负责的内容里找出了很多你没有测试出来的bug。

　　我也曾因为测试不全被组长在工作群里艾特。说实话，真的恨不得找个地方躲起来。

　　为了避免自己再次出现类似的情况，我开始写测试笔记。记录负责task中需要测试的内容，然后不断的重复研究测试，这种情况就基本没有了。

　　复杂的测试笔记，我写了有两年，后来慢慢发现好多东西都是相通的。于是，我整理了一个做测试的模板，每次新分配给我task时，我都按我自己的模板测试。

　　我做的工作是黑盒测试，基本属于纯黑盒。测试的有web端，android手机端和ios手机端，偶尔也会测试手机带的浏览器，所以我的这个模板应该更多的适用于黑盒测试。

　　当然，如果你做的是别的测试，也是有参考意义的。

　　由于我测试的软件公司要求不对外，所以模板的内容，我用文字来叙述。我自己用的时候，也全部用的文字版。因为我写的这个模板就是为了最大的简化测试，所以写的时候也只有文字版。我的同事也借用了这个文字版的模板，效果也很好。

　　下面是我总结的模板的内容：

　　task名：在这里列出你要测试的内容。比如：测试手机app的功能区。

　　1.找测试入口：找出能进入这个功能的各个入口，并罗列出来。

　　如果是因为不同的账号入口不同，也记得在这里标注出来。

　　2.具体测试

　　2.1功能和UI测试=对着需求文档测试。

　　· 一行内容一行内容的测试；

　　· 文字&图片从上到下，从左到右测试，尤其注意图片中图标的位置、大小等是否符合给的需求图。需求文档内容是否合理等。

　　· 注意错别字和错误使用的标点符号。

　　2.2抛开需求文档测试

　　这里补充一些内容：首先我们要知道，我们测试的软件都是由一个一个的页面组成的。而每一个页面，都有不同的内容，我把页面中的内容称为内容项，比如按钮，比如图标等等。我们做测试其实就是对页面的测试，更具体的就是针对页面中有的内容项的测试。

　　那么做测试的时候，就从进入功能的第一个页面开始，每个页面做如下测试：

　　①页面内容项的查、增查、改查、删查以及页面内容项的其它(点击、跳转、切换、刷新等)的测试。只针对单个内容项，注意无数据，数据少和数据多的情况。

　　比如你测试的页面中有一个显示控件，显示用户头像。那么针对这个内容项的查、增查、改查、删查以及其它测试为：

　　· 查：看进入后显示的是什么，是否符合需求。

　　· 增查：这里用不到。

　　· 改查：改变用户的头像，看怎么显示；改变后重新进入页面又如何显示；从下一级页面返回又如何显示。总之就是对这个内容项找出你能想到的一切测试内容。

　　· 删查：如果删除这个用户，应该怎么显示。

　　· 其他测试：点击这个控件，页面是怎么跳转的。

　　②测试步骤的排列组合测试

　　比如需要上传头像和名字。那么测试的时候，就可以先传头像再传名字，或者先传名字再传头像。

　　③涉及常用功能的测试

　　常用功能有：进页面刷新、下拉刷新、上拉刷新、刷新、删除、编辑修改、左滑删除(空白的地方也滑一下)、刷新+编辑、编辑+刷新、回到顶部、点击放大等。

　　④页面的点击测试

　　页面上所有内容：从上到下、从左到右全部点击一遍。无论按钮、图标、横线、空白等任何位置。从而避免出现不能点击的可以点，可以点的不能点的情况。

　　3.android/ios/web三平台配合测试

　　android加的内容：android、ios和web能否正常显示。

　　ios加的内容：android、ios和web能够正常显示。

　　web加的内容：android、ios和web能够正常显示。

　　除了测试加内容，还可以试试改和删除内容后，另外的平台是否可以正常显示。

　　其实以上的内容，就是给测试找的方向，在我的工作中，基本涵盖了我要测试的所有方向。测试的时候，利用好自己学的测试理论，再结合这些测试方向，多多发散思维测试。基本上很少会有漏测的内容。

　　对于新分配的task我们可以按上面的内容测试。有的时候，分给我们的内容，可能是之前的功能，只是新开了一个入口。可能我们只是大致记得功能点，具体的需求文档估计也不太好找了。那我们对这个新入口的测试也可以按照上面的方向测试。

　　我们做测试工作的，付出基本是和成绩成正比的，bug就在那，你多多发散思维测试，总能找到它。

作者：蓝羽    

来源：http://www.51testing.com/?action-viewnews-itemid-7800282