测试用例的设计步骤.doc

《测试用例的设计步骤.doc》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、系统测试之功能测试：测试用例的设计步骤——从登陆开始说起一个完整的softwaretestinglifecycle包括诸多内容，本文仅从测试用例的编写开始，聊聊测试用例编写的一般步骤，以使编写的测试用例最大程度上满足完备的要求，而又不产生重复而冗余的负担。　　测试用例的来源是产品需求，如果足够幸运，我们应当有一份不错的可依赖的UseCase文档，但大部分情况下，UseCase恐怕是不存在，能有一份不错的PRD文档和原型设计图已经是不错的待遇了，如果可能的话，最好还能够有HLD文档，这些已经足够我们开始写详细的测试用例文档（

2、我相信在这之前无法产出详细的测试用例文档①）。也许LLD文档产生之后或者产品的第一个版本发布之后，我们会不断的更新已有的测试用例，但那将是不断的迭代过程，暂不做讨论。　　首先让我们先从理论上了解测试用例编写的一般步骤②：　　1、确定测试套件（Test Suite）：测试套件是功能上的划分，是相似测试场景的组合，而非技术划分。如果技术设计中各模块耦合度较高（强烈推荐解耦，哪怕复制粘贴代码），可能功能上不相干的模块由于代码重用的原因会在bugfix时互相引致错误，实际上回归测试即是为了避免这种情况。但是我们在做功能测试划分模块

3、时，还是要从用户的角度出发，按照用户场景划分测试的“模块”。值得庆幸的是，相似或相关的功能总是倾向于在同一组页面出现，按钮和输入框、选择菜单等内容并不是随机组合的一堆零件。　　2、针对每一个测试套件，确定一个或多个基本流程（basicflow）和可选流程（alternativeflow），即测试场景（TestScenario）：可以借助scenariomatrix来清晰地对可能出现的场景进行排列组合。值得注意的是，一方面UseCase或PRD文档中的描述很有可能并没有完整的写尽所有的场景，测试人员尽可能地挖掘测试场景，既有

4、可能是出于测试本身的需要，也可能是基于开发团队的工作；另一方面，在复杂系统中，测试场景不可能覆盖所有可能的场景，这便需要测试人员采用一定的测试策略③，对SUT（SystemunderTesting）进行“足够（adequate）”的测试，而不是完全的测试。　　3、针对每一个测试场景，确定一到多个测试用例（TestCase）：仍然可以借助matrix来清晰地规划测试用例，每一个测试用例都有其对应的预置条件④、输入和期望结果。测试用例分为PositiveTestCase和NegativeTestCase两种，分别用来测试产品是

5、否完成应当完成的工作和不执行不应当完成的操作。更详尽地说，测试用例一般包括以下列column：用例编号/测试场景/用例描述/需求对应/用例分类（Positive/Negative）/用例类型/用例级别/是否自动化/预置条件/测试步骤/测试数据/预期结果/实际结果/备注/　　4、增加测试数据（TestData）完成测试用例：测试数据是测试用例中很重要的内容，一个用例可能对应多套测试数据，测试工程师根据某种测试技术⑤，将尽可能的设计较少的测试数据完成“足够”的测试。　　任何规范、流程都是为了让工作更加可靠，对于项目工程，天外飞

6、仙灵机一动应当放在合适的位置，而不应当成为规范和流程的反例存在⑥。　　现在让我们开始从登陆（PC端网页，如果是PC客户端比如QQ或手机客户端则又不同）开始说起。　　不打开任何网站的登陆框，想象一下登陆框的样子。　　然后对照一下本文最后的附图，一个优秀的登陆框除了基本的用户名/密码输入框、登陆按钮之外、（不考虑注册、找回密码、第三方登陆、登陆版本、帮助），包含的内容有：输入框文字提示/免登陆选项/输入的表单提示（新浪微博）/必要的验证码（出错时的处理）/用户名和密码输入错误（正确）提示/焦点反馈/快速删除已输入字符/Tab切

7、换/鼠标点击有字符输入框光标位置/Enter键选中/密码非明文显示/是否弹窗显示（不要打断正在处理的任务）/页面跳转/进度反馈（网络较差的情况）/多账户登录/多终端登录/Cookie/token　　最后值得强调的是，真正能够保证产品质量的是开发人员而不是测试。在一个完整的软件工程周期中，开发人员从建设的角度保证产品质量，测试人员从破坏的角度检验产品质量。如果在测试用例执行环节提交了成百上千的bug，即便最终每个bug都被修复，新产生的bug数量一直在收敛，这样的软件产品恐怕也不是让人有足够信心发布出去的产品。实际上，从经验

8、来看，总是有大量的bug被用户发现，即使测试人员采用了单元、接口、自动化、Monkey等诸多手段进行测试，由于受限于测试场景、测试次数等因素，这种情况仍然是无法避免的。　　让测试人员在项目早期介入，与开发人员一起评审技术设计，是减少这种情况并从根源上提高产品质量的方法之一。但是需要指出的是，这只是理想化