工作总结

今天是2012年12月6日，不知不觉已经工作2年多，我所在的项目MDM HCP 马上就到头了，到头的意思就是项目要拿到印度去做，我们可以和MDM说拜拜了。

 

从毕业开始就进入到了这个ＭＤＭ项目，那是还是MDM2.5,现在MDM3.8马上就release了。

还是从2.5说起吧：

 

１０年７月份刚毕业，本来说是要去另外一个项目，不过那个项目没拿下来，就来MDM了，说是测试其实什么都不会，英语也不好，只要一开会和老外，就紧张的要命，因为听不懂，说不出来。

 

其实ＭＤＭ真的很强大，文档，业务逻辑，Framework都够我们学习的，只是那时候比较嫩，还体会不了.

 

说到文档，MDM 项目有大量的文档，每个不同的feature都有自己的文档，每个版本的MDM都有很多feature change,我们叫FSD – Functional Specification Document.这个文档是ＰＭ写的，ＰＭ是我们项目人员与客户的接口，他们会把客户的要求详细的定义好，写到这个文档上面去，细致到每一个操作的细节，名字都会有定义。

 

测试初期我们会开始读FSD文档，其实在ＦＳＤ出炉之前会有一个one page文档，这个文档会定义这一版遇到了那些问题，哪些需要改进，怎么改进，是一个简单的论述。我觉得ＦＳＤ就是根据onepage扩展的。读文档真的很重要，尤其是刚进项目，相对这个项目了解更多的同事，一定要多看文档，多问问题。即使每一个词的事态都要不放过。一旦有问题，就要给ＰＭ写信去确认，其实这时候可以报bug了.如果这时候能发现设计的缺陷或是给ＰＭ提出很好的建议或是问题，其实就是给他提醒，会赚足印象分。

 

读完了FSD,我们测试人员要出一个test plan,其实确切的说是，针对每一个feature,写关于这个feature的test plan. 这个plan 要包括你对这个feature的理解：

1.      什么应该测，什么不应该测

2.      Workflow

3.      Test scenario

4.      Test case, Test Data

5.      A schedule for test caseexecute

 

 

之前写过test plan,　因为是第一次写，所以被Dev，ＰＭ搞了好多次，而且留下了不好印象，因为我们从来没有写过test plan,之前的plan是交给ＦＴＥ，我们是负责执行的。

能有机会写plan 和被review其实也是不错的锻炼机会。最主要的问题是我们对整个feature了解熟悉程度不够，这就要追溯到读FSD阶段没有能够问出问题，导致test plan直接copy FSD,再加上我的英语不过关，PM肯定不放心交给我们测，人家要重点看测什么，怎么测。

What and how

至于流程图，最好对整个feature有个整体了解之后，尤其是在整个项目的位置，这个feature怎么工作的，流程图就是考察你对自己feature理解。

根据workflow就可以写Test scenario,每个scenario扩展自己的test case , test data,这时候尽量想好，自己用什么样的测试数据，有没有DataDriven　test,　用不用DB,如果用DB就要设计自己TestDB,　看看之前其他feature的DB是怎么设计的能不能借鉴，还是CSV文件，都是可以借鉴的。个人觉得要是DataDriven　如果很多的话就用ＤＢ,CSV文件不是很好编辑，加一条数据，或是调试的时候都不好用。

 

后面说plan里面还要有个时间计划，就是执行你的那么多test case需要多长时间，这是给leader用来估算时间用的，一定要尽可能多给出缓冲时间。这时候时间长了，后面压力能小一些。

 

谈到了test case, 就会有人问什么样的test case是一个好的test case,我觉得一个好的test cases 能发现bug,　能够让一个对这个feature不是很懂的人，也能把case看懂，并且能够执行。Test case 会告诉你测什么，还会告诉你怎么测。具体到每一个步骤，input,　output

也就是尽可能的详细。

 

Example

Test Summary

   What you are testing, what you are testingfor this feature?

2) Test inputfile

   This section will list what are variationsof the inputs you are going to provide. I think matrix is good

3) Test result

   This section is detailing what should behappen when this test case is run, what is the test result. 

4) Testvalidation

   This is about what is it you are verifyingfor this tests.

1)      Response Data from web services

2)      DB update

3)      Exception

 

每个test case都会有级别，p1,p2　最高的是Ｐ１我们会用它来做ＢＶＴcase

