软件测试周报总结(通用3篇)

周报是按周出版的报纸， 以下是为大家整理的关于软件测试周报总结3篇 , 供大家参考选择。

软件测试周报总结3篇

软件测试周报总结篇1

1.软件质量保证包括软件质量管理方法、有效的软件工程技术（方法、工具）、在整个软件工程中采用的正式技术复审、多层次的测试策略、对软件文档及其修改的控制、保证软件遵从软件开发标准的规程以及度量、报告机制。

2.21世纪计算机软件发展的大方向是质量优于性能改进。

3.软件测试定义：软件测试是使用人工或自动手段来运行或测定某个系统的过程，检验是否满足规定需求，或者弄清预期结果与世纪结果之间的差别。

4.测试是程序执行的过程，目的在于发现错误，一个好的测试用例可以发现至今尚未发现的错误，一个成功的测试能发现至今未发现的错误。

5.软件测试方法：（1）从是否需要执行被测试软件的角度分为静态测试和动态测试；（2）从测试是否针对系统的内部结构和具体实现算法的角度分为黑盒测试和白盒测试。

6.静态测试无需执行被测代码，而是借助专用的软件测试工具评审软件文档或程序，度量程序静态复杂度，通过分析或检查程序的文法，结构、过程、接口等来检查程序的正确性，借此发现程序不足之处减少错误概率。

7.黑盒测试也称功能测试或数据驱动测试，是已知软件所需功能，通过测试来检测每个功能是否能正常使用。

8.白盒测试也称结构测试或逻辑驱动测试，知道软件内部的工作过程，可通过测试来检测软件产品内部的动作是否按照规格说明书的规定要求正确运行，并且按照程序内部的结构测试程序来检验程序中的每条通路是否都能按照预定的要求正常工作，而不考虑功能是否正确。

9.软件质量控制是一组由开发组织使用的程序和方法，可在规定的资金投入和时间限制的条件下提供满足客户质量要求的软件产品并持续不断地改善开发过程和开发组织本身以提高将来生产高质量软件产品的能力。

10.软件质量控制是对开发过程中软件产品（包括阶段性产品）的质量信息进行连续的收集，反馈。

11.详细描述PDCA：（1）计划Plan：确定参数要求；（2）实施Do：根据要求开展活动（3）检查Check：通过评审、度量、测试确认满足要求；（4）改进Action：纠正参数要求再开发。

12.软件质量控制的实施过程：

1、预开发阶段

2、开发阶段

3、维护阶段

13.软件质量保证的目的是使软件过程对于管理人员来说是可见的，通过对软件产品和活动进行评审和审计来验证软件是符合标准的。软件质量保证组在项目开始时就一起参与建立计划，标准和过程。这些将使软件项目满足机构方针的要求。

14.软件质量度量的根本目的是为了管理的需要利用度量来改进软件过程。

15.软件度量是对软件开发项目、过程、产品、进行数据定义、收集、分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制、改善。

16.通过软件度量可以改进软件开发过程。促进项目成功，开发高质量的软件产品。

17.软件度量作用：

18.对于软件质量，CMM的定义如下：一个系统、组件、过程符合特定需求的程度；一个系统、组件、过程、符合客户或用户的要求或者期望程度。

19.软件质量的要素指以下两个方面：

（1）从技术角度讲，对软件整体质量影响最大的是那些质量属性才是质量要素；

（2）从商业角度讲。客户最关心的、能成为卖点的质量属性才是质量要素。

20.影响软件质量的因素：人（M）、过程（P）、技术（T）。

21.软件质量保证模型：McCall模型，Boehm模型、FURPS模型、ISO9126。

22.软件过程度量不是单一的活动，而是一组活动的集合，本身也是一个系统的过程。

23.软件过程度量的目标：是对软件过程的行为进行目标管理，并在度量的基础上对软件过程进行控制、评价、改善。

24.软件过程度量就其对象而言主要包括3个，即工作产品、软件项目、过程。

25.软件过程度量的方法包括常用的采集方法和常用的数据分析方法。

26.软件质量度量的常见问题：

（1）度量的太多、太频繁。

（2）度量的太少、太迟。

（3）度量了不正确的事物或属性

（4）度量的定义不精确。

