APP 连续签到功能应该怎么测试？
回答·8
最热
最新
- 关注点 1.正常的连续签到 2.异常的断签 3.定位断签日期 4.当前日期未签到，不属于断签 5.月初月末的连续性是否能正常判断 6.年头年尾的连续性是否能正常判断 7.2 月的月尾和 3 月份的月初的连续性是否能正常判断 8.扩展：补签 9.ui 展示签到/未签到标识 10.签到动作只能标识在 t、t-n（补签），不允许签到未来的时间 11.签到动作只能生效一次
- 1.看签到逻辑（业务代码逻辑） 2.看达成触发条件（比如 7 天内完成打卡 7 次，记录在数据库） 3.mock 触发条件（数据库添加近 7 天记录） 4.看签到完成结果（查看结果）
- 连续签到看情况分很多：签到后只做记录的，签到后有奖励的，还有其他一些以签到为触发和支撑搞特殊需求的。 纯签到的话相对简单一些，签到触发、记录、签到限制期内重复签、签到有效期界限等等。尤其要注意跨周、跨月、跨年等特殊时间和场景。一般签到都是接口触发，所以依据接口测试的情况，最好进行下性能相关和压测。其他的数据入缓存、数据入库等也要注意，尤其是敏感信息，最好检查下是否加密。 特殊需求或者发奖励的话，要根据业务来进行确认。没有一成不变的通用测试方法，只能根据具体需求制定测试计划，设计场景。
- 1、正常情况下，用户每天签到一次，签到天数逐日递增，连续签到天数正确累加。 2、用户中途断签，再次签到时，连续签到天数应该从 1 开始重新计算。 3、用户在签到过程中，网络突然中断，导致签到失败，连续签到天数不应该累加，签到状态应该保持不变。 4、用户已经连续签到 N 天，但是第 N+1 天签到时，签到失败，连续签到天数应该从 1 开始重新计算。 5、用户在签到页面进行多次签到，只有第一次签到生效，后续签到应该无效。 6、用户当天签到多次，只有第一次签到生效，后续签到应该无效。 7、用户重复签到某一天，签到天数不应该累加。 8、用户在签到页面中断签到，再次进入签到页面时，应该提示用户上一次签到失败，让用户重新签到。 9、用户在签到页面中途退出，再次进入签到页面时，应该显示用户当前的连续签到天数。 10、如果用户在连续签到的过程中卸载了 APP，重新安装后应该从 1 开始重新计算连续签到天数。 11、用户签到完成后可以查看签到历史，签到天数应该与实际签到天数一致。 12、签到历史应该包括签到日期、签到状态（成功或失败）以及连续签到天数。 13、用户签到过程中，应该有相应的提示信息，如签到成功、签到失败等。
- 不能 mock 未来，就 mock 过去 代码也是基于数据实现逻辑的
- 先看下业务逻辑，是否关联限时，限地，补签，连续签到奖励等，对限时的进行边界值验证，关注 0 点天数切换间隙，对本机时间及服务器时间进行校准，有补签和限地区的需要用虚拟坐标验证，建议做下弱网测试
- 签到我见过的分为以下几种： 1，连续签到。 2，日期签到。 先说说连续签到，首先要了解连续签到的目的。是简约的还是复杂化的。签到的目的在哪？干啥用的，客户群体。 1，首先，保证点击签到，正常签到成功，并记录打标记。 2，在次签到，签到成功，并标记。如果，需要有需要记录次数的功能，那并一起验证，次数是否增加。 3，再次签到，签到成功。这里就需要知道需求是否有，连续签到多少天，是否有奖励。种类方式。 4，再次签到，签到成功。如2.3两点额外的情况，都没有。那就是正常签到并标记。（正向测试没那么复杂） 5，异常签到，假设按天签到。间隔一天，是否会记录连续的异常签到。 6，异常签到，点击签到后，是否可以取消？ …… 备注：需求过于简单。简单测试一下。 1，正常签到，正常记录标记。 2，多次（连续天数点击签到），正常记录标记。 3，异常签到，当天不点击签到不标记。 4，异常签到，点击签到无响应或不记录不标记不增加次数。 ……
- 基于限制条件的情况下，改库时间