展望2011

2008年度工作经验总结之测试经验

上一篇 / 下一篇 2009-03-30 16:25:46 / 不允许评论 / 个人分类：学习日志

2008年度工作经验总结之测试经验51Testing软件测试网[!Izu(S4]

总体来说，2008年是工作收获颇丰的一年，一方面是全程参与了一个项目的测试，从需求开始，到模块测试，到集成测试，到系统测试，最后到出差上线，我都参与了，虽然结果让人有点失望，但在此过程中学到了很多东西；另一方面是白盒测试经验更丰富，定位BUG的能力也增强了不少，解决问题的能力也有所提升。比较可惜的是，编程能力的提升还是比较慢，2008年中修改成功过一个桩模块，《C语言程序设计》这本书每章后面的编程练习题基本上都写了一遍并调试，这方面还有待2009年来加强实践。下面是我在2008年中每天总结出来的工作经验的一次年度汇总，可能文章的流畅性不够好，因为都是每天一点一滴的记录的，不过我会尽量的完善它。

一．测试经验

1.计划阶段

a.测试时间的计划

当项目计划中没有安排测试时间或安排的测试时间很短，从这个时候开始测试就已经处于被动的状态了，但毕竟从大局考虑，开发时间已经很紧迫，测试人员只能是扮演辅助的角色了，尽量用最有限的时间完成最有效的测试，测试时间和内容都是被动的，但还是有点失望，因为测试的作用本来可以发挥到最大，可惜时间不够。

如果给你测试的时间实在是太短，没关系，还是按照自己的工作程度和进度进行，如果发现了问题，开发人员必须花这个时间去修改，所以给你时间越短，同样给他自己修改代码的时间也越短，当然他修改BUG可能会非常快，我们也别觉得委屈，各有各的难处。51Testing软件测试网"N%F%SD'V y

b.工作量的估算

同一个功能点，测试的工作量也许比不上开发的工作量，但至少不会比开发工作量的一半还少，如果某个功能的开发完成需要2人日，则测试至少需要1人日，这只是个保守估算。因为测试人员在测试的过程中，需要花时间来了解该功能（沟通时间占去了大部分），然后分析如何进行测试，还要编写测试用例、测试数据等文档，最后还要非常细心的检查每个测试数据执行完成后的结果是否正确，而且如果遇到问题就更花时间了（因为需要确认并定位问题并且开发人员修改后还得验证是否成功和是否影响到其他功能）。

51Testing软件测试网&BChduG

2.测试设计阶段

a.测试模块的划分

其实在划分测试模块的时候，每个人可能划分的角度会不同，各有优点和缺点，但毕竟拿来测试的是测试数据，如果测试数据基本上一致，任何划分角度都是可以的。划分测试模块的目的是为了防止某些特性被遗忘，同时也为了测试需求的覆盖率，所以只要保证这2点，任何的划分角度都可行。

b.不要跟着开发人员的思路走

在设计计算类的测试用例的时候，尽量不要按照开发人员的设计逻辑进行思考和计算，最好能想出另一套计算方法，来检验开发人员设计的算法有没有错误，当然之前你要理解开发人员的算法，然后想出自己的算法，这也是非常考验你的逻辑思维能力。尽量想一些不太可能发生但发生之后会出现BUG的情况，的确开发人员可能拒绝修改，但我们至少要提醒他的确存在风险，万一真的在客户那出了这个问题，我们也有话可说，不能因为发生的可能性太小而不好意思告诉开发人员，如果真的出了问题，我们就要负很大一部分责任了。

有的时候，开发人员说某个功能不用测了，而且可能还强调了2遍以上，可是测试人员根据经验和对系统的熟悉程度，并没有十足的把握认为这个功能没有问题，还是要坚持自己的立场，只要有时间，还是需要进行测试的。因为有一次我就碰到这种情况，结果在不用测的模块中发现了问题。

3.测试执行阶段

a.开发环境和测试环境要分离

开发环境和测试环境共用一个的话，的确会遇到很多麻烦，特别是边开发边测试这样的模式，测试过程更加的不顺利，会互相干扰，而且也会影响测试的结果观察。当开发环境和测试环境在一起时，为了方便找到开发人员修改的内容，最好是每天一个版本的获取，然后比较前一天的版本有什么区别，就能知道前一天发现BUG的产生原因和修改范围。

开发测试共用一个环境，环境会变得很乱，遇到问题时就会感到头疼。因为你得花时间去解决，而且你了解的情况还不如开发人员了解的多，毕竟环境是他给弄乱了的。

b.冒烟测试51Testing软件测试网$||0zX(W9e$@

冒烟测试的目的是，尽早的发现可能会严重影响测试进度的BUG，特别像业务流程性非常强的系统，中间某个流程出了问题会影响到后面流程的测试，所以这个问题要尽早的在冒烟测试中发现，尽早让开发人员去修改，一般来说，覆盖到优先级较高的有效测试用例就可以了。

c.单元测试、集成测试、系统测试的测试需求和测试用例不一样

如果在开发阶段，只是针对后台设计的测试需求和测试用例，也就是模块测试的测试需求和测试用例，在系统测试的时候，是不实用的。需要重新设计和编写。因为系统测试考虑更多的是业务流程的正确性和用户体验到的是否正确。系统测试时，有些隐藏深的BUG不容易发现，需要在前期的模块测试中去发现，当然，模块测试时，有些接口上的错误也没办法发现，也是等待系统测试的时候去发现。模块测试时，一方面是熟悉系统设计，另一方面是将系统深处的系统测试不容易发现的问题找出来，而且这时候发现的BUG修复的成本比较低。系统测试时，更多的是从用户的角度去测试，将业务流程中的问题和界面上的问题找出来，但是这个时候如果发现严重的业务流程问题，BUG修复的成本会更大些。模块测试时，测试是没有问题的，不等于系统测试时也没有问题，因为代码是在不断的修改之中，而且最后的系统测试也不能只测一次。最后的系统测试一定要做好，即使模块测试做的很多很完善。

d.CS系统架构的测试经验

客户端－服务器系统架构，在执行测试用例时，一般按照下面这个步骤进行：1。界面能不能正常输入数据；2。后台能不能正常收到数据；3。补充或编写测试需求；4。编写测试用例；5。设计简单的测试数据检查功能是否已经基本实现；6。运行所设计的测试用例的测试数据开始正式执行测试。如果6步中第1、2或5步就已经有问题，那么后面的步骤可以暂时不进行，直接进入下一个功能点的执行测试。为什么？因为当功能的基本实现都有问题，那些更精细更逆向的测试用例基本上都会执行失败，这种情况下去执行它们就浪费时间了，而且现在测试的也不准确，因为开发人员之后会去修改这个功能，那个时候程序质量更高了，那些更精细更逆向的测试用例测试起来也更有效果，而且还有机会补充新的测试用例。随着测试的越深入，对系统的了解越深，测试用例和数据的设计也越来越精炼。因为测试的针对性更强，需求也更明确，逻辑思维也更清晰。冗余的测试用例和测试数据可以删除掉。

在执行某一个功能点的多组测试数据时，如果功能点测试时所观察的点是差不多的，而且测试结果不容易混淆，那么可以先执行多个测试用例或测试数据之后，如果界面上的输出数据没有问题的话，最后一起检查内部的中间数据是否正确，例如数据库的表、日志等，这样执行测试的效率会有所提高。

关于无效测试用例（错误情况）的执行，如果客户端和后台都对一些错误输入进行判断，那是双重保险，那就最好了，但测试的时候只要保证其中1个能对某个错误输入判断正确并在终端上提示清晰，基本上就算通过，但也可能有特殊的情况，一定要保证后台有某些严重错误判断的能力，看具体的功能性质而定。而且，某些错误在某种情况下一定有机会穿越客户端的阻拦，而把错误的数据交给服务器去判断，所以，测试的时候，尽量想办法将错误数据送到后台去判断，检验后台的排错能力和健壮性。如果测试目的就是为了检验后台的错误判断，那么也可以开发一个测试工具来代替客户端，发送一些错误的数据给后台。

同样，如果客户端的问题导致某个功能的测试用例无法进行，那么也可以用这个测试工具来测试后台模块，因为问题的发现是越早越好，所以先把后台模块的BUG找出来，然后让开发人员修改成功，再使用真正的客户端进行测试，那么测试发现问题基本上就是接口错误或者是客户端错误了，这样也方便定位问题。

从合法性判断的代码的实现角度来看，测试的时候，一方面是测试错误的情况是否会返回错误，另一方面也要测试正确的情况是否会因为判断错误而返回错误。而且后者如果出现，将会是更严重的问题。某一次我偶然在测试合法性要求时发现后者情况的BUG，所以数据的合法性测试的优先级不能太低，因为这里也可能会出现严重级别高的BUG。51Testing软件测试网"jYI a'D e)\

在测试服务器程序的功能时，注意实时监控后台错误日志，一般性的调试日志可以不看，但错误日志一定要实时监控，有几点好处：一。如果出现问题，可以首先从这里初步定位原因；二。从界面现象上没有发现问题，但日志中捕捉到了一些错误信息，使得测试人员能够及时的发现程序潜在的错误。使用tail -f命令实时查看错误日志文件。

e.接口协议的错误发现

系统联调时，最容易发现接口协议上的错误，比如传送的数据格式要求不一样，服务器接受某个字段为0，而客户端传了个null过来，可能会导致服务器操作失败，实际上null和0是一样的意义。再比如，子系统A保存的数据中某个字段是空的，需要子系统B自己计算出来，可是子系统B以为这个字段是已经算好的，直接取它的值就可以了，这样就出现BUG了。所以在代码设计阶段，一般都会有个接口协议的文档出来，测试接口的时候也要多参考这个设计文档。所以可见，在分别测试各子系统之后，一定要进行整个系统的系统测试，才有把握说没有问题。51Testing软件测试网QW"qQuXao

51Testing软件测试网Pg4aH2KL/X@

f.维护版本的测试经验

维护版本的测试，最怕遇到的一种情况是，开发人员修改了某个程序，但是忘了在修改记录中记录，结果测试人员没有更新这个最新的程序，肯定的是，在测试过程中遇到问题，花了很多时间验证和归纳问题，然后提交给开发人员，最后，开发人员才记起来说有个程序不是最新的，这时我们就很无语了。这样实在是浪费了测试时间，为了避免这种问题，最好的办法是自己去确认有那些程序是被更新了，在VSS上看版本记录，在测试环境看所有文件最后修改的时间，然后和修改记录中的记录进行比较，确认后再开始正式的测试工作。

如何确定某个功能点比较多但修改很小的功能模块的测试需求呢？我先从黑盒角度出发，罗列出这个模块所有功能特性，想到的越全越好，然后根据从灰盒出发，观察代码修改的范围，如果能确定不会影响的功能特性，就把它去掉，如果不能确定，就还是要测。另外，看代码修改范围的时候，还可能发现一些你不知道的功能特性，而且可能会受影响，同样把他们写进你的测试需求。

除了修改模块，当然也要考虑到修改的功能点和其他功能点之间的相互影响，还有时序的问题.首先，有必要和该修改模块的相关联的前一个模块和后一个模块同时验证结果的正确性，以防万一。其次，看起来有影响却没有修改的功能点，这个所牵涉的范围就更广了，也最难把握分寸，到底要测试哪些，需要测试到什么程度？就我看来，只能按照功能的重点级别来考量了，哪些功能对用户是最重要的，如果出问题后严重程度是很大的，这些虽然没有修改而且关联性不大的功能都要过一遍。结果测试的效率低下，那些所谓可能受影响的范围中没有发现任何问题，但工作时间占用了大半，得不偿失。最重要的是，在测试过程中，测试人员自己收获很少，因为发现不了问题，只是枯燥的重复测试，没有发现BUG和定位BUG的乐趣，也不会学到新的业务或设计。所以，这种测试最好是由自动化测试工具来完成，把繁琐而且低效率的工作交给工具来做是最合适的了。

g.错误推断

根据某个现象，推测另一个功能会有问题，然后去测试另一个功能，这应该也算为错误推断，当然这个现象表明看来不是BUG。比如说今天这次，偶然想起某个旧的功能特性（以前没有测试过这个特性，还是从别人那里得知的），突然发现某个现象和这个功能特性是冲突的，于是想到这个现象的不正常会影响到哪些功能，这个功能特性的目的是什么，于是推测某个功能会有问题，果然，经过测试，已经确认的确存在BUG。这种突然想到而不是测试方法所设计的用例发现的，让人感到不安，也许还有很多像这样不容易发现的问题。办法有一个，就是尽量去整理全面的功能特性，防止出现漏测。

二．测试需求

a.测试需求的输入

测试需求，在软件需求阶段产生的东西，就是说软件的目标分解一下，是很大的方向性的东西，也就是需要测试的功能，测试需求的输入：原始用户需求、软件需求，此功能有哪些测试特性再逐步分解，最终得到用例。所以，和测试需求相比较，测试特性就有些细了。测试特性的输入文档有：测试需求、软件需求规格、概要设计、原始需求。最初期，用户提出用户需求，开发人员补充软件需求，然后，双方逐步明确，产生了需求规格说明书。

b.根据输入文档来编写测试需求51Testing软件测试网ak2W~!Xq

在根据需求和设计文档来编写测试需求时，遇到不明白的地方，在文档中添加批注，能确定的测试需求先写下来，需求不明确的地方先不写，等到整个相关的文档都阅读完后，再去看以前插入的批注，这个时候看自己是否知道了答案，如果还是有疑问，把这些批注整理成一些问题，发给相关的开发人员，然后等待他来回答，在此过程中，需求理解的越来越清晰，然后再完善测试需求文档。

在需求文档不完整或更本没有的情况下，不能只是抱怨或者等待文档的完善，而是自己去寻找去挖掘一些需求信息，而且是用合理的方法去挖掘，多理解开发人员的想法，比如说可以从某些设计文档可以找出大部分的需求和功能点，不过这些都是开发人员自己理解的需求，不是最全面的，但至少会让我们有办法开展测试的工作，而不只是等待需求文档的出现。

e.从其他途径上获得测试需求

如果需求文档和设计文档写的并不规范或完善，有的测试需求还是需要自己去挖掘的，例如一些你不知道的需求，特别是没有这些文档的情况，基本上都是客户和开发人员口头上进行交流，如果你不主动去挖掘，真的是测试不到全部的需要被测试的对象，这样的测试效果是非常差的。那么如何进行挖掘呢？一个是，多和开发人员进行沟通，和他们进行沟通至少有2个好处，一个是你自己学习到了业务和设计，对系统更熟悉；另一个是开发人员会觉得你挺靠谱的，因为通过沟通，他知道你究竟掌握了多少业务和设计方面的知识，对你的测试工作也就更放心，更愿意和你进行工作上的合作。另一个就是多看代码了。从代码中挖掘测试需求，从中还能发现设计和业务需求点，当然这些测试需求不是最原始的和最全面的，但是总比什么文档都没有的好吧。这些测试需求的正确与否，还需要进行进一步的确认，根据这些测试需求写出的测试用例也只是发现设计上的BUG，如果测试需求本身就有错误，就没办法发现了。

f.测试需求的类型51Testing软件测试网BY o&N9{ {

测试需求，再细分一下，目前接触到的，可以被选为测试需求的有：数值的限制范围（例如最大最小）、相同功能的不同类型（可以是相同的也可以是不同的有效等价类）、某些特例的限定规则（某种条件下有不同的实现）、某个属性的特定规律（比如流水号码的递增性）、各种状态的特定要求（例如非销售状态时不能销售）、各种算法（例如金额的计算）、设计上的要求（例如可配置性、日志记录）。总之，可以拿来测试的所有特性都可以成为测试需求。

g.单元测试的测试需求51Testing软件测试网s6@\G0j

如果是编写某个模块的测试需求，该模块不是最顶层的模块，也不是最低层的模块，那么可以从三个方面考虑：第一，本模块需要完成的功能，第二，输入数据中各字段和系统中有什么逻辑上的关系和规则，第三，输入数据的最基本的格式检验。举个简单的例子，后台的注册模块，第一，该模块要完成的功能就是生成一个唯一的用户ID，并把所有资料存入到数据库中，并返回用户ID给上层模块；第二，输入数据的身份证号如果为空，则注册为普通用户，否则注册成拥有某个权限的用户；第三，输入数据的身份证号的个数不对或有非数字字符。一般来说，第一和第二都会在需求文档和设计文档中罗列出来，如果没有，则需要自己去发现，第三是常规检查，也就是说即使没有需求和设计文档，自己也能考虑到（而且初级测试人员更容易关注这方面的测试），但这种测试需求的优先级最低，因为既然不是最上层模块，和它相关联的上层模块会发送这种低级错误的数据的可能性比较小，当然也不是说不需要测试，毕竟一旦这里出现问题，将造成严重的影响，比如说当机。

h.怎么从代码中提取单元测试的测试需求？

在没有需求文档和设计文档的情况下，而且该模块也没有界面，怎么从代码中提炼出测试需求？第一步，找出该模块的输入数据和输出数据有哪些？包括文件、网络、参数、数据库表等，画出相应的数据流程图；第二步，从最开始的代码处开始看，比如如果是非后台进程就从main开始看，如果是动态连接库，则从最上层的函数开始看，如果是后台进程则从网络接受到输入数据的地方开始看；第三步，看的过程中，一般先看到输入数据的合法性检验处理代码，这可以归纳为一个测试需求；第四步，再接下来一般是具体的业务处理代码，多注意观察if和switch语句，这里有可能表示多个等价类，可归纳为一个测试需求，代码如果有注释，可以根据注释推测出部分测试需求，如果没有注释，则思考为什么要这样设计，把这些疑问记录下来，稍后再问开发人员；第五步，寻找return错误码语句，一般是发生错误的情况下的返回数据，理解出错的原因，删除掉一些发生可能性比较小的部分，其他的可归纳为一个或多个测试需求。

因为代码是根据用户需求和设计需求所编写出来的，所以从代码推导出测试需求完全是可以的。但这种方法有一个很大的弊端，它只能得出开发人员所理解的需求而不一定是最原始的需求，如果开发人员对需求本身理解有问题，而测试人员又不知道原始需求，那么这种问题就没办法发现了。其实在挖掘测试需求的同时，也是在进行代码静态测试，因为有可能在此过程中发现BUG。当然最后还是要经过开发人员的确认后，再开始设计测试用例。

三．测试数据

a.测试数据记录的好处

测试数据记录的好处：1。需要手工批量执行测试数据时，参照着记录文档可以提高手工执行的效率，一次性想好，一次性执行。2。如果制造数据比较复杂，花费时间比较长，而且有下次再利用的可能。3。如果自动化的数据不能自动产生，第一次手工测试的时候，可以把数据保留下来，以方便自动化测试时的数据输入。

b.测试数据编写的时机51Testing软件测试网JX[d"h zCS2a

测试数据一般在执行测试用例的时候编写。特别是动态的测试数据，有时候会根据当前的系统状态而定，也就是说在执行测试用例之前不好去写死对应的测试数据，例如日期的选择，如果执行测试用例当天就是某个测试数据的值，那么只有当天执行测试的时候才去填写测试数据。

c.无效测试用例的测试数据设计

有效测试用例设计测试数据时，可以把所有正常的对象只用一个测试数据就可以保证，而无效等价类则相反，所有异常的对象各自用一个测试数据来保证，为什么这么做，因为在代码进行输入数据检验的时候，很有可能是分别对每个异常对象进行检验是否正确，所以代码实现的时候先判断A对象的错误，然后判断B对象的错误，所以如果A对象和B对象都错误的话，就无法测试到B对象的错误被程序检验的结果是什么。51Testing软件测试网E Yn6`,~/in

当选择测试数据的时候，有效等价类的数据要多考虑各种组合情况，但是无效等价类的数据可以根据程序的错误代码的设计来减少一些多余的组合情况。举个非常简单的例子，一个登录功能，需要用户名和密码，用户名和密码分别有正确和错误2种大的情况，那么有效等价类的组合有：用户名正确密码正确，无效等价类的组合有：用户名正确密码错误，用户名错误密码正确，用户名错误密码错误，那么是不是所有这4种情况都要测试呢？我个人认为用户名错误密码错误这种组合情况就是多余的，一般来说，程序在进行错误判断的时候，是有顺序的进行着，程序可能先判断用户名，在数据库中是否存在，如果不存在，立刻return一个错误码，而不再检查密码是否正确，这样一来，用户名错误密码正确和用户名错误密码错误这2个测试用例，相对于该程序来说就是相同的，也就是说是同一等价类。所以，我得出一个结论，无效等价类的测试组合情况不需要太多，根据程序的错误处理设计而定。

d.记录测试数据的坏处51Testing软件测试网V:U)dx|n@yi

记录不必要记录的测试数据的坏处：会增加工作量，特别是记录数据时的切换成本。而记录后的数据对之后的测试效率提升没有任何帮助，对测试策略不会有影响，仅仅增加了人力成本。对管理上，对数据分析没有任何帮助，而该数据不会成为影响之后测试策略、测试改进的输入（测试策略、测试改进，主要是从BUG发现的模块、BUG的数据、BUG的执行手段上来进行改进，而数据对策略和改进没有任何影响）。51Testing软件测试网1k4g;z+ZJ

51Testing软件测试网+Bzwo|'t Z

收藏举报

TAG:

查看全部评论