第一次从头参加项目，参与前期的需求，UC评审，自己完成负责部分的测试设计，测试用例（TC），执行TC。自己按期完成测试设计，测试用例。感觉不是太困难，但明白自己用例是很粗糙的，具体有什么不足之处也说不上来。时间推移到自己执行时，自己才明白自己的测试用例的粗糙是怎样体现的。

　　测试用例 bug  一：功能操作TC多管页面校验TC闲事。一个页面显示bug，使得我的TC大批量 failed，其实多数TC死的很冤。一个页面显示错误，校验页面显示的TC已经用自己的failed把好关了。但我却总是在校验功能操作的TC中，跳转新页面的结果中描述一下出现新页面的元素显示。直接后果，一个页面显示错误，挂点掉 N 多TC，包括很多验证功能操作的TC。这些验证功能的TC就是很冤，本来他们负责把关的功能是正确的，而他们 failed 了。这样的恶劣影响就是， failed TC个数不能有效反映 bug 个数。而且也是让这些冤死的TC，多一个条失责罪，因为他们的pass/failed不能有效的反映他们负责把关的功能是OK/NO。

　　解决方案：大家不要多管闲事，页面显示校验过了，那么操作TC中不要再提，转到一个新页面，不要怕简单，结果就给一句话，多了没有：跳转到XX页面

　　测试用例 bug  二：功能步骤分家，藕断丝连。如果说上面是让功能TC不要帮页面校验TC，那么 bug 二就是让功能TC兄弟之间也是一定分工分明，不要互帮互助。这次项目中一个惨痛教训。收货地址有一个规则，大概描述是：收货地址默认选中上次使用的收货地址。那么这个功能的本质是通过数据库中一个字段来判断的实现的。那个测试收货地址功能本应分解：1.使用收货地址后设置数据库默认地址字段值；2.使用收货地址时，根据数据库默认地址字段值来选中默认地址。 3.选择使用收货地址创佳订单。  但是当初我却认识不太清楚，设计TC成：第1部分功能是单独一个TC。但是第2部分感觉步骤太小，没有单独成TC，融合到第3部分中。而我又在第3部分很多TC中，每个前面都是加入一句验证：“默认选中上次使用的收货地址”。虽然简单简短一句话，它包含了第1.2两个部分的功能。时间也是推移到执行用例时，没有想到第1部分的简单功能有缺陷，不能设置数据库中的默认值，而且长期没有得到修复。第3部分的很多TC，因为前面一句简短的话：“默认选中上次使用的收货地址”而failed。这个也是误死误伤，和bug 一中的恶劣影响一样。

　　解决方案：功能分解一定要彻底，步骤不要嫌弃它小，分解成单独TC。分工后一定也只守自己的关。 当然考录到测试的覆盖率，测试完整，需要考虑完全每个步骤的前置和后续场景应该就没有问题了。

　　只能是初感测试用例设计，谈到的问题应该是大多Tester 不会犯的错误。但对于我自己却是亲身体会得来，意义不同，对自己设计TC有帮助意义，所以在此记下。 自己TC设计还有很多不足之处，希望大家指导帮助。我也将不断学习，提高自己。