软件测试的定义、目的、软件的生命周期、瀑布模型和敏捷开发

    软件测试的定义:

软件测试已有了行业标准(IEEE/ANSI ),1983年IEEE提出的软件工程术语中给软件测试下的定义是:“使用人工或自动的手段来运行或测定某个软件系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。”这个定义明确指出:软件测试的目的是为了检验软件系统是否满足需求。它再也不是一个一次性的,而且只是开发后期的活动,而是与整个开发流程融合成一体。

    软件测试的目的:

        1)软件测试是为了发现错误而执行程序的过程。

        2)测试是为了证明程序有错,而不是证明程序无错。(发现错误不是唯一目的)

        3)一个好的测试用例在于它发现至今未发现的错误。

        4)一个成功的测试是发现了至今未发现的错误的测试。

那么用自己的话来理解软件测试的目的:

1.为了证明这个软件可以正常工作:在正常情况下和可接受范围内的非正常情况下的功能和反应、后续可以正常对它进行集成也就是更新功能、当承担一些风险时保持正常工作

2.发现错误以及系统缺陷、系统的局限性(比如同时可以承载多少用户访问之类的)、产品和系统的质量信息

3.确认问题和风险,提早解决,预防上线后出现问题。简单来说就是:确保达到上线标准

    软件的生命周期:

基于瀑布模型的生命周期:

问题定义和计划——需求分析——软件设计(概要设计,详细设计)——软件编码——软件测试——运行和维护

瀑布模型适合用于小项目,不会有很大的需求变化。

既然说到了瀑布模型,那么必须谈谈现在越来越流行的敏捷开发,简单来理解,瀑布模型就是按照规划一步一步去完成一个项目,敏捷开发就是一边开发一边交互迭代测试。这里引用一个两种开发模式的对比,我个人是认同敏捷开发的。

I 敏捷开发的优势:

开发的阶段性成果会在开发过程中尽早的进行审查,项目的风险会降低;

适用于需求不明确情况,因为需求不明确,所以需要在不断迭代的过程中来逐步理清需求。

灵活性较高,几乎可以在任何时间进行需求变更;

敏捷鼓励开发人员与业务用户之间进行多频次的沟通,业务用户的不合理需求以及开发人员的错误理解都会在这些频繁的沟通中进行不断审查和更新,

敏捷的协作通常要高得多,通常能开发出更高质量的产品;

适用于快速变化的项目,特别是面向前端业务人员的CRM项目更容易根据业务的变化而变化。

I 敏捷开发的劣势:

敏捷的概念接受度还不算太高,初次尝试可能不会非常成功;

最终交付的内容无法预测,预期和实际完成的内容经常会有很大差异;

敏捷需要高水平的协作以及开发人员和用户之间的定期沟通。 业务和IT人员在沟通前需要做大量的准备工作,但很多情况下业务的沟通时间无法保证;

当存在乙方供应商的情况,敏捷会面临更大的挑战性。 客户通常希望尽早了解他们的项目投入。 预估项目时间和成本难度较高;

在敏捷项目中,最大的问题可能是业务部门永远不希望有最终的截止时间。

I 瀑布开发的优势:

在管理良好的项目中,瀑布可以在早期提供交付的信心;

项目团队成员不需要在同一地点频繁沟通;

在需要大量的设计或分析的情况下瀑布是一种更合适的方法;

如果在基本产品开发之外存在许多接口和依赖关系,瀑布式项目会使用工具来建模和管理这些接口和依赖关系。

I 瀑布开发的劣势:

许多企业和业务人员确实不容易在前期定义清楚需求,早期计划中所依据的假设需求可能存在很大风险;

沟通的风险要高得多 - 特别是很多项目都是前期单向的沟通,后期项目和业务人员的预期差别很大;

瀑布项目的风险一般都很高,因为基于无效假设基础上的需求可能会让项目无限度扩大。 所以你会看到很多瀑布项目都出现成本超出预算或延迟的情况。

结论:

敏捷和瀑布的实施方法差别还是很大的,瀑布几乎可以应用于任何类型的项目,尤其是大型的项目。

敏捷方法今年来越来越受欢迎,尤其是当前SaaS软件当道,特别像Salesforce这样自带开发平台的SaaS产品可以非常容易的搭建初始原型并进行快速迭代,所以我们才会看到有越来越多的企业采用敏捷的方式来进行项目实施。总的来说敏捷并不能完全替代瀑布,它只是给了我们另外一种好的选择。(From:CRM日记本)

发布了44 篇原创文章 · 获赞 15 · 访问量 2万+

猜你喜欢

转载自blog.csdn.net/IGGIRing/article/details/104490036