软件工程期末总结

Software Engineering-v2

据说基本就是上课的题

Chapter1:intro

• software=computer programs + associated documentation
• we need methods to develope high-qualified software that are: standard,systematic,efficient,dependable,easy-to-use
• software engineering is an discipline that is concerned with all aspects of software production from initial conception to operation and maintenance.
• History of software engineering:

• SE's composition:

  • software development(needs methods, techniques and tools to support)

    • requirements engineering
    • software design
    • coding
    • testing
    • maintenance
  • project management

• delevoping software:(整个design testing 等等都不是同一套体系)

  • structured
  • object-oriented

• software engineering ethics

  • confidentiality
  • competence
  • intellectual property rights
  • computer misuse

Chapter2:software process model

Organization of processes and activities

Key points in this chapter:

1. What is software process?
2. What is software process model?
3. What are the software process models and what's their advantages and disadvantages and implementation area?
4. Difference between plan-driven and agile?
5. What is agile method?
6. What are the steps of software process?

Fundamental activities in software processes

(all processes involve the following steps)

• Specification:what the system should do
• Design and implementation:the organization of system
• Validation:checking if it does what the customer wants
• Evolution:changing in response to customer need(changing requirements) development and evolution

• descriptions of activities in software process

  • Products
  • Roles

  • Pre- and Post- conditions

    • Pre-condition
    • Post-condition:conditions that must test true after exiting this module

      (退出这个module时 如果不符合post-condition 表示这个module是有错的)

• software process:a sequence of activities leading to the production of a software product.
• software process model/aka product life cycle : an abstract representation of a software process.

• software processes(后面还有)

  • Plan-driven processes:Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan.
  • Agile processes:In agile processes, planning is incremental and it is easier to change the plan and the software to reflect changing customer requirements.

Software process models:

• Waterfall model:Plan-driven strict order

  前一个activity结束才能进行下一个activity

  5 steps in waterfall model:

  • requirements definition
  • system and software design
  • implementation and unit testing
  • integration and system testing
  • operation and maintenance

  Advantages of waterfall model

  • (The plan-driven nature of the waterfall model) Helps coordinate the work
  • Good requirements imporves software quality.

  Disadvantages of waterfall model: difficult to deal with changing requirements(Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements)

  Application domain of waterfall model:

  • Large system
  • requirements that are well-understood and unlikely to change radically

• Incremental model

  interleaving activities

  

  Advantages of incremental model:

  • dealing with change(The cost of accommodating chaging customer requirements is reduced)
  • repid delivery and deployment(Can use and gain value from the software earlier than is possible with a waterfall model)
  • effective feedbacks(Customers can comment on the demonstrations of the software and see how much has been implemented)

  Disadvantages of incremental model:

  • invisible processes

    Managers need regular deliverables to measure progress.

    If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.

  • degrading system structure(system structure tends to degrade as new increments are added)

    Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly.

  Application condition of incremental model:

  • limited time and budget
  • changing requirements

• Reuse-oriented model

  component search and configuration

  Key points of re-use oriented model:

  • Component selection
  • Component filtering
  • Component-dependent requirements development

  Types of component

  • Web services
  • Collections of objects(developed as a package to be integrated with a component framework suh as .NET or J2EE)
  • Stand-alone software systems(COTS)

  Advantages of reuse-oriented model:

  • Reduce the amoung of software to be developed
  • Reduce cost and risk
  • Faster delivery

  Disadvantages of reuse-oriented model:

  • Inevitable requirements compromises
  • Different from real needs
  • Components out of control
• These models are not mutually exclusive and are often used together, especially for large systems development.
• For large systems, it makes sense to combine some of the best features of the waterfall and the incremental development models.
• You need to have information about the essential system requirements to design a software architecture to support these requirements. You cannot develop requirements incrementally.
• Sub-systems within a larger system may be developed using different approaches.
• Parts of the system that are well understood can be specified and devel- oped using a waterfall-based process.
• Parts of the system which are difficult to specify in advance, such as the user interface, should always be developed using an incremental approach.
• 一个问题：只会考ppt上的三种process models嘛？

