看士兵突击好像是很久以前的事情了，今天公司的一个单纯的小男生突然兴致勃勃的和我说，他最喜欢看士兵突击了，让我又回味起那些活生生的面孔。其实我是断断续续的看，整体的情节还是知道的，但是人们最喜欢的班长史今，我确看到的剧情不多，因为前部分我看得少，后部分看得多。当然印象最深的就是袁朗了，还有许三多，贯穿全剧始终的人物，还有就是吴哲，不光他在剧中是一表人才，而是青葱少年时，就是我的白马王子，因为他就是饰演十七岁不哭中的简宁。

  还是从吴哲说起，看到他我总想起我初三的一个寒假看到中央二台播放的电视剧十七岁不哭，那是每个晚上都有期待的假期，因为简宁，学习刻苦，有理想，有内涵，身上看不到俗气，个性坚韧，我现在还记住他说过的话，“忍，就是当你浑身燥热的时候，还主动靠近火炉旁”。那时候我多想我的高中生活也能碰到象简宁这样的人，可惜没有，最主要因为我不是杨宇凌。看到吴哲，我总感觉是简宁长大了，他们身上的优秀面比较相似。吴哲才思敏捷，却理性沉稳，却时常提醒自己要保持平常心，他也是这样做的。这种平常心是多么难能可贵呀。突然想再次感叹时光的匆匆呀，少年不在，似乎还有儿时纯真的情节，或许也是自己的一时假纯呀。

  袁朗，似乎看过电视剧的女生都喜欢他，理由很简单，他承载了我们对男人的所有美好的期待。他文武双全，本质善良，却外表又野性不羁，有股脱俗的神态，他给人以力量，说的夸张一点，他魅力四射，深邃而神秘。让人怦然心动，而又不得不承认如果现实生活中真的存在，我恐怕只能远远的观望了。我喜欢的人应该是有些脱俗的，虽说世事哪有不为俗事所累，可我还是希冀现实生活中的某些人的心地有些纯真的净土。

  再说男人之间的感情，男人之间的情是粗犷的，源远流长的。看士兵突击，最多是为剧中人物之间真挚的感情所感动，看似平常的事情，却充满了真挚的关心，看似无言的话语，却有深深的牵挂。剧中的男人之间的感情让我羡慕，曾经看过一本书，说女人之间的友谊就是漆黑的夜路陪你说话的人，当漆黑的夜路没有了，那么相互陪伴说话的人也就没有了。前几天看电视采访一个女明星，她特意强调说闺中密友的感情要比爱情更牢固，当时很惊讶她的说词，后来才知道原来她失恋了，也许是一时的感慨才有此话语吧。想想自己这些年都有哪些交心的女友，真是寥寥无几，想到的都是儿时一起长大，现在已是多年不见了。

 

 

pointer：光标,显示在屏幕上让用户移动以选择对象和命令的符号。通常显示为一个小的箭头。但是在文字处理的应用程序则是用象大写I一样的光标。

icon:图标,代表命令，文件或窗口的小图片。通过移动光标到图标上然后按下鼠标，用户可以执行预定的命令。

window:窗口

Form:表单

Property Sheets:属性页

menu:菜单

tool bar:工具栏

Status bar:状态栏

progress bar:进度栏

button:按钮

dialog Box:对话框

message Box:消息框

input box:输入对话框

Text Box:文本框

List Box:列表框

combo Box:组合框

Drop-down List Box:下拉列表框

Check Box:复选框

Radio box:但选框

Option box:选项框

Slider:滑动条

Wizards:向导

 

Regression Testing

1.Regression testing:Repeat testing after changes.

1)Procedural:重复运行相同的用例

a:手动,脚本的回归测试

b:自动的GUI回归测试

c:冒烟测试

2)Risk-oriented:找出由于改变而引起的错误

a:BUG回归测试

b:已修复问题的回归测试

c:常规的功能回归测试

3)Refactoring support:帮助开发人员找到代码的改动引起的牵连

2.GUI自动化测试存在的普遍问题

