通过与 Jira 对比,让您更全面了解 PingCode

  • 首页
  • 需求与产品管理
  • 项目管理
  • 测试与缺陷管理
  • 知识管理
  • 效能度量
        • 更多产品

          客户为中心的产品管理工具

          专业的软件研发项目管理工具

          简单易用的团队知识库管理

          可量化的研发效能度量工具

          测试用例维护与计划执行

          以团队为中心的协作沟通

          研发工作流自动化工具

          账号认证与安全管理工具

          Why PingCode
          为什么选择 PingCode ?

          6000+企业信赖之选,为研发团队降本增效

        • 行业解决方案
          先进制造(即将上线)
        • 解决方案1
        • 解决方案2
  • Jira替代方案

25人以下免费

目录

软件测试怎么写测试用例

软件测试写测试用例有两种方式可供参考。有一种是在原本测试用例的基础上,再次放大用例描述的模糊度,以利于用例可用于相似但细节不同的功能。另一种是建立较为完善的基础用例库,项目用例作为基础用例库的子集存在。

一、软件测试写测试用例

1.在原本测试用例的基础上,再次放大用例描述的模糊度,以利于用例可用于相似但细节不同的功能。以登陆界面的字符长度为12双字节的用户名提示框为例:

原始用例步骤:在登陆界面用户名输入框输入11个中文字符。

修改后的用例步骤:在登陆界面输入不超过字符长度限制的用户名。

点评:原始用例步骤仅适合登陆界面用户名字符长度限制为11以上的编辑框。修改后的用例可用于任何字符长度的用户名编辑框。此方法还可用于对流程描述,如”进入编辑用户名界面”可替换为”编辑用户名”。

2.建立较为完善的基础用例库,项目用例作为基础用例库的子集存在。这样的用例库在针对单个功能时,存在多种不同的描述和设计。如1点的模糊程度不同可作为相同用例的不同两支用例存在。而在以后的实际项目中,根据项目实际需求,从基础用例库筛选合适的用例组作为项目用例组。

如果用一条用例覆盖一个功能点在实际操作中有很大的缺陷。首先不能确保测试人员进行集成测试时对功能用例执行到位,可能会出现遗漏。因此我们在测试用例输出过程中,建议测试人员就测试因子使用工程方法进行流程功能覆盖。但是这样引入另外一个问题,客户的需求是不断变化的,需求在执行设计和测试用例输出时,很大几率产生变化,这种变化势必对原输出的测试用例造成冲击。调整的工作量有时会很大,有可能对整个功能推倒重新输出用例。面对这样的情况该如何解决?

分析:每个用例覆盖一个功能点,是优异的理想状态。但条件覆盖有个缺点就是每次执行会存在一个较长的周期,如果部分不可套用自动化,会导致测试和开发并行产生无法按时验证完每个版本的分支。

延伸阅读:

二、 测试用例的细度如何把握

用例粒度无论选择什么方法,都存在利弊,所以在实际测试用例设计中,如何选取,需要结合整个测试团队和产品未来发展来看,而非简单的只分析测试用例原理就能得到结果。提供一个用例粒度供参考。单个quick check test单个测试人员在2小时完成,组成的用例组要求覆盖产品所有功能,而每个用例都可从System cases中直接提取。以此为标准,可评估出每个用例的覆盖粒度。

相关文章