软件测试与现在

在实习的时候接到了一个hr电话，说是招软件测试实习生。

因为离 现在的公司近 ， 所以去试试看了。

自己平时做的是vb开发，测试都是很简易的测试，有结果进行参照。

面试官很好，问了一些项目上与测试的相关性。

自己回答得不太专业尤其是问我你们是迭代还是瀑布模型式，那时想的就是课上老师讲过，我也记得有个图，但是我现在开发的库到底是哪种测试方式呢。‘

于是回来细细百度了下这几种测试相关的模型，搞搞清楚现在自己在做的需要用怎么样的方式更好呢。。。

概念来自百度

瀑布模型核心思想

瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。   简单的说就是先定义需求，然后构建框架，然后写代码，然后测试，最后发布一个产品。

这样，几个月过去了，直到最后一天发布时，大家才能见到一个产品。

很明显这不适合我现在所开发的数据库，因为需求和库表实时在改变。

 

迭代模型的方法： 

迭代的方式就有所不同，假如这个产品要求6个月交货，我在第一个月就会拿出一个产品来，当然，这个产品会很不完善，会有很多功能还没有添加进去，bug很多，还不稳定，但客户看了以后，会提出更详细的修改意见，这样，你就知道自己距离客户的需求有多远，我回家以后，再花一个月，在上个月所作的需求分析、框架设计、代码、测试等等的基础上，进一步改进，又拿出一个更完善的产品来，给客户看，让他们提意见。　　

就这样，我的产品在功能上、质量上都能够逐渐逼近客户的要求，不会出现我花了大量心血后，直到最后发布之时才发现根本不是客户要的东西的情况。

 这种比较符合自己现在正在做的项目，一边在开发一边测试结果。

两种方法的比较：

瀑布模型：假如我们对用户的需求判断的不是很准确时——这是很常见的问题，一点也不少见——你工作了几个月甚至是几年，当你把产品拿给客户看时，客户往往会大吃一惊，这就是我要的东西吗？

迭代模型：这样的方法很不错，但他也有自己的缺陷，那就是周期长、成本很高。在应付大项目、高风险项目——就比如是航天飞机的控制系统时，迭代的成本比项目失败的风险成本低得多，用这种方式明显有优势。

 

面试是有收获的，面试官的问题也很用的。

记录第一次技术面试。其实很快。