测试现状与黑盒测试.doc

测试现状与黑盒测试大家知道，通常软件项目而言，基本上采用“瀑布型”开发方式，这种开发方式下，各个项目主要活动比较清晰，易于操作。整个项目生命周期为“需求设计编码测试发布实施维护”。 而合理的测试阶段应遵循下面划分方法（图1-1）： 阶段测试类型需求设计编码单元集成系统确认确认测试计划设计执行系统测试计划设计执行集成测试计划设计执行单元测试计划/设计执行（1-1） 首先，质保部在实施测试过程中，测试经理存在以下问题：在制定测试计划时候，测试经理对测试的阶段划分还不是十分明晰，经常性遇到的问题是把测试单纯理解成系统测试，或者把各类型测试设计（测试用例的编写和测试数据准备）全部放入生命周期的“测试阶段”，这样造成的问题是浪费了开发阶段可以并行的项目日程，另一方面造成测试时间及内容不足。解决办法，照上图所述，相应阶段可以同步进行相应的测试计划编制，而测试设计也可以结合在开发过程中实现并行，测试的实施即执行测试的活动即可连贯在开发之后。值得注意的是：单元测试往往由开发人员承担，因此这部分的阶段划分可能会安排在开发计划而不是测试计划中。 其次是测试人员存在以下几点问题：一，测试人员对BUG的描述能力不够，在描述测试结果方面，站在测试人员的角度去判断一个问题而给它下结论，这个是不对的。对于同一个问题，开发人员，现场配置人员，测试人员看问题的角度都是不一样的，所以在描述测试数据的时候不要轻易去下结论，而只要把自己所测试看到的种种现象一一记录清楚，以待评估阶段来定夺最后的结果。平时我们在BUG管理工具中提交给开发人员的bug，偶尔也会遇到开发人员来问测试人员这个是什么意思。这看起来没有什么，其实是个很严重的现象，说明测试人员的描述问题的时候出现了问题，开发人员没有看明白。正确的Bug描述中要包括以下三要素：位置、操作、现象。具体来说：1.位置：首先应说明操作进行的位置，通常是系统中的某一模块。另外是具体的出错位置，可能是某一字段、某一页面等。2.操作：详细的、有次序的、每一步的操作步骤，包括输入的数据。3.现象：具体的错误描述，包括界面显示、错误信息。二，测试人员对问题的分析解决能力不够，以综合金融信息化运营系统为例，测试人员只要发现BUG，无论大小，通常都会找开发人员解决，这无形之间就增加了研发人员的工作压力，我分析了一下，发生这种现象的原因有两点，一方面是测试人员对所发现的问题缺乏分析能力，不知道出现BUG要怎么处理才正确，所以只能找研发人员，二是测试人员对开发环境以及开发工具、语言等不熟悉，不知道出现BUG该怎么去调试。其实，作为一名合格的测试人员要对所测试的项目用到的开发环境、语言等要非常熟悉，可以说，好的测试人员同样也是合格的研发人员，因为只有熟悉了整个开发的过程才会更好的去测试，二是对所发现的问题要有分析掌控能力，例如，发现了一个Bug，要看看它到底是什么样的Bug，属于哪一级别的，该如何解决，出现的概率是多少等等，分析的能力在于思维框架，要养成结构化的思考习惯（善用脑图、鱼骨图等技术）； 三，测试专业技术不够，想做好的测试人员首先得了解测试，具有一定的测试基础。其次在工作中不断地进行学习，多掌握一些自动测试工具的用法，了解各种测试方法的流程，并且不断培养提高自己的逻辑思维和沟通能力。由于公司现在的测试人员少，技术良莠不齐，测试工期又短，所以，要先培养一批测试能力强的队伍，这样以后无论是做测试还是带新人都会有一定的基础，要鼓励这些人多多掌握一些自动测试工具的用法，多了解各种测试方法的流程，使他们成为公司产品品质保证的中坚力量。最后，我来说一说关于黑盒测试，目前公司测试产品的方式主要是黑盒测试，黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。进行黑盒测试时，首先，测试人员应将测试计划化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性）。其次，测试过程中，要对所发现的缺陷进行跟踪管理。测试人员在对项目进行系统测试和回归测试时，应本着科学负责的态度，一步一个脚印地进行测试，避免发生测试遗漏现象，坚决杜绝不测试就上线的现象。最后，我来说一说黑盒测试的弊端，黑盒测试的弊病是以用户的角度去测试，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设