1)不要创建不容易维护的测试脚本

2)不要使得代码针对具体的机器才能工作

3)不要不把自动测试过程当作一个真正的编程过程

4)不要忘记给工作提供文件资料

5)不要草率的处理以前的代码

6)不要把技能高的工作留给外行

7)不要坚决认为测试人员也是开发人员

8)不要使用有很多bug并且没有价值的工具

9)不要低估测试成本

10)不要低估员工培训的需求

11)不要期望短时期内提高生产力

12)不要花费太多时间在回归测试上

13)不要把代码的不稳定性当作借口

14)不要写case的理由拖延找bug

15)不要写过分简单的用例

16)不要期望100%的自动化

17)不要使用录制/回放创建用例

18)不要在空余的时间写孤立的脚本

 

Exploratory Testing in Pairs

1.什么是Paired Testing

1)一台机器两名测试人员

2)xp中的定义:两个人自愿的一起工作,其中的一个人也许一天中是好几个人的伙伴.

            一个人主要负责测试任务,寻找另一个人,也许是新手作为帮手.

2风险与建议

1)Paired testing不是初级测试员搪塞任务的方法,pairs是合作伙伴,通常都是初级人员在键盘旁边,允许后执行尝试自己的想法.

2)责任必须归属一个人.

3)有些人性格内向,他们需要时间和小组交流.

4)有些人很有主见,不能很好的同其他人合作,需要培训.

5)指导和培训是必需的.

Test Design :Test design is a multi-dimensional challenge

1.所有的测试都包含五个方面

  Testers:执行测试的人员

  Coverage:测试什么

  Potential problems:为什么要测试,哪些风险需要测试

  Activities:如何测试

  Evaluation:如何判定测试的结果是通过还是失败

2.Factors involved in test case quality

  imformation objectives

  test attributes

  techniques

3.Information objectives

寻找缺陷

最大限度的提高bug数量

制止不成熟的产品的发布

帮助经理决定上市与否

把技术支持的成本降低到最小

评估与规格说明书是否一致

遵循规章制度

降低安全相关的法律诉讼风险到最低

找到使用产品的安全场景

评估质量

验证产品的正确性

确保质量

4.Test attributes

Power.测试能够揭露出存在的问题

Valid.暴露的问题是确实存在的问题

Value.暴露的问题正是客户想要知道的问题

Credible.客户信任测试人员.

Representative.发现的问题用户很有可能碰到.

Motivating.客户想要修复发现的问题.

Performable.按照设计执行.

Maintainable.容易修改产品.

Repeatable.可以重复进行低成本的测试.

Pop.暴露的是基本和关键的问题.

Coverage.测试没有被别的测试注意的问题.

Easy to evaluate.

Supports troubleshooting.为调试的人员提供有用的信息.

Appropriately complex.程序稳定些采用复杂的测试.

Accountable.

Cost.

Opportunity Cost.为了进行某些测试而不得不放弃其它测试.

 

Scenario Testing

一.Risks of scenario testing

1)Other approaches are better for testing early, unstable code.

场景测试复杂,包含多个功能点,如果第一个功能点就是坏的,那么接下来的测试就不能进行下去.功能点fix了,下一个坏的功能点又会阻碍测试.

场景测试之前对每一个功能点单独测试,可以尽可能快的发现问题.
2)Scenario tests are not designed for coverage of the program.

通过场景测试去覆盖所有的功能点和需求,声明并不是简单的为了完成覆盖率.

3)Reusing scenarios may lack power and be inefficient

记录和从新使用场景测试更有效,这样可以创建更好的场景.

场景测试会暴露设计的缺陷,我们也会很快发现什么样的测试暴露设计的缺陷.

场景测试组合许多功能点和数据就会暴露代码的问题,覆盖更多的组合就需要更多的测试.

场景测试不适合回归测试,单一功能点的测试和单元测试适合使用回归测试.

 

 

Risk-Based Testing

Drive testing from a perspective of risk, rather than activities,
coverage, people, or available oracle.

