软件测试：测试用例篇

在测试过程中，我们往往会先写一些测试用例，并且在日常测试中，有时也需要补充测试用例到现有的案列库中。

测试用例的基本要素

测试用例是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试用例、预期结果等要素。
评价测试用例的标准：

• 用例表达清楚，没有二义性；
• 用例可操作性强；
• 用例的输入与输出明确，一条用例只有一个预期结果；
• 用例的可维护性好；
• 用例对需求的覆盖率高；
• 暴露程序Bug的能力强。

测试用例带来的好处

• 测试执行者的依据；
• 使得工作可重复，自动化测试的基础；
• 评估需求覆盖率；
• 用例的复用；
• 积累测试的方法思路以供后续借鉴。

但有好处的同时也有不利的一面：

• 使用中带来困扰
  测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间要比执行所花费的时间还多；

• 解决如下问题
  不知道是否全面的测试了所有功能，测试的覆盖率无法衡量，对新版本的重复测试很难实施，存在大量冗余影响测试效率。

测试用例的设计方法

基于需求的设计
RBT是基于需求的测试方式，会使测试更加有效，因为它使测试专注于质量问题产生的根源，即需求。
基于需求的测试是一种最根本的软件测试，重点关注以下两大关键问题：
（1）验证需求是否准确、完整、无二义性，并且逻辑一致；
（2）要从“黑盒”的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需求；

具体的设计方法将在下一篇中为大家进行介绍