写好了test case 我们就可以automation 了，如果是自动化测试，VSTF是支持自动导入test case到VSTF的.

 

 

查询suite命令：tcm suites /list /planid:997/collection:http://msitvstf1:8080/tfs/RXD /teamproject:RXD_AP_MDM

 

导cases命令：tcm testcase /import /collection:http://msitvstf1:8080/tfs/RXD/teamproject:RXD_AP_MDM /storage: E:\New

sLetterSubscription\NewsletterUnsubscribeCode\LookupAllSubscription\bin\Debug\L

ookupAllSubscription.dll /syncsuite:16101

 

tcm testcase /import/collection:http://msitvstf1:8080/tfs/RXD /teamproject:RXD_AP_MDM /storage:需要导入的cases的dll

/syncsuite:查询到的suite id

 

最好先在MTM里创建完文件夹，再到ID，再导case。

剩下的step, result可以用excel打开，然后一起加进去，这样的能提高效率

最好每个自动化的case，都能有个workitemid这样能快速的mapping VSTF和你的case

还有你的测试数据。

 

Automation 的时候就会遇到framework的问题，3.0版本之前我们的code都是用的ＱＡ自己testframework,到了3.0客户要求要用 DEV 的UT framework,还要求我们用scenario来cover，那个UT framework还是值得我们学习一下的。以后再分析他的framework,说到scenario写好它，还真是不太容易。用了scenario的话case看起来干净整洁，只需要new　特定的scenario就好了，一个scenario尽可能的覆盖更多的case ,因为好多case，在input,还有验证结果的时候有所不同，我们就搞了很多参数来区别对待，后来参数越来越多，多到我们不能一眼就看出来那些参数有什么意思，只能debug，效率反而更低。后来就干脆，一个ＷＣＦ方法一个scenario,我们要Suppress Persona,就先调用UpdateScenario,然后再调用suppress scenario这样就scenario个数就固定了，参数很少，便于debug.

 

Scenario 的个数确定了，为了便于debug我们需要加入一些log，一旦我们的testcase失败了，我们能从output之中找到关键点，比如我们的Config没有改对，webstore没有改，

stepCd没有到６，卡在３我们就知道是businesspipline有问题了，５,我们就该去看Eventing pipline。这样很能提高效率，不用再去花时间debug一边，才能发现问题出在哪。

曾经客户提出一个要求，就是让我们把每个scenario都加一条环境验证，比如我想suppress persona,我要去验证create/suppress是不是能调用这两个方法。如果不能调用直接就返回错误。其实我倒是觉得可以加一些，但不是所有的，Async方法要验证stepcd到６,这就设计到Eventing server,这是每一个版本release最大的障碍，Eventing是另外一个team做的。说到这先补充一下MDM背景MDM要调用好多第三方微软的产品.

 

ITA: 类似于入口，用户提交request到MDM,这时候ＭＤＭ会调用这个ＩＴＡ去验证，调用这个request的人是否有权限操作ＭＤＭ的resource,他们提交的请求有没有在ＩＴＡ那边认证成功。具体到你注册job的类型，ＯＢＡ权限都可以用ＩＴＡ来限制。

 

Trillium server: 其实ＭＤＭ有自己的trilliumrule,他还会调用第三方的，这个应该在step=3 Business Pipeline里面实现的。　Ｂｅｉｊｉｎｇ－BJ像这样吧

 

Eventing server: 这是最容易出问题的，我们team都快成Eventing专家了，step=5,　发不出来Notification，每次release都是它有问题，不管是bug还是环境问题,什么C/D盘没空间，CPU/memoryusage 100%... ＥＳＢservices down.而且不能start，账户没权限。。

ＩＩＳ停了，要发送的notification有上百万条，这时候就是堵住了，要手动删。其实上面都是小问题，大问题就是Eventing根本不能用，CTP team的人也解决不了。。。

 

CM server: CMSVCC，所有ＭＤＭ读取的CONFIG都在这通过这台Server来定义。最常见的问题就是你用的ＭＤＭ环境没有指向CM，也就是你没有告诉ＭＤＭ用哪台ＣＭ，这是通过注册表来实现的。

　

 

如果你的scenario 写好了，test case  我觉得一分钟一个就够了。

