测试工程化实践之路测试用例篇（02）

lsekfe

1.2 填写测试用例的故事
　　一直以来，一些人对软件测试存在如下认识误区：
　　软件测试就是用鼠标随便点击几下；
　　从事黑盒测试工作没有前途，软件测试人员应向自动化测试、性能测试和安全测试等专项测试方面发展，或者从事测试工具的开发工作；
　　软件测试如果不包含需要编码的技术工作，就没技术含量。
　　下面以“填写测试用例的故事”为例探讨产生这些认识误区的原因，帮助读者建立正确的认知。
　　测试用例的准确性和充分性决定着对软件中存在问题的揭露能力。测试用例对测试工作的重要性不言而喻，但测试用例的设计与代码的编写并没有必然联系。
　　Carl是作者的朋友，同时是消费电子产品领域的软件测试专业人士。某天，他和作者分享了让他感到意外的一次与测试用例设计相关的面试（作为面试官）经历。
　　Carl：请介绍一下你在工作中执行一项具体测试任务的流程。
　　应聘者：首先，组长安排任务，然后，我们直接在手机上测试APK（Android Application Package，Android应用程序包）。
　　显然，应聘者的回答并不是Carl想要的答案，于是Carl对应聘者稍加提示。
　　Carl：领到任务后，你首先做什么呢？
　　应聘者：开始测试，也就是在手机上测试。
　　Carl认为应聘者还是没有明白他的意思，于是再次提示。
　　Carl：你们进行测试分析、测试用例设计吗？
　　应聘者：我们会填写测试用例，但好像没有测试分析与测试用例设计活动。
　　Carl当时第一次听到“填写测试用例”这样的说法，感到很诧异。Carl认为测试用例是设计出来的，他不明白测试用例为什么是填写的。
　　于是，Carl问：“填写测试用例”是什么意思？
　　应聘者：我们的项目属于外包项目，任务交付时，需要输出测试报告。因此，我们事先复制外包项目的需求内容，并将它们粘贴到测试用例表格中。当执行完测试用例后，我们再在“测试结果”栏中填上“PASS”（通过），我们将这个过程称为“填写测试用例”。
　　Carl突然明白，原来应聘者对软件测试的认识与其工作环境有密切联系。
　　如果读者作为应聘者，那么应该如何回答Carl的问题？虽然答案并非绝对，但可以在一定程度上反映读者对测试工作中测试分析与测试用例设计的认识。
　　点评
　　在Carl与作者分享了那次经历后，我们就此事进行了热烈讨论。最后，我们一致认为，在测试工程化的路上，技术只有为客户解决问题并创造价值，才是有意义的。目前的软件市场中仍然存在大量项目外包的情况。在从事外包项目的公司中，与上面提到的“应聘者”从事类似工作的人不在少数，这可能会令相关人员产生“测试就是用鼠标随便点击几下”“测试没有技术含量”等认识误区。