如何编写一个好的测试用例

    作为一个测试人员,最基础的技能就是编写好的测试用例。而根据自己的工作总结,我觉得做好以下三点就是一个好的测试用例

  第一:依据分明

  众所周知,一个项目首先立项,然后经过一系列的动作到了需求分析,做完需求分析后,测试就可以做测试需求,然后就可以写测试用例了。所以写测试用例的依据就是需求。这么说太笼统,举一个例子。一个系统经过前期的需求分析,详细设计,模块设计等一系列的动作,最后生成了详细的需求说明和详细设计文档等等,在这些文档中,已经很详细的描述了所有的需求点和功能点,也有较详细的技术说明,接下来的工作就是怎么把这些功能点和需求点变成测试点,这就需要做好测试需求分析和测试方案工作,生成一个个可测试的测试点。这也是需求必须可测的一个体现。

  假设经过上一步工作,分析出这个系统有5个模块,50个大的功能点,500个具体需求点,最后生成了5000个测试点。那么 ok,我们就要写5000个测试用例。还是那句话,一个测试用例只能对应一个测试点,测试点和用例是1对1的关系;一个需求点可以对应多个用例,需求点和用例是1对多的关系。这样做的目的在统计中讲。

  第二:目的明确

  用例都有个测试目的,这就是要目的明确,并且也只能有一个目的。前面无论多少步骤,都是为了找到这个目的途径。功能从大到小有层次的划分,我们做测试用例也是有层次的,不然你怎么定义用例的优先级呢?等到测试最小的功能点是,支持这个功能点的其他上层功能点,我们都默认正确就可以了,这就是我们的预期,所以在测试步骤中不用对上层的功能专门考虑测试数据,只把他当成一个正确的找到目前的功能点的途径就行。换句话说,你要测试的功能点需要点10个连接才能找到,那么前9个连接我们再以前就应该设计了用例,在第10个连接中默认他们正确就ok,这个用例的前9步,只是告诉你如何找到第10步。就是这样。

  第三:便于统计

  测试用例对整个测试过程的质量控制和评估有很重要的意义。

  一,可以做测试需求覆盖分析。这样如果一个用例写几个测试点,那么就无法完成需求覆盖分析工作,至少是不符合规则的。

  二,做用例成功率分析。一个用例中有多个测试点,肯定会造成用例数量减少,用例失败率大大增多。那么你做的用例成功率还有什么意义?

  你还可以通过模块划分,来分析哪个模块存在的问题较多,还有可能存在更多的问题(应为程序员不同,能力就不同,缺陷喜欢扎堆分布,这个大家都知道),存在问题较多的模块需要做进一步的测试或者下一次作为测试重点。如果你统计的数据不准确,会误导结果的。

  三,做缺陷分析。用例失败了,就生成一个缺陷。如果一个用例中写了多个测试点,回归的时候,这几个测试点也有回归,有些可能与缺陷毫无关系的测试点,都被你回归了

阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页