1.3测试经理的尴尬
某天，部门总监A请Sherry到其办公室，让她解释一下什么是软件测试技术。Sherry被问得一头雾水，不明白背后发生了什么事情。Sherry心想，这位总监也曾是程序员，不可能一点都不了解软件测试，肯定是自己工作的某个方面出了问题，而且是他认为相当低级的问题。但这位总监有些“古怪”，偏偏不提及提问背后的原因，只是要求Sherry给他解释什么是软件测试技术。Sherry只好根据自己所学知识和过往经验，介绍了软件测试的方法、工具，以及如何应用等，但总监似乎不太满意，不断追问。
在这样的场景下，Sherry感到尴尬和委屈，因为部门总监A的问题难以用三言两语讲清楚，甚至这个问题太基础，部门总监A不应该向她提问。虽有不解，但Sherry还是在离开部门总监A的办公室后思考良久。
后来，Sherry了解到，其他研发部门开发的产品因软件质量问题被召回了上千台，风险意识极强的部门总监A想要仔细了解自己部门研发的产品是否存在类似问题，于是查看了相关软件测试报告。其中，关于仪器测量病人血液数据的保存正确性的测试用例很少或不充分，甚至大部分测试用例只用来检查界面显示情况，如某按钮亮显、某按钮灰显等。部门总监A认为，这样的测试不但毫无重点，而且无关痛痒，是“表面”测试。于是，才发生了上面的对话。
根据Sherry后来的描述，部门总监A是对图1-4所示的“测量数据浏览”界面的测试工作产生了质疑。
图1-4 “测量数据浏览”界面
为了测试图1-4所示的界面上的软件功能（此界面由用户单击前一界面中的“浏览”按钮进入），测试人员设计了一批测试用例，表1-2是相应的测试报告。
表1-2 “测量数据浏览”界面测试报告
一开始，Sherry感到有些委屈，但在她仔细看完这份测试报告后，也认为测试用例的设计不够严谨和专业。后来，她带领团队重新梳理了测试用例设计规范，以及测试用例的设计模板与方法等，并以流程规范为指引推动它们在项目中落地，最终收到成效。
优化之后的“测量数据浏览”界面测试报告见表1-3。
表1-3 优化之后的“测量数据浏览”界面测试报告
点评
对于表1-2所列的测试用例，“预设条件”“测试用例标题”“操作步骤”和“预期结果”中的内容有多处相同或类似，根据每条测试用例的唯一性要求，测试用例的设计与组织明显存在问题。在查看他人编写的测试用例报告时，我们只有了解测试用例设计人员的思路，结合被测试对象的用户需求和软件设计的实现原理，如用户浏览数据的主要目的、目前的实现结果是否满足用户需求、浏览数据从何而来、浏览数据时可能遇到的问题，以及是否设计了相应的测试用例等，才会发现测试用例的缺失或冗余之处，以及漏测带来的风险。
测试用例是测试工作的重中之重。无论是测试通过的测试用例，还是发现bug的测试用例，都是测试人员的重要产出，它们是守护产品质量的关键。
如果我们的测试分析高效，测试用例的设计充分，那么，就可以既守护产品质量，又不影响产品上市时间。
