如果您是开发团队的一员,而 QA 很可能来自其他团队,您最终可能会得到两组测试用例。您必须向您的经理证明您完成了工作并且通过了测试用例,并且 QA 将完成他们的测试工作,以向他们的经理展示这个应用程序通过了所有要求。
我认为我们的 QA 团队不时使用这里提到的其中一些服务,但并非总是如此。什么时候,我问我被告知他们使用这些服务器不是很方便,因为这非常耗时,而且他们都未能测试某些东西。
但是在我们这边(开发团队),我们没有额外的预算,也没有从 QA 和开发人员那里得到满意的结果,他们根据我们的要求研究了这些服务。所以,我们最终做我们自己的测试自动化。这正好花了两天时间。
- 使用 GIT,
- 詹金斯
- 亚行
- 批处理/Shell 脚本。
因此,每当我们完成一个功能及其单元测试用例时,我们都会在问题跟踪器上将该功能标记为完成。开发人员将代码推送到版本控制系统。
第二天早上,当开发人员来上班时,他或她会去 Jenkins 面板并开始构建。詹金斯只需执行一个批处理文件,它会执行以下操作,
- 从 GIT 下载最新代码。使用 git 命令。
- 更新版本 ID。
- 执行 Android 命令行构建过程来构建应用程序。
- 对单元测试应用程序执行相同的步骤。
- 在连接到该服务器的一个或多个设备上安装这两个应用程序。
- 在这些设备上使用 ADB 运行测试应用程序。
- 收集单元测试日志(Junit 风格)。
- 将日志邮寄给所有相关方。
这对于压力测试也是一样的。但是,如果您在夜间进行压力测试,它可能会收集数兆字节的日志,在这种情况下,关键字库搜索绝对是查找崩溃的好主意。
对于布局/分辨率测试,您始终可以使用adb
或从单元测试应用程序截屏,并将这些图像也作为电子邮件附件附加。
绝对使用第三方服务会减轻任务,我们总是可以外包我们需要的任何东西。但请记住,它们是绝对需要手动测试的情况。例如,如果您的应用想要激活 WiFi 或任何Settings
需要用户明确输入的 Android 设备,或者您正在使用其他资源的情况,例如使用相机拍照或测试社交网络集成。确保将您的要求与这些业务实体提供的服务进行比较。