测试用例之QA有话说

在软件测试领域，测试用例是个老生常谈的话题。看似了无新意，其实每个人都有自己独到的经验和体会。
编者采访了5位从业人员，当中既有测试新人，也有专业大拿。听听他们的心得和故事，或许有所裨益。

懒懒不想动

测试要站在客户的角度考虑问题。而作为客户，作为使用者，关注的是性能（页面打开的快不快），UI（页面好不好看），功能（业务逻辑是否合乎预期）。因此，性能、UI、功能，这些都应该在测试用例中有所体现 。另外，由于应用会运行于不同的手机端或浏览器，所以兼容性问题也必须关注。

测试人员应该有一个好的测试用例模板，好的模块能使测试用例简洁明了，通俗易懂。

若飞

(1) 编写测试用例前，先列出测试点，尽量细化，然后再补充成为用例
(2) 编写测试用例时，先不考虑能否进行测试，而是把用例尽量覆盖全面
(2) 尽量覆盖到可能出现的场景，一定要考虑异常情况，生产环境一切都有可能发生

尧米

先说用例的设计，虫师的 浅说《测试用例》，可以作为入门参考。除了常规的设计方法外，还应考虑：

(1) 实际业务场景和端到端用例。比如产品是给肯德基用的，肯德基的门店数有5000多，那就必须有5000多家门店的场景用例。关于端到端，比如这次改动了活动创建模块，那对该活动的创建、修改、用户享受该活动、活动下架等全过程都要测一遍。
(2) 产品的用户体验。这点比较难写用例，一般在需求评审、demo评审、测试执行过程关注即可，比较依赖个人经验。产品上线后也会有舆情分析，产品经理们会关注舆情并持续改进产品。我们主要关注给用户的错误提示够不够明确，通常在测试过程中需要梳理一版各系统以及前端的错误码映射关系并补充到测试用例中。
(3) 日志打印是否合适，是否便于后续线上问题排查。
(4) 异常测试一般考虑并发操作、某一个系统挂掉时，是否会重试、幂等返回。
http://www.cnblogs.com/fnng/archive/2011/09/10/2173149.html

再说用例的维护，可以从单个项目维度来维护，也可以从产品维度来维护。推荐从产品纬度维护用例，这样可以维持一份完整的知识库，也便于在后续项目中复用用例。

在执行用例时，除了标注用例pass或者fail之外，一般也需要将具体的测试结果值和测试数据都写在用例备注中，以便在后续轮次测试时复用测试数据，以及对比测试结果。当出现线上故障而追责时，也能证明我确实执行过了，免做背锅侠。

里河新村

我眼中的测试用例，应该能把测试工作控制在一个合理的时间范围，因为一个产品想要找出所有的缺陷几乎不可能，随着测试的推进，总会有新发现的缺陷，如果无的放矢、自由发挥，那么完成测试就遥遥无期；其次，测试用例也不是以多取胜，而要看整体的覆盖面，因为任何一个产品都可以通过枚举写出无数条用例，如果一百条用例覆盖了同样一段逻辑，那无疑徒劳无益。

如何写出好的测试用例，说实话我还在摸索中。目前使用的表格形式，不仅不易于统计管理，写的时候也是头大，每每写到复杂的功能，都得借助XMind来整理下思路，最后才勉强能够稍微清晰一点的放在一个只有function 、 test name的表格中。所以从我个人角度，还是希望能用专业的测试用例管理工具来代替Excel。

村上春树

写测试用例的能力之于测试人员，好比写代码的能力之于开发人员。

对软件测试而言，什么最重要？我认为是Test case。我曾在正规的企业做测试，工组中最看重的就是测试用例。每次新增需求，需要针对新增内容剖析各种可能性，设计用例；每次更新版本，也要保证重新维护的用例适用于新版本。从初入职时磨炼写case的基本功，到两年后技能成熟时，以时任领导吹毛求疵的脾气，我们仍然可以被允许一天只写出20条的测试用例。这种做法的结果是什么呢？是几乎不会出因为测试人员“这次没想到”，而出现“测不到的bug”，这才是严谨的测试工作该有的样子。

在创业公司，这种观念却是如此不合时宜。有人说，创业公司节奏快，需求变更频繁，要争分夺秒创造价值，我们做敏捷开发敏捷测试，不能给你充足的时间去做这个那个。但是我想说，敏捷开发敏捷测试的目的是快速迭代更新以提高产品质量，而快速提高质量的基础，正是依赖于测试人员抽丝剥茧，逻辑缜密的测试用例！这难道不是跟软件的形成是由开发人员一行行代码堆砌出复杂程序是一样浅显的道理么？

可惜并没人认同。领导层不健全，测试部门由开发部门管理；开发人员无法了解甚至不去了解测试工作的构成，以为测试用例只不过是给几分钟随便打一些字就能完成的文字表格；测试人员不训练写测试用例的能力，写出的用例没有标准的审核，甚至除了本人，没有其他人去阅读和使用。当这种观念形成并被“推崇”之后所带来的结果是什么呢？开发人员普遍不重视测试，码完了事，提测时re-work的功能漫山遍野；测试人员没有完善有条理的测试用例，敷衍了事，想不到的bug比比皆是。