面向软件测试新手的若干个关注点分析.docx

面向软件测试新手的若干个关注点分析.docx

《面向软件测试新手的若干个关注点分析.docx》由会员分享，可在线阅读，更多相关《面向软件测试新手的若干个关注点分析.docx（137页珍藏版）》请在冰豆网上搜索。

面向软件测试新手的若干个关注点分析

一软件测试从零开始5

1．1引言5

1．2测试准备工作5

1．2．1向有经验的测试人员学习5

1．2．2阅读软件测试的相关书籍6

1．2．3走读缺陷跟踪库中的问题报告单6

1．2．4走读相关产品的历史测试用例6

1．2．5学习产品相关的业务知识6

1．3识别测试需求7

1．3．1主动获取需求7

1．3．2确认需求的优先级8

1．3．3加入开发小组的群组8

1．3．4与开发人员为邻8

1．4测试用例设计8

1．4．1测试用例的基本格式8

1．4．2重用同类型项目的测试用例9

1．4．3利用已有的软件Checklist9

1．4．4加强测试用例的评审10

1．4．5定义测试用例的执行顺序10

1．5测试用例执行10

1．5．1搭建软件测试环境，执行测试用例10

1．5．2测试执行过程应注意的问题11

1．5．3及时更新测试用例11

1．5．4提交一份优秀的问题报告单12

1．6测试结果分析12

1．7总结13

二软件测试的常识13

2．1引言13

2．2软件测试常识13

2．2．1测试是不完全的（测试不完全）13

2．2．2测试具有免疫性（软件缺陷免疫性）14

2．2．3测试是“泛型概念”（全程测试）14

2．2．480-20原则14

2．2．5为效益而测试15

2．2．6缺陷的必然性15

2．2．7软件测试必须有预期结果15

2．2．8软件测试的意义-事后分析15

2．2．9结论：

15

三浅谈软件开发中的注意事项16

3．1项目设计16

3．2设计变化和需求变化16

3．3代码编写17

3．3．1源程序文件结构17

3．3．2界面设计风格的一致性17

3．3．3编辑风格17

3．3．4命名规18

3．4BUG修补18

3．5开发人员的测试18

四软件测试的若干问题19

4．1前言19

4．2博弈的各方19

4．3测试的过程20

4．4测试所具备的素质20

4．5自动化测试20

4．6测试的误区21

五浅谈功能测试用例模板设计21

5．1Excel模版21

5．2测试用例状态转换分析23

六如何提高软件质量23

6．1什么是质量24

6．2流程对质量的贡献25

6．3流程与技术27

6．4全面质量管理28

6．5关注测试29

6．6成功的铁三角30

6．7国际上流行的质量标准30

6．8如何起步32

七ISO和CMM，我们该选择谁32

7．1管理水平的适用性33

7．2复杂度的适用性33

7．2．1何谓研发过程复杂度34

7．2．2何谓组织机构复杂度34

7．3量化管理的适用性上35

7．4结论36

八如何做好单元测试36

8．1前言36

8．2组织结构应该保证测试组参与单元测试36

8．3加强单元测试流程规性37

8．3．1制订单元测试的过程定义37

8．3．2单元测试工作产品必须纳入配置管理38

8．3．3必须制订覆盖率指标和质量目标来指导和验收单元测试38

8．3．4加强详细设计文档评审39

8．4单元测试者技能的提高39

8．4．1加强对单元测试人员的技能培训39

8．4．2必须引入工具进行辅助40

8．4．3单元测试者加强对被测软件的全面了解40

8．5结尾40

九漫谈人机界面测试41

9．1一致性测试41

9．2信息反馈测试42

9．3界面简洁性测试42

9．4界面美观度测试42

9．5用户动作性测试43

9．6行业标准测试43

9．7小结44

十基于Web的系统测试方法44

10．1功能测试45

10．1．1测试45

10．1．2表单测试45

10．1．3Cookies测试45

10．1．4设计语言测试45

10．1．5数据库测试46

10．2性能测试46

10．2．1连接速度测试46

10．2．2负载测试46

10．2．3压力测试46

10．3可用性测试47

10．3．1导航测试47

10．3．2图形测试47

10．3．3容测试47

10．3．4整体界面测试47

10．4客户端兼容性测试48

10．4．1平台测试48

10．4．2浏览器测试48

