
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
随着互联网的不断发展,越来越多的程序员都在学习软件测试等技术,而本文我们就通过案例分析来简单了解一下,软件测试应用需要注意哪些问题。
AIR原则
AIR即空气,单元测试亦是如此。当业务代码在线上运行时,可能感觉不到测试用例的存在和价值,但在代码质量的保障上,却是非常关键的。新增代码应该同步增加测试用例,修改代码逻辑时也应该同步保证测试用例成功执行。AIR原则具体包括:
A:Automatic(自动化)
I:Independent(独立性)
R:Repeatable(可重复)
简单的解释一下三个原则:
单元测试应该是全自动执行的。测试用例通常会被频繁地触发执行,执行过程必须完全自动化才有意义。
如果单元测试的输出结果需要人工介入检查,那么它一定是不合格的。单元测试中不允许使用System.out等方法来进行人工验证,而必须使用断言来验证。
为了保证单元测试稳定可靠且便于维护,需要保证其独立性。用例之间不允许互相调用,也不允许出现执行次序的先后依赖。
BCDE原则
编写单元测试用例时,为了保证被测模块的交付质量,需要符合BCDE原则。
B:Border,边界值测试,包括循环边界、特殊取值、特殊时间点、数据顺序等。
C:Correct,正确的输入,并得到预期的结果。
D:Design,与设计文档相结合,来编写单元测试。
E:Error,单元测试的目标是证明程序有错,而不是程序无错。为了发现代码中潜在的错误,我们需要在编写测试用例时有一些强制的错误输入(如非法数据、异常流程、非业务允许输入等)来得到预期的错误结果。
CorrectTest&&DesignTest
正确性测试听起来应该会很简单,(比如调用一个API,然后看结果返回是否正确)但如果放到集成测试中,我们还是可以拓展出一些额外的关注点的.还是以上面提到的createVm为例子,我们看到了8个flow,然后里面可能还嵌套着好几个子flow.如图所示:
在编写正确性测试时,我们可以考虑额外关注以下几点:
APIParam在各个Flow间中转时是否如预期
关注管理节点内的服务:
Flow之间调用的时序是否符合预期
Flow之间流转时,业务目标状态是否符合预期
关注管理节点外的服务:
对于agent的请求是否符合预期
在API调用完后,相关资源的目标状态是否符合预期
而与文档结合的测试用例,则应当由团队的测试人员来定义.可以确定的是,这类的测试更加关注于API(即输入输出),而不是内部的状态.
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。