测试之开篇

  想来从开发转行到测试，已经2年半了。现在才开始写第一篇测试文章，确实为时有点晚，但是想起那句老话，亡羊补牢为时未晚。

  从开发刚转过来的时候，拿起了北邮都研究生时候的《软件测试技术概论-清华大学出版社》，下功夫学了2周左右。明白了什么是黑盒测试，白盒测试，测试覆盖率，测试分析技术等等。由于在日常工作中用到的也不多，现在过了2年多，剩下的也不多了。我主要记录一下我测试一个DNS防火墙的过程吧。

  1，了解需求。我在做开发的时候，对需求十分重视。但是到了测试这里，反而不太重视了。这个自我感觉退步了很多。我在做开发的时候，能提出很多很多需求方面的bug，或者说需求方面的问题。到了做测试这里，基本上提不出来了。看来还是懒惰作怪。由于程序不归我写了，看需求也马马虎虎了。只要能按照需求写明白测试用例就行了，对自己要求也低了。

  2，写测试用例。这个是每一个测试人员的基本功。

我先说一下文档格式吧。要按照单位给的文档格式来写，不要自己自造格式。仿照CMMI3 或者 CMMI4等等的。

其次是测试用例：在理解需求的基础上，使用边界值法，有效等价类，流程图法（我只会这3种）。

其余的方法我记录如下：

（1），边界值法：

   就是在取值的边界处，多取几个数值进行测试。

（2），有效等价类法：

  就是用一个数值代替这一类的数值进行测试。

（3），流程图法：

  就是读懂了需求的基础上，画出流程图，按照流程图中的if else 进行测试。

（4），场景法：
  用在性能测试上居多，就是设计一个场景，进行测试。

（5），因果图法：
从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），可以通过因果图转换为判定表。这个较复杂，我也不是很懂。
（6），正交设计法：
  这个挺管用的，就是把所有因素都列在一个表中，有选择的来测试几个，就代表所有的都测试了。减轻测试工作量的。
  本人现在就了解以上这6种。其余的以后慢慢了解并在工作中使用吧。

  3，测试执行

 这个本来没什么好说的，但是放到公司里就有的说了。比如测试执行前，测试环境谁来准备，测试软件找谁要。这时间耗费的就多了去了。测试执行的过程中，测试环境被破坏了，被格式化了。找谁负责的问题。总之，千辛万苦测试执行完毕吧。

 多说一句功能测试和性能测试吧。关于功能测试，以上的都适用。测试发现了问题，由开发去定位问题，由开发去判断这个问题是不是一个问题，如果是一个问题，由开发去修改。

 关于性能测试，如果发现了问题，一般由性能测试工程师去定位问题，由性能测试工程师去判断这个问题是不是代码造成的。这个过程很复杂，往往超过了开发这个软件本身的难度。一旦定位出来，再由相关人员去解决，或者由高层去决定是否解决。

  4，测试报告文档的编写

  要按照规定的格式写测试文档。记录测试bug的数量，严重程度，最好还分门别类的总结一下。提一下在本次测试中使用了什么新的测试方法没有，提高了测试效率没？这些都是有益的。还有本次测试完成后，有没有可以复用的东西，为下次测试所复用。一些测试脚本啦。

  5，最后就是上线测试了

  好歹上线了，抽测一下，就行了。然后就可以等着项目组一起吃饭了。