从2009年底进公司至今，我已经干了两年多的测试，接触了5个以上国内项目的测试。项目时间长则一年，短则数月。当然，其中有并行的项目。从手工测试到自动化，从自我学习到团队建设，我一直按照自己设定的路线行进。由Engineer升为Sub Leader，普通员工成为员工之星，我对自己的成长是满意的。下一步，我要提高自己的英文水平，深入了解云计算领域；我要结束之前的水平学习状态，开始垂直学习。但在换组之前，我要把在国内项目中的感悟记录下来。作为开篇，本文就围绕测试用例展开吧。
- 争取编写测试用例的时间
国内的软件测试不好做，很多客户包括项目经理完全没有把测试作为软件开发的一个重要环节，有的人是对软件测试没有概念，有的人则是认为专门的测试人员起不了明显的作用，只要开发人员手动测一测就好。对于这种现象，我经常跟开发和测试人员沟通，开发人员会抱怨说，测试人员测过之后，仍不能确保软件质量，到客户那里很容易就出问题；测试人员说，开发人员预留的测试时间太少，而且测试也不能保证发现所有的缺陷。看似公说公有理婆说婆有理，但归根结底，我觉得是测试经理/人员的问题。
测试人员要明白，他们介入项目的时机，越早越好。如果有需求变更，测试人员也应该和开发人员同时知道，而不能等到开发人员改好了程序，要求测试的时候才知晓。测试人员必须要为自己争取修改测试用例的时间。
测试用例是测试人员工作的凭据。没有测试用例，正如编码没有注释，没有设计文档，项目就变成了“打地鼠”，总有Bug不知从何处冒出。
- 不要再写空洞的“XXX操作已成功”
我接触最多的是基于Web的办公系统，用例中最长出现的就是“XXX操作成功”之类的话。仔细想想，这种语句出现在功能测试用例中，有多大意义呢？
难道我们真的能相信所谓的系统提示吗？或许页面上的操作根本没有让数据库中的数据更新。如果现在让我写功能测试用例，我会写明是某张表的某些字段被更新了，或是直接附上SQL语句。
这样写有两个好处，第一，在功能开发过程中，需求变更的可能性是非常大的，今天有三个文本框是First Name，Middle Name，Last Name，明天就只有一个文本框User Name。往往数据库字段和后台程序是没有改变的，只有页面上做了调整。在这种情况下，如果我们的用例结果是描述数据库受到的影响，就不用调整，我们减少了这部分的工作量。
第二，让测试人员关注数据库，让他们以开发的思维去思考，会让测试和开发的沟通更高效。有的测试人员能直接在Bug描述中指出是哪个存储过程，或哪张表的约束有问题，从而提高开发的工作效率。
当然，测试类型不同，用例的编写自然也不一样。我们当然不会在UAT用例中写SQL语句。
- 测试用例需要设计和评审
提到测试用例的设计方法，很多人都能说上一大串，但到了编写用例的时候，又抛之脑后。不少系统都有状态迁移图，但是有多少测试人员会根据状态迁移图去设计测试用例呢？大部分人都是根据功能模块，写写页面操作了事。其实网上有不少基于状态图生成测试用例的方法，也有很多介绍其他测试用例设计方法的文章，但在实际项目中，我没看到有多少人在实践。
测试人员不懂得利用设计方法和评审去避免测试遗漏，就难以保证软件质量，难以体现自身的专业价值。
- 没有测试用例，何谈自动化
工作中不断地输入、点击、重复确认，决定了测试人员对自动化孜孜不倦的追求。如果你告诉我，你在项目中进行了自动化测试，却没有测试用例，那我会认为你在说，“我只会用自动化测试工具写脚本，但我不懂自动化测试要如何进行。”没有测试用例，你要以什么为依据为自动化脚本创建公共方法库？你要如何衡量自动化在测试工作中的作用？没有测试用例，你连手工测试都没办法做好，更不用说自动化了。
所以，最后问问自己，你为项目设计出有效的测试用例了吗？