10．5安全性测试48

10．6总结49

十一为盈利而测试49

11．1引言49

11．2什么是软件测试50

11．3六个误区50

11．3．1误区一：

忽视对正常输入的测试50

11．3．2误区二：

忽视设计阶段的参与与评估50

11．3．3误区三：

忽视测试计划与测试文档的建立及维护51

11．3．4误区四：

忽视缺陷的分析，报告及跟踪51

11．3．5误区五：

错误的测试目标及测试终止条件51

11．3．6误区六：

不懂得合理调配使用测试人员的知识技能结构51

11．4软件质量与软件测试52

11．5软件测试的经济目的54

11．5．1满足用户需求，提高产品的竞争力，最终提高产品的销售量54

11．5．2尽早发现缺陷，降低后继质量成本54

11．6何时应当停止测试56

十二整体性能测试剖析57

十三性能测试工具之研究62

13．1性能测试的意义62

13．2性能测试工具综述63

13．3性能测试工具的体系架构64

13．4虚拟用户产生器Vugen65

13．5Proxy二次捕获的问题67

13．6关联的问题68

13．7脚本的问题70

13．8Conductor和Player部分71

13．9Conductor和Player的技术要点72

13．10数据分析工具Analysis72

13．11结束语72

十四性能测试原理及性能测试实例分析73

14．1软件测试中的性能测试73

14．1．1性能测试的含义73

14．1．2性能测试的分解73

14．2一个性能测试实例74

14．2．1被测系统74

14．2．2对被测系统进行性能测试75

14．5总结80

十五软件GUI测试中的关注点80

15．1不能不说的二个问题81

15．1．1软件测试中的“二八”原则81

15．1．2软件黑盒测试解决的问题81

15．2软件黑盒测试常见错误类型及说明81

15．2．1用户界面错误81

15．2．2功能性81

15．2．3人机交互82

15．3命令结构和录入87

15．3．1不一致性87

15．3．2“最优化”87

15．3．3菜单89

15．4遗漏的命令90

15．4．1状态转换90

15．4．2危机预防90

15．4．3由用户进行的错误处理91

15．4．4其他问题91

15．5程序僵化92

15．5．1用户可调整性92

15．5．2控制方式93

15．6性能94

15．6．1降低程序速度94

15．6．2缓慢回应94

15．6．3如何减少用户吞吐量94

15．6．4反应拙劣94

15．6．5没有提前输入95

15．6．6没有给出某个操作会花很长时间的警告95

15．6．7程序太多提示和询问95

15．6．8尽量使用简单命令和提示95

15．7输出95

15．7．1不能输出某种数据95

15．7．2不能重定向输出95

15．7．3与一个后续过程不兼容的格式96

15．7．4必须输出的很少或很多96

15．7．5不能控制输出布局96

15．7．6荒谬的精度输出级别96

15．7．7不能控制表或图的标记96

15．7．8不能控制图形的缩放比例96

15．8错误处理96

15．8．1错误预防96

15．8．2错误检测97

15．8．3错误恢复98

15．8．4边界相关的错误99

15．8．5计算错误100

15．9小结100

十六软件测试技术100

16.1软件测试基础101

16.1.1测试目标101

16.1.2测试原则101

16.1.3可测试性102

16.2测试用例设计104

16.3白盒测试104

16.4基本路径测试105

16.4.1流图符号105

16.4.2环形复杂性106

16.4.3导出测试用例106

16.4.4图矩阵108

16.5控制结构测试108

16.5.1条件测试108

16.5.2数据流测试110

16.5.3循环测试111

16.6黑盒测试112

一软件测试从零开始

【摘要】本文面向软件测试新手，从测试前的准备工作、测试需求收集、测试用例设计、测试用例执行、测试结果分析几个方面给出建议和方法。

鉴于国的软件开发、测试不规的现状，本文为软件测试新手提供了若干个软件测试的关注点。

【关键词】软件测试、测试用例、测试需求、测试结果分析

1．1引言

几年前，从学校毕业后，第一份工作就是软件测试。

那时候，国的软件企业大多对软件测试还没有什么概念，书店里除了人杰编写的《计算机软件测试技术》之外，几乎没有其它的软件测试相关书籍，软件测试仅仅在软件工程的教材中作为一个章节列出来，因此，我对软件测试一无所知。

