Software Quality – Lecture # 1
COMP 10066
Week 2 Lecture
Copyright By PowCoder代写 加微信 powcoder
Exploratory and Testing
Recorded by
Exploratory Testing
Exploratory testing is often thought of as a black box testing technique
Instead, those who have studied it consider it a test approach that can be applied to any test technique, at any stage in the development process.
The key is not the test technique nor the item being tested or reviewed; the key is the active engagement of the tester, and the tester’s responsibility for managing his or her time.
Testing that is done where access to the program source code is not available and/or needed.
https://www.imperva.com/learn/application-security/black-box-testing/
The test technique is executed by applying an input that will produce a known response that can be evaluated for correctness.
Correctness can be evaluated against either a known (expected) response/result that has been specified in the requirements
OR Confirmed against a known standard response/result.
Independent/External validation
Test to Pass
Normal data that a user would enter into an application.
User is using the program as expected
Not in a malicious manner or attempt to break it
Normal Data definition
For domain specific applications, the user has knowledge or has been provided with this knowledge.
Example: Postal code in Canada vs Zip code in U.S.
Application may guide user on normal data
It is expected that the program will accept AND produce the correct output based on Test to Pass data.
Test to Fail
Data sets that are not acceptable.
User is not using the program as expected
It is expected that the program will NOT accept or use the data and that it will not impact prior calculated results or impact the program in other ways.
An error message or correct guidance is expected
Test Case Outcome / Result
A test case has a successful or not successful outcome
Successful Test Case
Expected Result matches the Actual Result
Not Successful Test Case
Expected Result does not match the Actual Result
Need to investigate and confirm issue
Leads to more test cases
Once issue is confirmed, then a bug would need to be raised
Both Test to Pass and Test to Fail will have an outcome (Successful or Not Successful)
Test Cases
Each Test Data set (input) will form the basis of a single Test Case.
Things to think about when creating test cases
How many Test Cases do we need?
When do we stop testing?
What do we emphasize?
Test to Pass
Test to Fail
Boundary Testing
It is not feasible to test every single input value
Bugs are more likely to occur at the bounds of a input value
Example: More likely to have a bug at the bounds of an array
try to access array.length instead of array.length-1 to get the last element
Therefore, when selecting values to test, it is important to test at and around the bounds
Boundary Analysis and Equivalence Partitioning
Given a single input, which has a valid range of 1 to 10
Determine the best values to use in testing, to ensure good data coverage
Don’t forget to think of test to pass and test to fail test cases
Boundary Analysis and Equivalence Partitioning
Given a single input, which has a valid range of 1 to 10
Select test data in each partition, at the boundaries
/docProps/thumbnail.jpeg
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com