认识达内从这里开始

软件测试用例设计与应用是每一位软件测试程序员在工作中都会用到的一个测试工具，而本文我们就通过案例分析来简单了解一下，软件测试用例的编写需要注意哪些问题。

点分析：

此处的修改是服务端管理员对学生端学员信息的修改，如果按业务逻辑来，这里的修改会同步学生端学员信息的修改，这个点不容易遗漏的

说明：按业务逻辑来设计用例，容易让自己陷入矛盾的地方

背景：某个在线教育产品，功能模块包含了我的笔记，课程-视频课件播放，其中，我的笔记中，笔记内容记录，来源视频播放界面提交的笔记

举例：按业务逻辑来，可能会如下方式编写

1、打开视频播放界面，输入笔记内容，提交---(预期结果)

2、打开我的笔记--可见提交的笔记

这样看好像没问题，但是细想下，测试我的笔记模块时，会漏掉步骤2的验证么?不会吧，所以这里的步骤2是多余的，可去掉，这里应该对步骤1进行重点测试，不输入、输入字符过长，输入字符含特殊字符，输入字符含换行等

那步骤2怎么办?在我的笔记模块新增用例，把步骤1当做一条线，如下

1、打开视频播放界面提交一条笔记(预期结果可免了，视频播放模块已验证过了)

2、打开我的笔记--预期结果(提交时间，内容显示，字符类型支持等)

这里也告诉我们，仅当某个点不会被单独作为一个用例检测点时，才需要进行一个“关联”，好比上面的学员信息修改，数据同步

这样看好像是没错的，但是很大的不足是啥呢?还是上面提到的，人力的重复投入：测试提交笔记时至少测输入字符串的长度，类型支持;测试笔记模块的查阅时也要测试笔记内容是否被截断，要测试特殊字符的显示是否正常等，也要进行提交笔记时执行的测试操作

解决方案：没错，还是按逻辑设计用例>>输入笔记->提交笔记->显示笔记，

1、打开视频播放界面，输入笔记内容，提交---(预期结果)

2、打开我的笔记--可见提交的笔记

这里可以根据本文中提到的，检测点的思想，进行细化，分成多条用例

比如用例1.记笔记(字符长度测试);用例2.记笔记(字符类型验证)，当然对应的用例内容也跟着改，如下

1、打开视频播放界面，输入超长字符的笔记内容，提交---(预期结果)

2、打开我的笔记--笔记显示不截断，过长以…结尾

接着可以根据本文中提到的，归到同一个模块，比如笔记模块，分配给同一个人

d)独立出公共用例

思想：把某些公用的模块或功能独立出来设计，减少冗余

举例：常见的智能手机，很多模块中选择文字，文字变底色，通常伴随弹出操作面板，类似全选，复制等，那可以考虑在某个模块中把这个功能单独出来设计用例，其它模块则不再重复写

e)提高用例复用性

设计用例应该多考虑用例的复用性，可以从以下几个方面来考虑：

1)通用性。通用性是指可复用测试用例并不局限于具体的应用，不过分依赖于被测软件的需求、设计和环境，能够在某一类型、某一领域的相似软件的测试中广泛使用。(可以尝试去构建自己的用例库)

2)有效性。测试用例的目标是尽早发现软件问题

3)独立性。

1.用例之间不存在相互依赖关系

对于测试需求R1和R2，测试用例集分别为cl和c2，c1和c2的交集为空，并且每个可复用测试用例能够独立运行。测试用例是否具有独立性，决定了测试用例可复用能力的强弱。

如果测试用例之间存在着相互关联，或测试用例的运行环境取决于其他测试用例的执行状态，那么，其中的测试用例不能复用时，与之相关的测试用例的可复用性也不复存在。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。