数据库设计说明书 概要设计说明书 详细设计说明书 可行性研究报告 管理文档
项目开发计划 测试计划 测试报告 开发进度月报 开发总结报告
37、简述软件系统中用户文档的测试要点？
参考答案：
（1）读者群。文档面向的读者定位要明确。对于初级用户、中级用户以及高级用户应该有不同的定位 （2）术语。文档中用到的术语要适用与定位的读者群，用法一致，标准定义与业界规范相吻合。
（3）正确性。测试中需检查所有信息是否真实正确，查找由于过期产品说明书和销售人员夸大事实而导致
的错误。检查所有的目录、索引和章节引用是否已更新，尝试链接是否准确，产品支持电话、地址和邮政编码是否正确。
（4）完整性。对照软件界面检查是否有重要的分支没有描述到，甚至是否有整个大模块没有描述到。 （5）一致性。按照文档描述的操作执行后，检查软件返回的结果是否与文档描述的相同。
（6）易用性。对关键步骤以粗体或背景色给用户以提示，合理的页面布局、适量的图表都可以给用户更高
的易用性。需要注意的是文档要有助于用户排除错误。不但描述正确操作，也要描述错误处理办法。文档对于用户看到的错误信息应当有更详细的文档解释。
（7）图表与界面截图。检查所有图表与界面截图是否与发行版本相同。
（8）样例与示例。像用户一样载入和使用样例。如果是一段程序，就输入数据并执行它。以每一个模块制
作文件，确认它们的正确性。
（9）语言。不出现错别字，不要出现有二义性的说法。特别要注意的是屏幕截图或绘制图形中的文字。 （10）印刷与包装。检查印刷质量；手册厚度与开本是否合适；包装盒的大小是否合适；有没有零碎易丢失
的小部件等等。 38、单元测试主要内容是什么？
参考答案：
单元测试大多数由开发人员来完成，测试人员技术背景较好或者开发系统软件时可能会安排测试人员进行单元测试，大多数进行的单元测试都是开发人员调试程序或者开发组系统联合调试的过程。讨论这个问题主要是扩充一下读者的视野。
单元测试一般包括五个方面的测试：
（1）模块接口测试：模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。模块接口测试也是集成测试的重点，这里进行的测试主要是为后面打好基础。测试接口正确与否应该考虑下列因素：
-输入的实际参数与形式参数的个数是否相同； -输入的实际参数与形式参数的属性是否匹配； -输入的实际参数与形式参数的量纲是否一致；
-调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同； -调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配； -调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致； -调用预定义函数时所用参数的个数、属性和次序是否正确； -是否存在与当前入口点无关的参数引用；
11
-是否修改了只读型参数；
-对全程变量的定义各模块是否一致； -是否把某些约束作为参数传递。
如果模块功能包括外部输入输出，还应该考虑下列因素： -文件属性是否正确；
-OPEN/CLOSE语句是否正确；
-格式说明与输入输出语句是否匹配； -缓冲区大小与记录长度是否匹配； -文件使用前是否已经打开； -是否处理了文件尾；
-是否处理了输入/输出错误； -输出信息中是否有文字性错误。 -局部数据结构测试； -边界条件测试；
-模块中所有独立执行通路测试；
（2）局部数据结构测试：检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确，局部功能是整个功能运行的基础。重点是一些函数是否正确执行，内部是否运行正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误： -不合适或不相容的类型说明； -变量无初值；
-变量初始化或省缺值有错；
-不正确的变量名（拼错或不正确地截断）； -出现上溢、下溢和地址异常。
（3）边界条件测试：边界条件测试是单元测试中最重要的一项任务。众所周知，软件经常在边界上失效，采
用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。边界条件测试是一项基础测试，也是后面系统测试中的功能测试的重点，边界测试执行的较好，可以大大提高程序健壮性。 （4）模块中所有独立路径测试：在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模
块中每条语句至少执行一次。测试目的主要是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。具体做法就是程序员逐条调试语句。常见的错误包括： -误解或用错了算符优先级； -混合类型运算； -变量初值错； -精度不够；
-表达式符号错。
比较判断与控制流常常紧密相关，测试时注意下列错误： -不同数据类型的对象之间进行比较； -错误地使用逻辑运算符或优先级；
-因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等； -比较运算或变量出错；
-循环终止条件或不可能出现； -迭代发散时不能退出； -错误地修改了循环变量。
模块的各条错误处理通路测试：程序在遇到异常情况时不应该退出，好的程序应能预见各种出错条件，并预设各种出错处理通路。如果用户不按照正常操作，程序就退出或者停止工作，实际上也是一种缺陷，因此单元测试要测试各种错误处理路径。一般这种测试着重检查下列问题： -输出的出错信息难以理解；
-记录的错误与实际遇到的错误不相符；
-在程序自定义的出错处理段运行之前，系统已介入； -异常处理不当；
12
-错误陈述中未能提供足够的定位出错信息。 39、如何理解强度测试？
参考答案：
强度测试是为了确定系统在最差工作环境的工作能力,也可能是用于验证在标准工作压力下的各种资源的最下限指标。
它和压力测试的目标是不同的,压力测试是在标准工作环境下,不断增加系统负荷,最终测试出该系统能力达到的最大负荷(稳定和峰值),而强度测试则是在非标准工作环境下,甚至不断人为降低系统工作环境所需要的资源,如网络带宽,系统内存,数据锁等等,以测试系统在资源不足的情况下的工作状态,通过强度测试,可以确定本系统正常工作的最差环境.
强度测试和压力测试的测试指标相近,大多都是与时间相关的指标,如并发量(吞吐量),延迟(最大\\最小\\平均)以及顺序指标等
强度测试需要对系统的结构熟悉,针对系统的特征设计强度测试的方法 40、如何理解压力、负载、性能测试测试？
参考答案：
性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。
压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试。增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。而负载测试是压力相对较大的测试，主要是测试系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。100个用户对系统进行连续半个小时的访问可以看作压力测试，那么连续访问8个小时就可以认为负载测试，1000个用户连续访问系统1个小时也可以看作是负载测试。
实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行测试。
41、什么是系统瓶颈？
参考答案：
瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的特定业务要求，“特定”是指瓶颈会在某些条件下会出现，因为毕竟大多数系统在投入前。
严格的从技术角度讲，所有的系统都会有瓶颈，因为大多数系统的资源配置不是协调的，例如CPU使用率刚好达到100％时，内存也正好耗尽的系统不是很多见。因此我们讨论系统瓶颈要从应用的角度讨论：关键是看系统能否满足用户需求。在用户极限使用系统的情况下，系统的响应仍然正常，我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。
因此我们测试系统瓶颈主要是实现下面两个目的：
-发现“表面”的瓶颈。主要是模拟用户的操作，找出用户极限使用系统时的瓶颈，然后解决瓶颈，这是性能测试的基本目标。
-发现潜在的瓶颈并解决，保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生变化时，系统能够适应变化。满足用户目前需求的系统不是最好的，我们设计系统的目标是在保证系统整个软件生命周期能够不断适应用户的变化，或者通过简单扩展系统就可以适应新的变化。 42、文档测试主要包含什么内容？
参考答案：
在国内软件开发管理中，文档管理几乎是最弱的一项，因而在测试工作中特别容易忽略文档测试也就不足为奇了。要想给用户提供完整的产品，文档测试是必不可少的。文档测试一般注重下面几个方面：
文档的完整性：主要是测试文档内容的全面性与完整性，从总体上把握文档的质量。例如用户手册应
13
该包括软件的所有功能模块。
描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度。例如用户手册基本完整后，我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度。
易理解性：主要是检查文档对关键、重要的操作有无图文说明，文字、图表是否易于理解。对于关键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明了。
文档中提供操作的实例：这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是否丰富，提供的实例描述是否详细。只有简单的图文说明，而无实例的用户手册看起来就像是软件界面的简单拷贝，对于用户来说，实际上没有什么帮助。
印刷与包装质量：主要是检查软件文档的商品化程度。有些用户手册是简单打印、装订而成，过于粗糙，不易于用户保存。优秀的文档例如用户手册和技术白皮书，应提供商品化包装，并且印刷精美。 43、功能测试用例需要详细到什么程度才是合格的？
参考答案：
这个问题也是测试工程师经常问的问题。有人主张测试用例详细到每个步骤执行什么都要写出来，目的是即使一个不了解系统的新手都可以按照测试用例来执行工作。主张这类写法的人还可以举出例子：欧美、日本等软件外包文档都是这样做的。
另外一种观点就是主张写的粗些，类似于编写测试大纲。主张这种观点的人是因为软件开发需求管理不规范，变动十分频繁，因而不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护，可以让测试执行人员有更大的发挥空间。
实际上，软件测试用例的详细程度首先要以覆盖到测试点为基本要求。举个例子：“用户登陆系统”的测试用例可以不写出具体的执行数据，但是至少要写出五种以上情况（），如果只用一句话覆盖了这个功能是不合格的测试用例。覆盖功能点不是指列出功能点，而是要写出功能点的各个方面（如果组合情况较多时可以采用等价划分）。
另一个影响测试用例的就是组织的开发能力和测试对象特点。如果开发力量比较落后，编写较详细的测试用例是不现实的，因为根本没有那么大的资源投入，当然这种情况很随着团队的发展而逐渐有所改善。测试对象特点重点是指测试对象在进度、成本等方面的要求，如果进度较紧张的情况下，是根本没有时间写出高质量的测试用例的，甚至有些时候测试工作只是一种辅助工作，因而不编写测试用例。
因此，测试用例的编写要根据测试对象特点、团队的执行能力等各个方面综合起来决定编写策略。最后要注意的是测试人员一定不能抱怨，力争在不断提高测试用例编写水平的同时，不断地提高自身能力。 44、配置和兼容性测试的区别是什么？
参考答案：
配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否与不同的软件正确协作。
配置测试的核心内容就是使用各种硬件来测试软件的运行情况，一般包括： （1）软件在不同的主机上的运行情况，例如Dell和Apple；
（2）软件在不同的组件上的运行情况，例如开发的拨号程序要测试在不同厂商生产的Modem上的运行情况；
（3）不同的外设； （4）不同的接口；
（5）不同的可选项，例如不同的内存大小；
兼容性测试的核心内容：
（1）测试软件是否能在不同的操作系统平台上兼容；
（2）测试软件是否能在同一操作系统平台的不同版本上兼容； （3）软件本身能否向前或者向后兼容； （4）测试软件能否与其它相关的软件兼容； （5）数据兼容性测试，主要是指数据能否共享；
14
配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统等。具体进行时仍然按照测试用例来执行。 45、软件文档测试主要包含什么？
参考答案：
随着软件文档系统日益庞大，文档测试已经成为软件测试的重要内容。文档测试对象主要如下： -包装文字和图形；
-市场宣传材料、广告以及其它插页； -授权、注册登记表； -最终用户许可协议； -安装和设置向导； -用户手册； -联机帮助；
-样例、示范例子和模板； -??
文档测试的目的是提高易用性和可靠性，降低支持费用，因为用户通过文档就可以自己解决问题。因文档测试的检查内容主要如下：
-读者对象——主要是文档的内容是否能让该级别的读者理解； -术语——主要是检查术语是否适合读者；
-内容和主题——检查主题是否合适、是否丢失、格式是否规范等； -图标和屏幕抓图——检查图表的准确度和精确度； -样例和示例——是否与软件功能一致； -拼写和语法；
-文档的关联性——是否与其它相关文档的内容一致，例如与广告信息是否一致；
文档测试是相当重要的一项测试工作，不但要给予充分的重视，更要要认真的完成，象做功能测试一样来对待文档测试。 46、没有产品说明书和需求文档地情况下能够进行黑盒测试吗？
参考答案：
这个问题是国内测试工程师经常遇到的问题，根源就是国内软件开发文档管理不规范，对变更的管理方法就更不合理了。实际上没有任何文档的时候，测试人员是能够进行黑盒测试的，这种测试方式我们可以称之为探索测试，具体做法就是测试工程师根据自己的专业技能、领域知识等不断的深入了解测试对象、理解软件功能，进而发现缺陷。
在这种做法基本上把软件当成了产品说明书，测试过程中要和开发人员不断的进行交流。尤其在作项目的时候，进度压力比较大，可以作为加急测试方案。最大的风险是不知道有些特性是否被遗漏。 47、测试中的“杀虫剂怪事”是指什么？
参考答案：
“杀虫剂怪事”一词由BorisBeizer在其编著的《软件测试技术》第二版中提出。用于描述测试人员对同一测试对象进行的测试次数越多，发现的缺陷就会越来越少的现象。就像老用一种农药，害虫就会有免疫力，农药发挥不了效力。这种现象的根本原因就是测试人员对测试软件过于熟悉，形成思维定势。
为了克服这种现象，测试人员需要不断编写新的测试程序或者测试用例，对程序的不同部分进行测试，以发现更多的缺陷。也可以引用新人来测试软件，刚刚进来的新手往往能发现一些意想不到的问题。 48、在配置测试中，如何判断发现的缺陷是普通问题还是特定的配置问题？
参考答案：
15
软件测试经典面试题
