Sunday 11 September 2011

Mexico, Monterrey, Axtel, Motorola,NSN

Sep. 4.2011. From ShangHai to San Francisco, then Chicago, then Monterrey.

Monday 1 September 2008

MIMO HandOver


Q: How to turn on MIMO_B from APA:
NECB.xml wmanIfBsDownlinkUnicastZone1DiversityType = 3
EMS: Enable Alamouti and MIMO B for Unicast Zone

NECB.xml: wmanIfBsCINRTypeBitmap = 0000000DEMS: Enable CINR Measurement on Preamble (reuse 1), on non-STC zone, on STC zone.

NECB.xml: wmanIfBsDlMimoModeFBCycle = 4 (or 8, 16)
EMS: Set MIMO B mode FB Cycle 4 (8, 16)

Q: How to turn on MIMO_B from MSSA: from FirmwareCfg, setMIMO Enable = 1Corr2MacFlags = 0xffff
Q: How to confirm AP is sending data in MIMO burstA: From beceem swin tool (login devel: password: b3c33mdevel)swin2:> r harqmimog_u32NumOfHarqMimoMode3AllocsInMatB -- Number of allocation for MIMO Bg_u32NumOfHarqMimoMode3AllocsInMatA -- Number of allocation for MIMO Ag_u32NumOfHarqMimoMatByDedDlCntrol1 -- Number of allocation for Dedicated Control IE

Monday 31 March 2008

The LMT for AP

The Access Point Local Maintenance Terminal is a web based application which provides an interface for a user to perform a set of configuration, management, and debugging activities on the Access Point.

LMT users can be authenticated in one of two ways. AAA authentication is the default and is recommended due to its central and more secure storage of passwords. All accounts created using bootstrapping or the LMT GUI, use AAA authentication. Users in this class are denied access to LMT if AAA authentication is not successful. LMT also permits local authentication of the emergency admin user created during site commissioning (ap admin by default) to support the case where a AAA is not available.

Thursday 26 April 2007

今生轮回,只为相逢一笑

青衫磊落,剑啸龙吟,鲜衣怒马的日子,我已忘了 把酒临风,寒翠烟波,明月轻舟的过往,我还记得。 谁带醉意上高楼,望断远山,洗却了羌笛声里的无数怨愁 哪一杯酒是荡漾的波影,映出了前生红尘,告别了剑舞清歌,忆起了嫣然 也许幽咽的萧音,该是一场天意的告白 也许俯首的笑容,藏有今生所有的缘,所有的聚散都只为一次无望的流泪 我弹指而笑—— 暮鼓晨钟悠荡千年,青灯古佛恍如隔世 谁又醒悟?所有的生生世世,于轮回里擦肩而过的曾经,一次次错过铸成永恒 今生的舞者,敲碎的是久远的灵魂。谁是过客的马蹄声声? 断桥水旁,细雨如诗;蝴蝶双飞,曼舞相随可否击筑而歌?可否邀月共饮?可否横笛吹箫?可否青梅煮酒 我今生的轮回里,为的只是那“生死挈阔,与子相悦;执子之手,与子偕老”。 星河迢迢,佳期如梦,为的,只是相逢一笑 一觉醒来才发现相逢只是一场梦而已!

Wednesday 18 April 2007

Lucene index

Lucene 是一个基于 Java 的全文检索工具包,你可以利用它来为你的应用程序加入索引和检索功能。Lucene 目前是著名的 Apache Jakarta 家族中的一个开源项目,下面我们即将学习 Lucene 的索引机制以及它的索引文件的结构。

在这篇文章中,我们首先演示如何使用 Lucene 来索引文档,接着讨论如何提高索引的性能。最后我们来分析 Lucene 的索引文件结构。需要记住的是,Lucene 不是一个完整的应用程序,而是一个信息检索包,它方便你为你的应用程序添加索引和搜索功能。

架构概览

图一显示了 Lucene 的索引机制的架构。Lucene 使用各种解析器对各种不同类型的文档进行解析。比如对于 HTML 文档,HTML 解析器会做一些预处理的工作,比如过滤文档中的 HTML 标签等等。HTML 解析器的输出的是文本内容,接着 Lucene 的分词器(Analyzer)从文本内容中提取出索引项以及相关信息,比如索引项的出现频率。接着 Lucene 的分词器把这些信息写到索引文件中。

图一:Lucene 索引机制架构

用Lucene索引文档

