目前所在的公司，做测试的时候想要一个像样的大纲或者用例是困难的，一般用例是没有的（除非我自己加班加点的写），大纲一般就把需求列表搞出来（还是为了所谓的验收时用的，验收时，让用户、领导啥的看着系统各功能操作一遍），刚来的时候，有项目喊我测试，直接扔给我一个需求列表（还是只说了功能名字那种），然后说 你照着这个把每个功能用一下就行了。

　　原来我的测试工作再他们眼里就是做这么小白的事情，怪不得工资低低呢。

　　不过，工作一半是为了赚钱。一半是丰富生活嘛。。所以该努力的还是要努力，不然只会对不起自己。

　　最近测一个网站的后台管理，包括学生、老师、学校班级的信息处理，简单的说就是增删改。

　　因为是要测的时候才被通知有这个项目，而且这次也没有需求（自然没有需求大纲了），所以就完全盲测，让我和开发方都没有想到的是，发现了硕多错误，两周都没有结束“本应该简单的工作”，另，更验证了那句，错误出现多的地方，还隐藏着更多的错误！

　　这次工作让我对没有大纲和用例的测试重新审视了一下，优缺点可以列成下面这样：

优点
　　这种工作方式这么不符合满天飞的规范，为什么还有优点呢？因为存在即合理嘛。现在很多项目，由于用户、开发等种种原因，工期紧人手紧变化快，从实际角度来说根本无法按这规那范来做，但是负责的人还是希望能通过某种方式对系统进行测试，于是这种形式的“盲测”是必要的。
　　如果1不算是优点，那么这种方式的测试，随叫随到随时开始、不需准备不耗费过多的项目时间，测试的人完全可以身兼数职增加人力利用，这应该算了吧？ 对于周期短的项目。
　　另外从私人角度讲，这样的测试工作很有弹性，你可以说一天就结束，也可以拖一个星期还说没有完，想偷懒的人也大可放心的啥都不做，等时间到了交工就可以。
　　如果你能没有文字也能有条理的进行测试并喜爱探索式的工作，那么这种方法还挺适合你，因为他会让你感觉到喜悦和无约束，相反的写出大量步骤重复的用例文档反而让人感觉不爽。
缺点
　　缺点多了去了！测试完全没有计划，无边无界而且没有什么可见性，测了哪些漏了哪些除了做的人知道外别人一概不知，如果测试者记性差的话，说不定完全不知道做了哪些方面的测试。
　　效果跟执行测试的人的经验、责任心具有绝对正比的关联,而且再高级的测试人员可能也无法确保这样散漫的工作的效果会高于有计划有依据的测试。
　　无法提供合理的文档来应付各类规范的检查。
　　测试的人如果不主动思考，可能无法从这样的测试中积累经验，工作不能带来进步，直到最后厌倦。
...
　　其实不管理想情况下是多么的美好，我们还是在现实中度日，所以应付这样的工作，还是需要一些方法，怎样让自己能用条理的做测试工作，最近我在这样思考着。

　　我的目标是用最简单的方法获得最高的工作效率，不能因为环境不允许就降低工作质量和效率，以前工作的地方有个老师说过，几年以后变成什么样子完全由你自己来决定。

　　虽然我仍旧觉得我还是个新手，但是似乎已经找到套路，并知道要怎样才能提高。

　　关于没有大纲和用例的测试，对于功能和性能测试都是很有必要的，通常我们做的功能测试，在没有条件准备详尽计划的情况时，需要动一点脑子。

　　将被测对象分类，不是针对某项目，而是针对控件对象（或许这样并不准确，但大概是这么个意思），好比：输入框、列表（一般是查询结果列表）、按钮、链接、复选框、单选框等。然后再按照这些分类，针对每个控件做用例（要参照一些用例编写技术的），每做一次测试就做一个积累更新，发现新的需要测试的点，这个用例的文档不需要针对某个特定项目。他会用在你每次测试活动中。。。随着时间的推移，你的脑袋就是天然用例了。

　　另外你可以按功能分为新增、删除、修改、恢复、查询等，然后再分类写用例。

　　具体情况还要看你主要做哪种类别的测试吧，最近一年我都只做信息管理系统的测试，而且是.net 开发windows操作系统下的东西，所以现在一般都能知道容易出错的几个点。

　　有新项目时，就可以按上述两个用例来测试，他们不需要你很了解需求不需要任何准备，来就测，而且省时省力。

　　等你把上述两个用例上描述的东西都做过以后，估计就差不多了，但是在做这个工作之前，你需要找人（因为你可能确定不了）来保证这个系统是符合需求的，或者找一个合适的需求文档来验证需求的符合性。

　　其实从来没觉得做过的测试是有多高的技术含量，一直想知道高科技的测试是什么样子。可惜可以做高科技的测试的公司人家要求都好高，也不要我。。。。 所以我就个人开个小作坊。