In risk-based testing, we create harsh tests for vulnerable areas of the program.

Bach's heuristic test strategy model:

 

 

基于风险的启发式测试模型是提醒测试人员进行测试时候需要考虑的问题.

Quality Criteria are high-level oracles. Use them to determine or argue that the product has problems. Quality criteria are multidimensional, often in conflict with each other.

Product Elements are all the things that make up the product. They're what you intend to test. Software is so complex and invisible that you should take care to assure that you don't miss something you need to examine.

Project Environment includes resources, constraints, and other forces in the project that enable us to test, while also keeping us from doing a perfect job. Make sure that you make use of the resources you have available, while respecting your constraints.

Test Techniques are strategies for creating tests. All techniques involve some sort of analysis of project environment, product elements, and quality criteria.

Perceived Quality is the result of testing. You can never know the "actual" quality of a software product, but through the application of a variety of tests, you can derive an informed assessment of it.

project-level risk analysis

一.Project risk management involves

1)对项目的不同风险的鉴别

2)分析每一个分析相关联的潜在成本

3)完善计划和行为去减少风险的可能性和造成的损失

4)持续的评估和监测风险

二.启发式的风险:哪里去寻找错误

1)New things:新的功能点

2)New technology:新的概念会产生新的错误

3)Learning Curve:由未知的知识产生的错误

4)Changed things:改变也许会破坏旧的代码

5)Late change:匆忙的决定或是由于匆忙员工进行了没有信心的改动造成的错误

6)Rushed work:项目长期经费不足或是存在各个方面的质量问题

7)Tired programmers:开发人员加班导致的效率低下和错误

8)Tired programmers:喝酒了,亲人离去,或是开发人员没有代码的交流等等

9)Just slipping it in:一些功能点没有按照计划完成,影响了其他的代码

10)N.I.H.:外部因素导致的问题

11)N.I.H.:没有预算的任务完成的不好

12)Ambiguity:specs和文档中不明确的描述引起的错误的执行

13)Conflicting requirements:

14)Unknown requirements:

15)Evolving requirements:坚持项目开始的需求会满足合同但是也会产出一个失败的产品.

16)Complexity:复杂的代码会有很多问题

17)Bugginess:有许多bug的功能点也会有许多未知的bug

18)Dependencies:错误会引发其他的错误

19)Untestability:低风险效率低的测试

20)Little system testing so far:

21)Previous reliance on narrow testing strategies:

22)Weak testing tools:

23)Unfixability:不能修复bug的风险

24)Language-typical errors:

25)Criticality:重要功能点的严重缺陷

26)Popularity:经常使用的功能点的缺陷

27)Market:

28)Bad publicity:

29)Liability:

Project environment factors

1)Customers.测试项目的客户.

2)Information.测试需要的信息.

3)Team.执行和协助项目的人员

4)Equipment & Tools.测试中需要的硬件软件和文档.

5)Schedules.事件的顺序周期和同步情况.

6)Test Items.被测试的产品,包括Volatility,Volatility,Testability.

7)Deliverables.测试项目中看的见的成品.包括Content,Purpose,Standards,和Media.

8)Logistics:测试中需要的设备和支持

9)Budget:

Failure Modes

1)failure mode就是程序出错的方式

2)Analyze failure modes three angles

a.Quality attribute failures:比如产品中暴露出的可达性(accessibility),可用性(usability)和可维护性(maintainability)的问题.

b.Product element (or, component) failures:比如使用产品进行实际操作的时候,哪种情况会发生错误.

c.Common programming errors:

Quality criteria

Quality criteria是一种高级的oracles,用来判定产品是否存在问题,Quality criteria是多维的,常彼此冲突.

1)Quality criteria categories

a.Operational criteria

.Capability.是否实现了必须的功能

.Reliability.是否工作正常,并且在某些情况有一定的容错性.

  Error handling:产品遇到问题有错误提示,并很容易的恢复.

  Data Integrity:数据能被保护没有遗失和损坏.

  Security:产品有保护限制,未经授权的用户不能使用.

  Safety:在涉及到要伤害生命和财产问题上,产品不能出现故障