（5）手机了数据却没有利用。

（6）错误地解释度量数据。

（7）自动化工具欠缺。

27.基于目标的软件过程度量方法（GQM）是一种层次状结构，分层次解释，一个目标有多个问题，每个问题可进一步分为几个度量。

28.软件可靠性的定义：在规定条件下，在规定时间内，软件不引起系统失效的概率。

29.软件可靠性产生的软件差错包括以下几种：

（1）需求分析定义错误

（2）设计错误

（3）编码错误

（4）测试错误

（5）文档错误

30.软件质量标准分五个级别：国际标准、国家标准、行业标准、企业标准、项目规范。

31.CMM（软件过程成熟度模型）是对软件组织在定义、实施、度量、控制和改善其软件过程中各个发展段的描述；包括5个等级，18个过程域、52个目标、300多个关键实践。5个等级分为，优化级、已管理级、已定义级、可重复级、初始级。

32.CMM是一种用于评价软件承保能力并帮助其改善软件质量方法，侧重于软件开发过程的管理及工程能力的提高与评估。

33.CMMI（软件能力成熟度模型）是CMM中一种单一的模型。

34.软件评审是一些用于开发过程早起检查和纠正缺陷的有效方法，也可以用来检查未成形执行代码的文档的缺陷。

35.软件评审的方法：特别检查，检查，走查，团队评审，检视。

36.全面质量管理是一种由顾客的需要和期望驱动的管理哲学，是以质量为中心，建立在全员参与基础上的一种管理方法，其目的在于长期获得顾客满意、组织成员和社会的利益。

37.全面质量管理包括以下定义：

（1）强烈关注顾客

（2）精确度量

（3）坚持不断的改进

（4）向员工授权

（5）改进组织中每项工作的质量

38.软件测试：是软件质量保证的关键阶段，是对软件设计和编码的最终审查。

39.广义的软件测试包括验证、确认。

40.软件测试就是在软件投入运行前对软件的需求分析、设计、实现编码进行最终审查。

41.软件测试的目的：

（1）在于发现错误；

（2）测试用例在于能发现至今未发现的错误；

（3）发现了至今未发现的错误的测试。

42.软件测试原则：

（1）在整个开发过程中要尽早地不断地进行软件测试。

（2）在开始测试时不应默认程序中不存在错误。

（3）在设计测试用例时要给出测试的预期结果。

（4）测试工作应避免由系统开发人员或开发机构本身来承担。

（5）对合理的和不合理的输入数据都要进行测试。

（6）重点测试错误集群的程序区段。

（7）除检查程序功能是否完备外，还要检查程序功能是否多余。

（8）用穷举测试是不可能的。

（9）长期完整地保留所有的测试用例和测试文件，直则该软件产品被废止为止。

43.软件测试过程概述：由于软件错误的复杂性，在软件工程范围内要综合应用测试技术，根据定义域中的取值，通过执行和观察将预期的行为和实际的行为做比较，以确认测试结果。

44.软件测试的5个要素：质量、人员、技术、资源、流程。

45.综合测试分为四步：单元测试、集成测试、系统测试、验收测试，在所有的测试过程中始终贯穿着回归测试。

46.单元测试指对软件中最小可测试单元或基本组成单元进行检查和验证。

47.单元测试测试方法：

驱动模块：用来模拟被测模块的上级调用模块，功能比真正的上级模块简单得多，仅仅是接受测试数据，并向被测模块传送测试数据，启动被测模块，回收并输出测试结果。

桩模块：用来模拟被测模块在执行过程中所需要调用的模块，接受被测模块输出的数据并完成它所指派的任务。

48.集成测试（重点）：

定义：集成测试在单元测试的基础上将所有已经通过单元测试的模块按照概要设计的要求组装为子系统或系统。

49.集成测试测试内容：

（1）将各模块连接起来时穿越模块接口的数据是否会丢失。

（2）各子功能模块组合起来能否达到预期要求的父功能；

（3）模块的功能是否会对其他模块的功能产生不利影响。

（4）全局数据结构是否有问题，是否会被异常修改。

50.集成测试测试方法：

1.非增量式集成测试方法

2.增量式集成测试方法

（1）自顶向下增量式集成测试

（2）自底向上增量式集成测试