Coping with change

Cost of change include rework and the cost of implementing new functionality.

• How to reduce the cost of rework?

  • Changing avoidance:

  • Change tolerance:

• Prototype can be used in:

  • requirements engineering
  • design processes
  • testing processes

Agile methods(是一种理念、思想和价值观 不是具体的model)

• Why do we need agile methods?

  Overheads of tradition way of developing softwares is too big: planning+designing+documenting the system.(Disatisfaction with the overheads)

  To reduce overheads in the software process and to respond quickly to changing requirements without excessivee rework.

• Agile methods applicability

  • product development: a software company is developing a small or medium-sized product.
  • custom system development:An organization, where there is a clear commitment from the customer to become involved in the development process and where there are not a lot of external rules and regulations that affect the software.

• Agile methods（问题：这些agile methods的具体方法的含义需要知道吗？）

  • Extreme programming(XP):best known, most widely used
  • Scrum(敏捷开发)

    focus is on managing iterative development rather than specific agile practices.

  • Crystal
  • Adaptive software development(ASD)
  • DSDM(Dynamic Systems Development Method)
  • Feature driven development(FDD)

• software processes

  • Plan-driven development

    • Based around seperate development stages
    • Not necessarily waterfall model
    • Iteration occurs within activities

      

  • Agile development

    • Specification, design, implementation and testing are interleaved
    • A process of negotiation during the software development process decide the outputs
    • Iteration occurs across activities, the requirements and the design are developed together, rather than separately

      

• How to choose between agile and plan-driven?

  • Plan-driven:

    • detailed specification and design
    • big system
    • require a lot of analysis before implementation
    • if has to be approved by external regulator

  • Agile:

    • rely on good tools to keep track of an evolving design
    • (Some people say) agile methods require better programmer

• Scaling agile mothods：

  • Background: Agile methods have proved to be successful for small and medium sized projects that can be developed by a small colocated team.

    agile methods 最开始是给中小型团队使用的 但是如果想给大型团队使用agile methods 就应该用scaling agile methods中的一种

  • Scaling up to large systems: replace the small one with a larger, more powerful one.

    • More up-front design and system documentation

      For large systems development, it is not possible to focus only on the code of the system. You need to do more up-front design and system documentation.

    • Cross-team communication mechanisms have to be designed and used.

      This should involve regular phone and video conferences between team members and frequent, short electronic meetings where teams update each other on progress.

    • Continuous integration.

      Continuous integration, where the whole system is built every time any developer checks in a change, is practically impossible. However, it is essential to maintain frequent system builds and regular releases of the system.

  • Scaling out to large companies(pipeline): replicate the small one to work in parallel.

    • Refuse to accept risk

      Project managers who do not have experience of agile methods may be reluctant to accept the risk of a new approach.

    • Against standard procedures

      Large organizations often have quality procedures and standards that all projects are expected to follow and, because of their bureaucratic nature, these are likely to be incompatible with agile methods.

    • A wide range of skills

      Agile methods seem to work best when team members have a relatively high skill level. However, within large organizations, there are likely to be a wide range of skills and abilities.

    • Cultural resistance

      There may be cultural resistance to agile methods, especially in those organizations that have a long history of using conventional systems engineering processes.

Activities in software processes:

1. Specification

   

2. Design and implementation

   

3. Software validation

   

4. Software evolution

   evolution stemmed from changing requirements

   development and evolution(maintenance)

   

Chapter 3:requirements engineering

requirements engineering 是为了得到好的requirement

what should the system do?

key points in this capter:

1. What is requirements engineering?
2. What is the purpose of requirements engineering?
3. What's the 4 parts of requirements engineering?
4. What is feasibility study?
5. What are the requirements analysis models?
6. What are formal specification?
7. What are the methods in formal specification?
8. What are the 3 kinds in requirements validation?
9. What are the types of prototype? What's their features and differences?
10. What are software requirements reviews?

Why use requirements engineering?

• Requirements errors are likely to be the most common class of error.
• The quality of requirements is the key to the success of a software project.
• Requirements errors are likely to be the cheapest errors to fix.