接下来我将一步一步的来演示如何利用 Lucene 为你的文档创建索引。只要你能将要索引的文件转化成文本格式,Lucene 就能为你的文档建立索引。比如,如果你想为 HTML 文档或者 PDF 文档建立索引,那么首先你就需要从这些文档中提取出文本信息,然后把文本信息交给 Lucene 建立索引。我们接下来的例子用来演示如何利用 Lucene 为后缀名为 txt 的文件建立索引。

1. 准备文本文件

首先把一些以 txt 为后缀名的文本文件放到一个目录中,比如在 Windows 平台上,你可以放到 C:\\files_to_index 下面。

2. 创建索引

清单1是为我们所准备的文档创建索引的代码。

清单1:用 Lucene 索引你的文档

package lucene.index;

import java.io.File;
import java.io.FileReader;
import java.io.Reader;
import java.util.Date;

import org.apache.lucene.analysis.Analyzer;
import org.apache.lucene.analysis.standard.StandardAnalyzer;
import org.apache.lucene.document.Document;
import org.apache.lucene.document.Field;
import org.apache.lucene.index.IndexWriter;

/**
* This class demonstrates the process of creating an index with Lucene
* for text files in a directory.
*/
public class TextFileIndexer {
public static void main(String[] args) throws Exception{
//fileDir is the directory that contains the text files to be indexed
File fileDir = new File("C:\\files_to_index ");

//indexDir is the directory that hosts Lucene's index files
File indexDir = new File("C:\\luceneIndex");
Analyzer luceneAnalyzer = new StandardAnalyzer();
IndexWriter indexWriter = new IndexWriter(indexDir,luceneAnalyzer,true);
File[] textFiles = fileDir.listFiles();
long startTime = new Date().getTime();

//Add documents to the index
for(int i = 0; i <>> textFiles[i].getName().endsWith(".txt")){
System.out.println("File " + textFiles[i].getCanonicalPath()
+ " is being indexed");
Reader textReader = new FileReader(textFiles[i]);
Document document = new Document();
document.add(Field.Text("content",textReader));
document.add(Field.Text("path",textFiles[i].getPath()));
indexWriter.addDocument(document);
}
}

indexWriter.optimize();
indexWriter.close();
long endTime = new Date().getTime();

System.out.println("It took " + (endTime - startTime)
+ " milliseconds to create an index for the files in the directory "
+ fileDir.getPath());
}
}

正如清单1所示,你可以利用 Lucene 非常方便的为文档创建索引。接下来我们分析一下清单1中的比较关键的代码,我们先从下面的一条语句开始看起。

Analyzer luceneAnalyzer = new StandardAnalyzer();

这条语句创建了类 StandardAnalyzer 的一个实例,这个类是用来从文本中提取出索引项的。它只是抽象类 Analyzer 的其中一个实现。Analyzer 也有一些其它的子类,比如 SimpleAnalyzer 等。

我们接着看另外一条语句:

IndexWriter indexWriter = new IndexWriter(indexDir,luceneAnalyzer,true);

这条语句创建了类 IndexWriter 的一个实例,该类也是 Lucene 索引机制里面的一个关键类。这个类能创建一个新的索引或者打开一个已存在的索引并为该所引添加文档。我们注意到该类的构造函数接受三个参数,第一个参数指定了存储索引文件的路径。第二个参数指定了在索引过程中使用什么样的分词器。最后一个参数是个布尔变量,如果值为真,那么就表示要创建一个新的索引,如果值为假,就表示打开一个已经存在的索引。

接下来的代码演示了如何添加一个文档到索引文件中。

Document document = new Document();
document.add(Field.Text("content",textReader));
document.add(Field.Text("path",textFiles[i].getPath()));
indexWriter.addDocument(document);

首先第一行创建了类 Document 的一个实例,它由一个或者多个的域(Field)组成。你可以把这个类想象成代表了一个实际的文档,比如一个 HTML 页面,一个 PDF 文档,或者一个文本文件。而类 Document 中的域一般就是实际文档的一些属性。比如对于一个 HTML 页面,它的域可能包括标题,内容,URL 等。我们可以用不同类型的 Field 来控制文档的哪些内容应该索引,哪些内容应该存储。如果想获取更多的关于 Lucene 的域的信息,可以参考 Lucene 的帮助文档。代码的第二行和第三行为文档添加了两个域,每个域包含两个属性,分别是域的名字和域的内容。在我们的例子中两个域的名字分别是"content"和"path"。分别存储了我们需要索引的文本文件的内容和路径。最后一行把准备好的文档添加到了索引当中。