比较：

51.验收测试是一种有效性测试或合格性测试，是以用户为主，软件开发人员、实施人员和质量保证人员共同参与的测试。

52.验收测试测试技术：

α测试：内部人员模拟各类用户行为对即将面世的软件产品进行测试。

β测试：用户在日常实际使用β版本。

把α测试看成是对一个早期的、不稳定的软件版本所进行的验收测试。而把β测试看成是对一个晚期的、更加稳定的软件版本所进行的验收测试。

53.回归测试指修改了旧代码后重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

54.

55.

56.黑盒测试法是把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。

57.等价类划分法是一种黑盒测试技术，不考虑内部结构，把所有可能的输入数据（即程序的输入域）划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。

58.划分等价类：（1）有效等价类（2）无效等价类

59.设计测试用例原则：

（1）每一个等价类规定性一个唯一的编号

（2）设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，然后重复这一步，知道酥油的有效等价类都被覆盖为止。

（3）设计一个引得测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，然后重复这一步，直到所有的无效等价类都被覆盖为止。

60.边界值选择法：

61.因果图设计法：

（1）分析程序规格说明的描述中那些是原因，哪些是结果。

（2）分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”

（3）表明约束条件

（4）把因果图转换成判定表

（5）为判定表每一列表示的情况设计测试用例。

62.白盒测试法与黑盒测试法相反，前提是可以把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。

63.白盒测试实施步骤：

（1）测试计划阶段（2）测试设计阶段（3）测试执行阶段（4）测试总结阶段

64.白盒测试的方法在总体上分为静态方法和动态方法。

65.软件失效处理机制（陈述）

（1）软件错误：指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生，软件错误是一种人为过程，相对于软件本身是一种外部行为。

（2）软件缺陷：存在于软件（文档、数据或程序）之中的那些不希望或不可接受的偏差。结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。

（3）软件故障：指软件运行过程中出现的一种不希望或不可接受的内部状态。

（4）软件失效：指软件运行时产生的一种不希望或不可接受的外部行为结果。

66.软件缺陷管理就是在软件开发过程中对发现的缺陷进行跟踪，并确保每个被发现的软件缺陷被关闭。

67.严重性是软件缺陷对软件质量的破坏程度，反应其对产品、用户的影响，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。

68.优先级表示修复缺陷的重要程度和应该何时修复，他是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，那些缺陷可以稍后修正。

69.严重性和优先级并不总是一一对应的。

70.

71.软件缺陷的有效描述规则主要如下：（1）单一准确（2）可以再现（3）完整统一（4）短小精练（5）特定条件（6）补充完善（7）不做评价

72.软件缺陷生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至将缺陷最终解决的一个完整过程。

73.

74.集成测试是在单元测试的基础上将多个模块组合在一起进行测试的过程，主要检查各个软件单元之间的相互接口是否正确，是介于单元测试和系统测试之间的过渡阶段，是单元测试的扩展和延伸。

75.单元测试主要关注模块的内部，集成测试查看接口时主要关注穿越接口的数据、信息是否正确。

76.集成测试分为三个层次；即模块内集成测试、子系统内集成测试和子系统间集成测试。对于面向对象的应用系统来说，可以把集成测试分为两个阶段即类集成测试和类间集成测试。

77.驱动模块自底向上，桩模块自顶向下。

78.非渐增式集成测试采用一步到位的方法进行测试，即对所有模块进行个别的单元测试后按程序结构图将各模块连接起来，连接后的程序当做一个整体进行测试。

79.自顶向下增式集成测试表示逐步集成和逐步测试，是按照程序结构图自上而下进行的，即从顶层主控模块开始测试，对以后如何选择下一个要测试的模块并没有一个统一的方法，唯一的原则是下一次要测试的模块至少有一个调用的模块已经测试过。

80.自顶向上增式集成测试是从软件结构的最下层模块开始测试，在测试较高的高层模块时所需的下层模块功能都已具备，所以不在需要桩模块。

81.自底向上缺点是在于直到最后一个模块被加进去以后才能看到整个程序的框架，三明治集成测试弥补自底向上缺点。