Requirement

• Functional requirement(根据不同的software有不同的functional requirement)

  • finding and highlighting a misspelled word
  • displaying a dialog box with suggested replacement

• Non-functional requirement

  • Useability
  • Flexibility
  • Reliability

What is not in requirements:

• design or implementation details
• project planning information
• testing information

Requirements Engineering Composition

• Feasibility study

  (Before getting started)

  • Purpose

    • Determing hether go ahead with project.
    • Should be cheap and fast.

  • Mission

    • Technical: Do the have the technique to implement the system?
    • Economic: Will we earn enough money?
    • Operational: Will the system solve the problems well enough?
• Requirements Elicitation(找到有哪些requirements)

  Process of identifying the needs and constraint of stakeholders(利益相关者) for a software system.

  Requirements elicitation is a complex process that consists of gathering, researching, defining, structuring, and clarifying·a product’s requirements.

  As a result of elicitation, a BA creates a set of project objectives.

• Requirements Analysis（分析找到的需求）

  • Use analysis model as graphical representation
  • Analysis model 一般是graphic类型的 比较直观
  • We cannot use one single analysis model for requirements analysis.
• Requirements Specification

  The product's detailed functional and non-functional requirements reside in a software requirements specification.(SRS)

• Requirements Validation

Requirements Analysis Models

• State-Transition Diagram/State charts (STD)

  Describes how the system transferred among different states.

  不同状态之间的变化

  State: a collection of relationships between variables and certain allowed values.

  Software behaviors are regraded as "state transitions".

  

  Usage:

  • Useful for specification review or test case generation
  • Not suitable for data-intensive systems
  • Powerful notation for demonstrating the change of system states
  • Logical model
  • Suitable for control system and real time system

  How to dram state transition diagram?

  1. 分析有哪些state 有哪些状态控制信息或者是状态的转换过程
  2. 连线 画出状态之间的转变

• Data Flow Diagram (DFD)

  How data flows among different system modules.

  

  

  Process: must get inputs and then produce outputs (immediately)(compare with CDFD)

  DFD可能会有很多层级 Hierachy:interface of high level should be consistent with the low one

  

  Advantages of DFD:

  • A good view of system functions.
  • Intuitive and expressive.
  • Easy to master.
  • Controllable.
  • Effective for transaction-intensive systems.

  Limitations of DFD:

  • Lack of explicit data relationships.
  • Cannot demonstrate temporal features.
  • Not appropriate for control systems.

  How to draw DFD?

  1. 分析这些东西：

     • 数据源头(terminator)
     • 数据终点(terminator)
     • Process
     • 存储(数据库)
  2. 构建顶层DFD（确定系统边界、数据的输入输出、系统功能）

     在顶层DFD中 整张图只会有一个process 就是这个要设计的系统

  3. 对顶层DFD图细化，构建0层DFD（细化顶层数据流图，加入数据存储）0层的编号是1，2，3
  4. 对0层DFD的每个加工进行细化，分别构建1层DFD，依次类推，逐层精化，直至构建出底层DFD图 1层2层...的process编号是类似于1.1 和1.1.1这样的
• Entity-Relationship Diagram (ERD)

  Commonly used data model.

  

• Dialog Map

  

• Decision Table(判定表)

  表示复杂条件和应做的动作之间的对应关系

  

• Decision Tree(判定树)

  

• Use Case Diagram
• Class Diagram
• Activity Diagram

Requirements Specification

• The product's detailed <u>functional</u> and <u>nonfunctional</u> requirements reside in a software requirements specification (SRS).

• Requirements(3个requirement本质上是相同的 是requirements的不同抽象)

  • Business Requirement
  • User Requirement
  • Function Requirement

• Who need SRS:

  • User
  • Customer
  • Project manager
  • Analyst
  • Developer
  • Tester

• Attributes of good SRS

  • Well-structured
  • Abstract
  • Complete
  • Easy to understand
  • Unambiguous
  • Verifiable

Requirements Specification Language

• Natural language
• Graphical models

