What is meant by flow specification?

- There are many problems concerning the flow specification. 

- There are limited options for the provider for mitigation of the DDoS attacks that take place internally. 

- These can be categorized in to three different categories:

Ø  BGP (border gateway protocol) destination black holes

Ø  BGP src/ uRP

Ø  ACLS

- The basic idea is to make use of the BGP for the distribution of the flow specification filters. 

- This helps in dynamic filtering in the routers. 

- The flow specification rules are encoded according to the BGP NLRI address family. 

- The flow spec NLRI is used by the BGP as its opaque key is used as an entry key for its database. 

- The extended communities are used for specifying the actions such as accepting, discarding it, rate limiting, sampling, redirecting and so on. 

- The source/destination prefix and the source/destination port are matched in combinations according to the packet size, ICMP type/co9de, fragment encoding, DSCP, TCP flag and so on. 

- For example, the TCP ports 80…90 are matched with 192.168.0/24. 

- The flow specification trust model uni casts the routing advertisements for controlling the traffic. 

- Filter is considered as a hole for the traffic that is being transmitted to some destination. 

- Filter is accepted when it is advertised for the destination by the next hop. 

- Filters with various flow specifications are available today.

- The major benefit of the flow specifications is the filters with the fine grain specification which make it easy for deploying and managing the BGP. 

- The trust and the distribution problems are solved by the BGP. 

- ASIC filtering in routers is leveraged. 

- This is another major benefit of flow specifications. 

Apart from the benefits, there are various limitations of the flow specifications as mentioned below:

Ø  There is no update level security in the BGP.

Ø The statistics and the application level acknowledgement are not well defined.

Ø  The flow specifications work only for those nodes for which the BGP has been enabled.

Ø  Beyond routing the BGP payload has to be overloaded.

Ø  There are various operational issues between the security operations and the network operations.

Ø  The threat information cannot be gathered in one place.

- The integration of the flow specifications was announced by various security vendors. 

- The DDoS attacks are experienced by a large number of customers. 

- The DDoS attacks are now massive and have put the network infrastructure at risk apart from the end customer. 

- Congestion problems occur at both the exchange and the backbone. 

- The attacks of long durations add to the cost of bursting and circuit congestion problems. 

- Depending up on the size of the attack the POP has to be isolated.

- VoIP is also affected. 

- These attacks have negative economic effects as the cost of the operations has been increased. 

- This has led to a degradation of the business. 

- Measures such as firewall filtering and destination BGP black-holing have proved to be insufficient in preventing the attacks. 

- These methods are slow since it is required to log-in and configuring the devices. 

- The configuration has to be constantly. 

- The traffic is terminated to some destination. 

- This affects the availability. 

- The black hole routes are removed by constantly changing the configurations. - Earlier version of the flow specifications had many bugs. 

- There were some limitations on the performance. 

- However, it provided arbor support for the actions of the flow specifications. 

- It does not provide multi–vendor support. 

- To some extent it provides the mitigation facility for the attack that occurred at the source. 

- The collateral damage is eliminated for both the carriers and supports the change in the matching criteria. 

What are different rules of thumb to write good test cases?

Writing good and effective test cases requires great skills since after all effective testing is achieved by effective test cases only!

Writing such test cases is a great skill in itself and can only be achieved by in depth knowledge of the software system or application on which the tests are being carried out and it also requires some experience.

Here I’m going to share some rules of thumb to write effective test cases, basic test cases definition and test case procedures.

What is a test case actually?
A typical test case is comprised of components that are meant to describe an action or event, input and an expected outcome in order to determine whether the software system or application is working as it is meant to or not.

Before writing a test case you should know the 4 levels or categories of the test cases to avoid their duplication.
The levels have been discussed below:

Level 1:
This level involves writing of basic test cases using the available specifications and requirements and documentation provided by the client.

Level 2:
This level is the practical stage and it involves writing of test cases based on the actual system flow and functional routines of the software system or application.

Level 3:
This level involves grouping of some particular test cases. Some test cases are grouped together and a test procedure is written. A test procedure can have maximum up to 10 test cases.

Level 4:
This level involves the automation of the project. This leads to minimization of the human’s interaction with software system or application. This is done basically to maximize the focus upon the currently updated functionality to be tested rather than focusing on regression testing.

