功能测试——测试经验库

与测试用例设计不同，测试经验库更多体现的是测试工程师在日常测试活动中的经验积累，这些经验很多时候不一定编写为测试用例，但可作为测试执行、发现缺陷活动中必不可少的补充。

测试工程师可将测试活动过程中积累的经验，添加到经验库中。通过长时间积累，作为产品团队的一笔“财富”，每一位新成员加入，都可以先学习经验库，更快速的融入团队。

以笔者曾经所在公司为例，积累了大量的测试经验，主要分为功能设计、信息提示、系统交互、容错处理、数据边界等几个部分。

所有系统功能设计应当根据用户需求规格说明书确定，但从开发工程师角度思考，他们更多关注的是功能实现，至于是否确实是用户期望、满足用户使用习惯的设计，可能关注度不高，而测试工程师以用户视角验证被测对象，除了关注功能实现外，还需关注是否满足用户使用习惯或约定俗成的规则。

买东西送赠品，不一定是好事。根据用户需求实现满足其期望功能，总是恰当的做法。开发工程师觉得有用的功能并不一定是用户期望的，如老年手机设计了酷炫的灯光效果、总共不超过10条数据却设计了查询功能。功能越多，出错的可能性越高。

出于营销目的，产品团队可能通过某种形式夸大被测对象的功能性，测试工程师应该结合系统DEMO、宣传页、用户手册及用户需求进行多重验证，以判断是否存在夸大现象。

一个简单的功能，却需要通过多个步骤操作才能实现，用户无法记忆太多复杂的步骤。对于用户而言，“事不过三”总是对的，也是他们期望的。

任何系统设计，越是简洁越好，功能过于复杂的系统，通常没有好下场。

既然没有用的功能，开发出来做什么，需求分析的时候，是否真的分析清楚了？为了功能而实现功能，通常不是一个好的做法。

错误的功能，肯定需要处理。人民币转换日元，却以欧元的汇率，系统是怎么设计的？

说好了有按照订单号、订单总金额、商品名称等字段排序的功能，用户却在哪都找不到。

明明必填项“类别名称”为空，系统却提示“商品单位不能为空”，错误的信息提示可能让人怀疑整个系统的质量。

“对不起，你的操作不正确，请联系管理员！”

“我哪里错了，管理员是谁，我去哪里找他？”

能不能明确告诉用户错误位置及错误原因。

用户名及密码都没有输入，提交登陆后，系统先提示“用户名不能为空”，确定后又提示“密码不能为空”，有什么话能不能一口气说完？

相同类别的菜单应该在同一目录，查找与替换功能应该在一起。

一些脚本错误出现后，无论确定还是取消，都无法退出当前状态，只能强制关闭进程。

到底要加载多久？到底要下载多长时间？哪怕一个虚假的预估时间，对用户来说也是一种安慰。

一个一个来，那么光标都来提示用户，用户怎么知道应该先操作哪个，还是系统已经疯了？

用户名长度不超过18个字符、类别名称不超过15个字符、内容简介不超过2000个字符，这些都是对用户输入的限定，超过限定的输入是不被接受的。系统应当对超限输入做出明确的禁止。

小数点保留几位，是个严重的问题，是否应该有个规则说明，1.5万元与1.55万元的差别是500元。有限的区域只能显示20个字符，多余的信息则以折叠方式展示。

不小心的误操作，是否导致无法挽回的结果，密码输入错误几次才会被锁定？系统在用户操作错误时应该给予“改过自新”的机会。

异常的故障出现，系统能否恢复到故障前的状态，也是系统健壮性的重要表现。

系统提示用户可以使用微信或QQ登陆，可怎么授权都无法使用，该怎么办呢？

支付时明明支付成功了，为什么提示支付失败？钱哪去了？还能退回来吗？

系统与系统间的调用，更要保证数据及逻辑的正确性。

数组只能容纳10个整数，现在有9个、10个、11个的可能性，系统响应是什么？

内存使用率已经99%了，系统还能运行吗？磁盘已经没有空间了，还需要写日志怎么办？

系统等待过程中，是否可以给其发送命令，还有1秒结束安装了，能否取消？还有1秒完成卸载了，能否取消？系统要求15秒内给予响应，否则托管，在15秒刚到时做出响应是否取消托管可能性？

系统规定了控件的应用空间，如果把控件拖到区域外呢？是否存在“免死”区域，是否有越界可能？