软件测试方法总结（一）

软件测试方法的总结，

软件测试方法总结

一、界面

● 界面测试

（1） 测试界面设计是否合理、简洁、美观，操作是否方便

（2） 功能键、数据项信息是否齐全

（3） 确认系统中同一功能抌名称是否统一

（4） 设计样式、风格（查询条件样式；输入风格（点选/手输入）；）是否与系统其它模块统一

（5） 确认页面内所有字段名称显示风格是否统一（居中、左对齐、右对齐，一般采用居中显示风格）

1、新增页面及功能测试

● 字段

在开始测试时应该保证数据的正确性，然后再从系统中找出各种Bug

（1） 各字段输入正确的信息值保存，确认系统是否可以正确完成新增操作。

（2） 进入添加界面不输入任何信息值，单击“保存”功能按钮，系统应该给出某个不允许为空字段的提示信息（属于边界测试）

（3） 建议不允许为空的字段前面加上?*?作为标记（统一性，方便性问题）

（4） 编码/编号字段不允许输入中文及特殊字符，否则系统应该给出相应的提示信息

（5） 测试编码/编号字段不允许重复，否则系统应该给出相应的提示信息

（6） 确认字段是否已做长度限制，如果输入值超出长度范围，那么在保存时系统应该给出提示信息

（7） 非法测试，如：校验数值型字段输入非数值，保存时系统是否给出相应的提示信息（根据实际需要确定数值型字段是否能够接受负数）

（8） 边界测试，如：确认数值型字段的边界值（如：有效值为?0-100?整数，那么输入-1或101保存时系统应该给出相应的提示信息；输入值为0、100系统应该能正确保存信息值；输入0到100内的整数值系统应该正确保存信息值）

（9） 精确值测试，测试小数位数是否在定义的长度内

（10） 字段精确值是否正确（四舍五入否）。

（11） 根据实际情况测试名称字段是否具有唯一性，（一般情况下名称是不允许重复的，具体问题具体分析），否则系统应该给出相应的提示信息

（12） 确认各字段名称书写是否正确（注意：要求编辑界面、住息列表中、错误提示信息、查询条件中的字段名称完全相同）

（13） 确认特殊格式的字段是否已做标准格式的限制（如：电子邮件、邮编等）

（14） 测试上级信息字段（如：上级XXX名称、上级XXX编号）的信息值是否根据所选择的上级XXX名称系统自动生成（注意：编号生成值一定是维护界面的编号，而不应该是相应表的那个主键编码）

（15） 测试如果某字段信息值是从另一个模块中选择输入的，那么需要确认其它相关联字段的信息值是否也相应的正确的自动带入，并且这些字段应该都是只读的

（16） 创建人/编辑人、发布人、创建时间、创建人字段应该设为只读的，而且此类字段值应该默认当前操作人的姓名

（17） 如果某个字段可以点选输入多个信息值，那么测试该字段是否接受，并保存了点选输入的多个信息值

（18） 对于多选字段，测试是否具有记忆上次选择值并已验重

（19） 测试字符型字段是否可以接受空格（统一性问题，建议不要接受空格）

（20） 引用其它模块的字段信息值的字段长度是否与被引用模块相应字段长度一致

2、多行添加编辑页面

（1） 测试插入单行是否可以正确保存相应字段值

（2） 插入/添加多行测试是否对多行相应字段空值是否进行校验（通常如果有多条空行保存时系统会弹出XXX字段不允许重复提示信息，要求仅对空行不保存即可，不需要提示的）

（3） 多行添加，测试如果某个字段值太长保存后是否会导致界面混乱

（4） 保存---保存新添加的多行记录信息

（5） 保存---勾选待删除记录，单击此功能按钮系统正确完成删除操作

（6） 插入空行---单击此功能按钮系统插入一条空的记录行

3、 主子表编辑页面

（1） 测试只有保存主表信息后才能维护子表信息，否则系统应该给出相应的提示信息

（2） 如果子表信息是否需要维护取决于主表中的某个字段值，那么请确认主表中相关联的字段取值是否对应子表的存在（主表中较常用的取决子表存在的字段是“底层否”，如果与底层相关联一般只有在底层才能维护其子表信息）

（3） 如果子表中有继承主表信息，那么确认继承的信息是否完全正确

4、 左树右表的测试方法

（1） 添加、修改、删除保存后目录树信息是否要自动刷新（统一性问题）

（2） 添加界面：测试继承上级信息的字段（如：上级机构名称、上级机构编码等）值系统是否自动生成，而且信息值是否是只读的