Following this whole pattern you can have an automated testing suite from no testable item, i.e., you can observe a systematic growth.
- The tester should know the objective of each and every particular test case.
- The basic objective of all the test cases is to validate the testing coverage of the software system or application.
- You need to strictly follow test cases standards. Writing test cases reduces the chances of following an ad- hoc approach.

Below given is a basic test case format:
- Test case id
- Units to be tested
- Assumptions
- Input /test data
- Execution steps
- Expected outcome
- Actual outcome
- Success or failure
- Observation
- Comments

You need to write a test case statement also. So here’s the basic format:

- Verify:
This is the first word of the test case statement.
- Using tool names, tag names, dialogues etc: this is basically to identify what is being tested.
- Verification with conditions.
- Verification to result.

For any kind of testing:

- You will cover all types of tests like functional test cases, negative value test cases and boundary value test cases.
- Be careful while writing the test cases.
- Keep it simple and easy to understand.
- Don’t write test case statements with the length of an essay.
- Keep it brief and to the point.
- Follow the test cases and test case statements formats stated above.
- Generally spreadsheets are used to write test cases which make them more presentable and easy to understand.
- You can use tools like “test director” when you want to automate the test cases.
- Writing clear and concise test cases forms an important part of software quality assurance.
- Also be careful that a good number of test cases cover functional testing which means that the primary focus is on how the feature works.

What are different characteristics of resilience testing?

What does resilience mean? It’s important to know the meaning of resilience first because so many people confuse themselves with recovery, reliability and resilience. They think it’s all the same. But it is not so.

- Resilience means to recover from a change.
- It’s slightly different from recovery and reliability.
- Every software application or system has to have some degree of resilience in it in order to be more secure and recoverable and reliable.
- Resilience is a non functional requirement of a software system or application.
- Resilience testing falls under the category of non functional testing.

It is very common for the interchanging use of many non functional tests because of the overlapping in the scope between many non functional aspects or requirements.
One thing to be noted is that software performance is a broad and vast term and includes many specific requirements like scalability, reliability, compatibility, security and resilience.

Non functional testing contains the following testing techniques:
- Compliance testing
- Baseline testing
- Documentation testing
- Compatibility testing
- Load testing
- Localization testing
- Endurance testing
- Internationalization testing
- Recovery testing
- Performance testing
- Security testing
- Volume testing
- Usability testing
- Stress testing
- Scalability testing
- Resilience testing

Software system or application developers with disaster recovery plans or techniques are said to be actively and effectively engaged in reducing the risk of the software system or application crash, failure or data loss. But, the irony is that these disaster recovery plans become complacent.

This happens so because many of the software developers or testers have a false sense of security based on the existence of their disaster recovery plans. To ensure the safety of the software system or application the software developers need to test their data recovering strategies. Some software developers or testers feel this doesn’t applies to all programs because they conducted resilience testing when the software system or applications were put in place.

But one should always keep this in mind that the testing environment, the testing strategies and the range of cost effective solutions and tools available are always changing. It is required to keep pace with all these changes.

- The resilience testing strategies need to be tested and reviewed frequently in order to update for these changes.
- Some software developers and testers fear about the time and cost of test cases that give a better grade of tests and hence they are not able to put their good intention in to the practice and hence there remains a lack of resiliency in the software system or application.
- This does not necessarily means that each and every available test case should be implemented for testing the software system or application.

- There should be test plan for carrying out the resilience testing.
- A structured methodology always ensures that the amount of time consumed is minimum and the effectiveness of the testing is maximum.
- Resilience testing is some what similar to stability testing, fail over testing or recovery testing.
- Resilience testing is aimed at determining the behavior of the software system or application in the case of unreliable events, catastrophic problems and system failures, crashes and data losses.
- Resiliency is one of the core attributes of a good and reliable software system or application.
- Any software or hardware malfunctioning or failures are likely to have a considerable impact on the software system or application.

A software system needs to resilient against the following:
- Changes in requirements and specifications of the system.
- Hardware and software faults.
- Changes in data sources.

Resilience needs to be incorporated in the following stages of software development:
- Software design
- Hardware specification
- Configuration
- Documentation
- Testing