三、什么情况下不适合写测试用例

　　文件时间

　　如果一个功能我很快就测试完了，而且只需要测试一遍，但我们设计测试用例时却比较麻烦，花时间也长。这个时候就没必要编写测试用例了。

　　需求变动大且频繁

　　需求的功能变动非常频繁，而且变动很大，之前编写的测试用例根本没法使用，必须要重新编写，这个时候也没必要去设计测试用例了。

　　项目时间不允许

　　这一项是不太厚道的做法，如果不是急需交付客户的话，尽量不要这样做；当然了，如果只是给客户展示或试用，可以在之后进行补充和完善测试用例。

　　不要编写不完整或别人看不懂的测试用例，那样就没有意义了。

　　==========================================个人闲聊内容，欢迎指正===================================

　　四、停止软件测试的标准。

　　语句覆盖最低不能小于80%，测试需求覆盖率达到100%，测试用例覆盖率达到100%，一、二级缺陷修复率达到100%，三、四级修复率达到80%。

　　（上面一句是再网上找的，不是标准，只是个参考）

　　bug等级：

　　一级：非常严重的bug
　　二级：严重的bug
　　三级：一般性的bug
　　四级：建议性问题

　　五、关于探索性测试

　　完全的执行测试用例时一件非常枯燥的事情，个人在执行测试用例时会做一些，其它的非常规性的操作，看系统是否会有相应的处理和提示。我的一部分bug就是再这种非常规操作下发现的。

　　当然了真正的探索性测试需要对产品的深入了解，以及软件开发技术有一定的深度和宽度。姑且把我们的探索性测试看成是瞎捣鼓吧！呵呵。

　　六、交叉测试

　　有木有发现，当我们第一遍测试系统时，会非常认真，但要我们测试第二遍时，我们不愿意像第一次那样认真的去测了，这不能说明我们不负责，而是每个人都有的心理现象。这个时候，我们可以和其它测试人员交换功能来测试，提高效率，而且更容易发现问题。

　　七、测试的目的

　　1、我们让它做的它必须会做。

　　2、我们不让它做的它必须不会做。

　　可能你会发现有附加功能的时候，就是客户没有要求，我们加了这样的功能，可能加了这点功能系统看上去会更好。这时怎么办？算问题么？

　　作为开发人员，中规中矩的做东西最好，如果真的有非常好的功能要加的话，需要和客户沟通，然后写到需求里。毕竟多一点功能多一点风险。呵呵

　　作为测试人员，凡是不符合需求文档的都需要当问题点提出。责任分明，以免后续麻烦。

　　----------------------------------------------------

　　修改：

　　1、测试用例的格式的要素，去掉“实际结果”

　　2、关于测试方法“等价类划分”的解释。

　　谢谢“zdd”朋友的纠正。:)