天天看点

移动应用测试计划

确定功能和属性

User story: A high-level user or business requirement commonly used in Agile software development, typically consisting of one or more sentences in the everyday or business language capturing what functionality a user needs,

any non-functional criteria, and also includes acceptance criteria.

用户故事:敏捷软件开发中常用的高级用户或业务需求,通常由日常或业务语言中的一个或多个句子组成,用于捕获用户需要的功能,任何非功能性标准,还包括验收标准。

Use case: A sequence of transactions in a dialogue between an actor and a component or system with a tangible result, where an actor can be a user or anything that can exchange information with the system.

使用案例:参与者与具有有形结果的组件或系统之间的对话中的一系列事务,其中参与者可以是用户或可以与系统交换信息的任何事物。

现在,从这些定义中并不明显,但用例通常比用户故事更大,更详细。一个用例是个人(通常被称为演员)如何通过一系列步骤与系统完成某项任务或实现某些目标。这些步骤包括正常工作流程中的步骤以及作为异常工作流程一部分的步骤。异常工作流包括由不允许的输入或操作导致的错误处理,但也包括非典型但允许的输入或操作。用例的重点不仅仅是目标或任务,而且还有系统和演员之间的流程。

现在敏捷流程,文档经常不全或者在演进中,需要特别注意非功能需求。

风险分析

首先,您与项目团队成员合作,确定系统可能出现的问题。这些是质量风险,或者使用另一个通用名称,产品风险。对于提供步行或行车路线的地图应用,示例包括无法正确确定位置,无法以默认单位显示距离(例如,公制与英制),以及使用太小的字体来制作街道名称和地标名称难以阅读。在基于风险的测试中,这些质量风险是潜在的测试条件。要确定哪些风险是测试条件,您和您的同事评估每种风险的水平。将测试重要风险。与每种风险相关的测试工作取决于其风险等级。风险测试的顺序也取决于其风险等级。

评估风险等级的最简单方法是使用两个因素:可能性和影响。包含质量风险、项目风险

质量风险示例:

  • 在登录期间,应用软键盘输入在字段中显得非常缓慢;
  • 当使用网络(而不是GPS)获取位置信息时,app无法找到位置;
  • 如果在创建帐户期间Wi-Fi或蜂窝数据连接丢失,则应用程序崩溃

项目风险的一些示例:

  • 关键项目参与者在项目结束前退出;
  • 测试所需的设备未及时交付;
  • 项目赞助商在项目期间取消项目资金。

质量风险类别

描述
竞争 比不上竞争对手
数据质量 处理,存储或检索数据时出现故障。
日期和时间处理 基于日期或基于时间的输入/输出、计算和事件处理。
灾难处理和恢复 面对灾难性事件和/或无法从此类事件中正确恢复时,不能优雅地降级。
文档 用户或系统管理员的操作说明失败。
错误处理和恢复 由于可预见的错误(例如用户输入错误)而导致失败。
功能 特定功能无法工作,无论是给出错误答案还是不工作。
安装,设置,升级,和迁移 阻止或阻碍部署系统,将数据迁移到新版本的故障,包括不必要的副作用(例如,安装其他不受欢迎的非预期软件,如间谍软件,恶意软件等)。
互操作性 主要组件,子系统或相关系统相互作用发生故障。
负载,容量 将系统扩展到预期的峰值并发使用级别时出现故障。
本地化 在特定地区失败,包括语言,信息,税收和财务,运营问题,和时区。
联网和分布式 无法处理网络/分布式操作,包括延迟,延迟,丢失数据包/连接,和不可用的资源。
操作和维护 危及持续运行的故障,包括备份/恢复过程。
包装/履行 与包装和/或交付系统或产品相关的故障。
性能 无法执行(即响应时间,吞吐量,和/或资源利用率)在预期负载下的要求。
可移植性,配置和兼容性 特定于不同支持平台的故障,支持的配置,配置问题,和/或与其他软件/系统共存。
可靠性,可用性和稳定性 无法满足合理的可用性预期,平均故障间隔时间以及从可预见的不良事件中恢复。
安全/隐私 无法保护系统和安全数据免受欺诈或恶意滥用,可用性问题,违反相关安全或隐私法规以及类似问题。
符合标准 未遵守强制性标准,公司标准和/或适用的自愿标准。
状态和事务 未能正确响应事件序列或特定事务。
用户界面和可用性 人为因素失败,尤其是在用户界面。

参考资料

确定覆盖率目标

比如代码、网络等覆盖。

确定测试策略

测试环境、人员及能力先前版本,竞争对手的应用程序,行业标准以及与性能,可靠性和可用性相关的常见用户期望。进入退出标准等。

测试条件和范围

如果测试人员能力足够,能基于测试条件来确定如何进行测试。则文档不需要过细。

回归测试

尽量采用自动化的方式。

继续阅读