不过，在正式走上工作岗位之前，公司提供了为期两周的系统的软件测试技术专题培训，对接下来的软件测试工作有很大的指导意义。

现在，我继续从事软件测试的培训与咨询服务，在这个过程中，亲眼目睹了很多软件测试新手面对的困惑，他们初涉软件测试行业，没有接受系统的培训，对软件测试一无所知，既不知道该测试什么，也不知道如何开始测试。

下面针对上述情况，给出若干解决办法。

1．2测试准备工作

在测试工作伊始，软件测试工程师应该搞清楚软件测试工作的目的是什么。

如果你把这个问题提给项目经理，他往往会这样回答：

“发现我们产品里面的所有BUG，这就是你的工作目的”。

作为一名软件测试新手，如何才能发现所有的BUG？

如何开始测试工作？

即便面对的是一个很小的软件项目，测试需要考虑的问题也是方方面面的，包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用户的并发容量等等。

该从何处下手呢？

1．2．1向有经验的测试人员学习

如果你进入的是一家运作规的软件公司，有独立的软件测试部门、规的软件测试流程、软件测试技术有一定的积累，那么，恭喜你！

你可以请求测试经理委派有经验的测试人员作为你工作上的业务导师，由他列出软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录，在业务导师的指导下逐步熟悉软件测试的相关工作。

其实，在很多运作规的软件公司，已经把上述的师父带徒弟的方式固化到流程中。

如果你进入的是一个软件测试一片空白的软件企业，那么，也恭喜你！

你可以在这里开创一片自己的软件测试事业，当然，前提是老板确实认识到软件测试的重要性，实实在在需要提高产品的质量。

这时候，可以到国的软件测试论坛和相关上寻找软件测试资源，这种情况下，自学能力和对技术的悟性就至关重要了。

1．2．2阅读软件测试的相关书籍

现在，中文版的软件测试书籍越来越多，有的是国人自己写的，有的是翻译国外经典之作。

可以到.chinapub.或者.cnforyou.等网络购书的站点查找软件测试相关的书籍。

目前，从国外引入的软件测试书籍有很多经典之作，但是，翻译成中文后，翻译质量对阅读效果有很大的影响。

1．2．3走读缺陷跟踪库中的问题报告单

如果您所在的公司已经有软件缺陷跟踪库了，无论采用的是商用工具，如ClearQuest、TestDirecter等工具，还是采用的Bugzilla、Mantis等开源工具，这都无关紧要，缺陷跟踪库中的缺陷报告单才是有价值的。

缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现，同时也是软件产品问题的集中体现。

一般来说，缺陷报告单中最关键的几个部分包括：

第一部分是发现缺陷的环境，包括软件环境、硬件环境等；第二部分是缺陷的基本描述；第三部分是开发人员对缺陷的解决方法。

通过对上述缺陷报告单的三个部分作仔细分析，不知不觉你已经吸收了其他软件测试人员的工作经验，并掌握了软件产品常见的基本问题。

这是迅速提高软件测试经验的好方法。

1．2．4走读相关产品的历史测试用例

如果你所在的公司有测试用例管理系统，那么，走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。

走读测试用例也是有技巧的。

测试用例写作一般会包括测试用例项和根据测试用例项细化的测试用例，下面举例说明。

“测试用户登录的功能”是一个测试项，该测试项的目的是测试用户登录功能是否正确，是否能够完成正常的登录功能，是否能够对非法用户名和密码做异常处理等等。

因此，根据该用例项，可以设计出若干个测试用例，大多数情况下，测试用例项和测试用例是一对多的关系。

通过走读测试用例项目，你可以掌握应该从哪些功能点着手未来的测试工作；通过走读软件测试用例，你可以了解如何根据被测试的功能点开展软件测试用例的设计工作，包括如何确定测试用例的输入、测试用例的操作步骤和测试用例的输出结果等。

总之，走读其他软件测试人员设计的优秀软件测试用例，是提高自身用例设计水平的好方法。

1．2．5学习产品相关的业务知识

软件测试人员不仅要掌握软件测试技术相关知识，对产品相关的业务知识也要学习。

这很好理解，如果从事财务软件的测试工作，一定要学习财务知识；如果从事通讯产品测试工作，那么相关的通讯理论知识也是必须的；如果从事银行软件的测试，银行的业务流程也是不可或缺的知识点。

