200602271215442.html

软件工程的红包书

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 计划并不是到这里就结束了，在最后测试结果的评审中，必须要严格验证计划和实际的执行是不是有偏差，体现在最终报告的内容是否和测试的计划保持一致，然后，就可以开始着手制作下一个测试计划了。</P>
<P><BR><STRONG>九、报告软件测试错误的规范&nbsp;&nbsp;<BR></STRONG>&nbsp;<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 报告软件测试错误的目的是为了保证修复错误的人员可以重复报告的错误，从而有利于分析错误产生的原因，定位错误，然后修正之。因此，报告软件测试错误的基本要求是准确、简洁、完整、规范。需要掌握的报告技术归纳如下。 <BR>　　 1. 描述 (Description)，简洁、准确，完整，揭示错误实质，记录缺陷或错误出现的位置 </P>
<P>　　描述要准确反映错误的本质内容，简短明了。为了便于在软件错误管理数据库中寻找制定的测试错误，包含错误发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。 </P>
<P>　　2. 明确指明错误类型：布局、翻译、功能、双字节 <BR>根据错误的现象，总结判断错误的类型。例如，即布局错误、翻译错误、功能错误、双字节错误，这是最常见的缺陷或错误类型，其他形式的缺陷或错误也从属于其中某种形式。 </P>
<P>　　3. 短行之间使用自动数字序号，使用相同的字体、字号、行间距 </P>
<P>　　短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。 </P>
<P>　　4. UI要加引号，可以单引号，推荐使用双引号 </P>
<P>　　UI加引号，可以容易区分UI与普通文本，便于分辨、定位缺陷或错误。 </P>
<P>　　5. 每一个步骤尽量只记录一个操作 </P>
<P>　　保证简洁、条理井然，容易重复操作步骤。 </P>
<P>　　6. 确认步骤完整，准确，简短 </P>
<P>　　保证快速准确的重复错误，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。 </P>
<P>　　7. 根据缺陷或错误类型，选择图象捕捉的方式 </P>
<P>　　为了直观的观察缺陷或错误现象，通常需要附加缺陷或错误出现的界面，以位图的形式作为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或错误本质，可以捕捉缺陷或错误产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或错误位置，通常要求附加中英文对照图。 </P>
<P>　　8. 附加必要的特殊文档和个人建议和注解 </P>
<P>　　如果打开某个特殊的文档而产生的缺陷或错误，则必须附加该文档，从而可以迅速再现缺陷或错误。有时，为了使缺陷或错误修正者进一步明确缺陷或错误的表现，可以附加个人的修改建议或注解。 </P>
<P>　　9. 检查拼写和语法错误 </P>
<P>　　在提交每条缺陷或错误之前，检查拼写和语法，确保内容正确，正确的描述错误。 </P>
<P>　　10. 尽量使用业界惯用的表达术语和表达方法 </P>
<P>　　使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。 </P>
<P>　　11. 通用UI要统一、准确 </P>
<P>　　错误报告的UI要与测试的软件UI保持一致，便于查找定位。 </P>
<P>　　12. 尽量使用短语和短句，避免复杂句型句式 </P>
<P>　　软件错误管理数据库的目的是便于定位错误，因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。 </P>
<P>　　13. 每条错误报告只包括一个错误 </P>
<P>　　每条错误报告只包括一个错误，可以使错误修正者迅速定位一个错误，集中精力每次只修正一个错误。校验者每次只校验一个错误是否已经正确修正。 </P>
<P>　　以上概括了报告测试错误的规范要求，随着软件的测试要求不同，测试者经过长期测试，积累了相应的测试经验，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，经常阅读、学习高级测试工程师的测试错误报告，结合自己以前的测试错误报告进行对比和思考，可以不断提高技巧。&nbsp;<BR>&nbsp;<BR>&nbsp;<BR><STRONG>十、软件测试人员结构组成分析</STRONG></P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 软件测试工程师是软件行业中一种即年轻又古老的职业，进入二十一世纪以来，随着中国加入WTO以后，从事这项职业的人也越来越多。一个公司在组建一个测试队伍的时候如何分配人员结构，从而使公司软件测试工作水平得到提高，是大家比较关注的问题。本人依照自己的经验提出自己的观点：</P>
<P><BR>我们首先来看一下测试人员的纵向结构<BR>1，测试经理<BR>测试经理主要负责测试队伍的内部管理以及与其他外部人员，客户的交流，详细说来主要包括进度管理，<a href="200604240822405.html" tppabs="http://www.itisedu.com/phrase/200604240822405.html" target="_new">风险管理</a>，资金管理，人力资源管理，交流管理等等，测试经理需要具有项目经理的知识和技能。同时测试工作开始前项目经理需要书写《测试计划书》，测试结束需要书写《测试总结报告》<BR>2，测试文档审核师<BR>测试文档审核师主要负责前置测试，包括在需求期与设计期间产生的文档进行审核，比如《<a href="200603071000275.html" tppabs="http://www.itisedu.com/phrase/200603071000275.html" target="_new">业务建模</a>书》，《需求规格说明书》，《概要设计书》，《详细设计书》等等。审核需要进行书写审核报告。当文档确定后，需要整理文档报告，并且反映介绍给测试设计师。<BR>3，测试设计师<BR>测试设计师主要根据需求期与设计期间产生的文档设计各个测试阶段的测试用例。<BR>（往往测试文档审核师，测试设计师可以有相同的一组人来完成）<BR>4， 测试工程师<BR>测试工程师按照测试用例，来完成测试工作。</P>
<P><BR>但是测试人员应该有哪些人来组成呢？也就是测试人员的横向组成，让我们再来讨论讨论：<BR>1， 需要具有一定开发经验的计算机专业人员<BR>由于具有一定开发经验的计算机专业人员即懂得计算机的基本理论，又有一定的开发经验。所以对于软件中哪里容易出错，哪里不容易出错他们了如指掌；他们可以分析程序的性能，软件性能差是否是占有内存空间太多，或者是占有CPU时间太多引起的，还是其他原因，他们往往是专家。尤其是进行非功能测试的时候，他们可以更好的搭建系统测试平台。这种人员应该占测试队伍中一半以上。<BR>2， 需要具有本软件业务经验的人员<BR>测试队伍中需要有这样的人员的目的在于，这些人员由于对业务非常熟悉，软件质量的前提又是满足用户的需求。专业业务知识是计算机专业人员达不到的，所以这方面人才可以利用它们的业务知识和专业水平，参与系统需求期间的文当审核，可以发现软件中存在的业务性错误。比如专业用语不准确，业务流程不规范等等，这种人才对于专业性比较强的软件测试工作尤为重要，比如税务，法律，艺术，CAD,<a href="200604222217455.html" tppabs="http://www.itisedu.com/phrase/200604222217455.html" target="_new">CAM</a>…<BR>3， 只需要会操作计算机的人员<BR>由于软件一旦卖出去之后，使用软件的人各种各样，各种各样的人带来各种各样的操作情况，请一大部分人员在软件测试工作后期进行测试工作是十分重要的，他们往往会发现专业测试人员测试不出的东西和一些希奇古怪的错误。这就是软件测试学中所谓的猴子测试法。<BR>对于一个软件公司来说，并不是说所有的测试队伍都需要这三种人员，实际中可以一组人代替多个角色，但是要遵循以下原则：<BR>1，对于业务不是很专业的软件，具有一定开发经验的计算机专业人员与具有本软件业务经验的人员可以合并；<BR>2，只需要会操作计算机的人员，可以由公司行政人员来充当。</P>
<P><STRONG>十一、软件测试的现实和理想</STRONG> <BR>&nbsp;<BR>&nbsp;<BR>　　“从我在微软工作的经历来看，软件测试绝对不是开发活动完成后的收尾工作，很多大型的开发项目，测试会占据项目周期一半以上的时间。以IE4.0为例，代码开发时间为6个月，而稳定程序花去了8个月的时间。”前微软亚洲研究院博士、软件测试专家陈宏刚谈道。从投入的资金和人力物力来看，测试、使产品稳定和修改花去的时间可能占到80%。 <BR>还处在婴儿期 </P>
<P>　　软件测试之所以发展相对缓慢，一个原因是做研究和做开发的人交流的机会相对少。只有做大型系统工程的人才会对测试提出较高的要求，重要性才能显现出来，而做研究和教学的人没有大型系统工程案例，所以造成了测试理论研究的发展缺乏充实的基础材料。真正做大型系统开发的工程师，又没有时间将第一手的测试经验变成系统的理论。 </P>
<P>　　“在美国，佛罗里达州和华盛顿州分别有一所大学开设软件测试课程，其他有正规课程的学校不是很多。软件测试正停留在没有学科系统、没有系统教育的阶段。虽然已经有学校开设了这门课程，但是使用的教学案例，多半是单机软件，还谈不上系统的理论。”陈宏刚博士介绍说。 </P>
<P>　　高素质的“杂牌军” </P>
<P>　　由于企业对测试人才有着迫切的需要，因此，只好自己培养测试人才队伍。例如微软公司，对不同的产品制定测试规范，开设一些课程，通过讲座的形式对测试技术人员进行培训，但是也还未形成系统的理论。 </P>
<P>　　即使在微软，测试队伍是典型的“杂牌军”，没有科班，没有统一的专业，更多的是具有丰富的经验和不同行业背景的员工，例如具有语言学、数学、物理学、计算机、工程、管理等学科等背景的员工。但是，这不是说随便什么人都可以做测试工作，陈宏刚工作过的那个试验室，20个人中有7个博士。可见，虽然测试不是一个专门的学科，但是，这个部门对于一个成熟的软件企业又是至关重要的部门。 </P>
<P>　 认识需再提高 </P>
<P>　 IBM和微软公司属于领先的大公司，对测试的认识也经历了一个过程。开始的时候，也是开发人员兼职做测试，就像今天国内一些较小规模的软件企业。但是，后来的结果表明，花在软件修补上面的费用太高，以至于远远超出了所能够允许的范围。这个时候，增加测试队伍的规模，提高测试队伍的素质，提高测试队伍的待遇和受重视的程度是更加划算的。 </P>
<P>　　还有一个问题是，很多工程师不愿意做测试，认为是一种打下手的工作，没有前途，这也是国内比较大软件企业面临的问题。所以，企业从上到下普遍自觉和不自觉地只重视技术，不重视质量，后果是产品在市场上竞争力不高，产品售后维护和服务费用偏高。 </P>
<P>　　巨大反差 </P>
<P>　　微软的开发工程师与测试工程师的比例是1∶2，国内一般公司是6∶1。而且，致命的问题是没有哪个机构专门培养测试工程师。这个矛盾提示我们，在中国不能等到实际的需求和人力资源矛盾十分尖锐的时候，再谈培养问题；也不能等到产品质量成为产业阻碍的时候再来提高软件业的测试水平。测试工作不能靠手工劳动来完成，更多的情况是要使用工具软件和编写测试程序来完成，培养全面的测试专业人才是项任重道远的工作。</P>
<P><STRONG>十二、软件测试的新模型</STRONG>&nbsp;&nbsp;&nbsp;<BR></P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 通常情况下，一个软件模型说明的内容主要包括，在测试过程中你应该考虑到哪些问题，如何对测试进行计划，测试要达到什么目标，什么时候开始，在测试中你要用到哪些信息资源。一个好的模型可以引导你对问题进行思考，而不好的模型则只能使你误入歧途。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 这里我要宣称的是，目前的大多数软件测试模型都是不好的模型。这是因为这些测试模型仅仅是<a href="200602282307275.html" tppabs="http://www.itisedu.com/phrase/200602282307275.html" target="_new">软件开发模型</a>的一些装饰和补充而已。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 人们一直在苦苦寻找软件开发的模型，在创建了新的模型后，就把测试作为一个阶段放在模型的后面部分。因此测试总被作为一种事后行为，测试总是被开发所驱动。总的来说，我们是在检测他们的完成品。但是，作为事后处理的测试，其驱动方式是不正确的。实际上它显而易见地和开发过程中各种行为之间有关，测试没有起到应有的平衡作用。这样的测试只是检测了开发人员做了什么，而并没有检测到他们是否按照规则做了什么，这样的做法割裂了本该紧密联系的行为，剩下的只有那些匆忙而草率的想法所带来的伤害。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 而这样做的结果就是效果很差的、效率很低的测试。效果很差的测试将导致很多bug没有被发现，而效率很低的测试所浪费的是成本。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 在本文中，我要做2件事，其一，我要否定一个不好的模型，即V模型。我希望通过论述来表明，“单元测试”和“集成测试”这2个词汇可以从我们的词