看了很多文章，在测试过程中，我们如何可以使我们的用例更加完善呢，以前上学的时候就说几个大的方面，设计测试用例的时候要从功能性，兼容性，易用性，可靠性，性能，安全方面去设计用例
但是在实际的测试过程中，你会发现，这些面真的是太广了，也太大了，不知道该如何下手，今天咱们就来说一说，具体从哪些方面考虑可以使我们的测试用例设计的更完善些呢。
（尽量我们在测试开始之前能够让开发进行codediff测试，他的目的是：明确改动范围，补充测试范围，一般这个流程也是要贯穿整个测试流程的。）
一， 测试用例的模块设计，其实就是：测试模块的划分，我们通常都会把测试项目分化成几个模块来单独编写用例，常用的经典方法是瀑布模型，从上到下，逐渐细分，大模块包括小模块，小模块甚至包括更小的模块，另外还要从不同的角度把系统化成一块一块来进行测试，从而确保大项的完整性。说到这个不同角度指的就是，第一我们要注意需求里面明确标注的功能，第二要注意跟此次功能相关的模块有哪些，要考虑到该功能与其他功能的关联性，往往第二个是我们最容易忽略的，这个方面要求你必须对业务很熟悉才能想到。除了上面的具体有以下方面需要注意
后台功能：
常见的如一些定时任务的服务，这些定时任务在界面上是体现不出来的，需要测试人员根据对项目的了解程度进行挖掘。完整的业务流程测试
我们都知道测试用例的设计是从点、线、面三个层次去考虑的。完整的一个功能项是线，其中的某个按钮是点，多个相关功能结合成完整业务流就是面。从实际来看这类用例往往被我们忽略。事实上目前公司的软件本来都是业务型应用软件，将各种功能从业务流中切割出来单独写用例，肯定也会有涉及到整体流程的情况。若不加以区分，将细节与全局 搅在一起，不仅思路混乱，也容易考虑不周。因此在系统测试阶段，建议用例设计要有分有合，针对具体功能的就只围着这个功能转：而在业务流程测试项中，再完 全从整体的业务流角度出发去考虑用例，这样不仅不容易产生疏漏，用例阅读与执行也更清楚。某种特定情况下系统的运行
这类用例的设计往往与系统实际业务情况密不可分。比如一些app应用是否可以在不同手机的操作系统上面能运行自如；再有如存在大量动态图片视频等的网页，在普通网速下的展现速度等等。总之就是要尽可能从实际应用的角度出发考虑，来进行测试补充。除功能测试外其他的测试类型
包括可靠性、安全性、恢复性、配置安装测试等等，这些测试类型都是一个单独的测试项。
二、详细的用例设计划分好了测试项，接着就是针对各个测试项，考虑具体的测试用例了。根据测试项的特点，测试用例的设计角度也有所不同。下面我们就来看看通常的功能点测试用例，该从哪些角度出发来进行设计：
1、功能切面表面用例设计
（1）、具体功能测试
根据需求分析设计，按页面提供的各个功能项，采用黑盒测试的各种方法，设计常用的用例，这个相信大家都没有问题
（2）、组合操作的测试
设计完初版用例之后，一般来说我们会考虑功能项之间的数据是否会存在关联，若有就需要考虑这种组合了，正向的组合以及逆向的组合
（3）、GUI界面的测试
这个属于UI类型的测试，根据需求文档查看界面是否符合要求，在这里我们要考虑一点就是要站在用户的角度上看一下此操作的方便性。
（4）、数据初始化情况测试
不该为空的数据是否有校验；该有默认值的数据默认值是否正确；引用其它功能生成的数据，是否会实时刷新；页面关闭或系统重启后，数据的初始化设置等都是这类用例。
（5）、业务需求实现是否正确
这类问题往往是由于我们的需求说明欠详细，而编码人员的需求了解程度又较低造成。作为测试人员自然要对需求进行深刻研究，来对软件实现进行把关。这里常见的一些关注点有：
●数据的长度、类型控制是否合理（比如控制纳税人识别号只能为数字，但实际业务中是会有字母出现的）；
●业务逻辑控制是否合理（比如某数据项不提供修改，但实际业务中该数据项经常会需要改动）；
●提供的实现方式是否合理（比如只在某一页面提供某数据的获取功能，但根据业务划分有些人员不能操作此页面，却必须要能看到该数据）；
●所做的数据控制是否合理（比如必须在A功能中新增数据，然后才能在B功能中操作，但实际业务中有可能会出现相反操作）；
●所做的数据控制是否完整（如授权的方式有普通按月、有买断、有按数量控制，那么当同一企业尝试同时存在以上几种授权方式时，系统是否能有必要的控制）；
●还有其它一些操作细节上的满足（如业务上需要批量操作的数据有否提供批量操作功能、导入失败的结果文件是否能修改后直接再导入等）。
对于不满足的需求，经开发组长、需求经理等确认不作修改的，就要作为软件的缺限或限制在测试报告中进行说明民。
2、功能隐含测试项用例设计：
（1）、数据完整性的测试
数据完整性的测试表示当某一数据被其他的功能所共同引用时，修改其中某一块功能，要考虑其他模块是否正常运行
（2）、功能业务之间的关联与转换
相关联的几个功能之间数据的传递，是否会产生影响。比如新增录入的某种特殊字符，要查询时会引起查询SQL语句异常；相关联的模块是否会发生异常，通常只能是在每个功能设计 用例时，尽量保证用例中的数据能涉及到允许范围的各种情况，即充分运用等价类划分+边界值的方法设计出各种“稀奇古怪”的数据，并需验证这些数据从头流到 尾，都还是能保持其正确性，而不仅仅是在当前功能中正确。
（3）、并发操作时的测试
即两个或多个用户同时操作同一功能时，会否引起数据的混乱
（4）、与业务流相关的测试
这类测试用例的设计，就要从完整业务角度来设计数据了。从理论上来讲，应该要将各个功能可能出现的各种数据排列组合到一起，按业务流程逐一进行 测试。但实际上我们不可能去做全覆盖。所以设计这类用例时，最好有一张草稿，将所有相关功能按业务流程逐一列示，然后再将每个功能可能出现的特定数据一一 标上，最后将图中最可能出现的、最可能出错的、最核心的数据取出来，分别组合成一个个完整的业务数据用例，来进行测试。这样就可以按清晰的思路，找出最实 用、最有效的测试数据。
（5）、其它测试类型
这一类的测试通常都有其特定的方法。如要测可靠性就准备大量数据不停地执行；要测安全性就考虑数据的加密、数据的传输、数据的破坏；恢复性一般 从网络、电源方面着手；配置安装则根据系统可支持的配置，搭建相应环境进行功能验证，此处的验证也要掌握技巧，即要多测试那些涉及到：数据库读写、磁盘文 件读写、文件上传下载、文件加解密、数据统计、图表展现、打印等方面的功能。
至些，看了很多文章，结合自己的经验，写了一些总结，希望可以在测试过程中对用例的覆盖度有所帮助。因为具体项目中的具体情况太多，以上叙述的内容也只是个人观点。至于其中的疏漏错误之处应也难免，只希望各位阅后能打开思路，从自己多年的测试经验中多总结、提炼出一些想法思路，进一步补充完善这个文档，使大家的测试用例设计能力都能进一步提升。
