软件测试
软件测试
- UT 单元测试
- SIT 集成测试
- ST 系统测试
- UAT 验收测试
- 冒烟测试
- 黑盒测试
黑盒测试常用方法
- 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。
- 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。
- 检查按钮的功能是否正确：如update,cancel,delete,save等功能是否正确。
- 字符串长度检查： 输入超出需求所说明的字符串长度的内容，看系统是否检查字符串长度，会不会出错.
- 字符类型检查： 在应该输入指定类型的内容的地方输入其他类型的内容（如在应该输入整型的地方输入其他字符类型），看系统是否检查字符类型，会否报错.
- 标点符号检查： 输入内容包括各种标点符号，特别是空格，各种引号，回车键.看系统处理是否正确.
- 中文字符处理： 在可以输入中文的系统输入中文，看会否出现乱码或出错.
- 检查带出信息的完整性： 在查看信息和update信息时，查看所填写的信息是不是全部带出.，带出信息和添加的是否一致
- 信息重复： 在一些需要命名，且名字应该唯一的信息输入重复的名字或ID，看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理.
- 检查删除功能：在一些可以一次删除多个信息的地方，不选择任何信息，按”delete”，看系统如何处理，会否出错；然后选择一个和多个信息，进行删除，看是否正确处理.
- 检查添加和修改是否一致： 检查添加和修改信息的要求是否一致，例如添加要求必填的项，修改也应该必填；添加规定为整型的项，修改也必须为整型.
- 检查修改重名：修改时把不能重名的项改为已存在的内容，看会否处理，报错.同时，也要注意，会不会报和自己重名的错.
- 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。
- 检查多次使用back键的情况： 在有back的地方，back，回到原来页面,再back，重复多次，看会否出错.
- search检查： 在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确.如果可以输入多个search条件，可以同时添加合理和不合理的条件，看系统处理是否正确.
- 输入信息位置： 注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方.
- 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。
- 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*
- 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
- 回车键检查： 在输入结束后直接按回车键，看系统处理如何，会否报错。
测试用例编写
测试用例文档
编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。
软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。
测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：版本号、模块名称、用例编号、用例名称、用例级别、预知条件、验证步骤、期望结果（含判断标准）、测试结果、测试时间、测试人员等。
测试用例的设置
我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。演变为按功能、路径混合模式设置用例。
按功能测试是最简捷的，按用例规约遍历测试每一功能。
对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。
但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。
设计测试用例
测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。
设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。
浙公网安备 33010602011771号