软件生成周期 什么是软件的生存周期
- 作者: 淡淡的忧伤有木有
- 来源: 51数据库
- 2020-04-14
软件生命周期划分成哪些阶段？
软件测试周期分为如下的阶段： Planning 计划阶段 Analysis 分析阶段 Design 设计阶段 Constuction 书写阶段 Testing Cycles 测试阶段 Final Testing 完成阶段 Implementation 执行阶段 Planning - this is the poduct definition phase 这是产品测试概念定义的阶段。
我觉得这部分的工作主要是管理人员在做，然后让测试组员进入某些活动。
包含的工作是： 1. High Level Test Plan 制定一个高级别的测试计划，应该就是测试大纲了，包含多个测试周期的设定等等。
2. Quality Assuance Plan 制定测试的目标，质量参数，eta测试的验收标准等等。
3. Identify when eview will e held 制定各个阶段进行eview的时间。
这个eview应该是对上阶段的情况进行分析和总结，以调整计划。
也应该有一些讨论测试覆盖率或者某些Test case或者人员的不足啊之类的东西吧。
4. Polem Repoting Pocedues 制定错误报告的流程。
比如说那些问题要报，那些问题暂时不用报。
书写的格式，跟踪的方法等等。
5. Identify Polem Classification 制定错误报告的类型。
比如说那些是UI的，那些是功能的，那些是性能的等等 6. Identify Acceptance Citeia 制定软件可接受标准。
比如说错误率在多少，那些错误可以暂时不修改，测试多少轮，覆盖率多少，测试深度多少等等。
7. Identify application testing dataases 制定程序测试数据库。
这个可能是模仿用户需求的数据库模型是什么，或者也可能是一个包含需要测试的数据的库 8. Identify measuement citeia制定错误的优先级别。
分为紧急啊，一般啊，较高啊之类的级别。
用来给开发人员参考，那些需要先修改。
9. Identify metics fo the poject 制定项目的跟踪。
比如一些跟踪文档，每周提交的weekly epot之类的。
例如在周报里面包含着本周新写多少个问题，解决了多少个问题，有多少问题是无效的，运行了多少个测试用例，通过率是多少等等。
10. Begin oveall testing poject schedule 制定详细项目计划表。
包括每个阶段的具体时间了，需要的人数了，需要的资源了等等。
11. Review Poduct Definition Document 复检产品定义文档。
主要是重新对设计文档进行阅读，对现在开发的产品进行检验，防止出现误差。
并且对一些设计提出用户角度的观点等等。
这个应该不用所有测试人员参与。
生成的应该是设计文档的一个修改和一个会议记录之类的文档。
12. Plan to manage all test cases in a dataase, oth manual and automated. 设立一个数据库将手工测试和自动测试用例放到一起管理。
我觉得不如只输入编号，然后剩下得字段用于记录每个测试用例在不同软件版本时的情况。
例如，是否通过，还是阻塞了和有那些问题报告等等。
Analysis -This is extenal document phase 这是一个外部文档阶段。
之所以说是外部文档，是因为这个阶段的工作主要都是从客户和开发组得到的文档。
在这个阶段，对这些外部文档进行分析和总结。
根据得到的信息，去创建测试的框架和文档。
所以本阶段主要的工作是完成分析，搭出框架，书写大纲等。
并不是要所有的文档工作都在本阶段内完成。
包括的主要工作是： 1. Develop Functional validation matix ased on Business equiements 制定功能验证矩阵，基于商业要求。
嗯，我觉得这里应该是根据设计说明书来划分需要测试的功能区域，每个区域内要测试的元素和功能逻辑。
这样就是建立了一个可以被测试用例和问题分类使用的功能验证表格。
而且可以检验测试的覆盖度。
2. Develop Test Case fomat 制定测试用例格式。
就是制定一系列的文档格式。
对于UI，功能，性能，自动化测试脚本等应该都有不同的格式规范。
然后给出测试优先级别，这样优先级别低，对系统影响小，一般都比较稳定的一些测试用例就可以减少测试频率和周期次数。
然后最好给每个测试用例估计一个时间，这样便于统计和管理人力资源。
3. Develop Test Cycles matices and time line 制定测试轮次和时间线。
这时候应该是根据写好的测试用例估计的时间，按照对系统的不同测试点制定测试轮次。
然后每个轮次之间有个时间点。
例如在刚刚收到产品时，做的都是简单的功能的验证测试。
这时候可以设置一个测试目标，选择一批测试用例。
然后在测试目标达到后（比如，测试用例通过率达到85%）就可以进行复杂的功能测试。
这个就可以称之为一个轮次。
是以测试用例走完一遍为测试轮次的。
当然也可以设置，一周或一个月为一个轮次。
因此我们看到，找个实际上考验的是一个领导者制定计划和管理执行计划的能力。
好的管理人员就能够制定有效的针对具体系统不同的计划，而不是一成不变，老是用一套方法。
4. Begin wites Test Case ased on Functional Validation matix 根据功能验证矩阵书写测试用例。
这个就没什么好说了，以前写过一个怎么写测试用例的文档。
总之一句话，测试用例书写的标准就是满足需要，而不是硬套模板。
5. Map aseline data to test cases to usiness equiements 将用户需求中的设定测试数据和测试用例链接。
有些用户，需要你对某些特殊的数据结构或者数据类型等等进行测试，这时候就需要将那些数据独立出来，以便能够复用。
6. Identify test case to ...
谁能给软件下个准确地定义？
计算机软件 “软件”一词于20世纪60年代初从国外传来，英文“software”，有人译为“软制品”，也有人译为“软体”，现在人们大多统称它为软件。
目前公认的解释认为软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合。
其中，程序是按事先设计的功能和性能要求执行的指令序列；数据是使程序能正常操纵信息的数据结构；文档是与程序开发、维护和使用有关的图文材料。
⑵在学者通常的论述中，计算机软件一词经常与计算机程序混用。
但是，根据世界知识产权组织（WIPO）1978年公布的《计算机软件保护标准条款》中对计算机软件的定义，计算机软件包括三部分：（1）计算机程序：包括附者于任何媒介上的原始码、目的码、微码等以任何语言、文字或符号所完成之计算机程序；（2）程序描述：包括资料结构、演绎法则、流程图；（3）辅助资料：包括程序规格书、操作手册、使用手册。
在我国，计算机软件是指计算机程序及其有关文档。
计算机程序，是指为了得到某种结果而可以由计算机等具有信息处理能力的装置执行的代码化指令序列，或者可以被自动转换成代码化指令序列的符号化指令序列或者符号化语句序列。
同一计算机程序的源程序和目标程序为同一作品。
文档，是指用来描述程序的内容、组成、设计、功能、规格、开发情况、测试结果及使用方法的文字资料和图表等，如程序设计说明书、流程图、用户手册等。
⑶因此，计算机软件包含了计算机程序并且不局限于计算机程序，还包括与之相关的程序描述和辅助资料。
计算机软件具有以下特点： 1. 计算机软件是一种逻辑实体，而不是具体的物理实体。
计算机软件具有抽象性，与计算机硬件和其他工程对象有着明显的差别。
人们可以把他记录在纸面上或者保存在计算机的存储器内部，也可以保存在磁盘、磁带和光盘上，但却无法看到软件本身的形态，而必须通过专业人士的观察、分析、思考、判断，才能够了解其功能、性能和其他特性。
2. 计算机软件的产生与硬件不同。
计算机软件开发没有明显的制造过程，也不象硬件那样，一旦研制成功，可以重复制造，并在制造过程中进行质量控制。
软件是通过人的智力活动，把知识与技术转化成信息产品。
一旦某一软件项目研制成功，即可大量复制，所以对软件的质量控制，必须着重在软件开发方面先工夫。
也正是由于软件的复制非常容易，因此才出现了对软件产品的保护问题。
3. 计算机软件的运行和使用不会出现硬件的机械磨损、老化问题。
任何机械、电子设备在使用过程中，其失效率大都遵循“浴盆曲线”：在刚投入使用时，各部件尚未作到配合良好、运转灵活，容易出现问题，经过一段时间的运行，即可稳定下来。
而当设备经历了相当长的时间运转，就会出现磨损、老化，使失效率越来越大，当达到一定程度时，就达到了寿命的终点。
而软件不存在磨损和老化问题只存在退化问题。
在软件的生命周期中，为了使他能够克服以前没有发现的问题使他能够适应硬件、软件环境的变化以及用户的新的要求，必须多次修改（维护）软件，而每次修改又不可避免引入新的错误，导致软件失效率升高，从而使软件逐步退化。
4. 计算机软件的开发和运行常常受到计算机系统的限制，很多软件对计算机系统都有着不同程度的依赖性。
软件不能完全摆脱硬件而单独活动。
有些软件依赖性大，常常为某个型号的计算机所专用，有些软件依赖于某个操作系统。
5. 计算机软件的开发至今尚未摆脱手工艺的开发方式。
软件产品大多是“定作”的，很少能作到利用现成的部件组装所需的软件。
近年来，软件技术虽然取得了很大进展，提出很多新的开发方法，例如利用现成软件的复用技术、自动生成系统研制了一些有效的软件开发工具和软件开发环境，但在软件项目中采用的比率仍然很低。
由于传统的手工艺开发方式仍然占统治地位，软件开发的效率自然受到很大限制。
6.软件本身是非常复杂的。
软件的复杂性可能来自它所反映的实际问题的复杂性，例如，它所反映的自然规律，或是人类社会的事物，都具有一定的复杂性；另一方面，也可能来自程序逻辑结构的复杂性。
软件开发，特别是应用软件的开发常常涉及到其它领域的专门知识，这对软件开发人员提出了很高的要求。
软件的复杂性与软件技术的发展不相适应的状况越来越明显。
7.软件的开发成本相当昂贵。
软件的研制工作需要投入大量的、复杂的、高强度的脑力劳动，因此其成本比较高，美国每年投入软件开发的费用要高达几百亿美元。
8.相当多的软件工作涉及到社会因素。
许多软件的开发和运行涉及机构、体制及管理方式等问题，甚至涉及到人的观念和心理。
⑷ 计算机软件按功能区分，包括系统软件和应用软件两大类。
系统软件的功能在于提供人与计算机的沟通桥梁，将使用者的命令转换成计算机的可执行程序，驱使计算机执行工作，之后把结果输出给使用者，系统软件主要包括作业系统、翻译程序、连结程序、载入程序、公用程序、程序语言、资料库管理系统及监督程序。
应用软件主要是用于解决某些特定问题，种类和用途年繁多。
什么是＂软件设计＂
什么是＂软件设计＂ 面向对象技术，特别是C++，似乎给软件界带来了不小的震动。
出现了大量的论文和书籍去描述如何应用这项新技术。
总的来说，那些关于面向对象技术是否只是一个骗局的问题已经被那些关于如何付出最小的努力即可获得收益的问题所替代。
面向对象技术出现已经有一段时间了，但是这种爆炸式的流行却似乎有点不寻常。
人们为何会突然关注它呢？对于这个问题，人们给出了各种各样的解释。
事实上，很可能就没有单一的原因。
也许，把多种因素的结合起来才能最终取得突破，并且这项工作正在进展之中。
尽管如此，在软件革命的这个最新阶段中，C++本身看起来似乎成为了一个主要因素。
同样，对于这个问题，很可能也存在很多种理由，不过我想从一个稍微不同的视角给出一个答案：C++之所以变得流行，是因为它使软件设计变得更容易的同时，也使编程变得更容易。
虽然这个解释好像有点奇特，但是它却是深思熟虑的结果。
在这篇论文中，我就是想要关注一下编程和程序设计之间的关系。
近10年来，我一直觉得整个软件行业都没有觉察到做出一个软件设计和什么是真正的软件设计之间的一个微妙的不同点。
只要看到了这一点，我认为我们就可以从C++增长的流行趋势中，学到关于如何才能成为更好的软件工程师的意义深远的知识。
这个知识就是，编程不是构建软件，而是设计软件。
几年前，我参见了一个讨论会，其中讨论到软件开发是否是一门工程学科的问题。
虽然我不记得了讨论结果，但是我却记得它是如何促使我认识到：软件业已经做出了一些错误的和硬件工程的比较，而忽视了一些绝对正确的对比。
其实，我认为我们不是软件工程师，因为我们没有认识到什么才是真正的软件设计。
现在，我对这一点更是确信无疑。
任何工程活动的最终目标都是某些类型的文档。
当设计工作完成时，设计文档就被转交给制造团队。
该团队是一个和设计团队完全不同的群体，并且其技能也和设计团队完全不同。
如果设计文档正确地描绘了一个完整的设计，那么制造团队就可以着手构建产品。
事实上，他们可以着手构建该产品的许多实物，完全无需设计者的任何进一步的介入。
在按照我的理解方式审查了软件开发的生命周期后，我得出一个结论：实际上满足工程设计标准的惟一软件文档，就是源代码清单。
对于这个观点，人们进行了很多的争论，无论是赞成的还是反对的都足以写成无数的论文。
本文假定最终的源代码就是真正的软件设计，然后仔细研究了该假定带来的一些结果。
我可能无法证明这个观点是正确的，但是我希望证明：它确实解释了软件行业中一些已经观察到的事实，包括C++的流行。
在把代码看作是软件设计所带来的结果中，有一个结果完全盖过了所有其他的结果。
它非常重要并且非常明显，也正因为如此，对于大多数软件机构来说，它完全是一个盲点。
这个结果就是：软件的构建是廉价的。
它根本就不具有昂贵的资格；它非常的廉价，几乎就是免费的。
如果源代码是软件设计，那么实际的软件构建就是由编译器和连接器完成的。
我们常常把编译和连接一个完整的软件系统的过程称为“进行一次构建”。
在软件构建设备上所进行的主要投资是很少的——实际需要的只有一台计算机、一个编辑器、一个编译器以及一个连接器。
一旦具有了一个构建环境，那么实际的软件构建只需花费少许的时间。
编译50 000行的C++程序也许会花费很长的时间，但是构建一个具有和50 000行C++程序同样设计复杂性的硬件系统要花费多长的时间呢？ 把源代码看作是软件设计的另外一个结果是，软件设计相对易于创作，至少在机械意义上如此。
通常，编写（也就是设计）一个具有代表性的软件模块（50至100行代码）只需花费几天的时间（对它进行完全的调试是另外一个议题，稍后会对它进行更多的讨论）。
我很想问一下，是否还有任何其他的学科可以在如此短的时间内，产生出和软件具有同样复杂性的设计来，不过，首先我们必须要弄清出如何来度量和比较复杂性。
然而，有一点是明显的，那就是软件设计可以 极为迅速地变得非常庞大。
假设软件设计相对易于创作，并且在本质上构建起来也没有什么代价，一个不令人吃惊的发现是，软件设计往往是难以置信的庞大和复杂。
这看起来似乎很明显，但是问题的重要性却常常被忽视。
学校中的项目通常具有数千行的代码。
具有10 000行代码（设计）的软件产品被它们的设计者丢弃的情况也是有的。
我们早就不再关注于简单的软件。
典型的商业软件的设计都是由数十万行代码组成的。
许多软件设计达到了上百万行代码。
另外，软件设计几乎总是在不断地演化。
虽然当前的设计可能只有几千行代码，但是在产品的生命期中，实际上可能要编写许多倍的代码。
尽管确实存在一些硬件设计，它们看起来似乎和软件设计一样复杂，但是请注意两个有关现代硬件的事实。
第一，复杂的硬件工程成果未必总是没有错误的，在这一点上，它不存在像软件那样让我们相信的评判标准。
多数的微处理器在发售时都具有一些逻辑错误：桥梁坍塌，大坝破裂，飞机失事以及数以千计的汽车和其他消费品被召回——所有的...
