7.5 联系人搜索案例测试设计实践
第2个案例就开门见山地来讲吧，先描述一下 应用的背景。
应用类型:智能拨号软件
所在系统环境: Android, ios, windowsphone等
应用核心功能:联系人搜索，Voip,智能IP拨号
应用所属结构:纯本地应用
应用帐户:无账号
当下有很多的智能联系人搜索应用，如腾讯、360、 触宝等。联系人应用是- -个移动系统固有的应用,为什么用户还会有这么大的需求量呢?原因只有一个,智能机上的默认联系人应用太不智能。当你要查询-一个想找的人、想在出差、出国等各种漫游的情况下得到优惠提示、想有很好的黑名单功能以免于骚扰，那么默认的联系人拨号应用几乎不可能实现。
每个智能联系人搜索应用的特色各有不同，但最常用的核心功能都-样一搜索。如何让用户在使用各种方式进行搜索的时候，都能尽快地查到自己想要找的人，就成了一个难题。现在假设测试人员要针对某款应用的搜索联系人功能做测试工作,首先我们得到的搜索策略如下表所示:
了解完需求之后,我们还需要做- -件事情一准 备测试数据。这些搜索策略也许在某个联系人名字上测试通过了，但不能确保在其他各种形式的名字上都通过。所以，在真正测试之前先要设计测试数据。要做到这些，我们需要了解用户的需求，比如联系人姓名的显示形式:
●全中文名称。比如“陈晔”“移动测试会”。
●全中文复姓名称。比如“欧阳振华”。
●多音字姓氏名称。比如“单- -平”。
●全英文名称。比如“Peter Parker"。
●中英文名称。比如“陈晔Monkey”。
●带有特殊字符的名称:比如“陈晔[移动测试]” 。.
●全号码名称。比如“18621519900*
基本.上也就是以上这些情况，再根据边界制做一定的设计，就会出现测试用例。可问题随之而来，一个应用的搜索功能就有那么多的测试用例，如果在项目时间和人力有保证的情况下，那么有多少用例都不怕,问题就在于现实中我们遇到的情况往往都是相反的。所以，很自然地就需要用自动化这个工具来帮助我们高效率地进行数据驱动的测试和回归测试。
本例中的自动化工具使用的是Android系统的原生测试框架Instrumentation。 如果要对搜索功能进行自动化测试，需要输入测试用例，通过使用应用的搜索方法之后，再对搜索列表做遍历查询,看看是否有期望的结果。所以需要先准备两个文本文档，一个存放测试用例(用户真实的搜索数据)，另一个存放期望搜索出来的结果(用户想要的结果)。接下来看看如何使用Instrumentation框架吧。
我们需要先新建一个Android junit test 的项目工程，在ContactTestCase类中继ActivityInstrumentationTestCase2类，定义相关测试的Activity 名称等一些常 规设置。核心代码如下:
//继承Android测试类
public class ContactTestCase extends
ActivityInst rumentati onTestCase2<DialerActivity>
//新建实例，指定Activity名称和Package名称
DialerActivity mActivity;//DialerActivity是被测应用的核心类
ContentResolver mCR; .
public ContactTestCase() {
super ("com. contact . smartcontact", DialerActivity.class) ;
}接着我们需要将先前准备的测试用例数据和保存期望结果的两个文本文档放入测.试工程的asses目录下，以方便在测试的过程中读取。在setup0方法中将对象实例化并将测试用例和期望结果存放入list列表中，输入用例的列表如下图所示。
保存期望结果的文本文档内容如下图所示。
.