For investors
股价:
5.36 美元 %For investors
股价:
5.36 美元 %认真做教育 专心促就业
单元测试是程序员在做软件测试的时候会经常用到的一个测试方法,而本文我们就通过案例分析来简单了解一下,单元测试应用实践与排期预估方法。
1、如何单元测试?
软件可测性和研发过程息息相关的,但是现实场景是软件开发人员很不愿意编写单元测试用例,原因有很多,比如:方法和分支太多,单元测试用例的编写甚至要比业务代码还要多,时间根本不够用;好多方法依赖于上下文,需要做模拟(mock),只有这样才能跑起来;推行单元测试似乎就困难重重。
很多公司程序代码正确性的验证就交由软件测试人员来完成,工作的转移必定产生了更多的沟通与协作成本,如果软件不经常迭代,问题还不大,如果软件是按照周期迭代的,每个周期都要进行全量测试,那么这个测试团队的人员必将会非常之大,这个问题就比较突出了,测试阶段极有可能成为需求交付的瓶颈,损害软件产品的发布,影响业务的增长。
为了提升测试效率,很多测试过程可以进行自动化,比如回归测试,性能测试等。当然还有另一种提升测试效率的办法,就是让单元测试回归到开发人员的职责范围内,当然单元测试也属于自动化测试的范畴。
单元测试交给软件开发人员来编写,本身是没有问题的,有问题的其实是软件开发人员对单元测试的认知,以及开发出来的代码本身。测试驱动开发模式就是规范我们进行单元测试用例编写的一种实践方式。
2、如何预估排期?
研发人员应该懂得如何为业务人员提供可信的预估结果,以便做出计划。一旦做了承诺.就要提供确定的数字,按时兑现。但是大多数情况下,精确数字这很难做到。专业的做法是提供概率预估,来描述期望的完成时间及可能的变数。对预估结果,研发人员会与团队的其他人协商,以取得共识。
你可以根据3个数字预估某项任务。这就是三元分析法。
O:乐观预估。这是非常乐观的数字。如果一切都异常顺利,你可以在这个时间内完成。实际上,为了保证乐观预估有意义,这个数字对应的发生概率应当小于1%。举例:假如是1天。
N:标称预估。这是概率大的数字。如果画一张柱状图,标称预估就是高的那个。举例:假如3天。
P:悲观预估。这是糟糕的数字。它应当考虑到各种意外,比如飓风、核战争、黑洞、其他灾难等。为保证悲观预估有意义,这个数字对应的发生概率也应当小于1%。举例:假如12天。
有了以上三个预估,我们可以这样描述概率分布:μ=(O+4N+P)/6
针对于例子,我们可以的出预估值(1+4*3+12)/6=4.2天
实际情况可能会更复杂一些,有时候我们会多项任务并行,这时候的预估模型也会进行调整,总任务统计分布:μseq=∑μtask,总标准差就是标准差平方和的平方根。
掌握一些基本的时间预估模型的知识,对于项目规划和实施节奏的把控,是非常必要的,毕竟依据经验甚至是拍脑袋给出的排期往往是不能让人满意和信服的。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。