• Formal specification：define requirements using mathematically precise formal logic languages.

  

  • Data definition in formal specification(Data Dictionary)

    1. Primitive data elements(No further decomposition is possible or necessary)
    2. Composition(Multiple data items)
    3. Iteration(Multiple instances of one item)
    4. Selection(Limited number of discrete values)

  • Formal specification(methods?)

    1. B,Z,VDM(缺点是难理解) 大概知道是什么就行了

       • B

         

       • Z

         

       • VDM

         

    2. SOFL(Structured Object-oriented Formal Language)

       A formal language+ A method for construction

       

       module

       Const//module中用到的常数

       Type//module中用到的类型 int real

       Var//module中使用的变量 b:int

       Behav//module对应的CDFD名

       

       pre //前置条件，满足该条件A才能正确运行

       post //后置条件，描述输出与输入的关系

       decom ci //process A可分解为底层CDFDci

       end_process;

       Process_2;

       ....

       Process_n;

       End-module;

       Hierarchy in SOFL specification

       • One-layer CDFD 只有一层的CDFD

         Describe functions by data flows among processes in the CDFD.

       • Hierarchical CDFD 层次CDFD

         If certain processes are too complex to describe in pre- and post-conditions, decompose them into low-level CDFDs

       Advantages:

       • Integrating graphical representation
       • Construction strategy
       • Tool support

Requirements Validation

Does the specification satisfy user's requirement?

Check consistency between domain knowledge and specification.

3 requirements validation techniques: prototype,review and testing

• Software prototype

  • Pros of software prototype:

    1. Making it alive.
    2. Easy to be understood by non-experts.
    3. Fast.
    4. Closes gaps in customer's understanding of the requirements.
    5. Stimulates customer's thinking.
    6. Early feedbacks.
    7. Deals with variability.

  • Types of software prototype:

    1. 根据description分类：

       • Horizontal(behavioral prototype or mock-up)(就是一个展示表面的demo 类似于原型图)

         Does not dive into all the layers or into system details

         Demonstrate how the user interacts with the target system, the functional options the user will have available.

       • Vertical(structural prototype or proof of concept)(深入的demo 类似于整个正式系统的一小块)

         A splice of application functionality from the user interface through the technical services layers.

         Touches on all levels of the system implementation

         Looks like a subsystem of the target software

    2. 根据purpose分类：

       • Throwaway Prototype(Exploratory prototype)(只是用来展示 展示完之后就丢掉或者整合进系统)

         For answering questions and resolving uncertainties and improving requirements quality.

         Discard or being integrated into the final system

       • Evolutionary Prototype(必须认真写代码 有牢固的代码基础)

         A solid architectural foundation for building the product incrementally.

         Must be built with robust, production quality code

         Takes longer time than throwaway.

  • Building tools of software prototype(在做prototype之前要先做requirement analysis)

    1. Paper:Cheap,Fast,Anytime,Hardly any interaction,Throw away
    2. Software:Tool selection,Interactive behaviors,Maybe used as part of the real system
  • Animation:Evolutionary prototype

• Software review(another kind of documentation)

  Informal review approaches:Lack engineering guidelines and controllable processes.

  • peer deskcheck: ask one colleague to look over my work.
  • passround:invite several colleagues to examine a deliverable concurrently.
  • walkthrough:author describes a deliverable and solicits comments.

  inspection(代码审查)

  Best-estabilished type of formal peer review.

  Inspection Roles:

  • Author:写了SRS的人(software requirements specification)
  • Moderator: inspection leader and organizer
  • Reader/Inspector: paraphrases each requirements for checking defects
  • Recorder: document and confirm detected issues

  

  • Inspection meeting

    • reader describes each requirement
    • inspector brings up

  • defect checklist(在review里还是单独的一个部分？)

    • Organization and Completeness
    • Correctness
    • Quality attributes
    • Special Issues

  • Challenges in software review

    • Large requirements documents:priority and risk
    • Large inspection teams:reduce redundancy
    • Geographical separation of inspectors

• Testing(validation of software)

  • For detecting missing, erroneous, or unnecessary requirements
  • Generate test cases
  • Walkthrough the specification with the test cases
  • Result analysis

