上文所提到的项目的SRE问题，现在已经有了一个完整的分析。

1. SRE有个前提，所有新功能要在中前期进完。SRE假定基于对于功能和系统的熟悉程度，一开始bug的数量少一些，随着逐渐熟悉，在中间bug数量会到达一个顶峰，在后期bug数量会迅速下降。目前的项目自始至终都在进新的功能，所以这个前提满足不了，从而SRE失去了他的质量指示意义。

2. 如果项目的总的bug数量不多，SRE的精确性也会打折扣。这是因为假如你在后面偶然发现了两个bug,而由于总的bug数量并不多，SRE有可能给出不切合实际的指示。当前的项目也有这个问题。

基于上面的分析，如何使用SRE应该比较清楚了。对于大型，功能及早集成好的系统，是具有质量指示意义的。而对于中小型，功能持续集成的系统，SRE只能帮助我们分析当前的问题，但并不能将其作为衡量软件质量的标准。

SRE是一个理想中的模型，有一些使用的假定。但现实中的项目往往无法全部具备所有的假定，故此我们不可以完全依赖于SRE的指示，否则就可能造成各种资源的浪费。但另一方面，它的确能够帮助我们分析当前存在的各种问题，以便于将来可能避免。所谓尽信书则不如无书，所有的东西都不能盲目的说好或者不好。

一个项目快要结束了，但我发现SRE有些问题，目标是97%，但现在数据显示只有60%多。

SRE(software reliability engineering)是一种软件稳定性指标，97%意味着测试已经发现了软件所有缺陷的97%，还有3%没有被发现。从一个软件的投入产出比而言，100%是没有必要的，因为那意味着需要更多的测试时间，这也就意味着更多的resource的投入和schedule的延长。SRE的结果和设定的基准缺陷数有关，和不同时间段内发现的缺陷数有关，和测试时间有关，是一个复杂的公式。

但目前的60%多肯定有问题，我不相信还有30%多的缺陷存在在系统内。因为我们的测试策略与以前的项目没有多大的不同，而上一个项目的最终数据显示超过98%的缺陷以被发现。那，问题在哪儿呢？该怎么解决呢？

最近两周发现的bug数和前面相比，有了一个明显的上升，原因在于在这个最新的build里面引入了一些新的，较前相比更复杂的功能。SRE的计算公式对此的处理是认为根据目前的趋势，意味着未来依然会有很多的bug，需要更多的测试时间来发现。而问题在于, SRE是一个理想的模型，它缺省认为系统中间不在有更多的新功能引入，而这和这个项目的现实是不一样的。

难道是现在使用的SRE模型不适合这个项目？这个问题需要继续调查。通过调整各种数据来看SRE到底是如何据此来做预报的。

这个问题目前不是我一个人说了算的。项目的质量保证计划上已经设定了这个目标，而这个目标显然是无法达到的。我需要做的是，先自己做充分的调查，有一个基本的判断。然后邀请相关的SRE专家，质量控制人员来做进一步的处理 - 希望不要过于繁琐和官僚。

做project leader已经一年半了，有很多收获，也有很多痛苦。

收获：

锻炼自己的领导能力；锻炼自己的抗压能力，提高自己的心理素质；加强自己为人处事，与人沟通的方式，把握处理事情的度；提高英语口语水平；对软件测试的流程有很好的把握，能够很有计划的把一个项目做下来；对整个软件的流程也有很多的理解；能接触到一些非工程层面的东西，有助于开阔眼界；……

痛苦：

带项目要考虑的是整个项目，整个团队，所以会想很多，从而也有很多烦恼，很多问题自己也无法完全解决。压力之下，有时候心情不太好，睡眠也不太好，所以现在睡觉的时候总是强迫不要再想东西。涉及到人时候，不可能每个人都满意，总有人不满意，如何处理，如何对待，也是一件费心的事情，出发点应该是基于对项目，对团队有好处，而非从感情角度出发。如何能在困难艰苦的时候，仍然能让大家齐心协力的完成目标。

林林总总，不止这些了。人总是要不断的发展，才会让自己觉得人生有希望，生活有意义。既然都做了1年半的组长了，下一步就要考虑如何向manager发展。我的计划是在2010年底前，从一个project leader成长为manager。把目标写在这里，人才会更有动力，更能承受压力。我现在理解的manager的工作范畴，某些方面和project leader有重叠，也有一些方面不一样，不一样之处有：

