原来我的测试工作再他们眼里就是做这么小白的事情，怪不得工资低低呢。
不过，工作一半是为了赚钱。一半是丰富生活嘛。。所以该努力的还是要努力，不然只会对不起自己。
最近测一个网站的后台管理，包括学生、老师、学校班级的信息处理，简单的说就是增删改。
因为是要测的时候才被通知有这个项目，而且这次也没有需求（自然没有需求大纲了），所以就完全盲测，让我和开发方都没有想到的是，发现了硕多错误，两周都没有结束“本应该简单的工作”，另，更验证了那句，错误出现多的地方，还隐藏着更多的错误！
这次工作让我对没有大纲和用例的测试重新审视了一下，优缺点可以列成下面这样：
优点
这种工作方式这么不符合满天飞的规范，为什么还有优点呢？因为存在即合理嘛。现在很多项目，由于用户、开发等种种原因，工期紧人手紧变化快，从实际角度来说根本无法按这规那范来做，但是负责的人还是希望能通过某种方式对系统进行测试，于是这种形式的“盲测”是必要的。
如果1不算是优点，那么这种方式的测试，随叫随到随时开始、不需准备不耗费过多的项目时间，测试的人完全可以身兼数职增加人力利用，这应该算了吧？ 对于周期短的项目。
另外从私人角度讲，这样的测试工作很有弹性，你可以说一天就结束，也可以拖一个星期还说没有完，想偷懒的人也大可放心的啥都不做，等时间到了交工就可以。
如果你能没有文字也能有条理的进行测试并喜爱探索式的工作，那么这种方法还挺适合你，因为他会让你感觉到喜悦和无约束，相反的写出大量步骤重复的用例文档反而让人感觉不爽。
缺点
缺点多了去了！测试完全没有计划，无边无界而且没有什么可见性，测了哪些漏了哪些除了做的人知道外别人一概不知，如果测试者记性差的话，说不定完全不知道做了哪些方面的测试。
效果跟执行测试的人的经验、责任心具有绝对正比的关联,而且再高级的测试人员可能也无法确保这样散漫的工作的效果会高于有计划有依据的测试。
无法提供合理的文档来应付各类规范的检查。
测试的人如果不主动思考，可能无法从这样的测试中积累经验，工作不能带来进步，直到最后厌倦。
...
其实不管理想情况下是多么的美好，我们还是在现实中度日，所以应付这样的工作，还是需要一些方法，怎样让自己能用条理的做测试工作，最近我在这样思考着。
文章来源于领测软件测试网 https://www.ltesting.net/