软件测试写测试用例有两种方式可供参考。有一种是在原本测试用例的基础上，再次放大用例描述的模糊度，以利于用例可用于相似但细节不同的功能。另一种是建立较为完善的基础用例库，项目用例作为基础用例库的子集存在。
一、软件测试写测试用例
1.在原本测试用例的基础上，再次放大用例描述的模糊度，以利于用例可用于相似但细节不同的功能。以登陆界面的字符长度为12双字节的用户名提示框为例：
原始用例步骤：在登陆界面用户名输入框输入11个中文字符。
修改后的用例步骤：在登陆界面输入不超过字符长度限制的用户名。
点评：原始用例步骤仅适合登陆界面用户名字符长度限制为11以上的编辑框。修改后的用例可用于任何字符长度的用户名编辑框。此方法还可用于对流程描述，如”进入编辑用户名界面”可替换为”编辑用户名”。
2.建立较为完善的基础用例库，项目用例作为基础用例库的子集存在。这样的用例库在针对单个功能时，存在多种不同的描述和设计。如1点的模糊程度不同可作为相同用例的不同两支用例存在。而在以后的实际项目中，根据项目实际需求，从基础用例库筛选合适的用例组作为项目用例组。
如果用一条用例覆盖一个功能点在实际操作中有很大的缺陷。首先不能确保测试人员进行集成测试时对功能用例执行到位，可能会出现遗漏。因此我们在测试用例输出过程中，建议测试人员就测试因子使用工程方法进行流程功能覆盖。但是这样引入另外一个问题，客户的需求是不断变化的，需求在执行设计和测试用例输出时，很大几率产生变化，这种变化势必对原输出的测试用例造成冲击。调整的工作量有时会很大，有可能对整个功能推倒重新输出用例。面对这样的情况该如何解决？
分析：每个用例覆盖一个功能点，是优异的理想状态。但条件覆盖有个缺点就是每次执行会存在一个较长的周期，如果部分不可套用自动化，会导致测试和开发并行产生无法按时验证完每个版本的分支。
延伸阅读：
二、 测试用例的细度如何把握
用例粒度无论选择什么方法，都存在利弊，所以在实际测试用例设计中，如何选取，需要结合整个测试团队和产品未来发展来看，而非简单的只分析测试用例原理就能得到结果。提供一个用例粒度供参考。单个quick check test单个测试人员在2小时完成，组成的用例组要求覆盖产品所有功能，而每个用例都可从System cases中直接提取。以此为标准，可评估出每个用例的覆盖粒度。