Chapter 4:software design

requirements specification: what

design specification:how

software design definition:

A description of the structure of the software to be implemented, the data models and structures used by the system, the interfaces between system components and, sometimes, the algorithms used.

Software design：

• Architectural design: The overall structure of the system. A model that describes how the system is organized as a set of communicating components. Design Patterns and Priciples

• Detailed Design:Strategy, Methods and Tools

Architectural design

Designing the overall structure of the system.

A model that describes how the system is organized as a set of communicating components

• Block diagram

  

• Design Patterns

  Each pattern provides a solution for a kind of design problems under certain conditions

  Knowledge reuse

  Written in natural language

  • Layered architecture pattern
  • Repository architecture pattern
  • Client-server pattern
  • Pipe and filter pattern
  • MVC pattern

    

    

    Compare Design Pattern with Specification Pattern.

• Application architectures

  • Design principles

    • Abstraction: focus on the nature rather than details.
    • Refinement:
    • Information hide: implementation details are hidden. The process and data of a module should be hidden from the modules that do not need them.
    • Modulization

      Decompose the software system into several interrelated modules.

      Each module performs a sub-function and can be independently applied.

      All the modules form a software system that satisfies user requirements.

    • Module independence:

      1. organize items for the same use into a same room(cohesion)
      2. purchase different items for different use(coupling)
      3. independent modules are easier to design, develop, test and maintain.

    • Cohesion:degree of interaction in one module(deep degree)

      

      • Informational Cohesion(每一个操作都有相互独立的代码，并且都在同一个数据结构上操作): performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure.

        

      1. Informational Cohesion

         A module has informational cohesion if it performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure

      2. Functional Cohesion(所有的element module都齐心协力为了一个功能/工作): Module with functional cohesion performs exactly one action.
      3. Communicational Cohesion: performs a series of actions related by the procedure to be followed by the product, but in addition all the actions operate on the same data.
      4. Procedural Cohesion: performs a series of actions related by the procedure to be followed by the product.
      5. Temporal Cohesion(操作在时间上重叠): performs a series of actions related in time.
      6. Logical Cohesion(有可能不会被调用的操作): performs a series of related actions, one of which is selected by the calling module.

         Problem:

         1.Interface may be difficult to understand.

         2.Code for more than one action may be intertwined.

         3.Difficult to reuse.

      7. Coincidental Cohesion(一个模块里有不相关的操作): performs multiple, completely unrelated actions.

         Problem:1. degrades maintainability 2.modules are not reusable

         Solution: break into separate modules, each performing one task.

      另一个版本的各种cohesion解释：

      1. Functional Cohesion: Every essential element for a single computation is contained in the component. A functional cohesion performs the task and functions. It is an ideal situation.

    1. Sequential Cohesion: An element outputs some data that becomes the input for other element, i.e., data flow between the parts. It occurs naturally in functional programming languages.

       1. Communicational Cohesion: Two elements operate on the same input data or contribute towards the same output data. Example- update record int the database and send it to the printer.

    2. Procedural Cohesion: Elements of procedural cohesion ensure the order of execution. Actions are still weakly connected and unlikely to be reusable. Ex- calculate student GPA, print student record, calculate cumulative GPA, print cumulative GPA.

       1. Temporal Cohesion: The elements are related by their timing involved. A module connected with temporal cohesion all the tasks must be executed in the same time-span. This cohesion contains the code for initializing all the parts of the system. Lots of different activities occur, all at init time.

    3. Logical Cohesion: The elements are logically related and not functionally. Ex- A component reads inputs from tape, disk, and network. All the code for these functions is in the same component. Operations are related, but the functions are significantly different.

       1. Coincidental Cohesion: The elements are not related(unrelated). The elements have no conceptual relationship other than location in source code. It is accidental and the worst form of cohesion. Ex- print next line and reverse the characters of a string in a single component.

    • Coupling:degree of interation between different modules(light degree)

      

      1. Data Coupling: Two modules are data coupled if all parameters are homogeneous data items [simple parameters, or data structures all of whose elements are used by called module]

         数据耦合：是指模块借由传入值共享数据，每一个数据都是最基本的数据，比如说几个字符串和几个int等等，而且只分享这些数据（例如传递一个整数给计算平方根的函数）。

      2. Stamp Coupling(特征耦合，标记耦合，几个模块共享一个复杂的数据结构): Two modules are stamp coupled if a data structure is passed as a parameter, but the called module operates on some but not all of the individual components of the data structure
      3. Control Coupling(控制耦合，一个模块调用另一个模块，传递控制变量比如开关和标志，被调用的模块通过这个变量选择执行某一个功能): Two modules are control coupled if one passes an element of control to the other.
      4. Common Coupling(全局耦合，都对全局变量有写的权限): Two modules have write access to global data.
      5. Content Coupling(内容耦合，耦合度最高，一个模块直接引用另一个模块的数据 或者一个模块直接调用另一个模块): Two modules are content coupled if one directly references contents of the other

      另一个版本的各种coupling的解释：

      1. Data Coupling: If the dependency between the modules is based on the fact that they communicate by passing only data, then the modules are said to be data coupled. In data coupling, the components are independent to each other and communicating through data. Module communications don’t contain tramp data. Example-customer billing system.
      2. Stamp Coupling In stamp coupling, the complete data structure is passed from one module to another module. Therefore, it involves tramp data. It may be necessary due to efficiency factors- this choice made by the insightful designer, not a lazy programmer.
      3. Control Coupling: If the modules communicate by passing control information, then they are said to be control coupled. It can be bad if parameters indicate completely different behavior and good if parameters allow factoring and reuse of functionality. Example- sort function that takes comparison function as an argument.
      4. Common Coupling: The modules have shared data such as global data structures.The changes in global data mean tracing back to all modules which access that data to evaluate the effect of the change. So it has got disadvantages like difficulty in reusing modules, reduced ability to control data accesses and reduced maintainability.
      5. Content Coupling: In a content coupling, one module can modify the data of another module or control flow is passed from one module to the other module. This is the worst form of coupling and should be avoided.
    • Good design has high cohesion and low coupling.

