加密锁测试感受总结

这段时间一直在做公司加密锁方面的测试，快到年底任务尤其的紧，已经很长时间没来这里更新日志了，而且对于自动化工具方面的经验也来不及沉淀总结，算是为偷懒找个借口吧...

加密锁的测试是我第一次接触，感觉很新奇。一个小小的“U盘”就关系到公司几千万的产值，压力也是很大的。而且加密锁涉及到公司内部很多项目组的产品，所以测试起来相当麻烦，业务相对简单但组合分支众多，测试用例庞杂，我们不仅要关注软件同时还需考虑硬件和兼容性等多种环境。在团队组建方面也是首次采用虚拟团队的方式，从事业部到研发、测试都是从各项目组抽调的，当然这里也遇到了很多问题。下面就谈谈我对加密锁测试的一些感想，希望不管对自己还是别人都是一种总结和拓展。

一、需求不确定

开始接手加密锁测试首先遇到的问题就是对老版加密锁的需求整理。因为之前没有任何文档，所以我们所有的需求来源只能依靠市场的反馈和不断测试验证来总结，可以说所有的指导都是基于“想象”。于是我们决定将所有验证的步骤和结果作为测试用例编写到TD库中，一方面记录我们做过什么，一方面可以作为需求依据提供给市场和开发人员，如果他们发现预期结果有错误，则可以很快很明确的改正，而排除大家都自认为正确的情况。

PS：以前我面试过一家大公司，考官曾经问过我需求文档应该由谁来编写，我说由需求人员啊，于是考官一脸的疑惑（还有需求人员这个职位？）可见不管是什么规模的企业，需求在软件流程中的定位总是不能很明确。

没有一个具有“权威”性的人，将会给之后的开发和测试带来很多不便。

二、开发人员的调动

项目过程中开发人员的调动给软件质量带来了一些反复，但还好加密锁本身并不复杂而且开发人员能力相差不大，所以这种反复没有带来很大损失。但可以肯定的是不管一个团队协作怎样顺畅，个人能力对项目进度和质量的影响还是占有相当比重。各开发人员编码能力不同，对需求理解也不同，不熟悉之前代码的人修改一个bug后产生的连带问题会很多。我知道有一个项目组就是因为新人过多，造成软件质量无法控制，久而久之开发和测试之间相互不信任：开发人员编完一段代码后不想交付测试，测试人员拿到一个新模块后总不放心，于是项目组内部情绪很对立，这样使得任务进度很难控制。

三、与其他项目组的协调

前面已经说过加密锁涉及到其他项目组的软件，这就需要项目组人员的配合，很突出的问题就是我们“支配”不动其他项目组的开发人员，项目组的代码改动必须经由更高一层的领导同意，才能逐层传达命令，而命令的准确性也是逐层递减的。于是前期已经确认好的问题到实现后发现根本不一样。

加密锁也是虚拟团队组建的一个试验，即是说开发经理、测试经理并不完全投入到这个项目中，他们同时还兼顾其他项目，于是领导对本项目的了解程度就大大降低，而且不能做到拍板决定。有时一个解决方案要来回循环很多次才能决定，这个问题一直没有得到很好的解决。

四、复杂的环境和众多的测试组合

真正涉及到测试的任务就是整理测试用例和测试执行。因为加密锁测试在一定程度上是偏硬件的，而且对环境和支持软件的组合较复杂，所以整理用例这块花费了我们很多的时间。前面说到加密锁没有统一的需求文档，所以我想以测试用例驱动开发，在测试执行之前考虑出尽可能详细的组合情况，编写用例交予市场和开发人员参考，得到统一认同后可以避免许多潜藏的问题，节省了不必要的开发浪费。事实证明这一点是非常有效的，在用例编写过程中我们发现了很多初期考虑不周详的问题，并即时终止了一些错误的功能开发，也发现了很多老锁中就已隐藏很久的问题，并进一步规范了加密锁的使用，得到市场人员的信任。

下面大概介绍一下我们测试加密锁的用例方案：

实际编写用例的过程中我们将加密锁分为新版单机锁，新版网络锁，老版单机锁，老版网络锁（老版锁还有很多型号）。操作系统上我们主要关注Win2000，WinXP，Win2003，对Win98系统不做详细测试，只保证能够正常安装驱动。

1、对加密锁的检测和兼容性：

client端插入一把新版单机锁，插入两把新版单机锁，同时插入一把新版单机锁一把老版单机锁...能否正确检测注册产品

SRV端插入一把新版网络锁，插入两把新版网络锁，同时插入一把新版网络锁一把老版网络锁...client端能否正确检测注册产品

2、网络锁SRV端对client的控制和节点数控制：

client端指向正确的SRV端，client端指向没插入网络锁的一台机器，client端指向SRV端的同时本机也插入一个单机锁并检测，能否正确检测注册产品。

小于等于连接节点数时所连client端能否正确打开软件，大于连接节点数时超出的client是否以学习版打开，插入两把网络锁同一产品的节点数是否相加，client正常退出连接时节点数是否扣除，client非正常退出时节点数是否有超时控制...

3、试用版加密锁对时间、次数的控制：

超出试用时间软件是否可用，调整系统时间后软件是否可用，同时插入两把试用锁且试用时间不同时软件怎样判断...

超出试用次数软件是否可用，软件怎样判断扣除次数，如同一台机器上打开多个软件和同一个软件打开多份保存文件...

目前对加密锁总结的测试方案大致以上这些，其中细节部分因为涉及敏感而没有一一列出，希望能给做类似测试的朋友一些拓展，同时如果我有什么遗漏也请交流。

五、感受总结：

上面的几条标题似乎都是在“痛斥”这个项目的不足之处，惟有测试组合部分才真正说点实际的内容，也许这和我在项目中还是一个小兵的位置有关吧^_^!总是在抱怨却很难改进。

但这次加密锁测试仍然给我许多不错的经验总结：

l        首先要定下一套明确的标准，怎么做是对怎么做是错。这套标准要让项目中所有人认同，无论中间的过程怎样争吵，当目标确定后就要一致统一，且尽量保证少发生变更。

l        在测试执行前制定详细的计划方案，进一步思考实际中可能发生的情况，这样可以有效减少潜在的问题，避免不必要的反复。

l        对测试方案和用例做结构化的分类，与同组的测试人员一同讨论编写，会使大家对未来的测试都有一个明确和开阔的认识。对于像加密锁这样的测试，我们需要考虑众多组合内容，结构化用例并与市场人员协商做适当取舍，这样可以突出实现的重点，简略极少存在的情况，规范使用，减少工作量。

l        多与开发和市场人员沟通并得到确认，掌握项目的进度，得到别人的信任。我认为测试人员对于一个项目的整体把握要好于开发人员，因为我们更关注的是软件的实现而非代码，这使得我们能从一个更高的视点来观察。

加密锁测试有其特有的地方，如对环境和支持软件的依赖，不同版本加密锁的兼容性等但总结起来测试的方法没有太大改变，在用例设计方面我们主要偏向实际流程用例，脱离开单个模块的功能，这样不管对市场还是开发人员都更具说服力。定期的沟通和汇报进展可以让自己和别人心里更踏实，对进度的瓶颈也能做到及时察觉和避免。

到目前为止加密锁测试还没有完全结束，项目的运作也还未及成熟，回顾这几个月的工作感受还是颇丰的，至少让我对怎样把握一个流程有了新的认识，不管你掌握多少技能或学会多少工具，协助提高软件的质量才是测试的目标。如何协调一个团队，这里的学问很大。希望大家都能稳扎稳打，早日进入更高的层面和职位^_^