软件测试工作流程总结

Q：什么是软件测试？

答：特定的环境、特定的条件下运行软件，验证其能正常运行，并发现其缺陷，对软件的质量进行评估的过程。

Q：软件测试的工作过程有哪几步？
答：需求、计划、方案、用例、执行、总结。

1、测试需求

测试需求分析：分析识别测试范围，解决测什么的问题，方便测试的跟踪和管理。
测试需求分析的流程：需求采集—>需求分析—>需求评审。
测试需求分析的评审：完整性、准确性、一致性、易理解性、无歧义性。
测试需求分析的时间：开发需求完成后。

参考依据：
（1）狭义依据：需求规格；
（2）广义依据：参照上面的测试需求分析来源。

Q：在测试需求不明确的情况下，如何保证测试质量？
（1）多方收集需求；
（2）多与开发人员沟通；
（3）若有以前的系统，参照以前的系统；
（4）找类似的产品熟悉；
（5）到网上查找与系统相关的业务知识、专业术语。

测试需求分析的来源：
（1）开发文档：需求规格、概设、详设、数据库结构设计文档、模块功能图等；
（2）用户需求：与用户或需求分析人员沟通，需求调研的会议纪要，与用户邮件往来；
（3）软件雏形：可运行软件，软件的框架；
（4）相关的规划及标准：各行各业的标准、国家标准、行业标准、企业标准、项目标准、国家法律法规；
（5）类似的产品：公司内部相同的旧版本产品，行业其他公司类似的产品；
（6）测试知识经验库：测试人员的业务背景、系统业务知识的积累、个人的测试经验积累；
（7）其他隐性的需求：产品利益相关者的建议、会议纪要、备忘录、沟通记录、邮件往来等。

测试需求分析的内容：
（1）业务流程图的分析；
（2）用户和角色的分析；
（3）数据库结构的分析；
（4）测试要点的分析。

测试需求分析的方法：
（1）测试功能点分析法；
（2）功能交互分析法；
（3）质量特性分析法；

（4）测试类型分析法。

2、测试计划

测试计划：管理层文档，对测试过程、测试活动起到指导的作用，解决做什么的问题，5W。

测试计划编写时间：测试需求完成之后。

评审人：项目经理、QA、开发、产品、设计人员。

输出文档：总的测试计划文档。

测试计划的内容：
（1）项目背景，缩略语（专业术语）；
（2）测试的参考文档、测试的交付文档；
（3）测试目标、测试范围、测试环境、测试工具、测试策略、测试风险；
（4）人力资源的分配、工作量的估算；
（5）测试时间、进度安排、任务分配、培训计划等；
（6）出入口准则（准入准出标准）等。

测试风险：质量、时间进度、成本、变更、人员变动等；

QA与QC的区别：QA为质量保证、QC为质量控制。

冒烟测试：在测试之前，对软件进行可测性检查，保证基本功能，基本流程可通，提高工作效率。
回归测试：包括完全回归和部分回归（根据操作频率和风险选择）。

项目	项目时间周期	测试用例数量
小	3个月-10个月	500-1000个
中	10个月-1.5年	1000-2000个
大	1.5年以上	2000个以上

测试阶段	占用时间比例
测试需求阶段	10%-20%
测试计划	小项目2-3天，大项目5天左右
测试方案	小项目1周，大项目2周
测试用例	测试总时间的30%
测试执行	测试总时间的40%
测试报告	小项目2-3天，大项目5天

集成策略： 

（1）非增量式集成：大爆炸式集成；

（2）增量式集成：自顶向下、自底向上、三明治。

测试准入条件：

（1）测试用例编写，测试评审完成；

（2）开发人员完成编码，并完成自测；

（3）冒烟测试通过；

（4）开发组提交了测试申请单；

测试准出条件：

（1）时间标准：项目时间用尽；

（2）缺陷修复：致命/严重缺陷比率为0%，一般<5%，轻微<10%;

（3）测试用例执行覆盖率为100%；

（4）测试用例对需求覆盖率>95%;

（5）缺陷修复率达到一定的标准；

（6）收益比：存在bug，但是修复需要花费的时间大于受益，测试停止；

（7）完成软件测试验收报告，并且报告结果达到认可。

3、测试方案

测试方案：技术层面文档，主要对被测软件测试特性、方法、环境等进行规范，解决怎么做的问题。

测试方案的编写时间：测试计划完成之后。

参考依据：测试计划、测试需求分析、测试规格、概设、详设。

评审人员：测试人员、开发人员、项目经理、QA。

测试内容：

（1）项目背景、测试目标、测试范围、测试环境、测试策略、测试工具；

（2）测试特性的分析；

（3）测试特性方法的分析；

以最少的用例更全面的覆盖需求，测试不能发现潜在的缺陷；

缺陷的级别：致命、严重、一般（不超过15%）、轻微（不超过20%）、建议。

缺陷处理状态迁移图：新建—打开—已修正—已关闭—拒绝—延迟—重新打开。

缺陷优先级的考虑方面：

（1）缺陷本身的严重级别；

（2）功能的重要性方面；

（3）功能发布的时间进度；

（4）功能的可见性方面；

（5）从操作频率方面；

（6）从安全性方面。

4、测试用例

参考依据：参考方案、需求分析的结果、需求规格。

评审人：测试工程师、QA、开发人员、测试经理。

输出文档：测试用例文档。

Q：用例设计需考虑的方面有哪些（以最少的用例更全面的覆盖需求，以此发现更多的缺陷）？