因此，在学习软件测试技术的同时，千万不要忽略产品相关业务知识的学习。

如果你是一个软件测试技术专家，但是对产品业务知识一无所知，那么也只能测试出来纯粹的软件缺陷，而面对眼前出现的产品业务相关的缺陷，很可能是视而不见，如此这般，软件测试的效果会大打折扣。

1．3识别测试需求

识别测试需软件测试的第一步。

如果开发人员能够提供完整的需求文档和接口文档，那固然好。

可以根据需求文档中描述的每个功能项目的输入、处理过程和输出，来设计测试用例。

如果开发人员没有提供软件需求文档，那该如何是好？

下面给出几个有效的方法：

1．3．1主动获取需求

开发人员通常不会更好地考虑软件测试，如果没有开发流程的强制规定，他们通常是不愿意提供任何开发文档，即便有强制规定，需求文档也未必能够真正指导软件系统测试工作。

因此，需要测试人员发挥主观能动性，与相关的软件开发项目经理和软件开发人员保持沟通，了解软件实现的主要功能是什么，并记录得收集到的信息。

一般来说，开发人员即便没有提供相关需求文档，也会保存一些简单的过程文档，主动向开发人员索要这些文档，可以作为测试的参考。

此外，可以与公司的技术支持人员交流，技术支持人员是最贴近用户的人，因此，通过交流可以获取第一手的用户使用感受，在测试的过程中会更加贴近用户。

当拿到相关的资料后，从哪些方面分析需求？

如何与开发人员交流需求？

其实，只要把握需求分析的几个关键的点就可以解决问题：

输入、处理过程、输出、性能要求、运行环境，下面针对每一个项目逐一分析：

软件输入：

与该需求相关的一切可能输入，可以从这几方面考虑，输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、输入参数的精度和输入参数的有效输入围。

在测试用例设计中，这部分容作为测试用例输入的依据。

处理过程：

描述对输入数据所执行的所有操作和如何获得输出的过程。

测试人员了解处理过程即可，在测试过程中发现BUG时候，如果对处理过程了解的深入，对定位问题根源有很大的帮助。

软件输出：

描述每个需求的输出结果，包括输出的位置（如计算机显示器、打印机，文件），输出参数的数量、输出参数的度量单位、输出参数的时序、输出参数精确度、输出参数的有效输出围、错误消息。

在测试用例设计中，这部分容作为测试用例的预期输出。

性能要求：

与该需求相关的性能要求，比如“插入ATM取款卡后，3秒钟弹出提示用户取款的图形界面”。

3秒钟这一限制，就是对需求的基本性能要求。

运行环境：

软件的运行所需的环境，包括硬件平台的要求、操作系统的要求、数据库的要求，以及其它相关支撑软件的要求。

1．3．2确认需求的优先级

确认需求的优先级是很必要的，如果在产品进度比较紧的情况下，测试人员可以考虑优先测试优先级高的需求项，如果进度允许，那么在测试优先级低的需求项，如果进度不允许，那么就放弃测试优先级低的需求项。

如果软件公司有规的流程支撑，开发人员在提供软件需求文档的时候，应该在文档中确定需求的优先级。

但是，如果开发人员连基本的软件需求文档都没有提供，又怎能指望他们确定软件需求的优先级？

如果是这样，需求的优先级只能由测试人员完成了。

1．3．3加入开发小组的群组

测试人员需要通晓被测试产品，但是，产品在开发的过程中往往是不断变化的。

如果软件开发团队有一套变更控制流程，测试人员会对产品的变更了如指掌。

如果没有变更控制，那就要采用其他的土方法了。

如果公司里面有自动化办公系统，也许采用的是LotusNotes系统，也许使用的是E-mail系统，测试人员应该加入到开发人员的群组中。

当开发人员通过讨论问题、通知召开技术会议的时候，测试人员可以及时知晓，如果必要，可以参加开发人员的技术会议。

即便公司里面有了软件变更控制流程，加入到开发群组也是一个很好的习惯。

1．3．4与开发人员为邻

建议测试人员与开发人员为邻。

我所在的测试组曾经与开发组是在相邻的写字间里，开发人员与测试人员的关系非常融洽，抛去同事关系，大家还是不错的朋友。

不管开发人员有什么样的活动，测试人员都能第一时间获得信息。

