今天完成的事：

测试用例添加了前置条件、优先级、重要级，还有预期结果

总结测试用例

明天计划的事：

完成测试用例

任务进度

收获：

测试用例：

测试用主要由8部分构成：模块、名称、编号、等级、描述、预制条件、操作步骤、预期结果

名称：

要求熟练的测试人员看见名称就大概明白测试用例所测试的点，大概怎么测试，不要求描述过分详细，尽量简短、精练

描述：

测试点的详细描述，相当于测试用例名称的详细版

预制条件：

就是在执行操作步骤前，系统需要达到的状态

操作步骤：

如果有多个步骤，每一个步骤都需要填上序号，每一行一个步骤， 不能写得过于简略，至少要让熟悉过系统的测试人员可以执行，也建议不要写得太复杂。

预期结果：

如果有多个检查点，需要都罗列出来，每一行一个标号， 让人一目了然有几个结果检查点， 另外检查点尽量写详细些，不要出现结果正常、不正常等字眼，应该描述 出正常的具体情况。

把测试用例的每一个部分写好仅仅是测试用例的基本要求，就算这些都做好了，也不能说明这个测试用例是一个好的测试用例。

测试用例好坏的评判标准？

首先纠正一个误区，测试用例不是越多越好？相反如果测试用例中冗余用例太多，这样在执行测试用例会浪费大量测试人力，而且不会产生测试效果。

标准如下：

1、测试用例书写格式正确、描述清晰， 其他测试人员拿到测试用例可以在不询问写作人的情况下正常执行下去

2、测试用例对测试点覆盖完全，也就是说测测过程中发现的问题基本都是通过测试用例发现的，发现的比例越高越好， 越高说明测试用力的防护能力越强，当然测试用例不           

可能特别完备，在我们执行测试用例的过程，如果bug不是通过用例发现，我们需要对用例进行增加，这样我们下一次就可以把这个问题给防护住。

如何写出一份高质量的测试用例？

1、测试人员尽早介入，彻底理解清楚需求，这个是写好测试用例的基础

2、如果以前有类似的需求，可以参考类似需求的测试用例， 然后还需要看类似需求的bug情况

3、清楚输入、输出的各种可能性，以及各种输入的之间的关联关系，理解清楚需求的执行逻辑， 通过等价类、边界值、判定表等方法找出大部分用例

4、 找到需求相关的一些特性，补充测试用例

5、根据自己的经验分析遗漏的测试场景

6、多总结类似功能点的测试点，才能够写出质量越来越高的测试用例

7、书写格式一定要清晰