如何做好功能测试.ppt

《如何做好功能测试.ppt》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、如何做好功能测试充分理解需求与需求人员沟通讨论，了解需求的来源和背景跟开发人员沟通讨论，了解需求的实现方法和细节做好需求评审，可以从以下几个方面进行需求评审完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。正确性：每一项需求都必须准确地陈述其要开发的功能。一致性：一致性是指与其它软件需求或相关标准规定不相矛盾。可行性：每一项需求都必须是在已知系统和环境的限制范围内可以实施的。无二义性：对所有需求说明都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁

2、明了的语言表达出来。健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。必要性：每项需求的制定都是必要的且能够追溯的。可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。可修改性：每项需求只应在软件需求说明书中出现一次，这样更改时易于保持一致性。可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接，这种可跟踪性要求每项需求以一种结构化的方式编写并单独标明。设计好的测试用例覆盖率：每一个需求点都要覆盖到，异常用例不可少等级划分：按优先级划分，便于在时间紧迫和多轮

3、测试的时候能用最少的时间测完系统主要功能分类和描述要清晰：最好是按需求规格来分类，这样每个用例都能清晰对应到需求点，描述要尽可能详细以便其他测试人员能快速上手测试，前置条件要写清楚，预期结果不能只是操作成功这种简单的描述用例评审：通过评审改进优化测试用例，确保没有遗漏和不规范的地方Web功能测试常见测试点页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。相关性检查：删除、增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。检查按钮的功能是否正确：如update、cancel、delete、save等功

4、能是否正确。字符串长度检查：输入超出需求所说明的字符串长度的内容，看系统是否检查字符串长度，会不会出错。字符类型检查：在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型)，看系统是否检查字符类型，会否报错。标点符号检查：输入内容包括各种标点符号，特别是空格、各种引号、回车键。看系统处理是否正确。Web功能测试常见测试点中文字符处理：在可以输入中文的系统输入中文，看会否出现乱码或出错。检查带出信息的完整性：在查看信息和update信息时，查看所填写的信息是不是全部带出，带出信息和添加的是否一致。

5、信息重复：在一些需要命名，且名字应该唯一的信息输入重复的名字或ID，看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理。检查删除功能：在一些可以一次删除多个信息的地方，不选择任何信息，按”delete”，看系统如何处理，会否出错;然后选择一个和多个信息，进行删除，看是否正确处理检查添加和修改是否一致:检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.Web功能测试常见测试点检查修改重名:修改时把不能重名的项改为已存在的内

6、容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。检查多次使用back键的情况:在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.search检查:在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.功能测试中安全和性能问题比如输入框可以提交特殊字符，可能导致sql注入的安全问题比如现在我们的系统都是

7、分权限的，但很多url可能手动输入也能进，从而可以查看和操作一些没有权限的菜单比如有的统计查询慢，功能测试的时候不明显，但并发的时候会越来越慢，很可能是sql过于复杂或者没有用到索引导致的站在用户的角度用户体验的范围比较大，功能只是其中的一部分，但是功能实现不能以牺牲用户体验为代价，产品最终是给用户使用的，用户的体验直接关系到产品的质量。比如：界面是否简单易用，响应速度是否在可接受的范围以内（业内一般要求5s以内），操作是否繁琐，是否有批量和记忆功能等等。遇到问题怎么办工作中遇到问题先思考，可以百度的先百度，排除一些可能的原因，至

8、少要尝试定位解决一下。尝试过后仍然无法解决或找到原因的问题，描述清楚问题现象、已排除点等等之后发给相关人员寻求帮助。测试出bug时，首先要确保能重现，其次排除掉人为失误、环境原因和数据原因，最后保存相关日志等数据，时间允许时可以自己先走读代码尝试定