当我们把文档添加到索引中后,不要忘记关闭索引,这样才保证 Lucene 把添加的文档写回到硬盘上。下面的一句代码演示了如何关闭索引。

indexWriter.close();

利用清单1中的代码,你就可以成功的将文本文档添加到索引中去。接下来我们看看对索引进行的另外一种重要的操作,从索引中删除文档。

从索引中删除文档

类IndexReader负责从一个已经存在的索引中删除文档,如清单2所示。

清单2:从索引中删除文档
File indexDir = new File("C:\\luceneIndex");
IndexReader ir = IndexReader.open(indexDir);
ir.delete(1);
ir.delete(new Term("path","C:\\file_to_index\lucene.txt"));
ir.close();


在清单2中,第二行用静态方法 IndexReader.open(indexDir) 初始化了类 IndexReader 的一个实例,这个方法的参数指定了索引的存储路径。类 IndexReader 提供了两种方法去删除一个文档,如程序中的第三行和第四行所示。第三行利用文档的编号来删除文档。每个文档都有一个系统自动生成的编号。第四行删除了路径为"C:\\file_to_index\lucene.txt"的文档。你可以通过指定文件路径来方便的删除一个文档。值得注意的是虽然利用上述代码删除文档使得该文档不能被检索到,但是并没有物理上删除该文档。Lucene 只是通过一个后缀名为 .delete 的文件来标记哪些文档已经被删除。既然没有物理上删除,我们可以方便的把这些标记为删除的文档恢复过来,如清单 3 所示,首先打开一个索引,然后调用方法 ir.undeleteAll() 来完成恢复工作。

清单3:恢复已删除文档
File indexDir = new File("C:\\luceneIndex");
IndexReader ir = IndexReader.open(indexDir);
ir.undeleteAll();
ir.close();


你现在也许想知道如何物理上删除索引中的文档,方法也非常简单。清单 4 演示了这个过程。

清单4:如何物理上删除文档
File indexDir = new File("C:\\luceneIndex");
Analyzer luceneAnalyzer = new StandardAnalyzer();
IndexWriter indexWriter = new IndexWriter(indexDir,luceneAnalyzer,false);
indexWriter.optimize();
indexWriter.close();


在清单 4 中,第三行创建了类 IndexWriter 的一个实例,并且打开了一个已经存在的索引。第 4 行对索引进行清理,清理过程中将把所有标记为删除的文档物理删除。

Lucene 没有直接提供方法对文档进行更新,如果你需要更新一个文档,那么你首先需要把这个文档从索引中删除,然后把新版本的文档加入到索引中去。

提高索引性能

利用 Lucene,在创建索引的工程中你可以充分利用机器的硬件资源来提高索引的效率。当你需要索引大量的文件时,你会注意到索引过程的瓶颈是在往磁盘上写索引文件的过程中。为了解决这个问题, Lucene 在内存中持有一块缓冲区。但我们如何控制 Lucene 的缓冲区呢?幸运的是,Lucene 的类 IndexWriter 提供了三个参数用来调整缓冲区的大小以及往磁盘上写索引文件的频率。

1.合并因子(mergeFactor)

这个参数决定了在 Lucene 的一个索引块中可以存放多少文档以及把磁盘上的索引块合并成一个大的索引块的频率。比如,如果合并因子的值是 10,那么当内存中的文档数达到 10 的时候所有的文档都必须写到磁盘上的一个新的索引块中。并且,如果磁盘上的索引块的隔数达到 10 的话,这 10 个索引块会被合并成一个新的索引块。这个参数的默认值是 10,如果需要索引的文档数非常多的话这个值将是非常不合适的。对批处理的索引来讲,为这个参数赋一个比较大的值会得到比较好的索引效果。

2.最小合并文档数

这个参数也会影响索引的性能。它决定了内存中的文档数至少达到多少才能将它们写回磁盘。这个参数的默认值是10,如果你有足够的内存,那么将这个值尽量设的比较大一些将会显著的提高索引性能。

3.最大合并文档数

这个参数决定了一个索引块中的最大的文档数。它的默认值是 Integer.MAX_VALUE,将这个参数设置为比较大的值可以提高索引效率和检索速度,由于该参数的默认值是整型的最大值,所以我们一般不需要改动这个参数。

清单 5 列出了这个三个参数用法,清单 5 和清单 1 非常相似,除了清单 5 中会设置刚才提到的三个参数。