.Usability.对于实际要使用的用户是否容易操作.

  Learnability:用户能否快速的精通产品.

  Operability:能够运行产品所需要的最小资源

  Throughput:用户能否快速的完成一个操作

  Accessibility:有缺陷或残疾的用户能否易用产品

.Performance.产品的速度和反应情况.

.Concurrency.能够很好的同时处理多个任务.

.Scalability.能够升级用户数和作业数.

.Installability and Uninstallability.

.Compatibility.与外部模块和配置的兼容程度.

  Application Compatibility:同其它软件产品的兼容性的问题.

  Operating System Compatibility:

  Hardware Compatibility:

  Backward Compatibility:能够兼容以前版本

  Resource Usage:产品没有消耗不必要的hog memory等系统资源

b.Development criteria

.Supportability.可支持性

.Testability.可测试性

.Maintainability.可维护性

.Portability.

.Localizability.

.Conformance to Standards.遵循一些标准的情况.

  Coding Standards.程序员之间的协议或是某个客户的规定.

  Regulatory Standards.一些权威机构关于程序质量和开发过程的规章制度.

  Industry Standards.包括广泛公认的指导方针和正式出台的标准.

Product elements

1)Structures:产品的物理结构的组成部分

  Code:

  Interfaces:

  Hardware:

  Non-executable files:程序以外的文件,包括文本文件,样本数据,帮助文档和图形视频 等等.

  Ephemera and collaterals:除了软件和硬件的任何事务,如文档,web连接和内容,打包和许可协议等.

2)Functions:产品所要完成的事情

  User Interface:同用户的数据交换

  System Interface:同其它程序,硬盘,网络,打印机等的数据交换

  Application:定义和区别产品并完成了核心的功能需求

  Multimedia:

  Error Handling:

  Interactions:产品中各功能的交互和接口

  Interactions:用来帮助测试的log文件,诊断,警告等

3)Data:产品处理的事物

  Input:

  Output:

  Preset:

  Persistent:经过多次操作之后,数据能够长久保存.包括产品的模式和状态,如选项的设置,观察模式和文档内容等等.

  Temporal:数据和时间的对应关系,包括每秒的键击数,文件的日期标志,和分布式系统的同步性.

4)Platform:产品为之依赖的平台.

  External Hardware:

  External Software:如操作系统,驱动,字体等等.

5)Operations:如何使用产品

  Users.

  Usage Profile:

  Environment:

Programming errors and attacks

1)User interface attacks:检测所有输入值

  Attack 1:输入能有错误提示信息的值

  Attack 2:数人能让软件设立默认值的值

  Attack 3:检测所有允许的字符和数据类型

  Attack 4:输入值溢出

  Attack 5:输入互有影响的值,测试其组合

  Attack 6:重复输入相同的值

2)User interface attacks:检测所有输出

  Attack 7:促使每次输入会有不同的结果输出

  Attack 8:促使非法输出

  Attack 9:促使输出属性的改变

  Attack 10:促使屏幕的刷新

3)Exploring stored data

  Attack 11:采用使用不同初始条件的输入值

  Attack 12:使得数据结构存储很多或很少的值

  Attack 13:采用交替的方式改变内部数据的约束条件

4)Exploring computation and feature interaction

  Attack 14:使用无效的操作数进行组合运算

  Attack 15:递归调用函数

  Attack 16:使得计算结果太大或太小

  Attack 17:对共享数据的功能点进行测试

5)Testing from the file system interface: Media-based attacks

  Attack 1:填充文件系统的容量

  Attack 2:使媒体文件被占用或不被使用

  Attack 3:损坏媒体文件

6)Testing from the file system interface: File-based attacks

  Attack 4:命名不合法的文件名

  Attack 5:改变访问允许

  Attack 6:改变和损坏文件内容

7)Code changes cause side effects

  测试更改的功能点

  测试与更改功能有交互作用的功能点

  测试与更改的功能点相关联的日期和日期的设置

  对更改的功能点进行场景测试

