《软件测试心得》PPT课件.ppt

软件测试经验与心得交流,唐荣军Office Phone:+86-755-33956551,1.软件测试概述,1.1经典V模型介绍这是一个非常单纯、非常理想的一元线性模型，正是因为它太理想、太单纯了，以至于都无法应用于软件工程实践，几乎被业界所抛弃，只有在软件工程的教科书或培训文档上还能找到这个模型，偶尔被人们提及，也属于被批驳的对象。一元线性模型是人类最容易掌握并能熟练运用的一种思维方法，人们总是把一个复杂的非线性问题转化为一系列的线性问题，然后逐个求解，高等数学里的偏微分就是这样一种思想。重温这个模型有助于我们理解软件工程里最核心的东西！,需求开发,验收测试,系统测试,高层设计,集成测试,详细设计,单元测试,编码实现,1.软件测试概述,1.2我们所处的位置阿尔卡特流程把手机产品开发定义为OR、DR0、DR1、DR2、DR3和DR4等几个关键里程碑（Milestone），DR是英文Delivery Review的缩写。跟软件有关系的三个关键里程碑（Milestone）是DR1、DR2和DR4：DR1解决“做什么”和“不做什么”的问题，软件需求开发及功能定义要在这个阶段完成DR2是full feature全部开发结束DR4是软件交付生产，也就是说在DR4的时候要能够发布量产软件,需求变更,1.软件测试概述,1.3我们所采取的策略V模型所展现的是一种把软件工程化整为零、分而治之的战略艺术，单元测试、集成测试、系统测试和验收测试体现了“由小到大”、“由内至外”和“循序渐进”的思想！下面把单元测试称为单个功能测试。单个功能测试的粒度最小，由开发工程师自行完成测试，在软件工程学的定义里，属于白盒测试的范畴，我们现在使用simulation加手工来完成，离这个理论定义是有差距的。集成测试是连接单个功能测试与系统测试的桥梁，以后将由新成立的integration team来完成。系统测试的粒度最大，由软件部的Test Branch采用黑盒测试方式完成，主要的测试依据是软件需求文档或者Feature List。验收测试的内容跟系统测试非常接近，主要区别是测试人员不同，在软件工程之定义里，验收测试一般由上帝（客户）来执行，对JRD软件部来说，TCT的QA软件测试组就是我们的上帝！,1.软件测试概述,1.4测试流程规范测试计划（Test Plan）应该明确测试的范围，即测什么，如果说不清楚测什么，至少要说清楚不测什么，否则测试将是苦海无边，回头也找不到岸；计划还应该明确测试项目在时间上怎么安排，先测什么，后测什么；第二步应该明确测试的方法，即怎么样测，要对在第一步中所确定的测试项目进行展开，明确测试的需求并编制测试规范（Test Specification）及测试用例（Test Case）；第三步执行测试用例（Test Case）；最后要撰写测试报告（Test Report），目的是使软件缺陷能够得到迅速的修复，同时也使相关的部门或同事能够清楚地了解软件开发的进展情况，软件测试报告并无固定的格式，只要能够完整、清楚地反映当前的测试情况就可以了。撰写测试报告时可以参考我们在学校时写的物理或者化学试验报告的格式，这些报告的格式是非常严谨的！,1.软件测试概述,1.5手机软件质量的属性1.6手机软件质量的要素市场角度：用户最关注的、能够成为买点的功能研发角度：对软件整体质量产生重大影响的,1.软件测试概述,1.5手机软件缺陷的判定依据软件需求定义文档相关国际标准、国家标准、行业标准没有在需求文档中写明的隐含的约定俗成 是表示选中，还是表示未选中？全世界人民都在用表示肯定，用表示否定，可是搞不懂为什么微软就是要弄出这种反人类行为没有谁规定手机必须要支持关机闹钟，但如果你现在设计一款无关机闹钟的手机，那无疑是在给自己掘坟墓，当然，如果有人就好这一口，那另当别论2003年7月我们在新疆作调研的时候，还碰到有用户拿着5288问我们，“可不可以给我焊个马达？”看着他那望穿秋水的眼神，我却只能残酷地告诉他：曾经有一个马达摆在我们面前，可是我们认为不重要，就把它去掉了，直到你来投诉的时候，我们才后悔莫及，如果你以后能再买我们的手机，我们一定设计一个马达，如果要给这个马达加上一个期限，我希望它能振动一万年！后面的这两个案例已经超出了软件测试的范畴，我把它们写在这里是期望能够给大家提供一个更为广阔的思路！,1.软件测试概述,1.7手机软件测试理念手机开发的三个关键要素是：质量（Quality）、成本（Cost）和上市时间（Time to Market），这三个要素相互制约和影响，一款成功的手机开发，往往是这三个要素的完美折衷。测试只能证明软件存在缺陷（Defect），却不能证明不存在缺陷（Defect），“彻底地测试”是不现实的，要考虑上市时间和测试成本等因素的限制，不允许无休止的测试，我们应当祈祷：软件缺陷在用户换掉他的手机之前一直没有机会发作！并非所有测试出来的问题都会被修复。手机软件是属于嵌入式的，软件的运行跟硬件结合得非常紧密，因此在手机软件测试的过程中，硬件是不能忽略的一个因素。测试是为了证明手机软件存在错误，而不是为了证明软件没有错误，所以成功的测试在于发现了迄今为止没有发现的问题。,2.系统测试概述,2.1功能测试2.2健壮性测试2.3矩阵测试2.4UI测试2.5兼容性测试（IOT）2.6性能测试2.7临界测试2.8可靠性测试,2.系统测试概述,2.1功能测试这是手机软件测试工作中最核心和最基本的一项测试，该测试的主要内容是检查软件是否符合需求定义，并通过构造正常的操作来检查手机的动作是否正确；在这个测试里，正确性是最最重要的手机软件质量要素。手机的功能（若无特别指明，均指软件功能）按照可见性可以分为两类：显性功能和隐性功能。隐性功能就好像是地下党员，你在共产党员的花名册里永远找不到他们的名字。显性功能：指在菜单里可以看得到的功能隐性功能：指在菜单里看不到的功能举个例子，电话本的显性功能有增加、编辑、删除、拨打等，这些功能可以在电话本的菜单里面看得到，姓名列表排序则属于一个隐性功能，因为在电话本的菜单里没有这样一个子菜单，但它却是一个实实在在的功能在实际的测试过程中，显性功能通过菜单遍历可以很容易地进行无遗漏的测试，但是隐性功能却很容易为我们所忽略！一个有效的解决办法是去检查软件的功能定义列表（Feature List），从这个列表里面找出那些隐性的功能。,2.系统测试概述,2.2健壮性测试这项测试主要是检查手机软件对异常操作的容错能力，异常操作通常要考虑异常输入操作及异常条件两个方面小时候看电影发现，日本鬼子往往一枪就over了，八路军打一枪顶多流几滴血，仍然能够冲锋陷阵，这说明八路军的健壮性比日本鬼子的健壮性要强手机软件的很多功能的实现是有很多隐含的条件的，在健壮性测试中，要检查当这些条件不满足的时候手机的反应我们举一个GD85-1的例子，动感无限自动更新的功能是基于GPRS实现的，当使用一张不支持GPRS的SIM卡在GD85-1上执行自动更新时手机会重启橘生淮南为之橘，橘生淮北为之枳，这说明橘的健壮性太差,2.系统测试概述,2.3矩阵测试矩阵测试是使手机处于一个特定的状态，然后构造一个异步事件，检查当这个异步事件发生时手机软件的性能根据事件的来源，异步事件可以分为外部事件和内部事件外部事件举例：SMS到达、来电呼入、CB-SMS到达、非关机状态拔电池、插入耳机等内部事件举例：闹钟响闹、日程表事件提示、低电告警、自动关机等,2.系统测试概述,2.4UI测试这里主要测试手机软件的易用性、用户界面的友好性及美学性，我们应该把诺基亚定为自己的榜样，学习他们UI设计的简洁性，我们应当以西门子为榜样，学习他们UI的严谨性。傻瓜相机在问世之前，摄影只是少数人手机耐以炫耀的玩物，光圈、快门、景深等深奥的摄影技能摧残了无数摄影爱好者那颗火热的心；自从傻瓜相机一声炮响，仿佛1842共产党宣言的发表，从此轰轰烈烈的摄影运动迅速传遍了五大州四大洋。旧时王榭堂前燕，飞入寻常百姓家。傻瓜手机是我们UI设计的终极目标！UI测试遵循的原则：求美原则，检查在UI的布局里，各种要素是否能传达一种美感，布局是否合理，色彩是否合谐，”科技美学化“不是一句挂在墙上印在纸上的口号，而应该成为实实在在的行动正确性原则一致性原则，同样的一个功能的UI在不同的情景（scenario）所呈现的方式应该保持一致普遍性原则,2.系统测试概述,2.5兼容性测试（IOT）测试手机对不同地区SIM卡的兼容能力，这部分尤其在STK中表现的很突出，我们经常可以发现一些异地的SIM卡中的STK菜单中会有乱码，这就是兼容性不好造成的2006年7月，成都客服中心报告：成都郊县双流、都江堰地区M360在使用移动动感地带新卡2.0版本（64K）时出现“开机断电”故障；经调查，除M360外，还有398和U58也有这样的问题，而其它机型如E787未见本故障，固可初步判定为SIM不匹配问题。2004年11月，我们在印度东北部的昌吉达尔做SIM的兼容性测试，发现Q515在点播SPICE的SIM卡中任何一条STK的内容之后，屏幕就一直显示一个沙漏动画，按任意键手机都没有反应。2005年3月，在印度作IOT测试时发现在使用Air Tel的SIM卡时无法正确显示网络运行商的名称。测试我们的手机跟其它品牌手机的数据交换能力，例如，使用NOKIA手机存储一个SIM卡电话本记录，当使用MTK平台手机读取时，发现姓名后面会显示有一个问号两只手表的困惑，当你手上戴了两只手表的时候，你往往无法确定现在是几点几分。如果这个数据是要经过网络传输的，那么我们应该假定数据在传输过程中不会被网络所污染，例如联通和移动的网络之间本身就存在兼容性问题。兼容性的商业游戏规则是弱者应当努力与强者兼容，而强者应当努力避免被兼容。GE18-1发送一个有相片的MMS给NOKIA6230，6230不支持该相片在MMS中的显示，这是典型的强者不兼容弱者的案例。,2.系统测试概述,2.6性能测试性能测试从负荷及容量两个方面考虑，有些教材把这个测试叫做压力测试，内容是一样的，换汤不换药考察手机在高负荷状态下的运行情况。所谓高负荷，就是多个功能快同时在运行，使手机CPU资源高负荷地运转。考察手机在满容量状态下的运行情况。在测试前，应设法使手机所有的用户内存全部存满，然后在进行一些相应的操作，观察手机的性能情况。2.7临界测试所谓临界测试，就是指数据在保存、删除、传送、发送时或者这些动作即将发生时，考察手机软件对外部干扰事件的处理情况。例如，MTK平台的某些机型在即将删除一条短信息时收到一条新信息，但删除的却不是刚刚选定的那条信息，而是刚刚收到的这条新信息！,2.系统测试概述,2.8可靠性测试可靠性是指在一定的环境下、在给定的时间里，手机软件不发生故障的概率。可靠性本来是硬件领域的术语，比如某个电子设备在刚开始工作时挺好的，但由于器件在工作中其物理性质会发生变化（如发热），慢慢地系统的功能或性能就会失常。软件在运行过程中不会发生象硬件那样的物理变化，但是并不代表软件现在运行是正确的，那它一辈子运行也是正确的，说不定哪一天它就不正常了。很多小朋友在小的时候是个好孩子，但并不代表他老了还是个好爷爷，“小学宝贝蛋，中学靠边站，大学吃鸭蛋”，这样的情况也不时不可能！软件中司空见惯的“内存泄漏”与”误差积累“等问题不是一时办会儿就能测试出来的，需要一个较长时间的观察。时隐时现的问题一般都属于可靠性问题，纠错的成本非常高。当工程师十万火急地感到问题现场时，问题消失了；等工程师离开后，问题又出现了，仿佛敌进我退一般！内部人员试用是执行可靠性测试的有用的方法，但一定要管理好，否则试用就变成滥用了。,3.黑盒测试介绍,3.1黑盒测试模型黑盒测试不需要去关注手机软件的整体架构及其编码细则，只需要通过构造一些合理的输入（操作），来观察手机的实际结果或现象（输出），从而判定是否存在问题，需求文档是黑盒测试的主要依据。在一个功能的实现过程中，可能存在这一些隐含的制约条件，它们影响着期望结果或者是输出。“牛吃的是草，挤出的是奶”，这个命题有一个制约条件，鲁迅先生虽然没有说明，但我们应该明白，这里是特指母牛，你就是把公牛捏死了也挤不出奶来！问题就是输出跟期望结果的差距，需要注意的是，当立场不同时，对问题的定性也可能不一样，开发人员站在研发的角度说这不是问题，测试人员站在质量的角度说这是问题，用户说谁请我吃饭我就支持谁。,3.黑盒测试介绍,3.1两个实用的黑盒技术输入的构造通常会采用穷举的思想，可是穷举的空间如果非常大，那将使人十分的沮丧，还不如回家象张恒一样数星星，说不定还能数出个天文学家来。有两种手段可以有效地缩小穷举空间：等价划分边界值分析等价划分：等价区间的概念可以这样表述，设（A，B）是命题f(x)的一个等价区间，在（A，B）中任意取值x1进行测试：如果f(x1)错误，那么f(x)在整个区间（A，B）上都将出错；如果f(x1)正确，那么f(x)在整个区间（A，B）上都将正确。等价划分思想的关键是找到一个合适的标准去划分等价区间！新中国成立不久，有一位外国记者问周恩来总理：总理先生，请问你们中国有几个厕所？意思是新中国一穷二白，除了厕所多一点之外没有什么别的财富。周恩来回答说：记者先生，我们中国只有两个厕所，一个是男厕所，另一个是女厕所。周恩来总理已经把等价划分艺术用到了炉火纯青的境界，是我们学习的榜样！边界值分析，“缺陷遗漏在角落里，聚集在边界上”，边界值分析是对等价划分的一种有效补充。,4.撰写高质量的测试文档,4.1软件测试中的关键文档测试计划（Test Plan）测试用例（Test Case）/测试规范（Test Specification）测试报告（Test Report）缺陷报告（Bug Report）古代中国的科技举世辉煌，秦帝国修灵渠、直道，其地理知识超越了它的时代600年；越王宝剑的制造工艺，超越了青铜器材的物理极限；宋代的科技创新举世瞩目！可惜这些宝贵的科技财富很多都没有流传下来，因为古人不喜欢写文档！我们今天只能望历史而一声叹息！中华民族有师承的传统，武艺高强的师傅总是在自己还剩下一口气的时候把看家本领教给徒弟，说：“徒儿，师傅只能打一遍，你用心看吧，能学多少就算多少。”打完之后师傅便悲壮死去，失望的徒弟翻遍师傅的屋里墙外，掘地三尺也找不出一页武功秘籍！多少绝世武功因此失传！改变这种不爱写文档的习惯，要从我们这一代做起，热爱写文档，写高质量的文档！,4.撰写高质量的测试文档,4.2测试计划制定一个完整、规范的测试计划对每一个测试管理人员来说是非常重要的！目前JRD是由软件项目经理（SPM）来制定测试计划的。测试计划应该至少包括如下之内容：概述（Overview）文档通常都是以概述开头的，测试计划在概述里应该要写明该测试是做什么的，把测试的范围定下来，要测什么，不测什么。测试目标（Test Goals）和发布标准（Release Criteria）一般说来，测试计划以定要写明测试的最终目标（Test Goals），必须使自己和别人明白为什么必须做这个测试，该测试需要达到的目的是什么。另外，测试计划还需要明确定义发布标准（Release Criteria）的范围，如果有需要，可能还需要定义每一个发布标准定义在DR2、DR3和DR4个阶段的目标。测试方法描述（Testing Approach/Description）从项目总体的角度定义软件的测试方法，如我们在前面讲过的单个功能测试、集成测试、系统测试，以及没有讲的附件测试、专项测试、外场测试（Field Trial)。测试进度表（Testing Schedule）定义在DR各个阶段的详细进度，该进度表依赖于项目总进度及软件开发进度。测试资源（Testing Resource）,4.撰写高质量的测试文档,4.3为什么有人不喜欢写测试计划不知道怎么去写，要写些什么样的内容、要写成什么样的格式，这些都不知道。现在我们从阿尔卡特搬过来很多文档，阿尔卡特的文档之多简直到了汗牛充栋、洛阳纸贵的地步，我们应该如饥似渴地吸收这些文档的思想，参考他们的格式和模板，迅速补充我们自身的不足。对手机软件测试本身没有深刻和全面的理解，不清楚手机软件测试到底要做哪些工作，不知道手机软件测试的范围，从而无法对测试工作进行阶段性分解（WBS）。我们可以借鉴一下现代项目管理的一些理念，首先定义出手机软件测试的范围及边界，其次对这些工作内容按照项目总体进度进行关键性的划分，最后对各项内容逐级分解到具体的测试，这样就可以把手机软件测试的大概脉络给理清了。中国有句俗话，叫做“计划赶不上变化“，很多提前作好的计划在实际的执行过程中往往变成了一张废纸！久而久之，也没有人再愿意再做计划了。造成这样的原因有：计划本身做得不周全，或者是为了应付某个检查而随意编制计划。前年公司进行ISO质量体系资格复审，无数的项目组成员补写开发计划，加班之疯狂可惊天地泣鬼神！实施中发生了变化，但计划却没有及时地修正。计划是相对的，变化是绝对的，既然时时事事处处都充满着变数，那计划的意义何在呢？回答是：计划为控制事物向预期方向发展提供了可能！没有计划的事物其发展就象“身如柳絮随风飘，飘到哪就是哪”，其运动方向是发散的，跟分子在做不朗运动一样，不具有收敛的性质！变化是相对于计划而言的，没有计划，变化则无从谈起。,4.撰写高质量的测试文档,4.4测试用例（Test Case）编号所有的测试用例都应该进行编号，以便集中管理，这个编号应该是唯一的，不能发生重复标题简单描述这个用例要测试的功能用例目的描述该测试用例的目的前提条件描述在执行该测试用例前需要满足的前提条件输入描述用于该测试用例的操作输入期望结果描述该测试用例的期望输出,4.撰写高质量的测试文档,4.5测试用例示例,4.撰写高质量的测试文档,4.6测试报告中学物理的第一个实验是用欧姆表测量电阻，作完实验后老师教我们写实验报告，内容有实验目的、实验地点、实验时间、实验人员、实验原理、实验器材、实验方法、实验数据和实验结论一大堆！一个欧姆表加一个滑动变阻器居然能够弄出这么一个长篇大论，洋洋洒洒上千言，比写作文还有成就感，简直令我惊诧不已！学校的实验报告在格式上是非常严谨的，我们在写测试报告时可以参考这样的格式。测试报告可能有很多其他部门的同事来阅读，其目的是使软件项目干系人能够清楚地了解当前的进展情况，是软件缺陷能够得到迅速的修复！因此，测试报告的撰写应该提高到严谨治学的高度上来！不是只有发现问题的时候才写测试报告，没有发现问题的时候更要写测试报告，而且要大写特写，好好地宣传一下我们的软件质量，趁机拿这个报告让项目经理请测试人员吃饭！,4.撰写高质量的测试文档,4.7实验报告示例,4.撰写高质量的测试文档,4.8缺陷报告软件问题在软件工程里的学名叫做软件缺陷（Defect），它还有一个非常形象的英文名字BUG。缺陷报告跟刚才介绍的测试报告是有区别的，测试报告是一份宏观的整体信息，一般由测试管理人员编制和发布，缺陷报告一般是针对某个具体的问题，由测试人员书写和发出。撰写缺陷报告的目的是为了使bug能够迅速得到修复，因此，测试人员对测试报告撰写的好坏会直接影响到软件开发人员对bug的修复！如果一个缺陷报告撰写得不好，开发人员就不能有效地从缺陷报告中得到关于bug的正确而详细的信息，导致开发人员与测试人员反反复复的沟通，白白浪费了宝贵的时间，更为严重的是有可能导致这个缺陷报告会因为别人看不懂而被扔到一边！一个缺陷报告至少要包括下面的基本要点，这里只列出了最关键的要点，实际上还有很多。标题（Title），标题是需要用一句最简单的话把这个软件问题说清楚测试步骤（Test Steps），说明这个软件问题是经过了一些什么样的步骤或什么样的操作后发现的。测试步骤要写得有条有理，不要眉毛胡子一把抓，通常以按键的动作、画面状态的迁移来划分操作步骤，测试步骤写得越详细越好！严重度（Severity）与优先级（Priority）严重度：A、B、C优先级：0-立即处理、1-顺序处理、2-低优先级软件版本及测试人员,4.撰写高质量的测试文档,4.9缺陷报告实例PVCS TRACKER,5.关于不稳定问题的分析,5.1问题不稳定的现象在手机A上能够再现的问题却不能够在手机B上再现2002年3188上市后，客服接收到相当数量的用户投诉3188在关机充电时指示灯呈红绿两色交替闪烁，研发与生产车间组织了大批量的充电专项试验，却一直无法复现这个问题。2005年5月份，GD18-1在生产车间爆发“密码错误”问题：手机在MMI生产测试后恢复出厂设置输入密码时提示“密码错误”，测试完毕重新开机显示“请输入NSP码”；在线生产该问题再现比率1.5，OQC抽检批次再现率更是高达11.73。重新下载软件之后，问题无法再现张三能够再现，李四却不能再现GC20在116版本内部测试时发现在写短消息时快速地输入文字会导致手机重启，这是一个稳定的问题，但另外一名测试员在审核这个问题的时候却怎么样也无法再现这个问题。换张SIM卡之后问题无法再现GC20在116版本内部测试时报告了一个STK问题，使用的SIM卡发现在STK应用中会显示“口入口效”，但使用的SIM确怎么也无法再现这个问题,5.关于不稳定问题的分析,5.2问题不能稳定再现的原因跟手机硬件或附件有关3188充电指示灯异常是由伟业顺和股份的充电器涓流过低引起的，伟业顺充电器为10毫安，股份充电器为20毫安，而根据3188电源系统的设计，这个涓流要达到30毫安。GD18-1密码错误问题则是由于FLASH批量不良造成的；MB01有段时间也是发现有不稳定死机现象，后来调查发现是由于FLASH有气泡造成的。STK“口入口效”虽然使用的都是惠州的全球通SIM卡，而且尽管其STK的菜单也一模一样，但那两张SIM卡可能是来自不同的提供商，所以STK问题一定要使用原卡核对跟历史操作记录有关系，手机软件是一个有记忆效应的系统，历史操作产生的数据或信息会被手机存储起来，从而对后面的动作产生影响。重新下载软件会擦除这些历史数据或信息。小日本无论现在怎么表现，都无法改观他们在亚洲人民心目中的形象，这是因为小日本在历史上的滔天罪行已经被亚洲人民深深地记忆在心里！跟操作员本身的因素有关，GC20写短消息输入问题重启需要很快的速度，换一个输入速度慢的操作员是不能再现这个问题的。,5.关于不稳定问题的分析,5.3发现不稳定的问题怎么办首先要确定这是不是由于非软件的因素造成的。多用几部手机去尝试再现这个问题，如果是纯软件问题，它应该在任何一部手机上都可以再现的，这里假设这个问题跟历史操作记录无关。使用历史追溯法去再现这个问题使用一些辅助工具去查找原因我们的测试人员发现MTK平台手机在试图打开某些电子邮件的时候会重启，经过长期的观察，我们发现这些电的标题都是乱码，由于手机打不开这些邮件，所以我们使用META工具把一封这样的电子邮件读出来，然后用outlook打开，发现这是一封来自163邮件系统的退信。我们猜测：MTK平台手机在试图打开163邮件系统的退信的时候会重启。于是我们构造一个用例去验证这个猜想：在手机中配置163邮件系统发送一个邮件到一个非法地址收取163邮件系统的退信，并打开它就这样，我们终于找到了稳定再现电子邮件重启的方法一条原则：大胆假设，小心求证,6.测试心理学,6.1测试与开发的对立和统一测试的目的是发现问题，所以测试是破坏性的，而开发是建设性的，就好像开发人员在砌墙，测试人员在推墙一样，测试和开发在这一点上是对立的，开发人员总是愿意欣赏软件的成功之处，不愿意看到他的失败之处。据报道，微软的开发人员和测试人员的比例是1:3左右，但是在中国不是这样的，在深圳JRD，开发人员与测试人员的比例为7:1。从学历上来说，目前测试与开发也是不对称的。开发队伍几乎全是本科及本科以上学历，而测试人员绝大部分都是中专学历。在我国的大部分企业里，软件测试是不受重视的，老板们都相信高质量的软件是代码写出来的，跟测试无关。开发人员大多数是瞧不起测试人员的，虽然他们心里清楚自己的程序离不开测试！绝大部分的测试人员在面对开发人员时都有一种自卑心理，即使是在给开发人员报告问题时也是抱着一种请教的心态，这是不正确的！测试和开发的最终目标都是为了高质量的产品，从这一点来讲，测试和开发又是统一的。,6.测试心理学,6.2避免与开发人员产生矛盾在书写测试报告时不要带有使用过多的主观色彩的词语，即使别人的软件问题很多，也不要到处嚷，一个报告抄送给公司所有大大小小的领导，恨不得天下人都知道。书写测试报告时一定要做到客观，不要只报忧不报喜。例如，一共测试了1000个用例，其中990个获得通过，有10测试用例失败，那一定要在测试报告上写明有990个测试用例成功了，不要只写那10个失败，否则会让别人觉得你只做了10测试用例，每一个都失败了，100出错，那样会显得别人的软件跟垃圾一样！测试人员在书写bug报告时一定要详细，不要遗漏关键信息，本来别人就不愿意你说他的软件有错误，结果他按照你的步骤又不能再现问题，很容易激怒他使他对你破口大骂。测试人员在书写bug报告时应该只描述问题的现象，不要给问题下定性的结论。在评定稳定的严重度时，更不要夸大，A、B、C的判定一定要公正。,7.结束语,一位不知名的网友创作这首写给软件质量人员的赞美诗，我觉得我们的软件测试人员非常的不容易，软件成功交付的时候受到表扬的往往是开发人员，发生软件质量事故的时候被批评的往往是测试人员，我觉得我们应该要感谢所有的软件测试人员和质检人员，而不应该等到发生了软件质量事故的时候想起拿她们来出出气，特把这首诗摘抄如下，与诸君共勉！诗中的“狼人”和“银弹”是软件工程中两个著名的典故，寓意非常的深刻。,晚上八九点钟的太阳 献给软件测试和质保人员我更喜爱晚上八九点钟的太阳，虽然人们都已把他遗忘，但他还是艰难地悬挂在天上。我更喜爱晚上八九点钟的太阳，因为他将奏出黎明的交响。没有他又怎会呼唤出一片明亮？,我更喜爱晚上八九点钟的太阳，因为他会化成早上的朝阳。没有他又怎会有什么希望？我更喜爱晚上八九点钟的太阳，因为他是上帝的臂膀。没有他，又怎会创造万物的光芒。,狼人望月嚎叫，它知道月亮映出的太阳之光，终将化为银弹，射入它的胸膛。我更喜爱晚上八九点种的太阳。,8.相信未来,1968年，诗人食指写下了这首经典之作，激励着在那个非常年代里还没有彻底绝望的人们！38过去了，我们仍然还被这首诗感动着，并从中读出带泪的乐观和深藏痛苦的信念！李东生总裁在鹰的重生里写道：这次蜕变是痛苦的，对企业，对全体员工，对我本人都一样。但为了企业的生存，为了实现我们发展目标，我们必须要经历这场历练！像鹰的蜕变一样，重新开启我们企业新的生命周期，在实现我们的愿景“成为受人尊敬和最具创新能力的全球领先企业”的过程中，找回我们的信心、尊严和荣誉！,相信未来 献给还没有绝望的奋斗者当蜘蛛网无情地查封了我的炉台当灰烬的余烟叹息着贫困的悲哀我依然固执地铺平失望的灰烬用美丽的雪花写下：相信未来当我的紫葡萄化为深秋的露水当我的鲜花依偎在别人的情怀我依然固执地用凝霜的枯藤在凄凉的大地上写下：相信未来,我要用手指向涌向天边的排浪我要用手掌那托起太阳的大海摇曳着曙光的那枚温暖漂亮的笔杆用孩子的笔体写下：相信未来我之所以坚定地相信是因为我相信人们的眼睛她有拨开历史风尘的睫毛她有看透岁月篇章的瞳孔,