看了关于软件盲点的帖子，每个人都有不同的建议，没有统一起来，所以决定将相关有意义的说法整理一下：

　　1、简单的说，需求上明确要求的，你写成案例都应该是有效案例，在保证了基本需求用例覆盖后，再逐步的增加案例的类型考虑意外的情况等等

　　测试是计划出来的，不是测出来的

　　2、建议从被测应用所涉及的实际业务开始学习起。

　　3、对于一个用例能解决所有问题的方法只有在不断累积的基础上才能完成，不过，可能到时候会发现－－此用例太臃肿了……

　　4、不知道你对有效用例和无效用例怎么划分的？

　　能够检查出错误的用例是有效的？-------对于已知错误编写的用例，算测出了这个错误也不能说是有效的吧？

　　不能测试出错误的用例是无效的？-------对于你觉得这个地方比较容易出现缺陷而编写的用例，算是没有测出问题，应该也不能说是无效吧？

　　5、测试用例是不断的扩充，修改出来的，现在好象还没有谁说能够让一套测试用例贯穿整个软件开发周期的啊！

　　6、首先我觉得如果你想在测试行业发展的话，你应该自己去找一些测试相关书籍去学习，这当然是要靠自己了；另外你可以去你们的用例库看看别人写的用例，同时请教公司的前辈，切记要虚心！把每天学到的东西记下来；还有是好好的看需求，深入的挖掘和分析其显式的和隐式的需求，明确需求后你才知道要测什么？测试的目的是什么？再是用例设计方法了，常用的有等价类边界值法，因果图判定表法，状态迁移图法，流程图法，正交分析法，异常分析法，错误处理法等；后你把平时工作中的成功和失败的经验教训都记下来，因为测试也是需要经验积累的。

　　7、设计有效的测试用例，你可以站在前的人肩膀上：

　　针对本次你负责的项目，分析查看以前类似项目的用例是怎样设计的，和其它的有经验的测试人员交流，分析他们是怎样去设计用例。分析以前项目的缺陷报告，缺陷多是由于什么原因引起的。想信经过分析以后你会有很大的收获。

　　8、用例除了要在需求基础上，也要从业务逻辑上，还有平时测试的经验上来，主要从这几点上考虑

　　9、软件测试是有2种假设前提的。1）假设软件是正确的，我们写测试用例，测试软件等等完全是为了证明软件的正确性；2）发现了错误与漏洞，及时正确改正，那么软件还是正确的，测试到后都始终坚信软件是正确的。不知道如果这样的话，你估计会从始至终都会认为你所做的测试是无效的呢。

　　10、假设软件是错误的，也是说错误随处可见，测试的目的是为了发现软件的错误而努力的尽可能广得进行软件测试，当发现问题时会发现软件确实存在错误，假设是正确的，这样测试是为了发现尽可能多的错误而存在的。这样，发现错误和不发现错误都是有效的。

　　所以说任何测试，任何测试用例，只要按需求走，都是有效的；

　　本人意见，测试对象不同，测试目的不同，测试方法不同。学会有计划性的测试，比盲目的下手，能更深刻的理解测试的目的，也才能在实际的测试中做到有效而不被动。