Case写好了就可以找个环境来跑了.其实在ＤＣＣ之前就会有build出来，等ＤＣＣ的是时候我们就应该读完文档，写好test　plan. Automate 的差不多了，如果你有好几个feature的话，可能不会有那么快，也没关系，不过一定要有进度，3.0的时候有个feature叫DataConcurrencyHanding,有这个feature的原因是因为ＭＤＭ有个漏洞吧，如果你想更新Persona name,　开始personaName= Ida,这时候有两个request过来了，一个想把它更新成Neola,另外一个request想更新成Ron,按照PersonaUpdate pipeline先会把这条记录查出来，如果这两条记录都把这个request查出来了，还没有来到及更新，Neola快了一步，抢先更新了，等Ron再去跟新的时候就会出问题了，因为已经没有Ida了。为了模拟这个情况，我就修改了BussinessPipeline，在lookup和 update 两个component之间加了一个sleep　component　这时候这个就好实现了。这还是跟DEV学的，被block好久，说这个的意思是，这个feature其实很小，但是真的实现却不是很容易，不能把问题拖在最后解决，一定要把问题抛出去，如果没有思路自己。我觉得ＭＤＭ　team的人都很能吃苦，也比较上进，最大的问题就是，发现问题了之后不去跟踪，甚至不愿意去问客户问题，也不说出来，即使说出来，其他人一看到跟自己没关系就不管了，当然了其他人也很忙。别人说的时候最好要听一听，想一想，以免自己遇到的时候就白瞎了。

之前笑伟上传过一个文档，他遇到的问题，怎么解决的，给以后ｔｅａｍ的人可以迅速的解决省了不少时间。海林以前刚到ｔｅａｍ的时候看了不知道多少文档，问了好多问题，记了很多很多，因为ＭＤＭ太多值得记的东西，当你都记住的时候觉得也没什么了，庆杰也是，都是有好多学习方法，知道借鉴。以后去了新项目就向他们看齐。

 

当跑完case之后全都ｐａｓｓ，其实这时候是最要命的哈哈

之前3.0 小董own FLIndex,　她在印度姐姐的帮助下写了好多scenario, case,　后来　Kelvin Dai帮小董review 删了大部分case，等case都pass之后，Kelvin　Dai说ＰＭ问什么没有bug，小董欲哭无泪。。

报bug，也讲究技术含量。。Suresh总能第一时间发现bug然后指出来为什么会有这个bug，这样DEV一眼就看出来怎么回事，不过这就要求有点高了，我一般都是描述现象，

用FSD来卡，用Simon的话就是”它干了他该干的活，它没做它不该干的活”，bug其实就是

它没做它改干的，它做了它不该干的。要是有些文档上没写，那就要问ＰＭ，看是不是文档的bug.

 

                              

我可以拿我的provision tool的一个bug来举例

 

Build number

User to run yourtool

Test env:

Command line forrun this tool

Test Data

Repro steps

Expected result

Actual result

Log file

Screenshot 

 

尽可能的让其他同事只要一看到bug就能repro，而不需要你的指导

 

报了bug之后最好写一封信给PM还有DEV　跟踪一下，如果ＤＥＶ看到bug之后，他能repro就会直接去改，这样省时间

 

Unable to repro 也是有可能的，你写的不太清楚，Dev比较懒，还要给他详细解释，再指回去

Bug 被resolved之后要抓时间去新build上面去验，有些比较好的DEV他们会把workiteam记录到bug上面，你只要看一下check in记录直接能找到，就可以知道哪个build已经解了，要是bug上面什么也没写，就只能硬着头皮去看checkin记录，DEV肯定会有写fix什么问题的，也能推断出来，要是还没有就要写信问问了。

 

 

 

我还有一个tool，provisioningtool，用来onboarding　ＯＢＡ的

Tool 其实是最容易出bug的，当初ＦＳＤ文档定义的很模糊，Paul好多功能也没实现好到ＴＣＣ的时候，只能报bug,　手动测试需要准备的测试数据很多，result也是，这一点很恶心，以致到最后跑一次需要很久。后来又加了security tool，手动测试的工作量其实很大的，一定要把前期的测试数据搞好，不过有一次，测试数据都准备好了，ＤＥＶ这小子把数据格式改了，那次坑死了。

 

 

谈到report，其实ＦＴＥ在的时候，我们需要每周，甚至每天(很忙的时候)汇报每天的结果

每天要把自己的问题整理出来，详细描述清楚，因为有时差，沟通不畅会有很多问题

 

 

 

 

想不起来再说什么了，后面想到了补充。