精华内容
下载资源
问答
  • 大话软件测试

    千次阅读 2014-10-17 09:31:13
    大话软件测试(不扭曲,不变形,不晦涩,不忽悠,明晰软件测试,从哪里来,到哪里去。大鸟和小白为您洞见软件架构底层,诠释软件测试的设计哲学。) 欧立奇 何金池 等 编著  ISBN 978-7-121-24097-3 2014年9月...

    大话软件测试(不扭曲,不变形,不晦涩,不忽悠,明晰软件测试,从哪里来,到哪里去。大鸟和小白为您洞见软件架构底层,诠释软件测试的设计哲学。

    欧立奇 何金池 等 编著  

    ISBN 978-7-121-24097-3

    2014年9月出版

    定价:45.00元

    280页

    16开

    编辑推荐

    本书用完整严密的知识体系和诙谐幽默的语言,为您在软件测试的道路上打好坚实的基础;培养读者敏锐的洞察力以及优秀的测试素养,提高自身功力,从容面对软件开发/测试。

    内容提要

    《大话软件测试》通过小白与大鸟的趣味情景对话形式,用多个小故事、案例、漫画来组织讲解软件测试的方方面面,包括测试需求、测试分类、测试计划以及测试管理等。

    《大话软件测试》表现形式虽为“大话”,但内容结构实为严谨。在讲解软件测试的过程中,通过问询式结构,把学习门槛降低,让读者可以更加容易地理解测试的目的、策略、方法以及管理,澄清有关软件测试的常见误解,用一种不扭曲、不变形、不晦涩、不忽悠的表达方式表现测试的真谛,以达到不但授之以“鱼”,还授之以“渔”的目的,引导读者体会软件测试过程中蕴藏的大智慧。

    《大话软件测试》适合软件测试、软件开发和软件管理人员以及其他计算机爱好者阅读。

    目录

    第1部分  软件需求与设计          1

    第1章  软件需求          2

    1.1  从需求的含混性说到软件测试的目的        2

    1.2  需求的定义与分类        5

    第2章  PRD审核 8

    2.1  PRD分类        8

    2.2  软件产品定位        9

    2.3  软件产品需求        14

    2.4  审核软件产品需求        17

    2.5  范围约束        26

    第3章  用户故事          29

    3.1  什么用户故事        29

    3.2  用户故事特点        30

    3.3  用户故事分解、细化、合并        32

    第4章  审核FS     35

    4.1  实现的含混性        35

    4.2  交付目标        36

    4.3  范围约束        37

    4.4  假设和依赖   37

    4.5  功能描述        38

    4.6  审核功能描述        38

    4.7  非功能描述   41

    第2部分  软件功能性测试          43

    第5章  功能性测试的准确性和合适性     44

    5.1  功能性测试概念   44

    5.2  功能性测试分类   45

    5.3  适合性测试   45

    5.4  准确性测试   46

    第6章  软件功能性测试用户故事     47

    6.1  软件功能性测试故事表        47

    6.2  执行者/行为/状态/预期结果/检查点 48

    第7章  软件互操作性测试          72

    7.1  互操作性测试定义        72

    7.2  兼容性和互操作性的区别   73

    7.3  不可互操作的原因        74

    7.4  互操作性测试分类        75

    第8章  安全性测试     81

    8.1  软件安全性测试概念   81

    8.2  软件安全性测试策略   82

    8.3  用户认证安全        84

    8.4  系统网络安全性测试   89

    8.5  数据库安全性测试        94

    第9章  全球化测试     99

    9.1  全球化测试分类   99

    9.2  日期        101

    9.3  字符格式        103

    9.4  数字格式        104

    9.5  输入法编辑器测试        106

    9.6  语言敏感信息测试        107

    第3部分  软件非功能性测试     109

    第10章  易用性测试   110

    10.1  易用性测试分类 110

    10.2  易理解性测试      111

    10.3  易学习性测试      113

    10.4  易操作性测试      114

    10.5  UI测试          121

    第11章  可靠性测试   126

    11.1  容错性测试 126

    11.2  可恢复性测试      127

    11.3  故障转移测试      130

    第12章  可移植性测试       131

    12.1  可移植性测试定义与分类 131

    12.2  用户故事列表      131

    12.3  行为/状态/预期结果/检查点     133

    第13章  性能测试       143

    13.1  功能与性能的区别      143

    13.2  性能测试指标      144

    13.3  获取性能需求      148

    13.4  性能测试分类      149

    13.5  如何进行性能测试      151

    13.6  分析性能瓶颈      152

    第14章  文档测试       156

    14.1  文档测试重要性 156

    14.2  文档种类      156

    14.3  文档测试检查点 157

    第4部分  软件项目流程与风险          159

    第15章  软件项目开发流程       160

    15.1  Project Milestone定义         160

    15.2  软件项目的主要阶段 161

    15.3  研发周期制定      170

    15.4  工作量估计 171

    第16章  项目风险分析       177

    16.1  风险、问题、缺陷的区别 177

    16.2  风险分类      177

    16.3  风险分析      183

    16.4  风险缓解      184

    16.5  常见的风险处理措施 186

    第5部分  测试策略与测试计划          190

    第17章  测试策略       191

    17.1  测试策略的定义和分类      191

    17.2  测试重点/测试优先级分析         192

    17.3  各时间阶段对应的测试策略      193

    17.4  多平台/操作系统/浏览器的测试策略       198

    17.5  测试开始和结束的标准      198

    17.6  测试环境策略      201

    17.7  测试人员指定策略/任务分配策略    203

    17.8  测试工具的使用策略 205

    17.9  测试报告/进度策略    205

    第18章  测试计划       206

    18.1  测试计划的定义 206

    18.2  测试计划的范围 207

    18.3  测试用例设计方法      207

    18.4  测试用例优先级划分 217

    第6部分  软件测试管理     219

    第19章  如何预防Bug        220

    19.1  Bug和Defect的区别 220

    19.2  预防Bug的意义 221

    19.3  干净的代码 222

    19.4  代码可复用 224

    19.5  代码审核管理机制      227

    19.6  做好单元测试      227

    19.7  代码重构      228

    第20章  如何Log高质量的Bug         232

    20.1  Bug报告写给谁看       232

    20.2  Bug模板介绍       232

    20.3  常见的Bug问题 246

    20.4  如何分析Root Cause  247

    20.5  Bug生命周期       251

    20.6  测试报告分析      253

    第21章  其他QA日常工作         255

    21.1  日报      255

    21.2  如何开会      258

    后记  QA的自我修养   261

    第1课  QA到底是做什么的?   261

    第2课  质疑和思考     262

    第3课  QA要具备的技能   264

    第4课  QA和DEV的关系  265

    第5课  QA的主要贡献        266

    第6课  自动化测试和常规测试的关系     267

    作者简介

    欧立奇:IBM高级测试工程师

    前言

    本书通篇都是以情景对话的形式,用多个小故事或案例、漫画来组织讲解软件测试。从软件需求设计说起,在对软件测试做了妥善分类后,将本书的内容分为如下几大方面。

    在测试需求方面:如何测试需求,如何审核需求,如何设计文档。

    在测试分类方面:详解软件质量模型的6大特性27个子特性的各个检查点,并提供经验和案例,从而使读者能够容易地运用到实际项目环境中;让读者能够清楚地得知,软件测试究竟是测什么?

    在测试计划方面:如何写用户故事、测试用例、测试计划,如何进行测试建模,如何制定人力资源的分配计划。

    在测试管理方面:如何预知风险,如何写日报,如何与DEV(研发)、PM(项目经理)进行交流,如何进行测试项目的管理,如何利用自动化技术来提高测试的效率等。

    本书表现形式虽为“大话”,但内容结构实为严谨。在讲解软件测试的过程中,通过问询式结构,把学习门槛降低,让读者可以更加容易地理解测试的目的、策略、方法以及管理,澄清有关软件测试的常见误解,用一种不扭曲、不变形、不晦涩、不忽悠的表达方式表现测试的真谛,以达到不但授之以“鱼”,还授之以“渔”的目的,引导读者体会软件测试过程中蕴藏的大智慧。

    本书不同于其他软件测试书籍的主要特点如下。

    软件测试由于工作的特殊性,软件测试人员更要具有认真、耐心、细致、敏感等个性元素,涉及的方面比较多,且比较基础,也比较细。以软件安装为例,一个完整的软件安装检查点就包括:1.安装环境检查;2.中断安装的情况;3.回溯的检查;4.可定制化安装;5.安装特定参数/端口依赖;6.安装路径;7.安装介质;8.安装语言;9.安装Shell;10.安装组件;11.操作系统兼容性;12.操作系统语言包;13.硬件系统兼容性;14.逻辑安装次序;15.安装安全性;16.安装接口;17.安装结果检查,等等。

    所以本书把这些细小的知识点和检查点做了汇总,让读者有章可循,按图索骥就可以轻松测试。本书使用了四级标题,每一条都是一个实际的案例,切切实实地解决读者遇到的实际问题。

    说到测试,人们首先想到的是:测试是一种技术。然而事实上,测试是一种哲学,一种思想,思想的背后是一个人的眼界和世界观。一个测试也许能从多方面揭示测试者的素质和看待问题、思考问题的能力。市面上流行的测试书籍在此专业性的分类方面做得不够,正因为如此,本书追求的是循循善诱,讲深讲透,侧重于软件测试技术的本质理解,而不仅限于对测试的单纯讲解。

    广

    市面上流行的软件测试书籍仅对软件功能性测试本身比较侧重,而忽略软件测试外延的东西:比如非功能性测试中的易用性测试、性能测试、文档测试。而随着用户对易用性、可靠性要求的与日俱增,本书对以上诸多方面都给出了详细分析,并结合大量案例制定出测试方案,以满足读者需求。

    苦逼的团队做不出有爱的产品,愉悦编程、快乐测试才能使你的职场之路长久。所以,本书语言幽默诙谐,并夹杂了一些漫画来摆事实、讲道理,力求为众多严谨的软件测试书籍添加一抹亮色。

     

    本书不是一本万能书籍,但肯定是您软件测试/开发/管理工作的好助手、好伙伴。

    本书主要由欧立奇、何金池编著,其他参与编写的人员有刘洋、秦晓东、李启高、马雪、马煜、胥虎军、李富星、牛永洁等。

    最后,感谢本书编写过程中的几位重要人士的支持,衷心感谢明总、峰总、大胖、小四的鼎力协助。

     

    展开全文
  • 本文为《大话软件测试》的读书笔记,仅作为本人梳理知识所用,并且只对本人认为的重点进行记录。 本书是以问答的形式来进行软件测试的基础知识普及的,因此感觉相对于之前看的基本纯理论的书来说,更加轻松,但是...

    本文为《大话软件测试》的读书笔记,仅作为本人梳理知识所用,并且只对本人认为的重点进行记录。
    本书是以问答的形式来进行软件测试的基础知识普及的,因此感觉相对于之前看的基本纯理论的书来说,更加轻松,但是其中的内容也有一定深度,对于面试可能有一定作用。

    文章目录

    第一章,软件需求

    关键点
    需求不应只由产品经理关注,每一个开发和测试都应该接触。

    测试的根本目的是验证需求,围绕需求保证软件质量,BUG(缺陷)是这个过程中的一个产物,不应以找BUG为目标。

    1.1需求的含混性

    一定要根据客户的具体描述来定义需求;
    不能只根据客户的描述来定义需求,只有让他们见到实物才能知道真正的需求是什么。
    找到客户的关注点。

    1.2用户需求

    在业务需求(市场人员主导)的基础上进行用户访谈、调查、整理,从用户角度体现业务价值。
    最终将概念化的需求转化为可实现的具体细则,输出PRD产品需求文档(功能要求、开发要求、兼容性要求、性能要求、扩展要求、产品文档要求、外观要求、发布要求、技术支持和培训要求等)注重特性的重点描述。

    第二章,PRD审核

    PRD是测试执行的源头,需要对每一个标点都需要整个开发团队包括测试进行认真的审核。

    2.1PRD分类

    2.1.1软件产品定位

    a产品背景/定位;潜在客户群;用户问题;特点/特性;产品结构图。

    b功能性需求;非功能性需求。

    c用户期盼超出能力;非技术因素决定技术选型;预期的使用环境。

    2.2软件产品定位a

    2.2.1产品背景

    背景分析:市场状况、用途、未来增长趋势、竞争能力、需求规模、发展前景。

    2.2.2目标潜在客户群

    具有购买能力和购买需求。
    潜在客户-价值客户-忠实客户

    2.2.3用户问题

    从问题(单纯的问题)总结需求。
    根据客户规模制定需求列表。

    2.2.4特性

    创新点?优越性?独特价值?相关领域影响?市场同类型的区别?

    2.3产品需求

    功能性、非功能性、文档、项目需求优先级。

    2.3.1功能性需求

    特性、安全性、交互性。

    2.3.2非功能性需求

    性能、易用性、可靠性(故障频率和可恢复性)、可支持性、可移植性。

    2.3.3文档需求

    用户手册教程等

    2.3.4项目优先级

    P1强制完成,影响发布
    P2对发布很重要
    P3重要,但不是一定要

    2.4审核PRD

    完整性、正确性、一致性。

    2.4.1完整性

    演绎法、比较法、分解法(主谓宾)、标签法。

    2.4.2正确性

    明确用户动机(不是WHAT而是WHY);
    表达方式正确。

    2.4.3一致性

    需求之间不相互矛盾。

    2.5范围约束

    用户的期盼超出能力;
    非技术因素决定技术选型;
    预期使用环境限制。
    (不要被PM和DEV忽悠)

    第三章,用户故事

    画面式场景模拟用户行为(用户写或者PM整理,不能涉及专业术语)
    用户角色;
    某项功能(具体操作);
    客户实现目标/价值。

    第四章,审核FS(功能规格书)

    4.1含混性

    含混性=实现需求最大花费/最小花费,不能过大

    4.2交付目标

    版本是否清晰

    4.4假设和依赖

    不能有过多假设和依赖(操作系统、环境、集成包)

    4.5功能描述

    相对于PRD中更加具体,如安装路径、端口、网段、输入输出等具体步骤。

    4.6审核功能描述

    需求或特性描述是否准确;
    可扩展性;
    技术合理性;
    集成和升级风险;
    理解一致性(主要在数据库、接口、API方面);
    设计一致性

    第五章,功能性测试准确性和合适性

    5.1功能测试隐含需求

    1、隐含需求(行业规则等,如缺少沟通则极易出错)
    2、计算机领域规范
    3、由于不了解相关技术导致指标错误。

    第六章,软件功能测试用户故事

    执行者、行为、目标+状态(属性)、方式(接口)、验证点。

    6.2数据输入

    是否添加中断保存机制
    特殊字符(全半角、简繁体、html、JS函数、日文)
    带空格字段
    数字型边界:输入某些特殊字符和负数时不能崩溃
    前后一样的字段数值一致
    删除不存在的数据
    拷贝数据时不应该全都一样,内嵌属性不应一样

    数据库锁机制!

    https://blog.csdn.net/C_J33/article/details/79487941

    6.2.10一份好的日志

    保存成独立的文件;
    必须是可以被并行执行的;
    起码三级级别;
    接口要灵活;
    格式统一(最少有时间戳;等级;文件/函数/进程ID/主机名;信息内容)

    第七章,软件互操作性测试

    即不同软件系统之间接收、处理并共享发送信息的能力。

    7.1兼容性和互操作性区别

    兼容性除了考虑软件之间、软硬之间的配合程度外,还要考虑自身前后版本之间的适应性,重点在于自己软件本身!

    互操作性则将两者都作为重点,不能相互影响。

    7.2互操作性影响因素

    服务;
    两者之间协议;
    资源;
    用户配置;
    接口;
    自身协议。

    第八章,安全性测试

    关注软件的风险阈值。
    最易被利用之处:缓冲区溢出

    8.3安全测试重点

    安全测试水很深,即使不是要以此为专业的话,也要关注以下几方面:

    8.3.1用户权限:

    同组人员的权限;
    可扩展性;
    功能权限和资源权限。
    权限是否过大;
    避免用户冲突;
    避免收回权限时出现错误;
    超时;
    操作记录日志。

    8.3,2密码验证机制

    所有输入验证(边界、长度、特殊、黏贴等);
    密码比较验证;
    输入次数;
    密码形式;

    8.3.3网络安全测试

    缓冲区溢出;
    加密测试;
    SQL注入。

    加密部分不额外介绍了。

    第十章,易用性测试

    易理解性(清晰性+一致性);
    易学习性(直观性+可记忆性);
    易操作性(用户可控性+灵活性+可扩展性+避免错误);
    用户界面。

    第十一章,可靠性测试

    成熟性;
    容错性;
    可恢复性:硬件及有关设备;软件系统故障;数据故障;通信故障;

    第十二章,可移植性测试

    指软件从一种环境迁移到另一种环境的能力,包括:
    适应性;
    易安装性;
    替换性。
    Update是更新,更新完版本不变;Upgrade是升级,即版本升级。

    12.2用户故事列表

    五大要素:执行者;行为;属性(目标+状态);方式(接口);检查点。

    12.3 行为状态等预期结果

    安装、卸载、重装、Update、Upgrade及其中中断。

    12.3.1安装测试

    1、安装环境检查
    2、中断安装
    3、回溯检查
    4、可定制化安装
    5、安装特定参数/端口依赖
    6、路径
    7、介质
    8、语言
    9、Shell
    10、组件
    11、操作系统兼容性、语言包
    12、硬件系统兼容性
    13、逻辑安装次序
    14、安全性
    15、接口

    第十三章,性能测试

    通过特定方式对被测系统按照一定策略逐步施加压力,获取系统的响应时间、资源利用率和吞吐量等关键性能指标。

    13.2性能测试指标

    响应时间;并发用户数;吞吐量和资源利用率

    13.2.1响应时间

    包括客户端呈现时间、网络传输时间和服务器响应时间。

    13.2.2 并发用户数

    分为完全相同且同时的请求和不同但同时的请求。

    13.2.4资源利用率

    服务器端和网络传输。

    13.4性能测试分类

    性能参数测试(一步到位,测试不同负载下响应时间等性能)
    负载测试(逐渐)
    压力测试(极限或超极限)

    13.6分析

    得到数据后,通过工具转化为图表,获取性能瓶颈。

    第十四章,文档测试

    文档完整性、正确性、易用性

    第十五章,软件项目开发流程

    15.2软件开发主要阶段

    15.2.1信息采集和立项

    采集主体是市场人员,立项主体为PM
    输出MRD市场需求书
    包括:
    1、原始需求及背景
    2、业界水平和标准
    3、市场价值预估
    4、竞争对手
    5、潜在目标客户描述
    6、期望研发团队完成优先级和时间点
    7、其他问题(战略等)
    开会,作为第一个MILESTONE

    15.2.2需求分析

    对于上者需求分析的一个扩展。
    需求分析过程和MRD一般不对研发和外界公开,转化为具体需求(指标化技术化)后再交给研发。
    PRD体现产品的所有要求(功能、开发、兼容性、性能、扩展、产品文档、外观、发布、支持和培训)

    15.2.3项目架构与设计

    主体为架构师和RM(在我们这边是SE系统工程师),DEV和QA一起参与。
    输出FRD功能需求文档(如果项目不大则PRD就行了)继续转义PRD中指标,确定所有接口细节。

    15.2.4开发

    不同模块开发输出各模块功能规格书FS,体现所有方案功能接口等,经审核以后开发,完成单元测试UT。

    15.2.5系统测试

    1、前置检查:包、安装测试、UT检查。
    2、冒烟,也叫acceptance测试检测基础功能
    3、功能测试feature,全面的测试用例(正向负向易用性边界值等)
    4、回归测试regression,最好自动化
    5、完整性测试sanity,最后一道防线,最后进行一个整体测试(正向)
    6、inspection流程检查

    15.2.6发布

    PM检查后交付客户。
    QA检查完整性。

    15.2.7软件运行和维护

    修复用户反馈BUG

    15.3研发周期

    根据客户、PM的PRD、研发水平和不可抗因素确定时间。

    15.4估计工作量

    这环节非常重要,和实际最好控制在10%以内
    由PL,测试负责人和研发负责人或更多人一起估计。

    一般功能测试=前段时间/3或后端/2
    回归=系统测试/3
    测试计划一般2-3天(大项目)
    冒烟1天等
    建立QA计划表

    第十六章,项目风险分析

    16.2常见风险分类

    16.2.1需求风险

    早期需求制定时的风险,包括:

    1、主要需求突然变更
    2、需求定义模糊
    3、产品定义模糊
    4、客户参与度不够导致额外需求
    5、缺少有效的需求变化管理过程
    6、客户的决策周期过长
    7、客户答复时间

    16.2.2技术风险

    软件设计风险和实现风险

    16.2.3设计阶段风险

    1、可扩展性弱、设计文档不健全。
    2、源码书写规范、选择技术新旧、接口意外错误
    3、软件质量低,BUG过多导致测试时间延长
    4、兼容等需求扩展
    5、交付前修改部分功能
    6、版本控制风险

    16.3管理风险

    1、计划/流程风险;
    2、人员管理风险;
    3、环境/资源风险。

    16.5风险处理策略

    1、合同风险:
    PL提前全面准确得了解合同
    2、需求变更:
    一开始就进行书面约定
    3、沟通不良:
    一开始就建立良好的沟通渠道
    4、缺乏领导支持:
    主动沟通、汇报进展
    5、进度风险:
    分阶段交付,增加监控力度
    6、质量风险:
    经常和用户交流、认真审核、流程完整
    7、系统性能风险:
    提前设计架构并性能测试
    8、工具风险:
    提前落实工具来源
    9、技术风险:
    提前选好实用技术并培训
    10、成员能力风险:
    提前选人培训
    11、协作风险:
    PL提前沟通清除,公开考评制度
    12、人员流动风险:
    核心工作分派给多人
    13、系统运行环境风险:
    提前沟通确认
    14、分包商风险:
    及时审计督促

    第十七章,测试策略

    17.2 测试优先级分析

    1、先变更部分后未变更
    2、先核心功能后辅助功能
    3、先功能后可靠性易用性
    4、先常见后少见
    5、先常见压测后少见压测
    6、先影响大后影响小

    17.3不同阶段的测试策略

    17.3.1单元测试

    1、验证代码是否清晰、函数规模及接口定义
    2、边界和错误条件
    3、不做模块间集成测试
    4、代码质量

    17.3.2feature

    严格,全面

    17.3.3集成测试

    前置要求
    对一系列模块和产品非常了解,软硬件上下文环境等多方面都需要了解;
    进行总需求文档、技术架构、业务场景分析、子系统测试用例等,绘制一条端对端测试用例图;
    多和PL交流,引导用户做一些测试。
    要点:
    1、接口的数据交换
    2、子功能组合是否能完成预定功能
    3、模块间影响
    4、全局数据结构是否互相影响
    5、单个模块误差是否放大

    17.3.4回归测试

    回归测试是对某些已经进行过的测试的某些子集再重新进行一遍测试,一般在项目中后期进行。
    主要测试方法:
    多样性测试!
    利用帮助人员、自动化测试工具、特殊测试活动、启发式测试、β测试人员等非正常手段。
    1、重点识别着重修改过的部分。
    2、从测试用例库中,排除低优先级建立新的测试用例库。
    3、人员交叉测试。
    4、根据预算决定测试数量和内容。
    5、从不同角度看(安全、易用性等)

    17.5测试结束标准

    1、基于测试阶段:单元测试、集成测试、系统测试三个阶段及其中的结束点。
    2、基于测试用例:通过百分比。
    3、基于缺陷收敛趋势:根据走向判断。
    4、基于缺陷修复率:严重100%,主要错误90%等等。
    5、基于验收测试:通过客户验收则结束。
    6、基于覆盖率原则:语句覆盖率、需求覆盖率等
    7、基于测试成本:避免为修复缺陷带来更大的缺陷。

    17.6测试环境策略

    1、计算机等配置
    2、操作系统、中间件数据库等依赖环境
    3、版本号
    4、备份
    5、网络环境
    6、文档编写及测试管理工具
    7、测试前需要的初始化工作(权限等)

    第十八章,测试计划

    根据需求等分层级列出测试重点。
    根据等价类(有效无效)、边界值、因果图和事件流的方法设计测试用例;
    再进行优先级划分并进行测试。

    第十九章,如何预防BUG

    19.1从代码入手

    1、干净的代码;
    2、简洁;
    3、有意义的命名;
    4、函数的有效组织;
    5、合理注释;
    6、代码可复用;

    19.2设计的重要性

    在需求、概念和实现之间建立关系,每一个概念最好都在视线中能够体现。
    如管理系统中公司里有雇员,就用一个employee类来表示,雇员有工资,就加一个salery方法。
    代码复用的最好情况 应该是包,创始者以包为最小单位进行发布,其他人进行复用。

    19.3代码审查

    1、可读性
    2、防止未通知的代码改动
    3、做好单元测试UT

    19.4单元测试的重要性

    单元测试可以在最早的时间发现错误,以最小的代价将其球服,因此单元测试的计划、用例和代码覆盖率是非常重要的!

    第二十章,高质量BUG报告

    高质量的报告类似论文,分为以下几个部分:
    综述、测试环境、优先级、描述正确行为、可重现性、本质原因和解决方案、附件。

    20.2模板

    20.2.1综述

    描述简洁明了、指出错误的局限性。
    如果有以下属性冲突的特性也该写入:
    可实现性、能力、兼容性、并发性、标准符合性、效率、可安装和可卸载性、可本地化、可维护性、性能、可移植性、可恢复性、可靠性、安全性、可支持性、可测试性、易用性等。

    20.2.2测试环境

    写清所有需要的配置条件等环境。

    20.2.3可扩展性

    找寻一些类似的功能尝试

    20.2.4优先级

    致命、严重、一般、微小。

    20.2.5重现

    如果是概率性无法复现,则通过仔细的分析进行整理,直到设定的某个时限,如果还不行就寻求帮助

    20.2.6附件

    截图、日志

    20.4找到root cause

    找到根源并非一定是开发的事情,从底层找寻问题是一种本领,可以加深对产品的理解,也可以拓展思维。

    20.4.1比较法

    对于出问题前后或是上次测试正常的系统进行对比,对比各种配置、步骤等。

    20.4.2假设法

    一般需要在熟悉的领域才能进行该方法。

    20.4.3分解法

    一层层分析原因。

    展开全文
  • 大话软件测试.pdf

    2021-09-14 15:41:50
    大话软件测试.pdf
  • 推荐一本个人刚入测试行业最先接触的入门书籍"大话软件测试",好不好,看了就知道! 网盘下载地址:https://pan.baidu.com/s/1UXcTD-GILWGBr_NxSQi06Q 目录第1部分 软件需求与设计第1章 软件需求第2章 PRD审核第3章 ...

    推荐一本个人刚入测试行业最先接触的入门书籍"大话软件测试",好不好,看了就知道!

    网盘下载地址:https://pan.baidu.com/s/1UXcTD-GILWGBr_NxSQi06Q

    目录
    第1部分 软件需求与设计
    第1章 软件需求
    第2章 PRD审核
    第3章 用户故事
    第4章 审核FS
    第2部分 软件功能性测试
    第5章 功能性测试的准确性和合适性
    第6章 软件功能性测试用户故事
    第7章 软件互操作性测试
    第8章 安全性测试
    第9章 全球化测试
    第3部分 软件非功能性测试
    第10章 易用性测试
    第11章 可靠性测试
    第12章 可移植性测试
    第13章 性能测试
    第14章 文档测试
    第4部分 软件项目流程与风险
    第15章 软件项目开发流程
    第16章 项目风险分析
    第5部分 测试策略与测试计划
    第17章 测试策略
    第18章 测试计划
    第6部分 软件测试管理
    第19章 如何预防Bug
    第20章 如何Log高质量的Bug
    第21章 其他QA日常工作
    后记 QA的自我修养
    第1课 QA到底是做什么的?
    第2课 质疑和思考
    第3课 QA要具备的技能
    第4课 QA和DEV的关系
    第5课 QA的主要贡献
    第6课 自动化测试和常规测试的关系

    转载于:https://www.cnblogs.com/wuxunyan/p/10256822.html

    展开全文
  • 14.我们都是年轻人,如果你在做软件测试行业,请问你是否年纪轻轻的就因为自己的不思进取而已经抢走了老大爷的饭碗。(软件测试职业生涯规划) 15.一群小伙子去森林里扔烟头,看看去什么样的地方扔多少烟头才能把...

    转载请注明出自天外归云的博客园:http://www.cnblogs.com/LanTianYou/

    题外话:大局做法与细节做法的区别——封装度高的事情做完以后可视度大,比如网站开发。封装度低的事情做完以后可视度小,比如接口开发等更底层的事情。前者更重于应用,而应用倚靠与于底层的开发所支撑。二者应解耦。底层的人更专注于开发,顶层的人更专注于应用。但现实中或多或少,他们彼此都在进行着渗透。没有电,仍然可以进行的,是编程思想。可以用编程的思想在现实生活中对现实进行编程。现实中的API就是我们自己的行为,类库就是我们的大脑。

    1.黑盒测试只能从一定程度上覆盖白盒测试中的checkpoint,而且是由表及里的测试。(界面测试的意义)

    2.一旦代码中存在一些判断逻辑分支的点测存在遗漏,就已经产生bug,所以一定要做好单元测试。(白盒测试的意义)

    3.如果任务是防治森林火灾,黑盒测试就像是找一个老大爷骑自行车去检查森林防火。(黑盒测试的意义)

    4.一定要检查各个人出没的地方有没有防火标识和警示语之类的东西。(友好性测试)

    5.过度的黑盒测试就是一群小伙子骑自行车去检查森林防火(开汽车也行就算开飞机也一样,没有太大差别,地上有个烟头根本看不到,防患于未然是假,亡羊补牢是真(客户反馈))。(很多公司不重视测试技术)

    6.所谓的soft freeze和hard freeze就像是平时和严打期,前者提倡你尽可能多的发现着火点,而后者,届时如果发现森林隐患,老大爷可能就要面临革职了(说的有点儿严重)。(软件测试阶段)

    7.过度设计与测试相当于杞人忧天,也许你这么想,一切都把客户当上帝,没想到客户当你放个屁,回头告诉你不需要,你还得删减逻辑(测试一定要遵循客户的需求,也要适当引导客户去发现隐藏的因为客户懒惰而暂时没有提出的需求,一旦这些需求后期提出,将对整个项目的进展产生很大的影响)。(需求分析)

    8.扩展测试相当于未雨绸缪,主要是测试测试周边的一些不易被人发现的东西(所谓正常checkpoint覆盖不到的点),一般来讲人所至者皆路,假如真有人跑去森林深处放把火,也是致命的。(扩展测试)

    9.自动化测试就像是在森林里安装了一个安全报警系统,随时随地进行监控,真正意义上的高效。但是有些路面理论上看起来没问题,走起来就塌陷了(汽车太重了单位面积压强太大,而地面的承受能力又不在本次防火职责范围内),一旦起火了没人过得去救火还是不行,所以还得需要小伙子开车亲自去跑一趟(又是黑盒),这时候骑自行车是不行的,因为你骑自行车可能地面就不会塌陷,如果事实证明了汽车压过地面真的会塌陷而又没有办法的时候,我们强制所有人只能骑车或步行小心通过(这就需要和客户谈判了,一般SE和PM做这件事)。(软件测试职责分工)

    10.黑盒与白盒,理论上二者缺一不可,但有很多公司根本没有白盒测试,就像很多小超市都没有安装监控摄像头一样,找个大娘坐门口一看就完了。(论黑盒与白盒的关系)

    11.好的防火员是勤劳勇敢的老大爷,辛辛苦苦一辈子没赚着钱,是共产主义的接班人。(黑盒测试)

    12.完善的防火防灾是要善于制造各种工具来将整个森林控制在鼓掌之中和眼界之内,从此需要看森林的老大爷数量就从100人变成了5个人。(自动化测试)

    13.好的防患于未然是要善于分析森林里的每一区域每一种树,各种湿度与温度的情况下,森林的火灾指数有多少(老大爷做不到)。(白盒测试)

    14.我们都是年轻人,如果你在做软件测试行业,请问你是否年纪轻轻的就因为自己的不思进取而已经抢走了老大爷的饭碗。(软件测试职业生涯规划)

    15.一群小伙子去森林里扔烟头,看看去什么样的地方扔多少烟头才能把森林点着了。(压力测试)

    转载于:https://www.cnblogs.com/LanTianYou/p/4629263.html

    展开全文
  • 2017年,对软件测试从业人员来讲找到一份好工作不容易,对企业而言找到一名符合要求的测试大牛更是难如登天。双方都有需求却匹配不上,这是为什么?面试的过程就占了很大一部分因素。本场Chat从如下几个方面切入: ...
  • 软件测试必读的经典书籍

    万次阅读 多人点赞 2019-01-15 15:20:30
    1、软件测试的艺术(原书第3版) 从第1版付梓到现在已经30余年,是软件测试领域的经典著作:第一章以一个小测试作为引子,第二章阐述全书的核心思想,后面各章就讨论了详细的方式方法。所谓详细也是相对而言,能...
  • 大话测试之BT思维

    2019-08-03 15:41:00
    前言 不废话,我们接着上篇的文章继续来大话一下测试,这次的主题主要围绕思维,而且我用了 BT 来形容,你懂得,哈哈。 1 正向思维 ...
  • 软件测试不是青春饭,时间越久,会越来越弱势,越来越不吃香,压力会很大(技术和心理都会)。以下针对作为测试员的我们,面对压力,到底该如何规划自己软件测试职场?是一直做测试到技术专家还是转做测试管理,又...
  • 不知不觉转行软件测试已经8年时间了,从一个什么都不会再到测试管理,期间有迷茫,有痛苦,有弯路,有捷径。做为测试人中的前辈,给大家分享8本软件测试书籍。不管你是0基础想转行到测试行业,还是卡在哪个阶段一直...
  • 大话测试与质量

    2018-04-09 21:44:11
    这是一次内部分享的提纲,不涉及细节,重在思想和方法的交流与分享。...}SQA重点是对软件开发过程进行监督、管理、控制TESTER重点是对开发出的产品进行检查.什么算一次成功的测试测试从什么时候...
  • 国内最大的综合性软件测试网,许多经验分享和资源都可在里面找到,新手、菜鸟必备网站。人气指数毫无疑问列为第1,但近年来可能因为上市原因,每况日下。 No.2:领测国际 www.ltesting.net 比较综合的软件测试网,...
  • 大话测试数据之一

    2019-07-02 21:30:55
    测试过程中,我们往往在测试计划阶段就忽略了测试数据,在起先没有给测试数据的设计、准备留出足够的时间,投入足够的精力,到了测试执行阶段追悔莫及。只有吃过大亏的测试人员,才会在下一个测试开始的初期就认真...
  • 软件测试--入门篇

    2018-08-11 13:33:53
    本文介绍下软件测试的基本入门知识,以使大家对软件测试行业有一个大概的了解。 主要分三部分介绍:软件测试综述、软件测试基本知识、软件测试发展。 第一部分:软件测试综述 1、基本概念--软件产品 一、软件...
  • 软件测试面试题和简历模板(面试前准备篇)

    千次阅读 多人点赞 2020-12-24 18:56:12
    面试官,你好,我叫xxx,xx年本科毕业,从事软件测试将近3年的时间。在此期间做过一些项目也积累过一些经验,能够独立地完成软件测试流程的一个工作。最近的一份工作是xx公司,主要参与app系统测试,负责xxapp,一款...
  • 大数据时代的遨游

    2017-06-26 17:54:20
      Hadoop来临 特点: 海量数据需要及时分析和处理。 ...海量数据需要深入分析和挖掘...奇虎360:Hadoop存储软件管家中软件,使用CDN技术将用户请求引到最近的Hadoop集群并进行下载 京东、百度:存储、分析日志、...
  • 大话移动测试

    2019-08-03 15:49:19
    测试界风云变幻,移动测试火爆来袭,移动测试真的像黄金价格一样吗?(黄金可是跌了啊)所有人都适合做移动测试吗?移动测试要怎么做?自动化是必经之路吗?好吧,面对如此多的疑问,小强带你浅入浅出看看移动测试。...
  • 软件测试

    2013-04-04 20:19:08
    顶顶顶顶顶顶顶顶顶顶 转载于:https://blog.51cto.com/liaoye/1171156

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 5,558
精华内容 2,223
关键字:

大话软件测试