整理笔记(十)

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 Criteriaare 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 Elementsare 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 Environmentincludes 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 Techniquesare strategies for creating tests. All techniques involve some sort of analysis of project environment, product elements, and quality criteria.

Perceived Qualityis 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历史记录,配置问题,技术支持请求和明显的客户混淆问题-进一步深化失败模式的清单.