首页>>技术前沿>>APP开发行业动态
软件开发与测试6条常规实践帮你节省时间和避免问题
作者:各地APP开发 | 转载 来源:软件开发 | 时间:2017年10月25日| 点击:0次 | 【评论】

我对软件测试测试充满热情,因为我相信良好的测试实践既能确保满足最低质量标准(可悲的是许多软件开发做不到),并能指导和塑造开发本身。不要写你认为将来可能需要但现在不需要的代码。这是为假想的未来用例编码,这些代码将不可避免地变成死代码,或需要重写,因为未来结果总是与想象的稍有不同。如果你写代码用于将来的用例,我将在代码评审中对其质疑。(你可能而且必须设计 API,并确保未来的用例可用,但这是不同的问题。)这条原则也适用于被注释掉的代码;如果一个被注释掉代码块即将进入一个发布版本,那么它就不应该存在。如果代码可能要还原,请为代码删除创建一个问题单并引用提交对象的哈希字符串。

软件开发

1、用于测试需要的基础设施、框架和库需要测试。除非你真的需要不要测试浏览器或外部库。测试你写的代码,而不是别人的代码。
2、当第三次编写相同的代码时,也是将其提取成通用的辅助函数(并为其编写测试)的正确时机。测试中的辅助函数不需要测试;但当你将它们剔除出去然后再重用它们时,它们需要测试。到你第三次编写类似代码的时候,你通常会清楚地认识到你正在解决的通用问题的模型是什么。
3. 快速失败。检查输入,如果遇到无意义输入或非法状态则尽早失败,最好是通过异常或错误响应使问题对调用者变得清晰。允许你的代码处理“有创意”的用例(例如,除非真的需要,否则在做输入验证的时候不要做类型检查)。
4、现在来谈谈 API 设计(面向外部的对象API):把简单的事情做简单了,复杂的事情自然成为可能。首先设计简单的用例,如果有可能最好是零配置或参数化。为更复杂和灵活的用例(如需要)增加选项或额外的 API 方法。
5. 对于单元测试(包括测试基础设施测试),所有代码路径都应该被测到。100% 覆盖是一个好的开始。你不能覆盖所有可能状态的排列/组合(组合性爆炸),因此这个问题需要考虑。只有当有很好理由的情况下才允许有代码路径未经测试。没有时间不是一个好理由,最终会花费更多的时间。可能的好理由包括:真正的不可测(以任何有意义的方式),现实中不可能发生,或被其它测试覆盖。没有测试的代码是一种债。测量覆盖率和拒绝减少覆盖率 PR(拉取请求) 是确保你在正确的方向演进的一种方式。
6、单元测试测的是行为单元,而不是实现单元。我们的目标是在改动实现的情况下不改动行为,也不必更新测试,尽管这个目标不总是能实现。因此在可能的情况下将测试对象视为黑盒,通过公共 API 测试,而不调用私有方法或玩弄状态位。在一些复杂的情况可能做不到,如在特定的复杂状态下测试行为,以找到一个偶发的错误。这一点对于写测试非常有帮助,因为它迫使你在写测试代码之前思考你代码的行为以及你将如何测试它。测试首先鼓励更小,更模块化的代码单元,这通常意味着好代码。关于“测试优先”方法有一本很好的入门参考书,就是 Kent Beck 写的《测试驱动开发》(《Test Driven Development by Example》)

此内容DOC下载 此内容PDF下载

【全文完】
关键词标签:软件开发 软件测试 
0 ([$-顶稿人数-$])
0 ([$-踩稿人数-$])

版权声明:

弈聪软件网站内容中凡注明来源为转载的内容,涉及软件开发,APP开发公司,APP开发,APP制作,app推广等内容并不代表本站赞同支持其观点,并不对其真实性负责。转载请署名弈聪软件公司,否则弈聪软件公司将追究其相关法律责任。