1、目录一软件测试从零开始51. 1引言62. 2测试准备工作61. 2.1向有经验的测试人员学习61.2.2阅读软件测试的相关书籍61.2.3走读缺陷跟踪库中的问题报告单61.2.4走读相关产品的历史测试用例71.2.5学习产品相关的业务知识71.3识别测试需求71.3.1主动获取需求71.3.2确认需求的优先级81.3.3参加开发小组的邮件群组81.3.4与开发人员为邻81.4测试用例设计91.4.1测试用例的根本格式91.4.2重用同类型工程的测试用例91.4.3利用已有的软件Checklist101.4.4加强测试用例的评审101.4.5定义测试用例的执行顺序101.5测试用例执行101.
2、5.1搭建软件测试环境，执行测试用例101.5.2测试执行过程应注意的问题111.5.3及时更新测试用例111. 5.4提交一份优秀的问题报告单111.6测试结果分析121.7总结12二软件测试的常识122.1引言122. 2软件测试常识132. 2.1测试是不完全的（测试不完全）132. 2.2测试具有免疫性（软件缺陷免疫性）132. 2.3测试是“泛型概念（全程测试）132. 2.480-20原则142. 2.5为效益而测试142. 2.6缺陷的必然性142. 2.7软件测试必须有预期结果142. 2.8软件测试的意义-事后分析142. 2.9结论：15三浅谈软件开发中的重点事项153.
3、1工程设计153. 2设计变化和需求变化153. 3代码编写163. 3.1源程序文件结构163. 3.2界面设计风格的一致性163. 3.3编辑风格163.3.4命名标准173. 4BUG修补173. 5开发人员的测试17四软件测试的若干问题174. 1前言185. 2博弈的各方186. 3测试的过程187. 4测试所具备的素质198. 5自动化测试199. 6测试的误区19五浅谈功能测试用例模板设计1910. 1Excel模版2011. 2测试用例状态转换分析21六如何提高软件质量2212. 1什么是质量2213. 2流程对质量的奉献2314. 3流程与技术2515. 4全面质量管理251
4、6. 5关注测试2717. 6成功的铁三角2718. 7国际上流行的质量标准2819. 8如何起步29七ISO和CMM,我们该选择谁2920. 1管理水平的适用性3021. 2复杂度的适用性307. 2.1何谓研发过程复杂度308. 2.2何谓组织机构复杂度307. 3量化管理的适用性上317.4结论32八如何做好单元测试328.1前言328. 2组织结构应该保证测试组参与单元测试338. 3加强单元测试流程标准性338. 3.1制订单元测试的过程定义338. 3.2单元测试工作产品必须纳入配置管理348. 3.3必须制订覆盖率指标和质量目标来指导和验收单元测试348. 3.4加强详细设计文档
5、评审358. 4单元测试者技能的提高358. 4.1加强对单元测试人员的技能培训358. 4.2必须引入工具进行辅助368. 4.3单元测试者加强对被测软件的全面了解368. 5结尾36九漫谈人机界面测试369. 1一致性测试3710. 2信息反应测试379.3界面简洁性测试389.4界面美观度测试389.5用户动作性测试389.6行业标准测试399.7小结39十基于Web的系统测试方法3910.1功能测试4010.1.1链接测试4010.1.2表单测试4010.1.3Cookies测试4010.1.4设计语言测试4110.1.5数据库测试4110.2性能测试4110.2.1连接速度测试411
6、0.2.2负载测试4110.2.3压力测试4110.3可用性测试4210.3.1导航测试4210.3.2图形测试4210.3.3内容测试4210.3.4整体界面测试4210.4客户端兼容性测试4310.4.1平台测试4310.4.2浏览器测试4310. 5平安性测试4310.6总结43十一为盈利而测试44U.1引言4411.2什么是软件测试4411. 3六个误区4511. 3.1误区一:无视对正常输入的测试4511. 3.2误区二：无视设计阶段的参与与评估4512. 3.3误区三：无视测试方案与测试文档的建立及维护4511. 3.4误区四：无视缺陷的分析，报告及跟踪4511. 3.5误区五：错
7、误的测试目标及测试终止条件4512. 3.6误区六：不懂得合理调配使用测试人员的知识技能结构4611. 4软件质量与软件测试4611. 5软件测试的经济目的48U.5.1满足用户需求，提高产品的竞争力，最终提高产品的销售量4811.5.2尽早发现缺陷，降低后继质量本钱4811.6何时应当停止测试50十二整体性能测试剖析51十三性能测试工具之研究5513.1性能测试的意义5513.2性能测试工具综述5613.3性能测试工具的体系架构5713.4虚拟用户产生器Vugen5813.5Proxy二次捕获的问题5913. 6关联的问题6014. 7脚本的问题6215. 8Conductor和Player
8、局部6316. 9Conductor和Player的技术要点6317. 10数据分析工具Analysis6413. 11结束语64十四性能测试原理及性能测试实例分析6414. 1软件测试中的性能测试6414. 1.1性能测试的含义6514. 1.2性能测试的分解6514. 2一个性能测试实例6514. 2.1被测系统6514. 2.2对被测系统进行性能测试6718. 5总结70十五软件GUl测试中的关注点7119. 1不能不说的二个问题7115.1.1软件测试中的“二八原则7115.1.2软件黑盒测试解决的问题7115.2软件黑盒测试常见错误类型及说明7215.2.1用户界面错误7215.2.
9、2功能性7215.2.3人机交互7315.3命令结构和录入7715.3.1不一致性7715.3.2最优化7715.3.3菜单7815.4遗漏的命令7915.4.1状态转换7915.4.2危机预防7915.4.3由用户进行的错误处理8015.4.4其他问题8015.5程序僵化8115.5.1用户可调整性8115.5.2控制方式8215.6性能8215.6.1降低程序速度8315.6.2缓慢回应8315.6.3如何减少用户吞吐量8315.6.4反应拙劣8315.6.5没有提前输入8315.6.6没有给出某个操作会花很长时间的警告8315.6.7程序太多提示和询问8415.6.8尽量使用简单命令和提
10、示8415.7输出8415.7.1不能输出某种数据8415.7.2不能重定向输出8415.7.3与一个后续过程不兼容的格式8415.7.4必须输出的很少或很多8415.7.5不能控制输出布局8415.7.6荒唐的精度输出级别8515.7.7不能控制表或图的标记8515.7.8不能控制图形的缩放比例8515.8错误处理8515.8.1错误预防8515.8.2错误检测8615.8.3错误恢复8615.8.4边界相关的错误8715.8.5计算错误8815.9小结88十六软件测试技术8816.1软件测试基础8916.1.1测试目标8916.1.2测试原则8916.1.3可测试性9016.2测试用例设计
11、9116.3白盒测试9216.4根本路径测试9216. 4.1流图符号9217. 4.2环形复杂性9318. 4.3导出测试用例9319. 4.4图矩阵9516.5 控制结构测试9516. 5.1条件测试9517. 5.2数据流测试9718. 5.3循环测试9816.6 黑盒测试98一软件测试从零开始【摘要】本文面向软件测试新手，从测试前的准备工作、测试需求收集、测试用例设计、测试用例执行、测试结果分析几个方面给出建议和方法。鉴于国内的软件开发、测试不标准的现状，本文为软件测试新手提供了若干个软件测试的关注点。【关键词】软件测试、测试用例、测试需求、测试结果分析1.1引言几年前，从学校毕业后，
12、第一份工作就是软件测试。那时候，国内的软件企业大多对软件测试还没有什么概念，书店里除了郑人杰编写的计算机软件测试技术之外，几乎没有其它的软件测试相关书籍，软件测试仅仅在软件工程的教材中作为一个章节列出来，因此，我对软件测试一无所知。不过，在正式走上工作岗位之前，公司提供了为期两周的系统的软件测试技术专题培训，对接下来的软件测试工作有很大的指导意义。现在，我继续从事软件测试的培训与咨询效劳，在这个过程中，亲眼目睹了很多软件测试新手面对的困惑，他们初涉软件测试行业,没有接受系统的培训，对软件测试一无所知，既不知道该测试什么，也不知道如何开始测试。下面针对上述情况,给出若干解决方法。1.2测试准备工
13、作在测试工作伊始，软件测试工程师应该搞清楚软件测试工作的目的是什么。如果你把这个问题提给工程经理，他往往会这样答复：“发现我们产品里面的所有BUG,这就是你的工作目的。作为一名软件测试新手，如何才能发现所有的BUG?如何开始测试工作？即便面对的是一个很小的软件工程，测试需要考虑的问题也是方方面面的，包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用户的并发容量等等。该从何处下手呢？1.2.1向有经验的测试人员学习如果你进入的是一家运作标准的软件公司，有独立的软件测试部门、标准的软件测试流程、软件测试技术有一定的积累，那么，恭喜你！你可以请求测试经理委派有经验的测试人员作为你工作
14、上的业务导师，由他列出软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录，在业务导师的指导下逐步熟悉软件测试的相关工作。其实，在很多运作标准的软件公司，已经把上述的师父带徒弟的方式固化到流程中。如果你进入的是一个软件测试一片空白的软件企业，那么，也恭喜你！你可以在这里开创一片自己的软件测试事业，当然，前提是老板确实认识到软件测试的重要性，实实在在需要提高产品的质量。这时候，可以到国内的软件测试论坛和相关网站上寻找软件测试资源，这种情况下，自学能力和对技术的悟性就至关重要了。1.2.2阅读软件测试的相关书籍现在，中文版的软件测试书籍越来越多，有的是国人自己写的，有的是翻译
15、国外经典之作。可以到或者等网络购书的站点查找软件测试相关的书籍。目前，从国外引入的软件测试书籍有很多经典之作，但是，翻译成中文后，翻译质量对阅读效果有很大的影响。1.2.3走读缺陷跟踪库中的问题报告单如果您所在的公司已经有软件缺陷跟踪库了，无论采用的是商用工具，如ClearQuestTestDirecter等工具，还是采用的Bugzilla、Mantis等开源工具，这都无关紧要，缺陷跟踪库中的缺陷报告单才是有价值的。缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中表达，同时也是软件产品问题的集中表达。一般来说，缺陷报告单中最关键的几个局部包括：第一局部是发现缺陷的环境，包括软件环境、硬件
16、环境等；第二局部是缺陷的根本描述；第三局部是开发人员对缺陷的解决方法。通过对上述缺陷报告单的三个局部作仔细分析，不知不觉你已经吸收了其他软件测试人员的工作经验，并掌握了软件产品常见的根本问题。这是迅速提高软件测试经验的好方法。1.2.4走读相关产品的历史测试用例如果你所在的公司有测试用例管理系统，那么，走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。走读测试用例也是有技巧的。测试用例写作一般会包括测试用例项和根据测试用例项细化的测试用例，下面举例说明。“测试用户登录的功能是一个测试项，该测试项的目的是测试用户登录功能是否正确，是否能够完成正常的登录功能，是否能够对非法用户名和密
17、码做异常处理等等。因此，根据该用例项，可以设计出若干个测试用例，大多数情况下，测试用例项和测试用例是一对多的关系。通过走读测试用例工程，你可以掌握应该从哪些功能点着手未来的测试工作；通过走读软件测试用例，你可以了解如何根据被测试的功能点开展软件测试用例的设计工作，包括如何确定测试用例的输入、测试用例的操作步骤和测试用例的输出结果等。总之，走读其他软件测试人员设计的优秀软件测试用例，是提高自身用例设计水平的好方法。1.2.5学习产品相关的业务知识软件测试人员不仅要掌握软件测试技术相关知识，对产品相关的业务知识也要学习。这很好理解，如果从事财务软件的测试工作，一定要学习财务知识；如果从事通讯产品测
18、试工作，那么相关的通讯理论知识也是必须的；如果从事银行软件的测试，银行的业务流程也是不可或缺的知识点。因此，在学习软件测试技术的同时，千万不要忽略产品相关业务知识的学习。如果你是一个软件测试技术专家，但是对产品业务知识一无所知，那么也只能测试出来纯粹的软件缺陷，而面对眼前出现的产品业务相关的缺陷，很可能是视而不见，如此这般，软件测试的效果会大打折扣。1.3识别测试需求识别测试需求是软件测试的第一步。如果开发人员能够提供完整的需求文档和接口文档，那固然好。可以根据需求文档中描述的每个功能工程的输入、处理过程和输出，来设计测试用例。如果开发人员没有提供软件需求文档，那该如何是好？下面给出几个有效的
19、方法：1.3.1主动获取需求开发人员通常不会更好地考虑软件测试，如果没有开发流程的强制规定，他们通常是不愿意提供任何开发文档，即便有强制规定，需求文档也未必能够真正指导软件系统测试工作。因此，需要测试人员发挥主观能动性，与相关的软件开发工程经理和软件开发人员保持沟通，了解软件实现的主要功能是什么，并记录得收集到的信息。一般来说，开发人员即便没有提供相关需求文档，也会保存一些简单的过程文档，主动向开发人员索要这些文档，可以作为测试的参考。止匕外，可以与公司的技术支持人员交流，技术支持人员是最贴近用户的人，因此，通过交流可以获取第一手的用户使用感受，在测试的过程中会更加贴近用户。当拿到相关的资料后
20、从哪些方面分析需求？如何与开发人员交流需求？其实，只要把握需求分析的几个关键的点就可以解决问题：输入、处理过程、输出、性能要求、运行环境，下面针对每一个工程逐一分析：软件输入：与该需求相关的一切可能输入，可以从这几方面考虑，输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、输入参数的精度和输入参数的有效输入范围。在测试用例设计中，这局部内容作为测试用例输入的依据。处理过程：描述对输入数据所执行的所有操作和如何获得输出的过程。测试人员了解处理过程即可，在测试过程中发现BUG时候，如果对处理过程了解的深入，对定位问题根源有很大的帮助。软件输出：描述每个需求的输出结果，包括输出的位
21、置（如计算机显示器、打印机，文件），输出参数的数量、输出参数的度量单位、输出参数的时序、输出参数精确度、输出参数的有效输出范围、错误消息。在测试用例设计中，这局部内容作为测试用例的预期输出。性能要求：与该需求相关的性能要求，比方“插入ATM取款卡后，3秒钟内弹出提示用户取款的图形界面。3秒钟这一限制，就是对需求的根本性能要求。运行环境：软件的运行所需的环境，包括硬件平台的要求、操作系统的要求、数据库的要求，以及其它相关支撑软件的要求。1.3.2确认需求的优先级确认需求的优先级是很必要的，如果在产品进度比较紧的情况下，测试人员可以考虑优先测试优先级高的需求项，如果进度允许，那么在测试优先级低的需
22、求项，如果进度不允许，那么就放弃测试优先级低的需求项。如果软件公司有标准的流程支撑，开发人员在提供软件需求文档的时候，应该在文档中确定需求的优先级。但是，如果开发人员连根本的软件需求文档都没有提供，又怎能指望他们确定软件需求的优先级？如果是这样，需求的优先级只能由测试人员完成了。1.3.3参加开发小组的邮件群组测试人员需要通晓被测试产品，但是，产品在开发的过程中往往是不断变化的。如果软件开发团队有一套变更控制流程，测试人员会对产品的变更了如指掌。如果没有变更控制，那就要采用其他的土方法了。如果公司里面有自动化办公系统，也许采用的是LotusNotes系统，也许使用的是E-mail系统，测试人员
23、应该参加到开发人员的邮件群组中。当开发人员通过邮件讨论问题、通知召开技术会议的时候，测试人员可以及时知晓，如果必要,可以参加开发人员的技术会议。即便公司里面有了软件变更控制流程,参加到开发邮件群组也是一个很好的习惯。1.3.4与开发人员为邻建议测试人员与开发人员为邻。我所在的测试组曾经与开发组是在相邻的写字间里，开发人员与测试人员的关系非常融洽，抛去同事关系，大家还是不错的朋友。不管开发人员有什么样的活动，测试人员都能第一时间获得信Mo无论从事软件测试工作，还是从事其它的工作，与工作中上下游环节的同事保持良好的个人关系对工作有很大便利。一般的公司内部都存在部门墙，良好的人际关系是打通部门墙的手
24、段之一。向领导建议测试人员与开发人员为邻，这很必要。1.4测试用例设计测试需求收集完毕后，开始测试设计。测试用例是什么？测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题：1.4.1测试用例的根本格式软件测试用例的根本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。用例编号：测试用例的编号有一定的规则，比方系统测试用例的编号这样定义规则：Projecti-St-OOI,命名规则是工程名称+测试阶段类型（系统测试阶段）+编号。定义测试用例编号，便于查找测试用例，便于测试用
25、例的跟踪。测试标题：对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比方“测试用户登录时输入错误密码时，软件的响应情况。重要级别：定义测试用例的优先级别，可以笼统的分为“高和“低两个级别。一般来说，如果软件需求的优先级为“高，那么针对该需求的测试用例优先级也为“高；反之亦然，测试输入：提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。操作步骤：提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这局部内容在操作
26、步骤中详细列出。预期结果：提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。软件测试用例的设计主要从上述6个域考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍，白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍，这里不作赘述。1.4.2重用同类型工程的测试用例如果我看得远，那是因为我站在巨人的肩上一一牛顿。一般来说，每个软件公司的工程可以分为固定的几大类。可以按业务类型划分，比方ER
27、P软件、产品数据管理软件、通信软件、地理信息系统软件等等；可以按软件结构来划分，比方B/S架构的软件、C/S架构的软件、嵌入式软件等等。参考同类别软件的测试用例，会有很大的借鉴意义。如果，公司中有同类别的软件系统，千万别忘记把相关的测试用例拿来参考。如果，系统非常接近，甚至经过对测试用例简单修改就可以应用到当前被测试的软件。“拿来主义可以极大的开阔测试用例设计思路，也可以节省大量的测试用例设计时间。1.4.3利用已有的软件Checklist在上面一个小节中，按照不同的规则划分了不同的软件类型。每种类型的软件都有一定的测试标准，比方，WEB软件系统在系统测试过程中，会有一系列的范式，比方针对Co
28、okie就会有很多测试点。在设计测试用例的时候,不妨到网上去搜索相关的Checklist,不过国内外的网站很少有这方面的资料，即便有，也不是特别系统。可以先找一份粗糙的Checklist,然后，在设计测试用例的时候不断的去完善它，以作为下次测试用例设计的基础。1.4.4加强测试用例的评审测试用例设计完毕后，最好能够增加评审过程。同行评审是CMM3级的一个KPA,如果因为公司没有通过CMM3级，就不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审，提交评审意见，然后根据评审意见更新测试用例。如果认真操作这个环节，测试用例中的很多问题都会暴露出来，比方用例设计错误、用
29、例设计遗漏、用例设计冗余、用例设计不充分等等；如果同行评审不充分，那么，在测试执行的过程中，上述本应在评审阶段发现的测试用例相关问题，会给测试执行带来大麻烦，甚至导致测试执行挂起。1.4.5定义测试用例的执行顺序在测试用例执行过程中，你会发现每个测试用例都对测试环境有特殊的要求，或者对测试环境有特殊的影响。因此，定义测试用例的执行顺序，对测试的执行效率影响非常大。比方某些异常测试用例会导致效劳器频繁重新启动，效劳器的每次重新启动都会消耗大量的时间，导致这局部测试用例执行也消耗很多的时间。那么在编排测试用例执行顺序的时候，应该考虑把这局部测试用例放在最后执行，如果在测试进度很紧张的情况下，如果优
30、先执行这局部消耗时间的异常测试用例，那么在测试执行时间过了大半的时候，测试用例执行的进度依然是缓慢的，这会影响到测试人员的心情，进而导致匆忙地测试后面的测试用例，这样测试用例的漏测、误测就不可防止，严重影响了软件测试效果和进度。因而，合理地定义测试用例的执行顺序是很有必要的。1.5测试用例执行测试用例设计完毕后，接下来的工作是测试执行，测试执行中应该注意以下几个问题：1.5.1搭建软件测试环境，执行测试用例测试用例执行过程中，搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软硬件环境，比方要求操作系统系统是Windows2
31、000pack4版本，数据库是SqlServer2000等等，止匕外，应该给出被测试软件产品的详细安装指导书，包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品，尤其是软件工程，如果没有安装指导书作为参考，在搭建测试环境过程中会遇到种种问题。如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，防止同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。1.5.2测试执行过程应注意的问题测试环境搭建之后，根据定义的测试用例执行顺序，逐个执行测试用例。在测试
32、执行中需要注意以下几个问题：全方位的观察测试用例执行结果：测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？答案是否认的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某测试用例后，测试用例的实际输出与预期输出完全一致，不过在查询CPU占用率地时候，发现CPU占用率高达90%,后来经过分析，软件运行的时候启动了若干个ImS的定时器，大量的消耗的CPU资源，后来通过把定时器
33、调整到IOms,CPU的占用率降为7%。如果观察点单一，这个严重消耗资源的问题就无从发现了。加强测试过程记录：测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比方有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。及时确认发现的问题：测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位
34、是否为软件缺陷，那么一定要保存现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己珍贵的测试执行时间，可以让开发人员记录重新问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。与开发人员良好的沟通：测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执
35、就不可防止了。止匕外，测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。1.5.3及时更新测试用例测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这局部用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。1.5.4提交一份优秀的问题
36、报告单软件测试提交的问题报告单和测试日报一样，都是软件测试人员的工作输出，是测试人员绩效的集中表达。因此,提交一份优秀的问题报告单是很重要的。软件测试报告单最关键的域就是“问题描述，这是开发人员重现问题，定位问题的依据。问题描述应该包括以下几局部内容：软件配置、硬件配置、测试用例输入、操作步骤、输出、当时输出设备的相关输出信息和相关的日志等。软件配置：包括操作系统类型版本和补丁版本、当前被测试软件的版本和补丁版本、相关支撑软件，比方数据库软件的版本和补丁版本等。硬件配置：计算机的配置情况，主要包括CPU、内存和硬盘的相关参数，其它硬件参数根据测试用例的实际情况添加。如果测试中使用网络，那么网络
37、的组网情况，网络的容量、流量等情况。硬件配置情况与被测试产品类型密切相关，需要根据当时的情况，准确翔实的记录硬件配置情况。测试用例输入操作步骤输出：这局部内容可以根据测试用例的描述和测试用例的实际执行情况如实填写。输出设备的相关输出信息：输出设备包括计算机显示器、打印机、磁带等等输出设备，如果是显示器可以采用抓屏的方式获取当时的截图，其他的输出设备可以采用其它方法获取相关的输出，在问题报告单中提供描述。日志信息：标准的软件产品都会提供软件的运行日志和用户、管理员的操作日志，测试人员应该把测试用例执行后的软件产品运行日志和操作日志作为附件，提交到问题报告单中。根据被测试软件产品的不同，需要在“问
38、题描述中增加相应的描述内容，这需要具体问题具体分析。1. 6测试结果分析软件测试执行结束后,测试活动还没有结束。测试结果分析是必不可少的重要环节，“编筐编篓,全在收口，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的“测试准备工作中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；然后，再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中，每个测试人员都有自己思考问题的盲区和测
39、试执行的盲区，有效的自我分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下一轮测试用防止盲区。2. 7总结限于文章的篇幅，本文不可能给出一个类似于checklist的指导性的软件测试新手入门。无论从事软件测试还是从事其它的工作，技术上的和技巧上的问题都可以通过查询相关的软件测试技术书籍获取，掌握一套根本的方法论是最重要的。以上文字，都是作者从事软件测试工作积累的经验之谈，如发现谬误之处请不吝指出。二软件测试的常识3. 1引言软件开发和使用的历史已经留给了我们很多由于软件缺陷而导致的巨大财力、物力损失的经验教训。这些经验教训迫使我们这些测试工程师们必须采取强有力的检测措施
40、来检测未发现的隐藏的软件缺陷。生产软件的最终目的是为了满足客户需求，我们以客户需求作为评判软件质量的标准，认为软件缺陷(SoftwareBug)的具体含义包括下面几个因素： 软件未到达客户需求的功能和性能； 软件超出客户需求的范围； 软件出现客户需求不能容忍的错误； 软件的使用未能符合客户的习惯和工作环境。考虑到设计等方面的因素，我们还可以认为软件缺陷还可以包括软件设计不符合标准，未能在特定的条件（资金、范围等）到达最正确等。可惜的是，我们中的很多人更倾向于把软件缺陷看成运行时出现问题上来，认为软件测试仅限于程序提交之后。在目前的国内环境下，我们几乎看不到完整准确的客户需求说明书，加以客户的需
41、求时时在变，追求完美的测试变得不太可能。因此作为一个优异的测试人员，追求软件质量的完美固然是我们的宗旨，但是明确软件测试现实与理想的差距，在软件测试中学会取舍和让步，对软件测试是有百益而无一弊的。2.2软件测试常识下面是一些软件测试的常识，对这些常识的理解和运用将有助于我们在进行软件测试时能够更好的把握软件测试的尺度。2.2.1测试是不完全的（测试不完全）很显然，由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素，哪怕是一个极其简单的程序，要想穷尽所有逻辑路径，所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子，比方说求两个整数的最大公约数。其输
42、入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试的话，从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的，即便某一天我们能够穷尽该程序，只怕我们乃至我们的子孙都早已作古了。为此作为软件测试，我们一般采用等价类和边界值分析等措施来进行实际的软件测试，寻找最小用例集合成为我们精简测试复杂性的一条必经之道。2.2.2测试具有免疫性（软件缺陷免疫性）软件缺陷与病毒一样具有可怕的“免疫性，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个50000行的程序中有500个软件缺陷并且这些软件错误分布时均匀的，则
43、每100行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为X小时/100行。照此推算，软件存在500个缺陷时，我们查找一个软件缺陷需要X小时，当软件只存在5个错误时，我们每查找一个软件缺陷需要100X小时。实践证明，实际的测试过程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试。2.2.3测试是“泛型概念（全程测试）我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生
44、的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷,记住“软件缺陷具有生育能力。软件测试应该跨越整个软件开发流程。需求验证（自检）和设计验证（自检）也可以算作软件测试（建议称为：需求测试和设计测试）的一种。软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估（信息系统审计和软件工程监理），即测试本身也应当被测试，从而确保测试自身的可靠性和高效性。否则自身不正，难以服人。另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件，软件测试是提高产品质量最直接、最快捷的手段，但决不是一个根本手段。2
45、2.480-20原则80%的软件缺陷常常生存在软件20%的空间里。这个原则告诉我们，如果你想使软件测试有效地话，记住常常光临其高危多发“地段。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。80-20原则的另外一种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发现和防止80%的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的80%,最后的5%的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试
46、只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。80-20原则还能反映到软件测试的自动化方面上来，实践证明80%的软件缺陷可以借助人工测试而发现，20%的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的局部，因此尚有5%左右的软件缺陷需要通过其他方式进行发现和修正。2.2.5为效益而测试为什么我们要实施软件测试，是为了提高工程的质量效益最终以提高工程的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件测试应该在软件测试本钱和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来，在软件测试中我们应该尽量地保持软件测试简单性,切勿将软件测试过度复杂化,拿物理学家爱因斯坦的话说就是:Keepitsimplebutnottoosimple02.2.6缺陷的必然性软件测试中，由于错误
免费区 
