测试用例设计方法
一、
Android系统功能测试设计的测试用例：
a.对所测APP划分模块
b.详细列出每个模块的功能点（使用Xmind绘制功能图）
c.使用等价类划分、边界值、场景法等对各功能点编写测试用例（考虑中断功能测试用例）
d.执行测试之后，反思总结补充相关用例
二、
1）根据业务需求文档、业务逻辑文档和流程图 等业务资料，整理测试方案和测试功能点；
2）将测试方案和测试功能点 内容细化，细化成一条条用例，包括页面元素显示、页面功能交互、底层数据交互、接口交互等；
3）针对每一个测试功能点，利用 边界值、等价类、因果图、错误推测法 枚举出每一个功能点的所有测试项，将每一测试项形成一条条测试用例；
4）考虑业务需求文档之外的其它异常情况，形成测试用例；
三、
之前测试TV系统及其集成APP，也很少设计测试用例，用例都是写好的，执行就可以，所以设计测试用例能力比较匮乏。但是自由测试的时候发现的bug数量还不少。
目前设计测试用例，主要是根据需求文档写测试用例。我们这边先进行需求评审，评审的时候可以提出疑问，产品解答，之后测试写用例，期间可以向产品确认需求。测试用例主要分为：
1)功能测试（正常用例、异常用例、参数校验）
用到的设计方法：等价类、边界值、正反法、流程图
2)兼容性
3)容错性：断电、断网、网络切换
4）网络测试：切换有线无线、延迟、丢包等
四、
根据产品给的需求，确定测试模块、功能点；细化测试点，测试极端显示情况
根据数据差异，确定特殊情况的测试
将设计测试用例时没想到，但是实际测试时遇到的问题加入到测试用例中
五、
1、功能点测试用例：主要使用等价类、边界值、因果图进行功能点（输入框、按钮等）用例设计
2、场景分析法：画流程图，根据流程图进行场景测试用例的设计
六、
a.梳理需求规格说明书，首先将说明书里明确写出的需求点梳理出来，然后写成用例。
b.边界值：如遇到文本框，需求里边明确规定范围的，利用边界值设计用例
七、
涉及到一个待测项目，因此只设计过一个项目的测试用例：
根据需求文档和原型，按照页面上的每个操作来一条一条的设计用例，常用的设计测试用例的方法有：边界值、等价类、正交法等
八、
功能性根据需求编写正常值、考虑边界值、异常值用例，根据数据的输入输出涉及用例、数据输出结果多方面验证、其他考虑兼容性、性能（大多数情况不测试性能）
九、
A:流程和功能点分开设计，以流程优先级最高，各种涉及到的正反向流程都详细设计，且数据准备充分；
B:功能点设计时，按模块细分，每个模块的独立功能及交互、UI布局一起整理，一般都按照系统中实际情况先后排序，以便测试方便；
C：用例中包括每次执行结果，不通过时包括输入bug编号及具体bug描述，方便跟踪；
十、
（不同模块的交互）接口跟前端的接口对接业务场景主流程异常场景接口主流程前端主流程前端对接口数据解析，前后空格，为空/null的情况，接口必填字段校验，前端php跟java算法精度统一，弱网访问，接口数据返回失败，前端php跟java数据返回超期时间，种cookie,兼容高低版本，兼容pc跟app功能，不同版本接口数据的影响，新老用户，同步，异步，检查数据库数据灰度发布，缓存机制，正则匹配的情况，页面加载过程中不能操作
十一、
根据策划的执行案写详细的需求分析，一般需求分析的每一行都是一条用例，基本的写完再加入一些自
己能想到的情况
十二、
一般产品会给出REQ，根据REQ，画出流程图，这样就有一个大概的知道影响那几个模块；
根据涉及到的模块，写测试点；
根据测试点，再细化，看REQ要求的字段长度，细到一个按钮的操作，跳转的页面，就要看具体REQ要求了
十三、
1、熟悉产品需求
在编写测试用例前，首先分析产品需求，透彻明白产品功能和业务流程，完全掌握每一个需求点的功能及效果
2、用例编写
首先使用等价类、边界值、正常、异常等方法设计每个模块、每个功能点的测试用例，包括UI界面（对比效果图）、用户权限（不同权限展示的模块不同、操作权限不同）、数据操作（增删除改查等）；再次通过场景法、业务流设计产品业务测试用例，包括正确流、错误流等
十四、
a、本期及往期有关联的软需中的需求点
b、明确本期用例需要的测试方法、测试点的覆盖
c、根据用例在不同公司的实际需求搭用例架构
十五、
后端
1、设计正常流程用例，关注流程的每一步，该记录的状态是否正确记录，该写的库表是否正常写了；整个流程的数据流是不是通畅
2、系统对于异常的容错处理，每一步操作失败，是否正常记录状态与库表；对于错误状态的出现，是否能触发下一步的处理操作
3、大数据量测试：1000条数据同时处理，是否每一条数据都能正确无误
PC前端
1、查询条件（各个下拉框显示正确（is_delete或acitve的过滤条件正常），单个查询条件每个选项查询正确，多个查询条件组合每个选项查询正确；）
2、输入框（长度、特殊字符处理（是否要求只包含一种或以下几种文字：中文、英文大小写、数字、特殊字符））
3、列表显示（分页是否正常显示，大数据量分页是否有性能问题；列表每个字段是否取值正确）
4、菜单、链接、页面跳转是否正常，是否跳到了预期的地方；
5、权限控制，不同的角色和用户，是否跳转到了权限不可访问的地方；前端页面做了拦截，但是后台是否返回了用户不具备权限访问的数据
APP：
1、按钮点击、菜单点击是否正常跳转
2、兼容性测试：不同版本的安卓系统、IOS系统，页面元素是否正常显示
3、权限控制，不同的角色和用户，是否跳转到了权限不可访问的地方；前端页面做了拦截，但是后台是否返回了用户不具备权限访问的数据
十六、
- 可支配的时间
根据可支配的时间决定如何设计如何写、设计以什么方式写。
- 项目类型
根据项目的类型，比如接到一个领导中标项目，这样的用例基本是按照对方（或验收的第三方）给出的固定格式去填内容，这种的用例一般没营养只是应付学生都能写；再比如是自己内部公司的产品的迭代测试，那根据本次的测试内容去灵活设计。
- 用例格式（方式）
测试用例格式（方式）不限定，如果是公司内部的产品的迭代测试，测试用例格式方式不限定，你可以天马行空发挥想象，但是就一个宗旨：我认为能达到测试目的用例就是一个好的测试设计。写的很规整但是覆盖不全、用例重复也不是好的测试设计。
- 用例框架
用例的作用是给测试过程提供服务的，假如你的用例覆盖的很全、也没有重复用例、也很规整，但是你的框架设计的不好，实际测试的时候测试时间发生了变化，你需要在很短的时间提炼出最需要测试的内容，这时就体现出框架的重要性。
- 特殊情况（适合老司机）
临时得到领导通知没时间设计测试用例怎么办？此时需要发挥你老司机的看家本领，凭借你多年的测试经验和对产品的熟悉程度再加上你对bug的敏感度，在脑子里自动创建探索式测试用例。
十七、
根据需求文档编写测试用例，一般后台的那些增删改查之类就用常说的那些边界值法、等价类法写；
涉及到逻辑，关联的就会串到一块，按照逻辑思路整个写下来
十八、
单纯的从功能角度来说，直接把主要的功能点写在用例模板里面即可，把要测试的点所有想到的都写出来或者部分也行，在实际测试功能时候，把没有想到的点在补充上，设计用例时有时候会用到等价类、边界值、错误猜测的法穿插到设计用例的思路里面
十九、
一般是先分析需求，再结合测试用例的设计方法，例如等价类、边界值等设计测试用例，有时候也会根据以往的测试中遇到的情况设计测试用例。
二十、
1、需求了解，通过过对需求的了解，写一个对本次测试功能点理解的文档，再对需求分析人员、测试、开发宣讲自己对需求的解读
2、逻辑复杂时，用思维导图列出功能点对应的正常场景异常场景组合场景
3、通过用例模板来写用例的输入输出
4、用例评审
二十一、
我这里是用思维导图当作测试用例的测试的。
组内分配任务后：
1）找文档：先整理下目前能拿到哪些产品文档、技术文档，要到产品原型、交互原型、接口文档。整理放一个目录或收藏夹下，便于查找。
2）梳理功能点及涉及页面：新建一个思维导图，一边看原型一遍写导图，记录原型里的每个功能：为啥做（目的）？涉及几个页面？每个功能总共能做哪几件事？然后再随手记一些想到的测试点（交互、流程等）。
3）找产品答疑：上一步梳理完功能点，可能会找到一些不明白的地方，或者产品没考虑到的地方，然后再补充下。
4）转换为测试点：考虑下之后测试时的顺序，将功能点转化为测试点，保证功能提测后，自己能按照导图测试，避免导图的不实用。
5）组内评审：讲述自己的负责的功能是怎么一回事，给别人说明白了。然后讲一下自己都考虑哪些方面、怎么测的（交互、边界值、流程等），然后相互讨论下，看看哪里有没有漏的。
6）评审后调整补充测试导图，然后设计测试数据（等价类／边界值），再准备测试数据。
二十二、
l 根据需求文档，确保覆盖所有本期功能点；
l 场景：根据用户使用的所有相关场景，设计用例；
l 等价类：
l 边界值：（分别设计等于边界值，小于边界值， 大于边界值时）；
l 流程图：根据程序判断分支，设计不同前提条件下的实现结果；
l 正常值 & 异常值。
二十三、
通常使用等价类边界值，场景法，因果图，随机正则，根据产品需求使用以上方法进行测试用例的设计
二十四、
（1）编写接口用例时用到等价类划分和边界值的方法。
例：编写"创建会员"测试用例时，会员id使用等价类划分的方法，找出有效等价类和无效等价类，分别作为请求成功和请求失败的条件；会员id最长限制为11个数字，使用边界值划分的设置2到3个边界值点编写测试用例；
（2）采用因果图的方法，查看那些那些输入会产生那些结果；
例：创建不同的规格的广告，输出不同的样式及内容；
（3）根据测试被测系统所积累的经验，使用错误猜测和随机测试来补充用例；
（4）根据tapd中的描述，有针对性的创建测试用例；
二十五、
（1）拿到需求后，先分析需求，确定测试范围，明确测试任务；
（2）列出所有功能点和交易流程；
（3）根据列好的功能点设计用例，如边界值分析/等价类划分等方法；根据列出的交易流程发散出分支流程和异常流程场景
二十六、
我在工作中通常是拿到需求文档后，与产品经理沟通，在充分理解需求的基础上开始编写测试用例：
（1）划分功能模块，编写基本功能测试用例
（2）划分流程，画流程图，整理成场景用例
（3）整理平台间及平台内功能模块之间的数据关联，编写联调测试用例。
设计测试用例中用到的方法：
（1）正常功能流程测试用例
（2）异常功能流程测试用例
二十七、
1. 等价类输入条件：有效等价类、无效等价类
2. 功能路径混合分析：比如一个功能，存在多个入口，每个入口携带参数以及跳转
3. 边界值：存在输入的，确定范围的
4. 错误猜测：空值提交，重复操作，负值，特殊字符，html代码等
5. 并行：被打断后重新回到被测软件，锁屏、后台等重新唤醒
二十八、
1) 理解对应的需求,根据需求设计测试用例; 2)会对边界地方设计一些测试用例
二十九、
主要以个的
1.络情况
2G,3G,4G,WIFI
2.适配情况 Android iOS
特别说下
Android 对于些控件的处理，在低的系统版本是不兼容的。rd经常会犯的错
误。
3.根据业务的功能模块图，延伸到涉及此次改动，影响的其他功能的功能点。
如，订单的改动，肯定会要增加收和客户
CRM的case。如上词条，增加个点：就
是要熟练的了解业务，个功能的改动，如果不熟练了解业务的话，那想到的点，肯定只
只限制于这个需求。
4.涉及case的法
错误猜测法
看到个需求后，应该先想，怎么能才出错。
边界值法
常谈，取最值，最值，中间值
5.性能测试
主要涉及些切换和拉取的操作的时候
可以写个脚本，切换
tab，50次，查看内存
拉取，
50次，查看内存
6.压测试
主要测试接的压，因为不是我这边做，不是很清楚具体实现，主要是测试接并发的
时候，看返回错误率。
付适配关注点：
Android适配关注点，踩坑数，共勉。
tip：如果公司接第三数据统计后台（友盟，腾讯MNT），看下top10的机型，重点
关注适配。
1.分辨率适配
480*800，
2.商机型适配
华为，
oppo，vivo，锤，
3.特殊ROM适配
MIUI, ColorOS，ymeOS，SmartisanOS，google亲
4.针对CPU架构适配
X86 机，和普通的android机
5.系统版本
4.0 4.3 4.4 5.X 6.X 7.X 8.X
这边说下，
4.X以下的版本需要兼容4.0.X和4.3.X和4.4.X 因为各个版本需求很。
ios 适配
iOS 8 iOS 9 iOS 10
三十、
1、需要了解需求。需求的来源最主要的是产品PRD（包括页面展示、跳转等说明）和开发的设计文档（修改内容的主要逻辑、修改内容的影响点、新老数据兼容、缓存处理、风险点、发布顺序等）。只有了解需求才能全面考虑怎么做到覆盖全面，不漏测。
2、需要选好用例模板。选择适合自己项目的用例模板很关键，因为用例是需要评审的，需要自己给别人展示并讲解的。个人推荐用脑图，用excel表不是很容易展示自己的逻辑。
3、用例要素。
预制条件，说清楚该条用例执行的前置条件。
用例分层，核心的几个要素从一级模块->二级模块->。。。->具体的某个功能点，清晰的分层能很明白交代自己测试的逻辑，让自己和他人明白该模块是否完成全部覆盖。
预期结果，指出该条用例执行应该得到的结果。
4、用例的设计方法。目前接触的到有等价类、边界值和正交分解法。正确的使用设计方法也是体现覆盖率的良好途径。
三十一、
1.熟悉清楚系统业务及需求，这样才能编写出高效的测试用例；
2.根据公司测试用例编写规范、模版编写测试用例；
3.测试用例编写思路清晰，要有顺序、优先级、逻辑性；
4.根据项目类型、特性、情况分析出系统核心、重点部分，保证这部分用例的高覆盖率，剩余部分用例如果项目时间紧急可写粗点；
5.测试过程中对系统测试用例进行维护；
三十二、
无
三十三、
我目前的公司做的是云平台项目，公司中没有任何需求文档，需求一般是经理或市场反馈，需要加一个功能，然后参考其它同行产品，UI进行设计，前端依据图稿做页面，JAVA写代码方法，测试依据展现的功能进行测试。最初为了快速熟悉业务，按展现的功能及使用流程，设计了一遍测试用例，但基本上未按测试用例执行。平台里就是一套系统，不停的加入新功能。测试元素中，输入情况也不多，偶尔我也会用不同的电脑系统、浏览器做兼容测试。常规的测试就是输入、流程分析、边界测试。