清单5:提高索引性能
/**
* This class demonstrates how to improve the indexing performance
* by adjusting the parameters provided by IndexWriter.
*/
public class AdvancedTextFileIndexer {
public static void main(String[] args) throws Exception{
//fileDir is the directory that contains the text files to be indexed
File fileDir = new File("C:\\files_to_index");

//indexDir is the directory that hosts Lucene's index files
File indexDir = new File("C:\\luceneIndex");
Analyzer luceneAnalyzer = new StandardAnalyzer();
File[] textFiles = fileDir.listFiles();
long startTime = new Date().getTime();

int mergeFactor = 10;
int minMergeDocs = 10;
int maxMergeDocs = Integer.MAX_VALUE;
IndexWriter indexWriter = new IndexWriter(indexDir,luceneAnalyzer,true);
indexWriter.mergeFactor = mergeFactor;
indexWriter.minMergeDocs = minMergeDocs;
indexWriter.maxMergeDocs = maxMergeDocs;

//Add documents to the index
for(int i = 0; i <>> textFiles[i].getName().endsWith(".txt")){
Reader textReader = new FileReader(textFiles[i]);
Document document = new Document();
document.add(Field.Text("content",textReader));
document.add(Field.Keyword("path",textFiles[i].getPath()));
indexWriter.addDocument(document);
}
}

indexWriter.optimize();
indexWriter.close();
long endTime = new Date().getTime();

System.out.println("MergeFactor: " + indexWriter.mergeFactor);
System.out.println("MinMergeDocs: " + indexWriter.minMergeDocs);
System.out.println("MaxMergeDocs: " + indexWriter.maxMergeDocs);
System.out.println("Document number: " + textFiles.length);
System.out.println("Time consumed: " + (endTime - startTime) + " milliseconds");
}
}


通过这个例子,我们注意到在调整缓冲区的大小以及写磁盘的频率上面 Lucene 给我们提供了非常大的灵活性。现在我们来看一下代码中的关键语句。如下的代码首先创建了类 IndexWriter 的一个实例,然后对它的三个参数进行赋值。

int mergeFactor = 10;
int minMergeDocs = 10;
int maxMergeDocs = Integer.MAX_VALUE;
IndexWriter indexWriter = new IndexWriter(indexDir,luceneAnalyzer,true);
indexWriter.mergeFactor = mergeFactor;
indexWriter.minMergeDocs = minMergeDocs;
indexWriter.maxMergeDocs = maxMergeDocs;


下面我们来看一下这三个参数取不同的值对索引时间的影响,注意参数值的不同和索引之间的关系。我们为这个实验准备了 10000 个测试文档。表 1 显示了测试结果。

表1:测试结果


通过表 1,你可以清楚地看到三个参数对索引时间的影响。在实践中,你会经常的改变合并因子和最小合并文档数的值来提高索引性能。只要你有足够大的内存,你可以为合并因子和最小合并文档数这两个参数赋尽量大的值以提高索引效率,另外我们一般无需更改最大合并文档数这个参数的值,因为系统已经默认将它设置成了最大。

Lucene 索引文件结构分析

在分析 Lucene 的索引文件结构之前,我们先要理解反向索引(Inverted index)这个概念,反向索引是一种以索引项为中心来组织文档的方式,每个索引项指向一个文档序列,这个序列中的文档都包含该索引项。相反,在正向索引中,文档占据了中心的位置,每个文档指向了一个它所包含的索引项的序列。你可以利用反向索引轻松的找到那些文档包含了特定的索引项。Lucene正是使用了反向索引作为其基本的索引结构。

索引文件的逻辑视图

在Lucene 中有索引块的概念,每个索引块包含了一定数目的文档。我们能够对单独的索引块进行检索。图 2 显示了 Lucene 索引结构的逻辑视图。索引块的个数由索引的文档的总数以及每个索引块所能包含的最大文档数来决定。

图2:索引文件的逻辑视图


Lucene 中的关键索引文件

下面的部分将会分析Lucene中的主要的索引文件,可能分析有些索引文件的时候没有包含文件的所有的字段,但不会影响到对索引文件的理解。

1.索引块文件

这个文件包含了索引中的索引块信息,这个文件包含了每个索引块的名字以及大小等信息。表 2 显示了这个文件的结构信息。

表2:索引块文件结构


2.域信息文件

我们知道,索引中的文档由一个或者多个域组成,这个文件包含了每个索引块中的域的信息。表 3 显示了这个文件的结构。

表3:域信息文件结构


3.索引项信息文件