82.系统测试是对已经集成好的软件系统进行彻底的测试，已验证软件系统的正确性和性能是否满足需求分析所指定的要求，系统测试通常是消耗测试资源最多的地方，一般可能会在一个相当长的时段内由独立的测试小组进行。

83.系统测试的主要方法：（选择、填空）

（1）性能测试

（2）强度测试

（3）安全性测试

（4）兼容性测试

（5）恢复测试

（6）用户图形界面测试

（7）安装测试

（8）可靠性测试

（9）配置测试

（10）可用性测试

（11）文档资料测试

（12）网站测试

84.测试方法的应用：集成测试及其后的测试阶段一般采用黑盒测试方法，策略如下：

（1）用边值分析法或等价类法提出基本测试用例

（2）用猜测法补充新的测试用例

（3）如果程序的功能说明中含有输入条件的组合，需要在一开始就用因果图法，然后再按以上两步进行。

85.软件测试文件描述被执行的软件测试及测试的结果。

86.测试管理者的工作原则

（1）雇测试工作最合适的员工

（2）与每个小组成员定期一一谈话

（3）假定员工能胜任各自的测试工作

（4）对待员工以他们能接受的方式

（5）重视结果而不是时间

（6）承认自己的错误

87.软件调试方法：（1）蛮力法（2）回溯（3）原因排除法

88.软件测试自动化最根本的意义是解决手工劳动的复杂性，成为代替某些重复性行为模式的最佳工具。

89.软件测试自动化事实理由：

（1）提高测试效率和降低测试成本

（2）对于功能性边界测试，人工测试非常耗费时间，而自动化测试很快并且很准确。

（3）项目测试人员的任务都是手工处理的，而实际上很大一部分重复性强的测试工作是可以独立开来自动实现的。

（4）自动测试可以避免人工测试容易犯的错误，如错误测试、漏测试、多测试和重复测试等

（5）典型应用，例如多用户并发注册，并发交易请求，并发交易应答，人工测试几乎办不到，但是自动测试却很容易实现。

90.

软件测试周报总结篇2

1、为什么要测试？软件测试的目的？软件测试的重要性？

A、发现缺陷BUG/Defect

B、评估软件、项目、产品上线风险？

C、满足客户要求、改善软件质量

D、帮助开发发现问题、定位问题、修改问题

E、软件验收、也包括第三方的验收（验收测试、UAT）

F、通过缺陷分析，从而预防同类缺陷的发生。

G、错的：软件测试能缩短开发周期。也不能直接降低开发成本。

H、改善软件的用户体验（易用性、性能、稳定性）12306订票

角度：系统性思维（1、2、3、4、5、6、7+=100: 1+2+34+56+7=100）门萨测试

角色：用户：发现缺陷、改善用户体验

：开发：证明软件GoodEnough，定位缺陷，从而减少开发修改问题的时间

历史：证明程序是正确？--》发现功能缺陷、错误--》发现不足（易用性、性能、稳定性）--》缺陷预防

现实：验收、评估质量风险、第三方评测、为了盈利而测试（商业成功）（测试成本《《软件缺陷导致成本）

2、什么是软件测试？

IEEE（国际电器电子工程协会）：目的：验证系统是否满足需求、验证实际结果跟期望结果的差异？

xll：在一定的软件、硬件、网络环境下（搭建测试环境LAMP），遵循相对规范的测试流程，使用合适的测试工具，合理的测试方法，测试或运行软件，其目的是为了验证系统是否满足需求、验证实际结果跟期望结果的差异。

3、软件测试的工作内容？

BAT：Baidu、Alibaba、Tecent

4、测试与调试的区别：

对象：代码、文档；代码

人：测试工程师；开发

流程：有规范的流程（除了随机测试和探索性测试外）；无流程

目的：发现问题；定位和解决问题

5、测试的七大原则：

A、测试只能证明软件存在缺陷，不能证明软件没有缺陷（证伪不证真）

B、测试是无法穷举？（输入数据是无法穷举、处理逻辑路径是无法穷举），学习测试用例的设计方法。

C、测试应该尽早测试？（发现缺陷和修改的成本越早越低。需求-设计-代码-测试-运行）

测试应该在需求之后？设计之后？编码之后？测试应该尽早介入，测试应该贯穿整个软件生命周期。

