软件测试的思考与总结 上一个项目总算是结束了,但是做的很不好,有很多的问题,在客户那边发现了很多的BUG.BUG多的原因有很多,也有设计和编码的问题.但是归根结底是测试没有做好.因为测试本身就是要找到程序中的bug,并修改它,当我们测试完之后,就说明程序在我们这边已经通过了,我们认为程序没有潜在的bug了.而我们在提交给客户之后,客户发现了很多的bug,这说明什么,说明我们的能力不行,我们编码编的不好?不是,是我们的测试没有做好.测试是软件质量的最后保证,测试做好了,我们的程序就能经的起考验,测试做的不好,那软件的质量无从谈起.我现在感觉,只要给予足够长的对应时间,和测试时间,开始是再烂的代码,通过严格的测试,我们都能把它变成精品.

现在结合上一个项目,来分析我们上个项目测试做的失败的原因.

1.对于测试的目的和重要性认识不足.

测试的目的是为了证明软件中存在bug,并把他找出来,以提高质量.它犹如数学中的反证法.我的目的是为了证明这软件有毛病有问题才做测试,但是经过严格的测试之后,发现他没有什么问题,这样就间接的证明了软件的质量.但是现状呢,在我们公司,没有专门的测试人员,一般都是自己测自己担当的那部分代码.而且项目做长了大家都有种厌倦的感觉,自己编好代码之后,根本就不想在改了.在测试的时候,也是报着证明软件没有问题的态度来去测试的.这样一来,在测试过程中极力的维护自己的代码和程序,这样下来,测试结果可想而知,根本达不到预定的测试效果.

要想保证软件质量,就需要进行好的软件测试,而严格的软件测试的最基础保证就是,要对软件测试的目的和重要性有个充分的认识.在下期的项目过程中,我们要向项目组的所有成员灌输软件测试的重要性,让他们对软件测试有个正确的认识.

2. 测试用例写的不好

现在来看,我们在做软件测试的时候,写的测试用例根本就比较白痴,也就是说我们写出的测试用例大都是不能发现问题的.在测试用例的制作过程中,我们有很多问题,而这些问题的类型是不一样的,现分别说明.

a. 要说写测试用例的话,首先还是要谈,写测试用例的目的,知道目的之后,我们才能写出有效的测试用例.在这一年多的软件开发过程中,我发现大多数人,包括我自己在内,都没有真正的明确写测试用例的真正用意.或者说由于现实的所迫,加上我们自己的能力有限.曲解了写测试用例的目的.写测试用例的目的就是为了测试能严格的被执行,不会出现本来想到的测试点被遗忘.且让不同层次的人对同一产品进行测试,能出现同样的效果.而且有了测试用例之后,让我们的回归测试更方便和精确.但是可惜很多人都没有意识到这点,或者说做到这一点.一个经验丰富的人,写出的测试用例的命中率是很高的.也就是说,他写出的测试用例并不一定很多,但是个个一针见血,直指要害.现在呢,公司和客户对每千行代码的测试用例数有严格的规定,大家为了达到这个目的而写了很多无效的测试用例,而一针见血的测试用例却还很少.而且大家通过无效的或者重复的测试用例的堆积,使自己的测试用例数达到了公司的要求之后.就不再费心思考虑有效的测试用例了.大家在写测试用例的时候想的是我如何才能使自己的测试用例够数,而不是如何设计测试用例来测出更多的BUG.这样就不自觉的背离了写测试用例的初衷.

在下期的项目中,不仅要求测试用例的数量,更要要求测试用例的质量,而真正的要保证测试用例的质量,除了进行检查之外,更重要的是测试人员本身了.养成对测试用例的正确的看法,和测试的根本目的.还要测试人员有很强的责任心,在以前的项目中,我个人感觉,自己的责任心就不够.

b. 测试用例写的不好,另一方面表现在,测试用例没有测到软件的所有的需求.也就是说在写测试用例的时候,没有能系统的考虑以前在设计阶段确定的需求.这里就要先讨论一下什么是bug,bug就是在软件中出现的不是我们以前在做需求的时候想要的结果.日方也经常叫做不具合.我们进行测试就是为了要找出bug,也就是找出不是我们预想得到的地方.而我们以什么为测试的凭判标准呢,当然是我们以前得到的软件需求,在写测试用例的时候,一定要保证测试用例体现了所有我们知道的软件需求.在我们现在的开发过程中,大多数需求是在基本设计书或者说是详细设计书里面记载的,但是要注意设计书里面并没有体现全部的需求.因为在开发过程中有需求的变更,正常的情况下他会体现在需求管理表中.还有一些是式样不明确的地方,我们需要通过QA List来给客户确认.以现在的情况来说,需求存在与式样书,需求管理表,和QA List中.我们只有在写测试用例的时候,把这些需求都写进去,这样测试用例才能有好的覆盖度.

