软件测试读书笔记之一软件测试背景
一.软件缺陷的正式定义：
符合下边5个规则的才能叫做软件缺陷。
1.软件未达到产品说明书标明的功能。
2.软件出现了产品说明书指明不会出现的错误。
3.软件功能超出产品说明书指明范围。
4.软件未达到产品说明书虽未指出但应达到的目标。
5.软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
二.软件缺陷的产生原因：
导致软件缺陷最大的原因是产品说明书；第二大来源是设计方案；三是代码；
四是某些软件缺陷产生的条件被错误地认定。
三.软件缺陷的修复费用：
随时间增长，修复软件缺陷的费用是呈几何数级增长的，随时间推移，数十倍增长。
四.软件测试人员的目的：
软件测试远的目标就是发现软件缺陷，尽可能早一些，并确保其得以修复。
五.怎么成为优秀测试员：
1.探索精神
2.故障排除能手
3.不懈努力
4.创造性
5.追求完美
6.判断准确
7.老练稳重
8.说服力
9.除了这些素质，在软件编程方面受过的教育也是重要的。
10.软件的功能为了解决现实问题，因此，教学烹饪航空木工医疗等知识都
将对查找该领域软件的缺陷有莫大帮助
软件测试读书笔记之二软件开发过程
一.测试文挡包括：
1.测试计划
2.测试案例
3.软件缺陷报告
4.归纳，统计和总结。
二.软件产品由哪些部分组成（都是要测的哦，当然我国许多软件都无法
达到这么多部分~呵呵）
1. 最终产品（光盘/软盘/程序...）
2.帮助文件
3.用户手册
4.样本和示例
5.标签和帖子
6.产品支持信息
7.图标和标志
8.错误信息
9.广告和宣传材料
10.安装
11.说明文件
这些都是要测试的，书中尤其提到了不要忘了测试错误提示信息（错误提示信息
是软件产品最容易忽视的部分，通常是有程序员而不是训练有素的稿手来写的。这
些信息很少照顾到修复软件缺陷的需要，还常常造成麻烦。软件测试员
也难以找到并显示全部信息。在软件中不要加入吓人和不友好的错误提示信息。）
三.软件开发模式
1.大棒式：所有精力都在开发软件和编写代码上
2.边写边改式：没有时间做好，总有时间返工哈哈！这句话经典，测试者几乎每天都
拿到一个新版本，新版本出来的时候，旧版本还没测完！而新版本还包含新的或者经过修改的功能）
3.流水式：创意-分析-设计-开发-测试-最终产品，只许前进不能后退！
4.螺旋式：开始不必详细定义所有细节。从小开始，定义重要功能，努力实现，接受
客户反馈，然后进入下一阶段。（一个螺旋包括6个步骤：1.确定目标，可选方案和限
制条件；2.指出并解决风险；3.评估方案；4.本阶段开发和测试；5.计划下一阶段；
6.确定进入下一阶段的方法。 ）测试一直在进行，知道最后宣布成功！
软件测试读书笔记之三软件测试的实质
一.测试人员要知道的几个‘交通规则’和‘生活法则’~
1.完全测试是不可能的。A.输入量太大；B.输出结果太多；C.软件实现途径太多；
D.软件说明书没有客观标准。从不同角度看，软件缺陷标准不同。
2.软件测试是有风险行为。
3.测试无法显示潜伏的软件缺陷。
4.找到的软件缺陷越多，就说明软件缺陷越多。
5.老用一种药，害虫都有抵抗力，程序也如此，如在螺旋开发模式中，每一个轮回都
会对软件进行测试，几回合后，该发现的都发现了，找不到什么错误了。这要求我们必
须不断编写不同的新测试程序，对程序的不同部分进行测试，以找到更多的缺陷。
6.并非所有的软件缺陷都能修复：A.没有足够的时间；B.不算真正的缺陷；
C.修复风险太大；D.不值得修复
7.难以说清的软件缺陷
8.产品说明书不断变化：软件测试员必须想到产品说明书可能改变。
9.测试员做的工作不受欢迎，因为工作就是挑错！所以我们要懂得怎么和开发的相处：
A.早点找出缺陷；B.控制情绪；C.多交流，不要总是报告坏消息。
10.软件测试是一项讲究条理的技术专业。
二.软件测试的术语和定义
这里引用下网上的术语总结，对原作者表示歉意和谢意和敬意！（不知道是谁）
1.精确和准确：A.精确参照物是目标。与目标越接近，就越准确；B：准确参照物是
每次实施的结果。几次结果相互之间越接近，表示越精确。但与目标可能相去甚远.
2.验证和合法性检查：A.验证保证软件符合产品说明书的过程 B.合法性检查保证软
件满足用户要求的过程.
3.质量和可靠性：可靠性只是质量的一个方面。A.质量可能包含功能是否齐全，产
品能否在各种机器上运行，软件公司有没有技术支持，甚至包装盒的色彩，可靠性
或者软件产品是否经常毁坏数据可能也很重要，但不绝对。B.可靠性：你自己想吧，
我没找到定义哈哈~
4.测试和质量评判(QA)：A.软件测试员的目标是找出软件缺陷，尽可能造一些，
确保得以修复；B.软件质量评判人员的主要指责是创建和加强促进软件开发并防止
软件缺陷的标准和方法
软件测试读书笔记之四检查产品说明书
一.开始测试
1.A：黑盒测试：软件测试员只需知道软件要做什么，无法看到如何运作。只进行输入操作来得到输入结果。
B：白盒测试：软件测试员可以访问程序员的代码，并通过检查代码来协助测试。
2.A：静态测试：测试不运行的部分—只是检查和审阅。
B：动态测试：指通常意义上的测试—运行和使用软件。
3.测试产品说明书属于静态黑盒测试。
二.对产品说明书进行高级审查
测试产品说明书第一步不是去找软件缺陷，而是在一个高度上审视。审查产品说明书是为了找出根本性大问题，疏忽或遗漏之处。
1.占在客户角度思考:设身处地的为客户着想,测试的时候把自己当成客户。
2.研究现有的标准和规范:软件测试员的任务不是定义润件要符合何种标准和规范，而是观察，检验是否套用正确的标准，没有遗漏。
3.审查和测试同类软件:同类软件有助于制订测试条件和测试方法，还可能暴露没想到的潜在问题。
三.产品说明书的低级测试技术
1.优秀产品说明书应当具有的8个属性
A.完整。是否有遗漏和丢失？完全吗？单独使用是否包含全部内容？
B.准确。解决方案正确吗？目标明确吗？有没有错误？
C.精确、不含糊、清晰。描述是否一清二楚？还是自说自话？ 容易看懂和理解吗？
D.一致。产品功能描述是否自相矛盾？与其他功能有无冲突？
E.贴切。描述功能的陈述是否必要？有没有多余信息？功能是否原来的客户要求？
F.合理。在特定预算和进度下，以现有人力、物力和资源能否实现？
G.代码无关。是否坚持定义产品，而不是定义其所依赖的设计、架 构和代码？
H.可测试。特性能否测试？测试员建立验证操作的测试错误程序是否提供足够的信息？
2.产品说明书7个用语检查清单
A.总是、每一种、所有、没有、从不。
看到此类绝对或肯定的切实认定的叙述，可以着手设计针锋相对的案例。
B.当然、因此、明显、显然、必然。
这些话意图诱使接受假定情况。不要中了圈套。
C.某些、有时、常常、通常、经常、大多、几乎。
这些话太过模糊。“有时”发生作用的功能无法测试
D.等等、诸如此类、依此类推。
以这样的词结束的功能清单无法测试。功能清单要绝对或者解释明确。
E.良好、迅速、廉价、高效、稳定。
这些是不确定的说法，不可测试。如果在产品说明书出现，必须要求进一步指明含义。
F.已处理、已拒绝、已忽略、已消除。
这些说法可能会隐藏大量需要说明的功能。
G.如果...那么...（没有否则）。
缺少配套的否则，想一想，“如果”没有发生会怎样呢？
软件测试读书笔记之五闭着眼睛测试软件
一.动态黑盒测试
1.不深入代码细节的软件测试方法称为动态黑盒子测试。它是动态的，因为程序正在运行；它是黑盒子，因为测试时不知道程序如何工作。测试工作就是进行输入，接受输出，检验结果。
2.首先要弄清楚作为测试对象的软件要输入什么得到什么，或者操作结果。这就要求有文挡或产品说明书；接下来开始定义测试案例（就是我们常说的测试用例）
3.选择测试案例是软件测试员最重要的任务。不正确的选择可能导致测试量过大或者过小，甚至测试目标不对。准确评估风险，把不可穷近的可能性减少到可以控制的范围是成功的诀窍。
*4.没有产品说明书的情况下使用探索测试。（这个我觉得很重要，因为国内大部分软件都是这样的，因为国内大部分软件都是这样的，什么说明都没有,没有需求说明,没有产品说明书,没有设计书......呵呵,这就是有中国特色的软件测试吧~~，遇到这种情况不要烦躁，"把软件当成产品说明书来对待。分步骤地逐项探索软件特性。记录软件执行情况，详细描述功能。在这种情况下，无法像有产品说明书那样完整的测试软件--比如无法断定是否遗漏功能，但是可以进行系统测试。找到软件缺陷几乎是肯定的." 小雪经验总结:这种情况还要多和开发的沟通，在他们那了解软件更多的情况。他们自己写的,没有人比他们知道的多.这种测试会遇到很多你认为逻辑不合理的地方,因为没有需求说明,开发的完全照自己的意思来编写代码.有的是多人编写,每人负责一个模块,模块之间衔接和整个软件的业务逻辑多会有许多问题.
二.通过测试和失败测试
通过测试：确认软件至少能做什么，而不考验其能力。只运用最简单，最直观的测试案例。
失败测试：纯粹为了破坏软件而设计和执行的测试案例。
设计和执行测试案例时，总是首先进行通过测试。在破坏性试验之前看看软件基本功能是否实现是很重要的，否则在正常使用软件时就会奇怪为什么有那么多的软件缺陷。常见的测试案例就是设法迫使软件出现错误提示信息。
三.等价分配
等价分配（等价类划分）：是指分步骤地把过多（无限）的测试案例减小到同样有效的小范围的过程。
等价类别或者等价区间是指测试相同目标或者暴露相同软件缺陷的一组测试案例。在寻找等价区间时，想办法把软件的相似输入、输出、操作分成组。这些组就是等价区间。等价分配的目标是把可能的测试案例组合缩减到仍然足以测试软件的控制范围。因为选择了不完全测试，就要冒一定的风险。如果为了减少测试案例的数量过度进行等价分配，测试的风险就会增加。另外，等价区间的划分没有一定的标准，只要足以覆盖测试对象就行了。
（个人认为这里讲的不是很好，在笔记前我就说了，本书测试用例设计方法上做的不是很好，有关知识大家上网看吧，写的很详细，推荐一个风姿清扬整理的测试用例设计方法~。以后遇到相关测试用例设计的问题我都引用一些比较流行的通俗的知识或者直接省去了`。我们设计用例数据的时候按照等价类划分方法：
等价类分为有效等价类和无效等价类，有效等价类就是由那些对程序的规格说明有意义的、合理的输入数据所构成的集合；无效等价类就是那些对程序的规格说明不合理的或无意义的输入数据所构成的集合。
划分等价类的方法：下面给出六条确定等价类的原则。
1、在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
2、在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。
3、在输入条件是一个布尔量的情况下，可确定一个有效等价类。
4、在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
5、在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
6、在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。）
四.数据测试
软件由数据和程序组成。数据包括键盘输入、鼠标单击、磁盘文件、打印输出等等；程序指可执行的流程、转换、逻辑和运算。
对数据进行软件测试，就是在检查用户输入的信息、返回结果以及中间计算结果是否正确。主要根据下列原则来进行等价分配，以合理减少测试案例：边界条件，次边界条件，空值和无效数据。
（个人认为书里介绍边界值这块不是很好，新手还是看下面的吧，流行的比较经典的是边界值分析法：
上点，就是边界上的点，不管它是开区间还是闭区间，就是说，如果该点是封闭的，那上点就在域范围内，如果该点是开放的，那上点就在域范围外；
内点，就是在域范围内的任意一个点；
离点，就是离上点最近的一个点，如果边界是封闭的，那离点就是域范围外离上点最近的点，如果边界是开放的，那离点就是域范围内离上点最近的点。
边界值分析方法的原则：
1、如果输入（输出）条件规定了取值范围，则应该以该范围的边界值及边界附近的值作为测试数据；
2、如果输入（输出）条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据；
3、如果程序规格说明书中提到的输入或输出是一个有序的集合，应该注意选取有序集合的第一个和最后一个元素作为测试数据；
4、如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试数据。）
五.状态测试。
软件状态是指软件当前所处的情况或者模式。软件通过代码进入某一个流程分支，触发一些数据位，设置某些变量，读取某些变量，而转入一个新的状态。软件测试员必须测试软件的状态及其转换。
1.测试软件的逻辑流程。状态测试运用等价分配技术选择状态和分支。因为选择不完全测试，所以要承担一定的风险，但是通过合理选择会减少危险。
2.建立状态转换图。包括的内容有：
A.软件可能进入的每一种独立状态；
B.如果不能断定是否为独立状态，就算它是，以后发现不是，随时把它T开；
C.从一种状态转入另一种状态所需的输入和条件。找出什么操作导致的变化；
D.进入或退出某种状态时的设置条件及输出结果。包括显示的菜单和按钮、设置的标志位、产生的打印输出、执行的运算等等。这些是状态转换时发生的部分或全部现象。
3.减少要测试的状态及转换的数量。
A.每种状态至少访问一次；
B.测试看起来最常见最普遍的状态转换；
C.测试状态之间最不常用的分支。
D.测试所有错误状态及其返回值;
E.测试随机状态转换。
4.具体测试的进行。确定要测试的状态及其转换之后,就可以定义测试案例了。测试状态及其转换包括检查所有的状态变量——与进入和退出状态相关的静态条件、信息、值、功能等等。状态变量也许不可见，但是很重要。
(建议看因果图法写测试用例呵呵)
六.失败状态测试
1.竞争条件和时序错乱:在真正的多任务环境中软件设计绝对不能想当然，必须处理随时被中断的情况，能够与其他任何软件在系统中同时运行，并且共享内存、磁盘、通信设备以及其他硬件资源。这一切的的结果就可能导致竞争条件问题.这些问题的几个事件恰好挤在一起,软件未预料到的操作过程被中断,时序就会发生错乱。竞争条件测试难以设计，最好是首先仔细查看状态转换图中的每一个状态，以找出哪些外部影响会中断该状态。考虑要使用数据如果没有准备好，或者在用到时发生了变化，状态会怎样。数条弧线或者直线同时相连的情形如何。
下是要面临竞争条件的典型情形：
A.两个不同的程序同时保存或打开同一个文档。
B.共享同一台打印机、通信端口或者其他外围设备。
C.当软件处于读取或者修改状态时按键或者单击鼠标。
D.同时关闭或者启动软件的多个实例。
E.同时使用不同的程序方位一个共同数据库。
2.重复、压迫和重负
测试的目标是处理那些连程序员都没有想到的恶劣条件下产生的问题的能力。
A.重复测试是不断执行同样的操作。最简单的是不停地启动和关闭程序，或者反复读写数据或者选择同一个操作。这种测试的主要目的是看内存是否不足。如果内存被分配进行某项操作，但操作完成时没有完全释放，就会产生一个常见的软件问题。
B.压迫测试是使软件在不够理想的条件下运行——内存小、磁盘空间少、CPU速度慢、调制解调器速率低等等。观察软件对外部资源的要求和依赖程度。压迫测试就是将支持降到最低限度，目的在于尽可能的限制软件的必要条件。
C.重负测试和压迫测试相反。压迫测试是尽量限制软件，而重负测试是尽量提供条件任其发挥。让软件处理尽可能大的数据文件。最大限度的发掘软件的能力，让它不堪重负。比如：软件对打印机或通信端口进行操作，就把能连的都连上；服务器可以处理几千个模拟连接，就按他说的做。
三者应联合使用，同时进行。
注意事项:
A.项目管理员和小组程序员可能不完全接受软件测试员这样打破软件的做法。但是软件测试员的任务就是确保软件在这样恶劣的条件下正常工作，否则就报告软件缺陷。如何以最佳方式报告软件缺陷，使其得到严肃对待和修复，也是一门学问。
B.无数次重复和上千次的连接对于手工操作是不可能的。因而需要借助自动化测试工具来实现。
七.其他黑盒测试技术
1.像新用户那样做,随意操作.
2.在已经找到软件缺陷的地方再找找(80%的缺陷通常集中在20%的模块)
3.凭借经验、直觉和预感. (软件测试确实是越有经验越吃香啊!,像我们这样的只能好好学习,多多实践,多多积累,不断总结)
呼! 这章怎么这么长啊!排版很乱,有时间再整理吧,对不起大家的眼睛了,再看看这章名字,闭着眼睛..呵呵,看的眼睛痛了就闭眼睛想一会吧,
最佳答案
段念得测试基础 软件测试方法和技术
最佳答案
是不是所有优秀的开发人员都能够成为优秀的测试人员？
所有的人都知道应该如何进行测试，但是却未必知道要成为一名优秀的测试人员，真正需要哪些素质。
优秀的系统验证测试人员应该具备哪些素质？
在 8 年多的软件开发工作中，我曾从事过各种项目的设计和开发，并且从初级开发人员成长为高级开发人员，最终成了一名软件架构师。在此期间，我意识到测试工作的重要性和挑战，甚至曾自愿地对自己设计的程序进行测试，这是出于“自己解决自己的问题”的考虑。大约在一年前，我成为了系统验证测试 (SVT) 组的负责人。我之所以想到要撰写这个专栏，是因为与所在部门的一名测试人员的闲聊，情况是这样的，该测试人员以前的一名同事申请了我部门中的测试职位。当我向这名测试人员询问有关申请者（当时他正从事开发工作）的情况时，她的回答是“对这个人我已经记不大清楚了，但他肯定是一名优秀的测试人员，因为他是一名开发人员”。
听到这样的评论我感到震惊，但是后来我发现，对于开发和测试团体来说，这是一个普遍存在的观点。的确存在许多优秀的开发人员和优秀的测试人员，但是在某个方面非常一流，并不一定就意味着在其他方面也同样优秀。所以作为一名测试管理人员，我需要说明成为一名优秀的 SVT 测试人员所面临的挑战和应该具备的独特品质，这不仅仅是要吸引高素质人才加入到这个行列，同时还可以分享这项工作给我们带来的自豪感，并且或许可以为测试工作赢得更多的尊重。
发现客户价值
按照规定，SVT 组负责进行系统级测试。什么是系统级测试呢？这是一个常见的问题。我的理解是，进行系统级测试的目的是为了确保通过产品所提供的功能，实现既定的客户价值。
那么，什么是“客户价值”呢？其答案正是为什么客户购买和使用某种产品的原因之一。例如，我使用 Microsoft® Word 已有许多年了。回忆我个人使用该软件的经历，在早期的版本中，最苦恼的事情是它容易在编辑的过程中发生崩溃，这样就会丢失最近一次保存以来的所有工作。幸好，现在的版本不再出现这种情况了。甚至更加完善，它会定期地自动保存文档，这样一来，即使在退出的时候忘了保存文档，仍然可以恢复到最近一次自动保存的副本，对我来说这是个非常好的特性。这种作为客户的经历使我意识到，尽管该产品提供一般性的功能，但正是其独特的特性使得它能够从众多的竞争产品之中脱颖而出，并且正是这些提供价值的特性使得其客户钟情于该产品。因此，对于优秀的 SVT 测试人员来说，最重要的品质是能够清楚地了解每个特性的客户价值。
尽管可以很容易地从设计文档或用户手册的简介部分中找到每个特性所允诺的客户价值，但是要有效地将它们合并为测试设计方案的核心，并不是那么简单。要实现这一点，测试人员需要了解技术的采用周期，以及该技术当前位于其采用曲线中的什么位置。他还需要了解提供类似客户价值的竞争技术，以及有可能共同使用的协作性技术。
测试更广泛的场景
我观察到新的 SVT 测试人员常犯的一个错误是，他们总是从局部而非整体的角度来看待某种技术（或者产品特性）。结果，测试工作重点关注于产品与设计的符合性，而不是它所提供的真正价值。例如，当在 J2EE™ 技术中引入容器管理的持久性时，其目标是为数据库的访问提供一种更简单并且更具可移植性的编程模式，它的竞争技术是其他持久性技术，如 JDBC 和持久的数据对象。如果该技术或特性不易于使用，并且不能够伸缩或至少执行其竞争技术所能完成的任务，那么该特性就难以获得接受，即使客户购买了这个产品，他们也不会使用该特性。因此，SVT 测试人员的任务是发现问题的本质，并在产品发布之前进行报告。
是可以工作，还是工作得更好？
不久之前，一名测试人员向我解释她正在测试的新的安全会话特性，如何通过在每次调用中与信任服务器联系以便进行身份验证，从而使得 Web 服务能够更好并且更安全地执行。我很怀疑向信任服务器进行附加调用的时间是否短到足以避免抵销这个新特性所节省的时间，以及这个信任服务器是否向系统中引入了单点故障。
对于 SVT 测试人员来说，对该特性及其相关特性的技术知识同样重要，并且仅仅有技术上的知识是不够的。使用客户价值作为特性测试的核心，还需要测试人员考虑更多的内容，在有些情况下，需要跨越组织的界限。当我提出关于信任服务器性能方面的担心时，该测试人员的回答是“我不负责测试性能，那是由性能团队负责的”。还有一次，有个客户向我询问关于产品如何在重负载下处理事务恢复的问题。执行这个测试场景的测试人员无法回答这个问题，因为她根本没有进行负载测试。
在一定程度上，这反映了组织中的定义受到很大的限制。当然，很少有能够很好地处理各种情况的组织结构。我认为，优秀的 SVT 测试人员不仅仅只是完成特性本身的测试工作，并且对任何可能妨碍该特性实现其允诺的客户价值的问题保持高度的警惕，无论是性能优于该特性的竞争技术、或未能很好集成的协作特性、或特性本身没有达到预期效果、或在系统中产生了附加的缺陷
|
