好用例Vs坏用例

测试用例是测试部门应该输出的最关键文档之一。敏捷开发提倡轻文档重交流，很多传统流程中的文档都可以省去，但我认为测试用例不在这个可以省去的文档之列。相反，测试用例在某种程度上可以替代详细设计和概要设计文档，作为一个接口性质的文档。

相比于可以运行的代码，文档的优势是可读性，换个词就是用户体验。好的文档可以帮助人更好的思考，老话说的好，好记性不如好文档。测试用例文档的写作目的一定是为了帮助你和你的团队更好的思考。因此，这里提出第一个观点：好的测试用例一定是以用户为中心的；坏的测试用例通常是以技术为中心的。

如何定义用户呢？用户可分为公司内部用户及外部用户，鉴于顾客是上帝的道理，测试部应该以最终用户的代理定义部门功能。因此，我的第二个观点：好的测试用例基于产品功能的用户体验；坏的用例通常基于功能的代码实现。

如何在用例中体现出用户体验呢？一个测试用例的基本骨架由3部分内容组成：{测试步骤，输入数据，观察点}。在测试步骤的设计中，首要需要考虑的是用户的使用场景。因此，我的第三个观点：好的测试用例应按照使用场景来组织；坏的测试用例通常按照程序员的修改点组织。

一个优秀的团队一定是一个有积累的团队。打造一个后辈可以站在前辈肩膀上不断攀登的团队，组织才能够冲刺更高的目标。优秀的组织应该是开放竞争的，激励先来着人不断探索和开拓新工具新方法，帮助后来者迅速融入和接受现有工具和现有方法。因此，我的第四个观点：不应该以是否可以脚本化来取舍测试用例，不能因为测试条件艰难而故意漏用例，好的测试用例按照需求挑选工具；坏的测试用例按照工具规避用例。

测试用例作为一篇文档，必须注意格式和可读性。文档格式不但要统一，而且应该要体现规律和逻辑，详简安排得当，测试点均匀的分布，冗余少。因此，我的第五个观点：好的用例结构是平衡的，层次清晰；坏的用例忽长忽短，整篇文挡组织无规律可循。

测试环境的搭建，往往是测试执行过程中最耗时最麻烦的一个环节，用例作为一个测试执行的指导说明，必须考虑测试执行过程中环境的易得性。因此我的第六个观点：好的用例测试按照深层的技术实现，搭建至简最优的测试环境；坏的测试用例照搬用户环境。

测试用例是一个寻需要保持更新的文档，应该定期将修改点，网上问题，测试中发现的问题等内容补充进去，并保持自动化甲苯和用例的同步。因此我的第七个观点：好的测试用例容易维护，可以持续发现问题；坏的用例维护困难，很快会失去价值，变成垃圾文挡。