D、缺陷的80/20原则（群集效应）。如果测试发现某个模块有问题？继续深入测试。刨根问底？破案？

E、杀虫剂悖论（软件对用例会免疫力）不断更新测试用例、更新的测试思维

F、测试依赖于商业背景（与行业知识相关）结合专业和工作经历和准备相关的项目。优点 SWOT

优势、劣势、机会、威慑（竞争对手）准备行业软件

G、不存在缺陷的软件并不代表是有用的系统。

一个合格、优秀、卓越、伟大的测试工程师的能力与素质的要求？

素质、性格、能力、管理、英语、行业六大维度回答

答

6、测试与开发的关系（独立性）

未来趋势：3大趋势：1、测试与开发的结合越来越紧密；2、测试与行业背景结合越来越紧密

3、专项测试（测试分工会越来越精细），大数据测试（数据库，用户工程） IT，DT。

比较分析不同网站的购物流程：亚马逊、当当网、京东、淘宝（CDC）联众游戏、QQ游戏

1、测试人员也开发，开发也做测试（Google：吃狗粮的文化）

2、测试人员独立与项目（在项目中有专职的测试人员：客观）

3、测试人员独立部门（有专门的测试部门：权威）

4、测试人员独立技术（测试工具部、测试技术部）

5、测试人员独立于公司（测试服务机构或者公司）

缺点：沟通越困难，对产品或者项目的熟悉越少。感情色彩：这是个非常严重的bug！！！！！

测试人员发现了BUG，开发人员不愿意修改，该怎么办？

加班？敏感问题？三方思考：对方、客观中立、自己

地铁自动售货机 PM

1、计划阶段：可行性分析：A、经济可行性分析；B、技术可行性分析（外包）

计划项目里程碑：计划、需求SRS、概要设计HLD、详细设计LLD、编码、测试、运行与维护

输出软件项目计划 SPP（Software Project Plan）PM

输出软件确认与验证计划 SVVP(Software verfication Validation Plan)软件测试计划 TPM

2、需求阶段：产品（金蝶）：调研与项目（用户） SE 系统工程师 what to develop？黑盒

TSE 分析测试需求挖掘用户的隐性需求

需求规格SRS：功能需求：1、接受货币 2、选择商品 3、计算功能 4、输出商品和找零、5、商品管理

性能需求：30S之内输出商品和找零

可靠性需求：7X24小时

易用性需求：良好易用性，不需要培训。最好用的软件baidu

需求分析的技术：UML建模（需求工程）

3、设计阶段：概要设计HLD （High Level Design 高层设计）：模块分解与接口的定义。

1、接受货币（识别真伪、识别面额、识别类别）分解原则？高内聚低耦合？（百度）

（无直接耦合、数据耦合、印记耦合、控制耦合、公共耦合、内容耦合）回归测试

2、接口：函数接口、消息接口、文件接口（QQ修改头像）、数据库接口

详细设计LLD（Low Level Design 底层设计）：算法的描述（程序=数据结构+算法/思路（各种排序））流程图、伪码。白盒

4、编码阶段：熟悉一门编程语言的语法 C、Java、PHP和一个开发工具或者平台 VC、Eclipse等

熟悉一门脚本语言：python、ruby、perl、tcl、shell BAT

5、测试阶段：测试工具、方法、流程

6、运行与维护：技术支持

测试应该贯穿整个软件生命周期。

1、测试应该在SRS之后？

HLD

LLD

CODE

瀑布模型：缺点：不适应需求变更频繁的项目。适合产品开发的项目。测试滞后于开发。

V模型：

用户需求URS-----------------------------------------验收测试UAT（User Acceptance Testing）

需求规格SRS---------------------------------系统测试ST（System Testing）

概要设计HLD-------------------------集成测试IT（Integration Testing）

详细设计LLD-----------------单元测试UT（Unit Testing）

编码CODE------------代码评审CODE Review

H模型、X模型。

1、方法的背景？2、方法的操作步骤、3、优缺点、4、适用范围、5与其他方法怎么样配合、6重点、要点、难点

等价类：

1、背景：why？输入无法穷举，我们不能测试所有情况，必选选择有代表数据来验证

2、操作步骤：

1、分析被测试对象输入条件以及子条件（关键点：考虑隐性子条件，条件正交完备）

