软件开发全过程检测及测试自动化
今天找了几篇基础概念介绍的文章，可谓是通俗易懂，入门中的入门文章。本来不想转贴过来的，但是发现不少朋友都是初涉测试行业，很多懵懂和迷惑，所以决心贴几篇文章给新朋友们了解。
-----------------
软件开发全过程检测及测试自动化
首先谈谈软件测试。这可以说是一个非常令人捉摸不定的领域。“应该怎样对我们的产品进行测试？”和“怎样才算对产品进行了足够的测试？”等问题，对于不同企业的不同类产品、同一企业的不同类产品、或不同企业的同一类产品，实际操作上都会有很大的不同。
SEI的SW-CMM在它的成熟度第三级的“软件产品工程”关键过程域中，把软件开发周期中不同阶段的测试作为实施活动中的关键实践。（在SW-CMM版本2.0 的讨论过程中，曾经有过提议，在成熟度第二级设立一个关键过程域“软件测试管理”。但在版本2.0 的讨论稿C 中，并没有这样做。从这里我们也可以看出，SW-CMM本身也是一个人为地制定的“软件”。）
一般地，基于开发周期中不同阶段对不同对象所进行的测试，可划分为：
单元测试（unit test ）：
由编程的开发人员自行计划与完成的，针对单个或相关联的一组程序单元的测试。
组装测试（inegration test ）：
计划于设计阶段，由开发人员与测试人员合作完成的，针对结合起来的不同单元以及它们的接口的测试。
系统测试（system test ）：（可认为包括“可用性与图形用户界面测试”）
测试整个系统，以证实它满足要求所规定的功能、质量和性能等方面的特性。
回归测试（regression test ）：
用于验证改变了的系统或其组件仍然保持应有的特性。
验收测试（acceptance test ）：
测试整个系统，以保证其达到可以交付使用的状态。
关于上述各阶段的测试的具体内容及实现的方法，读者可参考SW-CMM及有关软件工程和软件测试的书籍。千万不要停留在只参考SW-CMM，因为该文件只讲述要做些什么，而没有介绍怎样做。同时，所有的资料中谈及的内容及方法，都是一般化的。对于一个特定软件的测试，必须经过使用者对通用的测试方法的改变及改进，才能有效和达到高效率。
下面，谈谈软件测试的其他方面的一些问题。
一个被人忽略的软件测试目的
在谈到测试时，许多作者都引用了Grenford J. Myers 就软件测试目的提出的以下观点：
1.测试是程序的执行过程，目的在于发现错误；
2.一个好的测试用例在于能发现至今未发现的错误；
3.一个成功的测试是发现了至今未发现的错误的测试。
这是一种比较狭窄的观点。作为一个清醒的、纵观全局的软件开发人员或管理者，我们应当从软件过程的角度来看测试。
一个被人忽略的软件测试目的是：测试可以帮助发现当前开发工作所采用的软件过程（也是一个“软件”）的缺陷，以便进行改进。（在以下的讨论中，“错误”与“缺陷”基本上认为代表相同意义。）
怎样理解这种说法呢？
首先，测试并不仅仅是为了要找出错误。分析错误产生的原因和错误在开发的哪一个阶段产生，具有非常重要的意义。
通过分析错误的原因，我们可以立即在开发行动中对其进行改正。同时，这种分析也能帮助我们推理出 与所分析的错误有关联的潜在错误，从而有针对性地设计出检测的方法。
通过分析错误产生于哪一个开发阶段、而又在哪一个阶段被发现，我们可以判断从错误的产生到错误的发现，跨越了多少个开发阶段。软件开发的一条重要原则是尽早发现与修正错误。（当然，更高的一条原则是尽量预防错误的出现。）一个错误能够超越本开发阶段而不被发现，就指明了该开发阶段的检测手段有缺陷，从而也不难有针对性地制定出加强的措施与办法。这也就是软件过程改进的一项重要内容。如果能做到在同一开发阶段发现及修正错误，该开发机构就可以预期有一个高质量的产品及一个低成本、高效率的软件过程。
有些项目的主持人，认为以尽快的速度把测试之前的所有开发阶段完成（实际并没有完成），早日开始测试，以图达到快速和高质量（因为似乎有更长的时间可用于测试）。实际的效果将会是俗语所说的“欲速不达”。从常识就可以知道，花开发时间去继续扩大发展前面阶段引入的错误，得出的只能是更大量的需要耗时修正的错误。
因此，正确分析与利用测试的结果，我们可以非常有效地进行软件过程改进。
软件开发全过程检测，力争本阶段修正错误
从上面的讨论，我们很自然的就能领会到，软件错误的发现绝不能等到测试才开始（按常规，最早的测试就是编码后的单元测试）。因此，笔者提出一个软件工程的守则：软件开发全过程检测，力争本阶段修正错误。单元测试是在软件开发的“实现阶段”才开始的，在此之前的“可行性研究与计划阶段”，“需求分析阶段”，“概要设计阶段”，和“详细设计阶段”，都必须有非常明确切实的手段与措施对开发结果进行检验，以保证阶段的正确完成。
怎样判断一个软件过程的优劣，怎样进行软件过程改进，都可以在这个守则的指导下进行。这个守则是简单明确的，但因企业背景、条件的不同，开发环境条件的不同，项目产品的不同，实际的软件过程的实现方法就会变化无穷。考虑实现这个原则的方法的时候，可以尽量多参考各种理论及经验，但在选择制定本企业开发实践中使用的软件过程时，就必须处处根据是否能给自身的项目带来好处，以及自身的条件进行考虑。千万不要仅仅为了满足某个“标准”的提法而做一些无实际意义的工作。要尽量避免烦琐，争取做到简单、有条理和有最大的效果。
软件测试的自动化
软件测试的工作量很大（据统计，会用到40% 的开发时间；一些可靠性要求非常高的软件，测试时间甚至占到总开发时间的60% ），但测试却是在整个软件过程中极有可能应用计算机进行自动化的工作，原因是测试的许多操作是重复性的、非智力创造性的、需求细致注意力的工作。计算机就最适合于代替人类去完成这些任务。企业在这方面的投资，会对整个开发工作的质量、成本、和周期带来非常明显的效果。
一些适于考虑进行自动化的测试操作为：
1.测试个案的生成（包括测试输入，标准输出，测试操作指令等）。
2.测试的执行写控制（包括单机与网络多机分布运行；夜间及假日运行。测试个案调用控制；测试对象、范围、版本控制等。）。
3.测试结果与标准输出的对比。
4.不吻合的测试结果的分析、记录、分类、和通报。
5.总测试状况的统计，报表的产生。
测试自动化与软件配置管理是密不可分的。与测试有关的资源都应在配置管理中进行统一的计划考虑。另外，测试工具的采用也是一个提高质量的关键，有些专用的测试工具能帮助发现一些用任何测试个案都难以触及的错误。 谢谢了！以后有这样的好东西，经常传上来啊，我们这些新手十分感谢。 谢谢了！ thanks 又有电充了，3Q！ 此文对初学者适合 谢谢 受益非浅,十分感谢! 我是初学者,多谢! 非常感谢，看了版主的很多帖子，大多都是很好的系统性的文章，Thanks！8-) 3Q 非常的感谢，可以了解更多的东西 不错不错
good
good 好贴 不错的 谢谢啊 我觉得测试管理工具与性能测试工具是必须的，而功能测试方面的则因具体情况而定了！ 谢谢了！谢谢了！ 谢谢 好的开始！
页:
[1]
2