• Tools for architectural design

  • Hierarchy chart
  • HIPO(Hierachy plus Input-Process-Output)

    A hierarchy chart+a set of IPO(input-process-output) charts

Detailed design

Designing the algorithms of each module, data structure and interfaces.

• Flowchart(流程图)

• Problem Analysis Diagram(PAD) 问题分析图

  

Chapter 5:software testing

Software testing definition

A set of activities for identifying failures in a software or system to obtain user satisfaction.

Definitions

1. Test case：A set of input values + execution pre-conditions + expected output + execution post-conditions

   Test case = Input Output Pre and Post Conditions

2. Test case instantiation：

   

3. Test oracle：(测试预言 预期的输出) a mechanism for determining whether a program has passed or failed a test

   • Mechanism
   • Matamorphic

4. Why use software testing?

   • Demonstrate consistency between software program and requirements
   • Discover incorrect behaviors of the software
   • Not able to prove the correctness of the software program

Testing levels (Unit/Component testing, Integration testing, Acceptance testing)

• Unit/Component testing

  Features:

  • Testing on components
  • Applicable to a piece of independent program
  • Usually with source code
  • Identified defects are directly fixed
  • Discovering errors at an early stage

  

  

  • Diver:

    • A Software component or test tool that replaces a component that takes care of the control and/or calling of a software component.
    • Receives testing data, transmits to tested unit, starts tested unit and prints result.
    • Simplest: Main function

  • Stub:

    • A skeletal or special-purpose implementation of a software module, used to develop or test a component that calls the stub or otherwise depends on it
    • Processes few data and returns values to the calling component.
    • Simplest: assign constant values to the outputs

