测试用例设计步骤
测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。有哪些具体的列设计步骤可以关注的。小编给大家整理了关于测试用例设计流程，希望你们喜欢!
测试用例设计步骤
——从登陆开始说起
一个完整的software testing life cycle包括诸多内容，本文仅从测试用例的编写开始，聊聊测试用例编写的一般步骤，以使编写的测试用例最大程度上满足完备的要求，而又不产生重复而冗余的负担。 测试用例的来源是产品需求，如果足够幸运，我们应当有一份不错的可依赖的Use Case文档，但大部分情况下，Use Case恐怕是不存在，能有一份不错的PRD文档和原型设计图已经是不错的待遇了，如果可能的话，最好还能够有HLD文档，这些已经足够我们开始写详细的测试用例文档(我相信在这之前无法产出详细的测试用例文档①)。也许LLD文档产生之后或者产品的第一个版本发布之后，我们会不断的更新已有的测试用例，但那将是不断的迭代过程，暂不做讨论。
首先让我们先从理论上了解测试用例编写的一般步骤②：
1、确定测试套件(Test Suite)：测试套件是功能上的划分，是相似测试场景的组合，而非技术划分。如果技术设计中各模块耦合度较高(强烈推荐解耦，哪怕复制粘贴代码)，可能功能上不相干的模块由于代码重用的原因会在bug fix时互相引致错误，实际上回归测试即是为了避免这种情况。但是我们在做功能测试划分模块时，还是要从用户的角度出发，按照用户场景划分测试的“模块”。值得庆幸的是，相似或相关的功能总是倾向于在同一组页面出现，按钮和输入框、选择菜单等内容并不是随机组合的一堆零件。
2、针对每一个测试套件，确定一个或多个基本流程(basic flow)和可选流程(alternative flow)，即测试场景(Test Scenario)：可以借助scenario matrix来清晰地对可能出现的场景进行排列组合。值得注意的是，一方面Use Case或PRD文档中的描述很有可能并没有完整的写尽所有的场景，测试人员尽可能地挖掘测试场景，既有可能是出于测试本身的需要，也可能是基于开发团队的工作;另一方面，在复杂系统中，测试场景不可能覆盖所有可能的场景，这便需要测试人员采用一定的测试策略③，对SUT(System under Testing)进行“足够(adequate)”的测试，而不是完全的测试。
3、针对每一个测试场景，确定一到多个测试用例(Test Case)：仍然可以借助matrix来清晰地规划测试用例，每一个测试用例都有其对应的预置条件④、输入和期望结果。测试用例分为Positive Test Case和Negative Test Case两种，分别用来测试产品是否完成应当完成的工作和不执行不应当完成的操作。更详尽地说，测试用例一般包括以下列column：用例编号/测试场景/用例描述/需求对应/用例分类(Positive/Negative)/用例类型/用例级别/是否自动化/预置条件/测试步骤/测试数据/预期结果/实际结果/备注/
4、增加测试数据(Test Data)完成测试用例：测试数据是测试用例中很重要的内容，一个用例可能对应多套测试数据，测试工程师根据某种测试技术⑤，将尽可能的设计较少的测试数据完成“足够”的测试。 任何规范、流程都是为了让工作更加可靠，对于项目工程，天外飞仙灵机一动应当放在合适的位置，而不应当成为规范和流程的反例存在⑥。
现在让我们开始从登陆(PC端网页，如果是PC客户端比如QQ或手机客户端则又不同)开始说起。 不打开任何网站的登陆框，想象一下登陆框的样子。
然后对照一下本文最后的附图，一个优秀的登陆框除了基本的用户名/密码输入框、登陆按钮之外、(不考虑注册、找回密码、第三方登陆、登陆版本、帮助)，包含的内容有：输入框文字提示/免登陆选项/输入的表单提示(新浪微博)/必要的验证码(出错时的处理)/用户名和密码输入错误(正确)提示/焦点反馈/快速删除已输入字符/Tab切换/鼠标点击有字符输入框光标位置/Enter键选中/密码非明文显示/是否弹窗显示(不要打断正在处理的任务)/页面跳转/进度反馈(网络较差的情况)/多账户登录/多终端登录/Cookie/token
最后值得强调的是，真正能够保证产品质量的是开发人员而不是测试。在一个完整的软件工程周期中，开发人员从建设的角度保证产品质量，测试人员从破坏的角度检验产品质量。如果在测试用例执行环节提交了成百上千的bug，即便最终每个bug都被修复，新产生的bug数量一直在收敛，这样的软件产品恐怕也不是让人有足够信心发布出去的产品。实际上，从经验来看，总是有大量的bug被用户发现，即使测试人员采用了单元、接口、自动化、Monkey等诸多手段进行测试，由于受限于测试场景、测试次数等因素，这种情况仍然是无法避免的。
让测试人员在项目早期介入，与开发人员一起评审技术设计，是减少这种情况并从根源上提高产品质量的方法之一。但是需要指出的是，这只是理想化的假设。一是测试工程师缺乏项目经验，测试开发与开发毕竟是两种工作，评审技术设计有一定的难度;二是如果测试工程师有大量的项目经验，很容易与开发人员从同样的角度思考问题，这便偏离了初衷。
由此可见，成为一个优秀的测试工程师并不是一件容易的事情，既需要有专业的技术，又需要能够从技术中抽身，从不同的角度考虑问题;既要有吹毛求疵的完美主义精神，又要能够权衡效率，并对自己的选择所可能产生的风险有所估量。运用之妙存乎一心，这实际上就是大量实践中才能获得的经验了，无法详述。
Notes：
①关于这种说法需要进一步关注Model-based Testing;另，Software Development Life Cycle(SDLC)是一个让人眼花缭乱的概念，务虚，但又十分有用。
②这实际上是采用了自顶向下的设计方法
③测试策略：Traceability Matrix等，待完善
④我希望Test Cases成为一个池子，测试条件放在System Testing Specification文档中来统一归档，该文档中还应当包括测试环境等相关配置。除此之外，如果有Test Procedure，也使用另外的文档用来管理。
⑤测试技术：等价类划分、边界值条件等
⑥敏捷、探索性测试待深入理解
测试用例设计结果分析
软件测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的 “ 测试准备工作 ” 中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别;然后，再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中，每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下一轮测试中避免盲区。
测试用例设计流程相关文章：
1.测试用例流程图
测试用例设计步骤
