测试设计失误和测试质量把握

 
测试设计失误和测试质量把握

关于测试，我认为测试漏洞主要出现在两方面，测试设计失误和测试质量把握。
测试设计失误是指测试中没有想到，测试点被遗漏或测试组合被遗漏导致的程序错误；测试心理失误是指测试中有些问题在正常情况中可以被测试出来，但在测试实际过程中，可能受到环境，工期，心情影响导致测试点被遗漏或测试组合被遗漏导致的程序错误（比如你测试产品时间短，任务重，你可能会因此而遗漏某些点。但一旦遗漏点被发现，你马上就会认为此点绝对应该被发现，但还是出现了遗漏。）
首先我从测试设计失误谈起
测试内容从测试类型分为功能测试、权限测试、环境测试、年结测试、加密测试、并发互斥测试、升级测试、打印测试、安装卸载、帮助错误。
一、功能测试是测试中最主要的部分，软件产品质量是否稳定，80%要靠功能测试来把握。功能测试中最常用的测试是极限值、非法字符、数据、界面控制、需求和易用性。
1.极限值和非法字符测试中要把程序中可以输入值的部分，进行最大值、最小值、负值、零值的测试。测试中最应注意的部分是，不能只是测试输入在本界面的操作是否正确，要关联前后数据的流向进行测试。因为测试中的数据是在流动的，一个模块的数据可能要被其他模块引用。通常在程序设计时，不同模块是由不同的程序员来写的，因此同常一个数据极限值在某程序员的写的模块中没有问题，但到当数据传递到其他模块中，则数据极限值出错的可能性就很大。
 

输出

    
                         
                  

软件界面

                         
                         

数据

 

流程

输入

数据库

   
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

