什么时候开始写测试用例

需求文档确定后，就可以开始了。

此时这个开始设计系统测试用例，无法编写很具体细节的用例，但是我们可以思考编写简略测试用例的要点。

设计测试用例越靠近需求阶段，我们就能越早发现需求问题，在软件开发过程问题得到越早的修正，那么所花的代价就会越小。在需求阶段发现问题，我们可能只需要修改下文档。

如果在软件版本交付给测试后，才开始设计测试用例，那么结果因为时间压力我们就不能设计出完整的测试用例或者根本没有设计测试用例。一些测试环境或测试数据或测试工具的使用我们就无法充分的准备，就不能进行完整的测试。在这个阶段，我们可以考虑测试计划的编写，确定测试策略，采用的测试技术，以及开始做一些测试准备工作。

在一个不规范的单位，我们可能没有及时获取到需求文档，此时我们要做的是和需求人员多沟通，让他们在确定需求文档后也给我们测试通知下，让我们的一些测试准备工作也尽早开始。

一个好用例的评判标准是让别人看到你的用例，能很清楚的知道你要表达的信息，如果你写的用例测试步骤与预期结果不清晰，看完之后不知道你要关注的测试点是什么，只有你自己能看懂自己想要表达什么，那么证明你写的测试用例是不合格的，其实在工作中，我们也会经常遇到，写一条测试用例时，测试步骤是紧密相连的，好几条测试步骤会得到一个预期结果，或者是一条测试步骤对应好几条预期结果等等的情况，为了解决这些问题，那么就需要我们在写测试用例时将测试步骤区分清楚，预期结果做到有迹可循，所以我们在开始设计测试用例时，就需要添加一些特定的字段，来更好的帮助我们写测试用例，主要包含的字段已列出，具体也要看每个人怎么去使用它。

测试用例的字段根据实际情况可多可少，但是其中的一些字段是必不可少的，如下：

必须包含的字段：用例编号、模块、测试步骤、预期结果、实际结果、优先级、测试人员、备注等（注：从我经历大公司到小公司，此些字段在用例中必不可少）。

用例编号：在执行测试用例时，执行到当前测试用例发现了bug，那么在提交bug时，就可复制粘贴测试编号在bug提交系统中，后期统计；

模块：添加模块的好处，发现bug时根据测试用例可执行定位模块，也方便自己对模块进行梳理；

测试步骤：测试时执行的步骤，测试步骤要清晰，建议不要超过9条，复杂可根据实际情况分开，做到简单易懂；

预期结果：就是根据参考资料与需求，执行步骤之后应该实现的效果，预期结果最好与测试步骤一一对应；

实际结果：测试执行步骤，实际出现的结果是否与预期结果一致，一般为pass or fail；

优先级：添加优先级，可在项目紧急的情况下根据优先级排序，有限测试级别较高的用例，优先级高的用例都代表着对产品的影响性较大；

测试人员：清楚谁测试的模块，可用作任务量的评估，也可在项目某些模块出现漏测等问题时，可有迹可循；

备注：这个很好理解，不做说明；

可包含字段：模块的一级目录、二级目录、测试时间、用例关注点等等。

总的来说，用例字段多可能你写的用例看起来可参考的信息就多一点，但是字段的多少不能证明测试用例编写的好坏。希望大家用例写的溜溜溜的。。。。