只会黑盒测试算测试人员吗？

 作者：imlele1102            2007年4月27日

 

 

   本文是写给测试新人及还未入测试行业的人。对已经有很多很丰富测试经验的人来说可以略过哈。

在测试行业飞速发展的今天，越来越多的人和企业重视软件测试。测试行业的发展掀起了大众学习测试的浪潮。

很多新人，在各种论坛学习时，经常会看到的是大家在热火朝天的讨论着各种测试理论及测试工具，什么黑盒测试，白盒测试，功能测试，性能测试，回归测试，自动化测试，什么winrunner，loadrunner，Testdirector，Quicktest pro……

可能也因为这个原因，导致有的人一听说别人是做测试，喜欢问的第一个问题就是，你们测试是做白盒测试还是黑盒测试？或者就是，你们测试用什么工具呢？

也许他们认为：如果测试人员只会黑盒测试，而不会使用几种测试工具，不会用写测试脚本，不会做白盒测试，就算不上一名专业的测试人员。

 

而我要说得是，作为测试人员，功能测试是一切测试的基础，它就像if语句是开发的基础一样，做不好功能测试，不管你会使用多少工具，不管你的测试脚本写的多么出神入化，你的测试工作都是不可能做好的。

 

而功能测试仅仅是黑盒测试。

 

   我大学毕业后在一家软件公司上班。从程序员开始做起。

对应届毕业生刚进公司，这家公司的特点是不会马上安排你做开发工作，而是先从测试开始做。这个时候，我接触了软件测试。

初期的测试很简单，给你一个产品，点点这个按钮，按按那个图标，从这边输入一些数据，在那边看看输出是否正确等等。

 也许没有真正做过测试，或者说没有做过一个项目完整的功能测试的人，就会片面的认为所谓的“功能测试”和“黑盒测试”就是这样，给你一个产品，点点这个按钮，按按那个图标，这边输入一些数据，在那边看看输出是否正确。

而功能测试仅仅是这样吗？上面描述的这种功能测试顶多能算个单元功能测试。

 

功能测试的重点不在单元测试，测试人员做单元的功能测试顶多是帮助开发人员调试调试产品而已。

 

功能测试的难点和重点都在项目的集成测试和系统测试。

 

举个简单的例子来说明一下：

 

一个客户需求：

公司部门人员考核情况混乱，无法在月底得到每个人每一项绩效考核分数及总分数。希望解决的问题：

建立公司人员管理。

建立考核项管理。

员工绩效考核分数查询。

 

解决方案：建立公司人员管理，建立考核项管理，建立分数档案。将人员管理、考核项管理和分数管理关联起来。

设计：

数据库：建3个主表，人员管理表，考核类型管理表，分数总结表，将3个表关联起来。

数据访问层：对表的访问及处理方式（增加，删除，修改等）

业务处理层：界面，数据的录入，各种业务处理。

  

项目的功能测试

 

一．首先设计项目测试计划。测试计划内容包括：

1.测试时间，测试阶段划分

2.测试进度及人员安排

3.测试环境，测试资源（测试方法，测试工具等）

二．然后设计项目测试用例。项目需求分析结束后，进行测试用例书写，用例内容包括以下部分：（功能测试重点）

检查是否实现了公司人员管理。

如果满足了人员管理，那么在这个人员管理中，是否所有的数据都能够正确处理。是否所有错误数据都能合理处理。

如果没有满足，那么还有哪些地方需要补充。

检查是否建立了考核项的管理。

    如果有考核项的管理，那么是否所有的管理数据是否能够正确处理，是否所有的错误数据都能合理处理。

如果没有满足，那么还有哪些地方需要补充。

检查这个产品是否建立了分数档案管理

如果分数档案进行了统一管理，那么所有的数据是否正确处理了，是否所有的错误数据也合理处理了。

如果没有满足，那么还有哪些地方需要补充。

检查各个模块之间的关联是否都正确。（难点）

例如：

当某一员工考核项里面分数变化后，员工分数统计表里面分数是否也重新计算了。

当客户要求业务全面能够满足后。

检查产品的各种业务流程中的输入输出是否都是正确，各种错误输入都能够正确处理。

进入各个界面检查。

检查各个页面的布局是否合理，界面是否友好

按钮等等是否能够正常使用

输入输出是否正确

操作是否简易等等

……

三． 按照测试计划，测试用例实施测试。

首先根据测试用例检查产品的设计、实现是否能满足客户的要求，可根据需求追踪矩阵制作的checklist进行检查。

然后实施测试用例：

除了执行上面已经写好的测试用例外，实施测试用例还有个难点是设计测试数据。（因为测试数据等跟产品的设计，产品结构等有很大的关系，所以测试数据只能在产品已经成形后，才能具体设计。）

 

四．发现问题后，记录BUG，并跟踪，并根据修改及影响情况，进行回归测试。

（这一点项，任何测试都是一样的。而且也是非常重要的，在这里我也不详细解释了，详细对BUG记录及BUG跟踪进行讲解的文档也是非常多了，包括缺陷管理工具。）

 

这就是一个项目功能测试的基本流程。

上面所描述的也只是项目功能测试的冰山一角。真正实施起来时，还有很多的细节需要处理，比如：如何才能写一个合理的测试计划；如何合理安排测试进度；测试用例用什么形式写；发现了BUG怎么进行汇报和跟踪；什么情况下需要做大量的回归测试等等。

 

举这个例子就是想纠正一些人的错误观点。

 

功能测试这样的黑盒测试一点都不简单。

它要求对需求和业务有非常深刻的理解。同时最好要有软件开发知识或编写代码的经验，能理解产品的设计，实现的过程。最后很重要的是，能够根据需求和设计实现，写出好的用例，构思出合适的测试数据来找出产品中的错误。这些是测试的基础，方法和工具是测试的辅助手段。

 

测试做的好坏也并不是你会写代码，你会做白盒测试，你会做使用好多好多种工具，你就能好测试了。测试的基础一定是功能测试，如果你连产品的功能，业务流程等都不能够完整的理解，那么你的测试是不可能做好的。

 

当然，也并不是只要会做功能测试就一切ok了。

如果永远只会做功能测试，只会做黑盒测试，不会白盒测试，不会写测试脚本，不会使用工具，那么你的测试道路只会越走越窄。写测试脚本，使用工具等都是提高测试水平很好的方法，但是前提是要有好的基础。

 

最后建议一下测试新人，刚入行时，不要盲目的学习各种各样的工具及写漂亮的测试脚本。学这些肯定是有用的，但是要分清主次。测试初期，首先要练习自己的基本功：比如如何写“测试计划”，如何去理解一个产品的设计原理，业务流程，如何写“测试用例”，怎么设计测试数据。再学习些开发的知识，能理解产品的一些重要设计和实现原理等。

这些都学的比较扎实后，再去考虑学习工具和各种各样的测试方式来提升自己。

相信通过这样的学习模式，你的测试道路会越走越宽，越走越好～

 

PS：以上为个人观点，供大家参考。由于测试经验有限加上时间仓促，文章难免会存在一些不足和错误，欢迎大家指正，也希望能跟大家多多交流软件测试和软件质量管理。

我的msn： ychen_lele@hotmail.com

邮箱： imlele@sina.com