关于测试用例设计的思考

过年了，没事可做，总结一下自己在中国移动NGCRM项目组这一年的工作所获，希望对大家有帮助。语文水平不怎么滴，废话比较多，请原谅啊！

从事软件测试工作者，对怎么写一个测试用例应该是再熟悉不过了。只要是从事软件测试工作的，人人都会写测试用例，但什么是好的用例，怎样设计一个实用且规范的用例，可就见仁见智了。我根据自己的理解，结合在工作中的实际情况来说说对测试用例设计的思考。      

       毫无疑问，设计测试用例的前提是基于对需求的充分理解，从哪些方面去获取详尽的需求呢？如果公司研发流程比较规范的话，在测试准备阶段，测试人员就能拿到一份关于需求的分析说明文档，即软件规格说明书。那么，软件规格说明书就是我们获取需求的首要途径（但不是唯一途径）。通过阅读软件规格说明书，大概了解一下所测试系统或需求的测试内容，再结合质量模型的相关特性，测试者就可以初步确定从哪些方面进行测试用例的设计。

这里穿插说一下什么是质量模型。质量模型代表软件质量属性的总体，包括软件质量特性和软件质量度量。软件质量特性又分为质量属性和子特性，软件质量度量可以从软件外部质量和内部质量进行度量。软件外部质量和内部质量又可以从软件质量的六大属性，共27个子特性来进行度量，六大属性包括功能性、可靠性、易用性、效率、维护性、可移植性。关于各软件质量属性的子特性，这里就不再细说了，有心的人可以自己去学习一下。另外，软件质量度量除了从外部质量和内部质量度量外，还以从软件的使用质量来度量。软件的使用质量可以从有效性、生产率、安全性和满意度四个方面进行度量。

回到前面的话题。如果没有相关的需求文档，或者需求文档中提供的信息比较模糊，那测试人员就应该通过与那些熟悉需求的人员进行沟通交流，比如开发人员、SA（需求分析人员）等，在必要的时候，也可以直接和客户沟通了解需求的详细内容。需求确定以后，测试人员就可以进行测试用例的设计工作了。

      又得说点题外话。在测试准备阶段，测试人员一般都会同时拿到软件规格说明书和需求设计说明书。软件规格说明书是由客户提出需求，经SA与客户沟通交流后，SA给出的一个需求分析说明文档，而需求设计说明书是SE根据SA提供的需求分析说明文档，由SE给出的一个设计或实现的说明文档，而研发人员则按照SE给出的需求设计说明文档来进行具体的开发和系统实现。通过上述过程可知道，需求走向是：客户àSAàSEà开发人员，所以，从客户到开发，需求经过了三次转手。那么，每一次转手，需求都有可能被“打折扣”，而最原始最正确的需求在客户手里，无论是SA提供的软件规格说明书，还是SE给出的需求设计文档，都有可能偏离或遗漏了客户的原始需求或需求功能点。这也就是我们常说的在软件需求分析阶段或需求设计阶段出现的错误导致后期系统功能实现错误的原因之一。出现需求分析或需求设计偏差或遗漏原始需求这样的错误，责任在谁？测试人员就说了“这是需求分析和需求设计的错误，需求上就那样说的，就那样设计的，不关我事”。呵呵。。。如果你也这样说了或这样认为了，那我还是劝你转行吧！虽说软件测试的执行是软件生命周期中比较靠后的一个阶段，但测试人员也都知道软件测试应该贯穿于整个软件生命周期，可在大的软件公司，分工都比较明确，有专门做需求分析的（SA），也有专门做需求设计的（SE），测试人员往往很少参与需求分析和需求设计，那么对测试人员来说，软件测试到底是如何贯穿到整个生命周期中的？尤其是如何贯穿到需求分析和需求设计阶段的？其实，这就看测试者的态度和考虑问题的全面性了。我个人一向认为，能力也许只是时间问题，但态度一定是人品问题。有的测试人员抱着“多做多错，少做少错”的心态，只是对需求分析或需求设计文档中的说明和要求去测试需求或功能，而从不考虑需求分析或需求设计文档是否存在问题或遗漏。测试人员如何知道需求分析文档是否存在问题或遗漏呢？当我们拿到一个需求的时候，首先根据需求分析文档，初步了解需求要实现什么，进而要考虑与此需求相关的业务或功能，将自己能想到的相关业务和功能罗列出来，在需求分析文档中看是否对自己考虑到的相关业务和功能有说明，如果需求分析文档中没有说明，再在需求设计文档中看是否有与此相关的设计说明，如果还没有说明，可以直接与开发人员沟通，看实际开发过程中是否考虑到相关业务和功能。无论开发人员回答是与否，这个时候都应该和SA沟通确认，毕竟需求分析文档中没有明确说明，或许这是客户明确要求不考虑的，也或许这是客户明确要求考虑的。经过和SA沟通了解后，建议再和客户沟通求证（至于为什么，下面的例子中我会讲到），最终得到需求分析是否存在问题或遗漏。

      下面我根据自己的经历改编一个例子（注：这个例子纯属自己编的，不能当做业务知识进行学习）。大家都知道每个单月都是上缴水费和电费的时间，每个双月都是上缴燃气费的时间。水电气费是每两个月出一次账单，下面说到的本月、上月特指的是出账期，不指自然月。居民到银行去缴水电气费，在银行的代收系统中，按照原有的业务规则，居民缴纳本月水电气费前，首先要将上个月的费用结清后才可缴纳本月的水电气费。所以银行工作人员要在两个业务菜单中办理，即“历史账期结算”和“当前账期缴费”两个业务菜单。现在银行发现，这个业务操作流程太繁琐，要简化操作流程，提了一个需求，将“历史账期结算”业务和“当前账期缴费”业务进行融合，要求在一个业务菜单中受理这两个业务，但又要保持原有的业务规则。上述内容就是客户的原始需求，相信大家都有一样的感觉，感觉这个需求很明确，但似乎又很模糊。为什么会感觉模糊呢？大家都知道，一般收费系统办理业务后都要打印发票或收据，而且还支持业务回退，那么现在两个业务融合后，问题就出来了。先不说系统以什么方式对这两个业务进行融合，就说收据如何打印？是否需要支持两个业务的收据合并打印？有的系统还有发送短信的功能，那么融合后，这两个业务的短信提醒功能是否也需要融合？在业务回退时是否需要支持一次性回退两个业务？还有，因为原有的业务规则没有改变，所以，无论系统以什么方式对这两个业务进行融合，对系统来说，都是首先处理“历史账期结算”，然后才进行“当前账期缴费”处理，那么业务办理中断情况就需要考虑。为什么要考虑中断情况？大家能想到的且很少遇到的情况就是业务办理了一半突然停电了，但还有其它且很容易出现的情况也需要考虑。比如银行工作人员给某居民办理水电气费缴纳业务，系统已经先将“历史账期结算”处理了，在“当前账期缴费”提交前，银行工作人员按照系统计算出来的费用向此居民收取费用，此居民一摸兜……完了！忘记带钱包了、钱包被偷了、钱没有带够，或者这时候进来一个持枪抢劫的…….这些情况都需要中断业务受理。那么如果要中断业务受理的话，系统先前处理的“历史账期结算”业务就得撤销，那么两个业务融合后，系统是否需要支持这个功能，这也是测试者应该考虑到的（所以与其说心细的人比较适合做软件测试工作，倒不如说考虑问题全面的人更适合做软件测试工作。姑娘们找男朋友就找从事软件测试工作的吧，哈哈……）。我们带着这些疑问，对比需求分析文档，发现没有说明，再对比需求设计文档，发现也没有说明，那就找开发人员沟通，开发人员回答说“需求分析和需求设计中都没有讲这个，如果要实现的话，这属于需求变更，请提新需求解决！”（碰了一鼻子灰），得，那就找SA确认，若SA支支吾吾说了半天在打马虎眼（SA可能在和客户沟通的时候没考虑到这些），那就直接和客户沟通了解。如果SA明确说这些不需要支持或需要支持，作为测试者，还应该和客户沟通求证一下，到底哪些是需要支持的，哪些是不需要支持的，毕竟相关文档中没有明确说明。以上工作都需要在测试准备阶段进行思考和确认，不能等到开发人员已经开发完成，交付给你测试的时候，你才提出来，如果客户的要求正好和开发的一致，那还好办，但如果不一致，这个时候再进行改动，那可就费事了……