基于风险测试的步骤

1.获得风险的想法

2.对于每个想法,要决定测试行为,准备测试,准备测试的资源来收集信息,并要不断的完善.

3.保持风险和测试的可追溯性.

4.记录和报告项目进行中风险的状态.

5.评估测试覆盖的情况,给出一组基于风险的测试,并找出突破口.

6.如果判定了风险很小,就停止测试.

7.对一个部分进行重测,回顾目前为止的测试经历,明确哪些风险测过,哪些要要加强强度测试.

8.添加非基于风险的测试,避免风险测试分析错误.

9.构建bug历史记录,配置问题,技术支持请求和明显的客户混淆问题-进一步深化失败模式的清单.

 

 

 

Combination Testing（组合测试）

组合测试的方法（三种）

1） Mechanical (or procedural). The tester uses a routine procedure to determine a good set of tests
2） Risk-based. The tester combines test values (the values of each variable) based on perceived risks associated with noteworthy combinations
3） Scenario-based. The tester combines test values on the basis of interesting stories created for the combinations

Test Matrices

1)A matrix is a concise organizer of simple tests, especially useful for function tests and domain tests

2)The matrix groups test cases that are essentially the same.

What is equivalence?

4 views of what makes values equivalent.

1)Intuitive Similarity: two test values are equivalent if they are so similar to each
other that it seems pointless to test both.

2)Specified As Equivalent: two test values are equivalent if the specification says
that the program handles them in the same way.

3)Equivalent Paths: two test values are equivalent if they would drive the
program down the same path (e.g. execute the same branch of an IF).对于子集中的任一数据，如果执行路径并不完全相同，那么这个子集不是等价类.

4)Risk-Based: two test values are equivalent if, given your theory of possible
error, you expect the same result from each.

6条确定等价类的原则：
1、在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
2、在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，则可以确立一个有效等价类和一个无效等价类。
3、在输入条件是一个布尔量的情况下，可以确立一个有效等价类和一个无效等价类。
4、在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可以确立n个有效等价类和一个无效等价类。
5、在规定了输入数据必须遵守的规则的情况下，可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
6、在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

Domain testing-域测试

1)AKA partitioning, equivalence analysis, boundary analysis

2)测试方法

a) Divide the set of possible values of a field into subsets, pick values to represent
each subset. The goal is to find a “best representative” for eachsubset,and to run tests with these representatives.Best representatives of ordered fields will typically be boundary values.
b) Multiple variables: combine tests of several “best representatives” and find a
defensible way to sample from the set of combinations.

3)Strengths and weaknesses

a)• Strengths
– Find highest probability errors with a relatively small set of tests.
– Intuitively clear approach, easy to teach and understand
– Extends well to multi-variable situations

b)• Blind spots or weaknesses
– Errors that are not at boundaries or in obvious special cases.The "competent programmer hypothesis" can be misleading.
– Also, the actual domains are often unknowable.
– Reliance on best representatives for regression testing leads us to overtest    these cases and undertest other values that were as, or almost as, good.

测试新代码的基本方法

1)Start with obvious and simple tests.使用一些容易pass的值或case测试,如果fail,说明程序存在严重的问题.

2)Test each function sympathetically.弄懂功能存在的因由和给用户带来的价值.知道了用户希望这个feature做些什么,能够发现和解释功能错误的原因和这项功能和剩下的程序的交互性.

3)Test broadly before deeply.早期测试的目标就是尽快发现大的问题.当程序比较稳定的时候再进行更深度的测试.

4)Look for more powerful tests.系统通过简单测试之后,就要想出更强大的更系统的测试案例,头脑风暴是一种很好的集思广益的办法.

5)Pick boundary conditions.精选case,减轻测试负担.

6)Do some freestyle exploratory testing.从项目开始的第一周到最后一周,每周都应该尝试新的测试.

本地化 全球化 国际化测试概念

1)I18N-Internationalization 具有不同国际市场的普遍适应性。

