from https://testerhome.com/topics/4664
电影票促销
有一个移动app 电影票，现有个活动，
能以20%的价格买入1000张电影票，每人限购1张，
作为测试负责人如何设计这个测试。
我说是测试功能性，用户体验，以及重点测试并发，比如2000个并发测试，看系统有问题。面试官说我不了解app测试，不知道是不是测试重点搞错了
A1
功能性(边界条件)：Functionality (boundary condition)
- 0：电影票：
电影票是某一部电影，还是所有在售电影；选座是否正常；已售座位的信息更新是否及时；电影的相关信息是否正确
- 1：检查是否以实际价格的20%购入
20%的价格：购买方式（网银、支付宝、微信）是否正常；可能存在的安全漏洞；折扣是怎么计算的，数据库需要传哪些参数；退款时退款数额是否正确；购买时提交异常数据能否正常处理
- 2：检查是否每个人限制为1张，如果一个人买2张的话是否可以通过验证
限购：根据什么信息限购，eg手机号、app账号…；重复购买能否成功；买了后退款重新买是否正常;如果有允许等待30min内付款，那第一张不付款，购买第二张会怎么样…；能否通过抓包修改参数购买多张
- 3：检查上限1000张全部售出验证是否还可以继续购买
1000张：1000张的等价类划分；如何处理并行，N个人同时付款一张票；如果有允许等待30min内付款，那等待付款时这张票能否允许其他人付款；退款的票能否重新购买
4：因为是移动APP的一个活动，应该是Ｈ５的页面，需要要考虑该方面的检查(WKView)
- ①：前端是否可以实时刷新
- ②：前端提示是否友好，例如：“提示一个用户只可以购买一张”或“已全部售罄”等等
- ③：既然是活动，考虑活动时间范围检查。
5： consideration, 票价、票数、订单支付、取消、未支付、活动有效期等
兼容性：Compatibility
１：在不同设备，不同系统，不同系统版本该“活动”的兼容性检查
性能：Performance
１：考虑并发，高峰等测试（性能不熟悉）等等把
实际上服务端的性能需求是没给的，1000个是业务上的需求，因为是不同帐号，所以客户端的自动化脚本来实现比较麻烦，要不断切换帐号，比较好的方式是写接口测试脚本，然后参数化帐号消息。至于服务端的性能，要问清楚具体需求，一天有多少活跃用户，然后来计算并发量，设计服务端性能测试方案。
２：加载Ｈ５页面的时间。
可靠性检查 Reliability
１：模拟ｍｏｎｋｅｙ测试１００００次检查活动页面的可靠性
服务器端检查 Sever side check
１：活动相关接口性能，接口的响应时间，平均时间等等
2：检查前端提交的表单数据，数据方面的检查（具体没做过，不太清楚，但是我想应该考虑下数据方面）
专项测试：Special Test
１：System cost 该活动界面的CPU,GPU，耗电量，流量消耗检查等等
２：Networking condition 弱网络，不同网络wifi,3G ,4G 浏览的情况
3： No Networking 断网情况下的检查
4：Double click submit button 提交按钮双击检查。
*5：Data interpolate for HTTP 最好做下fiddler的抓包，篡改数据后重新发包，看后端的处理。
体验检查：Experience Test
因为是一个电影app的售票活动，用户应该基本是青年
- 界面的交互是否简单，simple UI interaction
- 提示是否友好，friendly notification
- 界面设计是否美观大方等等, UI is beautiful
A2
Monkey comment：
- 首先就如过现场真的是这个问题的话，按照我的原则，就是要先问清楚。如过我是测试的leader，那么我有多少人，分别是什么水平。然后我再去进行相关的测试设计，否则一切都是扯淡。
- 一个app，电影票。那么这个实现是怎么实现的，架构怎么样的？这个如果对方不说，我就拒绝回答这个问题。比如选座位是不是H5的，然后其他是不是native的，等等。
- 那么接下来就是分析3个点了。一个就是产品特性，就是业务特性。一个就是移动端的特性，因为毕竟是app。一个就是技术特性，比如什么是手工去做，什么是自动化去做，怎么做。
产品特性
关键字：电影票、活动、20%、1000张、每个人限购一张
好，那么接下来就从业务来分析这个特性。（虽然我没有测试过，我就是YY）
- 电影票有选电影院，选座，选场次，选地区等等，那么这个其中的等价类，边界值都是需要去考虑的。场景我们可以认为从PRD中都可以获取
- 活动，既然是一个活动，那么肯定是一个hybrid的应用，但是至于哪些webview，这个我之前也说了，一定要去问清楚。那么活动本身包括怎么上线，怎么下线，是否有提示等等，就是动态相关的一些功能点也是需要去测的
- 20%：多少价格的20%？整数？小数？就是数字上的工作了
- 1000张：的确这个就是所谓的压测了。那么我们就需要从性能测试角度来做测试了。肯定不可能是手工测试，而且压测的目标是服务器
- 每个人：ok，这其实是个很重要的点。我们怎么来定义每个人。app可能有独立的账户体系，也可能是第三方登录系体系。也可能两种并存，但是无论哪种，是否能够保证我们的应用可以识别每个人是不是就是同一个人呢？这个问题很值得去思考
1张：ok，那么每个人一张。活动的确是一张。那么我们从几个方面来考虑。比如混合去买活动＋非活动的票？比如买了退票，再买？比如我看完了，用完了，再买？
移动端特性
- 这就太多了，比如功能可以和移动端的本身的特性，比如home，menu，电话呼叫，闹钟等各种功能结合
- 比如上面这些情况在弱网下是不是会出现不可预料的bug？
- 那么app本身hybrid的性能也是去测试的，可以详细见社区的专项测试
- 那么还有安全呢？注入？数据篡改？数据敏感？等等
可能还有很多
测试类型
考虑哪些走Appium？走uiautomator？走压测，走手工等等。其实主要就是上面这些理清楚了，之后就很好定义了。
我个人碰见这种问题，其实很不爽，因为除非对方有本事给我说明清楚这些，否则不回答，回答了也是没有意义的。不过自己可以主动问，毕竟对方回答不出是对方的问题，你不问就是你的问题了