回到话题继续。接下来，谈一谈测试用例的设计方法。拿到需求规格以后，可以将其划分为几个相对独立的需求片段。对每个需求片段，采用不同的测试用例设计方法进行用例的设计。黑盒测试用例的设计方法有等价类、边界值、场景法、判定表、因果图、状态转移和流程分析法等等。每一种用例的设计方法都有其适用的情况，也有不适合的情况，这个要根据具体的需求片段进行筛选。这里要说一下，一个需求片段的测试用例不可能仅用一种方法就能设计出来，往往都需要多种方法结合。这样才能设计出更好、更完善的测试用例来。

最后，说一下测试用例的编写。按照上面设计出来的内容，一定要采用文档化的形式表现出来，不能说在我脑海里呢，测试的时候我会注意这些的（这可是测试者的大忌！）。从阅读需求到思考需求，再到测试用例文档，这其实就是测试用例的编写过程。拿功能测试类型来说，对于一个具体的系统功能测试项目，如果所测试项目功能比较复杂，我们可以把它进一步细分为几个测试子项目（这个是我借鉴的目标绩效考核管理中的“绩效考核目标分解原理”，这里要非常感谢一下我的第一个工作单位----南京美绩软件开发有限公司，感谢冯总、华总、谈总，还有伏崟、菲菲、栋栋、汤汤，春春想你们啦）。对于每个测试子项来设计若干个用例来进行测试。测试用例的编号可以参照方案中规定的格式来编写，要确保编号的唯一性和易识别等特性，至少要保证在测试组内部风格统一。测试标题可以按照所测试子项来进行标识，主要用来说明此用例所测的测试点。然后是设计测试数据及测试步骤。在进行测试步骤的设计过程中，应该使用简洁明了的语言把过程描述清楚，确保测试用例的执行人员能够完全理解。最后是预期结果，也就是此用例的检查点。检查点说明也要详尽，确保测试执行人员能够判断出此用例是否测试通过。

测试用例编写完成以后，测试小组内部应该相互评审一下，主要检查用例对功能、性能等类型的覆盖情况，用例编写风格是否统一等等。评审过后，再进行相应的修改。之后再转交给SA或客户进行测试用例的评审，来确保用例达到公司或项目组的要求。在后续的测试执行阶段，如果发现测试场景遗漏等问题，测试人员应该及时的修改测试用例，并通知相关的执行人员。如果发生了需求变更，也要增加或修改测试用例，始终保持测试用例与客户要求的一致性。