测试用例设计培训.pptxVIP

测试用例设计方法问题：1.许多书籍上大篇幅教受的“等价类划分”、“边界值”、“错误推断” “因果图”等，大家应该运用的很少。2.好不容易完成用例的编写，可随之而来的新特性加入，让现有的用例非 常尴尬。3.很多用例几乎很少去执行（因为它们已经与实际程序脱节了）。4.执行现有的测试用例发现的很少。5.没有时间为新特性补偿新的用例，就算有时间补充但现有结构非常乱， 不知道从何入手。………我们的测试用例设计方法出问题了！那么原因何在呢？我们有很多的文档和书本定义，但它们适合我们的项目吗？什么用例才算是好的用例，评测标准何在？我们有太多项目经验，但却没有形成适合的规范!功能与业务脱节没有适合的规范界面用例并不等于业务用例，业务用例好惨，它被忽略了！造成发现Bug少，并且运用不到用例设计方法原因就在此。（等价类、边界值等方法本来就是偏向于功能及代码的）测试未能跟上变化版本越来越多，测试总是跟在需求和开发后面,不断压缩时间，都想早点投入测试，早发现Bug，忘记了用例也需要花费时间修正新增，不从整体出发，新增的用例不考虑全局效果，只是新增没有考虑原有用例的修正，导致用例重用性降低，且结构混乱.可能的解决办法1测试驱动开发，用例指导结果，数据记录变化2为测试用例标明时间(版本)和优先级3功能用例和业务用例分开组织4审核用例，结对编写1测试驱动开发，用例指导结果，数据记录变化别误会，这里说的“测试驱动