你手头上有很多重复文档需要处理、环境搭建、从各种文件或查询结果中、多次重复执行的 shell 等步骤没?尝试用代码减轻手头工作开始吧。然后写着写着,很多新的想法就会出来,你的思维方式也会改变。
那时你还感兴趣的话,各种所谓的自动化名称的活就出来了
肯定是关注结果,问题在于什么样的结果?哪些结果?是否是一人工作量可达到的结果
跟公司老大多交流,弄清楚他们想要的目标。如果他们目标过高,要慢慢的展现结果,让他们自己反思目标是不是不合理,或者投入更多资源达到目标。
别一开始就想什么流程,一开始想的是怎么活下来
你没看清楚我说不重要的前提,也就是我回答的前半部分。
首先你得努力去将可能导致出错的输入条件分开,也就是在用例设计的时候,就要考虑一旦出错可以大概知道什么地方出错。这个要根据开发具体的实现进行分析。
怎么说呢,就好像物理公式中的前提条件 --- 真空中。
如果分不开,那么实际上就没必要花那么多心思去分开了,造成这种情况的原因会非常的多。除非这个是核心环节的核心,否则一般是没那么多时间去耗费的。
为什么你要在一个输入里面包含两种都可能出错的输入呢?如果能分开,就尽量分开,这个是最快捷的办法。如果分不开,那么从客户的视角来看,是哪个出得错已经不重要了。
将接口测试的服务端数据保存,然后 mock 服务端,这样可以让客户端自动化
这点是赞同的。测试领域,缺乏的不是思想,而是一个又一个落地思想的代码。
#4 楼 @zhipeng_sun 一般还是检查工具、客户端、服务端的证书安装情况。其他情况则需要看是否因为模拟器问题,真机其实没问题。最后都不行,检查代码吧,看逻辑再分析原因。
—— 来自 TesterHome 官方 安卓客户端
先把官网标准库的 unittest 章节完整的学习一遍,然后用自己的代码实践一下,配合 coverage 统计一下覆盖率就行了。如果后续还有需要深入的,再去搜和问更具体的问题。
网上的基础文章大多也就是官方文档的翻译。
—— 来自 TesterHome 官方 安卓客户端