从测试的角度来重新反思我们自己的程序以及我们的程序员之路——“通过追本溯源来进行前瞻性思考”...

从测试的角度来重新反思我们自己的程序以及我们的程序员之路——“通过追本溯源来进行前瞻性思考” 

最近比较忙&＃xff0c;而且情绪上有些浮动&＃xff0c;但控制的非常好。这几天协会搞一个编程比赛&＃xff0c;部分的题目是我出的&＃xff0c;所以最后大家决定让我做测试人员&＃xff0c;对协会的比赛进行评测。我虽然已不担任协会职务&＃xff0c;却毅然接受了。

首先&＃xff0c;我了解了测试相关的概念&＃xff0c;阅读了《软件测试》、《软件测试的艺术》、《微软的软件测试之道》、《软件测试经验与教训》等&＃xff0c;并结合自身的测试经历来做一些记录&＃xff0c;希望抛砖引玉。

虽然协会测试用不上这些&＃xff0c;既然让我做了&＃xff0c;我就应当力求公正公平&＃xff0c;准确有效。在做好这个工作的余下时间里&＃xff0c;作了一些浅薄的思考&＃xff0c;现在拿出来跟大家一起分享。

微软虽然有很多不足&＃xff0c;制作的程序漏洞不少&＃xff0c;但不可否认&＃xff0c;在其快速开发的进程中&＃xff0c;将测试放在比较重要的位置&＃xff0c;也是其获得较多正面评价的原因之一&＃xff1a;

微软的组织结构&＃xff1a;

微软的“大公司小团队”战略&＃xff0c;小团队布局&＃xff1a;

以下是读书心得&＃xff0c;摘抄&＃xff1a;

软件测试或系统测试大约占用50%的项目时间和超过50%的总成本。

测试是为发现错误而执行程序的过程。&＃xff08;人类的行为总是倾向于具有高度的目标性&＃xff0c;确立一个正确的目标有利于实现这一目标&＃xff0c;这里我们确立我们的目的是发现错误&＃xff09;

软件测试的大多数问题都是心理学问题。

程序员应当避免测试自己的程序。

一个测试用例必须包括两个部分&＃xff1a;1、对程序的输入数据的描述2、对程序在上述输入数据下的正确输出结果的精确描述。

黑盒测试主要将重点集中放在发现程序不按其规范正确运行的环境和条件。

白盒测试主要是对程序的逻辑结构进行检查&＃xff0c;从中获取测试数据。

检查程序是否“未做其应该做的”仅仅是测试的一半&＃xff0c;测试的另一半是检查程序是否“做了其不应该做的”。

程序某部分存在更多错误的可能性&＃xff0c;与该部分已发现错误的数量成正比。

至少编写足够的测试用例&＃xff0c;使得每一种可能均被测试&＃xff0c;每个入口点都至少被调用一次。

经验证明&＃xff0c;考虑了边界条件的测试用例与其他没有考虑边界条件的测试用例相比&＃xff0c;具有更高的测试回报率。所谓边界条件&＃xff0c;是指输入和输出等价类中那些恰好处于边界、或超过边界或在边界以下的状态。

错误猜测&＃xff0c;是一种通过举出测试用例&＃xff0c;找出程序漏洞的方法。

模块&＃xff08;单元&＃xff09;测试&＃xff1a;是对程序中的单个子程序、子程序或过程进行测试的过程。

系统测试&＃xff1a;将系统或程序与其初始目标进行比较&＃xff0c;包含两方面的含义1、系统测试并不局限于系统&＃xff0c;如果产品是一个程序&＃xff0c;那么系统测试就是一个视图说明程序作为一个整体是如何不满足其目标的额过程。2、根据定义&＃xff0c;如果产品没有一组书面的、可度量的目标&＃xff0c;系统测试也就无法进行。

容量测试&＃xff1a;使程序经受大容量数据的检验&＃xff0c;其目的是为了证明程序不能处理目标文档中规定的数据容量。

强度测试&＃xff1a;使程序承受高负载或强度的检验&＃xff0c;所谓高强度是指在很短的时间间隔内达到的数据或操作的数量峰值。

易用测试&＃xff1a;发现人为因素或易用性问题。&＃xff08;用户智力、背景、输入输出是否简介有效、错误诊断是否直接、语法风格问题、信息是否冗余不利于安全、确认信息是否需要&＃xff09;

安全性测试&＃xff1a;是否达到安全目标。

可恢复性测试&＃xff1a;故意将程序错误的置入某个系统中&＃xff0c;判断系统是否可以从中恢复。

测试结束准则&＃xff1a;1、用完了安排的测试时间后&＃xff0c;测试便结束2、当执行完所有的测试用例都没有发现错误&＃xff0c;测试便结束。

调试&＃xff1a;是执行一次成功的测试之后要进行的工作。

所有的测试都是基于模型。

不要将实验与测试混淆起来。

威胁建模&＃xff1a;威胁模型就象功能计划或设计文档一样&＃xff0c;是一种规格说明。而最大的不同在于威胁模型的意图是找出一个应用程序能被攻击的所有可能的方法&＃xff0c;然后根据概率和可能的危害来排优先级。好的威胁建模需要分析和调研技能—这两种技能使得测试在这过程中很适用。