• Integration testing(集成测试)

  • Big Bang integration

    • Test each unit and integrate units simultaneously.
    • Defects are difficult to isolate.
    • After unit testing, drivers and stubs will not be used any more

  • Top-Down integration(自顶向下)

    • Test the top level first, take the unit called by top level as stubs, then test the second level, take the unit that has been tested as driver unit sequentially.

    • Advantages:

      • Isolating defects
      • Stubs can be reused for developing real components
      • Discovering design problems at an early stage
    • Disadvantage: Low-level components may not be fully tested

  • Bottom-up integration(自底向上)

    • Test the bottom level first, set up driver unit for it, then test the upper level, take the unit that has been tested as stub sequentially.
    • 不需要stub！

    • Advantages：

      • Isolating defects
      • Low-level components can be fully tested since they are called by drivers avoiding defensive programming problem.
    • Disadvantage:Design problems are detected late

  • Sandwich integration(混合法)

    • 上半部分top-down 下半部分bottom-up 中间接口单独测试 所以最上面和最下面会测试的比较多
    • Bottom-up for operation units
    • Top-down for logic units
    • Test the interfaces of the two kinds

      

• Acceptance testing:Objective is to obtain customer or user acceptance of the software

  • User acceptance
  • Operational acceptance
  • Contractual acceptance
  • Regulatory acceptance
  • Alpha test

    用户在开发者的场所进行 Alpha test在受控的环境下进行

  • Beta test

    软件的最终用户们在多个客户场所进行

• Metamorphic Testing F(x)=sinx的example 利用属性来判断

• Different testing levels:

  • Unit/Component testing 中 Driver和Stub 越简单越好

Software testing methods-white box and black box

White-box testing

Can access source code/inner structure of program, base the test cases on the inner structure of the software program.

• Static analysis: Test without executing

  • NULL pointers
  • Use of uninitialized data
  • Incorrect usage of APIs
  • Buffer overruns
  • Error handling issues
  • Unreachable code
• Dynamic analysis: Test while running (Usually used for unit testing)

• Differet covering criteria:

  各种coverage按照覆盖程度从高到低排序：

  1. Path coverage(路径覆盖)
  2. Combinatory coverage(多重条件覆盖/组合覆盖)
  3. Clause/Branch coverage(条件/判断覆盖)
  4. Clause coverage(条件覆盖)
  5. Branch coverage(判断覆盖)
  6. Statement coverage(语句覆盖)
• Path coverage(路径覆盖):

  Designing test cases that enable the execution of each path at least once.

  从起点到终点的每一个possible的路径都走一遍

• Combinatorial coverage: Designing test cases that enable the coverage of each possible combination of the clauses of each decision.

  

  (每个判定中条件的各种组合都至少出现一次)

• Branch/Clause Coverage

  既满足每个clause都能取一次真一次假 又满足每个branch也能取一次真一次假