无论从事软件测试工作，还是从事其它的工作，与工作中上下游环节的同事保持良好的个人关系对工作有很大便利。

一般的公司部都存在部门墙，良好的人际关系是打通部门墙的手段之一。

向领导建议测试人员与开发人员为邻，这很必要。

1．4测试用例设计

测试需求收集完毕后，开始测试设计。

测试用例是什么？

测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。

设计测试用例需要考虑以下问题：

1．4．1测试用例的基本格式

软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。

用例编号：

测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则：

PROJECT1-ST-001，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。

定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

测试标题：

对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。

比如“测试用户登录时输入错误密码时，软件的响应情况”。

重要级别：

定义测试用例的优先级别，可以笼统的分为“高”和“低”两个级别。

一般来说，如果软件需求的优先级为“高”，那么针对该需求的测试用例优先级也为“高”；反之亦然，

测试输入：

提供测试执行中的各种输入条件。

根据需求中的输入条件，确定测试用例的输入。

测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

操作步骤：

提供测试执行过程的步骤。

对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分容在操作步骤中详细列出。

预期结果：

提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。

如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

软件测试用例的设计主要从上述6个域考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。

具体的测试用例设计方法可以参见相关的测试书籍，白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍，这里不作赘述。

1．4．2重用同类型项目的测试用例

如果我看得远，那是因为我站在巨人的肩上－－牛顿。

一般来说，每个软件公司的项目可以分为固定的几大类。

可以按业务类型划分，比如ERP软件、产品数据管理软件、通信软件、地理信息系统软件等等；可以按软件结构来划分，比如B/S架构的软件、C/S架构的软件、嵌入式软件等等。

参考同类别软件的测试用例，会有很大的借鉴意义。

如果，公司中有同类别的软件系统，千万别忘记把相关的测试用例拿来参考。

如果，系统非常接近，甚至经过对测试用例简单修改就可以应用到当前被测试的软件。

“拿来主义”可以极大的开阔测试用例设计思路，也可以节省大量的测试用例设计时间。

1．4．3利用已有的软件Checklist

在上面一个小节中，按照不同的规则划分了不同的软件类型。

每种类型的软件都有一定的测试规，比如，WEB软件系统在系统测试过程中，会有一系列的式，比如针对Cookie就会有很多测试点。

在设计测试用例的时候，不妨到网上去搜索相关的Checklist，不过国外的很少有这方面的资料，即便有，也不是特别系统。

可以先找一份粗糙的Checklist，然后，在设计测试用例的时候不断的去完善它，以作为下次测试用例设计的基础。

1．4．4加强测试用例的评审

测试用例设计完毕后，最好能够增加评审过程。

同行评审是CMM3级的一个KPA，如果因为公司没有通过CMM3级，就不开展同行评审是不恰当的。

测试用例应该由产品相关的软件测试人员和软件开发人员评审，提交评审意见，然后根据评审意见更新测试用例。

如果认真操作这个环节，测试用例中的很多问题都会暴露出来，比如用例设计错误、用例设计遗漏、用例设计冗余、用例设计不充分等等；如果同行评审不充分，那么，在测试执行的过程中，上述本应在评审阶段发现的测试用例相关问题，会给测试执行带来大麻烦，甚至导致测试执行挂起。

1．4．5定义测试用例的执行顺序

在测试用例执行过程中，你会发现每个测试用例都对测试环境有特殊的要求，或者对测试环境有特殊的影响。

因此，定义测试用例的执行顺序，对测试的执行效率影响非常大。

比如某些异常测试用例会导致服务器频繁重新启动，服务器的每次重新启动都会消耗大量的时间，导致这部分测试用例执行也消耗很多的时间。

那么在编排测试用例执行顺序的时候，应该考虑把这部分测试用例放在最后执行，如果在测试进度很紧的情况下，如果优先执行这部分消耗时间的异常测试用例，那么在测试执行时间过了大半的时候，测试用例执行的进度依然是缓慢的，这会影响到测试人员的心情，进而导致匆忙地测试后面的测试用例，这样测试用例的漏测、误测就不可避免，严重影响了软件测试效果和进度。

因而，合理地定义测试用例的执行顺序是很有必要的。

1．5测试用例执行

测试用例设计完毕后，接下来的工作是测试执行，测试执行中应该注意以下几个问题：

1．5．1搭建软件测试