2、根据等价类划分原则划分有效等价类和无效等价类

原则：1、规定范围或者格式，譬如长度6~18位，可以划分1个有效、2个无效等价类

2、规定的集合或者满足某个条件，譬如一些下拉列表的选择，可以划分1有效、1个无效

3、规定了必须如何，譬如组成、开头，可以划分1个有效和若干个无效。

4、规定是布尔量，譬如是否已经注册，可以划分1个有效和1个无效

5、规定是多种选择（还有不同的处理方式），譬如163邮箱注册的后缀，可以划分成若干个有效，和1个无效。

3、根据等价类设计用例原则：（1、用一个用例覆盖尽可能多的有效等价类；

2、为每一个无效等价类单独设计用例：为了更好定位问题）设计数据

原则：同样效果情况下用例数尽可能少，精确定位问题。

3、优缺点：适用范围广、能以有限用例达到比较好覆盖无法穷举的输入。

缺点：方法没有刻意考虑边界，只能针对单个输入条件，没有考虑输入之间组合以及输入与输出的关系。

4、适用范围：只要有业务规则的情况下，最好是有清晰的业务规则

5、与其他方法怎么样配合：一般情况下会跟边界值方法结合使用。

6、要点：等价类划分的原则：尤其是要注意隐性条件（完整性，不要遗漏）

思考：微信发送图片、上传QQ头像、导入文件这类如何使用等价类

边界值：

1、背景：why？：很多错误通常都发生在边界上。

2、操作步骤：

1、分析被测试对象输入条件以及子条件

2、分析上点、离点和内点

3、根据边界值设计用例的原则设计数据去覆盖可能上点、离点和内点

3、优缺点：优点：能够比较高效发现问题

缺点：不能考虑输入与输出之间的关系

4、适用范围：规定了大小、长度、值的范围、分辨率（广义）

5、与其他方法怎么样配合：与等价类配合

6、要点：找到边界（隐含的边界）

航空行李托运：重量不能超过30公斤，如果超过就要收费，正常人4元每公斤，外国人收6块，头等舱是其他舱的2倍

残疾人是正常人的1/2.

判定表/决策表：

1、背景：why？：输入条件很多情况（要么满足、要么不满足），不同条件组合下输出结果也很多，希望条件跟结果的一一对应的关系

它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确

2、操作步骤：

1、分析被测试对象的输入条件，同时分析各种可能的输出结果（）

2、列出所有的条件和动作（）

3、填写条件项和动作项

4、合并相似规则

3、优缺点：优点：能解决复杂条件之间逻辑组合，比较清晰列出所有的组合

缺点：一旦条件数过多，组合数会很庞大，合并存在漏测的风险（很难精确定位问题）。

对于条件，只能是有两种取值（为真、为假）

4、适用范围：条件只有两种取值的多条件组合的例子

5、与其他方法怎么样配合：与因果图

6、要点：找出业务条件规则，列出各种可能输出结果。（测试象棋马走日这个规则）当条件比较多>5 要考虑是否有中间结果（简化）

正交试验法

1、背景：弥补判定表方法可能导致用例规模非常庞大，多条件组合的数量非常巨大。

根据伽罗瓦理论，条件之间的两两组合如果不出问题，三三组合以上出问题的概率小，这样

一来，可以用非常少的用例来达到比较好的测试效果。

2、操作步骤：

1、分析输入条件以及条件的取值范围。（筛选出来的条件之间没有约束关系）

2、选择合适的正交表（计算需要最小正交表的试验数，然后分两种：

1、单一水平：去挑选比需要大但是是最接近的正交表，直接套用；合并去匹配正交表-->分解

2、混合水平：）

保证试验数最少

3、根据正交表（拆分之后）设计测试数据（每一列行是一个测试项），如果是空的地方，可以根据实际需要加权处理。

3、优缺点：优点：在保证一定均匀覆盖率的前提下可以大大降低试验次数（测试项），缺点：可能有一定的遗漏

4、适应范围：配置类需求的分析，多条件多取值的业务测试。

5、与其他方法配合：等价类和边界值（输入框）

6、要点：选择合适正交表以及如何去合并和分拆！

Use Case法/场景法/流程分析法