• Clause coverage: Designing test cases that enable each clause to evaluate to each possible value.

  每个atomic predicate(原子的小式子)都要取真和取假一次

  predicate 断言、谓语、谓词

  clause 子句

  

  

  Clause Coverage Example:

  

  • Active clause coverage(Same as MCDC/ Modified Condition/Decision Coverage

    对于不同情况 每个predicate里面决定这个clause的TF的clause就叫做active/major clause

    

    MCDC(修正条件判定覆盖)：每一个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；

    程序的判定被分解为通过逻辑操作符（and,or）连接的bool条件，每个条件对于判定的结果值是独立的。

  • Branch coverage/decision coverage: Designing test cases that enable the execution of each branch of each decision at least once.

    (每个判断取真分支和取假的分支至少一次)

  • Statement coverage(语句覆盖): Designing test cases that enable the execution of each statement at least once.

    (每个判断语句和statement语句都至少执行一次 并不管你的true和false 每个方框和菱形都走一遍就是了)

  • Graph coverage:

    • Node coverage
    • Edge coverage

Black-box testing

Test case design based on the specification of the software product

• Input space partitioning

  (分成的部分之间不能有重叠 同时得把所有可能的input都分区)

  • IDM(Input Domain Modeling) approach

    1. Interface-based IDM:Developing characteristics directly from input parameters to the program

       • Missing some important combinations of parameters since each parameter is analyzed in isolation
       • Easy to translate abstract tests into executable test cases
       • Easy to identify characteristics

    2. Functionality-based IDM:Developing characteristics from a functional or behavioral view of the program

       • Likely to yield better test cases since it includes more semantic information
       • If the system is large and complex, or the specifications are informal and incomplete, it can be hard to design reasonable characteristics
       • Requirements are available before the software is implemented and IDM can start early in the development
       • Harder to generate executable test cases
• Boundary value analysis

• Different black box testing techniques for different specification languages

  • Finite state machine
  • UML
  • Scenario-based
  • Z,B,SOFL

• Tool support for black-box testing

  • Test case generation(MC/DC / Modified Condition/Decision Coverage)
  • Expected result generation

• Grey-box (不深入讨论)

Chapter 6:object oriented software development

Basic concept of object-oriented

1. Object(对象)

   An entity with a well-defined boundary

   and identity that encapsulates state and behavior.

2. Class(类)

   A set of objects that share the same properties and behaviors.

3. Inheritance(继承)

   Subclasses inherit all features of their superclasses:

   • attributes
   • operations
   • relationships
   • stereotypes, tags, constraints

   Subclasses can add new features

   Subclasses can override superclass operations

4. Message

   A specification of a communication between objects that conveys information with the expectation that activity will ensue.

5. Abstraction(抽象)

   • Emphasizes relevant characteristics
   • Suppresses other characteristics

6. Encapsulation(封装)

   In design, attributes usually have private visibility (encapsulation).

7. Polymorphism(多态)

   Different implementation behind a single interface.

   Polymorphism = "many forms". A polymorphic operation has many implementations

Object-oriented analysis and design

Four steps in object-oriented analysis

1. Identifying objects and classes.
2. Identifying the object relationships.
3. Identifying the attributes.
4. Identifying services.

UML(Unified Modeling Language)

• Class diagram

  • Most widely use diagram of UML.
  • Static view of a system.
  • used for specifying structure, interface and relationships between classes that from the foundation of system architecture.

  • What's in a class:

    • ClassName:UpperCamelCase
    • Attribute: visibility(+ - #) name : type [multiplicity] = initialValue

      (除了名字 别的都可以没有)

      lowerCamelCase

    • Operations: visibility(+ - #) name(direction parameterName : parameterType = default,...) : returnType

      lowerCamelCase

  • 类之间的关系

    • aggregation(聚合):元素之间是整体和局部的关系。聚合关系强调的是整体和部分的关系，其中部分可以脱离整体而存在。

      用空心菱形表示

    • composition(组合):元素之间也是整体和局部的关系。但是不同的是部分无法脱离整体存在。

      用实心菱形表示

    • dependence(依赖):依赖关系是一种很弱的关系，一般是指一个类使用另一个类，这里学生捡到钱交给警察叔叔，学生和警察叔叔就是一种依赖关系。

      用虚线的箭头表示

    • association(关联):关联关系是一种比较强的关系，他们的关系是比较持久稳定的。

      比如学生从家里出来，学生和家就是一种关联关系。这种关系是比较稳定的。关联分单向关联和双向关联，如果一个类知道或者引用了另一个类，而另一个类不知道或者没有引用这个类，则这两个类是单向关联的。

      用实线箭头(单向联系)或者一根实线(双向联系)表示

    • generalization(泛化):表示继承
    • realization(实现):表示对于一个接口的实现
  • Classes 之间的联系叫associations(classes 之间有assiciation就表示这些class的实体化objects之间有links) Ojects之间的联系叫做links
  • Multiplicity是用来约束参与联系的object数量的

    

  • Generalization:一个比较general的元素和一个更具体元素之间的联系

    子类(Subclasses)具有超类(Superclasses)的所有feature

    

  

  

• Use-case diagram

  The context of the system to be built and the functionality provided by that system.

  

  

  

  

• Sequence diagram

  

  

  Message:an arrow from sender to the receiver

  1. Synchronous message
  2. Asynchronous message
  3. Response message
• State Machine Diagram

  

Object-oriented testing:

• Individual class testing

  • Random
  • Partition testing(state,attribute,function)
• Integration testing