这是索引文件里面最核心的一个文件,它存储了所有的索引项的值以及相关信息,并且以索引项来排序。表 4 显示了这个文件的结构。

表4:索引项信息文件结构


4.频率文件

这个文件包含了包含索引项的文档的列表,以及索引项在每个文档中出现的频率信息。如果Lucene在索引项信息文件中发现有索引项和搜索词相匹配。那么 Lucene 就会在频率文件中找有哪些文件包含了该索引项。表5显示了这个文件的一个大致的结构,并没有包含这个文件的所有字段。

表5:频率文件的结构


5.位置文件

这个文件包含了索引项在每个文档中出现的位置信息,你可以利用这些信息来参与对索引结果的排序。表 6 显示了这个文件的结构

表6:位置文件的结构


到目前为止我们介绍了 Lucene 中的主要的索引文件结构,希望能对你理解 Lucene 的物理的存储结构有所帮助。

参考资料

学习

您可以参阅本文在 developerWorks 全球站点上的 英文原文 。

实战 Lucene: 初识 Lucene 介绍了 Lucene 的一些基本概念,然后开发了一个应用程序演示了利用 Lucene 建立索引并在该索引上进行搜索的过程。

Parsing, indexing, and searching XML with Digester and Lucene 是 Otis Gospodnetic 在 developerWorks 上发表的一篇关于利用 Lucene 和 Digester 来操作 XML 文档的文章。

IBM Search and Index APIs (SIAPI) for WebSphere Information Integrator OmniFind Edition 是 Srinivas Varma Chitiveli 在 developerWorks 上发表的一篇关于如何用 SIAPI 来构建搜索解决方案的文章。

Lucene的官方网站:上面有大量的 Lucene 帮助文档。

一个关于 Lucene 的演讲:是由 Lucene 最初的作者 Doug Cutting 在 Pisa 大学所作。

现代信息检索是由 Ricardo Baeza-Yates 和 Berthier Ribeiro-Neto 所写的关于信息检索方面的一本著作。

developerWorks Web Architecture 专区:上面有很多关于如何构建网站的技术文章。

获得产品和技术

下载 Lucene 最新版本。

讨论

加入 Lucene 邮件讨论组:Lucene mailing list。

developerworks 论坛:上面有众多的技术人员在讨论技术问题。

关于作者
周登朋,上海交通大学研究生,目前在IBM上海国际化实验室(SGL)实习,对Java技术以及信息检索技术非常感兴趣,你可以通过 zhoudengpeng@yahoo.com.cn来联系他.






Dr. Amit Singhal and Google AK47