1、背景：在实际工作中，我们很业务功能是通过工作流来实现，需要站在流程角度（用户角度），譬如购物流程

安装测试、转账流程、游戏场景

2、操作步骤：1、分析业务的基本事件流和备选事件流（正常备选事件流和异常事件流（退出））担心备选流有遗漏

2、画出事件流图（Use Case图用例图）

3、根据图设计场景

4、根据场景来设计测试数据

3、优缺点：优点：站在用户的角度来测试（），可以很好地与开发配合，直接通过用例图转化，效率比较高

4、适应范围：验收测试用例的设计，只要流程

5、与其他方法配合：等价类、边界值（选多少个备选流）

6、要点：事件流分析，尤其是备选流的分析是最关键的地方。思路比较清晰，比较广

网银转账：写出基本流和备选，并且画出事件流图。

影响软件质量的因素：

技术：1.现有的技术：人

2. 技术沉淀：技术文档，专利技术，指导书，问题库，经验库

流程：流程可以提高软件透明度，控制项目的进度，帮助项目组预防风险。

组织：组织体现的是管理

1. 让合适的人去做合适的事情

2. 流程的推动需要组织强有力的保障

软件质量管理体系

1. ISO9000

八项质量管理原则：

以顾客为中心：以用户的角度去思考问题（UAT）

下游环节为上游环节的客户

领导的作用：有激情，有谋略，演讲才能，身先士卒

全员参与：团队合作信任

基于事实的决策方法：个人能力基线（PCB）（量化管理）

持续改进（持续改善）：最初是日本的一个管理理念，从初级员工到高级管理者都需要参与

互利的供方关系：共赢，共同创造利润

过程方法：

过程：输入转化为输出的活动

过程方法：过程的识别，相互作用以及管理

管理的系统方法：全局化的管理策略

2. CMM

-- 初始级：

手工作坊式，个人英雄主义，没有相关过程，不可预测并且缺乏控制。

-- 可重复级：特点 ->可以重复以往的项目经验

证券项目（招商证券）

国信证券：

SRS

HLD

LLD

Code

test case

模板

关键过程域（KPA）（key process area）：

需求管理

配置管理

软件质量保证

--已定义级

统一标准，一致的过程（软件工程小组SEPG）

关键过程域：同行评审

--已管理级：可预测的过程

量化管理，通过数据量化，来实现预测项目

Gompertz模型

--优化级：对过程的持续改进

新技术或新思想的引入

关键过程域：缺陷分析-》预防缺陷 -》质量标准

CMM与CMMI的区别

CMM：阶段式表示

CMMI：阶段式、连续式

3. 六西格玛

六西格玛管理法原则：

注重客户

注重流程

全员参与

预防为主

事实依据的决定

持续和突破性改进

六西格玛的实施方式：

DMAIC (define, measure, analysis, improve, control)

软件质量模型：

功能性

适合性：软件产品为指定任务或用户目标提供一组合适的功能的能力

准确性：软件产品提供所需要的精确度或和结果相符的能力

互操作性：软件产品与一个或更多的其他系统进行交互的能力

保密安全性：保护信息和数据的能力，不同权限的人可以操作不同的数据

功能性的依从性：遵守与功能性相关的标准，约定或法规的能力（国际标准，国家标准，行业标准，企业内部标准）

可靠性

成熟性：软件产品为避免由于软件中的错误而导致失效的能力

容错性：由于用户操作错误，软件可以处理相应的错误，而不是死机或崩溃

易恢复性：在失效已经发生的情况下，软件产品如何快速恢复使用的能力

可靠性的依从性：软件产品遵循与可靠性相关的标准或约定或法律法规

易用性

易理解性：软件产品使用用户能理解软件是否合适以及如何能将软件用于特定任务和使用环境的能力。

易学性：软件产品使得用户能学习其功能的能力（操作手册，帮助文档）

易操作性：软件产品使用户能操作和控制它的能力

吸引性：软件产品吸引用户的能力。界面美观，易用性要好

易用性的依从性：软件产品的易用性遵循相关的标准或法律法规

效率

时间特性：在规定的条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐率的能力。也就是完成用户的某个功能需要的时间

资源利用率：在规定的条件下，软件产品执行其功能时，使用合适的资源数量（CPU，内存占用）