c. 测试用例不好,还有一个方面是,测试用例设计的简单,或者说,我们设计的测试用例中,操作非常简单.这样仅仅测试了系统最基本的功能.而在程序的健壮性上没有测到.这种情况一般会在各个操作之间的关联比较大的情况下更加明显.在上个项目中,有一些bug就是这样出来的.我们的测试用例相对简单,我们的测试也比较简单.我们测过之后,没有问题.发给客户之后,客户给我们返回了一大堆bug.为什么呢,因为客户在测试的时候,他们测试用例相对复杂,他们一个测试用例涉及的操作比较多.一般来说,单独的每个功能测试,都没有问题.但是没个功能重复多次的操作,或者先进行A操作,再进行B操作,再进行C操作,然后再进行A操作,这时候可能就会有问题,而这就是涉及到软件的健壮性了.记得以前在程序员杂志上看到过一篇文章,说是一个小伙在大学的时候,发现了微软的几个bug,毕业后就被微软亚洲研究院给录用了.他是对软件进行几乎破坏性的操作,同样一个操作,操作一遍没有问题,5遍10遍也没有问题,但是在15到20遍的时候就出问题了.我估计我们做出的东西很多地方用不到10遍就会出问题了.

d.测试用例中自己不确定或者不放心的地方,一定要多做一些测试用例.正如成功学上说的我是我认为的我一样.当你感觉程序的某个地方有问题的时候,一般来说它确实有问题.这些地方一定不要放过,因为这就是虫子的小窝,你只要对其进行测试,肯定有收获的.

3.再说一下测试执行的方面.我个人感觉,如果测试用例制作的好坏,和担当人员的经验和能力有关系的话.执行测试时效果的好坏,主要决定于担当者的责任心和态度来说了.因为测试的时候,你只需要根据测试式样书上写的流程来测就好了.这个时候不需要再进行测试用力的设计了.在以前的项目中,可能有很多人,对测试不是很在乎,觉的测试就是走一个过场,我写出的测试用例和执行测试都是为了忽悠客户,而不真的是在提高产品质量.我以前就有这样的想法,以前觉得一个程序做的好坏,最主要的是在于代码的编写,后来又觉得设计非常的重要,而直到最近我才真正的意识到测试的重要性.其实对于在有限的时间中要做出一个好的产品,软件开发周期的各个阶段都是非常重要的.哪一环出了问题,都会对进度和软件的质量有挺大的影响.现在我甚至有这样的感觉,就是测试甚至比编码更重要,因为编码做的不好,还有测试来检查,而测试做的不好,那么就真的很难弥补他造成的恶劣影响了

其实,现在我们在测试过程中,做的不好,主要是态度不好.做任何事情都是态度决定一切.所以刘老大将软件是一种态度也是很有道理的.总结了这么多,希望在以后的项目中尽量的避免以上的各个问题.确实把测试做好,提高软件的质量,也提高我们自己的价值.

第二篇：软件测试的总结

软件测试分类

软件测试是 一项复杂的系统工程，从不同的角度考虑可以有不同的划分方法，对测试进行分类是为了更好的明确测试的过程，了解测试究竟要完成哪些工作，尽量做到全面测试。

1,按是否需要执行被测软件的角度

按是否需要执行被测软件的角度，可分为静态测试和动态测试，前者不利用计算机运行待测程序而应用其他手段实现测试目的，如代码审核。（我认为主要是让测试人员对编译器发现不了的潜在错误进行分析，如无效的死循环，多余的变量等），而动态测试则通过运行被测试软件来达到目的。

2、按阶段划分：

1 单元测试

单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。因为单元测试需要知道内部程序设计和编码的细节知识，一般应由程序员而非测试员来完成，往往需要开发测试驱动模块和桩模块来辅助完成单元测试。因此应用系统有一个设计很好的体系结构就显得尤为重要。 一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。

2 集成测试

集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。

3 系统测试

系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。

4 验收测试

验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

5 回归测试

回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里，修改的正确性有两重含义：一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。

6 Alpha 测试：在系统开发接近完成时对应用系统的测试；测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

7 Beta 测试：当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

3、按测试方法划分：

1 白盒测试

白盒测试也称结构测试或逻辑驱动测试，是指基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径、条件的测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。

“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。 白盒测试可以借助一些工具来完成如Junit Framework，Jtest等。

2 黑盒测试

黑盒测试是指不基于内部设计和代码的任何知识，而基于需求和功能性的测试，黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。

“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。 黑盒测试也可以借助一些工具，如WinRunner，QuickTestPro，Rational Robot等。

3 ALAC(Act-like-a-customer)测试

ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。ALAC测试是基于复杂的软件产品有许多错误的原则。最大的受益者是用户，缺陷查找和改正将针对哪些客户最容易遇到的错误。