什么是软件的“质量”?
高质量的软件是适当的、无错误的，能在预算内按时交货，满足需求/或期望，并且是可维护的。所以，质量是一个主观的术语。它取决于谁是客户以及客户对项目计划的影响。对一个软件开发项目来说，“客户”的范围很广，包括最终用户、客户所接受的测试者、与客户合同有关的官员、客户管理、开发机构的管理者/会计/测试人员/销售人员、未来的软件维护工程师、股票持有者、杂志专栏记者，等等。每一类客户对“质量”都有自己的倾向性 – 会计部门判断质量会从其收益来考虑，而最终用户则重视友好的用户界面和没有错误。
什么是“软件质量保障”?
软件质量保障涉及到整个软件开发过程，包括监视和改善过程、确保任何经过认可的标准和步骤都被遵循、并且保证问题被发现和被处理。从本质上说，软件质量保障是“预防”。
什么是“软件测试”?
软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。也就是说，如果用户面对着应用程序的 A 界面，在使用硬件 B 的时候做 C 操作，那么 D 结果应该出现。所谓受控制的条件应该包括正常条件和非正常条件。应该故意地去促使错误的发生，也就是事情在不该出现的时候出现或者在应该出现的时候没有出现。从本质上说，软件测试是“探测”。
在如何负责质量保障和软件测试的责任方面，各个机构有不同的做法。有时候，由一个小组或者个人来负责。常见的办法是项目组包括了测试人员和开发人员，他们在一起合作工作，由项目负责人来对质量保障进行总负责。这取决于该机构的大小和该机构的商务结构。
为什么软件会有毛病?
1. 交流错误或者没有进行交流 ── 指出应用软件应当做什么和不应当做什么 (针对该应用软件的用户需求)。
2. 软件的复杂性 ── 现在的应用软件十分复杂，以至于在当前的软件开发环境下，缺乏经验人不可能理解它。窗口类型的界面、客户／服务器和分布式的应用、数据通信、巨大的关系数据库、以及应用软件规模庞大，所有这一切都造成软件/系统的复杂性呈指数型的增长。除非进行仔细的设计，使用面向目标的技术会使得项目更加复杂而不是简单。
3. 编程错误 ── 和所有的人一样，程序员也会犯错误。
4. 需求改变 ── 客户恐怕不明白改变需求的影响，也许是知道但依然需要变更 ── 会导致重新设计、重订工程进度表、对其他项目的影响、已完成的工作需要重做或者放弃、对硬件需求的影响等等。如果在项目中出现许多小的改变或一个大的改变，在项目各部分中出现已知或未知的相关的问题，可能会相互影响并导致出现问题。而且，不断地变更也会增加软件的复杂性，可能会导致错误的出现。这样就会影响技术人员的积极性。在一些快速变化的商业环境里，持续变更需求的影响是致命的。在这种情况下，管理者必须知道它的危险性。质量保障和测试工程师必须与此相适应，并安排持续的广泛的测试，以克服不可避免产生的问题。
5. 时间压力 ── 因为有许多猜测成分，软件开发项目的进度很难安排得理想。当最后期限快到的时候，压力逐渐增大，错误随之产生。
6. 自负 ── 人们通常喜欢这样说：
a. “没问题”
b. “简单”
c. “我用几个小时就能完成”
d. “修改老代码应该是简单的事情”
而不是说：
a. “那个新增加的工作很复杂，可能会导致出现许多错误。”
b. “我们没有把握，但我们会尽力。”
c. “我在实际检查之前无法估计需要多长时间完成。”
d. “我们一下子还不能估计旧的代码是如何的”
如果有太多的“没问题”，必然会出问题。
7. 代码的文档质量差 ── 糟糕的维护和修改，或者写得很差的文档，也会导致错误。在许多单位里，管理人员并不鼓励程序员把代码写得清楚、易读。事实上，恰恰相反，他们主要注意尽快完成编码，认为如果别人不明白代码，就会更安全一点 (“难写的代码必然难读”)。
8. 软件开发工具 ── 视觉工具、类库、编译器、编辑工具等等，都会把本身的故障引入，或者产生质量差的文档，从而导致故障的产生。
有那些重要的计算机系统由于软件缺陷而导致故障?
1. 1999 年 10 月，耗资 1.25 亿美元的 NASA 的火星气象卫星失踪，据信这是由于简单的数据转换错误所导致的。人们发现卫星软件中，有些数据使用英制，它们应被转换成公制。这个卫星应当充当另一项任务中的火星极地着陆项目的通信转发器，那个任务也失败了，原因不明。已组成一些检查小组试图找出导致错误未能被发现的操作步骤方面的失误。
2. 1999 年 8 月，在一个大型的商业高速数据网络里，软件的缺陷影响了 70000 个商业用户，时间长达八天。在受到影响的客户中，有美国最大的远期交易电子贸易系统，该系统中断服务长达一周。
3. 1999 年 4 月，一个软件故障导致了一枚价值 12 亿美元的军用卫星的发射失败。这是发生在卡那维拉尔角的最昂贵的非人为事故。这次失败是一系列发射故障中最新的一个，引发了军队和工业界对空间发射计划的重新评估，包括软件集成和测试过程。国会也要求就疏忽举行听证会。
4. 1999 年 3 月，伊利诺斯州的一个小镇收到了数额达 700 万美元的该月的电费帐单。这个数额大约是平常的 700 倍。它的发生是由于当地电力公司新买的软件中有千年虫在作怪。
5. 1999 年年初，由于软件的错误，一个主要的计算机游戏公司收回了所有受欢迎的的新版软件产品。因为在准备好之前就发行了产品，该公司做了公开道歉。
6. 根据美国全国新闻报道，1999 年 2 月，美国的一个主要的网上股票交易服务公司的计算机系统在交易时间发生多次故障。原因是：为了加快交易速度而升级的软件中有问题。
7. 1998 年 4 月，美国的一个重要的数据通讯网络出现了长达 24 小时的故障，使大部分美国的信用卡管理系统交易受到影响。受到影响的还一些大银行、零售商、和政府的数据系统。最后查出也是软件故障所致。
8. 1998 年 1 月，新闻报道说，美国的一个重要的通信公司发现了软件问题。导致对四十万用户一个月的长途电话费未能收取。问题一直未被发现，直到用户来电话询问他们的账单。
9. 1997 年 11 月，由于有报道说一家主要的健康产业公司的计算机记账系统出了问题，该公司的股票值下跌了 60%。问题在于一个大型数据库的转换及不充分的软件测试。报道说，超过 1 亿美元的收入被勾销，政府主管部门对该公司的罚款高达好几百万美元。
10. 1997 年 8 月，一个连锁零售商起诉一个事务处理系统供应商 (不是信用卡公司)，原因是其软件不能处理 2000 年的信用卡业务。
11. 据报道，1997 年 8 月，一家最主要的消费信用卡报告公司的新网站刚开启两天，就因为软件问题而关闭了。这个新站点允许浏览者直接访问，只收取很少的费用就可以查询自己的信用卡使用情况。但是，最初的用户所看到的是别人的账单，而不是他们自己的。发怒的顾客使这件事流传全国。最后问题被归结为：“ … 未曾预料到的大量的客户需求，再加上导致把文件送到错误的计算机的软件毛病。”
12. 1996 年 11 月，报纸报道说，软件故障使得美国 RBOC 的 411 个电话系统在一天的大部分时间里不能正常工作。2000 个话务员中，多数只能使用电话号簿，却不能使用有 1 千 3 百万个记录的数据库。新近修改的软件中有毛病，并且有问题的软件已被安装在生产系统和后备系统中。软件经营商的发言人说：“软件的完整性毫无问题，它只不过是人为的错误。”
13. 据报纸报道，1996 年 5 月，一个重要的美国银行的 823 个顾客的账号都被记入贷方各924,844,208.32 美元。美国的银行家联合会声明这是在银行业务历史中所发生的的这类错误中最大的一个。银行发言人说：“程序错误已被更改，全部资金都被恢复。”
14. 1993 年，在苏联的早期预警监视系统中的软件错误几乎引发核战。该软件是为了过滤掉那些被云层顶部反射的阳光，以免被接收卫星误认为是导弹。但该软件未能做到这一点。灾难之所以能被避免，是因为据说一个苏联军官“内脏有奇怪的感觉”，所以他认定所谓导弹袭击是一次误报警。该过滤软件的代码后来被重写了。
在软件开发过程中5个常见的问题是什么?
1. 需求说明差 (poor requirements) ── 需求不清楚、不完整、太概括、或者不可测试，都会造成问题。
2. 不切实际的时间表 (unrealistic schedule) ── 如果在很短的时间里要求做许多事，出现错误是不可避免的。
3. 测试不充分 (inadequate testing)── 只能根据客户意见或者系统崩溃来判断系统质量的高低。
4. 不断增加功能 (featuritis) ── 在开发正在进行过程中要求增加许多新的功能。这是常见的问题。
5. 交流问题 (miscommunication) ── 如果开发人员对客户的要求不了解，或者客户由不恰当的期望，必然会导致错误。
针对软件开发过程中的问题，有5个解决办法：
1. 可靠的需求 (solid requirements) —— 应当有一个经各方一致同意的、清楚的、完整的、详细的、整体的、可实现的、可测试的需求。为帮助确定需求，可使用模型 (prototypes)。
2. 合理的时间表 (realistic schedules) —— 为计划、设计、测试、改错、再测试、变更、以及编制文档留出足够的时间。不应使用突击的办法来完成项目。
3. 适当的测试 (adequate testing) —— 尽早开始测试；每次改错或变更之后，都应重新测试。项目计划中要为测试和改错留出足够的时间。
4. 尽可能坚持最初的需求 (stick to initial requirements as much as possible) —— 一旦开发工作开始，要准备防止修改需求和新增功能。要说明这样作的后果。如果必须进行变更，必须在时间表上有相应的反映。如果可能，在设计阶段使用快速的模型，以便使客户了解将会得到的东西。这将会使他们对他们的需求有较高的信心，减少以后的变更。
5. 沟通 (communication ) —— 在适当时机进行预排和检查；充分利用团组通信工具 —— 电子邮件、群件 (groupware)、网络故障跟踪工具、变更管理工具、以及因特网的功能。要确保文件是可用的和最新的。优选电子版文档，避免纸介质文档；进行远距离联合作业及协作；尽早使用模型，使得客户的预想是清楚的。
何谓“好的代码”?
“好的代码”应能工作，应当没有错误，具有可读性和可维护性。有的机构有代码“标准”，供所有的开发人员遵循，但每个人对于“什么是最好的”以及“规则太多或太少”有着不同的看法。理论和方法也很多，例如马克开伯复杂计算法 (McCabe Complexity metrics) 就是一种。这种方法使人过分考虑标准和规则，从而限制了产量和创造性。“同事互检”( Peer reviews) 和“伙伴检察”(buddy checks) 中使用的代码分析等工具可以被用于检察错误和执行标准。
对于 C 和 C++ 代码，在建立规则/标准时，这里有一些典型的思路。但不一定适用于一切情况：
1. 减少或排除全局变量的使用。
2. 使用说明性的函数和方法名 —— 使用大、小写字符，避免用缩写，使用满足要求的说明文字来进行充分的描述 (使用超过 20 个字符也不致超行)。取名要与功能一致。
3. 使用说明性的变量名 —— 使用大、小写字符，避免用缩写，使用满足要求的说明文字来进行充分的描述 (使用超过 20 个字符也不致超行)。取名要与功能一致。
4. 函数和方法的大小要尽可能小 —— 最好不超过 100 行，少于 50 行最好。
5. 在函数代码前面的函数的说明文字应当清楚。
6. 书写代码应便于阅读。
7. 在水平方向和垂直方向都留出足够的空间
8. 每行代码字符数不超过 70 个
9. 每条语句占 1 行
10. 一个程序内的代码风格应一致 (在使用括弧、缩排、和命名方式等方面)
11. 注释内容宁多勿少，通常注释行的数量 (包括开始部分) 应当不少于代码行的数量
12. 不管应用程序多么小，都应有文档，包括程序功能的概述和流程图 (哪怕只有几行字，也比没有要好)。如果可能的话，最好有单独的流程图和详细的程序文档。
13. 尽最大可能使用错误处理过程，并对状况和错误进行记录。
14. 在使用 C++ 时，为了减少复杂程度和提高可维护性，应当避免类的继承的层数过多 (这取决于应用程序的大小和复杂程度)。除要尽量减少继承的层次以外，还应少用超负荷运算符 (minimize use of operator overloading)。使用 Java 语言可以消除多级继承和运算符超负荷。
15. 在使用 C++ 时，保持类的方法不要太大，对于每各类的方法，代码行不超过 50 行为最佳。
16. 在使用 C++ 时，应自由进行例外的处理 (make liberal use of exception handlers)
什么是“好的设计”?
“设计”意味着许多事情，但经常是指“功能设计” (functional design) 和“内部设计” (internal design)。
好的“内部设计”表现在软件的代码上 (by software code)，代码的总体结构清楚、易于理解、容易修改、并且便于维护；它应该牢靠 (robust)，包含足够的错误处理能力和状态记录能力；在运行时应该正常工作。
好的“功能设计”应表现在应用上 (by application) ，其功能是由客户或最终用户的需求所规定的。
如果程序中有用户界面，最好假定：最终用户只有很少计算机方面的知识，而且没有读过用户手册，甚至也没读过联机帮助信息。经常需要遵循的规则包括：
1. 程序不应对用户的操作方式表现出惊讶
2. 应当永远很清楚地告所用户下一步该做什么以及如何退出
3. 程序不应当允许用户在未受到警告之前作傻事
为什么经常很难使管理人员认真对待质量保障?
解决问题是一个高可见度的过程，而预防问题则是一个低可见度的过程。这可以用一个古老的寓言来说明：古代中国的一个杏林世家里有一个人的医术全国闻名，受雇于一位大财主。有人问他家里谁的医术最高，他回答说：
“我擅长应付病人和垂死的人，我使用烈药和使人印象深刻的治疗办法，有时也治好了病人，所以我的名声就在富人中间广为流传。”
“我的哥哥是在疾病刚刚冒头的时候就给人治病，他的高明医术在当地的农民和邻居中广为流传。”
“我哥哥能在疾病造成危害之前发现其苗头，并把它根除。但他的名字在我们家乡以外却不为世人所知。”
如何把新的软件质量控制过程引入现有的机构里呢?
1. 主要取决于机构的大小和所涉及的风险。对于大的机构和高风险性的项目 (就生命和费用而言)，需要严格管理采购和正规的质量保障过程。
2. 风险越低，进行管理组织采购和质量保障过程的必要性也越低。实现质量保障过程的步骤和时间应当与生产取得平衡，以避免官僚主义的介入。
3. 对于小项目而言，采用更专门化的过程就足够了。这取决于客户和项目的类型。大量的是取决于开发队伍负责人或者经理、向开发人员的反馈、以及确保在客户、管理者、开发人员和测试人员之间的适当的信息交流。
4. 在所有的情况下，最重要的是需求管理过程，目的是确保有一个清楚、完整、可测试的需求说明书。
什么是验证 (verification) 和评价 (validation)?
1. 验证 (verification) 涉及了回顾和会议，以评估文档、计划、代码、需求和说明书。可以通过检查表、调查表、排练、和检查会来进行。
2. 评价 (validation) 则指在检察完成之后的实际测试。术语“IV”和“V”分别代表验证和评价。
什么是“预排” ( walkthrough)?
“预排”是一个非正式的会议，用来进行评估和信息交流。通常不需要或者只需很少一点准备。
什么是“检查” (inspection)?
检查比预排更正式一点，通常有 3-8 个人参加会议，包括一个仲裁者 (moderator)、读者 (可以是作者或者任何评论者)、一个记录员作记录。典型的检查对象是一个文件，例如需求说明或者测试计划，目的在于发现问题和查找遗漏，而不是去对任何东西进行实际的修改。会议的参加者应当有准备，应当通读文件，大多数的问题会在准备的过程中被发现。检查会的结果应写成书面报告。对检查会进行全面准备是困难而艰苦的工作，但它是保证质量最有用的方法。在检查过程中，最有经验的雇员的作用就向‘大哥哥’一样，他们的技能也许不大显眼，但对任何软件开发机构是最重要的，这是因为预防错误要比发现错误在费用方面更加有效。
应该考虑进行何种测试?
1. 黑盒测试 (Black box testing) ── 不考虑内部设计和代码，根据需求和功能进行测试。
2. 白盒测试 (White box testing) ── 根据应用软件的代码的内部逻辑，按照代码的语句、分支、路径和条件进行测试。
3. 部件测试 (Unit testing) ── 最小范围的测试，针对特定的函数和代码模块进行测试。因为需要了解程序的设计和代码的细节才能进行，所以部件测试一般是由程序员，而不是由测试人员来做。除非应用软件的结构设计良好，而且代码也写得清楚，否则部件测试并非易事。也许需要开发测试驱动模块或测试工具。
4. 递增的综合测试 (incremental integration testing) ── 不断进行的测试过程，每增加一个新的功能模块，都进行测试。这要求一个应用软件在最终完成之前，各功能模块要相对独立，或者已根据需要开发出测试驱动软件。这种测试可由程序员或测试人员进行。
5. 综合测试 (integration testing) ── 对应用软件的各个部件进行组合测试，来检查各功能模块在一起工作是否正常。“部件”可以是代码模块、独立的应用程序、也可以是网络中的客户/服务器应用软件。这种测试特别适用于客户/服务器环境和分布式系统。
6. 功能测试 (functional testing) ── 对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。(这一原则适用于所有的测试阶段。)
7. 系统测试 ── 针对全部需求说明进行黑盒测试，包括系统中所有的部件。
8. 端到端测试 (end-to-end testing) ── 类似于系统测试，但测试范围更“宏观”一些。模仿实际应用环境，对整个应用软件进行使用测试。例如与数据库进行交互作业、使用网络通信、与其他硬件、应用程序和系统之间的相互作用是否满足要求。
9. 健全测试 (sanity testing) ── 是一种典型的初始测试。判断一个新的软件版本的运行是否正常，是否值得对它作进一步的测试。例如，如果一个新的软件每 5 分钟就破坏系统、大大降低系统的运行速度、或者破坏数据库，那么这样的软件就算不上是“健全”的，不值得在目前状态下进行进一步的测试。
10. 回归测试 (regression testing) ── 每当软件经过了整理、修改、或者其环境发生变化，都重复进行测试。很难说需要进行多少次回归测试，特别是是到了开发周期的最后阶段。进行此种测试，特别适于使用自动测试工具。
11. 认同测试 (acceptance testing) ── 基于说明书的、由最终用户或顾客来进行的测试。或者由最终用户/顾客来进行一段有限时间的使用。
12. 负荷试验 (load testing) ── 在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况，以确定在什么情况下系统响应速度下降或是出现故障。
13. 压力测试 (stress testing) ── 经常可以与“负荷测试”或“性能测试”相互代替。这种测试是用来检查系统在下列条件下的情况：在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询，等等。
14. 性能测试 (performance testing) ── 经常可以与“压力测试”或“负荷测试”相互代替。理想的“性能测试”(也包括其他任何类型的测试) 都应在质量保障和测试计划的文档终予以规定。
15. 可用性测试 (usability testing) ── 是专为“对用户友好”的特性进行测试。这是一种主观的感觉，取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人员通常不参加可用性测试。
16. 安装/卸载测试 (install/uninstall testing) ── 对安装/卸载进行测试 (包括全部、部分、升级操作)。
17. 恢复测试 (recovery testing) ── 在系统崩溃、硬件故障、或者其他灾难发生之后，重新恢复系统的情况。
18. 安全测试 (security testing) ── 测试系统在应付非授权的内部/外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。
19. 兼容性测试 (compatability testing) ── 测试在特殊的硬件/软件/操作系统/网络环境下的软件表现。
20. 认同测试 (acceptance testing) ── 看顾客是否对软件满意。
21. 比较测试 (comparison testing) ── 与竞争产品进行比较，以找出弱点和优势。
22. α 测试 (alpha testing) ── 在开发一个应用软件即将完成时所进行的测试。此时还允许有较小的设计修改。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。
23. β 测试 (beta testing) ── 当开发和测试已基本完成，需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。
什么是SEI CMM、ISO、IEEE、ANSI? 它们有用吗?
1. SEI = “软件工程研究所 (Software Engineering Institute)”，设在卡内基·梅隆大学，为改善软件开发过程，由美国国防部创建。
2. CMM = “性能完善模型 (Capability Maturity Model)”，由 SEI 开发。它是一个分 5 级的、可以描述结构完善程度的模型，用它来说明所交付的软件的效能。它适用于大的机构，例如美国国防部的承包商。所以，它所涉及的许多质量控制过程适用于任何机构，如果合理地利用它，将会获益不浅。一个机构经过权威评审机构的评估，可以得到CMM等级 (CMM ratings)。
a. 1 级 ──
表现混乱，定期需要应急措施，需要经过很大努力才能完成项目。很少有适当的过程，成功不可重复。
b. 2 级 ──
软件项目跟踪、需求管理、合理计划、以及结构管理过程适当，成功可以重复。
c. 3 级 ──
标准软件开发和维护处理过程完整地在整个机构内贯彻。有一个软件工程处理组来坚实软件过程，开设培训课程来确保理解和一致性。
d. 4 级 ──
对生产、处理和产品进行跟踪，项目的特性是可预见的，非常重视质量。
e. 5 级 ──
重视持续地改善处理过程。新的处理过程和新技术的效果是可预见的，在需要时使用它们便可提高效率。
(关于 CMM 等级的前景：1992-1996 年间，共有 533 个机构经过评估。其中 62% 的机构属于 1 级，23% 为 2 级，13% 为 3 级，2% 为 4 级，0.4% 是 5 级。中等大小的机构有 100 个工程师/维护人员；31% 的机构是美国国防部的承包商。在那些CMM等级为 1 级的机构里，有问题的关键处理领域在于软件质量保障。)
3. ISO = “国际标准化组织 (International Organisation for Standards)” ── ISO9001、9002 和9003 是针对质量系统的标准，由外部的评估人员进行评价，适用于许多类型的生产和制造机构，而不仅仅适用于软件开发。其中最复杂的是 9001，它被广泛用于软件开发机构。9001 涵盖文档、设计、开发、生产、测试、安装、服务和其他过程。ISO 9000-3 (不是9003) 是 ISO 9001 用于软件开发机构时的指导方针。美国版的 ISO 9000 系列标准与国际版完全相同，被称为 ANSI/ASQ Q9000 系列。美国版可以直接从美国质量协会 (ASQ ── American Society for Quality) 或者 ANSI 购买。一个机构要想获得 ISO 9001 认证，需要有第三方的评价人员进行评估，所获得的认证的有效期为 3 年，届时需要进行再评估。注意：ISO 9000 并不是表明产品质量所必需的，它只是表示文档所规定的处理过程都被遵循。
4. IEEE = “电学和电子工程师协会 (Institute of Electrical and Electronics Engineers)” ── 除作其他事情以外，还制定了以下标准：
a. IEEE/ANSI Standard 829 ── 软件测试文档标准
b. IEEE/ANSI Standard 1008 ── 软件部件测试 (Unit Testing) 标准
c. IEEE/ANSI Standard 730 ── 软件质量保障计划
以及其他一些标准。
1. ANSI = “美国国家标准协会 (American National Standards Institute)” ── 是美国主要的工业标准实体；与 IEEE 和 ASQ (American Society for Quality ── 美国质量协会) 协力，也出版了一些与软件有关的标准。
2. 除 CMM 或 ISO 9000 以外，其他的软件开发过程评估方法有：SPICE，Trillium，TickIT。 和 Bootstrap。
什么是“软件生命周期” (software life cycle)?
生命周期从收到应用软件开始算起，到该软件不再使用为止。它有如下各方面的内容：初始构思、需求分析、功能设计、内部设计、文档计划、测试计划、文档准备、集成、测试、维护、升级、再测试、逐步淘汰 (phase-out)、等等。
使用自动测试工具会使测试更容易吗?
1. 可能。对于小项目而言，由于在学习和执行过程中需要花费时间，所以使用自动测试工具不一定值得。对大项目来说，或者对于持续时间很长的项目来说，是值得的。
2. 常见的自动测试工具是“记录/重做”(record/playback) 类型的。例如，自动测试工具可以让测试人员在一个应用软件的图形用户界面上点击所有菜单选择、对话框中的选择、按钮、等等，并记录下操作及其结果。典型的“记录”使用了由测试工具翻译的字符型的描述语言。如果有新的按钮被加入，或者一些基础代码被修改，只需‘重做’记录过的操作，即可重新对该应用软件进行测试。然后对操作的结果进行比较，便可检查修改的效果。使用这种测试方法的问题是：如果在进行系统测试时又不断做出新的变更，那么“记录”也必须相应变化，而持续对脚本升级是非常耗费时间的。另外，对操作结果的解释 (屏幕、数据、日志等) 也不容易。
注：也有适用于所有平台的基于界面的‘记录/重做’类型的工具。
3. 其他的自动测试工具有：
a. 代码分析 ── 监视代码的复杂程度，坚持标准，等等。
b. 覆盖分析 ── 这种工具指出哪些代码已经经过测试，可以针对代码语句覆盖、条件覆盖、和路径覆盖等。
c. 存储分析 ── 例如边界测试和泄漏检查 (bounds-checkers and leak detectors)
d. 负载/性能测试工具 ── 检查链接是否有效、HTML 代码是否正确，检查客户端和服务器端的工作、web 站点的交互功能是否安全。
e. Web测试工具 ── 检查链接是否有效、HTML 代码是否正确，检查客户端和服务器端的工作、web 站点的交互功能是否安全。
f. 其他工具 ── 用于测试案例管理、错误报告、以及结构管理。
怎样造就一个好的测试工程师?
一个好的测试工程师应当有“分隔测试”的本领 ('test to break' attitude) 和以顾客身份来看问题的能力，他渴望高品质，并且注重细节。在与开发人员打交道时，机智和交际对维护合作关系是十分有用的。与技术人员 (开发人员) 和非技术人员 (客户、管理人员) 相互沟通的能力也是非常有用的。测试人员的过去的软件开发经验对于深入理解软件开发过程，是非常有用的。这种经验还可以让测试人员理解开发人员的观点，在学习自动测工具时少走弯路。在一个应用软件中，判断其高风险部分在哪里的技能也是必须的；在时间有限的情况下，这有助于确定测试的重点。
怎样造就一个好的软件质量保障工程师?
软件测试人员的一些好的品质对于质量保障工程师也是有用的。此外，质量保障工程师必须能够了解整个软件开发过程，了解开发过程是如何适应一个机构的商业活动及目标的。交流技能和对各种不同事物的理解是非常重要的。在一个机构里开始实行质量保障过程时，特别需要耐心和交际手段。在检察和回顾时，发现问题和找到遗漏的能力是非常重要的。
怎样造就一个好的软件质量或测试管理人员?
一个好的质量保障、测试、或者质量保障/测试 (综合的) 管理人员应当：
1. 熟悉软件开发过程
2. 不管情况如何不利，能够保持队伍的热情并能改善工作气氛 (即能够避免出现问题)
3. 能够促进团队工作，以提高产量
4. 能够促进在软件开发人员、测试人员、和质量保障工程师之间的竞争
5. 有为改善 QA 过程所必需的外交技能
6. 能够承受压力，在质量有问题时或出现未能坚持 QA 过程的情况时，敢于对其他管理人员说“不”
7. 具备识别人的本领，善于雇用和保持有能力的工作者
8. 能够与懂技术的或不懂技术的人员、工程师、管理人员和客户交流
9. 能够主持会议并能保持议题不偏离
在 QA 过程中，文档起什么作用?
起关键性作用。文档可以是电子化的，不一定非是纸介质的。QA 的实现必须是文档化的，以保证其过程是可重复的。说明书、设计、商业法规、调查报告、结构、代码变更、测试计划、测试案例、错误报告、用户手册等等，都应当形成文档。最理想的是有一个文档系统，使得寻找文件更加容易，能够针对某个信息找到有关文档。如果可能，该系统也应能够对文档的改变进行管理。
怎样对待“需求”?
在一个复杂的软件系统中，如果有关的需求说明书写得很差，问题或故障的出现是毫无疑义的。需求详细描述了一个应用软件的外部感觉功能和特性。需求应当是清晰的、完整的、相当详细的、cohesive、可实现的、并且是可测试的。一个不可测试的需求没准会是“对用户友好的” (太主观了)。而一个可测试的需求应当是类似于“用户必须首先输入预先设置的口令，然后才能访问应用软件”。使用一种方法来有效、详细地确定和组织需求的内容并不容易，在不同的项目中可以选择不同的方法。有许多书籍针对这个任务介绍了许多不同的方法。
在形成需求的过程中，应当小心地对待与项目有关的重要客户。“客户”应当包括内部客户和外部客户，还应当包括最终用户、客户所接受的测试人员、与客户合同有关的官员、销售人员、等等。任何人，如果他的期望未能实现就有可能使项目“出轨”，那么，只要有可能，这种人就应当被包括在“客户”之内。需求说明的结构是非常重要的。在需求文件中，理想的叙述方式应当由“产品应当....”这样的句子所组成。“设计说明书”不应当与“需求”搞混；设计说明书的根据是需求说明书。
在一些机构里，需求最终规定了高层次的项目计划、设计文档中的功能描述说明书、以及其他不同层次的文档的详细内容。不管名称是什么，测试人员需要某种类型的详细的需求文档，以便能够正确地规划和执行测试。如果没有这种文档，测试人员不可能清楚地指出应用软件的功能是否正常。
软件测试包括哪些内容?
以下是一些需要考虑的步骤：
1. 得到需求、功能设计、内部设计说书和其他必要的文档
2. 得到预算和进度要求
3. 确定与项目有关的人员和他们的责任、对报告的要求、所需的标准和过程 (例如发行过程、变更过程、等等)
4. 确定应用软件的高风险范围，建立优先级、确定测试所涉及的范围和限制
5. 确定测试的步骤和方法 ── 部件、集成、功能、系统、负载、可用性等各种测试
6. 确定对测试环境的要求 (硬件、软件、通信等)
7. 确定所需的测试用具 (testware)，包括记录/回放工具、覆盖分析、测试跟踪、问题/错误跟踪、等等
8. 确定对测试的输入数据的要求
9. 分配任务和任务负责人，以及所需的劳动力
10. 设立大致的时间表、期限、和里程碑
11. 确定输入环境的类别、边界值分析、错误类别
12. 准备测试计划文件和对计划进行必要的回顾
13. 准备白盒测试案例
14. 对测试案例进行必要的回顾/调查/计划
15. 准备测试环境和测试用具，得到必需的用户手册/参考文件/结构指南/安装指南，建立测试跟踪过程，建立日志和档案、建立或得到测试输入数据
16. 得到并安装软件版本
17. 进行测试
18. 评估和报告结果
19. 跟踪问题/错误，并解决它
20. 如果有必要，重新进行测试
21.在整个生命周期里维护和修改测试计划、测试案例、测试环境、和测试用具
什么是“测试计划”?
一个软件项目的测试计划是一份文件，它说明了在进行软件测试过程中的目标、范围、方法、和重点。在准备测试计划的过程中，要通盘考虑在接受一个软件产品之前所必需进行的一切验证工作。完整的文档将帮助测试组以外的人们了解“为什么”和“如何”验证产品。文档应当是十分完全的，但注意不要太繁杂，以至测试组以外的人不愿去读它。以下是一些应当包括在测试计划中的内容，它们依赖于特定的项目：
1. 标题
2. 软件标识，包括版本号
3. 文档修改历史，包括作者、日期、批准人
4. 内容目录
5. 文档的用途、所面向的读者
6. 测试目标
7. 软件产品概况
8. 有关的文件清单，例如需求、设计文档、其他测试计划等
9. 所需的有关标准和法律
10. 有跟踪能力
11. 有关的协议名称和协议的标识
12. 全部软件项目组织情况和人员/联系所需的信息/责任
13. 测试组织的情况和人员/联系所需的信息/责任
14. 假定和相关 (Assumptions and dependencies)
15. 项目风险分析
16. 测试优先级和重点
17. 测试范围和限制
18. 测试大纲 ── 一份有关测试方法的文件，涉及测试类型、特点、功能、 过程、系统、模块等
19. 数据输入设备类型大纲 ── 边界值分析、错误类别
20. 测试环境 ── 硬件、操作系统、必需的其它软件、数据结构、与其他系统之间的接口
21. 设置测试环境和结构
22. 设置所需的测试数据
23. 设置所需的数据库
24. 有关系统日志/错误日志/其他内容的大纲，还有工具，例如屏幕获取软件，以帮助对错误进行描述和报告
25. 对在测试中用于跟踪错误原因或源代码的专用软件和硬件工具进行讨论
26. 测试自动化 ── 判断和回顾
27. 所使用的测试工具，包括版本、路径等
28. 测试脚本/测试代码的维护过程和版本控制
29. 问题跟踪和解决 ── 工具和过程
30. 项目中所用的测试方法
31. 所需的报告和可交付使用的测试
32. 软件的进入和退出的条件
33. 初始的健全测试周期和条件 (Initial sanity testing period and criteria)
34. 测试中止和重新启动的条件
35. 人员分配
36. 人员预先培训的需求
37. 测试地点
38. 外部测试机构的利用及其目的、责任、可交付使用、联系人、及配合
39. 有关的所有人、类别、安全、以及许可证
40. 开放 (Open issues)
41. 附录 ── 术语表、缩写等
什么是“测试案例”?
测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的工作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设置、输入数据要求、步骤、以及预期的结果。
注：开发一个应用软件的测试案例的过程，需要全面、深入地考虑该软件的操作，所以有助于发现在其需求或设计里面的问题。因此，如果有可能，在开发周期中应当尽早准备测试案例。
什在发现错误之后应当做什么?
错误应当被通报并分配给开发人员，以便进行改正。在问题解决之后，应当对被修改的部分重新进行测试。而且应当根据情况进行回归测试，以检查被修改的部分是否在其他部分引出新的问题。如果使用了问题跟踪系统，可以缩短这些过程。商业市场上有许多问题跟踪/管理的软件工具可供选择。
下面是一些在问题跟踪过程中应当考虑的内容：
1. 整理出有关错误的完整的信息，以便使开发人员能够了解错误、知道错误是如何起作用的。如果有必要，可以再现错误。
2. 错误标识 (号码、识别码等)
3. 错误的当前状况 (即“出现在再测试过程中”、“新的”等)
4. 应用软件的名称或识别符及版本
5. 错误出现时的情况：功能、模块、特征、目标、屏幕等
6. 环境说明、系统、平台、有关硬件说明
7. 测试案例的名称/编号/识别符
8. 一行字的错误描述
9. 详细的错误描述
10. 如果所产生的错误不在测试案例之内，或者开发人员不太容易了解测试案例/测试剧本/测试工具，就要描述使错误重现的操作步骤。
11. 在测试中所使用的文件名/或文件的说明/数据/消息/等等
12. 文件引用/错误消息/日志文件的引用/屏幕情况/测试工具日志，它们有助于发现问题的原因
13. 问题严重的程度 (通常使用分 5 级或者用从“严重”到“低”的分类方法)
14. 错误是否可再现?
15. 测试人员的名字
16. 测试日期
17. 报告错误的日期
18. 与问题有关的开发人员/开发组/机构的名字
19. 描述问题的起因
20. 对改错进行描述
21. 修改过的代码段/文件/模块/类别/方法
22. 修改日期
23. 包含修改内容的应用软件的版本
24. 负责再测试的测试人员
25. 再测试的日期
26. 再测试的结果
27. 回归测试需求
28. 负责回归测试的测试人员
29. 回归测试的结果
在各个阶段，都应把问题跟踪过程的报告送给有关人员。例如，测试人员应当知道何时应进行再测试，开发人员应当知道错误何时发现并知道到何处能找到有关信息，而管理人员则应具备生成报告/总结的能力。
什么是“结构管理”?
结构管理包括控制、定位 (coordinate)、和跟踪的全过程。涉及了代码、需求、问题、变更请求、设计、工具/编译器/库/路径、变更方式、以及由谁进行变更。
遇到软件中错误太多，以至完全无法进行测试时怎么办?
在这种情况下，测试人员最好仔细研究报告，看错误或阻塞型的问题 (blocking-type problems) 最初出现的地方，并把注意力放在最严重的错误上。由于这类问题会影响进度，并能反映出软件开发过程中的深层次的问题 (例如，部件测试或集成测试不充分、设计不良、不适当的建立和发布过程，等等)，所以应当通知管理人员，并向他们提供一些证明文件。
什么时候停止测试?
很难说。许多大型应用软件非常复杂，又被用于相互依赖的环境中，进行完全的测试是根本不可能的。一般根据下列因素来决定何时停止测试：
1. 截止日期 (发行截止日期、测试截止日期、等等)
2. 一定比例的测试案例已经完成
3. 测试预算耗尽
4. 代码/功能/需求已经达到指定的程度
5. 错误已低于一定比例
6. β 或 α 测试期结束
如果时间不够，无法进行充分的测试怎么办?
使用风险分析，确定测试的重点。
由于很少有机会对一个应用软件进行所有可能的测试 (包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西)，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。需要考虑下列因素：
1. 对于该项目的用途而言，哪种功能最重要?
2. 哪种功能对用户最明显?
3. 哪种功能对安全影响最大?
4. 哪种功能对用户最有用?
5. 对客户来说，该应用软件的哪个部分最重要?
6. 在开发过程中，该应用软件的哪个部分可以最先测试?
7. 哪一部分代码最复杂，容易导致出现错误?
8. 哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?
9. 哪一部分程序与过去项目中引起问题的部分相类似/有关?
10. 哪一部分程序与过去项目中需要大量维护的部分相类似/有关?
11. 需求和设计的那些部分不清楚或不容易读?
12. 开发人员认为在应用软件中哪些部分是高风险的?
13. 哪些问题能造成最差的发行?
14. 哪些问题最能引起用户抱怨?
15. 哪些测试可以容易地覆盖多种功能?
16. 哪些测试在覆盖高风险部分的测试时使用时间最少?
如果项目不够大，不能进行大范围的测试怎么办?
应当考虑项目中错误的影响，而不是项目的大小。所以，如果不能进行大范围的测试，依然需要进行风险分析，如同在前面“如果时间不够，无法进行充分的测试怎么办?”一节中所讨论的一样。测试人员随后应进行专门测试，或者根据风险分析作出一个有限的测试计划来。
如果需求一直在变化怎么办?
这是一个常见的令人头疼的问题。
1. 如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。
2. 如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。
3. 好的代码注释和好的文档有助于开发人员作出相应的改变。
4. 只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。
5. 在项目的时间表中应当留出余量，以应付可能出现的变更。
6. 尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。
7. 通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。
8. 要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。
9. 在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。
10. 在设计自动测试剧本时，试图使其有一些灵活性。
11. 在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。
12. 对变更进行适当的风险分析，以减少回归测试的要求。
13. 在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。
14. 少注意详细的测试计划和测试案例，要把重点放在专门的测试 (ad hoc testing) 上。
在应用软件中出现了需求中所没有的功能怎么办?
应当作出认真的努力，来确定在应用软件中是否存在大量未曾期望的或隐藏的功能，它可能表明在软件开发过程中存在着深层次的问题。如果该功能不是该应用软件的目标所必需的，应当把它删除，因为可能会有设计者或客户未曾考虑到的未知的影响或派生问题 (dependencies)。如果不删除，就应增加设计内容，以便据此增加测试或回归测试。管理人员应当认识到，计划以外的功能必然导致风险的增加。如果计划以外的功能只是为了改善用户界面，其风险不会太大。
如何在没有沉闷感的情况下进行软件 QA 过程?
经过持续漫长的 QA 过程，使用多数人同意的原则，机构在成长和成熟过程中进行调整和试验，生产力将得到改善而不是窒息。预防问题将会减少检查问题的需要，恐慌和临界情况将会减少，精力将会集中，浪费将会减少。同时，要力求保持过程简单有效，减少准备工作，改善基于计算机的自动跟踪和报告过程，减少会议时间，改善培训并把它作为 QA 过程的一部分。没有人 ── 特别是有才能的技术类型人员，会喜欢规则和官僚主义，它们很快就会使工作减慢下来。理想的情况应当是花费更多的时间用于计划和开发所需，较少需要彻夜改错和面对顾客发怒的面孔。
如果机构发展太快，以致影响到 QA 过程时怎么办?
这是软件工业界里常见的问题，特别是在新技术领域里。除了做下列事情以外，没有什么容易的解决办法：
1. 雇用好人
2. 管理应当严格，质量第一，注重客户
3. 机构内所有人员都应了解“质量”对于客户的意义
客户/服务器环境如何影响测试?
客户/服务器应用软件是相当复杂的，这是因为在客户、数据通信、硬件、以及服务器之间是互相依赖的。从而使对测试的要求也扩大了。当时间紧张的时候 (这是通常的情况)，重点应当放在集成测试和系统测试上。此外，进行负载/压力/性能测试，也有助于了解客户/服务器应用软件的局限和能力。市场上有一些工具可用来评估这类测试。
怎样对 Web 站点进行测试?
Web 站点也是一种客户/服务器类型的应用 ── 有 Web 服务器和客户“浏览器”。应当考虑在 html页面、TCP/IP 通信、网间联结、防火墙、在 Web 页面运行的应用程序 (例如 java applets、java 描述语言、插入应用)、以及在服务器一端运行的应用程序 (例如 cgi 描述语言、数据库接口、日志应用软件、动态页面生成器、等等)。此外，有各种各样的服务器和浏览器，它们的版本也各不相同，相互之间的差别有小有大，链路的速度也各不相同，加上快速变化的技术以及各种标准和协议，都应当加以考虑。最终的结果是对 web 站点的测试成为一个主要的持续的努力过程。其他应当考虑的问题有：
1. 期望的加在服务器上的负载 (即单位时间内点击的次数)，以及在此负载下所需要的性能 (例如 web 服务器的响应时间、数据库查询响应时间)。还要考虑使用何种工具来进行测试 (例如 web 负载测试工具、其他已有的合适的工具、web 自动下载工具，等等)。
2. 谁是最终的观众? 他们会使用何种浏览器? 它们所用的链接类型和速度怎样? 它们是单位内的用户 (可能使用高速链接和类似的浏览器) ，还是因特网上的用户 (使用不同的链接速度和浏览器)?
3. 在客户端所期望的特性 (即页面出现速度要多快，动画速度要多快，是否能装入并运行applets)?
4. 在进行维护/升级时是否允许停机? 多长时间?
5. 使用何种安全措施 (防火墙、密码、口令等)? 对它们有何期望? 它们可被检查吗?
6. 对站点与因特网链接的可靠性的要求是怎样的? 对系统备份、冗余链接以及测试有何影响?
7. 管理站点内容的升级需要那些步骤? 为维护、跟踪、和控制页面内容、图形、链接等，需要做什么?
8. 使用那种 HTML 规范? 严格程度如何? 允许用多少种浏览器?
9. 是否有标准或要求规定页面外观? 或者有适用于站点的全部或部分图形的标准?
10. 如何对内部和外部链接确认和升级? 频度如何?
11. 是否能对生产系统进行测试? 是否需要对系统单独测试? 浏览器的高速缓存、浏览器的选项变化、拨号链接的变化、以及在因特网上的“拥塞”问题等，是否在测试中都考虑到了?
12. 服务器的日志和报告是怎样扩展，以适应用户要求的? 是否把它们也当作一个系统部件? 它们是否需要测试?
13. 对 cgi 程序、applets、java 描述语言、ActiveX 等组件如何进行维护、跟踪、控制和测试?
以下是一些有用的指导方针, 这仅仅是主观看法，在一定情况下，也许适用，也许不适用：
14. 页面最大为 3-5 帧，除非全部内容都是针对一个题目且不可分的。如果内容太多，需要在页面内建立链接。
15. 一个站点全部页面的版面和元素布局风格应当一致，使得用户知道自己仍在同一站点内。
16. 应当使页面尽量与浏览器相独立，否则应当提供相应的浏览器。
17. 所有的页面都应有指向页面以外的链接，不应当出现页面的死胡同。
18. 页面的主人、修改日期、与机构里有关人员的联系等内容，都应包括在每个页面内。
面向对象的设计如何影响测试?
好的面向对象的工程设计使得从代码追溯内部设计、再到功能测试，最后追溯到需求，成为一件容易的事。因为它对黑盒测试的影响很少 (不需要了解应用软件的内部设计) ，而白盒测试只需针对该应用软件的对象。如果该应用软件设计得好，就可简化测试设计。
1894
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