1. manager是资源的管理者和分配者，leader也有这方面的角色，但没有manager这么明显。资源是一个很大的话题，包括你如何有效的取得资源，有效的分配资源，有效的管理资源，有效的优化资源。资源短缺的时候怎么办？资源争夺的时候怎么办？downsize的时候如何操作。

2. manager应当是个领路人。为部门指引方向，描述愿景。构建有活力，有创造力，有战斗力，合作而又有良性竞争的团队。给人以希望，让人愿意为之工作。能用人之长，会用人。

3. 有成效的绩效考评制度。好的绩效制度要考虑个人表现，团队合作，态度等诸多方面。要有可操作的具体标准，要有可量化的数据支持。但要防止因此而带来的潜在的负面作用。（不公平竞争，欺骗性的数据，团队矛盾过于激化等）。

4. 个人魅力/修养/能力。这个是个泛泛的东西，需要用心揣摩。比如公众演讲能力，魄力，敢于承担责任和压力，为人处事的度的把握。等等。

先写这么多，这些还是需要不断反思和总结的。

从05年8月至今，做测试已经快满3年了，该做下小结了，回顾昨天，把握现在，展望明天。

1。从不情愿开始

还没毕业的时候就来到公司实习，职位是测试。心理不乐意，前面有文章说过历程，不再赘述。

2。开始认真面对

混着也是混着，对自己没有任何好处，为什么不好好干呢？于是转变观念，开始努力去工作，期间收获还是不少。因为自己的积极主动还有幸运的机会，虽然没有名分的带项目，但学到了很多带项目的知识，leader和manager也很认可自己。从而出现了一个好机会。

3。机会到来

种种原因，manager去年底决定把我放到project leader的位置上，应该算自己职业生涯的一个转折点。我知道从工程师到leader是小小的一步，但恰恰是职业发展的一个必需的起点，必经之路。

4。在路上

从leader到现在，过去半年了，从开始的诚惶诚恐，到现在逐渐适应角色。不容易，压力很大，但这是成长路上必须经历的。在这个职位上，自己仍然还有很多需要提高的，所以只有努力工作，努力学习，争取跨过这个坎。

5。一切都不是偶然

人往高处走，有几点必须做到。积极的心态；勤奋；乐于助人；挑战自我。成功从来不是偶然，而由心血浇灌。

6。因为难，才好玩

最近品味这句广告词，颇值得回味。迎难而上，越挫越勇，人才有进步，才会前进。但这些也不过是场游戏而已，本质上和电子游戏没有本质区别，play to win，你很容易就得到的，反而索然无味。这是场难玩的游戏，但需要轻松的心态。难，才好玩；不难，有意思的？跨过去，淡然一笑，把背影留给过去，奔向下一站。

原则1：

A necessary part of a test case is a definition of the expected output or result.

测试用例的一个必要组成部分是期望输出或结果的定义。

原则2：

A programmer should avoid attempting to test his or her own program.

程序员应该避免试图测试他自己的程序。

原则3：

A programming organization should not test its own programs.

程序开发部门不应该测试自己的程序。

原则4：

Thoroughly inspect the results of each test.

彻底地检查每一个测试的结果。

原则5：

Test cases must be written for input conditions that are invalid and unexpected, as well as for those that are valid and expected.

不仅要为有效的和期望的输入条件设计测试用例，而且还要为那些不合法的和不期望的输入条件设计测试用例。

原则6：

Examining a program to see if it does not do what it is supposed to do is only half the battle; the other half is seeing whether the program does what it is not supposed to do.

仅仅检查一个程序做了它应该做的事情只是完成了一半；另一半是检查程序是否也做了它不应该做的事情。

原则7：

Avoid throwaway test cases unless the program is truly a throwaway program.

除非程序已被抛弃，否则应该避免抛弃你的测试用例。（能够被regression test重用）

原则8：

Do not plan a testing effort under the tacit assumption that no errors will be found.

不要在基于没有错误会被发现的假设下计划测试所花的人力物力。

原则9：

The probability of the existence of more errors in a section of a program is proportional to the number of errors already found in that section.