（1）编写所有必填项（一个用例）；

（2）编写所有项包括必填和非必填（一个用例）；

（3）一个完整的流程一次性走完（一个用例）；

（4）编写预期结果：包括前台、后台、数据库等方面；

（5）新增和修改的链接为同一界面（代码一致为前提）：在修改中只需测试进入界面的默认情况，其余字段只需在新增上测试，修改所有字段点击保存、重置，修改后直接返回需要提示；

（6）删除：子信息有调用情况（全删、不能删除），例：品牌和商品，删除品牌时则提示，物理删除：可到数据库中回滚，数据库不存在；标志删除：到回收站用来做历史记录，后台可看，前台不可；

（7）登陆：账号长度限制，正确登陆，不正确登陆；

（8）业务流程图：场景法、基本流和备选流，串行用乘，并行用加；例：银行取款流程图；

（9）查询：精确查询和模糊查询，like“%x%”；多条件搜索可用正交法、再补充。

测试用例过程：

（1）输入—动作—输出；

（2）输入—测试环境—测试目的—执行条件—动作—输出；

（3）为了达到某种特定目标而设计的一组测试输入、执行条件和预期结果，其目的是为了检测某个程序或何时是否满足某个特定的需求。

测试用例的作用：便于软件质量的度量，方便测试任务的跟踪管理，方便缺陷的提交。

如何衡量测试用例的好坏：清晰、准确、完整、简洁、一致。

黑盒测试用例设计方法：包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。

白盒测试用例设计方法：语句覆盖率、条件覆盖率、判定覆盖率、条件判定覆盖率、组合覆盖率、路径覆盖率。

关于因果图法：

（1）因果图关系：（输入与输出）恒等、非~、与^、或V；

（2）输入约束：异E最多只能一个为1、或I最少有一个为1、唯一O有且只有一个唯一；要求R两个取值一样如C1为1C2也为1；

（3）输出约束：强制M两个输出互异。

#对于搜索框的测试用例设计#

（1）单个条件；

（2）所有条件；

（3）任意几个条件组合：应用正交实验法再补充情况；

（4）不符合条件查询；

（5）条件中有相互冲突的条件，需单独测试；

（6）输入合理的查询条件后，点击返回需有提示。

5、测试执行

参考依据：测试用例（需求）。

输出：缺陷报告。

测试执行注意事项：

（1）注意用例执行的先后顺序：数据流向、优先级、时间进度安排；

（2）执行的前置条件、测试环境、备注里的特殊说明；

（3）发现问题/缺陷时，应立即保留证据，再重现缺陷；

（4）缺陷至少重现3次，并初步定位到问题；

（5）测试过程中，根据实际情况维护测试用例。

测试用例的执行结果：

（1）未测试：Not test；

（2）通过：pass；

（3）失败：failed；

（4）阻塞：black；因为其它的问题导致用例无法执行；

（5）观察：investigates。

Q：什么时候需要维护测试用例？

（1）需求、编码、设计发生了变更；

（2）执行过程中发现用例描述有错误；

（3）发现的缺陷不能对应用例，需补充用例；

（4）发现重复、冗余的用例需删除；

Q：什么是缺陷（遗漏、错误、额外实现）？

（1）需求规格说明书中明确要求实现的未实现；

（2）需求规格说明书中虽未明确规定，但实际需要实现的缺陷；

（3）未正确实现（错误实现）；

（4）实现了需求规格中明确不需要的功能（额外实现）或实际不需要的功能；

（5）性能、易用性等方面，站在用户的角度，会认为不够完美的。

bug的内容：bug描述、重现步骤、实际结果、预期结果。

缺陷的生命周期：

提交->确认->分配->修复->验证->关闭

缺陷的内容：

        缺陷编号、模块、项目名、版本、缺陷标题、缺陷级别、优先级、缺陷类型、测试环境、缺陷描述（bug描述、重现步骤、实际结果、预期结果、修改建议）、状态、缺陷引入原因、缺陷引入条件、发现人、发现时间、修改人、修改时间、关闭人、关闭时间、附件、对应的用例编号。

Q：对于偶然发现，并难以重现的缺陷如何处理？

（1）先保留证据（抓包、截图、视频等）；

（2）本机重现问题，无法重现则换电脑重现；

（3）若重现，则根据缺陷的实际影响情况定义缺陷的严重级别；若无法重现，则找开发人员协助重现；在开发人员的协助下仍未能重现，则需要对此问题边重现边录视频（最多两小时），若2小时内重现则从发现问题的前半小时开始分析，若2小时内未重现，则需直接提交缺陷，降低缺陷的级别，将缺陷改成延迟状态，该缺陷至少历经半年或者在用户现场历经多个版本后关闭。

6、测试报告

定义：对于测试过程、产品质量进行评估，并对测试结果进行总结、下结论。

依据：测试用例的执行情况，缺陷数据的统计结果。

评审人：整个项目人员。

测试报告评估人：测试经理、测试人员。

测试报告的内容：

        项目背景、测试目标、测试范围、测试环境、测试策略、测试工具、测试人力资源、测试时间、测试用例数据统计、缺陷数据统计、遗留问题、测试风险、测试过程开发、产品质量评估、测试结论、经验教训与建议、附录。

Q：编写测试报告的目的是什么？

（1）用于项目经理决策提供依据；

（2）用于下一个项目维护提供方便；

（3）对测试进行评估。