有人告诉我说，软件就是表单加流程，我想了想，还是很形象的。我们测试的重点在于采用极限值或特殊字符的数据在界面上操作是否正确，保存在数据库中是否正确，从数据库中取回界面是否正确，数据流转到其它界面显示是否正确。
我的经验是在测试中尽量用每个数据最大值，最小值走一遍流程，以确定程序处理中各模块的对数据的处理是一致的。特别要注意的是如数据有小数位限制，比如数据保存只保留两位小数，是否实际保存的与控制一致。有时数据显示为两位小数，但实际数据保存在数据库中可能是四位，或更多位，这时是否会出错。数据在保存时，由于程序员选择数据类型的不同，数据值可能有位差，要注意在除不尽的情况下数据是否正确，如无法判断数据什么情况下尾差可以认为正确，必须要需求确认。
特殊字符重要的是将字符考虑全，最好组内统一总结一下特殊字符的范围，以免测试中有遗漏。特殊字符还要注意与网页html语法和sql关键字有关的内容，可能会导致程序报错。（注意：<>’”;%&/|/和group，by，select，<tr>,</>等关键字。）最后还要注意如与其它产品有接口，本产品控制的非法字符极限值与其它产品控制是否一致。因u8产品老产品与新产品研发时间相隔较长，有些产品可能会出现本产品无问题，而其它产品有问题的现象如以前用户名对web相关的特殊字符未作处理，会导致web产品不能登陆。
2.数据测试是测试中的难点。效率低，强度大，内容枯燥。我不知别人如何测数据，反正我是很讨厌数据测试枯燥无趣，每次测试都头晕脑涨的，效果也一般。不知大家有什么好方法，共享一下。既然不好测，我就总想：能否有什么偷懒的方法可以减轻工作的负担呢？
计算器是我们最常用的测试辅助工具，我们对数据十有八九要靠它。要是有其它的辅助工具可以对数就好了。我在数据分析的测试中想到了用excel来辅助测试。
数据分析的测试有两块难点，一是抽取后的数据按非正常期间、非自然期间，显示数据是否与实际数据一致，检验的数据量大，经常频繁的切换界面核对数据；二是数据分析有许多统计模型需要检验，如果自己手工计算结果，既烦琐又容易出错。
对于第一点我针对excel数据透视表支持对数据仓库表的查询，将数据放到excel表中与程序的结果进行比较。查询速度比原来打开ms analisys要快一些，多少减轻了一点工作量。对于第二点我针对excel提供的数据分析功能直接就可以对指数平滑、假设检验、描述统计功能进行检验，对excel不能自动完成的功能，也通过写excel的函数预置了结果公式，只要将数据粘贴进excel表特定区域就可以得出正确的结果。这样减少了对数据计算的时间，减轻的测试强度。从实际效果来看效果还可以。
对以预算管理测试中也有许多可以提高效率的地方，有待于辅助测试工具进一步提高测试效率。比如利用robot的datapool录入预算表，这样在测试前如果准备一套已知正确结果的excel表样。就可以用excel导入到数据池中，自动生成表样，再由robot走完预算流程。就可以核对数据，正确与否一目了然。
3界面控制、需求和易用性界面控制是单元测试中最常出现的测试内容，最理想的状态是在单元解决调决大部分问题，联调和集成测试尽量不出现或少出现问题，即使出现也是常规方法较难发现的问题。我在数据分析的测试中就在集成发版测试阶段还发现了一个不是很复杂的界面控制问题，但当时真的就是没想到有这种情况。（问题是自定义度量在报表中进行引用后，报表中钻取在某种情况下，会提示错误。虽然是软件已经错误处理的提示，但是此问题还是没能在早期发现。此处固然是测试经验不足的诱因，但也说明在方案设计时有一个详细的计划的重要，还应该持续性对一些已经认为没问题的部分，反复测试。但不能重复测试，要尽量想到新的测试思路。测试水平的高低，与测试内容是否总是重复同一内容有很大关系。测试方法要巧就是不能测试一次后不能走老路，否则总也没问题。要发散性思维尽量不重复测试路径。
关于易用性问题。我在刚开始测试时，有一个问题始终困扰我，就是有些问题属于可提可不提的问题，改或不改并没有一个清晰界限，如何判定我提的问题是否正确呢？经过一段时间的测试，我意识到：只要你自己认为这个功能不好用，用户就一定也会认为不好用，当然是要提的问题了。问题只有小问题，没有傻问题，不用怕问题无效。
需求问题则是在测试中很微妙的一个测试点。产品整体的把握来源于对需求的透彻理解，而需求通常是有不符合实际的情况，因此虽然必须根据需求把握产品，但也要对需求怀着审慎的态度，在测试中发现需求的问题，随时纠正。
 

二、权限测试和年结测试问题不太多，但是因为问题不多，反而会因为不重视而忽略它。预算测试中我就因为觉得权限问题应该问题不大，就测试的不是很细致，在测试的最后阶段出现了几个问题。原因就是觉得问题不大，反而出了问题。与权限相关的测试是审批流的问题，预算管理测试时认为审批流是小功能，问题不大。但实际测试发现，问题一点也不少。集成阶段测试有很大的一部分是审批流和权限的问题，这些问题在集成阶段是不应该出现。
这个教训说明：测试点再小也不能漏才能保证产品的质量，否则测试的任何一点疏忽都会导致产品的不稳定。就如木桶理论一样，测试中最薄弱的环节决定了产品质量。年结测试集团产品的量不大，但是要注意，测试前一定要把各种情况考虑全。另外进入集成测试后，一般都会作年结，因此集成测试录入数据全一些，在跟随集成帐进行年结测试，就应该没什么问题了。年结要注意连续多年年结是否会出错，预算管理有一个问题是连续三年年结没问题，当年结到第四年，报错。与权限相关的测试是审批流的问题，预算管理测试时认为审批流是小功能，问题不大。但实际测试发现，问题一点也不少。集成阶段测试有很大的一部分是审批流和权限的问题，这些问题在集成阶段是不应该出现。
三、环境测试和升级测试环境测试的目的主要是测试在不同环境下产品是否可用。 在单元阶段应该测试几天就换一个操作环境。但也没必要不停的换来换去，应该找一个用户最常用的系统win2000或xp作为主要的测试环境，但其它的测试环境也要隔一段时间跑一下产品的整个流程，如果流程和按钮不报错，产品在环境上就没问题。也可以用脚本跑不常测的环境。升级测试我的经验也不多，重要的是把不同版本的帐套准备全，关注升级后本产品的数据是否正确，特别要注意权限，引用关系是否正确，此处最容易出错。
四、加密测试和并发互斥测试加密测试主要是加密控制是否正确，只要把需求吃透，应该没什么问题。要注意的是，有些时候可能加密盒可以读出站点数，但产品模块功能不释放的问题，此处是较容易忽视的问题。并发互斥测试在集成前组内会进行一次，集成后测试部也会挑重点再测试一次。只要按需求的要求认真测试，就没什么问题。但要注意需求可能有想不到的地方，随着测试进行要检查是否需求没考虑到的地方，再补充进来。
五、打印测试、安装卸载、帮助错误测试这三项问题不多，测试中也没有什么难度，就是要重视，设计较全测试案例就可以了。
 