2)G11N-Globalization 使产品或软件进入全球市场还进行有关的商务活动。

3)L10N-Localization 将产品或软件针对国际的语言和文化进行加工，使之符合特定区域市场的过程。

What is test oracle？

An oracle is the principle or mechanism by which you recognize a problem.

It really means “...it appeared to meet some requirement to some degree.”

A test oracle is the set of predicted result for a set of tests。

An oracle is as a source of expected results.

What is heuristic？

中文意思是“启发式的”，作为一个形容词，形容通过推断以及猜测，而不是通过现成的公式来获得知识。可以用来形容那种未知结果的探索过程，或者试图证明一个猜想的正确性的方法。也就是通过反复试验获取的知识。当作为名词使用时，heuristic表示“探索性的方法或过程”。通过启发式方法来解决问题的程序称为heuristics。启发式方法（试探法）是一种帮你寻求答案的技术，但它给出的答案是具有偶然性的（subject to chance），因为启发式方法仅仅告诉你该如何去找，而没有告诉你要找什么。

 

一.Sakeholder:A stakeholder is a person who is affected by the product.A stakeholder is someone whose preference or opinion might result in change to the product.

二.Computer words

1)tooltips-工具提示

2)scroll bar-滚动条

3)dialogbox-对话框

4)pull-down menu-下拉菜单

5)child windwo-子窗口

6)click on a push button-点击按钮

7)system crash－系统崩溃

8)CAT-core automated testing

9)ABFT-Automated Basic Funtionality Testing

一.A brief introduction of 5M

1)APQP-Advanced product quality planning:is a quality framework used for developing new products in the automotive industry.

2)PPAP-Production Part Approval Process:outlines the method used for approval of production and service commoditics,incluing bulk materials,up to and including part submission warrant in the advanced quality planning process.

3)FEMA-Failure Modes and Effects Analysis is methodology for analyzing potential reliability problems early in the development cycle where it is easier to take actions to overcome these issues,thereby enhancing reliability through design.

4)SPC-Statistical Process Control is the application of statistical cause of variation in a process.

5)MSA-Measurement System Analysis:测量系统分析,使用数理统计和图表的方法对测量系统的误差进行分析,以评估测量的参数是否合适,并确定测量,系统误差的主要成分.

二.The brief of 7S

1)检查表(Data collection form)

2)分层法(Stratification)

3)散步图(scatter)

4)排列图(Pareto)

5)直方图(histogram)

6)因果图(Cause-effect diagram)

7)控制图(control chart)

1.Testing terminology

1)race conditon:竞争状态

2)instrumentation:插装,在程序中插入额外的代码以获得程序在执行时行为的消息.

3)error seeding:错误播种,错误插值

4)code walkthrough:代码走读-一个非正式的同行评审手段,在该评审中,代码被使用一些简单的测试用例进行人工执行,程序变量的状态被手工分析,以分析程序的逻辑和假设.

 

  我有一个习惯把新接收到的东西写在本子上,今天突然想把本子上的东西整理到空间里,算是对过去的一个回顾吧.

1.缺陷类型

F-Function 影响了重要特性

A-Assignment 需要修改少量代码

I-Interface 与其他组件相互影响的缺陷

C-Checking 不适当的数据验证

B-Build/package/Merge 配置库,版本引起的错误

D-Document 影响发布和维护,包括注释

G-Algorithm 算法错误

U-User interface 人机交互缺陷

P-Performance 不满足系统可测量的属性值

N-Norms 不符合多种标准要求 

2.测试名词

1.SOP-standard operatiing procedures标准的操作过程

2.spiral model螺旋模型

3.SQL-structured query language

4.test suite测试套:测试用例或测试脚本的集合

5.test harness测试用具

6.test completion criterion测试完成标准

7.test comparator测试比较器

8.structured walkthrough结构化走读

9.symbolic evaluation符号评价

10.syntax testing语法分析

11.state transition状态转换

12.statistical testing统计测试

13.stepwise refinement逐步优化

14.feasible path可达路径

15.SLA=service level agreenment服务级别协议