（3） 测试是底层节点才可以进行添加操作，还是非底层节点才可以进行添加操作（业务测试）

（4） 含有子结点信息的当前结点是不允许修改为“底层”结点的

（5） 如果当前结点下含有相关信息，那么当前结点是不允许删除的，否则删时系统应该给出被引用的提示信息

（6） 测试单击目录树上名称，右侧查询列表查询显示该结点所有子节点（1级、2级…）信息还是只显示当前节点的1级了节点信息，要求查询显示统一

5、控件测试

● 下拉选择控件

（1） 下拉选择字段要求只能选择输入信息值

（2） 确认下拉列表中的选择值是否与相应的集合域值完全匹配

（3） 一般情况下拉选择列表中有“请选择”值，而且系统默认值应该是“请选择”（为操作方便某些特殊字段如：是否底层、启用否等字段建议添加界面默认值为“是”）

（4） 测试下拉列表中的选择值是否有重复

● 点选

（1） 点选字段要求只能点选输入信息值，不能手动输入

（2） 确认点选按钮的链接页面是否正确

（3） 确认点选界面的界面设计是否合理、美观；功能按钮是否齐全；操作是否方便（点选页面功能按钮：选择、清除选择、关闭），

（4） 根据实际情况确认点选页面是否提供了查询功能，一般多数据量的选择界面，要求加上查询功能（基本查询，翻页查询功能）

（5） 测试点选页面各功能按钮的功能是否已经正确实现

（6） 测试点选页面的信息列表中相关的主要信息是否齐全，字段（数据项）是否按主次排放，信息查看是否方便

（7） 点选页面中的信息，如果与有效否、启动否、底层否等信息有关，建议系统统计查询时将无效、未启动、通常非底层信息过虑掉（业务测试）

（8） 人员查询条件的点选列表初始化查询应该查询系统所有用户

● 时间

（1） 系统内时间控件样式是否统一

（2） 单击输入框是否弹出时间选择页面，而且可以进行时间选择操作

（3） 时间选择页面是否具有“清除”功能（某类时间选择控件是没有清除功能的）

（4） 测试该字段选择输入值或系统默认值的精确值是否正确（一般只需精确到年-月-日，特殊情况需要精确的年-月-日-时-分-秒）

（5） 测试“开始时间”必须小于“结束时间”，否则系统应该给出相应的提示信息

（6） 根据实际情况某些时间字段的信息值是系统自动生成系统当前时间的（如：创建时间、发布时间），而且此类字段应该设为只读的

● 单选

（1） 点选控件可进行点选操作

（2） 测试单选字段只能选择一个信息值

（3） 测试单选字段的选择按钮可以相互切换

（4） 为操作方便，建议?有效否?的字段值添加时默认为?有效?

● 编辑控件（移动项目）

（1） 测试保存后，编辑控件内各段落间系统是否自动加了空行（此控件常出现的问题）

（2） 测试保存后，编辑控件上方是否会出现乱码

（3） 测试系统是否按设计的格式保存了信息值

 

第二篇：软件测试总结

常用的功能测试方法

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：

1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。

2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。

3. 检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。

4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.

5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.

6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.

7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.

8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致

9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.

10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.

11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.

12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.

13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。

14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.

15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.

16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.

17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。

18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*

19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。

20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错.

测试的基本原则

在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则。这里有一组测试原则：

1 、所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。 2 、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。

3 、 Pareto 原则应用于软件测试。简单地讲， Pareto 原则暗示着测试发现的错误中的 80 ％很可能起源于程序模块中的 20 ％。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。

4 、测试应从 “ 小规模 ” 开始，逐步转向 “ 大规模 ” 。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。

5 、穷举测试是不可能的。即使是一个大小适度的程序，其路径排列的数量也非常大。因此，在测试中不可能运行路径的每一种组合。然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。

6 、为了达到最佳效果，应该由独立的第三方来构造测试。 “ 最佳效果 ” 指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。

7、 不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现.

测试的基本原则<二>

1．应当把“尽早和不断的测试”作为开发者的座右铭

2．程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。

3．设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。

4．一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。

5．对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

6．制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

7．回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。

8．妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。

什么是测试用例

1、一个测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目 的是确定应用程序的某个特性是否正常的工作。一个测试用例应当有完整的信息， 如：测试用例ID号，测试用例名字，测试用例的目的，测试条件、输入数据需求、步 骤和期望结果。

2、注意开发测试用例的过程有助于在应用的需求和设计中发现问题。这主要是由于是 需要完整的考虑应用的整个操作。正因为这样，需要在开发的早期准备测试用例。