【IT168 评论】

　　测试用例无疑在测试过程中起着举足轻重的作用，好的测试用例让测试人员在测试执行过程中心情愉悦，测试效率高，能发现更多的问题。

　　好的测试用例一般有如下几个特点：清晰、简洁、完整、适用性、针对性以及以维护性。总结了我们公司的测试用例状况，存在以下一些问题：

　　1.全case测试用例太过详细、冗余，测试起来费时费神，而且发现不了什么问题，测试用例在清晰简洁性方面存在问题，这还体现在交叉测试上，冲突事件太多，实际上很多都是等价的冲突，有限的时间，没必要逐一确认;

　　2.同项目多个平台升级(客户升级)版本重复使用相同的测试用例，用例的针对性不强;

　　3.多国语言版本没有针对性的测试用例(目前版本基本使用基本功能case或者客户版本case，针对性不强)，测试用例的完整性存在问题，这还体现在其他一些新的功能模块，没有相应的测试用例;

　　4.有的case看上去很美，写的也十分详细、面面俱到，但测试上却发现不了什么问题，针对性方面存在问题;

　　5.受以上一些因素的影响，很多测试人员不愿意跑case，如果凭借经验让他们来测试，相同的时间他们能够发现更多的问题，而跑case却发现不了什么问题，也没什么成就感——测试用例在适用性方面也存在问题;

　　6.测试用例更新不够及时，目前主要是采用Excel表格形式来编写测试用例，有时候测试用例的设计人员做了改动，则其他测试人员一般难以及时了解——测试用例在可维护性方面存在一定的问题!

　　综合以上，我们的测试用例在清晰、简洁、完整、实用性、针对性及可维护性等方面均在需要我们改经的空间。

　　在做改进之前先得再介绍下项目平台特点，我们这边的开发平台都是MTK的老平台，平台相对比较稳定，之所以MTK能够成就那么多黑手机，一个主要原因还不是平台比较成熟、稳定，开发简单，风险较低，呵呵。

　　比较稳定的平台，每个功能模块本身的问题并不多，我们所作的主要就是一个集成、系统测试，所以类似针对类似单元测试用的太过详细的用例在这里就不适用了。

　　另一个原因就是我们的测试人员，大多数都具有1年以上手机测试经验，当你把某个功能点告诉他的时候，要测试哪些内容，要注意哪些细节，他们都十分清楚，根本就不用罗里罗嗦那么多去描述。

　　改进措施：

　　鉴于以上原因，我们的软件测试用例在优化调整工作主要从以下几方面开展：

　　1.为了让测试用例看起来更清晰、简洁，同时给测试人员一定的弹性空间，在内容上有些项可以写成checklist形式的;把太过详细、冗余的测试用例去简化，该删除的删除，该保留的保留，几个详细操作步骤能用一句话概括表达的就用一句话概括表达，在测试用例的检查点方面，尽量只写一两个最主要的检查点，其他很多无关紧要的检查点全部删掉(测试人员在测试过程中自然都会关注到);

　　2.把过时的以及错误优化更正，新增加的功能点，在测试用例上及时覆盖到，毕竟测试用例也是要与时俱进嘛;

　　3.同一个功能模块的测试用例，把同一张表格中的功能性、交叉、性能效果几方面的测试用例从不同角度进行分拆成不同在不同的表格中;

　　做到以上两点，我们的测试用例基本上也就达到了清晰、简洁、适用性以及针对性几方面的要求了。至于可维护性，说实话，目前感觉用Excel表格的形式来做测维护及测试方面而言还是挺不错的，Excel表格删除、增加等都比较方面，测试时使用也比较方面，唯一的问题就是更新后，难以及时的体现出来。但似乎也没有其他更好的测试管理工具，比如TD、TestLink也存在一定的缺陷。所以这块，目前还是维持现状了。

　　4.为了更快的检查出软件存在的一些主要问题，我们再增加一套checklist，以便不同阶段使用。我觉得checklist还是非常重要的!

　　5.其他

　　针对不同的版本，如客户版本、外文版本自身的特点，有针对性的整理出相应的测试用例。

　　以上改进目标主要针对目前开发平台相对比较稳定，各个模块封装的较好的特点所采用的对策，不太适合全新平台、功能模块!

　　改进结果：

　　to be continued……

　　补充：

　　Checklist VS test case：

　　Checklist即功能点检查表，只告诉测什么，并没告诉如何测的问题，而测试用例则是一份比较详细的文档，有具体测试步骤和预期结果等的描述，即告诉了你如何测的问题!测试用例和checklist是有些区别的，不过我们实际工作中可以将两者结合起来处理，实用就好。不同的人执行相同的测试用例，结果应该是相同的;不同的人执行同一条checklist，其结果可能不尽相同，有一定的弹性空间!两者结合起来有时候效果会好!

　　好的测试用例的特点：

　　简洁、清晰、完整、针对性、适用性、可维护性等

　　写测试用例的一般原则：由简单到复杂，由基本功能到细节功能

　　个人观点：

　　1.详细的测试用例不一定是好的测试用例;

　　2.出现问题多的模块一定还有较多未被发现的问题存在!

　　3.在时间、资源有限的情况下，能够更多地发现bug(尤其是严重的bug)的测试用例就是好的用例!

　　指导思想:

　　发现问题(搜集问题)—>分析问题——>改进措施——>执行——>效果检查—>改进，基本按照PDCA的思想处理!