在程序的某个模块中，更多错误存在的可能性与那个模块已经发现的错误数量是成正比的。

原则10：

Testing is an extremely creative and intellectually challenging task.

测试是一个极富有创造力和聪明才智的挑战性的任务。

PS，上班时间写blog有点不好意思。 

我现在在成都的一家外企工作，没毕业的时候就来实习，到现在算起来差2月不到两年。期间一直做测试。聊聊自己的测试经历，相信很多做测试的朋友和我有类似的感触。

刚来公司，听说让做测试，心里100个不愿意，非常抵触。自己觉得自己技术还不错，在学校里接过一些活，做的都还不错。最大一票一个人做个1W多dollors的项目，自我感觉良好（直接解决买房子的首付问题）。不乐意归不乐意，成都也没几家比这个公司好的了，心想先凑合着吧，然后就差不多凑合了1年，直到都毕业了。

凑合的这段时间怎么说呢，我觉得还是对得起公司吧，虽然没有以主人翁的精神去干活，但也没给项目拖过后腿，上上下下反映都还不错，觉得这小伙子挺踏实认真的。凑合的这段时间，自己也没少折腾，面试过其他公司（被鄙视了），接过私活，还和以前合作伙伴共商合作大计（12000/m，3年后5%期权，后来我保守了，没去……）。

后来慢慢自己思想也在变化，想自己这样子混日子下去，有什么意义？既然现在在做这一行，干脆就干好，要不这两年纯粹浪费，半瓶子水，高不成，低不就。在项目组里，自己也算老员工了，所以也有很多机会去锻炼。现在基本上自己在负责一个大些的项目的测试，带着几个XDJM。还行，Leader太懒，基本上plan，interface，assgin,report之类的活我都给做了。leader偷懒给我安排活的时候，有时候心里不乐意，以轻蔑的眼神瞅着他，瞅的他都挺惭愧的……。话虽如此，还是锻炼人的，自己觉得还是有收获。

说点实际的吧。

1。测试不需要很多的开发技能。但有更好，因为肯定会有些大批量数据处理或者耗时的测试（性能，压力测试等），这个时候就要考虑写个小工具来自动化处理。

2。测试这个行业应该说方兴未艾，距离成熟还远得很。只要你能力强，职业发展上比开发更容易上升，因为大部分人都想做开发……

3。测试是整个软件开发周期的一部分，和开发沟通很频繁。所以一个有效的process很重要。有效而不流于形式。

4。测试前期的plan，requirement review很重要。plan是要对整个测试的coverage, load有个基本的框架，包括很多非功能性的（很多不在requirement上，所以很容易漏掉）。requirement review就是把bug扼杀在摇篮里，对于问题，the earlier, the better.

5。测试的环境，设备，工具等以及相应的risk management：提早申请，提早购买，定时tracking. 免得用的时候发现还没买。

6。Tracking工作。对team Leader而言，要了解软件有多少release, 每个release有哪些feature, feature之间有没有imapct。什么时候disign test case, 什么时候review test case等。每个team member手头的活的进度如何等。

7。对于bug的管理是测试的一个核心。市面上有一些bug manage/tracking tools. Rational Clear Request etc. 有完整的process来控制bug的整个生命周期。

8。自动化测试。它既不像你想象的那么有用，也非一无是处。对于稳定的feature的回归测试（regresstion test)，自动化测试就会派上用场。另一个用处就是做压力测试。包括自己写的tool，也是自动化测试的一部分。针对GUI的自动化测试工具有：WinRunner, QuickTest Pro, Rational Robot etc.

9。lesson learn。总结上个项目的不足，在下个项目中改正。

10。未完待续……

上面说的都是些冰冷的条款，说点人性化的条款：

1。对你的team member好一点。不要tracking的别人无法呼吸。保持一定的信任度。

2。不要完全以bug的数量来评价member的成绩。这会偏离主题。

3。我讨厌形式主义的加班。赶着去测试，能测的仔细吗？

4。to be continue...

说点自己需要提高的地方：

1。英语口语。一哥们和老外开会，我都替他出了一把汗。这个行业，英语听说太重要了。

2。自动化测试。自己接触的不多，下一步的提高目标。

3。让自己再成熟些，沧桑些……

要和老外开会了。写完，收工！