效率依从性：软件产品遵守与效率相关的法规

维护性

易分析性：软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。（日志记录）

易改变性：修改缺陷的能力，实现功能的能力。（代码要高内聚，低耦合）目的在于降低修改软件的成本

稳定性：软件产品避免由于软件修改而造成意外结果的能力

易测试性：软件产品的问题能被确认的能力。定位问题的能力

维护性的依从性：软件产品的维护性遵循相关的标准

可移植性：

适应性：软件产品适应不同的环境的能力

易安装性：被安装的能力（一键安装）

共存性：和其他软件共同安装或存在的能力

易替换性：升级时替换文件的能力

可移植性的依从性：软件产品的可移植性遵循相关的标准

软件质量活动：

软件质量保证（ＳＱＡ）：从流程方面保证软件质量

　测试：从技术方面保证软件质量

度量：

作用：理解，预测，评估和改进

度量的分类：四个基本度量项：规模工作量进度缺陷

BUG属性：

发现人 reporter

发现时间 date

缺陷状态 status (new, open, resolved, reopened, closed) （fixed, duplicated, Invalid, won"t fix, postpone）

缺陷版本 version

缺陷所属的产品/项目/模块 product, project, feature

缺陷编号 no

缺陷严重程度serverity

缺陷优先级 priority

标题 title

详细描述 description

系统环境 OS (服务器环境和客户端环境)

测试环境（用户名/密码）test environment

重现率 repository

预置条件pre condition

步骤 steps

实际结果 actual result

期望结果 expected result

其他信息 additional information

用例编号testcase no

*附件 attachment

==================

缺陷引发的原因 root cause

缺陷解决方案 resolution (改代码，数据库，环境问题)

代码改动范围

影响范围

==================

验证人

验证环境

验证范围

结果

软件测试周报总结篇3

报告总结参考范本

软件测试个人总结

撰写人：__________________

部 门：__________________

时 间：__________________

软件质量越来越受到人们的关注，软件测试作为新兴行业有很多不完善的地方。很多从事软件测试工作的同行处于迷茫之中，如何提高，如何解决测试工作中的实际问题，困惑着每一个人。本文总结了一下个人经验，希望对大家有帮助。

我最初参加测试工作的时候，不知道什么是软件测试，集成测试和系统测试的概念经常混淆， cmm 是什么就更加不知道了。那时候最简单的开关机也是通过直接拔插电源完成，安装系统对我来说简直是有史以来人类的技能，对于那些拿着螺丝刀安装机器的人就认为是宇内超级高手，身具杀人于无形之绝世秘技。拿破仑说不想当将军的士兵不是好士兵，我最初的梦想就是想成为软件测试的高手，傲视天下。所以不断偷师，总结经验，自认为掌握了成为高手的几个秘技，这几年混迹 “ 江湖 “ 还算无往而不利。不敢独享，望与吾辈测试人员切磋，早日总结成功密技之大成，助新进人员早日入门，也算不愧对东北活雷锋的称号。

第一招 学会利用网络

刚参加工作面对浩瀚的网络世界，当时如刘姥姥进大观园，什么都新奇，什么都想要，从网上下载很多源程序的代码，软件技术文档之类，恨不得把所有的好东西收集到手中，其实有些在他人看起来就是垃圾一堆。当时觉得有了这些 “ 武林秘籍 “ ，成为高手指日可待。最初参加工作由于自己工作努力有幸转为开发，加入项目组后我的习惯还是没有改，反而变本加厉，手中的资源更加多，上网的时间更加频繁。

一次项目经理分配任务，觉得依靠手中的秘籍加上自己的 “ 聪明才智 “ 很快会完成，不料短短的时间，所有的一切变成了马奇诺防线。解决问题很慢，思路不清晰，项目经理在对我施压的过程中教会了我终身难忘的一招，学会利用网络寻找要解决问题的答案，从此 google 成了我的最爱，关键字成了我变化的招数。在软件测试工作中，他帮我解决了很多疑难问题，解答了很多令我迷惑的地方。也是我帮助测试同行解决问题手段之一，很多软件测试新手，甚至老手都没有意识到自己手上就握有 “ 无敌秘籍 “ ，所以只要你耐心找，答案就在身边。