From Google Researcher WuJun: 枪迷或者看过尼古拉斯.凯奇(Nicolas Cage)主演的电影“战争之王”(Lord of War)的人也许还记得影片开头的一段话:(在所有轻武器中,)最有名的是阿卡 47( AK47)冲锋枪(也就是中国的五六式冲锋枪的原型),因为它从不卡壳、从不损坏、可在任何环境下使用、可靠性好、杀伤力大并且操作简单。
我认为,在计算机中一个好的算法,应该向阿卡 47 冲锋枪那样简单、有效、可靠性好而且容易读懂(或者说易操作),而不应该是故弄玄虚。Google 的杰出工程师阿米特.辛格博士 (Amit Singhal) 就是为 Google 设计阿卡 47 冲锋枪的人,在公司内部,Google 的排序算法便是以他的名字命名的。
从加入 Google 的第一天,我就开始了和辛格长期而愉快的合作,而他一直是我的一个良师益友。辛格、Matt Cutts(中国一些用户误认为他是联邦调查局特工,当然他不是)、马丁和我四个人当时一同研究和解决网络搜索中的作弊问题(Spam)。我们需要建一个分类器,我以前一直在学术界工作和学习,比较倾向找一个很漂亮的解决方案。我设计了一个很完美的分类器,大约要花三个月到半年时间来实现和训练,而辛格认为找个简单有效的办法就行了。我们于是尽可能简化问题,一、两个月就把作弊的数量减少了一半。当时我们和公司工程副总裁罗森打了个赌,如果我们能减少 40% 的作弊,他就送我们四个家庭去夏威夷度假,后来罗森真的履约了。这个分类器设计得非常小巧(只用很小的内存),而且非常快速(几台服务器就能处理全球搜索的分类),至今运行得很好。
后来我和辛格一起又完成了许多项目,包括对中、日、韩文排名算法的改进。每一次,辛格总是坚持找简单有效的解决方案。这种做法在 Google 这个人才济济的公司常常招人反对,因为很多资深的工程师怀疑这些简单方法的有效性。不少人试图用精确而复杂的办法对辛格的设计的各种“阿卡47” 进行改进,后来发现几乎所有时候,辛格的简单方法都接近最优化的解决方案,而且还快得多。另一条选择简单方案的原因是这样设计的系统很容易查错(debug)。
当然,辛格之所以总是能找到那些简单有效的方法,不是靠直觉,更不是撞大运,而是靠他丰富的研究经验。辛格早年从师于搜索大师萨尔顿(Salton)教授,毕业后就职于 AT&T 实验室。在那里,他和两个同事半年就搭起了一个中等规模的搜索引擎,这个引擎索引的网页数量虽然无法和商用的引擎相比,但是准确性却非常好。在 AT&T,他对搜索问题的各个细节进行了仔细的研究,他的那些简单而有效的解决方案,常常是深思熟虑去伪存真的结果。
辛格非常鼓励年轻人不怕失败,大胆尝试。一次一位刚毕业不久的工程师因为把带有错误的程序推出到 Google 的服务器上而惶惶不可终日。辛格安慰她讲,你知道,我在 Google 犯的最大一次错误是曾经将所有网页的相关性得分全部变成了零,于是所有搜索的结果全部是随机的了。这位工程师后来为 Google 开发了很多好的产品。
辛格在 AT&T 时确立了他在学术界的地位,但是,他不是一个满足于做实验写论文的人,于是他离开了实验室来到了当时只有百、十人的 Google。在这里,他得以施展才智,重写了 Google 的排名算法,并且一直在负责改进它。辛格因为舍不得放下两个孩子,很少参加各种会议,但是他仍然被学术界公认为是当今最权威的网络搜索专家。2005年,辛格作为杰出校友被请回母校康乃尔大学计算机系在 40 年系庆上作报告,获得这一殊荣的还有大名鼎鼎的美国工程院院士,计算机独立磁盘冗余阵列(RAID)的发明人凯茨(Randy Katz) 教授。

Tuesday 17 April 2007

MOL IST

MOL(Maintence On_Line)
IST(Integration and System Test)
1.GSR MOL IST Project Scope:
MOL IST is responsible for verifying the fixes of the SRs merged into each software release and make sure it don’t impact the existing system functionality. Different sized regression suites are used on a given release depending upon a number of
factors, including the type of release (Service Pack, QuickFix, etc.), scope of the changes, and amount of time available. MOL IST includes:
• SITG test
• Performance test
• Voice quality test
• Upgrade/Rollback and Compatibility
• Large configure test
2.MOL IST Objectives
The key MOL IST project objectives include at a minimum:
• Verify SRs have been fixed completely
• Verify the fixes don’t impact existing system functionalities
• Conduct MOL SPR regression test to ensure system functionalities
• Conduct small feature test dropped into the SPR
3.Roles & Responsibilities
3.1 Release Manager
• Release Manager has completely release/project responsibility for driving the Integration and System Test teams to meet all their deliverables and prime contact to the program manager of the project for Integration and System Test.
• Control the schedule and evaluate the work effort to meet all the deliverables
• Communication with other MOL management team member about load test issue and other thing.
• Summary the test result and collect the data to improve the MOL test
3.2 Team Leader
• Team leader lead the team from test execution perspective.
• Assign the work and SR list when the load is scheduled
• Distribute resources and equipment in the team coordinate the equipment between the different teams
• Control the test program and collect the test result to analyze it from technical perspective.
3.3 Release Technical Leader
• Team technical leader that has complete release/project responsibility for delivery of the test deliverables for the whole project and for meeting the test preparation and execution schedule from technical level.
• Preparation and execution on load test plan and test method.
• Trouble-shooting in technical field
• Communicate with customer profiling owner to get useful customer data for test coverage and toimprove test quality.
• Make sure feature test smoothly handover to MOL test, including test equipments/tools are ready before MOL testing, features technical training to MOL engineers, and initial the MOL test strategy.
• New test cases review/inspection when MOL engineers design new test cases against SRs or DCA action.
• Apply DCA trend analysis result into MOL test strategy and test improvement
• Audit MOL testing, so as to follow the correct process and high test quality.
3.4 System Tester
System testers in MOL IST team are responsible for the setup of test equipments, and the execution of MOL SPR test per test plan. Create new test cases if no specific case for SRs. Investigate problems with developer, and raise the SRs if necessary. Fill the TMS with the test results and comments. Put the logs to specific directories.