项目几经折腾终于告一段落了,作为android engine的测试人员,我们都是跟着项目一起成长。在这里我想记录下我在这段时间的收获。恳请大家多多指教。
一.写测试脚本前一定要先写测试用例
测试脚本是测试用例的code直观反映。也就是说你如何来写测试脚本,一方面需要有脚本的语言基础,从一个专业的测试人员来说,更重要的是考虑到该测试脚本是用来测试目标程序的哪一个功能(即测试点)。所以测试人员必须在熟读了需求文档(JIL文档),了解了测试的需求点之后的情况下来编写测试用例就变得尤为重要了。
好处:使编写的测试脚本与测试用例一一对应,条理清晰,使测试脚本更能全方位地覆盖到
目标程序。
一个简单的例子:
测试短信息的messageId
通过JIL文档的介绍,我知道messageId是短信message对象的一个属性,
返回值为string类型,是用来表示短信的唯一标识符,且不可写。那些根据这些信息我们可以写出怎么样的测试用例呢
1. 读出短信息中的messageId(测试MessageId是否可读)
2. 重写短信息中的messageId(测试MessageId是否可写)
3. 查看MessageId的返回值是否是string类型
4. 可以根据不同的MessageId从数据库中取出短信息,看它是否是同一个短息
。。。
然后根据以上的测试用例编写测试脚本
function TestMessageId()
{
var msg=widget.Messaging.createMessage(widget.Messaging.MessageTypes.SMSMessage);
alert("the orial MessageId="+msg.messageId);//读出msg对象的messageId
msg.messageId="1001";//重写msg对象的messageId
//看orialmessageId和modified messageId是否相同,如果不相同,说明MessageId可写,不符合jil标准,那么这就是一个Bug
alert("the modified messageId="+msg.messageId);
//读出msg对象的MessageId的类型
alert(“the type of messageId is”+typeOf(msg.messageId));
}
以上一个js函数包含了头三个测试用例,所以测试用例和测试脚本并不是一一对应的哦。
二.充分利用Js语言,简化测试脚本
在编写测试脚本的时候,可能会遇到这样的情况:就是有好多测试用例都可以用在一个函数中来表述。但是起初没有经验的脚本编写者往往会根据每一种情况而写一个测试脚本,这样不仅加大了工作量,还会弄得脚本很混乱。我就曾经是这样做的,呵呵。
例子:
findAddressBookItem(compareAddressBook,beginInx, endInx):根据条件查找合适的联系人
JIL文档中介绍,对于AddressBookItem对象中除addressBookItemId以外的属性值,findAddressBookItems支持加入“*”通配符来实现模糊搜索并且大小写不敏感。且有属性beginIndex和endInx是控制联系人的选择范围。
根据这些信息,我们可以得出那些测试用例呢?
1. 根据正常条件查询联系人
2. 联系人属性中有*查询
3. 联系人属性中有大小写查询
4. 根据联系人属性值的特殊字符进行查询
5. 联系人属性中有*,字母大小写和空格符查询
6. 联系人属性中有属性为空的查询
7. 联系人中有index2>index1的查询
8. 联系人中有index2=index1的查询
9. 联系人中有index2<index1的查询。。。。
其中测试用例中的属性是联系人中除了AddressBookItemId这个属性,其他的属性都可以用上述测试用例的方法进行测试。而可恨的是AddressBookItem的属性还真不少(Address,company,Email,fullName,….),天啊,要是这样下去的话(以我一开始写脚本的习惯来写),测试脚本得写多少函数啊!
很庆幸Js中可以获取用户输入的值,作为脚本运行的数据来源,这样,问题就解决了,你们知道怎么解决的吗?
就是设置一系列的输入框或(radio,select),用例获取测试人员对联系人属性值的设置(可以为空,为空格符,包含*大小写字母等),嘿嘿,这样只要一个函数就解决问题啦。
如:我们对查询的联系人做出限制:请看最后的三个测试用例,其实远不止这三个,还可以写出好多个。。
那么就有执行测试的测试人员来控制啦,在脚本中我们写了
select1:<input type="text" name="index1" size="22"style="background-color:#ccff66"><br>
select2:<inputtype="text" name="index2" size="22"style="background-color:#ccff66"><br>
来提供用户输入的beginIndex和endIndex的值
然后利用varindex1=document.testForm.index1.value;varindex2=document.testForm.index2.value;来获取
最后widget.PIM.findAddressBookItems(compareAdd,index1,index2);来执行查询。看清楚了没有,此中的形参index1,index2可是有你决定输入的哦!其他的输入设定跟上述的大同小异,这里我就不诉述了。
三.压力测试很关键,内存泄露是大事
我们知道在测试过程中要是遇到执行一个功能的时候,目标程序突然退出了这种Bug可是优先级最高的呢,同时在碰到这类问题的时候,通常都是无比高兴,很有成就感。同样在脚本测试的时候,多次循环调用某一个函数来进行压力测试可是我们的大功臣呢,因为在这个项目中不少内存泄露的Bug都是这样测试出来的哦。
为什么会有内容泄露?因为Pc或手机的内存都是定量的,且比较小。所以当开发人员申请了内存空间来进行他们的数据存储,操作后,往往会忘记释放内存空间。久而就之,内存空间会越来越少,最后只好程序异常退出了。所以使用多次循环运行一个函数就是看看该函数中有没有及时释放内存。
一个简单的例子:多次循环添加联系人
function addAddr2()
{
var m=100;
var n=10;
for (var i=0;i<200;i++ )//循环添加200个联系人
{
var myContact = newwidget.PIM.AddressBookItem();//创建一个临时的联系人对象
myContact.fullName=m--;//给创建的联系人对象赋值fullName
myContact.company=n++;//给创建的联系人对象赋值company
widget.PIM.addAddressBookItem(myContact);//将新建的临时对象存入数据库
}
}
其中的个数是有自己定的(一般为500次左右)。
我就只说这么多了,这只是我们在测试过程中遇到的一些问题,通过实践和时间的验证,就是一点点经验了。希望大家共同成长,共同进步!