测试设计套路
1.测试流程设计
软件事件促发控制流程，事情促发形成情况为场景，事件场景促发顺序和处理结果形成事件流
2.场景设计
业务流程事件复杂程序，测试怎么能尽可能发现bug，站在用户角度去使用软件，用用户的使用逻辑去设计测试用例
总结:
1.对于做什么要非常清楚，深入了解需求解决什么
2.站在用户角度怎么使用它，遇到情况，限制条件，怎么解决遇到的困难
3.结合同类市场已经实现的产品，自己分析设计产品，并对其功能、可靠性、性能分析，站在用户角度考量自己设计的测试用例
4.评估测试用例是否过关及缺陷分析
测试用例设计思路
1.关注用户及如何使用
2.关注系统周边的依赖及交付，理解系统逻辑架构及熟悉业务流程
3.子系统的接口分析及业务各个系统与子系统直接交互，因子和因子分析，模块之间的关系，覆盖程度
应用场景分析（四W一H)
why:需求为什么设计，它的价值与竞争力
who:什么用户，什么类型用户，是否多用户同时使用，用户规模
when:用户什么时候使用，使用频率
what:促发用户使用使用因素
how:一个产品发布前交付过程，发布前需要具备的资源信息环境，出现问题点的处理结果
测试分析
功能测试，子功能区分的原则，这些子功能的交互因子，交互因子包含因子提取与分析，用户场景数据流流程
可靠性测试
1.配置文件是否会复发
2.需求模块考虑故障管理
性能测试
1.空间维度:需要什么资源，资源能否承受
2.时间维度:跑系统需要多久
用户体验重要性
1.界面应用型
2.响应时间
3.交互信息可用性
测试评估
1.功能性
2.可靠性
3.应用性
4.兼容性
5.维护性
6.性能指标
7.安全性（自己添加的）
缺陷分析
有效性，测试设计是否完美，测试缺陷是否提现在测试用例中
测试参与需求评审
测试有必要参与需求
测试用例
1.预置条件
2.执行步骤
3.预期结果
4.测试结果
ps:测试用例并不是写的越多越好，保证产品质量才是根本
外加举例详细说明
以上是Amy分享
下面我说说我自己的思路:（大体流程）
1.熟悉需求，参考原型图，大概设计自己测试用例大纲（记录疑问点）
2.跟内部同事沟通需求疑问点
3.参加需求评审重点提出沟通过后的疑问点
4.整理需求，理清思路，编写测试用例初稿
5.测试内部用例评审，整理总结完成测试用例
6.时间充裕，就二次用例评审（目的听取大家的建议，每个测试人的思路都不一样）
7.产品开发结束开始测试
了了分享总结一下吧:态度决定一切
给自己定位，自己想要什么？还有坚持学习，学多少不是问题，问题是学习的态度，你有没有想学，理由千万总，想学态度拿出来。都辛苦，你不学习落后的是你自己。被遗忘的也是你自己。每天学一点，一个月下来一些，一年下来一部分，三年下来就很多了！时间有限，不知不觉你已经被拉后了！
好吧(∩_∩)就这些吧！纯手机敲打，我大概检查了一下，困死了，睡了，晚安！欢迎指出错别字。
网友评论