２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。
３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。
４、熟悉系统，对编写测试用例很有帮助。
５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。
转的 对于不同软件产品之间，A产品的测试用例很难用到B产品上面
但是A产品的升级或者对A产品进行改版的话，老的测试用例的复用性才有可能拿来用上
各位都是能人啊
在下学习了，各位发表的都很好！:lol :lol 用例复用性的设置，根据公司性质不同而有所区别，但大体上一个公司业务方向或技术类型都会有一个或多个定向，比如外包类，可能会针对性向某几类公司进行外包测试，测试软件开发技术等可能有所不同，所以复用用例主要从功能业务角度出发；一般的软件公司，可能会专门为某一类或几类行业提供软件产品，此时复用用例则可以从功能业务、技术类型角度出发。1）公司应该建立一个共享库，专门用来存放测试用例；
2）共享库中应该单独确立一个公共测试用例库，这里又可根据不同特点设置多个类别，比如按产品/项目特点，分保险、金融类；平台管理类；B/S架构类；
3）在公共测试用例类中，针对该类型特点设置尽可能普遍的用例，如登陆/退出、新建、删除、修改、系统管理等，使这一类的软件产品能尽可能多的进行参照；
4）对于非公共用例，我们也需要做一定的控制约束，eg.角色、优先级、功能点描述、正向流、负向流、前置条件等，另 操作步骤与数据参数独立设置（因为类似两个系统或产品都存在共同特点甚至操作步骤，但部分参数数据必然不同，故在用例复用时，我们只要调整 角色、数据参数等相关字段即可更新用例）
5）在操作步骤中，如果考虑到作为复用用例，则建议使用通俗化术语，而专业化或针对性名词则可以在数据参数中做说明，或在备注说明里做解释。
6）对于产品或者项目，无论是正规大公司或规范不严的小公司，都会存在需求临时调整现象，当然也无法避免在若干次调整后，原先的需求可能被再次使用。而测试用例设计原则是：随着需求产品功能变动，用例做实时更新。此时可能在前期删除一些用例，而在后期却发现仍需要这些用例（雷同开发时，可能由于设计调整必须使用原来的开发设计模式），此时建议对于因需求设计变动而删除的用例做个逻辑删除，而非物理删除，以便后期参考；
7）发布的软件产品需要做版本控制、开发代码需要做版本控制，其实测试用例同样也存在版本控制必要性。因为系统性测试的用例通常会跟着需求走，此时一个需求版本的变动可能产生一个新的用例版本，因此建议在用例不做独立版本控制时，对每个用例与需求版本做动态关联；
8）如有需要，对于存在自动化测试、安装测试、单元测试、集成测试的公司，则设置以测试类型区分的用例属性库；
页:
1
[2]