测试用例的设计&＃xff1a;

在实际测试过程中的心得&＃xff1a;

1、许多同学对于题目没有读的很严谨&＃xff0c;在输出上没有严格按照规范&＃xff0c;输出错误是严格判错的。

2、有一个非常重要的问题是&＃xff0c;对于边界条件没有把握好&＃xff0c;我设计的每一种情况的边界情况考察2次&＃xff0c;较多同学没有做好这一项&＃xff0c;可能是时间比较紧&＃xff0c;另外就是没有养成良好的测试和思考习惯&＃xff0c;有的溢出、有的呈现出错误的结果等等。

3、对于程序输入值&＃xff0c;有同学没有考虑输入完全错误和输入越界的情况。

4、还有同学图省事&＃xff0c;简单的使用某些看似等价的语句&＃xff0c;一测试&＃xff0c;立刻原形毕露。

测试完毕后的对自己程序设计的反思&＃xff1a;

1、要严格考察输出是否满足程序功能需求。

2、对于边界条件一定要小心&＃xff0c;要经过严密的思考&＃xff0c;在编程中也要注意思考的逻辑与程序逻辑的等价性。

3、对于程序的输入&＃xff0c;严防各种类型的输入。

4、每一个语句的有效性非常重要&＃xff0c;它们的流程在某些情况下是正常的&＃xff0c;在另一种情况下可能出现错误&＃xff0c;不能简单的等效之&＃xff08;有不同的触发因素&＃xff1a;环境变量、特殊的值&＃xff09;。

5、软件测试是非常重要的一个环节&＃xff0c;测试别人的程序&＃xff0c;能够提高自己的编程意识。软件测试是非常严谨的&＃xff0c;不容出错的。

 　　程序员有时候犯的最大错误&＃xff0c;不是说写错了某个程序&＃xff0c;而是当程序出错后&＃xff0c;简单的调试成功&＃xff0c;或者在外力下被迫调试成功&＃xff0c;就再没有对出错的原因进行深入的分析&＃xff0c;这样做没有从思想和方法上防止类似的情况发生。如果我们换一个思考的角度&＃xff0c;通过不断调试自己或别人的程序&＃xff0c;从反面来思考&＃xff0c;是否对我们的编程具有一定的“前瞻性思考”呢&＃xff1f; 

　　我们有时候总是说&＃xff0c;自己工资不够高&＃xff0c;现在还是码农&＃xff0c;是否是因为我们缺乏优秀的思维角度&＃xff0c;不具有这样的一种“前瞻性思考”呢&＃xff1f;是否也应该从此处来反省我们的程序员之路&＃xff1f;

最后附上微软的聘人标准&＃xff1a;

   问题的分析和解决能力&＃xff1a;这个能力对测试人员非常重要&＃xff0c;因为对问题进行解剖和找出问题的症结是提高产品质量的关键。 

    面向客户的创新&＃xff1a;应聘者是否以客户为本&＃xff0c;是否能够充分理解软件如何才能帮助客户解决问题&＃xff0c;并对此充满兴趣和热情。 

    精湛的技术&＃xff1a;我们注重的是应聘者是否通晓网络和操作系统&＃xff0c;不仅能写代码&＃xff0c;而且能够优化代码。 

    项目管理&＃xff1a;对测试人员来说&＃xff0c;这个能力是指如何有效支配个人的时间&＃xff0c;以及如何策划和确保一个有许多互相牵制成分的计划得以按时完成。 

    对质量的执着追求&＃xff1a;如果不具备这个素质&＃xff0c;应聘者就无法胜任任何工程技术工作&＃xff0c;更不必说测试工作了。 

    战略远见&＃xff1a;新员工刚开始这方面比较弱&＃xff0c;但是如果我们旨在聘用能够帮助我们找到突破 

     自信&＃xff1a;在微软&＃xff0c;测试人员找出的软件错误并不一定都能得到修正&＃xff0c;在必要时&＃xff0c;测试人员需要有自信而去据理力争。 

    冲击力和影响力&＃xff1a;影响力来自于自信和经验&＃xff0c;冲击力来自于敢于革新。多数应聘者在谈到如何给自己的公司带来变革&＃xff0c;或者如何在学校带领团队出色地完成项目时&＃xff0c;都会体现这个特征。 

    跨界合作&＃xff1a;创新往往来之于各部门之间的合作&＃xff0c;只顾埋头自己的项目&＃xff0c;甘做井底之蛙的员工是不会成功的。 

人际意识&＃xff1a;主要指自我意识&＃xff0c;许多优秀的应聘候选人能够认识到自己的不足之处&＃xff0c;并且知道如何不断地提高自己&＃xff0c;也就是有一个不断提升自身素质的计划。 

很多人对职业发展有困惑&＃xff0c;现在附上微软的职业发展轨道>

结合现在学长学姐这几年的职业发展&＃xff0c;我想指出的是&＃xff0c;其实自己的职业发展&＃xff0c;依赖于你所选择的公司。你自己的能动性&＃xff0c;并没有你想象的那么大&＃xff0c;除非你想一直跳槽下去。