测试用例设计总结：
测试用例
测试用例是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。需要把把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。
二．测试用例的设置
1．按功能测试是最简捷的，按用例规约遍历测试每一功能。
2．路径分析是一个很好的方法，对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。其最大的优点是在于可以避免漏测试。
三．设计测试用例方法
测试用例可以分为基本事件、备选事件和异常事件。
1．基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。从需求和设计中所有基本实现的功能覆盖。用于证明该需求已经满足，通常称作正面测试用例。
2．设计备选事件和异常事件的用例，则要复杂和困难得多。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。
四．测试常用的基本方法
等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。
步骤1：首先使被测单元运行（模块设计导出的测试，对等区间划分），如果这个都有问题，可以直接把版本打回去
步骤2：正面测试(PositiveTesting) 正面测试的测试用例用于验证被测单元能够执行应该完成的工作。测试设计者应该查阅相关的设计说明；每个测试用例应该测试模块设计说明中一项或多项陈述。如果涉及多个设计说明，最好使测试用例的序列对应一个模块单元的主设计说明。（设计说明导出的测试，对等区间划分，状态转换测试）
步骤3：负面测试(Negative Testing)负面测试用于验证软件不执行其不应该完成的工作。这一步骤主要依赖于错误猜测，需要依靠测试设计者的经验判断可能出现问题的位置。（错误猜测，边界值分析，内部边界值测试，状态转换测试）
步骤4：设计需求中其它测试特性用例设计,如果需要，应该针对性能、余量、安全需要、保密需求等设计测试用例。
步骤5：执行测试用例
五．测试用例的实施
1．在实施测试时测试用例作为测试的标准，但测试人员可以在实施过程中添加其他有效的测试用例。并对测试情况记录在测试用例管理软件（TD）中，以便自动生成测试结果文档。
2．测试数据和测试用例是分离的，除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。
3．测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。
六．测试用例设计及执行经验总结
1．通常应该避免依赖先前测试用例的输出。虽然会多花点时间，但是有价值的
2．测试用例设计过程中，包括作为试验执行这些测试用例时，常常可以在软件构建前
就发现BUG。还有可能在测试设计阶段比测试执行阶段发现更多的BUG。
3．执行用例的时候，正面测试用例测试出BUG，负面测试用例也会有相同的问题，但测试点并不是这个，可以考虑下轮测试执行，做到有效测试用例全覆盖又最有效率
4．定义测试用例的执行顺序
在测试用例执行过程中，你会发现每个测试用例都对测试环境有特殊的要求，或者对测试环境有特殊的影响。因此，定义测试用例的执行顺序，对测试的执行效率影响非常大。比如某些异常测试用例会导致服务器频繁重新启动，服务器的每次重新启动都会消耗大量的时间，导致这部分测试用例执行也消耗很多的时间。那么在编排测试用例执行顺序的时候，应该考虑把这部分测试用例放在最后执行，如果在测试进度很紧张的情况下，如果优先执行这部分消耗时间的异常测试用例，
七．黑盒测试方法
1．对等区间划分
对等区间划分是测试用例设计的非常形式化的方法。它将被测软件的输入输出划分成一
些区间，被测软件对一个特定区间的任何值都是等价的。
2．边界值分析
边界值分析使用对等区间划分相同的分析。但是，边界值分析假定错误最有可能出现在
区间之间的边界。边界值分析将一定程度的负面测试加入到测试设计中，期望错误会在区间
边界发生，对边界值的两边都需设计测试用例。
3．错误猜测
错误猜测大多基于经验，需要从边界值分析等其他技术获得帮助。这种技术猜测特定软件类型可能发生的错误类型，并且设计测试用例查出这些错误。
八．搭建测试环境以及用例执行过程中遇到的问题
1．搭建测试环境
测试用例执行过程中，搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软硬件环境，如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。 可以形成自己的安装说明文档。
2．可测试性
如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。
3。发现bug时
及时确认发现的问题： 测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重新问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。
4。及时更新测试用例
测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。 总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。
5．提交一份优秀的问题报告单
软件测试提交的问题报告单和测试日报一样，都是软件测试人员的工作输出，是测试人员绩效的集中体现。因此，提交一份优秀的问题报告单是很重要的。软件测试报告单最关键的域就是 “ 问题描述 ” ，这是开发人员重现问题，定位问题的依据。问题描述应该包括以下几部分内容：软件配置、硬件配置、测试用例输入、操作步骤、输出、当时输出设备的相关输出信息和相关的日志等。

九．实际工作测试用例设计
1．KC客户端
主模块分解：登陆，注册，通讯录，IM，邮件，个人设置等等
单个大模块再次分解：登陆流程（客户端，CS，注册系统，短信，权限，voip），每个系统模块完成它自己的任务，但是测试刚入门，怎么实现以及怎么测，怎么查看数据在后来比较长的时间内才越来越清晰，测试用例也越来越有效。这是测试范围
技术基础：windows软件基础（内存，cpu，数据保存等）
2．注册系统
主模块分解：有许多种注册方式，每种注册方式的流程都有不同的地方，依赖的其他的模块也不相同，命令字也不同，所以可以再分解，开发人员会输出设计流程图（从网站到注册系统，到第三方系统验证，短信系统，数据库，权限系统，返回结果）
每个流程也会有很多步骤，每个步骤都会有各种不同的环境条件输入输出情况，每个步骤都有它的实现方式，日志记录，数据库修改，数据输出，在流程中有很多业余规则（每种注册方式分配号码规格会不同，多少天不能重复注册等等）和设计规则（同一IP注册有时间限制，手机验证码最多发多少次等等），这些都是功能点，每个功能点可以设计出几个测试用例（正面的，负面的，边界的），负面的用例基本上会用到错误码。2个功能点存在某种关联性，可以设计出组合操作的用例出来进行测试。
因为时间关系，可以直接测试整体流程，无法测试到的情况，用CT（开发人员开发的一个测试接口工具）来测试单个的模块，或者客户端还没出来，可以先测试命令字
测试计划－>模块分解－>根据需求和设计文档设计测试用例－>执行测试（需要观测的东西很多，可以在用例中写出数据库脚本，观察点）－>发现BUG，并确定是BUG－>补充测试用例－>第二次版本测试－>发现BUG，并确定是BUG－>回归测试－>验证测试
版本修改的测试：数据库表修改－>考虑影响到的范围有多少，然后测试多少，数据库表结构修改脚本也要测试，一方面了解脚本是否有问题，一方面了解上线时会花费多少时间。
                业务流程修改－>连模块都修改了，测试用例可以再利用，修改相应的流程，观察的点
                某些规则修改－>将旧的相关用例挖掘出来，更新并执行测试，并考虑到相关的功能点
                最后一步，还是验证测试，跑完基本测试用例
版本功能的增加：增加新功能点的测试用例并执行，是否影响到其他功能？需要测试
3．CS系统
当时测的是更新版本，添加和修改了一些功能
同上，修改了哪些新增了哪些，功能点设计出用例，执行并观测过程和数据
4．网站系统
有4个工程：mykc,client,reg,card
有2个web服务器：apache,tomcat
环境：1个客户端（IE6.0），1个网络（内网），1个测试服务器（22）
每个工程完成它自己的需求功能
网站可分为静态和动态页面，静态页面有apache服务，目录为keepc。动态页面有tomcat服务，目录为4个工程。动态页面中的图片为keepc目录里的，同样需要这个目录。

5．广告系统，邮件奖励系统