迄今为止，我的几段工作和研究经历都和测试有着或多或少的关系，下面我仅叙述下我的工作经历和我对于测试的一些思考，希望能够有所帮助。
我最早接触的测试是协议测试，那个时候正处于网络硬件快速发展的阶段。从最开始的有线网络产品到无线网络产品，不管网络硬件如何发展、如何更新换代，大家都需要遵循统一的约束——网络协议，因此那个时候最主要的工作就是基于网络协议，验证网络产品对于协议约束的一致性测试。具体的做法就是：根据协议描述（通常都是协议的RFC描述文档），分析协议的特性、流程、关键字，再根据这些提取出要测试的部分——待测点；根据待测点构建待测环境（通常都是一台或者数台终端和网络设备组成的一个局域网或者类广域网），进而撰写脚本，对于待测点进行验证；通过对于提取出的所有待测点的验证情况，评估待测网络产品对于其支持网络协议的一致性情况；最后将验证结果通告网络产品制造商，其根据结果对于产品进行改进。
在协议测试的后期，由于无线网络的迅猛发展，无线网络的产品也越来越多，因此更多的工作是关于无线网络协议的测试。无线网络不仅需要在协议的一致性测试上需要花费一定的精力，其另外一个特性越来越多的受到了厂商、测试人员、用户的重视：无线网络的安全性。因为无线网络报文的开放性，同时由于无线网络协议在安全性方面也不是尽如人意，所以其安全性相对于有线网络显的更加脆弱，所以无线网络产品一般都需要对其进行安全性测试。这个时期的主要工作就是：对于无线网络协议进行分析、提取，找出其中可能被攻击的漏洞，搭建网络环境（基本都是无线局域网WLAN），首先根据提取出的漏洞编写攻击脚本对于无线网络设备进行攻击，对攻击结果进行验证，判断待测无线网络设备是否具有该安全漏洞。在进行协议分析的时候，有些漏洞比较容易找出来，但是有些流程性漏洞却需要分析人员对于协议有了非常充分的了解，进而根据协议流程推断出可能发生的安全漏洞。
要对网络协议进行测试，首先必须要读懂RFC文档，大部分的RFC文档都是英文撰写的，虽说现在有一部分中文翻译的RFC文档，但是读懂文档之后还需对网络协议有着充分的了解，并且在脑海中有了该协议的大概模型和流程，然后才能提取协议的漏洞和待测点。这就要求测试人员不仅需要良好的语言功底，不错网络基础，还要需要优秀的抽象、建模能力，这对于测试人员的要求是相当高的。虽说大部分的测试都是由撰写测试脚本自动化运行完成，但是这前期的准备工作不可谓不充分，需要的工作量也是比较大的。
之后我来到了C公司进行软件测试方面的研究工作，C公司是一家著名的国际互联网硬件公司，其软件的整个生命周期严格遵守“瀑布模式”：从需求阶段，到开发阶段，再到测试阶段，一环一环，紧密相扣。当时我所在的部门是针对C公司的某款服务器进行测试，复杂的逻辑和相对稳定的架构就是测试的全部，测试人员首先要和开发人员就需求文档就行review，就功能点达成一致；等开发完成后，测试人员根据需求描述，首先生成测试例，然后再由测试人员根据测试例撰写脚本进行测试或者手动测试。这整个流程的迭代周期是相当长的，但是好处也是显而易见的：开发、测试各司其职，分工明确，而且有比较充足的时间对于功能进行反复测试，产品的测试覆盖率、稳定性都维持在一个相当高的水准上，而bug几乎是可以忽略的存在。
之所以采用这样的测试流程，我后来分析了下原因，我个人总结如下：首先C公司的产品追求的是质量，因此公司的一切活动都以此为导向，而在追求绝对的质量的基础上可能会有劳动力的浪费、人员的浪费、工作的重复，但是只要达到了质量，一切都是在可以承受的范围之内。同时，C公司的产品种类不多，版本也进行着严格的控制，这也就意味着产品的迭代周期会比较长，“瀑布模型”的产品迭代流程是一个比较经典也比较稳妥的选择。最后，对于部门的待测产品的架构进行简单的分析，因为待测产品是属于服务器产品，逻辑相对稳定，稳定的产品就需要一个稳定的测试流程对其质量进行保障，而“瀑布模型”在流程上是一个四平八稳、不会出太多漏洞的流程。
……………………
查看全文请点击下载：http://www.51testing.com/html/11/n-832511.html
环境都准备好了，测试对象也抽象化，在这里简单的说明一下：此处的测试对象抽象化，指的是通过某种技术对其进行抽象，并且能够通过对于该技术的分析得到其所有待测点。例如我们用流程图刻画出了某个对象，那么我们自然可以解析这个流程图得到这个对象所有的运行规则，这些运行规则就是我们需要得到的测试例；而对于流程图的解析，其仅仅是一个算法问题。所有的都准备好了，我们来谈一谈测试流程，其实我们发现：好像一切都变的简单了，我们只要按照测试例，在特定的测试环境下使用特定的操作就行了，这个时候需要的只是一点对于业务的了解和编程知识就可以了，甚至都不需要测试人员写程序。把一个测试人员所有的注意力集中到要测试的业务本身，这才是测试的终极目标。
好了，我们是不是说所有的工作都做完了？万事大吉，我的测试方案已经完美了？为了对这个问题做一个回答，我们可以同样用上面举过的例子：sunColor = nullweather=rainy，今天我把环境观察好了：下雨，而且我也看了天空：没太阳，看上去测试完成了；那么，明天怎么办？明天是不是我还是要观察下天空有没有下雨，再观察下天空有没有太阳？后天呢？……为了避免每天都问这样一个问题，我们其实需要的只是记录每天的天气就可以了，甚至我们可以通过传感器监测是否下雨自动记录天气，剩下的，都交给计算机吧。
上面的例子其实说明了测试当中的一个极其重要的部分：测试的可维护性。我们不愿意浪费时间在重复做着同样的事情，我们可以借助计算机来完成。计算机的一个重要的作用就是一些重复的、有规律的事情可以通过它来完成，因此我们可以借助计算机来帮我们完成一些重复性工作，但是需要给其一些特别的指令：比如定期扫描环境有没有变化、当环境发生变化时改变其运行规律、定期给我们一个提醒等。我们可以让计算机帮我们管理数据、管理脚本、管理环境、结果分析等；当需要调整我们的测试计划时，我们只需要给其几个简单的指令。在现在不少公司，产品结构相对稳定，更多的时候是功能是增加、修改、删除，对测试的可维护性的需求也就愈发强烈。
说了这么多，其实就是一句话：能够使得测试人员不用关注除了测试内容之外的其他繁冗复杂的事物的测试方案才是一个好的测试方案。
查看全文请点击下载：http://www.51testing.com/html/11/n-832511.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