第二个部分是关于产品质量把握的。软件产品测试是一个很有趣的工作，它由人来完成，质量也由人来把握。我现在要说的是产品质量可能出现问题的原因。前一部分主要是针对最细致的方面，本部分则是从总体上把握的。

产品的全部问题

人的本身对质量的影响：测试中的问题有些确实是测试人员的经验不足造成的，但还有一部分问题是由于测试人本身原因造成。如在预算管理中我在测试中犯了两个错误，权限测试不细致造成的问题，从自身是由于对权限功能不是重点，没有重视；另一方面也是由于当时联调进集成比较匆忙，急于提交成功，有所忽略造成的。如何解决这个问题呢：我想是要形成好的测试思维，把测试流程结构化。何为好的测试思维呢，就是拿到一个产品后，都必须要在预先设计好测试的内容，不能凭灵感和直觉测试。我自己就有一个认识不断提高的过程。

较难测试的问题但影响用户的使用

常规测试容易测试的问题

 

 

 

 

 

 

 

 

 

 

 

原来测试就好像打靶一样，充满了随意性。就好像往一个标靶上投飞镖，标靶就是产品存在的问题，靶上的飞镖就是找到的问题数，投到了靶上，就是找到了一个问题。这种情况下测试的质量取决于标靶上飞镖的密集程度，只要你投的位置对，就总有问题。产品的质量很难稳定。这时我的想法是：测试真是一个遗憾的工作，无论什么时候都不能自信的说，我保证产品肯定没有问题。这个想法也对也不对。对的部分是测试确实是遗憾的工作，只有测试不到的bug，没有完全无问题的产品。但是，产品是最终面对的是用户，我们虽然不能测试出所有的bug，但是我们可以在一定的程度上保证产品的在用户的使用下，不会出现问题。

随着产品的开发量越来越大，测试的任务越来越大。我们必然需要有一个原则来保证产品的质量。我将产品的问题划分为三个层次，一测试的全部问题是一个产品缺陷的全集，这个层次下，问题是不可能在测试被穷举的。第二个层次，是较难测试但影响用户的使用的问题。这个层次下，问题是较难被发现的，可能测试规定的时间下（即产品发版日期之前），很难测试出来，或可以测试出来，但投入的时间成本较高，严重与投入不成正比。此层次还有一类问题是一定会出现的，即由于测试人员能力有限，或测试人员精神和身体影响导致的测试问题，或测试人员思路的局限性（此类问题虽然不应在此层次出现，但在实际过程中由于测试主体是人，必然会出现问题。因此此类问题实际中其实是一定是会出现的，并不是纯粹按理想状态，按逻辑规则，就没问题的）。第三个层次是我们用常规方法可以测试出的问题，或在规定的测试时间内能够测试到的问题。其实我们测试的质量把握就是尽量缩小第三层次的与第二层次范围的差距，最理想的状态是第二层次与第三层次相重合。

怎样达到这种目的呢，我的想法是测试流程结构化，即尽量将自己测试的工作划分为较细的测试点，每测试一部分都尽量将问题想全面，每测试一个功能点都要将其测试的组合，记录为已测，列表标记。这样做到心中有数，才能减少由于人的因素可能导致的测试盲点。此外，测试除常规测试项目外，应着重从用户需求角度测试产品。因为产品最终是用户使用，而测试时间又是一定的，为了在短期内实现最大的效率，从用户角度测试应是最重要的。如果一个问题很难测试到，又不是用户常用的操作，那么在此处化费大量的时间其实是与控制产品质量的的目的是不相容的。因此应在单元阶段解决常规测试问题的前提下，重点把握需求。因为产品的核心还是用户的需求把握。

其次，是交叉测试。只要是人测试，就必然有思维的局限性。适当的交换测试人，等于多了一个人把关，如果一个测试人员的缺陷率是3％，那两个人测同一模块的缺陷率是3%×3%＝0.09％。虽然不同人测试的熟练程度不一样，测试的时间可能也不完全一样。缺陷率可能高于3%，但两人测试同一模块缺陷率大大低于3％应该是可以肯定的。因此，未来在本组内测试产品，交叉测试可能会是发展方向。因为本组产品关联较大，测试上有连贯性。但交叉测试有先决条件，即测试人员必须对交叉产品都有一定熟悉度，此外对于产品中的测试难点，比如算法，数据，由于受限于测试人对需求的掌握程度，可能在交叉测试中较难处理。最后，如交叉测试中人员出现互相依赖的现象，可能会降低测试的效率。如何把握目前我还不知道。

最后，如测试中出现问题，过于强调测试人员不应该出现此问题，或在产品发版后单纯追究测试人员责任的行为，其实是不智的行为。我相信即使测试人员漏测了最简单的问题，也一定是可以通过管理和培训加以避免。我们现在应该还是在事中控制多想办法，因为这是最有效的提高质量的方法。事后控制的方法，其实起到的作用很有限。

关于事中控制我只有几点不成熟的想法。

1.                  目前测试系统我们已经记录了大量的测试数据，但是并没有得到一个很好的利用。在测试预算产品的过程中，我突发奇想：如果将所有测试的产品分为大、中、小三类。假设填写的测试问题足够准确，我们对每一类不同产品的测试问题，按测试项目归类。某一类产品的不同测试项目，应趋向于一个定值，即一类产品的任一测试项目应有一个大约应达到的问题数，或占总产品的百分比。如新测试的某产品，某项的测试项目的问题数没有达到该类项目的测试平均问题数，我们有理由认为该产品在该项目的测试未达到质量要求。
2.                 
如某测试项目如年结在按周的问题数在时间序列下出现波动，我们也有理由认为该项目测试不充分。
这样我们根据分析结果，进行重新测试，必然可以提高测试质量。此处可能对测试人员能力不强时，应可以起到弥补的作用。
3.                  在前两条充分实现的前提下，对程序员的考核，对测试人员的考核都会有一个较为量化的指标。此外，可以加一些测试异常趋势报警，直接反映到测试负责人处，便于测试负责人监控测试质量。比目前填正确的测试单要有用的多。目前填写正确测试单，我认为，效果很一般，并不能反映出产品的实际状态。
4.                  测试如达到事中控制，就一定要求测试人员填写测试单选择项目要比较准确。是否过于理想化，我也不知道。

 

最后是关于测试工具的使用问题：

1.                  目前测试中已经都开始使用测试工具了，但是测试脚本的质量还是不统一。目前集团组的脚本，还是应该有一个统一的检查，以保证测试脚本的质量真正能帮助我们做事情，并且不加重我们的负担。
2.                  测试工具主要可以使用的部分是流程，按钮、数据测试。流程、按钮测试我们已经实现了。对于数据测试。我想我们应该分两步走，一减轻工作量，先研究一些辅助工具。二、在此基础上，对测试数据进行整理，整理出一套完整的测试数据，对数据检验在脚本中固化，争取用脚本回放就可以保证数据正确性，并归纳需求研究出通用的测试工具来。
3.                  产品测试不同版本之间，测试脚本差异很大，这可能是我们测试工具高级应用中最大阻力。但解决的方法可能有待于实践的摸索。